(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2022-09-30
(54)【発明の名称】ＣＡＮバス保護システムおよび方法
(51)【国際特許分類】
G06F 21/55 20130101AFI20220922BHJP
【ＦＩ】
G06F21/55
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2022504153
(86)(22)【出願日】2020-07-22
(85)【翻訳文提出日】2022-03-15
(86)【国際出願番号】 US2020042995
(87)【国際公開番号】W WO2021016307
(87)【国際公開日】2021-01-28
(31)【優先権主張番号】62/878,419
(32)【優先日】2019-07-25
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
(71)【出願人】
【識別番号】591072086
【氏名又は名称】バテル メモリアル インスティチュート
(74)【代理人】
【識別番号】100078282
【弁理士】
【氏名又は名称】山本 秀策
(74)【代理人】
【識別番号】100113413
【弁理士】
【氏名又は名称】森下 夏樹
(72)【発明者】
【氏名】ウィー， コリン
(72)【発明者】
【氏名】ロベルド， イアン
(72)【発明者】
【氏名】ソーントン， ダグラス エー．
(57)【要約】
ＣＡＮバス信号フォーマット推論は、訓練ＣＡＮバスメッセージトラフィックから候補信号を抽出することと、１つ以上の信号を定義することであって、各信号は、合致するデータタイプの構造的特性に合致する候補信号であり、各信号は、合致するデータタイプを割り当てられる、ことと、定義された１つ以上の信号が準拠する、推論されたＣＡＮバスプロトコルを発生させることとを含む。信号が、推論されたＣＡＮバスプロトコルを使用して、ＣＡＮバスメッセージトラフィックから抽出され、抽出された信号の異常が、検出され、検出された異常を示すアラートが、発生される。別の側面では、トランスポートプロトコル（ＴＰ）信号が、機械言語命令セットのオペコードに合致するＴＰ信号の割合を判定するために抽出および分析され、異常が、少なくとも部分的に、判定された割合がオペコード異常閾値を超えることに基づいて検出される。
【選択図】図１
【選択図】図１
【特許請求の範囲】
【請求項1】
電子デバイスであって、コントローラエリアネットワーク（ＣＡＮ）バスと通信可能に結合される、電子プロセッサと、
複数のＣＡＮバスプロトコルを表す記述子ファイルと、ＣＡＮバスセキュリティ方法を実施するために前記電子プロセッサによって可読かつ実行可能な命令とを記憶する、非一過性記憶媒体であって、前記方法は、
前記ＣＡＮバス上のＣＡＮバスメッセージトラフィックから信号を抽出することであって、各抽出された信号は、前記複数のＣＡＮバスプロトコルのうちの１つに準拠する、ことと、
抽出された信号の異常を検出することと、
前記検出された異常を示すアラートを発生させることと
を含む、非一過性記憶媒体と
を備える、電子デバイス。
【請求項2】
訓練ＣＡＮバスメッセージトラフィックから候補信号を抽出することであって、各候補信号は、前記ＣＡＮバスメッセージトラフィック内のデータビットの順序付けられたグループの繰り返しの時間シーケンスであり、前記データビットの順序付けられたグループは、１つ以上のメッセージヘッダによって区切られる、ことと、１つ以上の信号を定義することであって、各信号は、合致するデータタイプの構造的特性に合致する候補信号であり、各信号は、前記合致するデータタイプを割り当てられる、ことと、
前記定義された１つ以上の信号が準拠する、推論されたＣＡＮバス信号フォーマットを表す記述子ファイルを発生させることと
を含む、ＣＡＮバス信号フォーマット推論方法を実施するように構成される、電子機器をさらに備え、
前記複数のＣＡＮバスプロトコルは、前記推論されたＣＡＮバス信号フォーマットを含み、
前記電子機器は、（ｉ）前記電子プロセッサ、および前記ＣＡＮバス信号フォーマット推論方法を実施するために前記電子プロセッサによって可読かつ実行可能な命令をさらに記憶する、前記非一過性記憶媒体、および／または（ｉｉ）前記電子プロセッサと異なる訓練電子プロセッサ、および前記非一過性記憶媒体と異なり、前記ＣＡＮバス信号フォーマット推論方法を実施するために前記訓練電子プロセッサによって可読かつ実行可能な命令を記憶する、訓練非一過性記憶媒体のうちの少なくとも１つを備える、請求項１に記載の電子デバイス。
【請求項3】
前記１つ以上の信号を定義することは、カウンタデータタイプを割り当てられた信号を、前記カウンタデータタイプによって定義された前記データビットの順序付けられたグループの値が、前記データビットの順序付けられたグループの時間シーケンスにわたって単調に増加する、または単調に減少する、前記カウンタデータタイプの構造的特性に合致する候補信号として定義することを含む、請求項２に記載の電子デバイス。
【請求項4】
前記１つ以上の信号を定義することは、定数データタイプを割り当てられた信号を、前記データビットの順序付けられたグループの値が、前記データビットの順序付けられたグループの時間シーケンスにわたって一定である、前記定数データタイプの構造的特性に合致する候補信号として定義することを含む、請求項２－３のいずれか１項に記載の電子デバイス。
【請求項5】
前記１つ以上の信号を定義することは、指数および仮数を有する浮動小数点データタイプを割り当てられた信号を、
１６、３２、または６４ビットである前記データビットの順序付けられたグループと、
前記浮動小数点データタイプの仮数を表す前記データビットの順序付けられたグループの第２のサブセットよりも前記時間シーケンスにわたって低いエントロピを有する、前記浮動小数点データタイプの指数を表す前記データビットの順序付けられたグループの第１のサブセットと
を含む、前記浮動小数点データタイプの構造的特性に合致する候補信号として定義することを含む、請求項２－４のいずれか１項に記載の電子デバイス。
【請求項6】
前記１つ以上の信号を定義することは、整数データタイプを割り当てられた信号を、
４、８、１２、１６、または３２ビットである前記データビットの順序付けられたグループと、
前記整数データタイプの最下位ビットを表す前記データビットの順序付けられたグループの第２のサブセットよりも前記時間シーケンスにわたって低いエントロピを有する、前記整数データタイプの最上位ビットを表す前記データビットの順序付けられたグループの第１のサブセットと
を含む、前記整数データタイプの構造的特性に合致する候補信号として定義することを含む、請求項２－５のいずれか１項に記載の電子デバイス。
【請求項7】
前記整数データタイプを割り当てられた前記信号を定義することは、連続性基準を満たす前記時間シーケンスにわたる連続性を有する、前記整数データタイプによって定義された前記データビットの順序付けられたグループの値と、
エントロピ基準を満たす前記時間シーケンスにわたる連続性を有する、前記整数データタイプによって定義された前記データビットの順序付けられたグループの値と
をさらに含む、前記整数データタイプの前記構造的特性に合致する、請求項６に記載の電子デバイス。
【請求項8】
前記１つ以上の信号を定義することは、ビットフィールドデータタイプを割り当てられた信号を、前記データビットの順序付けられたグループの値が、バイナリ状態を示す、前記ビットフィールドデータタイプの構造的特性に合致する候補信号として定義することを含む、請求項２－７のいずれかに記載の電子デバイス。
【請求項9】
前記抽出することは、初期時間間隔にわたって実施され、前記検出することは、前記初期時間間隔に続く後の時間間隔にわたって、前記複数のＣＡＮバスプロトコルのうちの準拠する１つからの前記抽出された信号のうちの１つの逸脱を検出することを含む、請求項１－８のいずれか１項に記載の電子デバイス。
【請求項10】
前記記述子ファイルは、ＤＢＣファイルである、請求項１－９のいずれか１項に記載の電子デバイス。
【請求項11】
前記非一過性記憶媒体はさらに、１つ以上の機械言語命令セットを記憶し、各機械言語命令セットは、オペコードのセットを備え、前記抽出することは、ＣＡＮ－ＴＰプロトコルに準拠する複数のメッセージのデータバイトを備える、トランスポートプロトコル（ＴＰ）信号を抽出することを含み、
前記検出することは、
前記１つ以上の機械言語命令セットの機械言語命令セット毎に、前記機械言語命令セットのオペコードに合致する前記ＴＰ信号の割合を判定することと、
少なくとも部分的に、前記判定された割合のうちの少なくとも１つがオペコード異常閾値を超えることに基づいて、異常を検出することと
を含む、請求項１－１０のいずれか１項に記載の電子デバイス。
【請求項12】
電子デバイスであって、コントローラエリアネットワーク（ＣＡＮ）バスと通信可能に結合される、電子プロセッサと、
（ｉ）各機械言語命令セットが、オペコードのセットを備える、１つ以上の機械言語命令セットと、（ｉｉ）ＣＡＮバスセキュリティ方法を実施するために前記電子プロセッサによって可読かつ実行可能な命令とを記憶する、非一過性記憶媒体であって、前記方法は、
前記ＣＡＮバス上のＣＡＮバスメッセージトラフィックからＣＡＮ－ＴＰプロトコルに準拠する複数のメッセージのデータバイトを備える、トランスポートプロトコル（ＴＰ）信号を抽出することと、
前記１つ以上の機械言語命令セットの機械言語命令セット毎に、前記機械言語命令セットのオペコードに合致する前記ＴＰ信号の割合を判定することと、
少なくとも部分的に、前記判定された割合のうちの少なくとも１つがオペコード異常閾値を超えることに基づいて、異常を検出することと
を含む、非一過性記憶媒体と
を備える、電子デバイス。
【請求項13】
前記検出することは、前記ＴＰ信号を前記機械言語命令セットのオペコードと合致させる前に、前記ＴＰ信号のバイトに対してエンディアン補正を実施することを含む、請求項１２に記載の電子デバイス。
【請求項14】
前記検出することは、前記ＴＰ信号を前記機械言語命令セットのオペコードと合致させる前に、前記ＴＰ信号のバイトに対してバイトローテーションを実施することを含む、請求項１２－１３のいずれか１項に記載の電子デバイス。
【請求項15】
前記検出することは、（Ｉ）前記判定された割合のうちの少なくとも１つが、オペコード異常閾値を超え、（ＩＩ）前記ＴＰ信号が、許可されたファームウェア更新として識別されない場合、異常を検出することを含む、請求項１２－１４のいずれか１項に記載の電子デバイス。
【請求項16】
ＣＡＮバス信号フォーマット推論方法を実施するために少なくとも１つの電子プロセッサによって可読かつ実行可能な命令を記憶する非一過性記憶媒体であって、前記方法は、訓練ＣＡＮバスメッセージトラフィックから候補信号を抽出することであって、各候補信号は、前記ＣＡＮバスメッセージトラフィック内のデータビットの順序付けられたグループの繰り返しの時間シーケンスであり、前記データビットの順序付けられたグループは、１つ以上のメッセージヘッダによって区切られる、ことと、
１つ以上の信号を定義することであって、各信号は、合致するデータタイプの構造的特性に合致する候補信号であり、各信号は、前記合致するデータタイプを割り当てられる、ことと、
前記定義された１つ以上の信号が準拠する、推論されたＣＡＮバスプロトコルを発生させることと
を含む、非一過性記憶媒体。
【請求項17】
前記１つ以上の信号を定義することは、カウンタデータタイプを割り当てられた信号を、前記カウンタデータタイプによって定義された前記データビットの順序付けられたグループの値が、前記データビットの順序付けられたグループの時間シーケンスにわたって単調に増加する、または単調に減少する、前記カウンタデータタイプの構造的特性に合致する候補信号として定義することを含む、請求項１６に記載の非一過性記憶媒体。
【請求項18】
前記１つ以上の信号を定義することは、定数データタイプを割り当てられた信号を、前記データビットの順序付けられたグループの値が、前記データビットの順序付けられたグループの時間シーケンスにわたって一定である、前記定数データタイプの構造的特性に合致する候補信号として定義することを含む、請求項１６－１７のいずれか１項に記載の非一過性記憶媒体。
【請求項19】
前記１つ以上の信号を定義することは、指数および仮数を有する浮動小数点データタイプを割り当てられた信号を、
１６、３２、または６４ビットである前記データビットの順序付けられたグループと、
前記浮動小数点データタイプの仮数を表す前記データビットの順序付けられたグループの第２のサブセットよりも前記時間シーケンスにわたって低いエントロピを有する、前記浮動小数点データタイプの指数を表す前記データビットの順序付けられたグループの第１のサブセットと
を含む、前記浮動小数点データタイプの構造的特性に合致する候補信号として定義することを含む、請求項１６－１８のいずれか１項に記載の非一過性記憶媒体。
【請求項20】
前記１つ以上の信号を定義することは、整数データタイプを割り当てられた信号を、
４、８、１２、１６、または３２ビットである前記データビットの順序付けられたグループと、
前記整数データタイプの最下位ビットを表す前記データビットの順序付けられたグループの第２のサブセットよりも前記時間シーケンスにわたって低いエントロピを有する、前記整数データタイプの最上位ビットを表す前記データビットの順序付けられたグループの第１のサブセットと
を含む、前記整数データタイプの構造的特性に合致する候補信号として定義することを含む、請求項１６－１９のいずれか１項に記載の非一過性記憶媒体。
【請求項21】
前記整数データタイプを割り当てられた前記信号を定義することは、連続性基準を満たす前記時間シーケンスにわたる連続性を有する、前記整数データタイプによって定義された前記データビットの順序付けられたグループの値と、
エントロピ基準を満たす前記時間シーケンスにわたる連続性を有する、前記整数データタイプによって定義された前記データビットの順序付けられたグループの値と
をさらに含む、前記整数データタイプの前記構造的特性に合致する、請求項２０に記載の非一過性記憶媒体。
【請求項22】
前記１つ以上の信号を定義することは、ビットフィールドデータタイプを割り当てられた信号を、前記データビットの順序付けられたグループの値が、バイナリ状態を示す、前記ビットフィールドデータタイプの構造的特性に合致する候補信号として定義することを含む、請求項１６－１９のいずれか１項に記載の非一過性記憶媒体。
【請求項23】
ＣＡＮバス上のＣＡＮバスメッセージトラフィックから信号を抽出することであって、前記抽出された信号は、前記推論されたＣＡＮバスプロトコルに準拠する、ことと、前記抽出された信号の異常を検出することと、
前記検出された異常を示すアラートを発生させることと
を含む、ＣＡＮバス信号フォーマット推論方法を実施するために少なくとも１つの電子プロセッサによって可読かつ実行可能な命令をさらに記憶する、請求項１６－２２のいずれか１項に記載の非一過性記憶媒体。
【発明の詳細な説明】
【技術分野】
【0001】
（関連出願の相互参照）
本願は、参照することによってその全体として本明細書に組み込まれる、２０１９年７月２５日に出願され、「ＣＡＮ ＢＵＳ ＰＲＯＴＥＣＴＩＯＮ ＳＹＳＴＥＭＳ ＡＮＤ ＭＥＴＨＯＤＳ」と題された、米国仮特許出願第６２／８７８，４１９号の利益を主張する。
本願は、参照することによってその全体として本明細書に組み込まれる、２０１９年７月２５日に出願され、「ＣＡＮ ＢＵＳ ＰＲＯＴＥＣＴＩＯＮ ＳＹＳＴＥＭＳ ＡＮＤ ＭＥＴＨＯＤＳ」と題された、米国仮特許出願第６２／８７８，４１９号の利益を主張する。
【0002】
以下は、電子データネットワークセキュリティ技術、コントローラエリアネットワーク（ＣＡＮ）セキュリティ技術、電子制御ユニット（ＥＣＵ）セキュリティ技術、地上車両電子セキュリティ技術、水上車両電子セキュリティ技術、宇宙車両電子セキュリティ技術、および同等物に関する。
【背景技術】
【0003】
（背景）
現代の車両は、アンチブレーキシステム（ＡＢＳ）モジュール、機関制御モジュール、および操向、スロットル、走行制御、気候制御システム、ならびに種々の他の車両機能を制御するためのモジュール等のモジュール化された電子コンポーネントを採用する。これらのモジュールは、ＣＡＮバスを用いて相互通信する。車両エンターテインメントシステム、ナビゲーションシステム等の補助システムもまた、時として、ＣＡＮバスに接続されるＥＣＵを含む。アプリケーション層におけるＣＡＮバスを経由する通信は、アービトレーション識別子（ＡＲＢ ＩＤ）と、最大８のデータバイトとから成る。ＡＲＢ ＩＤは、メッセージ内に含有されるデータの意味を示す。例えば、車輪速度は、４つの車輪毎の回転速度を表す２バイトのデータを伴うＡＲＢ ＩＤ ０ｘ３５４上に含有され得る。車輪速度を把握する必要性を有する車両上の全てのＥＣＵは、ＡＲＢ ＩＤ ０ｘ３５４を車輪速度と関連付けるようにプログラムされる。データバイトによって伝えられる情報は、信号と称される。メッセージあたり最大８バイトを用いて、単一のメッセージが、最大８バイトの任意の信号を伝えることができる。さらに、単一のメッセージが、個々の信号が、８よりも少ないバイトによって表される場合、２つ以上の信号を伝えることができる（それぞれ、単一のバイトから成る、最大８つの信号）。逆に、８を上回るバイトを要求する信号が、２つ以上のメッセージによって伝えられることができる。そのような状況の実施例は、ファームウェア更新をＥＣＵに送信することである。ファームウェア更新は、単一の信号と見なされるが、数百、数千、またはそれを上回るバイトから成り得るものであり得る。そのような状況に対処するために、ＣＡＮ－ＴＰプロトコル（「ＴＰ」は、「転送プロトコル」を示す）として公知である、アプリケーション層ＣＡＮプロトコルが、複数のメッセージを介してファームウェア更新等のより長い信号を送信することを可能にする。国際規格ＩＳＯ １５７６５－２（ＩＳＯ－ＴＰとしても公知である）は、ＣＡＮ－ＴＰプロトコルの一般的実装であるが、しかしながら、同一の機能を達成する他のプロトコルも、存在する。
現代の車両は、アンチブレーキシステム（ＡＢＳ）モジュール、機関制御モジュール、および操向、スロットル、走行制御、気候制御システム、ならびに種々の他の車両機能を制御するためのモジュール等のモジュール化された電子コンポーネントを採用する。これらのモジュールは、ＣＡＮバスを用いて相互通信する。車両エンターテインメントシステム、ナビゲーションシステム等の補助システムもまた、時として、ＣＡＮバスに接続されるＥＣＵを含む。アプリケーション層におけるＣＡＮバスを経由する通信は、アービトレーション識別子（ＡＲＢ ＩＤ）と、最大８のデータバイトとから成る。ＡＲＢ ＩＤは、メッセージ内に含有されるデータの意味を示す。例えば、車輪速度は、４つの車輪毎の回転速度を表す２バイトのデータを伴うＡＲＢ ＩＤ ０ｘ３５４上に含有され得る。車輪速度を把握する必要性を有する車両上の全てのＥＣＵは、ＡＲＢ ＩＤ ０ｘ３５４を車輪速度と関連付けるようにプログラムされる。データバイトによって伝えられる情報は、信号と称される。メッセージあたり最大８バイトを用いて、単一のメッセージが、最大８バイトの任意の信号を伝えることができる。さらに、単一のメッセージが、個々の信号が、８よりも少ないバイトによって表される場合、２つ以上の信号を伝えることができる（それぞれ、単一のバイトから成る、最大８つの信号）。逆に、８を上回るバイトを要求する信号が、２つ以上のメッセージによって伝えられることができる。そのような状況の実施例は、ファームウェア更新をＥＣＵに送信することである。ファームウェア更新は、単一の信号と見なされるが、数百、数千、またはそれを上回るバイトから成り得るものであり得る。そのような状況に対処するために、ＣＡＮ－ＴＰプロトコル（「ＴＰ」は、「転送プロトコル」を示す）として公知である、アプリケーション層ＣＡＮプロトコルが、複数のメッセージを介してファームウェア更新等のより長い信号を送信することを可能にする。国際規格ＩＳＯ １５７６５－２（ＩＳＯ－ＴＰとしても公知である）は、ＣＡＮ－ＴＰプロトコルの一般的実装であるが、しかしながら、同一の機能を達成する他のプロトコルも、存在する。
【0004】
ＣＡＮバスは、有利なこととして、新しい電子コンポーネントのアドホック追加を可能にする。これは、異なる特徴を伴う様々なモデルにおける車両を販売する自動車製造業者にとって理想的であり、加えて、（例えば）アフターマーケット音響システムを供給するアフターマーケット製造業者にとっても理想的である。
【0005】
しかしながら、本オープンアーキテクチャは、セキュリティ課題を導入する。ＣＡＮバス上の任意のＥＣＵ（またはより一般的に、ＣＡＮバス上の任意の電子デバイス）が、ＣＡＮバスと接続され得（もしくはＣＡＮバスとすでに接続されているＥＣＵが、セキュリティ侵害され得）、次いで、ＣＡＮバス上でメッセージを伝送し得、これらのメッセージは、ＣＡＮバス上で全てのＥＣＵまたは他の電子デバイスによって受信される。メッセージは、セキュアな様式で送信者を識別するための認証を含まない。したがって、デバイスが、正当な伝送において使用されるものと同一のＡＲＢ ＩＤヘッダおよびペイロードフォーマットを採用することによって、正当な伝送を模倣するようにプログラムされるＣＡＮバス（またはそのようにプログラムされるようにセキュリティ侵害される既存のデバイス）に追加され、それによって、ＣＡＮバスを介して、不正な、潜在的に悪意のある活動を実施することに対して、いかなる障壁も、存在しない。そのような悪意のある活動は、データの不正な収集から、危険なスロットルまたは制動アクションを誘発すること等の潜在的に生命を危うくするアクションに及び得る。ＣＡＮ－ＴＰ伝送のペイロード容量が大きくなると、悪意のあるコードをＥＣＵに伝送し、それによって、ＥＣＵのファームウェアをハッキングし、悪意のある行為を実施するようにこれを再プログラムする潜在性さえも、存在する。
【0006】
２０１７年１０月１７日に発行され、「Ａｎｏｍａｌｙ Ｄｅｔｅｃｔｉｏｎ ｆｏｒ Ｖｅｈｉｃｕｌａｒ Ｎｅｔｗｏｒｋｓ ｆｏｒ Ｉｎｔｒｕｓｉｏｎ ａｎｄ Ｍａｌｆｕｎｃｔｉｏｎ Ｄｅｔｅｃｔｉｏｎ」と題された、Ｈａｒｒｉｓ ｅｔ ａｌ．の米国特許第９，７９２，４３５号が、参照することによってその全体として本明細書に組み込まれる。２０１８年９月２５日に発行され、「Ｔｅｍｐｏｒａｌ Ａｎｏｍａｌｙ Ｄｅｔｅｃｔｉｏｎ ｏｎ Ａｕｔｏｍｏｔｉｖｅ Ｎｅｔｗｏｒｋｓ」と題された、Ｓｏｎａｌｋｅｒ ｅｔ ａｌ．の米国特許第１０，０８３，０７１号が、参照することによってその全体として本明細書に組み込まれる。これらの特許は、ＣＡＮバス上で異常なメッセージングを検出し、それによって、ＣＡＮバス上の潜在的に悪意のある活動のアラートを提供するためのいくつかのアプローチを説明している。
故に、ＣＡＮアーキテクチャのセキュリティおよび応答性に対するある改良が、本明細書に提供される。
故に、ＣＡＮアーキテクチャのセキュリティおよび応答性に対するある改良が、本明細書に提供される。
【先行技術文献】
【特許文献】
【0007】
【特許文献1】米国特許第９，７９２，４３５号公報
【特許文献2】米国特許第１０，０８３，０７１号公報
【発明の概要】
【課題を解決するための手段】
【0008】
（簡単な要約）
本明細書に開示されるいくつかの例証的実施形態によると、電子デバイスは、コントローラエリアネットワーク（ＣＡＮ）バスと通信可能に結合される、電子プロセッサと、複数のＣＡＮバスプロトコルを表す記述子ファイルおよびＣＡＮバスセキュリティ方法を実施するために電子プロセッサによって可読かつ実行可能な命令を記憶する、非一過性記憶媒体とを備える。本方法は、ＣＡＮバス上のＣＡＮバスメッセージトラフィックから信号を抽出することであって、各抽出された信号は、複数のＣＡＮバスプロトコルのうちの１つに準拠する、ことと、抽出された信号の異常を検出することと、検出された異常を示すアラートを発生させることとを含む。
本明細書に開示されるいくつかの例証的実施形態によると、電子デバイスは、コントローラエリアネットワーク（ＣＡＮ）バスと通信可能に結合される、電子プロセッサと、複数のＣＡＮバスプロトコルを表す記述子ファイルおよびＣＡＮバスセキュリティ方法を実施するために電子プロセッサによって可読かつ実行可能な命令を記憶する、非一過性記憶媒体とを備える。本方法は、ＣＡＮバス上のＣＡＮバスメッセージトラフィックから信号を抽出することであって、各抽出された信号は、複数のＣＡＮバスプロトコルのうちの１つに準拠する、ことと、抽出された信号の異常を検出することと、検出された異常を示すアラートを発生させることとを含む。
【0009】
いくつかの実施形態では、直前の段落の電子デバイスはさらに、訓練ＣＡＮバスメッセージトラフィックから候補信号を抽出することであって、各候補信号は、ＣＡＮバスメッセージトラフィック内のデータビットの順序付けられたグループの繰り返しの時間シーケンスであり、データビットの順序付けられたグループは、１つ以上のメッセージヘッダによって区切られる、ことと、１つ以上の信号を定義することであって、各信号は、合致するデータタイプの構造的特性に合致する候補信号であり、各信号は、合致するデータタイプを割り当てられる、ことと、定義された１つ以上の信号が準拠する、推論されたＣＡＮバス信号フォーマットを表す記述子ファイルを発生させることとを含む、ＣＡＮバス信号フォーマット推論方法を実施するように構成される、電子機器を備える。直前の段落に言及される複数のＣＡＮバスプロトコルは、次いで、推論されたＣＡＮバス信号フォーマットを含む。電子機器は、電子プロセッサと、記憶媒体がさらに、ＣＡＮバス信号フォーマット推論方法を実施するために電子プロセッサによって可読かつ実行可能な命令を記憶する、直前の段落の非一過性記憶媒体とを備えてもよい、および／または直前の段落の電子プロセッサと異なる訓練電子プロセッサと、訓練記憶媒体が、ＣＡＮバス信号フォーマット推論方法を実施するために訓練電子プロセッサによって可読かつ実行可能な命令を記憶する、直前の段落の非一過性記憶媒体と異なる訓練非一過性記憶媒体とを備えてもよい。
【0010】
本明細書に開示されるいくつかの例証的実施形態によると、非一過性記憶媒体は、訓練ＣＡＮバスメッセージトラフィックから候補信号を抽出することであって、各候補信号は、ＣＡＮバスメッセージトラフィック内のデータビットの順序付けられたグループの繰り返しの時間シーケンスであり、データビットの順序付けられたグループは、１つ以上のメッセージヘッダによって区切られる、ことと、１つ以上の信号を定義することであって、各信号は、合致するデータタイプの構造的特性に合致する候補信号であり、各信号は、合致するデータタイプを割り当てられる、ことと、定義された１つ以上の信号が準拠する、推論されたＣＡＮバス信号フォーマットを発生させることとを含む、ＣＡＮバス信号フォーマット推論方法を実施するために少なくとも１つの電子プロセッサによって可読かつ実行可能な命令を記憶する。
【0011】
本明細書に開示されるいくつかの例証的実施形態によると、電子デバイスは、コントローラエリアネットワーク（ＣＡＮ）バスと接続可能な電子プロセッサと、（ｉ）各機械言語命令セットが、オペコードのセットを備える、１つ以上の機械言語命令セットと、（ｉｉ）ＣＡＮバスセキュリティ方法を実施するために電子プロセッサによって可読かつ実行可能な命令とを記憶する、非一過性記憶媒体とを備える。本方法は、ＣＡＮバス上のＣＡＮバスメッセージトラフィックからＣＡＮ ＴＰプロトコルに準拠する複数のメッセージのデータバイトを備える、トランスポートプロトコル（ＴＰ）信号を抽出することと、１つ以上の機械言語命令セットの機械言語命令セット毎に、機械言語命令セットのオペコードに合致するＴＰ信号の割合を判定することと、少なくとも部分的に、判定された割合のうちの少なくとも１つがオペコード異常閾値を超えることに基づいて、異常を検出することとを含む。
【図面の簡単な説明】
【0012】
図面に示される任意の定量的寸法は、非限定的な例証的実施例として理解されるものである。別様に示されない限り、図面は、縮尺通りではなく、図面の任意の側面が、縮尺通りであるとして示される場合、図示される縮尺は、非限定的な例証的実施例として理解されるものである。
【0013】
【0014】
【0015】
【0016】
【0017】
【発明を実施するための形態】
【0018】
（詳細な説明）
ＣＡＮバスセキュリティの文脈における異常検出の目標は、疑わしいと見なされ得るＣＡＮバス上の異常なメッセージを検出することである。本アプローチは、ＣＡＮバス上のトラフィックを監視する一般的なセキュリティコンポーネントから見ると、ＣＡＮバスメッセージの情報コンテンツが、概して、未知であるため、採用される。したがって、通常ではない、すなわち、異常なメッセージの検出は、情報コンテンツの知識に基づく検出のための代用物としての役割を果たす。加えて、検出された異常は、コンポーネント故障の予示を表し、保守問題と関連付けられ得る。
ＣＡＮバスセキュリティの文脈における異常検出の目標は、疑わしいと見なされ得るＣＡＮバス上の異常なメッセージを検出することである。本アプローチは、ＣＡＮバス上のトラフィックを監視する一般的なセキュリティコンポーネントから見ると、ＣＡＮバスメッセージの情報コンテンツが、概して、未知であるため、採用される。したがって、通常ではない、すなわち、異常なメッセージの検出は、情報コンテンツの知識に基づく検出のための代用物としての役割を果たす。加えて、検出された異常は、コンポーネント故障の予示を表し、保守問題と関連付けられ得る。
【0019】
ＣＡＮバスは、広い範囲の上位層信号フォーマットをサポートし得る、物理的トランスポート層を提供する。信号の信号フォーマットは、信号と関連付けられるメッセージヘッダ（例えば、具体的ＡＲＢ ＩＤまたはその部分）を識別し、信号が準拠する構造的表現を定義する。構造的表現は、典型的には、データタイプ（例えば、カウンタ、定数、整数、浮動小数点）と、バイトカウント、エンディアン等の関連付けられる性質とを含む。これらの上位層信号フォーマットのうちのいくつかは、信号フォーマットがＤＢＣファイルまたは他の信号フォーマット記憶装置として公的に利用可能である、公開されたプロトコルである。公開されたＣＡＮバスプロトコルのいくつかの実施例は、ＳＡＥ Ｊ１９３９、ＩＳＯ１４２２９、ＭｉｌＣＡＮ等を含む。公開されたＣＡＮバスプロトコルの場合であっても、異常の検出は、メッセージの情報コンテンツが、例えば、公開されたプロトコルの一部が、独自データに関して留保されるとき、常に把握されるわけではないため、困難である。それにもかかわらず、公開されたプロトコルの知識は、伝えられている信号の信号フォーマットに関する情報を提供する。例えば、公開されたプロトコルの知識は、異常検出が、メッセージのデータバイトの所与のセットが整数データタイプの（または浮動小数点データタイプ等の）信号を表すことを認識することを可能にする。本知識は、予期せぬ信号値に基づいて等、より洗練された異常検出を可能にする。
【0020】
しかしながら、いくつかのＥＣＵは、その信号フォーマットが公的に把握されていない独自信号を使用して、ＣＡＮバス上で通信する。この場合では、情報コンテンツが、未知であるだけではなく、信号フォーマットさえも、未知である。これは、実質的に、異常検出に関する課題を増加させる。Ｈａｒｒｉｓ ｅｔ ａｌ．の米国特許第９，７９２，４３５号およびＳｏｎａｌｋｅｒ ｅｔ ａｌ．の米国特許第１０，０８３，０７１号に開示されるもの等の信号非依存異常検出器が、構築されることができる。しかしながら、信号およびそれらの信号フォーマットに関する付加的情報は、より高度な異常検出を可能にするであろう。
【0021】
本明細書に開示されるいくつかの異常検出アプローチは、データが、概して、構造化される方法の知識が、独自メッセージ内の構造を推論するために使用され得るという本明細書で行われる洞察を活用する。構造を推論することによって、基礎データは、ＣＡＮバスメッセージ内で伝えられる信号の識別および信号のデータタイプを含む、構造化データとして扱われる。構造の本知識は、訓練時間を減少させ、下流の異常検出アルゴリズムの有効性を増加させることができる。信号抽出のための開示されるアプローチは、基礎データが構造化される（すなわち、指定された信号フォーマットの信号から構成される）が、その構造が未知である、独自信号フォーマットに適用可能である。開示される信号抽出は、基礎データの情報コンテンツを抽出せず、むしろ、信号およびそれらのデータタイプを抽出する。信号抽出は、ＣＡＮバストラフィック上で訓練され、本訓練は、オフラインおよび／またはオンラインで行われることができる（例えば、信号抽出をリアルタイムで微調整するための適応訓練）。本方法は、復号化キーが、存在し、メッセージおよび／または信号が、信号抽出段階に先立って、もしくはその間に復号化されるという条件で、ＣＡＮバス上のメッセージが、暗号化される場合、依然として機能することができる。
【0022】
悪意のある攻撃の特に関連するモダリティは、ＥＣＵにコードを実行させる様式におけるＥＣＵへの実行可能コードの潜在的配信である。これは、種々の方法で行われることができる。１つのアプローチでは、ＥＣＵファームウェアが、例えば、ＣＡＮ－ＴＰを使用して、ＣＡＮバスを介して更新可能である場合、攻撃者は、正当ではないファームウェア更新をＥＣＵに伝送することができ、これは、ＣＡＮバスを介したファームウェア更新のための設計ベースプロトコルに従う。別のアプローチでは、ＣＡＮ－ＴＰは、不良に設計されたＥＣＵ処理アーキテクチャにおけるスタックオーバーフローまたは他のメモリリークにつながる実行可能コードの大きいブロックを伝送することができ、オーバーフローまたはメモリリークされた実行可能コードは、次いで、ＥＣＵによって実行され得る。これらは、単に、本タイプの攻撃のいくつかの非限定的実施例である。
【0023】
本明細書に開示されるいくつかの異常検出アプローチは、これに正当ではないコードを実行させる目的のために正当ではない実行可能コードをＥＣＵに伝送する確かな試みであり得る、異常を検出するように設計される。これらのアプローチは、ＣＡＮ－ＴＰプロトコル下で伝送されるデータタイプのブロックを識別し、次いで、機械言語命令セットのオペコードに関するデータバイトを検索することを含む。機械言語命令セットは、例えば、中央処理ユニット（ＣＰＵ）アーキテクチャの命令セットまたはＪａｖａ（登録商標）仮想マシン（ＪＶＭ）等の仮想マシンアーキテクチャの命令セット等であってもよい。これらのオペコード検出器アプローチが、プロセッサのメモリ内でのメッセージデータの集約を引き起こす、ＣＡＮ－ＴＰのようなプロトコルへのオペコード検出器の適用を拡張するために、本明細書に同様に開示される信号抽出アプローチと有用に組み合わせられ得ることを理解されたい。しかしながら、開示されるオペコード検出器アプローチはまた、信号抽出を伴わずに使用され、オペコード検出器は、ＩＳＯ １５７６５－２等の公開されたＣＡＮ－ＴＰプロトコルに限定されることができる。
【0024】
図１を参照すると、車両１０が、それにいくつかの電子制御ユニット（ＥＣＵ）１４が接続される、コントローラエリアネットワーク（ＣＡＮ）バス１２を含む。より一般的に、車両１０は、地上車両（例えば、図示されるような自動車１０、またはトラック、オフロード車両、オートバイ、バス、もしくは同等物）、水上車両（例えば、外航船、潜水艦、または同等物）、もしくは宇宙車両（例えば、軌道衛星、惑星間探測器、または同等物）であってもよい。より一般的に、ＥＣＵは、機関制御モジュール、ＡＢＳモジュール、動力操向モジュール、および／または他の車両動作関連電子デバイス、カーステレオもしくは他の車両内エンターテインメントシステム、車両外通信のために使用される無線送受信機（例えば、通信衛星送受信機）、車両気候制御モジュール等のＣＡＮバスまたは他のネットワーク１２と接続される、任意の電子デバイスであり得る。ＣＡＮバス１２は、ＣＡＮバス上のトラフィックが、ＣＡＮバス上の全ての電子デバイスによって受信され、ＣＡＮバス上のトラフィックが、メッセージ認証を含まない、プロミスキャスネットワークである。本文脈におけるメッセージ認証は、それによって受信デバイスが、メッセージのソースを検証し得る、メッセージ内またはネットワークのアーキテクチャ内に含有される情報である。ＣＡＮバスは、メッセージ認証を提供しない。ＣＡＮバス上のメッセージは、ペイロードと、メッセージヘッダとを備える。多くの場合、ヘッダは、アービトレーション識別子（ＡＲＢ ＩＤ）自体である。しかしながら、ＡＲＢ ＩＤが、３つの優先度ビットを含むＪ－１９３９ ＡＲＢ ＩＤ等の信号抽出および識別目的のためのヘッダの一部と見なされない付加的情報を含む状況が、存在する。
【0025】
継続して図１を参照すると、少なくとも１つの保護ＥＣＵ１４ｐｒｏｔ（またはより一般的に、ＣＡＮバス１２上の電子デバイス１４ｐｒｏｔ）は、図１に図式的に表されるような異常検出能力を含む。保護ＥＣＵ１４ｐｒｏｔは、電子プロセッサ２０と、電子プロセッサ２０によって可読かつ実行可能である命令を記憶する、非一過性記憶媒体２２とを含む。ハードウェアコンポーネント２０、２２は、多様に実装されてもよい。例えば、いくつかの実施形態では、電子プロセッサ２０および非一過性記憶媒体２２は、印刷回路基板（ＰＣＢ、図示せず）上に配置される、別個の集積回路（ＩＣ）チップであり、ＰＣＢの伝導性トレースが、プロセッサ２０および記憶媒体２２を動作的に接続してもよい。いくつかの実施例として、電子プロセッサ２０は、マイクロプロセッサまたはマイクロコントローラＩＣチップを備えてもよく、非一過性記憶媒体２２は、フラッシュメモリチップ、読取専用メモリ（ＲＯＭ）ＩＣチップ、電子的プログラマブル読取専用メモリ（ＥＰＲＯＭ）ＩＣチップ等のメモリＩＣチップを備えてもよい。他の実施形態では、電子プロセッサ２０および非一過性記憶媒体２２は、単一のＩＣチップとしてモノリシックに統合されてもよい。いくつかの実施例として、ＥＣＵ１４ｐｒｏｔは、特定用途向け集積回路（ＡＳＩＣ）チップまたはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）チップとして実装され、記憶装置およびデジタルプロセッサの両方は、単一のＡＳＩＣもしくはＦＰＧＡ上にモノリシックに加工される。既述のように、ＥＣＵ１４ｐｒｏｔは、ＣＡＮバス１２からＣＡＮトラフィック２６を受信する。
【0026】
継続して図１を参照すると、非一過性記憶媒体２２上に記憶される命令は、本明細書に開示されるような信号抽出３０を実施し、１つ以上の異常検出器３２（例えば、時間異常検出器、メッセージ毎異常検出器、例証的オペコード検出器３４等）を実装し、異常検出器３２によって検出された異常のアラートおよび／またはログ付け３６を実装するために、電子プロセッサ２０によって可読かつ実行可能である。信号抽出３０は、標準的ＤＢＣファイル４０を利用し、これは、公開されたＣＡＮバスプロトコルに関する信号フォーマットを記憶する。（より一般的に、ＤＢＣ以外の別のファイルフォーマットが、標準的プロトコル信号フォーマットを記憶するために想定される。）加えて、信号抽出３０は、独自ＤＢＣファイル４２を利用し、これは、本明細書に開示されるようなＣＡＮバストラフィックの分析から推論された独自ＣＡＮバス信号フォーマットを記憶する。標準的および独自ＤＢＣファイル４０、４２は、非一過性記憶媒体２２上に好適に記憶される。
【0027】
いくつかの実施形態では、非一過性記憶媒体２２上に記憶される命令はさらに、本明細書に開示されるような独自ＣＡＮバス信号フォーマット推論４４を実施し、独自ＤＢＣファイル４２を発生させるために、電子プロセッサ２０によって可読かつ実行可能である。他の実施形態では、開示される独自ＣＡＮバス信号フォーマット推論４４は、オフラインで、すなわち、いくつかの他の電子プロセッサ（例えば、デスクトップコンピュータ、サーバコンピュータ等）によって実施され、独自ＤＢＣファイル４２を発生させ、これは、次いで、ＣＡＮバス１２を介して、または別の転送機構によってＥＣＵ１４ｐｒｏｔに転送され（例えば、車両１０上へのそのインストールに先立って、ＥＣＵ１４ｐｒｏｔ上に事前にロードされ）、電子プロセッサ２０上で実行される信号抽出３０によるアクセスのために、非一過性記憶媒体２２上に記憶される。また他の実施形態では、これらの２つのアプローチの組み合わせが、採用されてもよく、例えば、独自ＣＡＮバス信号フォーマット推論のインスタンスが、オフラインで実施され、初期独自ＤＢＣファイル４２を発生させてもよく、これは、続けて、車両１０の動作の間に電子プロセッサ２０によって実行される独自ＣＡＮバス信号フォーマット推論４４のインスタンスによってリアルタイムで更新される。
【0028】
さらに、オペコード検出器３４は、機械言語命令セット４６のデータベースを利用し、これは、ＣＡＮバス１２に接続されるＥＣＵにおいて展開されることが確実に予期され得る、種々のＣＰＵおよび／または仮想マシンアーキテクチャのための命令セットを記憶する。いくつかの典型的なＣＰＵアーキテクチャは、（非限定的な例証的実施例として）Ｉｎｔｅｌ ｘ８６、８０５１等のＣＰＵアーキテクチャ、ＡＲＭ Ａ３２、Ｔ３２、Ａ６４等のＣＰＵアーキテクチャ、種々のＲＩＳＣおよびＳＰＡＲＣアーキテクチャ等を含む。ＣＰＵアーキテクチャのための機械言語命令セットは、そのＣＰＵアーキテクチャに準拠するＣＰＵによって認識され、実行可能であるオペコードを識別する。同様に、Ｊａｖａ（登録商標）仮想マシン（ＪＶＭ）等の仮想マシンは、時として、バイトコードまたはある他の類似する名称と称される、命令を採用する。ＣＰＵまたは仮想マシンアーキテクチャのための機械言語命令セットは、そのアーキテクチャに準拠するＣＰＵもしくは仮想マシンによって認識され、実行可能であるオペコードを識別する。一般に、ＣＰＵまたは仮想マシンによって実行可能な機械言語命令は、オペコードと、オペランドとから成る。オペコードは、実施されるべき動作を識別し、オペランドは、オペコードの実行のために必要とされる任意のデータを提供する。（いくつかのオペコードは、いかなる関連付けられるオペランドも有していない場合がある。）任意の所与のＣＰＵまたは仮想マシンアーキテクチャが、オペコードの有限セットを認識し、それを実行することが可能であり、これらは、非一過性記憶媒体２２上に好適に記憶される、機械言語命令セット４６のデータベース内で識別される。
【0029】
いくつかの実施形態では、ＥＣＵ１４ｐｒｏｔは、異常検出のみを実施する、専用電子デバイスである。他の実施形態では、ＥＣＵ１４ｐｒｏｔは、ある他の機能を実施する、ＥＣＵである（例えば、ＥＣＵ１４ｐｒｏｔは、アンチロック制動を制御するＡＢＳモジュール、走行制御モジュール等であり得る）。そのような実施形態では、非一過性記憶媒体２２上に記憶される命令はさらに、アンチロック制動等を制御するためのＡＢＳモジュール機能性等のＥＣＵ機能的動作４８を実施するために、電子プロセッサ２０によって可読かつ実行可能である。図１に図式的に示されるように、ＥＣＵ機能的動作４８は、ある場合には、ＣＡＮバス１２を介して伝送されるメッセージを発生させてもよい、すなわち、ＥＣＵ機能的動作４８は、メッセージをＣＡＮトラフィック２６の中に投入してもよい。典型的には、これらの発信メッセージは、動作３０、３２、３４、３６によって処理されない（但し、代替として、例えば、ＥＣＵ１４ｐｒｏｔ自体がハッキングされ、ＥＣＵ機能的動作４８のその性能を修正する場合に、動作３０、３２、３４、３６によって発信メッセージを処理することもまた、想定される）。
【0030】
ＣＡＮバスの文脈における用語「信号」は、データの単一の自己完結した単位である。信号は、１つの変数、例えば、機関冷却剤温度のセンサ測定値であり得る。これはまた、デジタルコマンド、例えば、トルク要求であり得る。単一のＣＡＮメッセージ内の４つの８ビットタイヤ圧力信号のように、複数の信号が、単一のメッセージ内に存在することができる。または、Ｊ－１９３９トランスポートプロトコルが、ファームウェア更新を転送するために使用されているとき等、信号が、複数のメッセージ内に存在することができる。ファームウェア更新は、ＣＡＮ－ＴＰプロトコルを介して伝送される単一の信号と見なされることができる。より一般的に、信号は、基礎情報である。信号は、サポートする信号フォーマットまたはヘッダを含有しない。
【0031】
信号抽出は、２つのレジーム、すなわち、独自ＣＡＮバス信号フォーマット推論４４に対応する訓練レジームと、信号抽出３０に対応する動作レジームとを有する。一実施形態では、訓練は、ＣＡＮバストラフィックのコーパス上での展開の前に行われ、好ましくは、その上で信号抽出３０が続けて展開されるであろう、ＣＡＮバスの予期される動作エンベロープを包含する。別の実施形態では、訓練は、インストール後に、セキュリティ装置がアクティブ化されることに先立ってオンラインで実施される。第３の実施形態は、展開前訓練に続けて、展開の間に進行中の適応更新訓練を実施することによって、これらの２つの選択肢を組み合わせる。訓練（すなわち、独自ＣＡＮバス信号フォーマット推論４４）は、ＣＡＮバストラフィック内の構造を識別する。動作レジーム（すなわち、信号抽出３０）は、訓練された構造を利用し、未加工データストリームから信号をリアルタイムで抽出する。これらの２つのレジームは、不揮発性記憶媒体２２を通して通信する。例証的実施形態は、ＣＡＮバスプロトコルに関して一般的に採用されるフォーマットである記述子ファイル、すなわち、Ｖｅｃｔｏｒ Ｉｎｆｏｒｍａｔｉｋ ＧｍｂＨによって作成されるＤＢＣフォーマットを使用する。しかしながら、ＪＳＯＮまたはＸＭＬ等の他の記述子ファイルフォーマットが、採用されてもよい。訓練の間、独自信号に関する識別された信号フォーマットは、信号フォーマット毎に記述子ファイルに書き込まれる。また、独自ＣＡＮバス信号フォーマット推論４４が、典型的には、その信号フォーマットが推論される必要がある未知のＣＡＮバス信号が、独自信号フォーマットであるため、そのように言及されることに留意されたい。しかしながら、より一般的に、独自ＣＡＮバス信号フォーマット推論４４は、信号フォーマットが利用可能ではない理由にかかわらず、その信号フォーマットが利用不可能である任意のＣＡＮバス信号の信号フォーマットを推論するために使用されることができる。
【0032】
ここで図２を参照すると、独自ＣＡＮバス信号フォーマット推論４４の例証的実施形態が、説明される。独自ＣＡＮバス信号フォーマット推論４４の出力は、動作データ５０を提供するＤＢＣファイル４２として示される、記述子ファイルである。図２はまた、その信号フォーマットが推論される必要がないプロトコルベースの非独自信号の取扱を示す。これらの標準的ＤＢＣファイル４０は、プロトコル定義から明示的にプログラムされ、例えば、手動プログラミング、転写されたフォーマットにおける情報の購入、プロトコル文書化からの自動化抽出等を通して記述子ファイル４０に転写される（５２）。図２の非限定的な例証的実施例では、標準的ＤＢＣファイル４０は、標準的ＭＩＣＡＮ ５４、Ｊ１９３９ ５６、およびＩＳＯ１４２２９ ５８のためのＤＢＣファイルを含む。
【0033】
継続して図２を参照すると、例証的独自ＣＡＮバス信号フォーマット推論４４は、推論されるべき信号フォーマットにおける独自信号を含む、訓練ＣＡＮバスデータ６０に対して訓練される自動化信号フォーマット識別を提供する。入力訓練ＣＡＮバスデータ６０は、予期される動作エンベロープにわたるループシミュレーションにおいて計装されたプラットフォームまたはハードウェアから好適に収集される。訓練ＣＡＮバスデータ６０は、全データ幅を識別するために十分な全ての信号の移動を捕捉するべきである。訓練ＣＡＮバスデータ６０は、完全である必要はなく、例えば、信号が、１６ビットとして定義されるが、最上位４ビットが、決して誘発されず、事実上測定不可能である場合、正常な識別は、１２ビットを登録することのみ必要とする。独自ＣＡＮバス信号フォーマット推論４４は、未加工データ６０を取り込み、信号フォーマットを見出すために、プログラム的リバースエンジニアリングステップを実施する。動作６２において、候補信号が、訓練ＣＡＮバスメッセージトラフィック６０から抽出される。各候補信号は、ＣＡＮバスメッセージトラフィック６０内のデータビットの順序付けられたグループの繰り返し（すなわち、繰り返されるブロードキャスト）の時間シーケンスであり、データビットの順序付けられたグループは、１つ以上のメッセージヘッダによって区切られる。動作６４において、１つ以上の信号が、定義される。各信号は、合致するデータタイプの構造的特性に合致する候補信号であり、各信号は、合致するデータタイプを割り当てられる。以下では、動作６４の処理は、カウンタデータタイプ、定数データタイプ、浮動小数点データタイプ、整数データタイプ、およびビットフィールドデータタイプの非限定的実施例に関して説明される。
【0034】
カウンタデータタイプを割り当てられた信号は、カウンタデータタイプによって定義されたデータビットの順序付けられたグループの値が、データビットの順序付けられたグループの時間シーケンスにわたって（すなわち、連続するブロードキャストに伴って）単調に増加する、または単調に減少する、カウンタデータタイプの構造的特性に合致する候補信号として定義される。カウンタは、単調に増加または減少するフィールドである。概して、これらの値は、モジュールによるアクティブな通信を確実にし、モジュールが一時的にネットワークから外され、値のスキップを引き起こさない、またはスレッドがフリーズし、繰り返し値を送信させないことを確実にするために使用される。カウンタは、信号のブロードキャストの間の一定の差異を調べることによって識別される。ロールオーバー（すなわち、値が最大値または最小値のいずれかを横断するとき）が、時間シーケンスのサブ間隔にわたるモノリシック増加または減少を識別することによって取り扱われることができる。カウンタの幅は、最初に、カウンタの最下位ビットを表す、交互するビットを見出すことによって推論される。次に上位のビットが、第１のビットの全ての２番目の変化に伴って変化するビットを識別することによって、第１のビットに隣接して検索される。エンディアンに応じて、本変化は、先行または後続ビットにあり得る。第２のビットは、エンディアンを定義し、ビッグエンディアンの場合、第２のビットは、第１のものに先行し、リトルエンディアンの場合、第２のビットは、第１のものに続くであろう。カウンタの第２のビットを識別した後、検索は、ビットのパターンが、先行するビットの全ての他の変化に伴ってもはや変化しなくなるまで、第２のビットによって定義されるようなリトルエンディアンまたはビッグエンディアンのいずれかの方向において継続する。カンタは、サイズが単一ビットから複数バイトに及ぶことができる。
【0035】
定数データタイプを割り当てられた信号は、データビットの順序付けられたグループの値が、データビットの順序付けられたグループの時間シーケンスにわたって（すなわち、繰り返されるブロードキャストにわたって）一定である、定数データタイプの構造的特性に合致する候補信号として定義される。定数データタイプ値の信号を見出すことは、データビットの順序付けられたグループを構成するビットのセットが、決して変化しない候補信号を識別することを伴う。定数値は、空のプレースホルダであり得る、またはこれは、通常の条件下で誘発されない信号であり得る。これが、後者である場合、定数信号の変化を識別することは、いったん定数信号が認識されると、容易に検出される異常であろう。定数信号のいくつかの実施例は、デバイスシリアル番号、ソフトウェアバージョン、または識別番号を含む。定数として推測され得る信号は、実際に、変化する情報を伴う信号を表し得るが、しかしながら、その情報は、通常の状況下で誘発されない。例えば、信号が、エアバッグの状態を展開状態（第１の信号値によって表される）または非展開状態（第２の信号値によって表される）として表し得る。訓練された通常の条件下で、その信号は、一定であろう（すなわち、非展開状態を表す第２の信号値である）。エアバッグ展開事象の場合では、信号は、第１の値に変化し、したがって、異常としてマーキングされ、これは、車両が、展開の時点で予期される挙動における異常を被っている点において、正しい判定である。
【0036】
指数および仮数を有する浮動小数点データタイプを割り当てられた信号は、浮動小数点データタイプの構造的特性に合致する候補信号として定義される。これらの構造的特性は、１６、３２、または６４ビットであるデータビットの順序付けられたグループと、浮動小数点データタイプの仮数を表すデータビットの順序付けられたグループの第２のサブセットよりも時間シーケンスにわたって低いエントロピを有する、浮動小数点データタイプの指数を表すデータビットの順序付けられたグループの第１のサブセットとを含む。浮動小数点数は、ＩＥＥＥによって１６、３２、および６４ビットとして定義される。さらにより大きいサイズが、利用可能であるが、しかしながら、ＥＣＵが、６４ビットまたはより高い精度を使用するであろう可能性は低い。浮動小数点データタイプの信号を識別することは、エンディアンを交換し、検索を実施することを通して、平滑な低エントロピ出力を見出すことを伴う。一般に、指数は、仮数よりも低い頻度で変化することが予期される。エントロピの観点から、仮数は、指数よりも無秩序である（すなわち、より高いエントロピを有する）ことが予期される。これを確認するために、１～９９９で変動する浮動小数点値を検討する。「ＭＭＭ」が仮数を表し、「ＸＸ」が指数を表す、形態０．ＭＭＭＥＸＸの指数表記を使用すると、本範囲は、０．１００Ｅ０１～０．９９９Ｅ０３として記載されることができる。そこから分かり得るように、仮数は、本質的にその範囲全体にわたって変動する一方、指数は、０１～０３にのみ変動する。本実施例は、基数１０を採用する一方、ＣＡＮバス上の浮動小数点信号は、バイナリ、すなわち、基数２を採用するが、原理は、同一のままであり、仮数は、通常、指数よりもエントロピが高く、浮動小数点データタイプの本構造的特性は、これらの信号を検出するために活用される。
【0037】
整数データタイプを割り当てられた信号は、整数データタイプの構造的特性に合致する候補信号として定義される。これらの構造的特性は、４、８、１２、１６、または３２ビットであるデータビットの順序付けられたグループと、整数データタイプの最下位ビットを表すデータビットの順序付けられたグループの第２のサブセットよりも時間シーケンスにわたって低いエントロピを有する、整数データタイプの最上位ビットを表すデータビットの順序付けられたグループの第１のサブセットとを含む。プラットフォームにおけるデータは、概して、測定値または制御パラメータを表すため、データは、緩慢に変動する値を表す。これらの緩慢な変動は、メッセージの間の変化を殆ど伴わない、平滑である時系列履歴をもたらす。したがって、情報理論の観点から、データチャネル（信号の合計ビット）は、単位時間あたりにこれが通信することが可能であるものよりも有意に少ない情報を通信している。本特性は、低エントロピを有する信号をもたらす。データが、誤って表されるとき、より低いビットは、より高いビット位置に設置され、より大きい信号変動性をもたらす。信号は、次いで、急速に変化するように現れ、単位時間あたりの情報のより多い知覚される転送、したがって、より高いエントロピをもたらす。一般に、整数表現は、種々のビットサイズ、エンディアン、および符号属性を含む。目的は、試験データに関して平滑である最も大きい一貫した表現を見出すことである。各順列は、エントロピ測定値を介して達成される、平滑度に関して検証される必要がある。メッセージの時間履歴を使用して、サイズおよびエンディアンの各順列が、試験され、最良の最も平滑なフィットが、識別される。平滑なフィットは、多くの場合、近似エントロピ技法またはサンプルエントロピと称される、時系列エントロピ計算を使用して数値的に判定される。ここでは、近似エントロピ計算は、全ての順列に関して同じパラメータを用いて実行され、各順列が結果として生じる定量的エントロピ値を有することをもたらす。ビットサイズは、典型的には、４、８、１２、１６、および３２ビットの間である。整数フォーマットである殆どのＥＣＵデータは、１６ビットまたはそれを下回るものであり、３２ビットは、多くの場合、クロックのためにのみ使用される。符号なしまたは２つの補数のいずれかである、２つの形態の符号属性が、存在する。最後に、エンディアンは、バイト順序付け、すなわち、最上位ビットを反映するバイトおよびそれらのバイトがメッセージにパックされる方法を表す。バイト順序付けは、８ビットを上回るそれらの信号のみに関する基準である。
【0038】
ビットフィールドデータタイプを割り当てられた信号は、ビットフィールドデータタイプの構造的特性に合致する候補信号として定義される。ビットフィールドデータタイプは、単一ビットまたは単一ビットのグルーピングがバイナリ状態を表す場合である。本バイナリ状態は、ＣＡＮメッセージ内のバイトのサブセットとして反映されることができ、例えば、００００ ００１１は、ブレーキがアクティブであることを表し得、００００ ００００は、ブレーキが非アクティブであることを表し得る。代替として、メッセージは、アクティブに関して００００ ００１０または非アクティブに関して００００ ０００１であり得る。これらの先述の表現では、最左端の６ビットは、他の状態を表し得る。メモリまたは伝送における単一ビットエラーを軽減するために、状態を表すために１を上回るビットを使用することが、一般的である。ビットフィールドの検出は、例えば、等しいまたは等しくない、同一の関係を常に有する隣接するビットを検索することによって行われ、値は、訓練データセットにおいて少なくとも１回変化する。
【0039】
最も大きい一貫した表現を識別するために、前述の整数表現の異なる組み合わせが、信号として解釈され、次いで、平滑度に関して試験される。より具体的には、平滑度に関する試験は、解釈された信号のエントロピを分析し、時間が進行するにつれて、妥当な連続性に関してこれを試験することを伴う。過剰に不連続またはエントロピ的のいずれかである信号の解釈は、無効と見なされる。最も大きい解釈（これを表すために必要とされるビットの数の観点から）が、整数の最も可能性が高い表現として選定される。前述の１つの好適な公式化では、整数データタイプの構造的特性はさらに、連続性基準を満たす時間シーケンスにわたる連続性を有する、整数データタイプによって定義されたデータビットの順序付けられたグループの値と、エントロピ基準を満たす時間シーケンスにわたる連続性を有する、整数データタイプによって定義されたデータビットの順序付けられたグループの値とを含んでもよい。定数データが、より高次のビットにおいて存在する場合、上記の方法が、それらのビットがその独自の信号ではなく、信号に属することを推定することが可能である。このように、一定のビット変化が、実際には、異常な事象を表すであろうため、異常検出におけるいかなるエラーも、行われない。
【0040】
継続して図２を参照すると、動作６４において定義された１つ以上の信号は、ＤＢＣファイル４２における定義された信号の信号フォーマットを記述するために、ＤＢＣビルダ６６に出力される。これらのＤＢＣファイル４２は、推論された信号フォーマットにおいて信号を搬送するＣＡＮメッセージが、再び遭遇されるとき、ＤＢＣファイル４２が、迅速に信号を正しく解釈するために参照され得るように、信号フォーマット推論段階４４の訓練された結果を保存する。ＤＢＣファイルは、信号をヘッダおよびその信号の構造的表現に関連させるために定義される。異常検出は、受信の予期される頻度、受信の頻度の変動性、上限および下限、ならびに異常の識別を支援する他のメタデータ等の他の特徴もまた含むように共通フォーマットを拡張する。
【0041】
ここで図３を参照すると、信号抽出３０の例証的実施形態が、示される。制御フローの全ての分岐は、いくつかのプロトコルがその他の上に層化され得ることを示すために列挙される（各プロトコルを具体的に命名する）。一般性を失うことなく、プロトコル検出動作７０は、最初に、標準的ＤＢＣ４０のうちの１つを使用して、使用されるプロトコルを識別し、次いで、適切なプロトコルのＤＢＣを用いてメッセージを解析することを試みる。例えば、ＭｉｌＣＡＮパーサ７２が、プロトコルをＭｉｌＣＡＮとして識別することを試みる。決定７４において、ＭｉｌＣＡＮプロトコルが、認識される場合、ＭｉｌＣＡＮ信号抽出器７６が、ＭｉｌＣＡＮ ＤＢＣ４０ＭｉｌＣＡＮを使用して、信号を抽出するために適用される。同様に、Ｊ１９３９パーサ８２が、プロトコルをＪ１９３９として識別することを試みる。決定８４において、Ｊ１９３９プロトコルが、認識される場合、Ｊ１９３９信号抽出器８６が、Ｊ１９３９ ＤＢＣ４０Ｊ１９３９を使用して、信号を抽出するために適用される。Ｊ１９３９プロトコルが、ＣＡＮ－ＴＰをサポートするため、Ｊ１９３９パーサ８２は、Ｊ１９３９ ＣＡＮ－ＴＰ変形が、遭遇される場合、ＴＰアグリゲータ８８を呼び出してもよい。同様に、ＩＳＯ １４２２９パーサ９２が、プロトコルをＩＳＯ １４２２９として識別することを試みる。決定（空間制約に起因して図示せず）において、ＩＳＯ １４２２９プロトコルが、認識される場合、ＩＳＯ １４２２９信号抽出器９６が、Ｊ１９３９ ＤＢＣ４０Ｊ１９３９を使用して、信号を抽出するために適用される。ＩＳＯ １４２２９プロトコルが、ＣＡＮ－ＴＰをサポートするため、ＩＳＯ １４２２９パーサ９２は、ＩＳＯ １４２２９ ＣＡＮ－ＴＰ変形が、遭遇される場合、ＴＰアグリゲータ９８を呼び出してもよい。これらが、例証的実施例にすぎず、付加的および／または他の標準的プロトコルを採用する信号が、同様に抽出され得ることを理解されたい。解析されたメッセージが、独自フォーマットである（したがって、標準的ＤＢＣを有していない）場合、信号抽出器１００が、任意の利用可能な信号およびメタデータを抽出するために、（図２を参照して説明される）訓練段階の一部として発生される独自ＤＢＣ４２を使用する。全ての抽出された信号１０２およびメタデータ１０４（標準的または独自の両方）が、収集され、パイプラインにおける次の段階に出力される。
【0042】
再び図１を参照すると、図２および３を参照して説明されるように抽出された信号は、種々の方法で異常検出器３２によって活用されることができる。前述のように、信号が、定数データタイプであるとして識別される場合、その予期される定数値からのその信号の任意の逸脱が、異常としてフラグ付けされることができる。より一般的に、信号抽出３０は、個別のＣＡＮバス信号フォーマットに準拠する信号を抽出するために、初期時間間隔にわたって実施されてもよい。次いで、異常検出器３２のいくつかの実施形態は、初期時間間隔に続く後の時間間隔にわたって、準拠するＣＡＮバス信号フォーマットからの抽出された信号のうちの１つの任意の逸脱を異常として検出することによって動作してもよい。
【0043】
別の実施例として、オペコード検出器３４は、ＣＡＮ－ＴＰまたは類似する信号の大きいペイロードが、悪意のある機械コードがＥＣＵに配信されるサイバー攻撃の機会を提供するため、これらの多くのバイト信号にオペコード検出を集中させるために、そのような信号の検出を活用してもよい。オペコードベースの攻撃が、有効性を有するための最小数のオペコードを転送する必要があるであろうと仮定される。再び図１を参照すると、以下では、オペコード検出器３４のいくつかの実施形態が、説明される。
【0044】
ここで図４を参照すると、オペコード検出器３４は、ＣＡＮバス１２を横断して送信される機械コードを含有するバイナリペイロードを検出するように構成され、したがって、オペコード実行の脅威に対して保護する。ＥＣＵにコードを実行させることを試みる車両１０のＣＡＮバス１２に対する典型的な攻撃が、図４に図式的に示され、攻撃者１１０が、ＣＡＮバス１２上のＥＣＵまたは他の電子デバイス１１２をセキュリティ侵害し、同様にＣＡＮバス１２上にある別のＥＣＵもしくは電子デバイス１１６によって受信および実行されるエクスプロイト機械コード１１４を投入する。ＣＡＮバス上１２の侵入検出システム（ＩＤＳ）１２０（例えば、図１のＥＣＵ１４ｐｒｏｔとして具現化される）もまた、攻撃者１１０によってＥＣＵまたは他の電子コンポーネント１１６を感染させることが意図される悪意のあるペイロード試行１１４を受信する。これは、ＣＡＮバス１２が、ネットワーク上の全てのデバイスが全てのメッセージを受信する、プロミスキャスネットワークであるためである。
【0045】
攻撃者が個々のＣＡＮメッセージをコード実行エクスプロイトに活用する尤度は、低い。不良なコーディング実践が、何らかの方法で個々のＣＡＮメッセージ内に含有される機械コードの実行を許可した場合であっても、８バイトのデータのみが、シェルコードとして一般的に公知である、エクスプロイトを含有するオペコードに関して利用可能であろう。しかしながら、ＣＡＮ－ＴＰプロトコルが、使用される場合、複数のメッセージが、単一の信号に集約される。本集約は、より多くの量のデータを提供し、これによって、脆弱性を誘発するはるかに大きい潜在性を提供する。１つの可能性として考えられる攻撃の一非限定的な例証的実施例として、新しい証明書が、制御モジュールにアップロードされるべきである、ｘ５０９証明書パーサを検討する。証明書は、サイズが数キロバイトである。証明書が、不良に設計されたコードによって解析される場合、これは、攻撃者が、シェルコードを証明書の中に組み込み、次いで、プログラムフローをそのコードにリダイレクトすることを可能にし得る。別の実施例として、ファームウェア更新が、ＣＡＮバス１２を介してＥＣＵに伝送され得、プロミスキャスネットワークとして、ファームウェア更新プロセスの十分な知識を伴う悪意のある行為者が、正当ではないファームウェア更新を細工し、これが、次いで、ＥＣＵによって受信および実行されるであろうことに対して、いかなる障壁も、存在しない。一般に、いったんより高いレベルのＣＡＮ－ＴＰプロトコルが、複数のメッセージを集約するために使用されると、一般的なソフトウェア脆弱性を通したコード実行のリスクは、現実的になる。
【0046】
継続して図４を参照すると、信号抽出３０の出力は、ＣＡＮ－ＴＰプロトコルにおける信号または所定の数のバイト、例えば、３２よりも大きい類似する信号を識別する。動作１２２において、ＣＡＮ－ＴＰ信号のペイロードは、集約され、待ち行列１２４において待ち行列に入れられる。抽出されたペイロードは、有効なオペコードを検出するために検査される。前述のように、オペコードは、攻撃者がサイバー攻撃を実行するために悪意のある「シェルコード」の中に組み込む、ＣＰＵまたは仮想マシン命令セットの機械言語命令である。ＣＡＮバス１２のプロミスキャス性質は、ＩＤＳ１２０が、これらのＣＡＮ ＴＰペイロードを抽出し、ＣＡＮバス１２上の（または潜在的にその上の）ＥＣＵもしくは他の電子デバイスにおいて使用されるＣＰＵまたは仮想マシンアーキテクチャに関する大量の有効なオペコードに関してそれらを検査することもまた可能にする。ＣＰＵまたは仮想マシンの命令セットに属するオペコードは、そのＣＰＵもしくは仮想マシンによって認識され、実行可能であるが、しかしながら、オペコードは、バイナリシーケンスであるため、それらはまた、悪意のないメッセージにおいて偶然に生じ得る。
【0047】
これを考慮して、１つのアプローチでは、ＣＡＮ ＴＰプロトコルに準拠する複数のメッセージのデータバイトを備えるＣＡＮ－ＴＰ信号内の疑わしい機械コードの検出が、以下のように実施される。１つ以上の機械言語命令セット４６の機械言語命令セット毎に、機械言語命令セットのオペコードに合致するＴＰ信号の割合が、判定される。サイバー攻撃の標的であり得るＣＰＵまたは仮想マシンアーキテクチャは、先験的に把握されないため、これは、機械言語命令セット４６のセットの機械言語命令毎に繰り返される。異常が、（少なくとも部分的に）判定された割合のうちの少なくとも１つがオペコード異常閾値を超えることに基づいて検出される。すなわち、脅威のレベルを判別するために、有効なオペコードを表すメッセージの割合が、随意に、オペコードの連続性等の他の因子とともに、考慮される。本情報は、アラートエンジン３６に転送される信頼性測度を作成するために分析される。
【0048】
継続して図４を参照し、さらに図５を参照すると、オペコード検出器３４の例証的実装が、さらに詳細に説明される。動作１３０において、ペイロードのバイトが、機械言語命令セットのオペコードに合致される。これを行うために、バイトは、適切に解釈されなければならない。異なるプロトコルは、オペコードのエンディアンおよびローテーションに影響を及ぼし得、動作１３０は、既知のアーキテクチャのうちの１つに関する有効なコードを生成する（すなわち、機械言語命令セットのオペコードに合致する）バイトのエンディアンならびにローテーションが、存在するかどうかを判定するために、エンディアンおよびローテーションの異なる組み合わせを試験する。いったんこれらが、把握されると、動作１３２において、識別されたオペコードは、分析され、所与の機械言語命令セットのオペコードから構成されるＣＡＮ－ＴＰ信号の割合を判定し、随意に、ペイロードが疑わしい機械コードを含有するかどうかを立証し得る、他のメトリックを判定する。例えば、悪意のあるコード実行を得る試みを示す具体的な機能的測度は、（オペコードから構成されるペイロードの割合に加えて）命令多様性、スタック効果、ジャンプまたはコールである、もしくは別様に（ＣＰＵまたは仮想マシンアーキテクチャに応じて）プログラムカウンタ（ＰＣ）もしくは命令ポインタ（ＩＰ）を移動させるように動作するオペコードの割合、戻り動作を実装するオペコードの割合、および／またはソフトウェア割り込みを実装するオペコードの割合のメトリックを含んでもよい。ＰＣまたはＩＰを移動させる、もしくは戻りまたは割り込み動作を実装するオペコードは、これらがプログラムフローを投入された悪意のあるコードにリダイレクトするために使用され得るため、特に重要である。動作１３４において、機械言語命令セットのオペコードに合致するＴＰ信号の割合は、他の随意のメトリックとともに、ＣＡＮ－ＴＰ信号がサイバー攻撃を成す尤度を算出するために分析される。本尤度が、あるアラート閾値を超える場合、アラート／ログ付け３６が、異常をログ付けするために行使される。図５の例証的実施例では、動作１３４は、脅威の尤度を以下として算出する。
式中、Ａは、脅威の尤度であり、ｋは、算出されたメトリックの数であり、指数ｎは、ｋ個のメトリックにわたって及び、ｗｎは、ｎ番目のメトリックに関する加重であり、Ｒｎは、ｎ番目のメトリックに関するペイロードの単位量あたりのリスクであり、ｔは、調整パラメータである。
【数1】
【0049】
一般に、ＣＡＮ－ＴＰ信号内の検出された機械言語コンテンツの存在が、重要である。しかしながら、ＣＡＮ－ＴＰ内の機械言語コンテンツが、悪意のないものであり得るいくつかのインスタンスが、存在し得る。例えば、ＥＣＵが、ＣＡＮバス１２を介してファームウェア更新を受信する場合、正当なファームウェア更新は、ＥＣＵによって受信および実行されるべきである悪意のないメッセージである。これらのタイプの状況に適応するために、随意の決定動作１３６（図５にのみ示される）が、ＣＡＮ－ＴＰ信号が許可されたファームウェア更新であるかどうかをチェックし、ＣＡＮ－ＴＰ信号が、許可されたファームウェア更新として識別されない場合のみ、異常が、フラグ付けされる。例えば、証明書または他の認証機構が、採用されてもよく、これは、ＥＣＵ１４ｐｒｏｔにセキュアに配信され、そこに記憶される。その後、ＣＡＮ－ＴＰ信号が、機械コードを含有すると判定されるが、また、証明書または他の認証も含有する場合、決定１３６は、認証されたファームウェア更新を認識し、これを異常としてフラグ付けしない。
【0050】
再び図１を参照すると、アラート／ログ付け３６は、種々の形態をとることができ、アラートのタイプ（またはいかなるアラートも全く発行されないかどうか）ならびに／もしくはログ付けされる異常は、異常のタイプに依存し得る。いくつかの例証的実施例では、アラートが、（例えば、ＥＣＵ１４ｐｒｏｔがアラートメッセージをダッシュボードを制御するＥＣＵに送信することによって）車両１０のダッシュボード上に表示されてもよい、アラートが、３Ｇ、４Ｇ、５Ｇ、または他のセルラー通信リンクもしくは他の無線リンクを介して（車両１０がそのような無線通信を装備すると仮定して）車両製造業者に伝送されてもよい、アラートが、ハンドヘルドまたは自動車ショップベースのＣＡＮバスコードリーダを使用して、後での読出のためにＥＣＵ１４ｐｒｏｔのメモリ内にログ付けされてもよいこと等が考えられる。
【0051】
好ましい実施形態が、例証および説明された。明白なこととして、修正および改変が、先述の発明を実施するための形態を熟読し、理解することに応じて、他者に想起されるであろう。本発明が、それらが、添付される請求項またはその均等物の範囲内に該当する限り、全てのそのような修正および改変を含むものとして解釈されることを意図している。
【0052】
上記に開示される、および他の特徴ならびに機能の変形またはそれらの代替が、多くの他の異なるシステムもしくはアプリケーションに組み合わせられ得ることを理解されたい。種々の現在予見されていない、または予想されていない代替、修正、変形例、もしくはそれにおける改良が、当業者によって続けて行われ得、これもまた、以下の請求項によって包含されることを意図している。
【0053】
特許庁および本願ならびに任意の結果として生じる特許の任意の読者が、本明細書に添付される請求項を解釈することを支援するために、出願人らは、単語「～のための手段」または「～のためのステップ」が、特定の請求項において明示的に使用されない限り、添付される請求項もしくは請求項要素のうちのいずれかが、３５ Ｕ．Ｓ．Ｃ． § １１２（ｆ）を行使することを意図していない。
【図1】
【図2】
【図3】
【図4】
【図5】
【国際調査報告】