▶ インフィネオン テクノロジーズ アクチエンゲゼルシャフトの特許一覧
特表2022-544206自動車通信のためのトランスポート層の真正性およびセキュリティ
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2022-10-17
(54)【発明の名称】自動車通信のためのトランスポート層の真正性およびセキュリティ
(51)【国際特許分類】
H04L 9/32 20060101AFI20221007BHJP
H04L 12/40 20060101ALI20221007BHJP
H04L 12/28 20060101ALI20221007BHJP
B60R 16/023 20060101ALN20221007BHJP
【ＦＩ】
H04L9/32 200A
H04L9/32 200E
H04L12/40 Z
H04L12/28 100A
B60R16/023 P
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2022507881
(86)(22)【出願日】2020-07-28
(85)【翻訳文提出日】2022-04-08
(86)【国際出願番号】 EP2020000136
(87)【国際公開番号】W WO2021028066
(87)【国際公開日】2021-02-18
(31)【優先権主張番号】102019005608.6
(32)【優先日】2019-08-09
(33)【優先権主張国・地域又は機関】DE
(81)【指定国・地域】
(71)【出願人】
【識別番号】599158797
【氏名又は名称】インフィニオン テクノロジーズ アクチエンゲゼルシャフト
【氏名又は名称原語表記】Ｉｎｆｉｎｅｏｎ Ｔｅｃｈｎｏｌｏｇｉｅｓ ＡＧ
【住所又は居所原語表記】Ａｍ Ｃａｍｐｅｏｎ １－１５， ８５５７９ Ｎｅｕｂｉｂｅｒｇ， Ｇｅｒｍａｎｙ
(74)【代理人】
【識別番号】100114890
【弁理士】
【氏名又は名称】アインゼル・フェリックス＝ラインハルト
(74)【代理人】
【識別番号】100098501
【弁理士】
【氏名又は名称】森田 拓
(74)【代理人】
【識別番号】100116403
【弁理士】
【氏名又は名称】前川 純一
(74)【代理人】
【識別番号】100134315
【弁理士】
【氏名又は名称】永島 秀郎
(74)【代理人】
【識別番号】100162880
【弁理士】
【氏名又は名称】上島 類
(72)【発明者】
【氏名】アレクサンダー ツェー
(72)【発明者】
【氏名】ヴィヴァン リチャーズ アリムトゥ エラヴァラス
(72)【発明者】
【氏名】ハラルト ツヴェック
【テーマコード（参考）】
5K032
5K033
【Ｆターム（参考）】
5K032AA08
5K032BA06
5K033AA08
5K033BA06
(57)【要約】
一実施形態によれば、送信機は、車載ネットワークに参加するように構成される。送信機は、ペイロードを伝送するための要求を受信し、これに応答して、トランスポート層および／またはネットワーク層において第１のヘッダを生成するように構成される。送信機は、ｋバイト長の鍵Ｋにアクセスし、鍵Ｋと、追加の認証データとしての少なくとも第１のヘッダとを使用して認証タグを生成するようにさらに構成される。認証タグは、送信機から受信機へ送信されたオリジナルフレームとしてのトランスポート層および／またはネットワーク層上の第１のフレームの真正性を示す役割を果たす。送信機は、第１のヘッダ、トランスポート層ペイロード、および認証タグを含む第１のフレームを生成し、第１のフレームをデータリンク層へ転送するようにさらに構成され、データリンク層は、データリンク層上で第２のフレームを生成し、第２のフレームを車載ネットワークへ送出する。
【特許請求の範囲】
【請求項1】
車載ネットワーク（１）に参加するように構成された送信機（Ｓ）であって、前記送信機（Ｓ）は、－ペイロード（２１）を伝送するための要求を受信することと、
－これに応答して、トランスポート層および／またはネットワーク層において第１のヘッダ（２５１）を生成することと、
－ｋバイト長の鍵Ｋにアクセスすることと、
－前記鍵Ｋと、追加の認証データ（ＡＡＤ）としての少なくとも前記第１のヘッダ（２５１）と、を使用して認証タグ（２３３）を生成することであって、前記認証タグ（２３３）は、前記送信機（Ｓ）から受信機（Ｒ）へ送信されたオリジナルフレームとしての前記トランスポート層および／またはネットワーク層上の第１のフレーム（２５）の真正性を示すことと、
－前記第１のヘッダ（２５１）、トランスポート層ペイロード（２３２）および前記認証タグ（２３３）を含む前記第１のフレーム（２５）を生成することと、
－前記第１のフレーム（２５）をデータリンク層へ転送することであって、前記データリンク層は、前記データリンク層上で第２のフレーム（２７）を生成し、前記第２のフレーム（２７）を前記車載ネットワーク（１）へ送出することと、
を行うように構成されている、
送信機（Ｓ）。
【請求項2】
前記ペイロード（２１）または前記ペイロード（２１）の一部は、追加の認証データ（ＡＡＤ）としても使用される、請求項１記載の送信機（Ｓ）。
【請求項3】
前記送信機（Ｓ）は、－前記鍵（Ｋ）と、
－前記ペイロード（２１）と、
－追加の認証データ（ＡＡＤ）としてのヘッダ（Ｈ）と、
を使用して、前記トランスポート層ペイロード（２３２）のための暗号文（Ｃ；２３２）を生成するようにさらに構成されている、
請求項１または２記載の送信機（Ｓ）。
【請求項4】
前記送信機（Ｓ）は、－ｓｎバイトのシーケンス番号（ＳＮ）を生成することと、
－前記シーケンス番号（ＳＮ）を前記第１のフレーム（２５）に統合することと、
を行うようにさらに構成されている、
請求項１から３までのいずれか１項記載の送信機（Ｓ）。
【請求項5】
前記送信機（Ｓ）は、－長さｓｉのセキュリティ情報（ＳＩ）を受信することと、
－前記鍵Ｋのアクセス中に、前記セキュリティ情報（ＳＩ）に応じて複数の鍵から前記鍵Ｋを選択することと、
を行うように構成されている、
請求項１から４までのいずれか１項記載の送信機（Ｓ）。
【請求項6】
前記送信機（Ｓ）は、－前記セキュリティ情報（ＳＩ）を前記第１のフレーム（２５）に含めるようにさらに構成されている、
請求項５記載の送信機（Ｓ）。
【請求項7】
前記第１のフレーム（２５）は、ＩＳＯ－１５７６５－２に従って生成される、請求項１から６までのいずれか１項記載の送信機（Ｓ）。
【請求項8】
車載ネットワーク（１）に参加するように構成された受信機（Ｒ）であって、前記受信機（Ｒ）は、－データリンク層上で第２のフレーム（２７）を受信することと、
－前記第２のフレーム（２７）から受信ペイロード（２７２）を抽出することと、
－前記受信ペイロード（２７２）を第１のフレーム（２５）としてネットワーク層および／またはトランスポート層へ転送することと、
－前記第１のフレーム（２５）から、前記ネットワーク層および／またはトランスポート層上で、第１のヘッダ（２５１）を抽出することと、
－ｋバイト長の鍵Ｋにアクセスすることと、
－前記鍵Ｋと、追加の認証データ（ＡＡＤ）としての少なくとも前記第１のヘッダ（２５１）と、を使用することによって認証チェックを実行して、送信機（Ｓ）から受信機（Ｒ）へ送信されたオリジナルフレームとしての第１のフレーム（２５）の真正性を示すことと、
を行うように構成されている、
受信機（Ｒ）。
【請求項9】
前記受信機（Ｒ）は、－前記第１のフレーム（２５）からトランスポート層ペイロード（２３２）を抽出するようにさらに構成されている、
請求項８記載の受信機（Ｒ）。
【請求項10】
前記認証チェックは、前記トランスポート層ペイロード（２３２）または前記トランスポート層ペイロード（２３２）の一部をさらに使用する、請求項９記載の受信機（Ｒ）。
【請求項11】
前記受信機（Ｒ）は、－前記鍵Ｋと、
－暗号文としての前記トランスポート層ペイロード（２３２）と、
－追加の認証データ（ＡＡＤ）としての前記第１のヘッダ（２５１）と、
を使用して平文（Ｐ；２１）を生成するようにさらに構成されている、
請求項８から１０までのいずれか１項記載の受信機（Ｒ）。
【請求項12】
前記受信機（Ｒ）は、前記第１のフレーム（２５）からｓｎバイトのシーケンス番号（ＳＮ）を抽出するようにさらに構成されている、
請求項８から１１までのいずれか１項記載の受信機（Ｒ）。
【請求項13】
前記送信機（Ｓ）は、－前記第１のフレーム（２５）からセキュリティ情報（ＳＩ）を抽出することと、
前記鍵Ｋのアクセス中に、前記セキュリティ情報（ＳＩ）に応じて複数の鍵から前記鍵Ｋを選択することと、
を行うように構成されている、
請求項８から１２までのいずれか１項記載の受信機（Ｒ）。
【請求項14】
前記第１のフレーム（２５）は、ＩＳＯ－１５７６５－２に従って抽出される、請求項８から１３までのいずれか１項記載の受信機（Ｒ）。
【請求項15】
車載ネットワーク（１）に参加するための方法であって、前記方法は、－ペイロード（２１）を伝送するための要求を受信するステップと、
－これに応答して、トランスポート層および／またはネットワーク層において第１のヘッダ（２５１）を生成するステップと、
－ｋバイト長の鍵Ｋにアクセスするステップと、
－前記鍵Ｋと、追加の認証データ（ＡＡＤ）としての少なくとも前記第１のヘッダ（２５１）と、を使用して認証タグ（２３３）を生成するステップであって、前記認証タグ（２３３）は、送信機（Ｓ）から受信機（Ｒ）へ送信されたオリジナルフレームとしての前記トランスポート層および／またはネットワーク層上の第１のフレーム（２５）の真正性を示すステップと、
－前記第１のヘッダ（２５１）、トランスポート層ペイロード（２３２）および前記認証タグ（２３３）を含む前記第１のフレーム（２５）を生成するステップと、
－前記第１のフレーム（２５）をデータリンク層へ転送するステップであって、前記データリンク層は、前記データリンク層上で第２のフレーム（２７）を生成し、前記第２のフレーム（２７）を前記車載ネットワーク（１）へ送出するステップと、
を含む方法。
【請求項16】
車載ネットワーク（１）に参加するための方法であって、前記方法は、－データリンク層上で第２のフレーム（２７）を受信するステップと、
－前記第２のフレーム（２７）から受信ペイロード（２７２）を抽出するステップと、
－前記受信ペイロード（２７２）を第１のフレーム（２５）としてネットワーク層および／またはトランスポート層へ転送するステップと、
－前記第１のフレーム（２５）から、前記ネットワーク層および／またはトランスポート層上で、第１のヘッダ（２５１）を抽出するステップと、
－ｋバイト長の鍵Ｋにアクセスするステップと、
－前記鍵Ｋと、追加の認証データ（ＡＡＤ）としての少なくとも前記第１のヘッダ（２５１）と、を使用することによって認証チェックを実行して、送信機（Ｓ）から受信機（Ｒ）へ送信されたオリジナルフレームとしての第１のフレーム（２５）の真正性を示すステップと、
を含む方法。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、車両ネットワークにおけるトランスポート層またはネットワーク層上の認証およびセキュリティに関する。
【背景技術】
【0002】
現在の車両では、データの完全性およびセキュリティが必要不可欠となっている。従来、ステアリングの機能は、ステアリングホイールと車両の車輪とが物理的に接続されることで提供されていた。制動機能および変速機能も同様である。現在の車両では、かかる物理的接続はもはや存在しておらず、電気配線またはバスが電動ステアリングにステアリングコマンドを伝達している。バスを介したステアリングコマンドに応答して、電動ステアリングは、ステアリングホイールの回転に対応する車輪の回転を作動させている。
【0003】
バスへのアクセスにより、悪意のあるバス通信またはコマンドを挿入して、車両の機能を乗っ取ることができるようになる可能性がある。現在の車両のエンタテインメント機能および接続性が向上するにつれて、悪意のあるバスコマンドが挿入されるリスクがさらに高まっている。
【0004】
自律走行する車両および自動車の場合、車両を制御するアクチュエータへのコマンドだけでなく、自動車の周囲を分析するセンサデータもバス通信を介して伝送可能であるため、リスクはさらに高くなる。
【発明の概要】
【課題を解決するための手段】
【0005】
一実施形態によれば、送信機は、車載ネットワークに参加するように構成されている。送信機は、ペイロードを伝送するための要求を受信し、これに応答して、トランスポート層および／またはネットワーク層において第１のヘッダを生成するように構成されている。送信機は、ｋバイト長の鍵Ｋにアクセスし、鍵Ｋと、追加の認証データとしての少なくとも第１のヘッダと、を使用して認証タグを生成するようにさらに構成されている。認証タグは、送信機から受信機へ送信されたオリジナルフレームとしてのトランスポート層および／またはネットワーク層上の第１のフレームの真正性を示す役割を果たす。送信機は、第１のヘッダ、トランスポート層ペイロード、および認証タグを含む第１のフレームを生成し、第１のフレームをデータリンク層へ転送するようにさらに構成されており、データリンク層は、データリンク層上で第２のフレームを生成し、第２のフレームを車載ネットワークへ送出する。第１のフレームに対応する複数の第２のフレームを送出することもできることを理解されたい。
【0006】
実施形態は、添付の図面を参照して本明細書において説明される。
【図面の簡単な説明】
【0007】
【図1a】複数のノードを接続する例示的なバスを示す図である。
【図1b】異なるＩＳＯ－ＯＳＩ層上のバスの参加者としてのノードを示す図である。
【図2】ＣＡＮフレームの生成を示す図である。
【図3】ＣＡＮ規格によるプロトコルフレームを示す図である。
【図4】ＴＰｓｅｃメッセージを複数のＴＰｓｅｃフレームに分散させる動機を与える２つのシナリオを示す図である。
【図5】セキュリティアソシエーションがどのように導出されるかを示す図である。
【図6】セキュリティおよび／または認証が異なる層上でどのように確立されうるかを示す図である。
【図7a】送信機のみにおける認証のためのＳＡＤＳＥの入力変数および出力変数を示す図である。
【図7b】受信機のみにおける認証のためのＳＡＤＳＥの入力変数および出力変数を示す図である。
【図7c】送信機における認証済み暗号化のためのＳＡＤＳＥの入力変数および出力変数を示す図である。
【図7d】受信機における復号および認証のためのＳＡＤＳＥの入力変数および出力変数を示す図である。
【図8】データがフレーム上にどのように分散されうるかの実施形態を示す図である。
【発明を実施するための形態】
【0008】
図１ａは、複数のノードＮｏｄｅ１，Ｎｏｄｅ２，…，Ｎｏｄｅ ｎを接続する例示的なバスを示している。図１ａの例では、バスは２回線バスシステムとして示されており、これは差動回線として好適に実装することができる。無論、他のセットアップも考えられる。バスシステムは、任意選択手段としての終端抵抗器Ｔ１，Ｔ２で終端することができ、これは、バスに沿った信号品質に通常影響を及ぼすバス上の反射を低減するのに役立つ。車両におけるバスシステムの顕著な例は、ＣＡＮ（Controller Area Network）ネットワーク、ＣＡＮ－ＦＤ（CAN-Flexible Data Rate）ネットワーク、ＣＡＮＸＬ（CAN X Large）ネットワークおよびＬＩＮ（Local Interconnect Network）ネットワークである。
【0009】
図１ａに示すバスは、バスの両端がマスタユニット（図示せず）に供給され、これによってバスループを形成するリング型トポロジに配置することもできることが理解されよう。この場合、個々のノードＮｏｄｅ１，Ｎｏｄｅ２，…，Ｎｏｄｅ ｎは、同様の方式でバスに結合されている。
【0010】
（図１ａに示すような）車両ネットワークまたはバスベースの通信システムは、車載ネットワークの要件を反映した特定の属性を有する。車載ネットワークは、センサまたはセンサのコントローラから上位レベルの制御ユニットに伝送されるデータフレームによって、制御ユニットへのセンサデータの通信をサポートする。バスベースの通信ネットワークの個々のノードまたは参加者の間で通信されるデータフレームまたはプロトコルフレームには、有用なプロトコルを使用することができる。
【0011】
センサデータの受信に応じて、またはこれに応答して、センサのコントローラまたは上位レベルの制御ユニットは、バスに結合されたアクチュエータに特定のコマンド、例えばブレーキアクチュエータへの制動コマンドを送信することができる。図１ａの例では、Ｎｏｄｅ１は、ブレーキパドルがどれだけ押し下げられているかの角度を測定する角度センサ（図示せず）を表すことができる。この角度情報は、プロトコルフレームで上位レベルのＥＣＵ（電子制御ユニット）、例えばＮｏｄｅ２に伝送可能である。角度値の受信に応答して、ＥＣＵは、バスを介して、ブレーキアクチュエータであるＮｏｄｅ ｎに１つ以上のフレームを送信することができる。ＥＣＵからブレーキアクチュエータへ送信されたこれらのフレームにより、制動動作が行われる。
【0012】
制動動作に関連するバス通信はタイムクリティカルであり、迅速に伝送する必要があることは明らかであろう。かかるリアルタイム要件は、標準的な通信ネットワークでは一般的ではない。
【0013】
車載通信ネットワークは、通常、明確に定義された数のバス参加者を有しており、このバス参加者は、デフォルトでは、車両の一部のアップグレードを一時的に無視して、車両の寿命が尽きるまで一定のままである。同様に、個々のノード間の既存のリンク、つまりバスベースの通信システムのトポロジは、車両の寿命が尽きるまで変更されない。標準的なコンピュータネットワークでは、かかる状況は極めて発生しにくい。実際には、標準的なコンピュータネットワークには、コンピュータネットワークの運用中にノードの追加または削除を可能にすることが必要とされている。さらに、標準的なコンピュータネットワークでの運用中に、新しいリンクが追加されるか、またはリンクが削除される場合がある。
【0014】
車載ネットワーク（ＩＶＮ）では、バスを介して伝送されるプロトコルフレームの真正性を保証することが重要である。
【0015】
バスベースの通信システムの参加者間で通信されるタイムクリティカルなコマンドの認証における上位プロトコル層の関与を低減するために、トランスポート層またはネットワーク層上のプロトコルフレームの真正性を示すことが重要であることが理解されよう。
【0016】
エンタテインメントシステムの増加ならびに車両間通信の増加に伴い、悪意のあるコマンドまたはプロトコルフレームが挿入されやすくなっている。
【0017】
したがって、悪意のあるプロトコルフレームの挿入を防止するために、プロトコルフレームにデータセキュリティを提供することが重要である。プロトコルフレームの真正性表示に関しては、トランスポート層またはネットワーク層のレベルでデータ機密性を提供することへの関心が高まっている。これにより、セキュリティおよび／または真正性の情報を提供する上位プロトコル層または上位プロトコル層上のソフトウェアスタックの関与が不要になる。データセキュリティおよび真正性の機能は、送信機または受信機などのハードウェア要素によってサポートされうることが当業者には明らかであろう。換言すれば、データセキュリティおよび真正性の機能は、トランスポート層またはネットワーク層のレベルで専用ハードウェアにオフロードされうる。もちろん、データセキュリティは、トランスポート層および／またはネットワーク層上のプロトコルフレームにおいて提供されるだけではない。本発明の範囲を逸脱することなく、上位層または下位層上の追加のセキュリティ対策をさらに提供することができる。
【0018】
図１ｂは、図１ａに示したバスベースの通信システムの参加者としてのＮｏｄｅ１およびＮｏｄｅ２を示している。Ｎｏｄｅ１とＮｏｄｅ２との間の通信は、異なる層を流れており、この異なる層は、確立されたＯＳＩ－ＩＳＯ層モデルに従って分類することができる。最も下位レベルの層はいわゆる物理層であり、Ｎｏｄｅ１およびＮｏｄｅ２に対してＰＨＹＳとして示される。ＯＳＩモデル内の各層は、上位レベルからの命令を受け付け、当該レベルで何らかのアクションを実行し、下位レベルへ要求を転送することによって下位レベルのタスクをトリガすることができる。
【0019】
ＯＳＩ－ＩＳＯモデルにおける最上層は、アプリケーション層７であり、これは、通信の詳細から抽象化されたノードの機能を記述するものである。アプリケーションにより、制動コマンドが開始され、別のノードに送信されることを判定することができる。この通信がどのように実行されるかの詳細は、アプリケーション層の一部ではない。むしろ、コマンドはプレゼンテーション層６へ転送される。
【0020】
図１ｂにおいてそれぞれＮｏｄｅ１，Ｎｏｄｅ２用のＡｐｐ１，Ａｐｐ２として示されたソフトウェアスタックを用いて、ＯＳＩ－ＩＳＯ層モデルの層７にあるアプリケーション層で車両内のデータ通信の真正性を確認するためのコンセプトが知られている。ソフトウェアスタックＡｐｐ＠Ｎｏｄｅ１およびＡｐｐ＠Ｎｏｄｅ２を使用して２者以上の参加者間の認証済み通信および／または保護された通信を示すために、Ｎｏｄｅ１とＮｏｄｅ２との間に仮想チャネルのコンセプトを導入することが好適でありうる。
【0021】
ソフトウェアスタックを用いて車両内の車載ネットワークのセキュリティを実現する例として、ＡＵＴＯＳＡＲ（AUTomotive Open System Architecture）規格に基づくＳＥＣ ＯＣ（SECure OnBoard Communication）がある。Ｎｏｄｅ１およびＮｏｄｅ２に対するソフトウェアスタックＡｐｐを指定して、Ｎｏｄｅ１およびＮｏｄｅ２のハードウェア実装形態における自由度を持たせることは、自動車製造業者にとって好適でありうる。トレードオフとして、ソフトウェアスタックを用いた真正性および／またはデータセキュリティは、バスベースの通信システムに参加している図１ａのＮｏｄｅ ｎのような電子制御ユニット（ＥＣＵ）からのコマンドからアクチュエータの応答までの時間についてのリアルタイム要件を満たさなくなる可能性がある。例えば、図１ａのＮｏｄｅ２として示される制御ユニットＥＣＵから図１ａのブレーキアクチュエータＮｏｄｅ ｎにフレームで送信される制動コマンドを検討する。かかる通信を、ソフトウェアスタックを用いて認証および保護する必要がある場合、個々のＮｏｄｅのすべての層が関与することになり、これでは、タイムクリティカルな制動動作には時間がかかりすぎる可能性がある。
【0022】
ソフトウェアスタックの真正性および／またはデータセキュリティのソリューションのさらなる欠点は、適切に設計されていないソフトウェアスタックに由来することで、真正性および／または機密性の機能性が低下するかまたは損なわれる可能性があることである。
【0023】
物理層ＰＨＹＳとデータリンク層との間の下向き矢印によって示されているように、物理層へのコマンドはデータリンク層から受信されうる。層の機能として、Ｎｏｄｅ１の物理層は、物理層上のデータをＮｏｄｅ２と通信するために、Ｎｏｄｅ２への接続またはリンクを用いることができる。同様に、Ｎｏｄｅ１は、Ｎｏｄｅ１とＮｏｄｅ２との間の物理リンクを介してＮｏｄｅ２からデータを受信し、受信したデータを物理層の上のデータリンク層へさらに転送することができる。図１ｂにおけるＮｏｄｅ１の物理層とデータリンク層との間の上向き矢印は、この転送を示している。Ｎｏｄｅ２におけるプロトコルフローは、Ｎｏｄｅ１について説明したものと同様である。
【0024】
車両における既存のバスベースの通信ネットワークの一部には、ＯＳＩ－ＩＳＯモデルにおいて示唆されるような物理層とデータリンク層との分離に従わないものがある。この特殊性を反映するため、送信機Ｓおよび受信機Ｒは、物理層ＰＨＹＳおよびデータリンク層にわたって延在するように図１ｂに示されている。
【0025】
認証および／または暗号化機能がＯＳＩ－ＩＳＯスタックの下位レベルに統合されている場合、認証の速度が向上し、かつ／またはノード上のソフトウェアへの攻撃に対する脆弱性が低くなるため、通信をより安全にすることができる。
【0026】
したがって、状況に応じて、真正性および／またはデータセキュリティに関する機能を、図１ｂのＮｏｄｅ１またはＮｏｄｅ２などの通信システムへの個々の参加者のトランスポート層および／またはネットワーク層に統合することへの関心が高まっている。これらの機能は下位層であるデータリンク層２にも統合することが可能である。しかしながら、真正性および／またはデータセキュリティ機能のデータリンク層２への統合は、プロトコル層のフレームの長さによって制限されうる。データリンク層上で提供されるフレームは、セキュリティおよび／または認証情報を効率的かつ安全に統合するには短すぎる可能性がある。データリンク層上の各フレームが８ビットのペイロードのみを搬送する場合、認証のためにこのペイロードの大部分を使用することは効率的でない。一例では、古典的なＣＡＮフレームへのペイロードは、最大８バイト長である。真正性のためにこのペイロードの４バイト未満を使用することで、ブルートフォース攻撃における脆弱性が増大する。
【0027】
現代のＣＡＮバスアーキテクチャでは、様々な長さのフレームがバスを介して伝送されうる。特に、最新のＣＡＮ ＦＤおよびＣＡＮＸＬプロトコルは、より長いＣＡＮフレームをサポートしている。効率をほとんど損なうことなく、データリンク層にセキュリティおよび／または認証データを統合することが可能である。しかしながら、より短いＣＡＮフレームがバス上に存在する。第１に、古典的なＣＡＮのみをサポートするより古いデバイスが依然として存在する。さらに、長いフレームがより長い時間バスを占有することは望ましくない。長いメッセージが少なくても、他の参加者のバス通信の妨げになれば、緊急のメッセージを迅速に伝送することができない。そのため、フレームの平均的な長さが制限されることになる。
【0028】
そこで、本発明者らは、トランスポート層および／またはネットワーク層上にセキュリティおよび／または真正性機能を統合することを提案する。
【0029】
真正性が確立されていないフレームは、受信機のトランスポート層またはネットワーク層ですでに破棄されている可能性がある。真正性テストが、プロトコルフレームが特定の送信機から到来しなかったことおよび／または本来の形式で受信機に到着しなかったことを示した場合、そのフレームは、さらなる処理なしに破棄されうる。バスベースの通信システムの１つの参加者を、無効であるかまたは認証されていないフレームでフラッディングすることは、トランスポート層またはネットワーク層上のこの１つのノードにのみ影響を及ぼし、一方で、より上位のプロトコル層は影響を受けないままでありうる。真正性および／またはデータセキュリティに対するソフトウェアスタックベースのアプローチでは、かかる真正性および／またはデータセキュリティの制限は不可能であった。
【0030】
さらに、専用のハードウェア要素を使用することが好適である。すなわち、トランスポート層上および／またはネットワーク層上の送信機、および／またはトランスポート層上および／またはネットワーク層上の受信機は、真正性および／またはデータセキュリティを専用ハードウェアとして実装することができる。これは、バスの参加者または参加者におけるソフトウェアアプリケーションＡｐｐが時間とともに変化しても、追加の適応を必要とせずに、かかるビルディングブロックを標準回路として使用できるというさらなる利点を有する。
【0031】
図２をここで参照すると、ＣＡＮフレームの生成が示されている。ＩＳＯ－ＯＳＩ層７上のアプリケーションであるクライアント２０は、ＴＰデータ２１をＴＰｓｅｃエンジン２２に渡す。ＴＰデータ２１は、ビットのシーケンスを含むことができ、これは、コード化された特定のコマンドでありうる。ＴＰｓｅｃエンジン２２は、ＴＰｓｅｃメッセージ２３を生成し、ＴＰｓｅｃメッセージ２３は、ＴＰｓｅｃタグ２３１、ペイロードＴＰデータ２３２、および認証タグ２３３を含む。
【0032】
ＴＰｓｅｃタグ２３１は、シーケンス番号、セキュアチャネルＩＤおよび暗号情報を含みうる。暗号情報は、例えば、どの暗号スイートが使用されるか、またはどのモードが使用されるかを定義する。
【0033】
ペイロードＴＰデータ２３２は、例えばＡＥＳ（Advanced Encryption Standard）を用いてＴＰデータ２１を符号化することにより生成される。
【0034】
認証タグ２３３は、ＣＡＮ ＴＰフレーム２５が送信機Ｓから受信機Ｒに伝送されることが意図されたという認証表示を表すことができる。認証タグ２３３は、幾つかの実施形態では、伝送されたフレームが受信機に向かう途中で変更されたか否かをチェックすることをさらに可能にする。ＣＡＮ ＴＰフレーム２５は、第１のフレームとも称される。
【0035】
セキュリティタグ認証タグ２３３は、ペイロードＴＰデータ２３２の下流に示されているが、ペイロードＴＰデータ２３２の上流に配置されていてもよく、または標準ヘッダＨに統合されていてもよい。
【0036】
秘密鍵Ｋが認証、暗号化および復号に必要とされることが理解されよう。鍵のデプロイメントは、複数の理由から本開示の中心にはない。
【0037】
第１に、自動車環境では、バスベースの通信システムの参加者の数は限られており、車両の耐用期間が尽きるまでほとんど変化しない。バス通信システム上のすべての参加者に対して、長さｋの１つの鍵Ｋを使用することが好適でありうる。
【0038】
バス通信システムを介して通信可能に結合された個々のノードが個々の鍵Ｋを使用すべき場合、この個々の鍵は、車両の製造中にバスベースの通信システムのそれぞれのノードに格納されうる。Ｎｏｄｅ１およびＮｏｄｅ２に格納されたＮｏｄｅ１とＮｏｄｅ２との間の通信のための第１の鍵Ｋ１、ならびにＮｏｄｅ１およびＮｏｄｅ３に格納されたＮｏｄｅ１とＮｏｄｅ３との間の通信のための第２の鍵Ｋ２などが存在しうる。送信機Ｓおよび受信機Ｒは同じ鍵Ｋを使用するため、復号、暗号化、認証、および検証は対称であると仮定する。
【0039】
システム内で２つ以上の鍵Ｋが使用される場合、認証および／またはデータセキュリティに関与する鍵Ｋに関する情報を格納することが重要となりうるが、これは、任意選択手段としてのセキュリティ情報フィールドＳｅｃＩｎｆ（ここでは図示せず）に格納可能または表示可能である。なお、本プロトコルフレーム１００が認証済みのみのプロトコルフレームであるかまたは認証済みかつ暗号化済みのプロトコルフレーム１００であるかについて、セキュリティ情報フィールドを用いて示すことは、別のオプションである。
【0040】
フィールドＴＰｓｅｃタグ２３１は、さらなる任意選択手段としての要素である。これには、シーケンス番号７２が含まれてもよく、このシーケンス番号７２は、一度だけ使用される整数であり、ノンスとも称される。シーケンス番号７２がリスニングパーティに知られていない手法で変更された場合、リプレイ攻撃の成功を防止するのに役立つ。
【0041】
データリンク層上での認証および／またはデータセキュリティの最も簡単な実装形態として、リプレイ保護が必要とされる場合、ＴＰｓｅｃタグ２３１内のシーケンス番号を含むフレームを用いて、認証専用スキームを実装することができる。かかる保護が必要とされない場合、ＴＰｓｅｃタグ２３１を省略して、より大きなペイロードＴＰデータ２３２を可能にすることができる。
【0042】
ＴＰｓｅｃメッセージ２３は、ＣＡＮ ＴＰユニット２４に渡され、１つのＣＡＮ ＴＰフレーム２５または複数のＣＡＮ ＴＰフレーム２５．１，…，２５．ｎを生成する。ここで、ｎは１より大きい整数である。ＣＡＮ ＴＰフレームの生成は、ＩＳＯ－ＴＰとも称される規格ＩＳＯ１５７６５－２に従って行うことができる。プロトコルは、古典的なＣＡＮフレームの８バイト最大ペイロードを超えるメッセージのトランスポートを可能にする。ＩＳＯ－ＴＰは、１つ以上のメタデータバイトの後に８バイトの古典的ＣＡＮフレーム内のペイロードデータを追加し、ペイロードをフレーム当たり７バイト以下に低減することができる。ＩＳＯ－ＴＰは、より長いメッセージを複数のフレームにセグメント化し、メタデータを追加する。このメタデータは、受信機による個々のフレームの解釈および完全なメッセージパケットへの再組み立てを可能にする。これにより、メッセージパケット当たり２３２バイトまでのペイロードを搬送することができる。メタデータは、プロトコル制御情報またはＰＣＩと称される。ＰＣＩは１バイト、２バイトまたは３バイトである。初期フィールドは４ビット長で、フレームタイプを示し、ＰＣＩの長さを暗黙的に記述する。
【0043】
ＣＡＮ ＴＰフレーム２５は、ＴＰペイロード２５２を含み、ＴＰペイロード２５２は、ＣＡＮ ＴＰヘッダ２５１、ＴＰｓｅｃタグ２３１、ペイロードＴＰデータ２３２、および認証タグ２３３を含む。ＣＡＮ ＴＰヘッダ２５１は、プロトコル制御情報ＰＣＩを含む。
【0044】
ＴＰｓｅｃメッセージ２３が長すぎて１つのＣＡＮフレームでＣＡＮバスを介して転送できない場合、複数のＣＡＮ ＴＰフレーム２５．１～２５．ｎが生成される。ここでｎは１より大きい整数である。複数のＣＡＮ ＴＰフレームの各々は、ＣＡＮ ＴＰヘッダ２５１を有する。フレームの各々は、ＴＰｓｅｃタグ２３１、ペイロードＴＰデータ２３２および認証タグ２３３の全体のうちの一部を搬送する。図２の例では、第１のＣＡＮ ＴＰフレーム２５．１は、ＴＰｓｅｃタグ２３１およびペイロードＴＰデータ２３２の第１の部分を搬送する。第２のＣＡＮ ＴＰフレーム２５．２は、ペイロードＴＰデータ２３２の第２の部分を搬送する。最後のＣＡＮ ＴＰフレーム２５．ｎは、ペイロードＴＰデータ２３２の最後の部分および認証タグ２３３を搬送する。
【0045】
ＣＡＮ転送ブロック２６は、第２のフレームとも称されうるＣＡＮフレーム２７を生成する。ＣＡＮフレーム２７は、ヘッダ２７１と、ＴＰペイロード２５２を搬送するペイロード２７２と、エンドオブフレーム部分ＥＯＦと、を含む。図３は、ＣＡＮ規格によるプロトコルフレームを示している。ＣＡＮフレームは、１１ビットのアービトレーションフィールドを有するヘッダＨで始まり、７ビットの制御フィールドが続く。アービトレーションフィールドおよび制御フィールドの両方は、全バイト長に比例しないビット長のＣＡＮフレームの部分である。アービトレーションフィールドは、前述のＣＡＮ規格のバリアントであるＣＡＮおよびＣＡＮ－ＦＤ規格に従って２９ビットで構成されうることに留意されたい。
【0046】
８バイトのデータフィールドは、オリジナルプロトコルフレームのペイロードＰに対応する。１５ビットのＣＲＣフィールドとアクノレッジスロットビット、アクノレッジデリミタビット、および７ビットのエンドオブフレームがプロトコルフレームのエンドオブフレーム部分ＥＯＦに相当する。
【0047】
車両環境では、異なるプロトコルバリアントに従って古いデバイスと最近のデバイスとが同時に動作する可能性が高い。一例として、非常に古いデバイス、例えばＡＢＳセンサは、プロトコルの初期の変形形態、例えば古典的なＣＡＮプロトコルに従って通信しうるが、一方、ＬＩＤＡＲシステムなどのより最近のデバイスは、ＣＡＮ－ＦＤ規格を用いて、またはＣＡＮＸＬ規格を用いて電子制御ユニットと通信することができる。したがって、ヘッダＨ内で異なるプロトコルタイプを示すことは、個々のプロトコルフレーム１００に適用される真正性および／またはデータ保護のレベルにも影響を及ぼすので、有用でありうる。かかる状況の下では、Ｎバイトまたはビットの全フレーム長をプロトコルフレーム内のどこかに格納またはコード化することが重要でありうる。フレーム長フラグを設定することは、フレーム長をコード化する手法の１つのオプションである。かかる情報がプロトコルフレームにどのように格納されうるかは、プロトコル仕様から取得されうる。
【0048】
エンドオブフレーム表示ｅｏｆは、当該技術分野で知られているように、エラーチェック情報をさらに含んでいてもよく、したがって、この点についてはこれ以上説明しない。
【0049】
ここで図２に戻ると、ＣＡＮフレームのペイロード２７２は、ＣＡＮ ＴＰフレーム２５から、またはＣＡＮ ＴＰフレーム２５．１～２５．ｎのうちの１つから取り出される。ペイロード２７２はＴＰペイロードと称される。複数のＣＡＮ ＴＰフレームの場合、ＣＡＮ ＴＰフレーム２７．１～２７．ｎの各々は、ペイロード２７２．１，２７２．２または２７２．ｎとして、ＣＡＮ ＴＰフレーム２５．１，２５．２，…，２５．ｎのうちの１つを搬送する。
【0050】
ＣＡＮフレームのビットは、配線への電圧レベル信号２９としてＣＡＮバス上に出力される。ＣＡＮバスは、例えば、ＣＡＮ＿ＨＩＧＨおよびＣＡＮ＿ＬＯＷと名付けられた２本の銅配線を含んでもよい。ＩＳＯ１１８９８－２は、高速ＣＡＮ（ＣＡＮ上で１Ｍｂ／ｓ、ＣＡＮ－ＦＤ上で５Ｍｂ／ｓまでのビット速度）とも称され、各端部に１２０Ω抵抗器で終端された線形バスが用いられている。
【0051】
高速ＣＡＮシグナリングは、ドミナント（０）を伝送する場合、ＣＡＮハイ配線を５Ｖに向けて駆動し、ＣＡＮロー配線を０Ｖに向けて駆動し、リセッシブ（１）を伝送する場合、いずれの配線も駆動しない。ドミナントとして「０」を指定することで、バス上でより低いＩＤ番号を有するノードに優先権を与える。ドミナントの差動電圧は公称２Ｖである。終端抵抗器は、２つの配線を０Ｖの公称差動電圧に受動的に戻す。ドミナントコモンモード電圧は、コモンの１．５～３．５Ｖ以内でなければならず、リセッシブコモンモード電圧は、コモンの＋／－１２以内でなければならない。破線はＣＡＮハイ配線における電圧を示しており、実線はＣＡＮロー配線における電圧を示している。
【0052】
参加者が受信機である場合、情報の流れは、図２の下部から上部へと反対方向に進む。受信機は、信号２９を受信し、信号２９をデジタル値に変換し、データリンク層上のデジタル値からＣＡＮフレーム２７、ＣＡＮフレーム２７．１，…，２７．ｎをそれぞれ抽出する。ＣＡＮフレーム２７，２７．１，…，２７．ｎは、上位層、ネットワーク層およびトランスポート層へ転送され、これによって、ＣＡＮフレーム２７をＴＰフレーム２７に変換する。ＴＰフレーム２７からは、ＣＡＮ ＴＰヘッダ２５１、ＴＰｓｅｃタグ２３１、ペイロードＴＰデータおよび認証タグ２３３が抽出される。抽出されたデータは認証ユニットに送られ、認証ユニットは認証をチェックする。ペイロードＴＰデータが暗号化済みデータである場合、これらは復号される。
【0053】
図４は、ＴＰｓｅｃメッセージを複数のＴＰｓｅｃフレームに分散させる動機付けとなる２つのシナリオを示している。ＴＰｓｅｃメッセージの分割が有用な、より多くのシナリオが存在しうることを理解されたい。第１のシナリオでは、ＴＰｓｅｃメッセージ２３のデータ長は、特定のＣＡＮプロトコルのＣＡＮフレームのそれぞれのペイロードの最大長よりも大きく、これは例えば古典的なＣＡＮ、ＣＡＮ ＦＤまたはＣＡＮＸＬであってよい。この場合、ＴＰｓｅｃメッセージのデータは複数のＣＡＮ ＴＰフレーム２５．ｘに分割され、基礎となる各ＣＡＮフレームをその最大長まで埋められるようにする。
【0054】
第２のシナリオでは、ＴＰｓｅｃメッセージ２３のデータ長は、特定のＣＡＮプロトコルのＣＡＮフレームのそれぞれのペイロードの最大長よりも小さい。しかしながら、車内では、他の参加者がより小さいＣＡＮフレーム間でメッセージを送信できるようにするために、ＣＡＮバス上でデータの小さいチャンクのみを送信することが望ましい。この場合、ＣＡＮフレームの各々がＣＡＮ ＴＰメッセージのデータの一部を搬送するように、ＣＡＮ ＴＰメッセージも分割される。各ＣＡＮフレームは、特定のＣＡＮプロトコルによって許容される最大フレーム長よりも小さい。
【0055】
図５は、セキュリティアソシエーションがどのように導出されるかを示している。図５は、ＣＡＮ ＴＰｓｅｃメッセージ２３、ＣＡＮ ＴＰフレーム２５、およびＣＡＮフレーム２７を示している。前述のように、ＣＡＮ ＴＰｓｅｃメッセージは、ＴＰｓｅｃタグ２３１、ペイロードＴＰデータ２３２、および認証タグ２３３を含む。ＣＡＮ ＴＰフレーム２５は、ＣＡＮ ＴＰヘッダ２５１と、ＣＡＮ ＴＰｓｅｃメッセージを含むＣＡＮ ＴＰデータと、を含む。セキュリティアソシエーションは、少なくとも２つのＴＰクライアント間で確立され、ＣＡＮヘッダの一部としてのＣＡＮ ＩＤとＴＰｓｅｃタグ２３１との連結によって生成される。
【0056】
図６は、セキュリティおよび／または認証が異なる層上でどのように確立されうるかを示している。図６には、トランスポート層における４つのＴＰクライアントと、データリンク層における２つのＣＡＮ参加者とが示されている。２つのＣＡＮ参加者は、安全なＣＡＮチャネルを介して接続される。かかる安全なＣＡＮチャネルの例は、２０１９年７月１１日に出願された同時係属中の独国特許出願第１０２０１９００４７９０．７号明細書に開示されている。
【0057】
ＴＰクライアント１およびＴＰクライアント２は、トランスポート層およびデータリンク層上のユニット間でメッセージおよびフレームを転送および受信することができるように、同じノード内にあるものとしてＣＡＮ参加者Ａに接続される。したがって、ＴＰクライアント３および４は、ＣＡＮ参加者Ｂとともに別のノードに属する。ＴＰクライアント３およびＴＰクライアント４はそれぞれ、ＣＡＮ参加者Ｂとの間でフレームおよびメッセージを転送および受信することができる。
【0058】
第１のオプションとして、セキュリティアソシエーションを２つのＴＰクライアント間で確立することができる。この例では、セキュリティアソシエーションがＴＰクライアント２と３との間に存在し、別のセキュリティアソシエーションがＴＰクライアント１と４との間に存在している。バイトの最大長は２３２であり、オーバヘッドはＴＰフレームごとに生成される。
【0059】
第２のオプションとして、セキュリティアソシエーションは、ＣＡＮノード間のデータリンク層上で確立することができる。ここで、最大長は、ＣＡＮ規格に依存して、６バイト、６４バイトおよび２０４８バイトである。オーバヘッドは、各ＣＡＮフレームに対して費やされなければならない。さらに、トランスポート層およびデータリンク層の両方を確立しないことで、両方のセキュリティアソシエーションを組み合わせることが可能である。
【0060】
【0061】
プロトコルフレームの真正性および／またはデータセキュリティ保護を実装する１つの好適な手法は、図７ａ～図７ｄを参照してより詳細に説明するように、ハードウェアブロックとして実装される対称認証および／またはデータセキュリティエンジン（Symmetric Authentication and/or Data Security Engine）と称されうるものを使用することであり、これは、ＳＡＤＳＥとも称される。
【0062】
図７ａは、ＳＡＤＳＥの入力値および出力値を示している。ＳＡＤＳＥの入力変数および出力変数の命名は、暗号技術文献においてブロック暗号モードに対して確立された命名規則に従う。ＳＡＤＳＥは、真正性専用（Authenticity Only）モードＡＯまたは認証済み暗号化（Authenticated Encryption）モードＡＥで動作しうることが理解されるであろう。図７ａは、ＡＥモードを示している。ＳＡＤＳＥは、秘密鍵Ｋ、ノンスＮ、ｌｅ文字長の入力ストリームＰ、および追加の認証データＡＡＤを入力として受け付ける。出力は、ｌｅ文字長の出力ストリーム暗号文ＣおよびタグＴである。
【0063】
鍵Ｋは、ある長さ、例えば１２８ビット、１９２ビットまたは２５６ビットの対称鍵であることが好適である。前述したように、鍵の配布は本開示の焦点とはなっていない。実際には、ＩＥＥＥ８０２．１Ｘ－２０１０において定義されているＭＡＣｓｅｃ Ｋｅｙ Ａｇｒｅｅｍｅｎｔなどの対応する方式が知られている。幾つかの実施形態では、複数の鍵を使用することができ、セキュリティ情報データフィールド７２は、複数の鍵のうちのどれが使用されるかを選択する。
【0064】
ノンスＮは、通常、一度だけ使用される整数値である。状況に応じて、ＳＡＤＳＥの出力の２つ以上の生成についてＮについて同一の値を有することを判定してもよい。リプレイ保護が必要とされず、汎用鍵Ｋがバスベースの通信システムにおいて使用される状況では、シーケンス番号７２およびセキュリティ情報ＳｅｃＩｎｆフィールドは省略されてもよい。
【0065】
追加の認証データは、ＣＡＮ ＴＰヘッダを含み、一部のＴＰデータ２１または完全なＴＰデータ２１をさらに含んでもよい。
【0066】
入力ストリームＰは、ＴＰデータ２１によって供給される。平文ストリームＰは、鍵を使用して暗号化される。暗号化の結果は暗号Ｃとして出力される。
【0067】
タグＴは、ＳＡＤＳＥの使用された入力に基づいて計算される。タグＴは、プロトコルフレーム１００が指定された送信機Ｓから所与の受信機Ｒへ送信されることが意図されたか否かを示している（両方とも通常ヘッダＨで言及される）。
【0068】
シリアル番号７１は、トランスポート対象のＴＰデータ２１の固有番号を示している。ＴＰデータ２１自体は、平文としてＳＡＤＳＥに入力される。ＣＡＮ ＴＰヘッダ２５１は、ＳＡＤＳＥの入力された追加の認証データＡＡＤを供給する。暗号出力ＣはペイロードＴＰデータ２３２として使用され、タグＴは認証タグ２３３として使用される。したがって、ＴＰデータ２１はバスを介して暗号化された形式で伝送される。シリアル番号７１およびセキュリティ情報７２がＴＰｓｅｃタグ２３１に書き込まれる。
【0069】
ここで図７ｂを参照して、ＳＡＤＳＥが、ＣＡＮ ＴＰフレームを認証するために送信機Ｓにおいて認証専用モードＡＯにある場合を検討する。このモードでは、入力ストリームＰは使用されない。鍵Ｋの使用は前述と同様である。ＳＡＤＳＥはさらに、シーケンス番号７２および追加の認証データＡＡＤを入力として受信する。
【0070】
追加の認証データは、ＣＡＮ ＴＰヘッダ２５１を含み、一部のＴＰデータ２１または完全なＴＰデータ２１をさらに含んでもよい（図７に図示せず）。リプレイ保護が必要とされない場合、プロトコルフレーム１００は、図２ｂと組み合わせて上述したように、シーケンス番号７２を含まなくてもよい。シリアル番号７２が設定されていないため、ノンスＮは、過去に使用された値のままであってもよいし、または０もしくは任意の他の好適な値に設定されてもよい。ノンスＮは、使用される場合、送信機および受信機で同一でなければならない。
【0071】
バスベースの通信システム内で秘密鍵として１つの汎用鍵Ｋのみが使用される場合、ＣＡＮ ＴＰフレーム２５はセキュリティ情報ＳｅｃＩｎｆフィールドを含まなくてもよい。
【0072】
リプレイ保護が必要とされず、汎用鍵Ｋがバスベースの通信システムにおいて使用される状況では、シーケンス番号７２およびセキュリティ情報ＳｅｃＩｎｆ７２フィールドは省略されてもよい。上記で説明したように、ノンスＮは、過去に使用された値のままであってもよく、０に設定されてもよく、または任意の他の好適な値であってもよい。図７ｂでは、シリアル番号７１もＳｅｃ Ｉｎｆ７２も使用されないオプションが示されている。ＴＰｓｅｃタグ２３１は使用されないか、または例えばゼロで埋められる。
【0073】
ＳＡＤＳＥは、鍵Ｋ、ノンスＮ、および追加の認証データＡＡＤを計算ベースとして使用して計算されたタグＴを出力する。タグＴは、ＣＡＮ ＴＰフレームの認証タグ２３３で使用される。
【0074】
ここで、図７ｃを参照して、受信機においてＳＡＤＳＥが認証専用モードにある場合を検討する。受信機は、ＣＡＮフレーム２７．１，２７．２，２７．３を受信し、これらからＣＡＮ ＴＰフレームを生成する。図７ｃは、ＣＡＮ ＴＰフレーム２５．１の内容を用いて、認証を生成する様子を示している。ＳＡＤＳＥは、シリアル番号であったノンスをＴＰｓｅｃタグ２３１から受信する。ＴＰｓｅｃタグ２３１がセキュリティ情報データを含む場合、これらのデータを使用して、複数の鍵のうちの鍵Ｋが選択される。１つの鍵のみが使用される場合、セキュリティ情報データは受信機で使用されない。伝送された認証タグ２３３はＳＡＤＳＥのタグ入力Ｔに供給されるが、ＣＡＮ ＴＰヘッダは追加の認証データ入力に入力される。ＳＡＤＳＥは、鍵ＫおよびノンスＮに基づいてタグＴ’を計算する。ＳＡＤＳＥの出力認証識別ＡＩは、計算されたＴ’が入力タグＴに等しいか否かを示す。等しい場合、ＣＡＮ ＴＰフレーム２７．１は真正であるとみなされる。図７ｃには示されていない代替例では、計算されたタグＴ’が出力される。
【0075】
受信機における認証専用モードは、受信機Ｒにおいて受信されたＣＡＮ ＴＰフレームを、送信機Ｓから受信機へ送信されることが意図されたオリジナルプロトコルフレームであると認証する。換言すれば、受信機は、図２に従ってＣＡＮ ＴＰフレームを認証する。
【0076】
受信機における認証専用モードＡＯでは、追加の認証データＡＡＤは、ＣＡＮ ＴＰヘッダ２５１で始まるＣＡＮ ＴＰフレーム２５のすべての情報と、任意選択手段として一部のペイロードＴＰデータ２３２または完全なペイロードＴＰデータ２３２と、を含む。リプレイ保護が必要とされない場合、プロトコルフレーム１００は、図７ｂと組み合わせて上述したように、シーケンス番号７１を含まなくてもよい。７１が設定されていないため、ノンスＮは、過去に使用された値のままであってもよく、または０もしくは任意の他の好適な値に設定されてもよい。
【0077】
受信機において、ＣＡＮ ＴＰフレーム２７．１内の受信セキュリティタグＴと新たに計算されたタグＴ’とを比較することにより、受信したＣＡＮ ＴＰフレーム２７．１が送信機から受信機への伝送を意図したものであるか否かを認証することができる。ペイロードＴＰデータ２３２が、送信機でタグＴを計算し、受信機でタグＴ’を計算するためにも使用された場合、認証識別ＡＩは、プロトコルフレーム１００が本来の形式であるか否かを示す。
【0078】
ＳＡＤＳＥにとっては、新たに計算されたタグＴ’をプロトコルフレーム１００内のセキュリティタグＳｅｃＴａｇと比較した結果に対応する真正性表示ＡＩを直接に出力することが好適でありうる。セキュリティタグＳｅｃＴａｇがＳＡＤＳＥに入力されると、この比較のためのすべての情報がＳＡＤＳＥに利用可能となる。
【0079】
ここで、ＡＥモードとも称されるＳＡＤＳＥの認証済み暗号化モードを検討する。
【0080】
ここで図７ｄを参照して、受信機におけるＳＡＤＳＥのためのＡＥモードが説明される。ＳＡＤＳＥは、鍵Ｋ、ノンスＮ、暗号文Ｃ、タグＴ、および追加の認証データＡＡＤを受信する。鍵Ｋ、ノンスＮ、タグＴおよび追加の認証データＡＡＤの入力は、図７ｃの実施形態によるＳＡＤＳＥに供給される。さらに、暗号Ｃの入力は、送信機のＳＡＤＳＥにおけるＴＰデータ２１の暗号化から得られる受信ペイロードＴＰデータ２３１から得られる。
【0081】
受信機ＲにおけるＡＥモードでは、ＳＡＤＳＥは出力として平文Ｐを出力する。ＳＡＤＳＥは、暗号ＣＣおよび鍵Ｋに基づいて暗号Ｃの復号バージョンを生成する。
【0082】
受信機ＲにおけるＡＥモードでは、ＳＡＤＳＥは、鍵Ｋ、ノンスＮとしての任意選択手段としてのシーケンス番号、および追加の認証データＡＡＤを使用して計算されたタグＴ’を出力することができる。タグＴ’は、送信機Ｓで生成されたセキュリティタグＳｅｃＴａｇの再計算である。本実施形態では、ＳＡＤＳＥは、受信したタグＴと受信機で算出されたタグＴ’との比較結果を示す比較値をＡＩとして出力する。ＳＡＤＳＥにとっては、新たに計算されたタグＴ’をＣＡＮ ＴＰフレーム２７内のセキュリティタグＳｅｃＴａｇと比較した結果を示す真正性表示ＡＩを直接に出力することが好適でありうる。認証表示は、例えば、「検証済み」または「未検証」でありうる。
【0083】
本開示によるＳＡＤＳＥを実施する１つの可能な手法は、ブロック暗号モードである。かかるブロック暗号モードの顕著な例は、ＡＥＳ－ＧＣＭ（Galois-Counter Mode）である。
【0084】
ＡＥＳ－ＧＣＭについては、ＡＥＳ－ＧＣＭの入力値および出力値のそれぞれのビット長について、米国の国立標準技術研究所であるＮＩＳＴによる勧告が存在する。これらのパラメータは、認証専用モードＡＯについて表１に要約されており、すなわち
である。
【表1】
【0085】
認証専用モードＡＯの場合、ｌｅ文字の平文ストリームは使用されず、また、保護されたペイロードＰＰ上の対応する暗号文は平文ストリームとして使用され、これは、図７ｂおよび図７ｃに関するＳＡＤＳＥのＡＯモードの説明に対応している。
【0086】
追加の認証データＡＡＤに関して、１２８＊ａビット長は、１２８ビットの整数倍ａが、本開示のＳＡＤＳＥを実装するＡＥＳ－ＧＣＭモードのパフォーマンスを最適化するために選択されるべきであることを示している。１２８ビットの倍数に到達することは、ゼロパディングによって好適に達成されうる。カウンタＣＴＲはＡＥＳ－ＧＣＭの内部変数であり、ＡＯモードでは使用されないように、完全を期すために再現されている。
【0087】
表２は、ＳＡＤＳＥを実装するＡＥＳ－ＧＣＭの入力および出力パラメータに対するそれぞれのビット長を要約している。すなわち、
である。
【表2】
【0088】
表１の認証専用モードＡＯのパラメータとは異なり、認証済み暗号化モードＡＥは、３２ビット値として実装されるカウンタを利用する。
【0089】
暗号文Ｃおよび追加の認証データＡＡＤは、ＳＡＤＳＥを実装するＡＥＳ－ＧＣＭの最適なパフォーマンスのために、１２８ビット長の倍数であるべきである。かかるビット長を達成するために、ゼロパディングは好適なオプションである。
【0090】
図８は、ＣＡＮフレーム２７を形成するためにＣＡＮ ＴＰフレーム２５がどのようにデータリンク層へ転送されうるかの例を示している。ＣＡＮ ＴＰフレーム２５は、２～６バイトのＣＡＮ ＴＰヘッダ２５１と、ＴＰｓｅｃタグ２３１、２０１１～２０１６バイトのペイロードＴＰデータ２３２、および１６バイトの認証タグ２３３で構成されるペイロードと、を含む。ＴＰｓｅｃタグ２３１は、１２バイトのシリアル番号および２～３バイトのセキュリティ情報から構成される。ペイロードＴＰデータは、複数のペイロード部分Ｐ１，Ｐ２，…，Ｐｎから構成される。
【0091】
バージョン１であるｖ１では、ＣＡＮＸＬフレーム２７は、ＣＡＮヘッダ２７１と、上記フレーム２５のコピーであるペイロード２７２と、エンドオブファイル部分２７３と、を含むデータリンク層上に生成されている。ここで、ＴＰフレーム２５のコンテンツは、１フレームで伝送される。バージョン２であるｖ２では、ＴＰフレーム２５のコンテンツは、複数のＣＡＮＸＬフレーム２７．１，２７．２，…，２７．ｎに分散されている。これらのフレーム２７．１，２７．２，…，２７．ｎの各々は、ヘッダ２７１と、５１２バイトのペイロードと、エンドオブファイル２７３と、を含む。フレーム２７．１はペイロードとしてＳｅｃＴａｇ２３１およびペイロード部分Ｐ１を含み、フレーム２７．２はペイロードＰ２およびフレーム２７．ｎとしてペイロード部分Ｐｎおよび認証タグ２３３を含む。
【0092】
最初にフレーム２７．１が送信され、次に別の送信機からフレーム８０が送信され、次にフレーム２７．２が送信され、その後に別の送信機からフレーム８１が送信される。最後に、フレーム２７．ｎがネットワークを介して送信される。小さいフレーム２７．１～２７．ｎにより、他の送信機からの小さいフレーム８０および８１が適時に伝送されうる。フレーム８０は８バイトのペイロードを搬送し、フレーム８１は６４バイトのペイロードを搬送する。
【0093】
上述した例示的な実施形態は、単なる例示である。本明細書に記載された配置および詳細の修正および変形は、当業者に明らかであることが理解される。したがって、本明細書における実施形態の記述および説明として提示される特定の詳細によっては限定されず、添付の特許請求の範囲によってのみ限定されることが意図される。実施形態は、ＣＡＮ規格の助けを借りて説明したが、他のプロトコルも同様に使用可能である。
【符号の説明】
【0094】
１ 車載ネットワーク
２０ クライアント
２１ ＴＰデータメッセージ
２２ ＴＰｓｅｃエンジン
２３ ＴＰｓｅｃメッセージ
２４ ＣＡＮ ＴＰユニット
２５，２５．１，…，２５．ｎ ＣＡＮ ＴＰフレーム（第１のフレーム）
２６ ＣＡＮ転送ブロック
２７ ＣＡＮフレーム（第２のフレーム）
２９ 電圧レベル信号
２３１ ＴＰｓｅｃタグ
２３２ ペイロードＴＰデータ
２３３ 認証タグ
２５１ ＣＡＮ ＴＰヘッダ（第１のヘッダ）
２７１ ヘッダ（第２のヘッダ）
２７２ ＴＰペイロード
２７３ エンドオブファイル
２０ クライアント
２１ ＴＰデータメッセージ
２２ ＴＰｓｅｃエンジン
２３ ＴＰｓｅｃメッセージ
２４ ＣＡＮ ＴＰユニット
２５，２５．１，…，２５．ｎ ＣＡＮ ＴＰフレーム（第１のフレーム）
２６ ＣＡＮ転送ブロック
２７ ＣＡＮフレーム（第２のフレーム）
２９ 電圧レベル信号
２３１ ＴＰｓｅｃタグ
２３２ ペイロードＴＰデータ
２３３ 認証タグ
２５１ ＣＡＮ ＴＰヘッダ（第１のヘッダ）
２７１ ヘッダ（第２のヘッダ）
２７２ ＴＰペイロード
２７３ エンドオブファイル
【図1a】
【図1b】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7a】
【図7b】
【図7c】
【図7d】
【図8】
【国際調査報告】