2026 年 10 月 20 日
PAA・PAI・DAC の信頼チェーン ── TLS と何が違うのか
～ スマートホーム規格「Matter」の仕組みとセキュリティ（第 2 回）～
Matter デバイスがネットワークに参加する際、コントローラーは正当な機器かどうかを 3 段階で検証します。この検証の中心にあるのが、DAC という Matter 機器証明書と、DAC を発行する PAI・PAA という認証局の階層です。この証明書の信頼性を支えているのが、DCL という分散台帳の仕組みです。
証明書の階層構造という点で、Matter の仕組みは SSL/TLS サーバー証明書（サーバー証明書）のルート認証局、中間認証局、エンドエンティティ証明書という構造と似ています（コミッショニングの裏側── Matter デバイスアテステーションの仕組み）。実際、DAC・PAI・PAA はサーバー証明書と同じ X.509 形式で、上位の証明書が下位の証明書に署名し、その署名を遡って検証するという手順も TLS の証明書チェーン検証と同じです。異なるのは、信頼の起点を誰が管理し、証明書をどのように配付するかという運用の仕組みです。
PAA・PAI・DAC の 3 つが分担して Matter PKI を構成
Matter では、デバイスの開発会社が個々の機器に DAC という証明書を発行し、製品に組み込んで出荷します。この DAC を発行する中間認証局が PAI であり、PAI を発行する上位の認証局が PAA です。Matter の階層構造では、PAA が最上位（Tier1）、PAI がその下（Tier2）のサブ認証局にあたります。
PAA には 2 種類あります。1 つは VID PAA で、デバイスメーカー（ベンダー）自身がルート認証局を運用する方式です。1 つの PAA を 1 つのベンダーだけが使う、1 対 1 の関係になります。もう 1 つは Non-VID Scoped PAA で、特定のベンダーに属さない第三者認証局が運用する方式です。1 つのルート認証局を複数のベンダーで共有できるため、1 対多の関係になり得ます。配下に立つ個々の PAI は、どちらの方式でも単一のベンダーに対してしか DAC を発行できません。
PAI の証明書に必ず製造事業者の VID が載ります。この記載自体は PAI 側が申請時に指定し、PAA が内容を検証したうえで署名し、正当性を保証します。VID PAA と Non-VID Scoped PAA の違いは、上位の PAA 自体の証明書にも VID を記載するかどうかです。VID PAA は PAA 自体の証明書にベンダーの VID を記載し、1 つの PAA が 1 つのベンダー専用になります。Non-VID Scoped PAA は PAA 自体の証明書に VID を記載しません。代わりに 1 つの PAA を複数のベンダーで共有し、実際にどのベンダー向けかは配下の PAI 証明書に載っている VID で区別します。
Non-VID Scoped PAA を提供する PKI ベンダーは、PAI の運用代行サービスを組み合わせて提供するのが一般的です。運用代行とセットにすることで、デバイスメーカーは自前で PAI を構築・運用せずに済み、認証局の専門知識や鍵管理の設備がなくても、DAC の発行に必要な体制を整えられます。
PAA の証明書は、自分自身の鍵で署名する自己署名のルート証明書であり、Matter の世界では暗黙的に信頼される存在です。PAA の秘密鍵が漏えいすれば、その配下で発行されたすべての PAI 証明書と DAC が連鎖的に信頼を失います。PAA の秘密鍵は、単一のベンダーの信用を丸ごと背負う資産であり、厳重な管理が求められます。
証明書の有効期間にも、階層に沿った制約があります。下位の証明書は、それを発行した上位の証明書の有効期間を超えて有効にはできません。この制約がある以上、DAC の有効期間を長く設定したい場合は、上位の PAI と PAA の有効期間もそれに応じて長く設定しておく必要があります。
仕様上、DAC の有効期間はベンダーが自由に決められます。上位の PAI・PAA とあわせて極端に長い値を設定すれば、事実上無期限に近い扱いにすることも可能です。Matter 仕様書にも、設定可能な最大値として「9999 年 12 月 31 日」という値が載っています。もっとも、仕様上可能であることと、実務上どこまで長く設定すべきかの方針は別の問題です。
VID PAA と Non-VID Scoped PAA では、監査の方式にも違いがあります。VID PAA の場合、事業者自身が定期的に内部監査を実施し、結果を CSA に報告する仕組みです。一方、Non-VID Scoped PAA の場合、第三者機関による定期的な監査を受ける必要があります。
分散台帳の DCL が信頼の起点に
サーバー証明書では、Microsoft や Google といった Web ブラウザベンダーが、信頼するルート証明書を管理しています。Matter では、CSA が管理する DCL と呼ばれる分散台帳が信頼の起点です。
Web サーバーで利用するサーバー証明書では、通信先のサーバー証明書が正当かどうかを検証するため、信頼するルート認証局の証明書を Web ブラウザや OS があらかじめ内蔵しており、これを定期的に更新しています。一方、Matter はデバイスやコントローラーにルート証明書をあらかじめ内蔵するのではなく、必要なときだけ DCL に都度問い合わせます。
この都度問い合わせする方式には理由があります。コントローラーを製造した後に新しいデバイスメーカーや PAA が登場した場合、デバイスの DAC を検証するために必要な PAA 証明書を、コントローラーが手元に持っていない場合があります。この場合、コントローラーはデバイスの正当性を確認できず、ネットワークへの参加を許可できません。DCL に都度問い合わせる仕組みは、この問題を解決しています。
DCL の技術的な実体は、許可制のブロックチェーンです。誰でも自由に参加できる公開型のブロックチェーンとは異なり、DCL のサーバーを運用できるのは CSA が認めた組織だけです。DCL には記録の検証に直接関わる「バリデーターノード」と、記録を閲覧するだけの「オブザーバーノード」の 2 種類があります。複数のバリデーターノードが承認済みの鍵による署名を照合し、投票によって合意を形成することで、新しい記録の正当性を検証します。
ノードの設置場所は、CSA が世界各地への分散を意識して選定しています。単一の事業者やサーバーが停止しても、システム全体が止まらない設計です。CSA 会員が DCL にアクセスする際は、まず基本の「ベンダー」という役割が与えられます。ベンダーの役割を持つ会員は、自社の製品モデル情報やベンダー情報を DCL に登録できます。これとは別に、DCL の運用統治を担う「トラスティー」という役割もあります。トラスティーは CSA が任命し、新規アカウントの作成や、他の会員へのロール付与・剥奪、ルート証明書の承認といった管理業務を担います。
Matter PKI が目指しているのは、Matter ネットワーク内に不正なデバイスが侵入し、家庭内で流通する情報が外部に漏えいする事態を防ぐことです。正当なデバイスだけがネットワークに参加できるようにするという点では、現在のサーバー証明書とほぼ同じです。一方で、決定的に異なる設計もあります。Matter では、DAC を機器認証の際だけにしか使いません。デバイスがネットワークに参加した後の実際の通信には、NOC（Node Operational Certificate、ノード運用証明書）というローカルな証明書を使います。
次回は、DAC そのものの中身を解説します。
<
