WO2010143356A1 - 鍵管理方法 - Google Patents

鍵管理方法 Download PDF

Info

Publication number
WO2010143356A1
WO2010143356A1 PCT/JP2010/003201 JP2010003201W WO2010143356A1 WO 2010143356 A1 WO2010143356 A1 WO 2010143356A1 JP 2010003201 W JP2010003201 W JP 2010003201W WO 2010143356 A1 WO2010143356 A1 WO 2010143356A1
Authority
WO
WIPO (PCT)
Prior art keywords
mkb
storage area
key management
authentication
management method
Prior art date
Application number
PCT/JP2010/003201
Other languages
English (en)
French (fr)
Inventor
大井田篤
和田紘幸
Original Assignee
パナソニック株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by パナソニック株式会社 filed Critical パナソニック株式会社
Publication of WO2010143356A1 publication Critical patent/WO2010143356A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/78—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data
    • G06F21/79—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data in semiconductor storage media, e.g. directly-addressable memories
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H04L9/3273—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response for mutual authentication

Definitions

  • the present invention relates to a key management method, and more particularly to a management method of an MKB (Media Key Block) for generating a content key and invalidating a device.
  • MKB Media Key Block
  • the MKB which is the device invalidation information recorded in the storage medium
  • the MKB has been extended to a mechanism that always keeps the latest information through the network and the authentication device. For this reason, it is necessary to always check the MKB version between the device and the storage medium, and to share or update the MKB.
  • BD Blu-ray Disc
  • DVD Digital Versatile Disc
  • a backup mechanism for MKB, title key, and usage rights rule information is provided, and MKB is written if no recording processing occurs on blank media that does not have the corresponding MKB. In some cases, the processing speed is increased (see, for example, Patent Document 1).
  • MKB is written in advance in the system area on the assumption that high-quality content is recorded. Since the MKB of the disk media cannot be rewritten by the user, it was not necessary to assume deletion or falsification of the MKB.
  • memory cards such as SD (Secure Digital) cards are attracting attention as recording media for high-quality content.
  • SD Secure Digital
  • CPRM Content Protection for Recordable Media
  • the content is encrypted after acquiring the MKB corresponding to high-quality recording from the host device when recording the content. It is possible.
  • the memory card has a normal storage area that can be accessed without mutual authentication with the host device and an authentication storage area that can be accessed through mutual authentication.
  • the MKB stored in the normal storage area may be deleted or tampered. If the MKB is deleted, the content recorded on the memory card cannot be reproduced. Also, if the MKB is altered, sufficient copyright protection cannot be ensured.
  • an object of the present invention is to realize secure key management in a recording medium such as a memory card.
  • the present invention has taken the following measures. That is, a key management method for managing an MKB in a recording medium having a normal storage area accessible without mutual authentication with a host device and an authentication storage area accessible through mutual authentication, the normal storage area and If no MKB is stored in any of the authentication storage areas, the MKB possessed by the host device is written to the normal storage area and the authentication storage area.
  • the MKB in the normal storage area can be recovered even if the MKB in the normal storage area is deleted. It is also possible to verify whether or not tampering has occurred.
  • a key management method for managing an MKB in a recording medium having a normal storage area accessible without mutual authentication with a host device and an authentication storage area accessible via mutual authentication comprising: a normal storage area; When no MKB is stored in any of the authentication storage areas, the MKB possessed by the host device is written in the normal storage area and the identification information of the MKB is written in the authentication storage area, or the MKB possessed by the host apparatus is stored in the normal storage area. And a hash value for at least a part of the MKB is calculated and written to the authentication storage area.
  • the present invention it is possible to recover when the MKB is deleted from a memory card or the like, and to verify whether the MKB has been tampered with. This enables secure key management in a recording medium such as a memory card.
  • FIG. 1 is a configuration diagram of a key management system according to the first embodiment.
  • FIG. 2 is a flowchart of a new MKB writing process to the recording medium.
  • FIG. 3 is a flowchart of the MKB update process in the key management system of FIG.
  • FIG. 4 is a configuration diagram of a key management system according to the second embodiment.
  • FIG. 5 is a flowchart of a new MKB writing process to the recording medium.
  • FIG. 6 is a flowchart of the MKB update process in the key management system of FIG.
  • FIG. 7 is a configuration diagram of a key management system according to the third embodiment.
  • FIG. 8 is a flowchart of a new MKB writing process to the recording medium.
  • FIG. 9 is a flowchart of the MKB update process in the key management system of FIG.
  • FIG. 10 is a diagram illustrating an application example of the key management system.
  • FIG. 1 shows a configuration of a key management system according to the first embodiment.
  • the system includes a host device 10 corresponding to various consumer devices such as a mobile phone, and a recording medium 20 corresponding to various memory cards such as an SD memory card.
  • the host device 10 includes an encryption processing unit 11 that performs encryption / decryption of an authentication key, a content encryption key, encrypted content, and the like by hardware (hereinafter abbreviated as HW) and software (hereinafter abbreviated as SW) control, and decrypted content.
  • Output unit 12 that corresponds to a display that displays a sound, a speaker that outputs sound, a power supply unit 13 that corresponds to a battery that supplies power, a control unit 14 that performs system control of each unit by HW or SW control, and secret information such as a key
  • a memory area 15 for storing stores an MKB 151 that is an MKB update source, a device unique key 152 that is used for authentication with the recording medium 20, and an authentication key 153 that is generated by device authentication with the recording medium 20.
  • the recording medium 20 includes a normal storage area 21 that can be accessed without mutual authentication with the host device 10, an authentication storage area 22 that can be accessed through mutual authentication, an input / output with an external device, and a normal storage area 21.
  • the control unit 23 is configured to control access to the authentication storage area 22.
  • the normal storage area 21 stores an MKB 211 that is device invalidation information and an encrypted content group 222 encrypted with a content encryption key.
  • MKB 221 held as a copy of the MKB 211, a content encryption key 222 for encrypting content, and rights information management for managing rights information such as the number of copies defined by the content provider for each encrypted content A group 223 is stored.
  • the file size of the MKB corresponding to AACS reaches several megabytes, it is necessary to secure a sufficiently large storage capacity in the authentication storage area 22.
  • the MKB 221 in the authentication storage area 22 is used for the following backup and verification purposes. Therefore, it is assumed that the MKB 211 in the normal storage area 21 is used in the MKB calculation process or the like.
  • a new MKB writing process to the recording medium 20 will be described with reference to the flowchart of FIG. This processing occurs when the recording medium 20 is in a shipping state and does not hold the MKB 211 and content is recorded on the recording medium 20 for the first time.
  • the MKB 151 held by the host device 10 is copied to the normal storage area 21 of the recording medium 20 to create the MKB 211 (S11). However, it is assumed that the MKB 151 provided from the host device 10 is a legitimate one that has not been tampered with.
  • MKB verification is performed on the MKB 211 written in the normal storage area 21 to confirm the validity (S12). If the validity is confirmed, the MKB 211 is copied to the authentication storage area 22 of the recording medium 20 to create the MKB 221 (S13). Then, content encryption processing is performed using the key calculated from the MKB 211 whose validity has been confirmed (S14).
  • step S13 is not necessarily performed between step S12 and step S14.
  • Step S13 may be performed at an idle time when the MKB update process is not performed in the key management system.
  • MKB update processing is performed.
  • AACS stipulates that the MKB update is performed by comparing the versions of the MKB stored in the host device 10 and the recording medium 20, respectively, and rewriting the old version to the new version.
  • the MKB 221 exists in the authentication storage area 22 (YES in S21), it is confirmed whether or not the MKB 211 exists in the normal storage area 21 (S22). If the MKB 211 does not exist in the normal storage area 21 (NO in S22), recovery processing is performed because it is considered that the user has deleted it by mistake. Specifically, the MKB 211 is copied by copying the MKB 221 in the authentication storage area 22 to the normal storage area 21 (S23). On the other hand, if the MKB 211 exists in the normal storage area 21 (YES in S22), a verify process for verifying that the tampering has not been performed is performed. Specifically, the identity between the MKB 211 and the MKB 221 is verified (S24).
  • an MKB matching error is notified (S25).
  • an MKB update process is performed between the MKB 211 in the normal storage area 21 and the MKB 151 in the host device 10 (S26).
  • the MKB update process corresponds to, for example, a key conversion process defined in AACS, but detailed description thereof is omitted.
  • recovery is possible even if the MKB 211 stored in the normal storage area 21 of the recording medium 20 is accidentally deleted by the user, and it is verified whether the MKB 211 has been tampered with. Can do.
  • FIG. 4 shows a configuration of a key management system according to the second embodiment.
  • This system is basically the same as the key management system according to the first embodiment, except that the MKB identification information 224 is stored instead of the MKB 221 in the authentication storage area 22 of the recording medium 20.
  • the MKB identification information 224 is version information included in the Type and Version Record of the MKB 211.
  • differences from the first embodiment will be described.
  • step S11 MKB verification is performed on the MKB 211 written in the normal storage area 21 to confirm the validity and extract the identification information (S12A).
  • the extracted identification information is written in the authentication storage area 22 of the recording medium 20 to create the MKB identification information 224 (S13A).
  • Step S14 is as described above.
  • step S13A is not necessarily performed between step S12A and step S14.
  • Step S13A may be performed at an idle time when the MKB update process is not performed in the key management system.
  • the MKB update process in the key management system will be described with reference to the flowchart of FIG. First, it is confirmed whether or not the MKB identification information 224 exists in the authentication storage area 22 (S31). If the MKB identification 224 does not exist in the authentication storage area 22 (NO in S31), the process is not performed according to the flow of FIG. 5, and therefore, a special MKB update process is not performed here, and a standard such as AACS is used. The defined MKB update process is performed.
  • the identification information of the MKB 211 in the normal storage area 21 is acquired (S32). Then, the identity of the acquired identification information and the MKB identification information 224 in the authentication storage area 22 is verified (S33). If they are not identical (NO in S33), a TYPE AND VERSION NUMBER error is notified (S34). . On the other hand, if they are the same (YES in S33), version comparison is performed between the MKB 151 of the host device 10 and the MKB 211 of the normal storage area 21 (S35).
  • the MKB 151 in the host device 10 is replaced with the MKB 211 in the recording medium 20 (S36).
  • the MKB 151 of the host device 10 is newer, an MKB update process is performed between the MKB 211 of the normal storage area 21 and the MKB 151 of the host device 10 (S37). If the versions are the same, the MKB update process is unnecessary.
  • the normal storage is performed using the MKB identification information 224. It is possible to verify whether or not the MKB 211 in the area 21 has been tampered with, for example, by replacing it with a previously revoked MKB (MKB down-version).
  • the MKB identification information 224 is not limited to Type ⁇ and Version Record, but may be any information as long as it can identify the MKB. However, since Type and Version Record is placed in the first record of the MKB, it can be easily extracted. It is.
  • FIG. 7 shows a configuration of a key management system according to the third embodiment.
  • the system is basically the same as the key management system according to the first and second embodiments, and stores the hash value 225 instead of storing the MKB 221 or the MKB identification information 224 in the authentication storage area 22 of the recording medium 20.
  • the point is different.
  • the hash value 225 is a hash value calculated from all or part of the MKB 211.
  • step S11 MKB verification is performed on the MKB 211 written in the normal storage area 21 to confirm the validity, and a hash value is calculated (S12B). If the validity is confirmed, the calculated hash value is written in the authentication storage area 22 of the recording medium 20 to create the hash value 225 (S13B). Step S14 is as described above.
  • step S13B does not necessarily need to be performed between step S12B and step S14.
  • Step S13B may be performed at an idle time when the MKB update process is not performed in the key management system.
  • the MKB update process in the key management system will be described with reference to the flowchart of FIG. First, it is confirmed whether or not the hash value 225 exists in the authentication storage area 22 (S31A). If the hash value 225 does not exist in the authentication storage area 22 (NO in S31A), the processing is not performed according to the flow of FIG. 8, and therefore, special MKB update processing is not performed here, and a standard such as AACS is used. The defined MKB update process is performed.
  • the hash value 225 exists in the authentication storage area 22 (YES in S31A)
  • the hash value of the MKB 211 in the normal storage area 21 is calculated (S32A). Then, the identity of the calculated hash value and the hash value 225 of the authentication storage area 22 is verified (S33). If they are not the same (NO in S33), a hash value error is notified (S34A). On the other hand, if they are the same (YES in S33A), an MKB update process is performed between the MKB 211 in the normal storage area 21 and the MKB 151 in the host device 10 (S37).
  • equivalent legitimacy can be ensured without performing time-consuming processing such as elliptical encryption required for MKB verification defined in the standard.
  • the speed of MKB verification may be increased by performing computation using a cryptographic engine implemented in HW.
  • FIG. 10 shows an application example of the key management system.
  • the host device 10 according to each embodiment described above can be realized as various consumer devices such as the television device 101, the mobile phone 102, the recorder 103, the viewer (image & sound output mobile device) 104, and the digital still camera 105. it can. Then, high-definition content for digital broadcasting or Internet distribution is recorded on a recording medium 20 such as an SD card inserted in these devices.
  • a recording medium 20 such as an SD card inserted in these devices.
  • the key management method according to the present invention is useful for managing the MKB in a memory card or the like because it allows safe key management in a recording medium.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)

Abstract

　メモリカードなどの記録媒体における安全な鍵管理を実現する。記録媒体（２０）において、ホスト装置（１０）との相互認証を経ずにアクセス可能な通常記憶領域（２１）および相互認証を経てアクセス可能な認証記憶領域（２２）のいずれにもＭＫＢが格納されていない場合、ホスト装置（１０）が有するＭＫＢ（１５１）を通常記憶領域（２１）および認証記憶領域（２２）に書き込む。

Description

鍵管理方法
　本発明は、鍵管理方法に関し、特に、コンテンツ鍵の生成および機器の無効化を行うためのＭＫＢ（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はＭＫＢの先頭レコードに置かれているため抽出が容易である。
　（第３の実施形態）
　図７は、第３の実施形態に係る鍵管理システムの構成を示す。当該システムは第１および第２の実施形態に係る鍵管理システムと基本的に同じであり、記録媒体２０の認証記憶領域２２にＭＫＢ２２１あるいはＭＫＢ識別情報２２４を格納する代わりにハッシュ値２２５を格納する点が異なる。ハッシュ値２２５は、ＭＫＢ２１１の全部または一部から算出されたハッシュ値である。以下、第１および第２の実施形態と異なる点について説明する。
　記録媒体２０へのＭＫＢの新規書き込み処理について図８のフローチャートを参照しながら説明する。上述したステップＳ１１を実施すると、通常記憶領域２１に書き込んだＭＫＢ２１１に対してＭＫＢ検証を行って正当性を確認するとともにハッシュ値を算出する（Ｓ１２Ｂ）。正当性が確認できたら、算出したハッシュ値を記録媒体２０の認証記憶領域２２に書き込んでハッシュ値２２５を作成する（Ｓ１３Ｂ）。ステップＳ１４は上述したとおりである。
　なお、ハッシュ値２２５は暗号化コンテンツの鍵算出に必須ではないため、ステップＳ１３Ｂは必ずしもステップＳ１２ＢとステップＳ１４の間で実施する必要はない。ステップＳ１３Ｂは鍵管理システムにおいてＭＫＢ更新処理が行われていないようなアイドル時に実施してもよい。
　次に、本実施形態に係る鍵管理システムにおけるＭＫＢ更新処理について図９のフローチャートを参照しながら説明する。まず、認証記憶領域２２にハッシュ値２２５が存在するか否かを確認する（Ｓ３１Ａ）。認証記憶領域２２にハッシュ値２２５が存在しなければ（Ｓ３１ＡのＮＯ）、図８のフローに従って処理されていないため、ここでの特別なＭＫＢ更新処理は行わずに、別途、ＡＡＣＳなどの規格で定義されたＭＫＢ更新処理を行う。
　認証記憶領域２２にハッシュ値２２５が存在すれば（Ｓ３１ＡのＹＥＳ）、通常記憶領域２１のＭＫＢ２１１のハッシュ値を算出する（Ｓ３２Ａ）。そして、算出したハッシュ値と認証記憶領域２２のハッシュ値２２５との同一性を検証し（Ｓ３３）、これらが同一でなければ（Ｓ３３のＮＯ）、ハッシュ値エラーを通知する（Ｓ３４Ａ）。一方、これらが同一であれば（Ｓ３３ＡのＹＥＳ）、通常記憶領域２１のＭＫＢ２１１とホスト装置１０のＭＫＢ１５１との間でＭＫＢ更新処理を実施する（Ｓ３７）。
　以上、本実施形態によると、規格で定められたＭＫＢ検証で必要となる楕円暗号などの計算時間のかかる処理を行うことなく同等の正当性を確保することができる。
　なお、ハッシュ値算出のアルゴリズムに制限はない。ＨＷで実装された暗号エンジンなどを用いて演算することにより、ＭＫＢ検証の高速化を図ってもよい。
　（応用例）
　図１０は、鍵管理システムの応用例を示す。上記の各実施形態に係るホスト装置１０は、テレビジョン装置１０１、携帯電話機１０２、レコーダ１０３、ビューア（画像＆音声出力モバイル機器）１０４、デジタルスチルカメラ１０５などのさまざまな民生機器として実現することができる。そして、これら機器に挿入されたＳＤカードなどの記録媒体２０にデジタル放送やインターネット配信の高画質コンテンツが記録される。
　本発明に係る鍵管理方法は、記録媒体における安全な鍵管理が可能であるため、メモリカードなどにおけるＭＫＢの管理に有用である。
　１０　　ホスト装置
　１５１　ＭＫＢ（ホスト装置が有するＭＫＢ）
　２０　　記録媒体
　２１　　通常記憶領域
　２１１　ＭＫＢ（通常記憶領域に格納されているＭＫＢ）
　２２　　認証記憶領域
　２２１　ＭＫＢ（認証記憶領域に格納されているＭＫＢ）
　２２４　ＭＫＢ識別情報
　２２５　ハッシュ値

Claims (12)

  1. ホスト装置との相互認証を経ずにアクセス可能な通常記憶領域と相互認証を経てアクセス可能な認証記憶領域とを有する記録媒体においてＭＫＢ（Media Key Block）を管理する鍵管理方法であって、
    　前記通常記憶領域および前記認証記憶領域のいずれにもＭＫＢが格納されていない場合、前記ホスト装置が有するＭＫＢを前記通常記憶領域および前記認証記憶領域に書き込む
    ことを特徴とする鍵管理方法。
  2. 請求項１の鍵管理方法において、
    　前記通常記憶領域および前記認証記憶領域のいずれにもＭＫＢが格納されている場合、これら二つのＭＫＢの同一性を検証する
    ことを特徴とする鍵管理方法。
  3. 請求項１の鍵管理方法において、
    　前記通常記憶領域にＭＫＢが格納されておらず、かつ、前記認証記憶領域にＭＫＢが格納されている場合、前記認証記憶領域に格納されているＭＫＢのコピーを前記通常記憶領域に書き込む
    ことを特徴とする鍵管理方法。
  4. 請求項１の鍵管理方法において、
    　前記ホスト装置においてＭＫＢ更新処理が行われていないタイミングで前記ホスト装置が有するＭＫＢを前記認証記憶領域に書き込む
    ことを特徴とする鍵管理方法。
  5. ホスト装置との相互認証を経ずにアクセス可能な通常記憶領域と相互認証を経てアクセス可能な認証記憶領域とを有する記録媒体においてＭＫＢ（Media Key Block）を管理する鍵管理方法であって、
    　前記通常記憶領域および前記認証記憶領域のいずれにもＭＫＢが格納されていない場合、前記ホスト装置が有するＭＫＢを前記通常記憶領域に書き込むとともに当該ＭＫＢの識別情報を前記認証記憶領域に書き込む
    ことを特徴とする鍵管理方法。
  6. 請求項５の鍵管理方法において、
    　前記通常記憶領域にＭＫＢが格納されており、かつ、前記認証記憶領域に識別情報が格納されている場合、前記通常記憶領域に格納されているＭＫＢの識別情報と前記認証記憶領域に格納されている識別情報との同一性を検証する
    ことを特徴とする鍵管理方法。
  7. 請求項６の鍵管理方法において、
    　前記通常記憶領域に格納されているＭＫＢの識別情報と前記認証記憶領域に格納されている識別情報とが同一である場合、前記ホスト装置に格納されているＭＫＢと前記通常記憶領域に格納されているＭＫＢのうちバージョンが古い方をバージョンが新しい方で書き換える
    ことを特徴とする鍵管理方法。
  8. 請求項５の鍵管理方法において、
    　前記識別情報は、Type and Version Recordで定義されるレコードである
    ことを特徴とする鍵管理方法。
  9. 請求項５の鍵管理方法において、
    　前記ホスト装置においてＭＫＢ更新処理が行われていないタイミングで前記識別情報を前記認証記憶領域に書き込む
    ことを特徴とする鍵管理方法。
  10. ホスト装置との相互認証を経ずにアクセス可能な通常記憶領域と相互認証を経てアクセス可能な認証記憶領域とを有する記録媒体においてＭＫＢ（Media Key Block）を管理する鍵管理方法であって、
    　前記通常記憶領域および前記認証記憶領域のいずれにもＭＫＢが格納されていない場合、前記ホスト装置が有するＭＫＢを前記通常記憶領域に書き込むとともに当該ＭＫＢの少なくとも一部についてのハッシュ値を算出して前記認証記憶領域に書き込む
    ことを特徴とする鍵管理方法。
  11. 請求項１０の鍵管理方法において、
    　前記通常記憶領域にＭＫＢが格納されており、かつ、前記認証記憶領域にハッシュ値が格納されている場合、前記通常記憶領域に格納されているＭＫＢの少なくとも一部についてのハッシュ値と前記認証記憶領域に格納されているハッシュ値との同一性を検証する
    ことを特徴とする鍵管理方法。
  12. 請求項１０の鍵管理方法において、
    　前記ホスト装置においてＭＫＢ更新処理が行われていないタイミングで前記ハッシュ値を前記認証記憶領域に書き込む
    ことを特徴とする鍵管理方法。
PCT/JP2010/003201 2009-06-10 2010-05-11 鍵管理方法 WO2010143356A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2009139428A JP2010288013A (ja) 2009-06-10 2009-06-10 鍵管理方法
JP2009-139428 2009-06-10

Publications (1)

Publication Number Publication Date
WO2010143356A1 true WO2010143356A1 (ja) 2010-12-16

Family

ID=43308619

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2010/003201 WO2010143356A1 (ja) 2009-06-10 2010-05-11 鍵管理方法

Country Status (2)

Country Link
JP (1) JP2010288013A (ja)
WO (1) WO2010143356A1 (ja)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001256113A (ja) * 2000-03-13 2001-09-21 Toshiba Corp コンテンツ処理システムおよびコンテンツ保護方法
JP2003242040A (ja) * 1999-09-01 2003-08-29 Matsushita Electric Ind Co Ltd 半導体メモリカード、受信装置、及びコンピュータ読取可能な記録媒体
JP2006203812A (ja) * 2005-01-24 2006-08-03 Toshiba Corp 著作権管理方法、情報記録再生方法及び装置、並びに情報記録媒体及びその製造方法
JP2008022367A (ja) * 2006-07-13 2008-01-31 Toshiba Corp 暗号鍵情報保持方法および暗号鍵情報処理装置
JP2008527816A (ja) * 2005-01-11 2008-07-24 インターナショナル・ビジネス・マシーンズ・コーポレーション 保護デジタル・コンテンツへのアクセスをメディア鍵ブロックの検証によって制御する方法、システム、及びコンピュータ・プログラム（読出し／書込み型メディア鍵ブロック）
JP2008293161A (ja) * 2007-05-23 2008-12-04 Panasonic Corp 記録再生装置

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003242040A (ja) * 1999-09-01 2003-08-29 Matsushita Electric Ind Co Ltd 半導体メモリカード、受信装置、及びコンピュータ読取可能な記録媒体
JP2001256113A (ja) * 2000-03-13 2001-09-21 Toshiba Corp コンテンツ処理システムおよびコンテンツ保護方法
JP2008527816A (ja) * 2005-01-11 2008-07-24 インターナショナル・ビジネス・マシーンズ・コーポレーション 保護デジタル・コンテンツへのアクセスをメディア鍵ブロックの検証によって制御する方法、システム、及びコンピュータ・プログラム（読出し／書込み型メディア鍵ブロック）
JP2006203812A (ja) * 2005-01-24 2006-08-03 Toshiba Corp 著作権管理方法、情報記録再生方法及び装置、並びに情報記録媒体及びその製造方法
JP2008022367A (ja) * 2006-07-13 2008-01-31 Toshiba Corp 暗号鍵情報保持方法および暗号鍵情報処理装置
JP2008293161A (ja) * 2007-05-23 2008-12-04 Panasonic Corp 記録再生装置

Also Published As

Publication number Publication date
JP2010288013A (ja) 2010-12-24

Similar Documents

Publication Publication Date Title
US8190910B2 (en) Information processing apparatus, information recording medium manufacturing apparatus, and information recording medium
JP4690600B2 (ja) データ保護方法
CN101025977B (zh) 信息处理设备及方法和信息记录介质制造设备及方法
JP5786670B2 (ja) 情報処理装置、情報記憶装置、情報処理システム、および情報処理方法、並びにプログラム
JP4799626B2 (ja) 情報処理装置、および情報処理方法、並びにプログラム
JP4899442B2 (ja) 情報処理装置、情報記録媒体製造装置、情報記録媒体、および方法、並びにコンピュータ・プログラム
US20060136342A1 (en) Content protection method, and information recording and reproduction apparatus using same
WO2005066952A1 (en) Method of copying and reproducing data from storage medium
JP2010268417A (ja) 記録装置及びコンテンツデータ再生システム
JP2010267240A (ja) 記録装置
US20080232785A1 (en) Apparatus, Method, and Program Product For Recording and Reproducing Contents
US7926115B2 (en) Information recording and reproducing apparatus and method
JP4140624B2 (ja) 情報処理装置、情報記録媒体製造装置、情報記録媒体、および方法、並びにコンピュータ・プログラム
JP5821558B2 (ja) 情報処理装置、情報記憶装置、情報処理システム、および情報処理方法、並びにプログラム
CN101089980A (zh) 记录和再现信息的装置和方法
US20120002817A1 (en) Key management method and key management device
JP2005020703A5 (ja)
JP2010220019A5 (ja)
WO2010143356A1 (ja) 鍵管理方法
JP2012085320A (ja) 情報処理装置、および方法、並びにコンピュータ・プログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10785888

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10785888

Country of ref document: EP

Kind code of ref document: A1