Infineon Technologiesは独時間の2月21日、Matterに対応したセキュアエレメントとして「OPTIGA Trust M MTR」を発表した。これに関する説明会がオンラインで開催されたので、その内容をご紹介したい。

  • 「OPTIGA Trust M MTR」のパッケージイメージ

    「OPTIGA Trust M MTR」のパッケージイメージ

Matterそのものの説明は今さら不要だろうし、すでに昨年末から搭載製品の出荷も始まっている(Photo01)。

  • 充実するまでにはまだ相応の時間がかかるだろう

    Photo01:もっともまだ対応製品はそう多くないが、市場に山のように製品がある日突然登場する、といった類の規格ではないので、充実するまでにはまだ相応の時間がかかるだろう

ところでそんなMatterであるが、当たり前ではあるがセキュリティの対策をしないという選択肢は無い(Photo02)訳で、Matterはセキュリティに関して10項目ほどの要件が挙がっている(Photo03)。

  • Matterの目的の1つ

    Photo02:というよりも、単に相互接続性を確保するだけでなく、一定レベルのセキュリティを強制的に実装させることで、セキュリティ対応のレベルの底上げを全体的に図る、というのもMatterの目的の1つである

もちろん、このすべての項目をパーフェクトにカバーする必要があるか? と言えばNoではあるのだが、なるべく対応した方が良いのは事実である。

ただ、「そんな訳でセキュリティ対策をちゃんとやりましょう」と言ったときに障害になる問題がいくつかある。1つが「DAC(Device Attestation Certification)」である。要するにデバイスそのもののIDである(Photo03)。

  • OPTIGA Trust M MTRを使う事で容易になる項目

    Photo03:このうち太字で書かれた2~4が、OPTIGA Trust M MTRを使う事で容易になる項目である

スライド(Photo04)ではDACを“運転免許みたいなものだ”としているが、その比喩が正しいかどうかは兎も角として、DACが無いとMatter Deviceとして通信が出来ないので、すべてのデバイスにはそれぞれに向けたDACをインストールする必要がある。

  • Why are DACs a problem

    Photo04:“Why are DACs a problem”が問題点な訳だが、ただこれはMatterに限った話ではない。ただこれ以上に良い方法が今のところ無いので、これが使われている訳だ

すると必然的に出てくる問題がデプロイメントである。DACは運転免許証みたいなものだとしたが、現実の世界で運転免許証の正当性は誰が担保しているかと言えば警察庁である。同じことがDACにも必要で、まずRoot CA、ルート認証局と呼ばれるものを立ち上げるが、これは免許の世界で言えば警察庁そのものである。ここですべて認証をやるのは大変なので、Intermediate CA、中間認証局と呼ばれるものを作成する。免許でいえば、これは全国各地にある免許センターに相当するものだ。DACはこのIntermediate CAを使って作成される。そして作成したDACを、個々のデバイスにインストールするという手順になる。

ではRoot CAは何のためにあるのか? と言えば、それはIntermediate CAが正当なものであることを担保するために存在する。運転免許で言えば、裏路地で勝手に謎の免許センターとかが開設され、そこで発行された運転免許がまかり通ったらまずいのと同じである。これを防ぐために、免許センターそのものの存在をちゃんと認証するのがRoot CAという訳だ。まぁこれはごく一般的な実装で、Matter以外にもAWSとかAzureなどでも似たような実装が行われている。

問題は、これが結構大変なことだ。運転免許でも、免許センターが隣の市とか郡とかにあって、しかも離れた場所にあるので免許の更新に1日がかり、なんて場合もあったりする。MatterのCAも似たようなもので、Root CAとかIntermediate CAの作成はまだしも、DACの生成とかその生成したDACを最終製品にインストールするのが猛烈な手間である。

  • Expensiveとcomplexはまぁそうだ

    Photo05:Expensiveとcomplexはまぁそうだが、riskyとかdisruptiveはちょっと違うような気もする

ではMatter以外はこれをどうしているか? というと、例えばInfineonのAWS IoT Cloud向けのあるキットの場合、証明書を利用するためのコストがキットの代金の中に含まれている。セキュアエレメントは搭載されていないので量産には向かない(量産向けには、OPTIGA Trust Xと組み合わせる形になる)が、PoCとか試作のレベルであればこれを使う事で、オンラインで証明書の発行とインストール、実際の通信までが完結する。ただ量産には先に書いたようにIntermediate CAの立ち上げ(に伴うRoot CAの構築)や、DACの発行、インストールという手間が掛かる事になる。

このあたりを何とかしよう、というのが今回のOPTIGA Trust M MTRである。OPTIGAの名前を冠する事から判るように、これはセキュアエレメントである。Matter Deviceにセキュアエレメントを搭載する事は必ずしも必須ではないが、あった方が安全なのは間違いない。というよりも、あっても無くてもDACの扱いは必要になるので、であればセキュアエレメントを搭載してそちらに任せた方が安全性も高まるし、システムの構築も楽になる(Photo06)。

  • 要するに既存のMCUなりMPUベースのMatter Deviceに外付けでSEを接続する形になる

    Photo06:要するに既存のMCUなりMPUベースのMatter Deviceに外付けでSEを接続する形になる。長期的にはMCUなりMPUなりに内蔵する方向に移行するのだろうが、現時点では設計の柔軟性とか既存の製品の流用などを考えるとDiscreteの方が便利、という判断と思われる

ではOPTIGA Trust M MTRではこれがどう楽になるのか? というのがこちら(Photo07)。

  • Discreteの形で対応するしかない

    Photo07:まぁ現実問題、Matterに対応したセキュアエレメントを内蔵するMPUなりMCUがまだ存在しないから、Discreteの形で対応するしかない、という話もあるのだが

OPTIGA Trust M MTRは出荷段階である程度Provisioningが済んでいる。「ある程度」というのがポイントで、Infineonの方でRoot CAやIntermediate CAをすでに立ち上げており(有効期限は20年)、これをそのまま使う事も出来るが後で製品要件にあわせて変更する事もできる。MCUなりMPUとはI2Cで接続する形になっており、あとはOPTIGA Trust MのHost Librayを使ってOPTIGA Trust M MTRを必要な場所で呼び出すだけである。

DACのインストールのタイミングも色々選べるので、自社製造とOEM/ODMの委託のどちらの場合でもギリギリまで変更が可能である。セキュアエレメントだからCC(Common Criteria) EAL6+に対応しており、セキュリティの強度はかなり高い。

利用の手順はこんな感じ(Photo08)。

  • Infineonでまとめて行えるのもメリットの1つ

    Photo08:このあたりをInfineonでまとめて行えるのもメリットの1つである

設計/テストの段階ではDACがインストールされた評価用キット、あるいはテスト用サンプルを使って作業を行う形になる。そして製品化にGoが出たら、OPTIGA Trust M MTRの発注を掛けるが、この時点でChip IDがすでにPre-Provisionされている。問題が無ければこれをそのまま製品に埋め込んで量産となるが、変更などがあった場合はLate-stage ProvisioningでUpdateを掛けることも可能という訳だ。

評価用プラットフォームもすでに各種用意されており、現在設計中のMatter製品へのMigrationなども簡単に行える。Matterの開発をさらに効率化してゆくためには、OPTIGA Trust M MTRを利用する事を推奨する、というのがInfineonからのメッセージであった。

  • 拡張ボードはmikroBUSを使ったものが多い

    Photo09:拡張ボードはmikroBUSを使ったものが多いが、mikroBUSのI2Cを使って接続するものと思われる