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