鍵管理方法
【課題】メモリカードなどの記録媒体における安全な鍵管理を実現する。
【解決手段】記録媒体（２０）において、ホスト装置（１０）との相互認証を経ずにアクセス可能な通常記憶領域（２１）および相互認証を経てアクセス可能な認証記憶領域（２２）のいずれにもＭＫＢが格納されていない場合、ホスト装置（１０）が有するＭＫＢ（１５１）を通常記憶領域（２１）および認証記憶領域（２２）に書き込む。
【解決手段】記録媒体（２０）において、ホスト装置（１０）との相互認証を経ずにアクセス可能な通常記憶領域（２１）および相互認証を経てアクセス可能な認証記憶領域（２２）のいずれにもＭＫＢが格納されていない場合、ホスト装置（１０）が有するＭＫＢ（１５１）を通常記憶領域（２１）および認証記憶領域（２２）に書き込む。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、鍵管理方法に関し、特に、コンテンツ鍵の生成および機器の無効化を行うためのＭＫＢ（Media Key Block）の管理方法に関する。
【背景技術】
【０００２】
近年、コンテンツの著作権保護の必要性が高まり、地上波デジタル放送やインターネットなどでは、鍵や権利情報を含んだコンテンツの放送や配信が行われるようになってきた。このようなコンテンツを記憶媒体に記録する際には、コンテンツを暗号化するとともに鍵や権利情報を安全に記録する必要がある。コンテンツの高画質化に伴い、コンテンツの暗号方式、鍵長および機器認証の方式などが複雑化し、また、鍵や権利情報の不正コピーが困難な仕組みが次々と導入されている。
【０００３】
これらの仕組みの一つに、鍵の暴露などにより不正使用される機器においてコンテンツの不正利用をできなくする機器無効化がある。さらに、記憶媒体に記録される機器無効化情報であるＭＫＢを、ネットワークや認証機器を通じて常に最新のものに保つ仕組みに拡張されている。そのため、機器と記憶媒体の間で常にＭＫＢのバージョンを確認し合い、ＭＫＢの共有や更新を行う必要がある。ＭＫＢ更新に伴う認証鍵やコンテンツ暗号鍵といった各種暗号鍵情報を、ユーザが意識することなく安全に更新または管理する仕組みが必要となってきている。現在では、ＡＡＣＳ（Advanced Access Content System）という規格に基づき、Blu-ray Disc（以後、ＢＤと略す）やＤＶＤ（Digital Versatile Disc）の著作権保護技術として適用されている。
【０００４】
ＤＶＤなどの光ディスクにおける鍵管理方法に関して、ＭＫＢ、タイトル鍵、Usage Ruleの権利情報のバックアップ機構を設け、さらに、該当するＭＫＢが存在しないブランクメディアに対して記録処理が発生しない場合にはＭＫＢを書き込まないことで処理の高速化を図っているものがある（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００７−３３４９３９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ＢＤなどの光ディスクでは、高画質コンテンツが記録されることを想定してあらかじめシステム領域にＭＫＢが書き込まれている。ディスクメディアのＭＫＢはユーザによって書き換えができないようになっているため、ＭＫＢの削除や改竄については想定する必要がなかった。
【０００７】
一方、高画質コンテンツの記録媒体としてＳＤ（Secure Digital）カードなどのメモリカードが注目されつつある。現在、メモリカードにおける著作権保護としてＣＰＲＭ（Content Protection for Recordable Media）が採用されているが、今後は光ディスクにおける著作権保護に採用されているような、より高度な著作権保護が求められる。例えば、過去の互換性を保ちつつ高画質記録用のアルゴリズムにも対応できるＭＫＢの拡張方法として、コンテンツの記録時にホスト機器から高画質記録に対応したＭＫＢを取得した上でコンテンツの暗号化を行うことが考えられる。
【０００８】
メモリカードにはホスト装置との相互認証を経ずにアクセス可能な通常記憶領域と相互認証を経てアクセス可能な認証記憶領域がある。通常記憶領域に格納されたＭＫＢは削除や改竄のおそれがある。ＭＫＢが削除されるとメモリカードに記録されているコンテンツの再生が不可能になる。また、ＭＫＢが改竄されると十分な著作権保護が確保できなくなる。かかる問題に鑑み、本発明は、メモリカードなどの記録媒体における安全な鍵管理を実現することを課題とする。
【課題を解決するための手段】
【０００９】
上記課題を解決するために本発明によって次のような手段を講じた。すなわち、ホスト装置との相互認証を経ずにアクセス可能な通常記憶領域と相互認証を経てアクセス可能な認証記憶領域とを有する記録媒体においてＭＫＢを管理する鍵管理方法であって、通常記憶領域および認証記憶領域のいずれにもＭＫＢが格納されていない場合、ホスト装置が有するＭＫＢを通常記憶領域および認証記憶領域に書き込むものとする。
【００１０】
これによると、ユーザが自由にアクセスすることのない認証記憶領域にＭＫＢのコピーが保存されるため、通常記憶領域のＭＫＢが削除されてもリカバリすることができ、また、通常記憶領域のＭＫＢが改竄されているか否かの検証も可能となる。
【００１１】
また、ホスト装置との相互認証を経ずにアクセス可能な通常記憶領域と相互認証を経てアクセス可能な認証記憶領域とを有する記録媒体においてＭＫＢを管理する鍵管理方法であって、通常記憶領域および認証記憶領域のいずれにもＭＫＢが格納されていない場合、ホスト装置が有するＭＫＢを通常記憶領域に書き込むとともに当該ＭＫＢの識別情報を認証記憶領域に書き込む、あるいは、ホスト装置が有するＭＫＢを通常記憶領域に書き込むとともに当該ＭＫＢの少なくとも一部についてのハッシュ値を算出して認証記憶領域に書き込むものとする。
【００１２】
これによると、認証記憶領域に書き込まれたＭＫＢ識別情報あるいはハッシュ値に基づいて、通常記憶領域のＭＫＢが改竄されているか否かを検証することができる。
【発明の効果】
【００１３】
本発明によると、メモリカードなどにおいてＭＫＢが削除された場合にリカバリすることができ、また、ＭＫＢが改竄されているか否かを検証することができる。これにより、メモリカードなどの記録媒体における安全な鍵管理が可能となる。
【図面の簡単な説明】
【００１４】
【図１】第１の実施形態に係る鍵管理システムの構成図である。
【図２】記録媒体へのＭＫＢの新規書き込み処理のフローチャートである。
【図３】図１の鍵管理システムにおけるＭＫＢ更新処理のフローチャートである。
【図４】第２の実施形態に係る鍵管理システムの構成図である。
【図５】記録媒体へのＭＫＢの新規書き込み処理のフローチャートである。
【図６】図４の鍵管理システムにおけるＭＫＢ更新処理のフローチャートである。
【図７】第３の実施形態に係る鍵管理システムの構成図である。
【図８】記録媒体へのＭＫＢの新規書き込み処理のフローチャートである。
【図９】図７の鍵管理システムにおけるＭＫＢ更新処理のフローチャートである。
【図１０】鍵管理システムの応用例を示す図である。
【発明を実施するための形態】
【００１５】
（第１の実施形態）
図１は、第１の実施形態に係る鍵管理システムの構成を示す。当該システムは、携帯電話機などの各種民生機器にあたるホスト装置１０と、ＳＤメモリカードなどの各種メモリカードにあたる記録媒体２０から構成される。
【００１６】
ホスト装置１０は、ハードウェア（以後、ＨＷと略す）やソフトウェア（以後、ＳＷと略す）制御により認証鍵やコンテンツ暗号鍵や暗号化コンテンツなどの暗復号を行う暗号処理部１１と、復号したコンテンツを表示するディスプレイや音声を出力するスピーカなどにあたる出力部１２と、電源を供給するバッテリなどにあたる電源部１３と、ＨＷやＳＷ制御により各部のシステム制御を行う制御部１４と、鍵などの秘匿情報を格納するメモリ領域１５とから構成される。メモリ領域１５には、ＭＫＢ更新を行う元となるＭＫＢ１５１と、記録媒体２０との認証で使用する機器固有鍵１５２と、記録媒体２０との機器認証によって生成される認証鍵１５３が格納される。
【００１７】
記録媒体２０は、ホスト装置１０との相互認証を経ずにアクセス可能な通常記憶領域２１と、相互認証を経てアクセス可能な認証記憶領域２２と、外部装置との入出力や通常記憶領域２１および認証記憶領域２２へのアクセス制御を行う制御部２３とから構成される。通常記憶領域２１には、機器無効化情報であるＭＫＢ２１１と、コンテンツ暗号鍵で暗号化された暗号化コンテンツ群２２２が格納される。認証記憶領域２２には、ＭＫＢ２１１のコピーとして保持されるＭＫＢ２２１と、コンテンツを暗号化するコンテンツ暗号鍵２２２と、コンテンツプロバイダが定義したコピー回数などの権利情報を暗号化コンテンツ毎に管理する権利情報管理群２２３が格納される。
【００１８】
なお、例えばＡＡＣＳに対応するＭＫＢのファイルサイズは数メガバイトに及ぶため、認証記憶領域２２に十分大きな記憶容量を確保する必要がある。また、認証記憶領域２２のＭＫＢ２２１は下記のバックアップおよびベリファイの目的で使用されるものである。したがって、ＭＫＢ算出処理などでは通常記憶領域２１のＭＫＢ２１１を用いることを想定している。
【００１９】
記録媒体２０へのＭＫＢの新規書き込み処理について図２のフローチャートを参照しながら説明する。この処理は、記録媒体２０が出荷状態のままでＭＫＢ２１１を保持しておらず、記録媒体２０にコンテンツを初めて記録する場合などに発生する。ホスト装置１０が保持するＭＫＢ１５１を記録媒体２０の通常記憶領域２１にコピーしてＭＫＢ２１１を作成する（Ｓ１１）。ただし、ホスト装置１０から提供されるＭＫＢ１５１は改竄されていない正当なものであることを前提とする。通常記憶領域２１に書き込んだＭＫＢ２１１に対してＭＫＢ検証を行って正当性を確認する（Ｓ１２）。正当性が確認できたら、ＭＫＢ２１１を記録媒体２０の認証記憶領域２２にコピーしてＭＫＢ２２１を作成する（Ｓ１３）。そして、正当性が確認できたＭＫＢ２１１から算出した鍵を用いてコンテンツの暗号処理を行う（Ｓ１４）。
【００２０】
なお、ＭＫＢ２２１は暗号化コンテンツの鍵算出に必須ではないため、ステップＳ１３は必ずしもステップＳ１２とステップＳ１４の間で実施する必要はない。ステップＳ１３は鍵管理システムにおいてＭＫＢ更新処理が行われていないようなアイドル時に実施してもよい。
【００２１】
次に、本実施形態に係る鍵管理システムにおけるＭＫＢ更新処理について図３のフローチャートを参照しながら説明する。まず、認証記憶領域２２にＭＫＢ２２１が存在するか否かを確認する（Ｓ２１）。認証記憶領域２２にＭＫＢ２２１が存在しなければ（Ｓ２１のＮＯ）、図２のフローに従って処理されていないため、ここでの特別なＭＫＢ更新処理は行わずに、別途、ＡＡＣＳなどの規格で定義されたＭＫＢ更新処理を行う。例えば、ＡＡＣＳでは、ホスト装置１０および記録媒体２０のそれぞれに格納されたＭＫＢのバージョンを比較し、古いバージョンを新しいバージョンに書き換えることでＭＫＢ更新を行うことが規定されている。
【００２２】
認証記憶領域２２にＭＫＢ２２１が存在すれば（Ｓ２１のＹＥＳ）、通常記憶領域２１にＭＫＢ２１１が存在するか否かを確認する（Ｓ２２）。通常記憶領域２１にＭＫＢ２１１が存在しなければ（Ｓ２２のＮＯ）、ユーザが誤って削除したと考えられるためリカバリ処理を行う。具体的には、認証記憶領域２２のＭＫＢ２２１を通常記憶領域２１にコピーしてＭＫＢ２１１を作成する（Ｓ２３）。一方、通常記憶領域２１にＭＫＢ２１１が存在すれば（Ｓ２２のＹＥＳ）、改竄されていないことを検証するベリファイ処理を行う。具体的には、ＭＫＢ２１１とＭＫＢ２２１との同一性を検証し（Ｓ２４）、同一でない場合（Ｓ２４のＮＯ）、ＭＫＢ整合エラーを通知する（Ｓ２５）。一方、同一である場合（Ｓ２４のＹＥＳ）およびステップＳ２３の実施後に通常記憶領域２１のＭＫＢ２１１とホスト装置１０のＭＫＢ１５１との間でＭＫＢ更新処理を実施する（Ｓ２６）。このＭＫＢ更新処理については、例えば、ＡＡＣＳで定義されている鍵変換など処理が該当するが、詳細説明は省略する。
【００２３】
以上、本実施形態によると、記録媒体２０の通常記憶領域２１に格納されたＭＫＢ２１１がユーザによって誤って削除されてもリカバリすることができ、また、ＭＫＢ２１１が改竄されているか否かを検証することができる。
【００２４】
（第２の実施形態）
図４は、第２の実施形態に係る鍵管理システムの構成を示す。当該システムは第１の実施形態に係る鍵管理システムと基本的に同じであり、記録媒体２０の認証記憶領域２２にＭＫＢ２２１を格納する代わりにＭＫＢ識別情報２２４を格納する点が異なる。ＭＫＢ識別情報２２４は、ＭＫＢ２１１のType and Version Recordに含まれるバージョン情報などである。以下、第１の実施形態と異なる点について説明する。
【００２５】
記録媒体２０へのＭＫＢの新規書き込み処理について図５のフローチャートを参照しながら説明する。上述したステップＳ１１を実施すると、通常記憶領域２１に書き込んだＭＫＢ２１１に対してＭＫＢ検証を行って正当性を確認するとともに識別情報を抽出する（Ｓ１２Ａ）。正当性が確認できたら、抽出した識別情報を記録媒体２０の認証記憶領域２２に書き込んでＭＫＢ識別情報２２４を作成する（Ｓ１３Ａ）。ステップＳ１４は上述したとおりである。
【００２６】
なお、ＭＫＢ識別情報２２４は暗号化コンテンツの鍵算出に必須ではないため、ステップＳ１３Ａは必ずしもステップＳ１２とステップＳ１４の間で実施する必要はない。ステップＳ１３Ａは鍵管理システムにおいてＭＫＢ更新処理が行われていないようなアイドル時に実施してもよい。
【００２７】
次に、本実施形態に係る鍵管理システムにおけるＭＫＢ更新処理について図６のフローチャートを参照しながら説明する。まず、認証記憶領域２２にＭＫＢ識別情報２２４が存在するか否かを確認する（Ｓ３１）。認証記憶領域２２にＭＫＢ識別２２４が存在しなければ（Ｓ３１のＮＯ）、図５のフローに従って処理されていないため、ここでの特別なＭＫＢ更新処理は行わずに、別途、ＡＡＣＳなどの規格で定義されたＭＫＢ更新処理を行う。
【００２８】
認証記憶領域２２にＭＫＢ識別情報２２４が存在すれば（Ｓ３１のＹＥＳ）、通常記憶領域２１のＭＫＢ２１１の識別情報を取得する（Ｓ３２）。そして、取得した識別情報と認証記憶領域２２のＭＫＢ識別情報２２４との同一性を検証し（Ｓ３３）、これらが同一でなければ（Ｓ３３のＮＯ）、TYPE AND VERSION NUMBERエラーを通知する（Ｓ３４）。一方、これらが同一であれば（Ｓ３３のＹＥＳ）、ホスト装置１０のＭＫＢ１５１と通常記憶領域２１のＭＫＢ２１１とでバージョン比較を行う（Ｓ３５）。通常記憶領域２１のＭＫＢ２１１の方が新しい場合、ホスト装置１０のＭＫＢ１５１を記録媒体２０のＭＫＢ２１１で置き換える（Ｓ３６）。一方、ホスト装置１０のＭＫＢ１５１の方が新しい場合、通常記憶領域２１のＭＫＢ２１１とホスト装置１０のＭＫＢ１５１との間でＭＫＢ更新処理を実施する（Ｓ３７）。バージョンが同一であればＭＫＢ更新処理は不要である。
【００２９】
以上、本実施形態によると、記録媒体２０の認証記憶領域２２の記憶容量が小さいために通常記憶領域２１のＭＫＢ２１１のコピーを格納できない場合であっても、ＭＫＢ識別情報２２４を用いて、通常記憶領域２１のＭＫＢ２１１について過去にリボークされたＭＫＢに差し換えるなど（ＭＫＢのダウンバージョン化）の改竄がされているか否かを検証することができる。
【００３０】
なお、ＭＫＢ識別情報２２４は、Type and Version Recordに限られず、ＭＫＢを識別できるものであればどのようなものでもよいが、Type and Version RecordはＭＫＢの先頭レコードに置かれているため抽出が容易である。
【００３１】
（第３の実施形態）
図７は、第３の実施形態に係る鍵管理システムの構成を示す。当該システムは第１および第２の実施形態に係る鍵管理システムと基本的に同じであり、記録媒体２０の認証記憶領域２２にＭＫＢ２２１あるいはＭＫＢ識別情報２２４を格納する代わりにハッシュ値２２５を格納する点が異なる。ハッシュ値２２５は、ＭＫＢ２１１の全部または一部から算出されたハッシュ値である。以下、第１および第２の実施形態と異なる点について説明する。
【００３２】
記録媒体２０へのＭＫＢの新規書き込み処理について図８のフローチャートを参照しながら説明する。上述したステップＳ１１を実施すると、通常記憶領域２１に書き込んだＭＫＢ２１１に対してＭＫＢ検証を行って正当性を確認するとともにハッシュ値を算出する（Ｓ１２Ｂ）。正当性が確認できたら、算出したハッシュ値を記録媒体２０の認証記憶領域２２に書き込んでハッシュ値２２５を作成する（Ｓ１３Ｂ）。ステップＳ１４は上述したとおりである。
【００３３】
なお、ハッシュ値２２５は暗号化コンテンツの鍵算出に必須ではないため、ステップＳ１３Ｂは必ずしもステップＳ１２とステップＳ１４の間で実施する必要はない。ステップＳ１３Ｂは鍵管理システムにおいてＭＫＢ更新処理が行われていないようなアイドル時に実施してもよい。
【００３４】
次に、本実施形態に係る鍵管理システムにおけるＭＫＢ更新処理について図９のフローチャートを参照しながら説明する。まず、認証記憶領域２２にハッシュ値２２５が存在するか否かを確認する（Ｓ３１Ａ）。認証記憶領域２２にハッシュ値２２５が存在しなければ（Ｓ３１ＡのＮＯ）、図８のフローに従って処理されていないため、ここでの特別なＭＫＢ更新処理は行わずに、別途、ＡＡＣＳなどの規格で定義されたＭＫＢ更新処理を行う。
【００３５】
認証記憶領域２２にハッシュ値２２５が存在すれば（Ｓ３１ＡのＹＥＳ）、通常記憶領域２１のＭＫＢ２１１のハッシュ値を算出する（Ｓ３２Ａ）。そして、算出したハッシュ値と認証記憶領域２２のハッシュ値２２５との同一性を検証し（Ｓ３３）、これらが同一でなければ（Ｓ３３のＮＯ）、ハッシュ値エラーを通知する（Ｓ３４Ａ）。一方、これらが同一であれば（Ｓ３３ＡのＹＥＳ）、通常記憶領域２１のＭＫＢ２１１とホスト装置１０のＭＫＢ１５１との間でＭＫＢ更新処理を実施する（Ｓ３７）。
【００３６】
以上、本実施形態によると、規格で定められたＭＫＢ検証で必要となる楕円暗号などの計算時間のかかる処理を行うことなく同等の正当性を確保することができる。
【００３７】
なお、ハッシュ値算出のアルゴリズムに制限はない。ＨＷで実装された暗号エンジンなどを用いて演算することにより、ＭＫＢ検証の高速化を図ってもよい。
【００３８】
（応用例）
図１０は、鍵管理システムの応用例を示す。上記の各実施形態に係るホスト装置１０は、テレビジョン装置１０１、携帯電話機１０２、レコーダ１０３、ビューア（画像＆音声出力モバイル機器）１０４、デジタルスチルカメラ１０５などのさまざまな民生機器として実現することができる。そして、これら機器に挿入されたＳＤカードなどの記録媒体２０にデジタル放送やインターネット配信の高画質コンテンツが記録される。
【産業上の利用可能性】
【００３９】
本発明に係る鍵管理方法は、記録媒体における安全な鍵管理が可能であるため、メモリカードなどにおけるＭＫＢの管理に有用である。
【符号の説明】
【００４０】
１０ ホスト装置
１５１ ＭＫＢ（ホスト装置が有するＭＫＢ）
２０ 記録媒体
２１ 通常記憶領域
２１１ ＭＫＢ（通常記憶領域に格納されているＭＫＢ）
２２ 認証記憶領域
２２１ ＭＫＢ（認証記憶領域に格納されているＭＫＢ）
２２４ ＭＫＢ識別情報
２２５ ハッシュ値
【技術分野】
【０００１】
本発明は、鍵管理方法に関し、特に、コンテンツ鍵の生成および機器の無効化を行うためのＭＫＢ（Media Key Block）の管理方法に関する。
【背景技術】
【０００２】
近年、コンテンツの著作権保護の必要性が高まり、地上波デジタル放送やインターネットなどでは、鍵や権利情報を含んだコンテンツの放送や配信が行われるようになってきた。このようなコンテンツを記憶媒体に記録する際には、コンテンツを暗号化するとともに鍵や権利情報を安全に記録する必要がある。コンテンツの高画質化に伴い、コンテンツの暗号方式、鍵長および機器認証の方式などが複雑化し、また、鍵や権利情報の不正コピーが困難な仕組みが次々と導入されている。
【０００３】
これらの仕組みの一つに、鍵の暴露などにより不正使用される機器においてコンテンツの不正利用をできなくする機器無効化がある。さらに、記憶媒体に記録される機器無効化情報であるＭＫＢを、ネットワークや認証機器を通じて常に最新のものに保つ仕組みに拡張されている。そのため、機器と記憶媒体の間で常にＭＫＢのバージョンを確認し合い、ＭＫＢの共有や更新を行う必要がある。ＭＫＢ更新に伴う認証鍵やコンテンツ暗号鍵といった各種暗号鍵情報を、ユーザが意識することなく安全に更新または管理する仕組みが必要となってきている。現在では、ＡＡＣＳ（Advanced Access Content System）という規格に基づき、Blu-ray Disc（以後、ＢＤと略す）やＤＶＤ（Digital Versatile Disc）の著作権保護技術として適用されている。
【０００４】
ＤＶＤなどの光ディスクにおける鍵管理方法に関して、ＭＫＢ、タイトル鍵、Usage Ruleの権利情報のバックアップ機構を設け、さらに、該当するＭＫＢが存在しないブランクメディアに対して記録処理が発生しない場合にはＭＫＢを書き込まないことで処理の高速化を図っているものがある（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００７−３３４９３９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ＢＤなどの光ディスクでは、高画質コンテンツが記録されることを想定してあらかじめシステム領域にＭＫＢが書き込まれている。ディスクメディアのＭＫＢはユーザによって書き換えができないようになっているため、ＭＫＢの削除や改竄については想定する必要がなかった。
【０００７】
一方、高画質コンテンツの記録媒体としてＳＤ（Secure Digital）カードなどのメモリカードが注目されつつある。現在、メモリカードにおける著作権保護としてＣＰＲＭ（Content Protection for Recordable Media）が採用されているが、今後は光ディスクにおける著作権保護に採用されているような、より高度な著作権保護が求められる。例えば、過去の互換性を保ちつつ高画質記録用のアルゴリズムにも対応できるＭＫＢの拡張方法として、コンテンツの記録時にホスト機器から高画質記録に対応したＭＫＢを取得した上でコンテンツの暗号化を行うことが考えられる。
【０００８】
メモリカードにはホスト装置との相互認証を経ずにアクセス可能な通常記憶領域と相互認証を経てアクセス可能な認証記憶領域がある。通常記憶領域に格納されたＭＫＢは削除や改竄のおそれがある。ＭＫＢが削除されるとメモリカードに記録されているコンテンツの再生が不可能になる。また、ＭＫＢが改竄されると十分な著作権保護が確保できなくなる。かかる問題に鑑み、本発明は、メモリカードなどの記録媒体における安全な鍵管理を実現することを課題とする。
【課題を解決するための手段】
【０００９】
上記課題を解決するために本発明によって次のような手段を講じた。すなわち、ホスト装置との相互認証を経ずにアクセス可能な通常記憶領域と相互認証を経てアクセス可能な認証記憶領域とを有する記録媒体においてＭＫＢを管理する鍵管理方法であって、通常記憶領域および認証記憶領域のいずれにもＭＫＢが格納されていない場合、ホスト装置が有するＭＫＢを通常記憶領域および認証記憶領域に書き込むものとする。
【００１０】
これによると、ユーザが自由にアクセスすることのない認証記憶領域にＭＫＢのコピーが保存されるため、通常記憶領域のＭＫＢが削除されてもリカバリすることができ、また、通常記憶領域のＭＫＢが改竄されているか否かの検証も可能となる。
【００１１】
また、ホスト装置との相互認証を経ずにアクセス可能な通常記憶領域と相互認証を経てアクセス可能な認証記憶領域とを有する記録媒体においてＭＫＢを管理する鍵管理方法であって、通常記憶領域および認証記憶領域のいずれにもＭＫＢが格納されていない場合、ホスト装置が有するＭＫＢを通常記憶領域に書き込むとともに当該ＭＫＢの識別情報を認証記憶領域に書き込む、あるいは、ホスト装置が有するＭＫＢを通常記憶領域に書き込むとともに当該ＭＫＢの少なくとも一部についてのハッシュ値を算出して認証記憶領域に書き込むものとする。
【００１２】
これによると、認証記憶領域に書き込まれたＭＫＢ識別情報あるいはハッシュ値に基づいて、通常記憶領域のＭＫＢが改竄されているか否かを検証することができる。
【発明の効果】
【００１３】
本発明によると、メモリカードなどにおいてＭＫＢが削除された場合にリカバリすることができ、また、ＭＫＢが改竄されているか否かを検証することができる。これにより、メモリカードなどの記録媒体における安全な鍵管理が可能となる。
【図面の簡単な説明】
【００１４】
【図１】第１の実施形態に係る鍵管理システムの構成図である。
【図２】記録媒体へのＭＫＢの新規書き込み処理のフローチャートである。
【図３】図１の鍵管理システムにおけるＭＫＢ更新処理のフローチャートである。
【図４】第２の実施形態に係る鍵管理システムの構成図である。
【図５】記録媒体へのＭＫＢの新規書き込み処理のフローチャートである。
【図６】図４の鍵管理システムにおけるＭＫＢ更新処理のフローチャートである。
【図７】第３の実施形態に係る鍵管理システムの構成図である。
【図８】記録媒体へのＭＫＢの新規書き込み処理のフローチャートである。
【図９】図７の鍵管理システムにおけるＭＫＢ更新処理のフローチャートである。
【図１０】鍵管理システムの応用例を示す図である。
【発明を実施するための形態】
【００１５】
（第１の実施形態）
図１は、第１の実施形態に係る鍵管理システムの構成を示す。当該システムは、携帯電話機などの各種民生機器にあたるホスト装置１０と、ＳＤメモリカードなどの各種メモリカードにあたる記録媒体２０から構成される。
【００１６】
ホスト装置１０は、ハードウェア（以後、ＨＷと略す）やソフトウェア（以後、ＳＷと略す）制御により認証鍵やコンテンツ暗号鍵や暗号化コンテンツなどの暗復号を行う暗号処理部１１と、復号したコンテンツを表示するディスプレイや音声を出力するスピーカなどにあたる出力部１２と、電源を供給するバッテリなどにあたる電源部１３と、ＨＷやＳＷ制御により各部のシステム制御を行う制御部１４と、鍵などの秘匿情報を格納するメモリ領域１５とから構成される。メモリ領域１５には、ＭＫＢ更新を行う元となるＭＫＢ１５１と、記録媒体２０との認証で使用する機器固有鍵１５２と、記録媒体２０との機器認証によって生成される認証鍵１５３が格納される。
【００１７】
記録媒体２０は、ホスト装置１０との相互認証を経ずにアクセス可能な通常記憶領域２１と、相互認証を経てアクセス可能な認証記憶領域２２と、外部装置との入出力や通常記憶領域２１および認証記憶領域２２へのアクセス制御を行う制御部２３とから構成される。通常記憶領域２１には、機器無効化情報であるＭＫＢ２１１と、コンテンツ暗号鍵で暗号化された暗号化コンテンツ群２２２が格納される。認証記憶領域２２には、ＭＫＢ２１１のコピーとして保持されるＭＫＢ２２１と、コンテンツを暗号化するコンテンツ暗号鍵２２２と、コンテンツプロバイダが定義したコピー回数などの権利情報を暗号化コンテンツ毎に管理する権利情報管理群２２３が格納される。
【００１８】
なお、例えばＡＡＣＳに対応するＭＫＢのファイルサイズは数メガバイトに及ぶため、認証記憶領域２２に十分大きな記憶容量を確保する必要がある。また、認証記憶領域２２のＭＫＢ２２１は下記のバックアップおよびベリファイの目的で使用されるものである。したがって、ＭＫＢ算出処理などでは通常記憶領域２１のＭＫＢ２１１を用いることを想定している。
【００１９】
記録媒体２０へのＭＫＢの新規書き込み処理について図２のフローチャートを参照しながら説明する。この処理は、記録媒体２０が出荷状態のままでＭＫＢ２１１を保持しておらず、記録媒体２０にコンテンツを初めて記録する場合などに発生する。ホスト装置１０が保持するＭＫＢ１５１を記録媒体２０の通常記憶領域２１にコピーしてＭＫＢ２１１を作成する（Ｓ１１）。ただし、ホスト装置１０から提供されるＭＫＢ１５１は改竄されていない正当なものであることを前提とする。通常記憶領域２１に書き込んだＭＫＢ２１１に対してＭＫＢ検証を行って正当性を確認する（Ｓ１２）。正当性が確認できたら、ＭＫＢ２１１を記録媒体２０の認証記憶領域２２にコピーしてＭＫＢ２２１を作成する（Ｓ１３）。そして、正当性が確認できたＭＫＢ２１１から算出した鍵を用いてコンテンツの暗号処理を行う（Ｓ１４）。
【００２０】
なお、ＭＫＢ２２１は暗号化コンテンツの鍵算出に必須ではないため、ステップＳ１３は必ずしもステップＳ１２とステップＳ１４の間で実施する必要はない。ステップＳ１３は鍵管理システムにおいてＭＫＢ更新処理が行われていないようなアイドル時に実施してもよい。
【００２１】
次に、本実施形態に係る鍵管理システムにおけるＭＫＢ更新処理について図３のフローチャートを参照しながら説明する。まず、認証記憶領域２２にＭＫＢ２２１が存在するか否かを確認する（Ｓ２１）。認証記憶領域２２にＭＫＢ２２１が存在しなければ（Ｓ２１のＮＯ）、図２のフローに従って処理されていないため、ここでの特別なＭＫＢ更新処理は行わずに、別途、ＡＡＣＳなどの規格で定義されたＭＫＢ更新処理を行う。例えば、ＡＡＣＳでは、ホスト装置１０および記録媒体２０のそれぞれに格納されたＭＫＢのバージョンを比較し、古いバージョンを新しいバージョンに書き換えることでＭＫＢ更新を行うことが規定されている。
【００２２】
認証記憶領域２２にＭＫＢ２２１が存在すれば（Ｓ２１のＹＥＳ）、通常記憶領域２１にＭＫＢ２１１が存在するか否かを確認する（Ｓ２２）。通常記憶領域２１にＭＫＢ２１１が存在しなければ（Ｓ２２のＮＯ）、ユーザが誤って削除したと考えられるためリカバリ処理を行う。具体的には、認証記憶領域２２のＭＫＢ２２１を通常記憶領域２１にコピーしてＭＫＢ２１１を作成する（Ｓ２３）。一方、通常記憶領域２１にＭＫＢ２１１が存在すれば（Ｓ２２のＹＥＳ）、改竄されていないことを検証するベリファイ処理を行う。具体的には、ＭＫＢ２１１とＭＫＢ２２１との同一性を検証し（Ｓ２４）、同一でない場合（Ｓ２４のＮＯ）、ＭＫＢ整合エラーを通知する（Ｓ２５）。一方、同一である場合（Ｓ２４のＹＥＳ）およびステップＳ２３の実施後に通常記憶領域２１のＭＫＢ２１１とホスト装置１０のＭＫＢ１５１との間でＭＫＢ更新処理を実施する（Ｓ２６）。このＭＫＢ更新処理については、例えば、ＡＡＣＳで定義されている鍵変換など処理が該当するが、詳細説明は省略する。
【００２３】
以上、本実施形態によると、記録媒体２０の通常記憶領域２１に格納されたＭＫＢ２１１がユーザによって誤って削除されてもリカバリすることができ、また、ＭＫＢ２１１が改竄されているか否かを検証することができる。
【００２４】
（第２の実施形態）
図４は、第２の実施形態に係る鍵管理システムの構成を示す。当該システムは第１の実施形態に係る鍵管理システムと基本的に同じであり、記録媒体２０の認証記憶領域２２にＭＫＢ２２１を格納する代わりにＭＫＢ識別情報２２４を格納する点が異なる。ＭＫＢ識別情報２２４は、ＭＫＢ２１１のType and Version Recordに含まれるバージョン情報などである。以下、第１の実施形態と異なる点について説明する。
【００２５】
記録媒体２０へのＭＫＢの新規書き込み処理について図５のフローチャートを参照しながら説明する。上述したステップＳ１１を実施すると、通常記憶領域２１に書き込んだＭＫＢ２１１に対してＭＫＢ検証を行って正当性を確認するとともに識別情報を抽出する（Ｓ１２Ａ）。正当性が確認できたら、抽出した識別情報を記録媒体２０の認証記憶領域２２に書き込んでＭＫＢ識別情報２２４を作成する（Ｓ１３Ａ）。ステップＳ１４は上述したとおりである。
【００２６】
なお、ＭＫＢ識別情報２２４は暗号化コンテンツの鍵算出に必須ではないため、ステップＳ１３Ａは必ずしもステップＳ１２とステップＳ１４の間で実施する必要はない。ステップＳ１３Ａは鍵管理システムにおいてＭＫＢ更新処理が行われていないようなアイドル時に実施してもよい。
【００２７】
次に、本実施形態に係る鍵管理システムにおけるＭＫＢ更新処理について図６のフローチャートを参照しながら説明する。まず、認証記憶領域２２にＭＫＢ識別情報２２４が存在するか否かを確認する（Ｓ３１）。認証記憶領域２２にＭＫＢ識別２２４が存在しなければ（Ｓ３１のＮＯ）、図５のフローに従って処理されていないため、ここでの特別なＭＫＢ更新処理は行わずに、別途、ＡＡＣＳなどの規格で定義されたＭＫＢ更新処理を行う。
【００２８】
認証記憶領域２２にＭＫＢ識別情報２２４が存在すれば（Ｓ３１のＹＥＳ）、通常記憶領域２１のＭＫＢ２１１の識別情報を取得する（Ｓ３２）。そして、取得した識別情報と認証記憶領域２２のＭＫＢ識別情報２２４との同一性を検証し（Ｓ３３）、これらが同一でなければ（Ｓ３３のＮＯ）、TYPE AND VERSION NUMBERエラーを通知する（Ｓ３４）。一方、これらが同一であれば（Ｓ３３のＹＥＳ）、ホスト装置１０のＭＫＢ１５１と通常記憶領域２１のＭＫＢ２１１とでバージョン比較を行う（Ｓ３５）。通常記憶領域２１のＭＫＢ２１１の方が新しい場合、ホスト装置１０のＭＫＢ１５１を記録媒体２０のＭＫＢ２１１で置き換える（Ｓ３６）。一方、ホスト装置１０のＭＫＢ１５１の方が新しい場合、通常記憶領域２１のＭＫＢ２１１とホスト装置１０のＭＫＢ１５１との間でＭＫＢ更新処理を実施する（Ｓ３７）。バージョンが同一であればＭＫＢ更新処理は不要である。
【００２９】
以上、本実施形態によると、記録媒体２０の認証記憶領域２２の記憶容量が小さいために通常記憶領域２１のＭＫＢ２１１のコピーを格納できない場合であっても、ＭＫＢ識別情報２２４を用いて、通常記憶領域２１のＭＫＢ２１１について過去にリボークされたＭＫＢに差し換えるなど（ＭＫＢのダウンバージョン化）の改竄がされているか否かを検証することができる。
【００３０】
なお、ＭＫＢ識別情報２２４は、Type and Version Recordに限られず、ＭＫＢを識別できるものであればどのようなものでもよいが、Type and Version RecordはＭＫＢの先頭レコードに置かれているため抽出が容易である。
【００３１】
（第３の実施形態）
図７は、第３の実施形態に係る鍵管理システムの構成を示す。当該システムは第１および第２の実施形態に係る鍵管理システムと基本的に同じであり、記録媒体２０の認証記憶領域２２にＭＫＢ２２１あるいはＭＫＢ識別情報２２４を格納する代わりにハッシュ値２２５を格納する点が異なる。ハッシュ値２２５は、ＭＫＢ２１１の全部または一部から算出されたハッシュ値である。以下、第１および第２の実施形態と異なる点について説明する。
【００３２】
記録媒体２０へのＭＫＢの新規書き込み処理について図８のフローチャートを参照しながら説明する。上述したステップＳ１１を実施すると、通常記憶領域２１に書き込んだＭＫＢ２１１に対してＭＫＢ検証を行って正当性を確認するとともにハッシュ値を算出する（Ｓ１２Ｂ）。正当性が確認できたら、算出したハッシュ値を記録媒体２０の認証記憶領域２２に書き込んでハッシュ値２２５を作成する（Ｓ１３Ｂ）。ステップＳ１４は上述したとおりである。
【００３３】
なお、ハッシュ値２２５は暗号化コンテンツの鍵算出に必須ではないため、ステップＳ１３Ｂは必ずしもステップＳ１２とステップＳ１４の間で実施する必要はない。ステップＳ１３Ｂは鍵管理システムにおいてＭＫＢ更新処理が行われていないようなアイドル時に実施してもよい。
【００３４】
次に、本実施形態に係る鍵管理システムにおけるＭＫＢ更新処理について図９のフローチャートを参照しながら説明する。まず、認証記憶領域２２にハッシュ値２２５が存在するか否かを確認する（Ｓ３１Ａ）。認証記憶領域２２にハッシュ値２２５が存在しなければ（Ｓ３１ＡのＮＯ）、図８のフローに従って処理されていないため、ここでの特別なＭＫＢ更新処理は行わずに、別途、ＡＡＣＳなどの規格で定義されたＭＫＢ更新処理を行う。
【００３５】
認証記憶領域２２にハッシュ値２２５が存在すれば（Ｓ３１ＡのＹＥＳ）、通常記憶領域２１のＭＫＢ２１１のハッシュ値を算出する（Ｓ３２Ａ）。そして、算出したハッシュ値と認証記憶領域２２のハッシュ値２２５との同一性を検証し（Ｓ３３）、これらが同一でなければ（Ｓ３３のＮＯ）、ハッシュ値エラーを通知する（Ｓ３４Ａ）。一方、これらが同一であれば（Ｓ３３ＡのＹＥＳ）、通常記憶領域２１のＭＫＢ２１１とホスト装置１０のＭＫＢ１５１との間でＭＫＢ更新処理を実施する（Ｓ３７）。
【００３６】
以上、本実施形態によると、規格で定められたＭＫＢ検証で必要となる楕円暗号などの計算時間のかかる処理を行うことなく同等の正当性を確保することができる。
【００３７】
なお、ハッシュ値算出のアルゴリズムに制限はない。ＨＷで実装された暗号エンジンなどを用いて演算することにより、ＭＫＢ検証の高速化を図ってもよい。
【００３８】
（応用例）
図１０は、鍵管理システムの応用例を示す。上記の各実施形態に係るホスト装置１０は、テレビジョン装置１０１、携帯電話機１０２、レコーダ１０３、ビューア（画像＆音声出力モバイル機器）１０４、デジタルスチルカメラ１０５などのさまざまな民生機器として実現することができる。そして、これら機器に挿入されたＳＤカードなどの記録媒体２０にデジタル放送やインターネット配信の高画質コンテンツが記録される。
【産業上の利用可能性】
【００３９】
本発明に係る鍵管理方法は、記録媒体における安全な鍵管理が可能であるため、メモリカードなどにおけるＭＫＢの管理に有用である。
【符号の説明】
【００４０】
１０ ホスト装置
１５１ ＭＫＢ（ホスト装置が有するＭＫＢ）
２０ 記録媒体
２１ 通常記憶領域
２１１ ＭＫＢ（通常記憶領域に格納されているＭＫＢ）
２２ 認証記憶領域
２２１ ＭＫＢ（認証記憶領域に格納されているＭＫＢ）
２２４ ＭＫＢ識別情報
２２５ ハッシュ値
【特許請求の範囲】
【請求項１】
ホスト装置との相互認証を経ずにアクセス可能な通常記憶領域と相互認証を経てアクセス可能な認証記憶領域とを有する記録媒体においてＭＫＢ（Media Key Block）を管理する鍵管理方法であって、
前記通常記憶領域および前記認証記憶領域のいずれにもＭＫＢが格納されていない場合、前記ホスト装置が有するＭＫＢを前記通常記憶領域および前記認証記憶領域に書き込む
ことを特徴とする鍵管理方法。
【請求項２】
請求項１の鍵管理方法において、
前記通常記憶領域および前記認証記憶領域のいずれにもＭＫＢが格納されている場合、これら二つのＭＫＢの同一性を検証する
ことを特徴とする鍵管理方法。
【請求項３】
請求項１の鍵管理方法において、
前記通常記憶領域にＭＫＢが格納されておらず、かつ、前記認証記憶領域にＭＫＢが格納されている場合、前記認証記憶領域に格納されているＭＫＢのコピーを前記通常記憶領域に書き込む
ことを特徴とする鍵管理方法。
【請求項４】
請求項１の鍵管理方法において、
前記ホスト装置においてＭＫＢ更新処理が行われていないタイミングで前記ホスト装置が有するＭＫＢを前記認証記憶領域に書き込む
ことを特徴とする鍵管理方法。
【請求項５】
ホスト装置との相互認証を経ずにアクセス可能な通常記憶領域と相互認証を経てアクセス可能な認証記憶領域とを有する記録媒体においてＭＫＢ（Media Key Block）を管理する鍵管理方法であって、
前記通常記憶領域および前記認証記憶領域のいずれにもＭＫＢが格納されていない場合、前記ホスト装置が有するＭＫＢを前記通常記憶領域に書き込むとともに当該ＭＫＢの識別情報を前記認証記憶領域に書き込む
ことを特徴とする鍵管理方法。
【請求項６】
請求項５の鍵管理方法において、
前記通常記憶領域にＭＫＢが格納されており、かつ、前記認証記憶領域に識別情報が格納されている場合、前記通常記憶領域に格納されているＭＫＢの識別情報と前記認証記憶領域に格納されている識別情報との同一性を検証する
ことを特徴とする鍵管理方法。
【請求項７】
請求項６の鍵管理方法において、
前記通常記憶領域に格納されているＭＫＢの識別情報と前記認証記憶領域に格納されている識別情報とが同一である場合、前記ホスト装置に格納されているＭＫＢと前記通常記憶領域に格納されているＭＫＢのうちバージョンが古い方をバージョンが新しい方で書き換える
ことを特徴とする鍵管理方法。
【請求項８】
請求項５の鍵管理方法において、
前記識別情報は、Type and Version Recordで定義されるレコードである
ことを特徴とする鍵管理方法。
【請求項９】
請求項５の鍵管理方法において、
前記ホスト装置においてＭＫＢ更新処理が行われていないタイミングで前記識別情報を前記認証記憶領域に書き込む
ことを特徴とする鍵管理方法。
【請求項１０】
ホスト装置との相互認証を経ずにアクセス可能な通常記憶領域と相互認証を経てアクセス可能な認証記憶領域とを有する記録媒体においてＭＫＢ（Media Key Block）を管理する鍵管理方法であって、
前記通常記憶領域および前記認証記憶領域のいずれにもＭＫＢが格納されていない場合、前記ホスト装置が有するＭＫＢを前記通常記憶領域に書き込むとともに当該ＭＫＢの少なくとも一部についてのハッシュ値を算出して前記認証記憶領域に書き込む
ことを特徴とする鍵管理方法。
【請求項１１】
請求項１０の鍵管理方法において、
前記通常記憶領域にＭＫＢが格納されており、かつ、前記認証記憶領域にハッシュ値が格納されている場合、前記通常記憶領域に格納されているＭＫＢの少なくとも一部についてのハッシュ値と前記認証記憶領域に格納されているハッシュ値との同一性を検証する
ことを特徴とする鍵管理方法。
【請求項１２】
請求項１０の鍵管理方法において、
前記ホスト装置においてＭＫＢ更新処理が行われていないタイミングで前記ハッシュ値を前記認証記憶領域に書き込む
ことを特徴とする鍵管理方法。
【請求項１】
ホスト装置との相互認証を経ずにアクセス可能な通常記憶領域と相互認証を経てアクセス可能な認証記憶領域とを有する記録媒体においてＭＫＢ（Media Key Block）を管理する鍵管理方法であって、
前記通常記憶領域および前記認証記憶領域のいずれにもＭＫＢが格納されていない場合、前記ホスト装置が有するＭＫＢを前記通常記憶領域および前記認証記憶領域に書き込む
ことを特徴とする鍵管理方法。
【請求項２】
請求項１の鍵管理方法において、
前記通常記憶領域および前記認証記憶領域のいずれにもＭＫＢが格納されている場合、これら二つのＭＫＢの同一性を検証する
ことを特徴とする鍵管理方法。
【請求項３】
請求項１の鍵管理方法において、
前記通常記憶領域にＭＫＢが格納されておらず、かつ、前記認証記憶領域にＭＫＢが格納されている場合、前記認証記憶領域に格納されているＭＫＢのコピーを前記通常記憶領域に書き込む
ことを特徴とする鍵管理方法。
【請求項４】
請求項１の鍵管理方法において、
前記ホスト装置においてＭＫＢ更新処理が行われていないタイミングで前記ホスト装置が有するＭＫＢを前記認証記憶領域に書き込む
ことを特徴とする鍵管理方法。
【請求項５】
ホスト装置との相互認証を経ずにアクセス可能な通常記憶領域と相互認証を経てアクセス可能な認証記憶領域とを有する記録媒体においてＭＫＢ（Media Key Block）を管理する鍵管理方法であって、
前記通常記憶領域および前記認証記憶領域のいずれにもＭＫＢが格納されていない場合、前記ホスト装置が有するＭＫＢを前記通常記憶領域に書き込むとともに当該ＭＫＢの識別情報を前記認証記憶領域に書き込む
ことを特徴とする鍵管理方法。
【請求項６】
請求項５の鍵管理方法において、
前記通常記憶領域にＭＫＢが格納されており、かつ、前記認証記憶領域に識別情報が格納されている場合、前記通常記憶領域に格納されているＭＫＢの識別情報と前記認証記憶領域に格納されている識別情報との同一性を検証する
ことを特徴とする鍵管理方法。
【請求項７】
請求項６の鍵管理方法において、
前記通常記憶領域に格納されているＭＫＢの識別情報と前記認証記憶領域に格納されている識別情報とが同一である場合、前記ホスト装置に格納されているＭＫＢと前記通常記憶領域に格納されているＭＫＢのうちバージョンが古い方をバージョンが新しい方で書き換える
ことを特徴とする鍵管理方法。
【請求項８】
請求項５の鍵管理方法において、
前記識別情報は、Type and Version Recordで定義されるレコードである
ことを特徴とする鍵管理方法。
【請求項９】
請求項５の鍵管理方法において、
前記ホスト装置においてＭＫＢ更新処理が行われていないタイミングで前記識別情報を前記認証記憶領域に書き込む
ことを特徴とする鍵管理方法。
【請求項１０】
ホスト装置との相互認証を経ずにアクセス可能な通常記憶領域と相互認証を経てアクセス可能な認証記憶領域とを有する記録媒体においてＭＫＢ（Media Key Block）を管理する鍵管理方法であって、
前記通常記憶領域および前記認証記憶領域のいずれにもＭＫＢが格納されていない場合、前記ホスト装置が有するＭＫＢを前記通常記憶領域に書き込むとともに当該ＭＫＢの少なくとも一部についてのハッシュ値を算出して前記認証記憶領域に書き込む
ことを特徴とする鍵管理方法。
【請求項１１】
請求項１０の鍵管理方法において、
前記通常記憶領域にＭＫＢが格納されており、かつ、前記認証記憶領域にハッシュ値が格納されている場合、前記通常記憶領域に格納されているＭＫＢの少なくとも一部についてのハッシュ値と前記認証記憶領域に格納されているハッシュ値との同一性を検証する
ことを特徴とする鍵管理方法。
【請求項１２】
請求項１０の鍵管理方法において、
前記ホスト装置においてＭＫＢ更新処理が行われていないタイミングで前記ハッシュ値を前記認証記憶領域に書き込む
ことを特徴とする鍵管理方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公開番号】特開２０１０−２８８０１３（Ｐ２０１０−２８８０１３Ａ）
【公開日】平成２２年１２月２４日（２０１０．１２．２４）
【国際特許分類】
【出願番号】特願２００９−１３９４２８（Ｐ２００９−１３９４２８）
【出願日】平成２１年６月１０日（２００９．６．１０）
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
【公開日】平成２２年１２月２４日（２０１０．１２．２４）
【国際特許分類】
【出願日】平成２１年６月１０日（２００９．６．１０）
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
[ Back to top ]