JP6447974B2 - 送信方法 - Google Patents

Description

本発明は、バスで接続された通信システムにおける送信方法に関する。

車載ネットワークとしてＣＡＮ（Controller Area Network）が普及している。ＣＡＮはバス型ネットワークを採用したシリアル通信プロトコルである。バスに接続される各ノードからのメッセージは、バスに接続される全てのノードにブロードキャストされる。当該メッセージには送信元ノード及び宛先ノードの識別情報が含まれない。従って受信ノードにおいて、正しい通信相手から来たメッセージであるか否かを単純に判断することはできない。

メッセージの完全性を保証したり、ＣＡＮに接続された不正機器からのリプレイ攻撃を防御するため、メッセージ認証コード（Message Authentication Code;ＭＡＣ）を用いる方法が提案されている。例えば、通常のメッセージを生成・送信する度に、そのメッセージに対するＭＡＣを生成し、ＭＡＣを含むメッセージを送信する方法が提案されている（例えば特許文献１参照）。

特開２０１３−９８７１９号公報

通常のメッセージを生成・送信する度に、ＭＡＣを生成するとノードの負荷が大きくなり消費電力も増大する。またメッセージの数が増えるため、バスの占有率も増大する。

本発明はこうした状況に鑑みなされたものであり、その目的は、ネットワークの資源の負荷増大を抑制しつつ、セキュリティを向上させる技術を提供することにある。

本発明のある態様の送信装置は、ブロードキャスト送信すべきデータを生成する第１生成部と、第１生成部において生成したデータを少なくとも対象としたメッセージ認証コードを生成する第２生成部と、第１生成部において生成したデータと、第２生成部において生成したメッセージ認証コードをブロードキャスト送信する送信部と、を備える。第２生成部は、第１生成部において生成される複数のデータの内、一部のデータに対するメッセージ認証コードの生成を省略する。

なお、以上の構成要素の任意の組み合わせ、本発明の表現を方法、装置、システム、コンピュータプログラム、コンピュータプログラムを記録した記録媒体などの間で変換したものもまた、本発明の態様として有効である。

本発明によれば、ネットワークの資源の負荷増大を抑制しつつ、セキュリティを向上させることができる。

ＣＡＮで使用されるデータフレームのフォーマットの一例を示す図である。 本発明の実施の形態に係るＣＡＮシステムの構成の一例を示す図である。 本発明の実施の形態に係るＥＣＵの構成例を示す図である。 ＭＡＣを別メッセージで送信する方式にて、メッセージ処理部の送信に必要な機能を示すブロック図である。 図４のメッセージ処理部によるメッセージ送信処理を示すフローチャートである。 ＭＡＣを別メッセージで送信する方式にて、メッセージ処理部の受信に必要な機能を示すブロック図である。 図６のメッセージ処理部によるメッセージ受信処理を示すフローチャートである。 ＭＡＣを別メッセージで送信する方式にて、異常ケースを想定したメッセージ処理部の受信に必要な機能を示すブロック図である。 図８のメッセージ処理部によるメインメッセージ受信処理を示すフローチャートである。 図８のメッセージ処理部によるＭＡＣメッセージ受信処理を示すフローチャートである。 図１１（ａ）−（ｅ）は、正規のメインメッセージと正規のＭＡＣメッセージの間に、不正のメッセージを挿入する攻撃の例を示す図である。 ＭＡＣを同一メッセージで送信する方式にて、メッセージ処理部の送信に必要な機能を示すブロック図である。 図１２のメッセージ処理部によるメッセージ送信処理を示すフローチャートである。 ＭＡＣを同一メッセージで送信する方式にて、メッセージ処理部の受信に必要な機能を示すブロック図である。 図１４のメッセージ処理部によるメッセージ受信処理を示すフローチャートである。 ＭＡＣの生成・送信タイミングの複数の具体例をまとめた一覧表を示す図である。 状態を表すデータが変化したときＭＡＣを生成・送信する方式にて、メッセージ処理部のＭＡＣ生成タイミング決定部に必要な機能を示すブロック図である。 図１７のＭＡＣ生成タイミング決定部によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。 状態を表すデータが変化したときＭＡＣを生成・送信する方式の具体例を示す図である。 状態を表すデータが変化したときＭＡＣを生成・送信する方式において、送信側ＥＣＵから受信側ＥＣＵに送信されるメッセージの一例を示す図である。 変化量が閾値を超えたときＭＡＣを生成・送信する方式にて、メッセージ処理部のＭＡＣ生成タイミング決定部に必要な機能を示すブロック図である。 図２１のＭＡＣ生成タイミング決定部によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。 変化量が閾値を超えたときＭＡＣを生成・送信する方式の具体例を示す図である。 値が閾値を超えたときＭＡＣを生成・送信する方式における、ＭＡＣ生成タイミング決定部によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。 値の変化が規定した方向への変化のときＭＡＣを生成・送信する方式における、ＭＡＣ生成タイミング決定部によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。 値がデフォルト値と異なるときＭＡＣを生成・送信する方式における、ＭＡＣ生成タイミング決定部によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。 間引き周期でＭＡＣを生成・送信する方式にて、メッセージ処理部のＭＡＣ生成タイミング決定部に必要な機能を示すブロック図である。 図２７のＭＡＣ生成タイミング決定部によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。 間引き周期でＭＡＣを生成・送信する方式の具体例を示す図である。 周期変化に応じてＭＡＣを生成・送信する方式にて、メッセージ処理部のＭＡＣ生成タイミング決定部に必要な機能を示すブロック図である。 図３０のＭＡＣ生成タイミング決定部によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。 イベント発生に応じてＭＡＣを生成・送信する方式における、ＭＡＣの生成タイミングを決定する処理を示すフローチャートである。 オンデマンドに応じてＭＡＣを生成・送信する方式における、ＭＡＣ生成タイミング決定部によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。 バス占有率に応じてＭＡＣを生成・送信する方式にて、メッセージ処理部のＭＡＣ生成タイミング決定部に必要な機能を示すブロック図である。 図３４のＭＡＣ生成タイミング決定部によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。 ランダムにＭＡＣを生成・送信する方式にて、メッセージ処理部のＭＡＣ生成タイミング決定部に必要な機能を示すブロック図である。 図３６のＭＡＣ生成タイミング決定部によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。 車両状態に応じてＭＡＣを生成・送信する方式における、ＭＡＣ生成タイミング決定部によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。 ＭＡＣの検証に失敗した不正メッセージの数をカウントする機能を有するメッセージ処理部の構成を示すブロック図である。

本発明の実施の形態は、車両内に搭載される複数のＥＣＵ（Electronic Control Unit)がノードとして接続された車載ネットワークであって、メッセージＩＤとデータとＭＡＣが含まれるメッセージがブロードキャストされるものに関する。以下、このようなネットワークとしてのＣＡＮシステムを例示して本発明の実施の形態を説明する。上述のように、ＣＡＮはバス型ネットワークを採用しており、バスに接続される各ＥＣＵからのメッセージは、バスに接続される全てのＥＣＵにブロードキャストされる。近年、車両の電装化が進み一台の車両に搭載されるＥＣＵの数やＥＣＵが扱うデータ量が増えており、ＣＡＮバスのトラフィック量が増えている。またＥＣＵの増加および高度化に伴い、バッテリの消費電力が増えている。

図１は、ＣＡＮで使用されるデータフレームのフォーマットの一例を示す図である。図１のデータフレームは、ＳＯＦ、ＩＤフィールド、ＲＴＲ、ＩＤＥ、ｒ０、ＤＬＣ、データフィールド、ＣＲＣデリミタ、Ａｃｋ、Ａｃｋデリミタ、及びＥＯＦを含む。各ボックス内の数字はビット数を示す。またボックスの上が開放されている項目は常に「０」をとる項目であり、ボックスの下が開放されている項目は常に「１」をとる項目である。上下が開放されていない項目は「０」と「１」の両方をとりうる項目である。

本実施の形態では主に、ＩＤフィールドＦ１とデータフィールドＦ２に注目する。ＩＤフィールドＦ１に格納されるＩＤ（以下適宜、ＣＡＮＩＤともいう）は、メッセージの種類および優先度を表す識別情報である。本明細書では、送信可能な状態のデータフレームをメッセージと呼ぶ。ＣＡＮにおけるメッセージは、車両内の特定の機能に関するメッセージである。当該機能には、特定の監視対象を監視する監視機能および特定の制御対象を制御する制御機能が含まれる。例えば車両内の特定の機能に関するメッセージとして、速度情報を含むメッセージ、ドアの開閉を指示するメッセージ等がある。

ＣＡＮＩＤは、送信されるメッセージに含まれる情報に関連づけられており、メッセージを受信したＥＣＵでは、そのＣＡＮＩＤに基づいてメッセージに含まれる情報を判断する。データフィールドＦ２には最大６４ビットのデータを格納できる。

図１に示すようにＣＡＮのデータフレームには、送信先ＩＤおよび受信先ＩＤが含まれない。従って受信側ＥＣＵは、正しい通信相手から来たメッセージであるか否か判断できない。例えば、エンジン回転数を含むメッセージはエンジンＥＣＵから送信される。当該メッセージに付与されるＣＡＮＩＤと同じＣＡＮＩＤが付与されたメッセージが、不正ＥＣＵから送信されると、受信側ＥＣＵは正当なエンジンＥＣＵからのメッセージか不正ＥＣＵからのメッセージであるか判別できない。

このようにＣＡＮプロトコルでは、なりすましが容易である。またメッセージがＣＡＮバスに対してブロードキャスト送信されるため、ユニキャスト送信よりも盗聴が容易である。

これらの脅威に対して本実施の形態では、ＭＡＣを用いることでＣＡＮメッセージを認証する。ＭＡＣは、認証対象のデータと共通鍵とに所定のＭＡＣアルゴリズムを適用して生成される。共通鍵は、ＣＡＮに接続されたＥＣＵ間で事前に共有される秘密の鍵である。ＭＡＣ生成アルゴリズムには、ハッシュ関数を使う方式（ＨＭＡＣ）や、ブロック暗号アルゴリズムを使う方式（ＯＭＡＣ／ＣＭＡＣ、ＣＢＣ−ＭＡＣ、ＰＭＡＣ）などがある。受信側ＥＣＵでは、メッセージに含まれる認証対象のデータと自己が保持する共通鍵に、送信側ＥＣＵで使用されたＭＡＣアルゴリズムを適用してＭＡＣを算出する。この算出したＭＡＣと受信したＭＡＣが一致していれば認証が成功したと判定し、不一致であれば認証が失敗したと判定する。

従って共通鍵が漏洩しなければ不正なＥＣＵや悪意がある発信元などからのメッセージは、認証されないことになる。正当なメッセージとＭＡＣを受信した不正なＥＣＵなどからの再送攻撃に対しては、認証対象のデータに、カウント値などを含めることにより対処できる。本実施の形態では、送信側ＥＣＵで生成されるＭＡＣのデータ長を６４ビット以下とする。６４ビットを超えるＭＡＣが算出される場合、その任意の６４ビット又はそれ以下のビットを抽出して使用する。

以下本明細書ではデータフィールドに、特定の機能に関する情報（以下適宜、通常データという）を含みＭＡＣを含まないメッセージをメインメッセージという。メインメッセージは通常の制御を行うために送信されるメッセージである。通常データは、特定の機能の制御値などが該当する。データフィールドに、通常データを含まずＭＡＣを含むメッセージをＭＡＣメッセージという。データフィールドに、通常データとＭＡＣの両方を含むメッセージをＭＡＣ付きメインメッセージという。

上記では、ＣＡＮＩＤはメッセージに含まれる情報に関連づけられると説明した。この場合、そのメッセージがメインメッセージであるか、ＭＡＣメッセージであるか、ＭＡＣ付きメインメッセージであるかにより、それぞれに別のＩＤが付されてもよく、同一のＩＤが付されてもよい。

各ＥＣＵにおいてメインメッセージが送信される度に、ＭＡＣを生成する処理が行われ、ＭＡＣメッセージがＣＡＮに送信されると、ＥＣＵの処理負荷および消費電流が増大し、バスの占有率も増加する。ＭＡＣを生成する処理は暗号化処理を含むため、ＥＣＵの処理負荷が増大する。車両内のＥＣＵには処理能力が非力なものも存在するため、処理負荷が低く抑えられることが望ましい。また車両において、ＥＣＵの消費電流が増大するとバッテリの消費が早くなり、バッテリ上がりが発生しやすくなりバッテリの寿命も短くなる。従ってＥＣＵの消費電流は低いことが望ましい。またＣＡＮにおいて、バス占有率の増加による通信障害を回避するため、一般的にはバス占有率がある一定値以下になるように設定されている。メインメッセージが送信される度にＭＡＣメッセージが送信されると、単純に従来の２倍のメッセージ数になる。

以上に鑑み、以下に説明する実施の形態では、メインメッセージの送信の度にＭＡＣを毎回送信するのではなく、ＭＡＣを送信するタイミングを工夫することで、送信頻度を減らしながらも効率的にセキュリティを確保する方法を提供する。即ち、送信すべき複数の通常データの内、一部の通常データに対するＭＡＣの生成・送信を省略することにより、ＥＣＵの処理負荷および消費電流の増大を抑え、バス占有率の増加も抑制する。なお、以下の説明において「生成・送信」なる表現は、「生成かつ送信」および「送信のみ」のいずれか一方を意味する。

図２は、本発明の実施の形態に係るＣＡＮシステム５００の構成の一例を示す図である。当該ＣＡＮシステム５００では、ＣＡＮバス２００に複数のＥＣＵ１００（図２ではＥＣＵ１（１００ａ）、ＥＣＵ２（１００ｂ）、ＥＣＵ３（１００ｃ）及びＥＣＵ４（１００ｄ））が接続されている。ＣＡＮでは、ＣＳＭＡ／ＣＡ(Carrier Sense Multiple Access with Collision Avoidance)と呼ばれるアクセス制御方式が採用されており、ＣＡＮバス２００に対して最初に送信を開始したＥＣＵ１００が送信権を取得する。なお同時に複数のＥＣＵ１００が送信した場合は、通信調停（bus arbitration）が行われる。ＣＡＮではＣＡＮＩＤの値が小さいほうが優先される。

図３は、本発明の実施の形態に係るＥＣＵ１００の構成例を示す図である。ＥＣＵ１００は、アプリケーション処理部１０、メッセージ処理部３０及び送受信部５０を備える。これらの構成は、ハードウエア的には、任意のプロセッサ、メモリ、及びその他のＬＳＩで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。

アプリケーション処理部１０は例えば、プロセッサ、メモリ、及びメモリにロードされたアプリケーションプログラムによって実現される。メッセージ処理部３０は例えば、プロセッサ、メモリ、メモリにロードされたメッセージ処理プログラム、及びＣＡＮコントローラによって実現される。なおＣＡＮコントローラに全ての機能を実装する構成も可能である。送受信部５０は例えば、トランシーバにより実現可能される。

アプリケーション処理部１０は、各ＥＣＵ１００の制御対象または監視対象（例えばエンジン、ステアリング、ブレーキ、又はその他の各種補機）と接続し、それらの対象からステータス情報または指示情報を取得する。アプリケーション処理部１０は当該対象から取得した情報をもとに、ＣＡＮにおいてブロードキャスト送信すべきデータを生成し、メッセージ処理部３０に渡す。またアプリケーション処理部１０は、ＣＡＮバス２００から（他のＥＣＵからＣＡＮバス２００を通じて）受信されたメインメッセージに含まれるデータをメッセージ処理部３０から受け取り、当該データに応じて当該対象を制御する。

メッセージ処理部３０は、メッセージ送信時にメッセージを生成するとともに、メッセージ受信時にメッセージを解析する。メッセージ処理部３０の具体的な構成は後述する。

送受信部５０は、メッセージ処理部３０により生成されたメッセージをＣＡＮバス２００に対してブロードキャスト送信する。上述のようにメッセージには、メインメッセージ、ＭＡＣメッセージ、及びＭＡＣ付きメインメッセージがある。メッセージ処理部３０は、アプリケーション処理部１０により生成された通常データを少なくとも対象としたＭＡＣを生成する。当該ＭＡＣは、当該通常データを含むメインメッセージに含めて送信されてもよいし、別のメッセージで送信されてもよい。前者の場合はＭＡＣ付きメインメッセージが送信され、後者の場合はメインメッセージとＭＡＣメッセージが別に送信される。いずれも場合も、当該通常データと当該通常データに対するＭＡＣが、ＣＡＮバス２００に対してブロードキャスト送信されることに変わりはない。

送受信部５０は、他のＥＣＵ１００で生成され、ＣＡＮバス２００に対してブロードキャスト送信されたメッセージをＣＡＮバス２００から受信する。送受信部５０は、受信したメッセージをメッセージ処理部３０に渡す。

図４は、ＭＡＣを別メッセージで送信する方式にて、メッセージ処理部３０の送信に必要な機能を示すブロック図である。図４では受信に関する機能は省略して描いている。図４のメッセージ処理部３０は、メインメッセージ生成部３１、ＣＡＮＩＤ抽出部３２、データフィールド抽出部３３、ＭＡＣ生成タイミング決定部３４、ＭＡＣ生成部３５及びＭＡＣメッセージ生成部３６を有する。

図５は、図４のメッセージ処理部３０によるメッセージ送信処理を示すフローチャートである。メインメッセージ生成部３１は、送信すべきデータをアプリケーション処理部１０から取得し、当該データをＣＡＮメッセージのデータフィールドに格納する。また当該データに対応するＣＡＮＩＤをＩＤフィールドに格納する。当該ＣＡＮＩＤはアプリケーション処理部１０から取得してもよいし、予め保持していてもよい。メインメッセージ生成部３１は、ＣＡＮメッセージのその他の項目の値を確定してメインメッセージを完成させる。メインメッセージ生成部３１は、生成したメインメッセージを送受信部５０に渡し、送受信部５０は当該メインメッセージをブロードキャスト送信する。

ＣＡＮＩＤ抽出部３２は、メインメッセージ生成部３１により生成されたメインメッセージのＩＤフィールドからＣＡＮＩＤを抽出する（図５のＳ１０）。ＣＡＮＩＤ抽出部３２は、抽出したＣＡＮＩＤをＭＡＣ生成タイミング決定部３４及びＭＡＣ生成部３５に渡す。データフィールド抽出部３３は、メインメッセージ生成部３１により生成されたメインメッセージのデータフィールドに格納されたデータを抽出する（Ｓ１１）。データフィールド抽出部３３は、抽出したデータをＭＡＣ生成タイミング決定部３４及びＭＡＣ生成部３５に渡す。

ＭＡＣ生成タイミング決定部３４は、抽出されたＣＡＮＩＤ及びデータから、ＭＡＣを生成すべきタイミングであるか否か判断する（Ｓ１２）。なお、判断方法の具体例は後述する。ＭＡＣ生成が必要なタイミングである場合（Ｓ１３のＹ）、ＭＡＣ生成タイミング決定部３４はＭＡＣ生成部３５にＭＡＣの生成を指示する。ＭＡＣ生成部３５は、抽出されたＣＡＮＩＤ及びデータをもとにＭＡＣを生成する（Ｓ１４）。具体的には、少なくともＣＡＮＩＤ及びデータを含む認証対象に、保持する共通鍵３５ａを使用して所定のＭＡＣアルゴリズムを適用して、当該認証対象に対するＭＡＣを生成する。ＭＡＣ生成部３５は、生成したＭＡＣをＭＡＣメッセージ生成部３６に渡す。

ＭＡＣメッセージ生成部３６は、ＭＡＣ生成部３５から取得したＭＡＣをＣＡＮメッセージのデータフィールドに格納する。また上記データに対するＭＡＣを含むメッセージであることを示すＣＡＮＩＤをＩＤフィールドに格納する。例えば上記データそのものを含むメッセージであることを示すＣＡＮＩＤの値から所定の固定値を減算した値が使用されてもよい。ＭＡＣメッセージ生成部３６は、ＣＡＮメッセージのその他の項目の値を確定してＭＡＣメッセージを完成させる。ＭＡＣメッセージ生成部３６は、生成したＭＡＣメッセージを送受信部５０に渡し、送受信部５０は当該ＭＡＣメッセージをブロードキャスト送信する（Ｓ１５）。ステップＳ１３にて、ＭＡＣの生成が必要なタイミングでない場合（Ｓ１３のＮ）、ステップＳ１４及びステップＳ１５におけるＭＡＣ生成・送信処理はスキップされる。

図６は、ＭＡＣを別メッセージで送信する方式にて、メッセージ処理部３０の受信に必要な機能を示すブロック図である。図６では送信に関する機能は省略して描いている。図６のメッセージ処理部３０は、メッセージ解析部４１、ＣＡＮＩＤ抽出部４２、データフィールド抽出部４３、ＭＡＣ検証タイミング決定部４４、ＭＡＣ生成部４５、ＭＡＣ比較部４６及びデータ受渡部４７を有する。

図７は、図６のメッセージ処理部３０によるメッセージ受信処理を示すフローチャートである。送受信部５０はＣＡＮバス２００からメインメッセージを受信し、メッセージ解析部４１に渡す。ＣＡＮＩＤ抽出部４２は、メッセージ解析部４１により受信されたメインメッセージのＩＤフィールドからＣＡＮＩＤを抽出する（図７のＳ２０）。ＣＡＮＩＤ抽出部４２は、抽出したＣＡＮＩＤをＭＡＣ検証タイミング決定部４４及びＭＡＣ生成部４５に渡す。データフィールド抽出部４３は、メッセージ解析部４１により受信されたメインメッセージのデータフィールドに格納されたデータを抽出する（Ｓ２１）。データフィールド抽出部４３は、抽出したデータをＭＡＣ検証タイミング決定部４４、ＭＡＣ生成部４５及びデータ受渡部４７に渡す。

ＭＡＣ検証タイミング決定部４４は、抽出されたＣＡＮＩＤ及びデータから、ＭＡＣを検証すべきタイミングであるか否か判断する（Ｓ２２）。なお、判断方法の具体例は後述するが、送信側のＭＡＣ生成タイミング決定部３４と同じ判断方法が用いられる。ＭＡＣの検証が必要なタイミングである場合（Ｓ２３のＹ）、ＭＡＣ検証タイミング決定部４４はＭＡＣ生成部４５にＭＡＣの生成を指示する。ＭＡＣ生成部４５は、抽出されたＣＡＮＩＤ及びデータをもとにＭＡＣを生成する（Ｓ２４）。生成方法は送信側のＭＡＣ生成部３５の生成方法と同じである。受信側のＭＡＣ生成部４５は、送信側のＭＡＣ生成部３５が保持する共通鍵３５ａと同じ共通鍵４５ａを保持している。ＭＡＣ生成部４５は、生成したＭＡＣをＭＡＣ比較部４６に渡す。

ＥＣＵ１００は当該メインメッセージに対するＭＡＣメッセージの到着を待ち（Ｓ２５のＮ）、ＭＡＣメッセージが受信された場合（Ｓ２５のＹ）、送受信部５０はＣＡＮバス２００からＭＡＣメッセージを受信し、メッセージ解析部４１に渡す。データフィールド抽出部４３は、メッセージ解析部４１により受信されたＭＡＣメッセージのデータフィールドに格納されたＭＡＣを抽出する（Ｓ２６）。データフィールド抽出部４３は、抽出したＭＡＣをＭＡＣ比較部４６に渡す。

ＭＡＣ比較部４６は、ＭＡＣ生成部４５により生成されたＭＡＣとデータフィールド抽出部４３により抽出されたＭＡＣとを比較する（Ｓ２７）。両者のＭＡＣが一致した場合（Ｓ２８のＹ）、ＭＡＣ比較部４６はＭＡＣの検証が成功したと判定し、データ受渡部４７に検証が成功した旨を通知する。データ受渡部４７はデータフィールド抽出部４３から取得し、保留していたデータをアプリケーション処理部１０に渡す（Ｓ２９）。アプリケーション処理部１０は、取得したデータに応じて制御対象を制御、または監視対象を監視する。

ステップＳ２８にて、両者のＭＡＣが一致しない場合（Ｓ２８のＮ）、ＭＡＣ比較部４６はＭＡＣの検証が失敗したと判定し、データ受渡部４７に検証が失敗した旨を通知する。データ受渡部４７は、データフィールド抽出部４３から取得し、保留していたデータをアプリケーション処理部１０に渡さない。ステップＳ２３にて、ＭＡＣ検証が必要なタイミングでない場合（Ｓ２３のＮ）、ステップＳ２４〜ステップＳ２８の処理がスキップされる。データ受渡部４７は、データフィールド抽出部４３から取得したデータを無条件にアプリケーション処理部１０に渡す（Ｓ２９）。

図５及び図６に示すように、ＭＡＣを別メッセージで送信する場合、メインメッセージとＭＡＣメッセージの間に攻撃者が不正メッセージを挿入する攻撃が考えられる。以下、このような異常ケースを想定したメッセージ受信時の処理を説明する。

図８は、ＭＡＣを別メッセージで送信する方式にて、異常ケースを想定したメッセージ処理部３０の受信に必要な機能を示すブロック図である。図８では送信に関する機能は省略して描いている。図８のメッセージ処理部３０は、図６の異常ケースを想定しないメッセージ処理部３０の構成要素に、メインメッセージ一時保持部４８が追加された構成である。メインメッセージ一時保存部４８は、一般的なメモリ素子などによって実現される。

図９は、図８のメッセージ処理部３０によるメインメッセージ受信処理を示すフローチャートである。制御の方針としては、メインメッセージを最大ｎ個（３つ程度）まで保持し、ＭＡＣメッセージと保持しているメインメッセージとでＭＡＣを検証する。検証の結果、Ｒｉｊｅｃｔされた（検証が失敗した）場合は、保持しているメッセージを破棄する処理を行う。メッセージ解析部４１は、送受信部５０を介してＣＡＮバス２００からメインメッセージを受信すると、メインメッセージ一時保持部４８にメインメッセージが保持されているか否か判断する（図９のＳ３０）。保持されている場合（Ｓ３０のＹ）、メインメッセージ一時保持部４８に保持されているメインメッセージの数がｎ個以上であるか否か判断する（Ｓ３１）。ｎはメインメッセージ一時保持部４８に保持されるメインメッセージの上限数を規定したパラメータである。例えばｎ＝３に設定される。

メインメッセージの数がｎ個以上、保持されている場合（Ｓ３１のＹ）、メッセージ解析部４１は、メインメッセージ一時保持部４８に保持されている複数のメインメッセージの内、最も古いメインメッセージを破棄する（Ｓ３２）。メッセージ解析部４１は、受信した新しいメインメッセージをメインメッセージ一時保持部４８に格納する（Ｓ３３）。即ち、メインメッセージ一時保持部４８はＦＩＦＯで管理される。メインメッセージ一時保持部４８に格納されたメインメッセージに対する処理は、メッセージ解析部４１から指示があるまで保留される。

ステップＳ３１にて、メインメッセージ一時保持部４８に保持されているメインメッセージの数がｎ個未満である場合（Ｓ３１のＮ）、ステップＳ３２をスキップして、メッセージ解析部４１は、受信した新しいメインメッセージをメインメッセージ一時保持部４８に格納する（Ｓ３３）。

ステップＳ３０にて、メインメッセージ一時保持部４８にメインメッセージが保持されていない場合（Ｓ３０のＮ）、ＭＡＣ検証タイミング決定部４４は、そのメインメッセージに対するＭＡＣの検証が必要であるか否か判断する（Ｓ３４）。この判断方法の具体例は後述する。ＭＡＣの検証が必要である場合（Ｓ３４のＹ）、ＭＡＣ検証タイミング決定部４４は、その旨をメッセージ解析部４１に通知し、メッセージ解析部４１は、受信した新しいメインメッセージをメインメッセージ一時保持部４８に格納する（Ｓ３３）。

ステップＳ３４にて、ＭＡＣの検証が必要でない場合（Ｓ３４のＮ）、データ受渡部４７は、データフィールド抽出部４３から取得したデータをアプリケーション処理部１０に渡す（Ｓ３５）。アプリケーション処理部１０は、取得したデータに応じて制御対象を制御する、または監視対象を監視する。

図１０は、図８のメッセージ処理部３０によるＭＡＣメッセージ受信処理を示すフローチャートである。メッセージ解析部４１は、送受信部５０を介してＣＡＮバス２００からＭＡＣメッセージを受信すると、メインメッセージ一時保持部４８に検証の必要なメインメッセージが保持されているか否か判断する（図１０のＳ４０）。保持されている場合（Ｓ４０のＹ）、メインメッセージからＭＡＣを生成する（Ｓ４１）。具体的には当該メインメッセージのＣＡＮＩＤ及びデータからＭＡＣを生成する。

ＭＡＣ比較部４６は、上記メインメッセージから生成されたＭＡＣと、受信されたＭＡＣメッセージから抽出されたＭＡＣを比較する（Ｓ４２）。両者のＭＡＣが一致した場合（Ｓ４２のＹ）、データ受渡部４７は、データフィールド抽出部４３から取得したデータをアプリケーション処理部１０に渡す（Ｓ４３）。アプリケーション処理部１０は、取得したデータに応じて取得したデータに応じて制御対象を制御する、または監視対象を監視する。

ＭＡＣ比較部４６による検証が成功した場合にて、メインメッセージ一時保持部４８にその他のメインメッセージが保持されている場合（Ｓ４４のＹ）、保持されているその他のメインメッセージは破棄される（Ｓ４５）。保持されていない場合（Ｓ４４のＮ）、ステップＳ４５の処理はスキップされる。

ステップＳ４２にて、ＭＡＣが一致しない場合（Ｓ４２のＮ）、ステップＳ４０に遷移し、検証の必要なメインメッセージが保持されているか否かの判断が繰り返される。

ステップＳ４０にて、メインメッセージ一時保持部４８に検証の必要なメインメッセージが保持されていない場合（Ｓ４０のＮ）、メッセージ解析部４１は、受信したＭＡＣメッセージを破棄する（Ｓ４６）。

図１１（ａ）−（ｅ）は、正規のメインメッセージと正規のＭＡＣメッセージの間に、不正のメッセージを挿入する攻撃の例を示す図である。図１１（ａ）−（ｅ）では、車速センサに接続されたＥＣＵから、制御値として車速情報をデータフィールドに含むメインメッセージを送信する例を描いている。また前回送信したメインメッセージに含まれる車速と異なる車速を含むメインメッセージを送信する際に、ＭＡＣメッセージが生成・送信される制御を前提とする。即ち、前回送信したメインメッセージに含まれる車速と、今回送信するメインメッセージに含まれる車速が同じ場合、ＭＡＣメッセージは生成・送信されない。また図１１（ａ）−（ｅ）のそれぞれの、先頭のメインメッセージの直前のメッセージは、制御値として車速＝３０ｋｍ／ｈを含むメインメッセージであるとする。またメインメッセージ一時保持部４８に保持されるメインメッセージの上限数ｎは３とする。また図１１（ａ）−（ｅ）において、不正なメッセージは太枠で囲んでいる。

図１１（ａ）は、正常なケースを示す例である。このケースでは不正なメッセージは挿入されていない。前回のメインメッセージに含まれる車速と異なる車速を含む、２番目のメインメッセージと３番目のメインメッセージに、それぞれＭＡＣメッセージが付加される。先頭のメインメッセージは、前回のメインメッセージに含まれる車速と同じ車速（＝３０ｋｍ／ｈ）を含むメッセージであるため、ＭＡＣメッセージが付加されない。

図１１（ｂ）は、攻撃パターン１を示す例である。先頭のメインメッセージは不正なメインメッセージである。このメインメッセージ（不正）に含まれる車速（＝４０ｋｍ／ｈ）は、前回のメインメッセージ（正規）に含まれる車速（＝３０ｋｍ／ｈ）と異なる。従って図９のステップＳ３４のＭＡＣ検証が必要なメインメッセージに該当する。従って図９のステップＳ３４のＭＡＣの検証が必要なメインメッセージに該当するため、このメインメッセージは、メインメッセージ一時保持部４８に格納される。２番目及び３番目のメインメッセージ（正規）は、図９のステップＳ３０のメインメッセージ一時保持部４８に既にメインメッセージを保持しているという条件を満たすため、メインメッセージ一時保持部４８に格納される。

４番目のメインメッセージ（正規）の受信時点で、メインメッセージ一時保持部４８に既に３個のメインメッセージが保持されている。従って図９のステップＳ３２により最も古い先頭のメインメッセージ（不正）が破棄される。

図１１（ｃ）は、攻撃パターン２を示す例である。先頭のメインメッセージ（正規）は、図９のステップＳ３４の条件を満たすため、メインメッセージ一時保持部４８に格納される。２番目及び３番目のメインメッセージ（不正）も、図９のステップＳ３０の条件を満たすため、メインメッセージ一時保持部４８に格納される。３番目のメインメッセージ（正規）の次にＭＡＣメッセージ（正規）が受信される。メインメッセージ一時保持部４８に保持される３個のメインメッセージの内、図１０のステップＳ４０の検証が必要なメインメッセージは、先頭のメインメッセージ（正規）と３番目のメインメッセージ（不正）である。２番目のメインメッセージ（不正）に含まれる車速（＝４０ｋｍ／ｈ）は、前回のメインメッセージ（正規）に含まれる車速（＝３０ｋｍ／ｈ）と異なるため、２番目のメインメッセージ（不正）は検証が必要なメインメッセージに該当しない。

メインメッセージ一時保持部４８に検証が必要なメインメッセージが複数保持される場合、新しいメインメッセージから検証される。この例では３番目のメインメッセージ（不正）から検証される。３番目のメインメッセージ（不正）から生成されるＭＡＣと、受信したＭＡＣメッセージ（正規）に含まれるＭＡＣは一致しない。次に先頭のメインメッセージ（正規）が検証される。先頭のメインメッセージ（正規）から生成されるＭＡＣと、受信したＭＡＣメッセージ（正規）に含まれるＭＡＣは一致する。従って先頭のメインメッセージ（正規）がアプリケーション処理部１０に渡される。図１０のステップＳ４５により、２番目のメインメッセージ（不正）と３番目のメインメッセージ（不正）は破棄される。

なおＭＡＣメッセージが受信される前に、メインメッセージのＭＡＣを生成することも考えられる。しかしながら不正なメインメッセージが多量に送信された場合、メインメッセージのＭＡＣを生成することによるＥＣＵ１００の負荷が増大する。本実施の形態ではＭＡＣメッセージが受信された後に、新しいメインメッセージから順番にＭＡＣを生成して検証し、検証が成功したメインメッセージが見つかった時点で、残りのメインメッセージを破棄する。これによりＥＣＵ１００の負荷の増大を抑制できる。

図１１（ｄ）は、攻撃パターン３を示す例である。先頭のメインメッセージ（正規）は、図９のステップＳ３４の条件を満たすため、メインメッセージ一時保持部４８に格納される。２番目のメインメッセージ（不正）も、図９のステップＳ３０の条件を満たすため、メインメッセージ一時保持部４８に格納される。その次にＭＡＣメッセージ（不正）が受信される。

メインメッセージ一時保持部４８に保持される２個のメインメッセージの内、図１０のステップＳ４０の検証が必要なメインメッセージは、先頭のメインメッセージ（正規）である。２番目のメインメッセージ（不正）は検証が必要なメインメッセージに該当しない。先頭のメインメッセージ（正規）から生成されるＭＡＣと、受信したＭＡＣメッセージ（不正）に含まれるＭＡＣは一致しない。これによりメインメッセージ一時保持部４８に、検証が必要なメインメッセージが存在しなくなるため、図１０のステップＳ４６により当該ＭＡＣメッセージ（不正）が破棄される。このように２番目のメインメッセージ（不正）と当該ＭＡＣメッセージ（不正）との検証は行われずに、当該ＭＡＣメッセージ（不正）が破棄される。

次にＭＡＣメッセージ（正規）がさらに受信される。先頭のメインメッセージ（正規）から生成されるＭＡＣと、今回受信したＭＡＣメッセージ（正規）に含まれるＭＡＣは一致する。従って先頭のメインメッセージ（正規）がアプリケーション処理部１０に渡される。図１０のステップＳ４５により、メインメッセージ一時保持部４８内の２番目のメインメッセージ（不正）は破棄される。

図１１（ｅ）は、攻撃パターン４を示す例である。先頭のメインメッセージ（不正）は、図９のステップＳ３４の条件を満たすため、メインメッセージ一時保持部４８に格納される。２番目のメインメッセージ（正規）も、図９のステップＳ３０の条件を満たすため、メインメッセージ一時保持部４８に格納される。その次にＭＡＣメッセージ（不正）が受信される。

メインメッセージ一時保持部４８に保持される２個のメインメッセージの内、図１０のステップＳ４０の検証が必要なメインメッセージは、先頭のメインメッセージ（不正）である。２番目のメインメッセージ（正規）は検証が必要なメインメッセージに該当しない。先頭のメインメッセージ（不正）から生成されるＭＡＣと、受信したＭＡＣメッセージ（不正）に含まれるＭＡＣは一致しない。これによりメインメッセージ一時保持部４８に、検証が必要なメインメッセージが存在しなくなるため、図１０のステップＳ４６により当該ＭＡＣメッセージ（不正）が破棄される。

正規のメインメッセージと正規のＭＡＣメッセージの間に、不正のメッセージを挿入する攻撃に対しては、ＭＡＣメッセージの優先度をメインメッセージの優先度より高く設定することが有効である。これは、ＭＡＣメッセージのＣＡＮＩＤが、メインメッセージのＣＡＮＩＤより常に小さくなるように各メッセージのＣＡＮＩＤを設定すれば実現できる。上述のようにＣＡＮでは、同時に複数のメッセージが送信された場合、通信調停によりＣＡＮＩＤの値が小さいほうが優先されるためである。ＭＡＣメッセージの優先度をメインメッセージの優先度より高く設定することにより、正規のメインメッセージと正規のＭＡＣメッセージとの間に、多量の不正のメッセージが挿入される確率を下げることができる。

これまで、ＭＡＣの検証が必要なメインメッセージを受信した場合、そのメインメッセージに対応するＭＡＣメッセージが受信されるまで、メインメッセージに含まれるデータをデータ受渡部４７に保留する方式を説明した。ＭＡＣの検証が必要なメインメッセージを受信した場合でも、データ受渡部４７が、メインメッセージに含まれるデータを即座にアプリケーション処理部１０に渡す方式を採用することもできる。この方式では、ＭＡＣの検証が必要なメインメッセージを受信してから、所定の設定時間内に当該メインメッセージに対応するＭＡＣメッセージを受信できない場合、データ受渡部４７はアプリケーション処理部１０に、当該メインメッセージに含まれるデータを渡す前の制御状態に戻すよう指示する。この方式は、車両の安全性に比較的影響しない制御に適用されるのが望ましい。

なおデータ受渡部４７はアプリケーション処理部１０に、当該メインメッセージに含まれるデータを渡す前の制御状態に戻すよう指示する代わりに、フェイルセーフモードに移行するよう指示してもよい。

図１２は、ＭＡＣを同一メッセージで送信する方式にて、メッセージ処理部３０の送信に必要な機能を示すブロック図である。図１２では受信に関する機能は省略して描いている。図１２のメッセージ処理部３０の構成は、図４のメッセージ処理部３０の構成からＭＡＣメッセージ生成部３６を省略した構成である。

図１３は、図１２のメッセージ処理部３０によるメッセージ送信処理を示すフローチャートである。図１３のステップＳ１０〜ステップＳ１４までの処理は、図５のステップＳ１０〜ステップＳ１４までの処理と同じである。メインメッセージ生成部３１は、ＭＡＣ生成部３５から取得したＭＡＣを、メインメッセージのデータフィールドに、既に格納されているデータと重複しないように格納する。また上記データ及び当該データに対するＭＡＣを含むＭＡＣ付きメインメッセージであることを示すＣＡＮＩＤをＩＤフィールドに格納する。メインメッセージ生成部３１は、生成したＭＡＣ付きメインメッセージを送受信部５０に渡し、送受信部５０は当該ＭＡＣ付きメインメッセージをブロードキャスト送信する（Ｓ１５ａ）。

図１４は、ＭＡＣを同一メッセージで送信する方式にて、メッセージ処理部３０の受信に必要な機能を示すブロック図である。図１４では送信に関する機能は省略して描いている。図１４のメッセージ処理部３０は、図６のメッセージ処理部３０の構成と比較し、データフィールド抽出部４３が分離部４３ａを含む構成である。その他の構成は同じである。

図１５は、図１４のメッセージ処理部３０によるメッセージ受信処理を示すフローチャートである。送受信部５０はＣＡＮバス２００からＭＡＣ付きメインメッセージを受信し、メッセージ解析部４１に渡す。ＣＡＮＩＤ抽出部４２は、メッセージ解析部４１により受信されたＭＡＣ付きメインメッセージのＩＤフィールドからＣＡＮＩＤを抽出する（図１５のＳ２０ａ）。データフィールド抽出部４３は、メッセージ解析部４１により受信されたＭＡＣ付きメインメッセージのデータフィールド内のデータ及びＭＡＣを抽出する（Ｓ２１ｂ）。データフィールド抽出部４３は、抽出したデータフィールド内のデータとＭＡＣとを分離する（Ｓ２２）。

ＭＡＣ検証タイミング決定部４４は、抽出されたＣＡＮＩＤ及びデータから、ＭＡＣを検証すべきタイミングであるか否か判断する（Ｓ２３）。ＭＡＣの検証が必要なタイミングである場合（Ｓ２３のＹ）、ＭＡＣ生成部４５は、抽出されたＣＡＮＩＤ及びデータをもとにＭＡＣを生成する（Ｓ２４）。ＭＡＣ比較部４６は、ＭＡＣ生成部４５により生成されたＭＡＣと、データフィールド抽出部４３により抽出および分離されたＭＡＣを比較する（Ｓ２７ａ）。両者のＭＡＣが一致した場合（Ｓ２８のＹ）、ＭＡＣ比較部４６はＭＡＣの検証が成功したと判定し、データ受渡部４７に検証が成功した旨を通知する。データ受渡部４７はデータフィールド抽出部４３から取得し、保留していたデータをアプリケーション処理部１０に渡す（Ｓ２９）。アプリケーション処理部１０は、取得したデータに応じて制御対象を制御する、または監視対象を監視する。

ステップＳ２８にて、両者のＭＡＣが一致しない場合（Ｓ２８のＮ）、ＭＡＣ比較部４６はＭＡＣの検証が失敗したと判定し、データ受渡部４７に検証が失敗した旨を通知する。データ受渡部４７は、データフィールド抽出部４３から取得し、保留していたデータをアプリケーション処理部１０に渡さない。ステップＳ２３にて、ＭＡＣの検証が必要なタイミングでない場合（Ｓ２３のＮ）、ステップＳ２４、ステップＳ２７ａ及びステップＳ２８の処理がスキップされ、データ受渡部４７は、データフィールド抽出部４３から取得したデータを無条件にアプリケーション処理部１０に渡す（Ｓ２９）。

以上に説明したＭＡＣを同一メッセージで送信する方式は、送信すべき通常データの量が少ない場合に有効である。ＭＡＣを同一メッセージで送信する方式はＭＡＣを別メッセージで送信する方式と比較し、基本的にメッセージ数を減らす効果がある。しかしながら、通常データの量が多い場合、６４ビットのデータフィールドに通常データとＭＡＣを併存させるのが難しくなる。その場合、両者の少なくとも一方を複数に分割する必要があり、メッセージの数が増える。またＭＡＣを別メッセージで送信する方式のほうが通常、メッセージ処理部３０の処理を単純化できる。従って必ずしも、ＭＡＣを同一メッセージで送信する方式が、ＭＡＣを別のメッセージで送信する方式より有利というわけではない。したがって、通常データの量などが考慮されたうえで、両者が使い分けられて設定されるのが好ましい。

以下、ＭＡＣメッセージの生成・送信タイミングについて説明する。各ＥＣＵ１００は、通常データを含むメッセージを受信し、その通常データが示す値によって特定の制御を実行している。上述のように受信側ＥＣＵ１００でも送信側ＥＣＵ１００と同様に、ＭＡＣが付加されるべきタイミングを判断している。受信側ＥＣＵ１００では正規のＭＡＣが到着して検証が成功しない限り当該制御を保留している。これにより攻撃者からの不正制御を防御している。

車両内のＣＡＮで送信される通常データには様々な種類があるが、送信する値が変化しなくても周期的に送信される通常データも多い。例えば車速センサのＥＣＵ１００からは周期的に車速情報が送信される。

以上の状況に鑑み、送信する値が変化するときのみＭＡＣを生成・送信する制御方式が考えられる。この場合、セキュリティを確保しつつＥＣＵ１００及びＣＡＮバス２００の負荷を下げることができる。以下、送信すべき通常データ固有の特徴もしくは性質、または送信すべき通常データの重要度などに応じてＭＡＣの生成・送信タイミングを決定する方法を説明する。

図１６は、ＭＡＣの生成・送信タイミングの複数の具体例をまとめた一覧表を示す図である。まず大分類として、データ変化に起因してタイミングを決定するグループ、送信周期性に起因してタイミングを決定するグループ、及びその他のグループに分類した。

まず、データ変化に起因してタイミングを決定するグループの第１の例として、制御対象または監視対象の状態を表すデータが変化したときＭＡＣを生成・送信する方式を説明する。例えば、ドアロックのＯＮ／ＯＦＦが変化したときにＭＡＣを生成・送信する。またギアポジション（Ｐ，Ｎ，Ｄ，Ｒ）が変化したときにＭＡＣを生成・送信する。このように、制御対象または監視対象の状態は２値で表される場合もあれば、多値で表される場合もある。またエンジン回転数のように、さらに細かな値で表される場合もある。前回のデータと同じ値のデータは重要度が低いデータといえる。仮に当該データが不正なデータであっても、制御に与える影響が小さい。従って負荷軽減を優先して当該データに対するＭＡＣの生成・送信を省略する。

図１７は、状態を表すデータが変化したときＭＡＣを生成・送信する方式にて、メッセージ処理部３０のＭＡＣ生成タイミング決定部３４に必要な機能を示すブロック図である。図１７のＭＡＣ生成タイミング決定部３４は、前回データ保持部３４１及び比較部３４３を含む。

図１８は、図１７のＭＡＣ生成タイミング決定部３４によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。前回データ保持部３４１には、前回のメインメッセージで送信したデータが保持される。比較部３４３は、前回データ保持部３４１に保持されるデータと、データフィールド抽出部３３から渡される今回送信すべきデータを比較する（Ｓ５０）。両者のデータが異なる場合（Ｓ５１のＹ）、比較部３４３はＭＡＣ生成部３５にＭＡＣの生成を指示する。ＭＡＣ生成部３５は、ＣＡＮＩＤ抽出部３２及びデータフィールド抽出部３３により抽出されたＣＡＮＩＤ及びデータをもとにＭＡＣを生成する（Ｓ５２）。前回データ保持部３４１内の保持データは、今回送信されたデータに更新される（Ｓ５３）。ステップＳ５１にて、両者のデータが一致する場合（Ｓ５１のＮ）、ステップＳ５２及びステップＳ５３の処理はスキップされる。

図１９は、状態を表すデータが変化したときＭＡＣを生成・送信する方式の具体例を示す図である。図１９では２値（ＯＮ／ＯＦＦ）の状態を表すデータを送信する例を示している。２番目のメインメッセージＭ２に含まれるデータの値（ＯＮ）は、先頭のメインメッセージＭ１に含まれるデータの値（ＯＮ）に対して変化していないため、２番目のメインメッセージＭ２に対するＭＡＣは生成されない。３番目のメインメッセージＭ３に含まれるデータの値（ＯＦＦ）は、２番目のメインメッセージＭ２に含まれるデータの値（ＯＮ）に対して変化しているため、３番目のメインメッセージＭ３に対するＭＡＣが生成・送信される。同様に４番目のメインメッセージＭ４に対するＭＡＣは生成されず、５番目のメインメッセージＭ５に対するＭＡＣが生成・送信される。

図２０は、状態を表すデータが変化したときＭＡＣを生成・送信する方式において、送信側ＥＣＵ１００から受信側ＥＣＵ１００に送信されるメッセージの一例を示す図である。送信すべきデータの値が変化しない第１フェーズＰ１、第２フェーズＰ２及び第４フェーズＰ４では、送信側ＥＣＵ１００でメインメッセージのみが生成され、受信側ＥＣＵ１００に送信される。

送信すべきデータの値が変化する第３フェーズＰ３及び第５フェーズＰ５では、送信側ＥＣＵ１００でメインメッセージと、当該メインメッセージに対するＭＡＣメッセージが生成される。送信側ＥＣＵ１００から当該メインメッセージと当該ＭＡＣメッセージの両方が受信側ＥＣＵ１００に送信される。

次に、データ変化に起因してタイミングを決定するグループの第２の例として、データによって示される値の変化量が閾値を超えたときＭＡＣを生成・送信する方式を説明する。例えば、最後にＭＡＣを生成・送信したときのエンジン回転数の値から、１００ｒｐｍを超えて変化したときにＭＡＣを生成・送信する。データによって示される値の変化量が小さいデータは重要度が低いデータといえる。仮に当該データが不正なデータであっても、制御に与える影響が小さい。従って負荷軽減を優先して当該データに対するＭＡＣの生成・送信を省略する。

図２１は、変化量が閾値を超えたときＭＡＣを生成・送信する方式にて、メッセージ処理部３０のＭＡＣ生成タイミング決定部３４に必要な機能を示すブロック図である。図２１のＭＡＣ生成タイミング決定部３４は、前回データ保持部３４１、減算部３４２及び比較部３４３を含む。

図２２は、図２１のＭＡＣ生成タイミング決定部３４によるＭＡＣの生成をタイミング決定する処理を示すフローチャートである。前回データ保持部３４１には前回、ＭＡＣメッセージが生成されたメインメッセージで送信されたデータの値が保持される。減算部３４２は、前回データ保持部３４１に保持されるデータの値と、データフィールド抽出部３３から渡される今回送信すべきデータの値との差分値を算出する（Ｓ５０ａ）。この例では当該差分値は絶対値で算出される。比較部３４３は算出された差分値と閾値を比較し、当該差分値が当該閾値を超える場合（Ｓ５１ａのＹ）、比較部３４３はＭＡＣ生成部３５にＭＡＣの生成を指示する。ＭＡＣ生成部３５は、ＣＡＮＩＤ抽出部３２及びデータフィールド抽出部３３により抽出されたＣＡＮＩＤ及びデータをもとにＭＡＣを生成する（Ｓ５２）。前回データ保持部３４１内の保持データは、今回送信されたデータに更新される（Ｓ５３）。ステップＳ５１ａにて、当該差分値が当該閾値以下の場合（Ｓ５１ａのＮ）、ステップＳ５２及びステップＳ５３の処理はスキップされる。

図２３は、変化量が閾値を超えたときＭＡＣを生成・送信する方式の具体例を示す図である。図２３ではエンジンの回転数を表すデータを送信する例を示している。この例では、先頭のメインメッセージＭ１の直前に送信されたメインメッセージ（不図示）に含まれるエンジン回転数が９９９ｒｐｍであり、当該メインメッセージに対するＭＡＣメッセージが生成・送信されたことを前提とする。また上記の閾値は１００ｒｐｍとする。

前回ＭＡＣメッセージが生成されたメインメッセージで送信されたエンジン回転数（９９９ｒｐｍ）と、先頭のメインメッセージＭ１に含まれるエンジン回転数（１０００ｒｐｍ）との差分の絶対値は１００ｒｐｍ以下である。同様に２番目のメインメッセージＭ２に含まれるエンジン回転数（１００２ｒｐｍ）との差分の絶対値も１００ｒｐｍ以下である。同様に３番目のメインメッセージＭ３に含まれるエンジン回転数（１００５ｒｐｍ）との差分の絶対値も１００ｒｐｍ以下である。従って先頭のメインメッセージＭ１、２番目のメインメッセージＭ２、及び３番目のメインメッセージに対するＭＡＣメッセージは生成・送信されない。

前回ＭＡＣメッセージが生成されたメインメッセージで送信されたエンジン回転数（９９９ｒｐｍ）と、４番目のメインメッセージＭ４に含まれるエンジン回転数（１１００ｒｐｍ）との差分の絶対値は１００ｒｐｍを超える。従って４番目のメインメッセージＭ４に対するＭＡＣメッセージが生成・送信される。これにより、前回ＭＡＣメッセージが生成されたメインメッセージで送信されたエンジン回転数は１１００ｒｐｍに更新される。

前回ＭＡＣメッセージが生成された４番目のメインメッセージＭ４で送信されたエンジン回転数（１１００ｒｐｍ）と、５番目のメインメッセージＭ５に含まれるエンジン回転数（１１０３ｒｐｍ）との差分の絶対値は１００ｒｐｍ以下である。従って５番目のメインメッセージＭ５に対するＭＡＣメッセージは生成・送信されない。

図２１〜図２３に示した例では、前回送信されたデータの値として、前回ＭＡＣメッセージが生成されたメインメッセージで送信されたデータの値を使用したが、ＭＡＣメッセージの生成の有無を問わず、前回送信されたメインメッセージに含まれるデータの値を使用してもよい。

次に、データ変化に起因してタイミングを決定するグループの第３の例として、データによって示される値が閾値を超えたとき、または下回ったときにＭＡＣを生成・送信する方式を説明する。例えば、車速が１０ｋｍ／ｈを超えている場合、常にＭＡＣを生成・送信する。または例えば、バッテリの電源電圧が所定の値を下回った場合、常にＭＡＣを生成・送信する。閾値を超える、または下回る値を持つデータは重要度が高いデータといえる。従ってセキュリティの確保を優先して当該データに対するＭＡＣを生成・送信する。

値が閾値を超えたとき、または下回ったときにＭＡＣを生成・送信する方式にて、メッセージ処理部３０のＭＡＣ生成タイミング決定部３４に必要な機能は、図２１のＭＡＣ生成タイミング決定部３４の比較部３４３があれば足りる。この方式では、過去に送信したデータの値は不要であるため、前回データ保持部３４１及び減算部３４２は設ける必要がない。

図２４は、値が閾値を超えたとき、または下回ったときにＭＡＣを生成・送信する方式における、ＭＡＣ生成タイミング決定部３４によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。比較部３４３は、データフィールド抽出部３３から渡される今回送信すべきデータの値と閾値を比較する（Ｓ６０）。閾値を超えるときにＭＡＣを生成・送信する設定の場合（Ｓ６１１のＹ）、ステップＳ６１２に遷移する。閾値を下回るときにＭＡＣを生成・送信する設定の場合（Ｓ６１１のＮ）、ステップＳ６１３に遷移する。

ステップＳ６１２にて、今回送信すべきデータの値が当該閾値を超える場合（Ｓ６１２のＹ）、比較部３４３はＭＡＣ生成部３５にＭＡＣの生成を指示する。ＭＡＣ生成部３５は、ＣＡＮＩＤ抽出部３２及びデータフィールド抽出部３３により抽出されたＣＡＮＩＤ及びデータをもとにＭＡＣを生成する（Ｓ６２）。ステップＳ６１２にて、今回送信すべきデータの値が当該閾値以下の場合（Ｓ６１２のＮ）、ステップＳ６２の処理はスキップされる。

ステップＳ６１３にて、今回送信すべきデータの値が当該閾値を下回る場合（Ｓ６１３のＹ）、比較部３４３はＭＡＣ生成部３５にＭＡＣの生成を指示する。ＭＡＣ生成部３５は、ＣＡＮＩＤ抽出部３２及びデータフィールド抽出部３３により抽出されたＣＡＮＩＤ及びデータをもとにＭＡＣを生成する（Ｓ６２）。ステップＳ６１にて、今回送信すべきデータの値が当該閾値以上の場合（Ｓ６１３のＮ）、ステップＳ６２の処理はスキップされる。

次に、データ変化に起因してタイミングを決定するグループの第４の例として、データによって示される値の変化が規定した方向への変化のときＭＡＣを生成・送信する方式を説明する。例えば、データの値が減少する場合はＭＡＣを生成・送信せず、増加する場合にＭＡＣを生成・送信する。この例は、データの値が減少する方向への変化が安全サイドへの変化であり、データの値が増加する方向への変化がリスクサイドへの変化である例である。リスクサイドの方向に値が変化するデータに対してのみＭＡＣを生成・送信することにより、セキュリティの確保と負荷軽減のバランスを図ることができる。

値の変化が規定した方向への変化のときＭＡＣを生成・送信する方式にて、メッセージ処理部３０のＭＡＣ生成タイミング決定部３４に必要な機能は、図１７のＭＡＣ生成タイミング決定部３４の機能と同じである。

図２５は、値の変化が規定した方向への変化のときＭＡＣを生成・送信する方式における、ＭＡＣ生成タイミング決定部３４によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。前回データ保持部３４１には、前回のメインメッセージで送信されたデータの値が保持される。比較部３４３は、前回データ保持部３４１に保持されるデータの値と、データフィールド抽出部３３から渡される今回送信すべきデータの値を比較する（Ｓ５０）。値の変化が増加方向への変化のときＭＡＣを生成・送信する設定の場合（Ｓ５１１のＹ）、ステップＳ５１２に遷移する。値の変化が減少方向への変化のときＭＡＣを生成・送信する設定の場合（Ｓ５１１のＮ）、ステップＳ５１３に遷移する。

ステップＳ５１２にて、保持されるデータの値が今回送信すべきデータの値を超える場合（Ｓ５１２のＹ）、比較部３４３はＭＡＣ生成部３５にＭＡＣの生成を指示する。ＭＡＣ生成部３５は、ＣＡＮＩＤ抽出部３２及びデータフィールド抽出部３３により抽出されたＣＡＮＩＤ及びデータをもとにＭＡＣを生成する（Ｓ５２）。前回データ保持部３４１内の保持データは、今回送信されたデータに更新される（Ｓ５３）。ステップＳ５１２にて、保持されるデータの値が今回送信すべきデータの値以下の場合（Ｓ５１２のＮ）、ステップＳ５２及びステップＳ５３の処理はスキップされる。

ステップＳ５１３にて、保持されるデータの値が今回送信すべきデータの値以下の場合（Ｓ５１３のＹ）、比較部３４３はＭＡＣ生成部３５にＭＡＣの生成を指示する。ＭＡＣ生成部３５は、ＣＡＮＩＤ抽出部３２及びデータフィールド抽出部３３により抽出されたＣＡＮＩＤ及びデータをもとにＭＡＣを生成する（Ｓ５２）。前回データ保持部３４１内の保持データは、今回送信されたデータに更新される（Ｓ５３）。ステップＳ５１３にて、保持されるデータの値が今回送信すべきデータの値を超える場合（Ｓ５１３のＮ）、ステップＳ５２及びステップＳ５３の処理はスキップされる。

次に、データ変化に起因してタイミングを決定するグループの第５の例として、データによって示される値がデフォルト値と異なるときＭＡＣを生成・送信する方式を説明する。例えば、データの値がデフォルト値以外をとる場合、常にＭＡＣを生成・送信する。通常、デフォルト値は最も安全サイドの値に設定されている。従ってデータの値がデフォルト値をとる場合、負荷軽減を優先して当該データに対するＭＡＣの生成・送信を省略する。

値がデフォルト値と異なるときＭＡＣを生成・送信する方式にて、メッセージ処理部３０のＭＡＣ生成タイミング決定部３４に必要な機能は、図２１のＭＡＣ生成タイミング決定部３４の比較部３４３があれば足りる。この方式では、過去に送信したデータの値は不要であるため、前回データ保持部３４１及び減算部３４２は設ける必要がない。なお比較部３４３には閾値ではなく、デフォルト値が入力される。

図２６は、値がデフォルト値と異なるときＭＡＣを生成・送信する方式における、ＭＡＣ生成タイミング決定部３４によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。比較部３４３は、データフィールド抽出部３３から渡される今回送信すべきデータの値とデフォルト値を比較する（Ｓ６０ａ）。今回送信すべきデータの値と当該デフォルト値が異なる場合（Ｓ６１ａのＹ）、比較部３４３はＭＡＣ生成部３５にＭＡＣの生成を指示する。ＭＡＣ生成部３５は、ＣＡＮＩＤ抽出部３２及びデータフィールド抽出部３３により抽出されたＣＡＮＩＤ及びデータをもとにＭＡＣを生成する（Ｓ６２）。ステップＳ６１ａにて、今回送信すべきデータの値が当該デフォルト値と同じ場合（Ｓ６１ａのＮ）、ステップＳ６２の処理はスキップされる。

次に、送信周期性に起因してタイミングを決定するグループの第１の例として、間引き周期でＭＡＣを生成・送信する方式を説明する。例えば、メインメッセージの送信周期よりも長い周期でＭＡＣを生成・送信する。ＭＡＣを生成・送信する回数を単純に減らすことができる。

図２７は、間引き周期でＭＡＣを生成・送信する方式にて、メッセージ処理部３０のＭＡＣ生成タイミング決定部３４に必要な機能を示すブロック図である。図２７のＭＡＣ生成タイミング決定部３４は、ＭＡＣ送信時刻保持部３４４、時計部３４５、経過時間算出部３４６及び比較部３４７を含む。

図２８は、図２７のＭＡＣ生成タイミング決定部３４によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。ＭＡＣ送信時刻保持部３４４には、前回のＭＡＣメッセージの送信時刻が保持される。経過時間算出部３４６は、ＭＡＣ送信時刻保持部３４４に保持される前回のＭＡＣメッセージの送信時刻と、時計部３４５から供給される現在の時刻をもとに、前回のＭＡＣメッセージの送信時刻からの経過時間を算出する（Ｓ７０）。比較部３４７は、算出された経過時間と設定周期を比較し（Ｓ７１）、算出された経過時間が当該設定周期を超える場合（Ｓ７１のＹ）、ＭＡＣ生成部３５にＭＡＣの生成を指示する。ＭＡＣ生成部３５は、ＣＡＮＩＤ抽出部３２及びデータフィールド抽出部３３により抽出されたＣＡＮＩＤ及びデータをもとにＭＡＣを生成する（Ｓ７２）。ＭＡＣ生成部３５は、生成したＭＡＣをＭＡＣメッセージ生成部３６に渡す。ＭＡＣメッセージ生成部３６は、ＭＡＣ生成部３５から取得したＭＡＣをＣＡＮメッセージのデータフィールドに格納してＭＡＣメッセージを生成する。ＭＡＣメッセージ生成部３６は、生成したＭＡＣメッセージを送受信部５０に渡し、送受信部５０は当該ＭＡＣメッセージをブロードキャスト送信する（Ｓ７３）。ＭＡＣ送信時刻保持部３４４内に保持されるＭＡＣの送信時刻は、今回送信されたＭＡＣメッセージのＭＡＣの送信時刻に更新される（Ｓ７４）。

ステップＳ７１にて、算出された経過時間が設定周期を超えない場合（Ｓ７１のＮ）、ステップＳ７２、ステップＳ７３及びステップＳ７４の処理はスキップされる。上記の設定周期は、メインメッセージの送信周期より長い周期に設定される。例えば、メインメッセージの送信周期の整数倍の値に設定される。

図２９は、間引き周期でＭＡＣを生成・送信する方式の具体例を示す図である。図２９ではメインメッセージの送信周期が２０ｍｓ、上記の設定周期が２００ｍｓに設定された例を示している。先頭のメインメッセージＭ１に対するＭＡＣメッセージが送信された時刻から２００ｍｓが経過した時点のメインメッセージＭｎに対して、ＭＡＣメッセージが生成・送信される。先頭のメインメッセージＭ１に対するＭＡＣメッセージが送信された時刻から２００ｍｓが経過する前に生成されるメインメッセージＭ２、メインメッセージＭ３、・・・、メインメッセージＭ（ｎ−１）に対するＭＡＣメッセージの生成・送信は間引かれる。

次に、送信周期に起因してタイミングを決定するグループの第２の例として、メッセージの送信周期の変化に応じてＭＡＣを生成・送信する方式を説明する。ＥＣＵによっては、メッセージの送信周期が切り替わるものがある。これは、短周期または長周期といった現在の送信周期の情報をＥＣＵの内部で管理している。送信周期の情報は、アプリケーション処理部１０から現在の送信周期の情報を送信周期情報として取得する。このように、送信周期が変化するというメッセージ（データ）の性質に基づいて、次のように制御する。例えば、周期が変化するメインメッセージの現在の周期に応じて、ＭＡＣの生成・送信頻度を変化させる。例えば、メインメッセージの現在の周期が短周期の場合、ＭＡＣの生成・送信を間引く。一方、メインメッセージの現在の周期が長周期の場合、ＭＡＣの生成・送信を間引かない。メインメッセージの周期が短周期の場合、全てのメインメッセージに対してＭＡＣを生成・送信する必要性が低下するため、負荷軽減を優先してＭＡＣの生成・送信を間引く。

図３０は、周期変化に応じてＭＡＣを生成・送信する方式にて、メッセージ処理部３０のＭＡＣ生成タイミング決定部３４に必要な機能を示すブロック図である。図３０のＭＡＣ生成タイミング決定部３４は、図２７のＭＡＣ生成タイミング決定部３４の構成に、メインメッセージ送信周期判定部３４８が追加された構成である。

図３１は、図３０のＭＡＣ生成タイミング決定部３４によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。ＭＡＣ送信時刻保持部３４４には、前回のＭＡＣメッセージの送信時刻が保持される。メインメッセージ送信周期判定部３４８は、アプリケーション処理部１０から渡されるメインメッセージの送信周期情報をもとに、メインメッセージの現在の送信周期が短周期であるか長周期であるか判定する（Ｓ６９９）。メインメッセージの送信周期が２種類である場合、短いほうが短周期、長いほうが長周期とされる。

ステップＳ６９９にて、メインメッセージの現在の送信周期が短周期である場合（Ｓ６９９のＹ）、その後の処理は、図２８のステップＳ７０〜ステップＳ７４までの処理と同じ処理となる。即ち、間引き周期でＭＡＣメッセージが生成・送信される制御となる。

ステップＳ６９９にて、メインメッセージの現在の送信周期が長周期である場合（Ｓ６９９のＮ）、その後の処理は、図２８のステップＳ７２〜ステップＳ７４までの処理と同じ処理となる。即ち、全てのメインメッセージに対してＭＡＣメッセージが生成・送信される制御となる。

次に、送信周期性に起因してタイミングを決定するグループの第３の例として、イベント発生に応じてＭＡＣを生成・送信する方式を説明する。このように、イベントが発生した際に送信されるというメッセージ（データ）の性質に基づいて、次のように制御する。例えば、イベント発生に応じてメインメッセージが送信される場合、常にＭＡＣを生成・送信する。具体的には、ドライバーがヘッドライトをＯＮした場合などが該当する。イベント発生により送信されるデータは重要度が高いデータといえる。従ってセキュリティの確保を優先して当該データに対するＭＡＣを常に生成・送信する。

イベント発生に応じてＭＡＣを生成・送信する方式にて、メッセージ処理部３０のＭＡＣ生成タイミング決定部３４に必要な機能は、メインメッセージ生成部３１により生成されるメインメッセージに含まれるデータがイベント送信型のデータであるか否かを判定する機能があれば足りる。

図３２は、イベント発生に応じてＭＡＣを生成・送信する方式における、ＭＡＣ生成タイミング決定部３４によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。ＭＡＣ生成タイミング決定部３４は、ＣＡＮＩＤ抽出部３２により抽出されたＣＡＮＩＤ及び／又はデータフィールド抽出部３３から抽出されたデータから、今回送信すべきメインメッセージの種別を判定する（Ｓ８０）。今回送信すべきメインメッセージの種別がイベント送信型の場合（Ｓ８１のＹ）、ＭＡＣ生成タイミング決定部３４はＭＡＣ生成部３５にＭＡＣの生成を指示する。ＭＡＣ生成部３５は、ＣＡＮＩＤ抽出部３２及びデータフィールド抽出部３３により抽出されたＣＡＮＩＤ及びデータをもとにＭＡＣを生成する（Ｓ８２）。ステップＳ８１にて、今回送信すべきメインメッセージの種別がイベント送信型でない場合（Ｓ８１のＮ）、ステップＳ８２の処理はスキップされる。

次に、送信周期性に起因してタイミングを決定するグループの第４の例として、要求メッセージに応じてＭＡＣを生成・送信する方式を説明する。ここで、要求メッセージとは、あるＥＣＵから他のＥＣＵに対して何らかの情報を要求するためのメッセージである。要求メッセージを受信したＥＣＵはそれに対応するメインメッセージをＣＡＮバス２００へ送信する。このように、要求メッセージの応答として送信されるというメッセージ（データ）の性質に基づいて、次のように制御する。例えば、要求メッセージに応じてメインメッセージが送信される場合、常にＭＡＣを生成・送信する。具体的には、他のＥＣＵ１００から、自己のＥＣＵ１００で監視している計器の数値の取得要求があった場合などが該当する。要求メッセージに応じて送信されるデータは重要度が高いデータといえる。従ってセキュリティの確保を優先して当該データに対するＭＡＣを常に生成・送信する。

要求メッセージに応じてＭＡＣを生成・送信する方式にて、メッセージ処理部３０のＭＡＣ生成タイミング決定部３４に必要な機能は、メインメッセージ生成部３１により生成されるメインメッセージに含まれるデータがオンデマンド送信型のデータであるか否かを判定する機能があれば足りる。

図３３は、要求メッセージに応じてＭＡＣを生成・送信する方式における、ＭＡＣ生成タイミング決定部３４によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。ＭＡＣ生成タイミング決定部３４は、ＣＡＮＩＤ抽出部３２により抽出されたＣＡＮＩＤ及び／又はデータフィールド抽出部３３から抽出されたデータから、今回送信すべきメインメッセージの種別を判定する（Ｓ８０）。今回送信すべきメインメッセージの種別がオンデマンド送信型の場合（Ｓ８１ａのＹ）、ＭＡＣ生成タイミング決定部３４はＭＡＣ生成部３５にＭＡＣの生成を指示する。ＭＡＣ生成部３５は、ＣＡＮＩＤ抽出部３２及びデータフィールド抽出部３３により抽出されたＣＡＮＩＤ及びデータをもとにＭＡＣを生成する（Ｓ８２）。ステップＳ８１ａにて、今回送信すべきメインメッセージの種別がオンデマンド送信型でない場合（Ｓ８１ａのＮ）、ステップＳ８２の処理はスキップされる。

図１６に示したその他のグループの第１の例として、バス占有率に応じてＭＡＣを生成・送信する方式を説明する。例えば、バスの占有率を監視し、ＭＡＣの送信頻度を調整する。具体的には、自己のＥＣＵ１００から送信されるメッセージによるバスの占有率が閾値を超える場合、ＭＡＣを生成・送信しない。この方式では、バスのトラフィック量を的確に調整できる。

図３４は、バス占有率に応じてＭＡＣを生成・送信する方式にて、メッセージ処理部３０のＭＡＣ生成タイミング決定部３４に必要な機能を示すブロック図である。図３４のＭＡＣ生成タイミング決定部３４は、時計部３４５、バス占有率算出部３４９及び比較部３５０を含む。バス占有率はＣＡＮバス２００を流れるすべてのメッセージの送信頻度から計算する必要があるため、時計部３４５から得られる時間の情報とＣＡＮバス２００におけるメッセージの送信回数から、ある単位時間あたりの占有率を算出する。

図３５は、図３４のＭＡＣ生成タイミング決定部３４によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。バス占有率算出部３４９は送受信部５０から、ＣＡＮバス２００よりメッセージ（メインメッセージとＭＡＣメッセージを含む）が受信される度に受信情報を取得する。バス占有率算出部３４９は、取得したメッセージの受信情報からＣＡＮバス２００におけるメッセージの送信頻度を算出し、当該送信頻度と時計部３４５から供給される時間情報（時刻情報）、ＣＡＮバス２００の帯域をもとにバス占有率を算出する（Ｓ９０）。

比較部３５０は、算出されたバス占有率と閾値を比較し（Ｓ９１）、バス占有率が閾値を超える場合（Ｓ９１のＹ）、比較部３５０はＭＡＣ生成部３５にＭＡＣの生成を指示する。ＭＡＣ生成部３５は、ＣＡＮＩＤ抽出部３２及びデータフィールド抽出部３３により抽出されたＣＡＮＩＤ及びデータをもとにＭＡＣを生成する（Ｓ９２）。ステップＳ９１にて、バス占有率が閾値以下の場合（Ｓ９１のＮ）、ステップＳ９２の処理はスキップされる。

図１６に示したその他のグループの第２の例として、ランダムにＭＡＣを生成・送信する方式を説明する。例えば、ランダムなタイミングでＭＡＣを生成・送信する。なお送信側と受信側でタイミングの共有が必要となる。ランダムなタイミングでＭＡＣを生成・送信する場合、攻撃者からの不正な攻撃がされにくくなる効果がある。

図３６は、ランダムにＭＡＣを生成・送信する方式にて、メッセージ処理部３０のＭＡＣ生成タイミング決定部３４に必要な機能を示すブロック図である。図３６のＭＡＣ生成タイミング決定部３４は、カウント部３５１、乱数発生部３５２、次回ＭＡＣ送信カウント値保持部３５３及び比較部３５４を含む。カウント部３５１は、メインメッセージに対するＭＡＣの生成・送信時から、リセットされるまでカウントアップしていくカウンタを含む。乱数発生部３５２は、擬似乱数を発生させ次回ＭＡＣ送信カウント値保持部３５３に供給する。次回ＭＡＣ送信カウント値保持部３５３は、乱数発生部３５２から供給される擬似乱数値を、次回のＭＡＣの送信までのカウント値として保持する。

図３７は、図３６のＭＡＣ生成タイミング決定部３４によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。比較部３５４は、カウント部３５１の現在のカウント値と、次回ＭＡＣ送信カウント値保持部３５３に保持される次回のＭＡＣ送信までのカウント値とを比較する（Ｓ１００）。カウント部３５１の現在のカウント値が次回のＭＡＣ送信までのカウント値に到達した場合（Ｓ１０１のＹ）、比較部３５４はＭＡＣ生成部３５にＭＡＣの生成を指示する。ＭＡＣ生成部３５は、ＣＡＮＩＤ抽出部３２及びデータフィールド抽出部３３により抽出されたＣＡＮＩＤ及びデータをもとにＭＡＣを生成する（Ｓ１０２）。

乱数発生部３５２は、ＭＡＣ生成部３５からＭＡＣの生成が完了した旨の通知を受けると、新たに擬似乱数を発生させ、次回ＭＡＣ送信カウント値保持部３５３に供給する。これにより次回ＭＡＣ送信カウント値保持部３５３に保持される次回のＭＡＣの送信までのカウント値が更新される（Ｓ１０３）。またカウント部３５１は、ＭＡＣ生成部３５からＭＡＣの生成が完了した旨の通知を受けると、カウント値をリセットする（Ｓ１０４）。

ステップＳ１０１にて、カウント部３５１の現在のカウント値が次回のＭＡＣ送信までのカウント値に到達していない場合（Ｓ１０１のＮ）、カウント部３５１はカウント値をインクリメントする（Ｓ１０５）。なおステップＳ１０３にて発生させた擬似乱数値は、例えばＭＡＣメッセージのデータフィールドに含められて、ＣＡＮバス２００に接続された他のＥＣＵ１００に送信される。なおＭＡＣメッセージではなく、独立の制御メッセージに含められて送信されてもよい。

図１６に示したその他のグループの第３の例として、車両状態に応じてＭＡＣを生成・送信する方式を説明する。例えば高速走行中や、リプログラミング用のツールが接続されている最中は常にＭＡＣを生成・送信する。リスクが高い状態で生成されるデータは重要度が高いデータといえる。従ってセキュリティの確保を優先して当該データに対するＭＡＣを常に生成・送信する。

車両状態に応じてＭＡＣを生成・送信する方式にて、メッセージ処理部３０のＭＡＣ生成タイミング決定部３４に必要な機能は、車両情報を取得する機能があれば足りる。

図３８は、車両状態に応じてＭＡＣを生成・送信する方式における、ＭＡＣ生成タイミング決定部３４によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。ＭＡＣ生成タイミング決定部３４は、アプリケーション処理部１０から渡されるデータ、又はメインメッセージ生成部３１により受信されデータフィールド抽出部３３により抽出されたデータにより、例えば速度情報などの車両状態を取得する（Ｓ１１０）。

ＭＡＣ生成タイミング決定部３４は、取得した車両状態が、予め設定されたＭＡＣ送信が必要な車両状態であるか否か判定する（Ｓ１１１）。例えば、取得した速度が６０ｋｍ／ｈを超える場合、高速走行中であるとしてＭＡＣ送信が必要な車両状態と判定する。取得した車両状態が、当該ＭＡＣ送信が必要な車両状態である場合（Ｓ１１１のＹ）、ＭＡＣ生成タイミング決定部３４はＭＡＣ生成部３５にＭＡＣの生成を指示する。ＭＡＣ生成部３５は、ＣＡＮＩＤ抽出部３２及びデータフィールド抽出部３３により抽出されたＣＡＮＩＤ及びデータをもとにＭＡＣを生成する（Ｓ１１２）。ステップＳ１１１にて、取得した車両状態が、当該ＭＡＣ送信が必要な車両状態でない場合（Ｓ１１１のＮ）、ステップＳ１１２の処理はスキップされる。

以上説明したように本実施の形態によれば、ＭＡＣを生成・送信するタイミングを制御することにより、バス占有率の増加を抑制し、各ＥＣＵの処理負荷および消費電流を低減できる。送信すべきデータの特質（性質、重要度）に応じてＭＡＣを生成・送信するタイミングを決定することにより、バス及びＥＣＵの負荷増大を抑制しつつ、セキュリティを向上させることができる。

以上、本発明を実施の形態をもとに説明した。実施の形態は例示であり、それらの各構成要素や各処理プロセスの組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

例えば受信側ＥＣＵ１００において、ＭＡＣの検証に失敗した回数をカウントすることにより、あまりに多くの不正メッセージが送信されていた場合に、車両が正常に制御できる状態ではないと判断する機能を追加してもよい。

図３９は、ＭＡＣの検証に失敗した不正メッセージの数をカウントする機能を有するメッセージ処理部３０の構成を示すブロック図である。図３９のメッセージ処理部３０は、図６のメッセージ処理部３０の構成に、検証失敗回数保持部４９ａ及び異常判定部４９ｂが追加された構成である。

検証失敗回数保持部４９ａは、ＭＡＣ比較部４６によるＭＡＣの検証の累積失敗回数を保持する。具体的にはＭＡＣ比較部４６によるＭＡＣの検証が失敗する度にカウントアップしていく。異常判定部４９ｂは、検証失敗回数保持部４９ａに保持される失敗回数が設定値（例えば、１２８回）を超えたとき車両異常と判定する。車両異常と判定すると異常判定部４９ｂは、車両全体をフェイルセーフモードに移行させるためのデータを生成させるための指示信号をアプリケーション処理部１０に出力する。さらに運転者に異常を通知するためのデータを生成させるための指示信号をアプリケーション処理部１０に出力してもよい。

以上、本発明の実施の形態の説明において、送信すべき複数の通常データの内、一部の通常データに対するＭＡＣの生成および送信を省略することとして説明したが、他の形態として、送信すべき複数の通常データのすべてに対してＭＡＣの生成を行い、かつ、生成したデータの特質に基づいて一部のＭＡＣの送信を省略する形態としてもよい。

本発明の一態様の概要は、次の通りである。本発明のある態様の送信装置は、ブロードキャスト送信すべきデータを生成する第１生成部と、前記第１生成部において生成したデータを少なくとも対象としたメッセージ認証コードを生成する第２生成部と、前記第１生成部において生成したデータと、前記第２生成部において生成したメッセージ認証コードをブロードキャスト送信する送信部と、を備える。前記第２生成部は、前記第１生成部において生成される複数のデータの内、一部のデータに対するメッセージ認証コードの生成を省略する。「第１生成部」は図３のアプリケーション処理部１０であってもよい。「第２生成部」は図４のＭＡＣ生成部３５であってもよい。「送信部」は図３の送受信部５０であってもよい。

この態様によると、一部のデータに対するメッセージ認証コードの生成を省略することにより、一定レベルのセキュリティを確保しつつ、ＣＡＮ及びＣＡＮに接続された装置の負荷を軽減できる。

前記第２生成部は、前記第１生成部において生成したデータの特質（性質および重要度の少なくともいずれか一方）に基づき、前記メッセージ認証コードを生成するか否か決定してもよい。これによれば、重要度の高いデータに対するメッセージ認証コードを生成し、重要度の低いデータに対するメッセージ認証コードの生成を省略することができる。あるいは、データの性質に対応して適切にメッセージ認証コードの生成を省略することができる。従ってセキュリティの確保と負荷軽減を効率よく実現できる。

前記第２生成部は、前記第１生成部において生成したデータが変化した場合にメッセージ認証コードを生成し、それ以外の場合にメッセージ認証コードの生成を省略してもよい。データが変化した場合、そのデータは重要度が高いデータといえる。従って重要度の高いデータに対するメッセージ認証コードを生成し、重要度の低いデータに対するメッセージ認証コードの生成を省略することになり、セキュリティの確保と負荷軽減を効率よく実現できる。

前記第２生成部は、前記第１生成部において生成したデータによって示される値の変化量が閾値を超えている場合にメッセージ認証コードを生成し、それ以外の場合にメッセージ認証コードの生成を省略してもよい。データによって示される値の変化が閾値を超えいている場合、そのデータは重要度が高いデータといえる。従って重要度の高いデータに対するメッセージ認証コードを生成し、重要度の低いデータに対するメッセージ認証コードの生成を省略することになり、セキュリティの確保と負荷軽減を効率よく実現できる。なお当該閾値は、設計者により実験、シミュレーション、又は経験則などに基づき導かれた値に設定される。

前記第２生成部は、前記第１生成部において生成したデータによって示される値が閾値を超える場合にメッセージ認証コードを生成し、それ以外の場合にメッセージ認証コードの生成を省略してもよい。データによって示される値が閾値を超えている場合、そのデータは重要度が高いデータといえる。従って重要度の高いデータに対するメッセージ認証コードを生成し、重要度の低いデータに対するメッセージ認証コードの生成を省略することになり、セキュリティの確保と負荷軽減を効率よく実現できる。なお当該閾値は、設計者により実験、シミュレーション、又は経験則などに基づき導かれた値に設定される。

本発明の別の態様は、受信装置である。この装置は、送信装置がブロードキャスト送信した、データ及び前記データを少なくとも対象としたメッセージ認証コードを受信する受信部と、前記受信部において受信したデータ及びメッセージ認証コードを処理する処理部と、を備える。前記受信部において受信される複数のデータの内、一部のデータに対するメッセージ認証コードの生成が、前記送信装置において省略されている。「受信部」は図３の送受信部５０であってもよい。「処理部」は図３のアプリケーション処理部１０及びメッセージ処理部３０であってもよい。

この態様によると、一部のデータに対するメッセージ認証コードの検証を省略することができ、一定レベルのセキュリティを確保しつつ、ＣＡＮ及びＣＡＮに接続された装置の負荷を軽減できる。

本発明のさらに別の態様は、送信方法である。この方法は、ブロードキャスト送信すべきデータを生成する第１ステップと、前記第１ステップにおいて生成したデータを少なくとも対象としたメッセージ認証コードを生成する第２ステップと、前記第１ステップにおいて生成したデータと、前記第２ステップにおいて生成したメッセージ認証コードをブロードキャスト送信する第３ステップと、を備える。前記第２ステップは、前記第１ステップにおいて生成される複数のデータの内、一部のデータに対するメッセージ認証コードの生成を省略する。

この態様によると、一部のデータに対するメッセージ認証コードの生成を省略することにより、一定レベルのセキュリティを確保しつつ、ＣＡＮ及びＣＡＮに接続された装置の負荷を軽減できる。

本発明のさらに別の態様は、受信方法である。この方法は、送信装置がブロードキャスト送信した、データ及び前記データを少なくとも対象としたメッセージ認証コードを受信する第１ステップと、前記第１ステップにおいて受信したデータ及びメッセージ認証コードを処理する第２ステップと、を備える。前記第１ステップにおいて受信される複数のデータの内、一部のデータに対するメッセージ認証コードの生成が、前記送信装置において省略されている。

この態様によると、一部のデータに対するメッセージ認証コードの検証を省略することができ、一定レベルのセキュリティを確保しつつ、ＣＡＮ及びＣＡＮに接続された装置の負荷を軽減できる。

５００ ＣＡＮシステム、 １００ ＥＣＵ、 ２００ ＣＡＮバス、 １０ アプリケーション処理部、 ３０ メッセージ処理部、 ３１ メインメッセージ生成部、 ３２ ＣＡＮＩＤ抽出部、 ３３ データフィールド抽出部、 ３４ ＭＡＣ生成タイミング決定部、 ３４１ 前回データ保持部、 ３４２ 減算部、 ３４３ 比較部、 ３４４ ＭＡＣ送信時刻保持部、 ３４５ 時計部、 ３４６ 経過時間算出部、 ３４７ 比較部、 ３４８ メインメッセージ送信周期判定部、 ３４９ バス占有率算出部、 ３５０ 比較部、 ３５１ カウント部、 ３５２ 乱数発生部、 ３５３ 次回ＭＡＣ送信カウント値保持部、 ３５４ 比較部、 ３５ ＭＡＣ生成部、 ３５ａ 共通鍵、 ３６ ＭＡＣメッセージ生成部、 ４１ メッセージ解析部、 ４２ ＣＡＮＩＤ抽出部、 ４３ データフィールド抽出部、 ４３ａ 分離部、 ４４ ＭＡＣ検証タイミング決定部、 ４５ ＭＡＣ生成部、 ４５ａ 共通鍵、 ４６ ＭＡＣ比較部、 ４７ データ受渡部、 ４８ メインメッセージ一時保持部、 ４９ａ 検証失敗回数保持部、 ４９ｂ 異常判定部、 ５０ 送受信部。

本発明は、ＣＡＮに利用可能である。

Claims (2)

1. プロセッサが、
   ブロードキャスト送信すべきデータを生成し、
   前記生成したデータを少なくとも対象としたメッセージ認証コードを生成させるか否か判定し、
   前記判定の結果に応じて、前記生成したデータを少なくとも対象としたメッセージ認証コードを生成し、
   前記生成したデータおよび前記生成したメッセージ認証コードのうち少なくともいずれか一方をブロードキャスト送信し、
   前記ブロードキャスト送信されたデータをメモリに保持する、送信方法であって、
   初回は前記メモリに保持されているデフォルト値と、今回送信されたデータとを比較することで、２回目以降は前記メモリに保持されている前回送信されたデータと、今回送信されたデータとを比較することで、前記今回送信されるデータが変化したことが検知された場合、メッセージ認証コードを生成させると判定し、それ以外の場合、メッセージ認証コードを生成させないと判定する、
   送信方法。
2. プロセッサが、
   ブロードキャスト送信すべきデータを生成し、
   前記生成したデータを少なくとも対象としたメッセージ認証コードを生成させるか否か判定し、
   前記判定の結果に応じて、前記生成したデータを少なくとも対象としたメッセージ認証コードを生成し、
   前記生成したデータおよび前記生成したメッセージ認証コードのうち少なくともいずれか一方をブロードキャスト送信し、
   前記ブロードキャスト送信されたデータをメモリに保持する、送信方法であって、
   初回は前記メモリに保持されているデフォルト値に対する今回送信されるデータの第一変化量と閾値とを比較した結果前記第一変化量が前記閾値を超える場合、２回目以降は前記メモリに保持されている前回送信されたデータに対する前記今回送信されるデータの第二変化量と前記閾値とを比較した結果前記第二変化量が前記閾値を超える場合、メッセージ認証コードを生成させると判定し、それ以外の場合、メッセージ認証コードを生成させないと判定する、
   送信方法。

Images