JP2022502790A - 安全性に関連するデータストリームを検出する方法 - Google Patents

Abstract

少なくとも一つのデータ処理タスク２の実行中にハードウエアシステム１に発生する安全性に関連するデータフローを検出する方法である。本方法は、このハードウエアシステム１の少なくとも一つのメモリユニット３に保存できるクリティカルなデータ６を定義する工程と、このハードウエアシステム１をシミュレーション環境４において動作するシミュレーションモデル５にマッピングする工程と、このシミュレーション環境４におけるシミュレーションモデル５によるシミュレーションとしてデータ処理タスク２を実行する工程と、このデータ処理タスク２の実行中に、シミュレーションモデル５におけるクリティカルなデータ６及びクリティカルなデータ６のインスタンス６’，６’’の作成、送信及び削除を監視する工程と、安全性に関連するデータストリームを特定して、ログに記録する工程とを有する。

Description

本発明は、少なくとも一つのデータ処理タスクの実行中にハードウェアシステムで発生する安全性に関連するデータストリームを検出する方法に関する。

情報・通信技術（ＩＣＴ）のシステムにおける典型的な課題は、権限の無いユーザー又はアプリケーションによる情報（データ）へのアクセスを防止することである。そのために、従来技術では、様々な方法が実現されており、その方法として、例えば、（英語の専門用語で、「アクセス権限」又は「アクセスポリシー」とも呼ばれる）アクセス制御、アクセス権限の管理（認証）やプロセス及び／又はメモリ空間の隔離（例えば、サンドボクシング）が挙げられる。より低いレベルでは、例えば、ハードウェアにおいて、メモリ管理ユニット（メモリマネッジメントユニット、ＭＭＵ）によって、それを実現することができる。

方式又は実装のエラー、認証部への集中的な攻撃、バックドア（サイドチャネル）を介した意図しない情報ストリームや同様のメカニズムによって、データへの望ましくないアクセスに関する可能性が起こり得る（リーク）。そして、攻撃（アタック）は、所定の結果（インパクト）を伴って、ＩＣＴシステムへの影響及び／又はデータへのアクセスを得るために、一つ又は複数の弱点（脆弱性）を利用する。それによって、システムの機密規則（機密性）が無効化される、或いは破られる可能性がある。

ハードウェアシステム又はコンピュータシステムの機密特性は、一次的には、例えば
ア 設計毎のセキュリティ
イ 実証された成功モデルに基づく措置（成功例）
ウ プロセス又は標準（例えば、ＩＳＯ／ＩＥＣ２７００１及び２７００２、ＩＳＯ１５４０８／共通基準、ＮＩＳＴ ＣＳＦ、ＳＡＥ Ｊ３０６１）の遵守
エ メモリ内暗号化などの原理
オ アドレス空間配置のランダム化（ＡＳＬＲ）
などの設計、実装及び動作における原理及び規定を遵守することによって満たされる。

開発に付随して、特に、最終的に、並びに各統合工程後に、実装形態、そのため、結果として得られた挙動をテストすることが必要である。それは、例えば、ソフトウェア及びハードウェアのアーキテクチャ及び実装形態を審査すること（オーディット）によって実行することができる。そのプロセス手法は効果的であり、何十年も前から採用されているが、非常に（時間的な）負担もかかり、自動化も難しい。しかし、特に、システムのリソース（コード、モデル）が利用可能でなければならない。それは、例えば、機密保持の理由から、必ずしも望ましいことではなく、しばしば（例えば、第三者のソフトウェアライブラリの使用時には）全く不可能でもある。

別の手法は、統計的なコード分析（これは自動化可能であるが、リークの発見には大して効果的ではない）又は（又もやリソースの開示を必要とする）モデル検査から由来するものである。それらの方法も、（伝送、記憶及び処理を含む）処理チェーンへの攻撃及びその中の弱点を検知できないことが共通している。それは、例えば、コンパイル、リンキング、伝送（ダウンロード等）、（例えば、フラッシュメモリ、ハードディスク等への）記憶、ソフトウェア（インタープリタ、仮想機械等）での実行、最終的にはハードウェアに関係する。そのような理由から、多数の成功した攻撃が正にそこで起こっている。

例えば、非特許文献１は、サンドボックスを介した攻撃を記載している。

キャッシュ攻撃は、例えば、非特許文献２に記載されている。

非特許文献３は、メモリに向けた攻撃を記載している。

統計的なテストの外に、実行中にシステムの挙動を検査する動的なテストも存在する。動的なテストは、特に、（統計的には未だ探索できない）未知の、或いは新しいパターンに対応するシナリオと、複雑さ又は未観察の特性のために分析では統計的に発見されないケースとに関して統計的なテストを補完するものである。完全なシステム記述及びソースコードにアクセスできない場合、何れにせよ統計的なテストの手法が制限され、そのことは、動的なテストの重要性を一層高める可能性がある。

動的なテスト方法は、大抵は定義されたアプリケーションシナリオ（テストケース）を（手動により、或いは自動的に）実行することをベースとする。この場合、挑戦課題は、特に、
（ｉ）安全性の問題に注意を払うための、そのテストケースの好適な具体化、
（ｉｉ）実行（これは、所与の時間内で出来る限り多数のテストケースを実行できるようにするために、理想的には自動化されて行われる）、並びに
（ｉｉｉ）テスト結果の正しい評価、特に、セキュリティの弱点の検知、
である。

本発明との関連において、有利には、所定のテスト又は所定のシミュレーションの前提条件、入力、実施条件、テスト方法及び／又は期待される結果を定義する規定が「テストケース」と呼ばれる。

非特許文献４は、特別に修正されたハードウェア、例えば、Ｉ２Ｃ周辺モジュール、レジスタ及び内部バスにおいて、例えば、データワード当たり一つの追加ビットだけ拡張されたハードウェアを記載している。その（文献では、「タイント」と呼ばれる）ビットは、「クリティカルな」情報を標示して、それを用いて、ハードウェアを「泳動」する。データの処理工程（例えば、論理結合）は、この標示ビットだけ拡張されており、そのため、成果物に対するクリティカルなデータの影響を表示して、追跡することができる。しかし、その特別に修正されたハードウェアが無いと、その措置を実現できない。

国際特許公開第２０１５／０６７６４９号明細書

Ｌｉｐｐ Ｍ．， Ｇｒｕｓｓ Ｄ．， Ｓｃｈｗａｒｚ Ｍ．， Ｂｉｄｎｅｒ Ｄ．， Ｍａｕｒｉｃｅ Ｃ．， Ｍａｎｇａｒｄ Ｓ．， "Ｐｒａｃｔｉｃａｌ Ｋｅｙｓｔｒｏｋｅ Ｔｉｍｉｎｇ Ａｔｔａｃｋｓ ｉｎ Ｓａｎｄｂｏｘｅｄ ＪａｖａＳｃｒｉｐｔ"， Ｓｅｐｔｅｍｂｅｒ ２０１７ ｉｎ Ｆｏｌｅｙ Ｓ．， Ｇｏｌｌｍａｎｎ Ｄ．， Ｓｎｅｋｋｅｎｅｓ Ｅ． （ｅｄｓ） Ｃｏｍｐｕｔｅｒ Ｓｅｃｕｒｉｔｙ − ＥＳＯＲＩＣＳ ２０１７， Ｌｅｃｔｕｒｅ Ｎｏｔｅｓ ｉｎ Ｃｏｍｐｕｔｅｒ Ｓｃｉｅｎｃｅ， Ｂｄ． １０４９３ Ｇｒｕｓｓ， Ｄ．， Ｍａｕｒｉｃｅ， Ｃ．， Ｗａｇｎｅｒ， Ｋ．， ＆ Ｍａｎｇａｒｄ， Ｓ．， "Ｆｌｕｓｈ＋ Ｆｌｕｓｈ： ａ ｆａｓｔ ａｎｄ ｓｔｅａｌｔｈｙ ｃａｃｈｅ ａｔｔａｃｋ"， Ｊｕｌｉ ２０１６ ｉｎ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｄｅｔｅｃｔｉｏｎ ｏｆ Ｉｎｔｒｕｓｉｏｎｓ ａｎｄ Ｍａｌｗａｒｅ， ａｎｄ Ｖｕｌｎｅｒａｂｉｌｉｔｙ Ａｓｓｅｓｓｍｅｎｔ （Ｓ． ２７９−２９９）． Ｓｐｒｉｎｇｅｒ， Ｃｈａｍ Ｇｒｕｓｓ， Ｄ．， Ｍａｕｒｉｃｅ， Ｃ．， ＆ Ｍａｎｇａｒｄ， Ｓ．； Ｒｏｗｈａｍｍｅｒ．ｊｓ， "Ａ ｒｅｍｏｔｅ ｓｏｆｔｗａｒｅ−ｉｎｄｕｃｅｄ ｆａｕｌｔ ａｔｔａｃｋ ｉｎ ｊａｖａｓｃｒｉｐｔｔ"， Ｊｕｌｉ ２０１６ ｉｎ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｄｅｔｅｃｔｉｏｎ ｏｆ Ｉｎｔｒｕｓｉｏｎｓ ａｎｄ Ｍａｌｗａｒｅ， ａｎｄ Ｖｕｌｎｅｒａｂｉｌｉｔｙ Ａｓｓｅｓｓｍｅｎｔ （Ｓ． ３００−３２１）， Ｓｐｒｉｎｇｅｒ， Ｃｈａｍ Ｊ．， Ｈｕ， Ｗ．， Ｉｒｔｕｒｋ， Ａ．， Ｔｉｗａｒｉ， Ｍ．， Ｓｈｅｒｗｏｏｄ， Ｔ．， ＆ Ｋａｓｔｎｅｒ， Ｒ．， "Ｉｎｆｏｒｍａｔｉｏｎ ｆｌｏｗ ｉｓｏｌａｔｉｏｎ ｉｎ Ｉ２Ｃ ａｎｄ ＵＳＢ"， Ｊｕｎｉ ２０１１ ｉｎ Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ４８ｔｈ Ｄｅｓｉｇｎ Ａｕｔｏｍａｔｉｏｎ Ｃｏｎｆｅｒｅｎｃｅ （Ｓ． ２５４−２５９）， ＡＣＭ Ｋｏｃｈｅｒ， Ｐ． Ｃ．，"Ｔｉｍｉｎｇ ａｔｔａｃｋｓ ｏｎ ｉｍｐｌｅｍｅｎｔａｔｉｏｎｓ ｏｆ Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ， ＲＳＡ， ＤＳＳ， ａｎｄ ｏｔｈｅｒ ｓｙｓｔｅｍｓ"，Ａｕｇｕｓｔ １９９６ ｉｎ Ａｎｎｕａｌ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｒｙｐｔｏｌｏｇｙ Ｃｏｎｆｅｒｅｎｃｅ （Ｓ． １０４−１１３）． Ｓｐｒｉｎｇｅｒ， Ｂｅｒｌｉｎ， Ｈｅｉｄｅｌｂｅｒｇ Ｙｅ， Ｘ．， Ｆａｎ， Ｄ．， Ｓｕｎ， Ｎ．， Ｔａｎｇ， Ｓ．， Ｚｈａｎｇ， Ｍ．， ＆ Ｚｈａｎｇ， Ｈ，"ＳｉｍＩＣＴ： Ａ ｆａｓｔ ａｎｄ ｆｌｅｘｉｂｌｅ ｆｒａｍｅｗｏｒｋ ｆｏｒ ｐｅｒｆｏｒｍａｎｃｅ ａｎｄ ｐｏｗｅｒ ｅｖａｌｕａｔｉｏｎ ｏｆ ｌａｒｇｅ−ｓｃａｌｅ ａｒｃｈｉｔｅｃｔｕｒｅ"，Ｓｅｐｔｅｍｂｅｒ ２０１３， ｉｎ Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ２０１３ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｌｏｗ Ｐｏｗｅｒ Ｅｌｅｃｔｒｏｎｉｃｓ ａｎｄ Ｄｅｓｉｇｎ （Ｓ． ２７３−２７８）， ＩＥＥＥ Ｐｒｅｓｓ

本発明の課題は、特に、ハードウェアを変更することなく、動的なテストを実現できるにすることであり、本方法は、標準的なハードウェアに対して使用可能であるだけでなく、特に、工業的な自動化分野や、例えば、自動車分野における組込システムにも採用することができる。

この課題及び別の課題は、本発明に基づき、
ハードウェアシステムの少なくとも一つのメモリユニットに保存できる、或いはインターフェイス（ｉｎｔｅｒｆａｃｅ）を介してハードウェアシステムに伝送できる、クリティカルなデータを定義する工程と、
シミュレーション環境において実行可能なシミュレーションモデルにハードウェアシステムをマッピングする工程と、
このシミュレーション環境におけるシミュレーションモデルを用いたシミュレーションとしてデータ処理タスクを実行する工程と、
このデータ処理タスクの実行中に、このシミュレーションモデルにおけるクリティカルなデータ及びクリティカルなデータのインスタンスの作成、送信及び削除を監視する工程と、
安全性に関連するデータストリームを特定して、ログに記録する工程と、
を有する冒頭で述べた種類の方法によって解決される。本方法を用いて、ハードウェアシステムにおける望ましくないデータストリームの発生を検知することができ、そのために、このハードウェアシステムを修正する必要がない。特に、（例えば、Ｉｎｔｅｌ、ＡＲＭ、Ｉｎｆｉｎｅｏｎ等の）標準的なＣＰＵをベースとする実際のマイクロコントローラシステムでは、そのように修正されたハードウェアを取得する可能性が殆どないが、非常に良いことに、シミュレーション環境として利用できる、そのようなＣＰＵのほぼ全てに適したシミュレータが存在する。

本発明との関連において、特に、シミュレーションモデルのシミュレーションに適したコンピュータシステムが、そこで動くシミュレーションソフトウェアと共に「シミュレーション環境」と呼ばれる。純粋なハードウェアシステムと異なり、このシミュレーション環境は、特に、例えば、メモリ及びレジスタに存在するデータのその時々の状態と、それらのデータを変更する全てのプロセスとを監視することを可能にする。これによって、シミュレーション環境において、特に、データの作成、送信及び削除を監視することが可能である。所定のハードウェアシステムのシミュレーションモデルのシミュレーションに適した相応のシミュレーション環境は、専門分野において周知であり、所与のハードウェアシステムに適したシミュレーション環境を選定すること、並びにそのハードウェアシステムを選定されたシミュレーション環境により実行可能なシミュレーションモデルにマッピングすることは、ここに開示した教示を知った上で、当業者の手腕に依存する。

本明細書との関連において、少なくとも一つの所定の時点（例えば、発生時点／インスタンス生成時）に観察しているクリティカルなデータに直に依存するクリティカルなデータのコピーが「インスタンス」と呼ばれる。そのため、インスタンスは、例えば、クリティカルなデータのコピーであるか、さもなければデータをコピーして、（再）符号化したものであるとすることができる。再符号化は、例えば、元のデータが整数であり、インスタンスがその浮動表現である場合に行われる。

本開示との関連において、一般的にデータ処理システムの物理的なコンポーネント（即ち、電子部品と機械部品）とその周辺機器の全体が「ハードウェアシステム」と呼ばれる。このハードウェアシステムは、特に、周知のシステムアーキテクチャに基づくコンピュータシステムであるとすることができる。しかし、ハードウェアシステムは、より狭い意味で「コンピュータシステム」に相当しない複数のハードウェアコンポーネントの協力して動作する構造、例えば、複数のハードウェアコンポーネントから成るセンサー網又は専用網であるとすることもできる。

有利には、ハードウェアシステムをシミュレーションモデルにマッピングするために、ハードウェアシステムは、少なくとも一つの通信機器を介して接続されるとともに、その通信機器を介してデータを交換できる多数のハードウェアコンポーネントに分割することができ、各ハードウェアコンポーネントは、少なくとも一つの通信ユニット、少なくとも一つのメモリユニット及び少なくとも一つのプロセッサユニットを有する。シミュレーションモデルをモデル化するためのベースとなる、この分割の好適な選定によって、異なるレベルにおいて、例えば、抽象化された機械又は仮想機械のレベル、ＣＰＵ命令レベル、ゲート又はビットレベル、通信又はバスレベルにおいて、ハードウェアシステムをシミュレーションして、観察することができる。

有利な実施構成では、クリティカルなデータの定義をデータ特性の定義によって行うことができる。本開示との関連において、特に、データ内容、発生時点又は作成時点、処理時点、メモリ内のアドレスに関する属性、システム状態への依存性、別の（クリティカルな）データへの依存性等とそれらから定義可能な組合せがデータ特性であると理解する。これは、例えば、ソフトウェアコンポーネントのソースコードを知ることの無い検査を可能にする。

データ属性の関連する組合せの例は、例えば、コールスタックデータの発生時点と削除時点から成る、実行時間を観察することである。一種のサイドチャネル攻撃は、例えば、鍵検査ルーティンの実行時間に関する情報を利用して、鍵に関する情報を間接的に傍受する（非特許文献５を参照）。

有利には、少なくとも所定の安全性に関連するデータストリームを特定した場合に、警報メッセージを作成することができる。この警報メッセージは、シミュレーション環境を制御するために使用される、制御・監視システムのユーザーインターフェース上に即座に表示することができ、その結果、試験者は、シミュレーションを中止するのか、或いは更に実行するのかを決定することができる。場合によっては、警報メッセージの発生時に、それが望まし場合に、シミュレーションを自動的に中止することができる。

有利には、特定された安全性に関連するデータストリームを評価に保存することができ、この評価は、場合によっては、グラフィック表示される。これは、実行されたテストのログ記録と報告を可能にする。

有利には、シミュレーションの進行状況をログに記録することもできる。更に、場合によっては、（履歴を含む）包括的な進行状況を一緒に記録して、場合によっては、データストリームのログ記録と関連付けることができ、これは、その後の分析／診断／エラー探索を支援する。

有利には、場合によっては、定義されたテストケースの処理時に動作させるアプリケーションソフトウェアを実行することから、データ処理タスクを生成することができる。これは、アプリケーションソフトウェアを部分又は全体として試験して、アプリケーションソフトウェアとその下位のソフトウェア部分（ミドルウェア、フレームワーク、ライブラリ、オペレーティングシステム等）及び所与のハードウェアシステムとの協力した動作に関する知見を取得することを可能にする。

本発明による方法の別の有利な実施構成では、ハードウェアシステムの区画を許容ドメインと禁止ドメインに分割することができる。これは、ヒット関連性を向上させることができる。

許容ドメインと禁止ドメインへの分割は、例えば、クリティカルなデータの定義の途中で、シミュレーションモデルのモデル化の途中で、或いはその後でも行うことができ、この分割は、特に、プログラマー又は試験者の経験に基づき決定するか、或いは比較可能なハードウェアシステムの以前に実行されたテスト方法に基づき規定することができる。相応の分割を実施するには、ここに開示した教示を知った上で、当業者の手腕に依存する。

有利には、少なくとも次のデータストリームが、即ち、
ア 禁止ドメインの通信機器を介して、クリティカルなデータ又はそのインスタンスを伝送することと、
イ クリティカルなデータが削除される一方、クリティカルなデータの少なくとも一つのインスタンスが存在し続けることと、
ウ 禁止ドメインにおいて、クリティカルなデータのインスタンスが作成されることと、
エ 所定の時点及び／又はシステム状態後に、特に、データ処理タスクの完了後に、例えば、アプリケーションの終了後に、クリティカルなデータが存在し続けることと、
が安全性に関連するデータストリームとして特定することができる。場合によっては、進行状況を観察することによって、例えば、時間に対するクリティカル性の依存度、システム状態などの追加のルールを考慮することができる（これは、基本的に許容ドメインと禁止ドメインの定義がシミュレーションの進行状況に応じて変更されることを意味する）。

本発明との関連において、例えば、その時々の用途のために定義された所定の判断基準に、例えば、前の段落で言及した判断基準に合致するデータストリームが「安全性に関連するデータストリーム」と呼ばれる。

以下において、本発明の有利な実施形態を例示して、模式的に、本発明を制限しない形で図示した図１〜５を参照して、本発明を詳しく説明する。

本発明による方法に関与するユニットと本方法の工程の模式図 ハードウェアシステムとそこで動作するソフトウェアの模式図 図２のハードウェアシステムをシミュレーションモデルとしてマッピングするためのシミュレーション環境の模式図 シミュレーション環境で実行されるシミュレーションの模式図 グラフィック編集されたシミュレーション結果のグラフ図

図１には、本発明による方法の基本的なエンティティが抽象的に図示されている。ハードウェアシステム１は、一般的に少なくとも一つの通信機器８を介して互いに接続されるとともに、この通信機器８を介してデータ交換できる複数のハードウェアコンポーネント７（図１では、区別するために、ハードウェアコンポーネントにａ〜ｅの小文字を付けている）から構成される。このために、各ハードウェアコンポーネント７は、通常、図１においてハードウェアコンポーネント７ａに対してアイコンで表示されている通り、通信ユニット９、メモリユニット３及びプロセッサユニット１０を備えている。図１に表示されたハードウェアコンポーネント７ｃは、例えば、従来の（ノートブック）コンピュータであるとすることができ、そこでは、例えば、別のハードウェアコンポーネントのための制御ソフトウェアが動作する。このハードウェアシステム１は、「入れ子式」ハードウェア構造を有することもできる、即ち、ハードウェアシステムが上位のハードウェアシステムの一部である。ハードウェアシステム１（又はハードウェアシステム１のハードウェアコンポーネント７）は、例えば、ＳｏＣ（システム・オン・チップ）として実現することもできる。そのようなハードウェアシステムの例として、例えば、Ｉｎｆｉｎｅｏｎ社のＸＣ２７ｘ８Ｘシリーズのマイクロプロセッサが挙げられる。この場合、通信機器８は、内部バスシステムによって構成され、ＣＰＵのバス接続部内に通信ユニット９を見ることができ、内部レジスタとキャッシュをメモリユニット３と見做すことができ、プロセッサユニット１０はＳｏＣのＣＰＵである。場合によっては、例えば、ＣＡＮコントローラ、ＰＷＭコントローラ又はそれ以外のものなどの周辺コンポーネントをハードウェアシステム１のハードウェアコンポーネント７として定義することができる。

表現レベルに応じて、ハードウェアシステム１のハードウェアコンポーネント７は、異なる種類のユニットを包含することができる。ハードウェアコンポーネント７の別の例として、
ア 車両内の制御機器（例えば、ＥＣＵ又はエンジン、変速機、ＡＢＳ、ＥＳＰ等のための別の制御ユニット）、
イ 例えば、ＷＳＮ（ワイヤレス・センサー・ネットワーク）を介して通信する、センサー網、例えば、ＩｏＴシステムにおけるインテリジェントなセンサーノード、
ウ 蓄積プログラム式（産業用）制御部（ＳＰＳ）におけるＣＰＵモジュール及び／又はＩ／Ｏモジュール、
エ クラウド又は計算機クラスターにおけるノード、
が挙げられる。

従来のＰＣとの関連において、例えば、主ＣＰＵをハードウェアコンポーネント７として定義することができ、その際、例えば、ディスク、キーボード、グラフィックカードなどの周辺機器コントローラを別のハードウェアコンポーネントとして定義することができる。

通信機器８は、内部又は外部のバスシステム、或いは別の有線接続式又は無線接続式通信機器８であるとすることができる。例えば、通信機器８に関しては、例えば、ＰＣＩ、ＰＣＩ−Ｘ、ＰＣＩｅ、ＡＧＰ、ＵＳＢ、Ｉ２Ｃなどの機器内のバスや、例えば、ＣＡＮ、ＬＩＮ、Ｆｌｅｘｒａｙ、（自動車用）イーサネット、ＭＯＳＴなどの外部バス又はフィールドバスが挙げられる。車両分野において、これは、一般的に「車両内ネットワーク：ＩＶＮ」と呼ばれる。

図１に図示された形態と異なり、ハードウェアシステム１は、様々な配置構成のハードウェアコンポーネント７と通信システム８を包含することもでき、例えば、ハードウェアシステム１が複雑な網接続形態を有し、その際、例えば、複数の階層的なバス、星形網又は環状網等が包含される。実際にハードウェアシステム１に関する例は、組込システムである。

本開示との関連において、技術的な文脈で組み込まれているハードウェアシステム１が「組込システム」と呼ばれる。組込システムは、例えば、医療機器、例えば、洗濯機や冷蔵庫などの家電製品、例えば、テレビ、ＤＶＤプレーヤー、セットトップボックス、ルーターや携帯電話などの娯楽用電子機器、例えば、自動車、航空機や船舶などの様々な路上走行車両、軌道車両又は水上／水中車両、それ以外の運搬機器、産業設備、さもなければ宇宙飛行で使用されている。

（即ち、技術的に複雑であるとの文脈において）複雑な全体システムの場合、組込システムは、異なる通信機器８、例えば、それぞれ安全性、データスループット及び／又は速度の仕様が異なる複数のバスシステムを介して互いに網状に接続された、その他の点では自律的な多数の組込（サブ）システムの網接続形態であるとすることができる。

任意選択として、ハードウェアシステム１及び／又はそこに含まれるハードウェアコンポーネント７の個々又は全ては、周知の手法によりデータ処理タスク２を処理する、或いはその処理に関与する、ランタイム環境、ランタイムライブラリ、ドライバ等を含むオペレーティングシステム１１を有する。例えば、オペレーティングシステム１１は、コンピュータの内部及び外部のハードウェアの動作及び共同作業を制御する従来又は専用のコンピュータ用オペレーティングシステムであるとすることができる。オペレーティングシステム１１の例として、例えば、パーソナルコンピュータ、タブレット及びスマートフォンの分野におけるＷｉｎｄｏｗｓ、Ａｎｄｒｏｉｄ、ｉＯＳ、ｍａｃＯＳ、Ｌｉｎｕｘ、ＵＮＩＸ、自動車分野におけるＱＮＸ、ＥｌｅｋｔｒｏｂｉｔＯＳ、ＲＯＳ、ＡＵＴＯＳＡＲ、或いは様々な製造業者の所有製品が挙げられる。ハードウェアシステム１を表現する詳細度に応じて、単一のオペレーティングシステム１１を複数のハードウェアコンポーネント７に配備することもできる。これは、例えば、ハードウェアシステム１が、内部のハードウェアコンポーネント７がオペレーティングシステムにより制御される形で相応のバスシステムを介して互いに通信するコンピュータシステムである（或いはそのようなコンピュータシステムを含む）場合である。しかし、システム限界及びモデル形態に応じて、「より小さな」、「より大きな」又は「入れ子式の」ユニットをハードウェアコンポーネント７として定義することもでき、この場合、そのユニットの機能を決定する制御機構がそれぞれオペレーティングシステムであると理解される。

そのため、本明細書との関連において、ハードウェアコンポーネント７、ハードウェアコンポーネント７のグループ及びハードウェアシステム１の全体の中の一つ以上のシステムリソースの機能又はそこで進行するデータストリームを制御する一連のプログラム命令がオペレーティングシステム１１であると理解する。一つのハードウェアシステム１に複数のオペレーティングシステム１１を配備することもできる。

ハードウェアシステム１を表現する詳細度がそのハードウェアシステム１自体を変化させない場合でも、その表現形式又はハードウェアコンポーネント７への分割形式が後述するモデル化工程、即ち、ハードウェアシステム１のシミュレーションモデル５の作成にとって重要であることを指摘したい。

パラメータデータ１３に応じて、アプリケーションソフトウェア１２から、ハードウェアシステム１又は個々のハードウェアコンポーネント７によって処理される異なるデータ処理タスク２が生成される。本発明との関連において、一つのハードウェアコンポーネント７又は複数のハードウェアコンポーネント７によって共通的に実行される如何なるプロセス工程（又は如何なるプロセス工程のグループ）も「データ処理タスク」と見做すことができる。特に、本開示との関連において、データストリームを生じさせるプロセス工程がデータ処理タスクと見做される。

本開示との関連において、特に、
ア メモリユニット３のメモリアドレスに保存されたデータのコピーを同じメモリユニット３又は別のメモリユニット３の別のメモリアドレスに作成すること、
イ データ又はデータのコピーを変更すること、
ウ メモリユニット３のメモリアドレスに保存されたデータを削除すること、
エ 複数のハードウェアコンポーネントによって使用される通信機器８を介して、一つのハードウェアコンポーネント７から一つ（又は複数）のハードウェアコンポーネント７にデータを送信すること、並びに
オ ハードウェアシステム１の外部インタフェースを介してデータを送信又は受信すること、
が「データストリーム」と呼ばれる。

本明細書との関連において、アプリケーションソフトウェア１２の進行状況に影響を与える、プログラム外で設定される全ての影響要因が「パラメータデータ」１３と呼ばれる。パラメータデータ１３は、開発者又はユーザーによって選定された設定と関連するか、所定の環境条件から得るか、或いは、典型的には、（時には、「ＩＮＩ」又は「ＣＦＧ」ファイルと称される）コンフィグレーションファイルで定義される基本設定、デフォルト値、動作モード等を規定することができる。そのようなパラメータデータ１３の別の例は、（例えば、車両に組み込まれたシステムであるとすることができる）ハードウェアシステム１においてアプリケーションソフトウェア１２に基づき処理されるセンサーデータである。そのため、現実のハードウェアシステム１では、これらのパラメータデータ１３は、その時々の環境条件から得られるとともに、ハードウェアシステム１のシミュレーションの途中で、相応のパラメータデータ１３をテストケースとして準備して、処理することができる。

オペレーティングシステム１１、アプリケーションソフトウェア１２及びパラメータデータ１３に関するシンボルの階層表現によって、複数のオペレーティングシステム、アプリケーションソフトウェアユニット及びパラメータデータセットの中の一つ以上がそれぞれハードウェアシステム１と関連できることを見えるようにすべきである。

ハードウェアシステム１とそこに配備された一つのオペレーティングシステム１１又はそれに配備された複数のオペレーティングシステム１１の複雑なアーキテクチャのために、並びに最新のプログラミングツールを用いて作成されたアプリケーションソフトウェア１２の構造のために、統計的な方法によって、アプリケーションソフトウェア１２のソースコードに基づき、如何なるデータストリームが所定のハードウェアシステム１においてデータ処理タスクを削除するのかを完全に予測することは最早不可能である。パラメータデータ１３の限られた数の例だけに基づき、検査を行うこともできる。しかし、これは、正に、例えば、裏口を介した意図しない情報ストリームによる、攻撃に利用できる弱点を開放してしまう可能性がある。

しかし、ハードウェアシステム１において進行するデータストリームを監視することは不可能であり、その理由は、そのためには特別なハードウェアが必要になるからである。しかし、特別なハードウェアに基づくエラー分析は、変更されない本来のハードウェアに対して、限定的な意味しか持たない。

それ自体見えないデータストリームを眺めるために、本発明に基づき、ハードウェアシステム１が、シミュレーション環境４で実行可能なシミュレーションモデル５としてマッピングされる。

このシミュレーション環境４は、データ処理タスクの実行中に起こるデータストリームをハードウェアシステム１のシミュレーションモデル５においてシミュレーションして、それを観察できるようにする任意の好適なシミュレーションプラットフォームであるとすることができる。

シミュレーション環境４でのシミュレーションは、個々のハードウェアコンポーネント７によって実行されるデータストリームを観察して、ログに記録することを可能にする。この観察とログ記録は、有利には、シミュレーションの実行前に、制御・監視システム２４の相応のユーザーインターフェース２５を介して決定されて、シミュレーション環境４の「クリティカルなデータの定義」６に供給されるクリティカルなデータに限定される。この制御・監視システム２４は、ユーザーが、ユーザーインターフェース２５を介して、シミュレーションモデル５のモデル形態、クリティカルなデータ６の定義、シミュレーションの実行の開始と停止やパラメータデータ１３又はテストケースの定義又は選定を含む、シミュレーション環境４でのシミュレーションの進行に必要な全ての定義と指示を作成することを可能にする。

シミュレーションモデル５へのハードウェアシステム１のマッピングを可能にする技術とシステムは、専門分野において周知であり、例えば、非特許文献６に記載されている。

シミュレーションモデル５は、例えば、より大きな全体システムの一部だけをマッピングすることもでき、それは、例えば、その全体システムの全ての構成要素をソフトウェアでシミュレーションできない場合、完全なシミュレーションモデルの作成に負担がかかり過ぎる場合、或いはそのようなシミュレーションが長過ぎる計算時間を必要とする場合である。この場合、現実のハードウェア部品としてデータストリームに関連しない部分は、例えば、ハードウエア・イン・ザ・ループ・シミュレーションの形式でシミュレーション環境４に結び付けることができる。同様に、シミュレーションモデル５を動作させるためのシミュレーション環境４は、一つ（又は複数）の別のシミュレーション環境とデータを交換することができ、その際、別のシミュレーション環境は、本発明による方法でデータストリームを調査する必要の無い要素をシミュレーションし、従って、より簡単に構築することができる。

シミュレーションにおいて、シミュレーションモデル５は、アプリケーションソフトウェア１２から発生するデータ処理タスク２を実行し、その際、パラメータデータ１３は、事前に定義されたテストケースに基づき算出される。この場合、例えば、ソフトウェアプログラムは、その全体又は個別部分として処理することができる。この場合、テストケースは、例えば、ハードウェアシステム１の出来る限り現実的な進行状況に対して設計することができるが、特別なシナリオを表すか、或いは限界領域における動作条件と関連することもできる。車両用の走行支援システムと関連するテストケースを作成して、最適化する方法が、例えば、特許文献１に開示されており、そこでは、「テストシナリオ」と呼ばれている。シミュレーション環境４がそのようなテストケースに基づきシミュレーションモデル５を動作させる一方、シミュレーションモデル５におけるクリティカルなデータの物理的なコピーの作成、送信、処理／結合及び削除が、制御・監視システム２４によって観察されて、ログに記録される。

シミュレーションの実行後（又はその実行中）に、ログに記録されたデータに基づき、制御・監視システム２４によって、場合によっては、グラフィック表示をも含む評価１４が作成される。この場合、評価１４は、特に、有線接続式及び／又は無線接続式データ接続部を介したクリティカルなデータの送信プロセスと、シミュレーションモデル５としてモデル化された、ハードウェアシステム１の表現における任意のメモリ位置でのクリティカルなデータの物理的なコピーの作成及び削除とを表す。シミュレーションの実行後にメモリユニット３に存在する可能性のあるクリティカルなデータのインスタンスが特に興味の対象である。それは、クリティカルなデータ６のコピーが、シミュレーションの実行後（又は限定されたデータ処理タスク２の実行後、或いは元のメモリ位置でのクリティカルなデータ６の削除後）に未だ削除されていないか、或いは上書きされた場合であり、従って、発見されない形式の所定のアドレスがメモリユニット３の中の一つに依然として存在する場合であるとすることができる。

有利には、この評価１４において、メモリユニット３、通信機器８及び通信ユニット９の中の一つ以上をそれぞれ「許容ドメイン」１５と「禁止ドメイン」１６に分割することができる。これらのドメインは、例えば、メモリユニット３全体又はメモリユニット３内の所定のアドレス空間に基づき、バスアドレスに基づき、或いはハードウェアコンポーネント７に基づき定義することができ、この定義又は分割は、同じく制御・監視システム２４によって行うことができる。

シミュレーションモデル５は、必要に応じて、実行すべきハードウェアシステム１を定義可能な詳細度で表現することができる。例えば、シミュレーションモデル５は、ＣＰＵ命令セットのレベル（ＣＰＵ・インストラクション・レベル）又はハードウェアゲートレベルにおいてモデルすることができる。所要の詳細度は、テストすべき攻撃の形式に共通して依存する。ソフトウェアエラーに基づく望ましくないデータストリームを発見するためには、例えば、ＣＰＵの命令レベルにおけるシミュレーションで十分である。ハードウェア内の隙間又はキャッシュ攻撃に基づく望ましくないデータストリームを発見するためには、例えば、ハードウェアレベル／ゲートレベルにおいて、シミュレーションしなければならない。

ハードウェアシステム１は、特に、例えば、メモリダイレクトアクセス、周辺機器などのサブシステムと通信インタフェースを包含することもできる。

図２は、アプリケーションソフトウェア１２を実行できるオペレーティングシステム１１が動作するハードウェアシステム１の具体的な例を図示している。このハードウェアシステム１は、従来のコンピュータアーキテクチャに基づき構築されており、プロセッサ１７は、プロセッサコア１８，プロセッサキャッシュ１９及びプロセッサＩＯ２０を備えている。このプロセッサ１７は、バスアーキテクチャ２１を介して別のコンポーネント２２と通信することができる。このプロセッサコア１８，プロセッサキャッシュ１９、プロセッサＩＯ２０、バスアーキテクチャ２１及び別のコンポーネント２２から成るユニットは、（典型的には、センサー機器とアクチュエータを介して）（現実の）環境と置き換わるサイバーフィジカルシステムとして観察することができる。そのようなサイバーフィジカルシステムは、例えば、自動車の制御機器（ＥＣＵ）であるとすることができる。

このハードウェアシステム１において、アプリケーションソフトウェア１２を処理できるオペレーティングシステム１１が動作する。

図１と関連して成された総合的な記述の意味において、図２のプロセッサ１７が、例えば、第一のハードウェアコンポーネント７ａに相当し、プロセッサコア１８がプロセッサユニット１０に相当し、プロセッサキャッシュ１９がメモリユニット３に相当し、プロセッサＩＯ２０が通信ユニット９に相当し、バス装置２１が通信機器８に相当し、別のコンポーネント２２がそれ以外のハードウェアコンポーネント７を包含することができる。既に言及した通り、例えば、より詳細なレベルにおける別のモデル形態も可能である。

図３では、図２のハードウェアシステム１のモデル形態が、例えば、オペレーティングシステム１１とアプリケーションソフトウェア１２を考慮して、シミュレーション環境４によってハードウェアシステム１のシミュレーションとして動かすことができるシミュレーションモデル５で図示されている。

図４は、テスト実行時に本発明による方法に応じて実施される工程の模式図を図示している。試験者２３は、制御・監視システム２４のユーザーインターフェース２５を介して、シミュレーション環境４を操作し、図４の図面では、シミュレーションモデル５のモデル化が既に終了している。定義工程Ｉにおいて、試験者がクリティカルなデータ６を定義し、この定義は、特に、ハードウェアシステム１とそこで動作するアプリケーションソフトウェア１２の分析に基づく。監視すべきクリティカルなデータ６は、ユーザーによって、例えば、特別な標識により決定され、これは、ソフトウェア内で直に、即ち、コンパイル前に行うことができる。そのためには、例えば、シンボルファイルなどの、アプリケーションソフトウェア１２のソースコード及び／又はデバッグ情報へのアクセスが少なくとも部分的に必要である。場合によっては、クリティカルなデータの定義の決定は、ファイル特性、例えば、データ内容、発生時点、処理時点、メモリ内のアドレス等に関する属性の付与によって行うこともでき、この大部分は、ソースコードにアクセスしなくとも可能である。

それによると、本開示との関連において、特に、定義工程で、実施する人（例えば、プログラマー又は試験者２３）によって、或いは事前に定義された特性に基づきクリティカルなデータとして定義されたデータが「クリティカルなデータ」と呼ばれる。クリティカルなデータを定義するための判断基準は、特に、その時々の個々のケースと、検査すべきハードウェアシステム及び／又はデータ処理タスクとに依存する。当業者は、ここに開示された教示を知った上で、クリティカルなデータの定義を行うことが可能である。

クリティカルなデータ６の定義と関連して、ルールを作成する、例えば、監視されるクリティカルなデータ６が「上回る」ことを許されない「限界」を記述することができる。これらの限界は、ハードウェアの所定の部分、所定のメモリ範囲、ＣＰＵ内の所定の部分等と関連付けて、これらのリソースをそれぞれ許容ドメイン１５と禁止ドメイン１６に分割することができる。これらの定義は、別の制限、例えば、所定の時間区間又はシステム状態への依存性を含むこともできる。ドメインを定義するための別の特徴として、場合によっては、プロセスを実行する、例えば、どのユーザーの下で、（或いはどのユーザーのために）プロセスを実行するのか、或いはプロセッサをユーザーモード又はカーネルモードで動作させるのかなどの文脈を利用することができる。

定義工程Ｉの間に、シミュレーションの途中で処理すべきテストケースの選定又は定義も行われる。この工程において、シミュレーションモデル５のモデル化を行うか、或いはこのモデル化を適合させることもできる。

シミュレーションモデル５のモデル化、クリティカルなデータ６の定義、テストケースの選定及びルールと限界の定義の工程を任意の順番で、さもなければ互いに平行して、或いは反復工程で実施できることに留意されたい。

工程ＩＩにおいて、検査すべきアプリケーションソフトウェア１２が、用途又はテストケースに基づきシミュレーション環境にセットされて、工程ＩＩＩにおいて、このシミュレーション環境４で、シミュレーションが開始されて、この進行するシミュレーションが制御・監視システム２４によって監視される。テストすべきアプリケーションソフトウェアと、場合によっては、その下位のテストすべき部分（フレームワーク、ランタイムライブラリ、オペレーティングシステム等）、並びにハードウェアがシミュレーション環境４内で「動作」するので、クリティカルなデータ又はクリティカルなデータ（及びそのコピー）のストリームへの全てのアクセスを観察して、監視するとともに、定義されたルールと比較することができる。ルール違反は、ログに記録するか、警報メッセージとして通報するか、或いはその両方を行うことができ、それによって、起こり得るデータ漏洩を発見することができる。更に、文脈の記録とこれらの発見に関する履歴（シミュレーション環境４における完全な進行を追跡方法によって文書化できること）によって、別の診断（又はデバッグ）に重要な支援を与えることができる。

制御・監視システム２４は、少なくとも部分的に内部レジスタとシミュレーション環境４の状態にアクセスし、これは、典型的なデバッカーインタフェースに似ている。

そのため、クリティカルなデータ６、それへの全てのアクセス、並びにソフトウェア及びハードウェアの作動によって、これらのデータから由来し得る全ての変化（例えば、ＣＰＵのレジスタのフラグ）が観察、監視される。クリティカルなデータの経路は、制御・監視システム２４によって記録されて、評価１４において、例えば、空間構造における軌跡（「トレース」）の形で表すことができる（工程ＩＶ）。

図５には、そのようなツリー構造を有するクリティカルなデータ６に関する評価１４の例が図示されている。ｘ軸は、シミュレーションの時間経過を表し、ｙ軸には、許容ドメイン１５と禁止ドメイン１６に分割されたハードウェアの区間が表示されている。

図５に図示された例では、時点（ａ）で、（例えば、クリティカルなデータがハードウェアコンポーネント７のメモリにロードされた時に）クリティカルなデータ６の監視が始まる。時点（ｂ）で、プロセス工程の途中において、第一のインスタンス６’として表示された、クリティカルなデータのコピーが作成される。この第一のインスタンスは、許容ドメイン１５に割り当てられたメモリ領域に有る。時点（ｃ）で、コピーによって、第一のインスタンスから第二のインスタンス６’’が生成されて、禁止ドメイン１６に割り当てられたメモリに保存される。このプロセスは、制御・監視システム２４によって検知されて、報告される。場合によっては、警報メッセージを作成するか、シミュレーションの進行を中止するか、或いはその両方が可能である。時点（ｄ）で、クリティカルなデータのオリジナルが破壊される（即ち、例えば、上書きされるか、削除される）。しかし、この時点では、第一のインスタンス６’が依然として（しかし、許容ドメインに）存在する。このことも、記録されて、通報される。このようにして、監視されているクリティカルなデータ６の全てのインスタンスとそれへのアクセスを検知することができる。新しいインスタンスは、典型的には、新しいサブツリーの開始ノードを形成する。

実際には、上述した評価１４は、例えば、以下のプロセスを文書化することができる。監視されているデータが、外部メモリからＣＰＵのレジスタにロードされる。しかし、それによって、典型的には、ＣＰＵのレジスタ内のデータが削除又は上書きされた場合にも存在するコピーが（場合によっては、複数のレベルにおいてさえ）キャッシュに発生する可能性がある。即ち、このコピー（即ち、第一のインスタンス６’）を新たに監視しなければならず、従って、相応の状態でグラフ内に新しい分岐を形成する（例えば、キャッシュに割り当てられる）。バスを介したデータの伝送も、場合によっては、同じバスに繋がっている全ての受信機がその時点でそのデータを読み取ること（それに続いて、コピー又は処理すること）を可能にする。このことも、新しい枝によって、グラフ内に文書化されて、更に追跡される。

別の可能性は、監視されているデータの処理である。例えば、シフト命令によって、データが、二進の形で一定数のビット位置だけずらされて、それにより変更される。この結果は、監視されているデータに依存し、そのため、同じく新しい枝としてグラフ内に文書化されて、更に追跡される。

ここに開示した措置は、例えば、特に、車両において、制御機器及びバスシステムにおける「機密性」や「プライバシー」などの特性をテスト及び診断するための新しいツールファミリーの開発を可能にする。特に、自動化を支援された、或いは自律的な車両の開発との関連において、駆動系統、走行機能、車両通信、乗客の快適性（ｅＨｅａｌｔｈも）及び積載量管理に関する来るべき制御機器が、人に関連するデータ又は使命に関して重要なデータを益々処理することになろう。そのようなデータは、定義された形式及び手法でのみ開示又は転送されることを許されて、決して予期せぬ形で、或いは集中的な攻撃により傍受可能であってはならない。本発明を用いて、様々なハードウェアシステムを任意の深さの詳細度で安全性に関連するデータストリームに関してテストすることが可能である。これらのテストは、任意の拡がりで拡張可能であり、例えば、複数の互いに協力して動作するシステムをシミュレーションすることができる。同様に詳細度の深さが拡張可能なことによって、異なるレベルで（アプリケーションソフトウェアで、オペレーティングシステムで、ハイパーバイザーでも、或いは更に深いレベルで）、ハードウェアの実装形態において直にエラーを探し出すことができる（これは、例えば、サイドチャネル攻撃と関連する可能性がある）。

１ ハードウェアシステム
２ データ処理タスク
３ メモリユニット
４ シミュレーション環境
５ シミュレーションモデル
６ クリティカルなデータ
７ ハードウェアコンポーネント
８ 通信機器
９ 通信ユニット
１０ プロセッサユニット
１１ オペレーティングシステム
１２ アプリケーションソフトウェア
１３ パラメータデータ
１４ 評価
１５ 許容ドメイン
１６ 禁止ドメイン
１７ プロセッサ
１８ プロセッサコア
１９ プロセッサキャッシュ
２０ プロセッサＩＯ
２１ バス装置
２２ 別のコンポーネント
２３ 試験者
２４ 制御・監視システム
２５ ユーザーインターフェース

Claims (10)

1. 少なくとも一つのデータ処理タスク（２）の実行中にハードウエアシステム（１）に発生する安全性に関連するデータフローを検出する方法において、
   このハードウエアシステム（１）の少なくとも一つのメモリユニット（３）に保存できるか、インタフェースを介して、このハードウエアシステム（１）に伝送できるか、或いはその両方が可能であるクリティカルなデータ（６）を定義する工程と、
   このハードウエアシステム（１）をシミュレーション環境（４）において実行可能なシミュレーションモデル（５）にマッピングする工程と、
   このシミュレーション環境（４）において、シミュレーションモデル（５）によるシミュレーションとしてデータ処理タスク（２）を実行する工程と、
   このデータ処理タスク（２）の実行中に、シミュレーションモデル（５）においてクリティカルなデータ（６）及びクリティカルなデータ（６）のインスタンス（６’，６’’）の作成、送信及び削除を監視する工程と、
   安全性に関連するデータストリームを特定して、ログに記録する工程とを特徴とする方法。
2. ハードウエアシステム（１）をシミュレーションモデル（５）にマッピングするために、ハードウエアシステム（１）が、少なくとも一つの通信機器（８）を介して互いに接続されるとともに、この通信機器（８）を介してデータを交換できる多数のハードウェアコンポーネント（７）に分割されて、各ハードウェアコンポーネント（７）が、少なくとも一つの通信ユニット（９）、少なくとも一つのメモリユニット（３）及び少なくとも一つのプロセッサユニット（１０）を有することを特徴とする請求項１に記載の方法。
3. クリティカルなデータ（６）の定義がデータ特性の定義によって行われることを特徴とする請求項１又は２に記載の方法。
4. 少なくとも所定の安全性に関連するデータストリームが特定された場合に、警報メッセージが作成されることを特徴とする請求項１〜３のいずれか１項に記載の方法。
5. 特定された安全性に関連するデータストリームが評価（１４）に保存されることを特徴とする請求項１〜４のいずれか１項に記載の方法。
6. 前記の評価（１４）がグラフィック表示されることを特徴とする請求項５に記載の方法。
7. シミュレーションの進行状況がログに記録されることを特徴とする請求項１〜６のいずれか１項に記載の方法。
8. データ処理タスク（２）が、場合によっては、定義されたテストケースの処理時に動作させるアプリケーションソフトウェア（１２）の実行から発生することを特徴とする請求項１〜７のいずれか１項に記載の方法。
9. 本方法が、ハードウェアシステムの区画を許容ドメイン（１５）と禁止ドメイン（１６）に分割する工程を更に有することを特徴とする請求項１〜８のいずれか１項に記載の方法。
10. 安全性に関連するデータストリームとして、少なくとも、
    クリティカルなデータ（６）又はそのインスタンス（６’，６’’）が禁止ドメイン（１６）の通信機器（８）を介して送信されるデータストリーム、
    クリティカルなデータ（６）が削除される一方で、そのクリティカルなデータ（６）のインスタンス（６’，６’’）が存在し続けるデータストリーム、
    禁止ドメイン（１６）でクリティカルなデータ（６）のインスタンス（６’，６’’）が作成されるデータストリーム、
    所定の時点及び／又はシステム状態の後で、特に、データ処理タスクの完了後に、クリティカルなデータが存在し続けるデータストリーム、
    が特定されることを特徴とする請求項９に記載の方法。

Images