ファブリック

ノードの主なコンセプトを理解したところで、次はデバイスが相互に通信できるものを分析します。

Matter 仕様では、情報の暗号化復号のための高度な方法と、ノードの ID を保証し、暗号認証情報を共有するための安全なメカニズムを使用します。

ネットワーク内のデバイスのセットが同じセキュリティ ドメインを共有し、ノード間で安全な通信が許可されている場合、このセットはファブリックと呼ばれます。ファブリックは、同じ認証局(CA)の最上位証明書(ルート オブ トラスト)を共有します。また、CA のコンテキストでは、ファブリック ID という名前の一意の 64 ビット識別子を使用します。

したがって、コミッショニング プロセスは、新しいノードにファブリック認証情報を割り当てることで、同じファブリック内の他のノードと通信できるようになります。

運用クルデンシャル

ルート オブ トラストは、コミッショナーの委託によりノードに設定されます。通常、管理ドメイン マネージャー(ADM)は、信頼できるルート認証局(CA)として機能するエコシステムである管理ドメイン マネージャー(ADM)から受け取った後、スマートフォン、ハブ、コンピュータなどのなんらかのタイプの GUI を備えたデバイスです。

コミッショナーは CA にアクセスできます。したがって、委託先のノードまたは委員会に代わって CA にノード運用認証情報をリクエストします。認証情報は、次の 2 つの部分で構成されています。

ノード運用識別子(Operational Node ID)は、ファブリック内のすべてのノードを一意に識別する 64 ビットの番号です。

ノードの運用証明書(NOC)は、ノードが Fabric 内で通信と識別に使用する一連の認証情報です。証明書は、ノード運用証明書署名リクエストNOCSR)プロセスによって生成されます。

NOCSR は、コミッショニング対象のノードで実行されるプロシージャです。いくつかの暗号要素をバインドしてコミッショナーに送信します。コミッショナーは、対応する NOC について CA エコシステムにリクエストします。図 1 は、この依存関係ツリーと、一部のオペレーションが発生する順序を示しています。

NOC 生成の依存関係
図 1: NOC 生成の依存関係

各暗号要素を理解することは SDK の開発には重要ですが、その役割と影響を完全に分析することはこの入門書の範囲外です。次の点に注意してください。

  • NOC は、実際の本番環境ファブリック上で CA エコシステムによって発行されます。
  • NOC は、一意のノード操作鍵ペア(NOKP)に暗号的にバインドされます。
  • NOKP は、コミッショニング プロセス中にコミッショニングされるノードによって生成されます。
  • エコシステムに送信される NOCSR 情報にはノードの運用公開鍵が含まれますが、ノードの運用秘密鍵がコミッショナーまたは CA に送信されることはありません。
  • NOCSR プロセスは、証明書手順からの入力を使用して CSRSR 情報に署名することで、信頼できる NOC を生成するために CA のリクエストを検証します。

証明書手続きは、コミッショナーが以下のことを証明するプロセスです。

  • このデバイスは Matter の認定を受けています。
  • デバイスは実際のところ、ベンダー、プロダクト ID、その他の製造情報を暗号的に証明するものです。

マルチ管理者

ノードは複数の Fabric でコミッショニングすることもできます。このプロパティはよく「マルチ管理者」と呼ばれます。たとえば、メーカーのファブリックとクラウド エコシステムのファブリックの両方に委託されたデバイスがあり、各ファブリックがそれぞれ異なる暗号化された通信セットを処理し、独立して動作している場合があります。

複数のファブリックが共存できるため、デバイスに複数のノードの動作認証情報セットが存在する場合があります。ただし、ノードのデータモデルは共有されます。クラスタの属性、イベント、アクションは Fabric 間で共通です。したがって、Thread や Wi-Fi 認証情報はコミッショニング プロセス中に設定されますが、これらはネットワーキング運用クラスタの一部であり、Fabric の認証情報ではなく、すべての Fabric とノードの DM の一部で共有されます。