(57)【特許請求の範囲】
【請求項１】
アプリケーションの脆弱性に関する情報を収集する脆弱性情報収集手段と、
アプリケーションが搭載されたデバイスから前記アプリケーションの情報を取得するとともに、前記脆弱性情報収集手段から前記アプリケーションの脆弱性に関する情報を取得し、前記デバイスから取得した情報と、前記脆弱性情報収集手段から取得した情報とに基づいて、前記デバイスが暗号鍵の更新を必要とする鍵更新対象デバイスであるか否かを判定する更新判定手段と、
前記デバイスに搭載された前記アプリケーションの脆弱性に対する対策が完了したか否かを判定する脆弱性対策完了判定手段とを備え、
前記更新判定手段は、
前記デバイスが鍵更新対象デバイスであると判定し、さらに、前記脆弱性対策完了判定手段によって、アプリケーションの脆弱性に対する対策が完了したと判定された場合に、前記デバイスの暗号鍵を更新し、
前記脆弱性対策完了判定手段は、
アプリケーションが、当該アプリケーションのファイルがパッチファイルに置換された後に再起動が不要であるアプリケーションであるときには、アプリケーションのファイルがパッチファイルに置換された場合に、前記アプリケーションの脆弱性に対する対策が完了したと判定し、
アプリケーションが、当該アプリケーションのファイルがパッチファイルに置換された後に再起動を必要とするアプリケーションであるときには、アプリケーションのファイルがパッチファイルに置換され、さらに、前記アプリケーションが再起動済みである場合に、前記アプリケーションの脆弱性に対する対策が完了したと判定する
ことを特徴とする暗号鍵更新システム。
【請求項２】
アプリケーションの脆弱性に対する対策が完了した場合に、前記対策が完了する前の暗号鍵に関する情報を保持する暗号鍵情報保持手段を備え、
更新判定手段は、
デバイスが鍵更新対象デバイスであると判定し、さらに、脆弱性対策完了判定手段によって、アプリケーションの脆弱性に対する対策が完了したと判定され、新たに生成した暗号鍵に関する情報が、前記暗号鍵情報保持手段に保持されている情報に合致していない場合に、前記新たに生成した暗号鍵で前記デバイスの暗号鍵を更新する
請求項１に記載の暗号鍵更新システム。
【請求項３】
更新判定手段は、
デバイスから、アプリケーションの情報として、アプリケーションのバージョンと、前記アプリケーションの起動中に使用されるファイルのハッシュ値とを取得し、
脆弱性情報収集手段から、アプリケーションの脆弱性に関する情報として、アプリケーションのバージョンと、前記アプリケーションの起動中に使用されるファイルのハッシュ値と、当該アプリケーションによる暗号鍵漏えいの危険性の有無を示す脆弱性有無情報とを取得し、
前記デバイスから取得した情報と、前記脆弱性情報収集手段から取得した情報とに基づいて、前記デバイスが暗号鍵の更新を必要とする鍵更新対象デバイスであるか否かを判定する
請求項１または請求項２に記載の暗号鍵更新システム。
【請求項４】
脆弱性情報収集手段が、
アプリケーションの脆弱性に関する情報を収集し、
更新判定手段が、
アプリケーションが搭載されたデバイスから前記アプリケーションの情報を取得するとともに、前記脆弱性情報収集手段から前記アプリケーションの脆弱性に関する情報を取得し、前記デバイスから取得した情報と、前記脆弱性情報収集手段から取得した情報とに基づいて、前記デバイスが暗号鍵の更新を必要とする鍵更新対象デバイスであるか否かを判定し、
脆弱性対策完了判定手段が、
前記デバイスに搭載された前記アプリケーションの脆弱性に対する対策が完了したか否かを判定し、
前記更新判定手段が、
前記デバイスが鍵更新対象デバイスであると判定し、さらに、前記脆弱性対策完了判定手段によって、アプリケーションの脆弱性に対する対策が完了したと判定された場合に、前記デバイスの暗号鍵を更新し、
前記脆弱性対策完了判定手段が、
アプリケーションが、当該アプリケーションのファイルがパッチファイルに置換された後に再起動が不要であるアプリケーションであるときには、アプリケーションのファイルがパッチファイルに置換された場合に、前記アプリケーションの脆弱性に対する対策が完了したと判定し、
アプリケーションが、当該アプリケーションのファイルがパッチファイルに置換された後に再起動を必要とするアプリケーションであるときには、アプリケーションのファイルがパッチファイルに置換され、さらに、前記アプリケーションが再起動済みである場合に、前記アプリケーションの脆弱性に対する対策が完了したと判定する
ことを特徴とする暗号鍵更新方法。
【請求項５】
暗号鍵情報保持手段が、
アプリケーションの脆弱性に対する対策が完了した場合に、前記対策が完了する前の暗号鍵に関する情報を保持し、
更新判定手段が、
デバイスが鍵更新対象デバイスであると判定し、さらに、脆弱性対策完了判定手段によって、アプリケーションの脆弱性に対する対策が完了したと判定され、新たに生成した暗号鍵に関する情報が、前記暗号鍵情報保持手段に保持されている情報に合致していない場合に、前記新たに生成した暗号鍵で前記デバイスの暗号鍵を更新する
請求項４に記載の暗号鍵更新方法。
【請求項６】
更新判定手段が、
デバイスから、アプリケーションの情報として、アプリケーションのバージョンと、前記アプリケーションの起動中に使用されるファイルのハッシュ値とを取得し、
脆弱性情報収集手段から、アプリケーションの脆弱性に関する情報として、アプリケーションのバージョンと、前記アプリケーションの起動中に使用されるファイルのハッシュ値と、当該アプリケーションによる暗号鍵漏えいの危険性の有無を示す脆弱性有無情報とを取得し、
前記デバイスから取得した情報と、前記脆弱性情報収集手段から取得した情報とに基づいて、前記デバイスが暗号鍵の更新を必要とする鍵更新対象デバイスであるか否かを判定する
請求項４または請求項５に記載の暗号鍵更新方法。
【請求項７】
コンピュータに、
アプリケーションの脆弱性に関する情報を収集する脆弱性情報収集処理、
アプリケーションが搭載されたデバイスから前記アプリケーションの情報を取得し、前記デバイスから取得した情報と、前記脆弱性情報収集処理で取得した情報とに基づいて、前記デバイスが暗号鍵の更新を必要とする鍵更新対象デバイスであるか否かを判定する更新判定処理、
前記デバイスに搭載された前記アプリケーションの脆弱性に対する対策が完了したか否かを判定する脆弱性対策完了判定処理、および、
前記更新判定処理で、前記デバイスが鍵更新対象デバイスであると判定され、さらに、前記脆弱性対策完了判定処理で、アプリケーションの脆弱性に対する対策が完了したと判定された場合に、前記デバイスの暗号鍵を更新する鍵更新処理を実行させ、
前記脆弱性対策完了判定処理で、
アプリケーションが、当該アプリケーションのファイルがパッチファイルに置換された後に再起動が不要であるアプリケーションであるときには、アプリケーションのファイルがパッチファイルに置換された場合に、前記アプリケーションの脆弱性に対する対策が完了したと判定させ、
アプリケーションが、当該アプリケーションのファイルがパッチファイルに置換された後に再起動を必要とするアプリケーションであるときには、アプリケーションのファイルがパッチファイルに置換され、さらに、前記アプリケーションが再起動済みである場合に、前記アプリケーションの脆弱性に対する対策が完了したと判定させる
ための暗号鍵更新プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、デバイスが有している暗号鍵を更新する暗号鍵更新システム、暗号鍵更新方法および暗号鍵更新プログラムに関する。
【背景技術】
【０００２】
暗号を安全に運用するためには、暗号鍵を適切に管理する必要がある。暗号鍵が安全でない場合、暗号化したデータが、悪意のある第三者に盗聴される等の危険性がある。暗号が危殆化する要因として、暗号アルゴリズムの危殆化と、暗号鍵の漏えいとがある。暗号鍵の漏えいの原因の一つは、暗号鍵を有するデバイスに搭載されたアプリケーションの脆弱性である。このような事例の一つとして、ＯｐｅｎＳＳＬ（Secure Sockets Layer）のHeartBleed脆弱性があり、この脆弱性によって、秘密鍵情報が解析される危険性が存在した。【０００３】
また、特許文献１には、再暗号化の制御信号によって、再暗号化を行うシステムが記載されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特許第５９６４４６０号
【発明の概要】
【発明が解決しようとする課題】
【０００５】
特許文献１に記載のシステムでは、再暗号化の制御信号を受信したことをトリガとして、再暗号化を行う。【０００６】
デバイスが有している暗号鍵に着目した場合、その暗号鍵の漏えいの危険性が生じたことをトリガとして、デバイスが有している暗号鍵を更新することが好ましい。ただし、その場合であっても、暗号鍵の漏えいの危険性が残ったままでは、更新後の暗号鍵に関しても、漏えいの可能性が生じる。【０００７】
また、デバイスが使用している暗号鍵が、漏えいした鍵であるのか否かについては、判断できない。そのため、暗号鍵の漏えいの危険性が残ったままでは、漏えいした暗号化鍵を使用した攻撃者がなりすまし等を行う危険性を排除できない。【０００８】
そこで、暗号鍵の漏えいの危険性が生じた場合に、更新後の暗号鍵の漏えいの危険性がなくなった状態で、暗号鍵を更新することができる暗号鍵更新システム、暗号鍵更新方法および暗号鍵更新プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明による暗号鍵更新システムは、アプリケーションの脆弱性に関する情報を収集する脆弱性情報収集手段と、アプリケーションが搭載されたデバイスからアプリケーションの情報を取得するとともに、脆弱性情報収集手段からアプリケーションの脆弱性に関する情報を取得し、デバイスから取得した情報と、脆弱性情報収集手段から取得した情報とに基づいて、デバイスが暗号鍵の更新を必要とする鍵更新対象デバイスであるか否かを判定する更新判定手段と、デバイスに搭載されたアプリケーションの脆弱性に対する対策が完了したか否かを判定する脆弱性対策完了判定手段とを備え、更新判定手段が、デバイスが鍵更新対象デバイスであると判定し、さらに、脆弱性対策完了判定手段によって、アプリケーションの脆弱性に対する対策が完了したと判定された場合に、デバイスの暗号鍵を更新し、脆弱性対策完了判定手段が、アプリケーションが、当該アプリケーションのファイルがパッチファイルに置換された後に再起動が不要であるアプリケーションであるときには、アプリケーションのファイルがパッチファイルに置換された場合に、アプリケーションの脆弱性に対する対策が完了したと判定し、アプリケーションが、当該アプリケーションのファイルがパッチファイルに置換された後に再起動を必要とするアプリケーションであるときには、アプリケーションのファイルがパッチファイルに置換され、さらに、アプリケーションが再起動済みである場合に、アプリケーションの脆弱性に対する対策が完了したと判定することを特徴とする。
【００１０】
また、本発明による暗号鍵更新方法は、脆弱性情報収集手段が、アプリケーションの脆弱性に関する情報を収集し、更新判定手段が、アプリケーションが搭載されたデバイスからアプリケーションの情報を取得するとともに、脆弱性情報収集手段からアプリケーションの脆弱性に関する情報を取得し、デバイスから取得した情報と、脆弱性情報収集手段から取得した情報とに基づいて、デバイスが暗号鍵の更新を必要とする鍵更新対象デバイスであるか否かを判定し、脆弱性対策完了判定手段が、デバイスに搭載されたアプリケーションの脆弱性に対する対策が完了したか否かを判定し、更新判定手段が、デバイスが鍵更新対象デバイスであると判定し、さらに、脆弱性対策完了判定手段によって、アプリケーションの脆弱性に対する対策が完了したと判定された場合に、デバイスの暗号鍵を更新し、脆弱性対策完了判定手段が、アプリケーションが、当該アプリケーションのファイルがパッチファイルに置換された後に再起動が不要であるアプリケーションであるときには、アプリケーションのファイルがパッチファイルに置換された場合に、アプリケーションの脆弱性に対する対策が完了したと判定し、アプリケーションが、当該アプリケーションのファイルがパッチファイルに置換された後に再起動を必要とするアプリケーションであるときには、アプリケーションのファイルがパッチファイルに置換され、さらに、アプリケーションが再起動済みである場合に、アプリケーションの脆弱性に対する対策が完了したと判定することを特徴とする。
【００１１】
また、本発明による暗号鍵更新プログラムは、コンピュータに、アプリケーションの脆弱性に関する情報を収集する脆弱性情報収集処理、アプリケーションが搭載されたデバイスからアプリケーションの情報を取得し、デバイスから取得した情報と、脆弱性情報収集処理で取得した情報とに基づいて、デバイスが暗号鍵の更新を必要とする鍵更新対象デバイスであるか否かを判定する更新判定処理、デバイスに搭載されたアプリケーションの脆弱性に対する対策が完了したか否かを判定する脆弱性対策完了判定処理、および、更新判定処理で、デバイスが鍵更新対象デバイスであると判定され、さらに、脆弱性対策完了判定処理で、アプリケーションの脆弱性に対する対策が完了したと判定された場合に、デバイスの暗号鍵を更新する鍵更新処理を実行させ、脆弱性対策完了判定処理で、アプリケーションが、当該アプリケーションのファイルがパッチファイルに置換された後に再起動が不要であるアプリケーションであるときには、アプリケーションのファイルがパッチファイルに置換された場合に、アプリケーションの脆弱性に対する対策が完了したと判定させ、アプリケーションが、当該アプリケーションのファイルがパッチファイルに置換された後に再起動を必要とするアプリケーションであるときには、アプリケーションのファイルがパッチファイルに置換され、さらに、アプリケーションが再起動済みである場合に、アプリケーションの脆弱性に対する対策が完了したと判定させることを特徴とする。
【発明の効果】
【００１２】
本発明によれば、暗号鍵の漏えいの危険性が生じた場合に、更新後の暗号鍵の漏えいの危険性がなくなった状態で、暗号鍵を更新することができる。
【図面の簡単な説明】
【００１３】
【図１】本発明の暗号鍵更新システムの例を示すブロック図である。
【図２】本発明の実施形態の処理経過の例を示すフローチャートである。
【図３】ステップＳ１の処理の例を示すフローチャートである。
【図４】ステップＳ２の処理の例を示すフローチャートである。
【図５】ステップＳ２の処理の例を示すフローチャートである。
【図６】ステップＳ３の処理の例を示すフローチャートである。
【図７】アプリケーション脆弱性情報収集サーバ、鍵管理サーバ、脆弱性対策完了判定サーバおよびＮＧ暗号アルゴリズムの機能を１台のコンピュータで実現する場合のコンピュータの例を示す概略ブロック図である。
【図８】本発明の暗号鍵更新システムの概要を示すブロック図である。
【発明を実施するための形態】
【００１４】
以下、本発明の実施形態を図面を参照して説明する。
【００１５】
図１は、本発明の暗号鍵更新システムの例を示すブロック図である。本発明の暗号鍵更新システムは、アプリケーション脆弱性情報収集サーバ１１と、鍵管理サーバ１２と、脆弱性対策完了判定サーバ１３と、ＮＧ（No Good ）暗号アルゴリズム管理サーバ１４と、デバイス１５とを備える。図１では、１台のデバイス１５を図示しているが、デバイス１５の台数は限定されない。
【００１６】
デバイス１５は、暗号鍵を格納するための暗号鍵格納領域２３を備える。暗号鍵は、鍵管理サーバ１２によって発行される。また、デバイス１５には、鍵管理エージェント２１と、アプリケーション２２とが搭載されている。鍵管理エージェント２１は、ソフトウェアであり、実際には、デバイス１５に設けられているプロセッサが鍵管理エージェント２１に従って動作する。ただし、以下では、説明を簡単にするために、鍵管理エージェント２１の動作として説明する。
【００１７】
また、本実施形態において、アプリケーションは、アプリケーションソフトウェアである。
【００１８】
アプリケーション脆弱性情報収集サーバ１１は、アプリケーションの脆弱性に関する情報を、インターネットで公開されている情報の中から収集する。
【００１９】
アプリケーション脆弱性情報収集サーバ１１は、例えば、各アプリケーションに関して、アプリケーションの脆弱性情報と、そのアプリケーションに適用されるパッチのバージョンと、そのパッチを構成する各ファイル（パッチファイル）のファイル名と、そのパッチを構成する各ファイルのハッシュ値およびアプリケーションを構成する各ファイルのハッシュ値と、アプリケーションのバージョンと、アプリケーションにパッチを適用した後に再起動が必要か否かを示す再起動要否情報とを収集し、保持する。
【００２０】
アプリケーションの脆弱性情報は、アプリケーションのセキュリティ上の弱点に関する情報である。また、この脆弱性情報は、アプリケーションの脆弱性による暗号鍵漏えいの危険性の有無を示す脆弱性有無情報を含んでいる。
【００２１】
アプリケーションを構成するファイルとは、アプリケーション起動中に使用されるファイルである。アプリケーションを構成するファイルの数は、１つに限定されない。同様に、パッチを構成するファイル（パッチファイル）の数も、１つに限定されない。
【００２２】
鍵管理サーバ１２は、鍵管理エージェント２１が鍵管理サーバ１２に送信した情報や、アプリケーション脆弱性情報収集サーバ１１から取得した情報をそれぞれ保持する。
【００２３】
鍵管理サーバ１２は、鍵管理サーバ１２がデバイス１５に対して発行した暗号鍵に関する情報を、鍵管理エージェント２１から取得し、保持する。発行した暗号鍵に関する情報は、具体的には、その暗号鍵を有するデバイスのデバイス名（換言すれば、鍵管理エージェント２１が搭載されているデバイス１５のデバイス名）、アプリケーション２２が使用している暗号アルゴリズム、および、鍵長である。また、鍵管理サーバ１２は、暗号鍵の利用用途も、鍵管理エージェント２１から取得し、保持する。さらに、鍵管理サーバ１２は、デバイス１５に搭載されているアプリケーション２２のアプリケーション名、アプリケーション２２を構成する各ファイルのファイル名、アプリケーション２２を構成する各ファイルのハッシュ値、および、アプリケーション２２のバージョンも、鍵管理エージェント２１から取得し、保持する。
【００２４】
また、鍵管理サーバ１２は、各アプリケーションに関する、脆弱性有無情報、パッチのバージョン、パッチを構成する各ファイルのファイル名、パッチを構成する各ファイルのハッシュ値、アプリケーションを構成する各ファイルのハッシュ値、再起動要否情報を、アプリケーション脆弱性情報収集サーバ１１から取得し、保持する。
【００２５】
脆弱性対策完了判定サーバ１３は、鍵管理エージェント２１が脆弱性対策完了判定サーバ１３に送信した情報や、アプリケーション脆弱性情報収集サーバ１１や鍵管理サーバ１２から取得した情報を保持する。
【００２６】
脆弱性対策完了判定サーバ１３は、鍵管理エージェント２１から、デバイス１５に搭載されているアプリケーション２２のアプリケーション名、アプリケーション２２を構成する各ファイルのファイル名、アプリケーション２２を構成する各ファイルのハッシュ値を取得し、保持する
【００２７】
また、脆弱性対策完了判定サーバ１３は、鍵管理エージェント２１から、アプリケーション２２を構成する各ファイルの作成日時と、アプリケーション２２のプロセス開始時刻の情報を鍵管理エージェント２１から取得し、保持する。アプリケーション２２にパッチが適用された場合には、アプリケーション２２を構成する各ファイルの作成日時の中には、パッチファイルの作成日時も含まれることになる。そして、アプリケーション２２を構成する各ファイルの作成日時と、アプリケーション２２のプロセス開始時刻との比較により、パッチ適用後にアプリケーション２２が再起動したか否かを判定することができる。
【００２８】
なお、アプリケーション２２を構成する各ファイルの作成日時と、アプリケーション２２のプロセス開始時刻とを比較する処理は、脆弱性対策完了判定サーバ１３が実行してもよく、あるいは、鍵管理エージェント２１が実行してもよい。この比較処理を鍵管理エージェント２１が実行する場合、鍵管理エージェント２１は、前述の作成日時やプロセス開始時刻の情報を脆弱性対策完了判定サーバ１３に送信しなくてもよい。その場合、鍵管理エージェント２１は、上記の比較処理の結果（比較結果）を脆弱性対策完了判定サーバ１３に送信すればよい。
【００２９】
また、脆弱性対策完了判定サーバ１３は、鍵管理サーバ１２から、アプリケーション２２のパッチを構成する各ファイルのファイル名、そのパッチを構成する各ファイルのハッシュ値を、鍵管理サーバ１２から取得し、保持する。
【００３０】
また、脆弱性対策完了判定サーバ１３は、アプリケーション２２の再起動要否情報をアプリケーション脆弱性情報収集サーバ１１から取得し、保持する。なお、脆弱性対策完了判定サーバ１３は、鍵管理サーバ１２から、アプリケーション２２の再起動要否情報を取得してもよい。
【００３１】
デバイス１５に搭載されたアプリケーション２２の脆弱性が存在する場合、脆弱性対策完了判定サーバ１３は、取得した情報に基づいて、アプリケーション２２の脆弱性に対する対策が完了したか否かを判定する。
【００３２】
ＮＧ暗号アルゴリズム管理サーバ１４は、デバイス１５に搭載されたアプリケーション２２の脆弱性が存在していて、その脆弱性に対する対策が完了した場合、その対策の完了前における暗号鍵（デバイス１５が対策完了前に有していた暗号鍵）に関する情報（アプリケーション２２のアプリケーション名、アプリケーション２２が使用している暗号アルゴリズム、暗号鍵の鍵長）を、鍵管理エージェント２１から受け取り、その情報を保持する。ＮＧ暗号アルゴリズム管理サーバ１４は、脆弱性に対する対策の完了前における暗号鍵に関する情報を、鍵管理サーバ１２から受け取ってもよい。後述の図６に示すフローチャートの説明では、ＮＧ暗号アルゴリズム管理サーバ１４が対策の完了前における暗号鍵に関する情報を鍵管理サーバ１２から受け取る場合を例にして説明する。
【００３３】
鍵管理エージェント２１は、アプリケーション２２のアプリケーション名、アプリケーション２２のバージョン、アプリケーション２２を構成する各ファイルのファイル名、アプリケーション２２を構成する各ファイルのハッシュ値、アプリケーション２２を構成する各ファイルの作成日時、アプリケーション２２のプロセス開始時刻等を保持し、保持している情報を、他のサーバに送信する。
【００３４】
また、本実施形態では、鍵管理サーバ１２は、デバイス１５に搭載されたアプリケーション２２の脆弱性が存在していて、その脆弱性に対する対策が完了したと判定された場合、デバイス１５に対して発行する新たな暗号鍵を生成する。鍵管理サーバ１２は、その新たな暗号鍵に関する情報が、ＮＧ暗号アルゴリズム管理サーバ１４に保持されている情報と合致していないならば、新たな暗号鍵で、デバイス１５が有している暗号鍵を更新する。
【００３５】
デバイス１５は、アプリケーション２２や鍵管理エージェント２１に従って動作する。
【００３６】
アプリケーション脆弱性情報収集サーバ１１は、アプリケーション脆弱性情報収集サーバ１１用のプログラムに従って動作する。
【００３７】
鍵管理サーバ１２は、鍵管理サーバ１２用のプログラムに従って動作する。
【００３８】
脆弱性対策完了判定サーバ１３は、脆弱性対策完了判定サーバ１３用のプログラムに従って動作する。
【００３９】
ＮＧ暗号アルゴリズム管理サーバ１４は、ＮＧ暗号アルゴリズム管理サーバ１４用のプログラムに従って動作する。
【００４０】
次に、本実施形態の処理経過の例について説明する。図２は、本実施形態の処理経過の例を示すフローチャートである。
【００４１】
本実施形態の暗号鍵更新システムは、まず、デバイス１５が鍵更新対象デバイスであることを検知する処理を行う（ステップＳ１）。鍵更新対象デバイスとは、暗号鍵の更新を必要とするデバイスであり、デバイスに搭載されているアプリケーションに暗号鍵漏えいの危険性がある場合、そのデバイスは、鍵更新対象デバイスに該当する。
【００４２】
ステップＳ１に続いて、暗号鍵更新システムは、デバイス１５のアプリケーション２２の脆弱性に対する対策が完了したことを確認する処理を行う（ステップＳ２）。
【００４３】
次に、暗号鍵更新システムは、デバイス１５の暗号鍵を更新する処理を行う（ステップＳ３）。
【００４４】
次に、ステップＳ１，Ｓ２，Ｓ３の各処理について、それぞれ、より具体的に説明する。
【００４５】
図３は、ステップＳ１の処理の例を示すフローチャートである。なお、デバイス１５は稼働しているものとする。換言すれば、デバイス１５は、アプリケーション２２に従って動作しているものとする。
【００４６】
ステップＳ１において、鍵管理エージェント２１は、デバイス１５に搭載されているアプリケーション２２の情報を、定期的に鍵管理サーバ１２に送信する（ステップＳ１１）。アプリケーション２２の情報とは、アプリケーション２２のバージョン、および、アプリケーション２２を構成する各ファイルのハッシュ値である。すなわち、鍵管理エージェント２１は、アプリケーション２２のバージョン、および、アプリケーション２２を構成する各ファイルのハッシュ値を、定期的に、鍵管理サーバ１２に送信する。鍵管理サーバ１２は、鍵管理エージェント２１がその情報（アプリケーション２２のバージョン、および、アプリケーション２２を構成する各ファイルのハッシュ値）を送信する度に、その情報を受信する。
【００４７】
また、鍵管理サーバ１２は、アプリケーション脆弱性情報収集サーバ１１から、デバイス１５に搭載されているアプリケーション２２の脆弱性に関する情報を、定期的に取得する（ステップＳ１２）。アプリケーション２２の脆弱性に関する情報とは、アプリケーション２２のバージョン、アプリケーション２２を構成する各ファイルのハッシュ値、および、アプリケーション２２の脆弱性有無情報である。すなわち、鍵管理サーバ１２は、アプリケーション２２のバージョン、アプリケーション２２を構成する各ファイルのハッシュ値、および、アプリケーション２２の脆弱性有無情報を、定期的にアプリケーション脆弱性情報収集サーバ１１から取得する。
【００４８】
次に、鍵管理サーバ１２は、アプリケーション２２の脆弱性によりデバイス１５の暗号鍵の漏えいの危険性があるか否かを判定する（ステップＳ１３）。ステップＳ１３では、鍵管理サーバ１２は、鍵管理エージェント２１からステップＳ１１で受信したバージョンおよび各ハッシュ値と、アプリケーション脆弱性情報収集サーバ１１からステップＳ１２で取得したバージョンおよび各ハッシュ値とが合致していて、さらに、ステップＳ１２で取得した脆弱性有無情報が、アプリケーション２２の脆弱性による暗号鍵漏えいの危険性がある旨を示しているという条件が満たされていれば、アプリケーション２２の脆弱性によりデバイス１５の暗号鍵の漏えいの危険性があると判定する。また、鍵管理サーバ１２は、その条件が満たされていなければ、アプリケーション２２の脆弱性によるデバイス１５の暗号鍵の漏えいの危険性はないと判定する。
【００４９】
鍵管理サーバ１２が、アプリケーション２２の脆弱性によるデバイス１５の暗号鍵の漏えいの危険性はないと判定した場合（ステップＳ１３のＮｏ）、ステップＳ１１以降の処理を繰り返す。
【００５０】
また、アプリケーション２２の脆弱性によりデバイス１５の暗号鍵の漏えいの危険性があると判定した場合（ステップＳ１３のＹｅｓ）、鍵管理サーバ１２は、デバイス１５が鍵更新対象デバイスであると判定する（ステップＳ１４）。ステップＳ１４で、ステップＳ１が終了する。
【００５１】
図４および図５は、ステップＳ２の処理の例を示すフローチャートである。
【００５２】
例えば、ステップＳ１の後、鍵管理サーバ１２が、鍵管理エージェント２１に、デバイス１５が鍵更新対象デバイスであると判定された旨を通知すると、ステップＳ２の処理が開始される。
【００５３】
ステップＳ２において、鍵管理エージェント２１が、定期的に、デバイス１５に搭載されたアプリケーション２２を構成する各ファイルのハッシュ値を確認し（ステップＳ２１）、ハッシュ値が変化したファイルがあるか否かを判定する（ステップＳ２２）。ハッシュ値が変化したファイルがなければ（ステップＳ２２のＮｏ）、ステップＳ２１以降の処理を繰り返す。
【００５４】
ハッシュ値が変化したファイルある場合（ステップＳ２２のＹｅｓ）、アプリケーション２２を構成する各ファイルの一部がパッチファイルに置換された可能性（すなわち、アプリケーション２２にパッチが適用された可能性）がある。以下に示すステップＳ２３，Ｓ２４において、アプリケーション２２にパッチが適用されたか否かを確認する。
【００５５】
ハッシュ値が変化したファイルある場合（ステップＳ２２のＹｅｓ）、鍵管理エージェント２１は、デバイス１５に搭載されているアプリケーション２２を構成する各ファイルのファイル名とハッシュ値とを脆弱性対策完了判定サーバ１３に送信する。また、鍵管理サーバ１２は、アプリケーション２２のパッチを構成する各ファイルのファイル名とハッシュ値とを、脆弱性対策完了判定サーバ１３に送信する（ステップＳ２３）。なお、鍵管理サーバ１２は、アプリケーション２２のパッチを構成する各ファイルのファイル名およびハッシュ値を、予め、アプリケーション脆弱性情報収集サーバ１１から取得しておけばよい。そして、鍵管理サーバ１２は、ハッシュ値が変化したファイルある旨の通知を鍵管理エージェント２１から受信した場合に、アプリケーション２２のパッチを構成する各ファイルのファイル名とハッシュ値とを、脆弱性対策完了判定サーバ１３に送信すればよい。
【００５６】
脆弱性対策完了判定サーバ１３は、ステップＳ２３で鍵管理エージェント２１から受信した情報（ファイル名およびハッシュ値）と、ステップＳ２３で鍵管理サーバ１２から受信した情報（ファイル名およびハッシュ値）とを照合し、デバイス１５に搭載されているアプリケーション２２を構成する各ファイルの一部がパッチファイルに置換されたか否かを判定する（ステップＳ２４）。例えば、脆弱性対策完了判定サーバ１３は、鍵管理エージェント２１から受信したファイル名およびハッシュ値の組の中に、鍵管理サーバ１２から受信したファイル名およびハッシュ値の組が含まれているならば、アプリケーション２２を構成する各ファイルの一部がパッチファイルに置換されたと判定し、そうでなければ、アプリケーション２２を構成する各ファイルの一部がパッチファイルに置換されていないと判定する。
【００５７】
アプリケーション２２を構成する各ファイルの一部がパッチファイルに置換されていない（換言すれば、アプリケーション２２にパッチが適用されていない）と判定した場合（ステップＳ２４のＮｏ）、ステップＳ２１以降の処理を繰り返す。
【００５８】
アプリケーション２２を構成する各ファイルの一部がパッチファイルに置換された（換言すれば、アプリケーション２２にパッチが適用された）と判定した場合（ステップＳ２４のＹｅｓ）、ステップＳ２５（図５参照）に移行する。本例では、このとき、脆弱性対策完了判定サーバ１３が、鍵管理エージェント２１に対して、アプリケーション２２にパッチが適用された旨を通知するものとする。
【００５９】
ステップＳ２５では、鍵管理エージェント２１が、アプリケーション２２がパッチ適用後に再起動が必要なアプリケーションであるか否かを脆弱性対策完了判定サーバ１３に問い合わせる。脆弱性対策完了判定サーバ１３は、アプリケーション２２に対応する再起動要否情報を参照することによって、アプリケーション２２がパッチ適用後に再起動が必要なアプリケーションであるか否かを鍵管理エージェント２１に通知すればよい。
【００６０】
アプリケーション２２がパッチ適用後に再起動が不要なアプリケーションである場合（ステップＳ２５のＮｏ）、脆弱性対策完了判定サーバ１３が、デバイス１５のアプリケーション２２の脆弱性に対する対策が完了したと判定する（ステップＳ２７）。すなわち、脆弱性対策完了判定サーバ１３は、アプリケーション２２がパッチ適用後に再起動が不要なアプリケーションであることを確認した場合、デバイス１５のアプリケーション２２の脆弱性に対する対策が完了したと判定すればよい。
【００６１】
アプリケーション２２がパッチ適用後に再起動が必要なアプリケーションである場合（ステップＳ２５のＹｅｓ）、鍵管理エージェント２１は、デバイス１５におけるアプリケーション２２のプロセス開始時刻と、アプリケーション２２を構成する各ファイルの作成日時とを比較し、アプリケーション２２のプロセス開始時刻が、その各ファイルの作成日時より後であるか否かを判定する（ステップＳ２６）。鍵管理エージェント２１は、ステップＳ２６の判定結果（プロセス開始時刻が各ファイルの作成日時より後であるか否か）を、脆弱性対策完了判定サーバ１３に通知する。アプリケーション２２のプロセス開始時刻が、各ファイルの作成日時より後であるということは、アプリケーション２２がパッチ適用後に再起動したことを意味する。また、プロセス開始時刻が、各ファイルの作成日時より後であるという条件が満たされていない場合、アプリケーション２２がパッチ適用後に再起動していないことを意味する。
【００６２】
プロセス開始時刻が各ファイルの作成日時より後であるという条件が満たされていない場合（ステップＳ２６のＮｏ）、鍵管理エージェント２１は、ステップＳ２６の比較処理を繰り返す。プロセス開始時刻が各ファイルの作成日時より後である場合（ステップＳ２６のＹｅｓ）、脆弱性対策完了判定サーバ１３は、その旨の通知により、アプリケーション２２がパッチ適用後に再起動したと判定する。そして、脆弱性対策完了判定サーバ１３が、デバイス１５のアプリケーション２２の脆弱性に対する対策が完了したと判定する（ステップＳ２７）。ステップＳ２７で、前述のステップＳ２が終了する。
【００６３】
上記の例では、ステップＳ２５で、鍵管理エージェント２１が、アプリケーション２２がパッチ適用後に再起動が必要なアプリケーションであるか否かを脆弱性対策完了判定サーバ１３に問い合わせる場合を例にして説明した。ステップＳ２５において、脆弱性対策完了判定サーバ１３が、アプリケーション２２がパッチ適用後に再起動が必要なアプリケーションであるか否かを判定してもよい。
【００６４】
また、上記の例では、ステップＳ２６で、鍵管理エージェント２１が、デバイス１５におけるアプリケーション２２のプロセス開始時刻と、アプリケーション２２を構成する各ファイルの作成日時とを比較し、アプリケーション２２のプロセス開始時刻が、その各ファイルの作成日時より後であるか否かを判定する場合を例にして説明した。ステップＳ２６において、脆弱性対策完了判定サーバ１３が、アプリケーション２２のプロセス開始時刻と、アプリケーション２２を構成する各ファイルの作成日時とを比較し、アプリケーション２２のプロセス開始時刻が、その各ファイルの作成日時より後であるか否かを判定してもよい。この場合、例えば、脆弱性対策完了判定サーバ１３が、鍵管理エージェント２１に対して、アプリケーション２２にパッチが適用された旨を通知し、この通知に応じて、鍵管理エージェント２１が、アプリケーション２２のプロセス開始時刻と、アプリケーション２２を構成する各ファイルの作成日時とを、脆弱性対策完了判定サーバ１３に送信すればよい。
【００６５】
図６は、ステップＳ３の処理の例を示すフローチャートである。なお、ステップＳ２が終了したときに、脆弱性対策完了判定サーバ１３は、デバイス１５のアプリケーション２２の脆弱性に対する対策が完了した旨を鍵管理サーバ１２に通知する。
【００６６】
この通知を受けた鍵管理サーバ１２は、アプリケーション２２の脆弱性に対する対策の完了前における暗号鍵（換言すれば、既にアプリケーション２２向けに発行済みの暗号鍵）に関する情報を、ＮＧ暗号アルゴリズム管理サーバ１４に送信する。そして、ＮＧ暗号アルゴリズム管理サーバ１４は、その情報を受信し、その情報を保持する（ステップＳ３１）。アプリケーション２２の脆弱性に対する対策の完了前における暗号鍵に関する情報は、アプリケーション２２のアプリケーション名、アプリケーション２２が使用している暗号アルゴリズム、および、発行済みの暗号鍵の鍵長である。
【００６７】
次に、鍵管理サーバ１２は、デバイス１５に搭載されているアプリケーション２２向けの新たな暗号鍵を生成し、その暗号鍵に関する情報（アプリケーション２２のアプリケーション名、アプリケーション２２が使用する暗号アルゴリズム、および、新たな暗号鍵の鍵長の組）が、ＮＧ暗号アルゴリズム管理サーバ１４に保持されている情報と合致しないことを確認する（ステップＳ３２）。両者が合致する場合には、鍵管理サーバ１２は、再度、ステップＳ３２を実行すればよい。
【００６８】
ステップＳ３２の後、鍵管理サーバ１２は、デバイス１５が有する暗号鍵を、新たに生成した暗号鍵で更新する。すなわち、鍵管理サーバ１２は、新たに生成した暗号鍵をデバイス１５に送信し、デバイス１５は、受信した新たな暗号鍵を、アプリケーション２２が利用可能な暗号鍵格納領域２３に格納する（ステップＳ３３）。ステップＳ３３で、前述のステップＳ３が終了する。
【００６９】
本実施形態によれば、鍵管理サーバ１２が、デバイス１５が鍵更新対象デバイスであると判定し、さらに、脆弱性対策完了判定サーバ１３が、アプリケーション２２の脆弱性に対する対策が完了したと判定した後に、鍵管理サーバ１２が、デバイス１５の暗号鍵を更新する。従って、デバイス１５の暗号鍵の漏えいの危険性が生じた場合に、デバイスの暗号鍵を更新することができる。また、デバイス１５に搭載されたアプリケーション２２の脆弱性に対する対策が完了したと判定した後に、鍵管理サーバ１２が暗号鍵を更新するので、更新後の暗号鍵が漏えいする危険性はない。すなわち、本実施形態によれば、暗号鍵の漏えいの危険性が生じた場合に、更新後の暗号鍵の漏えいの危険性がなくなった状態で、暗号鍵を更新することができる。
【００７０】
さらに、本実施形態によれば、鍵管理サーバ１２は、新たに生成した暗号鍵に関する情報が、既に発行済みの暗号鍵（脆弱性に対する対策の完了前における暗号鍵）に関する情報と合致していないことを確認した後に、新たな暗号鍵でデバイス１５の暗号鍵を更新する。従って、この点からも、更新後の暗号鍵が漏えいする危険性を低減することができる。
【００７１】
また、上記の実施形態では、アプリケーション脆弱性情報収集サーバ１１、鍵管理サーバ１２、脆弱性対策完了判定サーバ１３およびＮＧ暗号アルゴリズム１４がそれぞれ別々のサーバである場合を示した（図１参照）。これらの各サーバの代わりに、これらの各サーバの機能を有する１台のコンピュータが設けられてもよい。すなわち、アプリケーション脆弱性情報収集サーバ１１、鍵管理サーバ１２、脆弱性対策完了判定サーバ１３およびＮＧ暗号アルゴリズム１４の機能が、暗号鍵更新プログラムに従って動作するコンピュータのＣＰＵ（Central Processing Unit ）によって実現されてもよい。例えば、コンピュータのＣＰＵが、コンピュータのプログラム記憶装置等のプログラム記録媒体から暗号鍵更新プログラムを読み込み、その暗号鍵更新プログラムに従って、アプリケーション脆弱性情報収集サーバ１１、鍵管理サーバ１２、脆弱性対策完了判定サーバ１３およびＮＧ暗号アルゴリズム１４と同様の動作を行ってもよい。
【００７２】
図７は、アプリケーション脆弱性情報収集サーバ１１、鍵管理サーバ１２、脆弱性対策完了判定サーバ１３およびＮＧ暗号アルゴリズム１４の機能を１台のコンピュータで実現する場合のコンピュータの例を示す概略ブロック図である。コンピュータ２は、ＣＰＵ１００１と、主記憶装置１００２と、補助記憶装置１００３と、インタフェース１００４と、通信インタフェース１００５とを備える。通信インタフェース１００５は、デバイス１５と通信を行うための通信インタフェースである。
【００７３】
アプリケーション脆弱性情報収集サーバ１１、鍵管理サーバ１２、脆弱性対策完了判定サーバ１３およびＮＧ暗号アルゴリズム１４の機能は、コンピュータ２に実装される。コンピュータ２の動作は、暗号鍵更新プログラムの形式で補助記憶装置１００３に記憶されている。ＣＰＵ１００１は、その暗号鍵更新プログラムを補助記憶装置１００３から読み出して主記憶装置１００２に展開し、その暗号鍵更新プログラムに従って、アプリケーション脆弱性情報収集サーバ１１、鍵管理サーバ１２、脆弱性対策完了判定サーバ１３およびＮＧ暗号アルゴリズム１４と同様の動作を行う。
【００７４】
補助記憶装置１００３は、一時的でない有形の媒体の例である。一時的でない有形の媒体の他の例として、インタフェース１００４を介して接続される磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭ（Compact Disk Read Only Memory ）、ＤＶＤ−ＲＯＭ（Digital Versatile Disk Read Only Memory ）、半導体メモリ等が挙げられる。また、このプログラムが通信回線によってコンピュータ２に配信される場合、配信を受けたコンピュータ２がそのプログラムを主記憶装置１００２に展開し、そのプログラムに従って動作してもよい。
【００７５】
次に、本発明の概要について説明する。図８は、本発明の暗号鍵更新システムの概要を示すブロック図である。本発明の暗号鍵更新システムは、脆弱性情報収集手段９１と、更新判定手段９２と、脆弱性対策完了判定手段９３とを備える。
【００７６】
脆弱性情報収集手段９１（例えば、アプリケーション脆弱性情報収集サーバ１１）は、アプリケーションの脆弱性に関する情報を収集する。
【００７７】
更新判定手段９２（例えば、鍵管理サーバ１２）は、アプリケーション（例えば、アプリケーション２２）が搭載されたデバイス（例えば、デバイス１５）からアプリケーションの情報を取得するとともに、脆弱性情報収集手段９１からアプリケーションの脆弱性に関する情報を取得し、デバイスから取得した情報と、脆弱性情報収集手段９１から取得した情報とに基づいて、デバイスが暗号鍵の更新を必要とする鍵更新対象デバイスであるか否かを判定する。
【００７８】
脆弱性対策完了判定手段９３（例えば、脆弱性対策完了判定サーバ１３）は、デバイスに搭載されたアプリケーションの脆弱性に対する対策が完了したか否かを判定する。
【００７９】
また、更新判定手段９２は、デバイスが鍵更新対象デバイスであると判定し、さらに、脆弱性対策完了判定手段９３によって、アプリケーションの脆弱性に対する対策が完了したと判定された場合に、デバイスの暗号鍵を更新する。
【００８０】
そのような構成により、暗号鍵の漏えいの危険性が生じた場合に、更新後の暗号鍵の漏えいの危険性がなくなった状態で、暗号鍵を更新することができる。
【００８１】
また、脆弱性対策完了判定手段９３が、アプリケーションが、当該アプリケーションのファイルがパッチファイルに置換された後に再起動が不要であるアプリケーションであるときには、アプリケーションのファイルがパッチファイルに置換された場合に、アプリケーションの脆弱性に対する対策が完了したと判定し、アプリケーションが、当該アプリケーションのファイルがパッチファイルに置換された後に再起動を必要とするアプリケーションであるときには、アプリケーションのファイルがパッチファイルに置換され、さらに、アプリケーションが再起動済みである場合に、アプリケーションの脆弱性に対する対策が完了したと判定する構成であってもよい。
【００８２】
また、アプリケーションの脆弱性に対する対策が完了した場合に、対策が完了する前の暗号鍵に関する情報を保持する暗号鍵情報保持手段（例えば、ＮＧ暗号アルゴリズム管理サーバ１４）を備え、更新判定手段９２が、デバイスが鍵更新対象デバイスであると判定し、さらに、脆弱性対策完了判定手段９３によって、アプリケーションの脆弱性に対する対策が完了したと判定され、新たに生成した暗号鍵に関する情報が、暗号鍵情報保持手段に保持されている情報に合致していない場合に、新たに生成した暗号鍵でデバイスの暗号鍵を更新する構成であってもよい。
【００８３】
また、更新判定手段９２が、デバイスから、アプリケーションの情報として、アプリケーションのバージョンと、アプリケーションの起動中に使用されるファイルのハッシュ値とを取得し、脆弱性情報収集手段９１から、アプリケーションの脆弱性に関する情報として、アプリケーションのバージョンと、アプリケーションの起動中に使用されるファイルのハッシュ値と、当該アプリケーションによる暗号鍵漏えいの危険性の有無を示す脆弱性有無情報とを取得し、デバイスから取得した情報と、脆弱性情報収集手段９１から取得した情報とに基づいて、デバイスが暗号鍵の更新を必要とする鍵更新対象デバイスであるか否かを判定する構成であってもよい。
【００８４】
以上、実施形態を参照して本願発明を説明したが、本願発明は上記の実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
【００８５】
この出願は、２０１８年３月１５日に出願された日本特許出願２０１８−０４７４４２を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【産業上の利用の可能性】
【００８６】
本発明は、暗号鍵を更新する暗号鍵更新システムに好適に適用される。
【符号の説明】
【００８７】
１１  アプリケーション脆弱性情報収集サーバ
１２  鍵管理サーバ
１３  脆弱性対策完了判定サーバ
１４  ＮＧ暗号アルゴリズム管理サーバ
１５  デバイス
２１  鍵管理エージェント
２２  アプリケーション
２３  暗号鍵格納領域
【図１】
0006988992.tif 000002
【図２】
0006988992.tif 000003
【図３】
0006988992.tif 000004
【図４】
0006988992.tif 000005
【図５】
0006988992.tif 000006
【図６】
0006988992.tif 000007
【図７】
0006988992.tif 000008
【図８】
0006988992.tif 000009