通信システムにおけるメッセージ認証方法および通信システム
【課題】ＣＡＮプロトコルを変更せずにＭＡＣによるメッセージ認証を行う。
【解決手段】各ＥＣＵにおいてＣＡＮＩＤごとにメッセージが送信された回数をカウントする。メインメッセージを送信した送信ノードは、メインメッセージのデータフィールドおよびＣＡＮＩＤと、ＣＡＮＩＤに対応するカウンタ値とからＭＡＣを生成して、ＭＡＣメッセージとして送信する。メインメッセージを受信した受信ノードは、メインメッセージに含まれるデータフィールドおよびＣＡＮＩＤと、ＣＡＮＩＤに対応するカウンタ値とからＭＡＣを生成して、ＭＡＣメッセージに含まれるＭＡＣと一致するか判断する。これにより、メインメッセージが正当なものであるか否か検証できる。
【解決手段】各ＥＣＵにおいてＣＡＮＩＤごとにメッセージが送信された回数をカウントする。メインメッセージを送信した送信ノードは、メインメッセージのデータフィールドおよびＣＡＮＩＤと、ＣＡＮＩＤに対応するカウンタ値とからＭＡＣを生成して、ＭＡＣメッセージとして送信する。メインメッセージを受信した受信ノードは、メインメッセージに含まれるデータフィールドおよびＣＡＮＩＤと、ＣＡＮＩＤに対応するカウンタ値とからＭＡＣを生成して、ＭＡＣメッセージに含まれるＭＡＣと一致するか判断する。これにより、メインメッセージが正当なものであるか否か検証できる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信システムにおけるメッセージ認証技術に関する。
【背景技術】
【０００２】
車載ネットワークとしてＣＡＮ（Controller Area Network）が採用されている。この
ＣＡＮにはＯＢＤ２ポートと呼ばれる診断用のポートが設けられており、ネットワーク上を流れるメッセージを受信したり、ネットワーク上にメッセージを送信したりすることができる。
【０００３】
ＯＢＤ２ポートはメッセージのフィルタリング処理などを行わない直づけのインタフェースであるため、ＯＢＤ２ポートに不正機器が接続された場合は、リプレイ攻撃が行われる危険性がある。ここで述べるリプレイ攻撃とは、ネットワーク上を流れるメッセージを盗聴してその内容を記憶しておき、記憶したメッセージを再送することで不正な動作を引き起こす攻撃とする。なお、不正機器はメッセージの内容が分からなくても、メッセージ送信後の車両の挙動が分かれば、そのメッセージの意図も把握できる。
【０００４】
このようなリプレイ攻撃を防ぐ技術として、ＣＡＮメッセージにメッセージ認証コード（ＭＡＣ）を埋め込む技術が提案されている（非特許文献１）。この提案では、図１１に示すように、Ｎ番目からＮ＋３番目の４つのＣＡＮメッセージに含まれるデータフィールド（６４×４＝２５６ビット）から６４ビットのＭＡＣを生成し、１６ビットずつに４分割して、Ｎ＋４番目からＮ＋７番目の４つのＣＡＮメッセージのＣＲＣフィールド（１６ビット）に埋め込んで送信している。
【０００５】
受信側では、Ｎ＋４番目からＮ＋７番目のＣＡＮメッセージのＣＲＣフィールドからＭＡＣを取得し、Ｎ番目からＮ＋３番目のデータフィールドから生成されるＭＡＣと一致するか否かによってＮ番目からＮ＋３番目のＣＡＮメッセージが正当であるか判断する。ＣＲＣフィールドから得られるＭＡＣと、データフィールドから算出されるＭＡＣが異なる場合は、Ｎ番目からＮ＋３番目のＣＡＮメッセージのいずれかが不正であることが判断できる。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】D. K. Nilsson, U. E. Larson, E. Jonsson, "Efficient In-Vehicle Delayed Data Authentication Based on Compound Message Authentication Codes", IEEE 68th VTC 2008-Fall, 2008, 1-5.
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、非特許文献１に示す方法では、以下のような問題がある。第１に、Ｎ番目のメッセージの正当性を検証するためにＮ＋７番目までのメッセージを受信する必要があるので、メッセージの検証に時間を要するという問題がある。
【０００８】
第２の問題点は、非特許文献１に示す方法は標準化されているＣＡＮのプロトコルを変更している点である。ＣＲＣフィールドは本来、データフィールド等のデータ内容の誤り検出のためのものである。ＣＡＮコントローラの処理をハードウェアによって実現している現状を考慮すると、プロトコルの変更は現実的ではない。したがって、この第２の問題点はより深刻なものである。
【０００９】
本発明は、ＣＡＮプロトコルに適用可能な方式でメッセージの認証を可能とする技術を提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明に係るメッセージ認証方法では、メインメッセージと、メインメッセージのメッセージ認証コード（Message Authentication Code: ＭＡＣ）を含むＭＡＣメッセージを
送信する。受信側では、メインメッセージから算出されるＭＡＣとＭＡＣメッセージに含まれるＭＡＣが一致すればメインメッセージが正当なものであり、不一致であれば不正なものであると判断できる。本発明においては、以下のようにしてＭＡＣを生成する点に特徴がある。
【００１１】
通信システム内の各ノードは、メインメッセージがネットワーク上を伝送する度にインクリメントするカウンタ値を記憶する。メインメッセージを送信するノードは、その送信に際してカウンタ値をインクリメントする。送信ノード以外は、ネットワーク上をメインメッセージが伝送したことを検知するとカウンタ値をインクリメントする。なお、カウンタ値の初期値は０である必要はなく任意であって良いが、各ノードで共通とする必要がある。また、インクリメントは、必ずしもカウンタ値を１ずつ増分させるものでなくても良い。各ノードが共通のルールに従ってカウンタ値を変化させる方式、すなわち全てのノードでカウンタ値が共通となる方式であれば、メインメッセージ送信の度に任意の方式に従ってカウンタ値を変化させる方式であっても構わない。
【００１２】
メインメッセージの送信ノードは、このカウンタ値を利用してＭＡＣメッセージに含めるＭＡＣを生成する。より具体的には、メインメッセージとカウンタ値に所定のアルゴリズムを適用してＭＡＣを生成する。この所定のアルゴリズムは、例えば共通鍵暗号による暗号アルゴリズムであったり、暗号鍵の事前共有を必要とする鍵付きハッシュ関数などであったりすることができる。なお、ＭＡＣを生成する際にメインメッセージの全データビットを利用する必要はなく、その一部のみとカウンタ値からＭＡＣを生成しても良い。
【００１３】
メインメッセージの受信ノードも同様に、受信したメインメッセージとカウンタ値に所定の暗号アルゴリズムを適用してＭＡＣを生成する。
【００１４】
このような本発明によると、ＣＡＮプロトコルに適用可能な方式で、ＭＡＣによってメインメッセージの正当性を検証することができる。たとえば、不正機器が以前に受信したメインメッセージと対応するＭＡＣメッセージを送信した場合であっても、再送時にはカウンタ値が変化しているため正しいＭＡＣも変化している。したがって、不正機器がリプレイ攻撃を行っても、受信ノードにおいてメインメッセージが不正であることを検知できる。
【００１５】
また、本発明では、メインメッセージは平文の状態でネットワーク上を伝送するため不正機器がメインメッセージを知ることができるが、カウンタ値はネットワーク上を伝送せず不正機器には未知である。したがって、メインメッセージおよびＭＡＣメッセージを盗聴しても、そこからＭＡＣを生成するための暗号アルゴリズムや暗号鍵を推測できないという利点もある。
【００１６】
本発明において、メインメッセージは、メッセージＩＤとデータフィールドを含むものであることができる。この場合、メインメッセージのカウンタ値は、メッセージＩＤごとに個別にカウントすることが好ましい。そして、ＭＡＣの生成は、メインメッセージに含まれるメッセージＩＤおよびデータフィールドと、このメッセージＩＤに対応するカウンタ値とに基づいて生成することが好ましい。なお、このような場合であってもデータフィ
ールドとカウンタ値のみからＭＡＣを生成しても構わない。
【００１７】
また、本発明において、ＭＡＣは、メッセージＩＤ、データフィールドおよびメッセージＩＤに対応するカウンタに共通鍵暗号アルゴリズムを作用させて生成されるビット列から、所定のビットを抽出して生成することが好ましい。この方式は、共通鍵暗号アルゴリズムから得られるビット列が、ＭＡＣメッセージに格納可能なビット数を超える場合に有効である。なお、ビットの抽出方法は、各ノードで共通していれば任意の方法であって良い。例えば、共通鍵暗号アルゴリズムから得られるビット列から、前半部分のビット列を抽出したり、後半部分のビット列を抽出したり、奇数番目のビット列を抽出したり、偶数番目のビット列を抽出したりすることができる。
【００１８】
また、本発明において、カウンタ値の初期化はマスタノードからの通知によって行うことが好ましい。すなわち、ネットワーク上の１つのノードがマスタノードとなって、各メッセージＩＤに対応するカウンタ値の初期値を、通信システム起動時にブロードキャストによって通知することが好ましい。
【００１９】
このようにすれば、各ノードが不揮発性のメモリを有していなくても、全てのノードでカウンタ値を同一とすることができる。
【００２０】
カウンタ値の初期化は、より具体的には、以下のようにして行うことが好ましい。すなわち、マスタノードは、メッセージＩＤごとに乱数値を生成して、ブロードキャスト送信する。各ノードは、ブロードキャスト送信された乱数値を取得して、この乱数値に対して共通鍵暗号アルゴリズムを作用させる。そして、得られた値をカウンタ値の初期値として採用する。
【００２１】
このようにすれば、カウンタ値の初期値が、ネットワーク上を直接流れることがないため、不正機器はどのような値でカウンタ値が初期化されたか知ることができない。初期値がわかれば、任意の時点におけるカウンタ値を知ることが可能となり、メインメッセージとＭＡＣメッセージから暗号鍵を解読することも可能となり得るが、カウンタの初期値を秘匿化することでこのような危険性も回避できる。
【００２２】
なお、本発明は、上記処理の少なくとも一部を含むメッセージ認証方法として捉えることができる。また、本発明は、この方法を実行するコンピュータプログラムとして捉えることもできる。また、本発明は、上記処理の少なくとも一部を実行する通信システムおよび、通信システムを構成する通信装置として捉えることができる。上記手段および処理の各々は可能な限り互いに組み合わせて本発明を構成することができる。
【発明の効果】
【００２３】
本発明によれば、ＣＡＮプロトコルに適用可能な方式でメッセージの認証が可能となる。
【図面の簡単な説明】
【００２４】
【図１】ＣＡＮプロトコルにおけるデータフレームのフォーマットを示す図。
【図２】本実施形態におけるメッセージ検証処理の概要を説明する図。
【図３】本実施形態におけるＭＡＣ算出方法の概要を説明する図。
【図４】本実施形態におけるＥＣＵの機能構成を示す図。
【図５】メッセージを送信するＥＣＵにおける各機能部の連携を示す図。
【図６】メインメッセージを送信するＥＣＵにおける処理の流れを示すフローチャート。
【図７】メッセージを受信するＥＣＵにおける各機能部の連携を示す図。
【図８】メインメッセージを受信するＥＣＵにおける処理の流れを示すフローチャート。
【図９】カウンタ初期化メッセージを受信するＥＣＵにおける各機能部の連携を示す図。
【図１０】（ａ）カウンタ初期化メッセージを送信するマスタノードにおける処理の流れを示すフローチャートと、（ｂ）カウンタ初期化メッセージを受信する一般ノードにおける処理の流れを示すフローチャート。
【図１１】非特許文献１におけるメッセージ検証方法を説明する図。
【発明を実施するための形態】
【００２５】
本実施形態の説明の前にＣＡＮ（Controller Area Network）プロトコルの概要につい
て説明する。ＣＡＮは相互接続された機器間のデータ伝送に用いられる通信プロトコルであり、例えば自動車内の各種ＥＣＵ（Electronic Control Unit）間の通信などに用いら
れる。
【００２６】
図１は、ＣＡＮに用いられるデータフレームのフォーマットを示した図である。データフレームは、ＣＡＮ ＩＤ（１０１）、データフィールド（１０２）、ＣＲＣフィールド（１０３）などを含む。図示した以外のフィールドについての説明は割愛する。ＣＡＮではＣＡＮ ＩＤを用いてメッセージのアドレッシングが行われる。すなわち、ＣＡＮ ＩＤによって、このメッセージがどのようなデータであるのかを示し、受信側はＣＡＮ ＩＤを参照して自ノードが処理する必要のあるデータか否かを判断する。データフィールドは（最大で）６４ビットのフィールドであり、この中にデータの内容が格納される。ＣＲＣフィールドは、データフィールドなどから計算されるＣＲＣコードが格納され、通信に伴うビット落ちを検出可能とする。
【００２７】
以上のように、ＣＡＮにおいては、メッセージに送信元や宛先を示すＩＤは付与されず、ＣＡＮ ＩＤによってデータの内容や受信ノードが指示される。
【００２８】
本実施形態では、ＣＡＮネットワークに本発明を適用して、メッセージの正当性検証を行う。以下、図面を参照しながら本実施形態について説明する。
【００２９】
（概要）
図２は、本発明の概要を示す図である。ネットワークに接続されたＥＣＵ間でデータを通信する場合には次のようにして行う。すなわち、通信すべきデータを含むメッセージ（以下、メインメッセージ）を送信した後に、メインメッセージのデータフィールドに対するＭＡＣ（メッセージ認証コード）を含むメッセージ（以下、ＭＡＣメッセージ）を送信する。ＭＡＣによるメッセージ認証自体は既知な仕組みであり、本実施形態においても、受信したメインメッセージのデータフィールドから得られるＭＡＣと受信したＭＡＣメッセージに含まれるＭＡＣが一致するか否かによって、受信側においてメインメッセージの正当性を検証する。
【００３０】
本実施形態においては、図３（Ａ）に示すように、それぞれのＥＣＵにおいて各ＣＡＮ
ＩＤのメッセージが送信された回数をカウントして記憶する。そして、図３（Ｂ）に示すように、メインメッセージのデータフィールドと、ＣＡＮ ＩＤと、このＣＡＮ ＩＤに対応するカウンタ値とを使ってＭＡＣを求める点に特徴がある。ＭＡＣの算出は、ハッシュ関数を使う方式（ＨＭＡＣ）や、ブロック暗号アルゴリズムを使う方式（ＣＭＡＣなど）の任意の既知の手法によって行えば良い。本実施形態では、共通鍵ブロック暗号の一つであるＡＥＳ暗号アルゴリズムによってＭＡＣを求める。ＡＥＳでは出力が少なくとも１２８ビットになるが、ＭＡＣが格納されるデータフィールドは６４ビットなので、１２８ビットの出力から所定の６４ビットを抽出してＭＡＣとして利用する。なお共通鍵暗号
アルゴリズムの中には６４ビットを出力可能なものも存在し、そのような共通鍵暗号アルゴリズムを採用する際には上記の抽出作業は不要である。
【００３１】
本実施形態においては、各ＥＣＵがそれぞれＣＡＮ ＩＤごとにメッセージ送信回数をカウントしているため、各ＣＡＮ ＩＤのカウンタ値は全ＥＣＵにおいて共通となる。したがって、受信側ＥＣＵにおいても、メインメッセージに含まれるデータフィールドとＣＡＮ ＩＤ、および自ノードが記憶しているカウンタ値からＭＡＣを求めることができる。そして、このようにして求めたＭＡＣとＭＡＣメッセージに含まれるＭＡＣが一致するか否かによって、メインメッセージの正当性を検証可能である。
【００３２】
本実施形態の効果を簡単に説明すると、第１にＣＡＮプロトコルを変更していないので、既存システムとの互換性があることを挙げられる。例えば、高速処理および低価格化を目的としてハードウェア化されているＣＡＮコントローラを利用することができる。第２に、メッセージ送信の度にカウンタ値が更新されるので、不正機器が以前に受信したメッセージをそのまま送信しても、受信側において不正なメッセージであることが検証可能である。第３に、カウンタ値がネットワーク上を流れないため、メインメッセージとＭＡＣメッセージを受信して暗号鍵を解読する試みも事実上不可能である。第４に、メインメッセージ送信直後に対応するＭＡＣメッセージを送信できるので、即座にメインメッセージの正当性検証が可能である。
【００３３】
（構成）
以下では、より詳細に本実施形態について説明する。図４は、本実施形態におけるＥＣＵが有する機能部を示す図である。ＥＣＵは、ＣＰＵ、ＲＡＭ、ＲＯＭ、センサやアクチュエータとのインタフェースなどから構成されており、ＲＯＭに格納されたプログラムをＣＰＵが実行することで、図４に示す各機能部が実現される。図４に示した機能部は、メッセージ送信およびメッセージ受信に必要な機能全てが示されており、処理内容に応じて適切な機能部が選択的に実行される。
【００３４】
なお、本実施形態において、全てのメッセージについてＭＡＣによるメッセージ認証を行う必要はない。すなわち、重要なメッセージについてのみメッセージ認証を行っても良い。そして、メッセージ認証が必要ないメッセージのみを送受信するＥＣＵについては、図４に示したようなメッセージ認証のための各機能部は不要である。
【００３５】
図４に示した各機能部の詳細については、メッセージ送受信処理とともに説明を行うが、いくつかの機能部については、ここで説明を加える。
【００３６】
暗号鍵記憶部５には、ＣＡＮネットワーク内で共通な暗号鍵（共通鍵）が記憶される。この暗号鍵は、外部に漏洩しないことが必要である。本実施形態では、ＡＥＳ暗号アルゴリズムを採用し鍵長は１２８ビットとする。もちろん、鍵長はより長くても良いし、ＡＥＳ以外の暗号アルゴリズムを採用しても構わない。
【００３７】
カウンタ記憶部３には、ＣＡＮ ＩＤごとにネットワーク上をメッセージが伝送された回数を表すカウンタ値が格納される。ＣＡＮはバス型アーキテクチャであるため、ネットワーク上を伝送されるメッセージを全てのＥＣＵが参照可能であり、各ＥＣＵにおいてカウンタの更新が可能である。なお、それぞれのＥＣＵは、自身が送受信する可能性があるＣＡＮ ＩＤについてのみカウンタを更新・記憶すれば十分である。
【００３８】
なお、本実施形態においてカウンタは５３ビットとする。これは、暗号アルゴリズムへの入力が１２８ビット必要なので、データフィールド（６４ビット）とＣＡＮ ＩＤ（１１ビット）と合わせて１２８ビットとするためである。ただし、暗号アルゴリズムへの入
力はパディングを行えば良いので、カウンタのビット数はこれより少なくても問題ない。例えば、ＣＡＮの仕様にしたがって２０年間継続的に最大限の速度でメッセージを送信したとしても、２４０個程度のメッセージしか送信できないので、カウンタ値は４０ビット程度としても良い。もちろんカウンタ値の繰り返しを許容しても良く、その場合はより少ないビット数であっても構わない。
【００３９】
（メッセージ送信時処理）
まず、メインメッセージを送信するＥＣＵが行う処理を、図５および図６を参照しつつ説明する。図５は、送信ＥＣＵにおける各機能部の連携を示す図である。図６は、メインメッセージ送信時の処理の流れを示すフローチャートである。
【００４０】
メインメッセージ生成部９は、ＣＡＮ ＩＤおよびデータフィールドを含むメインメッセージを生成してＣＡＮに送信する。図６のフローチャートには、メインメッセージを送信した後の処理の流れが示されている。メインメッセージを送信すると、ＣＡＮ ＩＤ抽出部６がメインメッセージ生成部９から送信したメインメッセージのＣＡＮ ＩＤを抽出する（Ｓ１０１）。ＣＡＮ ＩＤ抽出部６は、メインメッセージのＣＡＮ ＩＤに対応するカウンタ値をカウンタ記憶部３から読み取り（Ｓ１０２）、カウンタを１つ増加させてカウンタ記憶部３を更新する（Ｓ１０３）。抽出されたＣＡＮ ＩＤおよび更新後のカウンタ値は、ＭＡＣ生成部４に送られる。
【００４１】
また、データフィールド抽出部７は、メインメッセージ生成部９が送信したメインメッセージのデータフィールドを抽出する（Ｓ１０４）。抽出されたデータフィールドは、ＭＡＣ生成部４に送られる。
【００４２】
ＭＡＣ生成部４は、暗号鍵記憶部５から暗号鍵（共通鍵）を取り出し（Ｓ１０５）、この暗号鍵を用いて、ＣＡＮ ＩＤ、最新のカウンタ値、送信済みのデータフィールドからＭＡＣを生成する（Ｓ１０６）。なお、上述したように本実施形態ではＡＥＳを採用しているため暗号アルゴリズムの出力は１２８ビットであるが、ＣＡＮのデータフレームが送れるデータフィールドは６４ビットである。したがって、システム内で共通するルールに従って出力の１２８ビットから６４ビットを抽出する。例えば、前半６４ビットや後半６４ビットを採用しても良いし、奇数ビットや偶数ビットを採用しても良い。さらには、ＣＡＮ ＩＤが奇数か偶数かによって、前半６４ビットを採用するか後半６４ビットを採用するか、あるいは奇数ビットを採用するか偶数ビットを採用するかなどを決めても構わない。
【００４３】
ＭＡＣ生成部４が生成したＭＡＣはＭＡＣメッセージ生成部１へ送られ（Ｓ１０７）、ＭＡＣメッセージ生成部１がＭＡＣをＣＡＮメッセージ（ＭＡＣメッセージ）に加工してＣＡＮに送信する。すなわち、計算された６４ビットのＭＡＣがＭＡＣメッセージのデータフィールドに格納される。また、ＭＡＣメッセージのＣＡＮ ＩＤは、メインメッセージのＣＡＮ ＩＤに対応するＩＤが用いられる。メインメッセージとＭＡＣメッセージのＣＡＮ ＩＤの対応によって、受信側ＥＣＵでは、ＭＡＣメッセージを受信した場合に対応するＣＡＮ ＩＤを有するメインメッセージに対するＭＡＣであることが把握できる。
【００４４】
（メッセージ受信時処理）
次に、メインメッセージを受信してその検証を行うＥＣＵの処理を、図７および図８を参照しつつ説明する。図７は、受信ＥＣＵにおける各機能部の連携を示す図である。図８は、メインメッセージ受信時の処理の流れを示すフローチャートである。
【００４５】
ＥＣＵがメインメッセージを受信すると、ＣＡＮ ＩＤ抽出部６がＣＡＮメッセージ解析部８を経由して、受信したメインメッセージのＣＡＮ ＩＤを抽出する（Ｓ２０１）。
なお、ＣＡＮ ＩＤごとにメッセージの内容が規定されているため、ＣＡＮ ＩＤを参照することでそのメッセージがＭＡＣによる認証を必要とするものか否かも判断できる。受信したメインメッセージがＭＡＣによる認証を必要としないものであれば、以下の処理は行う必要がない。また、受信したメッセージが自ノードで処理する必要がないものである場合も、以下の処理を行う必要がない。
【００４６】
受信したメインメッセージは自ノードが処理する必要があるものであり、かつＭＡＣによるメッセージ認証が行われるものであると、抽出したＣＡＮ ＩＤから判断される場合には以下の処理が行われる。ＣＡＮ ＩＤ抽出部６は、抽出したＣＡＮ ＩＤに対応するカウンタ値をカウンタ記憶部３から読み取り（Ｓ２０２）、カウンタを１つ増加させてカウンタ記憶部３を更新する（Ｓ２０３）。抽出されたＣＡＮ ＩＤおよび更新後のカウンタ値は、ＭＡＣ生成部４に送られる。
【００４７】
また、データフィールド抽出部７は、ＣＡＮメッセージ解析部８を経由して、受信したメインメッセージのデータフィールドを抽出する（Ｓ２０４）。抽出されたデータフィールドは、ＭＡＣ生成部４に送られる。
【００４８】
ＭＡＣ生成部４は、暗号鍵記憶部５から暗号鍵（共通鍵）を取り出し（Ｓ２０５）、この暗号鍵を用いて、受信したメッセージのデータフィールド、ＣＡＮ ＩＤおよびＣＡＮ
ＩＤに対応する最新のカウンタ値からＭＡＣを生成する（Ｓ２０６）。ＭＡＣの生成方法は、メッセージ送信の際の方法と同じであるため詳細な説明は省略する。ＭＡＣ生成部４が生成したＭＡＣは、ＭＡＣ比較部２へと送られる（Ｓ２０７）。
【００４９】
受信側ＥＣＵは、メインメッセージに対応するＭＡＣメッセージをＣＡＮメッセージ解析部８が受信するのを待つ（Ｓ２０８〜Ｓ２０９）。上述のように、メインメッセージとそのＭＡＣメッセージとはＣＡＮ ＩＤが対応付けられているので、ＣＡＮメッセージ解析部８は、メインメッセージのＣＡＮ ＩＤに対応するＣＡＮ ＩＤを有するメッセージが到着するのを待つ。
【００５０】
メインメッセージに対応するＭＡＣメッセージが到着すると（Ｓ２０９−ＹＥＳ）、データフィールド抽出部７が、ＣＡＮメッセージ解析部８を経由して、ＭＡＣメッセージからＭＡＣを抽出する（Ｓ２１１）。上述したように、ＭＡＣはＭＡＣメッセージのデータフィールド（６４ビット）に格納されている。データフィールド抽出部７が抽出したＭＡＣは、ＭＡＣ比較部２へと送られる（Ｓ２１２）。
【００５１】
ＭＡＣ比較部２は、ＭＡＣ生成部４が生成したＭＡＣと、受信したＭＡＣメッセージから抽出されたＭＡＣとを比較する（Ｓ２１３）。これら２つのＭＡＣが同じであれば（Ｓ２１４−ＹＥＳ）、メインメッセージが正当なものであることが分かるので、受信ＥＣＵはメインメッセージを処理する（Ｓ２１６）。一方、これら２つのＭＡＣが異なるものであれば（Ｓ２１４−ＮＯ）、メインメッセージが不正なものであることが分かるので、受信ＥＣＵはメインメッセージを処理しない（Ｓ２１５）。なお、不正なメインメッセージを受信した後の処理は種々考えられるが、どのような対応を行っても構わない。
【００５２】
（カウンタ初期化処理）
次に、ＣＡＮ ＩＤごとのカウンタ値の初期化について説明する。カウンタ値はシステム内の全ＥＣＵで共通することが必要である。システム起動中はネットワークを伝送されるメッセージをカウントすることで全ＥＣＵにてカウンタを同一とすることができるが、システム起動時においてもカウンタ値を一致させる必要がある。このために、全ＥＣＵに読み書き可能な不揮発性メモリを設け、電源オフ時のカウンタ値を記憶し、システム再開時にこの不揮発性メモリからカウンタ値を読み込んで使用することが考えられる。しかし
ながら、本実施形態では、全ＥＣＵに不揮発性メモリを設けずにシステム開始時のカウンタ値を、以下のようにして一致させる。
【００５３】
本実施形態においては、カウンタの初期化処理のために、ネットワーク内の任意のＥＣＵをカウンタ初期化用のＥＣＵ（以下、マスタノードともいう）として利用する。マスタノードは、システム開始時に全てのＣＡＮ ＩＤ（メッセージ認証が必要なメッセージに対応するＣＡＮ ＩＤという意味。以下同じ。）についてカウンタ値の初期値を全ＥＣＵに通知する処理を行う。
【００５４】
図９は、マスタノードからカウンタ値の初期化メッセージを受信した際の、一般ノードの各機能部の連携を示した図である。図１０（ａ）は、カウンタ値の初期化メッセージを送信するマスタノードの処理の流れを示すフローチャートである。図１０（ｂ）は、初期化メッセージを受信した一般ノードの処理の流れを示すフローチャートである。
【００５５】
まず、マスタノードが行う処理について図１０（ａ）を参照して説明する。マスタノードは、システムが起動すると、ＣＡＮ ＩＤを選択して（Ｓ３０１）、そのＣＡＮ ＩＤのカウンタ初期値を決定するための乱数を発生させる（Ｓ３０２）。そして、カウンタを初期化するＣＡＮ ＩＤと関連づけて、カウンタ初期化メッセージとしてこの乱数を送信する（Ｓ３０３）。マスタノードでは、全てのＣＡＮ ＩＤについて、このようなカウンタ初期化メッセージを送信する。
【００５６】
次に、一般ノードが行う処理を図９および図１０（ｂ）を参照して説明する。一般ノードは、カウンタ初期化メッセージを受信した場合に（Ｓ３１１）、そのメッセージが自ノードで送受信する（すなわち、カウンタ値を記憶する必要がある）ＣＡＮ ＩＤに対するカウンタ初期化メッセージであれば以下の処理を行う。
【００５７】
データフィールド抽出部７が、カウンタ初期化メッセージのデータフィールドから、マスタノードが生成した乱数値を取得する（Ｓ３１２）。そして、この乱数値はＭＡＣ生成部４に送られる。そして、ＭＡＣ生成部４に含まれる暗号アルゴリズムを使用して、受信した乱数値を暗号鍵記憶部５内の暗号鍵（共通鍵）を用いて暗号化する（Ｓ３１３）。そして、得られた数値をこのＣＡＮ ＩＤ用のカウンタの初期値として、カウンタ記憶部３に記憶する（Ｓ３１４）。なお、暗号化処理の出力のビット数（１２８ビット）とカウンタのビット数（５３ビット）は一致していないので、例えば前半５３ビットを採用したり後半５３ビットを採用したりするなど、システム内で共通のルールに従ってカウンタの初期値を決定する。
【００５８】
このようにすることで、カウンタを記憶するための不揮発性メモリを設ける必要なく、またカウンタ値自体を平文でネットワーク上を伝送させることなく、システム起動時に全ＥＣＵにおいてカウンタ値を共通なものとすることができる。
【００５９】
（本実施形態の作用・効果）
本実施形態によれば、メッセージ認証コード（ＭＡＣ）を用いてメインメッセージの検証を行うことで、メインメッセージが正規なものであるか、不正機器から送信された不正なものであるかを判断することができる。メッセージ送信の度に、ＭＡＣ算出に用いられるカウンタ値が変化するので、以前に受信したメッセージを再送するリプレイ攻撃を行った場合には、受信側ＥＣＵでＭＡＣの相違により不正攻撃を検知することができる。
【００６０】
また、本実施形態によるＭＡＣによるメッセージ検証処理は、標準化されているＣＡＮのプロトコルにしたがった設計となっているため、既存システムへの影響を小さくすることができる。たとえば、ＣＡＮメッセージを処理するＣＡＮコントローラは、高速処理お
よび低価格化を目的としてハードウェア化されているが、本実施形態ではこのような既存のＣＡＮコントローラを用いて実装できる。
【００６１】
また、本実施形態においては、ＭＡＣを算出するためにメインメッセージのデータフィールドとＣＡＮ ＩＤとカウンタ値を利用している。ここで、データフィールドおよびＣＡＮ ＩＤは平文でネットワーク上を流れるが、カウンタ値自体はネットワーク上を流れない。暗号化前のテキストと暗号化後のテキストが全て分かれば、多くのメッセージを受信することで暗号鍵を解読することが可能となるが、本実施形態では不正機器はカウンタ値を得られないため暗号鍵の解読も不可能となる。
【００６２】
また、メインメッセージを送信した後、即座に対応するＭＡＣメッセージを送信できる設計となっているため、受信ＥＣＵ側ではメインメッセージの正当性を即座に判断することができる。
【００６３】
（変形例）
本発明は、以上の実施形態に限定されることなく、種々の変形が可能であることは明らかであろう。例えば、採用する暗号アルゴリズムや鍵長などは任意のものであって良いし、カウンタ値のビット長なども安全性に対する要求とコストに対する要求を勘案して任意の長さにすることができる。また、上記ではＣＡＮに対して本発明を適用した実施例を説明したが、ＣＡＮ以外であってもＣＡＮと類似するプロトコルにしたがった通信システムであれば本発明を適用できる。
【００６４】
また、上記の実施形態においてはメインメッセージに含まれるＣＡＮ ＩＤとデータフィールドと、ＣＡＮ ＩＤに対応するカウンタ値からＭＡＣを生成しているが、メインメッセージのデータフィールドとカウンタ値のみからＭＡＣを生成するようにしても良い。このようにしても、メインメッセージがリプレイ攻撃などによって送信されたものであるか、正当なものであるかの判断は可能である。
【００６５】
また、上記の説明においては、メインメッセージ受信時および送信時にカウンタ値をインクリメントし、インクリメント後のカウンタ値を使ってＭＡＣを算出しているが、インクリメント前のカウンタ値を用いてＭＡＣを算出しても構わない。また、カウンタ値のインクリメントは１ずつの増分であるとして説明したが、全ＥＣＵで共通のルールが採用されれば必ずしも１ずつ増分する必要はなく、それ以外の値ずつ増分させても構わない。
【００６６】
また、上記の実施形態においてはＭＡＣによってメインメッセージが正当であることを検証してからメインメッセージの処理を行っているが、処理のリアルタイム性が要求されるメッセージについては、まずメインメッセージの処理を行ってからその正当性を検証しても構わない。この場合、メッセージが不正なものであると判定された場合には、それ以降は該当するＣＡＮ ＩＤを有するメッセージを無視したりすればよい。
【符号の説明】
【００６７】
１ ＭＡＣメッセージ生成部
２ ＭＡＣ比較部
３ カウンタ記憶部
４ ＭＡＣ生成部
５ 暗号鍵記憶部
６ ＣＡＮ ＩＤ抽出部
７ データフィールド抽出部
８ ＣＡＮメッセージ解析部
９ ＣＡＮメッセージ生成部
【技術分野】
【０００１】
本発明は、通信システムにおけるメッセージ認証技術に関する。
【背景技術】
【０００２】
車載ネットワークとしてＣＡＮ（Controller Area Network）が採用されている。この
ＣＡＮにはＯＢＤ２ポートと呼ばれる診断用のポートが設けられており、ネットワーク上を流れるメッセージを受信したり、ネットワーク上にメッセージを送信したりすることができる。
【０００３】
ＯＢＤ２ポートはメッセージのフィルタリング処理などを行わない直づけのインタフェースであるため、ＯＢＤ２ポートに不正機器が接続された場合は、リプレイ攻撃が行われる危険性がある。ここで述べるリプレイ攻撃とは、ネットワーク上を流れるメッセージを盗聴してその内容を記憶しておき、記憶したメッセージを再送することで不正な動作を引き起こす攻撃とする。なお、不正機器はメッセージの内容が分からなくても、メッセージ送信後の車両の挙動が分かれば、そのメッセージの意図も把握できる。
【０００４】
このようなリプレイ攻撃を防ぐ技術として、ＣＡＮメッセージにメッセージ認証コード（ＭＡＣ）を埋め込む技術が提案されている（非特許文献１）。この提案では、図１１に示すように、Ｎ番目からＮ＋３番目の４つのＣＡＮメッセージに含まれるデータフィールド（６４×４＝２５６ビット）から６４ビットのＭＡＣを生成し、１６ビットずつに４分割して、Ｎ＋４番目からＮ＋７番目の４つのＣＡＮメッセージのＣＲＣフィールド（１６ビット）に埋め込んで送信している。
【０００５】
受信側では、Ｎ＋４番目からＮ＋７番目のＣＡＮメッセージのＣＲＣフィールドからＭＡＣを取得し、Ｎ番目からＮ＋３番目のデータフィールドから生成されるＭＡＣと一致するか否かによってＮ番目からＮ＋３番目のＣＡＮメッセージが正当であるか判断する。ＣＲＣフィールドから得られるＭＡＣと、データフィールドから算出されるＭＡＣが異なる場合は、Ｎ番目からＮ＋３番目のＣＡＮメッセージのいずれかが不正であることが判断できる。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】D. K. Nilsson, U. E. Larson, E. Jonsson, "Efficient In-Vehicle Delayed Data Authentication Based on Compound Message Authentication Codes", IEEE 68th VTC 2008-Fall, 2008, 1-5.
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、非特許文献１に示す方法では、以下のような問題がある。第１に、Ｎ番目のメッセージの正当性を検証するためにＮ＋７番目までのメッセージを受信する必要があるので、メッセージの検証に時間を要するという問題がある。
【０００８】
第２の問題点は、非特許文献１に示す方法は標準化されているＣＡＮのプロトコルを変更している点である。ＣＲＣフィールドは本来、データフィールド等のデータ内容の誤り検出のためのものである。ＣＡＮコントローラの処理をハードウェアによって実現している現状を考慮すると、プロトコルの変更は現実的ではない。したがって、この第２の問題点はより深刻なものである。
【０００９】
本発明は、ＣＡＮプロトコルに適用可能な方式でメッセージの認証を可能とする技術を提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明に係るメッセージ認証方法では、メインメッセージと、メインメッセージのメッセージ認証コード（Message Authentication Code: ＭＡＣ）を含むＭＡＣメッセージを
送信する。受信側では、メインメッセージから算出されるＭＡＣとＭＡＣメッセージに含まれるＭＡＣが一致すればメインメッセージが正当なものであり、不一致であれば不正なものであると判断できる。本発明においては、以下のようにしてＭＡＣを生成する点に特徴がある。
【００１１】
通信システム内の各ノードは、メインメッセージがネットワーク上を伝送する度にインクリメントするカウンタ値を記憶する。メインメッセージを送信するノードは、その送信に際してカウンタ値をインクリメントする。送信ノード以外は、ネットワーク上をメインメッセージが伝送したことを検知するとカウンタ値をインクリメントする。なお、カウンタ値の初期値は０である必要はなく任意であって良いが、各ノードで共通とする必要がある。また、インクリメントは、必ずしもカウンタ値を１ずつ増分させるものでなくても良い。各ノードが共通のルールに従ってカウンタ値を変化させる方式、すなわち全てのノードでカウンタ値が共通となる方式であれば、メインメッセージ送信の度に任意の方式に従ってカウンタ値を変化させる方式であっても構わない。
【００１２】
メインメッセージの送信ノードは、このカウンタ値を利用してＭＡＣメッセージに含めるＭＡＣを生成する。より具体的には、メインメッセージとカウンタ値に所定のアルゴリズムを適用してＭＡＣを生成する。この所定のアルゴリズムは、例えば共通鍵暗号による暗号アルゴリズムであったり、暗号鍵の事前共有を必要とする鍵付きハッシュ関数などであったりすることができる。なお、ＭＡＣを生成する際にメインメッセージの全データビットを利用する必要はなく、その一部のみとカウンタ値からＭＡＣを生成しても良い。
【００１３】
メインメッセージの受信ノードも同様に、受信したメインメッセージとカウンタ値に所定の暗号アルゴリズムを適用してＭＡＣを生成する。
【００１４】
このような本発明によると、ＣＡＮプロトコルに適用可能な方式で、ＭＡＣによってメインメッセージの正当性を検証することができる。たとえば、不正機器が以前に受信したメインメッセージと対応するＭＡＣメッセージを送信した場合であっても、再送時にはカウンタ値が変化しているため正しいＭＡＣも変化している。したがって、不正機器がリプレイ攻撃を行っても、受信ノードにおいてメインメッセージが不正であることを検知できる。
【００１５】
また、本発明では、メインメッセージは平文の状態でネットワーク上を伝送するため不正機器がメインメッセージを知ることができるが、カウンタ値はネットワーク上を伝送せず不正機器には未知である。したがって、メインメッセージおよびＭＡＣメッセージを盗聴しても、そこからＭＡＣを生成するための暗号アルゴリズムや暗号鍵を推測できないという利点もある。
【００１６】
本発明において、メインメッセージは、メッセージＩＤとデータフィールドを含むものであることができる。この場合、メインメッセージのカウンタ値は、メッセージＩＤごとに個別にカウントすることが好ましい。そして、ＭＡＣの生成は、メインメッセージに含まれるメッセージＩＤおよびデータフィールドと、このメッセージＩＤに対応するカウンタ値とに基づいて生成することが好ましい。なお、このような場合であってもデータフィ
ールドとカウンタ値のみからＭＡＣを生成しても構わない。
【００１７】
また、本発明において、ＭＡＣは、メッセージＩＤ、データフィールドおよびメッセージＩＤに対応するカウンタに共通鍵暗号アルゴリズムを作用させて生成されるビット列から、所定のビットを抽出して生成することが好ましい。この方式は、共通鍵暗号アルゴリズムから得られるビット列が、ＭＡＣメッセージに格納可能なビット数を超える場合に有効である。なお、ビットの抽出方法は、各ノードで共通していれば任意の方法であって良い。例えば、共通鍵暗号アルゴリズムから得られるビット列から、前半部分のビット列を抽出したり、後半部分のビット列を抽出したり、奇数番目のビット列を抽出したり、偶数番目のビット列を抽出したりすることができる。
【００１８】
また、本発明において、カウンタ値の初期化はマスタノードからの通知によって行うことが好ましい。すなわち、ネットワーク上の１つのノードがマスタノードとなって、各メッセージＩＤに対応するカウンタ値の初期値を、通信システム起動時にブロードキャストによって通知することが好ましい。
【００１９】
このようにすれば、各ノードが不揮発性のメモリを有していなくても、全てのノードでカウンタ値を同一とすることができる。
【００２０】
カウンタ値の初期化は、より具体的には、以下のようにして行うことが好ましい。すなわち、マスタノードは、メッセージＩＤごとに乱数値を生成して、ブロードキャスト送信する。各ノードは、ブロードキャスト送信された乱数値を取得して、この乱数値に対して共通鍵暗号アルゴリズムを作用させる。そして、得られた値をカウンタ値の初期値として採用する。
【００２１】
このようにすれば、カウンタ値の初期値が、ネットワーク上を直接流れることがないため、不正機器はどのような値でカウンタ値が初期化されたか知ることができない。初期値がわかれば、任意の時点におけるカウンタ値を知ることが可能となり、メインメッセージとＭＡＣメッセージから暗号鍵を解読することも可能となり得るが、カウンタの初期値を秘匿化することでこのような危険性も回避できる。
【００２２】
なお、本発明は、上記処理の少なくとも一部を含むメッセージ認証方法として捉えることができる。また、本発明は、この方法を実行するコンピュータプログラムとして捉えることもできる。また、本発明は、上記処理の少なくとも一部を実行する通信システムおよび、通信システムを構成する通信装置として捉えることができる。上記手段および処理の各々は可能な限り互いに組み合わせて本発明を構成することができる。
【発明の効果】
【００２３】
本発明によれば、ＣＡＮプロトコルに適用可能な方式でメッセージの認証が可能となる。
【図面の簡単な説明】
【００２４】
【図１】ＣＡＮプロトコルにおけるデータフレームのフォーマットを示す図。
【図２】本実施形態におけるメッセージ検証処理の概要を説明する図。
【図３】本実施形態におけるＭＡＣ算出方法の概要を説明する図。
【図４】本実施形態におけるＥＣＵの機能構成を示す図。
【図５】メッセージを送信するＥＣＵにおける各機能部の連携を示す図。
【図６】メインメッセージを送信するＥＣＵにおける処理の流れを示すフローチャート。
【図７】メッセージを受信するＥＣＵにおける各機能部の連携を示す図。
【図８】メインメッセージを受信するＥＣＵにおける処理の流れを示すフローチャート。
【図９】カウンタ初期化メッセージを受信するＥＣＵにおける各機能部の連携を示す図。
【図１０】（ａ）カウンタ初期化メッセージを送信するマスタノードにおける処理の流れを示すフローチャートと、（ｂ）カウンタ初期化メッセージを受信する一般ノードにおける処理の流れを示すフローチャート。
【図１１】非特許文献１におけるメッセージ検証方法を説明する図。
【発明を実施するための形態】
【００２５】
本実施形態の説明の前にＣＡＮ（Controller Area Network）プロトコルの概要につい
て説明する。ＣＡＮは相互接続された機器間のデータ伝送に用いられる通信プロトコルであり、例えば自動車内の各種ＥＣＵ（Electronic Control Unit）間の通信などに用いら
れる。
【００２６】
図１は、ＣＡＮに用いられるデータフレームのフォーマットを示した図である。データフレームは、ＣＡＮ ＩＤ（１０１）、データフィールド（１０２）、ＣＲＣフィールド（１０３）などを含む。図示した以外のフィールドについての説明は割愛する。ＣＡＮではＣＡＮ ＩＤを用いてメッセージのアドレッシングが行われる。すなわち、ＣＡＮ ＩＤによって、このメッセージがどのようなデータであるのかを示し、受信側はＣＡＮ ＩＤを参照して自ノードが処理する必要のあるデータか否かを判断する。データフィールドは（最大で）６４ビットのフィールドであり、この中にデータの内容が格納される。ＣＲＣフィールドは、データフィールドなどから計算されるＣＲＣコードが格納され、通信に伴うビット落ちを検出可能とする。
【００２７】
以上のように、ＣＡＮにおいては、メッセージに送信元や宛先を示すＩＤは付与されず、ＣＡＮ ＩＤによってデータの内容や受信ノードが指示される。
【００２８】
本実施形態では、ＣＡＮネットワークに本発明を適用して、メッセージの正当性検証を行う。以下、図面を参照しながら本実施形態について説明する。
【００２９】
（概要）
図２は、本発明の概要を示す図である。ネットワークに接続されたＥＣＵ間でデータを通信する場合には次のようにして行う。すなわち、通信すべきデータを含むメッセージ（以下、メインメッセージ）を送信した後に、メインメッセージのデータフィールドに対するＭＡＣ（メッセージ認証コード）を含むメッセージ（以下、ＭＡＣメッセージ）を送信する。ＭＡＣによるメッセージ認証自体は既知な仕組みであり、本実施形態においても、受信したメインメッセージのデータフィールドから得られるＭＡＣと受信したＭＡＣメッセージに含まれるＭＡＣが一致するか否かによって、受信側においてメインメッセージの正当性を検証する。
【００３０】
本実施形態においては、図３（Ａ）に示すように、それぞれのＥＣＵにおいて各ＣＡＮ
ＩＤのメッセージが送信された回数をカウントして記憶する。そして、図３（Ｂ）に示すように、メインメッセージのデータフィールドと、ＣＡＮ ＩＤと、このＣＡＮ ＩＤに対応するカウンタ値とを使ってＭＡＣを求める点に特徴がある。ＭＡＣの算出は、ハッシュ関数を使う方式（ＨＭＡＣ）や、ブロック暗号アルゴリズムを使う方式（ＣＭＡＣなど）の任意の既知の手法によって行えば良い。本実施形態では、共通鍵ブロック暗号の一つであるＡＥＳ暗号アルゴリズムによってＭＡＣを求める。ＡＥＳでは出力が少なくとも１２８ビットになるが、ＭＡＣが格納されるデータフィールドは６４ビットなので、１２８ビットの出力から所定の６４ビットを抽出してＭＡＣとして利用する。なお共通鍵暗号
アルゴリズムの中には６４ビットを出力可能なものも存在し、そのような共通鍵暗号アルゴリズムを採用する際には上記の抽出作業は不要である。
【００３１】
本実施形態においては、各ＥＣＵがそれぞれＣＡＮ ＩＤごとにメッセージ送信回数をカウントしているため、各ＣＡＮ ＩＤのカウンタ値は全ＥＣＵにおいて共通となる。したがって、受信側ＥＣＵにおいても、メインメッセージに含まれるデータフィールドとＣＡＮ ＩＤ、および自ノードが記憶しているカウンタ値からＭＡＣを求めることができる。そして、このようにして求めたＭＡＣとＭＡＣメッセージに含まれるＭＡＣが一致するか否かによって、メインメッセージの正当性を検証可能である。
【００３２】
本実施形態の効果を簡単に説明すると、第１にＣＡＮプロトコルを変更していないので、既存システムとの互換性があることを挙げられる。例えば、高速処理および低価格化を目的としてハードウェア化されているＣＡＮコントローラを利用することができる。第２に、メッセージ送信の度にカウンタ値が更新されるので、不正機器が以前に受信したメッセージをそのまま送信しても、受信側において不正なメッセージであることが検証可能である。第３に、カウンタ値がネットワーク上を流れないため、メインメッセージとＭＡＣメッセージを受信して暗号鍵を解読する試みも事実上不可能である。第４に、メインメッセージ送信直後に対応するＭＡＣメッセージを送信できるので、即座にメインメッセージの正当性検証が可能である。
【００３３】
（構成）
以下では、より詳細に本実施形態について説明する。図４は、本実施形態におけるＥＣＵが有する機能部を示す図である。ＥＣＵは、ＣＰＵ、ＲＡＭ、ＲＯＭ、センサやアクチュエータとのインタフェースなどから構成されており、ＲＯＭに格納されたプログラムをＣＰＵが実行することで、図４に示す各機能部が実現される。図４に示した機能部は、メッセージ送信およびメッセージ受信に必要な機能全てが示されており、処理内容に応じて適切な機能部が選択的に実行される。
【００３４】
なお、本実施形態において、全てのメッセージについてＭＡＣによるメッセージ認証を行う必要はない。すなわち、重要なメッセージについてのみメッセージ認証を行っても良い。そして、メッセージ認証が必要ないメッセージのみを送受信するＥＣＵについては、図４に示したようなメッセージ認証のための各機能部は不要である。
【００３５】
図４に示した各機能部の詳細については、メッセージ送受信処理とともに説明を行うが、いくつかの機能部については、ここで説明を加える。
【００３６】
暗号鍵記憶部５には、ＣＡＮネットワーク内で共通な暗号鍵（共通鍵）が記憶される。この暗号鍵は、外部に漏洩しないことが必要である。本実施形態では、ＡＥＳ暗号アルゴリズムを採用し鍵長は１２８ビットとする。もちろん、鍵長はより長くても良いし、ＡＥＳ以外の暗号アルゴリズムを採用しても構わない。
【００３７】
カウンタ記憶部３には、ＣＡＮ ＩＤごとにネットワーク上をメッセージが伝送された回数を表すカウンタ値が格納される。ＣＡＮはバス型アーキテクチャであるため、ネットワーク上を伝送されるメッセージを全てのＥＣＵが参照可能であり、各ＥＣＵにおいてカウンタの更新が可能である。なお、それぞれのＥＣＵは、自身が送受信する可能性があるＣＡＮ ＩＤについてのみカウンタを更新・記憶すれば十分である。
【００３８】
なお、本実施形態においてカウンタは５３ビットとする。これは、暗号アルゴリズムへの入力が１２８ビット必要なので、データフィールド（６４ビット）とＣＡＮ ＩＤ（１１ビット）と合わせて１２８ビットとするためである。ただし、暗号アルゴリズムへの入
力はパディングを行えば良いので、カウンタのビット数はこれより少なくても問題ない。例えば、ＣＡＮの仕様にしたがって２０年間継続的に最大限の速度でメッセージを送信したとしても、２４０個程度のメッセージしか送信できないので、カウンタ値は４０ビット程度としても良い。もちろんカウンタ値の繰り返しを許容しても良く、その場合はより少ないビット数であっても構わない。
【００３９】
（メッセージ送信時処理）
まず、メインメッセージを送信するＥＣＵが行う処理を、図５および図６を参照しつつ説明する。図５は、送信ＥＣＵにおける各機能部の連携を示す図である。図６は、メインメッセージ送信時の処理の流れを示すフローチャートである。
【００４０】
メインメッセージ生成部９は、ＣＡＮ ＩＤおよびデータフィールドを含むメインメッセージを生成してＣＡＮに送信する。図６のフローチャートには、メインメッセージを送信した後の処理の流れが示されている。メインメッセージを送信すると、ＣＡＮ ＩＤ抽出部６がメインメッセージ生成部９から送信したメインメッセージのＣＡＮ ＩＤを抽出する（Ｓ１０１）。ＣＡＮ ＩＤ抽出部６は、メインメッセージのＣＡＮ ＩＤに対応するカウンタ値をカウンタ記憶部３から読み取り（Ｓ１０２）、カウンタを１つ増加させてカウンタ記憶部３を更新する（Ｓ１０３）。抽出されたＣＡＮ ＩＤおよび更新後のカウンタ値は、ＭＡＣ生成部４に送られる。
【００４１】
また、データフィールド抽出部７は、メインメッセージ生成部９が送信したメインメッセージのデータフィールドを抽出する（Ｓ１０４）。抽出されたデータフィールドは、ＭＡＣ生成部４に送られる。
【００４２】
ＭＡＣ生成部４は、暗号鍵記憶部５から暗号鍵（共通鍵）を取り出し（Ｓ１０５）、この暗号鍵を用いて、ＣＡＮ ＩＤ、最新のカウンタ値、送信済みのデータフィールドからＭＡＣを生成する（Ｓ１０６）。なお、上述したように本実施形態ではＡＥＳを採用しているため暗号アルゴリズムの出力は１２８ビットであるが、ＣＡＮのデータフレームが送れるデータフィールドは６４ビットである。したがって、システム内で共通するルールに従って出力の１２８ビットから６４ビットを抽出する。例えば、前半６４ビットや後半６４ビットを採用しても良いし、奇数ビットや偶数ビットを採用しても良い。さらには、ＣＡＮ ＩＤが奇数か偶数かによって、前半６４ビットを採用するか後半６４ビットを採用するか、あるいは奇数ビットを採用するか偶数ビットを採用するかなどを決めても構わない。
【００４３】
ＭＡＣ生成部４が生成したＭＡＣはＭＡＣメッセージ生成部１へ送られ（Ｓ１０７）、ＭＡＣメッセージ生成部１がＭＡＣをＣＡＮメッセージ（ＭＡＣメッセージ）に加工してＣＡＮに送信する。すなわち、計算された６４ビットのＭＡＣがＭＡＣメッセージのデータフィールドに格納される。また、ＭＡＣメッセージのＣＡＮ ＩＤは、メインメッセージのＣＡＮ ＩＤに対応するＩＤが用いられる。メインメッセージとＭＡＣメッセージのＣＡＮ ＩＤの対応によって、受信側ＥＣＵでは、ＭＡＣメッセージを受信した場合に対応するＣＡＮ ＩＤを有するメインメッセージに対するＭＡＣであることが把握できる。
【００４４】
（メッセージ受信時処理）
次に、メインメッセージを受信してその検証を行うＥＣＵの処理を、図７および図８を参照しつつ説明する。図７は、受信ＥＣＵにおける各機能部の連携を示す図である。図８は、メインメッセージ受信時の処理の流れを示すフローチャートである。
【００４５】
ＥＣＵがメインメッセージを受信すると、ＣＡＮ ＩＤ抽出部６がＣＡＮメッセージ解析部８を経由して、受信したメインメッセージのＣＡＮ ＩＤを抽出する（Ｓ２０１）。
なお、ＣＡＮ ＩＤごとにメッセージの内容が規定されているため、ＣＡＮ ＩＤを参照することでそのメッセージがＭＡＣによる認証を必要とするものか否かも判断できる。受信したメインメッセージがＭＡＣによる認証を必要としないものであれば、以下の処理は行う必要がない。また、受信したメッセージが自ノードで処理する必要がないものである場合も、以下の処理を行う必要がない。
【００４６】
受信したメインメッセージは自ノードが処理する必要があるものであり、かつＭＡＣによるメッセージ認証が行われるものであると、抽出したＣＡＮ ＩＤから判断される場合には以下の処理が行われる。ＣＡＮ ＩＤ抽出部６は、抽出したＣＡＮ ＩＤに対応するカウンタ値をカウンタ記憶部３から読み取り（Ｓ２０２）、カウンタを１つ増加させてカウンタ記憶部３を更新する（Ｓ２０３）。抽出されたＣＡＮ ＩＤおよび更新後のカウンタ値は、ＭＡＣ生成部４に送られる。
【００４７】
また、データフィールド抽出部７は、ＣＡＮメッセージ解析部８を経由して、受信したメインメッセージのデータフィールドを抽出する（Ｓ２０４）。抽出されたデータフィールドは、ＭＡＣ生成部４に送られる。
【００４８】
ＭＡＣ生成部４は、暗号鍵記憶部５から暗号鍵（共通鍵）を取り出し（Ｓ２０５）、この暗号鍵を用いて、受信したメッセージのデータフィールド、ＣＡＮ ＩＤおよびＣＡＮ
ＩＤに対応する最新のカウンタ値からＭＡＣを生成する（Ｓ２０６）。ＭＡＣの生成方法は、メッセージ送信の際の方法と同じであるため詳細な説明は省略する。ＭＡＣ生成部４が生成したＭＡＣは、ＭＡＣ比較部２へと送られる（Ｓ２０７）。
【００４９】
受信側ＥＣＵは、メインメッセージに対応するＭＡＣメッセージをＣＡＮメッセージ解析部８が受信するのを待つ（Ｓ２０８〜Ｓ２０９）。上述のように、メインメッセージとそのＭＡＣメッセージとはＣＡＮ ＩＤが対応付けられているので、ＣＡＮメッセージ解析部８は、メインメッセージのＣＡＮ ＩＤに対応するＣＡＮ ＩＤを有するメッセージが到着するのを待つ。
【００５０】
メインメッセージに対応するＭＡＣメッセージが到着すると（Ｓ２０９−ＹＥＳ）、データフィールド抽出部７が、ＣＡＮメッセージ解析部８を経由して、ＭＡＣメッセージからＭＡＣを抽出する（Ｓ２１１）。上述したように、ＭＡＣはＭＡＣメッセージのデータフィールド（６４ビット）に格納されている。データフィールド抽出部７が抽出したＭＡＣは、ＭＡＣ比較部２へと送られる（Ｓ２１２）。
【００５１】
ＭＡＣ比較部２は、ＭＡＣ生成部４が生成したＭＡＣと、受信したＭＡＣメッセージから抽出されたＭＡＣとを比較する（Ｓ２１３）。これら２つのＭＡＣが同じであれば（Ｓ２１４−ＹＥＳ）、メインメッセージが正当なものであることが分かるので、受信ＥＣＵはメインメッセージを処理する（Ｓ２１６）。一方、これら２つのＭＡＣが異なるものであれば（Ｓ２１４−ＮＯ）、メインメッセージが不正なものであることが分かるので、受信ＥＣＵはメインメッセージを処理しない（Ｓ２１５）。なお、不正なメインメッセージを受信した後の処理は種々考えられるが、どのような対応を行っても構わない。
【００５２】
（カウンタ初期化処理）
次に、ＣＡＮ ＩＤごとのカウンタ値の初期化について説明する。カウンタ値はシステム内の全ＥＣＵで共通することが必要である。システム起動中はネットワークを伝送されるメッセージをカウントすることで全ＥＣＵにてカウンタを同一とすることができるが、システム起動時においてもカウンタ値を一致させる必要がある。このために、全ＥＣＵに読み書き可能な不揮発性メモリを設け、電源オフ時のカウンタ値を記憶し、システム再開時にこの不揮発性メモリからカウンタ値を読み込んで使用することが考えられる。しかし
ながら、本実施形態では、全ＥＣＵに不揮発性メモリを設けずにシステム開始時のカウンタ値を、以下のようにして一致させる。
【００５３】
本実施形態においては、カウンタの初期化処理のために、ネットワーク内の任意のＥＣＵをカウンタ初期化用のＥＣＵ（以下、マスタノードともいう）として利用する。マスタノードは、システム開始時に全てのＣＡＮ ＩＤ（メッセージ認証が必要なメッセージに対応するＣＡＮ ＩＤという意味。以下同じ。）についてカウンタ値の初期値を全ＥＣＵに通知する処理を行う。
【００５４】
図９は、マスタノードからカウンタ値の初期化メッセージを受信した際の、一般ノードの各機能部の連携を示した図である。図１０（ａ）は、カウンタ値の初期化メッセージを送信するマスタノードの処理の流れを示すフローチャートである。図１０（ｂ）は、初期化メッセージを受信した一般ノードの処理の流れを示すフローチャートである。
【００５５】
まず、マスタノードが行う処理について図１０（ａ）を参照して説明する。マスタノードは、システムが起動すると、ＣＡＮ ＩＤを選択して（Ｓ３０１）、そのＣＡＮ ＩＤのカウンタ初期値を決定するための乱数を発生させる（Ｓ３０２）。そして、カウンタを初期化するＣＡＮ ＩＤと関連づけて、カウンタ初期化メッセージとしてこの乱数を送信する（Ｓ３０３）。マスタノードでは、全てのＣＡＮ ＩＤについて、このようなカウンタ初期化メッセージを送信する。
【００５６】
次に、一般ノードが行う処理を図９および図１０（ｂ）を参照して説明する。一般ノードは、カウンタ初期化メッセージを受信した場合に（Ｓ３１１）、そのメッセージが自ノードで送受信する（すなわち、カウンタ値を記憶する必要がある）ＣＡＮ ＩＤに対するカウンタ初期化メッセージであれば以下の処理を行う。
【００５７】
データフィールド抽出部７が、カウンタ初期化メッセージのデータフィールドから、マスタノードが生成した乱数値を取得する（Ｓ３１２）。そして、この乱数値はＭＡＣ生成部４に送られる。そして、ＭＡＣ生成部４に含まれる暗号アルゴリズムを使用して、受信した乱数値を暗号鍵記憶部５内の暗号鍵（共通鍵）を用いて暗号化する（Ｓ３１３）。そして、得られた数値をこのＣＡＮ ＩＤ用のカウンタの初期値として、カウンタ記憶部３に記憶する（Ｓ３１４）。なお、暗号化処理の出力のビット数（１２８ビット）とカウンタのビット数（５３ビット）は一致していないので、例えば前半５３ビットを採用したり後半５３ビットを採用したりするなど、システム内で共通のルールに従ってカウンタの初期値を決定する。
【００５８】
このようにすることで、カウンタを記憶するための不揮発性メモリを設ける必要なく、またカウンタ値自体を平文でネットワーク上を伝送させることなく、システム起動時に全ＥＣＵにおいてカウンタ値を共通なものとすることができる。
【００５９】
（本実施形態の作用・効果）
本実施形態によれば、メッセージ認証コード（ＭＡＣ）を用いてメインメッセージの検証を行うことで、メインメッセージが正規なものであるか、不正機器から送信された不正なものであるかを判断することができる。メッセージ送信の度に、ＭＡＣ算出に用いられるカウンタ値が変化するので、以前に受信したメッセージを再送するリプレイ攻撃を行った場合には、受信側ＥＣＵでＭＡＣの相違により不正攻撃を検知することができる。
【００６０】
また、本実施形態によるＭＡＣによるメッセージ検証処理は、標準化されているＣＡＮのプロトコルにしたがった設計となっているため、既存システムへの影響を小さくすることができる。たとえば、ＣＡＮメッセージを処理するＣＡＮコントローラは、高速処理お
よび低価格化を目的としてハードウェア化されているが、本実施形態ではこのような既存のＣＡＮコントローラを用いて実装できる。
【００６１】
また、本実施形態においては、ＭＡＣを算出するためにメインメッセージのデータフィールドとＣＡＮ ＩＤとカウンタ値を利用している。ここで、データフィールドおよびＣＡＮ ＩＤは平文でネットワーク上を流れるが、カウンタ値自体はネットワーク上を流れない。暗号化前のテキストと暗号化後のテキストが全て分かれば、多くのメッセージを受信することで暗号鍵を解読することが可能となるが、本実施形態では不正機器はカウンタ値を得られないため暗号鍵の解読も不可能となる。
【００６２】
また、メインメッセージを送信した後、即座に対応するＭＡＣメッセージを送信できる設計となっているため、受信ＥＣＵ側ではメインメッセージの正当性を即座に判断することができる。
【００６３】
（変形例）
本発明は、以上の実施形態に限定されることなく、種々の変形が可能であることは明らかであろう。例えば、採用する暗号アルゴリズムや鍵長などは任意のものであって良いし、カウンタ値のビット長なども安全性に対する要求とコストに対する要求を勘案して任意の長さにすることができる。また、上記ではＣＡＮに対して本発明を適用した実施例を説明したが、ＣＡＮ以外であってもＣＡＮと類似するプロトコルにしたがった通信システムであれば本発明を適用できる。
【００６４】
また、上記の実施形態においてはメインメッセージに含まれるＣＡＮ ＩＤとデータフィールドと、ＣＡＮ ＩＤに対応するカウンタ値からＭＡＣを生成しているが、メインメッセージのデータフィールドとカウンタ値のみからＭＡＣを生成するようにしても良い。このようにしても、メインメッセージがリプレイ攻撃などによって送信されたものであるか、正当なものであるかの判断は可能である。
【００６５】
また、上記の説明においては、メインメッセージ受信時および送信時にカウンタ値をインクリメントし、インクリメント後のカウンタ値を使ってＭＡＣを算出しているが、インクリメント前のカウンタ値を用いてＭＡＣを算出しても構わない。また、カウンタ値のインクリメントは１ずつの増分であるとして説明したが、全ＥＣＵで共通のルールが採用されれば必ずしも１ずつ増分する必要はなく、それ以外の値ずつ増分させても構わない。
【００６６】
また、上記の実施形態においてはＭＡＣによってメインメッセージが正当であることを検証してからメインメッセージの処理を行っているが、処理のリアルタイム性が要求されるメッセージについては、まずメインメッセージの処理を行ってからその正当性を検証しても構わない。この場合、メッセージが不正なものであると判定された場合には、それ以降は該当するＣＡＮ ＩＤを有するメッセージを無視したりすればよい。
【符号の説明】
【００６７】
１ ＭＡＣメッセージ生成部
２ ＭＡＣ比較部
３ カウンタ記憶部
４ ＭＡＣ生成部
５ 暗号鍵記憶部
６ ＣＡＮ ＩＤ抽出部
７ データフィールド抽出部
８ ＣＡＮメッセージ解析部
９ ＣＡＮメッセージ生成部
【特許請求の範囲】
【請求項１】
複数のノードがネットワーク接続された通信システムにおけるメッセージ認証方法であって、
各ノードが、他のノードによってメインメッセージが送信される度に、各ノードに記憶されているカウンタ値をインクリメントするステップと、
送信ノードが、メインメッセージを送信するステップと、
送信ノードが、前記メインメッセージの送信に際し、カウンタ値をインクリメントするステップと、
送信ノードが、前記メインメッセージおよび前記カウンタ値に基づいて生成されるメッセージ認証コードを含むＭＡＣメッセージを送信するステップと、
受信ノードが、前記メインメッセージおよび前記ＭＡＣメッセージを受信するステップと、
受信ノードが、前記メインメッセージおよび前記カウンタ値に基づいて生成されるメッセージ認証コードと、前記ＭＡＣメッセージに含まれるメッセージ認証コードとが一致するか否かによって、前記メインメッセージの正当性を検証するステップと、
を含む、メッセージ認証方法。
【請求項２】
前記メッセージ認証コードは、共通鍵を用いた暗号アルゴリズムによって生成される、
請求項１に記載のメッセージ認証方法。
【請求項３】
複数のノードがネットワーク接続された通信システムにおけるメッセージ認証方法であって、
各ノードが、所定のメッセージＩＤを有するメッセージが他のノードによって送信される度に、各ノードに記憶されている当該メッセージＩＤに対応するカウンタ値をインクリメントするステップと、
送信ノードが、メッセージＩＤとデータフィールドを含むメインメッセージを送信するステップと、
送信ノードが、前記メインメッセージの送信に際し、前記メッセージＩＤに対応するカウンタ値をインクリメントするステップと、
送信ノードが、前記メッセージＩＤ、前記データフィールド、および前記メッセージＩＤに対応するカウンタ値に基づいて生成されるメッセージ認証コードを含むＭＡＣメッセージを送信するステップと、
受信ノードが、前記メインメッセージおよび前記ＭＡＣメッセージを受信するステップと、
受信ノードが、前記メインメッセージに含まれる前記メッセージＩＤおよび前記データフィールドと、前記メッセージＩＤに対応するカウンタ値とに基づいて生成されるメッセージ認証コードが、前記ＭＡＣメッセージに含まれるメッセージ認証コードと一致するか否かによって、前記メインメッセージの正当性を検証するステップと、
を含む、メッセージ認証方法。
【請求項４】
前記メッセージ認証コードは、共通鍵を用いた暗号アルゴリズムによって生成される、
請求項３に記載のメッセージ認証方法。
【請求項５】
前記メッセージ認証コードは、前記メッセージＩＤ、前記データフィールド、および前記メッセージＩＤに対応するカウンタ値に対して、前記共通鍵を用いた前記暗号アルゴリズムを作用させて生成されるビット列から、所定のビットを抽出して生成される、
請求項４に記載のメッセージ認証方法。
【請求項６】
マスタノードが、通信システム起動時に、各メッセージＩＤに対応するカウンタ値の初
期値をブロードキャストによって通知する、
請求項３〜５のいずれかに記載のメッセージ認証方法。
【請求項７】
前記マスタノードは、メッセージＩＤごとに乱数値を生成してブロードキャスト送信し、
各ノードは、受信された乱数値に対して、共通鍵を用いた暗号アルゴリズムを作用させて生成される数値を、各メッセージＩＤに対応するカウンタ値の初期値として利用する、
請求項６に記載のメッセージ認証方法。
【請求項８】
少なくとも送信ノードと受信ノードがネットワーク接続された通信システムであって、
送信ノードは、
カウンタ値を記憶するカウンタ値記憶手段と、
他のノードが送信したメインメッセージを受信する度、および自ノードがメインメッセージを送信する度に、カウンタ値をインクリメントするカウンタ値インクリメント手段と、
メインメッセージを送信するメインメッセージ送信手段と、
前記メインメッセージおよび前記カウンタ値に基づいて生成されるメッセージ認証コードを含むＭＡＣメッセージを送信するＭＡＣメッセージ送信手段と、
を有し、
受信ノードは、
カウンタ値を記憶するカウンタ値記憶手段と、
メインメッセージを受信する度に、カウンタ値をインクリメントするカウンタ値インクリメント手段と、
送信ノードから送信されるメインメッセージおよびＭＡＣメッセージを受信する受信手段と、
前記メインメッセージおよび前記カウンタ値に基づいて生成されるメッセージ認証コードが、前記ＭＡＣメッセージに含まれるメッセージ認証コードと一致するか否かによって、前記メインメッセージの正当性を検証するメッセージ検証手段と、
を有する、
通信システム。
【請求項９】
前記送信ノードのＭＡＣメッセージ送信手段と前記受信ノードのメッセージ検証手段は、共通鍵を用いた暗号アルゴリズムによってメッセージ認証コードを生成する、
請求項８に記載の通信システム。
【請求項１０】
少なくとも送信ノードと受信ノードがネットワーク接続された通信システムであって、
送信ノードは、
メッセージＩＤに対応するカウンタ値を記憶するカウンタ値記憶手段と、
所定のメッセージＩＤを有するメインメッセージが他のノードによって送信される度、および自ノードが所定のメッセージＩＤを有するメインメッセージを送信する度に、当該メッセージＩＤに対応するカウンタ値をインクリメントするカウンタ値インクリメント手段と、
メッセージＩＤとデータフィールドとを含むメインメッセージを送信するメインメッセージ送信手段と、
前記メッセージＩＤ、前記データフィールド、および前記メッセージＩＤに対応するカウンタ値に基づいて生成されるメッセージ認証コードを含むＭＡＣメッセージを送信するＭＡＣメッセージ送信手段と、
を有し、
受信ノードは、
メッセージＩＤに対応するカウンタ値を記憶するカウンタ値記憶手段と、
所定のメッセージＩＤを有するメインメッセージが他のノードによって送信される度に、当該メッセージＩＤに対応するカウンタ値をインクリメントするカウンタ値インクリメント手段と、
送信ノードから送信されるメインメッセージおよびＭＡＣメッセージを受信する受信手段と、
前記メインメッセージに含まれる前記メッセージＩＤおよび前記データフィールドと、前記メッセージＩＤとに対応するカウンタ値に基づいて生成されるメッセージ認証コードが、前記ＭＡＣメッセージに含まれるメッセージ認証コードと一致するか否かによって、前記メインメッセージの正当性を検証するメッセージ検証手段と、
を有する、
通信システム。
【請求項１１】
前記送信ノードのＭＡＣメッセージ送信手段と前記受信ノードのメッセージ検証手段は、共通鍵を用いた暗号アルゴリズムによってメッセージ認証コードを生成する、
請求項１０に記載の通信システム。
【請求項１２】
前記送信ノードのＭＡＣメッセージ送信手段と前記受信ノードのメッセージ検証手段は、前記メッセージＩＤ、前記データフィールド、および前記メッセージＩＤに対応するカウンタ値に対して、前記共通鍵を用いた前記暗号アルゴリズムによって生成されるビット列から、所定のビットを抽出してメッセージ認証コードを生成する、
請求項１１に記載の通信システム。
【請求項１３】
通信システム起動時に、各メッセージＩＤに対応するカウンタ値の初期値をブロードキャストによって通知するマスタノードをさらに含む、
請求項１０〜１２のいずれかに記載の通信システム。
【請求項１４】
前記マスタノードは、メッセージＩＤごとに乱数値を生成してブロードキャスト送信し、
前記送信ノードおよび受信ノードは、受信された乱数値に対して、共通鍵を用いた暗号アルゴリズムによって生成される数値を、各メッセージＩＤに対応するカウンタ値の初期値として利用する、
請求項１３に記載の通信システム。
【請求項１】
複数のノードがネットワーク接続された通信システムにおけるメッセージ認証方法であって、
各ノードが、他のノードによってメインメッセージが送信される度に、各ノードに記憶されているカウンタ値をインクリメントするステップと、
送信ノードが、メインメッセージを送信するステップと、
送信ノードが、前記メインメッセージの送信に際し、カウンタ値をインクリメントするステップと、
送信ノードが、前記メインメッセージおよび前記カウンタ値に基づいて生成されるメッセージ認証コードを含むＭＡＣメッセージを送信するステップと、
受信ノードが、前記メインメッセージおよび前記ＭＡＣメッセージを受信するステップと、
受信ノードが、前記メインメッセージおよび前記カウンタ値に基づいて生成されるメッセージ認証コードと、前記ＭＡＣメッセージに含まれるメッセージ認証コードとが一致するか否かによって、前記メインメッセージの正当性を検証するステップと、
を含む、メッセージ認証方法。
【請求項２】
前記メッセージ認証コードは、共通鍵を用いた暗号アルゴリズムによって生成される、
請求項１に記載のメッセージ認証方法。
【請求項３】
複数のノードがネットワーク接続された通信システムにおけるメッセージ認証方法であって、
各ノードが、所定のメッセージＩＤを有するメッセージが他のノードによって送信される度に、各ノードに記憶されている当該メッセージＩＤに対応するカウンタ値をインクリメントするステップと、
送信ノードが、メッセージＩＤとデータフィールドを含むメインメッセージを送信するステップと、
送信ノードが、前記メインメッセージの送信に際し、前記メッセージＩＤに対応するカウンタ値をインクリメントするステップと、
送信ノードが、前記メッセージＩＤ、前記データフィールド、および前記メッセージＩＤに対応するカウンタ値に基づいて生成されるメッセージ認証コードを含むＭＡＣメッセージを送信するステップと、
受信ノードが、前記メインメッセージおよび前記ＭＡＣメッセージを受信するステップと、
受信ノードが、前記メインメッセージに含まれる前記メッセージＩＤおよび前記データフィールドと、前記メッセージＩＤに対応するカウンタ値とに基づいて生成されるメッセージ認証コードが、前記ＭＡＣメッセージに含まれるメッセージ認証コードと一致するか否かによって、前記メインメッセージの正当性を検証するステップと、
を含む、メッセージ認証方法。
【請求項４】
前記メッセージ認証コードは、共通鍵を用いた暗号アルゴリズムによって生成される、
請求項３に記載のメッセージ認証方法。
【請求項５】
前記メッセージ認証コードは、前記メッセージＩＤ、前記データフィールド、および前記メッセージＩＤに対応するカウンタ値に対して、前記共通鍵を用いた前記暗号アルゴリズムを作用させて生成されるビット列から、所定のビットを抽出して生成される、
請求項４に記載のメッセージ認証方法。
【請求項６】
マスタノードが、通信システム起動時に、各メッセージＩＤに対応するカウンタ値の初
期値をブロードキャストによって通知する、
請求項３〜５のいずれかに記載のメッセージ認証方法。
【請求項７】
前記マスタノードは、メッセージＩＤごとに乱数値を生成してブロードキャスト送信し、
各ノードは、受信された乱数値に対して、共通鍵を用いた暗号アルゴリズムを作用させて生成される数値を、各メッセージＩＤに対応するカウンタ値の初期値として利用する、
請求項６に記載のメッセージ認証方法。
【請求項８】
少なくとも送信ノードと受信ノードがネットワーク接続された通信システムであって、
送信ノードは、
カウンタ値を記憶するカウンタ値記憶手段と、
他のノードが送信したメインメッセージを受信する度、および自ノードがメインメッセージを送信する度に、カウンタ値をインクリメントするカウンタ値インクリメント手段と、
メインメッセージを送信するメインメッセージ送信手段と、
前記メインメッセージおよび前記カウンタ値に基づいて生成されるメッセージ認証コードを含むＭＡＣメッセージを送信するＭＡＣメッセージ送信手段と、
を有し、
受信ノードは、
カウンタ値を記憶するカウンタ値記憶手段と、
メインメッセージを受信する度に、カウンタ値をインクリメントするカウンタ値インクリメント手段と、
送信ノードから送信されるメインメッセージおよびＭＡＣメッセージを受信する受信手段と、
前記メインメッセージおよび前記カウンタ値に基づいて生成されるメッセージ認証コードが、前記ＭＡＣメッセージに含まれるメッセージ認証コードと一致するか否かによって、前記メインメッセージの正当性を検証するメッセージ検証手段と、
を有する、
通信システム。
【請求項９】
前記送信ノードのＭＡＣメッセージ送信手段と前記受信ノードのメッセージ検証手段は、共通鍵を用いた暗号アルゴリズムによってメッセージ認証コードを生成する、
請求項８に記載の通信システム。
【請求項１０】
少なくとも送信ノードと受信ノードがネットワーク接続された通信システムであって、
送信ノードは、
メッセージＩＤに対応するカウンタ値を記憶するカウンタ値記憶手段と、
所定のメッセージＩＤを有するメインメッセージが他のノードによって送信される度、および自ノードが所定のメッセージＩＤを有するメインメッセージを送信する度に、当該メッセージＩＤに対応するカウンタ値をインクリメントするカウンタ値インクリメント手段と、
メッセージＩＤとデータフィールドとを含むメインメッセージを送信するメインメッセージ送信手段と、
前記メッセージＩＤ、前記データフィールド、および前記メッセージＩＤに対応するカウンタ値に基づいて生成されるメッセージ認証コードを含むＭＡＣメッセージを送信するＭＡＣメッセージ送信手段と、
を有し、
受信ノードは、
メッセージＩＤに対応するカウンタ値を記憶するカウンタ値記憶手段と、
所定のメッセージＩＤを有するメインメッセージが他のノードによって送信される度に、当該メッセージＩＤに対応するカウンタ値をインクリメントするカウンタ値インクリメント手段と、
送信ノードから送信されるメインメッセージおよびＭＡＣメッセージを受信する受信手段と、
前記メインメッセージに含まれる前記メッセージＩＤおよび前記データフィールドと、前記メッセージＩＤとに対応するカウンタ値に基づいて生成されるメッセージ認証コードが、前記ＭＡＣメッセージに含まれるメッセージ認証コードと一致するか否かによって、前記メインメッセージの正当性を検証するメッセージ検証手段と、
を有する、
通信システム。
【請求項１１】
前記送信ノードのＭＡＣメッセージ送信手段と前記受信ノードのメッセージ検証手段は、共通鍵を用いた暗号アルゴリズムによってメッセージ認証コードを生成する、
請求項１０に記載の通信システム。
【請求項１２】
前記送信ノードのＭＡＣメッセージ送信手段と前記受信ノードのメッセージ検証手段は、前記メッセージＩＤ、前記データフィールド、および前記メッセージＩＤに対応するカウンタ値に対して、前記共通鍵を用いた前記暗号アルゴリズムによって生成されるビット列から、所定のビットを抽出してメッセージ認証コードを生成する、
請求項１１に記載の通信システム。
【請求項１３】
通信システム起動時に、各メッセージＩＤに対応するカウンタ値の初期値をブロードキャストによって通知するマスタノードをさらに含む、
請求項１０〜１２のいずれかに記載の通信システム。
【請求項１４】
前記マスタノードは、メッセージＩＤごとに乱数値を生成してブロードキャスト送信し、
前記送信ノードおよび受信ノードは、受信された乱数値に対して、共通鍵を用いた暗号アルゴリズムによって生成される数値を、各メッセージＩＤに対応するカウンタ値の初期値として利用する、
請求項１３に記載の通信システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２０１３−９８７１９（Ｐ２０１３−９８７１９Ａ）
【公開日】平成２５年５月２０日（２０１３．５．２０）
【国際特許分類】
【出願番号】特願２０１１−２３９１６１（Ｐ２０１１−２３９１６１）
【出願日】平成２３年１０月３１日（２０１１．１０．３１）
【出願人】（５０２０８７４６０）株式会社トヨタＩＴ開発センター (232)
【出願人】（０００００３２０７）トヨタ自動車株式会社 (59,920)
【出願人】（５０４１８２２５５）国立大学法人横浜国立大学 (429)
【Ｆターム（参考）】
【公開日】平成２５年５月２０日（２０１３．５．２０）
【国際特許分類】
【出願日】平成２３年１０月３１日（２０１１．１０．３１）
【出願人】（５０２０８７４６０）株式会社トヨタＩＴ開発センター (232)
【出願人】（０００００３２０７）トヨタ自動車株式会社 (59,920)
【出願人】（５０４１８２２５５）国立大学法人横浜国立大学 (429)
【Ｆターム（参考）】
[ Back to top ]