保護通信方法
【課題】ＣＡＮにおけるフォーマットの互換性確保とセキュリティ性向上を両立させた保護通信方法を提供することを課題とする。
【解決手段】ＣＡＮ通信プロトコルに基づいて送受信されるデータを保護するための保護通信方法であって、ＭＡＣ（メッセージ認証コード）を生成し（Ｓ４６）、ＭＡＣと送信データを暗号化し（Ｓ４８）、その暗号化したＭＡＣと通し番号とワーク鍵ＩＤをＣＡＮ通信プロトコルの拡張フォーマットの識別子拡張領域に格納し、標準フォーマット互換のメッセージＩＤを拡張フォーマットの識別子ベース領域に格納し、暗号化した送信データを拡張フォーマットのデータ領域に格納し（Ｓ４９）、その拡張フォーマットでメッセージを送信する（Ｓ４９）。
【解決手段】ＣＡＮ通信プロトコルに基づいて送受信されるデータを保護するための保護通信方法であって、ＭＡＣ（メッセージ認証コード）を生成し（Ｓ４６）、ＭＡＣと送信データを暗号化し（Ｓ４８）、その暗号化したＭＡＣと通し番号とワーク鍵ＩＤをＣＡＮ通信プロトコルの拡張フォーマットの識別子拡張領域に格納し、標準フォーマット互換のメッセージＩＤを拡張フォーマットの識別子ベース領域に格納し、暗号化した送信データを拡張フォーマットのデータ領域に格納し（Ｓ４９）、その拡張フォーマットでメッセージを送信する（Ｓ４９）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＣＡＮ通信プロトコルに基づいて送受信されるデータを保護するための保護通信方法に関する。
【背景技術】
【０００２】
車載のＥＣＵ[Electronic Control Unit]間の基幹ネットワークとして、一般に、ＣＡＮ[Controller Area Network]が用いられている。ＣＡＮには、ＯＢＤ[OnBoard Diagnosis]のためのインタフェースやＥＣＵ追加のためのコネクタも用意されている。このような箇所からＣＡＮに接続し、外部から不正メッセージを送信することも可能である。このような不正メッセージを排除してセキュリティ性を向上させるために、一般に、メッセージにＭＡＣ[Message Authentication Code]（メッセージ認証コード）を付与する手法がある。特許文献１には、ネットワークにおけるデータ通信においてＭＡＣを暗号化して送信する技術が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開平７−２９７８１９号公報
【特許文献２】特開２０１０−１８７３２７号公報
【特許文献３】特開２０１０−２５８９９０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
セキュリティ性を向上させるためには、上記のようにＭＡＣ等のセキュリティに関するデータを追加する必要がある。しかし、ＣＡＮの場合、標準フォーマットが決まっており、データ領域に格納可能なデータは最大８バイトであり、データ領域に格納するデータは決まっているので、データ領域に安全な長さのＭＡＣを格納することは困難である。また、ＭＡＣを付加するために、送信データ量を大幅に増加すると、コストアップにつながる。さらに、ＣＡＮは車載の標準の基幹ネットワークとして定着しているので、他の通信方式に移行することは難しい。
【０００５】
そこで、本発明は、ＣＡＮにおけるフォーマットの互換性確保とセキュリティ性向上を両立させた保護通信方法を提供することを課題とする。
【課題を解決するための手段】
【０００６】
本発明に係る保護通信方法は、ＣＡＮ通信プロトコルに基づいて送受信されるデータを保護するための保護通信方法であって、メッセージ認証コードを生成する生成ステップと、生成ステップで生成したメッセージ認証コードと送信データを暗号化する暗号化ステップと、暗号化ステップで暗号化したメッセージ認証コードをＣＡＮ通信プロトコルの拡張フォーマットの識別子拡張領域に格納し、暗号化ステップで暗号化した送信データを拡張フォーマットのデータ領域に格納する格納ステップと、格納ステップで格納した拡張フォーマットでメッセージを送信する送信ステップとを含むこと特徴とする。
【０００７】
この保護通信方法では、生成ステップでメッセージ認証コードを生成し、暗号化ステップでメッセージ認証コードと送信データをそれぞれ暗号化する。そして、保護通信方法では、格納ステップで少なくとも暗号化したメッセージ認証コードを拡張フォーマットの識別子拡張領域に格納するとともに暗号化した送信データを拡張フォーマットのデータ領域に格納し、送信ステップでその拡張フォーマットでメッセージを送信する。この際、拡張フォーマットの識別子ベース領域には、標準フォーマット互換の識別子（ＩＤ）が格納される。したがって、ＣＡＮのハードウェアでは拡張フォーマットとして処理でき、ＣＡＮに接続される各ノードのアプリケーションソフトウェアでは拡張フォーマットの識別子ベース領域に格納される標準フォーマット互換の識別子（ＩＤ）を用いて標準フォーマットと同等に処理できる。また、拡張フォーマットの識別子拡張領域に格納される暗号化したメッセージ認証コードを用いてメッセージを認証でき、メッセージの安全性を向上できる。さらに、メッセージ認証コードを暗号化することにより、少ないデータ量でもメッセージの安全性を向上でき、拡張フォーマットの識張子拡張領域内において暗号化メッセージ認証コードを格納する領域を確保でき、拡張フォーマットのデータ領域にメッセージ認証コードを格納しなくてよい。また、送信データを暗号化することにより、送信データの安全性を向上できる。このように、保護通信方法では、メッセージ認証コードと送信データを暗号化し、この暗号化したメッセージ認証コードと送信データを拡張フォーマットを利用して送信することにより、ＣＡＮにおけるフォーマットの互換性を確保しつつセキュリティ性を向上させることができる。
【０００８】
本発明の上記保護通信方法では、格納ステップではワーク鍵ＩＤ、メッセージの通し番号をＣＡＮ通信プロトコルの拡張フォーマットの識別子拡張領域に格納し、送信ステップで送信された拡張フォーマットのメッセージを受信したノードにおいて、通し番号の検証又はメッセージ認証コードの検証で異常を検出した場合、防御モードに移行する。
【０００９】
この保護通信方法では、格納ステップで拡張フォーマットの識別子拡張領域に暗号化メッセージ認証コードの他にワーク鍵ＩＤとメッセージの通し番号を格納し、送信ステップでその拡張フォーマットでメッセージを送信する。ＣＡＮバスに接続する各ノードでは、この拡張フォーマットのメッセージを受信した場合、メッセージの通し番号で検証するとともにメッセージ認証コードを用いて検証し、少なくとも一方の検証で異常を検出した場合には防御モードに移行する。このように、保護通信方式では、通し番号とメッセージ認証コードによってメッセージを検証することにより、再送攻撃等の不正メッセージを高精度に検出でき、メッセージの安全性を向上でき、セキュリティ性がより向上する。
【発明の効果】
【００１０】
本発明によれば、メッセージ認証コードと送信データを暗号化し、この暗号化したメッセージ認証コードと送信データを拡張フォーマットを利用して送信することにより、ＣＡＮにおけるフォーマットの互換性を確保しつつセキュリティ性を向上させることができる。
【図面の簡単な説明】
【００１１】
【図１】本実施の形態に係るＣＡＮ通信システムの構成図である。
【図２】保護通信メンバＥＣＵのメモリに確保される保護通信で必要なバッファであり、（ａ）がワーク鍵関連のバッファであり、（ｂ）が送信メッセージ関連のバッファであり、（ｃ）が受信メッセージ関連のバッファである。
【図３】保護メッセージの拡張フォーマットの識別子領域である。
【図４】保護通信マスタＥＣＵにおけるワーク鍵シードメッセージ送信シーケンスのフローチャートである。
【図５】保護通信メンバＥＣＵにおけるワーク鍵シードメッセージ受信シーケンスのフローチャートである。
【図６】保護通信メンバＥＣＵにおけるメッセージ送信シーケンスのフローチャートである。
【図７】保護通信メンバＥＣＵにおけるメッセージ受信シーケンスのフローチャートである。
【発明を実施するための形態】
【００１２】
以下、図面を参照して、本発明に係る保護通信方法の実施の形態を説明する。なお、各図において同一又は相当する要素については同一の符号を付し、重複する説明を省略する。
【００１３】
本実施の形態では、本発明に係る保護通信方法を、車両に搭載されるＣＡＮ通信システムに適用する。本実施の形態に係るＣＡＮ通信システムは、ＣＡＮ２．０の通信プロトコルに基づいてメッセージを送受信する車載ＬＡＮ[Local Area Network]であり、ＣＡＮバスに複数のＥＣＵ（ノード）が接続されている。特に、本実施の形態では、ＣＡＮ通信システムにおける保護通信処理について詳細に説明する。
【００１４】
なお、ＣＡＮ２．０の通信プロトコルのデータフレームには、標準フォーマットと拡張フォーマットがある。標準フォーマット、拡張フォーマットは、データを格納するデータ領域とメッセージＩＤを格納する識別子領域（ＩＤ領域）を有している。データ領域は、０〜８バイト（０〜６４ビット）のデータを格納可能である。標準フォーマットの識別子領域は、１１ビット長である。拡張フォーマットの識別子領域は、２９ビット長である。拡張フォーマットの識別子領域は、１１ビット長の識別子ベース領域と１８ビット長の識別子拡張領域で構成される。
【００１５】
図１〜図３を参照して、本実施の形態に係るＣＡＮ通信システム１について説明する。図１は、本実施の形態に係るＣＡＮ通信システムの構成図である。図２は、保護通信メンバＥＣＵのメモリに確保される保護通信で必要なバッファであり、（ａ）がワーク鍵関連のバッファであり、（ｂ）が送信メッセージ関連のバッファであり、（ｃ）が受信メッセージ関連のバッファである。図３は、保護メッセージの拡張フォーマットの識別子領域である。
【００１６】
ＣＡＮ通信システム１は、保護通信のマスタとなる保護通信マスタＥＣＵ２と相互に保護通信を行う複数の保護通信メンバＥＣＵ３（３Ａ，３Ｂ）とからなり、各ＥＣＵ２，３がＣＡＮバス４に接続されている。また、ＣＡＮ通信システム１は、保守用のＯＢＤ−IIポート５やＥＣＵ追加のためのコネクタ（図示せず）なども備えており、これらもＣＡＮバス４に接続されている。例えば、ＯＢＤ−IIポート５に不正送信機器ＷＥが接続され、ＯＢＤ−IIポート５からＣＡＮバス４上に不正メッセージを送信することが可能である。ＣＡＮ通信システム１では、保護対象のメッセージの場合、そのような不正メッセージを検出し、不正メッセージを排除する保護通信を行う。本実施の形態では、各ＥＣＵ２，３に搭載される中位層のソフトウェアによる処理で保護通信のための各処理を行う。
【００１７】
保護通信マスタＥＣＵ２では、周期的に、ワーク鍵シードを格納してワーク鍵シードメッセージを送信する。保護通信メンバＥＣＵ３では、ワーク鍵シードメッセージを受信すると、ワーク鍵シードからワーク鍵を生成する（周期的にワーク鍵を更新する）。保護メッセージを送信する場合、保護通信メンバＥＣＵ３Ａでは、ＭＡＣを生成し、ＭＡＣと送信データ本体を暗号化し、拡張フォーマットのデータ領域に暗号化した送信データ本体を格納するとともに拡張フォーマットの識別子拡張領域にワーク鍵ＩＤ、通し番号、暗号化したＭＡＣを格納してメッセージを送信する。保護メッセージを受信した場合、保護通信メンバＥＣＵ３Ｂでは、暗号化された送信データ本体とＭＡＣを復号化し、通し番号とＭＡＣで検証し、検証で異常を検出した場合には防御モードに移行する。
【００１８】
なお、ワーク鍵は、ＣＡＮ通信システム１において周期的に更新される鍵であり、本実施の形態ではストリーム暗号化に用いる鍵ストリームを生成するために使われる。ワーク鍵ＩＤは、ワーク鍵の更新タイミングを送信側と受信側で同期をとるために用いられ、本実施の形態ではワーク鍵シードを更新（ひいては、ワーク鍵を更新）する際に０と１とで切り替えられる。ワーク鍵シードは、ワーク鍵を生成するためのシードであり、本実施の形態では６４ビットとする。通し番号は、送信側の保護通信メンバＥＣＵ３Ａが送信するメッセージＩＤ毎に付与され、同じメッセージＩＤのメッセージを送信する毎に１ずつ増加する番号であり、ワーク鍵が更新される毎にリセットされる。システム鍵は、ＣＡＮ通信システム１に接続される全てのＥＣＵが事前に持っている共有鍵である。
【００１９】
保護通信マスタＥＣＵ２は、保護通信でマスタとなるＥＣＵであり、保護通信を行うＥＣＵの中から任意のＥＣＵが選択される。保護通信マスタＥＣＵ２は、周期的に、ワーク鍵シードを生成し、ワーク鍵ＩＤを付加したワーク鍵シードメッセージを送信する。
【００２０】
具体的には、保護通信マスタＥＣＵ２では、一定時間毎に、ワーク鍵シードを生成し、標準フォーマットのデータ領域にワーク鍵シードを格納するとともに識別子領域（ＩＤ２８〜ＩＤ１８）にワーク鍵ＩＤのメッセージＩＤを格納し、ワーク鍵シードメッセージをＣＡＮバス４上に送信する。ワーク鍵シードは、例えば、６４ビット長乱数である。ワーク鍵ＩＤ＝０の場合にはメッセージＩＤを０ｘ１０とし、ワーク鍵ＩＤ＝１の場合にはメッセージＩＤを０ｘ１１とする。ワーク鍵ＩＤはワーク鍵メッセージを送信する毎（ワーク鍵シードを更新する毎）に切り替えられ、０、１、０、１・・・が繰り返される。なお、ワーク鍵シードメッセージのＣＲＣ[Cyclic Redundancy Check]は、送信時にＣＡＮのハードウェアによって付与されるものとする。
【００２１】
保護通信メンバＥＣＵ３は、相互に保護通信を行う複数のＥＣＵである。保護通信メンバＥＣＵ３は、ワーク鍵シードメッセージを受信する毎に、ワーク鍵シードメッセージからワーク鍵ＩＤとワーク鍵シードを取得し、ワーク鍵を生成する。また、送信側の保護通信メンバＥＣＵ３Ａは、保護メッセージの場合、通し番号とデータ本体のＭＡＣを計算し、データ本体と平文ＭＡＣ（ＭＡＣの一部）をワーク鍵を用いたストリーム暗号で暗号化し、暗号化データ本体の他にワーク鍵ＩＤ、通し番号、暗号化ＭＡＣを拡張フォーマットに格納して保護メッセージを送信する。また、保護通信メンバＥＣＵ３Ｂは、保護メッセージを受信すると、暗号化データ本体と暗号化ＭＡＣを復号化し、その復号化したデータ本体と通し番号のＭＡＣを計算し、計算したＭＡＣと復号化したＭＡＣとを検証するとともに通し番号を検証し、検証で異常がある場合には防御モードに移行する。
【００２２】
各保護通信メンバＥＣＵ３には、下記に示すように、メモリ上に保護通信に必要なバッファ領域がそれぞれ確保されている。保護通信メンバＥＣＵ３は、図２（ａ）に示すように、最新ワーク鍵ＩＤを管理するための最新ワーク鍵ＩＤバッファＩＢを有しており、初期値は−１である。最新ワーク鍵ＩＤバッファＩＢは、０，１，−１のうちのいずれかの値が格納され、値が−１の場合には「無効」を意味する。また、保護通信メンバＥＣＵ３は、図２（ａ）に示すように、ワーク鍵ＩＤ＝０の場合のワーク鍵を管理するためのワーク鍵０バッファＫＢ０とワーク鍵ＩＤ＝１の場合のワーク鍵を管理するためのワーク鍵１バッファＫＢ１を有しており、各バッファＫＢ０，ＫＢ１の初期値は０である。
【００２３】
また、保護通信メンバＥＣＵ３は、図２（ｂ）に示すように、保護メッセージ送信する場合の各メッセージＩＤの通し番号を管理するために受信メッセージＩＤ毎に通し番号バッファＴＮＢ１，ＴＮＢ２，ＴＮＢ３，・・・，ＴＮＢｎを有しており、初期値は０である。ＥＣＵ３毎に送信するメッセージＩＤは決まっており、ＥＣＵ３毎に送信メッセージＩＤの個数ｎは変わる。また、保護通信メンバＥＣＵ３は、図２（ｃ）に示すように、保護メッセージを受信した場合の最新のワーク鍵ＩＤを管理するために受信メッセージＩＤ毎に最新ワーク鍵ＩＤバッファＲＩＢ１，ＲＩＢ２，ＲＩＢ３，・・・，ＲＩＢｎを有しており、初期値は−１である。また、保護通信メンバＥＣＵ３は、図２（ｃ）に示すように、保護メッセージを受信した場合の最新の通し番号を管理するために受信メッセージＩＤ毎に最新通し番号バッファＲＮＢ１，ＲＮＢ２，ＲＮＢ３，・・・，ＲＮＢｎを有しており、初期値は０である。ＥＣＵ３毎に受信するメッセージＩＤは決まっており、ＥＣＵ３毎に受信メッセージＩＤの個数ｎは変わる。
【００２４】
ワーク鍵シードメッセージ受信時について具体的に説明する。ワーク鍵シードメッセージを受信すると、保護通信メンバＥＣＵ３では、ワーク鍵シードメッセージの標準フォーマットのデータ領域からワーク鍵シードを取り出し、そのワーク鍵シードを用いてワーク鍵を生成する。ワーク鍵の生成方法としては、例えば、ワーク鍵ＩＤ＝０の場合にはワーク鍵シードＳｅｅｄ０を用いて式（１）によりワーク鍵ＫＷ０を計算し、ワーク鍵ＩＤ＝１の場合にはワーク鍵シードＳｅｅｄ１を用いて式（２）によりワーク鍵ＫＷ１を計算する。式（１）、（２）のＥＫｓはシステム鍵Ｋｓを鍵としたＤＥＳ[Data Encryption Standard]などの６４ビット長ブロック暗号演算である。
ＫＷ０＝ＥＫｓ（Ｓｅｅｄ０）・・・（１）
ＫＷ１＝ＥＫｓ（Ｓｅｅｄ１）・・・（２）
【００２５】
そして、保護通信メンバＥＣＵ３では、標準フォーマットの識別子領域（ＩＤ２８〜ＩＤ１８）に格納されるメッセージＩＤが０ｘ１０（ワーク鍵ＩＤが０）の場合にはワーク鍵０バッファＫＢ０にワーク鍵を保存し、メッセージＩＤが０ｘ１１（ワーク鍵ＩＤが１）の場合にはワーク鍵１バッファＫＢ１にワーク鍵を保存する。また、保護通信メンバＥＣＵ３では、ワーク鍵ＩＤが更新される毎にそのワーク鍵ＩＤを最新ワーク鍵ＩＤバッファＩＢに保存する。また、保護通信メンバＥＣＵ３では、ワーク鍵が更新される毎（新しいワーク鍵シードを受信する毎）に、送信メッセージＩＤ毎の通し番号バッファＴＮＢ１，・・・，ＴＮＢｎを全て０でクリアする。また、保護通信メンバＥＣＵ３では、受信メッセージＩＤ毎の最新ワーク鍵ＩＤバッファＲＩＢ１，・・・，ＲＩＢｎに格納されるワーク鍵ＩＤと標準フォーマットの識別子領域（ＩＤ２８〜ＩＤ１８）に格納されるメッセージＩＤのワーク鍵ＩＤとが等しい場合（同じワーク鍵ＩＤのワーク鍵が更新された場合（新しいワーク鍵シードを受信した場合））、受信メッセージＩＤ毎の最新ワーク鍵ＩＤバッファＲＩＢ１，・・・，ＲＩＢｎを全て−１でクリアするとともに受信メッセージＩＤ毎の通し番号バッファＲＮＢ１，・・・，ＲＮＢｎを全て０でクリアする。なお、ワーク鍵シードメッセージのＣＲＣは、受信時にＣＡＮのハードウェアで検証されるものとする。
【００２６】
メッセージ送信時について具体的に説明する。送信側の保護通信メンバＥＣＵ３Ａでは、標準フォーマットのメッセージＩＤで送信する各種送信情報を収集し、収集できた送信情報からメッセージＩＤを取得する。ＣＡＮ通信システム１では、メッセージＩＤ毎に、データ領域に格納される送信情報が予め決められている。保護通信メンバＥＣＵ３Ａでは、メッセージＩＤに基づいて保護対象メッセージか否かを判定する。ＣＡＮ通信システム１では、メッセージＩＤ毎に、保護通信の対象か否か予め決められている。
【００２７】
メッセージＩＤが保護対象メッセージの場合、保護通信メンバＥＣＵ３Ａでは、送信するメッセージＩＤに対応する通し番号バッファＴＮＢｉに保存されている通し番号（前回送信時の通し番号）に１を加算し、その加算後の通し番号（今回送信時の通し番号）を通し番号バッファＴＮＢｉに保存する。保護通信メンバＥＣＵ３Ａでは、送信するメッセージＩＤ、最新のワーク鍵ＩＤ（最新ワーク鍵ＩＤバッファＩＢに格納されているワーク鍵ＩＤ）、今回送信時の通し番号及び収集された送信情報からなるデータ本体からＭＡＣを計算し、その計算したＭＡＣの下位１３ビットを平文ＭＡＣとする。ＭＡＣの計算としては、例えば、システム鍵Ｋｓを用いてＯＭＡＣ[One-Key CBC MAC]方式で計算する。保護通信メンバＥＣＵ３Ａでは、最新のワーク鍵（最新のワーク鍵ＩＤが０の場合にはワーク鍵０バッファＫＢ０に保存されているワーク鍵、最新のワーク鍵ＩＤが１の場合にはワーク鍵１バッファＫＢ１に保存されているワーク鍵）、送信するメッセージＩＤ、最新のワーク鍵ＩＤ及び今回送信時の通し番号を用いて、ストリーム暗号の鍵ストリームを生成し、データ本体と平文ＭＡＣを鍵ストリームを用いてストリーム暗号化する。ストリーム暗号としては、例えば、ブロック暗号のＯＦＢ[Output Feed Back]モードにより、メッセージＩＤとワーク鍵ＩＤと通し番号を用いて初期ベクトルを生成し、初期ベクトルと鍵（ワーク鍵）を用いて鍵ストリームを生成し、鍵ストリームと平文を結合して暗号文を生成する。
【００２８】
保護通信メンバＥＣＵ３Ａでは、図３に示すように、拡張フォーマットの識別子ベース領域（ＩＤ２８〜ＩＤ１８）に送信するメッセージＩＤ（標準フォーマット互換の１１ビットのメッセージＩＤ）を格納し、拡張フォーマットの識別子拡張領域のＩＤ１７に最新のワーク鍵ＩＤを格納し、識別子拡張領域のＩＤ１６〜ＩＤ１３に今回送信時の通し番号を格納し、識別子拡張領域のＩＤ１２〜ＩＤ０に暗号化したＭＡＣを格納し、拡張フォーマットのデータ領域に暗号化したデータ本体を格納する。そして、保護通信メンバＥＣＵ３Ａでは、拡張フォーマットでメッセージ（保護メッセージ）をＣＡＮバス４上に送信する。このように、拡張フォーマットに格納することにより、保護メッセージは、ＣＡＮ２．０の通常の拡張フォーマットと同等の形式をとる。したがって、ＣＡＮのハードウェアでは、ＣＡＮ２．０の拡張フォーマットとして処理する。なお、送信メッセージのＣＲＣは、送信時にＣＡＮのハードウェアによって付与されるものとする。
【００２９】
メッセージ受信時について具体的に説明する。メッセージを受信すると、受信側の保護通信メンバＥＣＵ３Ｂでは、識別子領域のＩＤ２８〜ＩＤ１８に格納されるメッセージＩＤに基づいて受信対象メッセージか否かを判定し、受信対象メッセージの場合には標準フォーマットか否かを判定する。
【００３０】
拡張フォーマットの場合、保護通信メンバＥＣＵ３Ｂでは、受信したメッセージＩＤに対応する最新ワーク鍵ＩＤバッファＲＩＢｉから最新のワーク鍵ＩＤを取得するとともに、受信したメッセージＩＤに対応する最新通し番号バッファＲＮＢｉから通し番号（前回受信時の通し番号）を取得する。保護通信メンバＥＣＵ３Ｂでは、拡張フォーマットの識別子拡張領域のＩＤ１７に格納されるワーク鍵ＩＤが最新のワーク鍵ＩＤ（同じメッセージＩＤのメッセージを前回受信したときのワーク鍵ＩＤ）と一致する場合、拡張フォーマットの識別子拡張領域のＩＤ１６〜ＩＤ１３に格納される通し番号が最新の通し番号（同じメッセージＩＤのメッセージを前回受信したときの通し番号）より大きい番号か否かを判定する。ワーク鍵ＩＤが前回受信時と同じで通し番号が前回受信時の通し番号以下の場合（同じメッセージＩＤのメッセージを前回受信したときとワーク鍵ＩＤが同じで通し番号が前回受信時から減っているかあるいは同じ場合）、保護通信メンバＥＣＵ３Ｂでは、受信したメッセージを不正メッセージ（攻撃メッセージ）と判断し、そのメッセージを破棄し、防御モードに移行する。
【００３１】
ワーク鍵ＩＤが前回受信時と同じで通し番号が前回受信時の通し番号より大きい場合あるいはワーク鍵ＩＤが前回受信時と異なる場合、保護通信メンバＥＣＵ３Ｂでは、受信したメッセージＩＤに対応する最新ワーク鍵ＩＤバッファＲＩＢｉに今回のワーク鍵ＩＤを保存するとともに、メッセージＩＤに対応する最新通し番号バッファＲＮＢｉに今回の通し番号を保存する。
【００３２】
保護通信メンバＥＣＵ３Ｂでは、最新のワーク鍵（最新のワーク鍵ＩＤが０の場合にはワーク鍵０バッファＫＢ０に保存されているワーク鍵、最新のワーク鍵ＩＤが１の場合にはワーク鍵１バッファＫＢ１に保存されているワーク鍵）、今回受信したメッセージＩＤ、今回受信したワーク鍵ＩＤ及び今回受信した通し番号を用いて、ストリーム暗号の鍵ストリームを生成し、拡張フォーマットのデータ領域に格納される暗号化データ本体と拡張フォーマットの識別子拡張領域のＩＤ１２〜ＩＤ０に格納される暗号化ＭＡＣを鍵ストリームを用いて復号化する。そして、保護通信メンバＥＣＵ３Ｂでは、今回受信したメッセージＩＤ、今回受信したワーク鍵ＩＤ、今回受信した通し番号及び復号化したデータ本体からＭＡＣを計算し、その計算したＭＡＣの下位１３ビットと復号化した平文ＭＡＣとを比較する。保護通信メンバＥＣＵ３Ｂでは、比較したＭＡＣが一致しない場合、受信したメッセージを不正メッセージと判断し、そのメッセージを破棄し、防御モードに移行する。また、保護通信メンバＥＣＵ３Ｂでは、比較したＭＡＣが一致する場合、上位層のアプリケーションソフトにおいて１１ビットのメッセージＩＤ（すなわち、標準フォーマットのデータ形式）で受信処理を行う。なお、メッセージのＣＲＣは、受信時にＣＡＮのハードウェアによって検証されているものとする。
【００３３】
図１〜図３を参照して、ＣＡＮ通信システム１における保護通信の処理の流れを説明する。ここでは、保護通信マスタＥＣＵ２におけるワーク鍵シードメッセージ送信処理について図４のフローチャートに沿って説明し、保護通信メンバＥＣＵ３におけるワーク鍵シードメッセージ受信処理について図５のフローチャートに沿って説明し、送信側の保護通信メンバＥＣＵ３Ａにおけるメッセージ送信処理については図６のフローチャートに沿って説明し、受信側の保護通信メンバＥＣＵ３Ｂにおけるメッセージ受信処理については図７のフローチャートに沿って説明する。
【００３４】
保護通信マスタＥＣＵ２では、最初に、メッセージＩＤとして０ｘ１０（ワーク鍵ＩＤ＝０）を設定する（Ｓ１０）。ワーク鍵シードメッセージの送信タイミング毎に、保護通信マスタＥＣＵ２では、ワーク鍵シード（６４ビット長乱数）を生成する（Ｓ１１）。保護通信マスタＥＣＵ２では、標準フォーマットの識別子領域にメッセージＩＤを格納し、データ領域にワーク鍵シードを格納し、ワーク鍵シードメッセージを生成する（Ｓ１２）。そして、保護通信マスタＥＣＵ２では、ワーク鍵シードメッセージを送信する（Ｓ１３）。
【００３５】
ワーク鍵シードメッセージ送信後、保護通信マスタＥＣＵ２では、次の送信タイミングまで一定時間待つ（Ｓ１４）。一定時間後、保護通信マスタＥＣＵ２では、ワーク鍵シードメッセージの最新のメッセージＩＤが０ｘ１０か否かを判定する（Ｓ１５）。保護通信マスタＥＣＵ２では、Ｓ１５にてメッセージＩＤが０ｘ１０と判定した場合にはメッセージＩＤとして０ｘ１１（ワーク鍵ＩＤ＝１）を設定し（Ｓ１６）、Ｓ１５にてメッセージＩＤが０ｘ１１と判定した場合にはメッセージＩＤとして０ｘ１０（ワーク鍵ＩＤ＝０）を設定する（Ｓ１７）。そして、保護通信マスタＥＣＵ２では、上記したように、ワーク鍵シードを生成し（Ｓ１１）、そのワーク鍵シードにメッセージＩＤを付加してワーク鍵シードメッセージを生成し（Ｓ１２）、ワーク鍵シードメッセージを送信する（Ｓ１３）。
【００３６】
このように、保護通信マスタＥＣＵ２では、周期的に、ワーク鍵シードを更新し、ワーク鍵シードを更新する毎にメッセージＩＤ（ワーク鍵ＩＤ）を切り替えて、ワーク鍵シードメッセージを保護通信メンバＥＣＵ３に送信する。
【００３７】
ワーク鍵シードメッセージを受信する毎に（Ｓ２０）、全ての保護通信メンバＥＣＵ３では、ワーク鍵シードメッセージの標準フォーマットの識別子領域に格納されるメッセージＩＤが０ｘ１０か否かを判定する（Ｓ２１）。保護通信メンバＥＣＵ３では、Ｓ２１にてメッセージＩＤが０ｘ１０と判定した場合にはワーク鍵ＩＤを０とし（Ｓ２２）、Ｓ２１にてメッセージＩＤが０ｘ１１と判定した場合にはワーク鍵ＩＤを１とする（Ｓ２３）。
【００３８】
保護通信メンバＥＣＵ３では、ワーク鍵シードメッセージの標準フォーマットのデータ領域からワーク鍵シードを取得し（Ｓ２４）、そのワーク鍵シードを用いてワーク鍵を生成する（Ｓ２５）。保護通信メンバＥＣＵ３では、Ｓ２２又はＳ２３で取得したワーク鍵ＩＤに対応するワーク鍵バッファＫＢｊに生成したワーク鍵を保存する（Ｓ２６）。
【００３９】
保護通信メンバＥＣＵ３では、全ての送信メッセージＩＤに対応する通し番号バッファＴＮＢ１，・・・，ＴＮＢｎの通し番号を０でクリアする（Ｓ２７）。また、保護通信メンバＥＣＵ３では、全ての受信メッセージに対応する最新ワーク鍵ＩＤバッファＲＴＢ１，・・・，ＲＴＢｎに保存されているワーク鍵ＩＤがＳ２２又はＳ２３で取得したワーク鍵ＩＤと等しい場合、全ての受信メッセージに対応する最新ワーク鍵ＩＤバッファＲＴＢ１，・・・，ＲＴＢｎのワーク鍵ＩＤを−１でクリアし、全ての受信メッセージに対応する最新通し番号バッファＲＮＢ１，・・・，ＲＮＢｎの通し番号を０でクリアする（Ｓ２８）。最後に、保護通信メンバＥＣＵ３では、最新ワーク鍵ＩＤバッファＩＢにＳ２２又はＳ２３で取得したワーク鍵ＩＤを保存する（Ｓ２９）。
【００４０】
このように、全ての保護通信メンバＥＣＵ３では、周期的に、ワーク鍵シードメッセージを受信し、ワーク鍵シードからワーク鍵を更新するとともにワーク鍵ＩＤも切り替えられる。
【００４１】
送信側の保護通信メンバＥＣＵ３Ａでは、標準フォーマットのメッセージＩＤで送信する各種送信情報を収集する（Ｓ４０）。そして、保護通信メンバＥＣＵ３Ａでは、収集できた送信情報からメッセージＩＤを取得する（Ｓ４１）。保護通信メンバＥＣＵ３Ａでは、そのメッセージＩＤに基づいて保護対象メッセージか否かを判定する（Ｓ４２）。Ｓ４２にて保護対象メッセージでないと判定した場合、保護通信メンバＥＣＵ３Ａでは、標準フォーマットの識別子領域にメッセージＩＤを格納し、標準フォーマットのデータ領域に収集した送信情報のデータを格納し、標準フォーマットでメッセージを送信する（Ｓ４３）。
【００４２】
Ｓ４２にて保護対象メッセージと判定した場合、保護通信メンバＥＣＵ３Ａでは、最新ワーク鍵ＩＤバッファＩＢから最新のワーク鍵ＩＤを取得する（Ｓ４４）。また、保護通信メンバＥＣＵ３Ａでは、送信するメッセージＩＤに対応する通し番号バッファＴＮＢｉから通し番号を取得し、その取得した通し番号に１を加算し、その加算後の通し番号を通し番号バッファＴＮＢｉに保存する（Ｓ４５）。
【００４３】
保護通信メンバＥＣＵ３Ａでは、送信するメッセージＩＤと最新のワーク鍵ＩＤと加算後の通し番号と収集できた送信情報によるデータ領域のデータからＭＡＣを生成し、生成したＭＡＣの下位１３ビットを平文ＭＡＣとする（Ｓ４６）。また、保護通信メンバＥＣＵ３Ａでは、最新のワーク鍵ＩＤに対応するワーク鍵バッファＫＢｊからワーク鍵を取得し、そのワーク鍵と送信するメッセージＩＤと最新のワーク鍵ＩＤと加算後の通し番号からストリーム暗号の鍵ストリームを生成する（Ｓ４７）。そして、保護通信メンバＥＣＵ３Ａでは、収集した送信情報によるデータ領域のデータと平文ＭＡＣを鍵ストリームを用いてそれぞれ暗号化する（Ｓ４８）。
【００４４】
保護通信メンバＥＣＵ３Ａでは、拡張フォーマットのデータ領域に暗号化したデータを入れ、拡張フォーマットの識別子ベース領域（ＩＤ２８〜ＩＤ１８）にメッセージＩＤを入れ、拡張フォーマットの識別子拡張領域（ＩＤ１７〜ＩＤ０）に最新のワーク鍵ＩＤと加算後の通し場号と暗号化したＭＡＣを入れ、拡張フォーマットでメッセージを送信する（Ｓ４９）。
【００４５】
このように、メッセージを送信する場合、保護通信メンバＥＣＵ３Ａでは、そのメッセージが保護対象の場合には、通し番号とデータ本体を含むＭＡＣを生成し、そのＭＡＣの一部とデータ本体をワーク鍵を用いたストリーム暗号で暗号化し、拡張フォーマットの識別子拡張領域を利用してワーク鍵ＩＤ、通し番号、暗号化ＭＡＣ（セキュリティに関するデータ）を入れて、拡張フォーマットでメッセージを送信する。この際、保護通信メンバＥＣＵ３ＡのＣＡＮのハードウェアでは、拡張フォーマットとして送信処理を行う。また、保護通信メンバＥＣＵ３Ａの上位層のアプリケーションソフトウェアからは、メッセージＩＤが標準フォーマットと同じく１１ビットとなる。
【００４６】
受信側の保護通信メンバＥＣＵ３Ｂでは、メッセージを受信する毎に（Ｓ６０）、ＩＤ２８〜ＩＤ１８に格納されているメッセージＩＤに基づいて受信対象のメッセージか否かを判定する（Ｓ６１）。Ｓ６１にて受信対象のメッセージでないと判定した場合、保護通信メンバＥＣＵ３Ｂでは、処理を終了する。
【００４７】
Ｓ６１にて受信対象のメッセージと判定した場合、保護通信メンバＥＣＵ３Ｂでは、メッセージが標準フォーマットか否かを判定する（Ｓ６２）。Ｓ６２にて標準フォーマットと判定した場合、保護通信メンバＥＣＵ３Ｂでは、上位層のアプリケーションソフトウェアが標準フォーマットの通常の受信処理を行う（Ｓ６３）。
【００４８】
Ｓ６２にて拡張フォーマットと判定した場合、保護通信メンバＥＣＵ３Ｂでは、拡張フォーマットの識別子ベース領域（ＩＤ２８〜ＩＤ１８）の受信メッセージＩＤに対応する最新ワーク鍵ＩＤバッファＲＩＢｉと最新通し番号バッファＲＮＢｉからワーク鍵ＩＤと通し番号の組を取得する（Ｓ６４）。そして、保護通信メンバＥＣＵ３Ｂでは、拡張フォーマットの識別子拡張領域のＩＤ１７のデータと取得したワーク鍵ＩＤとが一致するか否かを判定する（Ｓ６５）。Ｓ６５にて一致すると判定した場合、保護通信メンバＥＣＵ３Ｂでは、拡張フォーマットの識別子拡張領域のＩＤ１６〜ＩＤ１３のデータが取得した通し番号より大きいか否かを判定する（Ｓ６６）。Ｓ６６にてＩＤ１６〜ＩＤ１３のデータが取得した通し番号以下と判定した場合、保護通信メンバＥＣＵ３Ｂでは、受信したメッセージを廃棄し、防御モードに移行する（Ｓ７３）。
【００４９】
Ｓ６５にて一致しないと判定した場合又はＳ６６にてＩＤ１６〜ＩＤ１３のデータが取得した通し番号より大きいと判定した場合、保護通信メンバＥＣＵ３Ｂでは、受信メッセージＩＤに対応する最新ワーク鍵ＩＤバッファＲＩＢｉに拡張フォーマットの識別子拡張領域のＩＤ１７のデータ（今回受信したワーク鍵ＩＤ）を保存し、最新通し番号バッファＲＮＢｉに拡張フォーマットの識別子拡張領域のＩＤ１６〜ＩＤ１３のデータ（今回受信した通し番号）を保存する（Ｓ６７）。
【００５０】
保護通信メンバＥＣＵ３Ｂでは、ワーク鍵ＩＤに対応するワーク鍵バッファＫＢｊからワーク鍵を取得し、そのワーク鍵と受信したメッセージＩＤと受信したワーク鍵ＩＤと受信した通し番号からストリーム暗号の鍵ストリームを生成する（Ｓ６８）。そして、保護通信メンバＥＣＵ３Ｂでは、受信メッセージの拡張フォーマットのデータ領域の暗号化データと拡張フォーマットの識別子拡張領域のＩＤ１２〜ＩＤ０の暗号化ＭＡＣを鍵ストリームを用いてそれぞれ復号化する（Ｓ６９）。さらに、保護通信メンバＥＣＵ３Ｂでは、受信したメッセージＩＤと受信したワーク鍵ＩＤと受信した通し番号と復号化したデータからＭＡＣを生成し、生成したＭＡＣの下位１３ビットと復号化した平文ＭＡＣとを比較する（Ｓ７０）。そして、保護通信メンバＥＣＵ３Ｂでは、Ｓ７０で比較した結果、ＭＡＣが等しいか否かを判定する（Ｓ７１）。
【００５１】
Ｓ７１にてＭＡＣが等しいと判定した場合、保護通信メンバＥＣＵ３Ｂでは、上位層のアプリケーションソフトウェアが１１ビットのメッセージＩＤとして標準フォーマットのデータ形式で受信処理を行う（Ｓ７２）。一方、Ｓ７１にてＭＡＣが等しくないと判定した場合、保護通信メンバＥＣＵ３Ｂでは、受信したメッセージを廃棄し、防御モードに移行する（Ｓ７３）。
【００５２】
このように、拡張フォーマットでメッセージを受信した場合、保護通信メンバＥＣＵ３Ｂでは、通し番号とＭＡＣによる検証で不正メッセージか否かを判定し、不正メッセージと判定した場合には防御モードに移行する。この際、保護通信メンバＥＣＵ３ＢのＣＡＮのハードウェアでは、拡張フォーマットとして受信処理を行う。また、保護通信メンバＥＣＵ３Ｂの上位層のアプリケーションソフトウェアでは、標準フォーマットと同等の１１ビットのメッセージＩＤとして受信処理を行う。
【００５３】
このＣＡＮ通信システム１によれば、ＭＡＣとデータ本体を暗号化し、この暗号化したＭＡＣとデータ本体を拡張フォーマットを利用して送信することにより、ＣＡＮにおけるフォーマットの互換性を確保しつつセキュリティ性を向上させることができる。また、ＣＡＮ通信システム１によれば、メッセージＩＤ毎の通し番号とＭＡＣによってメッセージを検証することにより、再送攻撃等の不正メッセージを高精度に検出でき、メッセージの安全性を向上でき、セキュリティ性がより向上する。また、ＣＡＮ通信システム１によれば、各ＥＣＵ２，３におけるソフトウェアによる処理だけで簡易に保護通信を行うことができる。
【００５４】
特に、ＣＡＮ通信システム１によれば、ＣＡＮのハードウェアが拡張フォーマットとして処理できるとともに、各保護通信メンバＥＣＵ３の上位層のアプリケーションソフトウェアが拡張フォーマットの識別子ベース領域に格納される標準フォーマット互換のメッセージＩＤ（１１ビット）を用いて標準フォーマットと同等に受信処理できる。さらに、ＣＡＮ通信システム１によれば、ＭＡＣを暗号化しているので、少ないデータ量でもメッセージの安全性を確保できる。したがって、拡張フォーマットの識張子拡張領域内に暗号化ＭＡＣや通し番号を格納する領域を確保でき、拡張フォーマットのデータ領域にＭＡＣ等を格納しなくてよいので、拡張フォーマットのデータ領域には通常と同様にデータを格納でき、データ領域の互換性も確保できる。また、ＣＡＮ通信システム１によれば、データ本体を暗号化しているので、データ本体の安全性も向上できる。
【００５５】
さらに、ＣＡＮ通信システム１によれば、保護通信マスタＥＣＵ２から周期的に更新したワーク鍵シードを送信することにより、保護通信メンバＥＣＵ３で周期的にワーク鍵を更新でき、ワーク鍵の安全性を確保できる。また、ＣＡＮ通信システム１によれば、ワーク鍵シードを更新する毎にワーク鍵ＩＤを０と１で切り替えることにより、メッセージの送信側と受信側とでワーク鍵の更新の同期をとることができる。
【００５６】
以上、本発明に係る実施の形態について説明したが、本発明は上記実施の形態に限定されることなく様々な形態で実施される。
【００５７】
例えば、本実施の形態では車両に搭載されるＣＡＮ通信システムに適用したが、車両以外のＣＡＮにも適用可能である。また、本実施の形態ではソフトウェアで保護通信のための各処理を行う構成としたが、処理の一部（例えば、暗号化処理）をＣＡＮのハードウェアで行ってもよい。
【００５８】
また、本実施の形態ではワーク鍵を更新する際に送信側と受信側で同期をとるために、ワーク鍵ＩＤを導入し、ワーク鍵ＩＤを０と１で切り替える手法を適用したが、他の手法を用いてもよい。また、本実施の形態ではＭＡＣと通し番号を用いてメッセージを検証したが、ＭＡＣによる検証だけでもよい。この場合、拡張フォーマットの識別子拡張領域には少なくとも暗号化ＭＡＣを格納すればよい。
【００５９】
また、本実施の形態ではメッセージＩＤ、ワーク鍵ＩＤ、通し番号、データ本体からＭＡＣを生成したが、この組み合わせ以外でＭＡＣを生成してもよい。また、本実施の形態ではワーク鍵、メッセージＩＤ、ワーク鍵ＩＤ、通し番号から鍵ストリームを生成したが、この組み合わせ以外で鍵ストリームを生成してもよい。また、本実施の形態ではストリーム暗号を適用したが、他の暗号方法を適用してもよい。
【００６０】
また、本実施の形態では保護通信マスタＥＣＵでワーク鍵シードを更新する毎にワーク鍵シードメッセージを一度だけ保護通信メンバＥＣＵに送信する構成としたが、保護通信メンバＥＣＵでワーク鍵シードメッセージを確実に受信するために、保護通信マスタＥＣＵから同じワーク鍵シードメッセージを複数回送信するようにしてもよい。
【符号の説明】
【００６１】
１…ＣＡＮ通信システム、２…保護通信マスタＥＣＵ、３，３Ａ，３Ｂ…保護通信メンバＥＣＵ、４…ＣＡＮバス、５…ＯＢＤ−IIポート。
【技術分野】
【０００１】
本発明は、ＣＡＮ通信プロトコルに基づいて送受信されるデータを保護するための保護通信方法に関する。
【背景技術】
【０００２】
車載のＥＣＵ[Electronic Control Unit]間の基幹ネットワークとして、一般に、ＣＡＮ[Controller Area Network]が用いられている。ＣＡＮには、ＯＢＤ[OnBoard Diagnosis]のためのインタフェースやＥＣＵ追加のためのコネクタも用意されている。このような箇所からＣＡＮに接続し、外部から不正メッセージを送信することも可能である。このような不正メッセージを排除してセキュリティ性を向上させるために、一般に、メッセージにＭＡＣ[Message Authentication Code]（メッセージ認証コード）を付与する手法がある。特許文献１には、ネットワークにおけるデータ通信においてＭＡＣを暗号化して送信する技術が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開平７−２９７８１９号公報
【特許文献２】特開２０１０−１８７３２７号公報
【特許文献３】特開２０１０−２５８９９０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
セキュリティ性を向上させるためには、上記のようにＭＡＣ等のセキュリティに関するデータを追加する必要がある。しかし、ＣＡＮの場合、標準フォーマットが決まっており、データ領域に格納可能なデータは最大８バイトであり、データ領域に格納するデータは決まっているので、データ領域に安全な長さのＭＡＣを格納することは困難である。また、ＭＡＣを付加するために、送信データ量を大幅に増加すると、コストアップにつながる。さらに、ＣＡＮは車載の標準の基幹ネットワークとして定着しているので、他の通信方式に移行することは難しい。
【０００５】
そこで、本発明は、ＣＡＮにおけるフォーマットの互換性確保とセキュリティ性向上を両立させた保護通信方法を提供することを課題とする。
【課題を解決するための手段】
【０００６】
本発明に係る保護通信方法は、ＣＡＮ通信プロトコルに基づいて送受信されるデータを保護するための保護通信方法であって、メッセージ認証コードを生成する生成ステップと、生成ステップで生成したメッセージ認証コードと送信データを暗号化する暗号化ステップと、暗号化ステップで暗号化したメッセージ認証コードをＣＡＮ通信プロトコルの拡張フォーマットの識別子拡張領域に格納し、暗号化ステップで暗号化した送信データを拡張フォーマットのデータ領域に格納する格納ステップと、格納ステップで格納した拡張フォーマットでメッセージを送信する送信ステップとを含むこと特徴とする。
【０００７】
この保護通信方法では、生成ステップでメッセージ認証コードを生成し、暗号化ステップでメッセージ認証コードと送信データをそれぞれ暗号化する。そして、保護通信方法では、格納ステップで少なくとも暗号化したメッセージ認証コードを拡張フォーマットの識別子拡張領域に格納するとともに暗号化した送信データを拡張フォーマットのデータ領域に格納し、送信ステップでその拡張フォーマットでメッセージを送信する。この際、拡張フォーマットの識別子ベース領域には、標準フォーマット互換の識別子（ＩＤ）が格納される。したがって、ＣＡＮのハードウェアでは拡張フォーマットとして処理でき、ＣＡＮに接続される各ノードのアプリケーションソフトウェアでは拡張フォーマットの識別子ベース領域に格納される標準フォーマット互換の識別子（ＩＤ）を用いて標準フォーマットと同等に処理できる。また、拡張フォーマットの識別子拡張領域に格納される暗号化したメッセージ認証コードを用いてメッセージを認証でき、メッセージの安全性を向上できる。さらに、メッセージ認証コードを暗号化することにより、少ないデータ量でもメッセージの安全性を向上でき、拡張フォーマットの識張子拡張領域内において暗号化メッセージ認証コードを格納する領域を確保でき、拡張フォーマットのデータ領域にメッセージ認証コードを格納しなくてよい。また、送信データを暗号化することにより、送信データの安全性を向上できる。このように、保護通信方法では、メッセージ認証コードと送信データを暗号化し、この暗号化したメッセージ認証コードと送信データを拡張フォーマットを利用して送信することにより、ＣＡＮにおけるフォーマットの互換性を確保しつつセキュリティ性を向上させることができる。
【０００８】
本発明の上記保護通信方法では、格納ステップではワーク鍵ＩＤ、メッセージの通し番号をＣＡＮ通信プロトコルの拡張フォーマットの識別子拡張領域に格納し、送信ステップで送信された拡張フォーマットのメッセージを受信したノードにおいて、通し番号の検証又はメッセージ認証コードの検証で異常を検出した場合、防御モードに移行する。
【０００９】
この保護通信方法では、格納ステップで拡張フォーマットの識別子拡張領域に暗号化メッセージ認証コードの他にワーク鍵ＩＤとメッセージの通し番号を格納し、送信ステップでその拡張フォーマットでメッセージを送信する。ＣＡＮバスに接続する各ノードでは、この拡張フォーマットのメッセージを受信した場合、メッセージの通し番号で検証するとともにメッセージ認証コードを用いて検証し、少なくとも一方の検証で異常を検出した場合には防御モードに移行する。このように、保護通信方式では、通し番号とメッセージ認証コードによってメッセージを検証することにより、再送攻撃等の不正メッセージを高精度に検出でき、メッセージの安全性を向上でき、セキュリティ性がより向上する。
【発明の効果】
【００１０】
本発明によれば、メッセージ認証コードと送信データを暗号化し、この暗号化したメッセージ認証コードと送信データを拡張フォーマットを利用して送信することにより、ＣＡＮにおけるフォーマットの互換性を確保しつつセキュリティ性を向上させることができる。
【図面の簡単な説明】
【００１１】
【図１】本実施の形態に係るＣＡＮ通信システムの構成図である。
【図２】保護通信メンバＥＣＵのメモリに確保される保護通信で必要なバッファであり、（ａ）がワーク鍵関連のバッファであり、（ｂ）が送信メッセージ関連のバッファであり、（ｃ）が受信メッセージ関連のバッファである。
【図３】保護メッセージの拡張フォーマットの識別子領域である。
【図４】保護通信マスタＥＣＵにおけるワーク鍵シードメッセージ送信シーケンスのフローチャートである。
【図５】保護通信メンバＥＣＵにおけるワーク鍵シードメッセージ受信シーケンスのフローチャートである。
【図６】保護通信メンバＥＣＵにおけるメッセージ送信シーケンスのフローチャートである。
【図７】保護通信メンバＥＣＵにおけるメッセージ受信シーケンスのフローチャートである。
【発明を実施するための形態】
【００１２】
以下、図面を参照して、本発明に係る保護通信方法の実施の形態を説明する。なお、各図において同一又は相当する要素については同一の符号を付し、重複する説明を省略する。
【００１３】
本実施の形態では、本発明に係る保護通信方法を、車両に搭載されるＣＡＮ通信システムに適用する。本実施の形態に係るＣＡＮ通信システムは、ＣＡＮ２．０の通信プロトコルに基づいてメッセージを送受信する車載ＬＡＮ[Local Area Network]であり、ＣＡＮバスに複数のＥＣＵ（ノード）が接続されている。特に、本実施の形態では、ＣＡＮ通信システムにおける保護通信処理について詳細に説明する。
【００１４】
なお、ＣＡＮ２．０の通信プロトコルのデータフレームには、標準フォーマットと拡張フォーマットがある。標準フォーマット、拡張フォーマットは、データを格納するデータ領域とメッセージＩＤを格納する識別子領域（ＩＤ領域）を有している。データ領域は、０〜８バイト（０〜６４ビット）のデータを格納可能である。標準フォーマットの識別子領域は、１１ビット長である。拡張フォーマットの識別子領域は、２９ビット長である。拡張フォーマットの識別子領域は、１１ビット長の識別子ベース領域と１８ビット長の識別子拡張領域で構成される。
【００１５】
図１〜図３を参照して、本実施の形態に係るＣＡＮ通信システム１について説明する。図１は、本実施の形態に係るＣＡＮ通信システムの構成図である。図２は、保護通信メンバＥＣＵのメモリに確保される保護通信で必要なバッファであり、（ａ）がワーク鍵関連のバッファであり、（ｂ）が送信メッセージ関連のバッファであり、（ｃ）が受信メッセージ関連のバッファである。図３は、保護メッセージの拡張フォーマットの識別子領域である。
【００１６】
ＣＡＮ通信システム１は、保護通信のマスタとなる保護通信マスタＥＣＵ２と相互に保護通信を行う複数の保護通信メンバＥＣＵ３（３Ａ，３Ｂ）とからなり、各ＥＣＵ２，３がＣＡＮバス４に接続されている。また、ＣＡＮ通信システム１は、保守用のＯＢＤ−IIポート５やＥＣＵ追加のためのコネクタ（図示せず）なども備えており、これらもＣＡＮバス４に接続されている。例えば、ＯＢＤ−IIポート５に不正送信機器ＷＥが接続され、ＯＢＤ−IIポート５からＣＡＮバス４上に不正メッセージを送信することが可能である。ＣＡＮ通信システム１では、保護対象のメッセージの場合、そのような不正メッセージを検出し、不正メッセージを排除する保護通信を行う。本実施の形態では、各ＥＣＵ２，３に搭載される中位層のソフトウェアによる処理で保護通信のための各処理を行う。
【００１７】
保護通信マスタＥＣＵ２では、周期的に、ワーク鍵シードを格納してワーク鍵シードメッセージを送信する。保護通信メンバＥＣＵ３では、ワーク鍵シードメッセージを受信すると、ワーク鍵シードからワーク鍵を生成する（周期的にワーク鍵を更新する）。保護メッセージを送信する場合、保護通信メンバＥＣＵ３Ａでは、ＭＡＣを生成し、ＭＡＣと送信データ本体を暗号化し、拡張フォーマットのデータ領域に暗号化した送信データ本体を格納するとともに拡張フォーマットの識別子拡張領域にワーク鍵ＩＤ、通し番号、暗号化したＭＡＣを格納してメッセージを送信する。保護メッセージを受信した場合、保護通信メンバＥＣＵ３Ｂでは、暗号化された送信データ本体とＭＡＣを復号化し、通し番号とＭＡＣで検証し、検証で異常を検出した場合には防御モードに移行する。
【００１８】
なお、ワーク鍵は、ＣＡＮ通信システム１において周期的に更新される鍵であり、本実施の形態ではストリーム暗号化に用いる鍵ストリームを生成するために使われる。ワーク鍵ＩＤは、ワーク鍵の更新タイミングを送信側と受信側で同期をとるために用いられ、本実施の形態ではワーク鍵シードを更新（ひいては、ワーク鍵を更新）する際に０と１とで切り替えられる。ワーク鍵シードは、ワーク鍵を生成するためのシードであり、本実施の形態では６４ビットとする。通し番号は、送信側の保護通信メンバＥＣＵ３Ａが送信するメッセージＩＤ毎に付与され、同じメッセージＩＤのメッセージを送信する毎に１ずつ増加する番号であり、ワーク鍵が更新される毎にリセットされる。システム鍵は、ＣＡＮ通信システム１に接続される全てのＥＣＵが事前に持っている共有鍵である。
【００１９】
保護通信マスタＥＣＵ２は、保護通信でマスタとなるＥＣＵであり、保護通信を行うＥＣＵの中から任意のＥＣＵが選択される。保護通信マスタＥＣＵ２は、周期的に、ワーク鍵シードを生成し、ワーク鍵ＩＤを付加したワーク鍵シードメッセージを送信する。
【００２０】
具体的には、保護通信マスタＥＣＵ２では、一定時間毎に、ワーク鍵シードを生成し、標準フォーマットのデータ領域にワーク鍵シードを格納するとともに識別子領域（ＩＤ２８〜ＩＤ１８）にワーク鍵ＩＤのメッセージＩＤを格納し、ワーク鍵シードメッセージをＣＡＮバス４上に送信する。ワーク鍵シードは、例えば、６４ビット長乱数である。ワーク鍵ＩＤ＝０の場合にはメッセージＩＤを０ｘ１０とし、ワーク鍵ＩＤ＝１の場合にはメッセージＩＤを０ｘ１１とする。ワーク鍵ＩＤはワーク鍵メッセージを送信する毎（ワーク鍵シードを更新する毎）に切り替えられ、０、１、０、１・・・が繰り返される。なお、ワーク鍵シードメッセージのＣＲＣ[Cyclic Redundancy Check]は、送信時にＣＡＮのハードウェアによって付与されるものとする。
【００２１】
保護通信メンバＥＣＵ３は、相互に保護通信を行う複数のＥＣＵである。保護通信メンバＥＣＵ３は、ワーク鍵シードメッセージを受信する毎に、ワーク鍵シードメッセージからワーク鍵ＩＤとワーク鍵シードを取得し、ワーク鍵を生成する。また、送信側の保護通信メンバＥＣＵ３Ａは、保護メッセージの場合、通し番号とデータ本体のＭＡＣを計算し、データ本体と平文ＭＡＣ（ＭＡＣの一部）をワーク鍵を用いたストリーム暗号で暗号化し、暗号化データ本体の他にワーク鍵ＩＤ、通し番号、暗号化ＭＡＣを拡張フォーマットに格納して保護メッセージを送信する。また、保護通信メンバＥＣＵ３Ｂは、保護メッセージを受信すると、暗号化データ本体と暗号化ＭＡＣを復号化し、その復号化したデータ本体と通し番号のＭＡＣを計算し、計算したＭＡＣと復号化したＭＡＣとを検証するとともに通し番号を検証し、検証で異常がある場合には防御モードに移行する。
【００２２】
各保護通信メンバＥＣＵ３には、下記に示すように、メモリ上に保護通信に必要なバッファ領域がそれぞれ確保されている。保護通信メンバＥＣＵ３は、図２（ａ）に示すように、最新ワーク鍵ＩＤを管理するための最新ワーク鍵ＩＤバッファＩＢを有しており、初期値は−１である。最新ワーク鍵ＩＤバッファＩＢは、０，１，−１のうちのいずれかの値が格納され、値が−１の場合には「無効」を意味する。また、保護通信メンバＥＣＵ３は、図２（ａ）に示すように、ワーク鍵ＩＤ＝０の場合のワーク鍵を管理するためのワーク鍵０バッファＫＢ０とワーク鍵ＩＤ＝１の場合のワーク鍵を管理するためのワーク鍵１バッファＫＢ１を有しており、各バッファＫＢ０，ＫＢ１の初期値は０である。
【００２３】
また、保護通信メンバＥＣＵ３は、図２（ｂ）に示すように、保護メッセージ送信する場合の各メッセージＩＤの通し番号を管理するために受信メッセージＩＤ毎に通し番号バッファＴＮＢ１，ＴＮＢ２，ＴＮＢ３，・・・，ＴＮＢｎを有しており、初期値は０である。ＥＣＵ３毎に送信するメッセージＩＤは決まっており、ＥＣＵ３毎に送信メッセージＩＤの個数ｎは変わる。また、保護通信メンバＥＣＵ３は、図２（ｃ）に示すように、保護メッセージを受信した場合の最新のワーク鍵ＩＤを管理するために受信メッセージＩＤ毎に最新ワーク鍵ＩＤバッファＲＩＢ１，ＲＩＢ２，ＲＩＢ３，・・・，ＲＩＢｎを有しており、初期値は−１である。また、保護通信メンバＥＣＵ３は、図２（ｃ）に示すように、保護メッセージを受信した場合の最新の通し番号を管理するために受信メッセージＩＤ毎に最新通し番号バッファＲＮＢ１，ＲＮＢ２，ＲＮＢ３，・・・，ＲＮＢｎを有しており、初期値は０である。ＥＣＵ３毎に受信するメッセージＩＤは決まっており、ＥＣＵ３毎に受信メッセージＩＤの個数ｎは変わる。
【００２４】
ワーク鍵シードメッセージ受信時について具体的に説明する。ワーク鍵シードメッセージを受信すると、保護通信メンバＥＣＵ３では、ワーク鍵シードメッセージの標準フォーマットのデータ領域からワーク鍵シードを取り出し、そのワーク鍵シードを用いてワーク鍵を生成する。ワーク鍵の生成方法としては、例えば、ワーク鍵ＩＤ＝０の場合にはワーク鍵シードＳｅｅｄ０を用いて式（１）によりワーク鍵ＫＷ０を計算し、ワーク鍵ＩＤ＝１の場合にはワーク鍵シードＳｅｅｄ１を用いて式（２）によりワーク鍵ＫＷ１を計算する。式（１）、（２）のＥＫｓはシステム鍵Ｋｓを鍵としたＤＥＳ[Data Encryption Standard]などの６４ビット長ブロック暗号演算である。
ＫＷ０＝ＥＫｓ（Ｓｅｅｄ０）・・・（１）
ＫＷ１＝ＥＫｓ（Ｓｅｅｄ１）・・・（２）
【００２５】
そして、保護通信メンバＥＣＵ３では、標準フォーマットの識別子領域（ＩＤ２８〜ＩＤ１８）に格納されるメッセージＩＤが０ｘ１０（ワーク鍵ＩＤが０）の場合にはワーク鍵０バッファＫＢ０にワーク鍵を保存し、メッセージＩＤが０ｘ１１（ワーク鍵ＩＤが１）の場合にはワーク鍵１バッファＫＢ１にワーク鍵を保存する。また、保護通信メンバＥＣＵ３では、ワーク鍵ＩＤが更新される毎にそのワーク鍵ＩＤを最新ワーク鍵ＩＤバッファＩＢに保存する。また、保護通信メンバＥＣＵ３では、ワーク鍵が更新される毎（新しいワーク鍵シードを受信する毎）に、送信メッセージＩＤ毎の通し番号バッファＴＮＢ１，・・・，ＴＮＢｎを全て０でクリアする。また、保護通信メンバＥＣＵ３では、受信メッセージＩＤ毎の最新ワーク鍵ＩＤバッファＲＩＢ１，・・・，ＲＩＢｎに格納されるワーク鍵ＩＤと標準フォーマットの識別子領域（ＩＤ２８〜ＩＤ１８）に格納されるメッセージＩＤのワーク鍵ＩＤとが等しい場合（同じワーク鍵ＩＤのワーク鍵が更新された場合（新しいワーク鍵シードを受信した場合））、受信メッセージＩＤ毎の最新ワーク鍵ＩＤバッファＲＩＢ１，・・・，ＲＩＢｎを全て−１でクリアするとともに受信メッセージＩＤ毎の通し番号バッファＲＮＢ１，・・・，ＲＮＢｎを全て０でクリアする。なお、ワーク鍵シードメッセージのＣＲＣは、受信時にＣＡＮのハードウェアで検証されるものとする。
【００２６】
メッセージ送信時について具体的に説明する。送信側の保護通信メンバＥＣＵ３Ａでは、標準フォーマットのメッセージＩＤで送信する各種送信情報を収集し、収集できた送信情報からメッセージＩＤを取得する。ＣＡＮ通信システム１では、メッセージＩＤ毎に、データ領域に格納される送信情報が予め決められている。保護通信メンバＥＣＵ３Ａでは、メッセージＩＤに基づいて保護対象メッセージか否かを判定する。ＣＡＮ通信システム１では、メッセージＩＤ毎に、保護通信の対象か否か予め決められている。
【００２７】
メッセージＩＤが保護対象メッセージの場合、保護通信メンバＥＣＵ３Ａでは、送信するメッセージＩＤに対応する通し番号バッファＴＮＢｉに保存されている通し番号（前回送信時の通し番号）に１を加算し、その加算後の通し番号（今回送信時の通し番号）を通し番号バッファＴＮＢｉに保存する。保護通信メンバＥＣＵ３Ａでは、送信するメッセージＩＤ、最新のワーク鍵ＩＤ（最新ワーク鍵ＩＤバッファＩＢに格納されているワーク鍵ＩＤ）、今回送信時の通し番号及び収集された送信情報からなるデータ本体からＭＡＣを計算し、その計算したＭＡＣの下位１３ビットを平文ＭＡＣとする。ＭＡＣの計算としては、例えば、システム鍵Ｋｓを用いてＯＭＡＣ[One-Key CBC MAC]方式で計算する。保護通信メンバＥＣＵ３Ａでは、最新のワーク鍵（最新のワーク鍵ＩＤが０の場合にはワーク鍵０バッファＫＢ０に保存されているワーク鍵、最新のワーク鍵ＩＤが１の場合にはワーク鍵１バッファＫＢ１に保存されているワーク鍵）、送信するメッセージＩＤ、最新のワーク鍵ＩＤ及び今回送信時の通し番号を用いて、ストリーム暗号の鍵ストリームを生成し、データ本体と平文ＭＡＣを鍵ストリームを用いてストリーム暗号化する。ストリーム暗号としては、例えば、ブロック暗号のＯＦＢ[Output Feed Back]モードにより、メッセージＩＤとワーク鍵ＩＤと通し番号を用いて初期ベクトルを生成し、初期ベクトルと鍵（ワーク鍵）を用いて鍵ストリームを生成し、鍵ストリームと平文を結合して暗号文を生成する。
【００２８】
保護通信メンバＥＣＵ３Ａでは、図３に示すように、拡張フォーマットの識別子ベース領域（ＩＤ２８〜ＩＤ１８）に送信するメッセージＩＤ（標準フォーマット互換の１１ビットのメッセージＩＤ）を格納し、拡張フォーマットの識別子拡張領域のＩＤ１７に最新のワーク鍵ＩＤを格納し、識別子拡張領域のＩＤ１６〜ＩＤ１３に今回送信時の通し番号を格納し、識別子拡張領域のＩＤ１２〜ＩＤ０に暗号化したＭＡＣを格納し、拡張フォーマットのデータ領域に暗号化したデータ本体を格納する。そして、保護通信メンバＥＣＵ３Ａでは、拡張フォーマットでメッセージ（保護メッセージ）をＣＡＮバス４上に送信する。このように、拡張フォーマットに格納することにより、保護メッセージは、ＣＡＮ２．０の通常の拡張フォーマットと同等の形式をとる。したがって、ＣＡＮのハードウェアでは、ＣＡＮ２．０の拡張フォーマットとして処理する。なお、送信メッセージのＣＲＣは、送信時にＣＡＮのハードウェアによって付与されるものとする。
【００２９】
メッセージ受信時について具体的に説明する。メッセージを受信すると、受信側の保護通信メンバＥＣＵ３Ｂでは、識別子領域のＩＤ２８〜ＩＤ１８に格納されるメッセージＩＤに基づいて受信対象メッセージか否かを判定し、受信対象メッセージの場合には標準フォーマットか否かを判定する。
【００３０】
拡張フォーマットの場合、保護通信メンバＥＣＵ３Ｂでは、受信したメッセージＩＤに対応する最新ワーク鍵ＩＤバッファＲＩＢｉから最新のワーク鍵ＩＤを取得するとともに、受信したメッセージＩＤに対応する最新通し番号バッファＲＮＢｉから通し番号（前回受信時の通し番号）を取得する。保護通信メンバＥＣＵ３Ｂでは、拡張フォーマットの識別子拡張領域のＩＤ１７に格納されるワーク鍵ＩＤが最新のワーク鍵ＩＤ（同じメッセージＩＤのメッセージを前回受信したときのワーク鍵ＩＤ）と一致する場合、拡張フォーマットの識別子拡張領域のＩＤ１６〜ＩＤ１３に格納される通し番号が最新の通し番号（同じメッセージＩＤのメッセージを前回受信したときの通し番号）より大きい番号か否かを判定する。ワーク鍵ＩＤが前回受信時と同じで通し番号が前回受信時の通し番号以下の場合（同じメッセージＩＤのメッセージを前回受信したときとワーク鍵ＩＤが同じで通し番号が前回受信時から減っているかあるいは同じ場合）、保護通信メンバＥＣＵ３Ｂでは、受信したメッセージを不正メッセージ（攻撃メッセージ）と判断し、そのメッセージを破棄し、防御モードに移行する。
【００３１】
ワーク鍵ＩＤが前回受信時と同じで通し番号が前回受信時の通し番号より大きい場合あるいはワーク鍵ＩＤが前回受信時と異なる場合、保護通信メンバＥＣＵ３Ｂでは、受信したメッセージＩＤに対応する最新ワーク鍵ＩＤバッファＲＩＢｉに今回のワーク鍵ＩＤを保存するとともに、メッセージＩＤに対応する最新通し番号バッファＲＮＢｉに今回の通し番号を保存する。
【００３２】
保護通信メンバＥＣＵ３Ｂでは、最新のワーク鍵（最新のワーク鍵ＩＤが０の場合にはワーク鍵０バッファＫＢ０に保存されているワーク鍵、最新のワーク鍵ＩＤが１の場合にはワーク鍵１バッファＫＢ１に保存されているワーク鍵）、今回受信したメッセージＩＤ、今回受信したワーク鍵ＩＤ及び今回受信した通し番号を用いて、ストリーム暗号の鍵ストリームを生成し、拡張フォーマットのデータ領域に格納される暗号化データ本体と拡張フォーマットの識別子拡張領域のＩＤ１２〜ＩＤ０に格納される暗号化ＭＡＣを鍵ストリームを用いて復号化する。そして、保護通信メンバＥＣＵ３Ｂでは、今回受信したメッセージＩＤ、今回受信したワーク鍵ＩＤ、今回受信した通し番号及び復号化したデータ本体からＭＡＣを計算し、その計算したＭＡＣの下位１３ビットと復号化した平文ＭＡＣとを比較する。保護通信メンバＥＣＵ３Ｂでは、比較したＭＡＣが一致しない場合、受信したメッセージを不正メッセージと判断し、そのメッセージを破棄し、防御モードに移行する。また、保護通信メンバＥＣＵ３Ｂでは、比較したＭＡＣが一致する場合、上位層のアプリケーションソフトにおいて１１ビットのメッセージＩＤ（すなわち、標準フォーマットのデータ形式）で受信処理を行う。なお、メッセージのＣＲＣは、受信時にＣＡＮのハードウェアによって検証されているものとする。
【００３３】
図１〜図３を参照して、ＣＡＮ通信システム１における保護通信の処理の流れを説明する。ここでは、保護通信マスタＥＣＵ２におけるワーク鍵シードメッセージ送信処理について図４のフローチャートに沿って説明し、保護通信メンバＥＣＵ３におけるワーク鍵シードメッセージ受信処理について図５のフローチャートに沿って説明し、送信側の保護通信メンバＥＣＵ３Ａにおけるメッセージ送信処理については図６のフローチャートに沿って説明し、受信側の保護通信メンバＥＣＵ３Ｂにおけるメッセージ受信処理については図７のフローチャートに沿って説明する。
【００３４】
保護通信マスタＥＣＵ２では、最初に、メッセージＩＤとして０ｘ１０（ワーク鍵ＩＤ＝０）を設定する（Ｓ１０）。ワーク鍵シードメッセージの送信タイミング毎に、保護通信マスタＥＣＵ２では、ワーク鍵シード（６４ビット長乱数）を生成する（Ｓ１１）。保護通信マスタＥＣＵ２では、標準フォーマットの識別子領域にメッセージＩＤを格納し、データ領域にワーク鍵シードを格納し、ワーク鍵シードメッセージを生成する（Ｓ１２）。そして、保護通信マスタＥＣＵ２では、ワーク鍵シードメッセージを送信する（Ｓ１３）。
【００３５】
ワーク鍵シードメッセージ送信後、保護通信マスタＥＣＵ２では、次の送信タイミングまで一定時間待つ（Ｓ１４）。一定時間後、保護通信マスタＥＣＵ２では、ワーク鍵シードメッセージの最新のメッセージＩＤが０ｘ１０か否かを判定する（Ｓ１５）。保護通信マスタＥＣＵ２では、Ｓ１５にてメッセージＩＤが０ｘ１０と判定した場合にはメッセージＩＤとして０ｘ１１（ワーク鍵ＩＤ＝１）を設定し（Ｓ１６）、Ｓ１５にてメッセージＩＤが０ｘ１１と判定した場合にはメッセージＩＤとして０ｘ１０（ワーク鍵ＩＤ＝０）を設定する（Ｓ１７）。そして、保護通信マスタＥＣＵ２では、上記したように、ワーク鍵シードを生成し（Ｓ１１）、そのワーク鍵シードにメッセージＩＤを付加してワーク鍵シードメッセージを生成し（Ｓ１２）、ワーク鍵シードメッセージを送信する（Ｓ１３）。
【００３６】
このように、保護通信マスタＥＣＵ２では、周期的に、ワーク鍵シードを更新し、ワーク鍵シードを更新する毎にメッセージＩＤ（ワーク鍵ＩＤ）を切り替えて、ワーク鍵シードメッセージを保護通信メンバＥＣＵ３に送信する。
【００３７】
ワーク鍵シードメッセージを受信する毎に（Ｓ２０）、全ての保護通信メンバＥＣＵ３では、ワーク鍵シードメッセージの標準フォーマットの識別子領域に格納されるメッセージＩＤが０ｘ１０か否かを判定する（Ｓ２１）。保護通信メンバＥＣＵ３では、Ｓ２１にてメッセージＩＤが０ｘ１０と判定した場合にはワーク鍵ＩＤを０とし（Ｓ２２）、Ｓ２１にてメッセージＩＤが０ｘ１１と判定した場合にはワーク鍵ＩＤを１とする（Ｓ２３）。
【００３８】
保護通信メンバＥＣＵ３では、ワーク鍵シードメッセージの標準フォーマットのデータ領域からワーク鍵シードを取得し（Ｓ２４）、そのワーク鍵シードを用いてワーク鍵を生成する（Ｓ２５）。保護通信メンバＥＣＵ３では、Ｓ２２又はＳ２３で取得したワーク鍵ＩＤに対応するワーク鍵バッファＫＢｊに生成したワーク鍵を保存する（Ｓ２６）。
【００３９】
保護通信メンバＥＣＵ３では、全ての送信メッセージＩＤに対応する通し番号バッファＴＮＢ１，・・・，ＴＮＢｎの通し番号を０でクリアする（Ｓ２７）。また、保護通信メンバＥＣＵ３では、全ての受信メッセージに対応する最新ワーク鍵ＩＤバッファＲＴＢ１，・・・，ＲＴＢｎに保存されているワーク鍵ＩＤがＳ２２又はＳ２３で取得したワーク鍵ＩＤと等しい場合、全ての受信メッセージに対応する最新ワーク鍵ＩＤバッファＲＴＢ１，・・・，ＲＴＢｎのワーク鍵ＩＤを−１でクリアし、全ての受信メッセージに対応する最新通し番号バッファＲＮＢ１，・・・，ＲＮＢｎの通し番号を０でクリアする（Ｓ２８）。最後に、保護通信メンバＥＣＵ３では、最新ワーク鍵ＩＤバッファＩＢにＳ２２又はＳ２３で取得したワーク鍵ＩＤを保存する（Ｓ２９）。
【００４０】
このように、全ての保護通信メンバＥＣＵ３では、周期的に、ワーク鍵シードメッセージを受信し、ワーク鍵シードからワーク鍵を更新するとともにワーク鍵ＩＤも切り替えられる。
【００４１】
送信側の保護通信メンバＥＣＵ３Ａでは、標準フォーマットのメッセージＩＤで送信する各種送信情報を収集する（Ｓ４０）。そして、保護通信メンバＥＣＵ３Ａでは、収集できた送信情報からメッセージＩＤを取得する（Ｓ４１）。保護通信メンバＥＣＵ３Ａでは、そのメッセージＩＤに基づいて保護対象メッセージか否かを判定する（Ｓ４２）。Ｓ４２にて保護対象メッセージでないと判定した場合、保護通信メンバＥＣＵ３Ａでは、標準フォーマットの識別子領域にメッセージＩＤを格納し、標準フォーマットのデータ領域に収集した送信情報のデータを格納し、標準フォーマットでメッセージを送信する（Ｓ４３）。
【００４２】
Ｓ４２にて保護対象メッセージと判定した場合、保護通信メンバＥＣＵ３Ａでは、最新ワーク鍵ＩＤバッファＩＢから最新のワーク鍵ＩＤを取得する（Ｓ４４）。また、保護通信メンバＥＣＵ３Ａでは、送信するメッセージＩＤに対応する通し番号バッファＴＮＢｉから通し番号を取得し、その取得した通し番号に１を加算し、その加算後の通し番号を通し番号バッファＴＮＢｉに保存する（Ｓ４５）。
【００４３】
保護通信メンバＥＣＵ３Ａでは、送信するメッセージＩＤと最新のワーク鍵ＩＤと加算後の通し番号と収集できた送信情報によるデータ領域のデータからＭＡＣを生成し、生成したＭＡＣの下位１３ビットを平文ＭＡＣとする（Ｓ４６）。また、保護通信メンバＥＣＵ３Ａでは、最新のワーク鍵ＩＤに対応するワーク鍵バッファＫＢｊからワーク鍵を取得し、そのワーク鍵と送信するメッセージＩＤと最新のワーク鍵ＩＤと加算後の通し番号からストリーム暗号の鍵ストリームを生成する（Ｓ４７）。そして、保護通信メンバＥＣＵ３Ａでは、収集した送信情報によるデータ領域のデータと平文ＭＡＣを鍵ストリームを用いてそれぞれ暗号化する（Ｓ４８）。
【００４４】
保護通信メンバＥＣＵ３Ａでは、拡張フォーマットのデータ領域に暗号化したデータを入れ、拡張フォーマットの識別子ベース領域（ＩＤ２８〜ＩＤ１８）にメッセージＩＤを入れ、拡張フォーマットの識別子拡張領域（ＩＤ１７〜ＩＤ０）に最新のワーク鍵ＩＤと加算後の通し場号と暗号化したＭＡＣを入れ、拡張フォーマットでメッセージを送信する（Ｓ４９）。
【００４５】
このように、メッセージを送信する場合、保護通信メンバＥＣＵ３Ａでは、そのメッセージが保護対象の場合には、通し番号とデータ本体を含むＭＡＣを生成し、そのＭＡＣの一部とデータ本体をワーク鍵を用いたストリーム暗号で暗号化し、拡張フォーマットの識別子拡張領域を利用してワーク鍵ＩＤ、通し番号、暗号化ＭＡＣ（セキュリティに関するデータ）を入れて、拡張フォーマットでメッセージを送信する。この際、保護通信メンバＥＣＵ３ＡのＣＡＮのハードウェアでは、拡張フォーマットとして送信処理を行う。また、保護通信メンバＥＣＵ３Ａの上位層のアプリケーションソフトウェアからは、メッセージＩＤが標準フォーマットと同じく１１ビットとなる。
【００４６】
受信側の保護通信メンバＥＣＵ３Ｂでは、メッセージを受信する毎に（Ｓ６０）、ＩＤ２８〜ＩＤ１８に格納されているメッセージＩＤに基づいて受信対象のメッセージか否かを判定する（Ｓ６１）。Ｓ６１にて受信対象のメッセージでないと判定した場合、保護通信メンバＥＣＵ３Ｂでは、処理を終了する。
【００４７】
Ｓ６１にて受信対象のメッセージと判定した場合、保護通信メンバＥＣＵ３Ｂでは、メッセージが標準フォーマットか否かを判定する（Ｓ６２）。Ｓ６２にて標準フォーマットと判定した場合、保護通信メンバＥＣＵ３Ｂでは、上位層のアプリケーションソフトウェアが標準フォーマットの通常の受信処理を行う（Ｓ６３）。
【００４８】
Ｓ６２にて拡張フォーマットと判定した場合、保護通信メンバＥＣＵ３Ｂでは、拡張フォーマットの識別子ベース領域（ＩＤ２８〜ＩＤ１８）の受信メッセージＩＤに対応する最新ワーク鍵ＩＤバッファＲＩＢｉと最新通し番号バッファＲＮＢｉからワーク鍵ＩＤと通し番号の組を取得する（Ｓ６４）。そして、保護通信メンバＥＣＵ３Ｂでは、拡張フォーマットの識別子拡張領域のＩＤ１７のデータと取得したワーク鍵ＩＤとが一致するか否かを判定する（Ｓ６５）。Ｓ６５にて一致すると判定した場合、保護通信メンバＥＣＵ３Ｂでは、拡張フォーマットの識別子拡張領域のＩＤ１６〜ＩＤ１３のデータが取得した通し番号より大きいか否かを判定する（Ｓ６６）。Ｓ６６にてＩＤ１６〜ＩＤ１３のデータが取得した通し番号以下と判定した場合、保護通信メンバＥＣＵ３Ｂでは、受信したメッセージを廃棄し、防御モードに移行する（Ｓ７３）。
【００４９】
Ｓ６５にて一致しないと判定した場合又はＳ６６にてＩＤ１６〜ＩＤ１３のデータが取得した通し番号より大きいと判定した場合、保護通信メンバＥＣＵ３Ｂでは、受信メッセージＩＤに対応する最新ワーク鍵ＩＤバッファＲＩＢｉに拡張フォーマットの識別子拡張領域のＩＤ１７のデータ（今回受信したワーク鍵ＩＤ）を保存し、最新通し番号バッファＲＮＢｉに拡張フォーマットの識別子拡張領域のＩＤ１６〜ＩＤ１３のデータ（今回受信した通し番号）を保存する（Ｓ６７）。
【００５０】
保護通信メンバＥＣＵ３Ｂでは、ワーク鍵ＩＤに対応するワーク鍵バッファＫＢｊからワーク鍵を取得し、そのワーク鍵と受信したメッセージＩＤと受信したワーク鍵ＩＤと受信した通し番号からストリーム暗号の鍵ストリームを生成する（Ｓ６８）。そして、保護通信メンバＥＣＵ３Ｂでは、受信メッセージの拡張フォーマットのデータ領域の暗号化データと拡張フォーマットの識別子拡張領域のＩＤ１２〜ＩＤ０の暗号化ＭＡＣを鍵ストリームを用いてそれぞれ復号化する（Ｓ６９）。さらに、保護通信メンバＥＣＵ３Ｂでは、受信したメッセージＩＤと受信したワーク鍵ＩＤと受信した通し番号と復号化したデータからＭＡＣを生成し、生成したＭＡＣの下位１３ビットと復号化した平文ＭＡＣとを比較する（Ｓ７０）。そして、保護通信メンバＥＣＵ３Ｂでは、Ｓ７０で比較した結果、ＭＡＣが等しいか否かを判定する（Ｓ７１）。
【００５１】
Ｓ７１にてＭＡＣが等しいと判定した場合、保護通信メンバＥＣＵ３Ｂでは、上位層のアプリケーションソフトウェアが１１ビットのメッセージＩＤとして標準フォーマットのデータ形式で受信処理を行う（Ｓ７２）。一方、Ｓ７１にてＭＡＣが等しくないと判定した場合、保護通信メンバＥＣＵ３Ｂでは、受信したメッセージを廃棄し、防御モードに移行する（Ｓ７３）。
【００５２】
このように、拡張フォーマットでメッセージを受信した場合、保護通信メンバＥＣＵ３Ｂでは、通し番号とＭＡＣによる検証で不正メッセージか否かを判定し、不正メッセージと判定した場合には防御モードに移行する。この際、保護通信メンバＥＣＵ３ＢのＣＡＮのハードウェアでは、拡張フォーマットとして受信処理を行う。また、保護通信メンバＥＣＵ３Ｂの上位層のアプリケーションソフトウェアでは、標準フォーマットと同等の１１ビットのメッセージＩＤとして受信処理を行う。
【００５３】
このＣＡＮ通信システム１によれば、ＭＡＣとデータ本体を暗号化し、この暗号化したＭＡＣとデータ本体を拡張フォーマットを利用して送信することにより、ＣＡＮにおけるフォーマットの互換性を確保しつつセキュリティ性を向上させることができる。また、ＣＡＮ通信システム１によれば、メッセージＩＤ毎の通し番号とＭＡＣによってメッセージを検証することにより、再送攻撃等の不正メッセージを高精度に検出でき、メッセージの安全性を向上でき、セキュリティ性がより向上する。また、ＣＡＮ通信システム１によれば、各ＥＣＵ２，３におけるソフトウェアによる処理だけで簡易に保護通信を行うことができる。
【００５４】
特に、ＣＡＮ通信システム１によれば、ＣＡＮのハードウェアが拡張フォーマットとして処理できるとともに、各保護通信メンバＥＣＵ３の上位層のアプリケーションソフトウェアが拡張フォーマットの識別子ベース領域に格納される標準フォーマット互換のメッセージＩＤ（１１ビット）を用いて標準フォーマットと同等に受信処理できる。さらに、ＣＡＮ通信システム１によれば、ＭＡＣを暗号化しているので、少ないデータ量でもメッセージの安全性を確保できる。したがって、拡張フォーマットの識張子拡張領域内に暗号化ＭＡＣや通し番号を格納する領域を確保でき、拡張フォーマットのデータ領域にＭＡＣ等を格納しなくてよいので、拡張フォーマットのデータ領域には通常と同様にデータを格納でき、データ領域の互換性も確保できる。また、ＣＡＮ通信システム１によれば、データ本体を暗号化しているので、データ本体の安全性も向上できる。
【００５５】
さらに、ＣＡＮ通信システム１によれば、保護通信マスタＥＣＵ２から周期的に更新したワーク鍵シードを送信することにより、保護通信メンバＥＣＵ３で周期的にワーク鍵を更新でき、ワーク鍵の安全性を確保できる。また、ＣＡＮ通信システム１によれば、ワーク鍵シードを更新する毎にワーク鍵ＩＤを０と１で切り替えることにより、メッセージの送信側と受信側とでワーク鍵の更新の同期をとることができる。
【００５６】
以上、本発明に係る実施の形態について説明したが、本発明は上記実施の形態に限定されることなく様々な形態で実施される。
【００５７】
例えば、本実施の形態では車両に搭載されるＣＡＮ通信システムに適用したが、車両以外のＣＡＮにも適用可能である。また、本実施の形態ではソフトウェアで保護通信のための各処理を行う構成としたが、処理の一部（例えば、暗号化処理）をＣＡＮのハードウェアで行ってもよい。
【００５８】
また、本実施の形態ではワーク鍵を更新する際に送信側と受信側で同期をとるために、ワーク鍵ＩＤを導入し、ワーク鍵ＩＤを０と１で切り替える手法を適用したが、他の手法を用いてもよい。また、本実施の形態ではＭＡＣと通し番号を用いてメッセージを検証したが、ＭＡＣによる検証だけでもよい。この場合、拡張フォーマットの識別子拡張領域には少なくとも暗号化ＭＡＣを格納すればよい。
【００５９】
また、本実施の形態ではメッセージＩＤ、ワーク鍵ＩＤ、通し番号、データ本体からＭＡＣを生成したが、この組み合わせ以外でＭＡＣを生成してもよい。また、本実施の形態ではワーク鍵、メッセージＩＤ、ワーク鍵ＩＤ、通し番号から鍵ストリームを生成したが、この組み合わせ以外で鍵ストリームを生成してもよい。また、本実施の形態ではストリーム暗号を適用したが、他の暗号方法を適用してもよい。
【００６０】
また、本実施の形態では保護通信マスタＥＣＵでワーク鍵シードを更新する毎にワーク鍵シードメッセージを一度だけ保護通信メンバＥＣＵに送信する構成としたが、保護通信メンバＥＣＵでワーク鍵シードメッセージを確実に受信するために、保護通信マスタＥＣＵから同じワーク鍵シードメッセージを複数回送信するようにしてもよい。
【符号の説明】
【００６１】
１…ＣＡＮ通信システム、２…保護通信マスタＥＣＵ、３，３Ａ，３Ｂ…保護通信メンバＥＣＵ、４…ＣＡＮバス、５…ＯＢＤ−IIポート。
【特許請求の範囲】
【請求項１】
ＣＡＮ通信プロトコルに基づいて送受信されるデータを保護するための保護通信方法であって、
メッセージ認証コードを生成する生成ステップと、
前記生成ステップで生成したメッセージ認証コードと送信データを暗号化する暗号化ステップと、
前記暗号化ステップで暗号化したメッセージ認証コードをＣＡＮ通信プロトコルの拡張フォーマットの識別子拡張領域に格納し、前記暗号化ステップで暗号化した送信データを拡張フォーマットのデータ領域に格納する格納ステップと、
前記格納ステップで格納した拡張フォーマットでメッセージを送信する送信ステップと、
を含むこと特徴とする保護通信方法。
【請求項２】
前記格納ステップでは、ワーク鍵ＩＤ、メッセージの通し番号をＣＡＮ通信プロトコルの拡張フォーマットの識別子拡張領域に格納し、
前記送信ステップで送信された拡張フォーマットのメッセージを受信したノードにおいて、前記通し番号の検証又は前記メッセージ認証コードの検証で異常を検出した場合、防御モードに移行することを特徴とする請求項１に記載の保護通信方法。
【請求項１】
ＣＡＮ通信プロトコルに基づいて送受信されるデータを保護するための保護通信方法であって、
メッセージ認証コードを生成する生成ステップと、
前記生成ステップで生成したメッセージ認証コードと送信データを暗号化する暗号化ステップと、
前記暗号化ステップで暗号化したメッセージ認証コードをＣＡＮ通信プロトコルの拡張フォーマットの識別子拡張領域に格納し、前記暗号化ステップで暗号化した送信データを拡張フォーマットのデータ領域に格納する格納ステップと、
前記格納ステップで格納した拡張フォーマットでメッセージを送信する送信ステップと、
を含むこと特徴とする保護通信方法。
【請求項２】
前記格納ステップでは、ワーク鍵ＩＤ、メッセージの通し番号をＣＡＮ通信プロトコルの拡張フォーマットの識別子拡張領域に格納し、
前記送信ステップで送信された拡張フォーマットのメッセージを受信したノードにおいて、前記通し番号の検証又は前記メッセージ認証コードの検証で異常を検出した場合、防御モードに移行することを特徴とする請求項１に記載の保護通信方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２０１３−４８３７４（Ｐ２０１３−４８３７４Ａ）
【公開日】平成２５年３月７日（２０１３．３．７）
【国際特許分類】
【出願番号】特願２０１１−１８６２４３（Ｐ２０１１−１８６２４３）
【出願日】平成２３年８月２９日（２０１１．８．２９）
【出願人】（０００００３２０７）トヨタ自動車株式会社 (59,920)
【Ｆターム（参考）】
【公開日】平成２５年３月７日（２０１３．３．７）
【国際特許分類】
【出願日】平成２３年８月２９日（２０１１．８．２９）
【出願人】（０００００３２０７）トヨタ自動車株式会社 (59,920)
【Ｆターム（参考）】
[ Back to top ]