JP2017091360A - データ配布装置、通信システム、移動体およびデータ配布方法 - Google Patents

Abstract

【課題】通信を行う電子機器同士が共有すべきデータを他の電子機器が不正に取得しようとする試みを検知できるようにする。
【解決手段】実施形態のＧＷ１０は、ＥＣＵのグループごとに、グループに対応する所定データと、グループに属するＥＣＵの数を特定するための数特定情報とを対応付けたグループ管理情報を記憶する記憶部１１０と、所定データを含む共有開始指示を送信する指示送信部１２１と、共有開始指示に応じてＥＣＵから送信された配布リクエストを受信するリクエスト受信部１２２と、受信した配布リクエストの数が数特定情報により特定される数を超えるか否かを判定する判定部１３０と、受信した配布リクエストの数が数特定情報により特定される数を超える場合に、不正な配布リクエストを送信するＥＣＵが接続されていることを示すエラー信号を出力するエラー出力部１４０と、を備える。
【選択図】図３

Description

本発明の実施形態は、データ配布装置、通信システム、移動体およびデータ配布方法に関する。

例えば、自動車などの移動体には、各種機器を制御するための様々な電子制御装置（ＥＣＵ：Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）が搭載されている。これらのＥＣＵは、例えばＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）などのネットワークに接続され、ネットワークを介して信号を送受信しながら自動車の制御を行っている。

ＥＣＵなどの電子機器が接続されるネットワークでは、誤った制御が行われないようにするために、通信の正当性が保証されることが極めて重要となる。通信の正当性を保証するには、暗号技術の利用が有効である。例えば、通信を行う電子機器同士が共有すべき暗号鍵などのデータを正しく共有していれば、このデータを用いて通信の認証を行ったり、通信内容の秘匿や改竄検知などを行ったりすることができる。しかし、通信を行う電子機器同士が共有すべきデータを、他の電子機器が不正に取得すると、通信の正当性を保証できなくなる。

特許第５７７２６９２号公報 特開２００５−３４１５２８号公報

本発明が解決しようとする課題は、通信を行う電子機器同士が共有すべきデータを他の電子機器が不正に取得しようとする試みを検知することができるデータ配布装置、通信システム、移動体およびデータ配布方法を提供することである。

実施形態のデータ配布装置は、複数の電子機器とネットワークを介して接続されるデータ配布装置であって、記憶部と、指示送信部と、リクエスト受信部と、判定部と、エラー出力部と、を備える。記憶部は、電子機器のグループごとに、グループに対応する所定データと、グループに属する電子機器の数を特定するための数特定情報とを対応付けたグループ管理情報を記憶する。指示送信部は、前記所定データを含む共有開始指示を送信する。リクエスト受信部は、前記共有開始指示に応じて電子機器から送信された配布リクエストを受信する。判定部は、受信した配布リクエストの数が前記数特定情報により特定される数を超えるか否かを判定する。エラー出力部は、受信した配布リクエストの数が前記数特定情報により特定される数を超える場合に、不正な配布リクエストを送信する電子機器が前記ネットワークに接続されていることを示すエラー信号を出力する。

車載ネットワークシステムの概要を示す模式図。 ＧＷのハードウェア構成例を示すブロック図。 第１実施形態のＧＷの機能的な構成例を示すブロック図。 グループ管理情報の一例を示す図。 第１実施形態のＥＣＵの機能的な構成例を示すブロック図。 第１実施形態の処理手順の一例を示すフローチャート。 第２実施形態のＧＷの機能的な構成例を示すブロック図。 第２実施形態のＥＣＵの機能的な構成例を示すブロック図。 第２実施形態の処理手順の一例を示すフローチャート。

実施形態のデータ配布装置は、例えば、移動体の一例である自動車に搭載される車載ネットワークシステム（通信システム）に適用できる。以下では、車載ネットワークシステムに含まれる車載ゲートウェイ装置（以下、「ＧＷ」と略称する）を実施形態のデータ配布装置として構成した例を説明する。ただし、適用可能な装置やシステムは以下の例に限らない。実施形態のデータ配布装置は、通信の送信側と受信側とで共有する暗号鍵などのデータを用いて通信の正当性を保証することが求められる様々な通信システムにおいて広く適用可能である。

＜第１実施形態＞
図１は、車載ネットワークシステム１の概要を示す模式図である。この車載ネットワークシステム１は、図１に示すように、データ配布装置として構成されるＧＷ１０と、自動車Ｖに搭載される電子機器である各種のＥＣＵ２０とが、ネットワークを介して接続された構成である。本実施形態のＧＷ１０は、車載ネットワークシステム１内のサブネットワーク間の通信を中継したり、車載ネットワークシステム１と車外のネットワークとの間の通信を中継したりといった本来のゲートウェイとしての機能に加えて、通信するＥＣＵ２０間で共有すべき暗号鍵などのデータをそれぞれのＥＣＵ２０に配布する機能を有する。なお、車載ネットワークシステム１の通信規格としては、例えば、ＣＡＮやＦｌｅｘＲａｙ（登録商標）など、車載ネットワークの規格として公知のものを利用できる。

複数のＥＣＵ２０が連携して自動車Ｖの制御を実施する場合、これら複数のＥＣＵ２０はネットワークを介した通信を行って制御信号を送受信する。ここでいう制御信号は、自動車Ｖの制御を実施するためにＥＣＵ２０間で送受信される信号の総称である。ＥＣＵ２０間で制御信号を送受信する際には、誤った制御が行われないようにするために、ＥＣＵ２０間の通信の正当性が保証される必要がある。通信の正当性を保証する方法は様々あるが、例えば自動車Ｖの走行中におけるＥＣＵ２０間の通信はリアルタイム性が要求されるため、通信の正当性を保証するための処理に時間をかけることができない。そこで本実施形態では、通信の認証を短時間で行うことができるＭＡＣ（Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）の認証技術を利用して、ＥＣＵ２０間の通信の正当性を保証するものとする。

ＭＡＣの認証技術は、認証に必要なＭＡＣ値を導出するために、送信側と受信側とで共有された事前共有鍵または事前共有鍵から派生するセッション鍵を利用する。本実施形態では、ＧＷ１０が、通信するＥＣＵ２０のそれぞれに対して、例えばＭＡＣ値の導出に用いる事前共有鍵を配布するものとする。

車載ネットワークシステム１のノードとしてネットワークに接続される各種ＥＣＵ２０は、例えば、ブレーキに関する制御信号を送信または受信するＥＣＵ２０のグループ、車速に関する制御信号を送信または受信するＥＣＵ２０のグループといったように、送受信する制御信号の種類に応じてグループ分けすることができる。ここでいうグループは、送受信する制御信号の種類に応じた概念的な分類であり、ネットワーク上を流れる制御信号は、その制御信号に対応するグループに属するＥＣＵ２０が送信または受信し、そのグループに属さないＥＣＵ２０は送信も受信もしないことを意味する。１つのＥＣＵ２０が複数種類の制御信号を送信または受信する場合は、そのＥＣＵ２０が複数のグループに属することもある。また、複数種類の制御信号を送信または受信する複数のＥＣＵ２０を１つのグループに分類することもある。

本実施形態のＧＷ１０は、ネットワーク上の各ＥＣＵ２０に対する上述した事前共有鍵の配布を、このようなグループ単位で実施する。具体的には、ＧＷ１０は、あるグループに属するＥＣＵ２０をアクティベートして、これらのＥＣＵ２０からＧＷ１０に対する配布リクエストを送信させる。そして、ＧＷ１０は、この配布リクエストに応じて、そのグループに属するＥＣＵ２０が共有すべき事前共有鍵を配布するといった手順をとる。このとき、グループに属さない他のＥＣＵ２０あるいはネットワークに不正に接続された電子機器が不正な配布リクエストをＧＷ１０に送信すると、この不正な配布リクエストに応じて事前共有鍵を配布してしまって、グループに属する正当なＥＣＵ２０同士が事前共有鍵を正しく共有できなくなる虞がある。そこで、本実施形態のＧＷ１０は、受信した配布リクエストの数をグループに属するＥＣＵ２０の数と比較し、受信した配布リクエストの数がグループに属するＥＣＵ２０の数を超える場合は、不正な配布リクエストを送信する電子機器がネットワークに接続されていることを示すエラー信号を出力し、メンテナンス作業員やドライバなどに適切な対応を促すようにしている。

図２は、ＧＷ１０のハードウェア構成例を示すブロック図である。ＧＷ１０は、例えば図２に示すように、ネットワークＩ／Ｆ１１と、マイクロコントローラ１２と、を備える。ネットワークＩ／Ｆ１１は、ＧＷ１０をネットワークに接続するインタフェースである。マイクロコントローラ１２は、コンピュータシステムを集積回路として組み込んだものであり、コンピュータシステム上で動作するプログラム（ソフトウェア）に従って様々な制御を実行する。ＧＷ１０は、マイクロコントローラ１２がネットワークＩ／Ｆ１１を利用しながらプログラムに応じた制御を実行することにより、事前共有鍵の配布に関わる各種の機能を実現する。

図３は、本実施形態のＧＷ１０の機能的な構成例を示すブロック図である。本実施形態のＧＷ１０は、事前共有鍵の配布に関わる機能的な構成要素として、例えば図３に示すように、記憶部１１０と、送受信部１２０と、判定部１３０と、エラー出力部１４０と、演算部１５０と、を備える。

記憶部１１０は、グループ管理情報を記憶する。グループ管理情報は、上述したＥＣＵ２０のグループごとに、グループに対応する所定データと、グループに属するＥＣＵ２０の数を特定するための数特定情報とを対応付けた情報である。図４は、記憶部１１０が記憶するグループ管理情報の一例を示す図である。この図４のグループ管理情報３０は、グループに対応する所定データとして、そのグループに属するＥＣＵ２０が送信または受信する制御信号（例えば、ブレーキ信号、車速信号など）を格納し、数特定情報として、そのグループに属するＥＣＵ２０それぞれに割り当てられた機器ＩＤの集合を格納した例を示している。数特定情報として格納された機器ＩＤの数をカウントすることで、そのグループに属するＥＣＵ２０の数を特定することができる。

なお、グループに対応する所定データは、この所定データを含む後述の共有開始指示がネットワークに送信されたときに、ＥＣＵ２０が、共有開始指示の対象となるグループが自身の属するグループであることを認識できるデータであればよく、上述した制御信号に限らない。例えば、グループに割り当てられたグループＩＤを所定データとして用いてもよい。また、グループに属するＥＣＵ２０の機器ＩＤの集合を所定データとして用いてもよい。この場合、所定データと数特定情報とを統合できる。また、上述のデータの組み合わせ（例えば、複数の制御信号の組み合わせ、制御信号とグループＩＤの組み合わせ、制御信号と機器ＩＤの集合の組み合わせなど）を所定データとして用いてもよい。

また、数特定情報は、グループに属するＥＣＵ２０の数を特定できるデータであればよく、上述した機器ＩＤの集合に限らない。例えば、グループに属するＥＣＵ２０の数そのものを数特定情報として用いてもよい。

グループ管理情報は、例えば、ＧＷ１０の製造あるいは出荷時に記憶部１１０に格納されてもよいし、ＧＷ１０を含む車載ネットワークシステム１を搭載する自動車Ｖの製造あるいは出荷時に記憶部１１０に格納されてもよい。また、グループ管理情報は、自動車Ｖの出荷後に、ＧＷ１０の外部入出力端子あるいは車載ネットワークシステム１を介してＧＷ１０の外部から取得され、記憶部１１０に格納されてもよい。自動車Ｖの出荷後にグループ管理情報を記憶部１１０に格納する場合、ＥＣＵ２０の追加や削除などに応じたネットワーク構成の変化に対応させて、グループ管理情報を更新することもできる。

送受信部１２０は、ＧＷ１０がネットワークを介してＥＣＵ２０と通信するモジュールであり、サブモジュールとして、指示送信部１２１と、リクエスト受信部１２２と、鍵送信部１２３と、を含む。

指示送信部１２１は、事前共有鍵の配布を実施するグループ（以下、「配布対象グループ」という）に属する各ＥＣＵ２０に対し、その配布対象グループに対応する上述の所定データを含む共有開始指示を、ＧＷ１０の公開鍵および公開鍵証明書とともに送信する。指示送信部１２１は、配布対象グループに属する各ＥＣＵ２０に対して共有開始指示を個別に送信するのではなく、配布対象グループに対応する所定データを含む共有開始指示を、ネットワーク上にブロードキャストする。ネットワークに接続されている各ＥＣＵ２０は、ＧＷ１０の指示送信部１２１により送信される共有開始指示に含まれる所定データが、自身が属するグループに対応したものである場合に、その共有開始指示を受信する。

ＧＷ１０の公開鍵は、共有開始指示を受信したＥＣＵ２０において後述の一時鍵を暗号化するために用いられる。公開鍵証明書は、公開鍵を送信するＧＷ１０の正当性を保証するために、第三者が発行した証明書である。ＧＷ１０の公開鍵および公開鍵証明書は、公開鍵に対応する秘密鍵とともに、例えば記憶部１１０などに格納されている。なお、ＧＷ１０の公開鍵が事前にＥＣＵ２０に公開されている場合など、ＥＣＵ２０がすでにＧＷ１０の公開鍵を保持している場合は、指示送信部１２１は、配布対象グループに対応する所定データを含む共有開始指示のみを送信し、ＧＷ１０の公開鍵および公開鍵証明書を送信しなくてもよい。この場合、ＧＷ１０は、公開鍵に対応する秘密鍵のみを記憶していればよい。

リクエスト受信部１２２は、指示送信部１２１が送信した共有開始指示に応じてＥＣＵ２０から送信された配布リクエストを受信する。この配布リクエストには、ＧＷ１０の公開鍵を用いて暗号化された一時鍵が含まれている。ＧＷ１０の公開鍵を用いて暗号化された一時鍵そのものを、配布リクエストとしてもよい。一時鍵は、例えば、共有開始指示を受信したＥＣＵ２０においてランダムに生成される乱数であり、配布リクエストに応じて、ＧＷ１０がＥＣＵ２０に対して送信する事前共有鍵を暗号化するために用いられる。配布リクエストに含まれる暗号化された一時鍵は、ＧＷ１０の公開鍵に対応する秘密鍵を用いて復号される。

鍵送信部１２３は、後述の判定部１３０により、リクエスト受信部１２２が受信した配布リクエストの数が、配布対象グループに対応する数特定情報により特定される数、つまり、配布対象グループに属するＥＣＵ２０の数を超えないと判定された場合に、配布リクエストを送信したＥＣＵ２０に対して、配布対象グループに属するＥＣＵ２０間で共有される事前共有鍵を送信する。事前共有鍵は、例えば、グループごとに予め定められて記憶部１１０などに格納されていてもよいし、事前共有鍵の配布を実施する際にランダムあるいは所定の規則で選ばれたデータを用いてもよい。

鍵送信部１２３は、配布リクエストを送信したＥＣＵ２０のそれぞれに対し、各ＥＣＵ２０が生成した一時鍵を用いて暗号化された事前共有鍵を送信する。例えば、鍵送信部１２３は、リクエスト受信部１２２が受信した配布リクエストに含まれる送信元の情報から、事前共有鍵を送信すべきＥＣＵ２０を特定する。そして、鍵送信部１２３は、このＥＣＵ２０を宛先として、このＥＣＵ２０により生成された一時鍵を用いて暗号化された事前共有鍵を送信する。

また、鍵送信部１２３は、各ＥＣＵ２０で生成された一時鍵を用いて暗号化された事前共有鍵のそれぞれを、ネットワーク上にブロードキャストしてもよい。この場合、鍵送信部１２３は、事前共有鍵の正当性を検査するための検査用データを併せて送信する。検査用データとしては、事前共有鍵のハッシュ値や、ＧＷ１０とＥＣＵ２０の双方が記憶する所定の値を事前共有鍵により暗号化した値などを用いることができる。検査用データとして事前共有鍵のハッシュ値を用いる場合、ＥＣＵ２０は、自身の一時鍵を用いて復号した事前共有鍵のハッシュ値を算出し、この算出したハッシュ値がＧＷ１０から送信されたハッシュ値と一致するか否かを判定することで、事前共有鍵の正当性を検査することができる。また、検査用データとして所定の値を事前共有鍵により暗号化した値を用いる場合、ＥＣＵ２０は、自身の一時鍵を用いて復号した事前共有鍵を用いて所定の値を暗号化し、得られた値がＧＷ１０から送信された値と一致するか否かを判定することで、事前共有鍵の正当性を検査することができる。

判定部１３０は、リクエスト受信部１２２が受信した配布リクエストの数が、配布対象グループに対応する数特定情報により特定される数、つまり、配布対象グループに属するＥＣＵ２０の数を超えるか否かを判定する。具体的には、判定部１３０は、リクエスト受信部１２２が受信した配布リクエストの数を、例えば記憶部１１０に一時的に記憶されるカウンタを用いてカウントする。すなわち判定部１３０は、事前共有鍵の配布を実施する際に、まず、記憶部１１０が保持するカウンタを０にセットし、リクエスト受信部１２２が配布リクエストを受信するたびに、カウンタをインクリメント（＋１）する。そして、判定部１３０は、例えば、指示送信部１２１が共有開始指示を送信してから所定時間が経過すると、記憶部１１０が保持するカウンタの値を参照し、このカウンタ値を、配布対象グループに対応する数特定情報により特定される数と比較することで、リクエスト受信部１２２が受信した配布リクエストの数が、配布対象グループに属するＥＣＵ２０の数を超えるか否かを判定する。

この判定部１３０による判定は、配布対象グループに属さないＥＣＵ２０やネットワークに不正に接続された電子機器などが不正な配布リクエストを送信している場合に、これを検知するために実施される。すなわち、リクエスト受信部１２２が受信した配布リクエストの数が、配布対象グループに属するＥＣＵ２０の数を超える場合は、リクエスト受信部１２２が受信した配布リクエストに、不正な配布リクエストが含まれていると判断できる。

エラー出力部１４０は、リクエスト受信部１２２が受信した配布リクエストの数が、配布対象グループに対応する数特定情報により特定される数、つまり、配布対象グループに属するＥＣＵ２０の数を超えると判定部１３０によって判定された場合に、不正な配布リクエストを送信する電子機器がネットワークに接続されていることを示すエラー信号を出力する。

エラー出力部１４０は、例えば、ＧＷ１０の外部入出力端子や車載ネットワークシステム１を介してＧＷ１０に接続されたメンテナンスツールにエラー信号を出力することができる。すなわち、自動車Ｖの出荷前などに、メンテナンス作業員が使用するメンテナンスツールがＧＷ１０に接続された状態でＧＷ１０による事前共有鍵の配布が実施される場合、エラー出力部１４０は、上記のエラー信号をメンテナンスツールに出力する。メンテナンスツールは、エラー出力部１４０から入力したエラー信号に基づいて、不正な配布リクエストを送信する電子機器がネットワークに接続されていることを示すエラーメッセージを表示する。これにより、メンテナンスツールを使用するメンテナンス作業員に対し、適切な対応を促すことができる。

また、エラー出力部１４０は、不正な配布リクエストを送信する電子機器がネットワークに接続されていることを示すエラー信号とともに、配布対象グループに対応する所定データをメンテナンスツールに出力してもよい。この場合、メンテナンスツールは、上述のエラーメッセージとともに、配布対象グループに対応する所定データ、あるいはこの所定データを元に生成した情報を表示する。これにより、メンテナンスツールを使用するメンテナンス作業員は、車載ネットワークシステム１のどのＥＣＵ２０のグループにおいて事前共有鍵の共有に支障が生じているかを確認することができる。

また、エラー出力部１４０は、不正な配布リクエストを送信するＥＣＵ２０がネットワークに接続されていることを示すエラー信号とともに、リクエスト受信部１２２が受信した配布リクエストに含まれる送信元の情報をメンテナンスツールに出力してもよい。この場合、メンテナンスツールは、上記のエラーメッセージとともに、配布リクエストの送信元の情報を表示する。これにより、メンテナンスツールを使用するメンテナンス作業員は、不正な配布リクエストを送信した電子機器を特定することができる。

また、エラー出力部１４０は、自動車Ｖに設けられたディスプレイパネルや警告インジケータなどに対して、上記のエラー信号を出力してもよい。すなわち、自動車Ｖの出荷後であっても、例えば事前共有鍵の更新を目的として、定期的あるいは所定の指示に従ってＧＷ１０による事前共有鍵の配布が実施される場合がある。このような場合は、ＧＷ１０に対して上述のメンテナンスツールが接続されていないことが想定されるため、エラー出力部１４０は、上記のエラー信号を自動車Ｖに設けられたディスプレイパネルや警告インジケータなどに出力する。自動車Ｖに設けられたディスプレイは、エラー出力部１４０から入力したエラー信号に基づいて、不正な配布リクエストを送信する電子機器がネットワークに接続されていることを示すエラーメッセージを表示する。また、警告インジケータは、エラー出力部１４０から入力したエラー信号に基づいて、光源を点灯あるいは点滅させる。これにより、例えば自動車Ｖのドライバなどに対して、適切な対応を促すことができる。

演算部１５０は、リクエスト受信部１２２が受信した配布リクエストの数が、配布対象グループに対応する数特定情報により特定される数、つまり、配布対象グループに属するＥＣＵ２０の数を超えないと判定部１３０によって判定された場合に、ＥＣＵ２０に対する事前共有鍵の配布に必要な各種の演算を実行する。具体的には、演算部１５０は、リクエスト受信部１２２が受信した配布リクエストに含まれる暗号化された一時鍵を、ＧＷ１０の公開鍵に対応する秘密鍵を用いて復号する。また、演算部１５０は、ＥＣＵ２０に送信する事前共有鍵を、一時鍵を用いて暗号化する。この演算部１５０によって暗号化された事前共有鍵が、鍵送信部１２３によってＥＣＵ２０に送信される。また、事前共有鍵としてランダムあるいは所定の規則で選ばれたデータを用いる場合、演算部１５０は、この事前共有鍵を生成する。

次に、本実施形態のＥＣＵ２０の概要を説明する。図５は、本実施形態のＥＣＵ２０の機能的な構成例を示すブロック図である。本実施形態のＥＣＵ２０は、事前共有鍵の取得に関わる機能的な構成要素として、例えば図５に示すように、送受信部２１０と、演算部２２０と、記憶部２３０と、を備える。

送受信部２１０は、ＥＣＵ２０がネットワークを介してＧＷ１０と通信するモジュールであり、サブモジュールとして、指示受信部２１１と、リクエスト送信部２１２と、鍵受信部２１３と、を含む。

指示受信部２１１は、ＧＷ１０の指示送信部１２１が送信した共有開始指示に含まれる所定データが、当該ＥＣＵ２０が属するグループに対応したものである場合に、その共有開始指示を受信する。例えば、共有開始指示に含まれる所定データが制御信号である場合、指示受信部２１１は、その制御信号が、当該ＥＣＵ２０が他のＥＣＵ２０との間で送受信する制御信号であれば、その制御信号を含む共有開始指示を受信する。また、共有開始指示に含まれる所定データがグループＩＤである場合、指示受信部２１１は、そのグループＩＤが、当該ＥＣＵ２０が属するグループに割り当てられたグループＩＤであれば、そのグループＩＤを含む共有開始指示を受信する。また、共有開始指示に含まれる所定データが機器ＩＤの集合である場合、指示受信部２１１は、その機器ＩＤの集合に、当該ＥＣＵ２０に割り当てられた機器ＩＤが含まれていれば、その機器ＩＤの集合を含む共有開始指示を受信する。

また、指示受信部２１１は、ＧＷ１０の指示送信部１２１が共有開始指示とともに送信したＧＷ１０の公開鍵および公開鍵証明書を受信し、公開鍵証明書によりＧＷ１０の正当性が保証されていることを確認した上で、ＧＷ１０の公開鍵を記憶部２３０に格納する。

リクエスト送信部２１２は、指示受信部２１１が共有開始指示を受信した場合、演算部２２０により生成されてＧＷ１０の公開鍵で暗号化された一時鍵を含む配布リクエストを、ネットワークを介してＧＷ１０に送信する。

鍵受信部２１３は、ＧＷ１０の鍵送信部１２３が送信した暗号化された事前共有鍵を受信する。ＧＷ１０の鍵送信部１２３が上述の検査用データを暗号化された事前共有鍵とともに送信している場合、鍵受信部２１３は、暗号化された事前共有鍵とともに検査用データも受信する。

演算部２２０は、事前共有鍵の取得に必要な各種の演算を実行する。具体的には、演算部２２０は、指示受信部２１１が共有開始指示を受信した場合、一時鍵を生成して記憶部２３０に格納する。また、演算部２２０は、生成した一時鍵を、ＧＷ１０の公開鍵を用いて暗号化する。この暗号化された一時鍵は、リクエスト送信部２１２によって配布リクエストとしてＧＷ１０に送信される。また、演算部２２０は、鍵受信部２１３が暗号化された事前共有鍵を受信した場合、記憶部２３０が記憶する一時鍵を用いて、この暗号化された事前共有鍵を復号し、得られた事前共有鍵を記憶部２３０に格納する。なお、鍵受信部２１３が暗号化された事前共有鍵とともに検査用データを受信した場合、演算部２２０は、検査用データを用いて事前共有鍵の正当性を検査し、正しいことが確認された事前共有鍵を記憶部２３０に格納する。

記憶部２３０は、指示受信部２１１が受信したＧＷ１０の公開鍵、演算部２２０により生成された一時鍵、演算部２２０により復号された事前共有鍵などを記憶する。なお、演算部２２０により生成された一時鍵は、事前共有鍵を復号した後に消去されてもよい。

次に、図６を参照しながら、本実施形態における事前共有鍵の配布に関わるＧＷ１０およびＥＣＵ２０の動作例について説明する。図６は、本実施形態の処理手順の一例を示すフローチャートである。この図６のフローチャートで示す一連の処理手順は、配布対象グループごとに繰り返し実行される。

処理が開始されると、まず、ＧＷ１０の判定部１３０が、カウンタを０に設定する（ステップＳ１０１）。次に、ＧＷ１０の指示送信部１２１が、配布対象グループに対応する所定データを含む共有開始指示を、ＧＷ１０の公開鍵とともにネットワーク上に送信する（ステップＳ１０２）。

ＧＷ１０の指示送信部１２１が送信した共有開始指示とＧＷ１０の公開鍵は、配布対象グループに属するＥＣＵ２０の指示受信部２１１によって受信される（ステップＳ２０１）。そして、共有開始指示とＧＷ１０の公開鍵とを受信したＥＣＵ２０の演算部２２０は、一時鍵を生成し（ステップＳ２０２）、その一時鍵をＧＷ１０の公開鍵を用いて暗号化する（ステップＳ２０３）。そして、ＥＣＵ２０のリクエスト送信部２１２が、暗号化された一時鍵を含む配布リクエストをＧＷ１０に送信する（ステップＳ２０４）。

ＥＣＵ２０のリクエスト送信部２１２が送信した配布リクエストは、ＧＷ１０のリクエスト受信部１２２によって受信される（ステップＳ１０３）。そして、リクエスト受信部１２２により配布リクエストが受信されると、ＧＷ１０の判定部１３０は、カウンタをインクリメントする（ステップＳ１０４）。その後、判定部１３０は、指示送信部１２１が共有開始指示を送信してから所定時間が経過したか否かを判定する（ステップＳ１０５）。ここで、所定時間が経過していなければ（ステップＳ１０５：Ｎｏ）、ステップＳ１０３に戻って次の配布リクエストの受信を待つ。

一方、指示送信部１２１が共有開始指示を送信してから所定時間が経過すると（ステップＳ１０５：Ｙｅｓ）、判定部１３０は、受信した配布リクエストの数をカウントするカウンタ値が、配布対象グループに対応する数特定情報によって特定される数、つまり、配布対象グループに属するＥＣＵ２０の数を超えたか否かを判定する（ステップＳ１０６）。そして、カウンタ値が配布対象グループに属するＥＣＵ２０の数を超えたと判定されると（ステップＳ１０６：Ｙｅｓ）、ＧＷ１０のエラー出力部１４０が、不正な配布リクエストを送信する電子機器がネットワークに接続されていることを示すエラー信号を出力する（ステップＳ１０７）。

一方、カウンタ値が配布対象グループに属するＥＣＵ２０の数を超えていないと判定された場合は（ステップＳ１０６：Ｎｏ）、ＧＷ１０の演算部１５０が、配布リクエストに含まれる暗号化された一時鍵を、ＧＷ１０の公開鍵に対応する秘密鍵を用いて復号し（ステップＳ１０８）、この一時鍵を用いて事前共有鍵を暗号化する（ステップＳ１０９）。そして、ＧＷ１０の鍵送信部１２３が、暗号化された事前共有鍵を、配布リクエストに対する応答としてＥＣＵ２０に送信する（ステップＳ１１０）。

ＧＷ１０の鍵送信部１２３が送信した暗号化された事前共有鍵は、ＥＣＵ２０の鍵受信部２１３によって受信される（ステップＳ２０５）。そして、鍵受信部２１３により暗号化された事前共有鍵が受信されると、ＥＣＵ２０の演算部２２０が、一時鍵を用いて暗号化された事前共有鍵を復号し（ステップＳ２０６）、得られた事前共有鍵を記憶部２３０に格納する（ステップＳ２０７）。

なお、以上の例では、ＧＷ１０の判定部１３０が、共有開始指示の送信から所定時間が経過したときに、受信した配布リクエストの数をカウントするカウンタ値が、配布対象グループに属するＥＣＵ２０の数を超えるか否かを判定している。そして、受信した配布リクエストの数をカウントするカウンタ値が、配布対象グループに属するＥＣＵ２０の数を超えないと判定された場合に、ＧＷ１０の鍵送信部１２３が、配布リクエストに対する応答として、ＥＣＵ２０が生成した一時鍵を用いて暗号化した事前共有鍵をＥＣＵ２０に送信するようにしている。しかし、ＧＷ１０の判定部１３０による判定および鍵送信部１２３による暗号化された事前共有鍵の送信を、ＥＣＵ２０からの配布リクエストをリクエスト受信部１２２が受信するたびに行い、受信した配布リクエストの数をカウントするカウンタ値が、配布対象グループに属するＥＣＵ２０の数を超えた時点で、エラー出力部１４０がエラー信号を出力するとともに、車載ネットワークシステム１の動作を停止して、すでに送信した事前共有鍵を無効化する構成としてもよい。

以上、具体的な例を挙げながら詳細に説明したように、本実施形態の車載ネットワークシステム１では、ＧＷ１０が、共有開始指示に応じてＥＣＵ２０から送信される配布リクエストを受信し、受信した配布リクエストの数が配布対象グループに属するＥＣＵ２０の数を超えるか否かを判定する。そして、受信した配布リクエストの数が配布対象グループに属するＥＣＵ２０の数を超える場合は、不正な配布リクエストを送信する電子機器がネットワークに接続されていることを示すエラー信号を出力するようにしている。このように、本実施形態によれば、通信を行うＥＣＵ２０同士が共有すべき事前共有鍵を他の電子機器が不正に取得しようとする試みを検知して、例えば自動車Ｖのメンテナンス作業員やドライバなどに適切な対応を促すことができる。

また、ＧＷ１０は、受信した配布リクエストの数が配布対象グループに属するＥＣＵ２０の数を超えない場合に、配布リクエストに応じて、配布対象グループに属するＥＣＵ２０に事前共有鍵を送信するようにしている。したがって、本実施形態によれば、不正な電子機器がネットワークに接続された場合であっても、通信を行うＥＣＵ２０同士が事前共有鍵を正しく共有して、この事前共有鍵を用いた認証などによってＥＣＵ２０間の通信の正当性を保証することができる。

＜変形例＞
以上説明した第１実施形態では、ＥＣＵ２０が生成した一時鍵を暗号化するためにＧＷ１０の公開鍵を用い、ＧＷ１０の公開鍵に対応する秘密鍵を用いて、暗号化された一時鍵を復号している。しかし、これら公開鍵および秘密鍵に代えて、ＧＷ１０とＥＣＵ２０とで共通の暗号鍵を用いて、ＥＣＵ２０が生成した一時鍵の暗号化および復号を行う構成としてもよい。例えば、ＧＷ１０がＥＣＵ２０に配布する事前共有鍵を定期的あるいは所定の指示に従って更新する場合、ＧＷ１０がＥＣＵ２０に対して過去に配布した事前共有鍵を用いて、ＥＣＵ２０が生成した一時鍵の暗号化および復号を行うことができる。また、ＧＷ１０とＥＣＵ２０との双方に予め埋め込まれた共通の暗号鍵がある場合、この暗号鍵を用いて、ＥＣＵ２０が生成した一時鍵の暗号化および復号を行うようにしてもよい。

また、以上説明した第１実施形態では、ＧＷ１０がＥＣＵ２０に対してＭＡＣ値の導出に用いる事前共有鍵を配布する例を挙げたが、ＧＷ１０がＥＣＵ２０に配布するデータは、同じグループに属する複数のＥＣＵ２０間で共有すべきデータであればよく、ＭＡＣ値の導出に用いる事前共有鍵に限らない。例えば、事前共有鍵から派生するセッション鍵を配布する場合、あるいは、事前共有鍵からセッション鍵を生成するためのデータを配布する場合に本実施形態を適用してもよい。また、暗号鍵以外の共有すべきデータを配布する場合に本実施形態を適用してもよい。

＜第２実施形態＞
次に、第２実施形態について説明する。第２実施形態は、車載ネットワークシステム１のノードとしてネットワークに接続される各ＥＣＵ２０が、装置固有のデータを出力するＰＵＦ（Ｐｈｙｓｉｃａｌｌｙ Ｕｎｃｌｏｎａｂｌｅ Ｆｕｎｃｔｉｏｎ）を搭載し、装置固有のデータであるＰＵＦ出力を用いて事前共有鍵を算出する点が上述の第１実施形態と異なる。ＰＵＦ出力は各ＥＣＵ２０に固有のデータであるが、各ＥＣＵ２０のＰＵＦ出力の違いを吸収するように調整されたデータ（以下、「補助データ」と呼ぶ）を用いることで、ＰＵＦ出力から事前共有鍵を生成することができる。本実施形態では、第１実施形態でＧＷ１０がＥＣＵ２０に配布した事前共有鍵に代えて、この補助データをＥＣＵ２０に配布する。以下では、第１実施形態と共通する構成については同一の符号を付して重複した説明を適宜省略し、本実施形態に特徴的な部分についてのみ説明する。なお、以下では本実施形態のＧＷ１０を第１実施形態と区別してＧＷ１０’と表記し、本実施形態のＥＣＵ２０を第１実施形態と区別してＥＣＵ２０’と表記する。

図７は、本実施形態のＧＷ１０’の機能的な構成例を示すブロック図である。本実施形態のＧＷ１０’は、事前共有鍵の配布に関わる機能的な構成要素として、例えば図７に示すように、記憶部１１０と、送受信部１２０’と、判定部１３０と、エラー出力部１４０と、演算部１５０’と、を備える。このうち、記憶部１１０、判定部１３０およびエラー出力部１４０は第１実施形態と共通のため、説明を省略する。

送受信部１２０’は、ＧＷ１０’がネットワークを介してＥＣＵ２０’と通信するモジュールであり、サブモジュールとして、指示送信部１２１と、リクエスト受信部１２２’と、補助データ送信部１２４と、を含む。このうち、指示送信部１２１は第１実施形態と共通のため、説明を省略する。

リクエスト受信部１２２’は、指示送信部１２１が送信した共有開始指示に応じてＥＣＵ２０’から送信された配布リクエストを受信する。この配布リクエストには、ＧＷ１０’の公開鍵を用いて暗号化されたＰＵＦ出力が含まれている。ＧＷ１０’の公開鍵を用いて暗号化されたＰＵＦ出力そのものを、配布リクエストとしてもよい。ＰＵＦ出力は、ＥＣＵ２０’に搭載されたＰＵＦが出力するデータであり、ＥＣＵ２０’に固有の固有データである。本実施形態では、ＧＷ１０’が生成する補助データとＰＵＦ出力とから、ＥＣＵ２０’において事前共有鍵が導出される。つまり、ＧＷ１０’は、ＥＣＵ２０’の固有データであるＰＵＦ出力から事前共有鍵を導出するための補助データを算出してＥＣＵ２０’に送信する。ＥＣＵ２０’は、ＧＷ１０’から受信した補助データを用いて、自身のＰＵＦ出力から事前共有鍵を導出する。配布リクエストに含まれる暗号化されたＰＵＦ出力は、ＧＷ１０’の公開鍵に対応する秘密鍵を用いて復号される。

補助データ送信部１２４は、判定部１３０により、リクエスト受信部１２２’が受信した配布リクエストの数が、配布対象グループに対応する数特定情報により特定される数、つまり、配布対象グループに属するＥＣＵ２０’の数を超えないと判定された場合に、配布リクエストを送信したＥＣＵ２０’に対して、配布対象グループに属するＥＣＵ２０’間で共有される事前共有鍵を導出するための補助データを送信する。

補助データ送信部１２４は、配布リクエストを送信したＥＣＵ２０’のそれぞれに対し、各ＥＣＵ２０’のＰＵＦ出力を用いて算出された補助データを送信する。例えば、補助データ送信部１２４は、リクエスト受信部１２２’が受信した配布リクエストに含まれる送信元の情報から、補助データを送信すべきＥＣＵ２０’を特定する。そして、補助データ送信部１２４は、このＥＣＵ２０’を宛先として、このＥＣＵ２０’のＰＵＦ出力から事前共有鍵を導出するための補助データを送信する。

また、補助データ送信部１２４は、各ＥＣＵ２０’に送信すべき補助データのそれぞれを、ネットワーク上にブロードキャストしてもよい。この場合、補助データ送信部１２４は、補助データを用いて導出される事前共有鍵の正当性を検査するための検査用データを併せて送信する。検査用データとしては、事前共有鍵のハッシュ値や、ＧＷ１０’とＥＣＵ２０’との双方が記憶する所定の値を事前共有鍵により暗号化した値などを用いることができる。検査用データとして事前共有鍵のハッシュ値を用いる場合、ＥＣＵ２０’は、受信した補助データとＰＵＦ出力とから導出される事前共有鍵のハッシュ値を算出し、この算出したハッシュ値がＧＷ１０’から送信されたハッシュ値と一致するか否かを判定することで、事前共有鍵の正当性を検査することができる。また、検査用データとして所定の値を事前共有鍵により暗号化した値を用いる場合、ＥＣＵ２０’は、受信した補助データとＰＵＦ出力とから導出される事前共有鍵を用いて所定の値を暗号化し、得られた値がＧＷ１０’から送信された値と一致するか否かを判定することで、事前共有鍵の正当性を検査することができる。

演算部１５０’は、リクエスト受信部１２２’が受信した配布リクエストの数が、配布対象グループに対応する数特定情報により特定される数、つまり、配布対象グループに属するＥＣＵ２０’の数を超えないと判定部１３０によって判定された場合に、ＥＣＵ２０’に対する補助データの送信に必要な各種の演算を実行する。具体的には、演算部１５０’は、リクエスト受信部１２２’が受信した配布リクエストに含まれる暗号化されたＰＵＦ出力を、ＧＷ１０’の公開鍵に対応する秘密鍵を用いて復号する。また、演算部１５０’は、ＥＣＵ２０’のＰＵＦ出力とＥＣＵ２０’が共有すべき事前共有鍵とに基づいて、ＰＵＦ出力から事前共有鍵を導出するための補助データを算出する。この演算部１５０’によって算出された補助データが、補助データ送信部１２４によってＥＣＵ２０’に送信される。また、事前共有鍵としてランダムあるいは所定の規則で選ばれたデータを用いる場合、演算部１５０’は、この事前共有鍵を生成する。

次に、本実施形態のＥＣＵ２０’の概要を説明する。図８は、本実施形態のＥＣＵ２０’の機能的な構成例を示すブロック図である。本実施形態のＥＣＵ２０’は、補助データの取得に関わる機能的な構成要素として、例えば図８に示すように、送受信部２１０’と、演算部２２０’と、記憶部２３０’と、ＰＵＦ２４０と、を備える。

送受信部２１０’は、ＥＣＵ２０’がネットワークを介してＧＷ１０’と通信するモジュールであり、サブモジュールとして、指示受信部２１１と、リクエスト送信部２１２’と、補助データ受信部２１４と、を含む。このうち、指示受信部２１１は第１実施形態と共通のため、説明を省略する。

リクエスト送信部２１２’は、指示受信部２１１が共有開始指示を受信した場合、ＧＷ１０’の公開鍵で暗号化されたＰＵＦ出力を含む配布リクエストを、ネットワークを介してＧＷ１０’に送信する。ＰＵＦ出力は、ＰＵＦ２４０から出力されるＥＣＵ２０’の固有データである。このＰＵＦ出力が、演算部２２０’によってＧＷ１０’の公開鍵を用いて暗号化される。この暗号化されたＰＵＦ出力が、配布リクエストとしてリクエスト送信部２１２’からＧＷ１０’に送信される。

補助データ受信部２１４は、ＧＷ１０’の補助データ送信部１２４が送信した補助データを受信する。ＧＷ１０’の補助データ送信部１２４が上述の検査用データを補助データとともに送信している場合、補助データ受信部２１４は、補助データとともに検査用データも受信する。

演算部２２０’は、補助データの取得に必要な各種の演算を実行する。具体的には、演算部２２０’は、指示受信部２１１が共有開始指示を受信した場合、ＰＵＦ２４０からＰＵＦ出力を取得し、このＰＵＦ出力をＧＷ１０’の公開鍵を用いて暗号化する。この暗号化されたＰＵＦ出力は、リクエスト送信部２１２’によって配布リクエストとしてＧＷ１０’に送信される。また、演算部２２０’は、補助データ受信部２１４が補助データを受信した場合、この補助データを記憶部２３０’に格納する。なお、補助データ受信部２１４が補助データとともに検査用データを受信した場合、演算部２２０’は、検査用データを用いて事前共有鍵の正当性を検査し、事前共有鍵が正しいことが確認された場合に、補助データ受信部２１４が受信した補助データを記憶部２３０’に格納する。

また、演算部２２０’は、ＥＣＵ２０’が事前共有鍵を必要とする場合、すなわちＥＣＵ２０’が同じグループに属する他のＥＣＵ２０’と通信する場合に、ＰＵＦ２４０からＰＵＦ出力を取得するとともに記憶部２３０’から補助データを読み出し、ＰＵＦ出力と補助データとに基づいて、事前共有鍵を導出する。

記憶部２３０’は、指示受信部２１１が受信したＧＷ１０’の公開鍵、補助データ受信部２１４が受信した補助データなどを記憶する。

次に、図９を参照しながら、本実施形態のＧＷ１０’およびＥＣＵ２０’の動作例について説明する。図９は、本実施形態の処理手順の一例を示すフローチャートである。この図９のフローチャートで示す一連の処理手順は、配布対象グループごとに繰り返し実行される。

処理が開始されると、まず、ＧＷ１０’の判定部１３０が、カウンタを０に設定する（ステップＳ３０１）。次に、ＧＷ１０’の指示送信部１２１が、配布対象グループに対応する所定データを含む共有開始指示を、ＧＷ１０’の公開鍵とともにネットワーク上に送信する（ステップＳ３０２）。

ＧＷ１０’の指示送信部１２１が送信した共有開始指示とＧＷ１０’の公開鍵は、配布対象グループに属するＥＣＵ２０’の指示受信部２１１によって受信される（ステップＳ４０１）。そして、共有開始指示とＧＷ１０’の公開鍵とを受信したＥＣＵ２０’の演算部２２０’は、ＰＵＦ２４０からＰＵＦ出力を取得し（ステップＳ４０２）、ＰＵＦ出力をＧＷ１０’の公開鍵を用いて暗号化する（ステップＳ４０３）。そして、ＥＣＵ２０’のリクエスト送信部２１２’が、暗号化されたＰＵＦ出力を含む配布リクエストをＧＷ１０’に送信する（ステップＳ４０４）。

ＥＣＵ２０’のリクエスト送信部２１２’が送信した配布リクエストは、ＧＷ１０’のリクエスト受信部１２２’によって受信される（ステップＳ３０３）。そして、リクエスト受信部１２２’により配布リクエストが受信されると、ＧＷ１０’の判定部１３０は、カウンタをインクリメントする（ステップＳ３０４）。その後、判定部１３０は、指示送信部１２１が共有開始指示を送信してから所定時間が経過したか否かを判定する（ステップＳ３０５）。ここで、所定時間が経過していなければ（ステップＳ３０５：Ｎｏ）、ステップＳ３０３に戻って次の配布リクエストの受信を待つ。

一方、指示送信部１２１が共有開始指示を送信してから所定時間が経過すると（ステップＳ３０５：Ｙｅｓ）、判定部１３０は、受信した配布リクエストの数をカウントするカウンタ値が、配布対象グループに対応する数特定情報によって特定される数、つまり、配布対象グループに属するＥＣＵ２０’の数を超えたか否かを判定する（ステップＳ３０６）。そして、カウンタ値が配布対象グループに属するＥＣＵ２０’の数を超えたと判定されると（ステップＳ３０６：Ｙｅｓ）、ＧＷ１０’のエラー出力部１４０が、不正な配布リクエストを送信する電子機器がネットワークに接続されていることを示すエラー信号を出力する（ステップＳ３０７）。

一方、カウンタ値が配布対象グループに属するＥＣＵ２０’の数を超えていないと判定された場合は（ステップＳ３０６：Ｎｏ）、ＧＷ１０’の演算部１５０’が、配布リクエストに含まれる暗号化されたＰＵＦ出力を、ＧＷ１０’の公開鍵に対応する秘密鍵を用いて復号する（ステップＳ３０８）。そして、演算部１５０’は、復号したＰＵＦ出力とＥＣＵ２０’が共有すべき事前共有鍵とに基づいて、ＰＵＦ出力から事前共有鍵を導出するための補助データを算出する（ステップＳ３０９）。そして、ＧＷ１０’の補助データ送信部１２４が、演算部１５０’により算出された補助データを、配布リクエストに対する応答としてＥＣＵ２０’に送信する（ステップＳ３１０）。

ＧＷ１０’の補助データ送信部１２４が送信した補助データは、ＥＣＵ２０’の補助データ受信部２１４によって受信される（ステップＳ４０５）。そして、補助データ受信部２１４により補助データが受信されると、ＥＣＵ２０’の演算部２２０’が、この補助データを記憶部２３０’に格納する（ステップＳ４０６）。

なお、本実施形態においても第１実施形態と同様に、ＧＷ１０’の判定部１３０による判定および補助データ送信部１２４による補助データの送信を、ＥＣＵ２０’からの配布リクエストをリクエスト受信部１２２’が受信するたびに行い、受信した配布リクエストの数をカウントするカウンタ値が、配布対象グループに属するＥＣＵ２０’の数を超えた時点で、エラー出力部１４０がエラー信号を出力するとともに、車載ネットワークシステム１の動作を停止して、すでに送信した補助データを無効化する構成としてもよい。

以上、具体的な例を挙げながら詳細に説明したように、本実施形態の車載ネットワークシステム１では、ＧＷ１０’が、共有開始指示に応じてＥＣＵ２０’から送信される配布リクエストを受信し、受信した配布リクエストの数が配布対象グループに属するＥＣＵ２０’の数を超えるか否かを判定する。そして、受信した配布リクエストの数が配布対象グループに属するＥＣＵ２０’の数を超える場合は、不正な配布リクエストを送信する電子機器がネットワークに接続されていることを示すエラー信号を出力するようにしている。このように、本実施形態によれば、第１実施形態と同様に、通信を行うＥＣＵ２０’同士が共有すべき事前共有鍵を他の電子機器が不正に取得しようとする試みを検知して、例えば自動車Ｖのメンテナンス作業員やドライバなどに適切な対応を促すことができる。

また、ＧＷ１０’は、受信した配布リクエストの数が配布対象グループに属するＥＣＵ２０’の数を超えない場合に、配布リクエストに応じて、配布対象グループに属するＥＣＵ２０に対し、ＰＵＦ出力から事前共有鍵を導出するための補助データを送信するようにしている。したがって、本実施形態によれば、第１実施形態と同様に、不正な電子機器がネットワークに接続された場合であっても、通信を行うＥＣＵ２０’同士が事前共有鍵を正しく共有して、この事前共有鍵を用いた認証などによってＥＣＵ２０’間の通信の正当性を保証することができる。

また、特に本実施形態では、ＧＷ１０’が事前共有鍵そのものを記憶するのではなく、ＰＵＦ出力から事前共有鍵を導出するための補助データを記憶する構成であるため、ＥＣＵ２０’に対する不正な攻撃によって事前共有鍵が漏出するリスクを低減し、より安全な車載ネットワークシステム１を実現することができる。

＜変形例＞
以上説明した第２実施形態では、ＥＣＵ２０’のＰＵＦ出力を暗号化するためにＧＷ１０’の公開鍵を用い、ＧＷ１０’の公開鍵に対応する秘密鍵を用いて、暗号化されたＰＵＦ出力を復号している。しかし、これら公開鍵および秘密鍵に代えて、ＧＷ１０’とＥＣＵ２０’とで共通の暗号鍵を用いて、ＥＣＵ２０’のＰＵＦ出力の暗号化および復号を行う構成としてもよい。例えば、ＥＣＵ２０’の事前共有鍵を定期的あるいは所定の指示に従って更新する場合、過去の事前共有鍵を用いてＥＣＵ２０’のＰＵＦ出力の暗号化および復号を行うことができる。また、ＧＷ１０’とＥＣＵ２０’との双方に予め埋め込まれた共通の暗号鍵がある場合、この暗号鍵を用いて、ＥＣＵ２０’のＰＵＦ出力の暗号化および復号を行うようにしてもよい。

＜補足説明＞
ＧＷ１０，１０’の上述した機能は、例えば、図２に示したハードウェアとソフトウェアとの協働により実現することができる。この場合、マイクロコントローラ１２がネットワークＩ／Ｆ１１を利用しながら、ソフトウェアとして提供されるプログラムに応じた制御を実行することにより、上述した機能的な構成要素が実現される。

ＧＷ１０，１０’の機能的な構成要素を実現するプログラムは、例えば、マイクロコントローラ１２内のメモリ領域などに予め組み込んで提供される。また、上記プログラムは、インストール可能な形式または実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤなどのコンピュータ読み取り可能な記録媒体に記録されて提供されるようにしてもよい。また、上記プログラムを、インターネットなどのネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、上記プログラムを、インターネットなどのネットワーク経由で提供または配布するように構成してもよい。なお、ＧＷ１０，１０’における上述した機能的な構成要素は、その一部または全部を、ＡＳＩＣやＦＰＧＡなどの専用のハードウェアを用いて実現することも可能である。

以上、本発明の実施形態を説明したが、この実施形態は例として提示したものであり、発明の範囲を限定することは意図していない。この新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１ 車載ネットワークシステム
１０，１０’ ＧＷ
２０，２０’ ＥＣＵ
１１０ 記憶部
１２０，１２０’ 送受信部
１２１ 指示送信部
１２２，１２２’ リクエスト受信部
１２３ 鍵送信部
１２４ 補助データ送信部
１３０ 判定部
１４０ エラー出力部
１５０，１５０’ 演算部

Claims (13)

1. 複数の電子機器とネットワークを介して接続されるデータ配布装置であって、
   電子機器のグループごとに、グループに対応する所定データと、グループに属する電子機器の数を特定するための数特定情報とを対応付けたグループ管理情報を記憶する記憶部と、
   前記所定データを含む共有開始指示を送信する指示送信部と、
   前記共有開始指示に応じて電子機器から送信された配布リクエストを受信するリクエスト受信部と、
   受信した配布リクエストの数が前記数特定情報により特定される数を超えるか否かを判定する判定部と、
   受信した配布リクエストの数が前記数特定情報により特定される数を超える場合に、不正な配布リクエストを送信する電子機器が前記ネットワークに接続されていることを示すエラー信号を出力するエラー出力部と、を備えるデータ配布装置。
2. 受信した配布リクエストの数が前記数特定情報により特定される数を超えない場合に、グループに属する電子機器が共有すべき共有鍵を、受信した配布リクエストに対する応答として電子機器に送信する鍵送信部をさらに備え、
   前記リクエスト受信部は、電子機器により生成された一時鍵を含む前記配布リクエストを受信し、
   前記鍵送信部は、前記一時鍵により暗号化した前記共有鍵を電子機器に送信する、請求項１に記載のデータ配布装置。
3. 前記指示送信部は、データ配布装置の公開鍵を前記共有開始指示とともに送信し、
   前記リクエスト受信部は、前記公開鍵により暗号化された前記一時鍵を含む前記配布リクエストを受信し、
   前記鍵送信部は、前記公開鍵に対応する秘密鍵により復号された前記一時鍵により暗号化した前記共有鍵を電子機器に送信する、請求項２に記載のデータ配布装置。
4. 前記リクエスト受信部は、過去に共有した共有鍵により暗号化された前記一時鍵を含む前記配布リクエストを受信し、
   前記鍵送信部は、過去に共有した共有鍵により復号された前記一時鍵により暗号化した新たな共有鍵を電子機器に送信する、請求項２に記載のデータ配布装置。
5. 受信した配布リクエストの数が前記数特定情報により特定される数を超えない場合に、グループに属する電子機器が共有すべき共有鍵を電子機器において導出するための補助データを、受信した配布リクエストに対する応答として電子機器に送信する補助データ送信部をさらに備え、
   前記リクエスト受信部は、電子機器に固有の固有データを含む前記配布リクエストを受信し、
   前記補助データ送信部は、前記固有データと前記共有鍵とから算出される前記補助データを電子機器に送信する、請求項１に記載のデータ配布装置。
6. 前記指示送信部は、データ配布装置の公開鍵を前記共有開始指示とともに送信し、
   前記リクエスト受信部は、前記公開鍵により暗号化された前記固有データを含む前記配布リクエストを受信し、
   前記鍵送信部は、前記公開鍵に対応する秘密鍵により復号された前記固有データと前記共有鍵とから算出される前記補助データを電子機器に送信する、請求項５に記載のデータ配布装置。
7. 前記リクエスト受信部は、過去に共有した共有鍵により暗号化された前記固有データを含む前記配布リクエストを受信し、
   前記鍵送信部は、過去に共有した共有鍵により復号された前記固有データと新たな共有鍵とから算出される前記補助データを電子機器に送信する、請求項５に記載のデータ配布装置。
8. 前記所定データは、対応するグループに属する電子機器の間で送受信される制御信号である、請求項１乃至７のいずれか一項に記載のデータ配布装置。
9. 前記所定データは、対応するグループに対して割り当てられたグループ識別情報である、請求項１乃至７のいずれか一項に記載のデータ配布装置。
10. 前記所定データは、対応するグループに属する電子機器それぞれに割り当てられた電子機器識別情報の集合である、請求項１乃至７のいずれか一項に記載のデータ配布装置。
11. 請求項１乃至１０のいずれか一項に記載のデータ配布装置と、
    前記データ配布装置とネットワークを介して接続された複数の電子機器と、を備える通信システム。
12. 請求項１１に記載の通信システムを搭載した移動体。
13. 複数の電子機器とネットワークを介して接続されるデータ配布装置により実行されるデータ配布方法であって、
    前記データ配布装置は、
    電子機器のグループごとに、グループに対応する所定データと、グループに属する電子機器の数を特定するための数特定情報とを対応付けたグループ管理情報を記憶する記憶部を備え、
    前記所定データを含む共有開始指示を送信するステップと、
    前記共有開始指示に応じて電子機器から送信された配布リクエストを受信するステップと、
    受信した配布リクエストの数が前記数特定情報により特定される数を超えるか否かを判定するステップと、
    受信した配布リクエストの数が前記数特定情報により特定される数を超える場合に、不正な配布リクエストを送信する電子機器が前記ネットワークに接続されていることを示すエラーを出力するステップと、を含むデータ配布方法。

Images