人工知能 (AI) は急速に日常生活に組み込まれつつあり、監視システム、スマート シティ、産業オートメーション、自律ロボット、コネクテッド ビークル、医療機器、インテリジェント アシスタントなど、幅広い分野のアプリケーションを支えています。

AIが集中型のクラウド環境から分散型のエッジ デバイスへと移行するにつれて、モデル、データ、意思決定機能は、アクションが発生する場所により近いところへ展開されるようになっています。この広範な普及はリアルタイム インテリジェンスに大きな機会をもたらす一方で、攻撃対象領域も大幅に拡大します。そのため、信頼性、完全性、セキュリティは、エッジからクラウドまでのAIライフサイクル全体にわたる基本要件となります。

学習済みAIモデルは企業の知的財産です。AIモデルはOTA (無線) で更新され、分散ノード全体に複製され、クラウドからオーケストレーションされます。そのため、AIモデルの保護は、データを取得するエッジだけでなく、ワークフロー全体にわたって維持されなければなりません。つまり、次の3つを継続的に証明することを意味します。

●        デバイスが正規品であること、

●        その上で動作するモデルが改変されておらず正規のものであること

●        入力データが改ざんされていないこと

エッジAIのセキュリティが難しい理由

エッジAIのセキュリティ確保は、従来の組み込みシステムよりも根本的に困難です。これは、AIが学習済みモデル、推論ロジック、意思決定機能といった高価値資産を、保護されたクラウド環境から分散したエッジ デバイスへ移すためです。

AIモデルが展開可能な知的財産となるにつれ、盗難、改ざん、リバース エンジニアリングの魅力的な標的になります。同時に、機密データがデバイス上でローカルに処理されるケースが増えており、プライバシー、データ漏洩、コンプライアンスに関するリスクが高まっています。

中央集権的に管理されるクラウド インフラストラクチャとは異なり、エッジAIの導入は、組織の直接的な管理外で動作する地理的に分散した大規模なデバイス群で構成されることが多く、その結果、安全なアップデート、リモート アテステーション、デバイスの整合性検証、ポリシーの適用が著しく困難になります。そのため、セキュリティは従来のデバイス保護にとどまらず、デバイスと、その意思決定を支えるAIモデルを同時に保護する統合的な信頼アーキテクチャを提供する必要があります。

その結果、AIモデルの整合性は3つの層で同時に確保する必要があり、いずれか1つにギャップがあると、残り2つも損なわれます。

● デバイスの信頼性 — これは正規のデバイスですか？ それとも、コピーされたIDを提示するクローン デバイスですか？

● モデルの信頼性 — これから実行されるモデルはメーカーが署名したものですか？ それとも、改変または置換されたものですか？

● データの信頼性 — センサー入力とトレーニング データは、主張どおりの発生元から実際に取得されたものですか？

ワークフローの各段階 (エッジでのデータ取得、集約、トレーニング、モデルのパッケージングと配布、推論、クラウド オーケストレーション) は、信頼の境界です。その連鎖における未検証のノードはすべて、モデルのIPが漏洩したり、トレーニング データが汚染されたり、侵害されたデバイスが分散展開に受け入れられたりする可能性がある箇所です。

検証可能なハードウェア ルート オブ トラストを実現 AIモデル保護

このギャップを埋めるアプローチは、鍵 (キー) とそれを使用する操作を、独立した改ざん耐性のあるセキュリティ コントローラーに移すことです。鍵はその境界内で生成され、使用されます。暗号化と復号は内部で行われます。ホスト プロセッサはセキュリティ コントローラーに結果を要求します。この操作では、結果を生成した鍵を見る必要はありません。

AIモデルに適用すると、仮定されたシーケンスではなく、検証可能なシーケンスが得られます。モデルは暗号化された状態で出荷されます。実行前に、ホストはモデル イメージの暗号学的ハッシュを計算し、セキュリティ コントローラーに対して、保存されている署名と照合して検証するよう要求します。整合性と真正性のチェックがOKの場合にのみ、コントローラーは復号鍵のロックを解除します。モデルがメモリに復号され、推論が開始されます。検証に失敗すると鍵がロック解除されないため、モデルは復号されず、実行はブロックされます。信頼とは、システムが証明できて検証可能なものであり、前提とするものではありません。

完全なオペレーティング システムを実行するプラットフォームでは、同じ原則が計測ブートとデバイス アテステーションによって上位層まで拡張されます。ブート チェーンの各段階は、次の段階が実行される前にセキュリティ コントローラーに計測され、リモート サービスがデバイスを受け入れたり、デバイスにモデルを提供したりする前に検証できる、プラットフォーム状態の署名付き証跡が生成されます。これにより、デバイスのアイデンティティがエッジからクラウドへ引き継がれ、分散型またはフェデレーテッドなデプロイメントで、状態を確認できるノードのみを受け入れられます。

インフィニオンはこれをどう実現するのか

インフィニオンは、ワークフローの補完的な部分に対応する2つのハードウェア ルート オブ トラストで、このアプローチを実装しています。エッジAI向けにセキュア エレメントとTPMのどちらが適しているかは、両者の一般的な優劣ではなく、ホスト アーキテクチャとセキュリティ要件によって決まります。

OPTIGA™ Trust Mは、PSA Certified Level 3の認証を取得したターンキー型のセキュリティ コントローラーです。デバイスIDを確立し、改ざん耐性のある不揮発性メモリに鍵を保存し、自身の隔離境界内で署名と復号を実行します。これにより、モデル自体が保護対象資産となるエッジAI向けのセキュア エレメント (SE) として適しています。シールド付きの暗号化接続によるI²C経由で接続し、3 × 3 mmのUSON-10パッケージを採用しています。また、あらゆるMCUまたはMPUで動作するよう規定されているため、ホスト プロセッサを変更することなく既存の設計に追加できます。

暗号サポートは、NIST曲線のECC (最大P-521) およびBrainpool r1 (最大512) 、RSA (最大2048) 、AES鍵 (最大256 bit) 、HMAC (最大SHA-512) をカバーします。証明書と鍵ペアはインフィニオンの施設で事前プロビジョニングできるため、デバイスは固有のIDを保持した状態で生産ラインに届きます。

OPTIGA™ Trust M製品カテゴリ ページ

OPTIGA™ TPMは、ハードウェアベースの信頼の基点を提供し、エッジからクラウドまでAIデバイスのセキュリティ確保に役立ちます。暗号鍵を保護し、計測ブートとアテステーションによってプラットフォームの整合性を検証し、AIモデルとデバイスを保護するとともに、クラウドサービスとの安全で認証された通信を可能にします。OPTIGA™ TPMは、エンドツーエンドの信頼を確立することで、組織がより強固なセキュリティ、コンプライアンス、および脅威に対するレジリエンスを備えたAIシステムを導入できるよう支援します。

OPTIGA™ TPM SLB 9672 (SPI) およびSLB 9673 (I²C) は、TCG TPM 2.0 Library Specification revision 1.59に準拠した、すぐに使用できるTrusted Platform Moduleです。Common Criteria EAL4+ およびFIPS 140-2 Level 2の認証を取得しており、51 kBの拡張不揮発性メモリを備えています。

これらは計測ブートとアテステーションを提供するため、AIワークロードは、既知の良好なベースラインに対して状態が検証されたプラットフォーム上でのみ実行されます。さらに、そのIDを外部へ拡張します。OPTIGA™ TPMとOPTIGA™ Trust Mは、AWS IoT GreengrassおよびAzure IoT Edgeへのデバイスの自動オンボーディングをサポートしており、これによりエッジからクラウドまでのデバイスIDは、単に主張されるものではなく暗号的に検証可能になります。分散型およびフェデレーテッドなデプロイメントでは、同じアテステーション エビデンスによって、オーケストレーターは信頼できるノードのみを受け入れられます。ファームウェア更新は耐量子XMSS署名方式によって保護されており、ファームウェア復旧はNIST SP 800-193のプラットフォーム ファームウェア レジリエンス ガイドラインに従います。

OPTIGA™ TPM製品カテゴリ ページ

OPTIGA™ Trust Mは、PSA Certified Level 3の認証を取得したターンキー型のセキュリティ コントローラーです。デバイスIDを確立し、改ざん耐性のある不揮発性メモリに鍵を保存し、自身の隔離境界内で署名と復号を実行します。これにより、モデル自体が保護対象資産となるエッジAI向けのセキュア エレメント (SE) として適しています。シールド付きの暗号化接続によるI²C経由で接続し、3 × 3 mmのUSON-10パッケージを採用しています。また、あらゆるMCUまたはMPUで動作するよう規定されているため、ホスト プロセッサを変更することなく既存の設計に追加できます。

暗号サポートは、NIST曲線のECC (最大P-521) およびBrainpool r1 (最大512) 、RSA (最大2048) 、AES鍵 (最大256 bit) 、HMAC (最大SHA-512) をカバーします。証明書と鍵ペアはインフィニオンの施設で事前プロビジョニングできるため、デバイスは固有のIDを保持した状態で生産ラインに届きます。

OPTIGA™ Trust M製品カテゴリ ページ

OPTIGA™ TPMは、ハードウェアベースの信頼の基点を提供し、エッジからクラウドまでAIデバイスのセキュリティ確保に役立ちます。暗号鍵を保護し、計測ブートとアテステーションによってプラットフォームの整合性を検証し、AIモデルとデバイスを保護するとともに、クラウドサービスとの安全で認証された通信を可能にします。OPTIGA™ TPMは、エンドツーエンドの信頼を確立することで、組織がより強固なセキュリティ、コンプライアンス、および脅威に対するレジリエンスを備えたAIシステムを導入できるよう支援します。

OPTIGA™ TPM SLB 9672 (SPI) およびSLB 9673 (I²C) は、TCG TPM 2.0 Library Specification revision 1.59に準拠した、すぐに使用できるTrusted Platform Moduleです。Common Criteria EAL4+ およびFIPS 140-2 Level 2の認証を取得しており、51 kBの拡張不揮発性メモリを備えています。

これらは計測ブートとアテステーションを提供するため、AIワークロードは、既知の良好なベースラインに対して状態が検証されたプラットフォーム上でのみ実行されます。さらに、そのIDを外部へ拡張します。OPTIGA™ TPMとOPTIGA™ Trust Mは、AWS IoT GreengrassおよびAzure IoT Edgeへのデバイスの自動オンボーディングをサポートしており、これによりエッジからクラウドまでのデバイスIDは、単に主張されるものではなく暗号的に検証可能になります。分散型およびフェデレーテッドなデプロイメントでは、同じアテステーション エビデンスによって、オーケストレーターは信頼できるノードのみを受け入れられます。ファームウェア更新は耐量子XMSS署名方式によって保護されており、ファームウェア復旧はNIST SP 800-193のプラットフォーム ファームウェア レジリエンス ガイドラインに従います。

OPTIGA™ TPM製品カテゴリ ページ

定量化された効果

各デバイスはOPTIGA™ Trust M内に固有のAES 256-bit鍵を保存しており、その鍵がAIモデルの暗号化鍵を保護します。暗号化と復号はOPTIGA™ Trust M内部で行われます。そのため、デバイスが紛失、廃止、または物理的に分解された場合でも、モデルに組み込まれたメーカーのIPは保護されたままです。

OPTIGA™ TPM SLB 9672およびOPTIGA™ TPM SLB 9673は、Common Criteria EAL4+ とFIPS 140-2 Level 2の認証を取得しています。ソフトウェアのみ、または仮想化された信頼の基点では同等の、独立して評価された保証レベルを提供できない場合、これらの数値は評価者が比較として確認できる指標です。

エッジAIセキュリティが最も重要となる領域

3つのアプリケーション領域にリスクが集中します。高価値なモデル、物理的にアクセス可能な設置環境、そして組織の直接的な管理下にない場所で運用されるフリートが組み合わさるためです。

コンピューター ビジョンとセキュリティ監視

防犯カメラ、ビデオ分析、スマートシティ監視、ビデオドアベルは、多額の投資をかけて学習したモデルで推論を実行します。これらは、一般にアクセス可能な場所に設置されたハードウェア上で動作します。モデルが製品の差別化要因であり、デバイスははしごさえあれば誰でも手が届くほどアクセスが容易です。

産業用エッジAIインフラストラクチャ

産業用ゲートウェイ、ルーター、スイッチ、エッジ コンピュート ノード、PLCコントローラーは、機械を動かす判断を行います。ここでは機密性よりも完全性の問題の方が重要です。すり替えられたモデルはIPを漏えいさせるだけでなく、設備の動作そのものを変えてしまいます。長いサービス寿命により、暗号アジリティは後付けではなく設計要件になります。

フィジカルAI

ヒューマノイド ロボットとロボティクスは、フリート全体にわたる分散学習と、人間が共有する空間における自律的な行動を組み合わせます。学習に寄与するすべてのノードと、展開されたモデルに基づいて動作するすべてのノードは検証可能である必要があります。そのため、デバイス アテステーションがフリート参加のゲーティング メカニズムになります。

設計上の考慮事項に関する主要なセキュリティ原則

1. 保存時の暗号化により、保存されたモデルへの不正アクセスを防止します

2. アテステーション ベースのキー プロビジョニングにより、キーは検証済みデバイスにのみ配布されます

3. プラットフォームの整合性の検証により、侵害されたデバイスがクラウドサービスを欺くことを防止します

4. 強制アクセス制御により、不正なモデルアクセスを制限します

5. カーネルのハードニングにより、権限昇格攻撃の攻撃対象領域を縮小します

6. 実行時保護により、実行中の平文露出を最小限に抑えます

7. 包括的な監視により、脅威の検出とインシデント対応が可能になります。

エッジ環境でAIモデルを導入する組織は、このアーキテクチャをオプション機能ではなく、不可欠なセキュリティ基盤として捉えるべきです。

これらの対策を実装するための投資は、数百万ドル規模の知的財産盗難の潜在的リスクから保護すると同時に、将来のハードウェアベースのセキュリティ強化に向けたプロセスとインフラストラクチャを確立します。このフレームワークを採用することで、組織は以下のメリットを得られます。

● IP保護: モデル盗難や不正アクセスに対する多層防御

● コンプライアンス対応: 規制要件および業界のセキュリティ標準に整合可能

● 将来対応: ハードウェア機密コンピューティングが利用可能になった際に対応できるアーキテクチャ

● 運用レジリエンス: インシデント対応のための監視および対応能力

● リスク低減: 攻撃対象領域と権限昇格ベクトルの定量的な削減

暗号化による保護、プラットフォームの整合性、アクセス制御、およびランタイム保護を組み合わせることで、エッジ デバイス上の高価値なAI知的財産に適したセキュリティ態勢が構築されます。実装にはクラウドサービス、デバイス構成、運用プラクティスにわたる調整が必要ですが、その結果、重要なAI資産を保護する堅牢なフレームワークが得られます。

FAQ

既存のエッジ設計に、ハードウェアベースのAIモデル保護を追加できますか？

はい。ハードウェアベースのAIモデル保護は、ホスト プロセッサを変更せずに既存の設計へ追加できます。OPTIGA™ Trust Mは、あらゆるMCUまたはMPUで動作するように規定されており、単一のI²Cインターフェースで、シールドされた暗号化接続を介して接続します。3 × 3 mmのUSON-10パッケージで出荷されるため、基板への影響は小型部品1点とバス1本のみです。さらに、OPTIGA™ Trust M向けに複数のホスト ソフトウェア ライブラリが用意されています。ベアメタル マイクロコントローラー向けのCライブラリ、Linuxベース システム向けライブラリ、Pythonライブラリなどがあります。これにより、幅広いMCUおよびMPUプラットフォームに容易に統合でき、このソリューションがプロセッサ非依存である主要な理由にもなっています。OPTIGA™ TPM SLB 9672はSPIを使用し、OPTIGA™ TPM SLB 9673はI²Cを使用します。いずれもUQFN-32パッケージで、標準的なLinuxおよびWindowsのTPMソフトウェア スタックと統合されます。セキュリティ コントローラーはアプリケーション プロセッサに統合されるのではなくディスクリートであるため、ホスト アーキテクチャやAIランタイムを変更する必要はありません。

OPTIGA™ Trust M内部に安全に保管された暗号鍵が、AIモデルの暗号化鍵を保護します。アプリケーションに応じて、対称暗号方式と非対称暗号方式の両方を使用できます。すべての暗号処理は、OPTIGA™ Trust Mの保護境界内で実行されます。本デバイスは、AES-256、NIST曲線 (最大P-521) およびBrainpool r1曲線 (最大512) 上のECC、RSA (最大2048) 、HMAC (最大SHA-512) など、幅広いアルゴリズムをサポートしています。アルゴリズムと鍵サイズの選択はセキュリティ アーキテクチャに依存しますが、セキュリティ アーキテクチャ自体は同一です。暗号鍵はセキュリティ コントローラーの隔離境界内で使用されるため、暗号処理中であってもホスト プロセッサに公開されません。

OPTIGA™ Trust Mは、AIモデルの機密性、完全性、および真正性を保護することで、エッジAI導入に必要な主要なセキュリティ特性の確立を支援します。AIモデルは保存時に暗号化された形式で保管でき、モデルのアーキテクチャやパラメーターを不正アクセスや抽出から保護できます。デバイスは、使用前にモデルのハッシュと署名を検証することで、モデルが信頼できるソースに由来し、たとえば悪意のあるバージョンに置き換えられるなどの改ざんが行われていないことを確認します。

AIモデルのサイズは、多くの場合、数KBから数MBです。セキュア エレメントは、安全な鍵保管と暗号サービス向けに最適化されており、大量のアプリケーション データを処理する用途には適していません。そのため、通常は責務を分離するエンベロープ暗号化のプロセスが用いられます。OPTIGA™ Trust Mは、暗号鍵を保護および管理します。MCUは、データ暗号鍵を使用して一括復号を実行します。このコンセプトにより、セキュア エレメントを変更することなく、より大規模なAIモデルにも容易にスケールできます。

デバイス バインディングは、プロビジョニング時にAIモデルを特定のデバイスに暗号学的にリンクする手法です。製造時またはオンボーディング時に、モデル暗号鍵は、OPTIGA™ Trust M内に保存されたデバイス固有の暗号学的アイデンティティを使用して保護されます。その結果、意図されたデバイスのみが、モデルを復号するために必要な鍵を復元できます。攻撃者が暗号化されたモデル、アプリケーション ソフトウェア、およびストレージ内容をコピーしたとしても、必要な認証情報が元のデバイスにバインドされているため、そのモデルは他のハードウェアでは使用できません。このアプローチは、モデルの複製 (クローン) を防止し、価値の高いAIモデルのIPを保護するのに役立ちます。

はい。ハードウェアによるAIモデル保護は、産業用温度範囲全体で利用できます。OPTIGA™ Trust Mには標準温度版と拡張温度版があり、拡張温度版は −40℃～+105℃ をカバーし、産業オートメーションおよびインフラ用途向けに20年のライフタイム定格を備えています。OPTIGA™ TPM SLB 9672も同様に、産業用途向けに −40℃～+105℃ の拡張温度範囲で提供されています。屋外監視、産業用ゲートウェイ、または建物インフラに導入されるエッジAIでは、セキュリティ コントローラーの温度定格とライフタイム定格を、AIプロセッサ単体の周囲温度定格ではなく、筐体仕様に合わせる必要があります。

設計で、プラットフォーム レベルの信頼、OS対応の統合、セキュア ブートの計測、デバイス健全性のアテステーション、またはクラウドおよびIoTインフラストラクチャへの標準ベースのオンボーディングが必要な場合は、OPTIGA™ TPMを使用してください。これは、LinuxまたはWindowsベースのゲートウェイ、産業用エッジ コンピューター、PLC、ルーター、スイッチなど、デバイスIDとソフトウェア状態の両方を証明する必要がある接続システムで一般的です。OPTIGA™ TPM SLB 9672およびOPTIGA™ TPM SLB 9673は、SPIまたはI²Cのインターフェース オプション、Common Criteria EAL4+ およびFIPS 140-2 Level 2認証、拡張不揮発性メモリ、より強力な暗号アルゴリズムのサポートを備えた、すぐに使えるTPM 2.0セキュリティ ソリューションです。OPTIGA™ Trust Mなどのセキュア エレメントは、プロセッサ非依存の鍵保護とモデル暗号化キーの取り扱いに適しています。一方、OPTIGA™ TPMは、エッジからクラウドまでプラットフォーム全体の状態を計測し、アテステーションし、信頼する必要がある場合に適しています。

OPTIGA™ TPMは、計測ブートとリモート アテステーションを必要とするプラットフォーム向けに、ハードウェアベースの信頼の基点 (Root of Trust) を提供します。起動時には、関連する各ブート段階とソフトウェア コンポーネントをTPMのプラットフォーム構成レジスタ (PCR) に計測して記録できます。その後リモート サービスは、デバイスを受け入れたり、シークレットをプロビジョニングしたり、AIモデルを提供したりする前に、署名付きのアテステーション証跡を検証できます。エッジAIでは、クラウドはデバイスのIDの主張だけを信頼する必要はありません。ノードが推論、フリート オーケストレーション、またはフェデレーテッド ワークフローに参加することを許可する前に、プラットフォーム状態が既知の正常なベースラインと一致するかどうかを確認できます。OPTIGA™ TPMデバイスはTCG TPM 2.0仕様に基づいており、データの完全性と機密性を保護しながら、接続デバイスの識別と認証を支援するように設計されています。