Фабрика

Теперь, когда мы поняли некоторые ключевые концепции узла, мы проанализируем, что позволяет устройствам взаимодействовать друг с другом.

Спецификация Matter использует сложные методы шифрования и дешифрования информации, а также безопасные механизмы для обеспечения идентификации узла и обмена криптографическими учетными данными.

Всякий раз, когда набор Устройств в сети использует один и тот же домен безопасности и, таким образом, обеспечивает безопасную связь между узлами, этот набор называется Фабрикой. Фабрики используют один и тот же сертификат верхнего уровня центра сертификации ( CA ) ( корень доверия ) и в контексте CA уникальный 64-битный идентификатор с именем Fabric ID .

Таким образом, процесс ввода в эксплуатацию представляет собой назначение учетных данных Фабрики новому узлу, чтобы он мог взаимодействовать с другими узлами в той же Фабрике.

Операционные полномочия

Корень доверия устанавливается на узле, введенном в эксплуатацию Комиссаром, обычно это устройство с графическим интерфейсом определенного типа, например смартфон, концентратор или компьютер, после получения его от Административного менеджера домена ( ADM ), который часто является экосистема, которая действует как доверенный корневой центр сертификации ( CA ).

Комиссар имеет доступ к CA. Таким образом, он запрашивает эксплуатационные учетные данные узла у центра сертификации от имени вводимого в эксплуатацию узла или комиссионера . Учетные данные состоят из двух частей:

Операционный идентификатор узла (или идентификатор рабочего узла ) — это 64-битное число, которое уникально идентифицирует каждый узел в структуре.

Эксплуатационный сертификат узла ( NOC ) — это набор учетных данных, которые узлы используют для связи и идентификации внутри структуры. Они генерируются процессом запроса на подпись эксплуатационного сертификата узла ( NOCSR ).

NOCSR — это процедура, которая выполняется на вводящемся в эксплуатацию узле. Он связывает несколько криптографических элементов, а затем отправляет их комиссару, который запрашивает у экосистемы CA соответствующий NOC. На рисунке 1 показано это дерево зависимостей и порядок выполнения некоторых операций.

Зависимости генерации NOC
Рисунок 1: Зависимости генерации NOC

Хотя понимание каждого криптографического элемента важно для разработки SDK, полный анализ их роли и последствий выходит за рамки учебника. Важно отметить, что:

  • NOC выдаются экосистемой CA на реальных производственных фабриках.
  • NOC криптографически привязаны к уникальной паре рабочих ключей узла ( NOKP ).
  • NOKP генерируется вводимым в эксплуатацию узлом в процессе ввода в эксплуатацию.
  • Информация NOCSR, отправляемая в экосистему, включает в себя операционный открытый ключ узла, но операционный закрытый ключ узла никогда не отправляется комиссару или в центр сертификации.
  • Процесс NOCSR использует входные данные процедуры аттестации , подписывая информацию CSRSR и, таким образом, проверяя запрос центра сертификации на создание доверенного NOC.

Процедура аттестации – это процесс, используемый Уполномоченным для подтверждения того, что:

  • Устройство прошло сертификацию Matter .
  • Устройство действительно является тем, чем оно себя называет: оно криптографически подтверждает своего поставщика, идентификатор продукта и другую производственную информацию.

Мультиадминистратор

Узлы также могут быть введены в эксплуатацию на нескольких фабриках. Это свойство часто называют мультиадминистратором. Например, у нас может быть Устройство, подключенное как к Фабрике производителя, так и к Фабрике облачной экосистемы, при этом каждая Фабрика обрабатывает свой набор зашифрованных сообщений и работает независимо.

Поскольку несколько Фабрик могут сосуществовать, Устройство может иметь несколько наборов рабочих учетных данных узла. Однако модель данных узла является общей: атрибуты, события и действия кластера являются общими для всех фабрик. Таким образом, хотя учетные данные Thread и/или Wi-Fi задаются во время процесса ввода в эксплуатацию, они являются частью сетевого операционного кластера , совместно используются всеми фабриками и частью DM узла, а не учетными данными фабрики.

,

Теперь, когда мы поняли некоторые ключевые концепции узла, мы проанализируем, что позволяет устройствам взаимодействовать друг с другом.

Спецификация Matter использует сложные методы шифрования и дешифрования информации, а также безопасные механизмы для обеспечения идентификации узла и обмена криптографическими учетными данными.

Всякий раз, когда набор Устройств в сети использует один и тот же домен безопасности и, таким образом, обеспечивает безопасную связь между узлами, этот набор называется Фабрикой. Фабрики используют один и тот же сертификат верхнего уровня центра сертификации ( CA ) ( корень доверия ) и в контексте CA уникальный 64-битный идентификатор с именем Fabric ID .

Таким образом, процесс ввода в эксплуатацию представляет собой назначение учетных данных Фабрики новому узлу, чтобы он мог взаимодействовать с другими узлами в той же Фабрике.

Операционные полномочия

Корень доверия устанавливается на узле, введенном в эксплуатацию Комиссаром, обычно это устройство с графическим интерфейсом определенного типа, например смартфон, концентратор или компьютер, после получения его от Административного менеджера домена ( ADM ), который часто является экосистема, которая действует как доверенный корневой центр сертификации ( CA ).

Комиссар имеет доступ к CA. Таким образом, он запрашивает эксплуатационные учетные данные узла у центра сертификации от имени вводимого в эксплуатацию узла или комиссионера . Учетные данные состоят из двух частей:

Операционный идентификатор узла (или идентификатор рабочего узла ) — это 64-битное число, которое уникально идентифицирует каждый узел в структуре.

Эксплуатационный сертификат узла ( NOC ) — это набор учетных данных, которые узлы используют для связи и идентификации внутри структуры. Они генерируются процессом запроса на подпись эксплуатационного сертификата узла ( NOCSR ).

NOCSR — это процедура, которая выполняется на вводящемся в эксплуатацию узле. Он связывает несколько криптографических элементов, а затем отправляет их комиссару, который запрашивает у экосистемы CA соответствующий NOC. На рис. 1 показано это дерево зависимостей и порядок выполнения некоторых операций.

Зависимости генерации NOC
Рисунок 1: Зависимости генерации NOC

Хотя понимание каждого криптографического элемента важно для разработки SDK, полный анализ их роли и последствий выходит за рамки учебника. Важно отметить, что:

  • NOC выдаются экосистемой CA на реальных производственных фабриках.
  • NOC криптографически привязаны к уникальной паре рабочих ключей узла ( NOKP ).
  • NOKP генерируется вводимым в эксплуатацию узлом в процессе ввода в эксплуатацию.
  • Информация NOCSR, отправляемая в экосистему, включает в себя операционный открытый ключ узла, но операционный закрытый ключ узла никогда не отправляется комиссару или в центр сертификации.
  • Процесс NOCSR использует входные данные процедуры аттестации , подписывая информацию CSRSR и, таким образом, проверяя запрос центра сертификации на создание доверенного NOC.

Процедура аттестации – это процесс, используемый Уполномоченным для подтверждения того, что:

  • Устройство прошло сертификацию Matter .
  • Устройство действительно является тем, чем оно себя называет: оно криптографически подтверждает своего поставщика, идентификатор продукта и другую производственную информацию.

Мультиадминистратор

Узлы также могут быть введены в эксплуатацию на нескольких фабриках. Это свойство часто называют мультиадминистратором. Например, у нас может быть Устройство, подключенное как к Фабрике производителя, так и к Фабрике облачной экосистемы, при этом каждая Фабрика обрабатывает свой набор зашифрованных сообщений и работает независимо.

Поскольку несколько Фабрик могут сосуществовать, Устройство может иметь несколько наборов рабочих учетных данных узла. Однако модель данных узла является общей: атрибуты, события и действия кластера являются общими для всех фабрик. Таким образом, хотя учетные данные Thread и/или Wi-Fi задаются во время процесса ввода в эксплуатацию, они являются частью сетевого операционного кластера , совместно используются всеми фабриками и частью DM узла, а не учетными данными фабрики.

,

Теперь, когда мы поняли некоторые ключевые концепции узла, мы проанализируем, что позволяет устройствам взаимодействовать друг с другом.

Спецификация Matter использует сложные методы шифрования и дешифрования информации, а также безопасные механизмы для обеспечения идентификации узла и обмена криптографическими учетными данными.

Всякий раз, когда набор Устройств в сети использует один и тот же домен безопасности и, таким образом, обеспечивает безопасную связь между узлами, этот набор называется Фабрикой. Фабрики используют один и тот же сертификат верхнего уровня центра сертификации ( CA ) ( корень доверия ) и в контексте CA уникальный 64-битный идентификатор с именем Fabric ID .

Таким образом, процесс ввода в эксплуатацию представляет собой назначение учетных данных Фабрики новому узлу, чтобы он мог взаимодействовать с другими узлами в той же Фабрике.

Операционные полномочия

Корень доверия устанавливается на узле, введенном в эксплуатацию Комиссаром, обычно это устройство с графическим интерфейсом определенного типа, например смартфон, концентратор или компьютер, после получения его от Административного менеджера домена ( ADM ), который часто является экосистема, которая действует как доверенный корневой центр сертификации ( CA ).

Комиссар имеет доступ к CA. Таким образом, он запрашивает эксплуатационные учетные данные узла у центра сертификации от имени вводимого в эксплуатацию узла или комиссионера . Учетные данные состоят из двух частей:

Операционный идентификатор узла (или идентификатор рабочего узла ) — это 64-битное число, которое уникально идентифицирует каждый узел в структуре.

Эксплуатационный сертификат узла ( NOC ) — это набор учетных данных, которые узлы используют для связи и идентификации внутри структуры. Они генерируются процессом запроса на подпись эксплуатационного сертификата узла ( NOCSR ).

NOCSR — это процедура, которая выполняется на вводящемся в эксплуатацию узле. Он связывает несколько криптографических элементов, а затем отправляет их комиссару, который запрашивает у экосистемы CA соответствующий NOC. На рисунке 1 показано это дерево зависимостей и порядок выполнения некоторых операций.

Зависимости генерации NOC
Рисунок 1: Зависимости генерации NOC

Хотя понимание каждого криптографического элемента важно для разработки SDK, полный анализ их роли и последствий выходит за рамки учебника. Важно отметить, что:

  • NOC выдаются экосистемой CA на реальных производственных фабриках.
  • NOC криптографически привязаны к уникальной паре рабочих ключей узла ( NOKP ).
  • NOKP генерируется вводимым в эксплуатацию узлом в процессе ввода в эксплуатацию.
  • Информация NOCSR, отправляемая в экосистему, включает в себя операционный открытый ключ узла, но операционный закрытый ключ узла никогда не отправляется комиссару или в центр сертификации.
  • Процесс NOCSR использует входные данные процедуры аттестации , подписывая информацию CSRSR и, таким образом, проверяя запрос центра сертификации на создание доверенного NOC.

Процедура аттестации – это процесс, используемый Уполномоченным для подтверждения того, что:

  • Устройство прошло сертификацию Matter .
  • Устройство действительно является тем, чем оно себя называет: оно криптографически подтверждает своего поставщика, идентификатор продукта и другую производственную информацию.

Мультиадминистратор

Узлы также могут быть введены в эксплуатацию на нескольких фабриках. Это свойство часто называют мультиадминистратором. Например, у нас может быть Устройство, подключенное как к Фабрике производителя, так и к Фабрике облачной экосистемы, при этом каждая Фабрика обрабатывает свой набор зашифрованных сообщений и работает независимо.

Поскольку несколько Фабрик могут сосуществовать, Устройство может иметь несколько наборов рабочих учетных данных узла. Однако модель данных узла является общей: атрибуты, события и действия кластера являются общими для всех фабрик. Таким образом, хотя учетные данные Thread и/или Wi-Fi задаются во время процесса ввода в эксплуатацию, они являются частью сетевого операционного кластера , совместно используются всеми фабриками и частью DM узла, а не учетными данными фабрики.

,

Теперь, когда мы поняли некоторые ключевые концепции узла, мы проанализируем, что позволяет устройствам взаимодействовать друг с другом.

Спецификация Matter использует сложные методы шифрования и дешифрования информации, а также безопасные механизмы для обеспечения идентификации узла и обмена криптографическими учетными данными.

Всякий раз, когда набор Устройств в сети использует один и тот же домен безопасности и, таким образом, обеспечивает безопасную связь между узлами, этот набор называется Фабрикой. Фабрики используют один и тот же сертификат верхнего уровня центра сертификации ( CA ) ( корень доверия ) и в контексте CA уникальный 64-битный идентификатор с именем Fabric ID .

Таким образом, процесс ввода в эксплуатацию представляет собой назначение учетных данных Фабрики новому узлу, чтобы он мог взаимодействовать с другими узлами в той же Фабрике.

Операционные полномочия

Корень доверия устанавливается на узле, введенном в эксплуатацию Комиссаром, обычно это устройство с графическим интерфейсом определенного типа, например смартфон, концентратор или компьютер, после получения его от Административного менеджера домена ( ADM ), который часто является экосистема, которая действует как доверенный корневой центр сертификации ( CA ).

Комиссар имеет доступ к CA. Таким образом, он запрашивает эксплуатационные учетные данные узла у центра сертификации от имени вводимого в эксплуатацию узла или комиссионера . Учетные данные состоят из двух частей:

Операционный идентификатор узла (или идентификатор рабочего узла ) — это 64-битное число, которое уникально идентифицирует каждый узел в структуре.

Эксплуатационный сертификат узла ( NOC ) — это набор учетных данных, которые узлы используют для связи и идентификации внутри структуры. Они генерируются процессом запроса на подпись эксплуатационного сертификата узла ( NOCSR ).

NOCSR — это процедура, которая выполняется на вводящемся в эксплуатацию узле. Он связывает несколько криптографических элементов, а затем отправляет их комиссару, который запрашивает у экосистемы CA соответствующий NOC. На рисунке 1 показано это дерево зависимостей и порядок выполнения некоторых операций.

Зависимости генерации NOC
Рисунок 1: Зависимости генерации NOC

Хотя понимание каждого криптографического элемента важно для разработки SDK, полный анализ их роли и последствий выходит за рамки учебника. Важно отметить, что:

  • NOC выдаются экосистемой CA на реальных производственных фабриках.
  • NOC криптографически привязаны к уникальной паре рабочих ключей узла ( NOKP ).
  • NOKP генерируется вводимым в эксплуатацию узлом в процессе ввода в эксплуатацию.
  • Информация NOCSR, отправляемая в экосистему, включает в себя операционный открытый ключ узла, но операционный закрытый ключ узла никогда не отправляется комиссару или в центр сертификации.
  • Процесс NOCSR использует входные данные процедуры аттестации , подписывая информацию CSRSR и, таким образом, проверяя запрос центра сертификации на создание доверенного NOC.

Процедура аттестации – это процесс, используемый Комиссаром для подтверждения того, что:

  • Устройство прошло сертификацию Matter .
  • Устройство действительно является тем, чем оно себя называет: оно криптографически подтверждает своего поставщика, идентификатор продукта и другую производственную информацию.

Мультиадминистратор

Узлы также могут быть введены в эксплуатацию на нескольких фабриках. Это свойство часто называют мультиадминистрированием. Например, у нас может быть Устройство, подключенное как к Фабрике производителя, так и к Фабрике облачной экосистемы, при этом каждая Фабрика обрабатывает свой набор зашифрованных сообщений и работает независимо.

Поскольку несколько Фабрик могут сосуществовать, Устройство может иметь несколько наборов рабочих учетных данных узла. Однако модель данных узла является общей: атрибуты, события и действия кластера являются общими для всех фабрик. Таким образом, хотя учетные данные Thread и/или Wi-Fi устанавливаются во время процесса ввода в эксплуатацию, они являются частью сетевого операционного кластера , совместно используются всеми фабриками и частью DM узла, а не учетными данными фабрики.