Matterのデバイス認証

Nature ファームウェア・エンジニアの井田です。入社してから早いものであと1か月で1年が経ちます。 最近は一昨日 7/4 (火) に発売された Remo nanoファームウェア開発や生産工場向けのツールの開発を行っていました。

この記事は 第 2 回 Nature Engineering Blog 祭の 3 日目の記事になります。前日は 亀田さんによる、AndroidでのMatter検出時の画面切り替えを抑制する方法についての記事 でした。

Remo nanoの発売日に、田井さんによるRemo nanoを使ったMatter入門記事 が公開されましたので、既にRemo nanoを使ってMatter入門をされた方もいらっしゃるかと思います。 本日は一昨日とは違うMatterの側面として、 Matterのデバイス認証 について解説します。

基本:Matterの仕様書の入手

Remo nanoはMatter 1.0の規格に準拠しています。 解説の内容が正しいかどうか確認するために、公式の仕様書の入手は必須です。 以下のページから、 少なくとも Matter 1.0 Core Specification にチェックを入れて必要事項を入力し、Matter 1.0 Core SpecificationのPDFを入手しておきます。

(一昨日の 田井さんの記事 を見た方は既にダウンロード済みのはずです!)

Specifications Download Request - CSA-IOT

本題:Matterのデバイス認証

Matterの世界では、Amazon Alexa, Google Home, Apple HomeKitといったスマート・スピーカーに代表される コントローラ (Controller) と呼ばれる種類のデバイスが中心となり、Matter対応デバイス間で通信を行うネットワークとして ファブリック (Fabric) を構成します。 ファブリックにはコントローラから制御されるMatterデバイスが存在しないと意味がないので、制御対象の何かしらのMatterデバイスを追加する必要があります。 このファブリックにMatterデバイスを追加する手続きを コミッショニング (Commissioning) といいます。 また、コミッショニングを行うコントローラを コミッショナー (Commissioner) 、コミッショニングによりファブリックに追加されるMatterデバイスコミッショニー (Commissionee) といいます。

コミッショニング

ファブリックに属するMatterデバイス間は必要に応じて互いに通信を行うため、それぞれのデバイスがMatter規格に正しく準拠した実装となっていることが、動作の安定性や安全性にとって重要です。 そのため、コミッショニングの手順の中には、 バイス認証 (Device Attestation) の手続きが含まれており、追加するMatterデバイスが正当なMatterデバイスであるかどうかを確認しています。

このDevice Attestationで重要な役割を果たすのが、次に説明する CDDAC の2つのデータです。

CDとDAC

CDとDACの整合性の検証

CD (Certification Declaration) は、その名の通り、MatterデバイスがMatterの認証を受けていることを表すデータです。中身は、RFC5652 https://datatracker.ietf.org/doc/html/rfc5652 で規定されているCMS (Cryptographic Message Syntax) というフォーマットのデータです。 この中には、Matter認証を取得したデバイスVendor ID, Product ID やバージョンといった情報を、TLVと呼ばれるエンコーディング方式を用いて表現したものが含まれています。 例えば、Remo nanoは、Vendor ID = 0x138a (NatureのVendor ID), Product ID = 0x1392 (Remo nanoのProduct ID) を含んだCDを持っています。*1

CD自体はデバイスの認証試験完了後にCSAが署名を行ったものが発行されるため、改ざんを検出できるようになっていますが、コミッショニングプロセス中にコントローラがデバイスから読み出すようになっています。つまり、CD自体はデバイスから読み出せるのでコピーできてしまいます。 そこで、デバイス自体がCDに記載されているVendor ID, Product IDのデバイスであることを検証するために DAC を用います。

DAC (Device Attestation Certificate) は、デバイス認証に用いる証明書で、各Matterデバイスはデバイスの個体ごとに異なる証明書を持っています。証明書の形式は、RFC5290で規定されているX.509形式の証明書となっています。 DACのSubjectフィールドにはデバイスのVendor IDおよびProduct IDが含まれているため、DACを検証すれば、デバイスのVendor ID/Product IDがDACに記載されたものであることが確認できます。 *2

前述の通り、CDにもVendor ID, Product IDが含まれているので、これらの値がDACのVendor ID, Product IDと一致すれば、そのCDは確かにそのデバイスに対応するものということが確認できます。*3

DACの検証

DAC自体は前述の通り、X.509形式の証明書で、CSAが認可した PAA (Product Attestation Authority) と呼ばれる認証局ルート証明書で署名された PAI (Product Attestation Intermediate) と呼ばれる中間証明書で署名されます。つまり、 DAC → PAI → PAAというように証明書チェーンをたどることができます。 PAAのルート証明書の一覧はCSAが管理しており、 DCL (Distributed Compliance Ledger) と呼ばれるシステムから取得できます。 一昨日のMatterを試す記事中で、

$ python credentials/fetch-paa-certs-from-dcl.py --use-main-net-http

としてスクリプトを実行していましたが、これは実はDCLからPAAのルート証明書一覧を取得する作業です。 chip-tool にはデバイス開発中に用いるテスト用のPAA, PAIやDACの情報しか含まれておらず、正規MatterデバイスであるRemo nanoのコミッショニングを行うには、対応する正規のPAAs証明書が必要となるためです。 chip-tool--paa-trust-store-path で、信頼するPAAの証明書が含まれるディレクトリのパス (ファイルではなくディレクトリなのに注意) を指定すると、ディレクトリ中の証明書をPAAの証明書として扱うようになります。

Matterデバイスは、デバイス固有のDACの証明書と署名用の秘密鍵、およびDACに紐づくPAIの証明書を持っています。 コミッショナーDACの検証のために、DACとPAIの証明書をデバイスから読み出して証明書チェーンを検証します。

また、デバイスDAC秘密鍵を持っていることを検証するため、コミッショナーは32バイトの乱数列を生成し、 AttestationRequestコマンド としてデバイスに送付します。 デバイスDAC秘密鍵を使って送られてきた32バイトの乱数列に署名を行い、 AttestationResponse としてコミッショナーに送り返します。あとはコミッショナーがAttestationResponseに入っている署名内容を検証すれば、デバイスが正当なDACを持っていることが検証できます。

DACによる署名と検証

DAC秘密鍵の保護

バイス認証のプロセスの中で、デバイスDACを持っていることはDAC秘密鍵での署名を行えるかどうかで確認しています。よって、 DAC秘密鍵はMatterデバイスにとっての機密情報であり、デバイス外に漏れてはいけないもの です。 Matterの規格では、DAC秘密鍵の流出を防ぐために、デバイス内部のセキュアなストレージにDAC秘密鍵を保存することを要求しています。

RemoシリーズではEspressifの無線機能付きMCUであるESP32シリーズのMCUを使っており、ESP32のSecure Boot機能およびフラッシュ暗号化機能を使って、DAC秘密鍵を保護しています。

開発中のデバイスに対するデバイス認証

とはいえ、デバイス開発の検討段階や初期のころは、Matterの認証試験を通っていないため、デバイスに対する正当なCDはありませんし、正当なDACの証明書もないことが多いです。 そこで、Matterの規格では、コミッショニング中のデバイス認証に失敗した場合、コントローラがデバイスをどのように扱うかをきめることができるようになっています。 規格上は、ユーザーに対してコミッショニーがMatter認証を受けていないデバイスであるという警告を表示すべきとなっており、またユーザーにコミッショニングを続行するかどうかを尋ねてもよいと規定されています。 *4

例えばApple HomeKitへの登録の場合、Matterのデバイス認証に失敗した場合、Matter認証済みデバイスではないという警告が表示されるものの、ユーザーの判断でそのままデバイスを登録することができます。

Apple HomeKitへ未認証デバイスの登録時の警告

一方、Google Homeの場合、デバイス認証に失敗した場合、エラーとなり登録できません。

Google Homeの未認証デバイス登録時のエラー

Google Homeで認証前のデバイスの動作確認を行う場合は、テスト用のVendor ID, Product ID *5 を含むテスト用のCD・DACを使ったうえで、 Google Home Developer Console *6 でテスト用のデバイスとして登録する必要があります。

自作Matterデバイスを作ってつなぎたい場合は、connectedhomeip リポジトリにあるテスト用のCD・DACを使って作ればよいでしょう。*7

まとめ

Matterのデバイス認証におけるCDとDACの役割と、開発中や自作デバイス出の対応についてざっくり説明しました。 これで皆さんもMatterコントローラやMatterデバイスの自作に一歩近づいたと思いますので、ぜひRemo nanoで遊んでみてください。

明日の 4 日目の記事は、 バックエンド・エンジニアの桒山さんの担当です。よろしくお願いします。

Nature開発者Community

Natureのプロダクトに関する開発者向けの情報を交換する場として、 Nature開発者コミュニティ をDiscord上に立ち上げています。

matter チャネルもありますので、Remo nanoとMatterの開発に関することなど、気軽にご質問いただければと思います。

discord.com

更新履歴

  • 2023/07/06 : 初版
  • 2023/07/06 : CDの発行時期に関する文言を明確化

*1:Matter Specification 1.0 6.3 Certification Declaration pp.290-293

*2:Matter Specification 1.0 6.2.2 Device Attestation Certificate pp.274-287

*3:Matter Specification 1.0 6.2.3.1. Attestation Information Validation pp.288-290

*4:Matter Specification 1.0 5.5 Commissioning Flows p.252

*5:テスト用のVendor IDとして0xFFF1~0xFFF4が規定されている。Product IDは0x8001等にすることが多い

*6:https://console.home.google.com/

*7:実際、Matter specでもhomebrewデバイスの開発についても言及されています。