証明書

認定デバイスとは、 Connectivity Standards Alliance (Alliance) Matter 認定プロセス

認定デバイスは、試運転プロセス中に自身で証明を受ける必要があります。 つまり、それが主張する内容であり、それが本当に正しいことを 保証しますしたがって、すべての Matter デバイスに認証情報があります これには、証明書の鍵ペアと関連する証明書チェーンが含まれます。 デバイス構成証明書（DAC）は、このチェーンの一部です。認定中のデバイスが DAC をコミッショナーに提示すると、コミッショナーは次のことを証明します。

  • 認定メーカーによって製造されたデバイスであることです。
  • 純正デバイスである。
  • Matter 件の準拠性テストに合格しています。

開発フェーズでは、メーカーは完全な構成証明プロセスなしでデバイスをテストできます。テスターには、Google Workspace の デバイスがテスト中で、まだ認定もリリースもされていない。1 回 メーカーが生産フェーズに入ると、プロビジョナーの すべての証明書の要件を適用します

証明書はルートを利用する公開鍵基盤（PKI）を使用します。 認証局と中間証明書を使用して認証できます。 SSL/TLS で広く採用されているサーバー認証証明書を使用します。このプロセス デバイス認証証明書チェーンと呼ばれます。

デバイス認証の PKI

DAC は X.509 v3 証明書です。X.509 の最初のバージョンは、1988 年に ITU-T によって公開されました。Matter で使用される公開鍵基盤証明書と証明書失効リスト（CRL）を含む X.509 v3 は、RFC5280 で指定されています。次の内容が含まれます。

  • 公開鍵
  • 発行元
  • 件名
  • 証明書のシリアル番号
  • 有効期限（有効期限が不明な場合）
  • 署名

ベンダー ID とプロダクト ID は、DAC 内の MatterDACName の属性です。 あります。

DAC はデバイスごとに一意であり、一意の構成証明鍵ペアに関連付けられる あります。デバイスに関連付けられている CA によって発行されている メーカーによって異なります。

DAC の署名は、プロダクト認証の中間認証に照らして検証されます。 証明書（PAI）。これも PAA が発行します。しかしベンダーによっては 商品ごとに 1 つの PAI（PID 固有）、商品グループ、または 提供します

信頼チェーンのルートでは、プロダクト認証機関が （PAA）認証局（CA）の公開鍵が署名を検証する 取得されます。Matter トラストストアが連携されていることに注意してください。 委員会が信頼する一連の PAA 証明書が 一元化された信頼できるデータベース（Distributed Compliance Ledger）です。PAA の入力 信頼されたセット内では、サービス アカウントによって管理される証明書ポリシーを満たす Alliance。

Matter 証明書の公開鍵基盤
図 1: Matter 構成証明公開鍵インフラストラクチャ

PAI は、以下を含む X.509 v3 証明書でもあります。

  • 公開鍵
  • 発行元
  • 件名
  • 証明書のシリアル番号
  • 有効期限（有効期限が不明な場合）
  • 署名

ベンダー ID と商品 ID（省略可）は、MatterDACName の DAC サブジェクト

最後に、PAA はチェーンのルート証明書であり、自己署名されています。これは、 以下が含まれます。

  • 署名
  • 公開鍵
  • 発行元
  • 件名
  • 証明書のシリアル番号
  • 有効性

追加の証明書類とメッセージ

構成証明プロセスには複数のドキュメントとメッセージがあります。次の項目 その機能と構成の概要を説明します。以下の画像は、 階層の理解に役立ちます

証明書のドキュメント階層 <ph type="x-smartling-placeholder">
</ph> 図 2: 証明書ドキュメントの階層
ドキュメント 説明
認定の申告（CD） CD を使用すると、Matter デバイスは Matter プロトコルへの準拠を証明できます。この Matter 認定プロセスが終了すると、 Alliance が CD を作成します。 （デバイスタイプ） ベンダーはそれを できます。CD には、次の情報が含まれています。
  • VID
  • PID （1 つ以上）
  • サーバー カテゴリ ID
  • クライアント カテゴリ ID
  • セキュリティ レベル
  • セキュリティ 情報
  • 認定 タイプ（開発、プロビジョニング、 公式）
  • 署名
Firmware Information（ファームウェア情報（省略可）） [ファームウェア情報] には、CD バージョン番号と、ファームウェア内のコンポーネント（OS、ファイルシステム、ブートローダなど）の 1 つ以上のダイジェストが含まれています。ダイジェストは次のいずれかです。 ソフトウェアコンポーネントまたは アプリケーションの署名付きマニフェストのハッシュを ソフトウェア コンポーネント。

ベンダーは必要に応じて ファームウェア情報のみに含める "hash-of-hashes" というその 配列ではなく、これらのコンポーネントを

ファームウェア 情報は、インフラストラクチャの 概要にすぎません。 ベンダーがセキュアブートを ブート環境を作成し、オペレーティング システム 構成証明の鍵ペア。
構成証明情報 コミッショナーから コミッショナー。構成証明情報は、構成証明要素と構成証明署名を含む TLV を組み合わせたものです。
証明書の要素 これは以下を含む TLV です。

  • 証明書 宣言
  • タイムスタンプ
  • 証明書 ノンス
  • ファームウェア情報 （省略可）
  • ベンダー固有 情報（省略可）
構成証明チャレンジ アウトオブバンド チャレンジ Passcode Authenticated Session Establishment (PASE)/ Certificate Authenticated Session Establishment (CASE) セッション 保護するために使用されており、 シグネチャの再実行を避けることができます来る 提供元: CASE セッション、PASE 再開されたセッションは CASE セッション。
証明書の TBS（署名が必要） 証明書を含むメッセージ Elements and Attestation Challenge です。
証明書の署名 証明書の TBS の署名、 デバイス認証を使用して署名された 秘密鍵。

証明書の手順

コミッショナーは、コミッショナーを証明する責任を負います。Kubernetes は 手順は次のとおりです。

  1. コミッショナーがランダムな 32 バイトの構成証明ノンスを生成する。暗号用語では、ノンス（1 回限りの番号）は、暗号手順で生成され、1 回だけ使用することを目的とした乱数です。
  2. コミッショナーがノンスを DUT に送信し、証明書をリクエストします。 情報。
  3. DUT は証明書情報を生成し、証明書で署名します。 秘密鍵。
  4. コミッショナーがデバイスから DAC 証明書と PAI 証明書を復元する。 Matter 信頼から PAA 証明書を検索します。 あります
  5. コミッショナーが証明書情報を検証します。これが条件です :
    • DAC 証明書チェーンの検証が必要（失効チェックを含む） PAI と PAA の 2 つです
    • DAC の VID が PAI の VID と一致する。
    • 構成証明署名が有効である。
    • デバイス構成証明要素のノンスが、コミッショナーから提供されたノンスと一致している。
    • 証明書宣言署名は、Alliance の既知の証明書宣言署名鍵のいずれかを使用して有効です。
    • [Firmware Information]（ファームウェア情報（存在し、コミッショナーがサポートしている場合））が一致します。 Distributed Compliance Ledger に登録します。
    • デバイスの基本情報クラスタ、認証申告、DAC 間で追加の VID / PID 検証も行われます。
前へ
コミッショニング
次へ
スレッドと IPv6