Теперь, когда мы разобрались с некоторыми ключевыми концепциями узла, мы проанализируем, что позволяет устройствам взаимодействовать друг с другом.
Спецификация Matter использует сложные методы шифрования и дешифрования информации, а также безопасные механизмы для подтверждения подлинности узла и обмена криптографическими учетными данными.
Всякий раз, когда набор устройств в сети использует один и тот же домен безопасности, обеспечивая, таким образом, безопасную связь между узлами, этот набор называется фабрикой (Fabric). Фабрики используют один и тот же сертификат верхнего уровня ( Root of Trust ) Центра сертификации ( CA ) и, в контексте CA, уникальный 64-битный идентификатор, называемый Fabric ID .
Таким образом, процесс ввода в эксплуатацию представляет собой присвоение учетных данных Fabric новому узлу, чтобы он мог взаимодействовать с другими узлами в той же Fabric.
Оперативные полномочия
Корень доверия устанавливается на узле, вводимом в эксплуатацию Комиссаром, обычно на устройстве с каким-либо типом графического интерфейса пользователя, например смартфоне, концентраторе или компьютере, после его получения от Административного менеджера домена ( ADM ), который часто представляет собой экосистему, действующую как Доверенный корневой центр сертификации ( CA ).
Комиссар имеет доступ к центру сертификации (CA). Поэтому он запрашивает у центра сертификации (CA) оперативные учетные данные узла от имени узла, которому поручено управление, или уполномоченного . Учетные данные состоят из двух частей:
Операционный идентификатор узла (или идентификатор операционного узла ) — это 64-битное число, которое уникальным образом идентифицирует каждый узел в фабрике.
Сертификат операционного узла ( NOC ) — это набор учётных данных, которые узлы используют для взаимодействия и идентификации внутри фабрики. Они генерируются в процессе запроса на подпись сертификата операционного узла ( NOCSR ).
NOCSR — это процедура, выполняемая на узле, который вводится в эксплуатацию. Она связывает несколько криптографических элементов и отправляет их Комиссару, который запрашивает у экосистемы CA соответствующий NOC. На рисунке 1 показано это дерево зависимостей и порядок выполнения некоторых операций.
Хотя понимание каждого криптографического элемента важно для разработки SDK, полный анализ их роли и последствий выходит за рамки данного руководства. Важно отметить следующее:
- NOC выпускаются экосистемой CA на реальных производственных тканях.
- NOC криптографически привязаны к уникальной паре ключей узла ( NOKP ).
- NOKP генерируется узлом, вводимым в эксплуатацию в процессе ввода в эксплуатацию.
- Информация NOCSR, отправляемая в экосистему, включает в себя открытый ключ операции узла, но закрытый ключ операции узла никогда не отправляется Комиссару или в УЦ.
- Процесс NOCSR использует входные данные процедуры аттестации , подписывая информацию CSRSR и, таким образом, подтверждая запрос к центру сертификации на создание доверенного NOC.
Процедура аттестации — это процесс, используемый Комиссаром для удостоверения того, что:
- Устройство прошло сертификацию Matter .
- Устройство действительно является тем, чем оно себя называет: оно криптографически подтверждает своего поставщика, идентификатор продукта и другую производственную информацию.
Мульти-администратор
Узлы также могут быть подключены к нескольким фабрикам. Это свойство часто называют многопользовательским. Например, устройство может быть подключено как к фабрике производителя, так и к фабрике облачной экосистемы, при этом каждая фабрика обрабатывает свой набор зашифрованных соединений и работает независимо.
Поскольку несколько фабрик могут сосуществовать, устройство может иметь несколько наборов операционных учётных данных узла. Однако модель данных узла является общей: атрибуты кластера, события и действия являются общими для всех фабрик. Таким образом, хотя учётные данные Thread и/или Wi-Fi задаются в процессе ввода в эксплуатацию, они являются частью сетевого операционного кластера , являясь общими для всех фабрик и частью DM узла, а не учётными данными фабрики.