JP2001358705A - Information processing system and method using cryptographic key block and program providing medium - Google Patents

Abstract

PROBLEM TO BE SOLVED: To realize information processing system and method capable of dividing the key tree configuration of a hierarchical structure and managing the key tree configuration. SOLUTION: This system sets a plurality of entities which manages a sub tree as a partial tree constituting a key tree obtained by making each key correspond to routes, nodes and leaves on paths from the root of the tree to leaf constructed with a plurality of devices as leaves and generates a sub effective key block(sub EKB) on the basis of only a key set by being associated with a node or a leaf belonging to the sub tree and generates and distributes an effective key block(EKB) that can be decoded only in a selected entity by using the sub effective key block(EKB) generated by a plurality of entities.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

The present invention relates to an information processing system and an information processing method using an encryption key block, and a program providing medium, and more particularly to a system and method for distributing an encryption processing key in a system involving encryption processing. In particular, by using a tree-structured hierarchical key distribution system, the amount of messages can be kept small, reducing the load of data distribution, for example, when updating content keys or updating various keys, and maintaining data security. And an information processing system using an encryption key block that realizes an efficient key distribution and management configuration as a configuration for managing a hierarchical key distribution tree with entities as a subset having common elements The present invention relates to a processing method and a program providing 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, the data is reproduced by being loaded with a storage medium, or is stored in a recording device in a recording / reproducing device attached to a PC or the like, for example, a memory card, a hard disk, or the like, and 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. Encrypt the content key to prevent unauthorized copying of the content key itself, provide it to the legitimate user, decrypt the encrypted content key using the decryption key possessed only by the legitimate user, and use the content key. A configuration has been proposed.

[0012] The determination as to whether or not the user is a legitimate user is generally made, 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. . 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. There are two types of authentication: mutual authentication using a common key cryptosystem and authentication using a public key system.Authentication using a common key requires a system-wide common key. It is inconvenient at the time of etc. 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. Provided is an information processing system, an information processing method, and a program providing medium using an encryption key block that realizes an efficient key distribution and management configuration as a configuration for managing a dynamic key distribution tree with entities as a subset having common elements The purpose is to do.

[0014]

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 information processing system using an encryption key block that generates an enabling key block (EKB) that can be decrypted only by a specific device by performing the above key update and the encryption process of the upper key using the lower key, and providing the device to the device. A plurality of entities for managing a subtree as a partial tree constituting the key tree and generating a sub-validated key block (sub-EKB) based only on keys set corresponding to nodes or leaves belonging to the subtree. And a sub-activation key block (sub-EKB) generated by the plurality of entities. Te, in the information processing system using an encryption key block, characterized in that it has a, a key distribution center (KDC) to produce a decodable enabling key block (EKB) only in the entity which is selected.

Further, in one embodiment of the information processing system of the present invention, the plurality of entities are a higher entity and a lower entity in which a lowermost terminal node of one entity is configured as a vertex node (sub root) of another entity. Is characterized in that it has a hierarchical structure.

Further, in one embodiment of the information processing system of the present invention, each of the plurality of entities has authority to set and update a key corresponding to a node or a leaf constituting a subtree belonging to the own entity. It is characterized by being.

Further, in one embodiment of the information processing system of the present invention, among the plurality of entities, each of the devices belonging to the lowermost entity whose lowermost leaf in the entity is a leaf corresponding to each device, It is characterized by having a configuration in which nodes on a path from a vertex node (sub root) of an entity to which the self belongs to a leaf corresponding to the own device, a node key set in the leaf, and a leaf key are stored.

Further, in one embodiment of the information processing system according to the present invention, each of the plurality of entities includes a lowermost node in the own entity in order to further add a self-managed entity below the own entity. Alternatively, one or more nodes or leaves in the leaf are reserved and set as reserved nodes.

Further, in one embodiment of the information processing system according to the present invention, the upper entity that adds the new entity to the terminal node includes a key corresponding to the upper entity terminal node that is a node for setting a subtree of the new entity. It is characterized in that it is set as a vertex node (sub root) key of a new entity.

Further, in one embodiment of the information processing system of the present invention, the newly added entity is a sub-validation key block (based on only keys set corresponding to nodes or leaves in a subtree within the new entity). A sub-EKB) is generated and the key issuing center (K
DC) to execute registration processing of a sub-EKB.

Further, in one embodiment of the information processing system of the present invention, the entity executing the revocation processing of the device is a node on a path from a vertex node (sub root) in the entity to a leaf corresponding to the revoked device. The set node key is updated, an updated sub-EKB 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 is generated and transmitted to the upper entity, and the upper entity provides the updated sub-EKB. An update sub-EKB in which the node key on the path from the terminal node to the own sub-route is updated is generated and transmitted to the higher-level entity, and the update sub-EKB generation and transmission process in entity units are sequentially performed up to the highest-level entity. From the revoke device A node renewal on the path leading to the gateway and a process of registering the updated sub-EKB generated by the key update with the key issuing center (KDC), thereby executing a device revocation process. Features.

Further, in one embodiment of the information processing system of the present invention, the entity executing the revocation processing of the lower-level entity is located on a path from a vertex node (sub root) in the entity to a terminal node corresponding to the revoked entity. An updated sub-EKB in which the node key set in the node is updated is generated and transmitted to the upper entity. It generates and transmits it to the higher-level entity, sequentially executes update sub-EKB generation and transmission processing in entity units up to the highest-level entity, updates the node key on the path from the revoke entity to the root, and performs key update. Generated update sub KB said key distribution center of the (K
It is characterized in that it has a configuration to execute a revocation process in entity units by performing a registration process to DC).

Further, in one embodiment of the information processing system of the present invention, the entity executing the revocation processing of the lower entity is located on a path from a top node (sub root) in the entity to a terminal node corresponding to the revoked entity. An updated sub-EKB in which the node keys set in the nodes other than the terminal node are updated is generated and transmitted to the upper entity, and the upper entity replaces the node key on the path from the terminal node providing the updated sub-EKB to its own sub-root. Updated sub EK updated
B is generated and transmitted to the higher-level entity. Up to the highest-level entity, the update sub-EK in entity units
B generation and transmission processes are sequentially performed to update a node key excluding the terminal node corresponding to the revoked entity on the path from the revoked entity to the root, and the key issuing center of the updated sub-EKB generated by the key update (KDC) is characterized in that it is configured to execute revoke processing in entity units by performing registration processing.

Further, in one embodiment of the information processing system of the present invention, the entity includes a device type,
It is characterized by being configured as a device or entity that manages devices or entities belonging to a common category such as a service type and a management means type.

Further, a second 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 in which a plurality of devices are configured as leaves. An effective key block (E) that can select a path constituting the key tree, update a key on the selected path, and perform encryption processing of an upper key with a lower key to decrypt only a specific device.
In an information processing method using an encryption key block in an information processing system for generating and providing a KB) to a device, a node belonging to the subtree or a plurality of entities managing a subtree as a partial tree constituting the key tree Sub activation key block (sub EK) based only on the key set corresponding to the leaf
B) generating a key issuing center (KD
C), using a sub-activation key block (sub-EKB) generated by the plurality of entities to generate an activation key block (EKB) that can be decrypted only in the selected entity. An information processing method using an encryption key block is a feature.

Further, in one embodiment of the information processing method of the present invention, each of the plurality of entities executes a setting and updating process of a key corresponding to a node or a leaf constituting a subtree belonging to the own entity. It is characterized by.

Further, in one embodiment of the information processing method according to the present invention, the upper entity that adds the new entity to the terminal node includes a key corresponding to the upper entity terminal node that is a node for setting a subtree of the new entity. It is set as a vertex node (sub root) key of a new entity.

Further, in one embodiment of the information processing method of the present invention, the newly added entity is a sub-validation key block (based on only keys set corresponding to nodes or leaves in a subtree in the new entity). Sub-EKB) and generate the key issuing center (KD
The sub-EKB registration process for C) is executed.

Further, in one embodiment of the information processing method according to the present invention, the entity executing the revocation processing of the device is a vertex node (sub root) in the entity.
Updates a node key set in a node on a path from a to a leaf corresponding to a revoked device, and configures the updated node key as an encryption key that can be decrypted only in a leaf device other than the revoked device.
B, which is transmitted to the higher-level entity. The higher-level entity generates an updated sub-EKB obtained by updating the node key on the path from the terminal node that provided the updated sub-EKB to its own sub-root, and transmits the updated sub-EKB to the higher-level entity.
The update sub-EKB generation and transmission process are sequentially executed in entity units up to the highest entity to update the node key on the path from the revoke device to the root, and the key issuing center of the update sub-EKB generated by the key update It is characterized in that the device is revoked by performing a registration process to the (KDC).

Further, in one embodiment of the information processing method according to the present invention, the entity executing the revocation processing of the lower entity is located on a path from a vertex node (sub root) in the entity to a terminal node corresponding to the revoked entity. An updated sub-EKB in which the node key set in the node is updated is generated and transmitted to the upper entity. It generates and transmits it to the higher-level entity, sequentially executes update sub-EKB generation and transmission processing in entity units up to the highest-level entity, updates the node key on the path from the revoke entity to the root, and performs key update. Update sub EK generated The key distribution center of the (KDC)
It is characterized in that revoke processing in entity units is performed by performing registration processing to the.

Further, in one embodiment of the information processing method of the present invention, the entity executing the revocation processing of the lower entity is located on a path from a vertex node (sub root) in the entity to a terminal node corresponding to the revoked entity. An updated sub-EKB in which the node keys set in the nodes other than the terminal node are updated is generated and transmitted to the upper entity, and the upper entity replaces the node key on the path from the terminal node providing the updated sub-EKB to its own sub-root. An updated sub-EKB is generated and transmitted to a higher-level entity, and an update sub-EKB is generated and transmitted in entity units up to the highest-level entity, and the revoking / evaluation on the path from the revoking entity to the root is performed. Terminal No. corresponding to entity By performing node keys performs update registration process to the key distribution center updates sub-EKB produced by the key update (KDC) excluding,
It is characterized in that revoke processing is performed in entity units.

Further, according to a third 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 of a tree in which a plurality of devices are configured as leaves. An effective key block (E) that can select a path constituting the key tree, update a key on the selected path, and perform encryption processing of an upper key with a lower key to decrypt only a specific device.
A program providing medium for providing a computer program for causing a computer system to execute an enabling key block (EKB) generation process in an information processing system for generating a KB) and providing the generated KB to a device, wherein the computer program includes: A step of generating a sub-validated key block (sub-EKB) based only on keys set corresponding to nodes or leaves belonging to the sub-tree in a plurality of entities managing a sub-tree as a partial tree constituting the key tree When,
At a key issuing center (KDC), a sub-validation key block (sub-EK
B) generating an enabling key block (EKB) that can be decrypted only in the selected entity using B).

[0033]

In the configuration of the present invention, the amount of distribution messages required for key update is kept small by using an encryption key distribution configuration having a hierarchical structure of a tree (tree) structure. That is, using a key distribution method in which each device is arranged on each leaf of the n-ary tree, a content key, for example, an encryption key for content data, or authentication used for authentication processing via a recording medium or a communication line. The key or the program code is distributed together with the activation key block. By doing this,
It is possible to safely deliver data that can be decrypted only by a legitimate device.

Further, in the configuration of the present invention, an efficient key distribution and management configuration is realized as a configuration in which the hierarchical key distribution tree is managed by entities as a subset having common elements.

The program providing medium according to the third aspect of the present invention is, for example, a medium for providing a computer program in a computer-readable format to a general-purpose computer system capable of executing various program codes. It is. 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 providing medium defines a structural or functional cooperative relationship between the computer program and the providing medium for realizing the functions of a predetermined computer program on a computer system. Things. In other words, by installing the computer program into the computer system via the providing 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.

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 a data 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, and the like, while the device of the content reception side 20 is a personal computer. (PC) 21, portable device (PD) 22, mobile phone, PDA (Personal Digital A)
ssistants), a recording / reproducing device 24 such as a DVD or CD player, and a reproducing device 25 such as a game terminal. Each device of the content receiving side 20
The content provided from the content distribution side 10 is transferred to a communication means such as a network or a medium 30.
To get from.

[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 data transmissions and receptions with respect to 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 discovered that the key: K0011, K001, K00, K0, KR possessed by the device 3 has been analyzed and revealed by an attacker (hacker), 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. In this way, the devices 0, 1, and 2 update the keys K (t) 001, K (t) 00, K (t) 0, K
(T) R can be obtained. The index in FIG. 4A 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 the 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 the contents is 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 encrypted 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 a common key cryptosystem, other systems are also possible as long as they are common key cryptosystems. 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 process using the key Kab using the DES CBC mode, for example, in the process using the DES, the initial value and the Ra are exclusive-ORed, and the DES encryption unit encrypts using the key Kab. 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 ciphertext 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.

In the case where an invalid or inconsistent data is found at the time of verifying the received data, the processing 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 decrypt the data safely.

[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. Generate Sig and send it back to B along with A's public key certificate. Here, Ra and Rb are each 64 bits, and the X and Y coordinates of Av are each 160 bits, so that an electronic signature for a total of 448 bits is generated.

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 digital 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 invalid or mismatch is found, the processing 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) that generates an EKB that can be decrypted with the playback device that is the content key distribution destination, the node key and the leaf key of the recording medium, and that 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 Activation 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 activation 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
1 is an activation key block (EKB) that can be decrypted by the node key and 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 decrypts the program code using 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 obtained, 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 distribution of the check value generation key using the EKB, it is possible to distribute the check value generation key in which the amount of data 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 legally 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 falsified content.

[Category Classification of Hierarchical Tree Structure] The encryption key is configured as a hierarchical tree structure of FIG. 3 including a root key, a node key, a leaf key, etc., and a content key, an authentication key, an ICV generation key, or a program code, data, etc. are valid. Although the configuration for encrypting and distributing with the encrypted key block (EKB) has been described, the hierarchical tree structure defining the node keys and the like is classified for each device category to efficiently perform key update processing and encrypted key distribution. The configuration for executing 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 in the following middle row, and a leaf key 2303 is set in the bottom row. 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 the 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] In the above-described tree configuration of FIG. 3, for example, when a key, for example, a content key is sent to a predetermined device (leaf), a leaf key owned by the key distribution destination device ,
An activation key block (E
KB) is generated and provided. For example, in the tree configuration shown in FIG.
When a key, for example, a content key is transmitted to g and j, each node a, g, and j generates and distributes an enabling key block (EKB) that can be decrypted.

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 enabling key block (EKB) described with reference to FIG. 25 stores data obtained by encrypting all the 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. First
The second bit has the same meaning as in the example of FIG. 25, and 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 third 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 data can sequentially decrypt only the data of the portion where 1 is stored in the third 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.

The simplified hierarchical tree structure can be used particularly effectively in the entity-based EKB management structure described later. The entity is an aggregate block of a plurality of nodes or leaves selected from the nodes or leaves constituting a tree configuration as a key distribution configuration. An entity is a set that is set according to the type of device, or a processing unit, jurisdiction unit, or provided service unit that has a certain common point, such as a management unit of a device provider maker, a content provider, a payment institution, or the like. Is set as a set of various aspects. In one entity, 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 entities. Thus, it is possible to generate and distribute a simplified enabling key block (EKB) that can be decrypted by a device belonging to the selected entity. The management configuration of the entity unit will be described later in detail.

It should be noted 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 Entities] Next, a description will be given of 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. Note that a block as a set of a plurality of nodes or leaves is hereinafter referred to as an entity. An entity is a set that is set according to the type of device, or a processing unit, jurisdiction unit, or provided service unit that has a certain common point, such as a management unit of a device provider maker, a content provider, a payment institution, or the like. Is set as a set of various aspects. That is, the entity is defined as a device belonging to a common category such as a device type, a service type, and a management means type, or a management entity of the entity.

The entity will be described with reference to FIG. FIG. 27A is a diagram for explaining a management configuration in units of entity of a tree. One entity is shown as a triangle in the figure, for example, one entity 270
1 includes a plurality of nodes. (B) shows the node configuration within one entity. One entity is composed of a multi-stage bifurcated tree having one node as a vertex. Hereinafter, the vertex node 2702 of the entity is referred to as a sub root.

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

As understood from FIG. 27A, the entities have a hierarchical structure. About this hierarchy,
This will be described with reference to FIG.

FIG. 28 (a) is a diagram for explaining the hierarchical structure in a simplified manner. Entities A01 to Ann are arranged several steps below Kroot, and the entities A
Below 1-An, there are further entities B01-B
nk, and below that, entities C1 to Cnq are set. Each entity is shown in FIG.
As shown in (c), it has a tree shape composed of a plurality of nodes and leaves.

For example, the configuration of the entity 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 entity has the identifier Bnk, and executes the node key management corresponding to the nodes in the entity Bnk independently of the entity Bnk, thereby managing the lower (child) entity set with the terminal node 2812 as the vertex. On the other hand, Entity B
nk is under the management of a higher (parent) entity Ann having the sub route 2811 as a terminal node.

The configuration of the entity Cn3 has, as shown in (c), a sub-root 2851 as a vertex node, a terminal node 2852 as each device, in this case, a plurality of nodes and leaves up to the leaf. This entity has the identifier Cn3, and executes management of the leaf (device) corresponding to the terminal node 2852 by executing the node key and leaf key management corresponding to the node and leaf in the entity Cn3 independently of the entity Cn3. On the other hand, the entity Cn3 is under the management of a higher (parent) entity Bn2 having the sub-root 2851 as a terminal node. Key management in each entity is, for example, key update processing, revoke processing, etc., which will be described in detail later.

The device as the leaf of the lowermost entity stores the node key and leaf key of each node located on the path from the leaf key of the entity to which the device belongs to the subroot node which is the top node of the entity to which the device belongs. For example, terminal node 2
The device 852 stores each key from the terminal node (leaf) 2852 to the sub root node 2851.

The configuration of the entity will be further described with reference to FIG. An entity 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) entities corresponding to the terminal nodes managed by the entities or the number of devices as leaves.

When the vertical entity configuration as shown in FIG. 29A is embodied, the configuration shown in FIG. 29B is obtained. The root entity is the highest entity having a root key. Entities A, B, and C are set as a plurality of lower entities at a terminal node of the root entity, and an entity D is set as a lower entity of the entity C. Entity C is 2
The node 901 holds one or more of its end nodes as a reserved node 2950, and further increases an entity managed by itself by using an entity C ′ 2902 having a tree structure of a plurality of stages as a reserved node 295.
By newly setting 0 as the top node, the number of management terminal nodes 2970 can be increased, and the increased lower-level entity can be added to the management terminal node.

The reserve node will be further described with reference to FIG. Entity A, 3011 has lower-level entities B, C, D,... To be managed, and has one reserved node 3021. When the entity wants to further increase the lower-level entities to be managed, the reserve node 3021 stores the lower-level entities A ′, 3 of the self-management.
012, and the lower-level entities F and G to be managed can be further set at the terminal nodes of the lower-level entities A ′ and 3012. The lower-level entity A ′, 3012 of self-management can also further increase the number of management entities by setting at least one of its end nodes as the reserve node 3022, thereby setting the lower-level entity A ″ 3013. One or more reserve nodes are also secured at the terminal node of the lower entity A ″ 3013. By adopting such a reserve node possession configuration, the number of lower-level entities managed by a certain entity can be increased without limit. The reserved entity is 1 of the terminal node.
A configuration in which a plurality is set instead of only one may be adopted.

In each entity, an enabling key block (EKB) is formed in entity units, and key updating and revocation processing are executed in entity units. As shown in FIG. 30, a plurality of entities A,
In A ′ and A ″, an individual activation key block (EKB) is set for each entity.
For example, a device manufacturer that manages the entities A, A ′, and A ″ in common can collectively manage the entities A, A ′, and A ″.

[Registration Processing of New Entity] Next, registration processing of a new entity will be described. FIG. 31 shows the registration processing sequence. Description will be given according to the sequence of FIG. A new (child) entity (N-En) newly added in the tree configuration executes a new registration request for a higher (parent) entity (P-En).
Each entity has a public key in accordance with the public key cryptosystem, and the new entity sends its own public key to the higher-level entity (P-En) upon a registration request.

The higher-level entity (P
-En) is the received new (child) entity (NE)
n) the public key of the Certificate Authority (CA)
or the public key of the new (child) entity (N-En) to which the signature of the CA is added. These procedures consist of a higher entity (P-En) and a new (child)
This is performed as a procedure for mutual authentication with the entity (N-En).

When the authentication of the new registration request entity is completed by these processes, the upper entity (P-E)
n) permits registration of the new (child) entity (N-En) and transmits the node key of the new (child) entity (N-En) to the new (child) entity (N-En). This node key is the upper entity (P-En)
, And corresponds to the vertex node of the new (child) entity (N-En), that is, the subroot key.

When the node key transmission is completed, the new (child) entity (N-En) constructs a tree structure of the new (child) entity (N-En), and the vertex node of the vertex node received at the vertex of the constructed tree. The sub-root key is set, the key of each node and leaf is set, and an enable key block (EKB) in the entity is generated. An enabling key block (EKB) within one entity is called a sub-EKB.

On the other hand, the higher-level entity (P-En)
By adding a new (child) entity (N-En), a higher-level entity (P-
Generate the sub EKB in En).

A new (child) entity (N-En) is
A node key in the new (child) entity (N-En),
When the sub EKB constituted by the leaf key is generated, this is transmitted to the higher-level entity (P-En).

Higher-order entity (P-En) receiving sub-EKB from new (child) entity (N-En)
Indicates the received sub EKB and the higher-level entity (P-E
n) and the updated sub-EKB to the key issuing center (KD
C: Key Distribute Center).

The key issuance center (KDC) can use various aspects of E based on the sub-EKBs of all entities.
It is possible to generate a KB, that is, an EKB that can be decoded only by a specific entity or device. An EKB in which an entity or device that can be decrypted is set in this way is provided to, for example, a content provider,
The content provider encrypts the content key based on the EKB and provides the content key via a network or by storing the content key in a recording medium, so that the content can be provided only in a specific device.

The registration processing of the sub-EKB of the new entity to the key issuing center (KDC) is performed by the sub-EKB.
The present invention is not limited to the method of sequentially transferring and executing the KB via the higher-level entity, but may be configured to execute the process of directly registering the newly issued entity with the key issuing center (KDC) without the higher-level entity. Good.

FIG. 32 shows the correspondence between the upper entity and the lower entity to be newly added to the upper entity.
This will be described with reference to FIG. One of the terminal nodes of the upper entity
The lower entity is added as an entity under the management of the upper entity by providing the lower entity as a vertex node of the newly added entity to the lower entity. The entity managed by the higher-level entity, which will be described in detail later, has a meaning that the higher-level entity can execute the revocation (exclusion) processing of the lower-level entity.

As shown in FIG. 32, when a new entity is set as the upper entity, one node 3201 of the terminal node which is a leaf of the upper entity is set as an equal node to the top node 3202 of the newly added entity. . That is, one terminal node, which is one leaf of the upper node, is set as a sub route of the newly added entity. With this setting, the newly added entity is enabled under the entire tree structure.

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

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. As shown in FIG. 33 (b), each entity encrypts a valid terminal node or an upper node key encrypted with a leaf key, and further encrypts an upper node key with the upper node key, and sequentially encrypts the deeper and deeper sub-root. It has an EKB composed of data and manages it.

[Revoking Process under Entity Management] Next, a description will be given of a device or entity revoking (exclusion) process in a configuration in which the key distribution tree configuration is managed as an entity unit. Figure 3 above
In the fourth example, the process of distributing an enabling key block (EKB) in which only a specific device can be decrypted from the entire tree configuration and a revoked device cannot decrypt is described. The revocation processing described with reference to FIGS. 3 and 4 is processing for revoking a device that is a specific leaf from the entire tree. However, in the configuration based on the entity management of the tree, the revocation processing can be executed for each entity.

The revocation processing in a tree configuration under entity management will be described with reference to the drawings in FIG. FIG. 34 shows the entities forming the tree.
FIG. 9 is a diagram for explaining device revocation processing by the entity at the bottom, that is, the entity managing each device.

FIG. 34 (a) shows a key distribution tree structure by entity management. A root node is set at the top of the tree.
1 to Ann, and B01 to Bnk entities at lower stages, and C1 to cn entities at lower stages. The lowest entity is that the terminal node (leaf) is an individual device, for example, a recorder / reproducer,
It is assumed that it is a playback-only device or the like.

Here, the revoke process is independently executed in each entity. For example, in the lowermost entities C1 to Cn, revocation processing of a leaf device is executed. FIG. 34B shows a tree configuration of an entity Cn, 3430, which is one of the entities at the bottom. The entity Cn, 3430 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 entity Cn, 3430 is an activation key composed of a node key and a leaf key in the entity Cn that has been independently updated. Generate a block (sub-EKB). 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. The administrator of the entity Cn generates this as an updated sub-EKB. More specifically, each of the nodes 3431, 3434, and 3 configuring a path from the subroot to the revoke device 3432
The node key 435 is 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 entity in the revoke processing configuration described in FIGS.

The activation key block (sub-EKB) updated by the entity Cn, 3430 by the revocation process is transmitted to the upper entity. In this case, the upper entity is the entity Bnk, 3420
And the vertex node 34 of the entity Cn, 3430
This is an entity having 31 as a terminal node.

Upon receiving the activation key block (sub-EKB) from lower entity Cn, 3430, entity Bnk, 3420 receives the end of entity Bnk, 3420 corresponding to vertex node 3431 of entity Cnk, 3430 included in the key block. Node 3
431 is set to the key updated in the lower entity Cn, 3430, and its own entity Bnk,
In step 3420, the sub EKB is updated. FIG.
(C) shows a tree configuration of the entity Bnk, 3420. In the entity Bnk, 3420, the node key to be updated is the sub root 34 shown in FIG.
21 is a node key on a path from 21 to a terminal node 3431 constituting an entity including a revoke device. That is, the node keys of the nodes 3421, 3424, and 3425 constituting the path connected to the node 3431 of the entity that has transmitted the update sub-EKB are to be updated. The node key of each of these nodes is updated to generate a new updated sub EKB of the entity Bnk, 3420.

Alternatively, the entity Bnk, 3720
Does not update the terminal node 3731 of the entity Bnk, 3720 corresponding to the vertex node 3731 of the entity Cnk, 3730 when revoking the lower entity Cn, 3730, and updates the subroot of the entity Bnk, 3720 from the revoking entity 3730. Updating may be performed by updating the node keys except for the terminal node 3731 on the path up to generating the validation key block to generate the updated sub-EKB.

Further, the activation key block (sub-EKB) updated by entity Bnk, 3420 is transmitted to the higher-level entity. In this case, the higher-level entity is the entity Ann, 3410, and has the vertex node 3421 of the entity Bnk, 3420 as a terminal node.

Upon receiving an activation key block (sub-EKB) from lower-level entity Bnk, 3420, entity Ann, 3410 vertex node 342 of entity Bnk, 3420 included in the key block
The terminal node 3421 of the entity Ann, 3410 corresponding to No. 1 is set to the key updated in the lower entity Bnk, 3420, and its own entity A
nn, 3410, the sub EKB is updated. FIG. 34D shows a tree configuration of the entities Ann and 3410. In the entity Ann, 3410, the node keys to be updated are the nodes 3 constituting the path connected to the entity node 3421 that transmitted the update sub-EKB from the sub route 3411 in FIG.
Node keys 411, 3414, and 3415. The node keys of these nodes are updated and the entity An
n, 3410, and generate a new updated sub-EKB.

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

FIG. 35 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 entity (D-En) at the bottom of the tree configuration updates a key necessary to eliminate a revoked leaf in the device management entity (D-En), and updates the device management entity (D-En). -En) to generate a new sub-EKB (D). The update sub-EKB (D) is sent to the upper entity. The upper (parent) entity (P1-En) that has received the update sub-EKB (D) updates the terminal node key corresponding to the update vertex node of the update sub-EKB (D), and updates the terminal key from the terminal node to the subroot. An updated sub-EKB (P1) in which the node key has been updated is generated.
These processes are sequentially executed in the upper entity, and all sub EKBs finally updated are stored and managed in the key issuing center (KDC).

FIG. 36 shows an example of an enabling key block (EKB) generated by an upper entity performing an updating process by a device revocation process.

FIG. 36 shows that in the configuration shown in FIG. 36A, an update sub-E
EK generated in upper-level entity that received KB
FIG. 9 is a diagram illustrating an example of B. The top node of the lower entity including the revoked device corresponds to the terminal node (node 100) 3601 of the upper entity.

The higher-level entity is obtained from the sub-root of the higher-level entity by a terminal node (node 100) 3601.
A new updated sub-EKB is generated by updating the node keys existing in the paths up to. The update sub-EKB is shown in FIG.
(B). Updated keys are indicated by underlining and [']. The node key on the path from the terminal node updated to the sub-root updated in this manner is updated as an updated sub-EKB in the entity.

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

FIG. 37 (a) shows a key distribution tree structure by entity management. A root node is set at the top of the tree.
1 to Ann, and B01 to Bnk entities at lower stages, and C1 to cn entities at lower stages. The lowest entity is that the terminal node (leaf) is an individual device, for example, a recorder / reproducer,
It is assumed that it is a playback-only device or the like.

Here, the revoke processing is performed by the entity C
n, 3730 will be described.
The entity Cn, 3730 at the bottom is shown in FIG.
Has a vertex node 3431 and a plurality of devices in a leaf which is a terminal node as shown in FIG.

By revoking the entity Cn, 3730, all devices belonging to the entity Cn, 3730 can be excluded from the tree structure at once. The revoke process of the entity Cn, 3730 is executed in the entity Bnk, 3720, which is a higher-level entity of the entity Cn, 3730. The entity Bnk, 3720 is the entity Cn, 37
This entity has 30 vertex nodes 3731 as terminal nodes.

The entity Bnk, 3720, when executing revocation of the lower entity Cn, 3730,
Terminal node 3 of entity Bnk, 3720 corresponding to vertex node 3731 of entity Cnk, 3730
731 has been updated and its Revo
The node key on the path from 730 to the sub-root of the entity Bnk, 3720 is updated to generate an activation key block to generate an updated sub-EKB. The node key to be updated is the sub-root 372 in FIG.
This is a node key on the path from 1 to the terminal node 3731 constituting the vertex node of the revolute entity. That is, nodes 3721, 3724, 3725, and 373
One node key is to be updated. The node key of each of these nodes is updated to generate a new updated sub-EKB for the entity Bnk, 3720.

Further, the activation key block (sub-EKB) updated by entity Bnk, 3720 is transmitted to the higher-level entity. In this case, the upper-level entity is the entity Ann, 3710, and has the vertex node 3721 of the entity Bnk, 3720 as a terminal node.

Upon receiving the activation key block (sub-EKB) from lower entity Bnk, 3720, entity Ann, 3710, vertex node 372 of entity Bnk, 3720 included in the key block
The terminal node 3721 of the entity Ann, 3710 corresponding to No. 1 is set to the key updated in the lower entity Bnk, 3720, and its own entity A
nn, 3710 of the sub EKB are updated. FIG. 37D shows a tree configuration of the entities Ann and 3710. In the entity Ann, 3710, the node keys to be updated are the nodes 3 constituting the path connected to the node 3721 of the entity that transmitted the update sub-EKB from the sub route 3711 in FIG.
Node keys 711, 3714, and 3715. The node keys of these nodes are updated and the entity An
n, 3710 generate new updated sub-EKBs.

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

FIG. 38 shows a sequence diagram of the revoke processing of the entity. The processing procedure will be described with reference to the sequence diagram of FIG. First, the entity management entity (E-En) who wants to revoke the entity,
The key necessary for eliminating the revocation target terminal node in the entity management entity (E-En) is updated, and a new sub-EKB (E) of the entity management entity (E-En) is generated. Update sub EKB
(E) is sent to the host entity. Update sub E
Top (parent) entity that received KB (E) (P1-
En) updates the terminal node key corresponding to the updated vertex node of the updated sub EKB (E) and generates an updated sub EKB (P1) in which the node key on the path from the terminal node to the sub root is updated. These processes are sequentially performed.
The sub-EKB finally executed by the higher-level entity is stored and managed in the key issuing center (KDC). Key Issue Center (KDC)
Various EKBs are generated based on the update sub-EKBs of all the entities. The updated EKB is an encrypted key block that cannot be decrypted by a device belonging to the revoked entity.

FIG. 39 shows the correspondence between the revoked lower-level entity and the revoked upper-level entity. Terminal node 3901 of upper entity
Is updated by the revocation of the entity, and by updating the node key existing in the path from the terminal node 3901 to the sub root in the tree of the higher entity,
A new sub-EKB is generated. As a result, the node key of the vertex node 3902 of the revoked lower entity and the node key of the terminal node 3901 of the upper entity do not match. The EKB generated by the Key Issuing Center (KDC) after revoking the entity,
End node 390 updated in upper entity
Therefore, the device corresponding to the leaf of the lower entity that does not have the updated key cannot decrypt the EKB generated by the key issuing center (KDC).

In the above description, the revoking process of the entity at the bottom of the device management is described. However, the process of revoking the entity management entity in the middle of the tree by the upper entity can be performed by the same process as described above. It is. By revoking the middle entity management entity, all the plurality of entities and devices belonging to lower levels of the revoked entity management entity can be revoked collectively.

As described above, by executing revocation in entity units, revocation processing in a simpler process can be performed as compared with revocation processing executed in individual device units.

[Entity Capability Management] Next, in the key distribution tree configuration in entity units, the capabilities (Capabil
A description will be given of a processing configuration that manages the content and manages the content distribution according to the capability. 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. 40 shows an example of an entity configuration in which capabilities are defined. A root node is located at the highest point of the key distribution tree configuration, a plurality of entities are connected to a lower layer, and each node has a two-branch tree configuration. Here, for example, the entity 4001 is defined as an entity having a capability that allows any one of the audio reproduction methods A, B, and C. Specifically, for example, when music data compressed by a certain audio compression program-A, B, or C is distributed, the entity 4001
Devices belonging to the following entities are capable of expanding compressed data.

Similarly, the entity 4002 is for the audio reproduction system B or C, and the entity 4003 is for the audio reproduction system A.
Alternatively, B and the entity 4004 are defined as entities having capabilities capable of processing the audio reproduction system B and the entity 4005 are capable of processing the audio reproduction system C.

On the other hand, the entity 4021 is defined as an entity that allows the image reproduction schemes p, q, and r. The entity 4022 is an image reproduction scheme of the schemes p and q, and the entity 4023 is a capability capable of reproducing images of the scheme p. It is defined as an entity that has

The capability information of each entity 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 capability information of each entity. 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.

Although FIG. 40 shows a configuration in which capability information is defined for all entities,
It is not always necessary to define capability information for all entities as in the configuration of FIG. 40. For example, as shown in FIG. 41, a capability is defined only for the lowest entity to which a device belongs and belongs to the lowest entity. The capability of the device is managed at the key issuing center (KDC), and an enabling key block (EKB) that can be decrypted only by a device capable of processing desired by the content provider is determined based on the capability information defined in the lowermost entity. It is good also as composition which generates. In FIG. 41, capabilities in entities 4101 = 4105 in which devices are defined in end nodes are defined, and capabilities for these entities are defined by a key issuing center (KDC).
It is a configuration managed in. For example, entity 41
A device 01 is capable of processing the method B for sound reproduction and the method r for image reproduction. The entity 4102 includes a device capable of performing the processing of the method A for audio reproduction and the processing of the method q for image reproduction.

FIG. 42 shows a configuration example of the capability management table managed in the key issuing center (KDC). The capability management table has a data configuration as shown in FIG. That is, an entity ID as an identifier for identifying each entity, a capability list indicating a capability defined for the entity, and this capability list are processed by, for example, the audio data reproduction processing method (A) as shown in FIG. [1] if possible, [0] if processing is impossible, [1] if audio data reproduction processing method (B) can be processed,
If it is not possible to process the data, it is configured by setting [1] or [0] bit by bit for the possibility of data processing in various modes such as [0]. The method of setting the capability information is not limited to such a format, and another configuration may be used as long as the capability of the entity management device can be identified.

The capability management table further includes a sub-EKB or a sub-EKB of each entity.
Is stored in another database, the sub-EK
The identification information of B is stored, and the subroot node identification data of each entity is stored.

The key issuing center (KDC) generates, based on the capability management table, for example, an enabling key block (EKB) that can be decrypted only by a device capable of reproducing specific content. 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 an entity 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. 1] is selected.

Next, in step S4302, a list of selected entity IDs composed of the selected entities is generated. Next, step S4303
To select a path (a path in a key distribution tree configuration) required for the tree configured by the selected entity ID.
In step S4304, it is determined whether or not all the paths included in the list of selected entity IDs have been selected. Until the selection is completed, a path is generated in step S4303. This means a process of sequentially selecting each path when a plurality of entities are selected.

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

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 selection entity constituting the tree is extracted from the capability management table, and the sub-EKB and
Based on the updated node key generated in step S4306, an enable key block (EKB) that can be decrypted only in the device of the selected entity is generated. The activation key block (EKB) generated in this way becomes an activation key block (EKB) that can be used only by a device having a specific capability, that is, can be decrypted. For example, the content key is encrypted by the activation key block (EKB), and the content compressed by the content key based on the specific program is encrypted and provided to the device, and the content is selected by the key issuing center (KDC). The content is used only on a specific processable device.

As described above, 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 entity is registered, it is necessary to acquire the capability of the newly registered entity in advance. The capability notification process associated with the new entity registration will be described with reference to FIG.

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

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

The higher-level entity (P
-En) is the received new (child) entity (NE)
n) the public key of the Certificate Authority (CA)
or the public key of the new (child) entity (N-En) to which the signature of the CA is added. These procedures consist of a higher entity (P-En) and a new (child)
This is performed as a procedure for mutual authentication with the entity (N-En).

When the authentication of the new registration request entity is completed by these processes, the upper entity (P-E)
n) permits registration of the new (child) entity (N-En) and transmits the node key of the new (child) entity (N-En) to the new (child) entity (N-En). This node key is the upper entity (P-En)
, And corresponds to the vertex node of the new (child) entity (N-En), that is, the subroot key.

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

A new (child) entity (N-En) is
A node key in the new (child) entity (N-En),
When the sub-EKB constituted by the leaf key is generated, the sub-EKB is transmitted to the higher-level entity (P-En), and further, capability information on the device managed by the own entity is notified to the higher-level entity.

The upper entity (P-En) that has received the sub-EKB and capability information from the new (child) entity (N-En) has updated the received sub-EKB and capability information, and the upper entity (P-En). Sub EKB and key issuing center (KDC: Key
Distribute Center).

The key issuing center (KDC) registers the received sub-EKB and the capability information of the entity in the capability management table described with reference to FIG. 42, 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 an entity or a device having a specific capability.

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.

[0226]

As described above, according to the information processing system and method of the present invention, 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 are respectively provided. A plurality of sub-trees for managing a sub-tree as a partial tree constituting a key tree associated with a key and generating a sub-validated key block (sub-EKB) based only on keys set corresponding to nodes or leaves belonging to the sub-tree Is set, and a sub-activation key block (sub-EKB) generated by a plurality of entities is used to enable an activation key block (E) that can be decrypted only in the selected entity.
KB) is generated and delivered, so that the hierarchically structured key tree structure can be divided and managed.
Detailed processing can be performed according to the device.

Further, according to the information processing system and method of the present invention, it is possible to execute a device or entity revocation process in an entity, and to prevent an increase in the processing amount due to a device increase in the case of collective device management. You.

Further, according to the information processing system and method of the present invention, since a reserve node is set at a terminal node of each entity, it is possible to cope with an increase in management devices or management entities.

[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
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) in the information processing system of the present invention.

FIG. 27 is a diagram illustrating an entity management configuration of a hierarchical tree structure in the information processing system of the present invention.

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

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

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

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

FIG. 32 is a diagram illustrating the relationship between a new entity and a higher-level entity in an entity management configuration having a hierarchical tree structure in the information processing system according to the present invention.

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

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

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

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

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

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

FIG. 39 is a diagram illustrating a relationship between a revoking entity and a higher-level entity in an entity management configuration having a hierarchical tree structure in the information processing system of the present invention.

FIG. 40 is a diagram illustrating capability setting in an entity 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 an entity management configuration having a hierarchical tree structure in the information processing system of the present invention.

FIG. 42 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. 43 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. 44 is a diagram illustrating capability notification processing at the time of registration of a new entity 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 Entity 2702 Subroot 2811,2851 Subroot 2812,2852 Entity terminal node 2901,2902 Entity 2950 Reserve node 2970 Management terminal node 3011, 3012,3013 Entity 3021,3022,3023 Reserve node 3201 Terminal node 3201 Vertex node 330 , 3302 terminal node 3303 new entity added terminal node 3410, 3420, 3430 entity 3411, 3421, 3431 sub root 3432 revoked device node 3601 terminal node 3710, 3720, 3730 entity 3711, 3721, 3731 sub root 3901 terminal node 3902 Point node (sub root node) from 4,001 to 4,005 entity 4021,4022,4023 entity 4101 to 4105 entity

──────────────────────────────────────────────────の Continued on the front page (51) Int.Cl. ⁷ Identification symbol FI Theme coat ゛ (Reference) // H04N 7/167 H04L 9/00 601E H04N 7/167 Z (72) Inventor Yoshitomo Osawa Shinagawa, Tokyo 6-7-35 Kita-Shinagawa-ku, Sony Corporation (72) Inventor Tomoyuki Asano 6-7-35 Kita-Shinagawa, Shinagawa-ku, Tokyo Sony Corporation F-term (reference) 5B017 AA03 BA07 CA15 CA16 5B076 FA15 5B082 EA01 EA11 GA11 5C064 CA18 CB05 CB08 CC02 5J104 AA16 EA07 EA18 MA05 NA02 NA03

Claims (19)

[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 encryption key block that is selected to perform an update of a key on a selected path and an encryption process of an upper key by a lower key to generate an enabling key block (EKB) that can be decrypted only by a specific device and to provide to the device. In the information processing system used, a sub-tree as a partial tree constituting the key tree is managed, and a sub-validation key block (sub-EKB) based only on a key set corresponding to a node or leaf belonging to the sub-tree is managed. A plurality of entities to be generated, and a sub-activation key block (service) generated by the plurality of entities. EKB) using only decodable enabling key block in the entity that is selected (EKB)
An information processing system using an encryption key block, comprising: a key issuing center (KDC) for generating a key generation center; 2. The plurality of entities have a hierarchical structure of an upper entity and a lower entity in which a lowermost terminal node of one entity is configured as a vertex node (sub root) of another entity. Item 2. An information processing system using the encryption key block according to Item 1. 3. The apparatus according to claim 1, wherein each of the plurality of entities has a setting and update processing authority for a key corresponding to a node or a leaf constituting a subtree belonging to the own entity. Information processing system using the encryption key block. 4. A device belonging to a lowermost entity, wherein the lowermost leaf in the entity is a leaf corresponding to an individual device among the plurality of entities,
The vertex node (subroot) of the entity to which it belongs
The information processing system according to claim 1, wherein the information processing system has a configuration in which a node on a path from a device to a leaf corresponding to its own device, a node key set in the leaf, and a leaf key are stored. 5. Each of the plurality of entities reserves one or more nodes or leaves in the lowest node or leaf in its own entity in order to further add a self-managed entity below its own entity. The information processing system using an encryption key block according to claim 1, wherein the information processing system has a configuration that is set to be reserved as a node. 6. An upper entity that adds a new entity to a terminal node sets a key corresponding to an upper entity terminal node that is a node for setting a subtree of the new entity as a vertex node (sub root) key of the new entity. An information processing system using an encryption key block according to claim 1, wherein the information processing system has a configuration. 7. The newly added entity generates a sub-validated key block (sub-EKB) based only on a key set corresponding to a node or a leaf in a sub-tree in the new entity, and generates the key issuing center (sub-EKB). 2. The information processing system according to claim 1, wherein registration processing of a sub-EKB with respect to a KDC is performed. 8. An entity for executing a device revoke process is a vertex node (sub root) in the entity.
Updates a node key set in a node on a path from a to a leaf corresponding to a revoked device, and configures the updated node key as an encryption key that can be decrypted only in a leaf device other than the revoked device.
B, which is transmitted to the higher-level entity. The higher-level entity generates an updated sub-EKB obtained by updating the node key on the path from the terminal node that provided the updated sub-EKB to its own sub-root, and transmits the updated sub-EKB to the higher-level entity.
The update sub-EKB generation and transmission process are sequentially executed in entity units up to the highest entity to update the node key on the path from the revoke device to the root, and the key issuing center of the update sub-EKB generated by the key update 2. The information processing system according to claim 1, wherein the system performs a revocation process of the device by performing a registration process to the (KDC). 9. An entity for executing a revoke process of a lower entity is an update sub-EKB in which a node key set in a node on a path from a vertex node (sub root) in the entity to a terminal node corresponding to the revoke entity is updated. Is generated and transmitted to the higher-level entity. The higher-level entity generates an updated sub-EKB obtained by updating the node key on the path from the terminal node that has provided the updated sub-EKB to its own subroot, and transmits the updated sub-EKB to the higher-level entity. Until the entity, the update sub-EKB generation and transmission process are sequentially executed in entity units to update the node key on the path from the revoke entity to the root, and the key issuance center of the update sub-EKB generated by the key update ( KDC)
2. The information processing system using an encryption key block according to claim 1, further comprising a configuration for executing a revoke process for each entity by performing a registration process for the entity. 10. An entity for executing a revoke process of a lower entity is a node key set on a path from a vertex node (sub root) in the entity to a terminal node corresponding to the revoke entity, excluding the terminal node. Is generated and transmitted to the higher-level entity. The higher-level entity generates an updated sub-EKB in which a node key on a path from the terminal node that has provided the updated sub-EKB to its own sub-root is updated, and further generates a higher-level entity. , And sequentially executes the update sub-EKB generation and transmission processing in entity units up to the highest entity, and updates the node key except for the terminal node corresponding to the revoked entity on the path from the revoked entity to the root. ,
2. The encryption key according to claim 1, wherein the renewal process is performed by registering an updated sub-EKB generated by the key update with the key issuing center (KDC), thereby executing a revocation process in entity units. Information processing system using blocks. 11. The encryption key block according to claim 1, wherein the entity is configured as a device belonging to a common category such as a device type, a service type, and a management means type or a management entity of the entity. Information processing system used. 12. A key tree in which keys are respectively associated with roots, nodes, and leaves 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. In an information processing system, a selected key is updated on a selected path and an upper key is encrypted by a lower key to generate an enabling key block (EKB) that can be decrypted only by a specific device and provide the device to the device. In an information processing method using an encryption key block, in a plurality of entities for managing a subtree as a partial tree constituting the key tree, a sub-validation based only on a key set corresponding to a node or leaf belonging to the subtree Key block (sub EKB)
Generating a sub-activation key block (sub-EK) for generating the plurality of entities in a key issuing center (KDC).
Generating an enabling key block (EKB) that can be decrypted only in the selected entity using B). An information processing method using an encryption key block. 13. The information processing method, wherein each of the plurality of entities performs a key setting and updating process corresponding to a node or a leaf constituting a subtree belonging to the own entity. An information processing method using the encryption key block according to claim 12. 14. An upper entity that adds a new entity to a terminal node sets a key corresponding to the upper entity terminal node that is a node for setting a subtree of the new entity as a vertex node (subroot) key of the new entity. 13. The information processing method using an encryption key block according to claim 12, wherein: 15. The new additional entity generates a sub-validated key block (sub-EKB) based only on keys set corresponding to nodes or leaves in a subtree in the new entity, and 13. The information processing method using an encryption key block according to claim 12, wherein a sub-EKB registration process is performed for the KDC. 16. An entity that executes a device revocation process updates a node key set on a node on a path from a vertex node (sub root) in the entity to a leaf corresponding to the revocation device, and revokes the updated node key. An updated sub-EKB configured as an encryption key that can be decrypted only by a leaf device other than the device is generated and transmitted to the upper entity, and the upper entity is a node key on a path from the terminal node that provided the updated sub-EKB to its own subroot. Is generated and transmitted to the higher-level entity, and the update sub-EKB is generated and transmitted in entity units up to the highest-level entity, and the node key is updated on the path from the revoke device to the root. And update the key 13. The information processing using an encryption key block according to claim 12, wherein a revoking process of the device is performed by performing a registration process of the generated update sub-EKB with the key issuing center (KDC). Method. 17. An entity for executing a revoke process of a lower entity is an update sub-EKB in which a node key set in a node on a path from a vertex node (sub root) in the entity to a terminal node corresponding to the revoke entity is updated. Is generated and transmitted to the higher-level entity. The higher-level entity generates an updated sub-EKB obtained by updating the node key on the path from the terminal node that has provided the updated sub-EKB to its own subroot, and transmits the updated sub-EKB to the higher-level entity. Until the entity, the update sub-EKB generation and transmission process are sequentially executed in entity units to update the node key on the path from the revoke entity to the root, and the key issuance center of the update sub-EKB generated by the key update ( KD
2. A revoke process for each entity is performed by performing a registration process in C).
2. An information processing method using the encryption key block according to 2. 18. An entity for executing a revoke process of a lower entity is a node key set on a path from a vertex node (sub root) in the entity to a terminal node corresponding to the revoke entity, excluding the terminal node. Is generated and transmitted to the higher-level entity. The higher-level entity generates an updated sub-EKB in which a node key on a path from the terminal node that has provided the updated sub-EKB to its own sub-root is updated, and further generates a higher-level entity. , And sequentially executes the update sub-EKB generation and transmission processing in entity units up to the highest entity, and updates the node key except for the terminal node corresponding to the revoked entity on the path from the revoked entity to the root. ,
13. The encryption key block according to claim 12, wherein a revocation process is performed for each entity by performing a registration process of the updated sub-EKB generated by the key update with the key issuing center (KDC). Information processing method. 19. A key tree in which keys are respectively associated with roots, nodes, and leaves 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. In an information processing system, a selected key is updated on a selected path and an upper key is encrypted by a lower key to generate an enabling key block (EKB) that can be decrypted only by a specific device and provide the device to the device. A program providing medium for providing a computer program for causing an activation key block (EKB) generation process to be executed on a computer system, wherein the computer program manages a subtree as a partial tree forming the key tree. A node belonging to the subtree in a plurality of entities Or a sub-validated key block (sub-EKB) based only on the key set corresponding to the leaf
Generating a sub-activation key block (sub-EK) for generating the plurality of entities in a key issuing center (KDC).
Generating an enabling key block (EKB) that can be decrypted only in the selected entity using B).