JP2021057043A - トラストアンカコンピューティング装置を備える処理システムおよび対応する方法 - Google Patents

Abstract

【課題】トラストアンカコンピューティング装置を備える処理システムを提供する。【解決手段】実行時真正性チェック５００において、処理システムは、少なくとも実行のためにハードウェアトラストアンカのプログラムメモリ内に存在する署名済みソフトウェアブロックＳＳＢｊならびに対応するヘッダ及びデータブロックを識別する５０５と、各ＳＳＢｊについて、ＳＳＢｊに関連付けられた証明書の有効性をチェックする第１の段階５１０。ＳＢＢｊのヘッダの有効性をチェックする第２の段階５２０、ＳＳＢｊのデータのハッシュの有効性をチェックする第３の段階５３０を実行する。有効性チェックのチェックする段階５１０、５２０、５３０のうちの１つによって異常が検出された場合、検出された異常に関するセキュアログＳＬを書き込む５６０。【選択図】図４

Description

本説明は、ホスト処理ユニットおよびホストメモリ手段を含む少なくとも１つのホストコンピューティングモジュールとハードウェアトラストアンカとを備え、信頼できる操作を実行するように構成された処理システムに関する。少なくとも１つのホストモジュールとハードウェアトラストアンカとを備える処理システムは、特に上記少なくとも１つのホストモジュールが車両内で動作するＥＣＵである場合、システムオンチップの一部であることが好ましい。

ハードウェアトラストアンカ（ＨＴＡ）は、トラストチェーンを開始すると共に、システムに不可欠な機能と、スタートアッププロセスおよび不正操作が検出された場合のプロセスのシャットダウンの予防的なモニタリングを含むセキュリティ機能との両方を実行する、ローカルな隔離されたコンピューティングデバイスである。

一般的な自動車のシナリオにおいて、電子制御ユニット（ＥＣＵ）のような処理システムは、車両機能のためのアプリケーション処理ユニット、すなわち、アプリケーションコアと、セキュリティサポートのためのＨＴＡとから構成された、１つまたは複数のＳｏＣ（システムオンチップ）に基づくものである。したがって、ＥＣＵを外部からの攻撃（車両機能の認証されていないアクティベーション、慎重に扱うべきキー材料の読み出し、ソフトウェアの操作など）に対してハードニングするために、ハードウェアトラストアンカ技術（ＨＴＡ）が使用されている。

ＨＴＡは、ＨＴＡ側の基本的なセキュリティを高めるために使用されるメカニズムのセットが埋め込まれ、したがってセキュリティハードニングリアルタイムオペレーティングシステムと呼ばれる、リアルタイムオペレーティングシステム（ＲＴＯＳ）を使用する処理ユニットを含んでよい。コンピューティングにおいて、ハードニングとは通常、表層の脆弱性を低めることによってシステムのセキュリティを確保するプロセスである。

したがって、これらの保護技術は、より効果的に攻撃を検出／攻撃に反応し、それらの攻撃のエクスプロイトを実行する能力を制限するように構成されている。

ＨＴＡは、
・キー管理、
・証明書管理、
・暗号化演算、
・ソフトウェア保護（セキュアブートおよびセキュア更新）、
・慎重に扱うべきデータの読み取りおよび書き込みのためのアクセスメカニズムおよびデータの可視性を低めるための暗号化技術を用いたデータ保護（セキュアストレージおよびセキュア通信）、
などの、機密かつ慎重に扱うべき情報を伴うセキュリティ操作のために使用される。

したがって、その結果、セキュリティハードニングリアルタイムオペレーティングシステムは、
・複数のセキュア操作を同時に実行し、
・いくつかの所定のロジックおよびスケジューリングポリシに従って、様々なエンティティ（プロセスまたはタスク）の間で切り替え、
・機密性（情報の隔離）を保証および維持し、
・一般機能が実行されることおよびその実行時間が分かることを保証する、
ことが可能であるべきである。

ＨＴＡのために使用されるセキュリティハードニングリアルタイムオペレーティングシステムは、静的で変更不可能な動作環境であってよい。これはつまり、アプリケーションの実行中は、アプリケーションのオブジェクト、タスク、イベント、リソースを作成または削除できないことを意味する。セキュアシステムにおいては、データおよび他のメモリセクションの正確性（完全性）が基本的な要件であるべきである。

今日、ほとんどの自動車ＥＣＵは、アプリケーションソフトウェアまたはデータをいつでも更新可能であるように、ソフトウェアのダウンロードをサポートしている。ＯＥＭ要件に応じて、新しいソフトウェアが有効であることを保証するためにソフトウェアのダウンロード中に、ソフトウェアが依然として有効であることを保証するためにＥＣＵの電源オン中に、またはこれら２つの組み合わせで、いくつかのチェックが実行される。有効性情報をハンドリングするための種々の方法が存在する。

例えば、通常安全性の理由で要求される、完全性チェックが行われてよい。完全性チェックは、不揮発性ソフトウェアデータにわたって計算され、基準値と比較される、チェックサム／ＣＲＣ（巡回冗長検査）に基づくものである。チェックサムが正しければ、全ソフトウェアブロックの完全性が想定される。ところで、ＣＲＣのようなチェックサムアルゴリズムは、チェックサムの計算時に秘密パラメータが関与しないので、真正性チェックを提供するものではない。

そのような真正性チェックは、その代わりに、（例えば、セキュリティ関連ＥＣＵにおいてまたは調整保護として）正当なソースからのソフトウェアまたはデータのみがＥＣＵにおいて使用されることを要求するいくつかのＥＣＵによって要求される。認証は、不揮発性ソフトウェアデータにわたる暗号署名の計算によって通常実行される。署名は、ＯＥＭまたはＥＣＵいずれかの供給業者によって供給され得る。

署名計算アルゴリズムは、ダウンロードされたソフトウェアの完全性および真正性を確実にするために、モジュール１２２ａ〜１２２ｅにおいて実行されるもののようなハードウェアベースの、またはソフトウェアベースの、ハッシュ計算と暗号化ルーチンとを組み合わせたものである。上記ハードウェアトラストアンカ（ＨＴＡ）がモジュール１２２ａ〜１２２ｂを含まないか、またはそれらのうちのサブセットのみを含む場合、コンピュテーションはソフトウェアにおいて実行され、暗号化演算を実行するために特別なハードウェアは必要とされない。上記の方法は、実行時に有効性情報をチェックするためにも使用することができる。

現在、単に安全性要件を満たすために、完全性チェックのみが実行時に使用されている。しかし依然として、このような方法では、ＥＣＵ自体の通常の動作中に元のＥＣＵに対する操作を検出することはできない。

［目的および概要］
１つまたは複数の実施形態の目的は、先行技術により達成可能な解決策に内在する制限を解消することである。

１つまたは複数の実施形態によれば、この目的は、請求項１に規定された特徴を有するシステムによって達成される。１つまたは複数の実施形態は、対応するシステムに関するものであってよい。

特許請求の範囲は、様々な実施形態に関連して本明細書に提供された技術的教示の必須の部分をなす。

本明細書に記載される解決策によれば、解決策は、ホスト処理ユニットおよびホストメモリ手段を含む少なくとも１つのホストコンピューティングモジュールと、ハードウェアトラストアンカとを備える、信頼できる操作を実行するように構成された処理システムであって、上記ハードウェアトラストアンカは、それぞれのセキュア処理ユニットと、暗号化演算に専用のハードウェア処理モジュールと、セキュアストレージ手段とを備え、上記ハードウェアトラストアンカは、リアルタイムセキュアオペレーティングシステムを格納し実行するように構成され、上記リアルタイムセキュアオペレーティングシステムは、上記処理システムにおいて使用されているソフトウェア上で有効性チェックを実行するように構成され、上記リアルタイムセキュアオペレーティングシステムは、実行時にソフトウェアコードの完全性を制御する実行時真正性チェックを実行するように構成され、上記実行時真正性チェックは、少なくとも実行のために少なくとも上記ハードウェアトラストアンカのプログラムメモリ内に存在する、また最終的には上記ホストコンピューティングモジュールのプログラムメモリ内にも存在する、署名済みソフトウェアブロックならびに対応するヘッダおよびデータブロックを識別する段階と、各署名済みソフトウェアブロックについて、上記署名済みソフトウェアブロックに関連付けられた証明書の有効性をチェックする第１の段階、上記署名済みソフトウェアブロックのヘッダの有効性をチェックする第２の段階、上記署名済みソフトウェアブロックのデータのハッシュの有効性をチェックする第３の段階、を実行する段階と、上記有効性チェックのチェックする段階のうちの１つによって異常が検出された場合、上記検出された異常に関するセキュアログ情報を書き込む段階と、を含み、上記リアルタイムセキュアオペレーティングシステムは、他のホストコンピューティングモジュールまたはハードウェアトラストアンカのサービスに対して最優先されるタスクにおいて上記実行時真正性チェックを実行するように構成される、システムに関する。

また、本明細書に記載される解決策は、上記処理システムにおいて使用されているソフトウェア上で有効性チェックを実行するリアルタイムセキュアオペレーティングシステムを格納し実行することを含む、上記処理システムにおいて信頼できる操作を実行する対応する方法であって、上記方法は、実行時にソフトウェアコードの完全性を制御する実行時真正性チェックを実行する段階を含み、上記実行時真正性チェックは、実行のために上記ハードウェアトラストアンカのプログラムメモリ内に存在する、また最終的にはホストコンピューティングモジュールのプログラムメモリ内にも存在する、署名済みソフトウェアブロックならびに対応するヘッダおよびデータブロックを識別する段階と、各署名済みソフトウェアブロックについて、上記署名済みソフトウェアブロックに関連付けられた証明書の有効性をチェックする第１の段階、上記署名済みソフトウェアブロックのヘッダの有効性をチェックする第２の段階、上記署名済みソフトウェアブロックのデータのハッシュの有効性をチェックする第３の段階、を実行する段階と、上記有効性チェックのチェックする段階のうちの１つによって異常が検出された場合、上記検出された異常に関するセキュアログ情報を書き込む段階と、を含み、上記リアルタイムセキュアオペレーティングシステムは、他のホストコンピューティングモジュールまたはハードウェアトラストアンカのサービスに対して最優先されるタスクにおいて上記実行時真正性チェックを実行するように構成される、方法に関する。

以下、添付図面を参照しながら単に非限定的な例によって実施形態を説明する。
本明細書に開示された処理システムの一実施形態を概略的に示す図である。 本明細書に開示された処理システムによって使用されるメモリのアドレス空間を概略的に示す図である。 本明細書に開示された処理システムによって使用されるメモリのメモリエリアを概略的に示す図である。 本明細書に開示された処理システムによって実装される真正性チェック手順のフロー図である。 本明細書に開示された処理システムの複数の操作フェーズを表すタイミング図である。 本明細書に開示された処理システムのメモリのスタックのブロック図である。 本明細書に開示された処理システムによって実装されるスタックオーバーフロー制御手順のフロー図である。 本明細書に開示された処理システムによって実装される検出手順のフロー図である。

以下の記載は、実施形態の深い理解をもたらすことを目的とした様々な具体的な詳細を説明するものである。実施形態は、具体的な詳細のうちの１つまたは複数を伴わずに実装されてもよいし、または他の方法、構成要素、材料などと共に実装されてもよい。他の場合において、既知の構造、材料または操作は、実施形態の様々な側面を不明瞭にしないように、詳細には図示または説明されない。

本説明の枠組みにおいて、「一実施形態」または「１つの実施形態」への言及は、その実施形態に関連して記載された特定の形態、構造または特性が、少なくとも１つの実施形態に含まれることを示すことを意図している。同様に、本説明の様々な箇所に存在し得る「一実施形態において」または「１つの実施形態において」などの語句は、必ずしも１つの同じ実施形態を指すものではない。さらに、特定の形態、構造または特性は、１つまたは複数の実施形態において適切に組み合せることができる。

本明細書において使用される参照符号は、単に便宜上のものとして意図されており、したがって、保護範囲または実施形態の範囲を画定するものではない。

図１には、例えば、車両のエンジンの制御系統または他の機能部における、例えば、自動車用途のＳｏＣ上のＥＣＵに対応することができる処理システム１０が示されており、処理システム１０は、アプリケーション処理ユニット、すなわちアプリケーションコア１１と、ハードウェアトラストアンカ（ＨＴＡ）１２とを備える。アプリケーションコア１１は、不揮発性メモリ１１１と、ＲＡＭメモリ１１２と、例えば、車両バスと通信するためのバスインターフェース１１４と、アプリケーションＣＰＵ１１３とを備える。ＨＴＡ１２は、セキュア不揮発性メモリ１２１ｂおよびセキュアＲＡＭメモリ１２１ａを含むセキュアストレージ１２１を備える。ＨＴＡ１２は、セキュア処理ユニット１２３と、ＨＴＡインターフェースモジュール１２４と、暗号化ハードウェアアクセラレーションモジュール１２２とをさらに備え、暗号化ハードウェアアクセラレーションモジュール１２２は、ソフトウェアデータのハッシュ値をコンピュートするためのハッシュエンジン１２２ａと、対称暗号アルゴリズムを実行するための対称暗号エンジン１２２ｂおよび非対称暗号アルゴリズムを実行するための非対称暗号エンジン１２２ｃと、ＴＲＮＧおよび／またはＰＲＮＧを含んでよいランダム生成器モジュール１２２ｄと、カウンタモジュール１２２ｅとを含んでよい。

セキュリティハードニングリアルタイムオペレーティングシステムソフトウェアは、それ自体はソフトウェアであり、メモリすなわち下記のセクションにおいて図２に示されるようなセキュアストレージ１２１内に、通常は分割されている。図２は、ＨＯＳと共にまとめて示されているオペレーティングシステムが存在する、ＨＴＡ１２のメモリ１２１のアドレス空間を概略的に示している。
−テキストまたはソースコードＴＸＳ：プログラムの実行可能コードを格納するメモリエリア。メモリのこのブロックは、通常は読み取り専用である。
−データまたはデータフラッシュＤＴ：プログラマによって初期化された静的／グローバル変数を格納するメモリエリア。これは、さらには、ＯＳアプリケーションがプライベートデータを有することができるメモリのセクションである。

ＢＳＳ（Ｂｌｏｃｋ Ｓｔａｒｔｅｄ ｂｙ Ｓｙｍｂｏｌ）メモリＢＳ：初期化されていない静的／グローバル変数を格納するメモリエリア。このセグメントは、オペレーティングシステムによってゼロで満たされ、したがって、全ての初期化されていない変数がゼロで初期化される。ヒープメモリＨＰ：ヒープは、ダイナミックメモリアロケーションのための空間を提供するのに使用される。

スタックＳＳ：これは、ｒｅｔｕｒｎなどの関数呼び出しに関連する機能部、レジスタおよびデータ内で定義されたローカル変数が、タスク実行中にプッシュされる揮発性メモリ（ＲＡＭ）１２１ａのセクションである。各タスクは、固有のスタックエリアを有することができる。

テキストメモリエリアＴＸＳおよびデータメモリエリアＤＴは、不揮発性メモリ１２１ｂであり、それに対して、ＢＢＳメモリエリアＢＳ、ヒープメモリエリアＨＰ、およびスタックＳＳは、揮発性メモリ１２１ａである。

本明細書に記載されるＨＴＡのためのセキュリティハードニングリアルタイムオペレーティングシステムは、
−真正性の特性が暗号を介してチェックされる、不揮発性メモリのための実行時真正性チェック手順５００、
−使用されたスタックＳＳの量が静的境界に対してチェックされる、スタックＳＳ（揮発性メモリ１２１ａ）のためのスタックオーバーフロー検出手順６００、
を含む様々な特定の手順を通して、不揮発性メモリおよび揮発性メモリをチェックするように構成される。

実行時真正性チェック手順５００は、実行時に制御下のコードの完全性を維持することからなる、真正性方法に基づくハードニング技法である。これは、スタートアップを含む通常のシステム動作と並行に行われ、真正性がトラストルートから開始して検証され、他の時には、外部イベント（コードの一部の更新など）に関係し得る頻度で、または所定の定期的メカニズムで、またはＨＴＡの非アクティブ時間を利用して、実行することができる。

このようにして、ハードニングリアルタイムオペレーティングシステムは、侵入されたシステムが、それ自体のメモリ内容に不正を行うのを防止する。

このハードニング技法は、図１に示されるように、ＨＴＡが、ＥＣＵのフラッシュメモリへのフルアクセスを有する１つの追加のコアとして得られていることを利用する。結果として、単に上記ハードウェアトラストアンカ不揮発性メモリをチェックするために開発された実行時真正性チェック手順５００は、ホストコア上で実行されている安全性に不可欠なアプリケーションにいかなる影響または遅延も生じさせることなく、フラッシュメモリ全体のコード完全性を実証するように構成することができる。

この理由で、また説明を一般化するために、本明細書では、実行時真正性チェック手順５００は、フラッシュメモリ全体をチェックするように構成されたものと想定されている。

実行時真正性チェック手順５００は、署名済みＳＷブロックに基づく検証メカニズムと、証明書とを使用する。

ホスト１１の不揮発性メモリ１１１およびＨＴＡ１２の不揮発性メモリ１２１ｂを概略的に示す図３に示すように、署名済みＳＷブロックＳＳＢ、すなわちデータの真正性および完全性を提供するデジタル署名が付与されたソフトウェアブロックは、ホスト１１およびハードウェアトラストアンカ１２の不揮発性メモリ１１１および１２１ｂ、特にフラッシュメモリ内のプログラムメモリにそれぞれ格納され、証明書Ｃと、最終的には、下記でより良く説明される検出された異常についての情報を与えるセキュアログＳＬとは、例えば、プログラムフラッシュメモリおよびデータフラッシュメモリを含む、全ての慎重に扱うべきデータ（例えば、キー）を格納するためにも使用されるセキュアストレージ１２１内の不揮発性メモリ１２１ｂに格納される。

署名済みＳＷブロックＳＳＢは、ハードウェアトラストアンカ１２のフラッシュメモリにプログラムされた、また最終的にはホスト１１、具体的にはＥＣＵにもプログラムされた、バイナリデータに対応する。

ＥＣＵには、いくつかの署名済みＳＷブロックＳＳＢが存在する。ホストおよびＨＴＡはどちらも、プログラムフラッシュメモリおよびデータフラッシュメモリを含むそれぞれの不揮発性メモリを有し、したがって、ＳＳＢは、ホストおよびＨＳＭに分散されてよい。ホストおよびＨＴＡは、異なる時間に実行され、異なる目的を有する。例えば、ホストのフラッシュメモリにおいて、ブートローダＢＬ：いずれのアプリケーションコードの前に実行される１つのコードである。アプリケーションＡＰＰ：ブートローダの後に実行される１つのコードである。

キャリブレーションＣＬＢ：アプリケーションが適切に動作するために必須のデータを含む１つのコードである。ハードウェアトラストアンカのフラッシュメモリにおいて、ブート：いずれのオペレーティングシステムが動作する前に実行される１つのコードである。

アプリケーションＡＰＰ：オペレーティングシステムが動作した後に実行される１つのコードである。この１つのコードは、リアルタイムオペレーティングシステムを含んでよい。

各署名済みＳＷブロックＳＳＢは、ヘッダＳＳＢＨおよびデータＳＳＢＤという２つのセクションを有するメタデータと呼ばれるある情報と関連付けられる。
−ヘッダＳＳＢＨフィールドは、ブロックの内容および全ての暗号ハッシュおよび署名についての情報を含み、
−データＳＳＢＤフィールドは、真正性および完全性の証明が必要と判定されたデータのブロックである。

証明書（またはデジタル証明書）は、通信目的ならびに所有権および有効性を証明するのに使用されるカプセル化されたパブリックキーである。証明書は、証明書の内容の信頼性を伝えるために、認証機関によって署名されている。

証明書は、非限定的な例によれば、Ｘ．５０９ｖ３証明書に準拠し、ＡＳＮ．１ ＤＥＲフォーマットにエンコードされている。

例えば、ＥＣＵの観点から最高位の証明書を表し、別の証明書に対して有効性を確認され得ない、ＨＴＡにおけるルート証明書が存在し得る。ＥＣＵの観点から中間の証明書を表し、このようなルート証明書に対して有効性を確認される、ホストにおいて実行されているアプリケーションソフトウェアおよびホストソフトウェア自体（例えば、ブートローダ）の証明書が存在する。

一般的に、実行時真正性チェック手順５００は、ホストによって要求される他の実行時サービスと干渉しないようにＨＴＡ１２に実装された低優先度タスク（すなわち、バックグラウンドタスク）である。特に、実行時真正性チェック手順５００は、それらの実行について許容された遅延を超えるべきでない。

しかしながら、ＨＴＡ１２に多数の操作を要求する攻撃者または要求が過度に厳しいホスト１１が実行時真正性チェック５００の実行を妨げる可能性も回避するとともに、ソフトウェアの不正操作を検出することが必要である。同時に、フラッシュ全体を検証する時間が所定の値を超えることを回避しなければならない。

これらの正反対のビジョンを融合させるために、実行時真正性チェックは、他のホスト／ＨＴＡのサービスに対して最優先される定期的なタスクにおいて実行され、チェックは、構成可能な持続時間のｎ個の段階に分割される。図４には、実行時真正性チェック手順５００を示すフロー図が示されている。

実行時真正性チェック５００は、段階５０５にて、実行のために上記ハードウェアトラストアンカ１２のプログラムメモリ内に存在し、また最終的にはホスト１１のプログラムメモリ１１１内にも存在する、署名済みソフトウェアブロックＳＳＢならびに対応するヘッダＳＳＢＨおよびデータブロックＳＳＢＤを識別する段階と、段階５１０にて、各署名済みソフトウェアブロックＳＳＢｊ（ｊは、識別される署名済みソフトウェアブロックＳＳＢのゼロから数Ｎまでの署名済みブロックの識別インデックスである）について、各署名済みＳＷブロックＳＳＢに関連する各証明書Ｃの有効性のチェックを実行する段階とを含む。各証明書の有効性のチェックは、ＨＴＡ１２に格納されることになる任意の新たな証明書が、自己署名証明書でない限り、ＨＴＡ１２に格納された別の証明書に対して検証されなければならないことを含む。

次に、段階５２０にて、現在の署名済みＳＷブロックＳＳＢｊ、ＨｅａｄｅｒＳｉｇｎａｔｕｒｅのヘッダ署名フィールドＳＳＢＨが検証され、これにより、ブロックのヘッダの内容の真正性および完全性を保証する。このフィールドは、ヘッダの始点からその長さにわたってデジタル署名を含む。

次に、段階５３０にて、現在の署名済みＳＷブロックコードＳＳＢｊブロックハッシュが検証される。現在の署名済みＳＷブロックコードのヘッダ内のファイルダイジェストフィールドは、データブロックにわたって計算された適合ＳＨＡ−２５６ダイジェストを規定し、チェックは、ファイルダイジェストフィールドが、特に暗号化ハードウェアアクセラレーションモジュール１２２内のデータブロックにわたって実行時真正性チェックによって、特にハッシュ値をコンピュートするためのハッシュエンジン１２２ａによって計算された適合ＳＨＡ−２５６ダイジェストに等しい場合にのみ、合格となる。

チェックする段階５１０、５２０または５３０において異常が検出された場合、段階５５０にて、チェック中にＳＳＢに関してセキュアログＳＬが既に作成されているかがチェックされる。否であれば、段階５６０にて、ＨＴＡ１２のデータメモリ（不揮発性メモリ１２１ｂ）内にセキュアログＳＬが作成され、その中に、検出された異常についての情報が書き込まれる。すなわち、セキュアログ記録が呼び出され、そうでなければ、既に作成されたセキュアログＳＬが更新される。一般に、このような有効性のチェック段階５１０、５２０、５３０のうちの１つが異常を検出したら、検出された異常に関するセキュアログＳＬ情報の書き込みが実行される。

図５には、ホスト１１によりＨＴＡ１２に対して要求されるサービスの実行の持続時間ＤＨを所与として、認証手順５００の一部が持続時間のインターバルＤＲの間に実行されることを示す時間図が示されている。期間Ｔは、様々なホストサービスのサービス持続時間ＤＨを含むような長さを有する。

したがって、すぐ上で説明したように、一実施形態において、信頼できる操作を実行するように構成された処理システム１０は、ホスト処理ユニット１１３ならびに例えば揮発性および不揮発性のホストメモリ手段１１１、１１２を含む、少なくとも１つのホストコンピューティングモジュール１１と、ハードウェアトラストアンカ１２とを備える。ハードウェアトラストアンカ１２は、それぞれのセキュア処理ユニット１２３と、暗号化演算に専用のハードウェア処理モジュール１２２と、セキュアストレージ手段１２１とを含む。ここで、ハードウェアトラストアンカ１２は、リアルタイムセキュアオペレーティングシステムＨＯＳを格納し実行するように構成される。リアルタイムセキュアオペレーティングシステムＨＯＳは、処理システム１０において使用されているソフトウェア上で有効性チェックを実行するように構成される。上記セキュアオペレーティングシステムは、具体的には、実行時のソフトウェアコードの完全性を制御する実行時真正性チェック５００を実行するように構成される。上記実行時真正性チェック５００は、少なくとも実行のために上記ハードウェアトラストアンカコンピューティングモジュール１２のプログラムメモリ、すなわち不揮発性メモリ１２１ｂ内に存在する、また最終的にはホストのプログラムメモリ、すなわち不揮発性メモリ１１１内にも存在する、署名済みソフトウェアブロックＳＳＢならびに対応するヘッダＳＳＢＨおよびデータブロックＳＳＢＤを識別する段階５０５と、各署名済みソフトウェアブロックＳＳＢについて、上記署名済みソフトウェアブロックＳＳＢに関連付けられた証明書Ｃの有効性をチェックする第１の段階５１０、上記署名済みソフトウェアブロックＳＳＢのヘッダＳＳＢＨの有効性をチェックする第２の段階５２０、上記署名済みソフトウェアブロック（ＳＳＢ）のデータＳＳＢＤのハッシュの有効性をチェックする第３の段階５３０を実行する段階と、および、このような有効性をチェックする段階５１０、５２０、５３０のうちの１つによって異常が検出された場合、検出された異常に関するセキュアログＳＬ情報を書き込む段階、すなわち、検出された異常に関する情報を含むセキュアログＳＬを作成する段階、または、このようなセキュアログＳＬに異常を書き込む段階と、を含む。セキュアオペレーティングシステムＨＯＳは、他のホスト１１またはハードウェアトラストアンカ１２のサービスに対して最優先されるタスクＰＬにおいて上記実行時真正性チェック５００を実行するように構成される。処理システム１０は、言及したようなスタックオーバーフロー検出手順６００も実施する。

同時に実行が必要な複数のスケジュール可能エンティティをハンドリングするために、オペレーティングシステムは、マルチプロセッシングを実装する。プロセス（またはセキュアハードニングリアルタイムオペレーティングシステム内のタスク）は、独立したスケジュール可能コードのシーケンスを含む独立した実行スレッドである。セキュアハードニングリアルタイムオペレーティングシステムを確立するこれらのエンティティは、パフォーマンス（時間およびメモリオーバーヘッド）を犠牲にして、ＣＰＵ実行時間を得るために独立して競合し得る。各タスクは、関数呼び出しに関連する機能部、レジスタおよびデータ内で定義されたローカル変数を格納する揮発性メモリの固有の専用エリアを有する。

スケジューラは、１つのタスクの実行から別のタスクの実行に切り替えることを望む場合、古いタスクのコンテキストを保存し、新たなタスクのコンテキストをロードしなければならない。タスクのコンテキストは、タスクが使用するレジスタ（プログラムカウンタ、スタックポインタ、他の作業レジスタ）のセットである。特に、このレジスタのうちの１つ（スタックポインタ）は、現在使用されているスタック領域に対するポインタである。システムの正しい動作のためには、異なるスタック領域間で干渉がないことを確実にすることが不可欠である。スタックの干渉は、悪意のあるユーザによる攻撃を受けている車両に頻発することで有名なので、この側面はセキュリティの観点から重要である。

不揮発性メモリ内のコードおよびデータの一部の完全性チェックは、揮発性メモリに関して常に可能ではない。メモリのそれらの部分に含まれるデータは、プロセスの実行中、継続的に修正されるので、データの完全性を検証するのではなく、プロセスによって使用されているメモリ領域が事前に確立された境界を超えないことをチェックすることが好ましい。

図６には、セキュア処理ユニット１２３のバンクレジスタＲと、ＲＡＭメモリ１２１ａとが示されている。ＲＡＭメモリ１２１ａ内には、プロセススタックＰＳＳおよびメインスタックＭＳＳを含むスタックＳＳが示されている。知られているように、プロセススタックまたはタスクスタックは、一般的に、リターンアドレス、プロシージャの引数、一時退避レジスタ、およびローカルに割り当てられる変数のために使用される事前予約されたシステムメモリのエリアである。処理ユニットは、一般的に、スタックポインタＳＴＰによってスタックの上部を指し示すレジスタ、すなわちＣＰＵレジスタＲを含む。

図示のように、プロセススタックＭＳＳ内には、それぞれのスタックサイズＴＳＳを有する第１のタスクＴＡの第１のスタックＳＳＡおよび第２のタスクＴＢの第２のスタックＳＳＢが存在し、スタックサイズＴＳＳは、プロセススタックＭＳＳ内の対応するスタック範囲を規定する。図に示されているように、第１のタスクＴＡの第１のスタックＳＳＡおよび第２のタスクＴＢの第２のスタックＳＳＢの両方における、例えば最後の８／１６バイトに対応する、スタック範囲の最後の部分は、スタックパターンＳＰを表す。これについては、図７のフロー図を参照しながら説明する。

タスク動作の変更中、オペレーティングシステムは、どのタスクがタスクまたはスケジューラテーブルを用いて実行されているかを追跡する方法を必要とする。この場合、それには３つのルーチンが必要とされる。
−図６に示すように、コンテキストスイッチを実行し、ＣＰＵ内に存在する退出タスクレジスタ、すなわち第１のタスクＴＡのタスクレジスタが、第１のタスクＴＡのスタックエリアＳＳＡ内に保存され、次に、進入タスクレジスタ、すなわち第２のタスクＴＢのタスクレジスタがＣＰＵレジスタ内の第２のタスクＴＢのスタックエリアＳＳＢからリロードされ、
−システムを初期化して、セキュアリアルタイムオペレーティングシステムを構成する状態マシンおよび内部構造を更新し、
−新たなタスク、すなわち第２のタスクＴＢにジャンプする。

プロセスおよびシステム実行の完全性を保証するために、タスクオーバーフロー制御のメカニズム、すなわちスタックオーバーフロー検出手順６００を実行することが必要である。スタックオーバーフロー検出手順６００もまた、有効なスタック領域の境界が上書きされていないことを検証する。スタックオーバーフロー検出手順６００は、図７のフロー図に示されている。

段階６１０にて、タスク、例えば、ＴＡ、ＴＢに割り当てられたスタック、例えば、ＳＳＡ、ＳＳＢは、既知のパターン、すなわちシステムおよびタスクが初期化された時点でのスタックパターンＳＰで満たされる。

次に、すべてのコンテキストスイッチの間に、オペレーティングシステムは、有効スタック範囲内の最後の部分、例えば、最後の８／１６バイトをチェックし（６２０）、このパターンが変更されていないままである（上書きされていない）ことを確実にする。

テスト段階６２０にて、これらのスタックの最後の部分のバイトがいずれも元の値から変更されていないことが検証された場合、段階６３０にて、スタックオーバーフローフック機能が呼び出される。このようなスタックオーバーフローフック機能は、異常を捕捉し、エラーコードを提起する（６４０）と共に、段階５５０と同様に異常イベント、すなわち異常を好ましくは同じログＳＬに記録して（６５０）、オペレーティングシステムに対して異常をはっきりと示す。

手順６００は、エラーを捉え、すなわちエラーを提起し、異常、すなわちほとんどのスタックオーバーフローの発生をログ記録するが、例えば、最後のバイトが書き込まれずにスタックオーバーフローが発生した場合、そのうちいくつかは見逃され得ることが想定される。

システム１０は、ＨＴＡ１２の機能時間内での実行を保証するために、リアルタイム検出手順７００を実行するようにも構成される。このような手順７００は、タスク実行をモニタして、時間が割り当てられたタイムバジェット（最悪実行時間）を超えた場合に反応する。

このメカニズム制御および実行時真正性チェックは、大きなタイムスケールでは、完全性分析が実行されたことを検証するが、小さなタイムスケールの場合には、ＨＯＳタスクにマッピングされた全てのセキュリティ機能が実行され、時間内に実行されたことを検証する。

システムの分析および設計の間、リアルタイムでのコードの実行を保証するために、システムがタスクをスケジューリングすることおよびハードリアルタイムの要件の非違反を可能にするように最大持続時間（タイムバジェット）が各タスクに割り当てられている。これらの実行時間の検証は、タスクの実行中、システムによってリアルタイムで実行され、違反の可能性が検出されたら、補正およびログ記録の操作を起こすことができる。

実行するようにスケジュールされた時間と終了／応答時間との間に規定される定期的なタスクＴＫは、３つのパラメータＣ、Ｄ、Ｔによって規定される。ここで、Ｃは最悪実行時間（ＷＣＥＴ）またはリソースタイムバジェット、すなわちコンピューティング時間を示し、Ｄは、相対デッドライン、すなわちデッドライン時間であり、Ｔは、期間（時間期間）である。

同じタスクの２つの連続するジョブインスタンスの間に複数の期間が存在する散発的なタスクシステムを検討すると、特定の時間に発生するジョブは、せいぜい、対応するデッドラインＤの前の時間間隔におけるＣの時間単位の間に実行されなければならない。

散発的なタスクの特定の事例としては、タスクによって生成された２つの連続するジョブの到着の間でその期間が正確に時間的に分離されている定期的なタスクである。

各インスタンスついてデッドラインＤが期間Ｔに対応する、絶対的デッドラインシステムと、
各場合についてデッドラインＤが期間Ｔ未満である、制約付きデッドラインシステムと、
デッドラインＤと期間Ｔとの間に制約がない、恣意的デッドラインシステムと、
が区別される。

処理システム１０は、図８のフロー図を参照しながら本明細書において説明される時間検出手順７００を実行するように構成される。ここで、デッドラインＤおよび期間の間に制約は存在しないが、タスク最悪実行時間Ｃについて一般タスクＴＫの違反をチェックする段階７１０が実行される。ここで、所与の例の最悪実行時間Ｃの値は、オフライン時間解析によって与えられる。段階７２０にて、異常が、好ましくは同じセキュリティログＳＬに記録される。したがって、上記の説明から、記載された解決策の利点が明らかである。

説明されたシステムは、セキュアハードニングリアルタイムオペレーティングシステムを好都合に備え、ここで、実行時にオペレーティングシステムソフトウェア上またはアプリケーションソフトウェア上のいずれかで真正性チェックを実行することによって、セキュアハードニングが得られる。真正性チェックは、定期的に高優先度を用いて、暗号および証明書有効性確認に専用ハードウェアを利用することにより、リアルタイムで実行される。

特に、本明細書に開示されたシステムは、他のホスト／ＨＴＡのサービスに対して最優先される定期的なタスクにおいて認証手順を実行することによって、ＨＴＡに対して多数の動作を要求する攻撃者または要求が過度に厳しいホストが実行時真正性チェックの実行を妨げる可能性も回避するとともに、ソフトウェアの不正操作を検出する。同時に、フラッシュ全体を検証する時間が所定の値を超えることが回避される。

当然ながら、実施形態の原理に影響を与えることなく、以下の特許請求の範囲に規定された本実施形態の範囲から逸脱しなければ、構成の詳細および実施形態を単に例として本明細書に説明および図示されたものに対して広く変更してよい。

Claims (13)

1. ホスト処理ユニットおよびホストメモリ手段を含む少なくとも１つのホストコンピューティングモジュールと、ハードウェアトラストアンカとを備える、信頼できる操作を実行するように構成された処理システムであって、前記ハードウェアトラストアンカは、それぞれのセキュア処理ユニットと、暗号化演算に専用のハードウェア処理モジュールと、セキュアストレージ手段とを備え、前記ハードウェアトラストアンカは、リアルタイムセキュアオペレーティングシステム（ＨＯＳ）を格納し実行するように構成され、前記リアルタイムセキュアオペレーティングシステム（ＨＯＳ）は、前記処理システムにおいて使用されているソフトウェア上で有効性チェックを実行するように構成され、
   前記リアルタイムセキュアオペレーティングシステム（ＨＯＳ）は、実行時にソフトウェアコードの完全性を制御する実行時真正性チェックを実行するように構成され、前記実行時真正性チェックは、少なくとも実行のために前記ハードウェアトラストアンカのプログラムメモリ内に存在する署名済みソフトウェアブロック（ＳＳＢ）ならびに対応するヘッダ（ＳＳＢＨ）およびデータブロック（ＳＳＢＤ）を識別する段階と、
   前記署名済みソフトウェアブロック（ＳＳＢ）に関連付けられた証明書（Ｃ）の有効性をチェックする第１の段階、
   前記署名済みソフトウェアブロック（ＳＢＢ）のヘッダ（ＳＳＢＨ）の有効性をチェックする第２の段階、
   前記署名済みソフトウェアブロック（ＳＳＢ）のデータ（ＳＳＢＤ）のハッシュの有効性をチェックする第３の段階、
   を実行する段階と、
   前記有効性チェックのチェックする段階のうちの１つによって異常が検出された場合、前記検出された異常に関する情報をセキュアログ（ＳＬ）に書き込む段階と、
   を含み、
   前記リアルタイムセキュアオペレーティングシステム（ＨＯＳ）は、他のホストコンピューティングモジュールまたはハードウェアトラストアンカのサービスに対して最優先されるタスク（ＰＬ）において前記実行時真正性チェックを実行するように構成される、システム。
2. 前記実行時真正性チェックは、前記ホストコンピューティングモジュールの不揮発性メモリ内に存在する前記署名済みソフトウェアブロック（ＳＳＢ）にも適用される、請求項１に記載のシステム。
3. 前記リアルタイムセキュアオペレーティングシステム（ＨＯＳ）は、他のホストコンピューティングモジュールまたはハードウェアトラストアンカのサービスに対して最優先される所与の期間（Ｔ）を有する定期的なタスク（ＰＬ）において前記実行時真正性チェックを実行するように構成され、前記チェックする段階は、各期間（Ｔ）に実行される構成可能な持続時間（ＤＨ）の複数のサブ段階に分割される、請求項１または２に記載のシステム。
4. 前記署名済みソフトウェアブロック（ＳＳＢ）に関連付けられた証明書（Ｃ）の有効性をチェックする前記第１の段階は、前記ハードウェアトラストアンカに格納されることになる任意の新たな証明書が、自己署名証明書でない限り、前記ハードウェアトラストアンカに格納された別の証明書に対して検証されることを含む、請求項１に記載のシステム。
5. 前記署名済みソフトウェアブロック（ＳＳＢ）のヘッダ（ＳＳＢＨ）の有効性をチェックする前記第２の段階は、現在の前記署名済みソフトウェアブロック（ＳＢＢ）のヘッダ署名フィールドを検証する段階を含む、請求項１に記載のシステム。
6. 前記署名済みソフトウェアブロック（ＳＳＢ）のデータ（ＳＳＢＤ）のハッシュの有効性をチェックする前記第３の段階は、特にハッシュエンジンによって、暗号化ハードウェアアクセラレーションモジュール内の前記データブロック（ＳＳＢＤ）にわたってハッシュ値を計算する段階と、前記ハッシュ値と、前記データブロックにわたって計算された適合ダイジェストを規定するハッシュ値を格納するヘッダ（ＳＳＢＨ）内のフィールドの内容とを比較する段階とを含む、請求項１に記載のシステム。
7. 前記リアルタイムセキュアオペレーティングシステムは、タスク実行に使用される前記ハードウェアトラストアンカの揮発性メモリのスタック（ＳＳ）に対して、使用されたスタック（ＳＳ）の量を静的境界に対してチェックする段階を含むスタックオーバーフロー検出手順を実行するように構成される、請求項１に記載のシステム。
8. 前記リアルタイムセキュアオペレーティングシステム（ＨＯＳ）は、
   タスクに割り当てられたスタックエリアを既知のパターン（ＳＰ）で満たし、
   各コンテキストスイッチ中、修正がないか有効スタック範囲内の最後の部分をチェックし、
   前記満たす操作に対して修正が検出された場合、スタックオーバーフローフック機能を呼び出す、
   ように構成される、請求項７に記載のシステム。
9. 前記リアルタイムセキュアオペレーティングシステムは、タスク最悪実行時間（Ｃ）の違反をチェックする段階であって、前記タスクの所与のインスタンスに関する前記タスク最悪実行時間（Ｃ）の値は、オフライン時間解析によって与えられる、段階と、前記チェックする段階によって異常が検出された場合、前記検出された異常に関する情報をセキュアログ（ＳＬ）に書き込む段階とを含む、リアルタイム検出手順を実行するように構成される、請求項１に記載のシステム。
10. 前記少なくとも１つのホストコンピューティングモジュールおよびハードウェアトラストアンカは、システムオンチップの一部であり、特に、前記少なくとも１つのホストコンピューティングモジュールは、車両内で動作するＥＣＵである、請求項１に記載のシステム。
11. 前記検出された異常に関する情報を前記セキュアログ（ＳＬ）に書き込む段階は、前記検出された異常に関する情報を含むセキュアログ（ＳＬ）を作成する段階、または、前記セキュアログ（ＳＬ）内に前記異常を書き込む段階を含む、請求項１に記載のシステム。
12. 請求項１〜１０のいずれか１項に記載の前記処理システムにおいて使用されているソフトウェア上で有効性チェックを実行するリアルタイムセキュアオペレーティングシステム（ＨＯＳ）を格納し実行することを含む、前記処理システムにおいて信頼できる操作を実行する方法であって、前記方法は、実行時にソフトウェアコードの完全性を制御する実行時真正性チェックを実行する段階を含み、前記実行時真正性チェックは、少なくとも実行のために前記ハードウェアトラストアンカのプログラムメモリ内に存在する署名済みソフトウェアブロック（ＳＳＢ）ならびに対応するヘッダ（ＳＳＢＨ）およびデータブロック（ＳＳＢＤ）を識別する段階と、
    各署名済みソフトウェアブロック（ＳＳＢ）について、
    前記署名済みソフトウェアブロック（ＳＳＢ）に関連付けられた証明書（Ｃ）の有効性をチェックする第１の段階、
    前記署名済みソフトウェアブロック（ＳＢＢ）のヘッダ（ＳＳＢＨ）の有効性をチェックする第２の段階、
    前記署名済みソフトウェアブロック（ＳＳＢ）のデータ（ＳＳＢＤ）のハッシュの有効性をチェックする第３の段階、
    を実行する段階と、
    前記有効性チェックのチェックする段階のうちの１つによって異常が検出された場合、前記検出された異常に関する情報をセキュアログ（ＳＬ）に書き込む段階と、
    を含み、
    前記リアルタイムセキュアオペレーティングシステムは、他のホストコンピューティングモジュールまたはハードウェアトラストアンカのサービスに対して最優先されるタスク（ＰＬ）において前記実行時真正性チェックを実行するように構成される、方法。
13. 前記方法は、請求項２〜１１のいずれか１項に記載のシステムの前記操作を含む、請求項１２に記載の方法。

Images