JP2023519059A - ネットワークのセキュリティ手段を高めるネットワーク上におけるデータ交換のための方法およびシステムおよびその種のシステムを包含する乗り物 - Google Patents

Abstract

プロトコルに従って動作し、送信バス（４）と第１のノード（Ｅ１）と第２のノード（ＥＮ）とを含む通信ネットワーク（２）上におけるデータ交換のための方法。第１のノードは、第１および第２の情報データ（Ｄａｔａ１、Ｄａｔａ２）を伝送する第１および第２のデータ・フレーム（１０）を構成するステップと；第１および第２の情報データの関数として第１のメッセージ認証コード（ＭＡＣ１）を計算するステップと；第１のメッセージ認証コード（ＭＡＣ１）を伝送する第３のデータ・フレーム（２０）を構成するステップと；このように構成されたすべてのデータ・フレームを送信するステップとを実行する。第２のノードは、第１、第２、第３のデータ・フレームを受信するステップと、第１および第２の情報データおよび第１のメッセージ認証コードを抽出するステップと；抽出した第１および第２の情報データの関数として第２のメッセージ認証コード（ＭＡＣＥＸＰ）を計算するステップと；抽出したメッセージ認証コードと計算したメッセージ認証コードとを、それらの同一性を検証するために比較するステップとを実行する。

Description

関連出願の相互参照
本件特許出願は、２０１９年１２月１０日に出願されたイタリア特許出願第１０２０１９００００２３５４４号の優先権を主張するものであり、当該出願の開示のすべては、参照によりこれに援用される。

本発明は、通信ネットワーク上におけるデータ交換、特にネットワーク上において送信されるデータのセキュリティ手段を高めるデータ交換のための方法およびシステム、およびその種のシステムを包含する乗り物に関する。

自動車のための近代的な電子システムは、シリアル・バスおよびゲートウェイを介してネットワーク内において互いに通信する電子コントロール・ユニット（ＥＣＵ）上において動作するソフトウエアの使用を提供する。現在のシステムの大半は、たとえば、交換されるデータを改変する意図を伴って生成され、かつ機能障害、モータ・コントロール・アプリケーション、および／または乗り物アプリケーションの改変またはクラッシュを生じさせる内部または外部攻撃に対するオンボード・データのセキュリティについての考慮の下に設計がされていない。

現在の自動車電子システムの設計のために使用されているプロセス、方法、および機器類は、信頼性およびコストの最適化に傾注されている。ランダム故障に関する自動車電子システムの信頼性をテストするための方法および機器類は、商的に入手可能である。

しかしながら、ハードウエアおよびソフトウエア・アーキテクチャの開発の間にセキュリティに関係する側面が殆ど考慮されていない；同時に標準通信プロトコルもまた、攻撃を防止し、または軽減するために共有される方法を提供しない。

オンボード乗り物通信ネットワークは、結局のところ、乗り物内のＥＣＵ間の全通信が、送信側および受信側のアイデンティティが損なわれていないことを保証するに充分な認証メカニズムなしに実行されることから比較的単純な態様での無権限アクセスを可能にするために脆弱である。

残念なことに、たとえば、数あるうちのいくつかを挙げれば、ＣＡＮ（コントローラ・エリア・ネットワーク）、ＦｌｅｘＲａｙ（フレックスレイ）、ＭＯＳＴ（モスト）、およびＬＩＮ（リン）等の現在の通信ネットワーク・プロトコルは、認証を要求しないか、または最良の場合でもデータの完全性を保証するための誤りコントロール・メカニズム（ＣＲＣ）を有するに過ぎず、平文でメッセージが送信される。

したがって、コントロール・ユニット間においては、不正な通信の可能性が存在する。

とりわけＣＡＮプロトコルに関して言えば、上に述べられている欠点を克服するために、セキュリティの改善をねらいとして、特に、メッセージの真正および情報の新鮮さの意味において多様な解決策が提案されている。

たとえば、非特許文献１は、コントロール・コードに関係する分野を含ませるために、ＣＡＮメッセージの構造、またはフォーマットの再検討を提案している。しかしながら、その種の解決策は、実装されるプロトコルの一般適合を必然的なものとし、これは、新しいメッセージ構造の翻訳を可能にしなければならない。

そのほかの技術的解決策は、保護されるべき具体的なメッセージ内に含まれるアプリケーション・データに関して計算されるコントロール情報を伝送するべく適合されたコントロール機能を有する新しいメッセージの導入を提供する。これに関しては、非特許文献２を参照されたい。併せて非特許文献３も参照されたい。しかしながら、これらの解決策は、ネットワーク上のトラフィックおよび演算負荷が有意に増加するために最適ではない。

さらなる解決策は、データ・レートの増加（＞１メガビット／秒）およびペイロードの増加（＞８バイト）を伴い、データ伝送を最適化し、したがって、セキュリティの改善をねらいとした解決策の実装の可能性を増加させるＣＡＮ－ＦＤと呼ばれる、より最近になって導入されたＣＡＮプロトコルの使用を提供する。しかしながら、この解決策は、オンボード乗り物データ交換システムの再適合を必要とするという欠点を有し、新しいプロトコルへの変換を必須とし、したがって結果として生じるコストを伴う。

ウエダ・ヒロシほか著「Ｓｅｃｕｒｉｔｙ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｓｙｓｔｅｍ ｆｏｒ Ｉｎ－Ｖｅｈｉｃｌｅ Ｎｅｔｗｏｒｋ（セキュリティ・オーセンティケーション・システム・フォア・インビークル・ネットワーク）」、ＳＥＩ ＴＥＣＨＮＩＣＡＬ ＲＥＶＩＥＷ（セイ・テクニカル・レビュー）、Ｎｏ．８１、２０１５年１０月 Ｃｈｕｎｇ－Ｗｅｉ Ｌｉｎ（チャン・ウェイ・リン）ほか著「Ｃｙｂｅｒ－Ｓｅｃｕｒｉｔｙ ｆｏｒ ｔｈｅ Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＣＡＮ）Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（サイバー・セキュリティ・フォア・ザ・コントローラ・エリア・ネットワーク（ＣＡＮ）コミュニケーション・プロトコル）」、ＡＳＥ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ａｕｔｏｍａｔｅｄ Ｓｏｆｔｗａｒｅ Ｅｎｇｉｎｅｅｒｉｎｇ（ＡＳＥカンファレンス・オン・オートメイテッド・ソフトウエア・エンジニアリング）、２０１２年 Ｐａｌ－Ｓｔｅｆａｎ Ｍｕｒｖａｙ（パル・ステファン・マーベイ）ほか著「Ｓｅｃｕｒｉｔｙ Ｓｈｏｒｔｃｏｍｉｎｇｓ ａｎｄ Ｃｏｕｎｔｅｒｍｅａｓｕｒｅｓ ｆｏｒ ｔｈｅ ＳＡＥ Ｊ１９３９ Ｃｏｍｍｅｒｃｉａｌ Ｖｅｈｉｃｌｅ Ｂｕｓ Ｐｒｏｔｏｃｏｌ（セキュリティ・ショートカミングス・アンド・カウンターメジャーズ・フォア・ザ ＳＡＥ Ｊ１９３９ コマーシャル・ビークル・バス・プロトコル）」、ＩＥＥＥ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｖｅｈｉｃｕｌａｒ Ｔｅｃｈｎｏｌｏｇｙ（ＩＥＥＥトランザクション・オン・ビーキュラー・テクノロジー）、第６７巻、第５号、２０１８年５月

本発明の目的は、同一乗り物ネットワークに属するＥＣＵの間において転送される情報のセキュリティを増加することを、効率的かつコスト効果的な態様で、かつ演算負荷の増加および／またはハードウエア・リソースの修正の必要性を伴うことなく可能にする、上に述べられている欠点に対する解決策を提供することとする。

したがって、本発明によれば、付随する特許請求の範囲に定義されているとおり、通信ネットワーク上におけるデータ交換のための方法およびシステム、およびその種のシステムを包含する乗り物が提供される。

本発明のより良好な理解のために、以下、非限定的な例として、次に挙げる添付図面を参照して好ましい実施態様を説明する。

乗り物内に実装されるデータ送信／受信ネットワークに属するノード間のネットワークを略図的に図解した図である。 図１のネットワークのノード間において交換されるデータ・フレームを図解した図である。 図１のネットワークのノードによって実装される方法の送信における場合を図解したフローチャートである。 図１のネットワークのノード間において交換される認証フレームを図解した図である。 図１のネットワークのノードによって実装される方法の受信における場合を図解したフローチャートである。 送信ステップの間における図１のネットワークのノードによって実行される動作を図解した機能ブロック図である。 受信ステップの間における図１のネットワークのノードによって実行される動作を図解した機能ブロック図である。 ローカル単調カウンタの同期ステップの間における図１のネットワークのノードによって実行される動作を図解した機能ブロック図である。 ローカル単調カウンタの同期ステップの間における図１のネットワークのノードによって実行される動作を図解した機能ブロック図である。 図１のネットワークを包含する乗り物を略図的に図解した図である。

図１は、送信／受信プロトコルに従って動作する通信ネットワーク２を略図的に示している。ネットワーク２は、複数のノードＥ_１、Ｅ_２、・・・、Ｅ_Ｎが接続されるバス４を含む（これにおいて、Ｅ_ＮはＮ番目のノードを表す；ただし、Ｎは、具体的な用途に応じた必要性に従って選択される）。

本発明の１つの実施態様においては、送信プロトコルがＣＡＮ（「コントローラ・エリア・ネットワーク」）タイプである。この場合においては、バス４がＣＡＮバスである。本発明の文脈においては、自動車セクタにおいて使用されるべく適合され、かつ乗り物１（図１には、略図的に図解されている）内にインストールされるバージョン２．０（特に、２．０Ａまたは２．０Ｂ）に従ったＣＡＮプロトコルを明示的に参照する。しかしながら、ここで述べられていることは、自動車セクタに限定されず、一般に、ＣＡＮプロトコルの使用が提供されるすべてのセクタにおいて適用可能である。以下においてより明白となるとおり、本発明はまた、ＣＡＮプロトコルとは異なるタイプのネットワーク、および関連プロトコルに実装することも可能である。

図１に関して言えば、各ノードＥ_１－Ｅ_Ｎが、乗り物１に属する電子コントロール・ユニットまたはＥＣＵである。

ＣＡＮバス４は、異なるタイプのメッセージ（または、フレーム）を送信することが可能であり、それらの中には次のものがある：データ・フレーム、すなわちノードが送信するデータを含んでいるフレーム；リモート・フレーム、すなわち具体的な識別子の送信を要求するフレーム；エラー・フレーム、すなわちエラーを検出したノードによって送信されるフレーム；過負荷フレーム、すなわちデータ・フレームおよび／またはリモート・フレームの間に遅延を導くフレーム。

この開示の文脈において、リモートフレーム、エラーフレーム、および過負荷フレームは無関係であり、したがって、以下において論ずることはしない。

図２は、送信ノードＥ_１－Ｅ_Ｎと１つ以上の受信ノードＥ_１－Ｅ_Ｎの間において転送されることになるデータを含むデータ・フレーム１０を図解している。以下においては、データ・フレーム１０を、用語「メッセージ」によっても参照する。異なるメッセージは、通常、必然ではないが、互いに異なるタイプの情報コンテンツ（すなわち、伝送されるデータ）によって特徴付けられる。

データ・フレーム１０は、例として述べるが、特に、次の５つのフィールド１０ａ－１０ｅを含む：
－ それ自体は周知の態様でデータ・フレーム１０の開始を定義するため、および潜在的な衝突を管理するために使用される１つ以上のサブフィールドを含むヘッダ・フィールド１０ａ；
－ 受信ノードへ転送されなければならない、ノードによって送信される有用なデータを含むデータ・フレーム１０の情報負荷を表すバイト（０から８バイトまで）を含むデータまたはペイロード・フィールド１０ｂ；
－ メッセージ内に含まれているエラーをチェックするためのチェック・シーケンスを含む巡回冗長検査（ＣＲＣ）フィールド１０ｃ；
－ 受信ノードによる受信の確認のためのフィールドとして作用する肯定応答（ＡＣＫ）フィールド１０ｄ；
－ エンド・フィールド（ＥＯＦ）１０ｅ。

図２に図解されている例は、可能性のあるデータ・フレームの例証であり、異なるバージョンのＣＡＮプロトコルが、異なるタイプのフィールドを有するデータ・フレームを定義することは可能である。しかしながら、このことは、いずれかのバージョンのＣＡＮプロトコルに従って定義される任意のタイプのデータ・フレーム１０に対して適用可能な本発明と無関係である。

図３は、本発明のある態様に従った送信ノードによるネットワーク２上のデータ送信のためのプロシージャを、フローチャートを用いて図解している。送信ノードによる送信は、特定のノードをそれの受信者として有することが可能であるか、またはブロードキャスト・モードでそれを生じさせることが可能である。

非限定的な例として述べるが、以下においては、ネットワーク２のノードのうちの１つ（たとえば、ノードＥ_１）が、特定の受信ノード（たとえば、ノードＥ_Ｎ）へ向けた複数のメッセージＭｓｇ１－Ｍｓｇ６をＣＡＮバス４へ送信する。以下の説明は、類推によって、またそれ自体はこの分野の当業者に明白な態様で、送信ブロードキャストに対しても適用可能である。

通常、ノードＥ_１からノードＥ_Ｎへのデータの送信が単一メッセージの送信で終了することはなく、複数のメッセージＭｓｇ１－Ｍｓｇ６がまとまってリンクされ、すなわちノードＥ_１からノードＥ_Ｎへ順に送信される。メッセージＭｓｇ１－Ｍｓｇ６は、例として述べるが、図２に図解されている形式を有し、それぞれ自身のペイロード・フィールド１０ｂ内において、それぞれの情報データＤａｔａ１－Ｄａｔａ６を伝送する。

メッセージＭｓｇ１－Ｍｓｇ６は、適切な順序で送信されるために、送信ノードＥ_１のキュー（送信バッファ）内に置かれる。

したがって、図３のステップ１０１を参照すると、送信ノードＥ_１が、メッセージＭｓｇ１－Ｍｓｇ６のサブセット、すなわち、ここではメッセージＭｓｇ１、Ｍｓｇ２、およびＭｓｇ３によって形成されるサブグループを送信する。このステップ１０１においては、送信ノードＥ_１が、２以上の任意の数のメッセージを送信することが可能である。ノードＥ_１とＥ_Ｎの間における通信が単一のメッセージを伴って完了する場合においては、その種の単一のメッセージが送信されるだけであることは明白である。

次のステップ１０２においては、送信ノードＥ_１が受信ノードＥ_Ｎへ、「メッセージ認証コード」（ＭＡＣ）と呼ばれるコントロール・メッセージを送信する。このステップ１０２においては、ステップ１０１において送信されたメッセージＭｓｇ１－Ｍｓｇ３のそれぞれのペイロード・フィールド１０ｂ内に含められているデータＤａｔａ１－Ｄａｔａ３の関数として、送信されたＭＡＣ（ＭＡＣ_１として識別される）が計算される。

さらなる実施態様によれば、送信されるＭＡＣコードは、ビットの点から見たメッセージ全体の、またはメッセージのフィールドまたはサブフィールドのあらかじめ定義済みのサブセットのコンテンツに基づいて計算することが可能である。以下においては、説明を簡明に保つため、また一般性を失わないために、ペイロードのみがＭＡＣコードの計算に寄与する場合を考察する。

ＭＡＣコードを伝送するフレーム（以下においては「認証フレーム」と呼ぶ）は、それを構成するフィールドの、および伝送されるバイト数の構造またはフォーマットの点から見てデータ・フレーム、たとえば図２のデータ・フレーム１０と類似する。たとえば、認証フレーム２０（たとえば、ステップ１０２において計算されたＭＡＣ_１を伝送するフレーム）が図解されている図４を参照されたい。本発明の少なくとも１つの実施態様において、認証フレーム２０は、ＣＡＮプロトコルによって定義されるデータ・フレームとの区別が完全に不可能である。

具体的に述べれば、この例において、認証フレーム２０が、図２を参照して上で述べたヘッダ・フィールド１０ａと、巡回冗長検査フィールド１０ｃと、肯定応答フィールド１０ｄと、エンド・フィールド１０ｅを包含し、したがって、同一の参照番号によって識別されている；認証フレーム２０は、さらにペイロード・フィールド１０ｂと完全に類似するフィールド２０ａを包含する；しかしながら、データ・フレーム１０とは異なり認証フレーム２０は、フィールド２０ａの内側にステップ１０２において計算されたＭＡＣコード（ＭＡＣ_１）を識別するバイト（ここでは、８バイト）を含む。ただし、認証フレーム２０が、ＣＡＮプロトコルの観点において、フォーマットという点から見てデータ・フレーム１０との区別が不可能であることに注意する。

図３に戻るが、ステップ１０２に続くステップ１０３においては、送信ノードＥ_１がＣＡＮバス４へ、ステップ１の間に実行されたものと類似する態様で３つのさらなるメッセージＭｓｇ４、Ｍｓｇ５、Ｍｓｇ６を送信する。

その後、ステップ１０４において、送信ノードＥ_１が受信ノードＥ_Ｎへ、ステップ１０３において送信されたメッセージＭｓｇ４－Ｍｓｇ６のそれぞれのペイロード・フィールド１０ｂ内に含まれていたデータＤａｔａ４－Ｄａｔａ６の関数として計算されたＭＡＣコード（ＭＡＣ_１とは異なるＭＡＣ_２）をフィールド２０ａ内に含む新しい認証メッセージ２０を送信する。

ステップ１０３－１０４は、ステップ１０１－１０２の複製であり、それぞれのメッセージに関して実行されることに注意する。図３に図解されているプロシージャは、送信ノードＥ_１が、送信されるべきメッセージのキューを完了するまで（したがって、ステップ１０１－１０２と類似するステップを、送信されるべきすべてのメッセージについて実行するまで）限界を定めずに続けることが可能である。

図５は、ここではノードＥ_Ｎとする受信ノードによるＣＡＮバス４上のデータ受信のためのプロシージャを、フローチャートを用いて例証的に図解している。

受信においては、受信ノードＥ_Ｎが、メッセージＭｓｇ１－Ｍｓｇ３（ステップ２０１）と、コードＭＡＣ_１を含んでいる認証フレーム２０（ステップ２０２）とを獲得する。なお、受信ステップにおいては、認証フレーム２０によって伝送されるコードＭＡＣ_１が、ノードＥ_１によって送信されるコードＭＡＣ_１と（送信エラーに起因して、または不正な活動に起因して）異なる可能性があることに注意する。したがって、受信されたコードを、ここでは、符号ＭＡＣ_１’によって参照する。

さらに、受信ステップにおいては、メッセージＭｓｇ１－Ｍｓｇ３およびコードＭＡＣ_１が、（たとえば、受信ノードＥ_Ｎが複数のメッセージおよび関連する認証フレームを異なる送信ノードＥ_１、Ｅ_２、・・・から受信しているために）完全にシーケンシャルでない可能性があることに注意する。複数の送信ノードＥ_１、Ｅ_２、・・・からメッセージを受信する場合においては、受信ノードＥ_Ｎの受信バッファが多様なメッセージおよび関連する認証フレーム２０をランダムな順序で、または、いずれにしても先験的にあらかじめ決定可能でない順序で含むことになる。しかしながら、各メッセージおよび各認証フレームが、共通識別子またはそれを生成した送信ノードＥ_１、Ｅ_２、・・・の識別子（特に、送信ノードのソース・アドレス）を伝送することから、受信ノードＥ_Ｎは、それぞれの受信した各コードＭＡＣ_１’の計算のための正しい順序付けを実行することが可能である。

その後、受信ノードＥ_Ｎは、認証フレーム２０のフィールド２０ａ内に含まれている受信したコードＭＡＣ_１’の真正をチェックする（ステップ２０３）；言い換えると、ノードＥ_Ｎは、コードＭＡＣ_１’が、期待されるコードに対応するか否か、すなわち、コードＭＡＣ_１’がメッセージＭｓｇ１－Ｍｓｇ３のデータＤａｔａ１－Ｄａｔａ３の（送信ステップ１０２を参照して論じたとおり）関数になっているか否かをチェックする（ＭＡＣ_１’＝ＭＡＣ_ＥＸＰ、理想的には、ＭＡＣ_１’＝ＭＡＣ_ＥＸＰ＝ＭＡＣ_１）。この目的のために、受信ノードが常に、受信されたメッセージのペイロード・フィールドのデータに基づいて、送信されるべきメッセージのペイロード・フィールドのデータに基づいて送信ノードによって計算されたＭＡＣコードを復元することが可能となるように、ネットワーク２のすべてのノードＥ_１－Ｅ_Ｎが共通の暗号化メカニズム（たとえば、アルゴリズム）を共有することは明白である。

受信ノードは、期待されるＭＡＣコードを計算した後に、受信されたＭＡＣコードとの比較を実行し、それらがまったく同じであるか否かを検出することが可能である。それらがまったく同じであった場合には、関連するメッセージが受け入れられて処理される。それらがまったく同じではなかった場合においては、対応策を取ることが可能であり、たとえば、正しくないコードＭＡＣ_１’の計算の基礎となったメッセージＭｓｇ_１－Ｍｓｇ_３がリジェクトされ、関連するエラー・メッセージが、エラーを検出したノードによって送信される。受信したＭＡＣコードと期待されるそれの間に不一致が存在するためにリジェクトが反復されるメッセージを同一のノードが送信していることを受信ノードが認めた場合において（たとえば、メッセージの数があらかじめ決定済みの値を超えたとき）、当該受信ノードは、その送信ノードを「損なわれている可能性がある」と見做し、かつあらかじめ定義済みの時間期間にわたってそれを無視する決定をすることができる。そのあらかじめ定義済みの時間期間が経過した後に受信ノードは、その送信ノードから到来するメッセージの処理の再開を決定することができる。

引き続き図５を参照すると、ノードＥ_Ｎは、ステップ２０４においてさらなるメッセージＭｓｇ４－Ｍｓｇ６を順番に獲得し、かつメッセージＭｓｇ４－Ｍｓｇ６のデータＤａｔａ４－Ｄａｔａ６の関数としてノードＥ_１によって計算されたＭＡＣ_２コードを含む認証フレーム２０を獲得する（ステップ２０５）。その後、ステップ２０６において、ノードＥ_Ｎは、手前の説明と類似する態様でコードＭＡＣ_２の真正をチェックする。

このプロシージャは、送信ノードＥ_１によって送信されたすべてのメッセージが受信され、処理されるまで続けられる。

ハッカーまたは悪意のある意図を持った者またはそのほかの者がＣＡＮバス４に望ましくないデータ・フレームを書き込む場合において、書き込んだデータ・フレームがノードＥ_１－Ｅ_Ｎによって受け入れられるためには、それらの者は、ＭＡＣコードを生成するための方法もまた知らなければならない。実際に、手前で論じたとおり、各受信ノードによる自身宛のメッセージの受け入れは、常に、各ノードＥ_１－Ｅ_Ｎ内に常駐する（機密の）アルゴリズムに基づいて計算されたＭＡＣコードが正しいことの検証を受ける。その種の検証および肯定応答がない場合には、上で論じられているとおり、受信ノードがアラーム状態に入り、適切な対応策が取られる。

本発明の非限定的な好ましい実施態様においては、ＭＡＣコードがＡＥＳ－ＣＭＡＣ暗号化アルゴリズムを使用して計算される（これにおいて、ＡＥＳは「Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ（アドバンスド・エンクリプション・スタンダード）」を表し、ＣＭＡＣは「Ｃｉｐｈｅｒ－ｂａｓｅｄ Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ（サイファー・ベースド・メッセージ・オーセンティケーション・コード）」を表す）。

ＡＥＳ－ＣＭＡＣアルゴリズムは、それ自体は周知であり、通常、暗号化アルゴリズムＡＥＳ１２８を利用してＭＡＣコードを計算する。ＡＥＳ－ＣＭＡＣ暗号化アルゴリズムは、暗号鍵Ｋの使用を要求する。本発明のある態様によれば、各ノードＥ_１－Ｅ_Ｎが、受信したＭＡＣコードと期待されるＭＡＣコードの間の比較（図５のステップ２０３および２０６）を受信時に行うために、受信したデータおよび暗号鍵Ｋに基づいて関連するＭＡＣコードを計算することが可能となるように暗号鍵Ｋが各ノードＥ_１－Ｅ_Ｎのローカル・メモリ内に保存されている（すなわち、同一の鍵Ｋが各ノードＥ_１－Ｅ_Ｎによって共有されている）。

本発明の別の態様によれば、各送信ノードＥ_１－Ｅ_Ｎと関連付けされたそれぞれの鍵Ｋ_１－Ｋ_Ｎが提供される；したがって、特定の送信ノードによって送信されたメッセージの真正のチェックに関心があるか、またはメッセージの受信ノードとして特別に設計され、それを受信しなければならない受信ノード（または、複数の受信ノード）の中にのみ同一の鍵Ｋ_１－Ｋ_Ｎを保存することが可能である。

なお、ＡＥＳ－ＣＭＡＣアルゴリズムが、データ・フレームのペイロード・フィールド１０ｂに含まれているデータと（バイトにおいて）同じ長さを有するＭＡＣコード、またはそれより長い長さのコードを生成するという事実は、無関係であることに注意する。実際に、暗号化アルゴリズムによって生成されたコードが、データ・フレームのペイロード内に書き込むには大きすぎるバイト数で表現される場合においては、データ・フレーム１０のフォーマットと等しいフォーマットを有する認証フレーム２０によって伝送可能なデータの最大長に関する要件を尊重するために、その種のＭＡＣコードの切り捨てのための演算を実行することが可能である。

このことは、たとえば、メッセージＭｓｇ１－Ｍｓｇ３のペイロード・フィールド１０ｂ内において伝送されるデータＤａｔａ１－Ｄａｔａ３が８バイトで表現される場合には、Ｄａｔａ１－Ｄａｔａ３に基づいてＡＥＳ－ＣＭＡＣアルゴリズムによって計算されるコードＭＡＣ_１もまた、８バイトで表現され得ることを意味する。このように、ＣＡＮ標準によって定義されるデータ・フレーム１０と、フォーマットの観点から、完全に類似する認証フレーム２０内において伝送されることが可能なＭＡＣ認証コードを有することという要件が尊重される。

これに関して言えば、ＡＥＳ－ＣＭＡＣ標準が、セキュリティの理由のために８バイト（または、８バイトの倍数）を要求することに注意する。送信されるメッセージのペイロードが８バイトより小さいサイズを有している場合には、要求されている最小８バイトの完成が保証されるように、「パディング」演算（すなわち、０が追加される）が提供される。

概して言えば、一般的なネットワークのために、ＭＡＣコードは、任意バイト数を有することが可能である。

本発明のさらなる態様によれば、提案の方法の堅牢性を改善するため、したがってネットワーク２のセキュリティを増すために、検討されているメッセージのペイロード・フィールド１０ｂのデータに加えて、さらなるパラメータの関数としてＭＡＣコードを計算することも可能である。

具体的に述べると、実施態様によれば、ＡＥＳ－ＣＭＡＣ暗号化アルゴリズムのための有効な入力も構成可能であるように、ペイロード・フィールド１０ｂによって伝送することが可能なバイト数と等しいバイト数で表されるインクリメンタル単調カウンタが実装される。たとえば、ペイロード・フィールド１０ｂに８バイトを伝送する能力があるとき、単調カウンタは、８バイトで実装される。８バイトが、その単調カウンタが実装される乗り物１の全動作寿命をカバーするに充分であることに注意する。たとえば、毎秒１単位で単調カウンタを増加させることによって、２^６４秒後に８バイトで表現可能な最大値に到達し、これは、５８４×１０^９年を超える長さに対応する。

手前に述べられているとおり、この単調カウンタは、一般的なネットワークのために任意バイト数で表現することが可能である（８バイトである必要性はない）。

図６Ａは、以上の説明を送信ノードＥ_１によって行われる動作に関して、機能ブロック図を用いてグラフィカルに図解している。

図６Ｂは、以上の説明を受信ノードＥ_Ｎによって行われる動作に関して、機能ブロック図を用いてグラフィカルに図解している。

図６Ａを参照するが、図解されている動作は、独自のコントローラまたはプロセッサとローカル・メモリを有し、ＣＡＮプロトコルおよび説明済みの暗号化動作を実装するべく適切に構成された送信ノードＥ_１によって実行される。図６Ａのブロック４０は、ＡＥＳ－ＣＭＡＣ暗号化アルゴリズムの入力を表し、ノードＥ_１によって連続的に送信される３つのメッセージＭｓｇ１－Ｍｓｇ３のデータ・コンテンツＤａｔａ１－Ｄａｔａ３（ペイロード・フィールド１０ｂ）と、それに加えて、ノードＥ_１内に常駐する単調カウンタ（図６Ａのブロック４２）の現在値ＭＣを含む。

データＤａｔａ１－Ｄａｔａ３と値ＭＣ（前述したとおり、この例においてはすべて８バイトで表される）が暗号化ブロック４４へ入力され、それが、ローカル・メモリ（ブロック４６）内に保存されている暗号鍵Ｋとともに上で論じられているＡＥＳ－ＣＭＡＣ暗号化アルゴリズムを実行する。

暗号化ブロック４４は、ＭＡＣコード（この例においては、同じく８バイトのＭＡＣ_１－－必要であれば、切り捨て演算が実行される）を生成し、対応する認証フレーム２０の生成のためにブロック４８へ送る。前述したとおり、認証フレーム２０は、フォーマットという点から見てデータ・フレーム１０との区別が不可能であり、したがって、認証フレーム２０を生成するブロック４８は、データ・フレームを生成するそれと同一である（したがって、それ自体は周知のタイプであり、さらなる説明はしない）。ブロック４８は、受信ノードＥ_Ｎへ送信されるべきデータＤａｔａ１－Ｄａｔａ３も受信し、関連するメッセージＭｓｇ１－Ｍｓｇ３を生成する。

メッセージＭｓｇ１－Ｍｓｇ３は、データＤａｔａ１－Ｄａｔａ３に基づいて生成された認証フレーム２０とともに、送信キュー（または、送信バッファ）５０内に書き込まれ、ノードＥ_Ｎを受信者としてＣＡＮバス４へ順番に送られる。メッセージＭｓｇ１－Ｍｓｇ３が最初に送信され、その後にコードＭＡＣ_１を含む関連認証フレーム２０が送信される。

ここで、受信ノードＥ_Ｎによって実行される動作を、機能ブロック図を用いてグラフィカルに図解した図６Ｂを参照する。当該受信ノードは、メッセージＭｓｇ１－Ｍｓｇ３と、コードＭＡＣ_１（または、前述の説明によれば、むしろ受信したコードＭＡＣ_１’）を含む認証フレーム２０とを受信し、それらを受信バッファ５９内に書き込む。

ノードＥ_Ｎは、続いて、図６Ａのブロック４０－４４を参照して上で説明した送信ノードＥ_１において実行される演算と同じ演算を再現することによって、期待されるＭＡＣコード（ＭＡＣ_ＥＸＰ）をローカルに計算する。具体的に述べれば、受信ノードＥ_Ｎは、メッセージＭｓｇ１－Ｍｓｇ３のペイロード・フィールド１０ｂ内に含まれているデータＤａｔａ１－Ｄａｔａ３、およびローカル単調カウンタ６２の現在値ＭＣ’を獲得し（ブロック６０）、それらを、暗号化ブロック４４と同じ暗号化アルゴリズム（ここでは、ＡＥＳ－ＣＭＡＣ）を実行する暗号化ブロック６４へ送る。

暗号化ブロック６４は、さらに、入力として暗号鍵Ｋ（ブロック６５内にローカルに保存されている）を受信し、受信したコードＭＡＣ_１’と比較される（ブロック６６）８バイトの数（可能性として、ブロック４４によって実行されるものと類似する切り捨てを伴う）を出力として生成する。この比較には、期待されるＭＡＣコード（ＭＡＣ_ＥＸＰ）と、受信したＭＡＣコード（ＭＡＣ_１’）の間における同一性の評価が意図されている。比較の結果（ＯＫ＝有効／ＮＯＴ ＯＫ＝無効）は、その後に続いて取られる動作を決定する。

上記の説明は、その後に続く送信／受信に対して、たとえば、関連するＭＡＣ_２コードを伝送する関連する認証フレーム２０を伴う３つのさらなるメッセージＭｓｇ４－Ｍｓｇ６の送信／受信のためにも類似した形で適用される。

単調カウンタの使用は、暗号化の完全性だけでなく、受信したデータの「新鮮さ」を保証する機能を有する。実際に、ハッカーまたは悪意のある意図を伴う者が、複数のデータ・フレームを、関連する認証フレーム２０とともに獲得し、その種のデータ・フレームおよび関連する認証フレーム２０（形式上は正しい）をＣＡＮバス４へ、乗り物１の寿命内における後の時点に再書き込みし、予測不可能なエラーを生じさせるといったことが起こる可能性がある。しかしながら、ＭＡＣコードが、常に、前述したとおり、乗り物１の動作寿命の間にわたって累進的であり、かつ変化するカウンタの現在値を頼ることから単調カウンタの存在がその種の可能性を断ち切る。

上に述べられているプロシージャは、ネットワーク２の任意のノードによる送信および受信動作に適用され、概して言えば、ネットワーク２の各ノードＥ_１－Ｅ_Ｎが、ＣＡＮプロトコルおよび送信および受信を参照して説明した暗号化／復号化動作（図６Ａ、６Ｂ）を実装するべく適切に構成された、それ独自のコントローラまたはプロセッサおよびローカル・メモリを装備していることに注意する。

それに加えて、各ノードＥ_１－Ｅ_Ｎは、それ独自の、手前に述べられているタイプのインクリメンタル単調カウンタを装備する。

各受信ノードが、認証フレーム２０を認識することを（かつ、それと一般的なデータ・フレーム１０と混同しないこと）保証するために、何らかの認識ストラテジを予備的に定義することが可能である。

たとえば、その意味において、認証フレーム２０のヘッダ・フィールド１０ａ内に、その種のフレームの識別、および対応するＭＡＣコードの計算が基礎とした先行するメッセージの数の両方に関係する表示を書き込むことが可能である。

異なる実施態様は、すべてのノードＥ_１－Ｅ_Ｎが、認証フレーム２０の認識のために採用されるべき同一のストラテジを共有すること、すなわち、その種の認証フレーム２０が、常に、あらかじめ定義済みの数のメッセージ（データ・フレーム）の後に生成される（したがって、常に受信される）という事実を提供する。手前で論じられている例においては、その種の数が３に等しい（Ｍｓｇ１－Ｍｓｇ３およびＭｓｇ４－Ｍｓｇ６のグループ）。しかしながら、その後に続いて認証フレーム２０が送信される（したがって、受信される）データ・フレームの数を任意（２以上）に定義可能であることは明白であり、それにおいては、伝送されるＭＡＣコードが、あらかじめ定義済みの数の先行するデータ・フレームのデータに基づいて計算される。この文脈において、またノードＥ_１とＥ_Ｎの間の通信が単一メッセージを伴って完了する場合において、ゼロ情報コンテンツまたはあらかじめ定義済みの情報を有し、受信ノードによって適切に管理されるさらなるデータ・フレームの送信が（認証フレーム２０の生成のために必要とされるあらかじめ定義済みの数のフレームに到達するまで）提供可能であることは明白である。

上記の説明は、送信ノードＥ_１による送信および受信ノードＥ_Ｎによって受信された情報の処理が、ローカル・カウンタ４２、６２の値ＭＣ／ＭＣ’の変化未満の時間間隔内に開始し、かつ終了する場合において有効である。実際に、ローカル・カウンタの値ＭＣ／ＭＣ’が送信と受信において異なる場合には、図６Ｂのブロック６６の比較が信頼性のある応答を与えないことになる。

ＣＡＮバス４への送信は、概して非常に迅速（数千分の１秒台）であるが、その種の欠点は、１つ以上のストラテジを採用することによって救済が可能である。

たとえば、可能性のある実施態様においては、あらかじめ決定済みの時間間隔（たとえば、２－５秒）の後にカウント単位で増加され、その種の時間間隔内における関心フレーム（データおよび関連するＭＡＣコードを含む）の送信、受信、および処理が常に保証されるように、ノードＥ_１－Ｅ_Ｎの各ローカル・カウンタを構成することが可能である。

さらなる実施態様においては、受信ノードＥ_Ｎが、認証フレームの受信の時点に先行する時間間隔Ｔ_Ｃ（たとえば、２－５秒）の間に、カウンタ６２の複数の値ＭＣ’を獲得し、保存することが可能である。その後ブロック６４が、それぞれを、受信したデータ（Ｄａｔａ１－Ｄａｔａ３）およびカウンタ６２によって供給された異なる値ＭＣ’（すなわち、カウンタ６２が認証フレームの受信の時点に仮定した値、およびカウンタ６２が時間間隔Ｔ_Ｃ内に仮定したすべての値の両方）の関数として複数のＭＡＣコードを計算する。

さらなる実施態様においては、受信ノードＥ_Ｎが、認証フレーム２０の受信の時点に関して中心決めされるか、またはブロック６４によるＭＡＣコードの計算の時点に関して中心決めされる時間間隔の間に、カウンタ６２の複数の値ＭＣ’を獲得し、保存することが可能である。その種の中心決めされた時間間隔は、認証フレームの受信および／または計算の時点に先行する時間間隔Ｔ_Ｃ（たとえば、２－５秒）と、認証フレームの受信／計算の時点の後に続く時間間隔Ｔ_Ｐ（たとえば、１－２秒）とを含む；その種の中心決めされた時間間隔は、認証フレーム２０の受信および／または計算の時点も含む。その後ブロック６４が、それぞれを、受信したデータ（Ｄａｔａ１－Ｄａｔａ３）およびカウンタ６２によって供給されたそれぞれ複数の値ＭＣ’（すなわち、カウンタ６２が認証フレームの受信／計算の時点に仮定した値、およびカウンタ６２が時間間隔Ｔ_Ｃおよび時間間隔Ｔ_Ｐ内に仮定したすべての値の両方）の関数として複数のＭＡＣコードを計算する。

その種のＭＡＣコードは、その後、比較ブロック６６へ供給され、それがそれらを獲得する。比較は、認証フレーム２０（図６ＢのＭＡＣ_１’）とともに受信されたＭＡＣコードが、暗号化ブロック６４によって計算された複数のＭＡＣコードのうちの少なくとも１つと等しい場合に、肯定的な結果（ＯＫ）を有する。

互いに関して同期外れを生じる可能性のある、ノードＥ_１－Ｅ_Ｎのローカル単調カウンタに考えられるドリフトを未然に防ぐために、本発明は２つの可能性のある変形を提供し、それについて次に論じる。

第１の変形においては、ノードＥ_１－Ｅ_Ｎのうちの１つがマスター・ノードの役割を担うものとし、残りのノードがスレーブ・ノードの役割を担うものとする。

この場合において、マスター・ノードは、ランダムまたはあらかじめ決定済みの時点においてＣＡＮバス４へ、それ独自の単調カウンタの更新済みの値ＭＣ_ｎｅｗを送信する。その種の更新済みの値ＭＣ_ｎｅｗは、カウンタの現在値、またはそれ独自のローカル・クロックの値ＭＣ_{ＩＮＴ＿ＣＬＯＣＫ}（たとえば、マスター・ノードのコントローラまたはプロセッサのクロック）の関数として計算し、それに、たとえば数秒、特に１０秒から２０秒までの間に等しいあらかじめ決定済みまたはランダムな値の正のオフセット「ＯＦＦＳＥＴ」を追加した値とすることが可能である：ＭＣ_ｎｅｗ＝ＭＣ_{ＩＮＴ＿ＣＬＯＣＫ}＋ＯＦＦＳＥＴ。

スレーブ・ノードは、値ＭＣ_ｎｅｗを受信し、それら独自のローカル・カウンタの値を新しい値ＭＣ_ｎｅｗに更新する。より高いセキュリティのために、非限定的な実施態様においては、各スレーブ・ノードによって、それ独自のローカル・カウンタの現在値より受信したＭＣ_ｎｅｗの値が大きい場合だけに限って、更新が実行される。スレーブ・ノードによって値ＭＣ_ｎｅｗが正しく受信されなかった場合には、ネットワークの多様なノードの間に同期外れが生じる（すべてのノードによって生成されるＭＡＣコードが誤りのあるものとなる）；マスター・ノードは、先行するＭＣ値を用いたクロス・チェックを実施することによってこの望ましくない状況を検出することが可能である（すなわち、マスター・ノードを、ネットワークのノードが更新後の値とは異なる古いＭＣ値を使用していることを認識するべく構成することが可能である）。

カウンタを正しい値に修復するために、マスター・ノードは、この状況において、更新済みの値ＭＣ_ｎｅｗを再送する。さらに、カウンタの値の更新の間にスレーブ・ノードがＣＡＮネットワークから接続解除されるか、または何らかの理由で同期が失われた場合においては、マスター・ノードがその種の状況を検出し、新しい値ＭＣ_ｎｅｗを再送することによって正しい機能の回復が可能であることに注意する。

第２の変形においては、ノードＥ_１－Ｅ_Ｎの間に「ピア・トゥ・ピア」構成が存在する。

この場合においては、すべてのノードＥ_１－Ｅ_Ｎが、前述に類似する、現在値より大きい単調カウンタの新しい値ＭＣ_ｎｅｗを（周期的またはランダムな時点において）送信する：ＭＣ_ｎｅｗ＝ＭＣ_{ＩＮＴ＿ＣＬＯＣＫ}＋ＯＦＦＳＥＴ。他方のノードＥ_１－Ｅ_Ｎは、新しい値ＭＣ_ｎｅｗを受信し、受信した新しい値ＭＣ_ｎｅｗがそれら独自の内部カウンタの現在値より大きい場合だけに限って、それぞれのカウンタを更新する。ピア・トゥ・ピア構成の場合においては、ネットワークのすべてのノードによって値ＭＣ_ｎｅｗが正しく受信されなかった（たとえば、いくつかのノードが古いＭＣ値を使用している）場合に、更新されていないＭＣ値を使用しているノードが、新しい値ＭＣ_ｎｅｗを再送する。それに加えて、カウンタの値の更新の間にノードがＣＡＮネットワークから接続解除されるか、または何らかの理由で同期が失われた場合においては、ＭＡＣコードを正しく計算することが可能でないノードによって値ＭＣ_ｎｅｗが直ちに送信される。

上で述べた変形の両方においては、ＯＦＦＳＥＴ値が、ＣＡＮバス４上に存在可能な最大伝播遅延より大きくなるような態様で、かつ送信および受信ステップにおける潜在的な処理遅延も考慮に入れて生成されることに注意する。クロックの時間ドリフトを考慮に入れることも有利である。

さらに、カウンタの値ＭＣ_ｎｅｗが８バイトで表現され、その種の値は、ＣＡＮプロトコルに従ったあらかじめ定義済みのデータ・フレームを使用して送信が可能であることに注意する。類似した形で、異なるプロトコルが使用される場合においても、使用されるプロトコルの仕様に従った適切なバイト数のカウンタの値ＭＣを、これが表現して適用される。

値ＭＣ_ｎｅｗの送信は、専用のメッセージ（たとえば、ＭＡＣコードに関する前述の説明に類似した態様でデータ・フレームと同じ構造を有する）を使用することによって生じることが可能である；受信ステップのＭＡＣ計算においては、その値ＭＣ_ｎｅｗが直接使用される。

１つの実施態様においては、コードＭＣ_ｎｅｗを含むフレームが、通常のデータ・フレームと比較してより高い優先度を伴って構成される。

図７Ａ（図６Ａと共通の要素は、同一の参照番号によって識別されている）は、データ・フレームに類似する専用メッセージ７０を用いて値ＭＣ_ｎｅｗを生成し、送信するステップをグラフィカルに図解している。

カウンタ４２が、更新後の値ＭＣ_ｎｅｗを生成するために、（手前で述べたとおり）ＯＦＦＳＥＴ値を用いて更新される。図７Ａのブロック４０は、ＡＥＳ－ＣＭＡＣ暗号化アルゴリズムの入力を表し、ノードＥ_１によって送信される２つのメッセージＭｓｇ１およびＭｓｇ３のデータ・コンテンツＤａｔａ１およびＤａｔａ３（ペイロード・フィールド１０ｂ）と、それに加えて単調カウンタ（ブロック４２）の更新後の値ＭＣ_ｎｅｗとを、図６Ａを参照した手前の説明と類似した態様で含む。図７Ａの場合においては、単調カウンタ４２の更新後の値ＭＣ_ｎｅｗの共有が、データメッセージＭｓｇ２（図６Ａの例にあったもの）を、（手前に述べられているマスタ／スレーブまたはピア・トゥ・ピア・ストラテジに従って）ネットワークのほかのノードとの共有が望まれる単調カウンタ４２の更新後の値ＭＣ_ｎｅｗを伝送する等価のメッセージと置き換えることによって生じる。言い換えると、値ＭＣ_ｎｅｗは、あたかもそれが、ちょうど図６ＡのデータＤａｔａ２と同様の情報データであるかのように扱われ、かつ送信される。

図７Ｂ（図６Ｂと共通の要素は、同一の参照番号によって識別されている）の受信ステップにおいては、更新後の値ＭＣ_ｎｅｗがローカル・カウンタ６２へ供給され、続いてそれが、ブロック６０へそれを供給し、そこでこの値がＭＡＣコードの計算のために使用される。代替実施態様において、ローカル・カウンタ６２をバイパスして更新後の値ＭＣ_ｎｅｗを直接ブロック６０へ供給可能であることは明白である。

ブロック６０－６６は、Ｄａｔａ２の代わりに値ＭＣ_ｎｅｗを、値ＭＣ’の代わりに同じ値ＭＣ_ｎｅｗを使用し、図６Ｂを参照した手前の説明と類似した形で動作する。

ブロック６６によって実施される比較が肯定的な応答（「ＯＫ」）を与えた場合には、新しい値ＭＣ_ｎｅｗへのローカル・カウンタ６２の更新が確認される；それ以外であれば、受信ノードＥ_Ｎの再同期のためのストラテジが実行される。

上に述べられ、図解されていることに基づけば、ここに述べられているシステムによって得ることが可能な利点は明白である。

図８を参照すると、乗り物１のオンボード・システム７４をコントロールするために使用されるオンボード電子システム７２を含む乗り物１が示されている。乗り物１は、略図的にのみ表現されているが、自動車、自動二輪車、トラック、スポーツカー、ＳＵＶ、レクリエーショナル・ビークル、ボート、航空機等とすることが可能である。オンボード電子システム７２およびオンボード・システム７４は、通信バス７６、たとえば、手前に述べられているＣＡＮバス４を用いて相互通信する態様で接続される電子コントロール・ユニット（ＥＣＵ_１、ＥＣＵ_２、・・・、ＥＣＵ_Ｎ－－手前で論じたノードＥ_１、Ｅ_２、・・・、Ｅ_Ｎに対応する）の図解的な配置を含む。

オンボード電子システム７２は、たとえば、診断、監視、コントロール、レポーティング動作、および／またはそのほかの機能を実行するために１つ以上のセンサからの入力を受信するべく構成された、乗り物１全体にわたって分配される電子ハードウエア構成要素の形式で複数のＥＣＵを含むことが可能である。少なくとも２つの、またはすべてのＥＣＵが、バス７６を用いて互いに接続される；各ＥＣＵは、乗り物１のオンボード・システム７２をコントロールするべくプログラムすることが可能である。オンボード電子システム７２またはオンボード・システム７４の一部として示されている各ＥＣＵは、概して、マイクロプロセッサと、当該マイクロプロセッサによって読み取り可能なインストラクションを保存している不揮発性メモリ・デバイスと、バス７６上におけるデータおよびそのほかのコントロール情報の送信および受信のための入力／出力ポート（Ｉ／Ｏ）とを包含する。これらの構成要素は、それぞれのＥＣＵがコントロールする乗り物１の特定のシステム、および使用されるバス７６のタイプに基づいて変更することが可能である。マイクロプロセッサのパワーおよび処理の精巧さ、Ｉ／Ｏの数、およびマイクロプロセッサによって読み取り可能なインストラクションまたはソフトウエアの複雑さは、乗り物１のタイプおよび機能に基づいて増加、または減少させることが可能である。マイクロプロセッサは、電子インストラクションを処理する能力のある任意タイプのデバイスとすることが可能であり、それには、マイクロコントローラ、ホスト・プロセッサ、コントローラ、乗り物のための通信プロセッサ、および特定用途向け集積回路（ＡＳＩＣ）が含まれる。マイクロプロセッサは、メモリ・デバイス内に保存されたソフトウエアまたはファームウエア・プログラム等の、デジタル保存された種々のタイプのインストラクションを実行する。たとえば、マイクロプロセッサは、手前に図３、５、６Ａ、６Ｂを参照して論じられている方法の少なくとも一部を実行するために、プログラムを実行し、またはデータを処理することが可能である。メモリ・デバイスは、周知のタイプのランダム・アクセス・メモリ（ＲＡＭ）またはＥＥＰＲＯＭメモリを使用して実装可能であり、Ｉ／Ｏは、ＣＡＮコントローラ等のコントローラ、または使用されるバス７６のタイプに応じた何らかのそのほかの手段を使用して実装することが可能である。その意味において、ＥＣＵは、乗り物１上において使用される特定のタイプのバス７６と互換性のあるハードウエアを含むことが可能である。たとえば、ＣＡＮバスを使用して通信するＥＣＵは、マイクロプロセッサ、ＣＡＮコントローラ、およびＣＡＮバス上においてメッセージを送受信するトランシーバの形式のＩ／Ｏユニットを含むことが可能である。

特に本発明は、ネットワークのノードの間における（特に、乗り物のＥＣＵの間における）ネットワークおよび乗り物の現在のアーキテクチャ上の構成を変更することがなく、かつネットワークの動作が基礎とするプロトコル標準の部分を形成しない新しい通信テクノロジの使用を求めることのない、安全かつ実装可能な通信方法およびシステムを提案する。したがって、実装コストもまた、特に妥当性がある。

最後に、ここで述べられ、図解されていることに対する修正および変形を、付随する特許請求の範囲に定義されているとおりの本発明の保護範囲からの逸脱なしに実行可能であることは明らかである。

特に本発明は、ＣＡＮバスとは異なるタイプの送信ネットワーク、たとえば、ＣＡＮ－ＦＤプロトコルに基づくネットワーク、ＴＣＰ／ＩＰプロトコル、ローカル相互接続ネットワーク（ＬＩＮ）、メディア指向シリアル・トランスポート（ＭＯＳＴ）、イーサネット、ローカル・エリア・ネットワーク（ＬＡＮ）等々に基づくネットワークに適用可能である。

特に、本発明は、有線または無線送信ネットワークに適用することが可能である。

それに加えて、ＡＥＳ－ＣＭＡＣ暗号化方法が明示的に述べられているが、異なる暗号化方法およびアルゴリズムを、たとえば、ＨＭＡＣ（「キード・ハッシュ・メッセージ認証符号」）、ＫＭＡＣ（「ＫＥＣＣＡＫメッセージ認証コード」）、ＧＭＡＣ（「ガロア・メッセージ認証符号」）、またはそのほかの、たとえば、ＤＡＡ、ＣＢＣ－ＭＡＣ、ＮＭＡＣ、ＯＭＡＣ／ＣＭＡＣ、ＰＭＡＣ、ＶＭＡＣ、ＵＭＡＣ、Ｐｏｌｙ１３０５、ＳｉｐＨａｓｈ等、およびさらにほかのアルゴリズムさえ使用することが可能である。

さらにまた、ＭＡＣコードの生成のために使用可能な暗号化アルゴリズムを多様なタイプのものとし得ることは明白である；たとえば、対称型暗号化アルゴリズム（暗号鍵ＫがすべてのノードＥ_１－Ｅ_Ｎに保存される）または非対称型暗号化アルゴリズム（公開鍵がすべてのノードＥ_１－Ｅ_Ｎに保存され、秘密鍵は、単一のノードにおいて利用可能）を使用することが可能である。

それに代えて、次に例証するとおり、ノード毎に異なる秘密鍵Ｋ_１、Ｋ_２、・・・、Ｋ_Ｎと、関連する公開鍵Ｐ_１、Ｐ_２、・・・、Ｐ_Ｎをすべてのノードに提供することが可能である。
ノードＥ_１：（Ｋ_１、Ｐ_２、・・・、Ｐ_Ｎ）、
ノードＥ_２：（Ｋ_２、Ｐ_１、Ｐ_３、・・・、Ｐ_Ｎ）、
・・・、
ノードＥ_Ｎ：（Ｋ_Ｎ、Ｐ_１、Ｐ_２、・・・、Ｐ_Ｎ－１）。

１ 乗り物
２ ネットワーク、通信ネットワーク
４ バス、ＣＡＮバス
１０ データ・フレーム
１０ａ ヘッダ・フィールド
１０ｂ ペイロード・フィールド、データ・フィールド
１０ｃ ＣＲＣフィールド、巡回冗長検査フィールド
１０ｄ ＡＣＫフィールド、肯定応答フィールド
１０ｅ ＥＯＦフィールド、エンド・フィールド
２０ 認証フレーム
２０ａ フィールド
４０ ブロック
４２ カウンタ、ブロック、単調カウンタ
４４ 暗号化ブロック
４８ ブロック
５０ 送信キュー、送信バッファ
５９ 受信バッファ
６０ ブロック
６２ ローカル単調カウンタ、カウンタ、ローカル・カウンタ
６４ ブロック、暗号化ブロック
６５ ブロック
６６ ブロック、比較ブロック
７０ 専用メッセージ
７２ オンボード電子システム
７４ オンボード・システム
７６ バス、通信バス
１０ａ－１０ｅ フィールド
Ｅ_１ ノード
Ｅ_Ｎ ノード
Ｍｓｇ１－Ｍｓｇ６ メッセージ

Claims (25)

1. 送信／受信プロトコルに従って動作する通信ネットワーク（２）におけるデータ交換のための方法であって、前記通信ネットワークが、送信バス（４）と、前記送信バス（４）に接続された第１のノード（Ｅ_１）および第２のノード（Ｅ_Ｎ）とを含み、前記方法が、前記第１のノード（Ｅ_１）によって実行される、
   － それぞれが前記プロトコルによって定義されるフレーム・フォーマットを有し、かつそれぞれのペイロード・フィールド（１０ｂ）であって、前記第２のノード（Ｅ_Ｎ）へ送信されるべきそれぞれの第１および第２の情報データ（Ｄａｔａ１、Ｄａｔａ２）を含むペイロード・フィールド（１０ｂ）を含む第１および第２のデータ・フレーム（１０）を構成するステップと、
   － 送信されるべき前記第１および第２の情報データ（Ｄａｔａ１、Ｄａｔａ２）の関数として第１のメッセージ認証コード（ＭＡＣ_１）を計算するステップと、
   － 前記プロトコルによって定義されるフレーム・フォーマットを有し、かつペイロード・フィールド（２０ａ）を含み、かつ前記ペイロード・フィールド（２０ａ）内に前記第１のメッセージ認証コード（ＭＡＣ_１）を含む第３のデータ・フレーム（２０）を構成するステップと、
   － 前記送信バス（４）へ、前記第１、前記第２、および前記第３のデータ・フレームを送信するステップと、
   を包含し、さらに前記方法が、前記第２のノード（Ｅ_Ｎ）によって実行される、
   － 前記送信バス（４）から前記第１、前記第２、および前記第３のデータ・フレーム（１０、２０）を受信するステップと、
   － 受信した前記第１のデータ・フレーム（１０）から前記第１の情報データ（Ｄａｔａ１）を、受信した前記第２のデータ・フレーム（１０）から前記第２の情報データ（Ｄａｔａ２）を、受信した前記第３のデータ・フレーム（２０）から前記第１のメッセージ認証コード（ＭＡＣ_１、ＭＡＣ_１’）を抽出するステップと、
   － 抽出した前記第１および第２の情報データ（Ｄａｔａ１、Ｄａｔａ２）の関数として第２のメッセージ認証コード（ＭＡＣ_ＥＸＰ）を計算するステップと、
   － 抽出した前記第１のメッセージ認証コード（ＭＡＣ_１、ＭＡＣ_１’）と、計算した前記第２のメッセージ認証コード（ＭＡＣ_ＥＸＰ）とを比較するステップと、
   － 抽出した前記第１のメッセージ認証コード（ＭＡＣ_１、ＭＡＣ_１’）が計算した前記第２のメッセージ認証コード（ＭＡＣ_ＥＸＰ）と同一である場合だけに限って、前記第１および第２のデータ・フレーム（１０）を受け入れるステップと、
   を包含する方法。
2. 前記第１のメッセージ認証コード（ＭＡＣ_１）を計算するステップは、さらに、暗号鍵（Ｋ）の関数として前記第１のメッセージ認証コード（ＭＡＣ_１）を計算することを包含し、
   前記第２のメッセージ認証コード（ＭＡＣ_ＥＸＰ）を計算するステップは、さらに、復号鍵（Ｋ）の関数として前記第２のメッセージ認証コード（ＭＡＣ_ＥＸＰ）を計算することを包含し、
   それにおいて、前記暗号鍵は、前記復号鍵に対応し、したがって、対称型暗号化アルゴリズムを実装し、
   それに代えて、前記暗号鍵は、秘密鍵であり、前記復号鍵は、前記暗号鍵と異なる公開鍵であり、したがって、非対称型暗号化アルゴリズムを実装する、
   請求項１に記載の方法。
3. 前記第１のメッセージ認証コード（ＭＡＣ_１）を計算するステップは、さらに、第１のインクリメンタル単調カウンタ（４２）から前記第１のノード（Ｅ_１）へ供給される第１のカウント値（ＭＣ）の関数として前記第１のメッセージ認証コード（ＭＡＣ_１）を計算することを包含し、
   前記第２のメッセージ認証コード（ＭＡＣ_ＥＸＰ）を計算するステップは、さらに、第２のインクリメンタル単調カウンタ（６２）から前記第２のノード（Ｅ_Ｎ）へ供給される第２のカウント値（ＭＣ’）の関数として前記第２のメッセージ認証コード（ＭＡＣ_ＥＸＰ）を計算することを包含し、
   前記第１のメッセージ認証コード（ＭＡＣ_１、ＭＡＣ_１’）は、送信されるべき前記第１および第２の情報データが、抽出された前記第１および第２の情報データと同一であり、かつ前記第１のカウント値（ＭＣ）が前記第２のカウント値（ＭＣ’）と同一である場合だけに限って前記第２のメッセージ認証コード（ＭＡＣ_ＥＸＰ）と同一となる、
   請求項１または２に記載の方法。
4. 前記第２のメッセージ認証コード（ＭＡＣ_ＥＸＰ）を計算するステップは、さらに、前記第２の値（ＭＣ’）を受信する時点に先行する時間フレームの間に前記第２のインクリメンタル単調カウンタ（６２）から前記第２のノード（Ｅ_Ｎ）へ供給される１つ以上のさらなるカウント値（ＭＣ’）に関して実行され、
   前記方法は、さらに、
   － 前記第２のノード（Ｅ_Ｎ）において、それぞれの前記１つ以上のさらなるカウント値（ＭＣ’）の関数として１つ以上のさらなるメッセージ認証コードを計算するステップと、
   － 前記第２のノード（Ｅ_Ｎ）において、抽出された前記第１のメッセージ認証コード（ＭＡＣ_１、ＭＡＣ_１’）と、前記１つ以上のさらなるメッセージ認証コードのそれぞれとを比較するステップと、
   － 抽出された前記第１のメッセージ認証コード（ＭＡＣ１、ＭＡＣ１’）が前記１つ以上のさらなるメッセージ認証コードのうちの少なくとも１つと同一である場合だけに限って前記第２のノード（Ｅ_Ｎ）が前記第１および第２のデータ・フレーム（１０）を受け入れるステップと、
   を包含する、請求項３に記載の方法。
5. さらに、前記第１および第２のインクリメンタル単調カウンタ（４２、６２）を互いに同期させるステップを包含する、請求項３または４に記載の方法。
6. 前記第１および第２のインクリメンタル単調カウンタ（４２、６２）を互いに同期させるステップは、前記第１および第２のノードのうちの１つをマスター・ノードとして、かつ前記第１および第２のノードのうちのそのほかをスレーブ・ノードとして設定するステップと、前記マスター・ノードによって、前記送信バス（４）へ同期信号を送信するステップと、前記スレーブ・ノードによって、前記送信バス（４）から前記同期信号を受信するステップと、受信した前記同期信号の関数として前記スレーブ・ノードの呼応する前記第１または第２のインクリメンタル単調カウンタ（４２、６２）の値を更新するステップと、を包含する、請求項５に記載の方法。
7. 前記第１および第２のインクリメンタル単調カウンタ（４２、６２）を互いに同期させるステップは、前記第１および第２のノードのうちの任意の１つによって、前記送信バス（４）へ同期信号を送信するステップと、前記第１および第２のノードのうちのそのほかによって、前記送信バス（４）から前記同期信号を受信し、かつ、受信した前記同期信号の関数として呼応する前記第１または第２のインクリメンタル単調カウンタ（４２、６２）の値を更新するステップと、を包含する、請求項５に記載の方法。
8. 前記第１のメッセージ認証コード（ＭＡＣ_１）を計算するステップは、ＡＥＳ－ＣＭＡＣ暗号化アルゴリズムを実行することを包含する、請求項１から７のいずれかに記載の方法。
9. 前記プロトコルは、データタイプのフレーム・フォーマットを定義するＣＡＮプロトコルであり、
   前記第１、前記第２、および前記第３のデータ・フレームは、すべて、前記プロトコルによって定義される前記タイプと同一のフレーム・フォーマットを有する、
   請求項１から８のいずれかに記載の方法。
10. 前記送信バス（４）は、乗り物（１）のＣＡＮバスであり、前記第１のノード（Ｅ_１）は、前記乗り物（１）の第１のＥＣＵであり、前記第２のノード（Ｅ_Ｎ）は、前記乗り物（１）の第２のＥＣＵである、請求項１から９のいずれかに記載の方法。
11. 前記第１、前記第２、および前記第３のデータ・フレーム（１０、２０）の前記ペイロード・フィールド（１０ｂ、２０ａ）は、前記プロトコルによって定義されるバイト数を伝送するべく構成され、前記第１および第２のメッセージ認証コード（ＭＡＣ_１、ＭＡＣ_ＥＸＰ）は、前記プロトコルによって定義される前記バイト数と等しいバイト数で表現される、請求項１から１０のいずれかに記載の方法。
12. 前記第１および第２のカウント値（ＭＣ、ＭＣ’）は、前記プロトコルによって定義される前記バイト数と等しいバイト数で表現される、請求項３、または請求項３に従属するときの請求項４から１１のいずれかに記載の方法。
13. 送信バス（４）、前記送信バス（４）に接続された第１のノード（Ｅ_１）と前記送信バス（４）に接続された第２のノード（Ｅ_Ｎ）を含む通信ネットワーク（２）を含む送信／受信プロトコルに従って動作するデータ交換システムであって、
    前記第１のノード（Ｅ_１）が、
    － それぞれが前記プロトコルによって定義されるフレーム・フォーマットを有し、かつそれぞれのペイロード・フィールド（１０ｂ）であって、前記第２のノード（Ｅ_Ｎ）へ送信されるべきそれぞれの第１および第２の情報データ（Ｄａｔａ１、Ｄａｔａ２）を含むペイロード・フィールド（１０ｂ）を含む第１および第２のデータ・フレーム（１０）を構成し、
    － 前記送信されるべき前記第１および第２の情報データ（Ｄａｔａ１、Ｄａｔａ２）の関数として第１のメッセージ認証コード（ＭＡＣ_１）を計算し、
    － 前記プロトコルによって定義されるフレーム・フォーマットを有し、かつペイロード・フィールド（２０ａ）を含み、かつ前記ペイロード・フィールド（２０ａ）内に前記第１のメッセージ認証コード（ＭＡＣ_１）を含む第３のデータ・フレーム（２０）を構成し、かつ、
    － 前記送信バス（４）へ、前記第１、前記第２、および前記第３のデータ・フレームを送信するべく構成され、
    前記第２のノード（Ｅ_Ｎ）が、
    － 前記送信バス（４）から前記第１、前記第２、および前記第３のデータ・フレーム（１０、２０）を受信し、
    － 受信した前記第１のデータ・フレーム（１０）から前記第１の情報データ（Ｄａｔａ１）を、受信した前記第２のデータ・フレーム（１０）から前記第２の情報データ（Ｄａｔａ２）を、受信した前記第３のデータ・フレーム（２０）から前記第１のメッセージ認証コード（ＭＡＣ_１、ＭＡＣ_１’）を抽出し、
    － 抽出した前記第１および第２の情報データ（Ｄａｔａ１、Ｄａｔａ２）の関数として第２のメッセージ認証コード（ＭＡＣ_ＥＸＰ）を計算し、
    － 抽出した前記第１のメッセージ認証コード（ＭＡＣ_１、ＭＡＣ_１’）と、前記第２のメッセージ認証コード（ＭＡＣ_ＥＸＰ）とを比較し、かつ、
    － 抽出した前記第１のメッセージ認証コード（ＭＡＣ_１、ＭＡＣ_１’）が前記第２のメッセージ認証コード（ＭＡＣ_ＥＸＰ）と同一である場合だけに限り、前記第１および第２のデータ・フレーム（１０）を受け入れるべく構成される、
    データ交換システム。
14. 前記第１のノード（Ｅ_１）は、さらに、暗号鍵（Ｋ）の関数として前記第１のメッセージ認証コード（ＭＡＣ_１）を計算するべく構成され、
    前記第２のノード（Ｅ_Ｎ）は、さらに、前記暗号鍵（Ｋ）の関数として前記第２のメッセージ認証コード（ＭＡＣ_ＥＸＰ）を計算するべく構成される、
    請求項１３に記載のシステム。
15. さらに、前記第１のノード（Ｅ_１）と関連付けされた第１のインクリメンタル単調カウンタ（４２）と前記第２のノード（Ｅ_Ｎ）と関連付けされた第２のインクリメンタル単調カウンタ（６２）とを包含し、
    前記第１のノード（Ｅ_１）は、さらに、前記第１のインクリメンタル単調カウンタ（４２）から供給される第１のカウント値（ＭＣ）の関数として前記第１のメッセージ認証コード（ＭＡＣ_１）を計算するべく構成され、
    前記第２のノード（Ｅ_Ｎ）は、さらに、前記第２のインクリメンタル単調カウンタ（６２）から供給される第２のカウント値（ＭＣ’）の関数として前記第２のメッセージ認証コード（ＭＡＣ_ＥＸＰ）を計算するべく構成され、
    前記第２のノード（Ｅ_Ｎ）は、さらに、送信されるべき前記第１および第２の情報データが、抽出された前記第１および第２の情報データと同一であり、かつ前記第１のカウント値（ＭＣ）が前記第２のカウント値（ＭＣ’）と同一である場合だけに限って抽出された前記第１のメッセージ認証コード（ＭＡＣ_１、ＭＡＣ_１’）と前記第２のメッセージ認証コード（ＭＡＣ_ＥＸＰ）の間における同一性を確認するべく構成される、
    請求項１３または１４に記載のシステム。
16. 前記第２のノード（Ｅ_Ｎ）は、さらに、
    前記第２の値（ＭＣ’）を受信する時点に先行するか、かつ／またはその後に続く時間フレームの間に前記第２のインクリメンタル単調カウンタ（６２）から供給される１つ以上のさらなるカウント値（ＭＣ’）に関して前記第２のメッセージ認証コード（ＭＡＣ_ＥＸＰ）を計算する動作を反復し、
    それぞれの前記１つ以上のさらなるカウント値（ＭＣ’）の関数として１つ以上のさらなるメッセージ認証コードを計算し、
    抽出された前記第１のメッセージ認証コード（ＭＡＣ_１、ＭＡＣ_１’）と、前記１つ以上のさらなるメッセージ認証コードのそれぞれとを比較し、かつ、
    抽出した前記第１のメッセージ認証コード（ＭＡＣ_１、ＭＡＣ_１’）が前記１つ以上のさらなるメッセージ認証コードのうちの少なくとも１つと同一である場合だけに限り、前記第１および第２のデータ・フレーム（１０）を受け入れるべく構成される、
    請求項１５に記載のシステム。
17. 前記第１および第２のインクリメンタル単調カウンタ（４２、６２）は、互いに同期される、請求項１５または１６に記載のシステム。
18. 前記第１および第２のインクリメンタル単調カウンタ（４２、６２）を互いに同期させるために、前記第１および第２のノードのうちの１つがマスター・ノードとして構成され、前記第１および第２のノードのうちのそのほかがスレーブ・ノードとして構成され、
    前記マスター・ノードは、さらに、前記送信バス（４）へ同期信号を送信するべく構成され、
    前記スレーブ・ノードは、さらに、前記送信バス（４）から前記同期信号を受信し、かつそれの前記第１または前記第２のインクリメンタル単調カウンタ（４２、６２）の値を、受信した前記同期信号の関数として更新するべく構成される、
    請求項１６に記載のシステム。
19. 前記第１および第２のノードは、ピア・トゥ・ピア・タイプのシステムで動作し、前記第１および第２のインクリメンタル単調カウンタ（４２、６２）を互いに同期させるために、前記第１および第２のノードは、
    それぞれ前記第１および第２のカウント値を含むそれぞれの第１および第２の同期信号を前記送信バス（４）へ送信し、
    前記第１および第２の同期信号のうちの他方を前記送信バス（４）から受信し、
    前記第１のノードによって、それの前記第１のインクリメンタル・カウンタを、それの前記第１のカウント値より前記第２のカウント値の方が大きい場合だけに限って、前記第２のカウント値を用いて更新し、
    前記第２のノードによって、それの前記第２のインクリメンタル・カウンタを、それの前記第１のカウント値が前記第２のカウント値より大きい場合だけに限って、前記第１のカウント値を用いて更新するべく構成される、
    請求項１７に記載のシステム。
20. 前記第１のノード（Ｅ_１）は、さらに、ＡＥＳ－ＣＭＡＣ暗号化アルゴリズムを実行することによって前記第１のメッセージ認証コード（ＭＡＣ_１）を計算するべく構成される、請求項１３から１９のいずれかに記載のシステム。
21. 前記プロトコルは、データタイプのフレーム・フォーマットを定義するＣＡＮプロトコルであり、
    前記第１、前記第２、および前記第３のデータ・フレームは、すべて、前記プロトコルによって定義される前記タイプと同一のフレーム・フォーマットを有する、
    請求項１３から２０のいずれかに記載のシステム。
22. 前記送信バス（４）は、乗り物（１）のＣＡＮバスであり、前記第１のノード（Ｅ_１）は、前記乗り物（１）の第１のエンジン・コントロール・ユニット、すなわちＥＣＵであり、前記第２のノード（Ｅ_Ｎ）は、前記乗り物（１）の第２のエンジン・コントロール・ユニット、すなわちＥＣＵである、請求項１３から２１のいずれかに記載のシステム。
23. 前記第１、前記第２、および前記第３のデータ・フレーム（１０、２０）の前記ペイロード・フィールド（１０ｂ、２０ａ）は、前記プロトコルによって定義されるバイト数を伝送するべく構成され、前記第１および第２のメッセージ認証コード（ＭＡＣ_１、ＭＡＣ_ＥＸＰ）は、前記プロトコルによって定義される前記バイト数と等しいバイト数で表現される、請求項１３から２２のいずれかに記載のシステム。
24. 前記第１および第２のカウント値（ＭＣ、ＭＣ’）は、前記プロトコルによって定義される前記バイト数と等しいバイト数で表現される、請求項１５、または請求項１５に従属するときの請求項１６から２３のいずれかに記載のシステム。
25. 請求項１３から２４のいずれかに記載のデータ交換のためのシステムを含む乗り物（１）。
    

Images