Data processing apparatus, method and program providing medium

[0001] [Technical field to which the invention belongs] The present invention relates to a data processing apparatus, a data processing method, and a program providing medium. In particular, by using a hierarchical key distribution method with a tree structure, the amount of messages can be kept small, the load of distribution of content keys or other encryption processing keys can be reduced, and data security can be maintained. Link count data indicating the number of contents to which the encryption processing key that can be obtained based on the EKB distribution key encryption key (KEK) encrypted by the activation key block (EKB) is applied is included in the header. The present invention relates to a data processing device and a data processing method that enable efficient content processing by storing a distribution key permission information file as information in a storage device, and a program providing medium. [0002] [Conventional technology] Recently, various software data such as music data, game programs, image data, etc. (hereinafter, these are referred to as contents) can be stored in a network such as the Internet or a memory card, DVD, CD, etc. that can be distributed. Content distribution that is distributed via media is becoming popular. For these distributed contents, the content playback process is executed by receiving the content data on the user's personal computer (Personal Computer), playback-only device, or game device, or by installing a storage medium such as a memory card, CD, or DVD. Alternatively, it is used by storing the input content from the outside in a recording device built in a player, a PC, or the like, for example, a memory card, a hard disk, or the like, and playing it back from the storage medium. [0003] Information devices such as playback devices, game devices, and PCs have interfaces for receiving distribution content from networks or accessing DVDs, CDs, etc., and control means and programs required for content playback. , Has RAM, ROM, etc. used as a data memory area. [0004] Various contents such as music data, image data, and programs are instructed by a user from an information device such as a playback device, a game device, or a PC used as a playback device, or a user's instruction via a connected input means. Is called from, for example, a built-in or detachable storage medium, and is reproduced through the information device main body, a connected display, a speaker, or the like. [0005] Many software contents such as game programs, music data, and image data generally have distribution rights to their creators and sellers. Therefore, when distributing these contents, certain usage restrictions, that is, permission to use the software only to legitimate users and preventing unauthorized copying, that is, security is taken into consideration. It is common to take a structure like this. [0006] One method of implementing usage restrictions for users is the encryption process of distributed content. That is, for example, various contents such as voice data, image data, and game programs encrypted via the Internet are distributed, and the distributed encrypted contents are distributed only to those who are confirmed to be legitimate users. It is a means for decrypting, that is, a configuration in which a decryption key is given. [0007] The encrypted data can be returned to usable decrypted data (plaintext) by the decryption process according to a predetermined procedure. Data encryption and decryption methods that use an encryption key for such information encryption processing and a decryption key for decryption processing have been well known. [0008] There are various types of data encryption / decryption methods using an encryption key and a decryption key, and one example thereof is a so-called common key encryption method. In the common key encryption method, the encryption key used for data encryption processing and the decryption key used for data decryption are shared, and a common key used for these encryption processing and decryption is given to a legitimate user. Therefore, data access by an unauthorized user who does not have the key is excluded. DES (Deta encryption standard) is a typical method of this method. [0009] The encryption key and decryption key used for the above-mentioned encryption process and decryption can be obtained by applying a one-way function such as a hash function based on, for example, a certain password. A one-way function is a function that makes it very difficult to obtain an input from its output. For example, a one-way function is applied by inputting a password determined by a user, and an encryption key and a decryption key are generated based on the output. On the contrary, it is virtually impossible to obtain the password, which is the original data, from the encryption key and the decryption key obtained in this way. [0010] Further, a method in which the processing by the encryption key used at the time of encryption and the processing of the decryption key used at the time of decryption are different algorithms is a so-called public key cryptosystem. The public key cryptosystem is a method of using a public key that can be used by an unspecified user, and encrypts an encrypted document for a specific individual using the public key issued by the specific individual. A document encrypted by a public key can be decrypted only by a private key corresponding to the public key used in the encryption process. Since the private key is owned only by the individual who issued the public key, the document encrypted by the public key can be decrypted only by the individual who has the private key. RSA (Rivest-Shamir-Adleman) encryption is a typical public key cryptosystem. By using such an encryption method, it is possible to create a system in which encrypted contents can be decrypted only by a legitimate user. [0011] [Problems to be Solved by the Invention] In the above-mentioned content distribution system, the content is encrypted and stored in a network or a recording medium such as a DVD or CD and provided to the user, and the content key for decrypting the encrypted content is provided only to a legitimate user. Is widely adopted. It is possible to encrypt the content key to prevent unauthorized copying of the content key itself and provide it to legitimate users, and to decrypt the encrypted content key using the decryption key that only the legitimate user has and use the content key. The configuration to be used is proposed. [0012] The determination as to whether or not the user is a legitimate user is generally performed, for example, by executing an authentication process before distribution of the content or the content key between the content provider which is the sender of the content and the user device. In the general authentication process, the other party is confirmed and a session key valid only for the communication is generated. When the authentication is successful, the generated session key is used to generate data, for example, content or content key. Encrypt and communicate. There are two types of authentication methods: mutual authentication using a common key cryptosystem and authentication method using a public key method. However, authentication using a common key requires a system-wide common key and is used for update processing. It is inconvenient in such cases. Further, in the public key system, the calculation load is large and the required memory amount is also large, so it is not desirable to provide such a processing means in each device. [0013] The present invention provides a hierarchical key distribution tree that enables secure transmission of data only to legitimate users without relying on mutual authentication processing between the sender and receiver of data as described above. EKB distribution key encryption key encrypted by activation key block (EKB) while providing a system using an encryption key block that realizes a management configuration that uses and securely distributes keys only to devices with a legitimate license. Efficient content processing is possible by storing the distribution key permission information file that has link count data indicating the number of contents to which the encryption processing key that can be acquired based on (KEK) is applied as header information in the storage device. It is an object of the present invention to provide a data processing apparatus and a data processing method, and a program providing medium. [0014] [Means for solving problems] The first aspect of the present invention is In a data processing device that reproduces content from a storage device or records content on the storage device.<u style="single">Including the data processing device</u>Root on the path from the root of the tree consisting of multiple devices as a leaf to the leaf, a node, and an update key on the path that constitutes a key tree with a key associated with each leaf, and encryption of the upper key by a lower key Has an EKB delivery key encryption key (KEK) encrypted by an activation key block (EKB) that contains the encrypted data, Distribution key permission that has link count data as header information indicating the number of contents to which the encryption processing key that can be acquired based on the EKB distribution key encryption key (KEK) stored in the activation key block (EKB) is applied. The data processing device is characterized in that the information file is stored in the storage device. [0015] Further, in one embodiment of the data processing apparatus of the present invention, the distribution key permission information file is the content.<u style="single">Cryptographic key</u>The content key Kcon that is<u style="single">EKB delivery</u>The content key encrypted by the key encryption key (KEK) The encrypted data: E (KEK, Kcon) is included in the configuration. [0016] Further, in one embodiment of the data processing apparatus of the present invention, the data processing apparatus applies an encryption processing key that can be acquired based on the EKB distribution key encryption key (KEK) stored in the activation key block (EKB). It is characterized by having a configuration for executing a process of updating the link count data in the distribution key permission information file according to a change in the number of target contents. [0017] Further, in one embodiment of the data processing device of the present invention, the data processing device is converted into a distribution key permission information file having a large number of counts indicated by link count data in a plurality of distribution key permission information files stored in the storage device. Obtained by executing the decryption process of the included EKB distribution key encryption key (KEK)<u style="single">Key encryption key (KEK)</u>It is characterized in that it is configured to store and retain in memory. [0018] Further, in one embodiment of the data processing device of the present invention, the data processing device is converted into a distribution key permission information file having a large number of counts indicated by link count data in a plurality of distribution key permission information files stored in the storage device. Obtained by executing the decryption process of the included EKB distribution key encryption key (KEK)<u style="single">Key encryption key (KEK)</u>Is stored and held in the memory, and in the processing of the content stored in the storage device, the applicability of the key encryption key (KEK) stored in the memory in advance is determined, and if applicable, the key encryption key (KEK) is stored in the memory in advance. It is characterized in that it has a configuration in which a stored key encryption key (KEK) is used and the distribution key permission information file is read only when it is not applicable. [0019] Further, in one embodiment of the data processing apparatus of the present invention, the EKB distribution key encryption key (KEK) encrypted and provided by the activation key block (EKB) is generation (version) managed for each generation. It is characterized in that the update process is executed. [0020] Further, in one embodiment of the data processing device of the present invention, the data processing device is<u style="single">A plurality of devices including the data processing device</u>In the key tree configuration in which the key is associated with each of the root, node, and leaf on the path from the root of the tree configured as a leaf, the leaf key set corresponding to the self-leaf is unique to the data processing device. It is characterized by having a configuration in which it is encrypted with the storage key (Kstd) of the above and stored in the storage means in the data processing device. [0021] [0021] Further, in one embodiment of the data processing device of the present invention, the data processing device is<u style="single">A plurality of devices including the data processing device</u>In the key tree configuration in which the key is associated with each of the root, node, and leaf on the path from the root of the tree configured as a leaf to the leaf, the key tree is based on the leaf key set corresponding to the self leaf. It has a configuration in which a device key block (DKB) as a set of encryption keys in which multiple different node keys on the path from the self-leaf to the upper level are individually encrypted is stored in a storage means in the data processing device. It is a feature. [0022] Further, the second aspect of the present invention is<u style="single">In the data processing device</u>A data processing method for playing back content from a storage device or recording content on a storage device.<u style="single">And</u><u style="single">Including the data processing device</u>Root on the path from the root of the tree consisting of multiple devices as a leaf to the leaf, the node, and the update key on the path that constitutes the key tree with each key associated with the leaf, and encryption of the upper key by the lower key EKB distribution key encrypted by the activation key block (EKB) containing the encryption processing data The link count data indicating the number of contents to which the encryption processing key that can be obtained based on the encryption key (KEK) is applied is included in the header information. The data processing method is characterized in that the distribution key permission information file held as is stored in the storage device. [0023] Further, in one embodiment of the data processing method of the present invention, the distribution key permission information file is the content.<u style="single">Cryptographic key</u>The content key Kcon that is<u style="single">EKB delivery</u>The content key encrypted by the key encryption key (KEK) The encrypted data: E (KEK, Kcon) is included in the configuration. [0024] Further, in one embodiment of the data processing method of the present invention, the number of contents to which the encryption processing key that can be acquired based on the EKB distribution key encryption key (KEK) stored in the activation key block (EKB) is applied. It is characterized in that a process of updating the link count data in the distribution key permission information file is executed according to the change. [0025] Further, in one embodiment of the data processing method of the present invention, the data processing method further increases the number of counts of the distribution key permission information indicated by the link count data in the plurality of distribution key permission information files stored in the storage device. Obtained by executing the decryption process of the EKB distribution key encryption key (KEK) included in the file<u style="single">Key encryption key</u>Is stored and held in memory. [0026] Further, in one embodiment of the data processing method of the present invention, the data processing method further increases the number of counts of the distribution key permission information indicated by the link count data in the plurality of distribution key permission information files stored in the storage device. Obtained by executing the decryption process of the EKB distribution key encryption key (KEK) included in the file<u style="single">Key encryption key (KEK)</u>Is stored and held in the memory, and in the processing of the content stored in the storage device, the applicability of the key encryption key (KEK) stored in the memory in advance is determined, and if applicable, the key stored in the memory in advance is determined. It is characterized in that an encryption key (KEK) is used and the distribution key permission information file is read only when it is not applicable. [0027] Further, the third aspect of the present invention is A program providing medium for providing a computer program for executing data processing for reproducing contents from a storage device or recording contents for a storage device on a computer system, the computer program is a computer program. Obtained by executing the decryption process of the EKB distribution key encryption key (KEK) included in the distribution key permission information file with a large number of counts indicated by the link count data in multiple distribution key permission information files stored in the storage device.<u style="single">Key encryption key (KEK)</u>And the steps to store and retain in memory In processing the content stored in the storage device, the applicability of the key encryption key (KEK) stored in the memory in advance is determined, and if applicable, the key encryption key (KEK) stored in the memory in advance is used. The step of executing the reading of the distribution key permission information file only when it is not applicable, and To<u style="single">Recorded the program to be executed</u>It is in the program providing medium characterized by that. [0028] The program providing medium according to the third aspect of the present invention is, for example, a medium that provides a computer program in a computer-readable format to a general-purpose computer system capable of executing various program codes. The form of the medium is not particularly limited, such as a recording medium such as a CD, FD, or MO, or a transmission medium such as a network. [0029] Such a program providing medium defines a structural or functional collaborative relationship between a computer program and the provided medium in order to realize the function of a predetermined computer program on a computer system. .. In other words, by installing the computer program in the computer system via the providing medium, a collaborative action is exerted on the computer system, and the same action and effect as those of other aspects of the present invention can be obtained. Can be done. [0030] Still other objects, features and advantages of the present invention will be clarified by more detailed description based on the examples of the present invention described later and the accompanying drawings. [0031] BEST MODE FOR CARRYING OUT THE INVENTION [System overview] FIG. 1 shows an example of an applicable content distribution system of the data processing system of the present invention. The content distribution means 10 encrypts and transmits the content, the content key, and other data such as the authentication processing key to the data processing means 20. The data processing means 20 decrypts the received encrypted content or the encrypted content key or the like to acquire the content or the content key, reproduces the image data or the audio data, or executes various programs. Data exchange between the content distribution means 10 and the data processing means 20 is performed via a network such as the Internet or via a DVD, CD, or other distributable storage medium. [0032] The data processing means 20 stores and stores data in a data storage means 30 such as a memory card provided with a storage means such as a flash memory. The data storage means 30 includes, for example, a memory card (specifically, a memory stick (Memory)) as a storage means having an encryption processing function. Stick: Trademark)) is included. When data is stored from the data processing means 20 to the data storage means 30 and data is moved from the data storage means 30 to the data processing means, mutual authentication processing and data encryption processing are executed to prevent unauthorized data copying. It is planned. [0033] It is also possible to move the content data between the devices included in the data processing means 20, and at this time, mutual authentication processing between the devices and data encryption processing are also executed. [0034] The content distribution means 10 includes the Internet 11, satellite broadcasting 12, telephone lines 13, media 14 such as DVDs and CDs, and the data processing means 20 devices include personal computers (PCs) 21 and portable devices ( PD) 22, mobile phone, PDA (Personal Digital) There are 23 portable devices such as Assistants), recording / playback devices such as DVD and CD players, game terminals 24, and playback devices 25 using memory cards (ex. Memory Stick (trademark)). Each device of the data processing means 20 can acquire the content provided by the content distribution means 10 from a communication means such as a network, another data processing means, or a data storage means 30. [0035] Figure 2 shows an example of typical content data movement processing. The system shown in FIG. 2 is a diagram showing an example of data (content) transfer processing between a personal computer (PC) 100, a playback device 200, and a storage device 300. The PC100 has a hard disk (HD) for storing programs and data, and further has a configuration in which a CD, DVD, etc. as an external storage medium can be mounted. [0036] The personal computer (PC) 100 can be connected to various networks such as the Internet and public lines. For example, EMD (Electronic Music Distribution:) Receive various data such as audio data, image data, programs, etc. from the host computer of a service provider (not shown) that provides services such as electronic music distribution, and decode the received data as necessary. Output to the playback device 200. In addition, the personal computer (PC) 100 performs authentication processing, billing processing, and the like with the host computer of the service provider as necessary when receiving the content data. Further, the personal computer (PC) 100 outputs data input from, for example, a CD or a DVD to the playback device 200. [0037] The storage device 300 is a device that can be attached to and detached from the playback device 200, for example, a memory stick (trademark), and incorporates a rewritable semiconductor memory such as a flash memory. [0038] As shown in FIG. 2, when moving data between the PC 100, the playback device 200, and the storage device 300, for example, when performing data reproduction such as music data and image data, data recording, data copy, etc. Mutual authentication processing is executed, and data movement using unauthorized devices is prevented. These processes will be described later. In addition, data is encrypted by distributing content data via a network or various storage media, and when moving content between a PC and a playback device or between a playback device and a storage device such as a memory card. Security is maintained. [0039] [About the tree structure as a key distribution configuration] Securely use various encryption processing keys such as the encryption key applied to the encryption processing of the content as described above, for example, the content key applied to the encryption processing of the content, or the content key encryption key for encrypting the content key. As a configuration for distribution to a device having a legitimate license, a hierarchical key tree configuration will be described with reference to FIG. 3 and below. [0040] Numbers 0 to 15 shown at the bottom of FIG. 3 are individual devices constituting the data processing means 20 for playing and executing the content data, for example, a content (music data) playing device. That is, each leaf of the hierarchical tree structure shown in FIG. 3 corresponds to each device. [0041] Each device 0 to 15 is a key (node key) assigned to a node from its own leaf to the root and each leaf in the hierarchical tree structure shown in FIG. 3 at the time of manufacture, shipment, or after that. Stores a key set consisting of leaf keys in memory. K0000 to K1111 shown at the bottom of Fig. 3 are leaf keys assigned to each device 0 to 15, respectively, and are the keys described in the second section (node) from the bottom from the top KR (root key). : KR ~ K111 is used as the node key. [0042] In the tree configuration shown in FIG. 3, for example, device 0 owns the leaf key K0000 and the node keys: K000, K00, K0, KR. Device 5 owns K0101, K010, K01, K0, KR. Device 15 owns K1111, K111, K11, K1, and KR. In the tree of Fig. 3, only 16 devices from 0 to 15 are described, and the tree structure is also shown as a balanced left-right symmetric configuration with a 4-stage configuration, but more devices are configured in the tree. Also, it is possible to have a different number of stages in each part of the tree. [0043] In addition, each device included in the tree structure of FIG. 3 includes various recording media, for example, a memory card using a device-embedded type or a flash memory detachably configured on the device, a DVD, a CD, an MD, or the like. Devices that can use various types of storage devices are included. Furthermore, various application services can coexist. A hierarchical tree structure, which is a content or key distribution configuration shown in FIG. 3, is applied on top of such a coexistence configuration of different devices and different applications. [0044] In a system in which these various devices and applications coexist, for example, the part surrounded by the dotted line in FIG. 3, that is, devices 0, 1, 2, and 3 are set as one group using the same recording medium. For example, to the devices included in the group surrounded by this dotted line, the common content is encrypted and sent from the provider, the content key used for each device is sent, or each device. The processing such as encrypting and outputting the payment data of the content fee to the provider or the settlement institution is executed. An institution that sends and receives data to and from each device, such as a content provider or a payment processing institution, sends data collectively to the part surrounded by the dotted line in Fig. 3, that is, devices 0, 1, 2, and 3 as one group. Execute the process. There are multiple such groups in the tree of FIG. An institution that sends and receives data to and from each device, such as a content provider or a payment processing institution, functions as a message data distribution means. [0045] The node key and leaf key may be centrally managed by one key management center, or managed for each group by a message data distribution means such as a provider or a payment institution that sends and receives various data to each group. May be. Update processing is executed for these node keys and leaf keys in the case of key leakage, for example, and this update processing is executed by a key management center, a provider, a payment institution, or the like. [0046] In this tree structure, as is clear from FIG. 3, three devices 0,1,2,3 included in one group have common keys K00, K0, and KR as node keys. By using this node key sharing configuration, for example, it is possible to provide a common content key only to devices 0, 1, 2, and 3. For example, if the commonly held node key K00 itself is set as the content key, the content key common to only devices 0, 1, 2, and 3 can be set without executing a new key transmission. Also, if the new content key Kcon is encrypted with the node key K00 and the value Enc (K00, Kcon) is stored via the network or on a recording medium and distributed to devices 0,1,2,3, device 0, Only 1, 2 and 3 can solve the encryption Enc (K00, Kcon) using the shared node key K00 owned by each device to obtain the content key: Kcon. Note that Enc (Ka, Kb) indicates that Kb is encrypted with Ka. [0047] Also, at some point t, if it is discovered that the keys owned by device 3: K0011, K001, K00, K0, KR have been analyzed and exposed by an attacker (hacker), then the system (devices 0,1) will be used thereafter. Device 3 needs to be disconnected from the system to protect the data sent and received by (2,3 groups). To do this, update the node keys: K001, K00, K0, KR to the new keys K (t) 001, K (t) 00, K (t) 0, K (t) R, respectively, and device 0,1, You need to tell 2 the update key. Here, K (t) aaa indicates that it is the update key of the generation (Generation): t of the key Kaaa. [0048] The update key distribution process will be explained. The key update is, for example, the enabling key block (EKB: Enabling Key) shown in Fig. 4 (A). It is executed by storing a table composed of block data called Block) in a network or a recording medium and supplying it to devices 0, 1 and 2. The activation key block (EKB) is composed of an encryption key for distributing a newly updated key to the devices corresponding to each leaf constituting the tree structure as shown in FIG. The activation key block (EKB) is sometimes called the key renewal block (KRB). [0049] The activation key block (EKB) shown in FIG. 4 (A) is configured as block data having a data structure that can be updated only by the device that needs to update the node key. The example of FIG. 4 is block data formed for the purpose of distributing the update node key of the generation t in the devices 0, 1 and 2 in the tree structure shown in FIG. As is clear from FIG. 3, device 0 and device 1 require K (t) 00, K (t) 0, and K (t) R as update node keys, and device 2 requires K (t) as update node keys. ) 001, K (t) 00, K (t) 0, K (t) R are required. [0050] The EKB contains multiple encryption keys, as shown in the EKB in Figure 4 (A). The encryption key at the bottom is Enc (K0010, K (t) 001). This is the update node key K (t) 001 encrypted by the leaf key K0010 of device 2, and device 2 can decrypt this encryption key by its own leaf key to obtain K (t) 001. .. In addition, using the K (t) 001 obtained by decryption, the encryption key Enc (K (t) 001, K (t) 00) in the second row from the bottom of Fig. 4 (A) can be decrypted and updated. You can get the node key K (t) 00. In the following sequence, the encryption key Enc (K (t) 00, K (t) 0) in the second row from the top of Fig. 4 (A) is decrypted, and the update node key K (t) 0 and Fig. 4 (A) are displayed. Decrypt the encryption key Enc (K (t) 0, K (t) R) in the first row from the top to obtain K (t) R. On the other hand, in the device K0000.K0001, the node key K000 is not included in the update target, and K (t) 00, K (t) 0, and K (t) R are required as the update node keys. The device K0000.K0001 decrypts the encryption key Enc (K000, K (t) 00) in the third stage from the top of FIG. 4 (A) and obtains K (t) 00. The encryption key Enc (K (t) 00, K (t) 0) in the second row from the top of) is decrypted, and the update node key K (t) 0 is encrypted in the first row from the top in Fig. 4 (A). Decrypt the encryption key Enc (K (t) 0, K (t) R) to obtain K (t) R. In this way, devices 0,1,2 can obtain the updated keys K (t) 001, K (t) 00, K (t) 0, K (t) R. The index in FIG. 4 (A) indicates the absolute address of the node key and leaf key used as the decoding key. [0051] If it is not necessary to update the node keys: K (t) 0 and K (t) R in the upper row of the tree structure shown in Fig. 3, and only the node key K00 needs to be updated, the node key in Fig. 4 (B) is required to be updated. The update node key K (t) 00 can be distributed to devices 0,1,2 by using the activation key block (EKB). [0052] The EKB shown in FIG. 4 (B) can be used, for example, when distributing a new content key shared by a specific group. As a specific example, it is assumed that a recording medium having devices 0, 1, 2, and 3 in the group shown by the dotted line in FIG. 3 is used, and a new common content key K (t) con is required. At this time, a new common update content key: K (t) con encrypted data Enc (K (t)) using K (t) 00, which is the update of the common node key K00 of devices 0,1,2,3. ), K (t) con) will be distributed together with the EKB shown in Fig. 4 (B). This distribution enables distribution as data that cannot be decrypted by devices of other groups such as device 4. [0053] That is, if the devices 0, 1, and 2 decrypt the above ciphertext using K (t) 00 obtained by processing EKB, the content key K (t) con at the time t can be obtained. .. [0054] [Distribution of content keys using EKB] Figure 5 shows the data Enc (K (t)) in which a new common content key K (t) con is encrypted using K (t) 00 as an example of processing to obtain the content key K (t) con at time t. ) 00, K (t) con) and EKB shown in FIG. 4 (B) are received via the recording medium, and the processing of device 0 is shown. That is, it is an example in which the encrypted message data by EKB is used as the content key K (t) con. [0055] As shown in FIG. 5, the device 0 is subjected to the same EKB processing as described above using the EKB at the time of generation: t stored in the recording medium and the node key K000 stored in advance by itself, and the node key K (t). ) 00 is generated. Furthermore, the updated content key K (t) con is decrypted using the decrypted update node key K (t) 00, and the content key K (t) con is encrypted and stored with the leaf key K0000 that only one has for later use. [0056] [EKB format] Figure 6 shows an example of the activation key block (EKB) format. Version 601 is an identifier that indicates the version of the activation key block (EKB). The version has a function to identify the latest EKB and a function to show the correspondence with the contents. Depth indicates the number of layers in the hierarchy tree for the device to which the activation key block (EKB) is distributed. The data pointer 603 is a pointer indicating the position of the data part in the activation key block (EKB), the tag pointer 604 is the position of the tag part, and the signature pointer 605 is a pointer indicating the position of the signature. [0057] The data unit 606 stores, for example, data in which the node key to be updated is encrypted. For example, each encryption key related to the updated node key as shown in FIG. 5 is stored. [0058] [0058] The tag unit 607 is a tag indicating the positional relationship between the encrypted node key and leaf key stored in the data unit. The rule for assigning this tag will be described with reference to FIG. FIG. 7 shows an example of sending the activation key block (EKB) described earlier in FIG. 4 (A) as data. The data at this time is shown in Table (b) of FIG. The address of the top node included in the encryption key at this time is used as the top node address. In this case, the top node address is KR because the root key update key K (t) R is included. At this time, for example, the uppermost data Enc (K (t) 0, K (t) R) is at the position shown in the hierarchical tree shown in FIG. 7A. Here, the next data is Enc (K (t) 00, K (t) 0), which is in the lower left position of the previous data on the tree. If there is data, the tag is set to 0, otherwise it is set to 1. The tag is set as {left (L) tag, right (R) tag}. Since there is data on the left of the top data Enc (K (t) 0, K (t) R), L tag = 0, and since there is no data on the right, R tag = 1. Hereinafter, tags are set for all data, and the data string and tag string shown in FIG. 7 (c) are configured. [0059] The tag is set to indicate where the data Enc (Kxxx, Kyyy) is located in the tree structure. The key data Enc (Kxxx, Kyyy) ... stored in the data part is simply a list of encrypted keys, so it is on the encryption key tree stored as data by the above tags. The position can be determined. Instead of using the tags described above, for example, using a node index that corresponds to the encrypted data as in the configuration described in FIG. 4 above. 0: Enc (K (t) 0, K (t) root) 00: Enc (K (t) 00, K (t) 0) 000: Enc (K ((t) 000, K (T) 00) ... However, if the data structure is such that the index is used, the data becomes redundant and the amount of data increases, which is not preferable for distribution via a network or the like. On the other hand, by using the above-mentioned tag as index data indicating the key position, the key position can be determined with a small amount of data. [0060] Returning to FIG. 6, the EKB format will be described further. A signature is an electronic signature executed by, for example, a key management center, a content lover, a payment institution, etc. that issued an activation key block (EKB). The device that received the EKB is verified by signature verification that it is a valid activation key block (EKB) issued by the issuer. [0061] [Delivery of content keys and content using EKB] In the above example, an example in which only the content key is sent together with the EKB has been described, but the content encrypted with the content key, the content key encrypted with the content key encryption key, and the content key encryption key encrypted with the EKB are used. The configuration to be sent together will be described below. [0062] Figure 8 shows this data structure. In the configuration shown in FIG. 8 (a), Enc (Kcon, content) 801 is data obtained by encrypting the content (Content) with the content key (Kcon), and Enc (KEK, Kcon) 802 is the content key (Kcon). ) Is encrypted with the content key encryption key (KEK: Key Encryption Key), and Enc (EKB, KEK) 803 is the data encrypted with the content key encryption key KEK enabled by the activation key block (EKB). Show that. [0063] Here, the content key encryption key KEK may be the node key (K000, K00 ...) shown in FIG. 3 or the root key (KR) itself, or the node key (K000, K00 ...) or the root. It may be a key encrypted by a key (KR). [0064] FIG. 8 (b) shows a configuration example when a plurality of contents are recorded on the media and each uses the same Enc (EKB, KEK) 805. In such a configuration, the same Enc is used for each data. It is possible to add data indicating the link destination linked to Enc (EKB, KEK) to each data without adding (EKB, KEK). [0065] FIG. 9 shows an example in which the content key encryption key KEK is configured as the updated node key K (t) 00 in which the node key K00 shown in FIG. 3 is updated. In this case, assuming that device 3 is revoked (excluded) due to, for example, key leakage in the group surrounded by the dotted frame in FIG. 3, the members of other groups, that is, devices 0, 1 and 2, are shown in FIG. (A) Activation key block (EKB), (b) Content key (Kcon) encrypted with content key encryption key (KEK = K (t) 00), and (c) Content (content) By delivering the data encrypted with the content key (Kcon), devices 0, 1 and 2 can obtain the content. [0066] The decoding procedure for device 0 is shown on the right side of FIG. First, the device 0 acquires the content key encryption key (KEK = K (t) 00) from the received activation key block by the decryption process using the leaf key K000 owned by the device 0. Next, the content key Kcon is acquired by decoding with K (t) 00, and the content is further decoded with the content key Kcon. By these processes, the device 0 makes the content available. By processing the EKB in the devices 1 and 2 using different processing procedures, it is possible to obtain the content key encryption key (KEK = K (t) 00), and the content can be used in the same manner. .. [0067] Even if the devices 4,5,6 ... Of the other groups shown in Fig. 3 receive this similar data (EKB), the content key encryption key (KEK = K) uses the leaf key and node key that they own. (t) 00) cannot be obtained. Similarly, even in the revoked device 3, the content key encryption key (KEK = K (t) 00) cannot be obtained with the leaf key and node key owned by the device 3, and only the device having the legitimate right can obtain the content. It can be decrypted and used. [0068] [0068] In this way, by using the delivery of the content key using EKB, it is possible to reduce the amount of data and safely deliver the encrypted content that can be decrypted only by the legitimate right holder. [0069] The activation key block (EKB), content key, encrypted content, etc. can be safely distributed via the network, but the activation key block (EKB), content key, encrypted content, etc. Can be stored in a recording medium such as a DVD or a CD and provided to the user. In this case, it is valid in advance if the content key obtained by decrypting the activation key block (EKB) stored in the same recording medium is used for decrypting the encrypted content stored in the recording medium. Distribution processing of encrypted content that can be used only by the leaf key and node key owned only by the right holder, that is, content distribution that limits the available user devices can be realized with a simple configuration. [0070] Figure 10 shows a configuration example in which the activation key block (EKB) is stored together with the encrypted content on the recording medium. In the example shown in FIG. 10, the contents C1 to C4 are stored in the recording medium, the data associated with the activation key block (EKB) corresponding to each stored content is stored, and the version M activation key is further stored. The block (EKB_M) is stored. For example, EKB_1 is used to generate the content key Kcon1 with the content C1 encrypted, and EKB_2 is used to generate the content key Kcon2 with the content C2 encrypted, for example. In this example, the activation key block (EKB_M) of version M is stored in the recording medium, and the contents C3 and C4 are associated with the activation key block (EKB_M), so the activation key block (EKB_M) The content keys of contents C3 and C4 can be obtained by decrypting. Since EKB_1 and EKB_2 are not stored on the disk, it is necessary to acquire EKB_1 and EKB_2 necessary for decrypting the respective content keys by a new providing means, for example, network distribution or distribution by a recording medium. [0071] [Category classification of hierarchical tree structure] The encryption key is configured as a hierarchical tree structure shown in Fig. 3 such as root key, node key, leaf key, etc., and the content key, authentication key, ICV generation key, program code, data, etc. are encrypted and distributed together with the activation key block (EKB). The configuration to be performed has been explained, but the configuration for efficiently executing key update processing, encryption key distribution, and data distribution by classifying the hierarchical tree structure that defines the node key etc. into each device category will be explained below. To do. [0072] Figure 11 shows an example of the classification of categories in a hierarchical tree structure. In FIG. 11, the root key Kroot1101 is set at the top of the hierarchical tree structure, the node key 1102 is set at the following intermediate rows, and the leaf key 1103 is set at the bottom. Each device has an individual leaf key and a series of node keys and root keys from the leaf key to the root key. [0073] Here, as an example, a node having the Mth stage from the top is set as a category node 1104. That is, each of the nodes in the Mth stage is set as a device setting node of a specific category. The nodes and leaves of the M + 1 stage and below are the nodes and leaves related to the devices included in the category, with one node of the M stage as the apex. [0074] For example, the category [Memory Stick (trademark)] is set for one node 1105 in the M-th row in Fig. 11, and the nodes and leaves connected to this node and below are dedicated to the category including various devices using memory stick. Set as a node or leaf of. That is, nodes 1105 and below are defined as a set of related nodes and leaves of devices defined in the Memory Stick category. [0075] Further, a stage several steps lower than the M stage can be set as a subcategory node 1106. For example, as shown in the figure, a node of [Playback only device] is set as a subcategory node included in the category of the device using the memory stick in the node two steps below the category [Memory Stick] node 1105. Further, a node 1107 of a phone with a music playback function included in the category of the playback-only device is set under the node 1106 of the playback-only device, which is a subcategory node, and further below, the node 1107 of the phone with the music playback function is included in the category of the phone with the music playback function. You can configure [PHS] node 1108 and [Mobile Phone] node 1109. [0076] Furthermore, categories and subcategories are not limited to device types, but are arbitrary units such as nodes managed independently by a certain manufacturer, content provider, payment institution, etc., that is, processing units, jurisdiction units, or service units provided (these are). Collectively, it can be set by (hereinafter referred to as "entity"). For example, if one category node is set as a vertex node dedicated to the game device XYZ sold by the game device manufacturer, the lower node key and leaf key below the vertex node can be stored and sold in the game device XYZ sold by the manufacturer. After that, the distribution of encrypted contents, the distribution of various keys, and the update process are performed by generating and distributing the activation key block (EKB) consisting of the node key and leaf key below the vertex node key, and below the vertex node. Data that can be used only for the device can be distributed. [0077] In this way, by setting one node as a vertex and setting the following nodes as related nodes of the category or subcategory defined in the vertex node, one vertex of the category stage or the subcategory stage. It is possible for manufacturers, content providers, etc. that manage nodes to independently generate an activation key block (EKB) with that node as the apex and distribute it to devices belonging to the apex node and below, and other than that, it does not belong to the apex node. Key updates can be performed without affecting any device that belongs to a node in the category. [0078] [Key distribution configuration by simplified EKB] In the tree configuration shown above, for example, in the tree configuration shown in FIG. 3, when a key, for example, a content key, is sent to a predetermined device (leaf), an activation key that can be decrypted using the leaf key or node key owned by the key distribution destination device. Generate and provide a block (EKB). For example, in the tree configuration shown in FIG. 12 (a), when sending a key, for example, a content key to the devices a, g, j constituting the leaf, the enable key that can be decrypted at each node of a, g, j Generate and distribute blocks (EKB). [0079] For example, consider the case where the content key K (t) con is encrypted with the update root key K (t) root and distributed together with EKB. In this case, the devices a, g, and j each execute the EKB process using the leaf and node keys shown in Fig. 12 (b) to acquire K (t) root, and the acquired update root key K ( t) The content key is obtained by executing the decryption process of the content key K (t) con by root. [0080] [0080] The configuration of the activation key block (EKB) provided in this case is as shown in FIG. The activation key block (EKB) shown in FIG. 13 is configured according to the format of the activation key block (EKB) described in FIG. 6 above, and is composed of data (encryption key) and a corresponding tag. Have. The tag indicates 0 if there is data in each of the left (L) and right (R) directions as explained earlier with reference to FIG. 7, and 1 if there is no data. [0081] The device that received the activation key block (EKB) sequentially executes the encryption key decryption process based on the encryption key and tag of the activation key block (EKB) to obtain the update key of the upper node. I will go. As shown in FIG. 13, the amount of data of the activation key block (EKB) increases as the number of stages (depth) from the root to the leaf increases. The number of stages (depth) increases according to the number of devices (leaf), and if the number of devices to which the key is distributed is large, the amount of EKB data will further increase. [0082] A configuration that makes it possible to reduce the amount of data in the activation key block (EKB) will be described. FIG. 14 shows an example in which the activation key block (EKB) is simplified and configured according to the key distribution device. [0083] As in FIG. 13, it is assumed that a key, for example, a content key is transmitted to the devices a, g, and j constituting the leaf. As shown in (a) of FIG. 14, a tree composed only of key distribution devices is constructed. In this case, the tree structure shown in FIG. 14 (b) is constructed as a new tree structure based on the structure shown in FIG. 12 (b). There is no branch from Kroot to Kj and only one branch needs to exist. To reach Ka and Kg from Kroot, only a branch point is configured at K0, and a two-branch configuration is shown in Fig. 14 (a). The tree is built. [0084] As shown in Figure 14 (a), a simplified tree with only K0 as a node is generated. The activation key block (EKB) for update key distribution is generated based on these simplified trees. The tree shown in Fig. 14 (a) can be recreated by selecting a path that constitutes a bifurcated tree with the end node or leaf at the bottom where the activation key block (EKB) can be decrypted, and omitting unnecessary nodes. It is a reconstructed hierarchical tree to be constructed. The activation key block (EKB) for update key distribution is constructed based only on the key corresponding to the node or leaf of this rebuild hierarchy tree. [0085] The activation key block (EKB) described in Figure 13 above stored encrypted data for all keys from each leaf a, g, j to Kroot, but the simplified EKB is simplified. Stores encrypted data only for the nodes that make up the encrypted tree. As shown in FIG. 14 (b), the tag has a 3-bit configuration. The first and second bits have the same meaning as in the example of FIG. 13, and indicate 0 if there is data in each of the left (L) and right (R) directions, and 1 if there is no data. The third bit is a bit for indicating whether or not the encryption key is stored in the EKB, and is set as 1 if data is stored and 0 if there is no data. [0086] As shown in FIG. 14 (b), the activation key block (EKB) stored in the data communication network or the storage medium and provided to the device (leaf) has a larger amount of data than the configuration shown in FIG. It will be greatly reduced. Each device that receives the activation key block (EKB) shown in FIG. 14 realizes the decryption of a predetermined encryption key by sequentially decrypting only the data of the part where 1 is stored in the third bit of the tag. be able to. For example, device a decrypts the encrypted data Enc (Ka, K (t) 0) with the leaf key Ka, obtains the node key K (t) 0, and uses the node key K (t) 0 to decrypt the encrypted data Enc (K). Decrypt (t) 0, K (t) root) to get K (t) root. The device j decrypts the encrypted data Enc (Kj, K (t) root) with the leaf key Kj and obtains the K (t) root. [0087] In this way, a new simplified tree configuration consisting only of the destination device is constructed, and an activation key block (EKB) is generated using only the leaf and node keys that make up the constructed tree. By doing so, it becomes possible to generate an activation key block (EKB) with a small amount of data , and data distribution of the activation key block (EKB) can be efficiently executed. [0088] The simplified hierarchical tree configuration can be particularly effectively used in the EKB management configuration for each entertainment described later. The entity is an aggregate block of a plurality of nodes or leaves selected from the nodes or leaves that make up the tree configuration as the key distribution configuration. An entity is a set set according to the type of device, or a processing unit, a jurisdiction unit, a service unit, etc. that have a certain commonality, such as a management unit of a device provider, a content provider, a payment institution, etc. , Set as a set of various aspects. One entity is a collection of devices that fall into a common category, for example, by rebuilding a simplified tree similar to the one described above with vertex nodes (subroots) of multiple entities to generate an EKB. This enables the generation and distribution of a simplified activation key block (EKB) that can be decrypted on the device belonging to the selected entity. The management configuration for each entertainment will be described in detail later. [0089] It should be noted that such an activation key block (EKB) can be configured to be stored in an information recording medium such as an optical disk or a DVD. For example, the activation key block (EKB) including the data part composed of the above-mentioned encryption key data and the tag part as the position identification data in the hierarchical tree structure of the encryption key data is further encrypted by the update node key. It is possible to provide each device with an information recording medium that stores message data such as the contents. The device can sequentially extract and decrypt the encryption key data contained in the activation key block (EKB) according to the identification data of the tag part, acquire the key necessary for decrypting the content, and use the content. It becomes. Of course, the activation key block (EKB) may be distributed via a network such as the Internet. [0090] [Data movement between storage device with encryption processing function and data processing device] Next, regarding the processing configuration to which the encryption processing key distributed by the activation key block (EKB) to which the above-mentioned hierarchical tree configuration is applied is applied, a storage device having an encryption processing function, for example, a memory card such as a memory stick (trademark) The description will focus on data movement processing between data playback devices. [0091] FIG. 15 is a block diagram showing a detailed configuration of a playback device capable of mutually transferring content data and a storage device such as a memory card having an encryption processing function. [0092] As shown in FIG. 15, the storage device 300 includes, for example, a main control module 31, a communication interface 32, a control module 33, a flash memory 34, and a flash memory management module 35. Hereinafter, each module will be described. [0093] [Control module 33] As shown in FIG. 15, the control module 33 includes, for example, a random number generation unit 50, a storage unit 51, a key generation / calculation unit 52, a mutual authentication unit 53, an encryption / decryption unit 54, and a control unit 55. The control module 33 is an integrated circuit dedicated to single-chip cryptographic processing, has a multi-layer structure, and an internal memory cell is sandwiched between dummy layers such as an aluminum layer. Further, the control module 33 has a narrow range of operating voltage or operating frequency, and has tamper resistance so as not to illegally read data from the outside. When the random number generation unit 50 receives a random number generation instruction, it generates a 64-bit (8-byte) random number. [0094] The storage unit 51 is, for example, a non-volatile memory such as EEPROM (Electrically Erasable Programmable Read Only Memory), and stores various data such as key data required for authentication processing. FIG. 16 is a diagram for explaining data stored in the storage unit 51. As shown in FIG. 16, the storage unit 51 stores the authentication key data IK0 to IK31, the device identification data IDm, and the storage key data Kstm. [0095] The authentication key data IK0 to IK31 are key data used when the storage device 300 performs mutual authentication with the playback device 200, and among the authentication key data IK0 to IK31 each time the mutual authentication is performed as described later. One authentication key data is randomly selected. The authentication key data IK0 to IK31 and the storage key data Kstm cannot be read from the outside of the storage device 300. The device identification data IDm is identification data uniquely attached to the storage device 300, and is read out when the storage device 300 performs mutual authentication with the playback device 200, as will be described later. Output to 200. The storage key data Kstm is used when the content key data CK used for encrypting the content is encrypted and stored in the flash memory 34, as will be described later. [0096] The key generation / calculation unit 52 generates key data by performing various operations such as a MAC (Message Authentication Code) operation of ISO / IEC9797, for example. At this time, for the MAC operation, for example, DES (Data Encryption Standard) specified in FIPS PUB46-2 is used as the "Block cipher Algorithm". The MAC operation is a one-way hash function operation that compresses data of arbitrary length to a fixed length, and the function value is determined depending on the private key. [0097] The mutual authentication unit 53 performs a mutual authentication process with the playback device 200 prior to performing an operation of inputting audio data from the playback device 200 and writing the audio data to the flash memory 34. Further, the mutual authentication unit 53 performs a mutual authentication process with the playback device 200 prior to performing an operation of reading audio data from the flash memory 34 and outputting the audio data to the playback device 200. Further, the mutual authentication unit 53 performs the MAC calculation described above in the mutual authentication process. In the mutual authentication process, the data stored in the storage unit 51 is used. [0098] The encryption / decryption unit 54 encrypts with a block cipher algorithm such as DES, IDEA, or MISTY. The modes used are ECB (Electronic Code Book) mode and CBC (Cipher Block Chaining) mode as specified in FIPS PUB81 "DES MODES OF OPERATION". Further, the encryption / decryption unit 54 performs decryption by a block decryption algorithm such as DES, IDEA, or MISTY. The modes used are the above ECB mode and CBC mode. In the block encryption / decryption of the ECB mode and the CBC mode, the specified data is encrypted / decrypted using the specified key data. The control unit 55 controls the processing of the random number generation unit 50, the storage unit 51, the key generation / calculation unit 52, the mutual authentication unit 53, and the encryption / decryption unit 54. [0099] [Flash memory 34] The flash memory 34 has, for example, a storage capacity of 32 Mbytes. The flash memory 34 contains audio data or images input from the playback device 200 when both are recognized as legitimate devices by mutual authentication processing between the playback device 200 and the storage device 300 by the mutual authentication unit 53. Various data such as data are written. Further, from the flash memory 34, audio data, image data, etc. are read out when it is recognized as a legitimate partner by the mutual authentication process between the playback device 200 and the storage device 300 by the mutual authentication unit 53. Is output to the playback device 200. [0100] Hereinafter, the data stored in the flash memory 34 and its format will be described. FIG. 17 is a diagram for explaining data stored in the flash memory 34. As shown in FIG. 17, for example, a playback management file and a plurality of track data (reproduction data) files are stored in the flash memory 34. Here, the reproduction management file has management data for managing the reproduction of the track data file, and each track data file has corresponding track data (audio data). In the present embodiment, the track data means, for example, audio data for one song. Hereinafter, an example in which the data stored in the flash memory 34 is used as audio data will be described. [0101] FIG. 18 shows the structure of the playback management file, and FIG. 19 shows the structure of one ATRAC3 data file (one song). The playback management file is a 16KB fixed length file. The ATRAC3 data file consists of the first attribute header followed by the actual encrypted music data on a song-by-song basis. The attribute header also has a fixed length of 16KB and has a structure similar to that of a playback management file. [0102] The playback management file consists of a header, a 1-byte code memory card name NM1-S, a 2-byte code memory card name NM2-S, a song order playback table TRKTBL, and additional information INF-S for the entire memory card. .. The attribute header at the beginning of the data file consists of a header, 1-byte code song name NM1, 2-byte code song name NM2, track information TRKINF such as track key information, parts information PRTINF, and track additional information INF. The header contains information such as the total number of parts, name attributes, and the size of additional information. [0103] ATRAC3 music data follows for the attribute header. Music data is divided into 16KB blocks, and a header is added to the beginning of each block. The header contains initial values for decrypting the cipher. It should be noted that only the content data such as music data in the ATRAC3 data file is subjected to the encryption process, and the other data such as the playback management file and the header are not encrypted. [0104] FIG. 20 shows the detailed data structure of the playback management file PBLIST. The playback management file PBLIST is the size of one cluster (1 block = 16KB). The header shown in Figure 20A consists of 32 bytes. The parts other than the header shown in Fig. 20B are played with the name NM1-S (256 bytes), name NM2-S (512 bytes), encrypted content key (CONTENTSKEY), MAC, and S-YMDhms for the entire memory card. The table TRKTBL (800 bytes) that manages the order, the additional information INF-S (14720 bytes) for the entire memory card, and finally a part of the information in the header are recorded again. The head of each of these different types of data groups is defined to be at a predetermined position in the playback management file. [0105] The header of the playback management file is the first 32 bytes represented by (0x0000) and (0x0010) shown in FIG. 20A. A slot is a unit separated by 16 bytes from the beginning in a file. Data having the following meanings, functions, and values are arranged in order from the beginning in the headers arranged in the first and second slots of the file. The data described as Reserved represents undefined data. Normally null (0x00) is written, but Reserved data is ignored no matter what is written. Changes are possible in future versions. Also, writing to this part is prohibited. If the part written as Option is not used, it is treated the same as Reserved. [0106] BLKID-TL0 (4 bytes) Meaning: BLOCKID FILE ID Function: Value to identify the beginning of the playback management file Value: Fixed value = TL = 0 (eg 0x544C2D30) MCode (2 bytes) Meaning: MAKER CODE Function: Code that identifies the make and model of the recorded device Value: Upper 10 bits (manufacturer code) Lower 6 bits (model code) REVISION (4 bytes) Meaning: Number of PBLIST rewrites Function: Incremented every time the playback management file is rewritten Value starts from 0 and increases by +1 [0107] SN1C + L (2 bytes) Meaning: Represents the attribute of the name (1 byte) of the memory card written in the NM1-S area. Function: The character code and language code to be used are represented by 1 byte each. Value: The character code (C) is the upper 1 byte and distinguishes characters as shown below. 00: No character code is set. Treat it as just a binary number 01: ASCII (American Standard Code for Information Interchange) 02: ASCII + KANA 03: modified8859-1 81: MS-JIS 82: KS C 5601-1989 83: GB (Great Britain) 2312-80 90: S-JIS (Japanese Industrial Standards) (for Voice). [0108] The language code (L) is the lower 1 byte and distinguishes the language according to the EBU Tech 3258 regulations as shown below. 00: Not set 08: German 09: English 0A: Spanish 0F: French 15: Italian 1D: Dutch 65: Korean 69: Japanese 75: Chinese If there is no data, set it to all zero. [0109] SN2C + L (2 bytes) Meaning: Represents the attribute of the memory card name (2 bytes) written in the NM2-S area. Function: The character code and language code to be used are represented by 1 byte each. Value: Same as SN1C + L above SINFSIZE (2 bytes) Meaning: Represents the total size of all additional information about the entire memory card written in the INF-S area. Function: Describe the data size in 16-byte units, and if there is none, be sure to set it to all zeros. Value: Size from 0x0001 to 0x39C (924) T-TRK (2 bytes) Meaning: TOTAL TRACK NUMBER Function: Total number of tracks Value: 1 to 0x0190 (maximum 400 tracks), all zero if no data VerNo (2 bytes) Meaning: Format version number Function: Higher is major version number, lower is minor version number. It is also used as data indicating whether or not it is copyright compatible, that is, whether or not the distribution key is used by the activation key block (EKB) having the above-mentioned hierarchical tree structure.<img file="JP4660899B2_D0001.tif" />[0110] The data (FIG. 20B) written in the area following the header described above will be described below. [0111] NM1-S Meaning: 1-byte name for the entire memory card Function: Variable-length name data expressed in 1-byte character code (up to 256) Be sure to write the end code (0x00) at the end of the name data. The size should be calculated from this end code, and if there is no data, at least 1 byte or more of null (0x00) from the beginning (0x0020) should be recorded. Value: Various character codes NM2-S Meaning: 2-byte name for the entire memory card Function: Variable-length name data expressed in 2-byte character code (up to 512) Be sure to write the end code (0x00) at the end of the name data. The size should be calculated from this end code, and if there is no data, at least 2 bytes or more of null (0x00) from the beginning (0x0120) should be recorded. Value: Various character codes. [0112] EKB_version (4 bytes) Meaning: Indicates the generation number of the content key provided by the activation key block (EKB) in the above hierarchical tree structure and / or the file name of the activation key block (EKB). Function: Indicates the activation key block (EKB) for obtaining the content key provided by the activation key block (EKB) in a hierarchical tree structure. Values: 0 to 0xFF [0113] E (Kstm, Kcon) (8 bytes) Meaning: Data that is a key for encryption processing for each content and the content key is encrypted with the storage key (Kstm) of the memory card. Function: Used for content encryption Values from 0 to 0xFFFFFFFFFFFFFFFF [0114] E (KEKn, Kcon) (8 bytes) Meaning: Data in which the content key, which is the key for encryption processing for each content, is encrypted by the key encryption key KEKn provided by the activation key block (EKB) in the above-mentioned hierarchical tree structure. Function: Used for content encryption Values from 0 to 0xFFFFFFFFFFFFFFFF [0115] C_MAC [0] (8 bytes) Meaning: Copyright information tampering check value Function: S-YMDhms that indicates the date and time of content processing such as the data in the playback management file and the last content record. A value for tampering check generated based on other data. If the date and time data S-YMDhms has been tampered with, it is determined that the date and time data has been tampered with when checking C_MAC [0], and the content is not played. Values from 0 to 0xFFFFFFFFFFFFFFFF. [0116] MGR Meaning: Content key type Function: 0x00 with both content key Kcon and E (KEKn, Kcon), 0x01 with only E (KEKn, Kcon). Values: 0 to 0x01 [0117] S-YMDhms (4 bytes) (Option) Meaning: Year, month, day, hour, minute, second recorded on a device with a reliable watch Function: A value to identify the last processing date and time of the content, such as the last recording date and time of the content. Updated when content is processed.<img file="JP4660899B2_D0002.tif" />Note that S-YMDhms are updated during content processing such as content recording, and the above-mentioned C-MAC [0] is also updated and stored based on the updated data. [0118] TRK-nnn Meaning: SQN (sequence) number of ATRAC3 data file to play Function: Describe FNo in TRKINF Values: 1 to 400 (0x190) If there is no track, set it to all zero INF-S Meaning: Additional information data about the entire memory card (for example, information such as photos, lyrics, explanations, etc.) Function: Variable length additional information data with header Multiple different additional information may be lined up. Each has an ID and data size. The additional information data including each header has a minimum of 16 bytes and is composed of an integral multiple of 4 bytes. The details will be described later. Value: See Additional Information Data Structure [0119] BLKID-TL0, MCode, and REVISION, which are the same as those in the header, are written as the last slot of the playback management file. [0120] As a consumer audio device, the memory card may be pulled out during recording or the power may be turned off, and it is necessary to detect the occurrence of these abnormalities when the memory card is restored. As mentioned above, REVISION is written at the beginning and end of the block, and each time this value is rewritten, it is incremented by +1. If an abnormal termination occurs in the middle of a block, the REVISION values at the beginning and the end do not match, and the abnormal termination can be detected. Since there are two REVISIONs, abnormal termination can be detected with high probability. When an abnormal termination is detected, a warning such as an error message is displayed. [0121] Also, since the fixed value BLKID-TL0 is inserted at the beginning of one block (16KB), the fixed value can be used as a guide for repair when the FAT is broken. That is, the file type can be determined by looking at the fixed value at the beginning of each block. Moreover, since this fixed value BLKID-TL0 is described twice in the header of the block and the end of the block, its reliability can be checked. The same playback management file PBLIST may be recorded twice. [0122] The ATRAC3 data file has a considerably larger amount of data than the track information management file, and the ATRAC3 data file is given the block number BLOCK SERIAL. However, ATRAC3 data files usually have multiple files on the memory card, so if you do not add BLOCK SERIAL after distinguishing the contents with CONNUM0, duplication will occur and the FAT will be corrupted. Will be difficult to recover. In other words, a single ATRAC3 data file is composed of multiple BLOCKs and may be arranged separately. Therefore, CONNUM0 is used to determine the BLOCKs that make up the same ATRAC3 data file, and they are the same. The block number BLOCK SERIAL determines the ascending / descending order in the ATRAC3 data file. [0123] Similarly, although it does not lead to the destruction of FAT, the manufacturer code (MCode) is added to the beginning and end of the block so that the model of the manufacturer who wrote it can be identified when the logic is mistaken and it is inconvenient as a file. It has been recorded. [0124] FIG. 20C shows the structure of additional information data. The following header is written at the beginning of the additional information. Variable length data is written after the header. [0125] INF Meaning: FIELD ID Function: Fixed value indicating the beginning of additional information data Value: 0x69 ID Meaning: Additional information key code Function: Indicates the classification of additional information Values: 0 to 0xFF SIZE Meaning: Size of individual additional information Function: Data size is free, but must be an integral multiple of 4 bytes. Also, the minimum is 16 bytes or more. If there is a remainder from the end of the data, fill it with null (0x00). Values: 16-14784 (0x39C0) MCode Meaning: MAKER CODE Function: Code that identifies the make and model of the recorded device Value: Upper 10 bits (manufacturer code) Lower 6 bits (model code) C + L Meaning: Represents the attribute of the character written in the data area from the 12th byte from the beginning. Function: The character code and language code to be used are represented by 1 byte each. Value: Same as SNC + L above DATA Meaning: Individual additional information data Function: Represented as variable length data. The beginning of the actual data always starts from the 12th byte, and the length (size) must be at least 4 bytes and always an integral multiple of 4 bytes. If there is a remainder from the end of the data, fill it with null (0x00) Value: Defined individually by content. [0126] Figure 21 shows an example of the data arrangement of the ATRAC3 data file A3Dnnnn. FIG. 21 shows the attribute header (1 block) of the data file and the music data file (1 block). In FIG. 21, the first byte (0x0000 to 0x7FF0) of each slot of these two blocks (16 × 2 = 32 Kbytes) is shown. As shown separately in FIG. 22, 32 bytes from the beginning of the attribute header is the header, 256 bytes is the song title area NM1 (256 bytes), and 512 bytes is the song title area NM2 (512 bytes). The following data is written in the header of the attribute header. [0127] BLKID-HD0 (4 bytes) Meaning: BLOCKID FILE ID Function: A value to identify the beginning of an ATRAC3 data file Value: Fixed value = HD = 0 (eg 0x48442D30) [0128] MCode (2 bytes) Meaning: MAKER CODE Function: Code that identifies the make and model of the recorded device Value: Upper 10 bits (manufacturer code) Lower 6 bits (model code) [0129] BLOCK SERIAL (4 bytes) Meaning: Serial number assigned to each track Function: The beginning of a block starts from 0 and the next block is incremented by +1 Does not change the value when edited Value starts at 0 and ends at 0xFFFFFFFF. [0130] N1C + L (2 bytes) Meaning: Represents the attribute of track (song title) data (NM1) Function: The character code and language code used for NM1 are represented by 1 byte each. Value: Same as SN1C + L [0131] N2C + L (2 bytes) Meaning: Represents the attribute of track (song title) data (NM2) Function: The character code and language code used for NM2 are represented by 1 byte each. Value: Same as SN1C + L [0132] INFSIZE (2 bytes) Meaning: Represents the total size of all additional information about the track Function: Describe the data size in 16-byte units, and if there is none, be sure to set it to all zeros. Value: Size from 0x0000 to 0x3C6 (966) [0133] T-PRT (2 bytes) Meaning: Total number of parts Function: Represents the number of parts that make up a track. Usually 1 Values: 1 to 0x285 (645dec) [0134] T-SU (4 bytes) Meaning: Total number of SUs (sound units), SU is the smallest unit of parts and the smallest data unit when compressing audio data with ATRAC3. SU is hundreds of bytes of data obtained by compressing 1024 samples (1024 x 16 bits x 2 channels) of audio data obtained at a sampling frequency of 44.1 kHz to about 1/10. 1SU is about 23 ms in terms of time. Usually, thousands of SUs make up a part. If one cluster consists of 42 SUs, one cluster can represent about 1 second of sound. The number of parts that make up a track is affected by the size of the additional information. Since the number of parts is determined by the number of blocks excluding headers, song titles, additional information data, etc., the maximum number of parts (645) can be used when there is no additional information. Function: Represents the actual total number of SUs in a track. Corresponds to the playing time of the song Values: 0x01 to 0x001FFFFF [0135] INX (2 bytes) (Option) Meaning: Relative location of INDEX Function: A pointer to the beginning of the rusted part (characteristic part) of the song. Specify the position from the beginning of the song as the number of SUs divided by 1/4. This corresponds to a time (about 93 ms) that is four times as long as a normal SU. Value: 0 to 0xFFFF (maximum, approx. 6084 seconds) [0136] XT (2 bytes) (Option) Meaning: INDEX play time Function: Specifies the number of SUs for the time to be played from the beginning specified by INX-nnn, which is 1/4. This corresponds to a time (about 93 ms) that is four times as long as a normal SU. Value: 0x0000: Not set 0x01 to 0xFFFE (up to 6084 seconds) 0xFFFF: Until the end of the song. [0137] Next, the song title areas NM1 and NM2 will be described. [0138] NM1 Meaning: A string representing the song title Function: Variable length song title represented by 1-byte character code (up to 256) Be sure to write the end code (0x00) to end the name data. The size should be calculated from this end code, and if there is no data, at least 1 byte or more of null (0x00) from the beginning (0x0020) should be recorded. Value: Various character codes [0139] NM2 Meaning: A string representing the song title Function: Variable-length name data expressed in 2-byte character code (up to 512) Be sure to write the end code (0x00) to end the name data. The size should be calculated from this end code, and if there is no data, at least 2 bytes or more of null (0x00) from the beginning (0x0120) should be recorded. Value: Various character codes. [0140] The 80-byte data starting from the fixed position (0x320) of the attribute header is called the track information area TRKINF, and mainly manages security-related and copy control-related information collectively. Figure 23 shows the TRKINF part. The data in TRKINF will be described below according to the arrangement order. [0141] EKI (1 byte) Meaning: Indicates whether or not the encrypted content key provided by the activation key block (EKB) in the above-mentioned hierarchical tree structure: E (KEKn, Kcon) is possessed. Function: With bit7 = 1 with key, with bit7 = 0 without. When bit7 = 0, EKB_version and E (KEKn, Kcon) are not referenced. Values: 0 to 0xFF [0142] EKB_version (4 bytes) Meaning: Indicates the generation number of the content key provided by the activation key block (EKB) in the above hierarchical tree structure and / or the file name of the activation key block (EKB). Function: Indicates the activation key block (EKB) for obtaining the content key provided by the activation key block (EKB) in a hierarchical tree structure. Values: 0 to 0xFF [0143] E (Kstm, Kcon) (8 bytes) Meaning: Data in which the content key, which is the key for encryption processing for each content, is encrypted with the storage key (Kstm) of the memory card. Function: Used for content encryption Values from 0 to 0xFFFFFFFFFFFFFFFF [0144] E (KEKn, Kcon) (8 bytes) Meaning: Data in which the content key, which is the key for encryption processing for each content, is encrypted by the key encryption key KEKn provided by the activation key block (EKB) in the above-mentioned hierarchical tree structure. Function: Used for content encryption Values from 0 to 0xFFFFFFFFFFFFFFFF [0145] C_MAC [n] (8 bytes) Meaning: Copyright information tampering check value Function: A value created from the contents of multiple TRKINFs, including content cumulative numbers, and hidden sequence numbers. The hidden sequence number is a sequence number recorded in the hidden area of the memory card. Non-copyrighted recorders cannot read hidden areas. In addition, a dedicated copyright-enabled recorder or a personal computer equipped with an application that enables reading of a memory card can access the hidden area. [0146] A (1 byte) Meaning: Part attributes Function: Shows information such as compression mode in the part Value: Explained below with reference to Figure 24 However, for monaural with N = 0,1, bit7 is 1, the sub signal is 0, and the special Joint mode with only the main signal (L + R) is defined as monaural. The information of bit2 and 1 can be ignored by a normal player. [0147] Bit 0 of A forms information on / off of enhancement, bit 1 forms information on playback SKIP or normal playback, and bit 2 forms data divisions such as audio data, fax, etc. Form information such as data of. Bit 3 is undefined. By combining bits 4, 5 and 6, ATRAC3 mode information is defined as shown. That is, N is the value of the mode represented by these 3 bits, and is mono (N = 0,1), LP (N = 2), SP (N = 4), EX (N = 5), HQ ( For each of the five modes of N = 7), the recording time (in the case of a 64MB memory card), the data transfer rate, and the number of SUs in one block are shown. The number of bytes in 1SU is (mono: 136 bytes, LP: 192 bytes, SP: 304 bytes, EX: 384 bytes, HQ: 512 bytes). In addition, with bit 7, ATRAC3 mode (0: Dual) 1: Joint) is shown. [0148] As an example, a case where a 64MB memory card is used and the SP mode is used will be described. The 64MB memory card has 3968 blocks. In SP mode, 1SU is 304 bytes, so there are 53SUs in one block. 1SU corresponds to (1024/44100) seconds. Therefore, one block is (1024/44100) x 53 x (3968-16) = 4863 seconds = 81 minutes. The transfer rate is (44100/1024) x 304 x 8 = 104737 bps Will be. [0149] LT (1 byte) Meaning: Playback limit flag (bit 7 and bit 6) and security version (Bit 5-bit 0) Function: Indicates that there are restrictions on this track<img file="JP4660899B2_D0003.tif" />Bit 5-Bit 0: Security version 0 (If it is other than 0, playback is prohibited) [0150] FNo (2 bytes) Meaning: File number Function: The track number when it was first recorded, and this value locates the value for MAC calculation recorded in the hidden area in the memory card. Values: 1 to 0x190 (400) [0151] MG (D) SERIAL-nnn (16 bytes (upper: 8, Lower: 8)) Meaning: Serial number of security block (security IC20) of recording device Function: Unique values that are all different for each recording device Values: 0 to 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF [0152] CONNUM (4 bytes) Meaning: Content cumulative number Function: A unique value that is accumulated for each song and is managed by the security block of the recording device. 2 to the 32nd power, 4.2 billion songs are prepared and used to identify recorded songs Values: 0 to 0xFFFFFFFF. [0153] YMDhms-S (4 bytes) (Option) Meaning: Playback start date and time of a track with playback restrictions Function: Date and time to allow playback start specified in EMD Value: Same as the date and time notation above YMDhms-E (4 bytes) (Option) Meaning: Playback end date and time of a track with playback restrictions Function: Date and time when the playback permission specified in EMD ends Value: Same as the date and time notation above [0154] XCC (1 byte) Meaning: CC extension described below Function: Copy control [0155] CT (1 byte) (Option) Meaning: Views Function: The number of times that can actually be played within the number of times allowed to play. Decrement every time you play Value: 0x00 ~ 0xFF 0x00 when not in use If bit7 of LT is 1 and CT value is 00, playback is prohibited. [0156] CC (1 byte) Meaning: COPY CONTROL Function: Copy control Values: As shown in Figure 25, bits 6 and 7 represent copy control information, bits 4 and 5 represent copy control information for high-speed digital copying, and bits 2 and 3 represent security block authentication levels. Bits 0 and 1 are undefined CC example: (bit7,6) 11: Allow unlimited copy, 01: Copy prohibited, 00: Allow one copy (bit3,2) 00: Record from analog or digital in, MG authentication level is 0 To In digital recording from a CD, (bit7,6) is 00 and (bit3,2) is 00. [0157] CN (1 byte) (Option) Meaning: Number of copies allowed in High speed Digital Copy Management System (HSCMS) Function: Expands the distinction between copy once and copy free, and specifies by the number of times. Only valid for copy 1st generation, subtract for each copy Values: 00: Copy prohibited, 01 to 0xFE: Number of times, 0xFF: Unlimited number of times. [0158] Following the above-mentioned track information area TRKINF, the 24-byte data starting from 0x0370 is called the parts information area PRTINF for parts management, and when one track is composed of multiple parts, the PRTINFs are arranged in the order of the time axis. I will go. Figure 26 shows the PRTINF part. The data in PRTINF will be described below according to the arrangement order. [0159] PRTSIZE (4 bytes) Meaning: Part size Function: Represents the size of the part. Cluster: 2 bytes (highest), start SU: 1 byte (upper), end SU: 1 byte (lowest) Values: Cluster: 1 to 0x1F40 (8000), Start SU: 0 to 0xA0 (160), End SU: 0 to 0xA0 (160) (However, SUs are counted from 0,1,2, and 0. ) [0160] PRTKEY (8 bytes) Meaning: Value for encrypting the part Function: Initial value = 0, follow editing rules when editing Values: 0 to 0xFFFFFFFFFFFFFFFF [0161] CONNUM0 (4 bytes) Meaning: First created content cumulative number key Function: The role of ID to make the content unique Value: Content cumulative number Same value as the initial value key. [0162] Return to Figure 21. Additional information INF is included in the attribute header of the ATRAC3 data file, as shown in Figure 21. INF is additional information data about the track, which is variable-length additional information data with a header. Multiple different additional information may be lined up. An ID and data size are added to each. The additional information data including each header is a unit of an integral multiple of 4 bytes with a minimum of 16 bytes. [0163] The data of each block of the ATRAC3 data file follows the attribute header described above. As shown in FIG. 27, a header is added for each block. The data of each block will be described below. [0164] BLKID-A3D (4 bytes) Meaning: BLOCKID FILE ID Function: A value to identify the beginning of ATRAC3 data Value: Fixed value = A3D (eg 0x41334420) [0165] MCode (2 bytes) Meaning: MAKER CODE Function: Code that identifies the make and model of the recorded device Value: Upper 10 bits (manufacturer code) Lower 6 bits (model code) [0166] CONNUM0 (4 bytes) Meaning: Cumulative number of first created content Function: The role of ID to make the content unique, the value does not change even if edited Value: Content cumulative number Same value as the initial value key [0167] BLOCK SERIAL (4 bytes) Meaning: Serial number assigned to each track Function: The beginning of a block starts from 0 and the next block is incremented by +1 Does not change the value when edited Value starts at 0 and ends at 0xFFFFFFFF [0168] BLOCK-SEED (8 bytes) Meaning: One key to encrypt one block Function: At the beginning of the block, a random number is generated by the security block of the recording device, the following block is a value incremented by +1. If this value is lost, no sound can be produced for about 1 second, which is equivalent to 1 block. , The same thing is written twice in the header and the end of the block. Does not change the value when edited Value: Initially an 8-byte random number [0169] INITIALIZATION VECTOR (8 bytes) Meaning: Initial value required when encrypting and decrypting ATRAC3 data for each block Function: The first block starts at 0 and the next block is the last encrypted 8-byte value of the last SU. If it is from the middle of the divided block, use the last 8 bytes immediately before the start SU. Does not change the value when edited Values: 0 to 0xFFFFFFFFFFFFFFFF [0170] SU-nnn Meaning: Sound unit data Function: Data compressed from 1024 samples, the number of bytes output differs depending on the compression mode. Does not change the value even if edited (for example, N = 384 bytes in SP mode) Value: ATRAC3 data value. [0171] In FIG. 21, since N = 384, 42SU is written in one block. In addition, the first two slots (4 bytes) of one block are used as headers, and BLKID-A3D, MCode, CONNUM0, and BLOCK SERIAL are double written in the last one slot (2 bytes). Therefore, the remaining area M bytes of one block is (16,384-384 × 42-16 × 3 = 208 (bytes). As described above, 8-byte BLOCK SEED is recorded twice in this. [0172] Here, the data stored in the flash memory 34 is compressed by, for example, the ATRAC3 method, as will be described later. The unit of compression is the sound unit SU. Therefore, when reading data from the storage device 300 to the playback device 200, the minimum unit of reading is the sound unit SU. The audio data compression method may be a CODEC method other than the ATRAC method such as ATRAC3. [0173] The block seed data BS is data generated by generating, for example, a random number for each block. [0174] [Flash memory management module 35] The flash memory management module 35 controls such as writing data to the flash memory 34 and reading data from the flash memory 34. [0175] The configuration of the reproduction device 200 shown in FIG. 15 will be described. The playback device 200 includes, for example, a main control module 41, a communication interface 42, a control module 43, an editing module 44, a compression / decompression module 45, a speaker 46, a D / A converter 47, and an A / D converter 48. [0176] [Main control module 41] The main control module 41 comprehensively controls the processing of the reproduction device 200. [0177] [Control module 43] As shown in FIG. 15, the control module 43 includes, for example, a random number generation unit 60, a storage unit 61, a key generation / key calculation unit 62, a mutual authentication unit 63, an encryption / decryption unit 64, and a control unit 65. Like the control module 33, the control module 43 is an integrated circuit dedicated to single-chip cryptographic processing, has a multi-layer structure, and an internal memory cell is sandwiched between dummy layers such as an aluminum layer. Further, the control module 43 has a narrow range of operating voltage or operating frequency, and has tamper resistance so as not to illegally read data from the outside. When the random number generation unit 60 receives a random number generation instruction, it generates a 64-bit (8-byte) random number. The storage unit 61 stores various data required for the authentication process. [0178] The key generation / key calculation unit 62 generates key data by performing various calculations such as a calculation using the MAC calculation method of ISO / IEC9797. At this time, FIPS PUB as "Block cipher Algorithm" The DES specified in 46-2 is used. [0179] The mutual authentication unit 63 performs a mutual authentication process with the storage device 300 prior to performing an operation of outputting the audio data input from the computer to the storage device 300, for example. Further, the mutual authentication unit 63 performs a mutual authentication process with the storage device 300 prior to performing an operation of inputting audio data from the storage device 300. Further, the mutual authentication unit 63 performs the MAC calculation described above in the mutual authentication process. In the mutual authentication process, the data stored in the storage unit 61 is used. The mutual authentication unit 63 is, if necessary, for example, the personal computer (PC) 100 or the network prior to the operation of inputting / outputting audio data to / from the personal computer (PC) 100 or a computer on the network. Mutual authentication processing is performed with the above computer. [0180] As described above, the encryption / decryption unit 64 selectively uses the ECB mode and the CBC mode specified in the FIPS PUB 81 to perform block encryption. [0181] The encryption / decryption unit 64 selectively decrypts the ECB mode and the CBC mode among the modes of FIPS81. Here, in the CBC mode, the encryption / decryption unit 64 decrypts the ciphertext in units of 64-bit encryption blocks using, for example, 56-bit key data k, and generates plaintext. [0182] The control unit 65 comprehensively controls the processing of the random number generation unit 60, the storage unit 61, the key generation / key calculation unit 62, the mutual authentication unit 63, and the encryption / decryption unit 64. [0183] [Editing module 44] For example, as shown in FIG. 16, the editing module 44 edits the track data file stored in the flash memory 34 of the storage device 300 based on an operation instruction from the user to generate a new track data file. [0184] [Compression / decompression module 45] The compression / decompression module 45 decompresses the audio data compressed by the ATRAC3 method when the encrypted audio data input from the storage device 300 is decrypted and then played back, and the decompressed audio data is D. / A Output to converter 47. Further, for example, when the audio data input from the CD, DVD or PC1 is stored in the storage device 300, the audio data is compressed by the ATRAC3 method. [0185] [D / A converter 47] The D / A converter 47 converts the digital format audio data input from the compression / decompression module 45 into analog format audio data and outputs it to the speaker 46. [0186] [Speaker 46] The speaker 46 outputs sound according to the audio data input from the D / A converter 47. [0187] [A / D converter 48] For example, the A / D converter 48 converts the analog format audio data input from the CD player 7 into a digital format and outputs it to the compression / decompression module 45. [0188] [Memory 49] The memory 49 is, for example, an E2PROM (ex. Flash memory), and is a key data such as the above-mentioned key activation block (EKB) or a device key block (DKB) generated based on the EKB, and a device as a device identifier. ID etc. are stored. [0189] [Storage processing and playback processing of content data in the storage device] Content data is moved between the playback device 200 and the storage device 300 shown in FIG. 15, that is, data recording processing is executed from the playback device 200 to the flash memory 34 of the storage device 300, and further, the flash of the storage device 300 is executed. Data reproduction processing is executed from the memory 34 to the reproduction device 200. [0190] The data recording and reproduction processing will be described below. First, the data recording process from the reproduction device 200 to the flash memory 34 of the storage device 300 will be described with reference to the flow of FIG. 28. [0191] Prior to data movement, the playback device and the storage device first execute the mutual authentication process shown in steps S2701 and S2702. Figure 29 shows a mutual authentication method (ISO / IEC) using a common key cryptosystem. 9798-2) is shown. In FIG. 29, DES is used as the common key cryptosystem, but other methods are also possible as long as it is a common key cryptosystem. In FIG. 29, B first generates a 64-bit random number Rb, and transmits Rb and ID (b), which is its own ID, to A. Upon receiving this, A newly generates a 64-bit random number Ra, encrypts the data in the order of Ra, Rb, and ID (b) using the key Kab in the CBC mode of DES, and returns it to B. The key Kab is a key stored in each recording element as a secret key common to A and B. In the encryption process using the key Kab using the CBC mode of DES, for example, in the process using DES, the initial value and Ra are exclusively logically summed, and the DES encryption unit encrypts using the key Kab. The cipher statement E1 is generated, then the cipher statements E1 and Rb are exclusively logically summed, and the DES encryption unit encrypts the cipher statement E1 using the key Kab to generate the cipher statement E2, and further, the cipher statement E2 and the ID. The transmission data (Token-AB) is generated by the DES encryption unit, which is the exclusive logical sum of (b) and the encryption sentence E3 generated by encrypting with the key Kab. [0192] Upon receiving this, B decodes the received data with the key Kab (authentication key), which is also stored in each recording element as a common secret key. To decrypt the received data, first, the ciphertext E1 is decrypted with the authentication key Kab to obtain a random number Ra. Next, the ciphertext E2 is decrypted with the authentication key Kab, and the result and E1 are exclusively ORed to obtain Rb. Finally, the ciphertext E3 is decrypted with the authentication key Kab, and the result and E2 are exclusively ORed to obtain the ID (b). Of the Ra, Rb, and ID (b) thus obtained, it is verified whether Rb and ID (b) match those transmitted by B. If it passes this verification, B authenticates A as legitimate. [0193] Next, B generates a session key (Kses) to be used after authentication (the generation method uses random numbers). Then, in the order of Rb, Ra, and Kses, it is encrypted using the authentication key Kab in the CBC mode of DES and returned to A. [0194] Upon receiving this, A decrypts the received data with the authentication key Kab. Since the method for decoding the received data is the same as the decoding process for B, details will be omitted here. Of the Rb, Ra, and Kses obtained in this way, it is verified whether Rb and Ra match those transmitted by A. If it passes this verification, A authenticates B as legitimate. After authenticating each other, the session key Kses is used as a common key for secret communication after authentication. [0195] If any invalidity or inconsistency is found during the verification of the received data, the process is terminated as if mutual authentication failed (No in S2703). [0196] If mutual authentication is established (Yes in S2703), the playback device executes the content key Kcon generation process in step S2704. This process is executed in the key generation / key calculation unit 62 using the random numbers generated in the random number generation unit 60 of FIG. [0197] Next, in step S2705, (1) the content key Kcon is encrypted using the encryption key KEK obtained from the activation key block (EKB) to generate E (KEK, Kcon), and ( 2) The content key Kcon is encrypted with the session key (Kses) generated in the authentication process to generate E (Kses, Kcon) and send it to the storage device (memory card). [0198] In step S2706, the storage device decrypts the E (Kses, Kcon) received from the playback device with the session key to obtain the content key Kcon, and further encrypts the Kcon with the storage key Kstm stored in the storage device in advance. E (Kstm, Kcon) is generated and sent to the playback device. [0199] Next, in step S2707, the playback device uses the E (KEK, Kcon) generated in step S2705 and the E (Kstm, Kcon) received from the storage device in step S2706 to generate a data file (see FIG. 21). The constituent track information area TRKINF data is generated, and after the data file is formatted, it is transmitted to the storage device (memory card). [0200] In step S2708, the storage device (memory card) stores the data file received from the playback device in the flash memory. [0201] By such processing, the track information area TRKINF data of the data file has the encryption key KEK obtained from the enable key block (EKB) of the content key Kcon as shown in FIGS. 21 and 23 described above. Two encrypted content keys, E (KEK, Kcon) encrypted using and E (Kstm, Kcon) encrypted by the storage key Kstm in which the content key Kcon is stored in the storage device in advance, are stored. Will be. [0202] The encryption process of music data, image data, etc. is executed by applying the content key Kcon as it is as the content encryption key, or by using the parts or blocks that make up the content as a unit, the content key and others. It is possible to individually generate an encryption key for each part or block based on the key generation data of the above, and perform encryption processing for each part or block. [0203] In the reproduction process using such a data file, the reproduction device can selectively apply either E (KEK, Kcon) or E (Kstm, Kcon) to acquire the content key Kcon. [0204] Next, the process of reading the data stored in the flash memory 34 of the storage device 300, that is, the process of executing the reproduction process will be described with reference to the flow of FIG. 30. [0205] Prior to data movement, the playback device and the storage device first execute the mutual authentication process shown in steps S2901 and S2902. This process is the same as the process of FIG. 29 described above. If mutual authentication fails (No in S2903), the process ends. [0206] If mutual authentication is established (Yes in S2903), the storage device transmits the data file to the playback device in step S2904. The playback device that receives the data file inspects the track information area TRKINF data in the data file and determines the storage status of the content key (Kcon). This determination process is a process for determining whether or not the content key encrypted by the encryption key KEK acquired by the key activation block (EKB), that is, E (KEK.Kcon) is stored. The presence or absence of E (KEK.Kcon) can be determined from the [EKI] data of the track information area TRKINF data in the data file described in FIGS. 21 and 23 above. [0207] If E (KEK.Kcon) is stored (Yes in step S2906), proceed to step S2907 to obtain the encryption key KEK by processing the key activation block (EKB) and obtain the encryption key. Decrypt E (KEK.Kcon) with KEK to get the content key Kcon. [0208] When E (KEK.Kcon) is not stored (No in step S2906), in step S2908, in the control module 33 of the storage device, E (Kstm) encrypted by the storage key Kstm stored in advance in the storage device is used. , Kcon) is decrypted by the storage key Kstm, and further, the data E (Kses, Kcon) encrypted by the session key Kses shared by the playback device and the storage device in the mutual authentication process is generated and transmitted to the playback device. .. [0209] In step S2909, the playback device decodes E (Kses, Kcon) received from the storage device with the session key Kses to acquire the content key Kcon. [0210] In step S2910, the encrypted content is decrypted by the content key Kcon acquired in either step S2907 or step S2909. [0211] In this way, in the playback process of the encrypted content, the playback device decrypts E (KEK, Kcon) using the encryption key KEK obtained from the activation key block (EKB), or stores it in the storage device. The content key Kcon can be obtained by executing a process based on E (Kstm, Kcon) encrypted by the storage key Kstm stored in advance, or by executing either process. [0212] The decryption process of music data, image data, etc. is executed by applying the content key Kcon as it is as the content decryption key, or the content key and other keys are used in units of parts or blocks that compose the content. It is possible to individually generate a decryption key for each part or block based on the generated data and perform the decryption process for each part or block. [0213] [Format of EKB containing KEK] The general format of the activation key block (EKB) has been described earlier with reference to FIG. 6, but further, the specific case where the key encryption key (KEK) is stored and held in the activation key block (EKB). Data configuration example will be described. [0214] Figure 31 shows a configuration example of the distribution key permission information file, which is the EKB that is the data stored in the key encryption key (KEK) enabled key block (EKB). The device (playback device) takes out the key encryption key (KEK) from this file as needed, decrypts E (KEK, Kcon) with KEK, obtains the content key: Kcon, and decrypts the content. To do. Each data will be described. [0215] BLKID-EKB (4 bytes) Meaning: BLOCKID FILE ID Function: Value to identify the beginning of the distribution key information file Value: Fixed value = EKB (eg 0x454B4220) [0216] MCode (2 bytes) Meaning: MAKER CODE Function: Code that identifies the make and model of the recorded device Value: Upper 10 bits (manufacturer code) Lower 6 bits (model code) [0217] LKF Meaning: LINK FILE INFORMATION Function: Identifies the link file that is the KEK applicable content data retrieved by this EKB. Values: 0 ~ 0xFF bit7: Used for playback management file (PBLIST): 1, unused: 0 bit6: Used for tampering check value (ICV): 1, unused: 0 bit5 ~ 0: Reserve [0218] LINK count Meaning: LINK COUNT Function: Number of linked files (eg ATRACK3 files) Values: 0 ~ 0xFFFFFFFF [0219] Version Meaning: VERSION Function: Indicates the version of the distribution key permission information file. Values: 0 ~ 0xFFFFFFFF [0220] EA Meaning: Encryption Algorithm Function: Shows the trace processing algorithm of the distribution key permission information file. Values: 0 ~ 0xFF 00h: 3DES: Processing in triple DES mode 01h: DES: Processing in single DES mode The processing in the triple DES mode is an encryption process using two or more types of encryption processing keys, and the single DES mode is a processing using one key. [0221] KEK1 Meaning: Key Encrypting Key Function: Content key encrypted with root key (top level) key in key activation block (EKB) encryption key Value: 0 ~ 0xFFFFFFFFFFFFFFFF [0222] KEK2 Meaning: Key Encrypting Key Function: Content key encrypted with root key (top level) key in key activation block (EKB) encryption key Value: 0 ~ 0xFFFFFFFFFFFFFFFF [0223] E (Version) Meaning: Encrypted Version Function: The version number encrypted with the root key (top level) key in the key activation block (EKB). The last 4 bytes at the time of decryption is reserved Value: 0 ~ 0xFFFFFFFFFFFFFFFF [0224] Size of tag part Meaning: Size of tag part Function: Size of the tag part of the data that makes up the distribution key permission information file (Byte) Values: 0 ~ 0xFFFFFFFF [0225] Size of Key part Meaning: Size of key part Function: Size of the key part of the data that makes up the distribution key permission information file (Byte) Values: 0 ~ 0xFFFFFFFF [0226] Size of Sign part Meaning: Size of sign part Function: Size of the signature part of the data that makes up the distribution key permission information file (Byte) Values: 0 ~ 0xFFFFFFFF [0227] Tag part Meaning: Tag part Function: Data of the tag part of the data that composes the distribution key permission information file Values: All values If it is less than 8 bytes, fill it with 0s to make it 8 bytes. [0228] Key part Meaning: Key part Function: Data of the key part of the data that composes the distribution key permission information file Values: All values [0229] Signature part Meaning: Signature part Function: Data of the signature part of the data that composes the distribution key permission information file Values: All values [0230] As shown in the description above and with reference to FIG. 31, the distribution key authorization information file provided to the device identifies a link file that is KEK-applicable content data obtained from that distribution key authorization information file. Identification data [LKF] is stored, and data [Linc Count] as the number of linked files (for example, ATRACK3 file) is stored. By referring to [LKF] and [Link Count], the playback device can know whether or not there is data to which KEK is applied and the number of data obtained from the distribution key permission information file. .. [0231] [Data decoding and playback processing using link information] Efficiently use the identification data [LKF] for identifying the link file included in the distribution key permission information file described above and the data [Linc Count] as the number of linked files (for example, ATRACK3 file). A processing mode for executing decoding and reproduction will be described below. [0232] FIG. 32 shows an example of data file configuration stored in the data storage area of the storage device, for example, the flash memory 34 of the storage device 300 shown in FIG. Here, only the directory structure of music data (HIFI) is shown as an example, but a directory such as an image file may also exist. [0233] The music data directory shown in FIG. 32 includes a playback management file (PBLIST) and a plurality of ATRACK3 data files (A3D) as encrypted contents. In addition, the storage device stores a plurality of activation key block files (EKBn). The activation key block file (EKBn) for acquiring the content key applied to the decryption process of the ATRACK3 data file (A3D) is determined by the pointer contained in the ATRACK3 data file (A3D). As shown in FIG. 32, one activation key block file (EKB1) 3101 is applied to the decryption process of multiple (3) ATRACK3 data files (A3D). [0234] In this case, [Linc] in the distribution key permission information file corresponding to the activation key block file (EKB1) 3101. Count] will store data indicating that it applies to the three contents. [0235] FIG. 33 shows a processing flow when content is decrypted from a memory card which is a storage device storing a plurality of content files and a plurality of activation key block files as shown in FIG. 32 and played back. [0236] The process of FIG. 33 is a process executed by the playback device when, for example, a memory card as a storage device is set in the playback device, or when the power of the playback device in which the memory card is mounted is turned on. [0237] First, in step S3201, the playback device reads the track information of each EKB file and checks [Linc Count]. Furthermore, a predetermined number [n] of EKB files are selected in descending order of the number of counts of [Linc Count]. The number [n] is set as a number corresponding to the number that can be stored in the predetermined memory area of the playback device, that is, the area that stores and holds the key encryption key: KEK. [0238] Next, in step S3202, a plurality of [n] key encryption keys: KEKs are acquired by processing the selected EKB, and these are stored in a predetermined area of RAM set as a key storage area of the playback device. [0239] Next, the playback device selects the content to be decrypted and played back in step S3203. Further, in step S3204, it is determined whether or not the KEK applied to decrypt the selected content is stored in the RAM, and if Yes, the process proceeds to step S3205, and E (KEK, Kcon) is based on the corresponding KEK. ) Is decrypted to obtain the content key, and the data is played back in step S3209, that is, the data is decrypted and played back by the obtained content key. [0240] In step S3204, if the KEK applied to decrypt the selected content is not stored in RAM, in step S3206, the presence or absence of the content key encrypted with the storage key, that is, E (Kstm, Kcon) is determined. If there is, in step S3207, the content key is acquired by the decoding process of E (Kstm, Kcon), and the content key is reproduced in step S3209, that is, the data decoding and reproduction processing by the acquired content key is executed. [0241] If it is determined in step S3206 that there is no E (Kstm, Kcon), the EKB to be applied to the content to be decrypted is acquired from the storage device, and the KEK is acquired by the decryption process of the acquired EKB. The decryption process of E (KEK, Kcon) by the KEK is executed to acquire the content key, and the content key is reproduced in step S3209, that is, the data is decrypted and reproduced by the acquired content key. [0242] In this way, the playback device checks the [Linc Count] of the plurality of key activation blocks (EKB) stored in the storage device in advance, and [Linc]. By decrypting the EKB with a large number of Count] and storing the key encryption key: KEK, the KEK stored in RAM can be applied with high probability during content playback processing. Therefore, efficient content playback can be executed. [0243] [Authentication key distribution by key activation block (EKB)] In the key distribution using the above-mentioned activation key block (EKB), by distributing the authentication key IKn used when executing the authentication process, an authentication key shared as a secure private key is provided, and a common key is provided. A configuration for executing the authentication process according to the method will be described. [0244] The mutual authentication method (ISO / IEC 9798-2) using the common key cryptosystem is the process described above using Fig. 29, and the validity of both is confirmed as the process before data transmission / reception is executed. It is executed as a process to do. In the authentication process, data is transmitted and received, for example, the playback device and the storage device share the authentication key Kab. This common key Kab is distributed to the playback device using the activation key block (EKB) described above. [0245] Fig. 34 and Fig. 35 show a configuration example in which the authentication key IKn common to multiple devices is distributed by the enable key block (EKB). Figure 34 shows an example of delivering a decryptable authentication key IKn to device 0,1,2,3, and Figure 35 shows device 0, which revokes (excludes) device 3 in device 0,1,2,3. An example of delivering an authentication key that can be decrypted only to 1 and 2 is shown. [0246] In the example of FIG. 34, the data (b) in which the authentication key IKn is encrypted by the update node key K (t) 00, and the node key updated by the node keys and leaf keys of the devices 0, 1, 2, and 3, respectively, are used. Generates and distributes an enablement key block (EKB) that can decrypt K (t) 00. As shown on the right side of FIG. 34, each device first obtains the updated node key K (t) 00 by processing (decrypting) the EKB, and then obtains the obtained node key K (t) 00. It is possible to obtain the authentication key IKn by decrypting the authentication key: Enc (K (t) 00, IKn) encrypted using it. [0247] Even if the other devices 4, 5, 6, 7 ... receive the same activation key block (EKB), the node key that they own and the leaf key are the node keys K (t) that have been updated by processing the EKB. Since 00 cannot be obtained, the authentication key can be safely sent only to legitimate devices. [0248] On the other hand, in the example of FIG. 35, assuming that device 3 is revoked (excluded) due to, for example, a key leak, activation that can be decrypted only for members of other groups, that is, devices 0,1,2, This is an example of generating and distributing a key block (EKB). Deliver the data in which (a) the activation key block (EKB) and (b) the authentication key (IKn) are encrypted with the node key (K (t) 00) shown in Fig. 35. [0249] The decoding procedure is shown on the right side of FIG. 35. First, the devices 0, 1, and 2 acquire the update node key (K (t) 00) from the received activation key block by the decryption process using the leaf key or the node key owned by the device 0, 1, 2. Next, the authentication key IKn is acquired by decryption with K (t) 00. [0250] Devices in other groups, such as devices 4, 5, 6 ..., even if they receive this similar data (EKB), use their own leaf key and node key to update the node key (K (t) 00). Cannot be obtained. Similarly, even in the revoked device 3, the update node key (K (t) 00) cannot be obtained with the leaf key and node key owned by the device 3, and only the device having the legitimate right decrypts the authentication key. It will be possible to use it. [0251] In this way, by using the delivery of the authentication key using EKB, it is possible to reduce the amount of data and safely deliver the authentication key that can be decrypted only by the legitimate right holder. In addition, the EKB distribution authentication key encrypted and provided by the activation key block (EKB) is generation (version) managed, update processing is executed for each generation, and the device revokes (excludes) at any time. Is possible. [0252] Due to the above-mentioned EKB authentication key providing process, the revoked device (reproduction device) cannot perform the authentication process with the storage device (for example, a memory card), and unauthorized decryption of the data becomes impossible. [0253] Further, by using the delivery of the authentication key using EKB, it is possible to store data in a storage medium other than the memory card, for example, a storage medium such as a hard disk built in the playback device, and control the playback process. [0254] As described with reference to FIGS. 28 to 30 above, in the content recording / playback processing using the storage device, the mutual authentication process is executed, and the data recording / playback is performed on condition that the mutual authentication process is established. It will be possible. This authentication processing program works effectively in processing with a storage device capable of mutual authentication processing such as a memory card, but for example, the playback device has an encryption processing function such as a hard disk or a CD-R. No, that is, it makes no sense at the time of data storage and data reproduction in a storage medium in which mutual authentication cannot be performed. Shikashi, the system of the present invention is configured to execute an authentication processing program even in data storage or data reproduction processing using such an unauthenticateable device. Since mutual authentication is not possible for hard disks, CD-Rs, etc., a virtual memory card (Memory Stick) is configured as a playback device, and authentication processing is executed between the virtual memory card and the playback device, and authentication is required to be established. As a result, it is possible to perform data storage processing on a storage medium that does not have an authentication function, or data reproduction from the storage medium. [0255] Figure 36 shows the data recording and playback processing flow using these virtual memory cards. First, the playback device executes a mutual authentication process with the virtual memory card in the playback device. In step S3502, it is determined whether or not the authentication has been established, and on the condition that the authentication has been established, the process proceeds to step S3503, and data recording / playback processing using a storage medium having no authentication function, such as a hard disk, CD-R, or DVD. To execute. [0256] If it is determined in step S3502 that the authentication has not been established, data recording and playback processing using a storage medium that does not have the authentication function of step S3503, such as a hard disk, CD-R, or DVD, is not executed. [0257] Here, the virtual memory card is configured to store the authentication key data described in FIG. 16 in advance, and the authentication key used by the playback device is provided by the key activation block as described above. .. [0258] In this way, by providing the authentication key of the playback device in the key activation block (EKB), the authentication key that can be mutually authenticated with the virtual memory card can be provided only to the device (playback device) with a legitimate license. It will be possible to deliver. Therefore, it is possible to perform a process in which a valid authentication key is not distributed to an unauthorized device, that is, a revoked playback device. For playback devices for which a valid authentication key is not provided, mutual authentication fails, and data recording using not only a memory card with an authentication function but also a storage medium without an authentication function, such as a hard disk, CD-R, or DVD, The playback process is not executed, and it is possible to eliminate data recording and playback by an unauthorized device. [0259] That is, the activation key block (EKB) that provides the authentication key can be decrypted only by the data processing device that has a legitimate license among the data processing devices that make up the leaf of the key tree, and illegal data processing that does not have a legitimate license. By providing it as an activation key block (EKB) that cannot be decrypted in the device, it is possible to prevent the establishment of authentication with the virtual memory device in the unauthorized data processing device and eliminate the use of content in the unauthorized data processing device. A licensing system with a configuration is realized. [0260] [Check Value (ICV: Integrity Check Value) storage configuration] Next, a processing configuration for generating a content integrity check value (ICV) in order to prevent content tampering, associating it with the content, and determining the presence or absence of content tampering by ICV calculation will be described. [0261] The content integrity check value (ICV) is calculated using, for example, a hash function for the content, and is calculated by ICV = hash (Kicv, C1, C2, ...). Kicv is an ICV generation key. C1 and C2 are content information, and the message authentication code (MAC) of the important information of the content is used. As mentioned above, [MAC] is also included in the ATRAC3 data file described in FIG. These are used to calculate the Integrity Check Value (ICV). [0262] Figure 37 shows an example of MAC value generation using the DES encryption processing configuration. As shown in the configuration of FIG. 37, the target message is divided into 8-byte units (hereinafter, the divided messages are referred to as M1, M2, ..., MN), and first, the initial value (Initial). Exclusive OR of Value (hereinafter referred to as IV)) and M1 (the result is referred to as I1). Next, I1 is put into the DES encryption unit and encrypted using the key (hereinafter referred to as K1) (the output is referred to as E1). Subsequently, E1 and M2 are exclusively ORed, the output I2 is put into the DES encryption unit, and the key K1 is used for encryption (output E2). Hereinafter, this is repeated to perform encryption processing on all messages. The EN that appears last is the message authentication code (MAC). As the message, partial data constituting the content-related data such as the content to be verified and the header information can be used. [0263] A hash function is applied to the MAC value of such content and the ICV generation key Kicv to generate the integrity check value (ICV) of the content. It is guaranteed that there is no tampering. For example, if the same ICV is obtained by comparing the ICV generated at the time of content generation with the ICV newly generated based on the content, it is guaranteed that the content is not tampered with, and the ICV is If they are different, it is determined that they have been tampered with. [0264] As for the integrity check value (ICV) as described above, one integrity check value (ICV) can be generated by a plurality of content MAC values generated for each content. The calculation of ICV by multiple MACs is generated by, for example, ICV = MAC (Kicv, C_MAC [0] || C_MAC [1] || C_MAC [2] || ...). [0265] The ICV generated at the time of content generation is stored, and the generated ICV and the stored ICV are compared at the time of check processing. If both ICVs match, it is determined that there is no tampering, and if the ICVs do not match, it is determined that there is tampering, and processing such as data reproduction is restricted. [0266] A storage device such as a memory card stores not only music contents but also different categories such as image data and game program data. In order to prevent falsification of the contents of each of these categories, it is an effective means for checking the contents for falsification to generate and store the integrity check value (ICV) for each category. [0267] However, when the number of contents to be stored in the memory increases, it becomes difficult to generate, store, and manage the check value for verification based on the regular content data. In particular, in recent years, in a medium having a large capacity such as a memory card using a flash memory, various categories of content data such as music data, image data, and program data are stored in the memory. In such an environment, it becomes difficult to manage the check value generation process, storage process, and falsification check process. When the check value for the entire stored data is generated, it is necessary to execute the check value generation process for the entire data to be checked. For example, when the method of obtaining the check value ICV by the message authentication code (MAC) generated in the DES-CBC mode is performed, it is necessary to execute the DES-CBC process for the entire data. This amount of calculation increases as the data length increases, and there is a problem in terms of processing efficiency. [0268] A memory card that can be used as a storage device stores many different categories of different content. By configuring the falsification check management of these different contents of the category to generate and execute the integrity check value (ICV) independent for each category, when the ICV is checked or when the ICV is changed, for example, when the data is changed. New Integrity Check Value (ICV) generation process can be executed for data in one category without affecting other categories. A configuration for storing a plurality of integrity check values (ICVs) for each category in this way will be described. [0269] FIG. 38 shows an example of the data structure stored in the storage device and the storage configuration of each integrity check value (ICV). As shown in FIG. 38, a storage unit (flash memory) such as a memory card contains a playback management file (PBLIST) in a music data directory, a plurality of ATRACK3 data files (A3D) as encrypted contents, and further. , Content data (# 1 ~ # n) belonging to a plurality of categories is stored in the memory. The plurality of categories are, for example, music data, image data, game programs, and the like. Further, even if the same image data is used, it may be managed as an independent category as a separate directory according to each data provider. [0270] Further, the management unit (entity) of the above-mentioned activation key block (EKB) may be set as one category. That is, a set of content to which the key encryption key obtained by a certain activation key block (EKB): the content key Kcon decrypted by the KEK can be applied may be set as one category. [0271] Each of the playback management file (PBLIST) and multiple ATRACK3 data files (A3D) as encrypted content contains a message authentication code (MAC) for tampering check, and is based on these MAC values. The integrity check value (ICV (con)) is generated. The MAC values of multiple contents are stored and managed as a MAC list on the sequence page of the flash memory, and the integrity check value (ICV (con)) obtained by applying the ICV generation key Kicv based on these MAC lists is Stored Saved. [0272] Figure 39 shows the sequence page format for storing content MAC values. The sequence page area is an area set as a write-protected area for general content data. The sequence page configuration of FIG. 39 will be described. [0273] E (kSTR, kCON) is a content key encrypted with the storage key of the memory card. ID (upper) and (lower) are storage areas for the identifier (ID) of the memory card. C_MAC [0] is a MAC value generated based on the configuration data of the playback management file (PBLIST). C_MAC [1] stores the MAC value generated based on the content, for example, the data of the ATRACK3 data file # 1, hereinafter, the MAC value for each content. An integrity check value (ICV (con)) is generated based on these MAC values, and the generated ICV (con) is written to the memory through the serial protocol. In addition, in order to correspond to different key systems, it is preferable to have a configuration in which ICVs generated from each key system are stored in different areas. [0274] In addition, the integrity check value (ICV) for each category generated for falsification check for each category is recorded in the pool page of the storage unit (flash memory) of the memory card. The pool page is also set as a write-protected area for general data. [0275] Figure 40 shows the pool page format that stores the integrity check values (ICVs) for each category. # 0_revision is incremented when the update data of category # 0 is set and updated. # 0_version is the version of category # 0, # 0_E (KEK, Kicv) is the ICV generation key (Kicv) encrypted with the key encryption key (KEK) of category # 0, and ICV0 is the ICV generation key (Kicv) of category # 0. Integrity check value (ICV) value. Below, similar data can be stored up to EKB # 15 for each category. [0276] The ICV check is started on condition that the power is turned on or a storage device such as a memory card is set in the playback device. Figure 41 shows the processing flow including the ICV check. [0277] First, when it is detected that the playback device is powered on or a new memory card or the like is installed, in step S4001, it is determined whether or not mutual authentication between the playback device and the storage device is possible, and if possible, it is determined. , Mutual authentication processing (see FIG. 29) between the storage device and the playback device is executed in step S4002. If it is determined in step S4001 that mutual authentication between the playback device and the storage device is not possible, the above-mentioned mutual authentication process between the virtual memory card and the playback device is executed in step S4003. [0278] It is determined in step S4004 whether or not mutual authentication is established, and if it is not established, the following processing is not executed and ends. If mutual authentication is established, the ICV calculation is executed in step S4005. The ICV is calculated based on the MAC value of each file as described above. [0279] Next, in step S4006, a comparison between the generated ICV calculated by calculation and the stored ICV stored in advance is executed. If both ICVs match, it is determined that there is no data tampering, and in step S4007, various processes such as data reproduction are executed. On the other hand, if the ICVs do not match, it is determined that the data has been tampered with, and the process ends without reproducing the data. By executing such processing, prevention of data tampering and reproduction of tampered data are eliminated. [0280] In this way, by configuring the configuration to generate and manage the integrity check value (ICV) that is independent for each category for the contents of different categories, when checking the ICV or when changing the ICV, for example, when changing the data. The process of generating a new Integrity Check Value (ICV) can be executed for the data in one category without affecting the other categories. [0281] [Extended MAC configuration] MAC (Message Authentication) for checking data tampering explained in the data content column of the playback management file or ATRACK3 data file described above. As a modified example of the generation of Code) and the storage processing for each file, the generation and storage processing of the extended MAC will be described below. [0282] Figure 42 shows an example of extended MAC generation and storage processing. FIG. 42 shows a part of the ATRACK3 data file shown in FIGS. 21 to 23 above. The MAC (Message Authentication Code) for checking data tampering is a value generated by the process described in FIG. 37 above based on the data of some data items in the ATRACK3 data file, and is stored in the file in advance. Whether or not the data has been tampered with is determined by comparing the generated MAC with the generated MAC at the time of checking. [0283] For example, in the MAC stored in the ATRACK3 data file shown in FIG. 42, the data to be checked for falsification by the MAC is set to a plurality of data items from "INF-seq #", and is based on those MAC target data items in advance. The generated MAC will be stored in the file. That is, MAC (INF-seq # || A || LT || ...). The data in parentheses is the target of MAC, that is, the data to be determined whether or not it has been tampered with. [0284] However, various information data may be stored in the ATRACK3 data file, and the data to be checked for falsification may increase. A new MAC including such increased check target data is generated and stored in a file as an extended MAC, and the original MAC generated only for the conventional falsification check target data is basically The configuration in which the falsification check target area is set as immutable will be described. [0285] In FIG. 42, the data under INF-seq # described above is set as the data to be tampered with, and the original MAC701 generated is stored in the ATRACK3 data file. [0286] Furthermore, if some of the information recorded in the INF space in the ATRACK3 data file contains data that should be subject to tampering check, the data that constitutes the MAC generation target data of the original MAC701, here [INF -Generate a new MAC based on the data to be checked for tampering in other INF spaces, including [seq #], and store this as an extended MAC in the data file. [0287] In FIG. 42, the extended MAC [MAC (INF)] 702 is generated by the MAC (INF-Seq # || path || MAC (profile) || Others ...), thus the extended MAC is It is generated based on the data that includes a part of the MAC generation target data of the original MAC and is combined with other tampering check targets. [0288] Also, when rewriting the extended MAC, that is, by rewriting the target data of the extended MAC, that is, the data below [path] in the INF area, a new extended MAC is regenerated and re-stored based on the rewritten data. When executing, rewrite [INF-seq #], which is included in the extended MAC and is also the target data of the original MAC, to generate and store a new extended MAC. [0289] In this case, since the target data [INF-seq #] has been rewritten for the original MAC as well, the calculation of the original MAC is newly executed. That is, when the extended MAC is updated, the original MAC is regenerated and restored at the same time. [0290] The rewriting of [INF-seq #] can be executed by, for example, a rewriting process by generating a new random number, an increment process of INF-seq # data, or the like. [0291] In this way, the MAC generation target data of the extended MAC generated in response to the increase in the tampering check target data includes the MAC target data of both MACs, including a part of the MAC target data of the original MAC. Since the configuration is such that when the extended MAC is updated, the original MAC is also regenerated, the data in the INF, which is new data for tampering check, is rewritten without expanding the MAC target data area of the original MAC. It is possible to always reflect the processing in the original MAC. [0292] [EKB processing between storage device and playback device] Next, a specific processing configuration for acquiring the content key applied to the decryption processing of the encrypted content will be described using the activation key block (EKB) to which the above-mentioned tree-structured key distribution system is applied. [0293] FIG. 43 shows a storage device 100 such as a memory stick that stores encrypted contents such as ATRACK3 data, and a playback device A200 and a playback device B300 that execute content playback. [0294] The storage device 100 stores the ATRACK3 data file described with reference to FIG. 21 or the like as encrypted content, and in order to reproduce the content on the playback device, the content key Kcon required for decrypting the content must be acquired. Is required. [0295] First, a processing mode in which the playback device directly acquires the content key from the storage device will be described with reference to the storage device 800 and the playback device A810 shown in FIG. First, the storage device 800 and the playback device A810 execute mutual authentication processing between the mutual control modules 801, 811 that execute the authentication processing function. Mutual authentication is executed, for example, as a mutual authentication process using the common key cryptosystem shown in FIG. 8 or the public key cryptosystem described above. In this case, the storage device 800 and the playback device A810 need that their respective control processing modules 801, 811 have an authentication processing execution algorithm and further store a key required for the authentication processing. [0296] After mutual authentication with the playback device A810 is established, the storage device 800 is a content key encrypted with the storage key Kstm of the storage device from the ATRACK3 data file stored in the flash memory 802 in the control module 801 in the storage device 800. Extract either: E (Kstm, Kcon) or the content key encrypted with the key encryption key (KEK) that can be obtained by processing the EKB file described above: E (KEK, Kcon) and perform decryption processing. Run to get the content key Kcon. [0297] The storage device 800 re-encrypts the content key Kcon using the session key Kses generated during mutual authentication with the playback device A810, and sends the generated encrypted data: E (Kses, Kcon) to the playback device A810. To do. The playback device A810 decrypts the received encrypted content key E (Kses, Kcon) with the session key Kses in the control module 811 to acquire the content key. [0298] The method described above is a method in which the content key is decrypted and taken out on the storage device side, encrypted again with the session key, and sent to the playback device. [0299] Next, an execution mode will be described in which the storage device side does not execute the decoding process and the playback device side acquires the content key. [0300] This processing mode will be described as processing between the storage device 800 and the playback device B830 of FIG. 43. The storage device 800 identifies the corresponding activation key block (EKB) required to obtain the content key from the activation key block (EKB) version (or generation) in the ATRACK3 data file, and reproduces the specified EKB. Send to device B830. [0301] The playback device B830 receives the EKB from the storage device, executes the processing of the received EKB using the device key block (DKB) stored in the memory in the playback device in advance, for example, the E2PROM (ex. Flash memory), and performs the processing of the received EKB, and the key. Obtain the encryption key (KEK). [0302] Here, the device key block (DKB) will be described. The configuration of the device key block (DKB) will be described with reference to FIG. 44. As described above, each device such as the content reproduction device has a key of each node connected to the end of the tree-structured key distribution configuration shown in FIG. 44A, that is, the leaf to the upper route. For example, the device corresponding to the end node set 5 (SET5) shown in FIG. 44 (a) reaches the key set from K101 as the leaf key, K10 and K1 as the node key to the root key Kroot, or the subcategory node key. Holds a keyset or a keyset leading to a category node. [0303] Each of these keys is encrypted in the device and stored in a memory inside the device, such as E2PROM. The device key block (DKB) is the encryption key set of the key set corresponding to the key from the leaf stored in each device to a specific node (ex. Subcategory node) or root. [0304] Figure 44 (b) shows an example of the data structure of the device key block (DKB). As shown in Fig. 44 (b), DKB is an encryption key that has data whose node key and root key are encrypted with a leaf key and data whose leaf key is encrypted with a device (ex. Playback device) storage key: Kstd. Constructed as a block. The device (ex. Playback device) decrypts Enc (Kstd, Kleaf) in this device key block (DKB) using its own storage key: Kstd, obtains the leaf key Kleaf, and further obtains the obtained leaf key Kleaf. It is possible to directly decrypt the high-level encrypted node key and encrypted root key by using, and it is possible to omit the process of sequentially decrypting from the lower key of EKB and acquiring the upper key. The device key block (DKB) includes a leaf ID, which is a leaf identifier. [0305] The device-specific storage key is a different key for each set (device), and can be stored in the secure memory (ex.SAM) in the device in advance, or can be obtained based on the leaf ID. Good. That is, it may be configured to be generated based on the leaf ID in the device control module (encryption processing unit). Specifically, a hash may be applied to the leaf ID based on the master key Kmas commonly stored in a predetermined set unit, and the hash may be obtained as Kstd = hash (Kmas, leaf ID). [0306] Returning to FIG. 43, the description of the content key acquisition process is continued. The playback device B830, which has received the activation key block (EKB) from the storage device 800, applies the node key, root key, etc. obtained by decrypting the device key block (DKB) stored in the memory 832 in the control module 831 to the EKB. Obtain the key encryption key (KEK) encrypted by. The EKB processing method is the same as that described above with reference to FIG. 5 or 9. [0307] The playback device B830 uses the key encryption key (KEK) acquired by the activation key block (EKB) process, and further decrypts the encrypted content key: E (KEK, Kcon) received from the storage device 800. Run to get the content key. [0308] The initial EKB stored in the memory (E2PROM) 832 of the playback device B830 in FIG. 43 is a simplified EKB file stored in the device (playback device B830) from the beginning. For example, the above-mentioned FIG. 11 is used. In the category node described in the above description, it is an encryption key block commonly stored in the device corresponding to the leaf connected under one category node (for example, category = memory stick). [0309] For example, if the key of the category node is K01, the root key encrypted with K01: Enc (K01, Kroot) is stored as the initial EKB. The device can obtain the root key by processing the initial EKB. For example, when the device receives the EKB containing the key encryption key (KEK) encrypted by the root key, the root key obtained from the initial EKB. It is possible to obtain the key encryption key (KEK) using. [0310] The initial EKB is not limited to the configuration in which it is provided in common to devices belonging to one category node, and may be configured in common in a plurality of category nodes. For example, if the node key of the category node of the memory stick is K01, the node key of the cantegori node of the PC with the content playback function is K10, and the node key of the category node of the network compatible form playback device is K11, Enc By setting and shipping the initial EKB that stores three types of encrypted root keys (K01, Kroot), Enc (K10, Kroot), and Enc (K11, Kroot), it can be used in common on different devices. It is possible to deliver encrypted contents. [0311] FIG. 45 shows a configuration example in which the device key block (DKB) and the activation key block (EKB) for self-recording and self-playback are stored as the initial EKB in the memory (ex.E2PROM) of the playback device. Further, FIG. 46 shows an example of content key acquisition processing using these key blocks. [0312] The configuration of FIG. 45 will be described. The device (ex. Recorder / playback device) is a device corresponding to the leaf of FIG. 45 (a) and belongs to the category of the category node Kn8 configured in the eighth stage of the tree configuration. The device key block (DKB) of Enc (Kstd, Kleaf) to Enc (Kleaf, Kn8) shown in (b) is stored in the device. This configuration is the same as the DKB described above, but the data directly encrypted and stored by the leaf key is configured as a key from the node key Kn47 directly above the leaf key to the category node key Kn8. [0313] In addition, the device has an activation key block (EKB) for self-recording and playback, and this self-recording and playback activation key block (EKB) and device key when recording and playing content on its own device. The content key Kcon is acquired by processing with the block (DKB), and the content is decrypted and encrypted. [0314] FIG. 46 shows the steps to be executed in the content key acquisition process in the device having DKB and EKB in FIG. 45 (b). First, in step S4601, the device extracts the storage key Kstd based on the leaf ID. The storage key Kstd is extracted from the secure memory in the device based on the leaf ID, or calculated based on the master key Kmas and leaf ID as described above. [0315] Next, in S4602, the device key block (DKB) processing, that is, the decoding of Enc (Kstd, Kleaf) is executed based on the storage key Kstd, and the leaf key is obtained. Next, in S4603, the device key block (DKB) processing, that is, the decoding of Enc (Kleaf, Kn8) is executed based on the leaf key Kleaf, and the category node key is obtained. Since the DKB stores the node key directly encrypted by the leaf key, it is possible to obtain the higher node key by the decryption process directly by the leaf key. [0316] Next, in step S4604, EKB processing is executed from the node key Kn8, the higher node keys are sequentially obtained, and the root key, which is the highest key, is calculated. Next, in step S4605, the decryption process of Enc (Kroot, KEK) is executed using the root key Kroot obtained by the process of the activation key block (EKB) to obtain the key encryption key KEK. Finally, in step S4606, the acquired key encryption key KEK is used to execute the decryption process of Enc (KEK, Kcon) stored in the data attached to the content data to acquire the content key Kcon. [0317] The activation key block (EKB) shown in Fig. 45 (b) is an EKB for self-recording and reuse, but when downloading various contents to the device, the EKB corresponding to the contents is also downloaded and added to the contents. It is also possible to store the EKB in the memory in association with each other and execute the process shown in FIG. 46 for the EKB corresponding to the content downloaded at the time of playing the content. The device key block (DKB) shown in FIG. 45 (b) has a configuration in which data obtained by directly encrypting the node keys of the node Kn8 in the upper eight stages with a leaf key as DKB encryption key data is stored. The node key to be used may be a node key to a higher level or a lower level. [0318] The present invention has been described in detail with reference to the specific examples. However, it is self-evident that a person skilled in the art can modify or substitute the embodiment without departing from the gist of the present invention. That is, the present invention has been disclosed in the form of an example, and should not be construed in a limited manner. In order to judge the gist of the present invention, the column of claims described at the beginning should be taken into consideration. [0319] [Effect of the invention] As described above, according to the data processing apparatus and method of the present invention, a key is associated with each of the root, node, and leaf on the path from the root of the tree in which a plurality of devices are configured as leaves. Provides the key encrypted by the activation key block (EKB), which contains the update key on the path that makes up the key tree and the encryption processing data of the upper key by the lower key, and decrypts it only on the selected legitimate device. As a possible configuration, a highly secure encryption processing key or a content distribution system is realized. [0320] Further, according to the data processing apparatus and method of the present invention, the number of contents to which the encryption processing key that can be acquired based on the EKB distribution key encryption key (KEK) encrypted by the activation key block (EKB) is applied. Since the distribution key permission information file that has the link count data indicating the above as header information is stored in the storage device, the number of applicable contents can be easily grasped and multiple activation key blocks (EKB) are stored. When storing in the device, the key encryption key (KEK) included in the activation key block (EKB) with a large number of link counts is decrypted in advance and stored in the memory, so that EKB processing when using the content can be performed. It is possible to omit it, and the efficiency of content use is realized. [Simple explanation of drawings] FIG. 1 is a diagram illustrating a concept of use of the data processing device of the present invention. FIG. 2 is a diagram showing a system configuration example and a data path example of the data processing device of the present invention. FIG. 3 is a tree configuration diagram illustrating various keys and data encryption processing in the data processing apparatus of the present invention. FIG. 4 is a diagram showing an example of various keys and an activation key block (EKB) used for data distribution in the data processing apparatus of the present invention. FIG. 5 is a diagram showing a distribution example and a decoding processing example using a content key activation key block (EKB) in the data processing apparatus of the present invention. FIG. 6 is a diagram showing a format example of an activation key block (EKB) in the data processing apparatus of the present invention. FIG. 7 is a diagram illustrating a tag configuration of an activation key block (EKB) in the data processing apparatus of the present invention. FIG. 8 is a diagram showing an example of a data configuration in which an activation key block (EKB), a content key, and content in the data processing apparatus of the present invention are distributed together. FIG. 9 is a diagram showing an example of processing on a device when an activation key block (EKB) in the data processing apparatus of the present invention, a content key, and content are distributed together. FIG. 10 is a diagram illustrating a correspondence when an activation key block (EKB) and contents are stored in a recording medium in the data processing apparatus of the present invention. FIG. 11 is a diagram illustrating an example of categorization of a hierarchical tree structure in the data processing apparatus of the present invention. FIG. 12 is a diagram illustrating a process of generating a simplified activation key block (EKB) in the data processing apparatus of the present invention. FIG. 13 is a diagram illustrating a process of generating an activation key block (EKB) in the data processing apparatus of the present invention. FIG. 14 is a diagram illustrating a simplified activation key block (EKB) in the data processing apparatus of the present invention. FIG. 15 is a block diagram showing a configuration of a playback device and a storage device in the data processing device of the present invention. FIG. 16 is a diagram illustrating data stored in a storage unit in a storage device in the data processing device of the present invention. FIG. 17 is a diagram for explaining data stored in a flash memory of a storage device in the data processing device of the present invention. FIG. 18 is a diagram schematically showing a data structure of a reproduction management file in the data processing apparatus of the present invention. FIG. 19 is a diagram schematically showing a data structure of a data file in the data processing apparatus of the present invention. FIG. 20 is a diagram showing a data structure of a reproduction management file in the data processing apparatus of the present invention in more detail. FIG. 21 is a diagram showing a data structure of a data file in the data processing apparatus of the present invention in more detail. FIG. 22 is a diagram showing a part of an attribute header of a data file in the data processing apparatus of the present invention. FIG. 23 is a diagram showing a part of an attribute header of a data file in the data processing apparatus of the present invention. FIG. 24 is a diagram showing the types of modes in the data processing apparatus of the present invention, the recording time in each mode, and the like. FIG. 25 is a diagram for explaining copy control information in the data processing apparatus of the present invention. FIG. 26 is a diagram showing a part of an attribute header of a data file in the data processing apparatus of the present invention. FIG. 27 is a schematic diagram showing a header of each data block of a data file in the data processing apparatus of the present invention. FIG. 28 is a diagram showing a data recording processing flow in the data processing apparatus of the present invention. FIG. 29 is a diagram showing a mutual authentication process applicable to the data processing apparatus of the present invention. FIG. 30 is a diagram showing a data reproduction processing flow in the data processing apparatus of the present invention. FIG. 31 is a diagram showing a format of a distribution key permission information file in the data processing apparatus of the present invention. FIG. 32 is a diagram showing a data storage mode in the data processing apparatus of the present invention. FIG. 33 is a diagram showing a data decoding processing flow using a key activation block (EKB) in the data processing apparatus of the present invention. FIG. 34 is a diagram (No. 1) showing an activation key block (EKB) in the data processing apparatus of the present invention, a data structure for distributing an authentication key together, and a processing example in the device. FIG. 35 is a diagram (No. 2) showing an activation key block (EKB) in the data processing apparatus of the present invention, a data configuration in which an authentication key is distributed together, and a processing example in the device. FIG. 36 is a diagram showing an authentication processing sequence to which a virtual memory card in the data processing apparatus of the present invention is applied. FIG. 37 is a diagram showing an example of MAC value generation used for generating an integrity check value (ICV) applicable to the data processing apparatus of the present invention. FIG. 38 is a diagram illustrating a storage mode of an integrity check value (ICV) in the data processing apparatus of the present invention. FIG. 39 is a diagram showing a sequence page format for storing MAC values in the data processing apparatus of the present invention. FIG. 40 is a diagram showing a pool page format for storing ICVs in the data processing apparatus of the present invention. FIG. 41 is a diagram showing an ICV check processing flow in the data processing apparatus of the present invention. FIG. 42 is a diagram illustrating a process of generating and storing an extended MAC that can be worn by the data processing apparatus of the present invention. FIG. 43 is a diagram illustrating a content key acquisition processing mode using a key activation block (EKB) in the data processing apparatus of the present invention. FIG. 44 is a diagram illustrating a configuration of a device key block (DKB) used in the data processing apparatus of the present invention. FIG. 45 is a diagram showing an example of a storage configuration of a device key block (DKB) and a key activation block (EKB) in the data processing device of the present invention. FIG. 46 is a diagram illustrating a content key acquisition processing mode using a device key block (DKB) and a key activation block (EKB) in the data processing device of the present invention. [Explanation of symbols] 10 Content distribution means 11 internet 12 satellite broadcasting 13 Telephone line 14 media 20 Data processing means 21 Personal computer (PC) 22 Portable device (PD) 23 Mobile phones, PDAs 24 Recorder / player, game terminal twenty five Playback device 30 Memories 100 personal computer (PC) 200 playback device 300 storage device 601 version 602 depth 603 data pointer 604 Tag pointer 605 Signature pointer 606 data part 607 Tag part 608 signature 33,43 Control module 50,60 Random number generation unit 51,61 Storage unit 52,62 Key generation / arithmetic unit 53,63 Mutual authentication unit 54,74 Encryption / Decryption Unit 55,65 control unit 34 Flash memory 44 editing module 45 compression / decompression module 46 speakers 49 memory 800 storage device 801 control module 802 flash memory 810 playback device A 811 Control module 830 Playback device B 831 Control module 832 memory