WO2023187896A1 - 通信システム、送信機、及び受信機 - Google Patents

Abstract

送信機と受信機の間で鍵を用いてセキュリティ通信を行う通信システムであって、前記鍵を前記セキュリティ通信中に変更可能であって、前記送信機は、変更後の新鍵が使用可能になると、鍵変更タイミングに関する通知を送信し、前記新鍵が使用可能になった後の第１の所定の期間において変更前の旧鍵でデータを送信し、前記受信機は、前記新鍵が使用可能になった後の第２の所定の期間において前記旧鍵で受信時の認証処理を行い、前記送信機から前記鍵変更タイミングに関する通知を受信した場合、鍵変更タイミングより前に送信されたデータは前記旧鍵で認証処理を行い、前記鍵変更タイミングより後に送信されたデータは前記新鍵で認証処理を行う。

Description

通信システム、送信機、及び受信機

　本発明は、セキュリティ通信を行う通信システムに関する。

　コンピュータのセキュリティ通信の一つになりすまし防止の仕組みがある。例えば、通信機間で共通する鍵を用いてハッシュ値を計算し、受信機の計算結果と比較して受信したハッシュ値と計算したハッシュ値が一致するかを判定する。

　自動車の車載用ソフトウェアに活用されるＡＵＴＯＳＡＲ仕様によれば、ＣＡＮメッセージフレームに共通鍵で算出されるＭＡＣ(Message Authentication Code)を付与して、なりすまし防止ができる。また、フレッシュネス値を追加して、再送信攻撃を防止できる。

　共通鍵を用いたセキュリティ通信では、鍵変更時に各通信機における鍵変更のタイミングが同時ではない場合、セキュリティ通信の認証失敗によって、通信不可能な状態が生じる。また、認証失敗時の通知が発生し、通信負荷が増加する可能性がある。

　鍵変更に関する背景技術は以下のものが存在する。第一に鍵変更を各通信機器で逐次実行する方法があり、第二に鍵変更時は鍵変更モードなどに移行してネットワーク上の通信機の鍵をすべて変更完了させてから、通常モードに復帰する方法がある。

　第一の場合では、鍵変更が完了するタイミングの差によって、ネットワーク上の機器間で鍵が異なる期間が生じ、当該期間でセキュリティ通信が不可能な期間が生じ、セキュリティ通信の失敗が発生する。

　第二の場合では、鍵変更モードでは、通常モードで利用する少なくともセキュリティ通信機能が制限されるため、鍵変更処理は特定の状況に制約される。

　通信中に鍵を変更する技術として、以下の背景技術がある。特許文献１（特開２０１２－２２７６７２号公報）には、共通鍵を管理する鍵管理サーバ、路側機、車載機で構成する車車／路車間通信システムにおいて、鍵管理サーバがエリアの管理をおこない、あるエリアに存在する路側機および車載機は同じ共通鍵を共有し、共有した共通鍵を使ってメッセージの機密性または完全性、もしくはその両方を保証することを特徴とする車車／路車間通信システムが記載されている。

特開２０１２－２２７６７２号公報

　前述した背景技術では、本願が想定するような、任意のタイミングで使用する鍵を変更する場合や、予め決まっていない任意の鍵に変更する場合、未知の新しい鍵の変更タイミングの特定が困難である。また、通信機器間で鍵変更タイミングを合わせるため、時刻同期が必要である。

　本発明は、鍵変更に伴うセキュリティ通信の失敗の軽減を目的とする。

　本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、送信機と受信機の間で鍵を用いてセキュリティ通信を行う通信システムであって、前記鍵を前記セキュリティ通信中に変更可能であって、前記送信機は、変更後の新鍵が使用可能になると、鍵変更タイミングに関する通知を送信し、前記新鍵が使用可能になった後の第１の所定の期間において変更前の旧鍵でデータを送信し、前記受信機は、前記新鍵が使用可能になった後の第２の所定の期間において前記旧鍵で受信時の認証処理を行い、前記送信機から前記鍵変更タイミングに関する通知を受信した場合、前記鍵変更タイミングより前に送信されたデータは前記旧鍵で認証処理を行い、鍵変更タイミングより後に送信されたデータは前記新鍵で認証処理を行うことを特徴とする。

　本発明の代表的な実施の形態によれば、鍵変更に伴うセキュリティ通信の失敗を軽減できる。前述した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。

本発明の実施例の送信機の処理の例のフローチャートである。 本発明の実施例の受信機の処理の例のフローチャートである。 第１の方法における受信機の処理の例のフローチャートである。 第１の方法における受信機の処理の例のフローチャートである。 第２の方法における受信機の処理の例のフローチャートである。 第２の方法における受信機の処理の例のフローチャートである。 本実施例の動作例のタイミングチャートである。 第２の方法の動作例のタイミングチャートである。 受信処理順序が入れ替わる場合の説明図である。 本実施例の鍵変更のタイミングを示す図である。 本実施例の鍵変更のタイミングを示す図である。 本発明の実施例の送信機と受信機の構成を示す図である。

　本発明の実施例は、鍵変更の指令がなされたとき、鍵の受け取り完了後に、送信機は古い鍵での送信を所定の期間１だけ継続し、受信機は古い鍵での受信メッセージの認証を所定の期間２だけ行う。

　ここで、鍵受け取り完了のタイミングとは、使用する鍵を切り替え可能な状態としてもよい。また、予め次に使用する共通鍵が決まっている場合は、次の共通鍵を使用する指令などを受け取ったタイミングを鍵受け取り完了のタイミングとしてもよい。また、鍵受け取り完了のタイミングは、日時などで予め指定されてもよい。

　旧鍵は、送信機、受信機ともに所定の期間１や所定の期間２の終了後に削除したり、ロックしてもよい。旧鍵は、鍵の不一致期間と送信、受信処理順序が入れ替わった場合に使用するので、入れ替わりによる旧鍵で認証されるフレームを受信できなくなった場合に削除したりロックしてもよい。送信機の場合では、使用する鍵を新鍵に切り替えたタイミング以降では、旧鍵を使った送信処理を行わないので直ちに削除してもよい。例示した以外のタイミングでもよく、削除タイミングは様々なタイミングでよい。

　所定の期間１と所定の期間２を決定し設定する方法の例について説明する。

　第１の方法として、フレッシュネス値で鍵の変更タイミングを特定する方法について説明する。

　図１は、送信機の処理の例のフローチャートであり、図２、図３Ａ及び図３Ｂは、受信機の処理の例のフローチャートである。図２は、使用する鍵の変更タイミングが決定するまでの処理を記載し、図３Ａ及び図３Ｂは、鍵変更処理が開始してから、鍵の切り替えが完了するまでの受信処理を記載する。図１と図２は、それぞれ鍵変更指令を受信したときに開始されてもよい。図３Ａ及び図３Ｂは、受信機が鍵変更指令を受信してから旧鍵を用いた送信がされなくなるまでの間のセキュリティ通信の受信処理でもよい。

　第１の方法では、期間の一例はフレッシュネス値とするが、通信機器間でタイミングを計れる値であればよく、時間や通信回数などを使用できる。

　図１に示すように、送信機は、鍵変更タイミングで鍵管理装置から新鍵を受け取って、新鍵が使用可能となるまで待機し（Ｓ１０１）、所定の時間が経過してタイムアウトするまで（Ｓ１０７）、鍵準備完了通知１を受信したかを判定する（Ｓ１０２）。鍵準備完了通知１を受信せずに所定の時間が経過してタイムアウトした場合（Ｓ１０７でＹＥＳ）、タイムアウト時の処理を実行する（Ｓ１０８）。タイムアウト時の処理は任意のものでよく、その一例は、鍵の変更処理をキャンセルしたり、エラー通知をするものとしてもよい。また、タイムアウトを設けずに処理を継続してもよい。一方、鍵準備完了通知１を受信した場合（Ｓ１０２）、鍵変更タイミングを決定し（Ｓ１０３）、鍵変更タイミング通知２を送信する（Ｓ１０４）。鍵変更タイミングは、受信側の準備時間後の将来のタイミングであり、例えば、現在時刻（現在のフレッシュネス値）に所定値を加算して計算できる。フレッシュネス値でなく時間や通信シーケンスを計測できる値を使用してもよい。データの到着順乱れを考慮するとシーケンシャルに付与されるフレッシュネス値を採用するとよい。鍵変更タイミング通知２には、鍵変更するときのフレッシュネス値を含める。この値までが所定の期間１（図６の時間１ａ）であり、将来のタイミングとすることが望ましいが、受信機が鍵変更タイミング通知２を十分に受信できる期間となるように設定するとよく、例えば、通信の設計に基づいた値を設定しても、通信負荷や頻度や相手数など通信状況に基づいて設定してもよいし、これらに基づいて動的に設定してもよい。

　その後、送信機は、鍵変更タイミング３に到達したかを判定する（Ｓ１０５）。鍵変更タイミングに到達していなければ、鍵変更タイミング通知を所定のタイミングで繰り返し送信し（Ｓ１０９）、鍵変更タイミングに到達したかの判定を続ける。一方、鍵変更タイミングに到達していれば、送信時に使用する鍵を切り替える（Ｓ１０６）。ステップＳ１０９における定期送信は、鍵変更到達タイミングまでに所定の回数が送信されるように、その送信間隔が設定されてもよい。

　図２に示すように、受信機は、新鍵が使用可能となるまで待機し（Ｓ２０１）、鍵受け取りを完了した場合、鍵準備完了通知１を送信する（Ｓ２０２）。そして、鍵変更タイミング通知２を受信したかを判定する（Ｓ２０３）。鍵変更タイミング通知２を受信しない場合、ステップＳ２０２に戻り、鍵変更タイミング通知２を受信するまで、鍵準備完了通知１を送信してもよい。鍵変更タイミング通知２を複数回送信してもよい。一方、鍵変更タイミング通知２を受信した場合、受信した鍵変更タイミング通知に従って、鍵変更タイミング３を決定する（Ｓ２０４）。ステップＳ２０２の送信前に、所定時間の待機を追加してもよい。受信機が新鍵を受け取るまでに必要な最大の時間を待機することで、鍵準備完了通知１が受信されない場合を減らすことができる。所定の時間までに、ステップＳ２０３において、鍵変更タイミング通知２を受信できなかった場合、タイムアウト時の処理を実行してもよい。一例は、鍵変更処理のキャンセルやエラーの通知である。

　送信機は、受信機が複数存在する場合、全ての受信機から鍵準備完了通知１を受け取ってから、鍵変更タイミング通知２を送信するとよい。少なくとも一部の受信機から鍵準備完了通知１を受け取れない場合に、タイムアウトを設定して以降の処理を続行させてもよい。この場合、鍵準備完了通知１を受信できなかった受信機を無視して、新しい鍵を用いた送受信処理を続けてもよいし、ネットワーク全体の通信を制限してもよい。このような場合に実行される所定の処理をステップＳ１０８で実行してもよい。タイムアウトが発生した場合にタイムアウト時の任意の処理を実行してもよい。例えば、エラーの通知や、鍵変更処理のキャンセルをしてもよい。

　図３Ａ及び図３Ｂに示すように、受信機は、鍵変更指令の受信後、受信データから受信フレッシュネス値を抽出する（Ｓ３０１）。なお、毎回フレッシュネス値を抽出せずに、前回受信したフレッシュネス値から推測してもよい。鍵変更タイミング通知２を受信しているかを判定する（Ｓ３０２）。そして、鍵変更タイミング通知２を受信した場合、受信フレッシュネス値が鍵変更タイミング以降であるかを判定する（Ｓ３０３）。そして、鍵変更タイミング以降の受信フレッシュネス値のタイミングでは新鍵で受信し（Ｓ３０４）、鍵変更タイミング以前の受信フレッシュネス値のタイミングでは旧鍵で受信する（Ｓ３０５）。このタイミングまでが所定の期間２（図６の２ａ）となる。タイミングを時間や通信回数などで定める場合も同様に、鍵変更タイミング以前か以降かによって使用する鍵を分けるとよい。

　その後、受信機は、認証が成功したかを判定する（Ｓ３０６）。例えば、認証は、送信されたデータとフレッシュネス値のハッシュ値が一致するかを判定するとよい。また、受信済みフレッシュネス値を再度の受信すると認証失敗と判定するとよい。認証に成功した場合、認証成功時処理を実行し（Ｓ３０７）、認証に失敗した場合、認証失敗時処理を実行する（Ｓ３０８）。受信機が鍵変更タイミング通知２を受信している場合は、認証失敗の要因は新鍵と旧鍵との切り替え処理における使用鍵の間違いであることは、理論上は無いと考えることもできる。従って、鍵の切り替え処理における認証失敗時の処理や成功時の処理（Ｓ３０８、Ｓ３０７）を行わず、もともとの認証結果に応じた処理を行ってもよいし、ステップＳ３０７、Ｓ３０８はもともとの認証結果に応じた処理としてもよい。

　ステップＳ３０２で鍵変更タイミング通知２を受け取れなかった場合、新鍵で受信経験あり、かつ受信フレッシュネス値が鍵変更タイミング以降（所定の期間２（図６の２ｂ））であるかを判定する（Ｓ３１６）。新鍵で受信経験ない、又は受信フレッシュネス値が鍵変更タイミング以降でない場合（Ｓ３１６でＮＯ）、新鍵か旧鍵か不明なので、旧鍵と新鍵の両方での認証を試行する。すなわち、旧鍵で認証し（Ｓ３０９）、認証が成功したかを判定する（Ｓ３１０）。旧鍵での認証に成功した場合、認証成功時処理を実行する（Ｓ３１４）。旧鍵での認証に失敗した場合、新鍵で認証し（Ｓ３１１）、認証が成功したかを判定する（Ｓ３１２）。新鍵での認証に成功した場合、以後は新鍵で認証をすればよいので受信フレッシュネス値で鍵変更タイミングを変更し、そのタイミングを所定の期間２（図６の２ｂ）の終了タイミングとする（Ｓ３１３）。新鍵での認証に失敗した場合、認証失敗時処理を実行する（Ｓ３１５）。

　一方、新鍵で受信経験あり、かつ受信フレッシュネス値が鍵変更タイミング以降である場合（Ｓ３１６でＹＥＳ）、新鍵で認証し（Ｓ３１７）、認証が成功したかを判定する（Ｓ３１８）。新鍵での認証に成功した場合、認証成功時処理を実行する（Ｓ３１９）。新鍵での認証に失敗した場合、認証失敗時処理を実行する（Ｓ３２０）。すなわち、新鍵で認証した以降のフレッシュネス値のタイミングにおいては新鍵で認証する。

　ステップＳ３１３において、複数の受信について新鍵での認証に成功した場合、フレッシュネス値が小さいものを採用し、当該小さいフレッシュネス値で鍵変更タイミングを変更する。旧鍵で認証成功したフレッシュネス値の最大値を記録し、当該最大値以下の受信では、新鍵による認証を試みなくてもよい。鍵変更タイミング通知２を受け取れなかった場合をエラーとしてもよく、その場合は旧鍵での認証失敗後の新鍵での再認証処理を実行しなくてもよい。旧鍵によるセキュリティ通信を受信しなくなったとき、旧鍵による受信を停止して、新鍵による通常のセキュリティ通信処理を実行してもよい。

　旧鍵か新鍵かが明らかでないフレッシュネス値、即ち、新鍵で受信したフレッシュネス値の最大値と新鍵で受信したフレッシュネス値の最小値の間の値について、最初に新鍵と旧鍵どちらの鍵で試行するかを、そのフレッシュネス値に応じて決めてもよい。例えば、旧鍵の最大値に近い値である場合は旧鍵でまず試行し、新鍵の最小値に近い値の場合は新鍵で試行するようにしてもよい。

　なお、Ｓ３０２で鍵変更タイミング通知２を受け取れなかった場合のステップＳ３１１、Ｓ３１２、Ｓ３１３の処理は、鍵変更タイミング通知２の受信に失敗した場合の対策となるオプションの処理であり、Ｓ３０２で鍵変更タイミング通知２を受け取れなかった場合に新鍵での認証試行を行わず認証エラー（例えばＳ３１５）としてもよい。

　鍵変更タイミング２を受信するまでの間（Ｓ３０２がＮＯの間）は、旧鍵を用いた通常の認証処理が行われるものとしてもよい。

　前述の構成にすることで、使用する鍵の変更タイミングをフレッシュネス値で明確に決定できるので、新鍵と旧鍵との鍵の不一致を要因とした認証失敗が生じない。その為、本当の認証失敗の発生タイミングを直ちに把握できる。また、フレッシュネス値でタイミングを特定する場合、フレッシュネス値に応じて使用する鍵を変えるので、送信処理順序や受信処理順序の入れ替わりの影響を受けない。

　図７に示すように、フレッシュネス値が１～４までを旧鍵、５以降を新鍵で送信する場合を例にして、受信処理順序の入れ替わり時の処理例を説明する。

　フレッシュネス値を用いず、受信処理順序通りに処理する場合、３を受信した後、６を受信し、旧鍵で失敗した後新鍵でリトライして認証できる。受信処理順序の入れ替わりがない場合は、以降の受信処理は新鍵を用いれば認証可能である。しかし、図７に示す例のように受信処理順序が入れ替わる場合、フレッシュネス値が５において新鍵を用いたデータ受信した後、フレッシュネス値が４において旧鍵を用いたデータを受信する場合がある。新鍵で認証に失敗した場合、旧鍵でリトライすることによって認証できる。フレッシュネス値を用いない場合は、フレッシュネス値がメッセージに含まれなくてもよい。

　フレッシュネス値を用いる場合、送信機はフレッシュネス値を順に増加するカウンタとしてセキュリティフレームを送信し、受信機は送受信メッセージに含まれるフレッシュネ値で使用する鍵を判定する。すなわち、旧鍵から新鍵へ変えるフレッシュネス値を設定し、当該フレッシュネス値より大きいか小さいかで新旧鍵を使い分ける。鍵変更タイミング通知２で新鍵を用いるフレッシュネス値を鍵変更タイミング３として通知する。図７に示す例では５が通知される。受信機は、フレッシュネス値が５未満の場合は旧鍵で認証処理を実行し、フレッシュネス値が５以上の場合は新鍵で認証処理を実行する。

　このため、図７に示すように、受信側でフレッシュネス値４～６の範囲で受信順序が入れ替わっても、セキュリティフレームを受信するための鍵を一意に特定でき、再認証が不要となる。また、セキュリティ通信に使用されるフレッシュネス値を用いるので、メッセージ構成の変更が不要である。

　ここで、鍵変更タイミング通知２と鍵準備完了通知１は、既存の通信に用いる信号で代用してもよい。例えば、同期用の信号で代用できる。具体的には、定期的にＭＡＣ値を付与して送信されるフレッシュネス値の同期用の信号に、新鍵でのＭＡＣ値を付与して送信する。受信機は同期用の信号の認証を旧鍵で失敗し新鍵で成功したとき、それが鍵変更タイミング通知２と判断することができる。このとき、旧鍵で計算したＭＡＣを付与したものを並行して送信してもよいし、新鍵で計算したもののみを送信してもよい。

　第２の方法として、ＭＡＣ認証の成否で使用する鍵の切り替えを行う方法について説明する。

　第２の方法における送信機の処理のフローチャートの例は、図１のステップＳ１０２において常にＹＥＳとなり、ステップＳ１０４において所定の時間だけ待機した後に鍵変更タイミング通知２を送信する場合と同じである。

　図４Ａ及び図４Ｂは、第２の方法における受信機の処理の例のフローチャートである。

　ここでは、所定の期間１（図６の１ｂ）は、受信機の新しい鍵の利用準備が完了できる十分な時間とするとよい。例えば、所定の期間１は、通信系の設計に基づいて設計者やユーザが任意に設定してもよく、バス負荷などに基づいて送信機や受信機などの通信機器が算出してもよく、送信回数などの通信機の処理に基づく条件で設定してもよい。

　受信機は、鍵変更指令受信以降、鍵の準備完了時に所定の期間２（図６の２ｂ）を開始し、新鍵で認証成功経験があるかを判定する（Ｓ４０１）。新鍵で認証成功経験があれば、新鍵で認証し（Ｓ４０９）、認証が成功したかを判定する（Ｓ４１０）。新鍵での認証に成功した場合、認証成功時処理を実行する（Ｓ４１４）。新鍵での認証に失敗した場合、旧鍵で認証し（Ｓ４１１）、認証が成功したかを判定する（Ｓ４１２）。旧鍵での認証に成功した場合、認証成功時処理を実行する（Ｓ４１４）。旧鍵での認証に失敗した場合、認証失敗時処理を実行する（Ｓ４１５）。

　新鍵で認証成功経験がなければ、旧鍵で認証し（Ｓ４０２）、認証が成功したかを判定する（Ｓ４０３）。旧鍵での認証に成功した場合、認証成功時処理を実行する（Ｓ４０８）。旧鍵での認証に失敗した場合、新鍵で認証し（Ｓ４０４）、認証が成功したかを判定する（Ｓ４０５）。新鍵での認証に成功した場合、そのタイミングを所定の期間２（図６の２ｂ）の完了タイミングとして、認証成功時処理を実行する（Ｓ４０８）。新鍵での認証に失敗した場合、認証失敗時処理を実行する（Ｓ４０７）。

　受信機は、タイミングの判断にフレッシュネス値を用いて、第１の方法のように処理してもよいし、新鍵での認証成功タイミング以降の時間的タイミングであるかによって切り替えてもよい。フレッシュネス値をタイミングとして利用する場合、切り替えタイミングより遅いタイミングのフレッシュネス値の認証を旧鍵で失敗した場合は、新鍵で認証を行うとよい。複数の受信について新鍵での認証に成功した場合、フレッシュネス値が小さいものを採用し、当該小さいフレッシュネス値で鍵変更タイミングを変更する。旧鍵で認証成功したフレッシュネス値の最大値を記録し、当該最大値以下の受信では、新鍵による認証を試みなくてもよい。また、新鍵で認証を試みてから旧鍵で認証を試みてもよい。

　所定の期間２（図６の２ｂ）の間に新鍵での認証に成功した場合、所定の期間２（図６の２ｂ）を延長してもよい。このようにすることで、送信処理と受信処理の順序の入れ替わりによる認証失敗を抑制できる。例えば、新鍵で認証成功した後も、しばらくの間旧鍵での受信を許容する（Ｓ４１１）。継続する期間は、時間的に延長してもよいし、例えば「ｎ回受信するまで」のように受信回数で条件を設定してもよい。また、新鍵での認証に成功した場合、所定の期間２を短くしてもよい。新鍵での受信後に旧鍵での受信ができる期間を減らすことができる為、セキュリティが向上する。

　新鍵での認証成功後は、送信処理と受信処理の順序の入れ替わらない限り新鍵で認証される通信フレームを受信するので、新鍵で認証を試みてから旧鍵での認証を試みることで（Ｓ４０９、Ｓ４１０、Ｓ４１１、Ｓ４１２）、セキュリティ計算の回数を削減できる。また、新鍵での認証に成功するまでは、旧鍵での認証を先に試みることで（Ｓ４０２、Ｓ４０３、Ｓ４０４、Ｓ４０５）、セキュリティ計算の回数を削減できる。但し、通信確立の観点からは認証を試みる鍵の順番はいずれでもよい。

　所定の期間２（図６の２ｂ）が終了した後は、図４のフローチャートに代えて、新鍵を用いた通常の受信処理を行ってもよい。つまり、旧鍵を用いた通信を許容しない状態に移行してもよい。

　ステップＳ４０１で所定の期間内に新鍵での認証がされなかった場合、任意のエラー処理を実行してもよい。

　第２の方法では、第１の方法と比較して、処理の制御用に新たな信号を追加する必要がない。そのため、メッセージの種類の追加をすることなく、既存の通信機に第２の方法を適用できる。

　第２の方法では、第１の方法と比較して、旧鍵で認証失敗した場合に新鍵での認証も行うので、計算負荷が増加する。しかし、新鍵、旧鍵での再認証処理は実際の切り替えタイミングでのみ発生すること、受信順序の入れ替わり時のみ新鍵での複数回の再認証が必要なことから、負荷の増加を抑制できる。

　以上に説明した実施例を適用可能な通信機の例を説明する。本発明が適用可能な通信機は以下に例示する構成に限らず、適用先の変更や、類似機能を持つ構成要素への置き換えなどの種々の変形が可能である。

　通信機は、ＥＣＵなど一般的なコンピュータや電子回路で構成されるものでよい。また、ソフトウェアなどによって仮想的に実現されるものでもよい。送受信は、例えばプロセス間通信やモジュール間のデータの送受信など、ソフトウェア間のデータの送受信でもよい。

　本実施例の説明のため、通信機は送信機と受信機とで分けて構成する。送信機が受信機の機能を有してもよいし、受信機が送信機の機能を有してもよい。複数の送信機又は受信機がネットワークで接続される構成でもよい。

　送信機と受信機は、信号やデータの送受信が可能に接続される。通信の方法は有線、無線のいずれでもよく、いずれの通信方式でもよい。車載機器、ＥＣＵでは主に様々なＣＡＮ通信が用いられる。

　図１０は、本発明の実施例の送信機と受信機の構成を示す図である。

　本実施例における鍵を用いた暗号化通信は、ＥＣＵ１０、２０の間で行われる。また、ＥＣＵ１０、２０とゲートウェイ５０との間でも鍵を用いた暗号化通信が行われる。さらに、ＥＣＵ１０と管理センタ１００の間や、ゲートウェイ５０と管理センタ１００の間でも鍵を用いた暗号化通信が行われる。これらの場合、あるタイミングでは、一方の装置（例えばＥＣＵ１０）が送信機となり、対向する他方の装置（例えばＥＣＵ２０）が受信機となる。また、他のタイミングでは送受信が入れ替わって通信が行われる（例えば、ＥＣＵ２０が送信機となり、ＥＣＵ１０が受信機となる）。

　ＥＣＵ１０の内部には、マイコン１２が搭載されている。マイコン１２は、プログラムを実行する少なくとも一つのプロセッサ（ＣＰＵ）１３と、揮発性記憶領域を提供するＲＡＭ１４と、他の装置との通信を制御する少なくとも一つの通信部１５と、プログラムやデータを不揮発性記憶領域に保持する不揮発性メモリ１６を有する。同様にＥＣＵ２０の内部には、マイコン２２が搭載されている。マイコン２２は、プログラムを実行する少なくとも一つのプロセッサ（ＣＰＵ）２３と、揮発性記憶領域を提供するＲＡＭ２４と、他の装置との通信を制御する少なくとも一つの通信部２５と、プログラムやデータを不揮発性記憶領域に保持する不揮発性メモリ２６を有する。

　ゲートウェイ５０は、ＥＣＵ間の通信を制御する装置であり、プログラムを実行する制御部５１と、他の装置との通信を制御する通信部５２を有する。

　管制センタ１１０は、ＥＣＵ１０にデータやプログラムを提供する計算機であり、アプリケーション部１１１と通信部１１２とを有する。アプリケーション部１１１は、データやプログラムをＥＣＵ１０に提供する処理を実行する。通信部１１２は、ＥＣＵ１０やゲートウェイ５０との通信を制御する。

　通常時のセキュリティ通信では、送信機は共通鍵を用いて、送信するデータとフレッシュネス値を入力にハッシュ値（ここでは主にＭＡＣを扱う）を計算する。前述した第２の方法については、フレッシュネス値は必須ではないものの、再送信攻撃の防止のために適用するとよい。

　送信機は、データと、フレッシュネス値の少なくとも一部と、ハッシュ値の少なくとも一部を結合して、フレームとして送信する。

　受信機は、セキュリティ通信のフレームを受信し、データと、フレッシュネス値と、ハッシュ値を取得する。

　送信機がフレッシュネス値の一部のみを送信している場合、受信機が記録している送信機のフレッシュネス値に基づいて、フレッシュネス値の全部を計算する。例えば、フレッシュネス値の下位バイト部分しか送信されていない場合は、上位バイトの部分は、受信機が記録している送信機のフレッシュネス値から推論し、計算する。

　このとき、受信経験があるフレッシュネス値である場合や、受信を許可する範囲外である場合は、認証失敗とする。後述するハッシュ計算結果の判定の後にフレッシュネス値を判定してもよい。一般的に、フレッシュネス値の判定よりハッシュ計算の方が計算負荷が大きいので、フレッシュネス値の判定を先に実施したほうが効率が良い。ハッシュ計算や復号などセキュリティ計算を実施しないとフレッシュネス値が分からない場合、セキュリティ計算を先に実施するとよい。

　ハッシュ値の一部を送信している場合、受信機で計算したハッシュ値を、送信機と同様の方法で一部を取り出して比較する。

　受信したハッシュ値と計算したハッシュ値が一致した場合は、受信機はフレームを受理する。即ち認証成功とする。失敗した場合は受理しない。即ち認証失敗とする。失敗した場合は、失敗時の処理を実施してよい。例えば、失敗した旨を通知するようにしてもよい。

　各通信機は、鍵変更の指令を受け取ると、セキュリティ通信に用いる鍵を切り替える処理を開始する。鍵変更の指令は、ネットワーク上の特定の機器が通信機に送信してもよいし、いずれかの通信機がネットワーク上の通信機に送信してもよい。使用する鍵を予め用意しておいて、鍵変更の指令で使用する鍵を切り替えてもよいし、鍵変更の指令やその一連の処理において使用する鍵を選択してもよいし、通信機間での鍵の共有を使用してもよい。また、鍵変更の指令は、一時的に接続される外部ツールによって送信されるものでもよい。

　本実施例の第１の方法を適用する場合について説明する。

　送信機は、鍵変更の指令を受信し、切り替え後の新鍵が準備できたとき、受信機から鍵準備完了通知１を待機する状態を開始する。この間も、通常の処理は継続され、変更前の旧鍵を用いてセキュリティ通信が継続する。通知の送受信に新鍵を用いた認証を付与しない構成とする場合は、鍵変更タイミング通知２で通知される鍵変更のタイミングまでに新鍵が準備できればよい。

　受信機は、鍵変更の指令を受信し、切り替え後の新鍵が準備できたとき、鍵準備完了通知１を送信する。受信機は、新鍵を使用可能になるタイミングで鍵準備完了通知１を送信してもよいし、送信機が新鍵を使用可能になるタイミングのずれを考慮して、受信機が新鍵を使用可能になるタイミングの後の所定の時間後に送信してもよい。また、鍵準備完了通知１を送信するタイミングで、送信機が新鍵を使用可能な状態になっていない場合を考慮して、鍵準備完了通知１を定期的に送信してもよい。送信機から鍵変更タイミング通知２を受信するまでに、鍵準備完了通知１を送信すれば十分である。

　送信機は、受信機から鍵準備完了通知１を受信した後、鍵変更タイミング通知２を送信する。

　本実施例では、フレッシュネス値の値を用いて使用する鍵の切り替えタイミングを特定する。鍵変更タイミング通知２に、鍵変更タイミング３とするフレッシュネス値の情報を含める。通知する鍵変更タイミング３は、通知送信直後のタイミングとしてもよいが、送信処理や受信処理の順番入れ替わりによって、受信機が鍵変更タイミング通知２を受信処理する前に新鍵を用いたセキュリティ通信フレームを受信処理してしまう恐れがあるため、通知の送信タイミングより未来のタイミングとすることが望ましい。

　受信機は、鍵変更タイミング通知２に含まれる切り替えタイミングのフレッシュネス値を取得した場合、以降の受信処理時にフレッシュネス値が当該切り替えタイミング値未満の場合は旧鍵を用いて認証処理を行い、当該切り替えタイミング値以降の場合は新鍵を用いて認証処理を行う（Ｓ３０３～Ｓ３０５）。

　ここで、各通知には新鍵を用いてハッシュ値を計算した結果を付与してもよい。例えば、フレッシュネス値や特定のデータ列や送信する通知のペイロードを用いて計算したハッシュ値を通知に付与するとよい。送信機と受信機が、互いに知りえる情報と鍵を用いてハッシュ値を計算してもよい。このようにすることで、同じ新鍵に変更される場合のみ処理を継続することができ、例えば、送信機と受信機で切り替え先の新鍵の値が、エラーなどが原因で異なる場合、異なる新鍵を使用した通信の開始を抑制できる。各通知において認証に失敗した場合は、エラー処理を実行してもよい。例えば、鍵不一致を知らせる通知を送信したり、エラーを記録してもよい。

　鍵準備完了通知１を旧鍵又は認証不要な状態で送信してもよい。鍵準備完了通知１を旧鍵や認証不要状態で送信する構成では、新鍵を準備できていない送信機で鍵変更処理が開始していることをネットワーク上で検知できる。

　図５は、本実施例の動作例のタイミングチャートであり、鍵０、鍵１、鍵２へ順に切り替えた場合の動作例を示す。

　鍵０から鍵１への変更時は、鍵０が旧鍵、鍵１が新鍵となり、送信機の鍵準備が完了した後、受信機の鍵準備が完了する場合の動作例を示す。鍵１から鍵２への変更時は、鍵１が旧鍵、鍵２が新鍵となる。また、受信機の鍵準備が完了した後、送信機の鍵準備が完了する場合の動作例を示す。

　鍵０を使用中において、鍵を０から１に変更する鍵変更指令がされたとき（ｔ１５）、先に送信機で鍵の準備ができた（ｔ１６）。送信機は、受信機の鍵準備完了（ｔ２１）後に送信される鍵準備完了通知１を待つ（ｔ２２）。送信機は、鍵準備完了通知１を受信（ｔ２２）後に鍵変更タイミング通知２を送信する（ｔ２４）。鍵変更タイミング通知２は鍵変更タイミング３の情報を含む。送信機及び受信機は、鍵変更タイミング３に到達したとき（ｔ２９）、送信時に使用する鍵を０から１に変更する。受信機は、鍵変更タイミング３（ｔ２９）以降に受信したセキュリティ通信フレームは鍵１で認証し、鍵変更タイミング３以前（ｔ２８まで）に受信したセキュリティ通信フレームは鍵０で認証する。フレッシュネス値をタイミング特定に使用する場合、時間ｔはフレッシュネス値であり、受信機側で処理の順番が入れ替わっても、フレッシュネス値で使用する鍵が管理される。

　次に、鍵１から鍵２に変更する鍵変更指令がされたとき（ｔ３３）、受信機が先に鍵の準備ができた（ｔ３４）。受信機は鍵準備完了通知１を送信する（ｔ３５）。送信機は鍵の準備ができていない間（ｔ３４からｔ３８まで）、鍵準備完了通知１を無視する（ｔ３５、ｔ３７）。送信機は鍵準備ができた（ｔ３８）後に、鍵準備完了通知１を受信したとき（ｔ３９）、鍵変更タイミング通知２を送信する（ｔ４０）。鍵変更タイミング通知２は鍵変更タイミング３の情報を含む。受信機は、鍵変更タイミング通知２を受信後、鍵準備完了通知１の送信を停止してもよい。送信機及び受信機は、鍵０から鍵１に変更した場合と同様に、鍵変更タイミング３で使用する鍵を切り替える。

　図６は、フレッシュネス値を用いないで所定期間の決定する第２の方法を採用した場合の動作例のタイミングチャートである。

　図５との処理の主な違いは、送信機は、新鍵１の準備が完了してから（ｔ１６）、所定の時間１ａ（ｔ１６からｔ２４）の間は鍵０を用いてセキュリティ通信フレームを送信する。受信機は、鍵準備完了後（ｔ１９）から鍵０での認証に失敗し鍵１での認証に成功する（ｔ２４）まで、鍵０で認証処理を行う。また、受信機は、鍵１での認証成功後（ｔ２４）後も、所定の時間だけ鍵０での認証も実施する（図４参照）。

　受信機の鍵準備が先に完了する鍵１から鍵２への切り替え時も同様に、受信機は鍵準備完了後（ｔ３４）、鍵１で認証失敗し、鍵２で認証成功するまで（ｔ４６）、鍵１での認証処理を継続し、鍵２での認証成功後（ｔ４６）所定の時間（ｔ４７）まで鍵１での認証も実施する。

　通信機が相互に通信をする場合、前述した送信機と受信機の機能及び処理を各通信機に持たせるとよい。例えば、通信機１と通信機２が通信するとき、通信機１は通信機２に対する受信機の機能と送信機の機能を有し、通信機２は通信機１に対する受信機の機能と送信機の機能を有する。通信機１から通信機２へのセキュリティ通信と通信機２から通信機１へのセキュリティ通信の処理は独立して実施される。例えば、通信機１から通信機２へのセキュリティ通信に関する共通鍵の変更時に通信機２から通信機１へのセキュリティ通信に関する共通鍵を変更しなくてもよい。すなわち、通信経路各々でセキュリティ通信の処理は独立していると考えてもよい。このような場合、本発明の処理を各通信経路に適用すればよい。本発明の処理は通信経路ごとに独立して実施されるとよい。フレッシュネス値、鍵、鍵変更タイミング３などの通信制御情報は通信経路ごとに管理される。複数の通信経路で同時に鍵が変更される場合などは、各通信経路で新鍵と旧鍵を共用してもよい。また、送信経路と受信経路において、同じ共通鍵を用いてもよい。

　さらに、複数の受信機を設けてもよい。この場合、図１のステップＳ１０２において、全ての受信機からの鍵準備完了通知１を受信したときＹＥＳと判定される。

　さらに、複数の送信機を設けてもよい。この場合、送信元ごとに独立して受信処理を実行するとよい。フレッシュネス値、鍵、鍵変更タイミング３などの通信制御情報は送信元ごとに管理される。複数の通信経路で同時に鍵が変更される場合、各通信経路で新鍵と旧鍵を共用してもよい。この場合、受信機の所定の期間２は、すべての送信機について、鍵変更タイミング通知２を受信して鍵変更タイミング３を経過した、又は新鍵での認証に成功したタイミング以降であって、任意の期間経過後（例えば、旧鍵での受信をしえないタイミング以降）に、旧鍵をロック又は削除するとよい。また、全ての送信機において、同時に鍵が変更される場合、少なくとも一部の送信機から鍵変更タイミング通知２を受信できなかった場合、エラーとして扱い、エラー時処理を実行してもよい。

　フレッシュネス値を用いる場合、フレッシュネス値の代わりに送信毎に増加するカウント値を用いてもよく、このカウント値は所定の範囲内で繰り返す値にしてもよい。受信機は、鍵変更タイミング通知２を受信した後、鍵変更タイミング３までの期間での、送信の前後関係が分かればよい。例えば、０から１００の値を採用した場合、現在の値からマイナス３０のカウントに相当する値は過去の値としてよい。ここで、現在の値が２０の場合、３０を減じると－１０となり、０～１００の範囲内に修正すると９０となる。このとき、２０から８９は将来の値で、９０から１００と０から１９は過去の値として扱うとよい。３０以上の受信処理の入れ替わりは発生しないとすると、順番が入れ替わって受信しうるカウント値、例えば９１は過去の値であると判定できる。カウント値が２０の場合、鍵変更タイミングを８９など将来の値に設定することで、受信機は鍵変更タイミング通知２を受信してからカウント値８９を最初に通過するタイミングで、使用する鍵を切り替えればよい。

　認証処理時に、フレッシュネス値を原因とした認証失敗が発生する場合（図３のＳ３１０など）、失敗の要因に応じて、鍵変更処理における認証結果の扱いを変更してもよい。

　ネットワーク上の通信機が、鍵を管理する鍵管理通信機に鍵変更を要求して、鍵変更要求を受けた鍵管理通信機が鍵変更処理を開始してもよい。このように構成することで、ネットワーク上のいずれの通信機でも鍵変更要求が可能となり、特定の一つの通信機が鍵変更タイミングや鍵の値を管理することで、鍵変更要求が重なったときに発生しうる、使用鍵に違いが生じることを防止できる。また、各通信機がセキュリティリスクを検知して、鍵変更を要求することができるので、セキュリティリスクを検知するための負荷を分散できる。

　本発明は、なりすまし防止のための通信の他、暗号通信に用いる鍵の変更に関しても利用できる。第１の方法を適用する場合、暗号通信の送信順序が分かるシーケンス番号が付与されることで、使用鍵の変更タイミングを特定できる。シーケンス番号のみを平文で送信してもよく、復号成功を判定可能であれば、シーケンス番号を暗号文に含めてもよい。また、鍵準備完了通知１や鍵変更タイミング通知２は旧鍵を用いて暗号化してもよい。鍵の変更処理中において、少なくともシーケンス番号のみを旧鍵で暗号化してもよい。こうすることで、新鍵と旧鍵の入り混じる状況においても一意にシーケンス番号を特定することができる。復号成否を判定可能な場合は新鍵を用いてもよい。鍵準備完了通知１は旧鍵で暗号化して、鍵変更タイミング通知２は新鍵で暗号化してもよい。暗号化の代わりに、暗号復号用の鍵を用いたハッシュ値を付与してもよい。

　以上に説明したセキュリティ通信の鍵を変更とする技術は、タイミングを問わずに鍵を変更するアプリケーションにも適用できる。例えば、車両走行中のセキュリティ通信の利用中にセキュリティ通信に干渉を検知した場合に、直ちに鍵を変更でき、セキュリティリスク耐性を向上できる。すなわち、データの送信タイミングを表す値（例えばフレッシュネス値）が同じ通信のハッシュ値が正しい場合に、鍵を変更するとよい。

　例えば、フレッシュネス値が同じで、異なる内容の通信のハッシュ値が正しい値のデータを受信した場合、意図した通信相手と意図しない通信相手からのセキュリティ通信の信号を受信した可能性があり、セキュリティ通信用の鍵が流出した可能性がある。このとき、予め用意していた別の新鍵に変更すれば、新鍵を知らない意図しない通信相手は通信を継続できず、以降の通信のセキュリティを確保できる。

　鍵の流出と判定できる一つの例は、受信したフレッシュネス値とハッシュ値の少なくとも一部を受信履歴として記録し、受信したメッセージについて、ハッシュ値が正しく、同じフレッシュネス値が受信履歴に存在して、かつハッシュ値が異なる場合、鍵が流出したと判断することができる。ここで、ハッシュ値が同じ場合は再送攻撃がされたと判定してもよい。異なるメッセージに対して、同じハッシュ値が算出される可能性は低い為、ハッシュ値が異なる場合は流出した鍵による通信が実施されたと判定できる。また、ハッシュ値の少なくとも一部を記録することで、全ての受信メッセージを記録して比較する場合に比べて、メモリの節約が可能となる。ハッシュ値の一部を記録する場合は、受信したハッシュ値を同様の方法で一部を取り出すとよい。

　以後、別な図を使用して本発明の実施例の鍵変更のタイミングを説明する。

　図８は、本実施例の鍵変更のタイミングを示す図である。

　図８に示すように、鍵が変更され、鍵変更タイミング通知が送信されると、鍵変更後の所定期間１だけ送信機は旧鍵での送信を継続する。受信機は所定期間２だけ旧鍵で受信メッセージを認証する。なお、新鍵は変更の都度受け取っても、予め受け取っておいてもよい。このようにすると、ネットワーク上の送信機と受信機との間で鍵が不一致の期間も、旧鍵と新鍵との混在を許容し、セキュリティ通信を継続できる。

　図９は、本実施例の鍵変更のタイミングを示す図である。

　図９に示すように、鍵が変更され、鍵変更タイミング通知が送信されると、受信機が新鍵を利用可能になるまでの所定期間１だけ送信機は旧鍵での送信を継続する。送信機は鍵変更タイミングをその変更前に受信機に通知する。受信機は、新鍵が利用可能になった後も、鍵変更タイミングのずれを考慮して、所定期間２だけ旧鍵での認証を許容する。すなわち、一方の鍵での認証に失敗した場合、他方の鍵で認証を試みる。

　以上に説明したように、本発明の実施例の通信システムでは、送信機は、変更後の新鍵が使用可能になると、鍵変更タイミングに関する通知を送信し、新鍵が使用可能になった後の第１の所定の期間において変更前の旧鍵でデータを送信し、受信機は、新鍵が使用可能になった後の第２の所定の期間において旧鍵で受信時の認証処理を行い、前記送信機から前記鍵変更タイミングに関する通知を受信した場合、前記鍵変更タイミングより前に送信されたデータは旧鍵で認証処理を行い、前記鍵変更タイミングより後に送信されたデータは新鍵で認証処理を行うので、鍵変更に伴うセキュリティ通信の失敗の軽減できる。また、鍵変更中においても、通常時のようにセキュリティ通信を継続できるので、任意のタイミングで鍵を変更できる。暗号の復号成否で鍵が正しいかを判定することで、様々なセキュリティ通信に適用できる。

　また、受信機は、第２の所定の期間において旧鍵を用いた認証に失敗した場合、前記新鍵で認証処理を行うことで、通知を受信しなくても正しい鍵に切り替えできる。

　また、受信機は、新鍵で認証が可能となった場合に鍵準備完了通知を送信機に送信し、第１の所定の期間は、鍵準備完了通知を受信するまでの期間とすることで、通知を用いて正しい鍵に確実に切り替えできる。

　また、受信機は、新鍵で認証が可能となった場合に鍵準備完了通知を送信し、第１の所定の期間は、鍵準備完了通知を受信し、さらに所定の期間経過する又は所定の条件を満たすまでの期間とすることで、受信機の鍵変更の準備期間を考慮して正しい鍵に確実に切り替えできる。

　また、送信機は、第１の所定の期間が終了するタイミングを、鍵変更タイミング通知によって、受信機に通知することで、送信機と受信機の間で鍵変更タイミングを確実に整合できる。

　また、第２の所定の期間は、鍵変更タイミング通知に含まれる鍵変更タイミングまでの期間とすることで、送信機と受信機の間で鍵変更タイミングを確実に整合できる。

　また、第１の所定の期間及び第２の所定の期間は、セキュリティ通信に用いるフレッシュネス値によって特定されるので、データの到着順序が入れ替わってもセキュリティ通信を継続できる。また、既存のフレッシュネス値を使用するので、鍵を管理するために別にカウンタを設ける必要がない。

　なお、本発明は前述した実施例に限定されるものではなく、添付した特許請求の範囲の趣旨内における様々な変形例及び同等の構成が含まれる。例えば、前述した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに本発明は限定されない。また、ある実施例の構成の一部を他の実施例の構成に置き換えてもよい。また、ある実施例の構成に他の実施例の構成を加えてもよい。また、各実施例の構成の一部について、他の構成の追加・削除・置換をしてもよい。

　また、前述した各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等により、ハードウェアで実現してもよく、プロセッサがそれぞれの機能を実現するプログラムを解釈し実行することにより、ソフトウェアで実現してもよい。

　各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスク、ＳＳＤ（Solid State Drive）等の記憶装置、又は、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に格納することができる。

　また、制御線や情報線は説明上必要と考えられるものを示しており、実装上必要な全ての制御線や情報線を示しているとは限らない。実際には、ほとんど全ての構成が相互に接続されていると考えてよい。

Claims (13)

1. 　送信機と受信機の間で鍵を用いてセキュリティ通信を行う通信システムであって、
   　前記鍵を前記セキュリティ通信中に変更可能であって、
   　前記送信機は、
   　変更後の新鍵が使用可能になると、鍵変更タイミングに関する通知を送信し、
   　前記新鍵が使用可能になった後の第１の所定の期間において変更前の旧鍵でデータを送信し、
   　前記受信機は、
   　前記新鍵が使用可能になった後の第２の所定の期間において前記旧鍵で受信時の認証処理を行い、
   　前記送信機から前記鍵変更タイミングに関する通知を受信した場合、鍵変更タイミングより前に送信されたデータは前記旧鍵で認証処理を行い、前記鍵変更タイミングより後に送信されたデータは前記新鍵で認証処理を行うことを特徴とする通信システム。
2. 　請求項１に記載の通信システムであって、
   　前記受信機は、前記第２の所定の期間において前記旧鍵を用いた認証に失敗した場合、前記新鍵で認証処理を行うことを特徴とする通信システム。
3. 　請求項１に記載の通信システムであって、
   　前記第２の所定の期間は、前記旧鍵で認証に失敗し、前記新鍵で認証に成功するまでの期間であることを特徴とする通信システム。
4. 　請求項１に記載の通信システムであって、
   　前記第２の所定の期間は、前記旧鍵で認証に失敗し、前記新鍵で認証に成功した後、さらに所定の期間が経過する又は所定の条件を満たすまでの期間であることを特徴とする通信システム。
5. 　請求項１に記載の通信システムであって、
   　前記第１の所定の期間は、前記受信機が前記新鍵で認証が可能となるまでの期間であることを特徴とする通信システム。
6. 　請求項１に記載の通信システムであって、
   　前記受信機は、前記新鍵で認証が可能となった場合に鍵準備完了通知を前記送信機に送信し、
   　前記第１の所定の期間は、前記鍵準備完了通知を受信するまでの期間であることを特徴とする通信システム。
7. 　請求項１に記載の通信システムであって、
   　前記受信機は、前記新鍵で認証が可能となった場合に鍵準備完了通知を送信し、
   　前記第１の所定の期間は、前記鍵準備完了通知を受信し、さらに所定の期間経過する又は所定の条件を満たすまでの期間であることを特徴とする通信システム。
8. 　請求項１に記載の通信システムであって、
   　前記送信機は、前記第１の所定の期間が終了するタイミングを、鍵変更タイミング通知によって、前記受信機に通知することを特徴とする通信システム。
9. 　請求項８に記載の通信システムであって、
   　前記第２の所定の期間は、前記鍵変更タイミングに関する通知に含まれる鍵変更タイミングまでの期間であることを特徴とする通信システム。
10. 　請求項１に記載の通信システムであって、
    　前記第１の所定の期間は、前記セキュリティ通信に用いるフレッシュネス値によって特定されることを特徴とする通信システム。
11. 　請求項１に記載の通信システムであって、
    　前記第２の所定の期間は、前記セキュリティ通信に用いるフレッシュネス値によって特定されることを特徴とする通信システム。
12. 　鍵を用いて受信機とセキュリティ通信を行う送信機であって、
    　前記鍵が前記セキュリティ通信中に変更される場合、変更後の新鍵が使用可能になると、鍵変更タイミングに関する通知を送信し、前記新鍵が使用可能になった後の第１の所定の期間において変更前の旧鍵でデータを送信することを特徴とする送信機。
13. 　鍵を用いて送信機とセキュリティ通信を行う受信機であって、
    　前記鍵が前記セキュリティ通信中に変更される場合、変更後の新鍵が使用可能になった後の第２の所定の期間において変更前の旧鍵で受信時の認証処理を行い、
    　前記送信機から鍵変更タイミングに関する通知を受信した場合、鍵変更タイミングより前に送信されたデータは前記旧鍵で認証処理を行い、前記鍵変更タイミングより後に送信されたデータは前記新鍵で認証処理を行うことを特徴とする受信機。

Images