JP2010288013A - Key management method - Google Patents

Abstract

To realize secure key management in a recording medium such as a memory card.
In a recording medium (20), either a normal storage area (21) accessible without mutual authentication with a host device (10) or an authentication storage area (22) accessible through mutual authentication. If no MKB is stored, the MKB (151) of the host device (10) is written in the normal storage area (21) and the authentication storage area (22).
[Selection] Figure 1

Description

  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.

  In recent years, there has been an increasing need for copyright protection of contents, and broadcasting and distribution of contents including keys and rights information have been performed on terrestrial digital broadcasting and the Internet. When recording such content on a storage medium, it is necessary to encrypt the content and securely record the key and the right information. As the image quality of content increases, content encryption methods, key lengths, device authentication methods, and the like become more complex, and mechanisms that make it difficult to illegally copy keys and rights information have been introduced one after another.

  One of these mechanisms is device invalidation that prevents unauthorized use of content in devices that are illegally used due to key exposure. Furthermore, the MKB, which is the device invalidation information recorded in the storage medium, 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. There is a need for a mechanism for safely updating or managing various encryption key information such as an authentication key and a content encryption key accompanying MKB update without the user being aware of it. Currently, it is applied as a copyright protection technology for Blu-ray Disc (hereinafter abbreviated as BD) and DVD (Digital Versatile Disc) based on a standard called AACS (Advanced Access Content System).

  Regarding a key management method for an optical disc such as a DVD, a backup mechanism for MKB, title key, and usage rule rights information is provided, and MKB is written if no recording process 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).

JP 2007-334939 A

  In an optical disc such as a BD, MKB is written in advance in the system area assuming 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.

  On the other hand, memory cards such as SD (Secure Digital) cards have been attracting attention as recording media for high-quality content. Currently, CPRM (Content Protection for Recordable Media) is adopted as copyright protection in memory cards, but in the future, higher-level copyright protection that is adopted for copyright protection in optical disks is required. For example, as an MKB expansion method capable of supporting a high-quality recording algorithm while maintaining past compatibility, 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. In view of such a problem, an object of the present invention is to realize secure key management in a recording medium such as a memory card.

  In order to solve the above problems, 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.

  According to this, since a copy of the MKB is stored in the authentication storage area that the user does not freely access, 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.

  According to this, it is possible to verify whether or not the MKB in the normal storage area has been tampered with based on the MKB identification information or the hash value written in the authentication storage area.

  According to 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.

It is a block diagram of the key management system which concerns on 1st Embodiment. It is a flowchart of the new writing process of MKB to a recording medium. It is a flowchart of the MKB update process in the key management system of FIG. It is a block diagram of the key management system which concerns on 2nd Embodiment. It is a flowchart of the new writing process of MKB to a recording medium. 5 is a flowchart of MKB update processing in the key management system of FIG. 4. It is a block diagram of the key management system which concerns on 3rd Embodiment. It is a flowchart of the new writing process of MKB to a recording medium. It is a flowchart of the MKB update process in the key management system of FIG. It is a figure which shows the example of application of a key management system.

(First embodiment)
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 And a memory area 15 for storing. The memory area 15 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. In the authentication storage area 22, 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.

  For example, since 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).

  Since the MKB 221 is not essential for calculating the key of the encrypted content, 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.

  Next, the MKB update process in the key management system according to the present embodiment will be described with reference to the flowchart of FIG. First, it is confirmed whether or not the MKB 221 exists in the authentication storage area 22 (S21). If the MKB 221 does not exist in the authentication storage area 22 (NO in S21), the processing is not performed according to the flow of FIG. 2, and therefore, special MKB update processing is not performed here, and is separately defined in a standard such as AACS. MKB update processing is performed. For example, 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.

  If 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). If they are not the same (NO in S24), an MKB matching error is notified (S25). On the other hand, if they are the same (YES in S24) and after the execution of step S23, 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.

  As described above, according to the present embodiment, 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.

(Second Embodiment)
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. Hereinafter, differences from the first embodiment will be described.

  A new MKB writing process to the recording medium 20 will be described with reference to the flowchart of FIG. When step S11 described above is performed, 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). When the validity is confirmed, 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.

  Since the MKB identification information 224 is not essential for calculating the key of the encrypted content, step S13A does not necessarily need to be performed between step S12 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.

  Next, the MKB update process in the key management system according to the present embodiment 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.

  If the MKB identification information 224 exists in the authentication storage area 22 (YES in S31), the identification information of the MKB 211 in the normal storage area 21 is acquired (S32). Then, the identity between 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). If the MKB 211 in the normal storage area 21 is newer, the MKB 151 in the host device 10 is replaced with the MKB 211 in the recording medium 20 (S36). On the other hand, if 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.

  As described above, according to the present embodiment, even when the copy of the MKB 211 in the normal storage area 21 cannot be stored because the storage capacity of the authentication storage area 22 of the recording medium 20 is small, 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, and any information can be used as long as it can identify the MKB. However, since the Type and Version Record is placed in the first record of the MKB, it can be easily extracted. It is.

(Third embodiment)
FIG. 7 shows a configuration of a key management system according to the third embodiment. This 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. Hereinafter, differences from the first and second embodiments will be described.

  A new MKB writing process to the recording medium 20 will be described with reference to the flowchart of FIG. When step S11 described above is performed, 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.

  Since the hash value 225 is not essential for calculating the key of the encrypted content, step S13B is not necessarily performed between step S12 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.

  Next, MKB update processing in the key management system according to the present embodiment 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.

  If 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).

  As described above, according to the present embodiment, equivalent legitimacy can be ensured without performing processing that takes a long time such as elliptical encryption required for MKB verification defined in the standard.

  There is no limitation on the algorithm for calculating the hash value. The speed of MKB verification may be increased by performing computation using a cryptographic engine implemented in HW.

(Application examples)
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.

  The key management method according to the present invention is useful for the management of MKB in a memory card or the like because secure key management in a recording medium is possible.

10 Host device 151 MKB (MKB of host device)
20 Recording medium 21 Normal storage area 211 MKB (MKB stored in the normal storage area)
22 Authentication storage area 221 MKB (MKB stored in the authentication storage area)
224 MKB identification information 225 Hash value

Claims (12)

A key management method for managing an MKB (Media Key Block) 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,
A key management method comprising: writing an MKB included in the host device into the normal storage area and the authentication storage area when no MKB is stored in either the normal storage area or the authentication storage area. The key management method according to claim 1,
A key management method comprising: verifying the identity of two MKBs when both the normal storage area and the authentication storage area store an MKB. The key management method according to claim 1,
When the MKB is not stored in the normal storage area and the MKB is stored in the authentication storage area, a copy of the MKB stored in the authentication storage area is written into the normal storage area. Key management method. The key management method according to claim 1,
A key management method comprising: writing an MKB included in the host device into the authentication storage area at a timing when the MKB update process is not performed in the host device. A key management method for managing an MKB (Media Key Block) 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,
When no MKB is stored in either the normal storage area or the authentication storage area, the MKB included in the host device is written in the normal storage area and the identification information of the MKB is written in the authentication storage area. Key management method. The key management method according to claim 5,
When the MKB is stored in the normal storage area and the identification information is stored in the authentication storage area, the MKB identification information stored in the normal storage area and the authentication storage area are stored. A key management method characterized by verifying identity with existing identification information. The key management method according to claim 6,
When the identification information stored in the normal storage area and the identification information stored in the authentication storage area are the same, the MKB stored in the host device and the normal storage area are stored. A key management method characterized by rewriting an older version of an MKB with a newer version. The key management method according to claim 5,
The key management method, wherein the identification information is a record defined by Type and Version Record. The key management method according to claim 5,
A key management method comprising: writing the identification information into the authentication storage area at a timing when the MKB update process is not performed in the host device. A key management method for managing an MKB (Media Key Block) 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,
If no MKB is stored in either the normal storage area or the authentication storage area, the MKB included in the host device is written into the normal storage area and a hash value for at least a part of the MKB is calculated A key management method comprising writing to an authentication storage area. The key management method according to claim 10,
When the MKB is stored in the normal storage area and the hash value is stored in the authentication storage area, the hash value and the authentication storage for at least a part of the MKB stored in the normal storage area A key management method characterized by verifying the identity with a hash value stored in an area. The key management method according to claim 10,
A key management method, wherein the hash value is written into the authentication storage area at a timing when the MKB update processing is not performed in the host device.

Images