ファブリック

ノードに関する重要なコンセプトを理解したので、デバイスが相互に通信できるようにする仕組みについて分析します。

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

ネットワーク内のデバイスのセットが同じセキュリティ ドメインを共有しており、ノード間で安全に通信できる場合に、このセットをファブリックと呼びます。ファブリックは、同じ認証局CA)トップレベル証明書(信頼ルート)を共有し、CA のコンテキスト内で、Fabric ID という一意の 64 ビット ID を共有します。

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

運用認証情報

Root of Trust は、コミッショナーによる委任を受けてノードに設定されます。通常、これは、Administrative Domain ManagerADM)から受け取った後、スマートフォン、ハブ、コンピュータなどの GUI を備えたデバイスに設定されます。ADM は、多くの場合、Trusted Root Certificate AuthorityCA)として機能するエコシステムです。

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

ノード運用 ID(または運用ノード ID)は、Fabric 内のすべてのノードを一意に識別する 64 ビットの数値です。

ノード運用証明書NOC)は、ノードがファブリック内で通信して自身を識別するために使用する一連の認証情報です。これらは、ノード運用証明書署名リクエストNOCSR)プロセスによって生成されます。

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

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

各暗号要素を理解することは SDK 開発にとって重要ですが、その役割と影響を完全に分析することはこのプリマーの範囲外です。注意すべき点は次のとおりです。

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

構成証明手順は、コミッショナーが次の点を証明するために使用するプロセスです。

  • デバイスは Matter 認定を受けています。
  • デバイスが実際に宣称どおりのものであること: ベンダー、製品 ID、その他の製造情報を暗号的に証明します。

複数の管理者

ノードを複数のファブリックで構成することもできます。このプロパティは、マルチ管理者とも呼ばれます。たとえば、デバイスがメーカーのファブリックとクラウド エコシステムのファブリックの両方に委任されている場合、各ファブリックが異なる一連の暗号化された通信を処理し、独立して動作します。

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