JP2008035397A - Encryption information processing method and encryption information processing device - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To reduce redundancy of MKB processing in AACS, and to simplify the processing. <P>SOLUTION: The equipment that utilizes title key Kt holds an encryption media key Enc_Km corresponding to a media key Km and separately protected (ST250), relating to a method for generating a protected area key Kpa based on the media key Km and random number data BN, while generating the title key Kt used for encrypting or decrypting contents based on a title key file TKF containing a decrypted title key Kte and the protected area key Kpa. The equipment utilizes as required the held decrypted media key (Enc_Km) (ST210 yes, ST212-ST214). <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to information access management using an encryption key or the like. In particular, the present invention relates to a method for processing cryptographic information used for protecting highly confidential data.

  In recent years, various digital devices for accessing content recorded on a disk medium or the like have been developed. Data recorded on a disk accessed by such a device is subjected to an encryption process in order to prevent unauthorized access or illegal copying. For the encrypted data, DVD (Digital Versatile Disc) mainly adopts an encryption method conforming to the CSS (Content Scramble System) method.

  On the other hand, AACS (Advanced Access Content System) has been proposed as a more advanced encryption method (Patent Document 1). When this AACS system is adopted, for example, a set maker obtains a specific key set from a key tree held by a licensor, encrypts different combinations of keys, and incorporates them into individual devices.

Also, when an application program requests an authentication request for DVD media, a method is proposed in which the latest MKB for a memory card is read from the DVD media and passed to the application program instead of the MKB (Media Key Block) for DVD media. (Patent Document 2).
JP 2005-39480 A JP 2001-256113 A

  In AACS, each of a plurality of keys is encrypted using a device key assigned to each device that properly records and reproduces content and a randomly generated random number, is registered in a key file together with the random number, and is recorded on a medium. When reproducing the content, the encryption key registered in the key file is decrypted with the random number and the device key of the device to be reproduced. Then, the content is decrypted with the decrypted key, and the content is reproduced.

  In AACS, a process for generating a media key (Media Key: Km) by processing a media key block (Media Key Block: MKB) is included in the process of obtaining the key for decrypting the content (Title Key: Kt). . Since this MKB process is likely to be repeated for the same MKB, it is redundant to process each time.

  One of the problems of the present invention is to reduce the redundancy of the MKB process in AACS and to simplify the process.

  According to an embodiment of the present invention, a protected area key (Protected Area Key: Kpa) is generated from a media key (Media Key: Km) and random number data (Binding Nonce: BN), and an encrypted title key is generated. When generating a title key (Tit Key: Kt) used for content encryption or decryption from a title key file (TKF) including (Encrypted Title Key: Kte) and the protected area key (Kpa) Used for.

  In this method, the device (such as HD_DVD Recorder) that uses the title key (Kt) holds the uniquely protected encrypted media key (Enc_Km) corresponding to the media key (Km) (ST141 in FIG. 9). ). Information recorded by encrypting and recording the media key (Km) by a method (AACS) different from the original protection is used as a media key block (MKB), and is recorded or reproduced by the device (optical disc) Has the media key block (MKB), and when the media key block (MKB) information is held on the device to update the media key block (MKB) of the media, the device The stored encrypted media key (Enc_Km) is used (ST140 to ST148 in FIG. 9).

  A device using AACS holds the uniquely protected encrypted media key, whereby the MKB processing in the device can be simplified.

  Hereinafter, various embodiments of the present invention will be described with reference to the drawings. When recording information on an information recording medium such as an optical disk, it may be required to record the information encrypted. In that case, for example, the copyright-protected content is encrypted with an encryption key to be encrypted content, and further, the encryption key used for encryption is concealed so as to be encrypted with another encryption key to be an encryption key. The encryption key and the encrypted content are recorded together on a recording medium to prevent illegal copying.

  Currently, the DVD (Digital Versatile Disc), which is rapidly expanding its market, takes the following measures for copyright protection. That is, the DVD video uses the CSS (Content Scramble System) system licensed by DVD CCA (DVD Copy Control Association), and the DVD audio uses the CPPM (Content Protection for Prerecorded Media) system. A CPRM (Content Protection for Recordable Media) system is used as a copyright protection system for content recorded on a recording medium. The licenses for the CPPM method and the CPRM method are granted by a specific organization (for example, an organization called 4C Entity, LLC).

  On the other hand, development of large-capacity next-generation DVDs and the like that can record and reproduce high-definition video and high-quality multi-channel audio signals is in progress. As a copyright protection method for recording high-quality works on such next-generation recording media, it is required to introduce a method with higher security capability than before. As a specific example, there is an AACS (Advanced Access Content System) system. A content key management method in AACS, which is a content protection technology adopted in the HD DVD-VR (High Density Digital Versatile Disc Video Recording) format, will be described below.

  In the conventional CPRM method, an encryption key is generated using a media key block (MKB) and a media ID (Media ID) existing in the disc, and the content is encrypted. On the other hand, in the AACS system, the content in the disc is encrypted not by a common encryption key but by an encryption key for each content.

  FIG. 1 is a diagram illustrating a configuration example of data in the medium 100. In this example, a maximum of 1998 video objects (VOB) which are contents in a format such as MPEG2-PS and stream objects (SOB) which are contents in a format such as MPEG2-TS are stored in the same medium according to the standard. It is possible to do. In the conventional method, one encryption key is used for all these objects, but in the AACS method, encryption is performed using different encryption keys for each content. The encryption key for each content is stored in the title key file (TKF). That is, a title key file for a video object and a title key file for a stream object are provided, and each title key file can store a maximum of 1998 encrypted title keys (Encrypted Title Key: E-TK or Kte). It has become.

  FIG. 2 is a diagram for explaining processing for decrypting encrypted contents recorded in the media 100. FIG. 2 shows information stored in the medium 100 on which content is recorded, processing functions provided in the information recording / reproducing apparatus 200, and data flow therebetween.

AACS is a content protection technology employed in the HD_DVD Video Recording Format. A content key management method in AACS will be described with reference to FIG. The data recorded in the non-rewritable area on the disk used for AACS processing is:
・ Media ID
・ Lead-in MKB
There is.

On the other hand, data that is used in AACS processing and exists as a file on the disk 100 includes:
・ Read Write MKB
・ Title Key File
・ Title Usage File
There is. Also, data based on a random number called Binding Nonce is recorded in the protected area at the head address of the Title Key File.

  In AACS, the process of generating a “title key (Kt)” for encrypting content is large and executed in the following order. That is, first, MKB processing is performed using a newer version of Lead-in MKB and Read Write MKB. The key generated by this processing is called “media key (Km)”. When this media key Km and Binding Nonce (BN) are input, and a protected area key process (Kpa process) is performed, a “protected area key (Kpa)” is generated. By performing Title Key processing (TK processing) using the Kpa and Title Usage File data and Title Key File data as input, the encrypted title key (Encrypted Title Key) described in the Title Key File is originally Can be converted to the title key Kt.

  MKB is data called Media Key Block, which is a media key Km encrypted and recorded. Further, information on unauthorized devices is also recorded in the MKB, so that unauthorized devices cannot take out Km. Since unauthorized device information is updated, it is necessary to use a new MKB. For this reason, in the AACS of HD_DVD, the Lead-in MKB embedded in the Lead-in Area of the media, the Read Write MKB stored as a file on the disk, and the MKB stored in the nonvolatile memory inside the device itself (hereinafter referred to as “MB”) , Device MKB), and the latest MKB is overwritten on the Read Write MKB. However, updating the MKB to a new one changes the value of Km, so all key information after Km (Kpa, etc.) needs to be regenerated (Kt is regenerated) However, TKF needs to be regenerated (re-encrypted)).

  2 includes a control unit 210, a reading unit 220, and a writing unit 230. The control unit 210 controls each function and each processing operation of the information recording / reproducing apparatus 200 shown in FIG. The reading unit 220 reads data from the medium 100 into the information recording / reproducing apparatus 200. The writing unit 230 writes data in the information recording / reproducing apparatus 200 to the medium 100.

  Lead-in MKB (Media Key Block) is stored in the read-only lead-in area of the medium 100, and Read Write MKB is stored in the User Data Area which is a rewritable area. MKB has established a mathematical system by encrypting a media key (Km), which is a base key for content encryption, with a set of device keys (Kd) installed as a secret key in the information recording / reproducing apparatus 200. Media key block ".

  In S10 of FIG. 2, after comparing the Lead-in MKB and Read Write MKB versions recorded on the medium 100 and confirming that the Read Write MKB version is equal to or higher than the Lead-in MKB version. , Read Write MKB is read as Media MKB. If only the Lead-in MKB exists in the medium 100, the Lead-in MKB is read as the Media MKB. In S11, the MKB process is performed using the device key set (Set of Device Keys or Device Key Set) and Media MKB stored in the information recording / reproducing apparatus 200. This device key set is composed of a plurality of device keys Kd.

  Here, information for generating a protected area key (Kpa) is encrypted and stored in the MKB, but in addition, revoke information (Revoke Information: revocation information or invalidation information) is also included. . That is, when a security hole exists in a certain device key set and the licensor prohibits the use of the corresponding device key Kd, revocation information related to the corresponding device key Kd is described. This revoked information makes it impossible for the device having the corresponding device key Kd to decrypt the cipher (that is, the revoked information cannot be reproduced). Since unauthorized device information is gradually updated as time passes, it is necessary to use a new MKB (the latest updated MKB). Therefore, the newer version is used as Media MKB as described above.

  A media key (Km) is generated by this MKB process. In S12 of FIG. 2, the generated media key is verified. If the generated media key is invalid as a result of verification, the device key set is regarded as invalid, and the process related to AACS is terminated.

  On the other hand, “data based on random numbers” combined with a file called Binding Nonce is recorded in the protected area at the head address of the title key file (TKF). This Binding Nonce cannot be copied by, for example, a PC (personal computer) Write command, and can be copied only by a command defined by AACS. As described above, the information can be prevented from being leaked through the PC by enabling the copying only with the hardware having the AACS license.

  Next, in S13 of FIG. 2, Kpa processing that is encryption processing is performed using Km and Binding Nonce. For this Kpa processing, AES (Advanced Encrypted Standard) -G which is an encryption algorithm is used. As a result of this Kpa processing, a protected area key (Kpa) is generated.

  Next, title key processing for generating a title key (TK) from Kpa will be described. This process is indicated by S14 in FIG. The title key file (TKF) stores random data called TKFN (Title Key File Nonce). This TKFN is random number data used to encrypt the title key in the encryption process (described later). In addition, the disc 100 has a Title Usage File in which content usage rules are described. In this Title Usage File, for each of a plurality of usage rules, information (Usage Rule) on whether to apply the usage rules is described as 0 or 1 bit information.

  Further, a Media ID is recorded in a read-only burst cutting area (BCA) provided inside the lead-in area of the disc 100. Media ID is a unique ID added to each medium. In the user data area, which is a rewritable area, Media ID MAC, which is a falsification prevention code MAC (Message Authentication Code) using Media ID, is stored.

  In the title key process shown in S14 of FIG. 2, the process using the AES-D algorithm is performed based on the result of processing the above Usage Rule, Kpa and TKFN, and an encrypted title key (E-TK or E-TK or Kte) is decrypted to generate a title key (TK). At this time, it is verified that the MAC generated using the Media ID stored in the BCA and the Media ID MAC stored in the disk are not falsified. In S15 of FIG. 2, the TK thus generated and the encrypted content (Encrypted contents) are processed by the AES-G algorithm to generate a content key. In S16, the content key is used. The encrypted content (Encrypted contents) is decrypted to generate the content.

  FIG. 3 is a diagram for explaining a process of encrypting the content and recording it on the optical disc 100 such as HD_DVD-R / RW / RAM. The terminology used is the same as in FIG. In S20 of FIG. 3, the versions of Lead-in MKB and Read Write MKB recorded on the medium 100 are compared, and the new MKB of the version is read as Media MKB. Next, the versions of Media MKB and Device MKB possessed by information recording / reproducing apparatus 200 are compared. If the Device MKB version is newer, the MKB update process is started in S21, and the value of Device MKB is updated to Read Write MKB. However, if the Media MKB version is newer, whether to update the Device MKB value is a set specification. In S22 of FIG. 3, the MKB process is performed using the device key set stored in the information recording / reproducing apparatus 200 and the Media MKB. A media key (Km) is generated by this MKB process.

  In S23 of FIG. 3, the generated media key is verified. If the generated media key is invalid as a result of the verification, the device key set is regarded as invalid and the processing related to AACS is terminated. On the other hand, in S24 of FIG. 3, Kpa processing that is encryption processing is performed using Km and Binding Nonce. As a result of the Kpa process using AES-G, a protected area key (Kpa) is generated.

  In S25 of FIG. 3, the title key (TK) and the content are processed by an AES-G algorithm to generate a content key. In step S26, the content key is encrypted to generate encrypted contents, which are recorded on the medium 100. In S27, a MAC is generated using the Media ID and TK, and stored in the medium 100 as the Media ID MAC. On the other hand, in S28, random number data used for encrypting the title key is generated and recorded on the medium 100 as a Title Key File Nonce. In S29, the process using the AES-E algorithm is performed based on the result obtained by hashing the Usage Rule (known technique) and Kpa and TK, and the encrypted title key (E-TK or Kte) is obtained. It is generated and stored in the medium 100. The Usage Rule is recorded on the medium 100 in S30.

  As described above, the title key or the like plays an important role in content encryption and decryption. However, since the title key or the like is recorded on the medium 100 as a file that can be read / written, if the surface of the medium becomes dirty with, for example, a fingerprint, there is a possibility that the content cannot be easily read. Therefore, AACS provides a backup for a title key file (TKF) that stores information such as these title keys.

  FIG. 4 is an explanatory diagram showing a structure example of a title key file and a title key file as a backup file thereof. In the description of this backup method, the title key file is represented as TKF1, and the title key files as backup files are represented as TKF2 and TKF3. TKF 1 to 3 are stored in the medium 100.

  Each title key file (TKF 1 to 3) includes Binding Nonce 1 to 3 (BN 1 to 3), Title Key File Generation 1 to 3 (TKFG 1 to 3), Title Key File Nonce 1 to 3 (TKFN 1 to 3), Encrypted Title Key 1 to 3 (encrypted title keys ETK 1 to 3) are registered. Here, Binding Nonce 1 to 3 (BN 1 to 3) are random number data used for encryption of its own title key file as described above. Title Key File Generations 1 to 3 (TKFG1 to 3) represent the number of changes of title key files (TKF1 to 3). Title Key File Nonce to 3 (TKFN1 to 3) are random numbers for generating an encrypted title key (ETK1 to 3) of a file other than its own title key file or backup file.

Encrypted Title Keys 1 to 3 (encrypted title keys: ETK1, ETK2, and ETK3) are expressed by the following equations (eq.1) to (eq.3):
ETK1 = f (TK, Kpa1, TKFN3) (eq.1)
ETK2 = f (TK, Kpa2, TKFN1) (eq.2)
ETK3 = f (TK, Kpa3, TKFN2) (eq.3)
Here, Kpa = AES-G (Km, BN). Also, TK indicates a plaintext title key that is not encrypted, and the encryption processing function f uses the second parameter (BN1 to 3) and the third parameter (TKFN1 to 3) as the encryption key as the first parameter (TK). It shows that cryptographic processing is performed. For the encryption process f, a known encryption algorithm such as AES (Advanced Encryption Standard) may be used.

  That is, TKF1 is associated with TKF3, and the title key (TK) is encrypted with (BN1) and (TKFN3) of the associated TKF3. Further, TKF2 is associated with TKF1, and the title key (TK) is encrypted with (BN2) and (TKFN1) of the associated TKF1. Furthermore, TKF3 is associated with TKF2, and the title key (TK) is encrypted with (BN3) and (TKFN2) of the associated TKF2.

  Thus, the title key file TKF1 and the backup files TKF2 and TKF3 are associated with each other, and the encrypted title keys (E-TK1, E-TK2, E-TK3) are registered in its own file. (BN1, BN2, BN2) and (TKFN1, TKFN2, TKFN3) registered in other associated files are used to encrypt the title key (TK).

  By storing three TKFs and storing TKFN in a separate file as described above, even if one TKF is broken due to data corruption or the like, the broken data can be restored from the remaining two TKF data.

  It should be noted that unauthorized copying can be prevented by setting the above Binding Nonce as data that can be read and written only by a special drive command. That is, even if TKF is copied, the binding nonce associated therewith is not copied, so that it is possible to prevent unauthorized encryption / decryption by a malicious third party.

  The association between the title key file and the TKFN of the other backup files is not limited to the above formulas (eq.1) to (eq.3), but (eq.1) to (eq.1). 3) The title key file and the backup file TKFN may be associated with a pattern other than the formula.

  With reference to FIGS. 5, 6, and 7, data on the media necessary for AACS recording / reproduction processing will be described in detail. In the Protected Area on the medium 100, that is, the Protected Area of the file in which E-TK (or Kte) is stored, Binding Nonce and its backup data are stored. A Media ID is recorded in a BCA (Burst Cutting Area) in the read-only area of the medium 100, and Lead-in MKB is recorded in the lead-in area.

  In the user data area on the medium 100, management information that is information related to the copy protection pointer of the video object (VOB) and / or stream object (SOB) is stored. The user data area stores Read Write MKB, encrypted title key (E-TK), Media ID MAC, Usage Rule, and backup files thereof. Further, the user data area can store up to 1998 encrypted contents.

  It should be noted that the actual size of the correspondence information can be described at a location indicated by “−” in the size column of FIG. For example, the actual size of the Read / Write MKB can be written in the data size column of Read / Write MKB.

  FIG. 8 shows the structure of an encrypted title key file (E-TKF). FIG. 8 shows the E-TKF structure for the stream object (SOB), but the video object (VOB) has the same structure. In the byte position, the fixed information (STKF_ID, HR_STKF_EA) for specifying the title key file is described in 0 to 15 bytes, and the version number of TKF is described in “VERN” of 32 to 33 bytes. Yes.

  In 128 to 143 bytes, Title Key File Generation is stored, and in 144 to 159 bytes, Title Key File Nonce is stored. In 160 to 64095 bytes, 1998 sets of encrypted title key (E-TK or Kte) and Media ID MAC are described as Title Key Information (KTI).

  Each content is encrypted using one of the 1998 title keys. However, it is not necessary to record the Encrypted Title Key in all 1998 items, and an unused one is described by encrypting a numerical value of 0 by TK processing. The Title Key File Generation contains a value that is incremented each time this file is updated. As described above, the title key file has a total of three files for backup. If all the values of Title Key File Generation of these three files do not match, it means that there was some trouble during file writing.

  Next, a method for updating the title key file will be described. The types of media to which AACS is applied include rewritable media and write-once media. In a rewritable medium, for example, a new title key is added every time new content is recorded. Therefore, it is necessary to re-encrypt all title keys in the title key file using a new Kpa. That is, it is necessary to update the title key file.

  By the way, although the numerical value based on a random number called Binding Nonce is described in the protected area of the title key file, this Binding Nonce is used to prevent unauthorized decryption. Nonce is updated whenever the title key file is updated.

  On the other hand, in the write-once media, every time the title key file is updated, the title key file is written at a new address. For this reason, the address to which the Binding Nonce is written is also different each time. However, since AACS requires that the Binding Nonce be overwritten at the same location, in the case of a write-once medium, the title key file must not be updated. Therefore, the rewritable media and the write-once media have different title key file update conditions.

  In the Title Key File of FIG. 8, 1998 encrypted title keys are recorded. The content is encrypted using one of the 1998 keys. It is not necessary to record the Encrypted Title Key in all of 1998, and the unused one is to describe a value obtained by encrypting a numerical value “0” by TK processing. The Title Key File Generation contains a value that is incremented each time this file is updated. The Title Key File stores the title key. If the title key file cannot be read due to a defect on the media, the content cannot be reproduced at all. For this reason, three files are written for backup. If all the values of Title Key File Generation of these three files do not match, it means that there was some trouble during file writing.

  A numerical value based on a random number called Binding Nonce is recorded in the protected area of the address where the Title Key File is written on the medium 100. The protected area is an area that can be read and written only by a special command dedicated to AACS. By recording elements constituting Kpa in this portion, unauthorized descrambling using a personal computer or the like can be prevented.

The title key in Title Key File is the protected area key and Title Key FileNonce.
Encryption is performed by performing TK processing in combination with (TKFN). At this time, Title Key File Nonce of Title Key File # 2 is used for encryption of Title Key File # 1, and Title Key File Nonce of encryption of Title Key File # 2 is used. By doing so, even if one of the three Title Key Files is damaged, it can be restored by using the other two files. As described above, since the Title Key File Nonce is used for encryption of the title key, it is updated every time the Title Key File is updated.

  The Binding Nonce is also used for the encryption of the title key as data for generating the protected area key. Similarly, the Binding Nonce needs to be updated every time the Title Key File is updated.

  On the other hand, Binding Nonce depends on the address at which the file is written. In the case of write-once media such as HD_DVD-R, the Title Key File itself is stored at a new address each time, and the position where the Binding Nonce is written It ’s not one place. However, since AACS requires that the Binding Nonce be overwritten at the same location, the Title Key File is not updated for write-once media.

  The Title Key File can store 1998 encrypted title keys. This is consistent with the number of video objects (VOB) and stream objects (SOB), and it is assumed that the title key (Kt) is changed for each video object. This is because, for example, when content is moved from the disc to another medium, a loophole that can be illegally copied remains unless the title key used is erased. If the title key is deleted, other objects sharing the same title key cannot be decrypted, so it is necessary to assign a different key to each object as much as possible. Therefore, in the recording / playback apparatus, a new title key is generated for each recording process, and the video object and the stream object are encrypted with the title key.

  On the other hand, particularly in the case of recording by a stream object (SOB), it is necessary to dynamically divide the stream object according to the contents of the digital broadcast to be recorded. Specifically, when the constituent elements of the stream object (SOB) change, such as the number of audio streams changes at a program boundary, the SOB is automatically divided there. In such a case, it is practically impossible to switch the title key there. (If it is attempted to switch the title key, it takes time to generate a new key. Part of the recording is missing). In such a case, encryption using the same title key is continued.

  If the disc is a write-once medium (a medium that cannot be overwritten), the Title Key File cannot be updated, and therefore, an existing title key is used in the process of generating a key at the start of recording.

  When a rewritable medium (HD_DVD-RW / RAM or HDD) is used as the medium 100, the title key file update procedure of the rewritable medium is, for example, as follows. Here, it is assumed that a title key file has already been generated and written on the rewritable medium. This processing operation is realized by the control unit 210 of the information recording / reproducing apparatus 200 (or the key processing control unit 210 of FIG. 15 described later or the firmware of the CPU 11 of FIG. 21).

  For example, when the user turns on the information recording / reproducing apparatus 200 and inserts a rewritable medium, the MKB process and the TKF reading process are executed in a batch. In the MKB process, the signatures attached to the Read Write MKB and the Lead-in MKB are verified, and if it is determined that the verification result is valid, the version of each MKB is acquired. The Read Write MKB version must be the same as or newer than the Lead-in MKB version, otherwise it restricts playback and recording. In the TKF reading process, the title key file in the medium is expanded on the SDRAM or the like.

  Then, it is determined whether or not to update the title key file in response to the user's content recording operation, content editing operation, content deletion operation, media ejection operation, and power-off operation of the information recording / reproducing apparatus 200. That is, the title key file is updated only when at least one of the following three conditions is satisfied.

(1) When content is recorded and deleted When content is recorded and deleted, an Encrypted Title Key in the title key file is newly added or deleted. Therefore, the title key file is updated.

(2) When MKB is updated For example, when the version of Device MKB, which is the MKB held in the information recording / reproducing apparatus 200, is newer than the version of Read Write MKB, the value of Device MKB is changed to Read Write MKB. The media key (Km) of Device MKB is changed by copying. When Km is changed, Kpa is also updated. Therefore, the title key file is updated and the title key is re-encrypted.

(3) When only one of the three Title Key File Generations is different As described above, one of the three title key files is damaged. Therefore, the damaged title key file is repaired (updated) using the two remaining normal title key files. That is, when at least one of the above three conditions is satisfied, the title key file is updated. If all of the above three conditions are not satisfied, the process is terminated without updating the title key file.

  When a write-once medium (one-sided single-layer HD_DVD-R or single-sided two-layer HD_DVD-R: DL, etc.) is used as the medium 100, the write-on procedure of the title key file of the write-once medium is as follows, for example. This processing operation can be executed by the control unit 210 of the information recording / reproducing apparatus 200 or the like.

  For example, when the user turns on the information recording / reproducing apparatus 200 and inserts a write-once medium, the MKB process and the TKF reading process are executed in a batch. In the MKB process, the signatures attached to the Read Write MKB and the Lead-in MKB are verified, and if it is determined that the verification result is valid, the version of each MKB is acquired. The Read Write MKB version must be the same as or newer than the Lead-in MKB version, otherwise it restricts playback and recording. In the TKF reading process, the title key file in the medium is expanded on the SDRAM or the like.

  Then, in response to the user's content recording operation, content editing operation, content deleting operation, media ejecting operation, and power-off operation of the information recording / reproducing apparatus 200, it is determined whether to write the title key file. That is, if the following two conditions are satisfied, the title key file is written.

(1 *) When content is recorded (2 *) When a title key file is not recorded on the disc.

  In AACS, the Title Key File is required to be overwritten at the same location. Therefore, in the case of a write-once medium, the Title Key File is written only when the conditions (1 *) and (2 *) are satisfied. The reason for doing so is described below.

  If only the condition (1 *) is used, a write request occurs each time content is recorded, which causes a problem with write-once media that cannot be overwritten at the same location. Under the condition (2 *) alone, when no content is recorded on the disc, a valid content key has not been generated, so that a Title Key File with only an invalid Encrypted Title Key becomes a problem. When both of the conditions (1 *) and (2 *) are satisfied, writing is performed when the title key file is not recorded on the disc, so the effective Encrypted Title Key is 1 Only one Title Key File generated will be recorded.

  If both of the above two conditions are met, the title key file is written to the disc. If all of the above two conditions are not satisfied, the process is terminated without writing the title key file.

  According to the embodiment described above, the condition for writing the title key file is provided for each media type, and writing is performed on the disc only when the condition is met. According to this condition, in the case of a rewritable medium, the Title Key File is not updated unnecessarily, and the number of times of writing to the disk can be reduced. In the case of write-once media, writing a problematic title key file can be eliminated.

  FIG. 15 is a diagram for explaining an example of the configuration of a device in which the present invention is implemented and a data structure such as Index data held in the device. Here, an optical disc 100 in which MKB (Media Key Block) and TKF (Title Key File) are recorded as Media is used. When the disk 100 is loaded in the disk drive unit 300, information such as MKB and TKF is read from the disk 100. The read information such as MKB and TKF (information used in AACS) is sent to the key processing control unit 310. The key processing control unit (AACS processing unit) 310 sends MKB information and the like to the Media Key Block holding unit 320 and sends the Media Key and the like to the unique protection unit 330.

  The unique protection unit 330 (1) obtains the device key from the device key holding unit 340 and decrypts the original encryption to make the device key usable, and (2) the encryption unique to the Media Key. And (3) decrypting the unique encryption of the Media Key (see FIGS. 17 and 19 to be described later). The encrypted Media Key subjected to the unique encryption process is stored in the Media Key / Index holding unit (nonvolatile memory) 350 together with the corresponding Index information.

  The data structure of information stored in the media key / index holding unit 350 is illustrated on the right side of FIG. That is, the Media Key / Index holding unit 350 illustrated in FIG. 15 includes, in order from the top, Max_Index_count, Enc_Km pointer, and one or more index data (Index00 to Index4A: each data is composed of 8 bits). 2 digit Hex-decimal). Max_Index_count indicates the number of index data currently held in the Media Key / Index holding unit (nonvolatile memory) 350 of the device (the block configuration on the left side of FIG. 15). The Enc_Km pointer indicates the start position of the data of the encrypted media key Enc_Km on the memory constituting the Media Key / Index holding unit 350, and the Enc_Km pointer has the same number as the index data held. Each index data is paired with the data of the corresponding encrypted media key Enc_Km.

  When the encrypted media key held in the media key / index holding unit 350 can be used, the encrypted media key is decrypted, and the title key Kt is generated from the decrypted media key. Using the title key Kt, the encrypted content reproduced from the disc 100 is decrypted by the content decryption / encryption unit 360 and sent to the content reproduction unit 370. Alternatively, the content decrypting / encrypting unit 360 encrypts the content (to be protected by AACS) from the content receiving unit (digital TV tuner or the like) 380 using the generated title key Kt, and Send to part 300. The transmitted encrypted content is recorded on the disc 100.

The conditions necessary for the Media Key / Index holding unit 350 in FIG.
-Index data obtained from MKB;
-Media Key data in an encrypted state;
-The Media Key and Index data are associated with each other, and the position where the encrypted Media Key is extracted can be known from the Index data number.-The current number of Indexes can be grasped, and Indexes can be added as appropriate.

In addition, as an incidental condition (condition to be satisfied as much as possible) for the Media Key / Index holding unit 350 in FIG.
-If the correspondence between Index and encrypted Media Key is maintained, reordering each will not interfere with the decryption process or adding a new Index (encryption that associates previous and subsequent data Dependent encryption is not suitable for sorting)
There is.
The data structure illustrated on the right side of FIG. 15 has a configuration that satisfies both the above-described necessary conditions and incidental conditions.

  FIG. 16 is a diagram for explaining an example of the structure of encrypted data, and shows the data structure illustrated on the left side of FIG. 15 in more detail. In this example, a combination of BaseAddress and an address offset such as 00000000h or 00004000h is used as the address of the non-volatile memory constituting the Media Key / Index holding unit 350 in FIG. The storage position of data in the address range from the first Max_Index_Count to the last Enc_Km can be easily rearranged to an arbitrary position in the memory by changing BaseAddress. In addition, the storage position of Enc_Km linked to the Enc_Km pointer can be easily changed within this address range. For example, when extracting Enc_Km corresponding to Index03, data is extracted with “BaseAddress + Enc_Km pointer + 03h * 10h (size of Enc_Km)” as the head address. In this example, the correspondence between Index and Enc_Km depends on the “Index number” defined by the index sequence.

When configured as described above, the following advantages are obtained:
(I) Index and Enc_Km can be placed at a distance;
(B) Since it is not a fixed format, Enc_Km data can be moved to the optimal address even if the number of indexes increases in operation;
(C) If the Index and Enc_Km are sorted and operated so that the corresponding Index is higher (the one with the lowest address), the search efficiency of Enc_Km with high usage frequency and priority can be increased.

  FIG. 17 is a diagram for explaining an example of unique encryption processing of key information (Media Key) held in the device. The AES one-way function processing unit (input 128 bits: key 128 bits: output 128 bits) 170 receives a fixed value (128 bits) 171 and a random number (128 bits) 172 unique to the device. As the random number 172, for example, a set of keys issued by AACS for each device includes a random number value in addition to the key, and a part of the value can be used. The processing result of the AES one-way function processing unit 170 is output to the AES encryption processing unit (input 128 bit: key 128 bit: output 128 bit) 173 side. A Media Key (Km: 128 bit) 174 is input to the AES encryption processing unit 173. The AES encryption processing unit 173 encrypts the input information with AES using the processing result of the AES one-way function processing unit 170 as a key, and outputs an encrypted Media Key (Enc_Km) 175 (see FIG. 19). See later).

  Here, an encryption device other than AES (for example, an encryption device partially modified from AES) may be used as the encryption device itself, but this is not always necessary. Encrypted Media Key can be sufficiently protected by using a uniquely defined procedure based on AES used in AACS and a uniquely defined and secret key.

  FIG. 18 is a diagram for explaining an example of a unique decryption process of key information (Media Key) held in the device. The AES one-way function processing unit (input 128 bits: key 128 bits: output 128 bits) 180 receives a fixed value (128 bits) 181 and a random number (128 bits) 182 unique to the device. The processing result of the AES one-way function processing unit 180 is output to the AES decryption processing unit (input 128 bits: key 128 bits: output 128 bits) 183 side. An encrypted Media Key (Enc_Km: 128 bit) 184 is input to the AES decryption processing unit 183. The AES decryption processing unit 183 decrypts the input information with AES using the processing result of the AES one-way function processing unit 180 as a key, and outputs a decrypted Media Key (Km: 128 bit) 185 ( This will be described later with reference to FIG.

  FIG. 19 is a flowchart for explaining an example of the unique encryption processing procedure. First, Index data is acquired from an area handled as an MKB index (ST700), and the maximum index number (Max_Index_Count in the data structure of FIG. 15) of the nonvolatile memory (Media Key / Index holding unit 350) mounted on the device is incremented. (Max_Index_Count is incremented from 4Ah to 4Bh, for example) (ST702). Next, index data is written in the position of the maximum index number of the nonvolatile memory mounted on the device (ST704). Subsequently, the input is “random number unique to the device (172 in FIG. 17)” and the key is “fixed value (171 in FIG. 17) concealed in the hardware HW or firmware FW”. Function processing (170 in FIG. 17) is executed (ST706). When this processing is completed, the AES encryption processing (173 in FIG. 17) is executed with the input as “Media Key (Km) (174 in FIG. 17)” and the key as “the one-way function processing result in ST706”. (ST708). The encryption result of the process in ST708 is an encrypted Media Key (Enc_Km) (175 in FIG. 17) protected by a unique method (ST710). Then, the encrypted Media Key (Enc_Km) is written to the “Enc_Km pointer + 10h * Index” address of the nonvolatile memory (Media Key / Index holding unit 350) mounted on the device (ST712), and the original protection for the Media Key is made. Processing (encryption) is terminated.

  FIG. 20 is a flowchart for explaining an example of the unique decoding processing procedure. First, an Index address is acquired from the Index search result (ST800), and an encrypted Media Key (data in FIG. 15) corresponding to the Index address is read from a nonvolatile memory (Media Key / Index holding unit 350) mounted on the device. As shown in the structure example, Enc_Km paired with Index is acquired (ST803). Subsequently, the input is “equipment-specific random number (182 in FIG. 18)” and the key is “fixed value (181 in FIG. 18) concealed in hardware HW or firmware FW”. Function processing (180 in FIG. 18) is executed (ST806). When this processing is completed, the input is “encrypted Media Key (Enc_Km) (184 in FIG. 18)”, the key is “the result of the one-way function processing in ST806”, and the AES decryption processing (183 in FIG. 18). ) Is executed (ST808). The decryption result of the process of ST808 is Media Key (Km) (185 in FIG. 18) from which the protection of the unique method is released (ST810). In this way, the original protection process (decryption) for the Media Key is completed.

FIG. 9 is a flowchart for explaining an example of an MKB update process for a device or disk (when the device has an MKB update function). (In the device according to an embodiment of the present invention, it is essential to implement a function for updating the MKB of the disk, and the implementation of the function for updating the MKB on the device can be made optional. An embodiment in which both the implementation of the function to update and the implementation of the function to update the MKB on the device are essential is also possible.)
When the MKB process is started at the time of updating the MKB of the device (FIGS. 2, 3, 15, 21, etc.) or the disk 100, first, the MKB version information is acquired from the disk 100 (ST116). The obtained MKB version of the disc is compared with the MKB version held on the device (ST118). If the two versions are not different (in other words, the same) (NO in ST118), the process is terminated without updating the MKB.

  If the MKB version of the device is newer (one in the case of ST118 YES), the MKB of the disk 100 is updated. At this time, since TKF re-encryption occurs, both the media key of the device and the media key of the disc are required. The device's Media Key can be used that is uniquely protected (see ST142 described later).

  On the other hand, if the MKB version of the disc is newer (the other one in the case of ST118 YES), the MKB of the device is updated. That is, the MKB is obtained from the disk 100 (ST120), and the signature of the AACS_Verify MKB is verified (ST122). This signature verification will be described later with reference to FIG. If signature verification is not possible (NO in ST124), this MKB process ends abnormally. If the signature verification is OK (YES in ST124), the device key held on the device (device key holding unit 340 in the example of FIG. 15) is acquired (ST126). A processable node corresponding to the Device Key on the MKB is searched, and data corresponding to the found node is acquired (ST128). Media Key derivation is performed from the acquired data (ST130). As this calculation, AES (Advanced Encrypted Standard) processing is performed about 2 to 23 times (refer to the description of FIG. 2 for AES). After that, verification data on the MKB is verified (ST132). If the verification fails (NO in ST134), the MKB process ends abnormally. If the verification of the verification data is OK (YES in ST134), the media key of the disc 100 is acquired (ST136). The processing of ST120 to ST136 (processing for acquiring the media key of the disc) can be simplified by the processing described with reference to FIG.

  After obtaining the Media Key of the disk 100, the MKB version of the disk is compared with the MKB version held on the device (ST138). If the MKB version of the disc is newer than the MKB version of the device (YES in ST138), the MKB held on the device is updated (overwritten) with the MKB of the disc 100 (ST141). At this time, in addition to overwriting the MKB of the device, the Media Key is uniquely protected and held in the device together with the MKB (ST141). Here, since only one is uniquely protected as the Media Key of the MKB of the device, the old Media Key (the one to be protected uniquely) is discarded. However, without discarding, it is possible to leave the Index managed as one of the media keys processed in the past, similarly to the processing described with reference to FIG.

  If the MKB version of the disk 100 is not newer than the MKB version of the device (NO in ST138), the device uniquely acquires the Media Key (encrypted media key Enc_Km) on the device (ST142), and acquires the unique Media Key. The protection is released (that is, the encrypted media key is decrypted) (ST144). If “the device MKB media key holding function of the device” is not implemented (in the example of FIG. 15, the media key / index holding unit 350 is not installed in the device), here again (ST142). Media Key derivation processing is required. Therefore, the “MKB Media Key holding function of the device” is one of the important points in the embodiment of the present invention.

  After the Media Key with the original protection released is obtained, the TKF is re-encrypted (ST146). In this re-encryption, the media key of the disc is used as the decryption key, and the media key held in the device (the original protection is released) is used as the encryption key. Then, the MKB of the disk is updated with the MKB held on the device (ST148), and the MKB update process of the disk is completed.

  In the case of a device that does not have a function for updating the MKB of the device, the MKB incorporated when the device is shipped from the manufacturer and the corresponding uniquely protected Media Key continue to be used. FIG. 10 is a flowchart for explaining an example of an efficient Media Key derivation process when content on a disc is reproduced or content is recorded on the disc. First, the MKB Index information is acquired from the disc 100 (ST206), and the Index information held in the Media Key / Index holding unit 350 on the device is searched (ST208). If the Index corresponding to the search target is in the Media Key / Index holding unit 350 (YES in ST210), the uniquely protected Media Key on the device corresponding to the Index (corresponding to, for example, Index02 in the data structure example of FIG. 15) To obtain Enc_Km02) (ST212). Then, the original protection of the acquired Media Key is canceled (that is, the encrypted media key is decrypted, etc.) (ST214), and the MKB process is ended. Thereby, the acquisition of the Media Key is completed by a simplified process (ST212 to ST214) with less redundancy.

  When the index corresponding to the search target is not in the Media Key / Index holding unit 350 (NO in ST210), the MKB is acquired from the disc 100 (ST220), and the signature of the AACS_Verify MKB is verified (ST222). This signature verification is the same as the verification in ST122 of FIG.

  If signature verification is not possible (NO in ST224), the MKB process ends abnormally. In this case, the Media Key is not acquired. If the signature verification is OK (YES in ST224), the same processing as ST126 to ST134 in FIG. 9 (ST236 to ST244) is performed, and if the verification of Verification Data is OK (YES in ST244), the MKB processing is terminated. This completes the acquisition of the Media Key. The media key holding process is executed for the acquired media key (ST250). That is, the Index is acquired from the MKB (ST252), and the Media Key is concealed (encrypted) by an original protection method (ST254). Then, the pair of the acquired Index and the Media Key concealed by the original encryption is sequentially stored (accumulated) in the Media Key / Index holding unit 350 (ST256). When this storage is repeated, information on the data structure as shown on the right side of FIG. 15 is held in the Media Key / Index holding unit 350.

  FIG. 11 is a flowchart for explaining another example of an efficient Media Key derivation process in the case of reproducing content on a disc or recording content on a disc. First, MKB index information is acquired from the disk 100 (ST300), and the signature of the AACS_Verify MKB is verified (ST302). This signature verification is the same as the verification in ST122 of FIG.

  If signature verification is impossible (NO in ST304), the MKB process ends abnormally. In this case, the Media Key is not acquired. If the signature verification is OK (ST304 YES), the same processing (ST306 to ST314, ST336 to ST344) as ST206 to ST214 and ST236 to ST244 in FIG. 10 is performed, and if Verification of Verification Data is OK (ST344 YES). ), The MKB process ends, and the acquisition of the Media Key is thereby completed. The media key holding process is executed for the acquired media key (ST350).

  Note that the Media Key can be acquired in two ways, when the determination result of ST310 is yes and no. Of these, the processing of ST350 is executed only when the determination result of ST310 is no and the Media Key can be acquired thereafter. In that case, an Index is acquired from the MKB (ST352), and the Media Key is concealed (encrypted) by an original protection method (ST354). Then, the pair of the acquired Index and the Media Key concealed by the original encryption is sequentially stored (accumulated) in the Media Key / Index holding unit 350 (ST356). When this storage is repeated, information on the data structure as shown on the right side of FIG. 15 is held in the Media Key / Index holding unit 350. Note that the processes after ST336 (ST336 to ST344) in FIG. 11 are the same as ST126 to ST134 in FIG.

  FIG. 12 is a flowchart for explaining another example of an efficient Media Key derivation process in the case of reproducing content on a disc or recording content on a disc. Processes ST400 to ST414 and ST436 to ST456 in FIG. 12 correspond to processes ST300 to ST314 and ST336 to ST356 in FIG. 11, respectively. 11 differs from the processing in FIG. 12 in that verification data on the MKB is verified (ST432) after cancellation of the unique protection (ST414). If the verification of the verification data is OK (YES in ST434), the MKB process ends and the acquisition of the media key is completed. If this verification fails (NO in ST434), the process proceeds to ST436. Processes after ST436 (ST436 to ST444) are the same as ST126 to ST134 of FIG.

  FIG. 13 is a flowchart for explaining another example of an efficient Media Key derivation process in the case of reproducing content on a disc or recording content on a disc. Processes ST500 to ST504 and ST536 to ST556 in FIG. 13 correspond to processes ST300 to ST304 and ST336 to ST356 in FIG. 11, respectively. What differs from FIG. 11 is the processing of ST506 to ST514 of FIG. That is, the verification data of MKB is acquired from the disk 100 (ST506), and the verification data held on the device is searched (ST508). If there is Verification Data corresponding to the search target (YES in ST510), a uniquely protected Media Key on the device corresponding to the Verification Data is acquired (ST512). Then, the original protection of the acquired Media Key is released (ST514), and the MKB process is finished. Thereby, the acquisition of the Media Key is completed by the simplified processing (ST512 to ST514) with less redundancy. When there is no verification data corresponding to the search target (NO in ST510), the process proceeds to ST536. Processes after ST536 (ST536 to ST544) are the same as ST126 to ST134 of FIG.

  FIG. 14 is a flowchart (ST436 to ST444). Processes ST600 to ST604 and ST606 to ST656 in FIG. 14 correspond to processes ST500 to ST504 and ST506 to ST556 in FIG. 13, respectively. What is different from FIG. 13 is the version comparison process of ST605A to ST605B of FIG. That is, if Signature verification is OK in ST604, the MKB version is acquired from the disk 100 (ST605A). If this version is newer than the version number designated by the device at that time (or if it is the same version) (YES in ST605B), the process proceeds to ST606, and if older (No in ST605B), the process proceeds to ST636. Processes after ST606 (ST606 to ST614) are the same as ST506 to ST514 of FIG. Further, the processing after ST636 (ST636 to ST644) is the same as ST536 to ST544 in FIG. 13 or ST126 to ST134 in FIG.

  Note that the processing of ST605A to ST605B in FIG. 14 may be a size comparison process of the size of the media key block (MKB) (for example, the contents of the portion where “-” is shown in the size column of MKB in FIG. 7). . That is, the MKB size information is acquired (ST605A). If the size is larger than before (NO in ST605B), the process proceeds to ST636. If the size does not change from that before (ST605B Yes), the process of ST606 is performed. You may make it transfer to.

  FIG. 21 is a schematic overall configuration diagram showing a playback apparatus according to an embodiment of the present invention. The playback apparatus 10 includes a CPU (or MPU) 11, a RAM 12, a ROM 13, a signature verification input table 14 as an input database, and a disk drive 20. The playback apparatus 10 can be configured by a recording / playback apparatus such as an HD_DVD Recorder.

  The CPU 11 controls the processing operation of the playback device 10 according to a program (firmware) stored in the ROM 13. The CPU 11 loads the signature verification program stored in the ROM 13 and data necessary for executing the program into the RAM 12, and executes a signature verification operation according to the signature verification program. Further, the CPU 11 loads a drive control program stored in the ROM 13 and data necessary for executing the program into the RAM 12, and controls the operation of the disk drive 20 according to the control by the drive control program.

  The RAM 12 provides a work area for temporarily storing programs executed by the CPU 11 and data. The ROM 13 stores a playback program for the playback apparatus 10, a signature verification program, a drive control program, and various data necessary for executing these programs. The ROM 13 has a configuration including a magnetic or optical recording medium or a recording medium readable by the CPU 11 such as a semiconductor memory, and a part or all of the programs and data in the ROM 13 are downloaded via an electronic network. You may comprise.

  The Signature Verification Input Table 14 stores the hash value (compressed value) of the MKB data portion and the signature of the final block of the MKB (hereinafter, the hash value and signature are collectively referred to as input data) of the medium inserted in the past. To do.

  The disk drive 20 includes a CPU (or MPU) 21, a RAM 22, a ROM 23, and a pickup unit 24. The disk drive 20 can be configured by an optical disk drive such as HD_DVD. The processing operation of the disk drive 20 is controlled by the CPU 11 of the playback apparatus 10.

  The CPU 21 controls the processing operation of the disk drive 20 according to the program stored in the ROM 23. The CPU 21 loads the signature verification program stored in the ROM 23 and data necessary for executing the program into the RAM 22 and executes a process of performing signature verification according to the signature verification program. In addition, the CPU 21 loads the data stored in the ROM 23, the control program, and data necessary for executing the program into the RAM 22, and operates the pickup unit 24 according to the data read control program according to the control by the CPU 11 of the playback device 10. And the information recorded on the medium 1 is read.

  The RAM 22 provides a work area for temporarily storing programs executed by the CPU 21 and data. The ROM 23 stores, for example, a signature verification program, a data reading control program, and various data necessary for executing these programs. The ROM 23 has a configuration including a recording medium readable by the CPU 21 such as a magnetic or optical recording medium or a semiconductor memory, and a part or all of the programs and data in the ROM 23 are transmitted via an electronic network. It may be configured to be downloaded.

  The pickup unit 24 includes a laser oscillation unit, various lenses, and the like, irradiates a laser onto the information recording surface of the recording medium 1 under the control of the CPU 21 controlled by the CPU 11 of the reproducing apparatus 10, collects reflected light, Information on the reflected light is given to the disk drive 20. Based on the information of the reflected light, the CPU 21 reads information such as MKB recorded on the medium 1 by the reading control program, and gives this information to the reproducing apparatus 10.

  FIG. 22 is a schematic block diagram illustrating a configuration example of the CPU 11. The CPU 11 can function as at least a hash value calculation unit 11a, an input data search unit 11b, a signature verification calculation unit 11c, a signature verification determination unit 11d, and a final determination unit 11e by a signature verification program. Each of the means 11a to 11e uses a required work area of the RAM 12 as a temporary storage location for data.

  In describing the units 11a to 11e of the CPU 11, first, the configuration of the MKB used by the reproducing apparatus according to the present invention will be described. FIG. 23 is an explanatory view schematically showing how MKB data is handled in signature verification by the playback apparatus according to an embodiment of the present invention. As shown in FIG. 23, the MKB is configured to be within 1 Mbyte as a whole. Version information of 12 bytes is attached to the first block of the MKB. Some data may be recorded in the data portion of the MKB. An example of this data is Host Revocation List. Each data has a corresponding signature. For the last block of the MKB, a 40-byte signature (signature) having version information and a data portion as a message is added. This signature is created by a secret key held by AACS LA.

  Next, each means 11a-11e of CPU11 is demonstrated. The hash value calculation means 11a receives the MKB of the medium 1 from the disk drive 20 and compresses the data part of this MKB by performing a calculation according to SHA-1 (Secure Hash Algorithm 1: one of hash functions) to obtain 20 bytes. Has a function of generating a Hash value.

  The input data search means 11b receives the hash value of the data part of the MKB and the signature (input data) of the MKB from the hash value calculation means 11a, searches the input data according to the Signature Verification Input Table 14, and determines whether the same input data exists. It has a function to judge. Further, if there is the same input data, the input data search means 11b determines that the signature verification of the MKB of the medium 1 has succeeded, and gives this determination result to the final determination means 11e.

  The signature verification calculation means 11c has a function of performing signature verification calculation by EC-DSA for the MKB of the medium 1.

  The signature verification determination unit 11d has a function of receiving this calculation result, determining whether the signature verification is successful, and recording the input data corresponding to the Signature Verification Input Table 14 if successful. The signature verification determination unit 11d has a function of giving a determination result (success or failure) to the final determination unit 11e.

  The final determination unit 11e receives the determination result of the MKB signature verification of the medium 1 from the input data search unit or the signature verification determination unit 11d, and when the determination result is successful for the disk drive 20, the medium 1 has a function of giving permission to start reading of content 1 and controlling not to read content of the medium 1 when it is unsuccessful.

  Next, the operation of the reproducing apparatus 10 and the reproducing method according to the present invention will be described. FIG. 24 shows a case in which the CPU 11 of the playback apparatus 10 shown in FIG. 21 greatly reduces the time required for the second and subsequent signature verifications by holding necessary data for the signature that has been successfully verified once. It is a flowchart which shows the procedure of. In this flowchart, the medium 1 (corresponding to the optical disc 100 in FIGS. 1 to 3 or FIG. 15) is inserted into the disc drive 20, and the MKB of the medium 1 is read by the disc drive 20. It starts when the CPU 11 receives it.

  First, in step S1, the Hash value calculation means 11a compresses the MKB data part of the medium 1 received from the disk drive 20 by calculating with SHA-1 (Secure Hash Algorithm 1: one of hash functions). Then, a Hash value of 20 bytes is generated (see FIG. 23). Next, in step S2, the input data search means 11b receives the hash value of the data part of the MKB and the signature of the MKB from the hash value calculation means 11a, and searches the input data according to the signature verification input table 14.

  In step S3, the input data search means 11b determines whether or not there is the same input data as the input data derived from the MKB of the medium 1. If there is the same input data, it is determined that the signature verification of the MKB of the medium 1 has been successful, and this determination result is given to the final determination means 11e and the process proceeds to step S7. On the other hand, if there is no identical input data, the process proceeds to step S4.

  In step S4, the signature verification calculation unit 11c performs a signature verification calculation on the MKB of the medium 1 by EC-DSA. In step S5, the signature verification determination unit 11d receives the calculation result of the signature verification and determines whether the signature verification is successful. When it determines with having succeeded, it progresses to step S6. On the other hand, when it determines with having failed, this determination result is given to the final determination means 11e, and it progresses to step S8.

  Next, in step S6, the signature verification determination unit 11d records the input data derived from the MKB of the medium 1 in the Signature Verification Input Table 14, and gives the final verification unit 11e the determination result of the signature verification success. In step S7, the final determination unit 11e receives a determination result that the MKB signature verification of the medium 1 is successful from the input data search unit 11b or the signature verification determination unit 11d, and determines that the MKB of the medium 1 is a valid MKB. Subsequently, the final determination unit 11e transmits a signal giving permission to start reading the content of the medium 1 to the CPU 21 of the disk drive 20, and the series of signature verification is completed.

  In step S8, the final determination unit 11e receives the determination result that the MKB signature verification of the medium 1 has failed from the signature verification determination unit 11d, and determines that the MKB of the medium 1 is an illegal MKB. Subsequently, the final determination unit 11e transmits a signal for controlling the content of the medium 1 not to be read to the CPU 21 of the disk drive 20, and the series of signature verification is completed.

  With the above procedure, the time required for the second and subsequent signature verifications can be greatly shortened by holding the corresponding input data for a signature that has been successfully verified once. In addition, this signature verification increases the reliability of the MKB to be used (the risk that the MKB has been tampered with can be almost eliminated).

  According to the playback apparatus 10 shown in FIG. 21, by holding the corresponding input data for a signature that has been successfully verified once, only the input data is compared in the second and subsequent signature verifications. The validity of the signature can be determined. The only calculation required to derive the input data is SHA-1, and this calculation can be completed in a much shorter time than the signature verification operation by EC-DSA. Therefore, for a signature that has been successfully verified once, the time required for the second and subsequent signature verifications can be greatly reduced, and the time from insertion of a recording medium to reading of the contents of the recording medium can be greatly increased. It can be shortened.

  In the playback device 10 and the playback method using the playback device 10, the MKB data portion of the MKB input data recorded in the Signature Verification Input Table 14 is held as a Hash value compressed by the Hash function. . Therefore, for a signature that has been successfully verified once, all MKB data (message (Version information and data part) and Signature), which is originally a maximum of 1 Mbyte, must be retained as data necessary for the second and subsequent signature verifications. It is not necessary to store a small amount of input data.

  Further, as the hash value of the input data, an MKB message (Version information and data part) compressed with SHA-1 may be used. In this case, the input data reflecting all the data of the MKB is held. However, since the calculation result of the Hash function is always 20 bytes, the capacity as the input data does not change at 20 bytes.

  Note that the same effect can be obtained by performing the above procedure when performing signature verification on the signature attached to the data existing in the data portion of the MKB instead of the signature added to the final block of the MKB. Can be obtained. In this case, the input data includes a hash value of only data in the data portion or a data portion of data and version information converted to a hash value by SHA-1, and a signature attached to the data of the data portion. The generic name of In this case, the final determination unit 11e determines whether the signature is valid based on the determination result of the signature verification, and determines whether the CPU 11 and the CPU 21 are permitted to use the data with the signature.

  Further, the signature verification similar to the signature verification by the CPU 11 of the playback apparatus 10 can be performed on the CPU 21 of the disk drive 20. This is because the CPU 21 of the disk drive 20 functions as at least a hash value calculation unit 21a, an input data search unit 21b, a signature verification calculation unit 21c, a signature verification determination unit 21d, and a final determination unit 21e according to the signature verification program. This is because the same effect as the means having the same name of the CPU 11 can be obtained.

  In general, the disk drive 20 is inferior in CPU processing capacity and memory size in comparison with the playback apparatus 10. Therefore, if the above procedure is applied to the CPU 21 of the disk drive 20, the processing time can be reduced by skipping unnecessary signature verification processing, and the storage area can be reduced by converting the input data into hash values. I can expect.

  FIG. 25 is an explanatory view schematically showing an update mode of the input data recorded in the Signature Verification Input Table 14 of the playback apparatus 10 according to the embodiment of the present invention. The input data that can be stored in the Signature Verification Input Table 14 is finite. Therefore, when the capacity of the predetermined Signature Verification Input Table 14 is exceeded, it is necessary to delete any of the already recorded input data in order to record new input data.

  For example, when the hash value of the input data is an MKB message (Version information and data part) compressed with SHA-1, as shown in FIG. 25, the MKB Version information is compared, and the Version information The oldest one may be deleted (overwritten). Alternatively, the number of insertions of the recording medium may be stored in association with the input data and deleted (overwritten) from the one with the smallest number of insertions. Alternatively, the previous access time may be stored in association with the input data, and the previous access time may be deleted (overwritten) from the oldest input data. Furthermore, these deletion methods may be implemented in any combination.

  The method described above with reference to FIGS. 21 to 25 is an example of a method for improving the efficiency of signature verification by holding signature data and a hash value, which is data in the middle of the calculation, in the device. This method can be used, for example, in the process of ST302 in FIG.

  The embodiment of the present invention can also be applied to a Player device that handles AACS Pre-recorded Media. However, since the MKB is not updated in the Player device, the effect of implementing the present invention is greater when mounted on the Recorder device.

  By the way, a device that handles AACS Recordable Media uses a Media Key as one of keys for encryption / decryption processing. Media Key is stored secretly by using encryption technology in Media Key Block (MKB) stored in one AACS Recordable Media, and encrypted from MKB using data such as Device Key assigned to the device. Derived using an artificial process. There is a one-to-one correspondence between MKB and Media Key, and one Media Key is derived from one MKB through proper processing. The MKB and the Media Key included therein are not different for each AACS Recordable Media, and are often the same for discs of the same product type produced at the same time.

  A device that handles AACS Recordable Media also has an MKB on the device. If the MKB version on the AACS Recordable Media is older than the MKB stored in the device, the MKB on the AACS Recordable Media is rewritten. Process. On the other hand, depending on the device, when an MKB whose version is newer than the MKB on the device is detected, the MKB on the device may be replaced with the latest MKB.

  Due to such processing, there is a possibility that the MKB placed in the AACS Recordable Media is always replaced with the latest one possessed by the Recorder device. For this reason, the MKB handled by each Recorder is not necessarily different every time, and the same MKB may be processed many times. Some similar copyright protection technologies do not define replacement of MKB, but the possibility of repeatedly processing the same MKB is higher than that.

An outline of the MKB process is as follows, for example. (See Figure 9)
1. Validity verification of MKB (AACS_Verify) (ST122)
2. Search for a node in the MKB that can be operated by the Recorder (a process for selecting a Device Key that can be used for processing the MKB from 253 Device Keys held, or a process for searching for data that can be processed on the MKB) ( ST128)
3. Derivation of Media Key (2 to 23 times AES processing) (ST130)
4). Validity verification of the derived Media Key (AES processing) (ST132).

These processes are required when using the Media Key. For example, there are the following opportunities to use the Media Key:
1. Decryption of Title Key (during content playback, content recording / editing, MKB update on disk)
2. Title Key encryption (during content recording / editing, MKB update on disk).

  When updating the MKB, both the MKB on the disk and the MKB on the device are processed, the title key is decrypted by the media key on the disc, and the re-encryption is performed by the media key on the device. Replace the MKB on the disk with the one on the device.

  Media Key is data that is required to be concealed and protected according to the AACS standard. For this reason, when the Media Key is held on a device such as a High Definition Digital Video Recorder, it is necessary to hold the Media Key in a state protected by, for example, a uniquely defined protection method. Similar data is Device Key. Since an AACS-compliant device is obliged to keep the Device Key secret on the device, for example, if protection is provided to the same extent as the Device Key, the protection requirement of the Media Key according to the AACS standard can be satisfied. This confidentiality protection request does not apply to the MKB itself, so the index data or verification data need not be concealed, and only the Media Key should be concealed (however, other than the Media Key may be concealed) Not that you can't.)

<Summary>
(Point 1) Normally, if the MKB on the disk is older than the MKB on the Recorder and the disk is a rewritable medium, the MKB on the disk is updated and replaced. It is necessary to derive the Media Key from the latest MKB. However, this processing is redundant because the same calculation is performed every time and the same result is obtained unless the latest MKB held is changed. In the embodiment of the present invention, processing is simplified as shown in ST140 to ST141 (device MKB update) or ST142 to ST148 (media MKB update) in FIG. 9 by using a uniquely protected Media Key.

  (Point 2) Normally, the process for deriving the Media Key from the MKB on the disk is as shown in ST220 to ST244 in FIG. In point 2, first, when the Recorder needs to process the MKB, it is determined whether the MKB has been processed in the past and is an MKB holding a Media Key in the Recorder. If the MKB has not been processed in the past (NO in ST210), normal MKB processing (ST220 to ST244) is executed to acquire the Media Key. Subsequently, Index information indicating the acquired Media Key and MKB characteristics is held on the Recorder (ST250 to ST256). In this case, it is desirable that the Media Key value be protected by a unique method such as encryption (ST254).

  Next, when the Recorder needs to process the MKB, there is Index information corresponding to the MKB to be processed on the Recorder (Yes in ST210), and it is considered that the MKB has been processed in the past. The Media Key concealedly held on the Recorder corresponding to is obtained through a process such as decryption (ST212 to ST214) and used as a Media Key equivalent to that obtained from the MKB on the disc (see FIG. 10). At this time, the information used as the index is preferably a part of the MKB data other than a part where a fixed value such as a header is easily entered.

  (Point 3) At the point 3, in addition to the processing at the point 2, the signature of the MKB is verified (see FIG. 24) to prevent falsification. In the case of the implementation of only point 2, it is possible to process the disguised MKB by rewriting the value of the MKB and impersonating the data used for the index. However, by verifying the signature, the MKB including the index can be processed. It can be assured that the whole has not been tampered with (see FIG. 11).

  (Point 4) At the point 4, when using the Media Key held on the Recorder by the processing at the point 2 or 3, the verification of the verification data of the MKB performed in the normal Media Key derivation is performed. , Guarantee the validity of Media Key. Thereby, it is possible to avoid confusion when Index data coincides accidentally in different MKBs. In addition, this makes it possible to hold a Media Key with the same index and identify a valid Media Key based on the verification result of Verification Data. As a result, it is possible to make the index bit length shorter. When verification of verification data fails, normal MKB processing is performed. As a result, even in exceptional circumstances such as when the index is shortened or when the stored data is damaged, it can be guaranteed that the media key is finally correctly derived (see FIG. 12).

  (Point 5) At the point 5, the processing of the point 2 or the point 3 has Verification Data as an index on the device. In this way, verification on the verification data can be simultaneously simplified by performing a comparison on the index and confirming a match. In particular, if signature verification is performed as performed at point 3, the possibility that the verification data of the MKB to be processed has been falsified can be eliminated, which is preferable as an implementation of the embodiment of the present invention (FIG. 13).

  (Point 6) At point 6, the MKB Media Key held on the point 1 device is added to the list of Media Key and Index pairs held on the Recorder device. Since point 1 deals with the update of the MKB on the disk using the MKB held by the device, the index is not used, but when the MKB is updated by holding the index in the same manner as in points 2 to 6. In addition, the corresponding Media Key can be used at the time of reproduction, and the data to be held can be saved slightly compared to the point 1 processing and the point 2 to point 5 processing separately implemented.

  (Point 7) In points 2 to 6, derivation of Media Key using Index is shown. However, as described above, the MKB handled on the Recorder device and the usage frequency of Media Key derived therefrom are not necessarily uniform. . This depends on the user's preference, but there is also an element that can be used to infer a Media Key with a high use probability and a Media Key with a low use probability. For example, since an MKB that has been written in the Media is likely to be used again after that, the priority of searching for the corresponding Media Key is increased to improve efficiency. Alternatively, when the Media Key acquired from the MKB detected on the Recordable Media is used to update the MKB, the search priority is lowered to improve efficiency. On the other hand, when the Media Key acquired from the MKB detected on the Recordable Media is not updated for the Media, a method of increasing the search priority and improving the efficiency can be considered. It is also possible to simply record the frequency of using the Media Key for playback and recording, and increase the search priority for those that are frequently used to improve efficiency.

  Further, even when it is desired to limit the number of Media Keys or Indexes held on the device, if such a priority order exists, it can be a guideline for selection. For example, various implementations are possible, such as holding the Media Key for the MKB written from the device to the disk, but not holding the MKB just read from the disk. In the embodiment of the present invention, there is no restriction on how individual priorities are assigned, and the priority order of Media Key data depends on the processing performed on the Media and the processing performed inside the device. It is the subject of the invention to change.

  (Point 8) The processing load of a normal MKB varies depending on the complexity of the structure inside the MKB. This varies depending on the size of the MKB and the version shown in the MKB. Therefore, the processing of point 2 to point 5 is applied only to a large size, a large (new) version value, or a specific version. On the other hand, when it is expected that the processing load is low even if the normal MKB processing is executed, the processing load is reduced by performing the normal processing (see FIG. 14).

<Effect of Embodiment>
By holding the past processing results of Media Key and processing that uses Verification Data as an Index, the MKB processing in a device using AACS (next-generation high-definition video recorder or the like) can be simplified. In addition, the efficiency of data retrieval and retention can be improved by setting the priority of the retained Media Key. Further, it is possible to indicate a data sorting criterion suitable for MKB processing.

  By implementing the present invention in the Recorder in which AACS is implemented, when the structure of the MKB is complicated, it is possible to reduce the processing at the start, end or start of recording.

  By combining Signature and Hash inside the device to simplify the signature verification process and using Signature or the like as an Index, it becomes possible to derive the Media Key simultaneously with the simplified signature verification.

  By retaining the past processing results of the Media Key and processing the verification data as an index, the MKB processing in the AACS Recorder can be simplified. In addition, the efficiency of searching and holding data can be improved by setting the priority of the media key to be held.

  The present invention is not limited to the above-described embodiment, and can be variously modified within the scope of the gist of the present invention or a future implementation stage based on the technology available at that time. It is. For example, the information storage medium used in the embodiment of the present invention is not limited to an optical disk or a hard disk drive, and a large-capacity flash memory or the like may be used. The system in which the present invention can be implemented is not limited to HD_DVD, and may be a next-generation digital recording / reproducing system of another standard using a blue or blue-violet laser.

  In addition, the embodiments may be appropriately combined as much as possible, and in that case, the combined effect can be obtained. Further, the above embodiments include inventions at various stages, and various inventions can be extracted by appropriately combining a plurality of disclosed constituent elements. For example, even if some configuration requirements are deleted from all the configuration requirements shown in the embodiment, a configuration from which these configuration requirements are deleted can be extracted as an invention.

The figure explaining the structure of the data (title key file) in the medium (information recording medium) concerning one embodiment of this invention. The figure explaining the process example which decodes the encryption content recorded on the medium. The figure explaining the example of a process which encrypts a content and records on DVD. Explanatory drawing which shows the structure of a title key file as a title key file and its backup file. The figure which shows the data on the media required by the recording / reproducing process using the encryption system (AACS system) employ | adopted by one embodiment of this invention. The figure which shows the data on the media required by the recording / reproducing process of an AACS system. The figure which shows the data on the media required by the recording / reproducing process of an AACS system. The figure which shows the structural example of the encrypted title key file (E-TKF or Kte # 0- # n file). The flowchart figure explaining an example (when the MKB update function is mounted in the apparatus) of an MKB update process. The flowchart figure explaining an example of the efficient Media Key derivation | leading-out process in the case of reproducing | regenerating the content on a disc or recording a content on a disc. The flowchart figure explaining the other example of the efficient Media Key derivation | leading-out process in the case of reproducing | regenerating the content on a disc or recording a content on a disc. The flowchart figure explaining the other example of the efficient Media Key derivation | leading-out process in the case of reproducing | regenerating the content on a disc or recording a content on a disc. The flowchart figure explaining the other example of the efficient Media Key derivation processing in the case of reproducing the contents on a disk or recording the contents on a disk. The flowchart figure explaining the other example of the efficient Media Key derivation | leading-out process in the case of reproducing | regenerating the content on a disc or recording a content on a disc. The figure explaining an example of data structures, such as the structure of the apparatus with which this invention is implemented, and Index data currently hold | maintained at the apparatus. The figure explaining an example of the structure of encryption data. The figure explaining an example of the original encryption process of the key information (Media Key) hold | maintained at an apparatus. The figure explaining an example of the original decoding process of the key information (Media Key) hold | maintained at an apparatus. The flowchart figure explaining an example of an original encryption process sequence. The flowchart figure explaining an example of an original decoding process sequence. 1 is a schematic overall configuration diagram of a playback apparatus according to an embodiment of the present invention. 1 is a schematic block diagram showing a configuration example of an information processing unit of a playback device according to an embodiment of the present invention. The figure which illustrates typically how to handle the data of MKB in signature verification in one embodiment of this invention. The flowchart figure explaining the procedure at the time of shortening significantly the time required for the signature verification of the second time and later by holding required data about the signature which signature verification succeeded once. The figure which illustrates typically the aspect of the update of the input data recorded on Signature Verification Input Table in one embodiment of this invention.

Explanation of symbols

  DESCRIPTION OF SYMBOLS 100 ... Information storage medium (optical disk); 200 ... Information recording / reproducing apparatus; 210 ... Control part; 220 ... Reading part; 230 ... Writing part; 300 ... Disk drive part; 310 ... Key process control part (AACS processing part); ... Media Key Block holding part; 330 ... Unique protection part; 340 ... Device key holding part; 350 ... Media Key / Index holding part (nonvolatile memory).

Claims (10)

In a method for generating a protected area key from a media key and random number data, and generating a title key used for encryption or decryption of content from a title key file including an encrypted title key and the protected area key,
A device that uses the title key has a uniquely protected encrypted media key corresponding to the media key,
Information recorded by the media key encrypted and recorded by a method different from the original protection is used as a media key block, and the media to be recorded or reproduced by the device has the media key block. An encryption information processing method in which the device uses the held encrypted media key when information on a media key block is held on the device to update a block. In a method for generating a protected area key from a media key and random number data, and generating a title key used for encryption or decryption of content from a title key file including an encrypted title key and the protected area key,
The media key is converted into an encrypted media key by original protection,
When the media key is information recorded by encrypting and recording the media key different from the original protection as a media key block, the device using the title key identifies the encrypted media key and the medium for identifying the encrypted media key. Holds a list of indexes using data on the key block,
When performing the process of deriving the media key, the index list is referenced using predetermined index information, and if there is an index corresponding to the predetermined index information in the index list, Correspondingly, the uniquely protected encrypted media key held by the device is obtained, the unique protection of the obtained encrypted media key is canceled, and the media key whose unique protection is released is the title Cryptographic information processing method used for key generation.   When an electronic signature is added to the information of the media key block, the signature is verified to determine whether the information of the media key block is valid or illegal. Item 3. The method according to Item 2.   The method according to claim 2 or 3, wherein the validity of the media key is ensured by performing verification on the media key block performed in the process of deriving the media key.   If the device has predetermined verification data and the device has the uniquely protected encrypted media key corresponding to the predetermined verification data when processing the media key block, The encrypted media key corresponding to the predetermined verification data is acquired, the original protection of the acquired encrypted media key is canceled, and the media key whose original protection is released is used to generate the title key. 4. A method according to claim 2 or claim 3 for use. The media key is converted into an encrypted media key by original protection,
When information recorded by encrypting and recording the media key differently from the original protection is used as a media key block, the device using the title key obtains the encrypted media key derived in the past and The method according to claim 1, wherein a list of indexes using data on the media key block to be identified is maintained, and information on the media key of the media key block stored on the device is added to the list.   Depending on the processing performed by the device on a predetermined medium, the processing performed inside the device, or the type of the media, the priority of search and / or retention of the media key held on the device is increased or decreased. The method according to any one of claims 2 to 6, wherein the method is performed.   7. The size or version information of the media key block is acquired, and whether to perform processing using the encrypted media key is determined according to the value. Method. In an apparatus for generating a protected area key from a media key and random number data, and generating a title key used for encryption or decryption of content from a title key file including an encrypted title key and the protected area key,
Means for holding a uniquely protected encrypted media key corresponding to the media key;
A cryptographic information processing apparatus comprising means for decrypting the original protection of the stored encrypted media key. In an apparatus for generating a protected area key from a media key and random number data, and generating a title key used for encryption or decryption of content from a title key file including an encrypted title key and the protected area key,
Means for converting the media key into an encrypted media key by original protection;
Means for holding a list of the encrypted media key and an index for identifying the media key when information recorded by the media key encrypted and recorded by a method different from the original protection is a media key block;
The index list is referenced using predetermined index information, and when there is an index corresponding to the predetermined index information in the index list, the encrypted media key is acquired corresponding to the index, Means for releasing the original protection of the obtained encrypted media key;
An encryption information processing apparatus comprising means for using the media key, for which the unique protection has been released, for generating the title key.

Images