特許 7565458 情報処理装置および鍵管理装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-10-02

(45)【発行日】2024-10-10

(54)【発明の名称】情報処理装置および鍵管理装置

(51)【国際特許分類】

   H04L 9/16 20060101AFI20241003BHJP

   H04L 9/32 20060101ALI20241003BHJP

   G06F 21/57 20130101ALI20241003BHJP

【ＦＩ】

H04L9/16

H04L9/32 200A

G06F21/57 370

【請求項の数】 8

(21)【出願番号】P 2023563517

(86)(22)【出願日】2022-08-12

(86)【国際出願番号】 JP2022030762

(87)【国際公開番号】W WO2023095394

(87)【国際公開日】2023-06-01

【審査請求日】2024-04-16

(31)【優先権主張番号】P 2021193151

(32)【優先日】2021-11-29

(33)【優先権主張国・地域又は機関】JP

(73)【特許権者】

【識別番号】509186579

【氏名又は名称】日立Ａｓｔｅｍｏ株式会社

(74)【代理人】

【識別番号】110002572

【氏名又は名称】弁理士法人平木国際特許事務所

(72)【発明者】

【氏名】森田 伸義

(72)【発明者】

【氏名】片岡 幹雄

(72)【発明者】

【氏名】藤井 康広

(72)【発明者】

【氏名】矢野 正

【審査官】平井 誠

(56)【参考文献】

【文献】菅島 健司，岡 デニス健五，カミーユ ヴィオム，セキュアかつ効率的な車載鍵管理の提案，ＳＣＩＳ２０１６［ＵＳＢ］，2016年01月19日

【文献】竹森 敬祐 ほか，車載ＥＣＵ向け暗号鍵管理，２０１７年 暗号と情報セキュリティシンポジウム（ＳＣＩＳ２０１７）予稿集，日本，2017年01月24日，p.1-7

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ ９／００－４０

Ｇ０９Ｃ １／００－ ５／００

Ｇ０６Ｆ ２１／００－８８

(57)【特許請求の範囲】

【請求項1】

プログラム検証用の鍵を用いて検証値を算出し、当該検証値が、予め記憶された検証期待値と一致しているか否かを検証する情報処理装置であって、
前記鍵を更新する鍵更新部と、
前記鍵更新部によって更新される鍵に対応する検証期待値を予め格納する記憶部と、
更新された前記鍵に基づいて算出された検証値を検証するときに、検証のために参照される前記記憶部内の前記検証期待値を、更新された前記鍵に対応する前記検証期待値に切り替える検証期待値切替部と、
を備えることを特徴とする情報処理装置。

【請求項2】

請求項１の情報処理装置であって、
前記記憶部は、前記更新される鍵に対応する検証期待値を予め複数格納し、
前記検証期待値切替部は、前記複数の検証期待値の中から未使用の検証期待値に切り替える、
ことを特徴とする情報処理装置。

【請求項3】

請求項１の情報処理装置であって、
前記記憶部は、前記更新される鍵に対応する検証期待値を予め複数格納し、
前記検証期待値切替部は、前記複数の検証期待値の中に未使用の前記検証期待値が無かったときに、使用済みの前記検証期待値の中から何れかの第二検証期待値に切り替える、ことを特徴とする情報処理装置。

【請求項4】

請求項１の情報処理装置であって、
前記切り替えの回数が所定回数に達する前に、使用中の前記検証期待値を含む検証期待値の更新が必要となるタイミングに関する情報を装置外に通知するプログラム更新依頼管理部と、をさらに備える
ことを特徴とする情報処理装置。

【請求項5】

請求項４の情報処理装置であって、
前記プログラム更新依頼管理部は未使用の前記検証期待値の残数が所定の値よりも少なくなったときに、使用中の前記検証期待値を含む検証期待値の更新が必要となるタイミングに関する情報を装置外に通知する、
ことを特徴とする情報処理装置。

【請求項6】

請求項４の情報処理装置であって、
前記検証期待値を使い切る前に、使用中の前記鍵と新たに生成された鍵に対応するそれぞれの検証期待値を備えたプログラムに更新するプログラム更新部と、
をさらに備えることを特徴とする情報処理装置。

【請求項7】

請求項１に記載の情報処理装置であって、
前記記憶部は、前記更新される鍵に対応する検証期待値を予め複数格納する、
ことを特徴とする情報処理装置。

【請求項8】

請求項１の情報処理装置に接続された鍵管理装置であって、
前記鍵に関する鍵マスタ情報を記憶する記憶部を有する、
ことを特徴とする鍵管理装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は情報処理装置及び鍵管理装置に関し、特にプログラム検証用鍵の更新にともなう検証期待値の切替方法に関する。

【背景技術】

【0002】

自動車、家電、医療機器等に搭載される組み込みシステムでは、攻撃者によって、不正にソフトウェアやファームウェアが書き換えられた場合、甚大な被害に繋がることが懸念されている。このような脅威への対策として、プログラム起動時に、改ざんされていないプログラムのみを起動できるプログラム検証が検討されている。

【0003】

プログラム検証の一手法として、特許文献１では、プログラム起動時に、検証対象となるプログラムと、暗号技術に基づく検証処理と、検証処理に用いる鍵とを用いて検証値を算出し、事前に算出していた検証期待値と一致するかどうかを検証する技術が開示されている。

【0004】

暗号技術では演算に使用する鍵が一度でも危殆化してしまうと、プログラム検証そのものの安全性を担保できなくなってしまう。鍵の危殆化リスクを低減する方法の一つとして、鍵を定期的に更新することにより、攻撃者に使用している鍵を特定されるリスクを低減する方法が考えられる。

【先行技術文献】

【特許文献】

【0005】

【文献】再公表２００９／０４４５３３号公報

【発明の概要】

【発明が解決しようとする課題】

【0006】

プログラム検証は、検証対象プログラムが同じであっても、鍵値が異なれば算出される検証値も異なる特性があるため、鍵を更新した場合は異なる検証期待値が必要となる。しかしながら、従来の技術では、鍵更新にともない、適切に検証期待値の切替をすることができない課題があった。

【0007】

特許文献１の技術によれば、検証対象となるプログラム、および当該プログラムの検証期待値を更新することが可能である。しかしながら、鍵を更新した直後は、更新後の鍵値と、当該鍵値に対応する検証期待値が一致しないため、プログラム検証で常に失敗し、復旧不可となる虞がある。

【0008】

これに対して、プログラム検証機能を無効化した後に、検証期待値を含むプログラムを更新し、当該検証期待値が更新された後に、再びプログラム検証機能を有効化させる方法が考えられる。しかし、プログラム検証機能を無効化する機能を備えることになるため、その機能自身が攻撃者に悪用される脆弱性になる虞がある。

【0009】

本発明は、以上の問題に鑑みなされたものであり、プログラム検証機能を無効化せずに、プログラム検証用鍵の更新に対応可能な情報処理装置を提供することを目的とする。

【課題を解決するための手段】

【0010】

本発明に係る情報処理装置の一例は、プログラム検証用の鍵を用いて検証値を算出し、当該検証値が、予め記憶された検証期待値と一致しているか否かを検証する情報処理装置であって、鍵を更新する鍵更新部と、鍵更新部によって更新される鍵に対応する検証期待値を予め格納する記憶部と、更新された鍵に基づいて算出された検証値を検証するときに、検証のために参照される記憶部内の検証期待値を、更新された鍵に対応する検証値に切り替える検証期待値切替部と、を備える。

【発明の効果】

【0011】

本発明に係る情報処理装置は、プログラム検証機能を無効化せずに、プログラム検証用鍵を更新することにより、長期間のライフサイクルに亘って高い安全性を提供することができる。
本発明に関連する更なる特徴は、本明細書の記述、添付図面から明らかになるものである。また、上記した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。

【図面の簡単な説明】

【0012】

【図1】本発明の一実施例に係る情報処理装置の構成を示す図。

【図2】鍵更新およびプログラム検証処理に関する概要処理シーケンスを示す図。

【図3】鍵更新の概要処理フローを示す図。

【図4】プログラム検証の概要処理フローを示す図。

【図5】鍵関連情報のデータ構造を示す図。

【図6】検証期待値情報のデータ構造を示す図。

【図7】参照先検証期待値情報のデータ構造を示す図。

【図8】検証範囲情報のデータ構造を示す図。

【図9】本発明の一実施例に係る鍵管理装置の構成を示す図。

【図10】鍵更新にともなう鍵および検証期待値生成の概要処理フローを示す図。

【図11】鍵マスタのデータ構造を示す図。

【発明を実施するための形態】

【0013】

以下、本発明の実施形態について、実施例を用い、図面を参照しながら詳細に説明する。

【0014】

［情報処理装置１］
まず、本発明の一実施例に係る情報処理装置１について説明する。
本実施例では、車載ネットワークに接続された情報処理装置を対象としたプログラム検証用鍵の更新方法の例を説明する。ただし、本発明の技術的思想は、この実施例に限定されるものではない。

【0015】

図１は、本実施例における情報処理装置１の構成を示す。情報処理装置１は、たとえば車両に搭載され、車両を制御する装置である。ただし、情報処理装置１は車両に搭載されないものであってもよく、車両以外の対象を制御する装置であってもよい。

【0016】

情報処理装置１は、通信バス２を介して他の情報処理装置１に接続されている。情報処理装置１は、複数の情報処理装置１に対して通信可能に接続される。また、前記情報処理装置１は、鍵を更新するための装置である鍵管理装置３と直接接続されてもよいし、ＤＬＣ（Ｄａｔａ Ｌｉｎｋ Ｃｏｕｐｌｅｒ）のようなインタフェースを経由して接続されてもよいし、前記情報処理装置１のいずれかを経由して接続されてもよい。本実施例では、一例として情報処理装置１と鍵管理装置３とが通信バス２を介して接続されている例を開示している。

【0017】

通信バス２は物理的には複数の通信バスを含んでもよく、各通信バスの規格はすべて同一でもよいし異なっていてもよい。これら通信バスの規格はＣＡＮ（登録商標）、ＬＩＮ（登録商標）、ＦｌｅｘＲａｙ（登録商標）、イーサネット（登録商標）などである。

【0018】

情報処理装置１は、不図示の演算手段および不図示の記憶手段を備える。演算手段はたとえばＣＰＵを備える。記憶手段はたとえば不揮発性メモリおよび揮発性メモリを備える。記憶手段に格納されたプログラムを演算手段が実行することにより、情報処理装置１は本明細書に記載される機能を実現する。

【0019】

たとえば情報処理装置１はその機能部として、鍵更新制御部１２、検証期待値切替部１３、プログラム検証部１４、プログラム実行制御部１５、プログラム更新部１６、プログラム更新依頼管理部１７を備える。本明細書において、ＣＰＵまたはこれらの機能部が実行する処理は、情報処理装置１が実行するということもできる。

【0020】

また、記憶手段は、記憶部１００を備える。記憶部１００は、全体が不揮発性であってもよいし、一部が揮発性であってもよい。また、情報処理装置１は、通信インタフェースであり通信に必要な演算を行う通信部１１を備える。

【0021】

図１に示す機能ブロック図は例示であり、機能の単位および名称はこれに限らない。たとえば、本実施例において検証期待値切替部１３が実現する機能は、図１に示す他の機能部によって実現されてもよく、図１に示さない機能部によって実現されてもよい。

【0022】

通信部１１は、通信バス２を介して情報処理装置１からのメッセージを受信するとともに、通信バス２を介して他の情報処理装置１や車外の装置に対してメッセージを送信する。

【0023】

鍵更新制御部１２は、情報処理装置１が鍵更新依頼を受けたときに、記憶部１００に格納する鍵を更新する。検証期待値切替部１３は、プログラム検証に使用する鍵に合わせて適切な検証期待値を設定する。プログラム検証部１４は、検証対象のプログラムに異常がないかを検証する。プログラム実行制御部１５は、前記プログラム検証部１４の検証結果に基づいて、プログラムの実行可否を制御する。プログラム更新部１６は、情報処理装置１に格納されているプログラムを新しいプログラムに更新する。プログラム更新依頼管理部１７は、通信部１１を用いてプログラム更新を依頼するメッセージを送信するタイミングを管理する。

【0024】

記憶部１００には、プログラム検証時に使用する鍵値を含む鍵関連情報１０１、プログラム検証に用いる複数の鍵を含む検証期待値情報１０２、プログラム検証の検証範囲を示す検証範囲情報１０３、プログラム検証の際に参照する期待値を設定する参照先検証期待値情報１０４が記憶される。

【0025】

記憶部１００についても同様に、図１に示す機能ブロック図は例示であり、機能の単位および名称はこれに限らない。たとえば、本実施例において参照先検証期待値情報１０４が保持する情報は、図１の記憶部１００に示す他の機能部によって保持されてもよく、図１の記憶部１００に示さない機能部によって保持されてもよい。

【0026】

図２は、情報処理装置１が鍵を更新し、鍵更新後にプログラムを検証してから実行するまでの処理を示すシーケンスである。以下に説明する各ステップの実行主体は、たとえば情報処理装置１の不図示のＣＰＵである。

【0027】

ステップ２０１では、情報処理装置１の通信部１１は、鍵管理装置３から鍵更新依頼を受信する。
ステップ２０２では、情報処理装置１の鍵更新制御部１２は上記ステップ２０１で受信した鍵更新依頼に関する通信データが正しいかどうかを検証する。

【0028】

ステップ２０３では、情報処理装置１の鍵更新制御部１２は更新対象の鍵値を、上記ステップ２０１で受信した新しい鍵値に書き換える。
ステップ２０４では、情報処理装置１の通信部１１は上記ステップ２０３で更新した鍵の更新結果を鍵管理装置３に送信する。

【0029】

ステップ２０５では、鍵管理装置３は上記ステップ２０４で情報処理装置１から受信した鍵更新結果に基づいて、正しく鍵を更新できたかを検証する。
ステップ２０６では、情報処理装置１の検証期待値切替部１３は鍵更新の有無を確認し、検証期待値を切り替える必要があるかを検証する。

【0030】

ステップ２０７では、情報処理装置１の検証期待値切替部１３は上記ステップ２０６で検証期待値を切り替える必要があると判定した際に、更新前の鍵が参照していた検証期待値から、更新後の鍵に適した検証期待値を参照先に切り替える。
ステップ２０８では、情報処理装置１のプログラム検証部１４は上記ステップ２０３で更新した鍵と、上記ステップ２０７で切り替えた検証期待値と、検証対象のプログラムに基づいて、プログラムの異常有無を検証する。

【0031】

ステップ２０９では、情報処理装置１のプログラム実行制御部１５は上記ステップ２０８で検証対象プログラムに異常が無いと判定した場合、当該プログラムを起動し、実行する。
以上のステップにより、情報処理装置１は、プログラム検証機能を無効化することなく、鍵を新しい鍵に更新できる。

【0032】

図３は、上記ステップ２０１からステップ２０５までの鍵更新に関する処理を示すフローチャートである。鍵更新に関する技術として、ＡＵＴＯＳＡＲが発行するＳｐｅｃｉｆｉｃａｔｉｏｎ ｏｆ Ｓｅｃｕｒｅ Ｈａｒｄｗａｒｅ Ｅｘｔｅｎｓｉｏｎｓ（ＳＨＥ）において、Ｍｅｍｏｒｙ Ｕｐｄａｔｅ Ｐｒｏｔｏｃｏｌ（ＭＵＰ）が公開されている。以下に説明する鍵更新は、ＳＨＥ／ＭＵＰを例に説明するが、他の鍵更新プロトコルを採用してもよい。

【0033】

ステップ３０１では、鍵更新制御部１２は鍵管理装置３から鍵更新依頼を受信する。例えば、鍵更新制御部１２は、ＳＨＥ／ＭＵＰが定めるＭ１、Ｍ２、Ｍ３フォーマットの通信データを受信する。

【0034】

ステップ３０２では、鍵更新制御部１２は上記ステップ３０１で受信した鍵更新依頼に関する通信データが正しいかどうかを検証する。例えば、上記ステップ３０１で受信したＭ３と、Ｍ１とＭ２と所定の鍵に基づいて算出したＡＥＳ－ＣＭＡＣの演算結果を比較し、一致していれば正しいと判定する。なお、所定の鍵として、初期値「０」を使用してもよいし、予め情報処理装置１と鍵管理装置３との間で共有している鍵値を用いてもよい。

【0035】

ステップ３０３では、鍵更新制御部１２は上記ステップ３０２の検証結果に基づいて、更新内容に不備がなければステップ３０４に進み、更新内容に不備があればステップ３０８に進む。

【0036】

ステップ３０４では、鍵更新制御部１２は上記ステップ３０１で受信した更新内容に基づいて、更新対象となる鍵を特定する。例えば、前記Ｍ１に含まれる更新対象鍵スロットＩＤに基づいて、更新対象となる鍵スロットＩＤを特定する。

【0037】

ステップ３０５では、鍵更新制御部１２は更新対象の鍵値を、受信した新しい鍵値に書き換える。例えば、上記ステップ３０１で受信したＭ２を所定の鍵を用いて復号し、Ｍ２に含まれる更新鍵を取得し、鍵関連情報１０１において、上記ステップ３０４で特定した鍵スロットＩＤに紐づく鍵を、前記更新鍵で書き換える。なお、所定の鍵として、初期値「０」を使用してもよいし、予め情報処理装置１と鍵管理装置３との間で共有している鍵値を用いてもよい。

【0038】

図５に、上記ステップ３０５において更新鍵を保管する鍵関連情報１０１のデータ構造を示す。鍵関連情報１０１は、鍵関連情報１０１に格納される各鍵を識別するための鍵スロットＩＤ１０１１と、鍵の値を示す鍵値１０１２と、鍵更新のたびにカウントアップする更新カウンタ１０１３からなる。なお、更新カウンタ１０１３の代わりに、鍵更新の有無を示すフラグを用いてもよく、鍵更新にともない変化する情報であればその他の方法でもよい。

【0039】

例えば、鍵更新制御部１２は上記ステップ３０４においてＭ１から更新対象となる鍵スロットＩＤとして「０ｘ０１」を取得している場合、鍵関連情報１０１の鍵スロットＩＤ１０１１が「０ｘ０１」に紐づく鍵値１０１２を、Ｍ２から復号して取得した更新鍵に書き換えるとともに、更新カウンタ１０１３のカウンタ値を「０ｘ０００００００１」から「０ｘ０００００００２」に更新する。

【0040】

ステップ３０６では、鍵更新制御部１２は鍵管理装置３に送信する鍵の更新結果を作成する。例えば、鍵更新制御部１２は、上記ステップ３０５で更新した鍵更新内容に関する情報を示すＭ４と、更新後の鍵と前記Ｍ４に基づいて算出したＡＥＳ－ＣＭＡＣの演算結果を示すＭ５を含む鍵更新結果情報を作成する。

【0041】

ここで、データＭ４は、Ｍ１と暗号化（鍵は更新鍵を元に生成した鍵）した更新カウンタ値を結合したデータであり、Ｍ１－Ｍ３の送信者が、情報処理装置１で正しくメモリスロットを更新出来たかどうかの確認に使用する。データＭ５は、Ｍ４のＣＭＡＣ認証値（鍵は更新鍵を元に生成した鍵）であり、Ｍ１－Ｍ３の送信者がＭ４の正当性確認に使用する。

【0042】

ステップ３０７では、鍵更新制御部１２は通信部１１を用いて、上記ステップ３０６で作成した鍵更新結果情報を鍵管理装置３に送信する。なお、鍵管理装置３は、情報処理装置１から受信した鍵更新結果に基づいて、正しく鍵を更新できたかを検証する。例えば、上記ステップ３０１で情報処理装置１に送信した更新鍵と本ステップ３０７で送られてくるＭ４とに基づいて算出したＡＥＳ－ＣＭＡＣの演算結果と、本ステップ３０７で送られてくるＭ５の値が一致していれば正しく鍵を更新することができたと判定する。
以上のステップにより、情報処理装置１は、プログラム検証用の鍵を、新しい鍵に安全に更新できる。

【0043】

図４は、上記ステップ２０６からステップ２０９までのプログラム検証に関する処理を示すフローチャートである。以下に説明するプログラム検証処理は、上記ステップ２０３の直後に実施してもよく、装置外からの指示を受信したタイミングで実施してもよく、再起動時や定期的なタイミングで実施してもよい。

【0044】

ステップ４０１では、検証期待値切替部１３は鍵が更新されたかどうかを検証する。例えば、更新カウンタ１０１３の前回カウンタ値と最新カウンタ値を備えておき、カウンタ値に差分があった場合に鍵が更新されたと判定してもよい。また、上記ステップ３０５において鍵更新時に更新した履歴情報をフラグ情報として持たせておくことで鍵が更新されたと判定してもよい。また、上記ステップ２０３の直後に実施する場合、鍵が更新されているものと判定してもよい。また、装置外からの指示を受けたときに、指示内容に従って鍵が更新されたかどうかを判定してもよい。その他、鍵が更新されたことが判別可能な方法を用いることで、鍵の更新有無を判定してもよい。

【0045】

ステップ４０２では、検証期待値切替部１３は上記ステップ４０１において、鍵が更新されたと判定した場合、ステップ４０３に進み、鍵が更新されていないと判定した場合、ステップ４０５に進む。

【0046】

ステップ４０３では、検証期待値切替部１３は検証期待値情報１０２の中から更新した鍵に適した新たな検証期待値を選定する。

【0047】

図６に、上記ステップ４０３において選定する検証期待値を保管する検証期待値情報１０２のデータ構造を示す。検証期待値情報１０２は、鍵関連情報１０１に格納される各鍵を識別する鍵スロットＩＤ１０２１と、プログラム検証に用いる鍵値に紐づく検証期待値と更新後の鍵値に紐づく検証期待値を格納する検証期待値１０２２と、各検証期待値が配置されるアドレス情報を示す配置アドレス１０２３と、検証期待値１０２２の使用状況を示す使用状況１０２４からなる。

【0048】

例えば、検証期待値切替部１３は、更新された鍵スロットＩＤ１０１１に該当する鍵スロットＩＤ１０２１に紐づく検証期待値１０２２の中から、使用状況１０２４が「使用中」となっている検証期待値１０２２が「検証期待値Ａ」よりも一段下の「検証期待値Ｂ」を選定する。使用状況１０２４が「使用中」となる検証期待値１０２２が「検証期待値Ｃ」となっている場合、「検証期待値Ａ」に戻してもよい。このとき、鍵が更新されるたびに、選定する検証期待値は「検証期待値Ａ→検証期待値Ｂ→検証期待値Ｃ→検証期待値Ａ→・・・」となる。なお、前記のように検証期待値の選定順を一定の順番で繰り返してもよいし、鍵値と検証期待値の紐づけ関係が担保されていれば、順不同でもよい。

【0049】

また、検証期待値切替部１３は、上記ステップ４０３より以前の段階において鍵更新の際に次回選定する検証期待値の指示を情報処理装置１の外部から受信しておいてもよい。また、検証期待値切替部１３は、更新カウンタ１０１３のカウンタ値に基づいて検証期待値を選定してもよい。例えば、更新カウンタの値「Ａ」と検証期待値１０２２に格納する検証期待値の合計数「ｎ＝３」において、「Ａ ｍｏｄ ｎ」の算出結果が「１」の場合、「検証期待値Ａ」を選定し、算出結果が「２」の場合、「検証期待値Ｂ」を選定し、算出結果が「０」の場合、「検証期待値Ｃ」を選定してもよい。このとき、鍵が更新されるたびに、選定する検証期待値は「検証期待値Ａ→検証期待値Ｂ→検証期待値Ｃ→検証期待値Ａ→・・・」となる。

【0050】

以上の場合において、更新した鍵値１０１２と選定する検証期待値１０２２の適した組合せを担保するために、鍵更新を実施する管理者が、鍵更新後に使用する検証期待値に適した鍵を新たな鍵として更新してもよい。また、情報処理装置１が装置外に対して、鍵更新後に使用する検証期待値の情報を通知し、前記通知結果に基づいて検証期待値と鍵が適切な組合せとなるように新たな対象の鍵を更新してもよい。ステップ４０４では、検証期待値切替部１３は上記ステップ４０３において選定した検証期待値を参照先検証期待値情報１０４に登録する。

【0051】

図７に、上記ステップ４０４において選定した検証期待値を登録する参照先検証期待値情報１０４のデータ構造を示す。参照先検証期待値情報１０４は、選定した検証期待値と紐づく鍵スロットを示す鍵スロットＩＤ１０４１と、プログラム検証で使用する参照先検証期待値１０４２からなる。なお、参照先検証期待値１０４２は、具体的な検証期待値でもよく、或いは上記ステップ４０３で選定した検証期待値が格納されるアドレス情報を登録してもよく、プログラム検証に用いる検証期待値を特定できればその他の方法を用いてもよい。例えば、検証期待値切替部１３は上記ステップ４０３において、鍵スロットＩＤ１０２１が「０ｘ０１」に紐づく検証期待値１０２２から「検証期待値Ｂ」を選定し、鍵スロットＩＤ１０４１が「０ｘ０１」となる参照先検証期待値１０４２の値を「検証期待値Ａ」から「検証期待値Ｂ」に変更する。

【0052】

ステップ４０５では、プログラム検証部１４はプログラム検証に用いる鍵を、鍵関連情報１０１の鍵値１０１２から取得する。

【0053】

ステップ４０６では、ステップ４０５で取得した鍵に対応する検証期待値を取得する。

【0054】

ステップ４０７では、プログラム検証部１４はプログラム検証の対象となるプログラムが格納される領域を、検証範囲情報１０３から取得する。

【0055】

図８に、上記ステップ４０７においてプログラム検証部１４が検証対象プログラムの格納領域を取得する検証範囲情報１０３のデータ構造を示す。検証範囲情報１０３は、プログラム検証に用いる鍵スロットを示す鍵スロットＩＤ１０３１と、検証対象プログラムを示す検証対象プログラム１０３２と、検証対象プログラムのうち検証対象となる範囲情報を示す検証範囲アドレス１０３３からなる。

【0056】

例えば、プログラム検証部１４は上記ステップ４０５で取得した鍵値１０１２の鍵スロットＩＤに該当する検証範囲アドレス１０３３を取得する。ステップ４０７では、プログラム検証部１４は上記ステップ４０６で取得した検証範囲アドレス１０３３が指定するプログラム情報を取得する。

【0057】

ステップ４０８では、プログラム検証部１４は上記ステップ４０５で取得した鍵値１０１２と、上記ステップ４０７で取得した検証対象プログラムに基づいて検証値を算出し、上記ステップ４０６で取得した検証期待値と一致するかどうかを検証し、一致した場合は鍵値１０１２や検証対象プログラムなどの検証対象に不備がないと判定し、一致しなかった場合は鍵値１０１２や検証対象プログラムなどの検証対象に不備があると判定する。なお、検証値として、ＤＳＡ、ＥＣＤＳＡ、ＲＳＡ等の公開鍵暗号技術を用いて生成した署名値でもよく、ＡＥＳ－ＣＭＡＣのような共通鍵暗号技術を用いて生成したＭＡＣ（Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）の値でもよく、ハッシュやチェックサムでもよい。

【0058】

ステップ４０９では、プログラム検証部１４は上記ステップ４０８において検証対象に不備がないと判定した場合、ステップ４１０に進み、検証対象に不備があると判定した場合、ステップ４１１に進む。
ステップ４１０では、プログラム実行制御部１５は上記ステップ４０８において検証されたプログラムを実行する。

【0059】

ステップ４１１では、プログラム実行制御部１５は所定のエラー処理を実行する。例えば、プログラムを停止させてもよく、一部の機能のみを有したプログラムのみを実行するのでもよい。

【0060】

以上のステップにより、情報処理装置１は、プログラム検証用の鍵が新しい鍵に更新されたとしても、プログラム検証機能の無効化やプログラム自体の更新を必要とせず、鍵更新前に使用していた検証期待値を更新後の鍵に適した検証期待値に切り替えることにより、正しくプログラム検証を継続できる。

【0061】

また、例えば、上記ステップ２０４において、情報処理装置１に搭載されるプログラム更新依頼管理部１７が鍵管理装置３に対して、未使用の検証期待値の数に基づいて、もしくは、切り替えの回数が所定の回数に達する前に、例えば検証期待値の残り個数が所定の数よりも少なくなった場合に、新たな検証期待値の束を含めたプログラムに更新するように依頼し、プログラム更新部１６を用いて新たな検証期待値１０２２を含むプログラムに更新することもできる。これにより、鍵更新にともなって使用済みとなる検証期待値が増加したとしても、常に未使用の鍵と検証期待値のペアを使用したプログラム検証を実現できるため、安全性を高めることができる。

【0062】

［鍵管理装置３］
次に、本発明の一実施例に係る鍵管理装置３について説明する。一実施例に係る鍵管理装置３は、通信バス２を介して情報処理装置１と接続されている。

【0063】

鍵管理装置３は、情報処理装置１との間で各種データの送受信を行う通信部３１を有する。通信部３１は、図２におけるステップ２０１で情報処理装置１に鍵更新依頼を送信し、またステップ２０４において情報処理装置１から鍵更新の結果通知を受信する。

【0064】

また、鍵管理装置３は、情報処理装置１の有する複数の検証期待値に対応する鍵を生成する鍵生成部３２を有する。鍵生成部３２は、将来利用する分も含めた鍵を生成し、このうち最初に利用する鍵を出荷工場で情報処理装置１に格納する。

【0065】

また、鍵管理装置３は、検証期待値生成部３３を有する。検証期待値生成部３３は、上記生成した鍵ごとに検証期待値を生成し、当該検証期待値を出荷工場で情報処理装置１に格納する。

【0066】

また、検証期待値更新依頼部３４は、検証期待値生成部３３が検証期待値を生成すると、情報処理装置１の記憶部１００に格納されている検証期待値の束を、新たな検証期待値の束に更新するように、情報処理装置１に依頼する。そして、情報処理装置１は、上記の検証期待値の更新依頼の受信に伴い、検証期待値を更新する。

【0067】

なお、上記では、鍵管理装置３が直接情報処理装置１に各種情報を送信する例を説明したが、これに限らず、情報処理装置１以外の装置に通知するようにしてもよい。例えば、不図示のプログラム更新管理システムに通知し、情報処理装置１のプログラム更新と一緒に、検証期待値を安全に更新するようにしてもよい。より好ましくは、更新プログラムの機密性や完全性を担保したプログラム更新技術を用いてもよい。

【0068】

また、鍵更新依頼部３５は、所定の期限までに、情報処理装置１に対して格納している鍵を新たな鍵に更新するように依頼するとともに、更新した検証期待値に対応する鍵を、鍵マスタ情報から検索して情報処理装置１に送信する。そして、鍵更新結果検証部３６は、鍵更新が正しく実施できているかどうかを検証する。

【0069】

図１１に、記憶部３７に格納された鍵マスタ情報３７１のデータ構造を示す。検証範囲情報１０３は、検証対象のプログラムが格納された製品に対応する製品ＩＤ３７１１、プログラム検証に用いる鍵スロットを示す鍵スロットＩＤ３７１２、及び鍵スロットＩＤ３７１２のそれぞれに格納される、世代ごとの鍵情報３７１３からなる。

【0070】

上記の鍵管理装置３によれば、予め複数の検証期待値に対応する鍵に関する鍵マスタ情報３７１を備えているため、検証期待値の更新の度に鍵を生成する必要がなくなり、演算負荷の軽減が可能になる。

【0071】

以上で説明した本発明の実施例によれば、以下の作用効果を奏する。
（１）本発明の一実施例に係る情報処理装置は、プログラム検証用の鍵を用いて検証値を算出し、当該検証値が、予め記憶された検証期待値と一致しているか否かを検証する情報処理装置であって、鍵を更新する鍵更新部と、鍵更新部によって更新される鍵に対応する検証期待値を予め格納する記憶部と、更新された鍵に基づいて算出された検証値を検証するときに、検証のために参照される記憶部内の検証期待値を、更新された鍵に対応する検証期待値に切り替える検証期待値切替部と、を備える。

【0072】

上記構成により、プログラム検証機能を無効化せずに、プログラム検証用鍵を更新することにより、長期間のライフサイクルに亘って高い安全性を提供することができる。

【0073】

（２）記憶部は、更新される鍵に対応する検証期待値を予め複数格納し、検証期待値切替部は、複数の検証期待値の中から未使用の検証期待値に切り替える。これにより、同じ検証期待値を複数回使用することを避け、常に新しい検証期待値及び対応する鍵を使用するため、より高い安全性を確保できる。

【0074】

（３）記憶部は、更新される鍵に対応する検証期待値を予め複数格納し、検証期待値切替部は、複数の検証期待値の中に未使用の検証期待値が無かったときに、使用済みの検証期待値の中から何れかの第二検証期待値に切り替える。これにより、記憶する検証期待値の個数を抑制することが可能になり、メモリ容量の削減が図れる。

【0075】

（４）切り替えの回数が所定回数に達する前に、使用中の検証期待値を含む検証期待値の更新が必要となるタイミングに関する情報を装置外に通知するプログラム更新依頼管理部と、をさらに備える。これにより、鍵更新にともなって使用済みとなる検証期待値が増加したとしても、常に未使用の鍵と検証期待値のペアを使用したプログラム検証を実現できるため、安全性を高めることができる。

【0076】

（５）プログラム更新依頼管理部は未使用の検証期待値の残数が所定の値よりも少なくなったときに、使用中の検証期待値を含む検証期待値の更新が必要となるタイミングに関する情報を装置外に通知する。これにより、（４）と同様に、安全性を高めることが可能になる。

【0077】

（６）検証値を使い切る前に、使用中の鍵と新たに生成された鍵に対応するそれぞれの検証期待値を備えたプログラムに更新するプログラム更新部と、をさらに備える。これにより、（４）による作用効果を確実に実現することが可能になる。

【0078】

（７）記憶部は、更新される鍵に対応する検証期待値を予め複数格納する。これにより、例えば鍵を３年に一度更新すると仮定した場合、検証期待値を６個程度予め記憶させておくことによって、製品のライフサイクル中に更新する必要がなくなり、メンテナンスの点でメリットが生じる。

【0079】

（８）また、本発明の一実施例に係る鍵管理装置は、（１）の情報処理装置に接続され、複数の鍵に関する鍵マスタ情報を記憶する記憶部を有する。これにより、予め複数の検証期待値に対応する鍵に関する鍵マスタ情報を備えているため、検証期待値の更新の度に鍵を生成する必要がなくなり、演算負荷の軽減が可能になる。

【0080】

なお、本発明は、上記の実施例に限定されるものではなく、様々な変形が可能である。例えば、上記の実施例は、本発明を分かりやすく説明するために詳細に説明したものであり、本発明は、必ずしも説明した全ての構成を備える態様に限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能である。また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、削除したり、他の構成を追加・置換したりすることが可能である。

【符号の説明】

【0081】

１ 情報処理装置、１２ 鍵更新制御部、１３ 検証期待値切替部、１６ プログラム更新部、１７ プログラム更新依頼管理部、１００ 記憶部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】