JP2002198951A - System and method for processing information, and information recording medium and program recording medium - Google Patents

Abstract

PROBLEM TO BE SOLVED: To realize a system and a method for processing information, which can execute an effective processing using an effective key block(EKB) using a categorized key structure. SOLUTION: This system comprises a configuration, which provides a device with an EKB that is generated from encrypted data of an upper key by a lower key of a key tree which has a plurality of sub trees categorized and managed by category entity, where a synthesized EKB of sub EKBs capable of decryption is configured at each sub tree set as a part tree of the key tree, so as for each of data in the synthesized EKB to be stored in a fixed length data field, and thus decryption can be executed at each device even if the sub EKBs are synthesized by any of various algorithms.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an information processing system, an information processing method, an information recording medium, and a program recording medium, and more particularly, to a distribution accompanied by an encryption process for providing various data such as contents to a specific authorized user. Systems and methods. In particular, by using a hierarchical key distribution system having a tree structure and using a key block generated according to a distribution device, for example, content key distribution as an encryption key of content, or other various security is maintained. Information processing system that enables
The present invention relates to an information processing method, an information recording medium, and a program recording medium.

[0002]

2. Description of the Related Art Recently, game programs, audio data,
2. Description of the Related Art Various software data such as image data (hereinafter, referred to as "Content") have been actively distributed through networks such as the Internet, or via circulating storage media such as DVDs and CDs. I have.
These distribution contents are stored in the PC (Pe
rsonal Computer), receiving data by game machine,
Alternatively, a storage medium is loaded and played back, or a recording device in a recording / playback device attached to a PC or the like,
For example, stored on a memory card, hard disk, etc.
It is used by new reproduction from the storage medium.

Information devices such as video game machines and PCs receive distribution contents from a network.
Alternatively, it has an interface for accessing a DVD, a CD, and the like, and further has a control unit, a program, and a RAM, a ROM, and the like used as a memory area for data necessary for reproducing the content.

[0004] Various contents such as music data, image data, and programs are transmitted from a game device used as a reproduction device, a user instruction from an information device main body such as a PC, or a user instruction through a connected input means. Is called from a storage medium, and is played back through the information device main body or a connected display, speaker, or the like.

[0005] Many software contents such as game programs, music data, image data and the like generally have distribution rights and the like owned by their creators and sellers. Therefore, when distributing these contents, certain usage restrictions, that is, only authorized users are allowed to use the software, and unauthorized duplication is not performed, that is, security is taken into consideration. It is common to adopt a configuration as described above.

[0006] One method of realizing the use restriction for the user is an encryption process of the distributed content. That is, for example, various contents such as encrypted audio data, image data, and game programs are distributed via the Internet or the like, and the distributed encrypted contents are distributed only to those who are confirmed to be authorized users. This is a means for decrypting, that is, providing a decryption key.

[0007] The encrypted data can be returned to usable decrypted data (plaintext) by a decryption process according to a predetermined procedure. Data encryption and decryption methods using an encryption key for such information encryption processing and a decryption key for decryption processing are well known in the art.

There are various types of data encryption / decryption methods using an encryption key and a decryption key. One example is a so-called common key encryption method. In the common key encryption method, an encryption key used for data encryption processing and a decryption key used for data decryption are shared, and a common user used for these encryption processing and decryption is assigned to a regular user. Thus, data access by an unauthorized user without a key is eliminated. DES (Data Encryption Standard: Data encry
ption standard).

The encryption key and the decryption key used for the above-mentioned encryption processing and decryption can be obtained by applying a one-way function such as a hash function based on a certain password or the like. 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 with a password determined by the user as an input, and an encryption key and a decryption key are generated based on the output. Conversely, it is practically impossible to obtain a password as the original data from the encryption key and the decryption key obtained in this way.

[0010] A method called a public key encryption method is a method in which processing using an encryption key used for encryption and processing for a decryption key used for decryption are different algorithms. Public key encryption is
This is a method using a public key that can be used by an unspecified user, and encrypts an encrypted document for a specific individual using a public key issued by the specific individual. A document encrypted with a public key can be decrypted only with a private key corresponding to the public key used for the encryption processing. Since the private key is owned only by the individual who issued the public key, a document encrypted with the public key can be decrypted only by the individual having the private key. A typical public key encryption method is RSA (Rivest-Shamir-Adlema).
n) There is a cipher. By using such an encryption method, a system that enables encrypted content to be decrypted only for authorized users is possible.

[0011]

In such a content distribution system as described above, a content key for encrypting the content, providing the user with the content stored in a network or a recording medium such as a DVD or a CD, and decrypting the encrypted content is provided. Is provided in many cases only to authorized users. In order to prevent unauthorized copying of the content key itself, the content key is encrypted and provided to authorized users, and the content key can be used by decrypting the encrypted content key using the decryption key possessed only by the authorized user. A configuration has been proposed.

[0012] It is generally possible to determine whether a user is a legitimate user, for example, by executing an authentication process between the content provider, which is the sender of the content, and the user device before distributing the content or the content key. Becomes In a general authentication process, a party key is confirmed and a session key valid only for the communication is generated. When the authentication is established, data such as content or a content key is generated using the generated session key. Communication is performed with encryption. Authentication methods include mutual authentication using a common key encryption method and authentication methods using a public key method, but authentication using a common key requires a system-wide common key.
This is inconvenient for updating and the like. Further, in the public key method, the calculation load is large and the required memory amount is also large, and it is not a desirable configuration to provide such a processing means in each device.

According to the present invention, it is possible to safely transmit data only to a legitimate user without relying on the mutual authentication processing between the data sender and the data receiver as described above. We propose a configuration that forms a subtree in which the key distribution tree is a category unit, that is, a category tree, and uses an encryption key block that can be applied (decryption processing) in a plurality of category trees.

Further, an activation key block (EKB), which is an encryption key data block that can be decrypted in one or more selected category trees, is generated so that it can be commonly used in devices belonging to each category tree. An information processing system, an information processing method, and an information recording medium that enable the efficiency of EKB generation and management processing by using an EKB type definition list indicating which category tree can be processed, that is, can be decoded. And a program recording medium.

Further, in the generation of the activation key block (EKB), a composite EKB of a sub-activation key block (sub-EKB) that can be decrypted in each of the sub-trees set as a partial tree of the key tree is constructed and synthesized. An information processing system and a configuration in which each of the key data in the EKB is stored in a fixed-length data field and provided as an EKB that can be decrypted in each device even when sub-EKBs are synthesized by various algorithms. It is an object to provide a processing method, an information recording medium, and a program recording medium.

[0016]

SUMMARY OF THE INVENTION A first aspect of the present invention is as follows.
A key tree is formed by associating keys with roots, nodes, and leaves on a path from the root to the leaf of a tree in which a plurality of devices are configured as leaves, and a path constituting the key tree is selected and selected. An enabling key block (EK) that has encryption processing data of an upper key by an upper lower key and that can be decrypted only in a device that can use a node key set corresponding to the selected path.
B) to a device, wherein the activation key block (EKB) is a sub-activation key block (EKB) that can be decrypted in each of subtrees set as a partial tree of the key tree. Sub-EKB), and the composite EKB
The information processing system has a configuration in which each of a plurality of key data included in the data is stored in a fixed-length data field.

Further, in one embodiment of the information processing system of the present invention, the sub-tree is a category tree that is partitioned based on a category and managed by a category entity, and the sub-validation key block (sub-EKB) Is an EK that can be processed based on a key associated with a node or leaf belonging to a category tree managed by itself in the category entity.
B and generated by the key issuing center (KDC) at the sub-EKB generated by the category entity.
, A composite EKB is generated as an EKB that can be commonly used for a plurality of category trees.

Further, in one embodiment of the information processing system of the present invention, the sub-activation key block (sub-E
KB) each have a unique algorithm, a sub-validation key block (sub-EK
B), and the key issuing center (KDC)
In the process of generating a composite EKB based on the sub-EKB, a process of storing each key data in the sub-EKB constituting the composite EKB in a fixed-length data field is performed.

Further, in one embodiment of the information processing system of the present invention, the combined EKB encrypts a node key set corresponding to each node constituting the key tree using a lower node key or a lower leaf key. A configuration including encryption key data and a tag indicating presence / absence of encryption key data at a node or a leaf position at a lower left or right position below each node position of one or more encryption key data stored in the composite EKB. It is characterized by.

Further, in one embodiment of the information processing system according to the present invention, the combined EKB selects a path constituting a simplified tree having a terminal node or a leaf at the bottom which can decode the combined EKB. A key corresponding to a node or leaf of a reconstructed hierarchical tree reconstructed by omitting unnecessary nodes is provided as encryption key data.

Further, in one embodiment of the information processing system of the present invention, the combined EKB includes a plurality of sub-EKBs.
Are generated by rearranging a plurality of pieces of encryption key data included in each of them in accordance with a node or leaf position in a key tree.

Further, a second aspect of the present invention comprises a category tree as a subtree divided on the basis of a category, and a root on a path from a root to a leaf of a tree in which a plurality of devices are configured as leaves;
A key tree in which a key is associated with each of a node and a leaf is formed, a path forming the key tree is selected, and encryption processing data of an upper key by a lower key on a selected path is included. An information recording medium storing an enabling key block (EKB) that can be decrypted only in a device that can use a corresponding node key set,
A composite EKB of a sub-validated key block (sub-EKB) that can be decrypted in each subtree set as a partial tree of the key tree is stored, and the composite EKB is stored.
The information recording medium is characterized in that each of the plurality of key data included in the information recording medium has a configuration stored in a fixed-length data field.

Further, in one embodiment of the information recording medium of the present invention, the sub-activation key block (sub-EK
B) each has its own algorithm, its own key
Sub activation key block with data length (sub EKB)
The key data storage area has a fixed length.

Further, a third aspect of the present invention is to form a key tree in which a key is associated with each of a root, a node, and a leaf on a path from a root to a leaf of a tree in which a plurality of devices are configured as leaves. Select a path constituting the key tree, have encryption processing data of an upper key by a lower key on the selected path, and enable decryption only in a device that can use a node key set corresponding to the selected path. An information processing method in a system having a configuration for providing an activation key block (EKB) to a device, wherein the activation key block (EKB) can be decrypted in each of subtrees set as a partial tree of the key tree. And a composite EKB of the sub-activation key block (sub-EKB).
An information processing method is characterized in that each of a plurality of key data included in a KB is stored in a fixed-length data field and provided to a device.

Further, in one embodiment of the information processing method of the present invention, the sub-tree is a category tree that is partitioned based on a category and managed by a category entity, and the sub-validation key block (sub-EKB) Is generated as an EKB that can be processed based on a key associated with a node or leaf belonging to a category tree managed by the category entity in the category entity, and a key issuing center (KDC)
Based on the sub-EKB generated by the category entity, an EK that can be commonly used for a plurality of category trees
It is characterized in that a combined EKB as B is generated.

Further, in one embodiment of the information processing method of the present invention, the sub-activation key block (sub-EK
B) each has its own algorithm, its own key
Sub activation key block with data length (sub EKB)
The key issuing center (KDC) performs a process of storing each of the key data in the sub-EKB constituting the composite EKB in a fixed-length data field in the process of generating the composite EKB based on the sub-EKB. It is characterized by executing.

Further, in one embodiment of the information processing method according to the present invention, the activation key block (EKB) includes a node key set corresponding to each node constituting the key tree as a lower node key or a lower leaf key. The encryption key data encrypted using the encryption key data and the encryption key data at the left or right node or leaf position below the node position of each of the one or more encryption key data stored in the validation key block (EKB). It is generated as a configuration including a tag indicating the presence or absence.

Further, in one embodiment of the information processing method according to the present invention, the activation key block (EKB) is simplified by setting a terminal node or a leaf capable of decoding the activation key block (EKB) to the lowest stage. A key corresponding to a node or a leaf of a reconstructed hierarchical tree to be reconstructed by selecting a path constituting the created tree and omitting unnecessary nodes is generated as a configuration having encryption key data.

Further, in one embodiment of the information processing method of the present invention, the combined EKB re-creates a plurality of encrypted key data included in each of a plurality of sub-EKBs according to a node or leaf position in a key tree. It is characterized by being arranged and generated.

Further, according to a fourth aspect of the present invention, there is provided a key tree in which a key is associated with each of a root, a node, and a leaf on a path from a root to a leaf in which a plurality of devices are configured as leaves. Select a path constituting the key tree, have encryption processing data of an upper key by a lower key on the selected path, and enable decryption only in a device that can use a node key set corresponding to the selected path. A program recording medium storing a computer program for causing an activation key block (EKB) generation process in a system having a configuration for providing an activation key block (EKB) to a device to be executed on a computer system, The program has a subtree that is set as a subtree of the key tree. And a step of storing each of a plurality of key data included in the combined EKB in a fixed-length data field. A program recording medium characterized by the following.

[0031]

In the configuration of the present invention, an encryption key distribution configuration having a hierarchical structure of a tree (tree) structure is used, and a key distribution method having a configuration in which each device is arranged on each leaf of an n-ary tree is used. ,
Through a recording medium or a communication line, for example, a content key that is an encryption key of the content data, an authentication key used for authentication processing, a program code, and the like are distributed together with an activation key block.

Further, the validation key block is composed of an encryption key data portion and a tag portion indicating the position of the encryption key, so that the data amount can be reduced, and the decryption process in the device can be prepared and executed quickly. It is possible. With this configuration, it is possible to safely deliver data that can be decrypted only by a legitimate device.

Further, an activation key block (EKB), which is an encryption key data block that can be decrypted in one or more selected category trees, is generated so that it can be commonly used by devices belonging to each category tree.
By using an EKB type definition list indicating which category tree can be processed, that is, can be decoded, the efficiency of the EKB generation management process can be increased.

The program recording medium of the present invention is a medium for providing 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, an FD, and an MO, and a transmission medium such as a network.

Such a program recording medium defines a structural or functional cooperative relationship between the computer program and the recording medium in order to realize a function of a predetermined computer program on a computer system. Things. In other words, by installing the computer program into the computer system via the recording medium, a cooperative operation is exerted on the computer system, and the same operation and effect as the other aspects of the present invention can be obtained. You can do it.

It should be noted that a system in the description of the present invention is a logical set of a plurality of devices, and is not limited to a device having each component in the same housing.

Still other objects, features and advantages of the present invention are:
It will become apparent from the following more detailed description based on the embodiments of the present invention and the accompanying drawings.

[0038]

DESCRIPTION OF THE PREFERRED EMBODIMENTS [System Overview] FIG. 1 shows an example of a content distribution system to which an information processing system of the present invention can be applied. The content distribution side 10 encrypts the content or the content key and transmits the encrypted content or content key to the various content reproduction devices of the content reception side 20. The device on the receiving side 20 obtains the content or the content key by decrypting the received encrypted content or the encrypted content key, etc., and reproduces image data and audio data, or executes various programs. Data exchange between the content distribution side 10 and the content reception side 20 is executed via a network such as the Internet or via a circulating storage medium such as a DVD or CD.

The data distribution means of the content distribution side 10 includes the Internet 11, satellite broadcasting 12, telephone line 13, media 14 such as DVD and CD, etc.
The devices on the content receiving side 20 include a personal computer (PC) 21 and a portable device (P
D) 22, mobile phone, PDA (Personal Digital Assis)
(Tants), a recording / reproducing device 24 such as a DVD and a CD player, and a reproducing device 25 such as a game terminal. Each device on the content receiving side 20 acquires the content provided from the content distribution side 10 from communication means such as a network or from the medium 30.

[Device Configuration] FIG. 2 is a block diagram showing the configuration of a recording / reproducing apparatus 100 as an example of the device on the content receiving side 20 shown in FIG. Recording / reproducing device 100
Are input / output I / F (Interface) 120, MPEG (Moving
Picture Experts Group) Codec 130, A / D,
Input / output I / F (Interfa
ce) 140, encryption processing means 150, ROM (Read Only M
emory) 160, CPU (Central Processing Unit) 17
0, a memory 180, and a drive 190 for a recording medium 195, which are interconnected by a bus 110.

The input / output I / F 120 receives digital signals constituting various contents such as images, sounds, and programs supplied from the outside, outputs the digital signals to the bus 110, and receives the digital signals on the bus 110. Output to the outside. The MPEG codec 130 is connected to the bus 110
MPEG-encoded data supplied via
PEG is decoded and output to the input / output I / F 140, and the digital signal supplied from the input / output I / F 140 is MPEG-encoded and output to the bus 110.
The input / output I / F 140 is an A / D, D / A converter 14
1 is built in. The input / output I / F 140 receives an analog signal as content supplied from the outside, and
A / D (Analog Digita)
l) By performing the conversion, the digital signal is output to the MPEG codec 130 as a digital signal, and the digital signal from the MPEG codec 130 is D / A (Digital Analog) converted by the A / D and D / A converter 141, Output as an analog signal to the outside.

The encryption processing means 150 is composed of, for example, a one-chip LSI (Large Scale Integrated Circuit), and performs encryption, decryption processing, or authentication processing of digital signals as contents supplied via the bus 110. , Encrypted data, decrypted data, and the like, on the bus 110. Note that the encryption processing means 150 is not limited to a one-chip LSI, and can be realized by a configuration combining various software or hardware. The configuration as the processing means by the software configuration will be described later.

The ROM 160 stores program data processed by the recording / reproducing device. CPU 170
Controls the MPEG codec 130 and the encryption processing unit 150 by executing programs stored in the ROM 160 and the memory 180. The memory 180 is, for example, a non-volatile memory, and stores a program executed by the CPU 170, data necessary for the operation of the CPU 170, and a key set used for encryption processing executed by the device. The key set will be described later. The drive 190 drives a recording medium 195 capable of recording and reproducing digital data, thereby driving the recording medium 19.
5 reads (reproduces) digital data from the bus 1
The digital data output on the bus 10 and supplied via the bus 110 is supplied to the recording medium 195 for recording.

The recording medium 195 is, for example, a DVD or a CD.
Optical disk, such as optical disk, magneto-optical disk, magnetic disk, magnetic tape, or a medium that can store digital data such as a semiconductor memory such as RAM, in this embodiment,
It is assumed that the configuration is such that it is detachable from the drive 190.
However, the recording medium 195 may be configured to be built in the recording / reproducing apparatus 100.

The encryption processing means 150 shown in FIG.
It may be configured as one one-chip LSI,
A configuration realized by a combination of software and hardware may be adopted.

[Regarding Tree Structure as Key Distribution Configuration] Next, when the cryptographic data is distributed from the content distribution side 10 to each device of the content reception side 20 shown in FIG. The holding configuration and the data distribution configuration will be described with reference to FIG.

Numbers 0 to 15 shown at the bottom of FIG. 3 are individual devices of the content receiving side 20. That is, each leaf of the hierarchical tree structure shown in FIG. 3 corresponds to each device.

Each of the devices 0 to 15 is assigned a key (node key) assigned to a node from its own leaf to the root in the hierarchical tree structure shown in FIG. 3 at the time of manufacture or shipment, or thereafter. And a key set consisting of leaf keys for each leaf is stored in the memory. K0000 to K1111 shown at the bottom of FIG. 3 are leaf keys assigned to the respective devices 0 to 15, and keys described in the second node (node) from the bottom at the top from KR (root key) at the top. : KR to K11
Let 1 be a node key.

In the tree structure shown in FIG. 3, for example, device 0 has a leaf key K0000 and a node key: K0
00, K00, K0, KR. Device 5 is K
0101, K010, K01, K0, KR.
The devices 15 are K1111, K111, K11, K
1. Own KR. Although only 16 devices 0 to 15 are described in the tree of FIG. 3 and the tree structure is also shown as a four-stage balanced and symmetrical configuration, more devices are configured in the tree. Also, each section of the tree can have a different number of stages.

Each device included in the tree structure of FIG. 3 includes various recording media, for example, a DVD, a C which is embedded in a device or detachably attached to the device.
Various types of devices using D, MD, flash memory, etc. are included. Further, various application services can coexist. FIG. 3 shows the configuration of such different devices and different applications.
A hierarchical tree structure, which is a content or key distribution configuration shown in FIG.

In a system in which these various devices and applications coexist, for example, a portion surrounded by a 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, for devices included in the group surrounded by the dotted line, common contents are collectively encrypted and sent from the provider, a content key used commonly for each device is sent, or each device is sent. , The content payment data is also encrypted and output to a provider or a settlement institution. An organization that transmits and receives data to and from each device, such as a content provider or a payment processing organization, is shown in FIG.
, Ie, devices 0, 1, 2, 3
Is executed as a group and data is sent collectively. A plurality of such groups exist in the tree of FIG. An organization that transmits and receives data to and from each device, such as a content provider or a payment processing organization, functions as message data distribution means.

It should be noted that the node key and the leaf key have a certain 1
May be managed by one key management center,
It is also possible to adopt a configuration in which each group is managed by message data distribution means such as a provider or a settlement institution that performs various types of data transmission / reception for each group. These node keys and leaf keys are updated in the event of, for example, leakage of keys, and this update processing is executed by a key management center, a provider, a payment institution, or the like.

In this tree structure, as is apparent from FIG. 3, three devices 0, 1, 2, 3 included in one group have a common key K00 as a node key.
It owns K0 and KR. By using this node key sharing configuration, for example, a common content key can be provided only to the devices 0, 1, 2, and 3. For example, if the commonly owned node key K00 itself is set as a content key, only the devices 0, 1, 2, and 3 can set a common content key without sending a new key. Further, a value Enc (K) obtained by encrypting the new content key Kcon with the node key K00.
00, Kcon) via the network or stored in a recording medium and distributed to the devices 0, 1, 2, and 3, only the devices 0, 1, 2, and 3 have the shared node key K00 held in each device. Decrypts the content Enc (K00, Kcon) using
Kcon can be obtained. Note that Enc (K
a, Kb) indicates that Kb is data encrypted by Ka.

At a certain time t, if it is found that the key: K0011, K001, K00, K0, KR possessed by the device 3 has been analyzed and revealed by an attacker (hacker), then the system (device) 0,1,
In order to protect data transmitted / received in the group (2, 3), it is necessary to disconnect the device 3 from the system. For that purpose, node keys: K001, K00, K0, KR
With new keys K (t) 001, K (t) 00, K
It is necessary to update to (t) 0, K (t) R and to inform the devices 0,1,2 of the updated key. Here, K (t) a
“aa” indicates that the key is an update key of the generation of the key Kaaaa: t.

The update key distribution process will be described. The key is updated, for example, by storing a table constituted by block data called an enabling key block (EKB) shown in FIG. 2
To be performed. Note that the activation key block (EKB) is composed of an encryption key for distributing a newly updated key to devices corresponding to each leaf configuring the tree structure as shown in FIG. The activation key block (EKB) is sometimes called a key renewal block (KRB).

The activation key block (E) shown in FIG.
KB) is configured as block data having a data structure that can be updated only by a device that requires updating of the node key. The example of FIG. 4 is block data formed for the purpose of distributing an updated node key of generation t in devices 0, 1, and 2 in the tree structure shown in FIG. As is clear from FIG. 3, device 0, device 1
Are K (t) 00, K (t) 0,
K (t) R is required, and the device 2 uses K (t) 001, K (t) 00, K (t) 0,
K (t) R is required.

As shown in the EKB of FIG.
B includes a plurality of encryption keys. The encryption key at the bottom is Enc (K0010, K (t) 001).
This is the updated node key K (t) 001 encrypted by the leaf key K0010 of the device 2, and the device 2 can decrypt this encrypted key by its own leaf key to obtain K (t) 001. . Also, using K (t) 001 obtained by decoding, FIG.
(A) The second-stage encryption key Enc (K (t) 0 from the bottom)
01, K (t) 00) can be decrypted, and an updated node key K (t) 00 can be obtained. FIG. 4
(A) The encryption key Enc (K (t) 0 in the second stage from the top)
0, K (t) 0) and the updated node key K (t)
0, the encryption key Enc (K
(T) 0, K (t) R) is decoded to obtain K (t) R. On the other hand, device K0000. K0001 is the node key K
000 is not included in the object to be updated, and K (t) 00, K (t) 0, K
(T) R. Device K0000. K0001 is
The encryption key Enc (K00
0, K (t) 00) to obtain K (t) 00,
Hereinafter, the encryption key Enc in the second stage from the top in FIG.
(K (t) 00, K (t) 0) is decrypted, and the updated node key K (t) 0, the encryption key Enc (K (t) 0, K ( t) R) and K (t) R
Get. Thus, the devices 0, 1, and 2 can obtain the updated key K (t) R. Note that FIG.
Indicates the absolute addresses of the node key and leaf key used as the decryption key.

In the case where it is not necessary to update the node keys K (t) 0 and K (t) R in the upper stage of the tree structure shown in FIG. 3 and it is necessary to update only the node key K00, FIG. By using the activation key block (EKB) of B), the updated node key K (t) 00 is assigned to the devices 0, 1, 2, and 3.
Can be distributed to

The EKB shown in FIG. 4B can be used, for example, when distributing a new content key shared by a specific group. As a specific example, a device 0, 1, 2, 3 in a group indicated by a dotted line in FIG. 3 uses a certain recording medium, and a new common content key K is used.
(T) Assume that con is required. At this time, K, which updates the common node key K00 of the devices 0, 1, 2, 3
(T) New common updated content key using 00:
Data Enc (K (t), which is obtained by encrypting K (t) con)
K (t) con) is distributed together with the EKB shown in FIG. This distribution makes it possible to distribute data that cannot be decrypted to devices in other groups such as the device 4.

That is, if the devices 0, 1, and 2 decrypt the ciphertext using the K (t) 00 obtained by processing the EKB, the content key K (t) con at the time point t can be obtained. Will be possible.

[Distribution of Content Key Using EKB] FIG. 5 shows the content key K (t) con at time t.
As an example of processing for obtaining the data E, data E obtained by encrypting a new common content key K (t) con using K (t) 00
4 shows the processing of the device 0 that has received nc (K (t) 00, K (t) con) and the EKB shown in FIG. 4B via the recording medium. That is, this is an example in which the EKB-encrypted message data is used as the content key K (t) con.

As shown in FIG. 5, the device 0 uses the EKB at time t stored in the recording medium and the node key K000 stored in advance by the same EKB processing as described above to execute the node key. K (t) 00
Generate Further, the decrypted updated node key K (t)
The decrypted content key K (t) con is decrypted by using 00, and the decrypted updated content key K (t) con is encrypted and stored with the leaf key K0000 of its own for use later.

[Format of EKB] FIG. 6 shows a format example of the enabling key block (EKB). The version 601 is an identifier indicating the version of the activation key block (EKB). The version is the latest E
It has a function of identifying a KB and a function of indicating a correspondence relationship between contents. The depth indicates the number of layers in the hierarchical tree for the device to which the activation key block (EKB) is distributed.
The data pointer 603 indicates the activation key block (EK
B) is a pointer indicating the position of the data portion, the tag pointer 604 is the position of the tag portion, and the signature pointer 605 is a pointer indicating the position of the signature.

The data section 606 stores, for example, data obtained by encrypting a node key to be updated. For example, each encryption key related to the updated node key as shown in FIG. 5 is stored.

The tag section 607 is a tag indicating the positional relationship between the encrypted node key and leaf key stored in the data section. This tag assignment rule will be described with reference to FIG. FIG. 7 shows an example in which the enabling key block (EKB) described above with reference to FIG. 4A is sent as data. The data at this time is as shown in Table (b) of FIG. The address of the top node included in the encryption key at this time is set as the top node address. In this case, since the update key K (t) R of the root key is included, the top node address is KR. At this time, for example, the data Enc (K (t) 0, K (t) R) at the top is at the position shown in the hierarchical tree shown in FIG. Here, the next data is Enc (K (t) 00, K (t)
0) at the lower left position of the previous data on the tree. If there is data, the tag is set to 0, and if not, 1 is set. The tag is set as {left (L) tag, right (R) tag}. Data Enc (K (t) 0, K
Since there is data on the left of (t) R), the L tag = 0, and on the right there is no data, so the R tag = 1. Hereinafter, tags are set for all data, and a data sequence and a tag sequence shown in FIG. 7C are configured.

The tag has data Enc (Kxxx, Kyy).
y) is set to indicate where it is located in the tree structure. Key data Enc (Kxxx, Kyyy) stored in the data section. . . Is simply a series of data of the encrypted key, so that the position of the encryption key stored as data on the tree can be determined by the above-described tag. Instead of using the tag described above, using the node index corresponding to the encrypted data as in the configuration described in FIG. 4 above, for example, 0: Enc (K (t) 0, K (t) root ) 00: Enc (K (t) 00, K (t) 0) 000: Enc (K ((t) 000, K (T) 00) ... ,
Such a configuration using an index results in redundant data and an increased data amount, which is not preferable for distribution over a network. On the other hand, by using the above-described tag as index data indicating the key position, the key position can be determined with a small data amount.

Returning to FIG. 6, the EKB format will be further described. The signature is an electronic signature executed by, for example, a key management center, a content provider, a payment institution, or the like that has issued the activation key block (EKB). The device that has received the EKB confirms that the device is a valid activation key block (EKB) issued by a valid activation key block (EKB) issuer by signature verification.

[Distribution of Content Key and Content Using EKB] In the above-described example, an example in which only the content key is transmitted together with the EKB has been described, but the content encrypted with the content key and the content key encrypted with the content key encryption key have been described. The configuration for transmitting the content key thus encrypted and the content key encryption key encrypted by the EKB together will be described below.

FIG. 8 shows the data structure. FIG. 8 (a)
In the configuration shown in the figure, Enc (Kcon, content
t) 801 is data obtained by encrypting a content (Content) with a content key (Kcon), and Enc (K
EK, Kcon) 802 is a content key (Kco
n) with a content key encryption key (KEK: Key Encrypti)
on Key), and Enc (EKB,
KEK) 803 indicates that the data is obtained by encrypting the content key encryption key KEK with an enabling key block (EKB).

Here, the content key encryption key KEK
May be the node key (K000, K00...) Or the root key (KR) itself shown in FIG. 3, or the key encrypted by the node key (K000, K00...) Or the root key (KR). You may.

FIG. 8B shows a case where a plurality of contents are recorded on a medium, and each of them has the same Enc (EKB, KE).
K) 805 shows a configuration example in the case of using such a configuration. In such a configuration, the same Enc (EKB, EKB,
Enc (EKB, KE) without adding KEK)
Data indicating the link destination linked to K) may be added to each data.

FIG. 9 shows the contents key encryption key KEK,
4 shows an example in which the node key K00 shown in FIG. 3 is configured as an updated node key K (t) 00. In this case, in the group surrounded by the dotted frame in FIG.
Is revoked (excluded), for example, due to a key leak, (a) an activation key block (EKB) shown in FIG. b) Distribute data in which the content key (Kcon) is encrypted with the content key encryption key (KEK = K (t) 00) and (c) data in which the content (content) is encrypted with the content key (Kcon). Thus, the devices 0, 1, and 2 can obtain the content.

The decoding procedure in the device 0 is shown on the right side of FIG. The device 0 first obtains its own leaf key K000 from the received activation key block.
The content key encryption key (K
EK = K (t) 00). Next, K (t) 00
To obtain the content key Kcon, and further decrypt the content with the content key Kcon. Through these processes, the device 0 can use the content. The devices 1 and 2 process the EKB according to different processing procedures, thereby obtaining a content key encryption key (KEK = K (t) 00), and similarly making use of the content. .

Another group of devices 4 shown in FIG.
, 6,... Cannot obtain the content key encryption key (KEK = K (t) 00) using their own leaf key and node key, even if they receive the similar data (EKB). Similarly, in the revoked device 3, the content key encryption key (KEK = K (t) 0) is used for the leaf key and the node key held by the device 3 itself.
0) cannot be obtained, and only a device having a legitimate right can decrypt and use the content.

As described above, if the content key distribution using the EKB is used, it is possible to distribute the encrypted content in which the data amount is reduced and which can be safely decrypted only by the authorized user.

Although the activation key block (EKB), the content key, the encrypted content, and the like can be safely distributed via a network, the activation key block (EKB), the content key, It is also possible to store the encrypted content on a recording medium such as a DVD or a CD and provide it to the user. In this case, if the content key obtained by decrypting the activation key block (EKB) stored on the same recording medium is used for decrypting the encrypted content stored on the recording medium, the Distribution processing of encrypted content that can be used only by a leaf key and a node key held only by the right holder, that is, content distribution with limited available user devices can be realized with a simple configuration.

FIG. 10 shows an example of a configuration in which an enabling key block (EKB) is stored together with encrypted content in a recording medium. In the example shown in FIG. 10, contents C1 to C4 are stored in the recording medium, data in which an activation key block (EKB) corresponding to each stored content is stored, and an activation key of version M is further stored. The block (EKB_M) is stored. For example, EKB_
1 is a content key Kco obtained by encrypting the content C1.
nKB, for example, EKB_2 is used to generate a content key Kcon2 obtained by encrypting the content C2. 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). Decrypts the content C3
The content key of C4 can be obtained. EKB
_1 and EKB_2 are not stored on the disk,
It is necessary to obtain 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.

FIG. 11 shows a comparative example of the content key distribution using the EKB when the content key is distributed among a plurality of devices and the conventional content key distribution processing. The upper part (a) shows a conventional configuration, and the lower part (b) shows an example using the enabling key block (EKB) of the present invention.
In FIG. 11, Ka (Kb) indicates that the data is obtained by encrypting Kb with Ka.

Conventionally, as shown in FIG. 9A, authentication processing and authentication are performed between devices in order to confirm the legitimacy of a data transmitter / receiver and to share a session key Kses used for encryption processing of data transmission. Key exchange processing (AK
E: Authentication and Key Exchange) and the session key Kses on condition that authentication is established.
And the process of encrypting and transmitting the content key Kcon.

For example, in the PC shown in FIG. 11A, the content key Ks encrypted with the received session key is used.
es (Kcon) is decrypted with the session key and Kcon
Can be obtained, and the obtained Kcon is P
It is possible to encrypt with the storage key Kstr held by C itself and store it in its own memory.

In FIG. 11A, even when the content provider wants to distribute data in a form that can be used only to the recording device 1101 in FIG.
If there is a playback device, it is necessary to perform an authentication process as shown in FIG. 11A, and encrypt and distribute the content key with each session key. In addition, the intervening PC and playback device can decrypt the encrypted content key by using the session key generated and shared in the authentication process, and acquire the content key.

On the other hand, in the example using the activation key block (EKB) shown in the lower part of FIG. 11B, the activation key block (EKB) is sent from the content provider.
Data obtained by encrypting the content key Kcon with a node key or a root key obtained by processing an activation key block (EKB) (Kroot in the example of the figure)
(Kcon)), the delivered EKB
Key Kco only in devices that can process
n can be decrypted and obtained.

Therefore, for example, an enabling key block (EKB) usable only at the right end of FIG.
By transmitting the activation key block (EKB) and the data obtained by encrypting the content key Kcon with the node key or the root key obtained by the EKB processing, the intervening PC, the reproducing device, etc. EKB depending on the leaf key and node key
Cannot be executed. Therefore, a content key that can be safely used only for a legitimate device is distributed without executing processes such as an authentication process between data transmission / reception devices, generation of a session key, and a process of encrypting a content key Kcon using the session key. It is possible to do.

When it is desired to distribute a usable content key to a PC and a recording / reproducing device, a common content key is obtained by generating and distributing an enabling key block (EKB) that can be processed in each of them. It becomes possible.

[Distribution of Authentication Key Using Activation Key Block (EKB) (Common Key Method)] In the distribution of data or keys using the activation key block (EKB) described above, the validity transferred between devices is Since the encrypted key block (EKB) and the content or the content key always maintain the same encryption form, an illegal copy is generated by a so-called replay attack in which the data transmission path is stolen, recorded, and transferred again later. May be As a configuration for preventing this, it is effective means to execute the same authentication processing and key exchange processing as in the related art between the data transfer devices. Here, the authentication key Kake used in executing the authentication processing and the key exchange processing is distributed to the device using the above-described activation key block (EKB), so that the authentication key Kake is shared as a secure secret key. The configuration for performing the authentication process according to the common key method will be described. That is, this is an example in which EKB-encrypted message data is used as an authentication key.

FIG. 12 shows a mutual authentication method (ISO / IEC 9798-2) using a common key cryptosystem. In FIG.
Although DES is used as the common key encryption method, other methods can be used as long as the common key encryption method is used. In FIG. 12, first, B generates a 64-bit random number Rb, and transmits Rb and its own ID, ID (b), to A. Upon receiving this, A generates a new 64-bit random number Ra, encrypts the data using the key Kab in the DES CBC mode in the order of Ra, Rb, and ID (b), 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 processing using the key Kab using the DES CBC mode, for example, in the processing using the DES, the initial value and the Ra are exclusive-ORed, and the encryption is performed using the key Kab in the DES encryption unit. The ciphertext E1 is generated, and the ciphertext E
1 and Rb are exclusive-ORed, and in the DES encryption unit, encrypted using the key Kab to generate a ciphertext E2,
Further, the ciphertext E2 and the ID (b) are exclusive-ORed,
In the DES encryption unit, the transmission data (Token-AB) is generated by using the encrypted text E3 generated by encrypting using the key Kab.
Generate

Upon receiving this, B decrypts the received data with the key Kab (authentication key) stored in each recording element, also as a common secret key. In the method of decrypting 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 changed to the authentication key Ka.
b, and the result and E1 are XORed, and Rb
Get. Finally, the ciphertext E3 is decrypted with the authentication key Kab, and the result is XORed with E2 to obtain ID (b). Of the Ra, Rb and ID (b) thus obtained, R
Verify that b and ID (b) match what B sent. If the verification passes, B authenticates A as valid.

Next, B generates a session key (Kses) to be used after authentication (the generation method uses a random number). Then, in the order of Rb, Ra, and Kses, the data is encrypted using the authentication key Kab in the DES CBC mode, and is returned to A.

A receiving this decrypts the received data with the authentication key Kab. The decoding method of the received data is B
Since the decoding process is the same as the above, the details are omitted here. Of the Rb, Ra, Kses thus obtained, Rb
Verify that A and Ra match what A sent. If the verification passes, A authenticates B as valid. After mutually authenticating each other, the session key Kses is used as a common key for secret communication after authentication.

[0108] If an invalid or inconsistent data is found during the verification of the received data, the process is interrupted assuming that the mutual authentication has failed.

In the above-described authentication processing, A and B share a common authentication key Kab. The common key Kab is distributed to the device using the above-mentioned activation key block (EKB).

For example, in the example of FIG. 12, one of A and B is an activation key block (EK
Activation key block (EKB) generated by generating B)
The authentication key Kab may be encrypted and transmitted to the other device, or a third party may use the devices A and B
Activation Key Block (EK
B) may be generated, and the authentication key Kab may be encrypted and distributed using the activation key block (EKB) generated for the devices A and B.

FIGS. 13 and 14 show a key block (EKB) for validating an authentication key Kake common to a plurality of devices.
An example of a configuration for distributing the information is shown below. FIG. 13 shows device 0,
FIG. 14 shows an example of distributing a decryptable authentication key Kake to devices 1, 2, and 3. FIG. An example is shown in which an authentication key that can be decrypted only is delivered.

In the example of FIG. 13, the update node key K (t)
00, together with the data (b) obtained by encrypting the authentication key Kake, the activation key capable of decrypting the node key K (t) 00 updated by using the node key and leaf key of the device 0, 1, 2, 3 respectively. Generate and distribute a block (EKB). Each device first processes (decrypts) the EKB as shown on the right side of FIG.
(T) 00 is obtained, and then the obtained node key K
(T) Authentication key encrypted using 00: Enc (K
(T) 00, Kake) can be decrypted to obtain an authentication key Kake.

The other devices 4, 5, 6, 7... Receive the same activation key block (EKB), but their own node keys and leaf keys process the EKB and update the updated node key K (t). ) 00 cannot be acquired, so that the authentication key can be safely transmitted only to valid devices.

On the other hand, in the example of FIG. 14, it is assumed that the device 3 is revoked (excluded) due to, for example, leakage of a key in a group surrounded by a dotted line frame in FIG. This is an example of generating and distributing an enabling key block (EKB) that can be decrypted only for 1, 2, and 3. Data obtained by encrypting (a) an activation key block (EKB) and (b) an authentication key (Kake) with a node key (K (t) 00) shown in FIG. 14 is delivered.

The decoding procedure is shown on the right side of FIG. The devices 0, 1, and 2 first update the updated node key (K (t)) from the received activation key block by performing decryption processing using the leaf key or node key owned by the device.
00). Next, an authentication key Kake is obtained by decryption using K (t) 00.

The other groups of devices 4 shown in FIG.
, 6,... Cannot acquire the updated node key (K (t) 00) using their own leaf key and node key even if they receive the similar data (EKB). Similarly, in the revoked device 3,
The updated node key (K (t) 00) cannot be acquired with the leaf key and the node key owned by itself, and only a device having a valid right can decrypt and use the authentication key.

As described above, by using the distribution of the authentication key using the EKB, it is possible to distribute the authentication key in which the data amount is reduced and only the authorized person can safely decrypt the data.

[Public key authentication and activation key block (EK
Distribution of Content Key Using B)] Next, a description will be given of a content key distribution process using public key authentication and an enabling key block (EKB). First, a mutual authentication method using a 160-bit elliptic curve cryptosystem which is a public key cryptosystem will be described with reference to FIG. In FIG. 15, ECC is used as the public key cryptosystem, but any public key cryptosystem may be used. Also, the key size need not be 160 bits. In FIG.
First, B generates a 64-bit random number Rb and sends it to A. Upon receiving this, A newly generates a 64-bit random number Ra
And a random number Ak smaller than the prime number p. And
A point Av = Ak × G obtained by multiplying the base point G by Ak is obtained, and a digital signature A.A. for Ra, Rb, Av (X coordinate and Y coordinate) is obtained. Generate Sig and send it back to B along with A's public key certificate. Here, since Ra and Rb are each 64 bits, and the X and Y coordinates of Av are each 160 bits, an electronic signature is generated for a total of 448 bits.

A public key certificate, Ra, Rb, Av, digital signature B that has received Sig, R that A has transmitted
Verify that b matches the one generated by B. As a result, if they match, the electronic signature in the public key certificate of A is verified with the public key of the certificate authority, and the public key of A is extracted. Then, using the public key of the extracted A, the digital signature A.
Verify Sig.

Next, B generates a random number Bk smaller than the prime number p. And the point B obtained by multiplying the base point G by Bk
v = Bk × G, and a digital signature B.V. for Rb, Ra, Bv (X coordinate and Y coordinate). Generate Sig and send it back to A along with B's public key certificate.

B's public key certificate, Rb, Ra, Av, digital signature A that has received Sig, R that B has transmitted
Verify that a matches the one generated by A. As a result, if they match, the electronic signature in B's public key certificate is verified with the public key of the certificate authority, and B's public key is extracted. Then, using the public key of B, the digital signature B.
Verify Sig. After successfully verifying the electronic signature, A authenticates B as valid.

If the authentication is successful, B becomes Bk
XAv (Bk is a random number, but Av is a point on an elliptic curve, so a scalar multiplication of a point on the elliptic curve is required), A calculates Ak × Bv, and calculates the X coordinate of these points The lower 64 bits are used as a session key for subsequent communication (when the common key encryption is a 64-bit key length common key encryption). Of course, the session key may be generated from the Y coordinate, and may not be the lower 64 bits. In the secret communication after the mutual authentication, the transmission data may not only be encrypted with the session key but also may be digitally signed.

In the case of verifying the electronic signature or the verification of the received data, if an illegality or mismatch is found, the process is interrupted assuming that the mutual authentication has failed.

FIG. 16 shows an example of content key distribution processing using public key authentication and an activation key block (EKB). First, between the content provider and the PC, FIG.
The authentication processing by the public key method described in is performed. The content provider generates a content key E (Kcon), which generates an EKB that can be decrypted with the playback device serving as the content key distribution destination, the node key and the leaf key of the recording medium, and performs encryption with the updated node key;
The activation key block (EKB) is encrypted with the session key Kses generated in the authentication process between the PCs, and P
Send to C.

The PC encrypts the content key E, which has been encrypted with the session key,
(Kcon) and the activation key block (EKB)] with the session key, and then transmit them to the playback device and the recording medium.

The playback apparatus and the recording medium use the content key E (Kcon) that has been encrypted with the updated node key by using its own node key or leaf key.
Then, the content key Kcon is obtained by decrypting the activation key block (EKB)].

According to this configuration, [the content key E (Kcon) that has been encrypted with the updated node key and the activation key block (EKB)] are transmitted under the condition of authentication between the content provider and the PC. For example, even if a node key is leaked, data can be reliably transmitted to the other party.

[Distribution Using Program Code Validation Key Block (EKB)] In the above-described example, the method of encrypting and distributing the content key, the authentication key, and the like using the validation key block (EKB) has been described. However, a configuration in which various program codes are distributed using an activation key block (EKB) is also possible. That is, this is an example in which encrypted message data by EKB is used as a program code. Hereinafter, this configuration will be described.

FIG. 17 shows an example in which the program code is encrypted by, for example, an update node key of an enabling key block (EKB) and transmitted between devices. Device 170
Reference numeral 1 denotes an activation key block (EKB) that can be decrypted by a node key and a leaf key of the device 1702.
And the program code encrypted by the update node key included in the activation key block (EKB).
02. The device 1702 processes the received EKB to obtain an updated node key, and further executes decryption of the program code by the obtained updated node key to obtain a program code.

In the example shown in FIG. 17, the device 1
An example is shown in which the processing by the program code acquired in 702 is executed, the result is returned to the device 1701, and the device 1701 continues the processing based on the result.

Thus, the enabling key block (EKB)
By distributing the program code encrypted with the update node key included in the activation key block (EKB), the program code that can be decrypted by a specific device is transmitted to the specific device or group shown in FIG. It can be delivered to

[Check value (I
CV: Integrity Check Value) Next, a content integrity check value (ICV) is generated to prevent falsification of the content, and is associated with the content. A processing configuration for determining the presence or absence will be described.

The content integrity check value (ICV) is calculated using, for example, a hash function for the content, and ICV = hash (Kicv, C
1, C2,...). Kicv is ICV
It is a generated key. C1 and C2 are content information, and a message authentication code (MA) of important information of the content.
C: Message authentication Code) is used.

FIG. 18 shows an example of MAC value generation using the DES encryption processing configuration. As shown in the configuration of FIG. 18, the target message is divided into 8-byte units (hereinafter, the divided messages are referred to as M1, M2,..., MN),
First, the initial value (Initial Value (hereinafter referred to as IV))
And M1 are XORed (the result is I1).
Next, I1 is entered into the DES encryption unit, and is encrypted using a key (hereinafter, referred to as K1) (output is referred to as E1). Subsequently, E1 and M2 are XORed, the output I2 is input to the DES encryption unit, and is encrypted using the key K1 (output E2). Hereinafter, this is repeated, and encryption processing is performed on all messages. The last EN that appears is the message authentication code (MAC).
e)).

The MAC value of such content and the ICV
A content integrity check value (ICV) is generated by applying a hash function to the generated key.
For example, if the ICV generated at the time of content generation and the ICV generated based on the new content are compared and the same ICV is obtained, it is guaranteed that the content is not falsified. If different,
It is determined that there has been tampering.

[Check Value (ICV) Generation Key Kic]
Configuration for Distributing v by EKB] Next, a configuration for transmitting Kicv, which is a content integrity check value (ICV) generation key, by the above-described activation key block will be described. That is, in this example, the encrypted message data by EKB is used as a content integrity check value (ICV) generation key.

When common contents are sent to a plurality of devices in FIGS. 19 and 20, an integrity check value generation key Kicv for verifying whether the contents have been tampered with is distributed by an enabling key block (EKB). An example of the configuration will be described. FIG. 19 shows device 0,
Check value generation key Ki that can be decrypted for 1, 2, and 3
20 shows an example of distributing cv. FIG. 20 revokes (excludes) device 3 from devices 0, 1, 2, and 3
Check value generation key Kicv that can be decrypted only for
An example of distributing is shown below.

In the example of FIG. 19, the updated node key K (t)
00, the data (b) obtained by encrypting the check value generation key Kicv and the node keys K (t) 00 updated using the node keys and leaf keys of the devices 0, 1, 2, and 3 are valid. Generate and distribute an encrypted key block (EKB). First, as shown on the right side of FIG.
Is processed (decrypted) to obtain the updated node key K (t) 00.
(T) Check value generation key encrypted using 00:
Enc (K (t) 00, Kicv) can be decrypted to obtain a check value generation key Kicv.

The other devices 4, 5, 6, 7,... Receive the same activation key block (EKB), but their own node keys and leaf keys process the EKB to update the updated node key K (t). ) 00 cannot be acquired, so that the check value generation key can be safely transmitted only to the valid device.

On the other hand, in the example of FIG. 20, it is assumed that the device 3 is revoked (excluded) due to, for example, leakage of a key in a group surrounded by a dotted frame in FIG. This is an example of generating and distributing an enabling key block (EKB) that can be decrypted only for 1, 2, and 3. (A) Activation key block (EKB) and (b) check value generation key (Kic) shown in FIG.
v) is distributed with the node key (K (t) 00).

The decoding procedure is shown on the right side of FIG. The devices 0, 1, and 2 first update the updated node key (K (t)) from the received activation key block by performing decryption processing using the leaf key or node key owned by the device.
00). Next, a check value generation key Kicv is obtained by decryption using K (t) 00.

The other groups of devices 4, shown in FIG.
, 6,... Cannot acquire the updated node key (K (t) 00) using their own leaf key and node key even if they receive the similar data (EKB). Similarly, in the revoked device 3,
The updated node key (K (t) 00) cannot be obtained with the leaf key and the node key owned by itself, and only a device having a valid right can decrypt and use the check value generation key.

As described above, by using the delivery of the check value generation key using the EKB, it is possible to distribute the check value generation key in which the data amount is reduced and only the authorized right person can safely decrypt. Becomes

The integrity of such contents
By using the check value (ICV), illegal copying of the EKB and the encrypted content can be eliminated.
For example, as shown in FIG. 21, a medium 1 storing a content C1 and a content C2 together with an activation key block (EKB) capable of acquiring respective content keys.
It is assumed that this is copied to the medium 2 as it is. The EKB and the encrypted content can be copied, and this can be used in a device that can decrypt the EKB.

As shown in FIG. 21B, the configuration is such that the integrity check value (ICV (C1, C2)) is stored in association with the content properly stored in each medium. Note that (ICV (C1, C2)) indicates ICV = hash (Kicv, C1, C2) which is a content integrity check value calculated using a hash function for the content C1 and the content C2. In the configuration of FIG. 21B, the content 1 and the content 2 are properly stored in the medium 1, and the integrity check value (ICV (C1, C2)) generated based on the content C1 and the content C2 is stored. Is done. The content 2 is properly stored in the medium 2, and an integrity check value (ICV (C1)) generated based on the content C1 is stored. In this configuration, if {EKB, content 2} stored in the medium 1 is copied to the medium 2, if a new content check value is generated in the medium 2,
The CV (C1, C2) is generated, and it is clear that unlike the Kicv (C1) stored in the medium, the falsification of the content or the storage of the new content by unauthorized copying has been performed. In the device for reproducing the media, an ICV check is performed in a step before the reproducing step to determine a match between the generated ICV and the stored ICV, and if not, the reproduction is not executed. Can be prevented from being reproduced.

Further, in order to further enhance the security, the content integrity check value (ICV) may be generated based on the data including the rewrite counter. That is, ICV = hash (Kicv, c
counter + 1, C1, C2,...). Here, the counter (counter + 1)
Is set as a value that is incremented by one every time the ICV is rewritten. Note that the counter value needs to be stored in a secure memory.

Further, in a configuration in which the integrity check value (ICV) of the content cannot be stored on the same medium as the content, a configuration in which the integrity check value (ICV) of the content is stored on a different medium from the content. It may be.

For example, a read-only medium or a normal M
When storing content on media that does not take copy protection measures such as O, integrity and
If the check value (ICV) is stored, the ICV may be rewritten by an unauthorized user, and the security of the ICV may not be maintained. In such a case, the ICV is stored on a secure medium on the host machine, and content copy control (for example, check-in / check-out,
By using ICV for move), IC
V can be safely managed and the content can be checked for tampering.

FIG. 22 shows an example of this configuration. In FIG. 22, contents are stored in a read-only medium or a medium 2201 that is not protected against copying, such as a normal MO, and the integrity check value (ICV) for these contents is permitted to be freely accessed by the user. Secure media 220 on the unprotected host machine
2 to prevent unauthorized rewriting of the integrity check value (ICV) by the user. If such a configuration is adopted in which, for example, when a device loaded with the medium 2201 executes reproduction of the medium 2201, a PC or a server serving as a host machine executes an ICV check to determine whether reproduction is possible or not, an unauthorized It is possible to prevent the reproduction of the copied content or the altered content.

[Category Classification of Hierarchical Tree Structure] The encryption key is configured as a hierarchical tree structure of FIG. 3 such as a root key, a node key, a leaf key, etc.
The configuration in which the ICV generation key, the program code, the data, and the like are encrypted and distributed together with the enabling key block (EKB) has been described. The hierarchical tree structure defining the node keys and the like is classified according to the category of each device. A configuration for performing efficient and efficient key update processing, encrypted key distribution, and data distribution will be described below.

FIG. 23 shows an example of classification of categories in a hierarchical tree structure. In FIG. 23, a root key Kroot 2301 is set at the top of the hierarchical tree structure, a node key 2302 is set at the following middle, and a leaf key 2303 is set at the bottom. Each device has an individual leaf key and a series of node keys from the leaf key to the root key, the root key.

Here, as an example, a node at the M-th stage from the top is set as a category node 2304.
That is, each of the nodes in the Mth stage is a device setting node of a specific category. Hereinafter, one node at the M-th stage is defined as a vertex, and nodes and leaves at the (M + 1) -th stage and below are nodes and leaves relating to devices included in the category.

For example, one node 2 at the M-th stage in FIG.
A category [memory stick (trademark)] is set in 305, and nodes and leaves following this node are set as nodes or leaves dedicated to the category including various devices using the memory stick. That is, the nodes 2305 and below are defined as a set of related nodes and leaves of the device defined in the memory stick category.

Furthermore, a stage several stages lower than the M stage can be set as the subcategory node 2306. For example, as shown in the figure, the node of [reproduction-only device] is set as a subcategory node included in the category of the device using the memory stick in the node two levels below the category [Memory Stick] node 2305. Further, a node 23 of the playback-only device, which is a subcategory node,
06 and below, a node 2307 of a telephone with a music playback function included in the category of a dedicated playback device is set, and further below that, a [PHS] node 2308 and a [mobile phone] node included in the category of a telephone with a music playback function 230
9 can be set.

Further, the category and the sub-category are not only the types of devices, but also nodes that are independently managed by a certain maker, content provider, settlement institution, etc., ie, arbitrary units such as a processing unit, a jurisdiction unit, or a provided service unit. (These will be collectively referred to as entities hereinafter). For example, if one category node is set as a vertex node dedicated to a game device XYZ sold by a game device maker, the lower node key and leaf key below the vertex node can be stored and sold in the game device XYZ sold by the maker. After that, the distribution of the encrypted content or the distribution and update of various keys is performed by generating and distributing an enabling key block (EKB) composed of a node key and a leaf key below the vertex node key, and distributing the key. Data that can be used only for those devices can be distributed.

As described above, by setting one node as a vertex and setting the following nodes as related nodes of a category or a subcategory defined in the vertex node, a category stage or a subcategory stage is set. It is possible for a maker or a content provider that manages one vertex node to independently generate an activation key block (EKB) having that node as a vertex and distribute it to devices belonging to the vertex node and below. Key update can be performed without affecting devices belonging to other categories of nodes that do not belong.

[Key Distribution Configuration Using Simplified EKB (1)]
For example, in the tree structure of FIG.
For example, when a content key is sent to a predetermined device (leaf), an enabling key block (EKB) that can be decrypted using the leaf key and node key owned by the key distribution destination device is generated and provided. For example, FIG.
In the tree configuration shown in FIG. 7, when transmitting a key, for example, a content key, to devices a, g, and j constituting a leaf, an enabling key block (EKB) that can be decrypted at each node of a, g, and j is generated. And deliver.

For example, the content key K (t) con is encrypted with the updated root key K (t) root and the EKB
Consider the case of distribution together with In this case, the devices a, g, and j execute EKB processing using the leaf and node keys shown in FIG.
(T) Obtain the root and obtain the updated root key K
(T) Content key K (t) con by root
To obtain a content key.

The structure of the enabling key block (EKB) provided in this case is as shown in FIG. FIG.
The activation key block (EKB) shown in FIG. 6 is configured according to the format of the activation key block (EKB) described in FIG. 6 and has data (encryption key) and a corresponding tag. As described above with reference to FIG. 7, the tag indicates 0 if there is data in each direction of left (L) and right (R), and 1 if there is no data in each direction.

The device that has received the activation key block (EKB) performs decryption processing of the encryption key sequentially based on the encryption key and the tag of the activation key block (EKB), and updates the upper node's update key. Get it. As shown in FIG. 25, the data amount of the activation key block (EKB) increases as the number of steps (depth) from the root to the leaf increases. The number of steps (depth) increases in accordance with the number of devices (leaves). If the number of devices to which keys are to be distributed is large, the amount of EKB data further increases.

Such an activation key block (EKB)
A configuration that can reduce the amount of data will be described.
FIG. 26 shows an example in which the activation key block (EKB) is simplified according to the key distribution device.

As in FIG. 25, it is assumed that a key, for example, a content key is transmitted to devices a, g, and j constituting a leaf. As shown in FIG. 26A, a tree composed only of key distribution devices is constructed. In this case, the tree configuration shown in FIG. 26B is constructed as a new tree configuration based on the configuration shown in FIG. From Kroot to Kj, there is no branch at all, and only one branch needs to exist. From Kroot to Ka and Kj
In order to reach g, only a branch point is formed at K0, and 2
The tree shown in FIG. 26A having a branch configuration is constructed.

As shown in FIG. 26A, a simplified tree having only K0 as a node is generated. An activation key block (EKB) for update key distribution is generated based on these simplified trees. The tree shown in FIG. 26 (a) is re-created by selecting a path forming a two-branch tree having a terminal node or leaf at the lowest level capable of decoding an enabling key block (EKB) and omitting unnecessary nodes. 4 is a reconstructed hierarchical tree to be built. An activation key block (EKB) for update key distribution is constructed based only on keys corresponding to nodes or leaves of this reconstructed hierarchical tree.

The activation key block (EKB) described with reference to FIG. 25 stores data obtained by encrypting all keys from each leaf a, g, j to Kroot. Stores encrypted data only for the nodes that make up the simplified tree. FIG.
As shown in (b), the tag has a 3-bit configuration. Second
The third bit and the third bit have the same meaning as in the example of FIG. 25, and indicate 0 if there is data in the left (L) and right (R) directions, and 1 if there is no data in each direction. The first bit is EK
B is a bit for indicating whether or not an encryption key is stored in B, and is set to 1 when data is stored and to 0 when there is no data.

The enabling key block (EKB) stored in the data communication network or the storage medium and provided to the device (leaf) is, as shown in FIG. 26B, compared with the configuration shown in FIG. The amount of data is greatly reduced. Activation key block (EKB) shown in FIG.
Each device that has received the key can sequentially decrypt only the data of the part where 1 is stored in the first bit of the tag, thereby realizing the decryption of the predetermined encryption key. For example, the device a transmits the encrypted data Enc (Ka, K (t)
0) with the leaf key Ka to obtain the node key K (t).
0, and decrypts the encrypted data Enc (K (t) 0, K (t) root) with the node key K (t) 0 to obtain K (t) root. The device j decrypts the encrypted data Enc (Kj, K (t) root) with the leaf key Kj to obtain K (t) root.

As described above, by constructing a simplified new tree configuration constituted only by the distribution destination devices,
By generating the activation key block (EKB) using only the keys of the leaves and nodes constituting the constructed tree, the activation key block (EKB) with a small data amount is generated.
KB) can be generated, and data distribution of the enabling key block (EKB) can be efficiently executed.

[Key Distribution Configuration Using Simplified EKB (2)]
A configuration in which an enabling key block (EKB) generated based on the simplified tree shown in FIG. 26 is further simplified to reduce the data amount and enable efficient processing will be described.

In the configuration described with reference to FIG. 26, an end node which can decode the enabling key block (EKB) or a path forming a two-branch tree having leaves at the bottom is selected and unnecessary nodes are omitted. A hierarchical tree that is reconstructed. An activation key block (EKB) for update key distribution is constructed based only on keys corresponding to nodes or leaves of this reconstructed hierarchical tree.

The reconstructed hierarchical tree shown in FIG.
Update root key K (t) ro for leaves a, g, j
To enable ot to be obtained, an activation key block (EKB) shown in FIG. In the processing of the activation key block (EKB) of FIG.
Can obtain the root key: K (t) root by a single decryption process of Enc (Kj, K (t) root).
However, leaves a and g are Enc (Ka, K (t) 0)
Alternatively, after obtaining K (t) 0 by decoding Enc (Kg, K (t) 0), Enc (K (t) 0, K
(T) Root key: K
(T) Acquire root. That is, leaves a and g
Needs to execute the decoding process twice.

The simplified reconstructed hierarchical tree of FIG.
If the node K0 is performing its own management as a management node of its lower leaves a and g, for example, if it is managing a lower leaf as a subroot node described later, the leaves a and g are updated. This is effective for confirming that the key has been acquired. However, if the node K0 does not manage the lower leaf, or if the node K0 permits the update key distribution from the upper node, it is effective. 26A, the key of the node K0 may be omitted to generate and distribute an enabling key block (EKB).

FIG. 27 shows the structure of such an enabling key block (EKB). As in FIG. 26, it is assumed that a key, for example, a content key is transmitted to the devices a, g, and j that configure the leaf. As shown in FIG. 27A, a tree is constructed by directly connecting the root Kroot and each leaf a, g, j.

As shown in FIG. 27A, as shown in FIG.
A simplified tree without the node K0 is generated from the reconstructed hierarchical tree shown in FIG. An activation key block (EKB) for update key distribution is generated based on these simplified trees. The tree shown in FIG. 27A is a reconstructed hierarchical tree that is reconstructed only by a path directly connecting a leaf capable of decoding an enabling key block (EKB) and a root. An activation key block (EKB) for update key distribution is constructed based only on keys corresponding to the leaves of this reconstructed hierarchical tree.

Although the example of FIG. 27A is a configuration example in which the terminal is a leaf, for example, when the key is distributed to the highest node or a plurality of middle and lower nodes, the key is also transmitted to the highest node. It is possible to generate an enabling key block (EKB) based on a simplified tree in which the EKB is directly connected to the middle and lower nodes, and execute key distribution. As described above, the restructured hierarchical tree has a configuration in which the vertex nodes forming the simplified tree and the terminal nodes or leaves forming the simplified tree are directly connected. In this simplified tree, the number of branches from the top node is not limited to two, and it is possible to configure a tree having three or more branches according to the number of distribution nodes or leaves.

The activation key block (EKB) described with reference to FIG. 25 stores data obtained by encrypting all keys from each leaf a, g, j to Kroot. The simplified key block (EKB) stores leaf keys of leaves a, g, and j, K0 as a common node of a and g, and a root key. The simplified hierarchy shown in FIG. Since the key of the node K0 is omitted from the tree-based activation key block (EKB), the activation key block (EKB) has a smaller data amount as shown in FIG. 27B.

The activation key block (EK) shown in FIG.
B) shows the activation key block (EKB) shown in FIG.
Similarly to the above, the tag has a 3-bit configuration. Second and third
As described with reference to FIG. 26, the bit indicates 0 if there is data in the left (L) and right (R) directions, and 1 if there is no data in each direction. The first bit is a bit for indicating whether or not the encryption key is stored in the EKB, and is 1 when data is stored, and 1 when no data is stored.
Set as 0.

The enable key block (EK) shown in FIG.
In B), each leaf a, g, j is Enc (Ka,
K (t) root) or Enc (Kg, K (t) r
root): K (t) root can be obtained by one decryption process of (root) Enc (Kj, K (t) root).

An enabling key block (EKB) generated based on a tree having a configuration in which the top node of the simplified reconstructed tree and the terminal nodes or leaves constituting the tree are directly connected. FIG. 27 (b)
As shown in FIG. 6, the reconstructed hierarchical tree is constructed based only on the keys corresponding to the top node and the terminal node or leaf.

Like the activation key block (EKB) described with reference to FIG. 26 or FIG. 27, a simplified new tree configuration constituted only by the distribution destination device is constructed, and the constructed tree is constructed. By generating an activation key block (EKB) using only a leaf or only a key of a leaf and a common node, it becomes possible to generate an activation key block (EKB) with a small data amount, and an activation key block. (EKB) data distribution can be efficiently executed.

The simplified hierarchical tree structure can be used particularly effectively in an EKB management structure in units of category trees set as subtrees described later. The category tree is an aggregate block of a plurality of nodes or leaves selected from the nodes or leaves constituting the tree configuration as the key distribution configuration. The category tree is a set that is set according to the type of device, or a processing unit, a jurisdiction unit, or a provided service unit that has a certain common point, such as a management unit of a device provider maker, a content provider, or a payment institution. Etc. are set as a set of various aspects. In one category tree, devices classified into a certain common category are gathered. For example, an EKB is generated by reconstructing a simplified tree similar to the above using vertex nodes (sub roots) of a plurality of category trees. By doing
It is possible to generate and distribute a simplified enabling key block (EKB) that can be decrypted by a device belonging to the selected category tree. The management configuration for each category tree will be described in detail later.

Note that such an activation key block (E
KB) can be stored in an information recording medium such as an optical disk or a DVD. For example, an activation key block (EKB) including a data portion configured by the above-described encryption key data and a tag portion as position identification data in the hierarchical tree structure of the encryption key data is further encrypted by an update node key. It is possible to provide a configuration in which an information recording medium storing the message data such as the converted content is provided to each device. The device can sequentially extract and decrypt the encryption key data included in the activation key block (EKB) according to the identification data of the tag portion, acquire a key required for decrypting the content, and use the content. Becomes Of course, the configuration may be such that the activation key block (EKB) is distributed via a network such as the Internet.

[EKB Management Configuration in Category Tree Units]
Next, a configuration in which nodes or leaves forming a tree configuration as a key distribution configuration are managed by a block as a set of a plurality of nodes or leaves will be described.
Note that a block as a set of a plurality of nodes or leaves is hereinafter referred to as a category tree. The category tree is
A set that is set according to the type of device, or a device provider, content provider,
It is set as a set of various modes such as a processing unit, a jurisdiction unit, or a provided service unit having a certain common point such as a management unit of a settlement institution.

The category tree will be described with reference to FIG. FIG. 28A is a diagram illustrating a management configuration of a tree in units of category trees. One category tree is shown as a triangle in the figure. For example, one category tree 2701 includes a plurality of nodes. (B) shows a node configuration in one category tree. One category tree is composed of a multi-stage two-branch tree having one node as a vertex. Hereinafter, the vertex node 2702 of the category tree is called a sub root.

The end of the tree is constituted by leaves, ie, devices, as shown in FIG. The device belongs to one of the category trees including a plurality of devices as leaves and a tree having a vertex node 2702 as a subroot.

As is understood from FIG. 28A, the category tree has a hierarchical structure. This hierarchical structure will be described with reference to FIG.

FIG. 29 (a) is a diagram for explaining the hierarchical structure in a simplified manner. Category trees A01 to Ann are formed several levels below Kroot, and the category trees A1 to An are located below the category trees A1 to An. , And the category tree B0
1 to Bnk, and further below the category trees C1 to C1.
Cnq is set. Each category tree is shown in FIG.
As shown in (b) and (c), it has a tree shape composed of a plurality of nodes and leaves.

For example, the configuration of the category tree Bnk is as follows.
As shown in (b), there are a plurality of nodes up to the terminal node 2812 with the subroot 2811 as the top node. This category tree has an identifier Bnk, and executes a node key management corresponding to a node in the category tree Bnk independently of the category tree Bnk.
Lower level (child) set with terminal node 2812 as the vertex
Perform category tree management. On the other hand, the category tree Bnk is under the management of an upper (parent) category tree Ann having the sub root 2811 as a terminal node.

The configuration of the category tree Cn3 is, as shown in FIG.
Each device has a terminal node 2852, in this case, a plurality of nodes and leaves up to the leaf. This category tree has an identifier Cn3, and the category tree Cn3
The node (leaf) corresponding to the terminal node 2852 by executing the node key and the leaf key management corresponding to the node and the leaf within the category tree Cn3 independently.
Perform management of On the other hand, the category tree Cn3
Is under the management of the upper (parent) category tree Bn2 having the sub root 2851 as a terminal node. Key management in each category tree is, for example, key update processing,
Revocation processing and the like will be described in detail later.

The device which is the leaf of the bottom category tree stores the node key and leaf key of each node located on the path from the leaf key of the category tree to which the device belongs to the subroot node which is the top node of the category tree to which the device belongs. Is done. For example, the device of the terminal node 2852 is a terminal node (leaf) 28
52 to the sub-root node 2851 are stored.

The structure of the category tree will be further described with reference to FIG. The category tree can have a tree structure composed of various stages.
The number of stages, that is, the depth, can be set according to the number of lower (child) category trees corresponding to terminal nodes managed by the category tree or the number of devices as leaves.

When the upper and lower category tree configuration as shown in FIG. 30A is embodied, the configuration shown in FIG. 30B is obtained.
The root tree is a top tree having a root key. Category trees A, B, and C are set as a plurality of lower category trees at a terminal node of the root tree, and a category tree D is set as a lower category tree of the category tree C. Category tree C2901
Holds one or more of its terminal nodes as a reserved node 2950, and when increasing the category tree managed by itself, further adds a category tree C ′ 2902 having a tree structure of a plurality of stages to the reserved node 2950.
Is newly established as a top node, the number of management terminal nodes 2970 can be increased, and the increased lower category tree can be added to the management terminal node.

The reserve node will be further described with reference to FIG. The category trees A, 3011 have lower category trees B, C, D,... To be managed, and have one reserved node 3021. When it is desired to further increase the lower category tree to be managed, the lower node tree A ′, 3012 of self-management is set in the reserve node 3021, and the lower category tree A ′,
Further, lower category trees F and G to be managed can be set in the terminal node 3012. The self-managed lower-level category tree A ′, 3012 also has a lower-level category tree A ″ 3013 by setting at least one of its end nodes as a reserve node 3022.
Can be set to further increase the management category tree. One or more reserved nodes are also reserved at the terminal node of the lower category tree A ″ 3013. By adopting such a reserved node holding configuration, the number of lower-level category trees managed by a certain category tree can be increased without limit. It should be noted that the reserved category tree may have a configuration in which a plurality of reserved category trees are set instead of only one of the end nodes.

In each category tree, an activation key block (EKB) is formed in units of category trees, and key updating and revocation processing are executed in units of category trees. As shown in FIG. 31, an activation key block (EKB) is set for each of the category trees A, A ′, and A ″.
These can be collectively managed by, for example, a certain device maker that manages the category trees A, A ′, and A ″ in common.

[Registration process of new category tree]
The registration process of a new category tree will be described. FIG. 32 shows the registration processing sequence. Description will be made according to the sequence of FIG. The new (child) category tree (N-En) newly added in the tree configuration is higher (parent)
A new registration request is executed for the category tree (P-En). Each category tree holds a public key in accordance with a public key cryptosystem, and a new category tree receives its own public key when a higher-level category tree (P-E
n).

The upper category tree (P-En) that receives the registration request stores the public key of the received new (child) category tree (N-En) in the certificate issuing authority (CA).
ate Authority) and receives the public key of the new (child) category tree (N-En) to which the CA signature is added. These procedures are based on the upper category tree (PE
n) and a new (child) category tree (N-En).

When the authentication of the new registration request category tree is completed by these processes, the upper category tree (P
-En) permits registration of a new (child) category tree (N-En), and registers a new (child) category tree (N-En).
New (child) category tree (N-En)
Send to This node key is one of the terminal nodes of the upper category tree (P-En),
Also, it corresponds to the vertex node of the new (child) category tree (N-En), that is, the subroot key.

When the node key transmission is completed, the new (child) category tree (N-En) constructs a tree structure of the new (child) category tree (N-En), and the received vertex is placed at the top of the constructed tree. The subroot key of the node is set, the key of each node and leaf is set, and an activation key block (EKB) in the category tree is generated. Activation key block (E
KB) is called a sub-EKB.

On the other hand, upper category tree (P-En)
Generates a sub-EKB in the upper-level category tree (P-En) to which a terminal node to be activated is added by adding a new (child) category tree (N-En).

New (child) category tree (N-En)
Generates a sub-EKB composed of a node key and a leaf key in a new (child) category tree (N-En), and transmits this to the upper-level category tree (P-En).

The upper category tree (PE) that has received the sub EKB from the new (child) category tree (N-En)
n) transmits the received sub EKB and the updated sub EKB of the upper category tree (P-En) to a key distribution center (KDC: Key Distribute Center).

The key issuing center (KDC) can generate an EKB in various modes, that is, an EKB that can be decrypted only by a specific category tree or device, based on the sub EKBs of all the category trees. An EKB in which a category tree or a device that can be decrypted is set as described above is provided to, for example, a content provider, and the content provider encrypts a content key based on the EKB and provides the encrypted content key via a network or in a recording medium. This makes it possible to provide content that can be used only on a specific device.

The registration processing of the sub-EKB of the new category tree to the key issuing center (KDC) is not limited to the method of sequentially transferring and executing the sub-EKB via the upper category tree. The configuration may be such that the process of registering with the key issuing center (KDC) directly from the newly registered category tree without going through is performed.

The correspondence between the upper category tree and the lower category tree newly added to the upper category tree will be described with reference to FIG. By providing one of the terminal nodes 3201 of the upper category tree as the top node of the newly added category tree to the lower category tree, the lower category tree is added as a category tree managed by the upper category tree. The category tree under the management of the upper category tree, which will be described in detail later, has a meaning that the upper category tree can execute the revocation (exclusion) processing of the lower category tree.

As shown in FIG. 33, when a new category tree is set in the upper category tree, one node 3201 of the terminal node which is a leaf of the upper category tree
And the vertex node 3202 of the newly added category tree are set as equal nodes. That is, one of the upper nodes
One leaf node, one leaf node, is set as a subroot of the newly added category tree. With this setting, the newly added category tree is activated under the entire tree structure.

FIG. 34 shows an example of an updated EKB generated by the upper category tree when a newly added category tree is set. FIG. 34A shows the configuration shown in FIG. 34A, that is, a terminal node (node000) 3301 and a terminal node (node001) 3302 that already exist, and a new category tree added terminal node (node100) 3303 is added to the newly added category tree. 9 shows an example of a sub-EKB generated by a higher-level category tree when a sub-EKB is added.

The sub-EKB has a configuration as shown in FIG. The upper node key encrypted by the effective end node key, the further upper node key encrypted by the upper node key,. With this configuration, a sub EKB is generated. Each category tree is, as shown in FIG. 34B, a valid terminal node or an upper node key encrypted by a leaf key.
Encrypt the higher node key with the upper node key,
It has an EKB composed of encrypted data that is sequentially deeper and reaches the sub-root, and manages it.

[Revoking Process Under Category Tree Management] Next, a description will be given of a device or category tree revoking (exclusion) process in a configuration in which the key distribution tree configuration is managed in category tree units. In FIGS. 3 and 4 described above, the process of distributing an enabling key block (EKB) in which only a specific device in the entire tree configuration can be decrypted and a revoked device cannot decrypt is performed. Although the revocation processing described with reference to FIGS. 3 and 4 is processing for revoking a device which is a specific leaf from the entire tree, the configuration based on the category tree management of the tree indicates that the revocation processing can be executed for each category tree. Become.

The revoke processing in the tree structure under the management of the category tree will be described with reference to FIG. 35 and subsequent figures. FIG. 35 is a diagram illustrating a device revocation process based on the category tree at the bottom of the category trees forming the tree, that is, the category tree managing individual devices.

FIG. 35 (a) shows a key distribution tree structure by category tree management. A root node is set at the top of the tree, and category trees A01 to Ann are arranged several levels below the category tree, category trees B01 to Bnk are arranged below the category nodes, and category trees C1 to cn are arranged below the category trees. . In the lowermost category tree, the terminal node (leaf) is an individual device, for example, a recording / reproducing device, a reproducing-only device, or the like.

Here, the revoke process is independently executed in each category tree. For example, in the lowermost category trees C1 to Cn, revocation processing of a leaf device is executed. FIG. 35B shows a tree configuration of a category tree Cn, 3430, which is one of the category trees at the bottom. Category tree Cn, 343
0 has a vertex node 3431 and has a plurality of devices at a leaf that is a terminal node.

Assuming that a device to be revoked, for example, device 3432, is present in the leaf, which is the terminal node, the category trees Cn and 3430 are made up of node keys and leaf keys in the independently updated category tree Cn. Key block (sub EK
B) is generated. This validation key block is a key block formed by an encryption key that cannot be decrypted by the revoke device 3432 but can be decrypted only by devices that constitute other leaves. Category tree C
The administrator of n generates this as an updated sub-EKB. Specifically, from the sub root, the revoke device 3
Each node 3431, 34 constituting a path connected to 432
The node keys 34 and 3435 are updated, and a block in which the updated node key is configured as an encryption key that can be decrypted only in a leaf device other than the revoked device 3432 is set as an updated sub-EKB. This processing corresponds to the processing in which the root key is replaced with the sub root key which is the vertex key of the category tree in the revocation processing configuration described in FIGS.

As described above, the category tree Cn, 3430
The activation key block (sub-EKB) updated by the revoke process is transmitted to the upper category tree.
In this case, the upper category tree is the category tree Bn
k, 3420, which is a category tree having the vertex node 3431 of the category tree Cn, 3430 as a terminal node.

Upon receiving the activation key block (sub-EKB) from the lower-level category tree Cn, 3430, the category tree Bnk, 3420 receives the vertex node 34 of the category tree Cnk, 3430 included in the key block.
The terminal node 3431 of the category tree Bnk, 3420 corresponding to the lower-level category tree Cnk, 3430
And updates the sub EKB of its own category tree Bnk, 3420. FIG. 35C shows a tree configuration of the category trees Bnk and 3420. In the category tree Bnk, 3420, the node key to be updated is a node key on a path from the sub-root 3421 in FIG. 35C to the terminal node 3431 forming the category tree including the revoked device. That is, the node keys of the nodes 3421, 3424, and 3425 constituting the path connected to the node 3431 of the category tree that has transmitted the update sub-EKB are to be updated. By updating the node keys of these nodes, a new updated sub-EKB of the category tree Bnk, 3420 is generated.

Further, the category tree Bnk, 3420
The updated activation key block (sub-EKB) is transmitted to the upper category tree. In this case, the upper category tree is the category tree Ann, 3410, and is a category tree having the vertex node 3421 of the category tree Bnk, 3420 as a terminal node.

Upon receiving an activation key block (sub-EKB) from the lower-level category tree Bnk, 3420, the category tree Ann, 3410 receives the top node 3 of the category tree Bnk, 3420 included in the key block.
The terminal node 3421 of the category tree Ann, 3410 corresponding to 421 is set to the lower category tree Bnk, 34.
The sub EKB of the own category tree Ann, 3410 is updated by setting the updated key in the key 20. FIG. 35D shows the category trees Ann and 341.
0 shows a tree configuration. Category tree Ann, 341
0, the node key to be updated is
The node key of each of the nodes 3411, 3414, and 3415 constituting a path connected to the node 3421 of the category tree that has transmitted the updated sub EKB from the sub root 3411 of (d). By updating the node keys of these nodes, a new update sub E of the category tree Ann, 3410 is updated.
Generate KB.

These processes are sequentially executed in the upper category tree, and up to the root category tree described with reference to FIG. By this series of processing, the revocation processing of the device is completed. The sub EKB updated in each category tree is finally transmitted to a key issuing center (KDC) and stored.
The key issuing center (KDC) generates various EKBs based on the updated sub-EKBs of all the category trees. The updated EKB is an encrypted key block that cannot be decrypted by the revoked device.

FIG. 36 shows a sequence diagram of the device revocation processing. The processing procedure will be described with reference to the sequence diagram of FIG. First, the device management category tree (D-En) at the bottom of the tree configuration updates a key necessary to eliminate revoked leaves in the device management category tree (D-En). Generate a new sub-EKB (D) of the tree (D-En). The updated sub-EKB (D) is sent to the upper category tree. The upper (parent) category tree (P1-En) that has received the updated sub-EKB (D) is the updated sub-EK
An updated sub-EKB (P1) is generated by updating the terminal node key corresponding to the updated vertex node of B (D) and updating the node key on the path from the terminal node to the subroot. These processes are sequentially executed in the upper category tree, and all sub EKBs finally updated are executed.
Are stored and managed in a key issuing center (KDC).

FIG. 37 shows an example of an enabling key block (EKB) generated by updating the upper category tree by the device revocation processing.

FIG. 37 is a view for explaining an example of an EKB generated in the upper category tree which has received the updated sub-EKB from the lower category tree including the revoked device in the configuration shown in FIG. The top node of the lower category tree including the revoked device corresponds to the terminal node (node 100) 3601 of the upper category tree.

The upper category tree is obtained from the sub root of the upper category tree to the terminal node (node 100) 36.
The node keys existing in the paths up to 01 are updated to generate a new updated sub-EKB. The update sub-EKB is shown in FIG.
(B). Updated keys are indicated by underlining and [']. The updated node key on the path from the terminal node to the sub-root thus updated is set as an updated sub-EKB in the category tree.

Next, a description will be given of the processing when the revocation target is a category tree, that is, the revocation processing of the category tree.

FIG. 38A shows a key distribution tree structure based on category tree management. A root node is set at the top of the tree, and category trees A01 to Ann are arranged several levels below the category tree, category trees B01 to Bnk are arranged below the category nodes, and category trees C1 to cn are arranged below the category trees. . In the lowermost category tree, the terminal node (leaf) is an individual device, for example, a recording / reproducing device, a reproducing-only device, or the like.

Here, the case where the revocation processing is executed for the category tree Cn, 3730 will be described. The category tree Cn, 3730 at the bottom is shown in FIG.
As shown in (b), the device has a vertex node 3431 and a plurality of devices at a leaf which is a terminal node.

By revoking the category tree Cn, 3730, all devices belonging to the category tree Cn, 3730 can be collectively excluded from the tree structure. The revocation processing of the category trees Cn and 3730 is executed in the category trees Bnk and 3720 which are the upper category trees of the category trees Cn and 3730. The category tree Bnk, 3720 is a category tree having the vertex node 3731 of the category tree Cn, 3730 as a terminal node.

When revoking lower-level category trees Cn and 3730, category tree Bnk and 3720 determine the top node 37 of category tree Cnk and 3730.
The terminal node 3731 of the category tree Bnk, 3720 corresponding to 31 is updated, and the revoked category tree 3730 is used to update the category tree Bnk, 3720.
Update of the node key on the path up to the sub-root to generate an activation key block to generate an update sub-EKB. The node key to be updated is a node key on a path from the sub root 3721 in FIG. 38C to the terminal node 3731 constituting the top node of the revoked category tree. That is, nodes 3721, 3724, 3
Node keys 725 and 3731 are to be updated. The node key of each of these nodes is updated and the category tree Bn is updated.
A new updated sub-EKB of k, 3720 is generated.

Alternatively, the category tree Bnk, 372
0 indicates that when revoking the lower-level category trees Cn, 3730, the category trees Bnk, 37 corresponding to the vertex nodes 3731 of the category trees Cnk, 3730 are set.
20 is not updated, and the revoked category tree 3730 is used to update the category trees Bnk, 37.
The update sub-EKB may be generated by updating the node key except for the terminal node 3731 on the path up to the 20 sub-roots to generate an activation key block.

Further, the category tree Bnk, 3720
The updated activation key block (sub-EKB) is transmitted to the upper category tree. In this case, the upper category tree is the category tree Ann, 3710, and the category tree having the vertex node 3721 of the category tree Bnk, 3720 as a terminal node.

Upon receiving an activation key block (sub-EKB) from the lower-level category tree Bnk, 3720, the category tree Ann, 3710 receives the vertex node 3 of the category tree Bnk, 3720 included in the key block.
The terminal node 3721 of the category tree Ann, 3710 corresponding to 721 is set to the lower category tree Bnk, 37.
The sub EKB of the own category tree Ann, 3710 is updated by setting the updated key in the key 20. FIG. 38D shows the category tree Ann, 371.
0 shows a tree configuration. Category tree Ann, 371
0, the node key to be updated is
The node key of each of the nodes 3711, 3714, and 3715 constituting a path connected to the node 3721 of the category tree that has transmitted the updated sub EKB from the sub root 3711 of (d). By updating the node keys of these nodes, a new update sub E of the category tree Ann, 3710 is updated.
Generate KB.

These processes are sequentially executed in the upper category tree, and are executed up to the root category tree described with reference to FIG. By this series of processing, the revocation processing of the category tree is completed. The sub EKB updated in each category tree is finally transmitted to a key issuing center (KDC) and stored. The key issuing center (KDC) generates various EKBs based on the updated sub-EKBs of all the category trees. The updated EKB is an encrypted key block that cannot be decrypted by a device belonging to the revoked category tree.

FIG. 39 shows a sequence diagram of the revocation processing of the category tree. The processing procedure will be described with reference to the sequence diagram of FIG. First, a category tree management category tree (EE) for revoking a category tree
n) is a category tree management category tree (EE)
The key required to eliminate the revoked target terminal node in n) is updated, and a new sub EKB (E) of the category tree management category tree (E-En) is generated. The updated sub EKB (E) is sent to the upper category tree. Top (parent) who received the update sub-EKB (E)
The category tree (P1-En) is the updated sub-EKB
An updated sub-EKB (P1) is generated by updating the terminal node key corresponding to the updated vertex node of (E) and updating the node key on the path from the terminal node to the subroot. These processes are sequentially executed in the upper category tree, and all sub EKBs finally updated are stored and managed in the key issuing center (KDC). The key issuing center (KDC) generates various EKBs based on the updated sub-EKBs of all the category trees. The updated EKB is an encrypted key block that cannot be decrypted by a device belonging to the revoked category tree.

FIG. 40 is a diagram for explaining the correspondence between the revoked lower-level category tree and the revoked upper-level category tree. Terminal node 3 of the upper category tree
901 is updated by revocation of the category tree,
Terminal node 390 in the tree of the upper category tree
A new sub-EKB is generated by updating the node keys existing on the path from 1 to the sub-root. as a result,
Vertex node 390 of revoked lower category tree
2 node key and terminal node 3 of upper category tree
The node key of 901 does not match. Since the EKB generated by the key issuing center (KDC) after revoking the category tree is generated based on the key of the terminal node 3901 updated in the upper category tree, the lower category tree which does not have the updated key Of the EKB generated by the key distribution center (KDC) cannot be decrypted.

In the above description, the revocation processing of the lowermost category tree for managing devices has been described. However, the processing of revoking the category tree management category tree in the middle of the tree by the upper category tree is similar to the above. Is possible by the process. By revoking the middle-level entity management category tree, all the plurality of category trees and devices belonging to the lower level of the revoked category tree management category tree can be revoked collectively.

As described above, by executing revocation in units of category trees, revocation processing in a simpler process can be performed as compared with revocation processing executed in units of individual devices.

[Category Tree Capability Management]
Next, in the key distribution tree configuration in category tree units, the capabilities (Capab
A description will be given of a processing configuration for managing content (e.g., ility) and distributing content according to capabilities. Here, the capability means what kind of content or program the device uses, such as being able to decode specific compressed audio data, permitting a specific audio reproduction method, or being able to process a specific image processing program. Or the like, that is, the definition information of the data processing capability of the device.

FIG. 41 shows an example of a category tree configuration in which capabilities are defined. A root node is located at the top of the key distribution tree structure, a plurality of category trees are connected to the lower layer, and each node has a tree structure having two branches. Here, for example, the category tree 4001 is defined as a category tree having a capability that allows any of the audio reproduction methods A, B, and C. In particular,
For example, when music data compressed by a certain audio compression program-A, B, or C is distributed, devices belonging to a category tree configured below the category tree 4001 can perform processing for expanding compressed data.

Similarly, the category tree 4002 can process the audio reproduction method B or C, the category tree 4003 can process the audio reproduction method A or B, the category tree 4004 can process the audio reproduction method B, and the category tree 4005 can process the audio reproduction method C. Is defined as a category tree with various capabilities.

On the other hand, the category tree 4021 is defined as a category tree that allows the image reproduction methods p, q, and r. The category tree 4022 is an image reproduction method of the methods p and q, and the category tree 4023 is an image reproduction method of the method p. Defined as a category tree with possible capabilities.

[0219] Such capability information of each category tree is managed in a key issuing center (KDC). For example, when a certain content provider wants to distribute music data compressed by a specific compression program to various devices, the key issuing center (KDC) can enable only a device capable of reproducing the specific compression program to enable the decryption. A key block (EKB) can be generated based on the capability information of each category tree. A content provider that provides content distributes a content key encrypted with an enabling key block (EKB) generated based on capability information, and provides each device with compressed audio data encrypted with the content key. With this configuration, it is possible to reliably provide a specific processing program only to a device capable of processing data.

In FIG. 41, the capability information is defined for all category trees. However, it is not always necessary to define capability information for all category trees as shown in FIG. As shown in 42, the capability is defined only for the lowest category tree to which the device belongs, and the capability of the device belonging to the lowest category tree is managed in the key issuing center (KDC), so that the processing desired by the content provider can be performed. An enabling key block (EKB) that can be decrypted only by a specific device may be generated based on the capability information defined in the lowermost category tree. In FIG. 42, a category tree 4101 in which a device is defined as a terminal node
= 4105 is defined, and the capabilities for these category trees are managed in the key issuing center (KDC). For example, the category tree 4101 includes devices that can perform processing of method B for audio reproduction and method r for image reproduction. The category tree 4102 includes devices capable of processing in the method A for audio reproduction and processing in the method q for image reproduction.

FIG. 43 shows a configuration example of a capability management table managed by the key issuing center (KDC). The capability management table has a data configuration as shown in FIG. That is, a category tree ID as an identifier for identifying each category tree, a capability list indicating the capabilities defined in the category tree, and this capability list are shown in FIG.
As shown in (b), for example, [1] if the audio data reproduction processing method (A) can be processed, [0] if it cannot be processed, and if the audio data reproduction processing method (B) can be processed. For example, [1] if processing is not possible, [0]..., Etc., is set by setting [1] or [0] bit by bit to determine whether or not data processing can be performed in various modes. The method for setting this capability information is not limited to this format.
Another configuration may be used as long as the capability of the management device in the category tree can be identified.

The capability management table further includes a sub EKB or a sub EK of each category tree.
If B is stored in another database, sub-E
The identification information of the KB is stored, and the sub-root node identification data of each category tree is stored.

The key issuing center (KDC) generates, based on the capability management table, an activation key block (EKB) that can be decrypted only by a device capable of reproducing specific content, for example. The generation process of the activation key block based on the capability information will be described with reference to FIG.

First, in step S4301, the key issuing center (KDC) selects a category tree having the specified capability from the capability management table. Specifically, for example, when the content provider wants to distribute reproducible data based on the audio data reproduction processing method A, the item of the audio data reproduction processing (method A) is set to [from the capability list in FIG. Select the category tree set in [1].

Next, in step S4302, a list of selected category tree IDs constituted by the selected category trees is generated. Next, step S43
At 03, a path (key distribution tree configuration path) required for the tree configured by the selected category tree ID is selected. In step S4304, the selected category tree I
It is determined whether or not all the paths included in the list of D have been selected, and a path is generated in step S4303 until the selection is completed. This means a process of sequentially selecting each path when a plurality of category trees are selected.

When the selection of all the paths included in the list of the selected category tree ID is completed, the flow advances to step S4305 to construct a key distribution tree structure including only the selected path and the selected category tree.

Next, in step S4306, the node key of the tree structure generated in step S4305 is updated to generate an updated node key. further,
The sub EKB of the selected category tree forming the tree is extracted from the capability management table, and the sub EKB is extracted.
Then, based on the updated node key generated in step S4306, an activation key block (EKB) that can be decrypted only in the device of the selected category tree is generated. Activation key block (EKB) generated in this way
Can be used only on devices with specific capabilities, ie, a decryptable activation key block (EK
B). By encrypting, for example, a content key with this activation key block (EKB), encrypting the content compressed based on a specific program with the content key, and providing the encrypted content to the device, the key issuing center (KKB)
The content is used only on the specific processable device selected by DC).

Thus, the key issuing center (KDC)
Generates an activation key block (EKB) that can be decrypted only by a device that can reproduce specific content, for example, based on the capability management table. Therefore, when a new category tree is registered, it is necessary to acquire the capability of the newly registered category tree in advance. The capability notification process associated with the new category tree registration will be described with reference to FIG.

FIG. 45 is a diagram showing a capability notification processing sequence when a new category tree participates in the key distribution tree configuration.

The new (child) category tree (N-En) newly added in the tree configuration executes a new registration request for the upper (parent) category tree (P-En). Each category tree holds a public key in accordance with the public key cryptosystem, and the new category tree sends its own public key to a higher-level category tree (P-En) upon a registration request.

The upper category tree (P-En) that has received the registration request stores the public key of the received new (child) category tree (N-En) in the certificate issuing authority (CA).
ate Authority) and receives the public key of the new (child) category tree (N-En) to which the CA signature is added. These procedures are based on the upper category tree (PE
n) and a new (child) category tree (N-En).

When the authentication of the new registration request category tree is completed by these processes, the upper category tree (P
-En) permits registration of a new (child) category tree (N-En), and registers a new (child) category tree (N-En).
New (child) category tree (N-En)
Send to This node key is one of the terminal nodes of the upper category tree (P-En),
Also, it corresponds to the vertex node of the new (child) category tree (N-En), that is, the subroot key.

When the node key transmission is completed, the new (child) category tree (N-En) constructs the tree structure of the new (child) category tree (N-En), and the received vertex is placed at the top of the constructed tree. The sub root key of the node is set, the key of each node and leaf is set, and an activation key block (sub EKB) in the category tree is generated. On the other hand, the upper-level category tree (P-En) is also updated by adding a new (child) category tree (N-En) to the upper-level category tree (P-En) to which the terminal node to be activated is added.
Generate the sub EKB in En).

New (child) category tree (N-En)
Generates a sub-EKB composed of a node key and a leaf key in a new (child) category tree (N-En), transmits this to a higher-level category tree (P-En), and further manages it in its own category tree. Notify the upper category tree of the capability information about the device to perform.

The upper category tree (P-En) that has received the sub-EKB and capability information from the new (child) category tree (N-En) is the same as the received sub-EKB and capability information, and the upper category tree (P-E).
n) and the updated sub-EKB to the key issuing center (KD
C: Key Distribute Center).

The key issuing center (KDC) registers the received sub-EKB of the category tree and the capability information in the capability management table described with reference to FIG. 43, and updates the capability management table. Based on the updated capability management table, the key issuing center (KDC) can generate an EKB in various modes, that is, an EKB that can be decrypted only by a category tree or a device having a specific capability.

[EK using EKB type definition list]
B management configuration] Next, in a configuration in which an EKB that can be decoded in one or more selected category trees is generated and an EKB that can be commonly used for devices belonging to each category tree is provided, which category tree can be processed, That is, a configuration using an EKB type definition list indicating whether decoding is possible will be described.

In this configuration, the key issuing center (K
DC) uses EKB, such as a content provider,
An EKB issuance request is received from the EKB requester desiring the issuance processing. The EKB issuance request includes an EKB type identification number indicating the EKB type defined in the EKB type definition list.
An EKB that can be processed (decoded) in one or more category trees according to the type identification number is generated.

When generating an EKB, the key issuing center (KDC) determines the top as a category tree administrator based on the top node identifier of each category tree set corresponding to the EKB type identification number in the EKB type definition list. Level Category Entity (TL
Requests the generation of a sub-EKB from a CE: Top Level Category Entity, receives the sub-EKB generated by each TLCE, and executes a synthesis process of a plurality of sub-EKBs to generate an EKB that can be processed in a plurality of category trees. .

In this configuration, an EKB issue requester such as a content provider (CP) can select a specific category tree based on the EKB type definition list. Content Provider (CP)
The requester of the EKB issues an EKB that can be processed in a specific category tree by referring to the EKB type definition list.
Request the key issuance center (KDC) to issue B. The key issuing center (KDC) issues a sub-EKB issuance request to the management entity of the selected category tree based on the EKB issuance request, and the management entity of each selected category tree is revoked by the management entity. Key issuing center (KDC) by generating a sub EKB that can be processed only by a valid device
Send to The key issuing center (KDC) combines one or more sub-EKBs, generates an EKB that can be processed only in the selected category tree requested by the EKB issuing requester, and provides the EKB to the EKB issuing requester. EKB issuance requester
Receiving EKB from Key Issuing Center (KDC), EK
The distribution of the encrypted key or the encrypted content that can be decrypted only with the key obtainable by the process B is executed.

First, the configuration entity in the following description will be briefly described. Key Distribution Center (KDC)
r) Issue the activation key block (EKB) and issue the EK
Manages the EKB type definition list for B.

Top Level Category Entity (TLCE): An entity that manages a certain category tree. For example, a format holder for a recording device. The device manages the category tree, generates a sub-EKB that is an EKB that can be processed (decrypted) by a device in the managed category tree, and submits it to the key issuing center (KDC).

EKB requester (EKB requester) For example, electronic content provision (ECD: Electronic C)
ontent distribution) is an entity that provides various contents such as images, sounds, and programs to user devices, such as a content provider (CP) that executes a service, or a format holder for recording media. EKB
Content and media are provided as settings using keys that can be obtained by processing. A request for issuing an EKB used at this time is made to the key issuing center (KDC).

For example, a content provider (CP)
Encrypts and distributes its own content using an EKB Root Key generated by a key issuing center (KDC). The format holder of the recording medium writes and distributes the EKB when the recording medium is manufactured, so that the recorded content is encrypted using the root key (Root Key) of the EKB.

(TLCE and Category-Based Tree Management) Although the category-based tree management has been described above, the top-level category entity (TLC
The relationship between E) and the category tree will be described with reference to FIG.

First, the category is a set of devices having the same properties as described above, and specifically, devices manufactured by the same manufacturer or devices that can handle the same encoding format. In FIG. 46, A,
B, C, and D each indicate a category tree.

In FIG. 46, the root tree at the uppermost level has, for example, an eight-level configuration (the number of nodes), and the top node of the category tree is set at the lowermost level of the root tree. A plurality of category trees can be in a higher-order or lower-order relationship.
Corresponds to the upper rank of the category tree D.

A category tree directly connected to the root tree at the top is called a top-level category tree, and an entity that manages the top-level category tree is called a top-level category entity (TLCE).
In FIG. 46, A, B, and C are top-level categories, and the entity that manages them is the top-level category entity (TLCE). The top-level category entity (TLCE) is basically responsible for managing everything under its tree. That is, the TLCE managing the tree C in FIG.
Similarly, the management of the tree D is executed. If a lower category tree exists below D, the lower category tree is also managed. However, for example, a category entity (Sub Categor
y Entity) and delegate its responsibilities and rights.

Each device such as a recording / reproducing device that uses contents is assigned to a leaf of a certain tree by a top-level category entity (TLCE), and some nodes between paths from the leaf to the root are assigned. Own the key. A set of node keys of one device is referred to as a device node key (DNK: Device).
Node Key). The top-level category entity (TLCE) determines how many keys each device has (how many keys are included in the DNK).

FIG. 47 shows a key issuing center (KDC), a top-level category entity (TLCE), and E
FIG. 3 is a diagram for explaining correspondence between KB and requester entities and an outline of processing.

The key issuing center (KDC) 4511
It is positioned as a management entity 4510 of the EKB distribution system using the tree structure. The management entity 4510 further includes a certificate authority (CA) 4512 that executes a signature process on the EKB.

The key issuing center (KDC) 4511
Performs key management for subtrees such as the top level category tree, manages EKB type definition lists described later,
Execute generation of EKB. Certificate Authority (CA) 4512
The EKB generated by the key issuing center (KDC) is signed, and a public key corresponding to the signed private key is issued as a key for signature verification.

The EKB requester 4 requests the key issuing center (KDC) 4511 to issue an EKB.
520. The EKB requester is, for example, a content provider (C) related to a content storage medium for providing a medium such as a CD or DVD storing the content.
P), a content provider (CP) that executes distribution of electronic content, and a storage system licensor that provides a license for a format of a storage system such as a flash memory.

The EKB requester 4520 associates an EKB in which a required key is set as a key obtained by the EKB processing with a content, a media, a license format, and the like when using the provided media, content, and license. provide. The EKB is generated by the key issuing center (KDC) 4511 in accordance with an EKB issuing request from the EKB requester 4520 to the key issuing center (KDC) 4511.

The EKB requester 4520 provides the EKB received as a result of the issuance request to the key issuing center (KDC) 4511 to the media manufacturer 4540 and the device manufacturer 4550, and provides the media or device storing the EKB to the user. Can be supplied. These EKBs are generated, for example, as EKBs that can be processed in one or more category trees.

In this system, E that can be processed in common in a plurality of, for example, two or three or more category trees
Various types of EKB, such as a KB and an EKB that can be processed only in a single category tree, are generated and used. An EKB type definition list lists such various types of EKBs.
The EKB type definition list is at the Key Distribution Center (KDC)
Manages. The EKB type definition list will be described later in detail. EKB Requester 4520 uses EK
The request for the B type definition list is sent to the key issuing center (KD
C) The list can be obtained by requesting to the 4511, and when there is a change in the data of the list, the key issuing center (KDC) 4511 sends the EKB requester 4520
Will be notified.

The top-level category entity (TLCE) 4530 is a category tree management entity linked to the root tree as described above, and is used for key management of subtrees, management device IDs, and EKB processing stored in each device. Manages a correspondence list with a device node key (DNK), which is a node key set of. Further, a device node key (DNK) for device storage is generated and provided to a device manufacturer 4550 that manufactures a device corresponding to the device under management.

The key issuing center (KDC) 4511 has E
Upon receiving an EKB issuance request from the KB requester 4520, the key issuing center (KDC) 4511 generates an EKB according to the issuance request. If the EKB to be generated is 2
If the EKB can be processed in one top-level category tree, a sub-EKB issuance request is transmitted to the two top-level category entities (TLCE) 4530, and the sub-EKB issuance request is received. Top Level Category Entity (TLC
E) 4530 generates a sub-EKB from which a legitimate device in each category tree can acquire a root key, and transmits the sub-EKB to the key issuing center (KDC) 4511. Key Issuing Center (KDC) 4511 received from TLCE
An EKB is generated based on one or more sub-EKBs. The EKB generation processing based on the sub-EKB will be further described later.

The top-level category entity (TLCE) 4530 can request the EKB type definition list from the key issuing center (KDC) 4511 and acquire the list, like the EKB requester 4520.

The top-level category entity (TLCE) 4530 can further request the key issue center (KDC) 4511 to delete a type defined for its own tree in the EKB type definition list. For example, EKB shared with other category trees
This is a request to delete from the list the EKB type defined as. Top-level category entity (T
The LCE) 4530 further notifies the key issuing center (KDC) 4511 of the change information when there is a change in the tree managed by itself. These processes will be described later using a flow.

The device manufacturer 4550 is divided into two types of device manufacturers. One is a DNKE device manufacturer 4551 that manufactures a device that stores both a device node key (DNK) and EKB data in a device to be manufactured, and the other is a device that stores only a device node key (DNK) in a device. DN for manufacturing devices
K device manufacturer 4552.

FIG. 48 is a block diagram showing a configuration example of each of the key issuing center (KDC), EKB requester, and top-level category entity (TLCE) shown in FIG. Key Issue Center (KDC) is EK
The B-issued information processing device, the EKB requester are configured as an EKB request information processing device, and the top-level category entity (TLCE) is configured as a category tree management information processing device, and is basically configured as a data processing device capable of performing cryptographic communication.

The information processing devices constituting each entity each have a cryptographic processing unit that controls mutual authentication with other entities and general cryptographic processing during data communication. The control unit in the encryption processing unit is a control unit that executes control related to overall encryption processing such as authentication processing and encryption / decryption processing. The internal memory stores key data, identification data, and the like required in various processes such as a mutual authentication process, an encryption process, and a decryption process. The identification data is used, for example, in a mutual authentication process with another entity.

The encryption / decryption unit executes processing such as authentication processing, encryption processing, decryption processing, data verification, and generation of random numbers at the time of data transfer using key data or the like stored in the internal memory. .

However, in the information processing apparatus as an EKB requester, a configuration in which the key generation processing is not executed in the own apparatus is also possible. In this case, components necessary for generating a key, for example, a random number generator can be omitted. Specifically, an information processing apparatus as an EKB requester that requests a key issuing center to generate an EKB including a root key generated by generating a root key to be included in the EKB by itself requires means for generating a root key. However, it does not generate the root key to be included in the EKB by itself, requests the key issuing center to generate the root key, and requests the key issuing center (KDC) to generate the EKB including the root key generated by the key issuing center. In the information processing apparatus as an EKB requester, the components involved in key generation processing such as a random number generator can be omitted.

Since the internal memory of the cryptographic processing unit holds important information such as a cryptographic key, it must be structured so as to be hard to read illegally from the outside. Therefore, the encryption processing unit is configured as a tamper-resistant memory having a structure that is difficult to access from the outside, for example, a semiconductor chip.

Each entity has a central processing unit (CPU) in addition to these cryptographic processing functions.
ng Unit), RAM (Random Access Memory), ROM
(ReadOnly Memory), input unit, display unit, database I
/ F, a database.

Central processing unit (CPU: Central Proc)
essing Unit), RAM (Random Access Memory), R
The OM (Read Only Memory) is a component that functions as a control system of each entity body. The RAM is used as a main memory for various processes in the CPU.
Used as a working area for processing by ROM
Stores a startup program for the CPU and the like.

In the database or other storage means of the information processing device constituting each entity, data managed by each entity, for example, in the case of a key issuing center (KDC), management data relating to the issued EKB, Definition list etc. are stored,
In addition, top level category entities (TLC
The database of E) stores management data of devices belonging to the category tree, such as correspondence between managed devices and device node keys (DNK), and the database of the EKB requester is used for provided contents and contents. Management data in which a relationship with the EKB is associated, management data on a device to which the content is provided, and the like are stored. The EKB type definition list is
It is preferable that the EKB requester and the top-level category entity (TLCE) are stored in an information processing device and can be referred to. Or EK
B Requester, Top Level Category Entity (TLCE) Accessible Key Issuing Center (KD)
It may be configured to be placed on a Web site managed by C).

As described above, the device transmits a device node key (DNK: Denk) for EKB processing (decryption).
vice Node Key). A device node key (DNK) of one device will be described with reference to FIG. The tree shown in FIG. 49 shows one category tree, and the bottom row is a leaf associated with a device, and corresponds to, for example, a management tree of a top-level category entity (TLCE). Further, a root tree (ex. Eight-stage configuration) is connected to the upper stage. Here, the device has a node key on a path from the device to the upper stage as shown in FIG. These key sets are held as device node keys (DNKs), and the EKB is decrypted using the device node keys (DNKs).

Basically, one device is assigned so as not to overlap one leaf. As an exception, when associating software such as PC software with a leaf, one version of the software package may be all assigned to one leaf.
This is also decided by TLCE. That is, the TLCE determines how a device is assigned to a leaf and which node key is assigned.

The top-level category entity (TLCE) is a provider (maker) of the device itself.
The device node key (DNK) can be stored in advance for the manufacturing device and provided (sold) to the user. That is, for a device such as a recording / reproducing apparatus, a set of node keys of a specific category tree is previously stored in a device node key (DN).
K) can be stored in a memory and provided (sold) to a user.

(EKB Type Definition List) The EKB distribution in the category unit is as described above, but the EKB common to a plurality of categories, that is, the EKB that can be processed by devices belonging to different category trees.
When B is generated and issued, some problems may occur.

For example, as a rewritable medium (recording medium), for example, as a licensee (license receiver) of a portable flash memory format, A
There are two different companies, Company B and Company B. A maker that is a licensor (licenser) of media (portable flash memory) exists as a top-level category, and a category tree managed by Company A and B below it. In a configuration with a category tree managed by Company A, Company A and Company B provide compatibility between their devices and enable common use of various distributed contents. A key issuing center (KDC) generates and issues an EKB that can be processed (decrypted) by devices belonging to two category trees of the company category tree.

In such a situation, if the device node key (DNK) of one device belonging to the category tree managed by Company A is leaked, Company A uses the device node key (DNK), There is a possibility that all of the distribution contents that can be used in the mutual devices of Company B are used illegally. In order to eliminate the use, EKB update processing as revocation processing is necessary. In this case, instead of revocation processing on the category tree of company A, an EKB common to two category trees of company A and company B is used. EKB because it exists
The update process needs to be executed for two category trees of company A and company B.

As described above, when an EKB common to a plurality of category trees is generated and provided, not only revocation processing and EKB update processing within one category tree, but also
It is necessary to execute the renewal-related EKB update process in all other category trees that use the common EKB. This is affected by another management category tree different from the device managed by the company B, and the processing load is increased.

In order to solve such a situation, the category entity which manages each category has authority to issue an EKB which can be used in common in a plurality of categories. In other words, in order to achieve compatibility, only when the risk to the device in the own category caused by the failure of the device belonging to the partner category can be tolerated, the issuance of the compatible EKB is permitted. Is a commonly available E
Issuance or use of KB is not permitted.

To perform such processing, various types of EKB such as an EKB that can be processed in a plurality of, for example, two or three or more category trees, an EKB that can be processed only in a single category tree, and the like.
B is generated and used. An EKB type definition list lists such various types of EKBs. FIG. 50 shows an example of the EKB type definition list. The EKB type definition list is recorded on a recording medium and managed by a key issuing center (KDC). Also, E
The KB requester and the TLCE can be provided or browsed as needed.

As shown in FIG. 50, the EKB type definition list includes “EKB type identification number”, “node”,
It has each field of "description", and "EKB type identification number" is a number for identifying the various types of EKBs listed in the EKB type definition list. If the identification numbers are different, the EKB can be processed. Different category trees or combinations thereof.

[0280] The "node" field is a field for recording the top node ID of the category tree to which EKB can be applied. For example, in the EKB with the EKB type identification number: 1, the top node ID of the category tree of the MS (Memory Stick) is recorded. The EKB of the EKB type identification number: 3 is MS
The top node ID of the category tree (MemoryStick: Memory Stick) and the top node ID of the PHS category tree are recorded.

[0281] The "description" field is a field for recording the description of the EKB of various modes listed in the EKB type definition list. For example, the EKB of the EKB type identification number: 1 is MS (Memory Stick). This is an EKB for use. The EKB of the EKB type identification number: 3 is MS
(MemoryStick: Memory Stick) and an EKB that can be commonly used for devices in the PHS category tree.

The EKB type definition list shown in FIG. 50 is managed by the key issuing center (KDC). An entity that intends to distribute encrypted data such as an encrypted key or an encrypted content encrypted with a key obtainable by the EKB process, for example, a content provider, refers to the EKB type definition list shown in FIG. hand,
Select an EKB type that can be processed by the category tree including the device to which the content is provided, and
A KB type identification number is designated, and an EKB generation process is requested to a key issuing center (KDC).

However, in various types of EKB registration processing for the EKB type definition list, it is necessary to approve the top-level category entity (TLCE) of the category tree to be registered. For example, TLCE-A of category tree A shares E with other categories.
If the issuance of the KB is rejected, the type of the EKB that is shared by the category tree A and the other category trees is not registered in the EKB type definition list.

For example, TLCE-A of category tree A,
If the TLCE-B of the category tree B and the TLCE-C of the category tree C approve the issuance of a shared EKB, the common EKB types that can be processed in these three category trees are registered in the EKB type definition list. For example, a content provider can request an EKB generation process to a key issuing center (KDC) by designating an EKB type identification number indicating the registration type.

That is, a new EKB type is registered in the EKB type definition list, and an EKB type corresponding to the EKB type is registered.
In order to define the KB type identification number, the following processing is required. (1) All TLCEs managing the category to which the EKB corresponding to the EKB type identification number to be defined is applied send an EKB type registration request to the key issuing center (KDC). (2) The key issuance center (KDC) has sent the above EKB type registration request from all of the top level category entities (TLCE) of one or more category trees that can process the EKB to be registered in the request. After confirming this, a new EKB type identification number is defined and added to the EKB type definition list. (3) The key issuing center (KDC) sends an EKB type definition list change notification to all TLCEs and EKB requesters in order to notify that the EKB type definition list has been changed.

Note that the EKB type definition list contains all TL
Sent to CE and EKB requesters and to the web (We
b) All TLCE and EKB, for example by being placed on the site
Published to requesters. Therefore, TLCE and EK
The B requester can always acquire the EKB type information registered in the latest EKB type definition list.

(EKB Type Registration Processing) FIG. 51 shows a processing flow for explaining processing executed by the key issuing center (KDC) when registering a new EKB type in the EKB type definition list. First, the key issuing center (KD
C) is a TLC that makes a new EKB type registration request
Receives the EKB type registration request from E (S10
1) Yes. The EKB type registration request from the TLCE includes the number of categories that the registration request EKB can commonly use. The Key Issuing Center (KDC) has a TLC corresponding to the number of categories that matches the number of categories in the request.
It is determined whether the same EKB type registration request has been received from E (S102), and the EKB type definition is provided on condition that a request from TLCE corresponding to the number of categories corresponding to the number of categories in the request has been received. A new EKB type according to the request is registered in the list, and list update processing and list update notification processing (S103) are performed. The update notification processing is performed on the TLCE and the EKB requester.

Thus, the key issuing center (KDC)
Is registered on condition that all category entities managing one or more category trees selected as processable category trees of the EKB type to be registered are newly registered in the EKB type identifier for the EKB type definition list. Perform

In these processes, in the communication between the key issuing center (KDC) and the TLCE and EKB requesters, mutual authentication and encryption of transmission data are performed as necessary. Further, a configuration may be adopted in which other message encryption processing, digital signature generation, and verification processing are performed. When performing authentication or encryption communication based on the public key cryptosystem, a procedure for holding a public key between the entities is performed in advance.

(EKB Type Invalidation Processing) For example, when all devices belonging to a certain category have to be revoked, the top-level category entity (TLCE) has E as a component of the category.
The request to invalidate the KB type is sent to the key distribution center (KD
C). Also, the top-level category entity (TLCE) can issue a request to the KDC to invalidate the currently registered EKB type, for example, to suspend a service.

The flow of the EKB type invalidation processing is shown in FIG.
Description will be made according to the processing flow of No. 2. The key issuance center (KDC) issues an EKB type revocation request to the TL
An EKB type invalidation request is received from the CE (S2
01). Upon receiving the EKB type revocation request from the TLCE, the key issuing center (KDC) confirms that the TLCE managing the category that is the element of the EKB type revoked by the request is the originator of the request. After confirming, the EKB type identification number corresponding to the type specified in the invalidation request in the EKB type definition list is invalidated and E
The KB type definition list is updated, and a list update notification process (S202) is performed. The update notification processing is performed on the TLCE and the EKB requester.

Thus, the key issuing center (KDC)
In the invalidation processing of the EKB type identifier registered in the EKB type definition list, at least one category entity that manages at least one category tree selected as a processable category tree of the EKB type to be invalidated The invalidation processing is performed on the condition of the invalidation request. In this case, approval of other category entities is not required.

In these processes, in the communication between the key issuing center (KDC) and the TLCE and EKB requesters, mutual authentication and encryption of transmission data are performed as necessary. Further, a configuration may be adopted in which other message encryption processing, digital signature generation, and verification processing are performed. When performing authentication or encryption communication based on the public key cryptosystem, a procedure for holding a public key between the entities is performed in advance.

(EKB type definition list change notification processing)
For example, in a certain category tree, a process for changing a state in the tree such as a device revocation (device exclusion) or an update of a device node key (DNK) for exchanging a DNK stored in a certain device for a new one is performed in the category tree. When the TLCE that manages these devices performs, it is necessary to notify the EKB requester or the related TLCE using the EKB targeting those devices that these processes have occurred.

[0295] Because a device revocation has occurred, it is not notified and the content provider (C
If P) continues to use the old EKB and encrypts and distributes the content, the old EKB can perform EKB processing (decryption) even on a revoked device,
This is because there is a possibility that illegal use of the content may be continued. When the device node key (DNK) is updated, the replaced old DNK is normally discarded and the device has a new DNK. However, the content provider uses an EKB corresponding to the new DNK. Otherwise, the device with the new DNK is EK
This is because B cannot be processed (decrypted) and the content cannot be accessed.

In order to avoid such adverse effects, * when a change occurs in the EKB tag part as a result of device revocation, etc. * at least one device has as a result of updating a device node key (DNK), etc. When a change occurs in the value of DNK, in these cases, the TLCE issues a tree change notification (Tree
Change Notification) Key Issue Center (KDC)
Need to be sent to Tree Change Noti
fication) includes the EKB type identification number registered in the EKB type definition list that needs to be changed, information indicating which category has been registered corresponding to the EKB type identification number, and information on revocation and DNK update. Contains information about what happened.

The flow of the EKB type definition list change notification processing will be described with reference to the processing flow of FIG. The key issuing center (KDC) receives a tree change notification from TLCE (S301). Upon receiving the tree change notification from the TLCE, the key issuing center (KDC) uses the EKB type definition list to list the EKB having the category as an element.
The type identification number is extracted, and what kind of change (ex. Revocation,
An EKB type definition list change notification having information on whether DNK update (replacement) has occurred
Perform for LCE and EKB requesters. In addition,
In these processes, in the communication between the key issuing center (KDC) and the TLCE and EKB requesters, mutual authentication and encryption of transmission data are performed as necessary. Further, a configuration may be adopted in which other message encryption processing, digital signature generation, and verification processing are performed. When performing authentication or encryption communication based on the public key cryptosystem, a procedure for holding a public key between the entities is performed in advance.

(EKB type definition list request) Top-level category entity (TLCE) or TLCE
An EKB requester such as a subcategory entity (SCE) other than the above or a content provider can request the key issuing center (KDC) to send an EKB type definition list in order to know the latest version of the EKB type definition list. In response to this request, the key issuing center (KDC) returns the latest version of the EKB type definition list to the requester.

The flow of the EKB type definition list request processing will be described with reference to the processing flow of FIG. The key issuing center (KDC) receives an EKB type definition list request from any of TLCE, subcategory entity, or EKB requester (S401). Upon receiving the EKB type definition list request, the key issuing center (K
DC) extracts the latest EKB type definition list, and transmits the latest EKB type definition list to the entity that has performed the request processing (S402). In these processes, the key issuing center (KDC) and TLC
In communication between E, the subcategory / entity, and the EKB requester, mutual authentication processing and transmission data encryption processing are performed as necessary. Further, a configuration may be adopted in which other message encryption processing, digital signature generation, and verification processing are performed. When performing authentication or encryption communication based on the public key cryptosystem, a procedure for holding a public key between the entities is performed in advance.

(EKB Issuing Process) The EKB issuing process is as follows.
This is performed based on an EKB request issued by the EKB requester. The EKB requester is [a] a content provider (CP) that provides content storage media such as CDs and DVDs. [B] Electronic content distribution (ECD: Electronic Content Dis
tribution) A content provider that provides services. [C] Format holder for the recording system. For example, an entity that provides services, media, and devices that enable use of content and use of a format using a key obtained by decrypting an EKB.

[C1] The format holder for the recording system [c1] is, for example, a format holder that gives the EKB obtained to the recording medium manufacturer in a format in which the EKB is stored in the recording medium at the time of manufacture. [C2] A format holder for giving the acquired EKB to the recording device manufacturer in a format in which the EKB is stored in the recording device at the time of manufacture, for example. There are two types of format holders.

The procedure of the EKB issuing process will be described below.

(1) Creation of Content Key First, an EKB requester such as a content provider generates a content key to be used in accordance with the content, device, and media provided by itself. For example, the EKB requester: [a] A content provider (CP) that provides content storage media such as CDs and DVDs. [B] Electronic content distribution (ECD: Electronic Content Dis
tribution) A content provider that provides services. In the case of, the generated content key is used as a key for protecting (encrypting) the content on media or in an electronic information distribution (ECD) service.

[0304] Also, a format holder that gives the acquired EKB to the manufacturer of the recording medium in a format in which the EKB requester stores the EKB in the recording medium at the time of [c1] production. In this case, the content key is used as a key for protecting (encrypting) the content recorded on the recording medium. Further, [c2] a format holder for providing the recording device manufacturer with the acquired EKB in a format in which the EKB requester stores the EKB in the recording device at the time of manufacturing.
, The content key is used as a key for protecting (encrypting) the content recorded using the recording device.

A mechanism such as an encryption algorithm for protecting contents using a contents key can be arbitrarily determined for each format.

(2) Generating a Root Key The EKB requester generates a root key which can be obtained by decrypting the EKB. Note that the EKB requester does not generate the root key itself, and the key issuing center (K
DC). The root key is used to protect (encrypt) the content key. A mechanism such as an encryption algorithm for protecting the content key using the root key can be arbitrarily determined for each format.

(3) EKB Issuance Request The EKB requester sends an EKB issuance request to the key issuance center (KDC). This request includes the root key and one of the EKB type identification numbers registered in the EKB type definition list, to which category of device the root key is to be transmitted by the EKB. The EKB requester selects an EKB type definition list stored in its own storage means or a category including a device to which a service such as content provision is to be provided based on an EKB type definition list obtained from a browsable site on the network. The EKB type is selected, and an EKB type identification number indicating the selected EKB type is included in the EKB issuance request and transmitted to the key issuing center (KDC).

(4) EKB Issuing Process Based on the EKB issuing request from the EKB requester, the key issuing center (KDC) generates an EKB including the root key when the EKB issuing request includes the root key. , If the root key is not included in the EKB issuance request and a root key generation process request is made, the KDC
Generates a root key, generates an EKB including the generated root key, and transmits the generated EKB to the EKB requester.

An EKB generated by the key issuing center may be an EKB that can be processed in a single category tree, or may be an EKB that can be processed in common in a plurality of category trees. Key Issuing Center (KDC)
Is based on the EKB type identification number included in the EKB issuance request, the category which is a component of the EKB type identification number, that is, recorded in the node field of the designated EKB type identification number in the EKB type definition list. Extract nodes. The top node ID of the category tree is recorded in the node field. This is the node ID corresponding to the management entity of the category tree. This node ID
The sub-EKB issuance request is issued to the top-level category entity (TLCE), which is the management entity of the category tree, based on the. The sub-EKB issuance request includes a root key and information indicating each category.

[0310] Sub-EK from Key Issuing Center (KDC)
The TLCE that has received the B issue request receives a sub-EK having a configuration in which a root key can be finally obtained from each device (not revoked) in one or more designated categories.
B is generated and transmitted to the key issuing center (KDC).

The sub-EKB generated by the top-level category entity (TLCE) has the same structure as a normal EKB (see FIG. 6) except that it does not have a version number or information for verifying the version (Version Check Value). Is a set of information with Here, the algorithm, key length, and mode for encrypting an upper node key or root key using a leaf key or a node key in the sub EKB are set to the sub EKB.
It can be arbitrarily determined for each TLCE (format holder) that generates a KB. Thus, a unique security scheme can be used separately from other formats. In addition, for example, the encryption algorithm is set to FIPS46-2 Triple DES (Triple-DE
S) may be determined in advance, and TLCE which does not have a difference may be configured to apply the triple DES algorithm. T
Even if the LCE determines the encryption algorithm and key length arbitrarily, the EK combined with the sub-EKB created by another TLCE
It is decided that each (encrypted) key is represented by data of a predetermined length, for example, 16 bytes (16 bytes) so that B can be processed by other devices under the control of TLCE. In this way, the EKB common to a plurality of category trees
By generating data in accordance with a predetermined rule when generating a device, each device in a different category tree can
By following the KB tag, it is possible to determine what key data one needs. That is, if each of the key data included in the EKB is 16 bytes, it becomes possible to sequentially extract and process the key data that can be processed by the own device, and finally obtain the root key. .

That is, the composite EKB generated based on the sub-EKB has a configuration in which each of a plurality of key data is stored in a fixed-length data field. Therefore, a combined EKB generated based on a sub-validation key block (sub-EKB) having a unique algorithm and a unique key / data length is used to store a plurality of encrypted key data in the sub-EKB in a node in the key tree. Alternatively, even if the key data is generated by rearranging according to the leaf position, necessary key data can be sequentially acquired by following the tag of the EKB. Such a composite EKB is distributed or provided to a user (device) via a network or stored in various recording media.

[0313] The key issuing center (KDC)
Sub EKB sent from is re-arranged as necessary,
The combined EKB is synthesized by adding the version number and the information for verifying the synthesized EKB, and transmitted to the EKB requester. However, digital signatures using public key cryptography are only available to certificate authorities (C
A: In some cases, a request is made to a Certificate Authority.

Generation of sub-EKB, synthesis E from sub-EKB
Generation of KB will be described with reference to the drawings. FIG.
Are category trees A, 5100 and category trees B,
In the process of generating a combined EKB common to 5200,
It is a figure explaining composition of sub-EKB- (A) which TLCE of category tree A and 5100 generates. Sub EKB
-(A) is generated as an EKB from which each device of the category tree A 5100 can acquire a root key. In the figure, the root tree area 5300 has been described as having an eight-level configuration in the above description, but has a two-level configuration here to simplify the description.

In FIG. 55, an underlined 3-digit numerical value [XXX] described in the tree structure is represented by E
A tag (e, l, r) in the KB is shown. As described above (see FIGS. 26 and 27), e = 1 indicates that there is data, e = 0 indicates that there is no data, and l = 1 indicates a left branch. None, l = 0 indicates a branch on the left, r = 1 indicates no branch on the right, and r = 0 indicates a branch on the right.

In order for each device (leaf) of the category tree A 5100 in FIG. 55 to acquire the root key,
An EKB storing data obtained by encrypting a root key with a node key that is commonly stored in each leaf may be generated. Each device is a category tree A, 5 shown in FIG.
Since the node key of each path of the tree of the device node key (DNK) area 5120 of 100 is held, the DN
An EKB in which the root key is encrypted with the node key at the top of the K area 5120 may be generated.

Therefore, T of category tree A, 5100
The sub-EKB- (A) generated by LCE has a tag part:
101,010,000,111,111, key parts: Enc (K010, Kroot), Enc (K01
1, Kroot). The TLCE of category tree A, 5100 uses this sub-EK
B- (A) is transmitted to the key issuing center (KDC).

Next, the sub EKB- (B) generated by the category tree B 5200 will be described with reference to FIG. In order for each device (leaf) of the category tree B, 5200 to acquire the root key, an EKB storing data obtained by encrypting the root key with a node key that is commonly stored by each leaf may be generated. Since each device has a node key of each path of the tree of the device node key (DNK) area 5220 of the category tree B5200 in FIG. 56, the EKB obtained by encrypting the root key with the node key at the uppermost stage of the DNK area 5220 is stored. You just need to generate it.

Therefore, T of category tree B, 5200
The sub-EKB- (B) generated by LCE has a tag part:
110,010,000,111,111, key parts: Enc (K110, Kroot), Enc (K11
1, Kroot). The TLCE of category tree B, 5200 uses this sub-EK
B- (B) is transmitted to the key issuing center (KDC).

[0320] The key issuing center generates a combined EKB from the sub-EKB- (A) and the sub-EKB- (B) generated by each TLCE. The generation of the composite EKB will be described with reference to FIG. The composite EKB is a category tree A, 5
EKB that enables devices belonging to the trees 100 and 100 and the category trees B and 5200 to acquire the root key
Is configured as Basically, a plurality of received sub Es
A composite EKB is generated by mixing the key data arrays of the KBs and aligning them from the top of the tree. In the same stage, data arrangement is performed with the left side first.

As a result, the synthetic EKB had the tag part: 1
00,010,010,000,000,111,11
1, 111, 111, key part: Enc (K010,
Kroot), Enc (K011, Kroot), En
c (K110, Kroot), Enc (K111, Kr
oot). By setting the key data of each key part as, for example, 16 bytes as described above, the device in each category tree can detect the key data position that can be processed by the own device. It becomes possible to acquire.

The above is the processing configuration for generating and synthesizing a sub-EKB when there is no revoked device in any of the category trees. Next, generation and synthesis of a sub-EKB when there is a revoked device. EK
The generation of B will be described.

FIG. 58 is a view for explaining the generation of a sub-EKB when a revoke device (01101) 5150 exists in the category tree A 5100. The sub-EKB in this case is the revoked device (01101)
Only 5150 is generated as a sub-EKB- (A ′) that cannot be processed.

In this case, a sub EKB having a key data structure in which paths indicated by thick lines in the figure are connected is generated.
Therefore, the sub-EKB- (A ′) generated by the TLCE of the category tree A, 5100 has the tag part: 101, 0
10,000,111,000,000,001,111,11
1. Key part: Enc (K010, Kroot), E
nc (K0111, Kroot), Enc (K0110
0, Kroot).
The TLCE of the category tree A, 5100 is
KB- (A ') is transmitted to the key issuing center (KDC).

The key issuing center synthesizes the sub-EKB- (A ′) generated by each TLCE and the sub-EKB- (B) (see FIG. 56) received from the TLCE of the category tree B, 5200 without a revoke device. Generate EKB. The generation of the composite EKB will be described with reference to FIG. Synthetic EKB is a device excluding revoke device (01101) 5150 of category tree A, 5100,
And devices belonging to the category tree B, 5200, are configured as an EKB from which a root key can be obtained. Basically, a composite EKB is generated by mixing the received key data arrays of a plurality of sub EKBs and aligning them from the top of the tree. In the same stage, data arrangement is performed with the left side first.

As a result, the synthetic EKB had the tag part: 1
00,010,010,000,000,111,00
0, 111, 111, 001, 111, 111, key parts: Enc (K010, Kroot), Enc (K1
10, Kroot), Enc (K111, Kloo)
t), Enc (K0111, Kroot), Enc (K
01100, Kroot). This combined EKB is an EKB from which a root key can be obtained by devices other than the revoked device (01101) 5150 in the category tree A 5100 and devices belonging to the tree in the category tree B 5200.

(5) Use of EKB The key issuing center (KDC)
Is transmitted to the EKB requester.
For example, the EKB requester: [a] A content provider (CP) that provides content storage media such as CDs and DVDs. [B] Electronic content distribution (ECD: Electronic Content Dis
tribution) A content provider that provides services. In the case of, the content key is encrypted with the root key that can be obtained by the EKB, the content provided to the user device is encrypted with the content key, and the content is distributed. With this configuration, only devices belonging to a specific category tree that can process the EKB can use the content.

A format holder that gives the acquired EKB to the recording medium manufacturer in a format in which the EKB requester stores the EKB in the recording medium at the time of [c1] production. , The generated EKB,
The content key encrypted with the root key is provided to the recording medium manufacturer, and the recording medium storing the EKB and the content key encrypted with the root key is manufactured, or the recording medium is manufactured and distributed by itself. With this configuration, E
Only devices belonging to a specific category tree that can process the KB can perform encryption processing and decryption processing at the time of content recording and reproduction using the EKB of the recording medium.

Further, the EKB requester obtains the EKB obtained by the recording device manufacturer in a format such that [c2] the EKB is stored in the recording device at the time of manufacture.
Format holder giving B. In the case of, the generated EKB and the content key encrypted with the root key are provided to the recording device manufacturer, and the recording device storing the content key encrypted with the EKB and the root key is manufactured, or the recording device is manufactured by itself. And distribute it. With this configuration, only devices belonging to a specific category tree that can process the EKB can perform encryption processing and decryption processing at the time of content recording and reproduction using the EKB.

An EKB is issued by the above processing. In the communication between each entity, the EKB requester, the key issuing center (KDC), and the TLCE in the EKB issuing processing process, mutual authentication processing and transmission data encryption processing are performed as necessary.
Further, a configuration may be adopted in which other message encryption processing, digital signature generation, and verification processing are performed. When performing authentication or encryption communication based on the public key cryptosystem, a procedure for holding a public key between the entities is performed in advance.

(Structural Example in which a Simple Set of Sub-EKBs is Synthesized EKB) In the above-described processing for generating a synthesized EKB from a sub-EKB, an array of encryption key data included in each sub-EKB is arranged from the top of the entire tree. The reordering process was performed to reach the lower stage. Next, without performing such a rearrangement process, the T
A configuration in which the sub EKB generated by the LCE is sequentially stored as it is in the composite EKB to generate the composite EKB will be described.

FIG. 60 shows the TLC of a plurality of category trees.
It is the figure which showed the example of the synthetic | combination EKB6000 which stored two or more the sub EKB which E produced | generated as it was.

In the EKB issuing process, the key issuing center (KDC) issues a request to the TLCE which is the management entity of the category tree recorded in the EKB type definition list corresponding to the EKB type identification number designated by the EKB requester. A sub-EKB generation request is issued, and the sub-EKBs 6110 and 6 submitted by each TLCE are issued.
120 are simply collected and stored in the composite EKB. However, the size (ex. Data length) 6111 of each sub-EKB part is set so that a device belonging to each category can select a sub-EKB corresponding to a category to which the device belongs which the device can process from the combined EKB. Sub EK
Data (ex. Node ID) 6112 indicating which category B is for is added.

That is, each sub-EKB selected as a storage target has a length indicating the data length of the sub-EKB storage area, and a node ID as a node identifier of a corresponding category tree of each sub-EKB as sub-EKB identification data. Are stored in association with each other. Synthetic EK
The number of sub-EKBs included in B is added as header information 6200. A signature (ex. Signature of a certification authority (CA)) 6300 is generated and added based on all data of the combined EKB.

When a combined EKB corresponding to the description with reference to FIG. 57 is generated according to this method, a combined EKB as shown in FIG. 61 is generated. Sub EKB6
The storage EKB 110 is the sub-EKB- (A) itself generated by the TLCE of the category tree A described in FIG. 55, and the tag part: 101,010,000,11
1,111, key part: Enc (K010, Kloo
t), Enc (K011, Kroot). Also,
The storage EKB of the sub EKB 6120 is the sub EKB- generated by the TLCE of the category tree B described in FIG.
(B) itself, and the tag parts: 110, 010,
000, 111, 111, key part: Enc (K11
0, Kroot) and Enc (K111, Kroot).

The synthetic EKB with the revoke device described with reference to FIGS. 58 and 59 is shown in FIG.
The data configuration shown in FIG. The storage EKB of the sub EKB 6110 is the TLC of the category tree A described in FIG.
The sub-EKB- (A ') itself generated by E, and the sub-EKB- (A') is a tag part: 101,010,
000,111,000,000,001,111,111, key part: Enc (K010, Kroot), Enc
(K0111, Kroot), Enc (K01100,
Kroot). The storage EKB of the sub EKB 6120 where no revoke device is generated is the sub EKB generated by the TLCE of the category tree B described in FIG.
KB- (B) itself, tag part: 110,0
10,000,111,111, key part: Enc
(K110, Kroot), Enc (K111, Kro
ot).

By adopting such a configuration, a device belonging to each category can select and process (decode) a sub-EKB corresponding to the category to which the device belongs. Therefore, a sub-EKB can be generated using a completely arbitrary encryption algorithm and key length for each category (TLCE). That is, the TLCE can determine the encryption algorithm and the key length regardless of other categories.

For the key issuing center (KDC),
The sub-EKB tag and key data portion collected from each TLCE do not need to be disassembled and reassembled, reducing the load.

A device that obtains an EKB according to this method finds a sub-EKB of a category to which the device belongs, and obtains a root key by processing the sub-EKB by a unique method determined by a TLCE that manages the device. it can.
Other categories of TLs for processing other sub-EKBs
It is not necessary to know the method defined by the CE, and it is not necessary to devise individual keys in the sub-EKB with a fixed length, so that keys of any size can be used theoretically.

(Revocation Process- (1)) The process executed when a revocation occurs in the process using the EKB that can be used in common in a plurality of categories will be described below. First, a description will be given of a revoke process in a case where encrypted content is received from the outside via a network or a medium, a content key is obtained using a key obtained by EKB, and content is used.

Description will be made with reference to FIG. It is assumed that a category tree A, 7100 and a category tree B, 7200 use an EKB 7000 that is commonly used. The EKB 7000 commonly used in the category trees A and 7100 and the category tree B and 7200 is EKB type definition list.
It is assumed that the type identification number is defined as # 1.

In such a situation, the content provider provides the content encrypted with the content key via the network or the media, and the devices belonging to the category trees A and 7100 and B and 7200 use the EKB7000 to perform the root key encryption. , The content key is obtained by decryption processing using the root key, and the encrypted content is obtained using the content key.

In this situation, it is assumed that a situation where unauthorized processing such as leakage of key data of the devices A1 and 7120 belonging to the category tree A and 7100 is detected and the devices A1 and 7120 are revoked.

In this case, the TLCE of the category tree A 7100 executes a tree change notification (see FIG. 53) to the key issuing center (KDC), and the key issuing center (KDC) responds to the received tree change notification. The TLCE and the EKB requester under management are notified based on this.
The notification at this point only informs that the tree change notification has been received, and the EKB type definition list update process is not executed.

The tree change notification based on the occurrence of a revoked message is sent to the EK as an entity using an EKB that can be processed in the category tree in which the revoked message occurs.
The configuration may be such that the process is executed only for the B requester or only for the category entity that manages another category tree to which the shared EKB is applied with the category tree in which the revoke has occurred. In order to perform this process, the key issuing center (KDC) holds, as a user list of issued EKBs, a list in which the EKB type identification numbers are associated with the EKB requesters using the EKB types.

A content provider as an EKB requester executing content distribution for a device in a category tree that has performed a revocation process generates an updated EKB that can be processed only by a device other than a device to be revoked. An EKB issuance request is made to the key issuing center (KDC). In this case, the content providers as the EKB requesters include the category trees A and 7100 and the category trees B and
7200 specifies an EKB type identification number # 1 defined as a type of EKB commonly used. In addition, the EKB requester generates a new root key and sends it to the KDC, or requests the KDC to generate a new root key.

The key issuing center (KDC) refers to the EKB type definition list based on the designated EKB type identification number # 1, and based on the corresponding category tree node, category trees A and 7100 and category tree B. , 7200 requesting generation of a sub-EKB from which a new root key can be obtained by a valid device.

Each of the TLCEs of the category trees A and 7100 and the category trees B and 7200 generates a sub EKB based on a request. In this case, the category tree A,
7100, the revoked devices A1, 71
A sub-EKB- (A) that can acquire a new root key only in another device excluding 20 is generated. In the category tree B, 7200, if no revoked device exists, a sub-EKB- that can acquire a new root key in all devices belonging to the category
(B) is generated and transmitted to the key issuing center (KDC).

The key issuing center (KDC)
A composite EKB is generated based on the sub-EKB received from the EKB in accordance with the method described above, and the generated EKB is transmitted to an EKB requester (ex. Content provider).

The EKB requester (ex. Content provider) distributes contents by applying a new EKB received from the key issuing center (KDC). Specifically, we provide content encrypted with a content key,
The content key is encrypted and provided using the root key obtained by decrypting the EKB. Category tree A, 710
0 and devices belonging to the category tree B, 7200,
The content can be used by acquiring the root key using the EKB, acquiring the content key by decryption processing using the root key, and acquiring the encrypted content using the content key. However, since the revoked devices A1 and 7120 of the category tree A and 7100 cannot process the updated EKB, the content cannot be used.

In the above description, the key issuing center (KDC) does not execute the updating process of the EKB type definition list at the time of receiving the tree change notification from the TLCE. Receives the tree change notification, the key distribution center (KD
C) may execute the updating process of the EKB type definition list and the EKB updating process based on the tree change information, and send the updated EKB type definition list to each EKB requester and TLCE.

(Revocation Process— (2)) Next, for example, in a configuration in which an EKB is stored in a recording device or a recording medium, the user encrypts and records various contents on the recording medium, and performs encryption processing and decryption. A description will be given of a process associated with a revoke process in a so-called self-recording type in which a key required for the process uses a root key obtained from an EKB stored in a recording device or a recording medium.

Description will be made with reference to FIG. It is assumed that the EKB 8000 commonly used in the category trees A and 8100 and the category tree B and 8200 is used. That is, category tree A, 8100
A common EKB is stored in a recording device or a recording medium commonly used in the category tree B and 8200, and the user performs content recording and reproduction by content encryption and decryption processing using the EKB. I do. Note that EK commonly used in the category trees A and 8100 and the category tree B and 8200 is used.
B8000 is assumed to have the EKB type identification number defined as # 1 in the EKB type definition list.

In this situation, it is assumed that a situation in which unauthorized processing such as leakage of key data of devices A1 and 8120 belonging to category trees A and 8100 is detected and devices A1 and 8120 are revoked.

In this case, the TLCE of the category tree A 8100 executes a tree change notification (see FIG. 53) to the key issuing center (KDC), and the key issuing center (KDC) transmits the tree change notification to the received tree change notification. It notifies each TLCE under management and the related EKB requester based on this. The notification at this point only informs that the tree change notification has been received, and the EKB type definition list update process is not executed.

The TLCE of the category tree that has executed the revocation processing can stop itself as a new EKB requester in the revoking devices A1 and 8120 and use the EKB in the future. Key generation center (KD
An EKB issue request is issued to C). In this case, EK
TLCE as B requester is a category tree A,
EKB defined as a type of EKB commonly used in 8100 and category tree B, 8200
Specify the type identification number # 1. In addition, the EKB requester generates a new root key and sends it to the KDC, or requests the KDC to generate a new root key.

The key issuing center (KDC) refers to the EKB type definition list based on the designated EKB type identification number # 1, and based on the corresponding category tree nodes, category trees A and 8100 and category tree B , 8200 requesting generation of a sub-EKB from which a new root key can be obtained by a valid device.

Each of the TLCEs of the category trees A and 8100 and the category trees B and 8200 generates a sub EKB based on the request. In this case, the category tree A,
8100, the revoked devices A1, 81
A sub-EKB- (A) that can acquire a new root key only in another device excluding 20 is generated. In the category tree B, 8200, if there is no revoked device, a sub EKB- that can acquire a new root key in all devices belonging to the category
(B) is generated and transmitted to the key issuing center (KDC).

The key issuing center (KDC)
A combined EKB is generated based on the sub-EKB received from the above according to the method described above, and the generated EKB is generated by each TLCE.
(Ex. Format holder).

Each TLCE (ex. Format holder) distributes a new EKB received from the key issuing center (KDC) to each device, and updates the EKB. The devices belonging to the category trees A and 8100 and the category trees B and 8200 execute the encryption processing using the root key acquired by using the updated EKB in the recording of the new content recording device. Since the content encrypted and recorded using the new EKB can be decrypted only when the corresponding EKB is applied, the content cannot be used in the revoked device.

The present invention has been described in detail with reference to the specific embodiments. However, it is obvious that those skilled in the art can modify or substitute the embodiment without departing from the spirit of the present invention. That is, the present invention has been disclosed by way of example, and should not be construed as limiting. In order to determine the gist of the present invention, the claims described at the beginning should be considered.

[0362]

As described above, according to the information processing system and method of the present invention, a key tree which is divided based on a category and has a plurality of subtrees managed by a category entity is constructed. In the sub-tree set as a partial tree of the key tree in a configuration in which a path constituting the key tree is selected, and an EKB composed of the encryption processing data of the upper key by the lower key on the selected path is generated and provided to the device. Since a composite EKB of a processable sub-validation key block (sub-EKB) is configured and each of the key data in the composite EKB is stored in a fixed-length data field, the sub-EKB by various algorithms is stored. Even in the case of combining, an EKB that can be decoded in each device can be provided.

[Brief description of the drawings]

FIG. 1 is a diagram illustrating a configuration example of an information processing system according to the present invention.

FIG. 2 is a block diagram illustrating a configuration example of a recording / reproducing device applicable to the information processing system of the present invention.

FIG. 3 shows various keys in the information processing system of the present invention;
FIG. 3 is a tree configuration diagram for describing data encryption processing.

FIG. 4 shows various keys in the information processing system of the present invention;
Activation key block (EK
It is a figure which shows the example of B).

FIG. 5 is a diagram showing an example of distribution and an example of decryption processing using a content key enabling key block (EKB) in the information processing system of the present invention.

FIG. 6 is a diagram showing a format example of an enabling key block (EKB) in the information processing system of the present invention.

FIG. 7 is a diagram illustrating a configuration of a tag of an enabling key block (EKB) in the information processing system of the present invention.

FIG. 8 is a diagram showing an example of a data configuration for distributing an enabling key block (EKB), a content key, and content together in the information processing system of the present invention.

FIG. 9 is a diagram illustrating an example of processing in a device when an activation key block (EKB), a content key, and content are distributed together in the information processing system of the present invention.

FIG. 10 is a diagram illustrating a correspondence between an enabling key block (EKB) and a content stored in a recording medium in the information processing system of the present invention.

FIG. 11 is a diagram comparing a process of sending an activation key block (EKB) and a content key in the information processing system of the present invention with a conventional sending process.

FIG. 12 is a diagram showing an authentication processing sequence by a common key cryptosystem applicable to the information processing system of the present invention.

FIG. 13 is a diagram (part 1) illustrating a data configuration for distributing an activation key block (EKB) and an authentication key together in the information processing system of the present invention, and a processing example in a device.

FIG. 14 is a diagram (part 2) illustrating a data configuration for distributing an activation key block (EKB) and an authentication key together in the information processing system of the present invention, and a processing example in a device.

FIG. 15 is a diagram showing an authentication processing sequence by a public key cryptosystem applicable to the information processing system of the present invention.

FIG. 16 shows an activation key block (E) using an authentication process based on a public key cryptosystem in the information processing system of the present invention.
FIG. 9B is a diagram illustrating a process of distributing KB) and a content key together.

FIG. 17 is a diagram showing a process of distributing an enabling key block (EKB) and encrypted program data together in the information processing system of the present invention.

FIG. 18 is a content integrity check value (ICV) applicable in the information processing system of the present invention.
FIG. 7 is a diagram illustrating an example of generating a MAC value used for generating a MAC value.

FIG. 19 is a diagram (part 1) illustrating a data configuration for distributing an activation key block (EKB) and an ICV generation key together in the information processing system of the present invention, and a processing example in a device.

FIG. 20 is a diagram (part 2) illustrating a data configuration for distributing an activation key block (EKB) and an ICV generation key together in the information processing system of the present invention, and a processing example in a device.

FIG. 21 is a content integrity check value (ICV) applicable in the information processing system of the present invention.
FIG. 4 is a diagram for explaining a copy protection function when is stored in a medium.

FIG. 22 is a content integrity check value (ICV) applicable in the information processing system of the present invention.
FIG. 3 is a diagram for explaining a configuration for managing content separately from a content storage medium.

FIG. 23 is a diagram illustrating an example of category classification in a hierarchical tree structure in the information processing system of the present invention.

FIG. 24 is a diagram illustrating a process of generating a simplified enabling key block (EKB) in the information processing system of the present invention.

FIG. 25 is a diagram illustrating a generation process of an enabling key block (EKB) in the information processing system of the present invention.

FIG. 26 is a diagram illustrating a simplified enabling key block (EKB) (Example 1) in the information processing system of the present invention.

FIG. 27 is a diagram illustrating a simplified enabling key block (EKB) (Example 2) in the information processing system of the present invention.

FIG. 28 is a diagram illustrating a category tree management configuration of a hierarchical tree structure in the information processing system of the present invention.

FIG. 29 is a diagram illustrating details of a category tree management configuration having a hierarchical tree structure in the information processing system of the present invention.

FIG. 30 is a diagram illustrating a category tree management configuration of a hierarchical tree structure in the information processing system of the present invention.

FIG. 31 is a diagram illustrating a reserved node in a category tree management configuration having a hierarchical tree structure in the information processing system of the present invention.

FIG. 32 is a diagram illustrating a new category tree registration processing sequence in a category tree management configuration having a hierarchical tree structure in the information processing system of the present invention.

FIG. 33 is a diagram illustrating the relationship between a new category tree and a higher-level category tree in a category tree management configuration having a hierarchical tree structure in the information processing system of the present invention.

FIG. 34 is a diagram illustrating a sub-EKB used in a category tree management configuration having a hierarchical tree structure in the information processing system of the present invention.

FIG. 35 is a diagram illustrating device revocation processing in a category tree management configuration having a hierarchical tree structure in the information processing system of the present invention.

FIG. 36 is a diagram illustrating a device revocation processing sequence in a category tree management configuration having a hierarchical tree structure in the information processing system of the present invention.

FIG. 37 is a diagram illustrating an update sub-EKB at the time of device revocation in a category tree management configuration having a hierarchical tree structure in the information processing system of the present invention.

FIG. 38 is a diagram illustrating a category tree revocation process in a category tree management configuration having a hierarchical tree structure in the information processing system of the present invention.

FIG. 39 is a diagram illustrating a category tree revocation processing sequence in a category tree management configuration having a hierarchical tree structure in the information processing system of the present invention.

FIG. 40 is a diagram illustrating the relationship between a revoked category tree and a higher-level category tree in a category tree management configuration having a hierarchical tree structure in the information processing system of the present invention.

FIG. 41 is a diagram illustrating capability setting in a category tree management configuration having a hierarchical tree structure in the information processing system of the present invention.

FIG. 42 is a diagram illustrating capability setting in a category tree management configuration having a hierarchical tree structure in the information processing system of the present invention.

FIG. 43 is a diagram illustrating a configuration of a capability management table managed by a key issuing center (KDC) in the information processing system of the present invention.

FIG. 44 is a flowchart of an EKB generation process based on a capability management table managed by a key issuing center (KDC) in the information processing system of the present invention.

FIG. 45 is a diagram illustrating capability notification processing at the time of registering a new category tree in the information processing system of the present invention.

FIG. 46 is a diagram illustrating a configuration of a category tree in the information processing system of the present invention.

FIG. 47 is a diagram illustrating a relationship between an EKB requester, a key issuing center, and a top-level category entity (TLCE) in the information processing system of the present invention, and a processing example.

FIG. 48 is a diagram illustrating a hardware configuration example of an EKB requester, a key issuing center, and a top-level category entity (TLCE) in the information processing system of the present invention.

FIG. 49 is a diagram illustrating a device node key (DNK) held by a device in the information processing system of the present invention.

FIG. 50 is a diagram illustrating a data configuration of an EKB type definition list in the information processing system of the present invention.

FIG. 51 is a diagram showing an EKB type registration processing flow in the information processing system of the present invention.

FIG. 52 is a diagram showing an EKB type invalidation processing flow in the information processing system of the present invention.

FIG. 53 is a diagram showing a tree change notification processing flow in the information processing system of the present invention.

FIG. 54 is a diagram showing an EKB type list request processing flow in the information processing system of the present invention.

FIG. 55 is a sub EK in the information processing system of the present invention.
FIG. 9 is a diagram illustrating a generation process of B.

FIG. 56 shows a sub EK in the information processing system of the present invention.
FIG. 9 is a diagram illustrating a generation process of B.

FIG. 57 shows a sub EK in the information processing system of the present invention.
FIG. 9 is a diagram illustrating a process of generating an EKB synthesized from B.

FIG. 58 is a diagram illustrating a process of generating a sub-EKB when a revoked device is present in the information processing system of the present invention.

FIG. 59 is a diagram illustrating a process of generating an EKB synthesized from a sub EKB when a revoke device is present in the information processing system of the present invention.

FIG. 60 shows a sub EK in the information processing system of the present invention.
FIG. 6 is a diagram for explaining a data configuration of an EKB synthesized from B.

FIG. 61 shows a sub EK in the information processing system of the present invention.
FIG. 6 is a diagram for explaining a data configuration of an EKB synthesized from B.

FIG. 62 is a diagram illustrating a data configuration of an EKB synthesized from a sub EKB when there is a revoke device in the information processing system of the present invention.

FIG. 63 is a diagram illustrating a revoke process in a data distribution type system in the information processing system of the present invention.

FIG. 64 is a diagram illustrating a revoke process in a self-recording type system in the information processing system of the present invention.

[Explanation of symbols]

DESCRIPTION OF SYMBOLS 10 Content distribution side 11 Internet 12 Satellite broadcasting 13 Telephone line 14 Media 20 Content reception side 21 Personal computer (PC) 22 Portable device (PD) 23 Cellular phone, PDA 24 Recording / reproducing device 25 Reproduction only device 30 Media 100 Recording / reproducing device 110 Bus 120 input / output I / F 130 MPEG codec 140 input / output I / F 141 A / D, D / A converter 150 encryption processing means 160 ROM 170 CPU 180 memory 190 drive 195 recording medium 601 version 602 depth 603 data pointer 604 tag pointer 605 Signature pointer 606 Data part 607 Tag part 608 Signature 1101 Recording device 2301 Root key 2302 Node key 2303 Leaf key 230 Category node 2306 Subcategory node 2701 Category tree 2702 Subroot 2811,2851 Subroot 2812,2852 Category tree terminal node 2901,290 Category tree 2950 Reserve node 2970 Management terminal node 3011, 3012,3013 Category tree 3021, 3022,3023 Reserve node 3201 Terminal node 3202 top node 3301, 3302 terminal node 3303 new category tree added terminal node 3410, 3420, 3430 category tree 3411, 3421, 3431 sub root 3432 revoke device node 3601 terminal node 3710, 3720, 3730 category tree 3711, 3721, 3731 sub root 3901 terminal No De 3902 a top node (sub-root node) 4001-4005 category tree 4021,4022,4023 category tree 4101-4105 category tree 4510 management entity 4511 key distribution center (KDC) 4520 EKB requester 4530 top-level category entity (T
LCE) 4540 Media manufacturer 4550 Device manufacturer 4551 DNKE device manufacturer 4552 DNK device manufacturer 5100 Category tree A 5120 Device node key area 5150 Revoke device 5200 Category tree B 5220 Device node key area 5300 Root tree 6000 EKB 6110, 6120 Sub EKB 6111, 6121 Length data 6112, 6122 Category identification data 6200 Header information 6300 Signature data 7000 EKB 7100 Category tree A 7120 Revoke device 7200 Category tree B 8000 EKB 8100 Category tree A 8120 Revoke device 8200 Category tree B

 ────────────────────────────────────────────────── ─── Continued on the front page (72) Inventor Takeo Oishi 6-7-35 Kita-Shinagawa, Shinagawa-ku, Tokyo Inside Sony Corporation (72) Inventor Ryuji Ishiguro 6-35, Kita-Shinagawa, Shinagawa-ku, Tokyo No. Sony Corporation (72) Inventor Ryuta Taki 6-7-35 Kita Shinagawa, Shinagawa-ku, Tokyo F-term within Sony Corporation (reference) 5B017 AA03 BA07 CA09 CA15 CA16 5J104 AA16 EA04 EA26 NA02 PA07

Claims (15)

[Claims] 1. A key tree in which a key is associated with a root, a node, and a leaf on a path from a root to a leaf of a tree in which a plurality of devices are configured as leaves, and a path forming the key tree is defined. An enabling key block (EKB) that has selected and has the encryption processing data of the upper key by the lower key on the selected path and that can be decrypted only in a device that can use the node key set corresponding to the selected path. The activation key block (EKB) is a sub-activation key block (sub-EKB) that can be decrypted in each of subtrees set as a partial tree of the key tree. Each of the plurality of key data included in the combined EKB is a fixed-length data file. The information processing system characterized by having configurations stored in Rudo. 2. The sub-tree is a category tree that is partitioned based on categories and managed by category entities. The sub-validation key block (sub-EKB) is a category tree managed by the category entities. It is generated as an EKB that can be processed based on keys associated with nodes or leaves belonging to the tree.
2. A configuration for generating a composite EKB as an EKB that can be commonly used for a plurality of category trees based on a sub-EKB generated by an entity.
An information processing system according to item 1. 3. The sub-activation key block (sub-EK)
B) each has its own algorithm, its own key
Sub activation key block with data length (sub EKB)
The key issuing center (KDC) performs a process of storing each of the key data in the sub-EKB constituting the composite EKB in a fixed-length data field in the process of generating the composite EKB based on the sub-EKB. The information processing system according to claim 1, wherein the information processing system is configured to execute. 4. The composite EKB, wherein the composite EKB is obtained by encrypting a node key set corresponding to each node constituting the key tree by using a lower node key or a lower leaf key, and stored in the composite EKB. 2. The information processing apparatus according to claim 1, further comprising a tag indicating presence / absence of encryption key data at a node or a leaf position at a lower left / right position of each of the one or more encryption key data. system. 5. The combined EKB is reconstructed by selecting a path constituting a simplified tree having a terminal node or a leaf at the bottom which can decode the combined EKB and omitting unnecessary nodes. 2. The information processing system according to claim 1, wherein a key corresponding to a node or a leaf of the construction hierarchy tree is included as encryption key data. 6. The composite EKB has a configuration in which a plurality of encrypted key data included in each of a plurality of sub-EKBs are rearranged according to a node or leaf position in a key tree. The information processing system according to claim 1, wherein 7. A tree composed of a category tree as a subtree divided on the basis of a category, and a key corresponds to each of a root, a node, and a leaf on a path from a root to a leaf of a tree in which a plurality of devices are configured as leaves. A key tree attached to the selected key tree is selected, the selected key path is selected, and encryption processing data of an upper key by a lower key on the selected path is included, and a node key set corresponding to the selected path can be used. An information recording medium storing an activation key block (EKB) that can be decrypted only in a device, and a sub-activation key block (sub-EKB) that can be decrypted in each of subtrees set as a partial tree of the key tree. Is stored, and the combined EKB is stored.
An information recording medium characterized by having a configuration in which each of a plurality of key data included therein is stored in a fixed-length data field. 8. The sub-activation key block (sub-EK)
B) each has its own algorithm, its own key
Sub activation key block with data length (sub EKB)
8. The information recording medium according to claim 7, wherein the storage area for the key data has a fixed length. 9. A key tree in which a key is associated with each of a root, a node, and a leaf on a path from a root to a leaf in which a plurality of devices are configured as leaves, and a path forming the key tree is defined. An enabling key block (EKB) that has encryption processing data of an upper key by a lower key on a selected path and that can be decrypted only in a device that can use a node key set corresponding to the selected path. The activation key block (EKB) is a sub-activation key block (sub-EKB) that can be decrypted in each subtree set as a partial tree of the key tree. ), And each of a plurality of key data included in the combined EKB is fixed. The information processing method characterized by providing a device stored in the data field. 10. The sub-tree is a category tree that is partitioned based on categories and managed by category entities. The sub-validation key block (sub-EKB) is a category tree managed by itself in the category entities. It is generated as an EKB that can be processed based on keys associated with nodes or leaves belonging to the tree.
10. The information processing method according to claim 9, wherein a combined EKB is generated as an EKB that can be commonly used for a plurality of category trees based on the sub-EKB generated by the entity. 11. The sub-activation key block (sub-EK)
B) each has its own algorithm, its own key
Sub activation key block with data length (sub EKB)
The key issuing center (KDC) performs a process of storing each of the key data in the sub-EKB constituting the composite EKB in a fixed-length data field in the process of generating the composite EKB based on the sub-EKB. The information processing method according to claim 9, wherein the method is executed. 12. The activation key block (EKB) includes: encryption key data obtained by encrypting a node key set corresponding to each node constituting the key tree using a lower node key or a lower leaf key; The one or more encryption key data stored in the activation key block (EKB) is generated as a configuration including a tag indicating the presence or absence of the encryption key data at the lower left / right node or leaf position of the node position. The information processing method according to claim 9, wherein: 13. The validating key block (EKB) is an unnecessary node by selecting a path forming a simplified tree having a terminal node or a leaf at the bottom which can decode the validating key block (EKB). 10. The information processing method according to claim 9, wherein a key corresponding to a node or a leaf of a reconstructed hierarchical tree to be reconstructed by omitting is generated as encryption key data. 14. The composite EKB is characterized in that a plurality of encrypted key data included in each of a plurality of sub-EKBs are rearranged according to a node or leaf position in a key tree, and are generated. 10. The information processing method according to 9. 15. A key tree in which a key is associated with each of a root, a node, and a leaf on a path from a root to a leaf in which a plurality of devices are configured as leaves, and a path forming the key tree is defined. An enabling key block (EKB) that has encryption processing data of an upper key by a lower key on a selected path and that can be decrypted only in a device that can use a node key set corresponding to the selected path. A program recording medium recording a computer program for causing an activation key block (EKB) generation process in a system having a configuration provided in a computer system to be executed on a computer system,
The computer program comprises: a sub-validation key block (sub-EKB) combining process step capable of decrypting in each of the sub-trees set as a partial tree of the key tree; and a plurality of key data included in the combined EKB. Storing each in a fixed-length data field.