なぜIoT/M2Mコミュニケーションに注目しているのか？

2019年頃からDIDエコシステムに参加し、初期は人材・金融領域のお客様と共に、モバイルウォレットと属性証明書のモデルを検討していました。実際にβリリースしたときに反応してくれたのは、100%が製造メーカーでした。大学院で趣味でロボットを開発していた経験から、セキュアなM2M通信の実装が闇であることを知っており、このM2M通信のデータセキュリティとDIDとの関係に強い関心を持ちました。現在、IoTソリューション領域は成長を続ける超巨大市場で、現在のテクノロジーでは解決できない深刻な顧客の問題があります。そこで、DID/DIDCommを利用して解決できるのではないかという仮説を検証しながら、2021年夏頃からIoT/M2M領域にフォーカスすることになりました。

達成したいことは、M2Mコミュニケーションにおける安全で信頼できるデータインフラをシンプルにすること、これを誰もが簡単に使いやすくすることです。近年のデータインフラ系SaaS（Zscaler, Okata, Snowflake）の急成長は、すでにデータインフラが”作る”から”使う”時代に変わったことを示しています。パートナー企業との共同プロジェクトやエンジニアとの対話を重ねるたびに、IoTデータインフラを製品ごとにテーラーメイドで構築すること、長期間で安定運用することには限界があることを確信しています。

このテーマにおいて、ものづくり大国である日本は非常によい検証ベッドです。日本から世界に発信する流れも自然的で、僕らがやる意味があるとても好きなテーマです。

M2MコミュニケーションにおけるDID/DIDCommの実装と技術優位性

M2MコミュニケーションにおけるDID/DIDCommの実装で、達成したいことは『正確に送信元を検証し、トランスポートとNW構成に依存せず、データの完全性を保証しながら、許可された受信者以外からは内容を隠し、その受信者にデータを届ける』こと。整理すると以下の5つの要件を同時に満たすことが重要になります。これをスクラッチで構築・運用することが現場の開発者のペインになっています。

1. プロビジョニングの自動化（識別子と公開鍵証明書の紐付け）

2. デバイスのルートオブトラストの確立（暗号鍵管理）

3. 検証可能なデータ通信

4. DIDCommによるE2EEメッセージング

5. デバイスの高度な認証・認可

今回の発表では、DID/DIDCommを活用してどんな技術課題を解決したいか？当社が提供するNodeX（ノード・クロス）の特性や機能についてご紹介し、従来のデータインフラ構築との違いと技術優位性や今後の技術課題について説明しました。参加者と、DIDCommの暗号鍵・暗号処理周りのメカニズム、今後のスケーリングについての課題、実装課題などについて議論を深めました。

発表スライド

Q&A

Q: 暗号用の鍵共有ってどうしているの？
A: DID Document に署名用の鍵と鍵交換用の鍵（ X25519 ）を載せて、DIDから resolve することで、共通鍵を生成します。IoT機器が最終目的地の識別子を知っている場合、複数の TCP Connections を跨っていても、0-RTT で共通鍵生成ができる。

Q: VC あるいは VP を DIDComm Plaintext にするのか？
A: M2M コミュニケーションにおける Verifiable Presentation の有効な使いどころがまだ発見できていないので、現時点では VC を body にいれて DIDComm Plaintext を生成している。

Q: デバイス側の DID の真正性を検証できないと、Replay Attack などが可能になるのではないか？
A: 事前認証プロセスにより、Agent と HUB で共有する秘密情報から HMAC を生成し、Agent と HUB の初回通信時にデバイスの真正性を検証している。以後、HUB の DID Configuration File に登録される DID であるかどうかを確認することで、シャドーIoTや中間者により Replay Attack などを排除することができる。

Q: NodeX HUB で DID Lists を持ってしまうとスケールしないのでは？
A: DIDComm を載せる通信プロトコルやトラフィックの頻度ごとにステートフル/レスな実装のどちらがいいのか判断する前提で、現時点では課題になっていない。IoT機器のインベントリ/ログ管理のことを考えると識別子は管理しておくほうがいいと判断している。

Q: リアルタイム性をどこまで求めますか？マルチホップの場合の順番制御など気になる
A: Simplex 非同期でいい場合、Duplexな通信が求められる場合に、柔軟にMQTT, HTTP(S)などを選べるツールキットにしたいと考えている。順番制御はめちゃくちゃ難しい部分で、各種トランスポートの制約を考えると、 TCP Layer から実装するのもアプローチとしてありますが、DIDComm が trasnport-agnostic であることがとても技術的な魅力なので、DIDComm レイヤーでルーティングを仮想化して、うまく実装することが大切になる。

Q: デバイスにハードコーディングするのではなくて、Resolver みたいなものに委任するのはどうなのか？（デバイスの能力に制約がある場合。通信量が上がるけどね）
A: 非常に面白い視点。RTOSで稼働するMCUの場合、Agent Library のフットプリントの課題に直面する。ソフトウェアではなく物理的な暗号回路に押し付けるやり方もあるし、ご提案いただいたように外部のエージェントに委任することもできるかもしれませんね。

Q: 今回ご紹介いただいたケースは、デバイスがVCをセルフイシューするケースでしたが、外部で発行されたVCをNodeX Agentが提示することもある？
A: ある。ユーザーのモバイル Wallet から VC を IoT 機器に転送し、この VC を IoT 機器があるエンティティに提示するケースなど。標準化されたWalletがモバイルやブラウザに展開されていくと、こうしたユーザー（自然人）とマシンとのインタラクションも簡単に実装できるようになると思う。

DIF Japan について

DIF Japan とは 分散型ID の国際標準化を推進する DIF: Decentralized Identity Foundation の Japan SIG です。現在 DIF Japan を運営する仲間を募集しています。詳細はこちらからご覧ください。
DIF Japan では毎月第四金曜日9:00-10:00 ( JST ) に Monthly Call を開催しています。

Monthly Call Schedule (2023.02.03時点）

• 2月3日（金）9:00-10:00 / zk-SPARQL: SPARQLクエリに対して検証とプライバシ保護が可能な結果を返すパーソナルRDFデータストア / Dan Yamamoto

• 2月24日（金）9:00-10:00 / M2MコミュニケーションにおけるDIDCommの実装と技術優位性 / Masayoshi Mitsui

• 4月7日（金）9:00-10:00 / Selective Disclosure JWT (SD-JWT) の実装 / Kazuhide Yasukata / Yumin Haku

• 4月28日（金）9:00-10:00 / 考え中 / Naohiro Fujie

ご関心のある方はぜひ気軽にご参加ください。
DIF Japan SIG のメーリスか、三井（ mitsui@collabogate.com ）までご連絡いただけると幸いです。