2026 年 09 月 29 日
コミッショニングの裏側──Matter デバイスアテステーションの仕組み
～ スマートホーム規格「Matter」の仕組みとセキュリティ（第 1 回）～
Matter 規格に準拠したスマート家電の初期接続は、QR コードをスマートフォンで読み取るだけで完了します。この裏側では、複数の検証処理が動作しています。
※ QR コードは株式会社デンソーウェーブの登録商標です。
Matter 対応デバイスを開発するメーカーは、個々のデバイスに DAC（Device Attestation Certificate）と呼ばれる証明書を組み込んで出荷します。DAC の発行を担っているのが PAI と呼ばれる中間認証局で、さらに上位の PAA というルート認証局が PAI の証明書を発行します（Matter 製品の開発に求められる認定プロセスとは、Matter 対応に必要な機器の認証と証明書の重要性）。
DAC は、工場出荷時にデバイスに組み込む証明書です。証明書自体は、認証局のソフトウェアさえあれば誰でも発行できます。しかし、これだけでは Matter のネットワークが Matter 対応デバイスとして受け入れてくれません。正しい認証局が、正しい手続きを経て発行した証明書でなければ、ネットワークに参加する他の機器は信頼してくれません。証明書を「発行できること」と「信頼されること」は別問題です。
CSA は 2026 年 6 月 17 日、Matter 1.6 と Product Security 1.1 と呼ぶ 2 つの仕様を発表しました。電源を入れる前の段階で NFC （近距離無線通信）を使ってプロビジョニングできる機能や、複数のコントローラーが 1 つの Matter ネットワークを共同管理できる機能などを追加しています。こうした新機能を支える土台にあたるのが、機器の身元確認と呼ぶべき仕組みです。
TLS と異なる Matter の証明書構造
Matter における証明書の階層構造は、Web サーバーで使う SSL/TLS サーバー証明書（サーバー証明書）の構造（ルート認証局・中間認証局・エンドエンティティ証明書）と似ています。ルートにあたる PAA、中間にあたる PAI、エンドエンティティにあたる DAC という 3 層構造です。
しかし、異なる点もあります。DAC は、機器を認証する初期設定時にしか使わず、通信の実運用には別の証明書（NOC：Node Operational Certificate、ノード運用証明書）を使う設計になっています。また、信頼の起点となるルート証明書の扱い方も異なります。サーバー証明書は、信頼するルート証明書を Web ブラウザベンダーがあらかじめ機器やソフトウェアに組み込み、定期的に更新する方式を取っています。一方の Matter は、ルート証明書をあらかじめ内蔵するのではなく、信頼できる認証局の一覧を記録した DCL（Distributed Compliance Ledger、分散型コンプライアンス台帳）という台帳に、必要なタイミングで都度問い合わせる仕組みになっています。
QR コードでプロビジョニングが完了
Matter 規格に準拠したデバイスをスマートフォンでセットアップする際は、まず QR コードを読み取ります。この作業を担うのは、仕様上「コミッショナー」と呼ばれる役割で、典型的にはスマートフォンアプリが担います（日常的にデバイスを操作する「コントローラー」とは別の役割です）。
QR コードには、識別子やパスコード、ベンダー ID、プロダクト ID といった数値情報が、専用の形式でエンコードされています。このうちパスコードは、機器とスマートフォンアプリの双方が共有する秘密情報です。QR コードの読み取りをきっかけに、スマートフォンアプリはパスコードを使って、対象デバイスとの間に暗号化された一時的な通信セッションを確立します。この一連のプロビジョニング手続き全体を、仕様上は「コミッショニング」※1と呼びます。
- ※1
- コミッショニング（Commissioning）とは：プラントや設備、建築物などの試運転や調整、性能検証を行うプロセスのことです。
最初の接続方式には複数の種類があります。代表的なものが Bluetooth Low Energy（BLE）を用いた近距離無線です。BLE での接続はインターネットを必要とせず、機器とスマートフォンが直接ローカルでつながります。Wi-Fi 機器では、デバイス自体が一時的にアクセスポイントになるやり方もあります。
この時点では、スマートフォンアプリは相手が本物の Matter デバイスかどうかを確認できていません。ここから始まるのが、機器の身元確認です。仕様上はこれを「デバイスアテステーション」※2と呼びます。この確認が済むと、NOC という Matter ネットワークだけで使うローカル証明書をデバイスに発行し、以降の通信はこの NOC を用いた仕組みに切り替わります。この Matter のネットワーク管理領域全体を、ファブリックと呼びます。
- ※2
- デバイスアテステーション（Device Attestation）とは：アクセスしているデバイスやアプリが改ざんされていない本物であり、信頼できるハードウェア・ソフトウェア環境で動いていることを暗号学的に証明・検証する仕組みです。
NOC の発行が完了すると、機器は Wi-Fi や Thread のローカルネットワークに正式に参加し、BLE での接続を解除します。以降、mDNS という仕組みを通じて、機器は「ノード」としてネットワーク内の他の機器から見つけてもらえるようになります。機器のホスト名は、その機器の MAC アドレスをもとにした文字列で構成されており、実際の IP アドレスはこの名前解決を通じて特定します。
3 段階検証でなりすましを見抜く
スマートフォンアプリは、デバイスから DAC と PAI の証明書、さらに CD （Certification Declaration） と呼ぶ別の証明データを受け取り、「正当なベンダーが製造した Matter デバイスか」を確認します。この確認作業は、性質が異なる 3 つの検証で成り立っています。
まず、チャレンジレスポンスによる鍵の保有確認です。スマートフォンアプリは、デバイスに「チャレンジ」と呼ぶランダムなデータを送ります。デバイスは、内部に格納した秘密鍵で署名し、結果を返送します。スマートフォンアプリは、この署名結果を DAC で検証し、「このデバイスが、DAC に紐づく正当な鍵を確かに保持している」ことを確認します。
次に、パス検証です。DAC は、PAI が自らの秘密鍵で署名して発行したものです。スマートフォンアプリは、DAC 内の署名を PAI の公開鍵で検証し、さらにその PAI 自体の正当性を、上位の PAA の鍵で検証します。PAA は自分自身の鍵で署名する「自己署名」の証明書であるため、単独では正当性を証明できません。そこでスマートフォンアプリは DCL から正しい PAA 情報を取得し、突き合わせます。
3 つ目が、CD の確認です。CSA は PAA や PAI の系譜とはまったく別に CD を発行しています。CSA は CD に VID（ベンダー ID）と PID（プロダクト ID）を記載しており、DAC にも同じ情報を記載しています。スマートフォンアプリは両者を突き合わせることで、DAC の記載内容そのものが正しいかを確認します。
チャレンジレスポンスとパス検証だけでは、「鍵の正当性」と「発行元の正当性」しか証明できません。DAC の中身、つまり「これがどのベンダーの、どの製品なのか」という記載内容自体の正しさは、CD 照合によって初めて確認できます。3 つの検証はそれぞれ役割が異なり、どれか一つが欠けたら成り立ちません。
身元確認が済むと、デバイスは新しい鍵ペアを生成し、その公開鍵を含む CSR（Certificate Signing Request、証明書署名要求）を、スマートフォンアプリやスマートホームハブなど、そのファブリックの認証局としての役割を担う機器に送ります。この機器が CSR に署名して NOC を発行し、デバイスに組み込みます。
これ以降、デバイスは、この認証局の役割を担う機器や、Apple HomePod、Amazon Echo、Google Nest Hub などのスマートスピーカー（常時給電されるスマートホームハブであり、日常的な操作を担う「コントローラー」）との間で、NOC を使った証明書ベースの通信を行います。DAC は最初の身元確認のためだけに使う証明書であり、日常的な通信には NOC を使います。
次回は、PAA・PAI・DAC という 3 層の証明書が、なぜ・どのように信頼を得るのかを解説します。
