FIDEM: A Standard-Compliant Framework for Secure Binding of MUD Profiles to IoT Devices

技術概要：安全な MUD バインディングのための FIDEM フレームワーク

問題提起
メーカー使用記述（MUD）規格（RFC 8520）は、メーカーが IoT デバイスのネットワーク動作プロファイルを定義し、ネットワークコントローラーが期待されるトラフィックに基づいて制限を強制することを可能にします。しかし、デバイスから MUD プロファイルへのバインディング（MUD バインディング）プロセスには重大な脆弱性が存在します。規格は X.509 証明書に基づく安全な発行方法を定義していますが、現在の展開では、その単純性とプラグアンドプレイ性のため、安全でない動的ホスト構成プロトコル（DHCP）拡張に主に依存しています。

安全でない DHCP 拡張では、デバイスが単に自らの MUD プロファイルを指す URL を広告します。ネットワークコントローラーはファイルを取得し、ファイルの真正性ではなく、要求したデバイスの権限に基づいてポリシーを強制します。この分離により、悪意のあるまたは侵害されたデバイスが、他のデバイス向けに意図された正当な MUD プロファイルを参照する有効な URL を広告することが可能になります。その結果、攻撃者は誤った、過度に寛容なネットワークポリシーの強制を誘発し、横移動や権限昇格を容易にします。このバインディングを安全にする既存の解決策は、多くの場合、実用的な制約を満たすことができません。それらは、制約のある IoT デバイスでほとんどサポートされていない公開鍵基盤（PKI）に依存するか、実行時にメーカーによる過度な能動的関与を必要とするか、規格準拠を破るか、安全なプロファイル更新のメカニズムを欠いています。

手法：FIDEM フレームワーク
これらのギャップに対処するため、著者は PKI や検証中のメーカーの能動的関与に依存することなく、DHCP ベースの MUD URL 発行を安全にする規格準拠のフレームワークであるFIDEMを提案します。

1. 脅威モデル: FIDEM は、先行研究よりも強力で現実的な脅威モデルの下で動作します。これは、デバイスがサプライチェーンの侵害を含むライフサイクルのあらゆる段階で侵害される可能性を仮定し、侵害されたデバイスの代わりに操作を実行するために正当なデバイスを暗号オラクルとして使用できる敵対者を考慮します。
2. MUD 管理モデル（MMM）: スケーラビリティを確保するため、FIDEM はクラスベースの管理モデルを導入します。個々のデバイスごとに固有のプロファイルを割り当てるのではなく、メーカーは同一のネットワーク要件を持つデバイスを「MUD クラス」にグループ化します。各クラスは、単一の MUD プロファイルと共有秘密鍵（$K_c$）に関連付けられます。これにより、メーカーの管理オーバーヘッドとデバイスのストレージ要件が削減されます。
3. ゼロ知識証明（ZKP）による暗号的バインディング:
   • 鍵管理: 各 MUD クラス $C$ は、デバイスの安全なハードウェアに格納された秘密鍵 $K_c$ と、楕円曲線上の対応する公開点 $X_c = K_c \cdot G$ を持ちます。MUD ファイルには、これらの公開パラメータ（$X_c$、曲線パラメータなど）が含まれるように拡張されます。
   • 検証プロトコル: DHCP ハンドシェイク中に、デバイスは $K_c$ を開示することなくその所有権を証明します。プロトコルは Schnorr ベースの対話型 ZKP を使用します。
     • デバイスは、MUD URL に加えて、コミットメント $R = r \cdot G$（ここで $r$ はランダムなナンス）を送信します。
     • コントローラーはランダムなチャレンジ $C$ を発行します。
     • デバイスは、コミットメント、公開鍵、チャレンジ、および URL のハッシュである $H$ を用いて、レスポンス $Z = r + H \cdot K_c$ を計算します。
     • コントローラーは等式 $Z \cdot G \stackrel{?}{=} R + H \cdot X_c$ を検証します。
   • 埋め込み: 規格との後方互換性を維持するため、ZKP パラメータ（コミットメント $R$）は、DHCP オプション 161（MUDstring）の予約フィールド、またはスペースが不足している場合は別の DHCP オプションに埋め込まれます。
4. 安全な更新: FIDEM は、パブリッシュ - サブスクライブモデルを介した安全なプロファイル更新をサポートします。コントローラーは定期的に MUD ファイルの署名をチェックします。デバイスが新しい URL で再起動した場合、コントローラーは新しいプロファイルが同じメーカーに属していることを検証し、メーカー間でのなりすましを防止します。

主要な貢献

• 形式的な脅威モデル: 本論文は、サプライチェーンの侵害と、正当なデバイスを暗号オラクルとして使用する敵対者を明示的に考慮する脅威モデルを形式化しました。これは、先行文献でしばしば見過ごされてきたシナリオです。
• 規格準拠のフレームワーク: FIDEM は、非標準拡張や PKI を必要とせずに、DHCP ベースの MUD URL 発行を安全にする最初の解決策です。
• 軽量な ZKP 認証: Schnorr ベースの ZKP を活用することで、FIDEM は PKI の必要性を排除し、メーカーの関与をクラス鍵の初期プロビジョニングとファイルホスティングに最小限に抑えます。
• MUD 管理モデル（MMM）: プロファイル関連付けのためのクラスベースモデルの導入により、スケーラブルな鍵管理とライフサイクルサポートが可能になります。
• 実世界の実装: 著者は、商用の制約付きデバイス（ESP32-S3 および ESP32-C6）上で FIDEM を実装し、ソースコードを公開しました。

実験結果
著者は、ESP32-S3 および ESP32-C6 デバイスを用いて、FIDEM を標準 DHCP、HTTP 上の X.509、TLS 上の X.509 と比較評価しました。

• パフォーマンス: FIDEM は、安全でない標準 DHCP に比べて最小限のオーバーヘッドしか導入しません。ESP32-S3 において、中央値の検証時間は 9.06ms（標準 DHCP の 6.99ms より約 30% 遅い）でした。ハードウェア TEE を備えた ESP32-C6 では、オーバーヘッドは約 7%（5ms）に削減されました。
• PKI との比較: FIDEM は、証明書ベースのアプローチを大幅に凌駕します。TLS 上の X.509 より約20 倍高速であり、エネルギー消費は約 35% 少ないです。
• エネルギー効率: ESP32-S3 における FIDEM のエネルギー消費は 385mJ で、標準 DHCP（354mJ）に対するわずかな増加（約 8%）にとどまり、TLS 上の X.509（574mJ）よりも大幅に低かったです。

重要性と主張
本論文は、FIDEM が IoT ネットワークにおけるセキュリティと展開可能性のギャップを成功裡に埋めたと主張しています。複雑な PKI インフラや能動的なメーカー実行時サポートを必要とすることなく、広く使用されている DHCP 拡張を安全にすることで、FIDEM はリソース制約のある環境における安全な MUD の採用を現実的なものとしています。このフレームワークは、正当なデバイスをオラクルとして悪用できるものを含む、先行研究よりも強力な敵対者にも耐性があり、規格準拠を維持しつつ安全なプロファイル更新をサポートします。著者は、FIDEM が MUD バインディングの脆弱性に対する実用的で低オーバーヘッドの解決策を提供し、IoT デバイスの運用効率を損なうことなく正しいネットワークポリシーの強制を可能にすると結論付けています。