(57)【特許請求の範囲】
【請求項１】
第１システムと、第１サーバと、第２サーバと、を含む鍵管理システムであって、
前記第１システムは、前記第２サーバが前記第１システムを認証するための第１認証鍵を保持し、
前記第１サーバは、前記第２サーバが前記第１システムを認証不可能な更新鍵、を用いた前記第１認証鍵の上書き指示を、前記第１システムに対して、送信し、
前記第１システムは、
前記上書き指示に従わなかった場合、前記第１認証鍵を用いて前記第２サーバとの認証を試み、
前記上書き指示に従って、前記更新鍵を用いて前記第１認証鍵を上書きした場合、前記更新鍵を用いて前記第２サーバとの認証を試み、
前記第１サーバ及び前記第２サーバの少なくとも一方は、
前記第１システムが前記上書き指示に従ったか否かを監視し、
前記第１システムと前記第２サーバとの間の認証処理を監視し、
前記第１システムと前記第２サーバとの間の認証が失敗し、かつ前記第１システムが前記上書き指示に従ったと判定した場合、前記第１システムから前記第１認証鍵が削除されたことを示す判定結果を出力する、鍵管理システム。
【請求項２】
請求項１に記載の鍵管理システムであって、
前記第２サーバは、前記第１システムが前記第２サーバを認証するための第２認証鍵を保持し、
前記少なくとも一方は、前記第１サーバを含み、
前記第１サーバは、前記第１システムから前記第１認証鍵が削除されたと判定した場合、前記第２サーバに対して、前記第２認証鍵の削除指示を送信し、
前記第２サーバは、前記削除指示に従って、前記第２サーバから前記第２認証鍵を削除する、鍵管理システム。
【請求項３】
請求項１に記載の鍵管理システムであって、
前記少なくとも一方は、前記第１サーバを含み、
前記第１システムは、前記上書き指示に従った場合、前記第１サーバに対して、更新完了通知を送信し、
前記第１サーバは、前記更新完了通知を受信した場合、前記第１システムが前記上書き指示に従ったと判定する、鍵管理システム。
【請求項４】
請求項１に記載の鍵管理システムであって、
前記少なくとも一方は、前記第１サーバを含み、
前記第２サーバは、前記第１システムとの認証が失敗した場合、前記第１サーバに対して、認証失敗通知を送信し、
前記第１サーバは、前記認証失敗通知を受信した場合、前記第１システムと前記第２サーバとの間の認証が失敗したと判定する、鍵管理システム。
【請求項５】
請求項４に記載の鍵管理システムであって、
前記第１システムは、複数の端末を有し、
前記第２サーバは、前記第１システムとの間で複数のアプリケーションを実行し、
前記第１サーバは、前記複数のアプリケーションと、前記複数のアプリケーションを実行する端末と、の対応を示す管理情報を保持し、
前記第１認証鍵は、前記複数の端末に含まれる第１端末が、前記第２サーバとの間で、前記複数のアプリケーションに含まれる第１アプリケーションを実行する際に、前記第２サーバが前記第１端末を認証するための鍵であり、
前記第２サーバは、前記第１端末との、前記第１アプリケーションを実行するための認証が失敗した場合、前記第１端末と前記第１アプリケーションとの対応を示す情報を前記認証失敗通知に含め、
前記認証失敗通知に含まれる対応が前記管理情報に含まれる場合、前記第１サーバは、前記第１システムと前記第２サーバとの間の認証が失敗したと判定する、鍵管理システム。
【請求項６】
請求項４に記載の鍵管理システムであって、
前記第１システムは、前記上書き指示に従った場合、前記第１サーバに対して、更新完了通知を送信し、
前記第１サーバは、前記更新完了通知を受信した第１時刻を取得し、
前記第２サーバは、前記認証失敗通知に前記第１システムとの認証が失敗した第２時刻を前記認証失敗通知に含めて、前記第１サーバに対して送信し、
前記第１サーバは、前記第１システムと前記第２サーバとの間の認証が失敗し、前記第１システムが前記上書き指示に従い、かつ前記第２時刻が前記第１時刻より後であると判定した場合、前記判定結果を出力する、鍵管理システム。
【請求項７】
請求項４に記載の鍵管理システムであって、
前記少なくとも一方が、前記第１システムと前記第２サーバとの間の認証が失敗し、かつ前記第１システムが前記上書き指示に従ったと判定した場合、
前記第２サーバは、前記認証失敗通知の送信を停止する、鍵管理システム。
【請求項８】
請求項１に記載の鍵管理システムであって、
前記少なくとも一方は、前記第１システムと前記第２サーバとの間の認証が失敗し、かつ前記第１システムが前記上書き指示に従ったと判定した場合、前記第１システムに対して、前記第２サーバとの認証を試みないよう指示する、鍵管理システム。
【請求項９】
請求項１に記載の鍵管理システムであって、
前記少なくとも一方は、前記第２サーバを含み、
前記第１システムは、前記更新鍵を用いて前記第１認証鍵を上書きした場合、前記第１サーバに対して、更新完了通知を送信し、
前記第１サーバは、前記更新完了通知を受信した場合、前記第２サーバに対して、前記更新完了通知を送信し、
前記第２サーバは、前記更新完了通知を受信した場合、前記第１システムが前記上書き指示に従ったと判定する、鍵管理システム。
【請求項１０】
請求項９に記載の鍵管理システムであって、
前記第２サーバは、前記第１システムが前記第２サーバを認証するための第２認証鍵を保持し、
前記第２サーバは、前記第１システムから前記第１認証鍵が削除されたと判定した場合、前記第２サーバから前記第２認証鍵を削除する、鍵管理システム。
【請求項１１】
第１システムに接続された、サーバであって、
プログラムを実行するプロセッサと、前記プロセッサがアクセスする記憶装置と、を含み、
前記第１システムは、前記第１システムに接続された第１サーバ又は前記サーバの一方が前記第１システムを認証するための第１認証鍵を保持し、
前記プロセッサは、
前記第１サーバが前記第１システムを認証不可能な更新鍵、を用いた前記第１認証鍵の上書き指示に、前記第１システムが従ったか否かを監視し、
前記第１システムと前記一方との間の認証処理を監視し、
前記第１システムと前記一方との間の認証が失敗し、かつ前記第１システムが前記上書き指示に従ったと判定した場合、前記第１システムから前記第１認証鍵が削除されたことを示す判定結果を出力する、サーバ。
【請求項１２】
第１システムに接続された、サーバが鍵管理を実行する方法であって、
前記第１システムは、前記第１システムに接続された第１サーバ又は前記サーバの一方が前記第１システムを認証するための第１認証鍵を保持し、
前記方法は、前記サーバが、
前記一方が前記第１システムを認証不可能な更新鍵、を用いた前記第１認証鍵の上書き指示に前記第１システムが従ったか否かを監視し、
前記第１システムと前記一方との間の認証処理を監視し、
前記第１システムと前記一方との間の認証が失敗し、かつ前記第１システムが前記上書き指示に従ったと判定した場合、前記第１システムから前記第１認証鍵が削除されたことを示す判定結果を出力する、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、鍵管理システム、サーバ、及び鍵管理方法に関する。
【背景技術】
【０００２】
近年、Ｍ２Ｍ（Ｍａｃｈｉｎｅ  Ｔｏ  Ｍａｃｈｉｎｅ）やＩｏＴ（Ｉｎｔｅｒｎｅｔｏｆ  ｔｈｅ  Ｔｈｉｎｇｓ）の広まりを受け、車載システムやセンサノードなどの多様な端末が様々なネットワークを介して各種サービスサーバに接続するようになりつつある。これらの端末がサービスサーバと安全に通信するために、鍵管理サーバは、通信用の秘密鍵等を発行し、端末内部の機器ユニットに配備する必要がある。
【０００３】
本技術分野の背景技術として特開２００５−３４１５２８号公報（特許文献１）がある。この公報には、「システムが起動すると、ゲートウェイＥＣＵ（ＧＷ）が暗号鍵を生成し、これを種鍵を用いて暗号化した暗号化データを、放送形式で全ＥＣＵ（ＥＣＵ１  〜ＥＣＵＮ  ）に一括配信する。各ＥＣＵは、受信した暗号化データを種鍵を用いて復号し、復号結果を暗号鍵として以後の通信データの暗号化，復号に用いる。また暗号鍵を設定したＥＣＵは、その旨を表す応答（鍵確認）を生成し、これを暗号鍵を用いて暗号化した暗号化データをゲートウェイＥＣＵに返送する。ゲートウェイＥＣＵは、その応答に基づいて各ＥＣＵの正当性を判定する。」と記載されている（要約参照）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００５−３４１５２８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
端末内部の機器ユニットに配備された秘密鍵は、例えば端末の所有者が変更された際や端末が破棄された際に適切に削除される必要があるが、鍵管理サーバが鍵の削除を機器ユニットに指示したとしても、機器ユニットの不正な動作や故障により鍵が削除されない可能性があり。従って、鍵の削除が適切に行われたか否かを鍵管理サーバが確認することが難しい。
【０００６】
特許文献１に記載の技術は、車載機器ユニットであるＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ  Ｃｏｎｔｒｏｌ  Ｕｎｉｔ）の鍵を、ゲートウェイとなるＥＣＵから更新するが、ＥＣＵ内の鍵が削除されたことを確認する方法は特許文献１には開示されていない。そこで本発明の一態様は、鍵が配備された端末から当該鍵が削除されたか否かを高精度に判定し、ひいてはセキュリティを強化することを目的する。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本発明の一態様は以下の構成を採用する。第１システムと、第１サーバと、第２サーバと、を含む鍵管理システムであって、前記第１システムは、前記第２サーバが前記第１システムを認証するための第１認証鍵を保持し、前記第１サーバは、前記第２サーバが前記第１システムを認証不可能な更新鍵、を用いた前記第１認証鍵の上書き指示を、前記第２サーバに対して、送信し、前記第１システムは、前記上書き指示に従わなかった場合、前記第１認証鍵を用いて前記第２サーバとの認証を試み、前記上書き指示に従って、前記更新鍵を用いて前記第１認証鍵を上書きした場合、前記更新鍵を用いて前記第２サーバとの認証を試み、前記第１サーバ及び前記第２サーバの少なくとも一方は、前記第１システムが前記上書き指示に従ったか否かを監視し、前記第１システムと前記第２サーバとの間の認証処理を監視し、前記第１システムと前記第２サーバとの間の認証が失敗し、かつ前記第１システムが前記上書き指示に従ったと判定した場合、前記第１システムから前記第１認証鍵が削除されたことを示す判定結果を出力する、鍵管理システム。
【発明の効果】
【０００８】
本発明の一態様は、鍵が配備された端末から当該鍵が削除されたか否かを高精度に判定し、ひいてはセキュリティを強化することができる。
【図面の簡単な説明】
【０００９】
【図１】実施例１における情報システムの構成例を示すブロック図である。
【図２】実施例１における鍵管理サーバの構成例を示すブロック図である。
【図３】実施例１における車載システムの構成例を示すブロック図である。
【図４】実施例１におけるサービスサーバの構成例を示すブロック図である。
【図５Ａ】実施例１における削除ステートの一例である。
【図５Ｂ】実施例１におけるインシデント通知のフォーマットの一例である。
【図６】実施例１における、削除用鍵を用いた鍵更新処理及び削除完了の確認処理を示すシーケンス図である。
【図７】実施例１におけるインシデント通知判定処理の一例を示すフローチャートである。
【図８】実施例１における、ＥＣＵが鍵を更新しなかった、又は更新していないにも関わらず更新完了通知を送信した場合の処理の一例を示すシーケンス図である。
【図９】実施例２における鍵管理サーバの構成例を示すブロック図である。
【図１０】実施例２におけるサービスサーバの構成例を示すブロック図である。
【図１１Ａ】実施例２における鍵管理サーバが保持する削除ステートの一例である。
【図１１Ｂ】実施例２におけるサービスサーバが保持する削除ステートの一例を示す図である。
【図１２】実施例２における、削除用鍵を用いた鍵更新処理及び削除完了の確認処理を示すシーケンス図である。
【図１３】実施例２における、ＥＣＵが鍵を更新しなかった、又は更新していないにも関わらず更新完了通知を送信した場合の処理の一例を示すシーケンス図である。
【発明を実施するための形態】
【００１０】
以下、添付図面を参照して本発明の実施形態を説明する。本実施形態は本発明を実現するための一例に過ぎず、本発明の技術的範囲を限定するものではないことに注意すべきである。各図において共通の構成については同一の参照符号が付されている。
【００１１】
本実施形態は、車載機器ユニットであるＥＣＵの不正な動作や故障により鍵が適切に削除されない場合があっても、鍵が削除されたか否かを鍵管理サーバで判断することでセキュリティを高める、情報システムの一例を説明する。
【実施例１】
【００１２】
図１は、鍵管理システムの一例である情報システムの構成例を示すブロック図である。情報システムは、例えば、相互に通信可能な、鍵管理サーバ１と、車載システム２と、サービスサーバ３と、を含む。また、情報システムは、例えば、鍵管理サーバ１と相互に通信可能なサービス管理者端末４をさらに含む。
【００１３】
なお、情報システムに含まれる各構成は図１で示していない経路によって接続されていてもよい。例えば、サービス管理者端末４は、サービスサーバ３及び車載システム２と接続されていてもよい。また、情報システム内のある構成が他の構成を含んでもよい。例えば、サービス管理者端末４がサービスサーバ３を含んでもよい。
【００１４】
鍵管理サーバ１は、ネットワーク等を介して車載システム２、サービスサーバ３、サービス管理者端末４等と通信を行うサーバである。鍵管理サーバ１は、ＰＫＩ（Ｐｕｂｌｉｃ  Ｋｅｙ  Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）の公開鍵証明書や秘密鍵、又は共通鍵暗号の共通鍵を安全に格納するサーバである。
【００１５】
鍵管理サーバ１において、他のアプリケーションが動作してもよい。また、鍵管理サーバ１の機能が複数のサーバやストレージなどの筐体に分かれ、それらが組み合わさった構成になっていてもよい。また、サーバに限らず同様の処理が可能な情報機器などであってもよい。これらのことは、サービスサーバ３についても同様である。
【００１６】
車載システム２は、ネットワーク等を通じて鍵管理サーバ１及び車載システム２と通信する機能を備えた自動車である。車載システム２は、車載機器である複数のＥＣＵを備え、各ＥＣＵは車内のネットワークで接続されている。
【００１７】
本実施例では情報システムが、車載システム２を含む例を説明するが、車載システム２の代わりに他のＭ２Ｍ／ＩｏＴシステムを含んでもよい。情報システムは、車載システムの代わりに、例えば、農業モニタリングシステム、ＨＥＭＳ（Ｈｏｍｅ  Ｅｎｅｒｇｙ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ）、ＢＥＭＳ（Ｂｕｉｌｄｉｎｇ  Ｅｎｅｒｇｙ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ）、工場管理システム、スマートグリッドシステム、医療システム、又は位置情報提供システム等のシステムを含んでもよい。
【００１８】
情報システムが、車載システム２の代わりに上述のシステムのいずれかを含む場合、以下の説明において、後述するメインＥＣＵを当該システムのゲートウェイ機器に置き換え、ＥＣＵを当該システムの末端ノードの端末に置き換えればよい。この場合、ゲートウェイ機器と末端ノードの端末は有線又は無線で接続されている。
【００１９】
サービスサーバ３は、ネットワーク等を通じて車載システム２及び鍵管理サーバ１と通信を行うサーバである。サービスサーバ３は、サービス管理者端末４と通信してもよい。また、サービスサーバ３とサービス管理者端末４とは同一の要素であってもよい。
【００２０】
サービスサーバ３は、車載システム２のＥＣＵと通信を行うことで、車載システム２又は外部システム等に向けたサービスを提供する。サービスサーバ３は、車載システム２のＥＣＵと安全に通信するための鍵を保持するサーバである。また、サービスサーバ３は、処理等に異常が発生したことをインシデントとして検知し、検知したインシデントを鍵管理サーバ１に通知する。
【００２１】
サービス管理者端末４は、ＥＣＵが保有する鍵の削除を鍵管理サーバ１に指示する。サービス管理者端末４は、例えば、プロセッサ、メモリ、補助記憶装置、通信インターフェース、及び入出力インターフェースを含む計算機によって構成される。
【００２２】
サービス管理者端末４は、鍵の発行、更新、及び失効を鍵管理サービスに指示する機能をさらに備えてもよい。サービス管理者端末４は、ディスプレイ装置等を含む端末であってもよいし、ネットワーク等を通じて鍵管理サーバ１と通信するサーバであってもよい。  鍵管理サーバ１とサービスサーバ３との間の通信、および鍵管理サーバ１とサーバであるサービス管理者端末４との間の通信は、例えば、ＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）、３Ｇ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ）、ＷｉＭＡＸ（Ｗｏｒｌｄｗｉｄｅ  Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ  ｆｏｒ  Ｍｉｃｒｏｗａｖｅ  Ａｃｃｅｓｓ）、無線ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、若しくはＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）等の無線通信、又は有線ＬＡＮ、インターネット、若しくは専用回線等を用いた有線通信である。
【００２３】
鍵管理サーバ１と車載システム２との間の通信、および、サービスサーバ３と車載システム２との間の通信は、例えば、ＬＴＥ、３Ｇ、ＷｉＭＡＸ、無線ＬＡＮ又はＷＡＮ等の無線通信である。情報システム内の各構成間の通信は、別のネットワークであってもよいし、同一のネットワークであってもよい。
【００２４】
図２は、鍵管理サーバ１の構成例を示すブロック図である。鍵管理サーバ１は、例えば、互いにバス線などで結線された、制御部１０、記憶部１１、及び通信部１２を備える。なお、鍵管理サーバ１は、例えば、暗号処理を高速化する暗号処理部等をさらに含んでもよい。
【００２５】
なお、鍵管理サーバ１内の各部は、必ずしもバス線により結線されている必要はなく、その他の方法で電気的に繋がっていてもよい。また、鍵管理サーバ１内において、相互に接続されている必要がある部同士が接続されていてもよい。また別個の筐体内の部が電気的又は光配線等で接続されていてもよい。これは、情報システムに含まれる他の装置の構成についても同様である。
【００２６】
制御部１０は、例えば、プロセッサ（ＣＰＵ、ＭＰＵ、又はＤＳＰ）等から構成され、記憶部１１等に格納されたプログラムを実行する。記憶部１１は、制御部１０が実行するプログラム及びプログラムの実行時に使用されるデータを格納する。記憶部１１は、例えば、磁気ディスク、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）、ＥＥＰＲＯＭ、又はフラッシュメモリ等の、大容量かつ不揮発性の記憶装置を含む。
【００２７】
また、記憶部１１は、不揮発性の記憶素子であるＲＯＭ及び揮発性の記憶素子であるＲＡＭを含むメモリを含んでもよい。ＲＯＭは、不変のプログラム（例えば、ＢＩＯＳ）などを格納する。ＲＡＭは、ＤＲＡＭ（Ｄｙｎａｍｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）のような高速かつ揮発性の記憶素子であり、制御部１０が実行するプログラム及びプログラムの実行時に使用されるデータを一時的に格納する。
【００２８】
記憶部１１は、鍵などの情報を安全に保持するＨＳＭ（Ｈａｒｄｗａｒｅ  ｓｅｃｕｒｉｔｙ  ｍｏｄｕｌｅ）を備えてもよい。記憶部１１は、複数の記憶装置から構成されていてもよく、各プログラム及び各データが当該複数の記憶装置に分けて格納されていてもよい。
【００２９】
通信部１２は、所定のプロトコルに従って、情報システムに含まれる他の構成との通信を制御するネットワークインターフェース装置を含み、上述した無線通信及び有線通信を行うモジュールである。
【００３０】
鍵管理サーバ１は、例えば、通信方式ごとに応じて複数の通信部１２を含んでもよい。また、通信部１２は、他の通信を実施するモジュールと共用になっていてもよい。なお、通信部１２は、無線通信に用いられるアンテナ及び変復調回路等を含んでもよい。また、通信部１２は、有線通信に用いられるコネクタ及び変復調回路等を含んでもよい。
【００３１】
制御部１０が実行するプログラムは、リムーバブルメディア（ＣＤ−ＲＯＭ、フラッシュメモリなど）又はネットワークを介して鍵管理サーバ１に提供され、例えば、記憶部１１に含まれる非一時的記憶媒体である不揮発性の補助記憶装置に格納される。このため、鍵管理サーバ１は、リムーバブルメディアからデータを読み込むインターフェースを有するとよい。
【００３２】
なお、鍵管理サーバ１は、入力インターフェース及び出力インターフェースをさらに有してもよい。入力インターフェースは、キーボードやマウスなどが接続され、オペレータからの入力を受けるインターフェースである。出力インターフェースは、ディスプレイ装置やプリンタなどが接続され、プログラムの実行結果をオペレータが視認可能な形式で出力するインターフェースである。
【００３３】
鍵管理サーバ１は、物理的に一つの計算機上で、又は、論理的又は物理的に構成された複数の計算機上で構成される計算機システムであり、同一の計算機上で別個のスレッドで動作してもよく、複数の物理的計算機資源上に構築された仮想計算機上で動作してもよい。
【００３４】
記憶部１１は、制御ソフト１１０と、鍵管理テーブル１１１と、を格納する。制御ソフト１１０は、鍵管理サーバ１を制御するためのソフトウェアが記述されている。制御ソフト１１０は、例えば、通信部１２からの通信、所定のタイマー、又は他の割り込み処理を開始トリガとして、処理フローを実行するソフトウェアである。
【００３５】
制御ソフト１１０は、複数のソフトウェアが連携した複合的なものであってもよい。なお、特に断りなく鍵管理サーバ１又は制御ソフト１１０が処理を実行するような記述をした場合、物理的には制御ソフト１１０のプログラムの記述に則って制御部１０が処理を実行することを示す。上述した制御ソフト１１０の説明、及び制御ソフト１１０と制御部１０との関係の説明は、他の装置に含まれる制御ソフト及び制御部についても同様である。
【００３６】
制御ソフト１１０は、例えば、それぞれプログラムである、鍵管理機能１１０１、インシデント通知処理機能１１０２、削除用鍵生成機能１１０３、削除ステート管理機能１１０４、メインＥＣＵ認証機能１１０５、サービスサーバ認証機能１１０６を備える。制御ソフト１１０はこれらの機能の組み合わせで実現される。
【００３７】
鍵管理機能１１０１は、車載システム２に配信した鍵を所定の鍵で更新する指示を行う。また、鍵管理機能１１０１は、鍵の配送、失効、又は削除を指示してもよい。また、鍵管理機能１１０１は、鍵管理テーブル１１１を更新してもよい。インシデント通知処理機能１１０２は、サービスサーバ３から受け取ったインシデント通知の内容に応じた処理を行う。
【００３８】
削除用鍵生成機能１１０３は、削除用の鍵を生成する。削除用の鍵の値は通常に運用する鍵の値とは異なる。削除ステート管理機能１１０４は、鍵管理テーブル１１１を読み書きすることで鍵削除に関する一連のプロセスをステートとして管理する。
【００３９】
メインＥＣＵ認証機能１１０５は、後述する車載システム２のメインＥＣＵと相互認証する機能であり、メインＥＣＵと認証するためのＩＤや認証鍵が記述されている。サービスサーバ認証機能１１０６は、後述するサービスサーバ３と相互認証する機能であり、サービスサーバ３と認証するためのＩＤや認証鍵を含む。なお、メインＥＣＵと認証するためのＩＤと認証鍵、及びサービスサーバと認証するためのＩＤと認証鍵は、テーブル形式で記憶部１１に格納されていてもよい。
【００４０】
鍵管理テーブル１１１は、鍵管理サーバ１が配布した、車載システム２とサービスサーバ３との間の認証鍵の情報を格納する。鍵管理テーブル１１１は、例えば、サービス管理者端末４などから送信された情報に従って、予め生成される。鍵管理テーブル１１１は、例えばデータベースやハッシュテーブル等で構成される。
【００４１】
鍵管理テーブル１１１は、例えば、端末ＩＤ欄１１１１、アプリＩＤ欄１１１２、鍵値欄１１１３、鍵状態欄１１１４、削除ステート欄１１１５、及び状態変更日時欄１１１６を含む。端末ＩＤ欄１１１１は、車載システム２に含まれるＥＣＵを識別する端末ＩＤを格納する。アプリＩＤ欄１１１２は、車載システム２に含まれるＥＣＵのアプリケーションを識別するアプリＩＤを格納する。端末ＩＤ及びアプリＩＤは、例えば、数値列又は文字列である。本実施形態において、端末ＩＤとアプリＩＤの組み合わせによって、鍵が一意に識別されるものとする。なお、鍵管理テーブル１１１は、鍵を一意に識別する鍵ＩＤをさらに保持してもよい。
【００４２】
鍵値欄１１１３欄は、鍵値を格納する。鍵値は例えば、公開鍵暗号の秘密鍵と公開鍵証明書の組や、共通鍵暗号の秘密鍵である。鍵状態欄１１１４は鍵の状態を示す情報を格納する。例えば、「削除中」は対応する鍵が削除中であることを示す。また、鍵状態欄１１１４は、例えば、鍵が有効である状態を示す「有効」、及び鍵が失効された状態を示す「失効」等の値を保持してもよい。
【００４３】
削除ステート欄１１１５は、鍵の削除ステートが格納される。削除ステートの詳細については後述する。なお、鍵状態欄１１１４が「削除中」であるレコードの削除ステート欄１１１５は削除ステートを格納し、鍵状態欄１１１４が「削除中」でないレコードの削除ステート欄１１１５は、例えば、ｎｕｌｌ値を格納する。
【００４４】
状態変更日時欄１１１６は、例えば、削除ステート又は鍵状態が最後に変更された日時を保持する。状態変更日時欄１１１６に格納される日時は、例えば、鍵管理サーバ１の内部から取得されてもよいし、状態変更のきっかけとなる外部からの通信に含まれる時刻情報から取得されてもよい。
【００４５】
なお、本実施形態において、情報システムが使用する情報がテーブル形式で表されている例を説明するが、情報システムが使用する情報はデータ構造に依存せずどのようなデータ構造で表現されていてもよい。例えば、テーブル、リスト、データベース又はキューから適切に選択したデータ構造体が、情報を格納することができる。情報記憶システムが使用する情報は、データ記憶装置における対応するデータ記憶領域に格納される。
【００４６】
図３は、車載システム２の構成例を示すブロック図である。車載システム２は、例えば、ＣＡＮ（Ｃｏｎｔｒｏｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）などで互いに結線されている、サーバ通信ＥＣＵ２０、メインＥＣＵ２１、及び１以上のＥＣＵ２２を備える。サーバ通信ＥＣＵ２０、メインＥＣＵ２１、及びＥＣＵ２２は、例えば、ＣＡＮ  ＦＤ（ＣＡＮ  ｗｉｔｈ  Ｆｌｅｘｉｂｌｅ  Ｄａｔａ  Ｒａｔｅ）、Ｅｔｈｅｒｎｅｔ（登録商標、以下同）、又はＦｌｅｘＲａｙ等（登録商標、以下同）によって結線されていてもよい。
【００４７】
サーバ通信ＥＣＵ２０は、鍵管理サーバ１やサービスサーバ３等の他の構成要素と通信を行う。サーバ通信ＥＣＵ２０は、ＬＴＥ、３Ｇ、ＷｉＭＡＸ、無線ＬＡＮおよびＷＡＮ等の無線通信を行うためのモジュールである。また車載システム２が自動車以外のＩｏＴシステムである場合は、サーバ通信ＥＣＵ２０は有線の通信を行うモジュールであってもよい。
【００４８】
なお、サーバ通信ＥＣＵ２０は、メインＥＣＵ２１又はＥＣＵ２２に含まれていてもよい。また、車載システム２は、用途や通信方式に応じた複数のサーバ通信ＥＣＵ２０を含んでもよい。またその他の通信を実施するモジュールと共用になっていても構わない。なお、サーバ通信ＥＣＵ２０は、無線通信の場合、アンテナ、および変復調回路等を含んでもよい。有線通信の場合は、コネクタ、および変復調回路等を含んでもよい。
【００４９】
メインＥＣＵ２１は、例えば、互いにバス線などで結線された、制御部２１０、記憶部２１１、通信部２１２を備えるメインＥＣＵ２１は、例えば、暗号処理を高速化する暗号処理部等を、さらに含んでもよい。メインＥＣＵ２１は、例えばセントラルゲートウェイユニットであることが考えられる。
【００５０】
通信部２１２は、メインＥＣＵ２１が車載システム２の他の構成要素と通信を行う。通信部２１２は、例えば、ＣＡＮ、ＣＡＮ  ＦＤ、Ｅｔｈｅｒｎｅｔ、又はＦｌｅｘＲａｙなどによる通信を行うためのモジュールである。車載システム２が自動車以外のＩｏＴシステムである場合は、通信部２１２は、例えば、無線又は有線の通信を行うためのモジュールである。メインＥＣＵ２１は、用途や通信方式に応じた複数の通信部２１２を含んでもよい。また、通信部２１２は、他の通信を実施するモジュールと共用になっていてもよい。なお、通信部２１２は、無線通信を行う場合、アンテナ及び変復調回路等を含んでもよい。通信部２１２は、有線通信を行う場合は、コネクタ及び変復調回路等を含んでもよい。
【００５１】
以下、制御部２１０及び記憶部２１１それぞれと、制御部１０及び記憶部１１それぞれと、の相違点を説明し、同様の点についての説明を省略する。記憶部２１１は、例えば、メインＥＣＵ２１を制御するためのソフトウェアが記述されている制御ソフト２１１０を備える。
【００５２】
制御ソフト２１１０は、例えば、それぞれプログラムである、鍵管理機能２１１１、鍵管理サーバ認証機能２１１５を備える。鍵管理機能２１１１は、鍵管理サーバ１からの指示を受け指定された鍵を所定のＥＣＵに配送することで当該ＥＣＵの鍵を更新する。鍵管理機能２１１１は、鍵管理サーバ１からの指示を受けて所定のＥＣＵに対し鍵を配送、失効、及び削除してもよい。
【００５３】
鍵管理サーバ認証機能２１１５は鍵管理サーバ１と相互認証する。鍵管理サーバ認証機能２１１５には、鍵管理サーバ１と認証するためのＩＤや認証鍵が記述されている。ＥＣＵ２２は、例えば、互いにバス線などで結線された、制御部２２０、記憶部２２１、通信部２２２を備える。ＥＣＵ２２は、例えば、暗号処理を高速化する暗号処理部をさらに備えてもよい。通信部２２２の説明は、通信部２１２の説明と同様であるため省略する。
【００５４】
以下、制御部２２０及び記憶部２２１それぞれと、制御部１０及び記憶部１１それぞれと、の相違点を説明し、同様の点の説明は省略する。記憶部２２１は、ＥＣＵ２２を制御するためのソフトウェアが記述されている制御ソフト２２１０、及び端末ＩＤ２２１１を格納する。
【００５５】
制御ソフト２２１０は、１以上のアプリケーション２２１２を備える。これ以外の構成要素を備えてもよい。アプリケーション２２１２は、サービスサーバ３と連携したサービスを実行するソフトウェアであり、サービスサーバ３との通信を行う。アプリケーション２２１２が備える構成要素については後述する。端末ＩＤ２２１１は、ＥＣＵ２２を識別するＩＤであり、例えば、数値列又は文字列である。
【００５６】
アプリケーション２２１２は、例えば、アプリＩＤ２２１３、サービスサーバ通信認証鍵２２１４を保持する。アプリＩＤ２２１３は、アプリケーション２２１２を識別するＩＤであり、例えば、数値列又は文字列である。
【００５７】
サービスサーバ通信認証鍵２２１４は、後述するサービスサーバ３のアプリケーションと通信を行う際に相互認証を行うための鍵であり、鍵管理サーバ１からメインＥＣＵ２１を介して配信又は更新される。サービスサーバ通信認証鍵２２１４は、車載システム２の所有者が変更された場合や車載システム２が破棄される場合等において、適切に削除される必要がある。
【００５８】
図４は、サービスサーバ３の構成例を示すブロック図である。サービスサーバ３は、例えば、バス線などで互いに結線された、制御部３０、記憶部３１、及び通信部３２を備る。サービスサーバ３は、例えば、暗号処理を高速化する暗号処理部をさらに備えていてもよい。
【００５９】
以下、制御部３０、記憶部３１、及び通信部３２それぞれと、制御部１０、記憶部１１及び通信部３２それぞれと、の相違点を説明し、同様の点の説明を省略する。記憶部３１は、サービスサーバ３を制御するためのソフトウェアが記述されている制御ソフト３１０、及び鍵テーブル３１１を備える。
【００６０】
制御ソフト３１０は、例えば、それぞれプログラムである、鍵管理機能３１０１、インシデント通知機能３１０２、アプリケーション３１０３、及び鍵管理サーバ認証機能３１０６を備える。鍵管理機能３１０１は、鍵管理サーバ１からの指示を受けて鍵テーブル３１１の鍵を削除する。また、鍵管理機能３１０１は、鍵管理サーバ１からの指示を受けて鍵を保持、更新、及び失効してもよい。
【００６１】
インシデント通知機能３１０２は、サービスサーバ３の処理等に異常が発生したことをインシデントとして検知し、鍵管理サーバ１に通知する。車載システム２のＥＣＵ２２との相互認証が失敗したことは、インシデントの一例である。
【００６２】
アプリケーション３１０３は、ＥＣＵ２２と連携したサービスを実行するソフトウェアであり、ＥＣＵ２２との通信を行う。鍵管理サーバ認証機能３１０６は鍵管理サーバ１と相互認証する。鍵管理サーバ認証機能３１０６には、例えば、鍵管理サーバ１と認証するためのＩＤや認証鍵が記述されている。
【００６３】
鍵テーブル３１１は、鍵管理サーバ１が配布した認証鍵の情報を格納する。鍵テーブル３１１は、例えば、鍵管理サーバ１から送信された情報に従って、予め生成される。鍵テーブル３１１は、例えばデータベースやハッシュテーブル等で構成される。
【００６４】
鍵テーブル３１１は、例えば、端末ＩＤ欄３１１１と、アプリＩＤ欄３１１２と、鍵値欄３１１３と、を含む。端末ＩＤ欄３１１１は、車載システム２に含まれるＥＣＵを識別する端末ＩＤを格納する。アプリＩＤ欄３１１２は、車載システム２に含まれるＥＣＵのアプリケーションを識別するアプリＩＤ情報を格納する。なお、鍵テーブル３１１は、鍵を一意に識別する鍵ＩＤをさらに保持してもよい。
【００６５】
鍵値欄３１１３は、端末ＩＤ欄１１１１とアプリＩＤ欄１１１２とに対応付き、記憶部３１が保持する、端末通信認証鍵の鍵値を格納する。鍵値は例えば、公開鍵暗号の秘密鍵と公開鍵証明書の組や、共通鍵暗号の秘密鍵である。端末通信認証鍵は、ＥＣＵ２２のサービスサーバ通信認証鍵２２１４と組み合わせて相互認証を行うための鍵である。
【００６６】
図５Ａは、削除ステート欄１１１５に格納される削除ステートの一例である。削除ステート欄１１１５は、例えば、削除ステート１乃至削除ステート７のいずれか又はｎｕｌｌ値を格納する。削除ステートの遷移は後述する処理フローにおいて示す。
【００６７】
削除ステート１は、鍵管理サーバ１がサービス管理者端末４から削除要求を受けたことを示す。削除ステート２は、削除専用鍵による端末通信認証鍵の更新を鍵管理サーバ１が指示中であることを示す。削除ステート３は、通信認証鍵の削除専用鍵による更新完了報告を受信したことを示す。削除ステート４は、鍵管理サーバ１がサービスサーバ３から通信認証失敗の報告を受信したことを示す。
【００６８】
削除ステート５は、鍵管理サーバ１がサービスサーバ３に端末通信認証鍵の削除を指示中であることを示す。削除ステート６は、サービスサーバ３から鍵管理サーバ１に削除完了の報告があったことを示す。削除ステート７は、鍵管理サーバ１がサービス管理者端末４に削除完了を通知済みであることを示す。
【００６９】
図５Ｂは、インシデント通知機能３１０２が通知するインシデント通知のフォーマット一例である。図５Ｂのインシデント通知は、ＥＣＵ２２とサービスサーバ３との相互認証が失敗したことを示す。
【００７０】
インシデント通知は、例えば、端末ＩＤ、アプリＩＤ、発生日時、インシデント内容、詳細ログを含む。インシデント通知における端末ＩＤは、サービスサーバ３が相互認証を行った相手であるＥＣＵ２２の端末ＩＤを示す。
【００７１】
インシデント通知におけるアプリＩＤは、サービスサーバ３が相互認証を試みた相手であるＥＣＵ２２のアプリＩＤを示す。インシデント通知における発生日時は、相互認証の失敗が発生した時刻を示す。インシデント通知におけるインシデント内容は、サービスサーバ３で発生したインシデントの内容を示し、図５Ｂの例は相互認証が失敗したことを示す。インシデント通知における詳細ログは、インシデント内容が示すインシデントに至ったログを示す。図５Ｂの例では、詳細ログは、認証失敗に至ったログの詳細を示し、例えば、相互認証に係る通信内容などを含む。
【００７２】
以下、図６から図８を用いてでは情報システムの処理の一例を示す。図６は、削除用鍵を用いたサービスサーバ通信認証鍵２２１４の更新処理及び削除完了の確認処理を示すシーケンス図である。以下、特に断りがなくとも、鍵管理サーバ１又はサービスサーバ３と、メインＥＣＵ２１又はＥＣＵ２２と、の間の通信を、必要に応じてサーバ通信ＥＣＵ２０が中継してもよい。
【００７３】
まず、サービス管理者端末４は、鍵管理サーバに対して鍵削除指示を送信する（Ｓ１０１）。鍵削除指示は、削除対象であるサービスサーバ通信認証鍵２２１４（以下、削除対象鍵と呼ぶ）を特定する情報を含む。端末ＩＤとアプリＩＤとの組み合わせ、鍵ＩＤ、及び鍵値はいずれも削除対象鍵を特定する情報の一例である。
【００７４】
続いて、削除ステート管理機能１１０４は、削除対象鍵の、鍵状態欄１１１４の値を「削除中」に、削除ステート欄１１１５の値を削除ステート１に、それぞれ更新し、状態変更日時欄１１１６に現在日時を格納する（Ｓ１０２）。なお、削除ステート管理機能３１０４は、削除ステート欄１１１５の値を変更する度に、当該削除ステート欄１１１５に対応する状態変更日時欄１１１６の変更日時を更新するが、以下の説明において、状態変更日時欄１１１６の変更日時の更新処理の説明は省略する。
【００７５】
続いて、削除用鍵生成機能１１０３は、削除用鍵を生成する（Ｓ１０３）。なお、削除用鍵生成機能１１０３は、例えば、擬似乱数生成器を用いて削除用の鍵を生成する。また、削除用鍵生成機能１１０３は、例えば、所定の値を持つ鍵を、削除用の鍵として生成してもよい。
【００７６】
続いて、鍵管理機能１１０１は、Ｓ１０３で生成した削除用鍵での削除対象鍵の更新をメインＥＣＵ２１に指示し、削除ステート管理機能１１０４は削除対象鍵の削除ステート欄１１１５の値を削除ステート２に更新する（Ｓ１０４）。当該更新指示は、削除対象鍵及び削除対象鍵を保持するＥＣＵ２２を特定する情報、並びに削除用鍵を含む。なおステップＳ１０４の処理が実施される前に、メインＥＣＵ認証機能１１０５と鍵管理サーバ認証機能２１１５が相互認証を実施し、暗号セッション等を確立しておくことが望ましい。
【００７７】
続いて、メインＥＣＵ２１の鍵管理機能２１１１は、更新指示を参照して削除対象鍵を保持するＥＣＵ２２を特定し、削除用鍵での鍵更新を特定したＥＣＵ２２に指示する（Ｓ１０５）。つまり、鍵管理機能２１１１は、受信した更新指示を特定したＥＣＵ２２に転送する。
【００７８】
更新指示を受けたＥＣＵ２２の削除対象鍵を保持するアプリケーション２２１２は、削除対象鍵であるサービスサーバ通信認証鍵２２１４を受け取った削除用鍵で上書きすることによって更新し（Ｓ１０６）、更新完了をメインＥＣＵ２１に通知する（Ｓ１０７）。更新完了通知は、削除対象鍵を特定する情報を含む。メインＥＣＵ２１の鍵管理機能２１１１は、鍵管理サーバ１に更新完了通知を転送する（Ｓ１０８）。
【００７９】
削除ステート管理機能１１０４は、削除対象鍵の削除ステート欄１１１５の値を削除ステート３に更新し（Ｓ１０９）、サービスサーバ３からのインシデント通知を待機する（Ｓ１１０）。なおステップＳ１０３からステップＳ１０９の処理は所定の回数繰返して実施されてもよい。また、ステップＳ１１０における待機中に、鍵管理サーバ１が他の処理を実施してもよい。
【００８０】
続いて、ステップＳ１０６においてサービスサーバ通信認証鍵２２１４を更新したアプリケーション２２１２は、サービスサーバ３との通信を行うために、端末ＩＤ２２１１、アプリＩＤ２２１３、及び更新済みのサービスサーバ通信認証鍵２２１４を用いて、アプリケーション３１０３と相互認証を試みる（Ｓ１１１）。
【００８１】
ここでステップＳ１１１の処理は、ステップＳ１０７の直後や一定時間経過後に実施されてもよいし、サービスサーバ３、鍵管理サーバ１、サービス管理者端末４、又はメインＥＣＵ２１からの通信や通知をきっかけとして実行されてもよい。ステップＳ１１１による相互認証の試みは、サービスサーバ３のアプリケーション３１０３によって処理される。
【００８２】
サービスサーバ３がＥＣＵ２２から受け取った端末ＩＤとアプリＩＤに対応する鍵値欄３１１３の値は、Ｓ１０６において削除用鍵で上書きされたサービスサーバ通信認証鍵２２１４の鍵値と適合しないため、相互認証は失敗する（Ｓ１１２）。
【００８３】
インシデント通知機能３１０２は、例えば、図５Ｂに示した認証失敗のインシデントを鍵管理サーバ１に通知する（Ｓ１１３）。なお、ステップＳ１１３の処理が実施される前にサービスサーバ認証機能１１０６と鍵管理サーバ認証機能３１０６が相互認証を実施し、暗号セッション等を確立しておくことが望ましい。
【００８４】
続いて、インシデント通知処理機能１１０２は、受信したインシデント通知が示すインシデントが、削除対象鍵に関する認証失敗のインシデントであるか否かを判断する（Ｓ１１４）。インシデント通知処理機能１１０２は、受信したインシデント通知が示すインシデントが、削除対象鍵に関する認証失敗のインシデントでないと判断した場合（Ｓ１１４：Ｎｏ）、適切なインシデント処理を行ってＳ１１０に遷移する。
【００８５】
インシデント通知処理機能１１０２が、受信したインシデント通知が示すインシデントが削除対象鍵に関する認証失敗のインシデントであると判断した場合（Ｓ１１４：Ｙｅｓ）、削除ステート管理機能１１０４は削除対象鍵の削除ステート欄１１１５の値を削除ステート４に更新する（Ｓ１１５）。
【００８６】
続いて、鍵管理サーバ１の鍵管理機能１１０１は、サービスサーバ３に削除対象鍵である端末通信認証鍵の削除を指示し、削除ステート管理機能１１０４は削除対象鍵の削除ステート欄１１１５の値を削除ステート５に更新する（Ｓ１１６）。なお、ステップＳ１１６の処理を実施する前に、サービスサーバ認証機能１１０６と鍵管理サーバ認証機能３１０６が相互認証を実施し、暗号セッション等を確立しておくことが望ましい。
【００８７】
続いて、サービスサーバ３の鍵管理機能３１０１は、削除対象鍵である端末通信認証鍵を削除し、削除したことを鍵管理サーバ１に通知する（Ｓ１１７）。削除ステート管理機能１１０４は、削除対象鍵の削除ステート欄１１１５の値を削除ステート６に更新する（Ｓ１１８）。なお、削除ステート管理機能１１０４は、ステップＳ１１８において、削除対象鍵の鍵状態欄１１１４の値を「削除済み」に変更してもよい。
【００８８】
続いて、鍵管理機能１１０１は削除完了をサービス管理者端末４に通知し、削除ステート管理機能１１０４は、削除対象鍵の削除ステート欄１１１５の値を削除ステート７に更新し（Ｓ１１９）、図６の一連の処理が終了する。
【００８９】
なお、鍵管理機能３１０１は、ステップＳ１１７において削除対象鍵を削除しなくてもよい。この場合、インシデント通知機能３１０２は、ステップＳ１１６の指示を受信した後は、削除対象鍵に対応する認証失敗のインシデントが発生しても、当該インシデントを鍵管理サーバ１に通知しないことが望ましい。サービスサーバ３が当該インシデントを通知しないことにより、サービスサーバ３及び鍵管理サーバ１の処理負担が軽減される。
【００９０】
また、鍵管理機能１１０１は、例えばステップＳ１１４の処理以降に、メインＥＣＵ２１を介して、削除対象鍵を有していたＥＣＵ２２に対して、削除対象鍵に対応するアプリケーションの認証を今後試みないよう指示してもよい。なお、鍵管理機能が、例えばステップＳ１１７の処理以降に当該指示を実行してもよい。当該指示により、ＥＣＵ２２及びサービスサーバ３の処理負担が軽減される。
【００９１】
図６に示した処理により、鍵管理サーバ１及びサービス管理者端末４は、削除対象鍵が削除用鍵で上書きされ更新された、即ちＥＣＵ２２から削除されたことを確認することができる。
【００９２】
図７は、ステップＳ１１４におけるインシデント通知判定処理の一例を示すフローチャートである。まず、インシデント通知処理機能１１０２は、取得したインシデント通知におけるインシデント通知内容が認証失敗を示すか否かを判定する（Ｓ１１４ａ）。インシデント通知処理機能１１０２は、インシデント通知内容が認証失敗を示す場合（Ｓ１１４ａ：Ｙｅｓ）ステップＳ１１４ｂに遷移し、インシデント通知内容が認証失敗を示していない場合（Ｓ１１４ａ：Ｎｏ）、ステップＳ１１４ｅに遷移する。
【００９３】
インシデント通知処理機能１１０２は、インシデント通知における端末ＩＤ及びアプリＩＤの組み合わせが、鍵管理テーブル１１１のいずれかのレコードの端末ＩＤ欄１１１１の値及びアプリＩＤ欄１１１２の値の組み合わせと一致するかどうかを判定する（Ｓ１１４ｂ）。
【００９４】
インシデント通知処理機能１１０２は、当該組み合わせが一致するレコードがあると判定した場合（Ｓ１１４ｂ：Ｙｅｓ）、ステップＳ１１４ｃに遷移し、ないと判定した場合（Ｓ１１４ａ：Ｎｏ）、ステップＳ１１４ｅに遷移する。
【００９５】
インシデント通知処理機能１１０２は、一致したレコードの削除ステート欄１１１５の値が削除ステート３であるか否かを判定する（Ｓ１１４ｃ）。インシデント通知処理機能１１０２は、削除ステート３であると判定した場合（Ｓ１１４ｃ：Ｙｅｓ）、ステップＳ１１４ｄに遷移し、削除ステート３でないと判定した場合（Ｓ１１４ｃ：Ｎｏ）、ステップＳ１１４ｅに遷移する。
【００９６】
インシデント通知処理機能１１０２は、インシデント通知における発生日時が一致したレコードの状態変更日時欄１１１６の日時よりも後か否かを判定する。インシデント通知処理機能１１０２は、インシデント通知における発生日時が一致したレコードの状態変更日時欄１１１６の日時よりも後であると判定した場合（Ｓ１１４ｄ：Ｙｅｓ）ステップＳ１１５に遷移し、後でないと判定した場合（Ｓ１１４ｄ：Ｎｏ）、ステップＳ１１４ｅに遷移する。インシデント通知処理機能１１０２は、ステップＳ１１４ａからステップＳ１１４ｄの処理において、インシデント通知における詳細ログを用いた判断処理を実施してもよい。
【００９７】
なお、ステップＳ１１４ｅにおいて、インシデント通知処理機能１１０２は、取得したインシデント通知内容が削除対象鍵の認証失敗のインシデント通知ではなかったと判定して、インシデントの通知に応じた適切な処理を実行し、Ｓ１１０に遷移する。図７の処理により、インシデント通知処理機能１１０２は、取得したインシデント通知内容が削除対象鍵の認証失敗のインシデント通知であった場合に限り、削除対象鍵の削除ステート欄１１１５の値を更新することができる。
【００９８】
図８は、サービス管理者端末４が削除用鍵で鍵を更新することを指示したものの、ＥＣＵ２２が鍵を更新しなかった、又は更新していないにも関わらず更新完了通知を送信した場合の処理の一例を示すシーケンス図である。以下、図６のシーケンス図との相違点を説明する。
【００９９】
図６と同様にステップＳ１０５において、ＥＣＵ２２はから削除用鍵での鍵更新の指示を受ける。しかし、更新指示を受けたＥＣＵ２２の削除対象鍵を保持するアプリケーション２２１２は、削除対象鍵であるサービスサーバ通信認証鍵２２１４を更新しない、又は更新に失敗したにも関わらず更新完了を通知する（Ｓ２０１）。なお、ステップＳ１０８及びステップＳ１０９の処理は、ステップＳ２０１において、更新完了が通知された場合にのみ実施される。
【０１００】
サービスサーバ通信認証鍵２２１４が更新されていないため、ステップＳ１１１におけるＥＣＵ２２とサービスサーバ３との認証は成功する（Ｓ２０２）。従って、インシデント通知機能３１０２は、ステップＳ１１３におけるインシデント通知を実行しない。ステップＳ１１０に続いて、インシデント通知処理機能１１０２は、削除対象鍵の状態変更日時欄１１１６の日時から一定時間が経過したか否か、即ち削除対象鍵の削除ステート欄１１１５の値が削除ステート３に変更されてから一定時間が経過したか否かを判定する（Ｓ２０３）。
【０１０１】
インシデント通知処理機能１１０２が一定時間経過したと判定した場合（Ｓ２０３：Ｙｅｓ）、鍵管理機能１１０１は、削除対象鍵の削除未完了をサービス管理者端末４に通知する（Ｓ２０４）。図８の処理により、鍵管理サーバ１及びサービス管理者端末４は、削除対象鍵がＥＣＵ２２から削除されていない可能性があることを確認することができる。
【実施例２】
【０１０２】
本実施例の情報システムにおけるサービスサーバ３は、削除ステート管理機能を持つ。これによりサービスサーバ３にインシデント通知の仕組みがなくとも、鍵管理サーバ１及びサービス管理者端末４は鍵が削除されたことを確認することができる。
【０１０３】
図９は、鍵管理サーバ１の構成例を示すブロック図である。本実施例の制御ソフト１１０は、インシデント通知処理機能１１０２を含まない点において、実施例１の制御ソフト１１０と異なる。また、削除ステート欄１１１５に格納される削除ステートが実施例１と異なるが、詳細は後述する。
【０１０４】
図１０は、サービスサーバ３の構成例を示すブロック図である。本実施例の制御ソフト３１０は、インシデント通知機能３１０２の代わりに、インシデント処理機能３１０２ａ及び削除ステート管理機能３１０４を含む点において、実施例１の制御ソフト３１０と異なる。
【０１０５】
インシデント処理機能３１０２ａは、サービスサーバ３の処理等に異常が発生したことをインシデントとして検知し、検知したインシデントに応じた処理を実施する削除ステート管理機能３１０４は、鍵テーブル３１１を読み書きすることで鍵削除に関する一連のプロセスをステートとして管理する。
【０１０６】
本実施例の鍵テーブル３１１は、鍵状態欄３１１４、削除ステート欄３１１５、及び状態変更日時欄３１１６をさらに含む点において、実施例１の鍵テーブル３１１と異なる。鍵状態欄３１１４、削除ステート欄３１１５、及び状態変更日時欄３１１６それぞれの説明は、鍵状態欄１１１４、削除ステート欄１１１５、及び状態変更日時欄１１１６それぞれの説明と同様であるため省略する。
【０１０７】
図１１Ａは、削除ステート欄１１１５に格納される削除ステートの一例である。本実施例の削除ステート欄１１１５は、削除ステート４及び削除ステート５を格納せず、削除ステート４ａを格納する点において、実施例１と異なる。削除ステート４ａは、鍵管理サーバ１がサービスサーバ３に鍵の削除（即ち削除対象鍵が削除用鍵で更新されたこと）を報告済みであることを示す。
【０１０８】
図１１Ｂは、削除ステート欄３１１５に格納される削除ステートの一例である。削除ステート欄３１１５は、例えば、削除ステート１ｂ及び削除ステート２ｂを格納する。削除ステート１ｂは、例えば、鍵管理サーバ１から鍵の削除報告があった（即ち、削除対象鍵が削除用鍵で更新された）ことを示す。削除ステート２ｂは、例えば、サービス管理者端末４に端末通信認証鍵の削除完了を通知済みであることを示す。
【０１０９】
図１２は、削除用鍵を用いたサービスサーバ通信認証鍵２２１４の更新処理及び削除完了の確認処理を示すシーケンス図である。以下、図６との相違点を説明し、図６と同様の説明については省略する。
【０１１０】
ステップＳ１０９の処理に続いて、鍵管理機能１１０１はサービスサーバ３に削除対象鍵がＥＣＵ２２から削除されたことを通知し、削除ステート管理機能１１０４は削除ステート欄１１１５の値を削除ステート４ａに更新する（Ｓ３０１）。このとき、鍵管理機能１１０１は、サービスサーバ３に削除対象鍵の削除を明示的に指示してもよい。なお、ステップＳ３０４の処理が実施される前にサービスサーバ認証機能１１０６と鍵管理サーバ認証機能３１０６が相互認証を実施し、暗号セッション等を確立しておくことが望ましい。
【０１１１】
続いて、削除ステート管理機能３１０４は、削除対象鍵に対応する削除ステート欄３１１５の値を削除ステート１ｂに更新し（Ｓ３０２）、ＥＣＵ２２からの相互認証を待機する（Ｓ３０３）。
【０１１２】
インシデント処理機能３１０２ａは、ステップＳ１１２での認証結果を受け、認証失敗した端末通信認証鍵に対応する削除ステート欄３１１５の値が削除ステート１ｂであるか否かを判定する（Ｓ３０４）。インシデント処理機能３１０２ａは、当該削除ステート欄３１１５の値が削除ステート１ｂでないと判定した場合（Ｓ３０４：Ｎｏ）は、当該インシデントに対応するインシデント処理を行ってステップＳ３０３に遷移する。
【０１１３】
インシデント処理機能３１０２ａが当該削除ステート欄３１１５の値が削除ステート１ｂであると判定した場合（Ｓ３０４：Ｙｅｓ）、鍵管理機能３１０１は削除対象鍵を記憶部３１から削除する（Ｓ３０５）。このとき、鍵管理機能３１０１は、削除対象鍵の鍵状態欄３１１４の値を「削除済」に変更してもよい。ステップＳ３０４の処理により、認証失敗が削除中の鍵に関するものであった場合に限り、サービスサーバ３は削除対象鍵をサービスサーバ３から削除することができる。
【０１１４】
続いて、鍵管理機能３１０１は、削除対象鍵の削除完了を鍵管理サーバ１に通知し、削除ステート管理機能３１０４は削除対象鍵の削除ステート欄３１１５の値を削除ステート２ｂに更新し（Ｓ３０６）、ステップＳ１１８に遷移する。なおステップＳ１１８の処理を実施する前にサービスサーバ認証機能１１０６と鍵管理サーバ認証機能３１０６が相互認証を実施し、暗号セッション等を確立しておくことが望ましい。図１２の処理により、サービスサーバ３がインシデント通知を実施せずとも、鍵管理サーバ１およびサービス管理者端末４は、削除対象鍵がＥＣＵ２２から削除されたことを確認することができる。
【０１１５】
図１３は、サービス管理者端末４から削除用鍵で鍵を更新することを指示したものの、ＥＣＵ２２が鍵を更新されなかった、又は更新していないにも関わらず更新完了通知を送信した場合の処理の一例を示すシーケンス図である。以下、図６、図８、及び図１２で説明したステップの説明を省略する。
【０１１６】
インシデント処理機能３１０２ａは、ステップＳ２０２における認証成功の結果を受け、認証成功した鍵の削除ステート欄３１１５の値が削除ステート１ｂであるか否かを判定する（Ｓ４０１）。インシデント処理機能３１０２ａは、当該鍵の削除ステート欄３１１５の値が削除ステート１ｂでないと判定した場合（Ｓ４０１：Ｎｏ）、ステップＳ３０６に遷移する。
【０１１７】
インシデント処理機能３１０２ａが、当該鍵の削除ステート欄３１１５の値が削除ステート１ｂであると判定した場合（Ｓ４０１：Ｙｅｓ）、鍵管理機能３１０１は、削除対象鍵がＥＣＵ２２から削除されていないことを鍵管理サーバ１に通知する（Ｓ４０２）。鍵管理機能１１０１は、削除対象鍵の削除未完了をサービス管理者端末４に通知する（Ｓ４０３）。なお、ステップＳ４０２の処理が実施される前にサービスサーバ認証機能１１０６と鍵管理サーバ認証機能３１０６が相互認証を実施し、暗号セッション等を確立しておくことが望ましい。図１３の処理により、サービスサーバ３がインシデント通知を実施せずとも、鍵管理サーバ１およびサービス管理者端末４は、削除対象鍵がＥＣＵ２２から削除されていないことを確認することができる。
【０１１８】
なお、本実施形態において説明したステップが、実施されている最中に、何らかのエラーが発生した場合は、当該エラーが情報システムの各構成要素の制御部に通知されてもよい。
【０１１９】
また、制御ソフト１１０、制御ソフト２１１０、制御ソフト２２１０、及び制御ソフト３１０に含まれる各プログラムは、必要に応じて、実行中の処理を示す情報を表示装置などに表示してもよい。当該各プログラムは、特に一連の処理の完了や、分岐処理の発生を示す情報を表示装置に表示することが望ましい。また、分岐処理における判定を、入力装置を介したユーザが実行してもよい。
【０１２０】
また、本実施形態において各ステップ間の情報のやり取りを省略して示している場合があるが、実際には、コマンドに対するレスポンスのペアを成している場合がある。また、各ステップ間の情報のやり取りを一組の双方向矢印で示している場合であっても、当該やり取りにおいて複数のコマンド・レスポンスを含んでいてもよい。また、エンティティ間でデータを送受信するという内容を記述している場合でも、実際の通信は一方のエンティティがクライアント役、他方のエンティティがサーバ役となることで、のコマンド・レスポンスを通じて実施され、その結果として先述のようなデータの送信を実現してもよい。
【０１２１】
なお、本発明は上記した各実施例に限定されるものではなく、様々な変形例が含まれる。上記した各実施例は本発明を分かりやすく説明するために詳細に説明されたものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
【０１２２】
また、上記の各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に格納されていてもよい。
【０１２３】
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
【符号の説明】
【０１２４】
１  鍵管理サーバ、２  車載システム、３  サービスサーバ、４  サービス管理者端末、１１１  鍵テーブル、３１１  鍵管理テーブル、１１０１  鍵管理機能、１１０２  インシデント通知処理機能、１１０４  削除ステート管理機能、２１１１  鍵管理機能、２２１２  アプリケーション、２２１４  サービスサーバ通信認証鍵、３１０１  鍵管理機能、３１０２インシデント通知機能、３１０２ａ  インシデント処理機能、３１０３  アプリケーション
【図１】
0006588863.tif 000002
【図２】
0006588863.tif 000003
【図３】
0006588863.tif 000004
【図４】
0006588863.tif 000005
【図５Ａ】
0006588863.tif 000006
【図５Ｂ】
0006588863.tif 000007
【図６】
0006588863.tif 000008
【図７】
0006588863.tif 000009
【図８】
0006588863.tif 000010
【図９】
0006588863.tif 000011
【図１０】
0006588863.tif 000012
【図１１Ａ】
0006588863.tif 000013
【図１１Ｂ】
0006588863.tif 000014
【図１２】
0006588863.tif 000015
【図１３】
0006588863.tif 000016