特表2024-535700 | 知財ポータル「IP Force」

知財求人 - 知財ポータルサイト「IP Force」

▶ カーネギー−メロン　ユニバーシティの特許一覧 ▶ バスデバン，アミットの特許一覧 ▶ セカル，ヴヤスの特許一覧 ▶ マコーマック，マシューの特許一覧

特表2024-535700信頼できるエッジＩｏＴセキュリティゲートウェイの正式なモデリングのためのシステム及び方法

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3
4
5
6
7
8
9

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-10-02

(54)【発明の名称】信頼できるエッジＩｏＴセキュリティゲートウェイの正式なモデリングのためのシステム及び方法

(51)【国際特許分類】

G06F 21/55 20130101AFI20240925BHJP

G06F 21/44 20130101ALI20240925BHJP

【ＦＩ】

G06F21/55

G06F21/44

【審査請求】未請求

【予備審査請求】有

(21)【出願番号】P 2024510510

(86)(22)【出願日】2022-07-13

(85)【翻訳文提出日】2024-04-18

(86)【国際出願番号】 US2022036906

(87)【国際公開番号】W WO2023022816

(87)【国際公開日】2023-02-23

(31)【優先権主張番号】63/234,913

(32)【優先日】2021-08-19

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＪＡＶＡ

２．ＡＬＬＯＹ

３．ＤＯＣＫＥＲ

４．ＳＮＯＲＴ

５．ＡＲＭ

(71)【出願人】

【識別番号】591236068

【氏名又は名称】カーネギー－メロンユニバーシティ

【氏名又は名称原語表記】ＣＡＲＮＥＧＩＥ－ＭＥＬＬＯＮＵＮＩＶＥＲＳＩＴＹ

(71)【出願人】

【識別番号】524064081

【氏名又は名称】バスデバン，アミット

【氏名又は名称原語表記】ＶＡＳＵＤＥＶＡＮ，Ａｍｉｔ

(71)【出願人】

【識別番号】524064092

【氏名又は名称】セカル，ヴヤス

【氏名又は名称原語表記】ＳＥＫＡＲ，Ｖｙａｓ

(71)【出願人】

【識別番号】524064106

【氏名又は名称】マコーマック，マシュー

【氏名又は名称原語表記】ＭＣＣＯＲＭＡＣＫ，Ｍａｔｔｈｅｗ

(74)【代理人】

【識別番号】100145403

【弁理士】

【氏名又は名称】山尾憲人

(74)【代理人】

【識別番号】100135703

【弁理士】

【氏名又は名称】岡部英隆

(74)【代理人】

【識別番号】100189544

【弁理士】

【氏名又は名称】柏原啓伸

(72)【発明者】

【氏名】バスデバン，アミット

(72)【発明者】

【氏名】セカル，ヴヤス

(72)【発明者】

【氏名】マコーマック，マシュー

(57)【要約】

マイクロハイパーバイザに基づいて信頼できるＩｏＴセキュリティゲートウェイアーキテクチャのモデルを定義する方法が開示される。モデルの評価は、攻撃を受けているときを含む、各ＩｏＴデバイスのネットワークトラフィックに常に正しいセキュリティ保護が適用されることの保証を提供する。本明細書に開示される方法に従って定義されるモデルは、妥当な性能オーバーヘッドで既存のソフトウェアを利用する広範囲のレガシーハードウェアプラットフォームに堅牢な信頼特性を提供するセキュリティゲートウェイアーキテクチャを検証するために使用される。

【特許請求の範囲】

【請求項1】

ＩｏＴデバイスのための信頼できるゲートウェイを提供するためのモデルを生成するための方法であって、
モデリング言語で、前記ＩｏＴデバイスのための制御プレーンを定義するコントローラを定義するステップであって、前記コントローラが、コントローラマイクロハイパーバイザによって保護される又は証明されるソフトウェアを実行する、ステップと、
モデリング言語で、セキュリティゲートウェイマイクロハイパーバイザによって証明されたデータプレーンを定義するセキュリティゲートウェイを定義するステップと、
を含む方法。

【請求項2】

前記コントローラは、コントローラ署名インタフェースによって前記モデリング言語で定義され、
前述セキュリティゲートウェイは、ゲートウェイ署名インタフェースを使用して前記モデリング言語で定義される、請求項１に記載の方法。

【請求項3】

前記コントローラ署名インタフェースは、
セキュリティポリシーと、
前記セキュリティポリシーに基づいて前記ゲートウェイ署名インタフェースを構成するために使用されるチャネルと、
を備える、請求項２に記載の方法。

【請求項4】

前記ゲートウェイ署名インタフェースは、
ｖＳｗｉｔｃｈと、
１つ以上のミドルボックスと、
を備え、
前記ゲートウェイ署名インタフェースは、前記チャネルを介して前記コントローラ署名インタフェースから受信したセキュリティ情報に基づいて前記ｖＳｗｉｔｃｈにパスをインストールする、請求項３に記載の方法。

【請求項5】

各パスがミドルボックスと関連付けられ、前記ミドルボックスを通じて特定のＩｏＴデバイスとの間のトラフィックがルーティングされる、請求項４に記載の方法。

【請求項6】

前記セキュリティポリシーがミドルボックスごとにパスを指定する、請求項５に記載の方法。

【請求項7】

ＩｏＴデバイスとの間で送受信されるデータパケットがどのように処理されるかを指定する一連の記述を含む機能を定義するステップ、を更に含む、請求項６に記載の方法。

【請求項8】

前記ｖＳｗｉｔｃｈは、前記機能に従って前記データパケットのそれぞれを評価し、
無害データパケットをＩｏＴデバイスにルーティングし、
有害データパケットをドロップする、
ようにモデリングされる、請求項７に記載の方法。

【請求項9】

前記方法は、前記信頼できるゲートウェイを確立するために充足されなければならない１つ以上の制約を指定する前記モデルにおける述語を定義するステップ、を更に含む、請求項７に記載の方法。

【請求項10】

前記１つ以上の制約は、前記セキュリティポリシーが改ざん防止される及び隔離されることを指定する制約を含む、請求項９に記載の方法。

【請求項11】

前記１つ以上の制約は、前記制御プレーンとデータプレーンとの間の前記チャネルが悪意のあるメッセージを注入する攻撃者の影響を受けないことを指定する制約を含む、請求項９に記載の方法。

【請求項12】

前記１つ以上の制約は、正しいソフトウェアが前記コントローラ上で実行されていることを指定する制約を含む、請求項９に記載の方法。

【請求項13】

前記１つ以上の制約は、前記データプレーン上のパケットが正しいパスを辿って正しい一連のミドルボックスによって処理されることを指定する制約を含む、請求項９に記載の方法。

【請求項14】

各データパケットは、前記コントローラによって指定されて前記ｖＳｗｉｔｃｈ及び各ミドルボックスによって実行される前記パスをたどる、請求項９に記載の方法。

【請求項15】

前記方法は、前記モデルに基づいて真であると評価しなければならない一連の記述を含む前記モデルにおいてアサートインタフェースを定義するステップ、を更に含む、請求項９に記載の方法。

【請求項16】

前記一連の記述は、全ての有害パケットがドロップされる間に全ての無害パケットを送信できるようにすることを指定する、請求項１５に記載の方法。

【請求項17】

ＩｏＴデバイスのための信頼できるゲートウェイを検証する方法であって、前記アサートインタフェース内の前記一連の記述のいずれかの反例が存在するか否かを決定するために請求項１５に記載の前記モデルを評価するステップ、を含む方法。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願
この出願は、２０２１年８月１９日に出願された米国仮特許出願第６３／２３４，９１３号の利益を主張する。当該仮特許出願の内容は参照により本明細書に援用される。
政府の利益

【0002】

この発明は、全米科学財団によって命じられたＣＮＳ－１５６４００９との契約の下で米国政府の支援を受けてなされた。米国政府は、この発明に一定の権利を有する。

【背景技術】

【0003】

発明の背景
モノのインターネット（ＩｏＴ）は、オブジェクトがタスクを実行してインターネットを介して他のデバイスと接続してデータを交換できるようにする、組み込みセンサ、ソフトウェア、及び他のコンポーネントを有する物理デバイスのネットワークを表す。これらのデバイスは、通常の家庭用品から洗練された産業用具にまで及ぶ。

【0004】

ホームネットワークから製造フロアまで、ますます多くのＩｏＴデバイスがエッジ環境に配備される。残念なことに、これらのデバイスは、無数の脆弱性に悩まされており、攻撃者は、この脆弱性を、保護されているネットワークへの踏み石として及び他の攻撃のための発射台として利用することができた。その結果、これらのＩｏＴデバイスは、エッジネットワークのセキュリティに対する継続的な脅威をもたらす。

【0005】

業界及び学界は、オンサイトのセキュリティゲートウェイによりエッジネットワーク上の潜在的に脆弱なＩｏＴデバイスを保護することを提案している。これらの「ボルトオン」セキュリティゲートウェイは、ＩｏＴデバイスとの間の全てのトラフィックを傍受し、ネットワークレベル（例えば、ファイアウォール）のミドルボックスを介してセキュリティ保護を適用するように設計される。これらのミドルボックスは、デバイスのソフトウェアにパッチを適用することなくデバイスの脆弱性を軽減する「ネットワークパッチ」を実装するために使用され得る。

【0006】

ボルトオンセキュリティゲートウェイは、人気を得ており、配備可能な解決策であるが、ネットワークレベルの保護を提供するシステムの信頼性の基本的な問題は残っている。例示的なシナリオとして、複数のセキュリティゲートウェイによって保護された多数のＩｏＴデバイスを有するスマートファクトリを考える。ファクトリのセキュリティゲートウェイは、個々のＩｏＴデバイスの脆弱性に合わせて調整されたネットワークレベルの保護を提供する。残念ながら、セキュリティゲートウェイは単一障害ポイントを形成する。セキュリティゲートウェイは、ゲートウェイが一般にコモディティソフトウェア（例えば、Ｌｉｎｕｘ（登録商標）、Ｄｏｃｋｅｒ、ＯＶＳ、Ｓｎｏｒｔなど）を実行するため、（ＯＳ及び／又はアプリケーションの脆弱性を利用することによって）セキュリティゲートウェイを侵害することができる敵対者に対して特に脆弱である。侵害されると、敵対者はゲートウェイの保護（例えば、ファイアウォールルールを除去する）を修正することができ、それによってＩｏＴデバイスに対する攻撃が操業を停止／変更できるようにする。

【0007】

信頼できないクラウド環境でアプリケーションを保護するための現在のアプローチは、セキュリティゲートウェイにおける信頼を確立するために適用される可能性がある。これらのアプローチは、ハードウェア固有の能力（例えば、ＳＧＸ、ＭＰＸ）に依存する。残念なことに、そのようなアプローチは高性能のオーバーヘッドを有し、ＩｏＴ配備には実用的ではない。また、それらのアプローチは、特定のプロセッサクラスに限定される一般性を欠いており、制約のあるメモリ割り当てを伴うユーザ空間アプリケーションのみをサポートする。更に、セキュリティの脆弱性に対処するには、ハードウェアの新しいバージョンを製造する必要がある。

【発明の概要】

【0008】

本明細書では、マイクロハイパーバイザに基づいて信頼できるＩｏＴセキュリティゲートウェイアーキテクチャのモデルを定義する方法が開示され、アーキテクチャモデルの評価は、攻撃を受けているときを含む、常に各ＩｏＴデバイスのネットワークトラフィックに正しいセキュリティ保護が適用されることの正式な（数学的）保証を提供する。本明細書に開示される方法に従って定義されるモデルは、妥当な性能オーバーヘッドで既存のソフトウェアを利用する広範囲のレガシーハードウェアプラットフォームに堅牢な信頼特性を提供するセキュリティゲートウェイアーキテクチャを検証するために使用される。

【0009】

本明細書で開示されるように、マイクロハイパーバイザに基づく手法は、エッジセキュリティゲートウェイにおける信頼を構築するためのアーキテクチャ基盤として使用される。従来のハイパーバイザのようなマイクロハイパーバイザは、前述の課題に効果的に対処するために適用することができるコアセキュリティ機能（例えば、メモリ分離、調停、及び証明）を提供するソフトウェア基準モニタである。従来のハイパーバイザとは対照的に、マイクロハイパーバイザは、潜在的な脆弱性を排除するための正式な検証を可能にする信頼できるコンピューティングベース（ＴＣＢ）及び複雑さを劇的に低減してこれらの機能を提供する。更に、マイクロハイパーバイザは、一般性を失うことなく、最小限の性能オーバーヘッドで堅牢な信頼特性を実現するための拡張可能な基盤を提供する。最後に、アプリケーション（例えば、前述のＳＧＸの制限）を制限する特定のハードウェア機能を使用する手法とは対照的に、マイクロハイパーバイザは、修正されていないソフトウェア（例えば、Ｌｉｎｕｘ）を実行する様々なハードウェアプラットフォーム（例えば、ｘ８６、ＡＲＭ、マイクロコントローラ）をサポートすることができる。したがって、マイクロハイパーバイザは、セキュリティ機構を構築するための実用的で安全な基礎を提供する。

【0010】

これまで、マイクロハイパーバイザはエッジＩｏＴゲートウェイでは使用されていなかった。したがって、本発明の新規性は、エッジＩｏＴセキュリティゲートウェイのためのより全体的なシステム敵対者モデル及びマイクロハイパーバイザに基づく高レベルアーキテクチャから導かれ、正式に証明されたセキュリティ特性を有する実用的で柔軟な解決を可能にする。

【図面の簡単な説明】

【0011】

【図1】ＩｏＴデバイスに関連する様々な攻撃ベクトルを示す概略図である。

【図2】信頼でき、拡張可能であり、広く配備可能なエッジセキュリティゲートウェイアーキテクチャの高レベルブロック図である。

【図3】データプレーン実装上のアーキテクチャのスタックの高レベルブロック図である。

【図4】アーキテクチャモデルの重要なコンポーネントを示すブロック図である。

【図5】ソフトウェア定義セキュリティゲートウェイアーキテクチャの要約形式モデルを示すＡｌｌｏｙモデリング言語のリストである。

【図6】ポリシー分離及び調停のＡｌｌｏｙモデルを示す。

【図7】インスタンス検証のＡｌｌｏｙモデルを示す。

【図8】メッセージ完全性及び認証のＡｌｌｏｙモデルを示す。

【図9】パケットパス及びデータ検証のＡｌｌｏｙモデルを示す。

【発明を実施するための形態】

【0012】

図１は、ボルトオンセキュリティアーキテクチャが脆弱である様々な攻撃ベクトルを示す。攻撃者は、アーキテクチャ内の複数のポイントで攻撃を開始する可能性がある。例えば、攻撃者は、（１）パッチされていないエクスプロイトを使用してゲートウェイ自体（「Ｂ」）を危険にさらすこと、及び（２）攻撃者のトラフィックが通過できるようにミドルボックス構成を変更して、攻撃者が工場のＩｏＴデバイスを危険にさらし、専有データ（「Ａ」）を盗むことを可能にすることができる。ソフトウェアを変更する以外に、攻撃者はネットワークメッセージを改ざんすることもできる。例えば、コントローラとゲートウェイとの間の制御チャネル（「Ｃ」）及びｖＳｗｉｔｃｈとミドルボックスとの間のデータチャネル（「Ｄ」）上のパケットを変更し、誤ったミドルボックスにトラフィックをリダイレクトし、セキュリティ検査を回避する。信頼できるセキュリティアーキテクチャは、ネットワークトラフィックの改ざんを禁止しながらゲートウェイ及びコントローラのソフトウェアを保護する必要がある。

【0013】

これらの様々な攻撃ベクトルに対処するために、本明細書では、今日のエッジＩｏＴ配備のセキュリティ課題に対処する、信頼でき、拡張可能であり、広く配備可能なエッジセキュリティゲートウェイアーキテクチャを実装するシステム及び方法が開示される。

【0014】

設計空間は、２つの軸に沿って分類することができる。第１に、ハードウェア機能に依存する手法は、それらがサポートすることができるハードウェアプラットフォーム及びソフトウェアの両方において制限される。更に、それらのセキュリティ特性は、脆弱性を有することが知られているマイクロコード及びシリコンにおける複雑で不透明な実装に依存する。第２に、純粋なソフトウェアアプローチ（例えば、形式検証、セキュアプログラミング言語）は、かなりの再実装及び検証努力を必要とするため、制限される。エッジセキュリティゲートウェイ上で一般的に使用される多くのソフトウェアアプリケーションは、１０万ラインを超えるＣ／Ｊａｖａに及ぶため、これはすぐに扱いにくくなる。

【0015】

重要なセキュリティ機能を、脅威に対処するために新しいハードウェアを必要とするハードウェア実装、又はソフトウェアスタック全体の大幅な再実装又は正式な検証努力を必要とするソフトウェアアプローチのいずれかに結び付けることは危険である。代わりに、本アーキテクチャは、基本的な信頼特性を提供し、進化する脅威からエッジデバイスを保護するために、小さなＴＣＢ及び拡張可能なソフトウェアフレームワークと組み合わせてレガシーハードウェア機能を活用する。

【0016】

その結果、マイクロハイパーバイザに基づく手法が本明細書で開示され、図２に示す信頼できるエッジセキュリティゲートウェイアーキテクチャを可能にする。エッジセキュリティゲートウェイアーキテクチャは、必要なシステムコンポーネントのみにセキュリティ保護を後付けする。マイクロハイパーバイザは、本質的に、保護者として機能するソフトウェア参照モニタであり、スモールＴＣＢを使用してシステムリソース（例えば、ファイル、ソケット）へのアクセス制御を実施する。これらの保護は、きめ細かい方法で適用することができ、最小限の性能オーバーヘッドで単一のデータ値（例えば、秘密鍵）又はオブジェクトの複雑なセット（例えば、仮想マシン）を保護することができる。マイクロハイパーバイザは、セキュリティサービスを拡張として設計及び実装することを可能にする、小さいＴＣＢを用いたきめ細かい調整、分離、及び証明のための強力な基礎を提供する。

【0017】

それらの単純さ及び小さいＴＣＢに起因して、マイクロハイパーバイザは、それらのコード内の潜在的な脆弱性を排除するための正式な検証に適している。更に、マイクロハイパーバイザは、任意のハードウェアプラットフォーム上で潜在的にサポートすることができる。本発明は、信頼できるセキュリティゲートウェイアーキテクチャを構築するために、前述のマイクロハイパーバイザ対応の基礎的能力に基づいて構築される。コントローラ及びゲートウェイのソフトウェアは、マイクロハイパーバイザの上で動作し、それによって任意の汎用ＯＳ及びアプリケーションスタックをサポートする。コントローラ上で、重要なデータ（例えば、セキュリティポリシー）は、信頼できないソフトウェア（例えば、ＯＳ）からそれを分離するためにマイクロハイパーバイザ拡張に移行される。更に、全てのアクセスはマイクロハイパーバイザによって媒介され、攻撃者がデータの整合性を損なうことを禁止する。

【0018】

ゲートウェイでは、カスタマイズされたミドルボックスのセットが各デバイスに割り当てられる。ミドルボックスは互いに分離されている。ミドルボックスは、単一のＩｏＴデバイスに割り当てられ、マイクロハイパーバイザによって起動時に証明される処理要素又は仮想マシンである。更に、各ミドルボックス及びｖＳｗｉｔｃｈの署名は、それらの完全性を検証するために定期的に監視される。最後に、コントローラ及びゲートウェイは、インスタンス化された保護がセキュリティポリシーを正しく反映することを保証するために、制御プレーンとデータプレーンとの間の通信を仲介するために使用されるマイクロハイパーバイザ拡張である信頼できるエージェントを実行する。

【0019】

マイクロハイパーバイザに基づくアーキテクチャは、３つの重要な利点を提供する。第１に、このアーキテクチャは、アーキテクチャが性能的でありながら正しい保護を実施することを正確に保証することを可能にするきめ細かい分離及び調停を提供する。第２に、このアーキテクチャは、拡張可能であり、新たなセキュリティ機能の急速な成長及び新たな脅威への対応を可能にする。第３に、このアーキテクチャは、広く配備可能であり、信頼を提供するための低い性能オーバーヘッドで、既存のソフトウェアを利用しながら広範囲のハードウェアプラットフォームをサポートする。

【0020】

開示されたアーキテクチャ及び関連する正式なモデリングが対処する以下の３つの課題がある。すなわち、（１）必要なセキュリティ特性：全体論的敵対者モデルの下で信頼を保証するセキュリティ特性を識別する；（２）動的ミドルボックスのサポート：ＩｏＴ環境によって必要とされる動的ミドルボックスを保護することを可能にし、敵対者が保護を変更することができないことを保証する；（３）セキュアな通信：パフォーマンスへの影響が低いパケットごとの保護を提供し、敵対者がパケットを変更又はスプーフィングすることができないことを保証する。次に、これらの要件に対処するアーキテクチャの重要なコンポーネントについて説明する。

【0021】

敵対者及び信託財産：目標は、全体論的脅威モデルに対するエンドツーエンドの保護を提供することである。ＳＤＮドメイン内では、これは、制御プレーンとデータプレーンの両方を保護することを伴う（例えば、ＢＧＰハイジャックから）。しかしながら、ＩｏＴセキュリティゲートウェイに関する以前の研究は、通常、狭い脅威モデルのみを考慮していた。

【0022】

この目的のために、そのような敵対者は、ゲートウェイの保護を阻止する目的で体系的に定義される（すなわち、保護されたＩｏＴデバイスの利用を可能にする）。敵対者は、セキュリティアーキテクチャ並びに全てのデバイスへのネットワークアクセスの知識を有すると仮定される。敵対能力は、（１）デバイスのソフトウェアスタックを侵害する能力（すなわち、コントローラ又はゲートウェイ上のソフトウェア：図１の「Ａ」及び「Ｂ」）、及び（２）ネットワークメッセージを挿入／変更する能力（すなわち、制御、データチャネル：図１の「Ｃ」及び「Ｄ」）の２つのカテゴリにグループ化される。

【0023】

敵の能力のセットを表１に要約する。これらの能力は、ＩｏＴデバイスを保護し、一緒になって敵対モデルを形成するアーキテクチャの能力を阻害する。

【表1】

【0024】

完全なリストではないが、表１の脅威例は、信頼できるアーキテクチャに必要な基本的なセキュリティ特性を定義するために使用される。表１の敵対モデルに基づいて、信頼できるセキュリティゲートウェイアーキテクチャに必要な少なくとも５つの基本的な特性がある。

【0025】

データ分離及び仲介（Ｐｓｗ１）：セキュリティクリティカルロジックを分離する能力（例えば、ＯＳがセキュリティポリシーにアクセスしないようにする）及び信頼できるエンティティにセキュリティクリティカルデータへのアクセスを仲介させる能力（例えば、信頼できないアプリケーションの秘密鍵へのアクセスをブロックする）。

【0026】

ソフトウェア完全性（Ｐｓｗ２）：コード及びデータの修正を検出する能力（例えば、ミドルボックス構成の変更）。

【0027】

セキュア制御チャネル（Ｐｃｏｍ１）：コントローラとゲートウェイ（例えば、ゲートウェイは、コントローラからのコマンドのみを実行する）との間で転送されるデータを信頼する能力。

【0028】

セキュアデータチャネル（Ｐｃｏｍ２）：パケットが正しいミドルボックス（例えば、パケットは誤ったミドルボックスによって処理されるべきではない）を介してルーティングされることを信頼する能力。

【0029】

このアーキテクチャは、追加の敵対的な特性をサポートすることができるが、これら４つは信頼できるアーキテクチャにとって基本的なものである。これらの基本的な特性は、（１）実行中のコード及びデータの保護（Ｐ_ＳＷ）と、（２）通信の保護（Ｐ_ｃｏｍ）とに分類することができる。

【0030】

形式モデル

【0031】

信頼できるアーキテクチャの設計を導き、知らせるために、現在のソフトウェア定義ＩｏＴセキュリティゲートウェイアーキテクチャの正式なモデルが生成される。このモデルは、アーキテクチャの重要なコンポーネント及びインタフェースの識別を助け、対応するアーキテクチャ要素を正式に定義及び符号化し、所望の信頼性及びセキュリティ特性を証明する。

【0032】

幾つかの実施形態では、Ａｌｌｏｙモデリング言語（図５、リスト１を参照）を使用して、ボルトオンＩｏＴセキュリティアーキテクチャのモデルを生成することができる。Ａｌｌｏｙモデルは、一階述語論理および関係論理を使用して定義される。Ａｌｌｏｙ言語は、その中心では、使用が容易であるが、関係の概念に基づく表現論理学である。Ａｌｌｏｙモデルは、スコープ制約付き充足可能性問題にコンパイルされ、既製のＳＡＴソルバーによって解析される。この解析は、モデルのインスタンスが存在するかどうかを識別し、制約に対する反例を識別するために使用することができる。この分析は、攻撃ベクトルを識別し、セキュリティアーキテクチャを改良し、信頼特性を形式化するために使用される。

【0033】

モデル記述及びセマンティクス－図４にブロック図形式で示されているボルトオンソフトウェア定義ＩｏＴセキュリティアーキテクチャモデルは、集中コントローラと、ＩｏＴデバイスとの間でパケットを処理するゲートウェイのセットとを含む。簡潔にするために、単一のゲートウェイを有する例示的なアーキテクチャを使用して、リスト１の簡略化されたＡｌｌｏｙモデルを説明する。

【0034】

２つの主要なエンティティは、Ａｌｌｏｙのｓｉｇインタフェースを使用して、最初にモデリングされたコントローラ及びゲートウェイを提供する（リスト１の行１～１０）。ｓｉｇ（署名（ｓｉｇｎａｔｕｒｅ））は、セット（例えば、コントローラ）と他のｓｉｇ（すなわち、各コントローラは１つのポリシーを有する、リスト１の２行目を参照）との関係を定義する。コントローラは、セキュリティポリシーを維持し、ポリシーに基づいて各ゲートウェイを構成するために制御チャネルを使用する。各ゲートウェイは、関連するコントローラによって管理される。ゲートウェイは、制御チャネルを介してそのポリシーを受信し、ｖＳｗｉｔｃｈにパスをインストールし、次いでミドルボックスをインスタンス化する。各パスは、特定のＩｏＴデバイスのどのミドルボックストラフィックがルーティングされるべきかを指定する。

【0035】

ゲートウェイがパケットを処理する方法は、Ａｌｌｏｙのｆｕｎ（機能）インタフェースを使用してモデリングされている（リスト１の１１～１８行を参照）。機能は、一連の記述を評価し、全ての可能な解決策を返す。ゲートウェイによって受信されたパケットは、ルーティングのためにｖＳｗｉｔｃｈに送信される。ｖＳｗｉｔｃｈは、特定のミドルボックス（ＲＯＵＴＥＰＫＴ、リスト１の１２行目を参照）にパケットをルーティングする。次いで、ミドルボックスはパケットを処理し、パケットが無害（benign）であるか有害（malicious）であるかを決定する（ＭＩＤＤＬＥＢＯＸＰＲ０ＣＥＳＳ、リスト１の行１３を参照）。無害のパケットは元のスイッチにルーティングされ、次いでＩｏＴデバイスに送出されるが、他の全てのパケットはドロップされる。

【0036】

次に、Ａｌｌｏｙのｐｒｅｄ（述語）インタフェースを使用して信頼できるゲートウェイアーキテクチャが定義される（リスト１の１９～２７行を参照）。述語は、一連の制約を評価する。述語は、全ての制約が充足されている場合にのみ真を返し、そうでない場合には偽を返す。したがって、信頼できるアーキテクチャのためには、以下の条件が全て充足されなければならない。第１に、攻撃者は、コントローラ上のポリシーを改ざんできてはならない（すなわち、ＴＡＭＰＥＲＰＲＯＯＦは、リスト１の行２ｌにおいて真である）。第２に、コントローラとゲートウェイとの間の制御チャネルは、悪意のあるメッセージを注入する攻撃者の影響を受けないようにセキュアでなければならない（すなわち、ＳＥＣＵＲＥＣＨＡＮＮＥＬは、リスト１の行２２において真である）。第３に、正しいソフトウェアは、コントローラ、ｖＳｗｉｔｃｈ、及び中間ボックスで実行されていなければならない（ＣＯＲＲＥＣＴＳＷは、リスト１の２３～２６行において真である）。最後に、各パケットは、コントローラによって指定され、ｖＳｗｉｔｃｈ及び各ミドルボックスによって実行されるパスに従う必要がある（リスト１の２７行目ではＡＵＴＨＥＮＴＩＣＡＴＥＲＯＵＴＥが真である）。これらの条件の全てが真である場合、ゲートウェイアーキテクチャは信頼できると見なされる。

【0037】

最後に、Ａｌｌｏｙのアサートインタフェースを使用して、全ての出力パケットが正しく処理されたという目標が定義される（リスト１の２８～３１行を参照）。Ａｌｌｏｙにおいて、アサートは、一連の記述がモデルに基づいて真でなければならず、特許請求の範囲のいずれかが真でない場合に反例を生成することを主張する。信頼できるゲートウェイアーキテクチャは、この目標を達成することができる。具体的には、全ての有害パケットをドロップしながら、全ての無害パケットを許可する。

【0038】

アーキテクチャモデル及びセマンティクスを使用して、包括的なセキュリティ特性及びそのサブプロパティが定義される。

【0039】

包括的なセキュリティ特性：ＩｏＴデバイスのインバウンド及びアウトバウンドトラフィックの全てが信頼できるセキュリティゲートウェイを通過するネットワークを考えると、目標は、無害パケットが許可され、有害パケットがドロップされるように、ゲートウェイによって出力された任意のパケットｐｋｔが正しいミドルボックスによって処理されたことを保証することである（リスト１でモデリングされている）。これは、以下のように表すことができる。

【数1】

【0040】

攻撃者の存在下でこの特性を達成するために、ゲートウェイアーキテクチャは信頼されなければならず、これは以下のように形式的に表すことができる。

【数2】

【0041】

式（１，２）は、リスト１に示すようにＡｌｌｏｙで実現され、ゲートウェイアーキテクチャは、ソフトウェアミドルボックスを使用してパケットを処理するコントローラ及びゲートウェイでインスタンス化される。ＰＲＯＣＥＳＳＰＫＴ機能は、各パケットが無害であり、したがってその最終宛先に転送されることが許可されるか、又は有害のものであり、ドロップされるかを決定する。ＴＲＵＳＴＥＤＧＡＴＥＷＡＹ述語は、（ゲートウェイ及びコントローラから構成される）アーキテクチャが信頼できるかどうかをテストする。モデルは、コントローラがゲートウェイに割り当てられていること、コントローラのセキュリティポリシーが改ざん防止であること、コントローラとゲートウェイとの間のチャネルがセキュアであること、コントローラ、ｖＳｗｉｔｃｈ、及び全てのミドルボックスが正しいことが証明されていること、及び処理されている各パケットが認証されたルートに従うことを検証する。これらの要件を満たすゲートウェイは、全ての無害パケットが許可され、有害パケットがドロップされる（アサートインタフェースで確認される）ことを保証する。

【0042】

包括的なセキュリティ特性は、４つのサブプロパティに更に分解される。これらのサブプロパティは、（１）データ及び実行コードの保護（Ｐ_ＳＷ１，Ｐ_ＳＷ２）及び（２）ネットワーク通信の保護（Ｐ_ＣＯＭ１，Ｐ_ＣＯＭ２）の２つのカテゴリに広くグループ化することができる。これらのそれぞれについて、ここでより詳細に説明する。

【0043】

セキュリティポリシーアイソレーション及びメディエーション（Ｐ_ＳＷ１）：第１のサブプロパティは、コントローラに格納されたセキュリティポリシー（データ）を保護することである。コントローラアプリケーションは、セキュリティポリシーを脆弱にする攻撃を受ける。システムの残りの部分の正当性はこのポリシーに基づくので、ポリシーは改ざん防止でなければならない。これを達成するために、セキュリティポリシーは保護メモリ内で隔離され、全てのアクセスは信頼できるエンティティ（図６のリスト２を参照）による仲介を必要とする。そのような防御は、ＯＳ及び他の信頼できないアプリケーションがセキュリティポリシーにアクセスして変更するのを阻止する。これは、以下のように表すことができる。

【数3】

【0044】

リスト２は、式（３）がどのようにＡｌｌｏｙでモデリングされるかを示す。ＴＡＭＰＥＲＰＲＯＯＦ述語は、オブジェクトが隔離メモリ内に位置し、全てのアクセスが仲介されるかどうかをチェックする。アサートインタフェースは、コントローラのポリシーが改ざん防止であることをチェックする。

【0045】

コンポーネントインスタンス検証（Ｐ_ＳＷ２）：セキュリティポリシーに加えて、重要なコンポーネントのソフトウェアは、攻撃者によって（例えば、表１の攻撃Ｂ）変更されてはならない。これを達成するためには、重要なコンポーネントの正しいインスタンスが実行されていることの検証が必要である。これは、コントローラ、ｖＳｗｉｔｃｈ、及び全てのミドルボックス（図７のリスト３を参照）を検証することを含む。ここで、各ミドルボックスインスタンスは、コントローラのセキュリティポリシーによって現在指定されているタイプ及び構成（例えば、ルールセット）である。これは、以下のように表すことができる。

【数4】

【0046】

式（４）の実施態様は、リスト３でモデリングされている。述語ＲＥＭＯＴＥＡＴＴＥＳＴは、オブジェクトが正しいソフトウェアを有し、その正当性を証明できることをチェックする。これは、コントローラ、ｖＳｗｉｔｃｈ、及び各ミドルボックスに対してアサートすることによって検証される。

【0047】

制御メッセージ保全及び認証（Ｐ_ＣＯＭ１）：制御チャネル攻撃（例えば、表１の攻撃Ｃ）から保護するために、制御チャネルがセキュアであるという保証が提供される。これを達成するために、制御チャネルは、チャネルを介して送信されるデータが修正又は偽装されないように（例えば、コントローラのみがゲートウェイにミドルボックス構成コマンドを送信することができる）認証及び暗号化される必要がある。一方、チャネルによって使用される秘密鍵は分離され、任意のアクセスは信頼できるエンティティ（図８のリスト４を参照）によって仲介される。これは、以下のように表すことができる。

【数5】

【0048】

式（５）のＡｌｌｏｙ実装のモデルがリスト４に示される。ＴＲＵＳＴＷＯＲＴＨＹＣＨＡＮＮＥＬ述語は、チャネル（すなわち、コントローラとゲートウェイとの間でメッセージを送信するために使用される方法）が認証された暗号を使用していること、及び暗号鍵が改ざん防止されていることをチェックする。アサートは、ゲートウェイとコントローラとの間のチャネルが認証された暗号化を使用し、両方のホストが暗号鍵を保護することを検証する。

【0049】

パケットパス及びデータ検証（Ｐ_ＣＯＭ２）：各パケットは、セキュリティポリシーによって指定された正しいミドルボックスにルーティングされなければならない。インターネットルーティングに関する以前の研究では、パケットが指定されたパスをたどることを検証するために、ホップごとのパス認証が提唱されている。本明細書では、誤ったミドルボックス（例えば、表１の攻撃Ｄ）に悪意をもってルーティングされたパケットを検出するために、同様の保証が提供される。特に、パケットの意図されたパスが実施されなければならず、パケットデータが修正されているかどうか（図９のリスト５を参照）。これは、以下のように表すことができる。

【数6】

【0050】

図９のリスト５は、式（６）のＡｌｌｏｙ実装を示す。機能ＧＥＴＰＡＴＨは、適切なミドルボックスにパケットのマッピングを提供し、ゲートウェイ上のパケットの一連のホップを返す。次に、述語ＡＵＴＨＥＮＴＩＣＡＴＥＤＨＯＰが定義され、これは、パケットが修正されなかったこと、及び正しいホップ位置に到達したことを確認する。パケットが正しいパスを辿ること、及び各ホップ位置でパケットが修正されないようにするために、ゲートウェイによって処理されているパッカーがアサート記述を使用して認証されたルートを辿ることが検証される。

【0051】

これらの特性を提供するシステムは、構築により、表１の例示的な攻撃を防ぐ。表２に示すように、セキュリティポリシーアイソレーション及びメディエーション（Ｐ_ＳＷ１）は、攻撃者がセキュリティポリシーを変更することを阻止する（表１の攻撃Ａ）。コンポーネントインスタンス検証（Ｐ_ＳＷ２）は、アーキテクチャが、攻撃者がミドルボックスを変更していることを検出することを可能にする（表１の攻撃Ｂ）。制御メッセージ完全性及び認証（Ｐ_ＣＯＭ１）は、攻撃者が悪意のある制御メッセージを注入できることを阻止する（表１の攻撃Ｃ）。最後に、パケットパス及びデータ検証（Ｐ_ＣＯＭ２）は、パケットを修正するローカル攻撃者を軽減する（表１の攻撃Ｄ）。

【表2】

【0052】

追加の実施形態では、アーキテクチャは、追加の特性をサポートするが、信頼できるアーキテクチャの基礎として本明細書に提示されているものに焦点を当てている。基本的な特性は、（１）実行中のコード及びデータの保護（Ｐ_ＳＷ）及び（２）通信の保護（Ｐ_ＣＯＭ）のうちの１つにグループ化することができる。これらを提供するための１つの手法がここで開示される。

【0053】

動的ミドルボックスのサポート

【0054】

理想的には、ＩｏＴデバイスの制御プレーンとデータプレーンの両方のコードベース全体を攻撃者から確実に保護することができる。しかしながら、これは、著しい性能コスト（例えば、各パケットを処理するための複数のエンクレーブ）を招くか、又は著しい再実装（例えば、Ｃ／Ｊａｖａの１０万＋ラインを移動する）を必要とするため、実用的ではない。代わりに、アーキテクチャの保護に影響を与えるコードベースの部分にきめ細かいセキュリティ特性が適用され、それによって敵対者に対するロバスト性がもたらされる。具体的には、定期的な遠隔証明を適用して、コードの完全性を保証する（Ｐ_ＳＷ２を提供する）。これにより、コードは、攻撃に対して脆弱な持続時間を制限しながら、最小限の性能低下で実行することができる。更に、重要なコード（例えば、セキュリティポリシー）をハイパーバイザ拡張で保護して、それを分離し、それへのアクセスを仲介することができる（Ｐ_ＳＷ１を提供する）。

【0055】

定期的な遠隔証明：ＩｏＴセキュリティゲートウェイは、デバイス固有の保護を提供するために大きなコードベースに依存している。信頼できるプラットフォームモジュール（ＴＰＭ）などの遠隔証明の従来の方法は、適切なソフトウェアスタックが実行されていることを正確に保証するために使用される（Ｐｓｗ２を提供する）。起動すると、マイクロハイパーバイザ、ＯＳ、及び重要なソフトウェアコンポーネント（例えば、コントローラ、ｖＳｗｉｔｃｈ、ミドルボックスなど）から構成される正しいベースラインソフトウェアスタックが検証される。

【0056】

その後、提供された保護に影響を与える新しいモジュール（例えば、ロード前の新しいミドルボックスのコード）が証明され、それによってアーキテクチャが正しい保護がインスタンス化されることを確実にすることを可能にする。

【0057】

実行時に、重要なモジュール（例えば、コントローラ、ｖＳｗｉｔｃｈ、ミドルボックス）が定期的に再証明され、それによって攻撃者がそれらを改ざんしていないことが保証される。例えば、ミドルボックスコードは、ハイパケットスループットを可能にするためにハイパーバイザの外部で実行されなければならない。攻撃者によるこのコードの改ざん（すなわち、保護が適用されていない）の潜在的な影響を制限するために、コントローラは、全てのエポックの終わりにゲートウェイ上の重要なソフトウェアコンポーネントを遠隔的に証明し、エポック期間は、脆弱なウィンドウの長さとセキュリティオーバーヘッドとの間のトレードオフを提供するように調整することができる。

【0058】

この証明能力を提供するために、マイクロハイパーバイザ上の仮想的な信頼できるプラットフォームモジュール（ｖＴＰＭ）が活用される。ｖＴＰＭは、物理ＴＰＭのソフトウェア実装であり、同じ機能の多くを提供する。具体的には、プログラム制御レジスタ（ＰＣＲ）を拡張することによって測定値のチェーンを安全に記憶し、それらの記憶された値（すなわち、ＰＣＲ見積書）を安全に提供するその能力が使用される。これら２つの機能は、ローカル又はリモートマシン上のソフトウェアスタックが既知の構成と一致するかどうかを決定することを可能にする。これらのｖＴＰＭ測定は、複数の測定のための別個の記憶装置を用いて、細かい粒度で適用することができる。

【0059】

コントローラのセキュリティポリシーの保護：証明は、コードの完全性に関する重要な保証を提供することができるが、更なる保護に値する幾つかのコードがある（例えば、セキュリティゲートウェイによって提供される保護に関する決定に影響を与えるコード）。マイクロハイパーバイザ手法は、このコード（Ｐｓｗ１）を選択的に分離し、それに対するアクセスが信頼できるエンティティ（Ｐｓｗ１）によって媒介されることを要求することを可能にする。そのようなコードの例は、プレーン間のセキュアな制御チャネル及びコントローラ上のセキュリティポリシーを確立するために使用される秘密鍵である。

【0060】

具体例として、コントローラのセキュリティポリシーを考える。セキュリティポリシーは、正しい保護が実施されることを保証するために重要である（例えば、それを変更すると、ゲートウェイのミドルボックスがＩｏＴデバイスを保護しなくなる可能性がある）。このコードは、コントローラから抽出され、（Ｐｓｗ１を提供する）マイクロハイパーバイザによって分離されたメモリに配置されることができる。更に、このメモリへのアクセスは、コントローラのコードのみがセキュリティポリシーにアクセスできることを保証するために、（Ｐｓｗ１を提供する）マイクロハイパーバイザのコードホワイトリストによって仲介される。

【0061】

この組み合わせは、オペレーティングシステムを制御している攻撃者が、既存のコードの大幅な変更を必要とせずに、マイクロハイパーバイザ保護されたコード片にアクセスして変更することを禁止する。

【0062】

セキュアかつ効率的な通信

【0063】

セキュリティアーキテクチャは、制御チャネル（コントローラとゲートウェイとの間、Ｐｃｏｍ１）とデータチャネル（ゲートウェイのパケット処理パスに沿う、Ｐｃｏｍ２）の両方で信頼保証を必要とする。マイクロハイパーバイザは、これらの通信チャネルを保護するための分離及び調停を提供するために使用される。

【0064】

セキュア制御チャネル：制御プレーンとデータプレーンとの間の通信は、これらのメッセージがゲートウェイによって提供されるセキュリティ保護に影響を与えることが多いため、信頼できることが重要である。このアーキテクチャは、コントローラとゲートウェイとの間の従来のトンネリング（例えば、ＩＰｓｅｃ／ＴＬＳ）によって提供される保証を強化して、危険にさらされたコントローラ又はゲートウェイがトンネルを介してなりすましメッセージを送信できないようにする（例えば、悪意のあるミドルボックス構成コマンド）。これらの通信を保護するために（Ｐｃｏｍｍ１）、マイクロハイパーバイザ内で動作する信頼できるエージェントペアがこれらの通信を仲介するために使用される（例えば、このチャネルを介してデータを送信するために必要な秘密鍵にアクセスする）。コントローラ上にエージェントがあり、ゲートウェイ上に対応するエージェントがあり、それらは共にセキュアチャネルへのアクセスを仲介する役割を果たす。

【0065】

セキュアデータチャネル：データプレーンでは、セキュリティ保護は、正しいミドルボックスによって処理されている各パケットに依存する。このアーキテクチャは、低いパフォーマンス・オーバヘッドで、ホップ毎の保証を提供する。具体的には、目標は、パケットが正しいパスをたどり、データプレーン上の正しい一連のミドルボックスによって処理されることを保証することである（Ｐｃｏｍ２）。各ミドルボックスとｖＳｗｉｔｃｈとの間に従来のトンネルを確立することができるが、これは、著しいオーバーヘッド及び処理遅延をもたらす。データチャネルを保護するべく、マイクロハイパーバイザは、各パケットの正しいパス（すなわち、ミドルボックスチェーン）を実施するために使用される。これは、マイクロハイパーバイザ符号を有し、各パケットをその処理パスに沿って検証し、検証に失敗したパケットをドロップすることによって達成される。この手法は、パケットが単一のホスト上に残り、ハイパーバイザが秘密鍵を維持することができるため、以前のホップごとの認証提案とは異なる。

【0066】

これらのデジタル署名は、ｖＳｗｉｔｃｈと各ミドルボックスとの間で共有される（マイクロハイパーバイザによって保護された）秘密鍵によって、生パケットデータとパケットを処理するミドルボックスとの間の接続を形成する。更に、秘密鍵は、マイクロハイパーバイザの仲介によってのみアクセス可能な隔離メモリに保持され、攻撃者が署名されたパケットを偽造するのを阻止するので、デジタル署名は信頼できる。

【0067】

モデル評価

【0068】

上記で開示されたＡｌｌｏｙモデルは、信頼できるアーキテクチャを反映し、その性能を分析するために更新された。アーキテクチャのモデルは、攻撃者が信頼特性に侵害し、有害パケット（すなわち、エクスプロイトを含むもの）を出力することを可能にするインスタンスについて調査された。

【0069】

Ａｌｌｏｙアナライザはカウンタ例を識別することができず、その結果、アーキテクチャは誤ったミドルボックスによって処理されたパケットを出力する。アナライザは、有界モデル検査（ＢＭＣ）を使用し、モデルは、モデル内の各シグの限界Ｎまで評価される。モデルは、１００（すなわち、各ｓｉｇの１００個のインスタンス）の境界までで評価され、必要なリソースは、解析をパーソナルコンピュータで実行できることを示している。

【0070】

更に、セキュリティサブプロパティに関連する制約が体系的に除去され（例えば、ミドルボックスソフトウェアは補正される必要がない）、それぞれが包括的なセキュリティ特性が侵害された反例をもたらすことが検証された。この分析は、アーキテクチャの設計におけるセキュリティ特性の信頼性を提供した。

【0071】

Ａｌｌｏｙモデルは、ニュアンスの特定を支援し、設計の改良を通知した。このモデルは、パケットがミドルボックスを完全にスキップすることを禁止する必要性を強調した。例えば、ミドルボックスが同じ鍵で入出力パケットに署名する場合、それはパケットが検出されることなくミドルボックスをバイパスすることを可能にする。同様に、Ａｌｌｏｙモデルは、アーキテクチャの動作を信頼するために、信頼されるか定期的に証明される必要があるソフトウェアコンポーネントを強調した。パケットを処理するミドルボックスだけでなく、仮想スイッチとコントローラソフトウェアの両方が、正しい動作を保証するために信頼される必要がある。

【0072】

実装

【0073】

ここで、例示的な実施形態を開示する。一実施形態では、ｘ８６及びＡＲＭプラットフォームの両方をサポートするｕｂｅｒＸＭＨＦオープンソースマイクロハイパーバイザが使用される。ＲａｓｐｂｅｒｒｙＰｉ３ハードウェアプラットフォームを使用して、ゲートウェイ上でｕｂｅｒＸＭＨＦマイクロハイパーバイザ、ＲａｓｐｂｉａｎＪｅｓｓｉｅ（Ｌｉｎｕｘ４．４．ｙについて）並びにＯｐｅｎＶｉｒｔｕａｌＳｗｉｔｃｈ及びＳｎｏｒｔを実行することができる。

【0074】

実装のソフトウェアスタックの高レベルの概要が図３に示されており、ハイパーバイザ拡張３０２は、「パケット署名」とラベル付けされた長方形として示されている。楕円３０４，３０６は、ハイパーバイザ保護動作（例えば、パケットのデジタル署名の生成／検証）を実行するためにコモディティソフトウェアに追加されたハイパーバイザ拡張３０２へのハイパーコールを表す。アーキテクチャ実装のこれらの要素は例示的なものにすぎず、実現されるように、他の要素を使用する実装も本発明の範囲内であると考えられる。

【0075】

仮想的な信頼できるプラットフォームモジュール（ｖＴＰＭ）：このアーキテクチャは、ハイパーバイザ対応のｖＴＰＭを活用して、周期的な遠隔証明を行なう。信頼できるプラットフォームモジュール（ＴＰＭ）の開発における重要な動機は、システムのブートシーケンスの健全性を遠隔的に証明する能力を提供することであった。ＴＰＭ規格によって提供される特徴のサブセットは、信頼特性、具体的にはＰＣＲ拡張及びＰＣＲ見積を提供するために活用される。追加のハードウェアを必要としないｖＴＰＭに加えて、このサブセットは、物理ＴＰＭを超える２つの重要な利点、ストレージの増加及び性能の向上を提供する。ｖＴＰＭ上の測定ストレージ（すなわち、ＰＣＲ）は、マイクロハイパーバイザによって保護されたプラットフォームのメモリ領域に基づいており、多数の別個の測定（例えば、単一の４ＫＢページ上の＞２００個のＰＣＲ）を可能にする。更に、これらの測定値は、システムバス（例えば、ＲａｓｐｂｅｒｒｙＰｉ３上のＳＰＩ）のデータレートによって制限されず、アクセス待ち時間が２０倍以上短縮される。ソフトウェアベースのＴＰＭの課題は、再起動にわたって秘密を保持することである。ｖＴＰＭは、既存のプラットフォーム不揮発性メモリを活用して、ブート間で秘密を保持する（例えば、ＲａｓｐｂｅｒｒｙＰｉ３は、長期的に安全なストレージとして機能することができるブートＮＶＲＡＭを有する）。

【0076】

一実施形態では、アーキテクチャは、プロバイダ（例えば、エッジＩＳＰ、ＣＤＮ、ＩｏＴプロバイダ）がＩｏＴコンシューマに提供することができる信頼できる「サービスとしてのセキュリティ」提供として実装することができ、正しいセキュリティ保護が常に適用されることを保証する。例えば、アーキテクチャは、ＩｏＴセキュリティの最良実施例（例えば、デバイスの製造業者の使用説明仕様におけるアクセス制御ポリシー）を実施するための信頼できるメカニズムを提供する。

【0077】

当業者には理解されるように、本明細書に記載の開示されたシステム及び方法は、プロセッサ及びメモリを備え、プロセッサによって実行されると、方法を含む機能を実行するソフトウェアを格納するシステムによって実施することができる。例えば、モデルの訓練、試験、及び配備は、プロセッサ上で実行されるソフトウェアによって実施することができる。

【0078】

当業者であれば更に分かるように、本発明の範囲内に含まれる本明細書で説明される実施態様の多くの変形が想定し得る。具体的には、モデルのアーキテクチャの多くの変形を使用して、同様の結果を得ることができる。本発明は、本明細書に開示される特定の典型的なモデルに限定されることを意味するものではない。更に、本明細書に記載の様々な実施形態の特徴は、相互に排他的ではなく、そのような組み合わせ又は置換が本明細書で明示されていなくても、本発明の精神及び範囲から逸脱することなく、様々な組み合わせ及び置換で存在することができることを理解すべきである。したがって、本明細書に開示される方法及び装置は、本発明に対する限定としてではなく、その例示として解釈されるべきである。本発明の範囲は、以下の特許請求の範囲によって規定される。

【図1】