JP4120135B2 - Information processing system and information processing method using encryption key block, and program providing medium - Google Patents

Description

[0001]
BACKGROUND OF THE INVENTION
The present invention relates to an information processing system and 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 method, the amount of messages can be kept small, for example, the load of data distribution during content key distribution or various key updates can be reduced, and data security can be maintained. Information processing system and information using encryption key block that realizes efficient key distribution and management configuration as a configuration for managing hierarchical key distribution tree with entities as subsets having common elements The present invention relates to a processing method and a program providing medium.
[0002]
[Prior art]
Nowadays, various software data (hereinafter referred to as “Content”) such as game programs, audio data, image data, etc. are transmitted via a network such as the Internet or a storage medium such as a DVD or CD. The circulation of is becoming popular. These distribution contents are reproduced by receiving data by a user's own PC (Personal Computer) or game device, or by attaching a storage medium, or recording devices in a recording / reproduction device attached to the PC, for example, It is stored in a memory card, hard disk, etc., and used by new reproduction from the storage medium.
[0003]
Information devices such as video game machines and PCs have interfaces for receiving distribution content from the network or accessing DVDs, CDs, etc., and further, control means, programs, data required for content playback RAM, ROM, etc. used as the memory area.
[0004]
Various contents such as music data, image data, or programs are stored in accordance with a user instruction from a game device used as a playback device, an information device main body such as a PC, or a user instruction via a connected input means. And is played through the information device main body or a connected display, speaker, or the like.
[0005]
Many software contents such as game programs, music data, and image data generally have distribution rights and the like for their creators and sellers. Therefore, when distributing these contents, certain usage restrictions, that is, license the use of software only to authorized users and prevent unauthorized copying, etc. It is common to take this configuration.
[0006]
One technique for realizing usage restrictions on users is encryption processing of distributed content. That is, for example, various contents such as encrypted audio data, image data, and game programs are distributed via the Internet, etc., and the encrypted contents distributed only to those who are confirmed to be authorized users. The decryption means, that is, a decryption key is assigned.
[0007]
The encrypted data can be returned to the decrypted data (plain text) that can be used by the decryption process according to a predetermined procedure. Data encryption and decryption methods that use an encryption key for such information encryption processing and a decryption key for decryption processing are well known.
[0008]
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, the encryption key used for the data encryption process and the decryption key used for the data decryption are made common, and the common key used for the encryption process and the decryption is given to an authorized user. Thus, data access by an unauthorized user who does not have a key is eliminated. A typical method of this method is DES (Data Encryption Standard).
[0009]
The encryption key and decryption key used for the above-described encryption processing and decryption can be obtained by applying a one-way function such as a hash function based on a certain password, for example. 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 using a password determined by the user as an input, and an encryption key and a decryption key are generated based on the output. From the encryption key and the decryption key obtained in this way, it is virtually impossible to obtain the password that is the original data.
[0010]
In addition, a method in which processing using an encryption key used for encryption and processing of a decryption key used for decryption are different algorithms is a so-called public key encryption method. The public key encryption method uses a public key that can be used by an unspecified user, and encrypts an encrypted document for a specific individual using the public key issued by the specific individual. A document encrypted with a public key can be decrypted only with a secret key corresponding to the public key used for the encryption process. 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 who has the private key. A typical public key encryption method is RSA (Rivest-Shamir-Adleman) encryption. By using such an encryption method, a system that enables decryption of encrypted content only for authorized users is possible.
[0011]
[Problems to be solved by the invention]
In the content distribution system as described above, the content is encrypted and stored for a user on a network or a recording medium such as a DVD or CD, and the content key for decrypting the encrypted content is provided only to a legitimate user. Is often adopted. The content key for preventing unauthorized copying of the content key itself is encrypted and provided to a legitimate user, and the content key can be used by decrypting the encrypted content key using the decryption key possessed only by the legitimate user A configuration has been proposed.
[0012]
In general, the determination as to whether or not the user is a valid user is performed, for example, by executing an authentication process between the content provider, which is the content sender, and the user device before distributing the content or the content key. In general authentication processing, the other party is confirmed and a session key that is valid only for the communication is generated. When authentication is established, data such as content or content key is generated using the generated session key. Encrypt communication. There are two authentication methods: mutual authentication using a common key encryption method and an authentication method using a public key method. However, authentication using a common key requires a system-wide common key, and update processing It is inconvenient in the case of. Further, in the public key method, the calculation load is large and the required memory amount is large, and it is not desirable to provide such processing means in each device.
[0013]
In the present invention, it is possible to securely transmit data only to legitimate users without relying on the mutual authentication process between the data sender and receiver as described above, and hierarchical key distribution. To provide 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 tree with an entity as a subset having a common element Objective.
[0014]
[Means for Solving the Problems]
  The first aspect of the present invention is:
  Configure a key tree by associating keys with the root, nodes, and leaves on the path from the root of the tree that configures multiple devices as leaves to the leaf, and select the path that configures the key tree and select it 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 executing upper key update processing and upper key encryption processing using a lower key In
  A subtree as a partial tree constituting the key treeAs an entity,Sub-enabling key block (sub-EKB) generation based only on the key set corresponding to the node or leaf to which it belongsSub-enabling key block generation means for executing as entity management processingWhen,
  SaidBy means of sub-activation key block generationUsing the generated sub-validation key block (sub-EKB),Selected device corresponding to the leaf of the lowest entity in the key treeAn enabling key block (EKB) that can be decrypted only inActivation key block generation meansWhen,
  There is an information processing system using an encryption key block.
[0015]
  Furthermore, in one embodiment of the information processing system of the present invention,RecordingThe entity is characterized by having a hierarchical structure of upper and lower entities in which the lowest end node of one entity is configured as a vertex node (sub-root) of another entity.
[0016]
  Furthermore, in one embodiment of the information processing system of the present invention,The sub-activation key block generation meansThe selfmanagementIt is characterized in that it has the authority to set and update keys corresponding to nodes or leaves constituting a subtree belonging to an entity.
[0017]
  Furthermore, in one embodiment of the information processing system of the present invention,RecordingDuring the entity, each of the devices belonging to the lowest entity in which the lowermost leaf in the entity is a leaf corresponding to each device reaches the leaf corresponding to the own device from the vertex node (sub-root) of the entity to which the entity belongs. It has a configuration in which a node key set on a leaf, a node key set on a leaf, and a leaf key are stored.
[0018]
  Furthermore, in one embodiment of the information processing system of the present invention,The sub-activation key block generation meansThe selfmanagementIn order to add a self-management entity further below the entity, it has a configuration in which one or more nodes or leaves in the lowermost node or leaf in the entity are reserved and set as reserve nodes. .
[0019]
  Furthermore, in one embodiment of the information processing system of the present invention, a higher entity that adds a new entity to a terminal nodeSub-enabling key block generation means for managingIs characterized in that a key corresponding to a higher entity end node which is a node for setting a new entity sub-tree is set as a vertex node (sub-root) key of the new entity.
[0020]
  Furthermore, in one embodiment of the information processing system of the present invention, a new additional entitySub-enabling key block generation means for managingGenerates a sub-enabling key block (sub-EKB) based only on keys set corresponding to nodes or leaves in the sub-tree in the new entity,Activation key block generation meansSub EKB againstOfferIt is the structure which performs a process.
[0021]
  Further, in one embodiment of the information processing system of the present invention, a device revocation process is executed.Sub-activation key block generation meansIsmanagementRevoked from a vertex node (subroot) in the entityKudeThe node key set in the node on the path to the leaf corresponding to the device is updated, and an updated sub-EKB configured with the updated node key as an encryption key that can be decrypted only by the leaf device other than the revoke device is generated and used as the upper entity. And the upper entity generates an updated sub-EKB in which the node key on the path from the terminal node that provided the updated sub-EKB to the sub-route of itself is updated, and further the upper entitySub-enabling key block generation means for managingTo the top-level entitySub-enabling key block generation means for managingUntil the entiteteIThe update sub-EKB generation and transmission processing in units is sequentially executed to update the node key on the path from the revoke device to the root, and the update sub-EKB generated by the key updateActivation key block generation meansToOfferIt is characterized by having a configuration for executing the revocation process of the device by performing the process.
[0022]
  Furthermore, in one embodiment of the information processing system of the present invention, the revocation process of the lower entity is executed.Sub-activation key block generation meansIsmanagementAn updated sub EKB in which the node key set in the node on the path from the vertex node (sub root) in the entity to the terminal node corresponding to the revocation entity is updated is generated and transmitted to the upper entity, and the upper entity is updated sub EKB. An updated sub-EKB is generated by updating the node key on the path from the terminal node that provides the sub-root to its own sub-root, and further higher entitySub-enabling key block generation means for managingTo the top-level entitySub-enabling key block generation means for managingUntil the entiteteIThe update sub-EKB generation and transmission process in units is sequentially executed to update the node key on the path from the revoke entity to the root, and the update sub-EKB generated by the key update is updated.Activation key block generation meansToOfferIt is characterized by having a configuration for executing revocation processing in units of entities by performing processing.
[0023]
  Furthermore, in one embodiment of the information processing system of the present invention, the revocation process of the lower entity is executed.Sub-activation key block generation meansIsmanagementA high-order entity is generated by generating an updated sub-EKB in which a node key set in a node other than the terminal node is updated on a path from the vertex node (sub-root) in the entity to the terminal node corresponding to the revocation entity.Sub-enabling key block generation means for managingTo the top entitySub-enabling key block generation means for managingGenerates an updated sub-EKB by updating the node key on the path from the terminal node that provided the updated sub-EKB to its own sub-root, and further adds a higher-level entity.Sub-enabling key block generation means for managingTo the top-level entitySub-enabling key block generation means for managingUntil the entiteteIThe update sub-EKB generated by the key update is performed by sequentially executing the update sub-EKB generation and transmission processing in units, and performing the node key update excluding the terminal node corresponding to the revocation entity on the path from the revocation entity to the route. Of the aboveActivation key block generation meansToOfferIt is characterized by having a configuration for executing revocation processing in units of entities by performing processing.
[0024]
  Furthermore, in one embodiment of the information processing system of the present invention,Sub-activation key block generation meansManagement of devices or entities belonging to a common category such as device type, service type, management method type, etc.It is the composition which performsIt is characterized by that.
Furthermore, in one embodiment of the information processing system of the present invention, the entity is classified based on capability information indicating a data processing capability of a device that is a leaf of the key tree, and the sub-validation key block generation means includes a management entity A sub enabling key block is generated based only on a key set corresponding to a node or leaf having a common capability belonging to.
Furthermore, in one embodiment of the information processing system of the present invention, the enabling key block generating means includes an identifier for each of a plurality of entities, capability information for each entity, and a sub-enabling key block (sub-EKB) for each entity. An enabling key block having a capability management table in which information is associated, selecting an entity that can process distribution data for a device based on the capability management table, and decrypting only by a device under the selected entity It has the structure which produces | generates (EKB).
Furthermore, in one embodiment of the information processing system of the present invention, the new additional entity for the key tree is a sub-validating key block based only on keys set corresponding to nodes or leaves in the sub-tree in the new entity. (Sub EKB) is generated, and the notification processing of the capability information of the generated sub EKB and its own entity to the enabling key block generation means is executed.
[0025]
  Furthermore, the second aspect of the present invention provides
  Configure a key tree in which a key is associated with each root, node, and leaf on the path from the root of the tree that configures multiple devices as leaves to the leaf, and select the path that configures the key tree and select it Using the encryption key block in the information processing system that executes the above key update and the encryption process of the upper key by the lower key to generate an enabling key block (EKB) that can be decrypted only by a specific device and provides it to the device In the information processing method that was
  The sub-activation key block generation meansA subtree as a partial tree constituting the key treeAs an entity and as an entity management processGenerating a sub-enabling key block (sub-EKB) based only on keys set corresponding to the node or leaf to which it belongs;
  Activation key block generation meansIn the aboveSub-activation key block generation meansUsing the sub-activation key block (sub-EKB) generated bySelected device corresponding to the leaf of the lowest entity in the key treeGenerating an enabling key block (EKB) decipherable only in
  There is an information processing method using an encryption key block.
[0026]
  Furthermore, in one embodiment of the information processing method of the present invention, in the information processing method,The sub-activation key block generation meansThe selfmanagementA key setting / updating process corresponding to a node or leaf constituting a subtree belonging to the entity is executed.
[0027]
  Furthermore, in one embodiment of the information processing method of the present invention, a higher entity that adds a new entity to a terminal nodeSub-enabling key block generation means for managingIs characterized in that a key corresponding to a higher entity end node, which is a node for setting a new entity sub-tree, is set as a vertex node (sub-root) key of the new entity.
[0028]
  Furthermore, in one embodiment of the information processing method of the present invention, a new additional entitySub-enabling key block generation means for managingGenerates a sub-enabling key block (sub-EKB) based only on keys set corresponding to nodes or leaves in the sub-tree in the new entity,Activation key block generation meansSub EKB againstOfferA process is executed.
[0029]
  Furthermore, in one embodiment of the information processing method of the present invention, a device revocation process is executed.Sub-activation key block generation meansIsmanagementRevoked from a vertex node (subroot) in the entityKudeThe node key set in the node on the path to the leaf corresponding to the device is updated, and an updated sub-EKB configured with the updated node key as an encryption key that can be decrypted only by the leaf device other than the revoke device is generated and used as the upper entity. And the upper entity generates an updated sub-EKB in which the node key on the path from the terminal node that provided the updated sub-EKB to the sub-route of itself is updated, and further the upper entitySub-enabling key block generation means for managingTo the top-level entitySub-enabling key block generation means for managingUntil the entiteteIThe update sub-EKB generation and transmission processing in units is sequentially executed to update the node key on the path from the revoke device to the root, and the update sub-EKB generated by the key updateActivation key block generation meansToOfferBy performing the process, a device revocation process is executed.
[0030]
  Furthermore, in one embodiment of the information processing method of the present invention, the revocation process of the lower entity is executed.Sub-activation key block generation meansGenerates an updated sub-EKB by updating the node key set in the node on the path from the vertex node (sub-root) in the entity to the terminal node corresponding to the revoke entity.Sub-enabling key block generation means for managingTo the top entitySub-enabling key block generation means for managingGenerates an updated sub-EKB by updating the node key on the path from the terminal node that provided the updated sub-EKB to its own sub-root, and further adds a higher-level entity.Sub-enabling key block generation means for managingTo the top-level entitySub-enabling key block generation means for managingUntil the entiteteIThe update sub-EKB generation and transmission process in units is sequentially executed to update the node key on the path from the revoke entity to the root, and the update sub-EKB generated by the key update is updated.Activation key block generation meansToOfferBy performing the process, the entity-based revocation process is executed.
[0031]
  Furthermore, in one embodiment of the information processing method of the present invention, the revocation process of the lower entity is executed.Sub-activation key block generation meansIsmanagementA high-order entity is generated by generating an updated sub-EKB in which a node key set in a node other than the terminal node is updated on a path from the vertex node (sub-root) in the entity to the terminal node corresponding to the revocation entity.Sub-enabling key block generation means for managingTo the top entitySub-enabling key block generation means for managingGenerates an updated sub-EKB by updating the node key on the path from the terminal node that provided the updated sub-EKB to its own sub-root, and further adds a higher-level entity.Sub-enabling key block generation means for managingTo the top-level entitySub-enabling key block generation means for managingUntil the entiteteIThe update sub-EKB generated by the key update is performed by sequentially executing the update sub-EKB generation and transmission processing in units, and performing the node key update excluding the terminal node corresponding to the revocation entity on the path from the revocation entity to the route. Of the aboveActivation key block generation meansToOfferBy performing the process, the entity-based revocation process is executed.
Furthermore, in one embodiment of the information processing method of the present invention, the entity is classified based on capability information indicating a data processing capability of a device that is a leaf of the key tree, and the sub-validation key block generation means includes a management entity A sub enabling key block is generated based only on a key set corresponding to a node or leaf having a common capability belonging to.
Furthermore, in an embodiment of the information processing method of the present invention, the enabling key block generating means includes an identifier for each of a plurality of entities, capability information for each entity, and a sub-enabling key block (sub-EKB) for each entity. An enabling key block having a capability management table in which information is associated, selecting an entity that can process distribution data for a device based on the capability management table, and decrypting only by a device under the selected entity (EKB) is generated.
Further, in an embodiment of the information processing method of the present invention, the new additional entity for the key tree is a sub-validating key block based only on keys set corresponding to nodes or leaves in the sub-tree in the new entity. (Sub-EKB) is generated, and notification processing of capability information of the generated sub-EKB and its own entity is executed with respect to the enabling key block generating means.
[0032]
  Furthermore, the third aspect of the present invention provides
  Configure a key tree in which a key is associated with each root, node, and leaf on the path from the root of the tree that configures multiple devices as leaves to the leaf, and select the path that configures the key tree and select it An activation key block in an information processing system that executes the above key update and the encryption process of the upper key by the lower key to generate an activation key block (EKB) that can be decrypted only by a specific device and provides the device to the device EKB) A computer program for executing generation processing on a computer systemRecordedprogramRecordA computer program comprising:
  In the sub-activation key block generation means,A subtree as a partial tree constituting the key treeAs an entity and as an entity management processGenerates a sub-activation key block (sub-EKB) based only on the key set corresponding to the node or leaf to which it belongsLetAnd steps
  Activation key block generation meansIn the aboveSub-activation key block generation meansUsing the sub-activation key block (sub-EKB) generated bySelected device corresponding to the leaf of the lowest entity in the key treeAn enabling key block (EKB) that can only be decrypted inLetAnd steps
  A program characterized by includingRecordIn the medium.
[0033]
[Action]
In the configuration of the present invention, the amount of distribution messages necessary for key update is kept small by using an encryption key distribution configuration having a hierarchical structure of a tree structure. That is, using a key distribution method in which each device is arranged on each leaf of the n-ary tree, for example, a content key that is an encryption key of content data or authentication used for authentication processing via a recording medium or a communication line A key, a program code, or the like is distributed together with an activation key block. In this way, data that can be decrypted only by a legitimate device can be delivered safely.
[0034]
Furthermore, in the configuration of the present invention, an efficient key distribution and management configuration is realized as a configuration in which a hierarchical key distribution tree is managed by an entity as a subset having common elements.
[0035]
The program providing medium according to the third aspect of the present invention is a medium that provides a computer program in a computer-readable format to, for example, a general-purpose computer system that can execute various program codes. The form of the medium is not particularly limited, such as a recording medium such as CD, FD, or MO, or a transmission medium such as a network.
[0036]
Such a program providing medium defines a structural or functional cooperative relationship between a computer program and a providing medium for realizing a function of a predetermined computer program on a computer system. . In other words, by installing a computer program in the computer system via the provided medium, a cooperative action is exhibited on the computer system, and the same effects as the other aspects of the present invention are obtained. Can do it.
[0037]
Other objects, features, and advantages of the present invention will become apparent from a more detailed description based on embodiments of the present invention described later and the accompanying drawings.
[0038]
DETAILED DESCRIPTION OF THE INVENTION
[System Overview]
FIG. 1 shows an example of a content distribution system to which the data processing system of the present invention can be applied. The content distribution side 10 encrypts and transmits the content or content key to various content reproducible devices of the content reception side 20. The device on the receiving side 20 decrypts the received encrypted content or the encrypted content key to acquire the content or content key, and reproduces image data, audio data, or executes various programs. Data exchange between the content distribution side 10 and the content reception side 20 is performed via a network such as the Internet or via a distributable storage medium such as a DVD or CD.
[0039]
The data distribution means on the content distribution side 10 includes the Internet 11, satellite broadcast 12, telephone line 13, media 14 such as DVD, CD, etc., while the device on the content reception side 20 is a personal computer (PC). 21, a portable device (PD) 22, a portable device 23 such as a mobile phone and a PDA (Personal Digital Assistants), a recording / reproducing device 24 such as a DVD or CD player, a dedicated reproduction device 25 such as a game terminal, and the like. Each device on the content receiving side 20 acquires the content provided from the content distribution side 10 from a communication means such as a network or the media 30.
[0040]
[Device configuration]
FIG. 2 shows a configuration block diagram of a recording / reproducing apparatus 100 as an example of a device on the content receiving side 20 shown in FIG. The recording / reproducing apparatus 100 includes an input / output I / F (Interface) 120, an MPEG (Moving Picture Experts Group) codec 130, an input / output I / F (Interface) 140 including an A / D and D / A converter 141, and encryption processing. Means 150, a ROM (Read Only Memory) 160, a CPU (Central Processing Unit) 170, a memory 180, and a drive 190 of a recording medium 195 are connected to each other by a bus 110.
[0041]
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, receives the digital signals on the bus 110, and externally receives them. Output. The MPEG codec 130 MPEG-decodes MPEG-encoded data supplied via the bus 110 and outputs it to the input / output I / F 140 and MPEG-encodes a digital signal supplied from the input / output I / F 140. Output on the bus 110. The input / output I / F 140 includes an A / D and D / A converter 141. The input / output I / F 140 receives an analog signal as content supplied from the outside and performs A / D (Analog Digital) conversion by the A / D and D / A converter 141, thereby converting the MPEG codec 130 as a digital signal. In addition, the digital signal from the MPEG codec 130 is D / A (Digital Analog) converted by the A / D and D / A converter 141 to be output to the outside as an analog signal.
[0042]
The cryptographic processing means 150 is composed of, for example, a one-chip LSI (Large Scale Integrated Circuit), executes encryption, decryption processing, or authentication processing of a digital signal as content supplied via the bus 110, and performs encryption processing. Data, decoded data, etc. are output on the bus 110. The cryptographic processing means 150 is not limited to a one-chip LSI, and can be realized by a configuration combining various types of software or hardware. The configuration as the processing means by the software configuration will be described later.
[0043]
The ROM 160 stores program data processed by the recording / reproducing apparatus. The CPU 170 controls the MPEG codec 130, the encryption processing means 150, and the like 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 / reproducing digital data, thereby reading (reproducing) the digital data from the recording medium 195, outputting it on the bus 110, and supplying the digital data via the bus 110. Data is supplied to the recording medium 195 and recorded.
[0044]
The recording medium 195 is a medium capable of storing digital data, such as an optical disk such as a DVD or CD, a magneto-optical disk, a magnetic disk, a magnetic tape, or a semiconductor memory such as a RAM. In this embodiment, the recording medium 195 is a drive 190. Suppose that it is the structure which can be attached or detached with respect to. However, the recording medium 195 may be built in the recording / reproducing apparatus 100.
[0045]
Note that the cryptographic processing means 150 shown in FIG. 2 may be configured as a single one-chip LSI, or may be configured by a combination of software and hardware.
[0046]
[About tree structure as key distribution configuration]
Next, an encryption processing key holding configuration and a data distribution configuration in each device when distributing encrypted data from the content distribution side 10 to each device on the content reception side 20 shown in FIG. 1 will be described with reference to FIG.
[0047]
Numbers 0 to 15 shown at the bottom of FIG. 3 are individual devices on the content receiving side 20. That is, each leaf (leaf) of the hierarchical tree (tree) structure shown in FIG. 3 corresponds to each device.
[0048]
Each device 0 to 15 is a key (node key) assigned to a node from its own leaf to the root in the hierarchical tree (tree) structure shown in FIG. The key set consisting of the leaf keys is stored in the memory. K0000 to K1111 shown at the bottom in FIG. 3 are leaf keys assigned to the devices 0 to 15, respectively, and the keys described in the second clause (node) from the bottom to the top KR (root key). : KR to K111 are used as node keys.
[0049]
In the tree configuration shown in FIG. 3, for example, the device 0 has a leaf key K0000 and node keys: K000, K00, K0, and KR. The device 5 owns K0101, K010, K01, K0, and KR. The device 15 owns K1111, K111, K11, K1, and KR. In the tree of FIG. 3, only 16 devices of 0 to 15 are described, and the tree structure is shown as a balanced configuration with a four-stage configuration, but more devices are configured in the tree. In addition, it is possible to have a different number of stages in each part of the tree.
[0050]
In addition, each device included in the tree structure of FIG. 3 includes various types of recording media, such as various types using a device embedded type or a DVD, CD, MD, flash memory, etc. that are configured to be detachable from the device. The device is included. Furthermore, various application services can coexist. The hierarchical tree structure as the content or key distribution configuration shown in FIG. 3 is applied on the coexistence configuration of different devices and different applications.
[0051]
In a system in which these various devices and applications coexist, for example, the 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, the common content is encrypted and sent from the provider, the content key used in common for each device is sent, or each device is sent. Then, the process of encrypting and outputting the content fee payment data to the provider or the settlement institution is executed. An institution that performs data transmission / reception with each device, such as a content provider or a payment processing institution, sends data collectively as a group of the parts surrounded by the dotted lines in FIG. 3, that is, devices 0, 1, 2, and 3. Execute the process. There are a plurality of such groups in the tree of FIG. An organization that transmits / receives data to / from each device, such as a content provider or a payment processing organization, functions as message data distribution means.
[0052]
The node key and leaf key may be managed by a single key management center, or may be managed for each group by a message data distribution means such as a provider or a settlement organization that performs various data transmission / reception for each group. It is good. These node keys and leaf keys are updated when, for example, a key is leaked, and this updating process is executed by a key management center, a provider, a settlement organization, or the like.
[0053]
In this tree structure, as is apparent from FIG. 3, the three devices 0, 1, 2, 3 included in one group have common keys K00, K0, KR as node keys. 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 common node key K00 itself is set as the content key, only the devices 0, 1, 2, and 3 can set the common content key without executing new key transmission. Further, if the value Enc (K00, Kcon) obtained by encrypting the new content key Kcon with the node key K00 is stored in a recording medium via a network or distributed to the devices 0, 1, 2, 3, the device 0, Only 1, 2, 3 can use the shared node key K00 possessed by each device to break the encryption Enc (K00, Kcon) and obtain the content key: Kcon. Enc (Ka, Kb) indicates data obtained by encrypting Kb with Ka.
[0054]
Further, at a certain time t, when it is discovered that the keys possessed by the device 3: K0011, K001, K00, K0, KR are analyzed and exposed by an attacker (hacker), thereafter, the system (devices 0, 1) is detected. , 2 and 3), the device 3 needs to be disconnected from the system. For this purpose, the node keys: K001, K00, K0, KR are updated to new keys K (t) 001, K (t) 00, K (t) 0, K (t) R, respectively, and devices 0, 1, 2 must be notified of the update key. Here, K (t) aaa indicates that the key is a renewal key of Generation: t.
[0055]
The update key distribution process will be described. The key is updated by, for example, storing a table composed of block data called an enabling key block (EKB) shown in FIG. 2 is executed. The enabling key block (EKB) is composed of an encryption key for distributing a newly updated key to devices corresponding to each leaf constituting the tree structure as shown in FIG. The enabling key block (EKB) is sometimes called a key renewal block (KRB).
[0056]
The enabling key block (EKB) shown in FIG. 4A is configured as block data having a data configuration 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 generation t update node keys in the devices 0, 1, and 2 in the tree structure shown in FIG. As is apparent from FIG. 3, device 0 and device 1 require K (t) 00, K (t) 0, and K (t) R as update node keys, and device 2 uses K (t) as an update node key. ) 001, K (t) 00, K (t) 0, K (t) R are required.
[0057]
As shown in the EKB in FIG. 4A, the EKB includes a plurality of encryption keys. The lowest encryption key is Enc (K0010, K (t) 001). This is an update node key K (t) 001 encrypted with the leaf key K0010 of the device 2, and the device 2 can decrypt this encryption key with the leaf key of itself and obtain K (t) 001. . In addition, by using K (t) 001 obtained by decryption, the encryption key Enc (K (t) 001, K (t) 00) in the second stage from the bottom of FIG. 4A can be decrypted and updated. The node key K (t) 00 can be obtained. Subsequently, the encryption key Enc (K (t) 00, K (t) 0) in the second stage from the top in FIG. 4A is sequentially decrypted, and the update node key K (t) 0, as shown in FIG. The first-stage encryption key Enc (K (t) 0, K (t) R) is decrypted to obtain K (t) R. On the other hand, the device K0000. K0001 is not included in the node key K000 to be updated, and K (t) 00, K (t) 0, and K (t) R are required as update node keys. Device K0000. K0001 decrypts the third-stage encryption key Enc (K000, K (t) 00) from the top of FIG. 4A to obtain K (t) 00. The second-stage encryption key Enc (K (t) 00, K (t) 0) is decrypted from the update node key K (t) 0, and the first-stage encryption key Enc from the top in FIG. (K (t) 0, K (t) R) is decoded to obtain K (t) R. In this way, the devices 0, 1, and 2 can obtain updated keys K (t) 001, K (t) 00, K (t) 0, and K (t) R. The index in FIG. 4A indicates the absolute address of the node key and leaf key used as the decryption key.
[0058]
When it is not necessary to update the node keys: K (t) 0, K (t) R in the upper level of the tree structure shown in FIG. 3, and only the node key K00 needs to be updated, the processing shown in FIG. By using the enabling key block (EKB), the updated node key K (t) 00 can be distributed to the devices 0, 1, and 2.
[0059]
The EKB shown in FIG. 4B can be used, for example, when distributing a new content key shared in a specific group. As a specific example, it is assumed that a recording medium having devices 0, 1, 2, and 3 in a group indicated by a dotted line in FIG. 3 is used and a new common content key K (t) con is required. At this time, the data Enc (K (t (K)) is obtained by encrypting a new common updated content key: K (t) con using K (t) 00 that has updated the common node key K00 of the devices 0, 1, 2, and 3. ), K (t) con) is distributed together with the EKB shown in FIG. This distribution enables distribution as data that is not decrypted in other groups of devices such as the device 4.
[0060]
That is, the devices 0, 1, and 2 can obtain the content key K (t) con at time point t by decrypting the ciphertext using K (t) 00 obtained by processing the EKB. .
[0061]
[Distribution of content key using EKB]
In FIG. 5, as an example of processing for obtaining the content key K (t) con at time t, data Enc (K (t (t)) obtained by encrypting a new common content key K (t) con using K (t) 00 ) 00, K (t) con) and the EKB shown in FIG. 4B via the recording medium. That is, this is an example in which the encrypted message data by EKB is used as the content key K (t) con.
[0062]
As shown in FIG. 5, the device 0 uses the EKB at the time of generation: t stored in the recording medium and the node key K000 stored in advance by the EKB process similar to the above to perform the node key K (t ) 00 is generated. Further, the update content key K (t) con is decrypted using the decrypted update node key K (t) 00, and is encrypted and stored with the leaf key K0000 that only the user has in order to use it later.
[0063]
[EKB format]
FIG. 6 shows a format example of the enabling key block (EKB). The version 601 is an identifier indicating the version of the enabling key block (EKB). Note that the version has a function for identifying the latest EKB and a function for indicating a correspondence relationship between contents. The depth indicates the number of hierarchies of the hierarchical tree for the device to which the enabling key block (EKB) is distributed. The data pointer 603 is a pointer indicating the position of the data part in the enabling key block (EKB), the tag pointer 604 is the position of the tag part, and the signature pointer 605 is a pointer indicating the position of the signature.
[0064]
The data unit 606 stores, for example, data obtained by encrypting the node key to be updated. For example, each encryption key related to the updated node key as shown in FIG. 5 is stored.
[0065]
The tag part 607 is a tag indicating the positional relationship between the encrypted node key and leaf key stored in the data part. The 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 the table (b) of FIG. The top node address 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 uppermost data Enc (K (t) 0, K (t) R) is at the position shown in the hierarchical tree shown in FIG. Here, the next data is Enc (K (t) 00, K (t) 0), and is in the lower left position of the previous data on the tree. When there is data, the tag is set to 0, and when there is no data, 1 is set. The tags are set as {left (L) tag, right (R) tag}. Since there is data on the left of the uppermost data Enc (K (t) 0, K (t) R), L tag = 0, and there is no data on the right, so R tag = 1. Hereinafter, tags are set for all data, and the data string and tag string shown in FIG. 7C are configured.
[0066]
The tag is set to indicate where the data Enc (Kxxx, Kyyy) is located in the tree structure. Key data Enc (Kxxx, Kyyy) stored in the data part. . . Is merely enumerated data of encrypted keys, so that the position of the encryption key stored as data on the tree can be determined by the above-described tag. Without using the above-described tag, using a node index corresponding to encrypted data as in the configuration described in FIG. 4, 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)
. . . However, if such a configuration using an index is used, redundant data is generated and the amount of data increases, which is not preferable for distribution via 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 amount of data.
[0067]
Returning to FIG. 6, the EKB format will be further described. The signature (Signature) is an electronic signature executed by, for example, a key management center, a content provider, a settlement organization, or the like that has issued an enabling key block (EKB). The device that has received the EKB confirms by the signature verification that it is an activation key block (EKB) issued by a valid activation key block (EKB) issuer.
[0068]
[Content key and content distribution using EKB]
In the above-described example, the example in which only the content key is sent together with the EKB has been described. However, the content key encrypted with the content key, the content key encrypted with the content key encryption key, and the content key encryption key encrypted with the EKB are described. The configuration to be sent together will be described below.
[0069]
FIG. 8 shows this data structure. In the configuration shown in FIG. 8A, Enc (Kcon, content) 801 is data obtained by encrypting content with a content key (Kcon), and Enc (KEK, Kcon) 802 is content key (Kcon). ) Is encrypted with a content key encryption key (KEK), and Enc (EKB, KEK) 803 is data obtained by encrypting the content key encryption key KEK with an enabling key block (EKB). It shows that.
[0070]
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 node key (K000, K00...) Or the root key (KR). It may be a key encrypted by.
[0071]
FIG. 8B shows a configuration example in which a plurality of contents are recorded on a medium and each uses the same Enc (EKB, KEK) 805. In such a configuration, the same Enc is used for each data. Without adding (EKB, KEK), data indicating a link destination linked to Enc (EKB, KEK) can be added to each data.
[0072]
FIG. 9 shows an example in which the content key encryption key KEK is configured as an updated node key K (t) 00 obtained by updating the node key K00 shown in FIG. In this case, assuming that the device 3 is revoked (excluded) due to key leakage in the group surrounded by the dotted frame in FIG. (A) an enabling key block (EKB), (b) data obtained by encrypting a content key (Kcon) with a content key encryption key (KEK = K (t) 00), and (c) content (content) By distributing the data encrypted with the content key (Kcon), the devices 0, 1, and 2 can obtain the content.
[0073]
The right side of FIG. 9 shows a decoding procedure in the device 0. The device 0 first obtains the content key encryption key (KEK = K (t) 00) from the received activation key block by the decryption process using the leaf key K000 held by the device 0. Next, the content key Kcon is obtained by decryption with K (t) 00, and the content is decrypted with the content key Kcon. With these processes, the device 0 can use the content. The devices 1 and 2 can acquire the content key encryption key (KEK = K (t) 00) by processing the EKB according to different processing procedures, and can use the content in the same manner. .
[0074]
Even if the devices 4, 5, 6... Shown in FIG. 3 receive this similar data (EKB), the content key encryption key (KEK = K (t ) 00) cannot be obtained. Similarly, even in the revoked device 3, the content key encryption key (KEK = K (t) 00) cannot be obtained with the leaf key and node key held by itself, and only the device having a legitimate right can obtain the content. It can be used after being decrypted.
[0075]
In this way, if content key delivery using EKB is used, it is possible to distribute encrypted content that can be decrypted only by the rightful owner safely while reducing the amount of data.
[0076]
The enabling key block (EKB), the content key, the encrypted content, etc. can be safely distributed via the network. However, the enabling key block (EKB), the content key, the encrypted content, etc. Can be stored in a recording medium such as a DVD or CD and provided to the user. In this case, if the content key obtained by decrypting the enabling key block (EKB) stored in the same recording medium is used for decryption of the encrypted content stored in the recording medium, it is valid in advance. Distribution processing of encrypted content that can be used only by the leaf key and node key held only by the right holder, that is, content distribution limited to available user devices can be realized with a simple configuration.
[0077]
FIG. 10 shows a configuration example in which an enabling key block (EKB) is stored in the recording medium together with the encrypted content. In the example shown in FIG. 10, the contents C1 to C4 are stored in the recording medium, the data in which the activation key block (EKB) corresponding to each stored content is associated, and the version M activation key is further stored. A block (EKB_M) is stored. For example, EKB_1 is used to generate a content key Kcon1 obtained by encrypting the content C1, and 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), so the activation key block (EKB_M) Thus, the content keys of the contents C3 and C4 can be acquired. Since EKB_1 and EKB_2 are not stored on the disc, it is necessary to acquire EKB_1 and EKB_2 necessary for decrypting the respective content keys by new providing means, for example, network distribution or distribution by a recording medium.
[0078]
FIG. 11 shows a comparative example of content key distribution using EKB and conventional content key distribution processing when content keys are distributed among a plurality of devices. The upper stage (a) is a conventional configuration, and the lower stage (b) is an example using the enabling key block (EKB) of the present invention. In FIG. 11, Ka (Kb) indicates data obtained by encrypting Kb with Ka.
[0079]
Conventionally, as shown in (a), authentication processing and key exchange processing are performed between devices in order to confirm the legitimacy of a data sender and to share a session key Kses used for data transmission encryption processing. (AKE: Authentication and Key Exchange) is executed, and the content key Kcon is encrypted and transmitted with the session key Kses under the condition that the authentication is established.
[0080]
For example, in the PC of FIG. 11A, the content key Kses (Kcon) encrypted with the received session key can be decrypted with the session key to obtain Kcon, and the acquired Kcon is held by the PC itself. It is possible to encrypt the data with the storage key Kstr and store it in its own memory.
[0081]
In FIG. 11 (a), even if the content provider wants to distribute data only to the recording device 1101 in FIG. 11 (a) in a form that can be used, ), An authentication process is executed, and a process of encrypting and distributing the content key with each session key is required. In addition, the content key can be acquired by decrypting the encrypted content key by using the session key generated and shared in the authentication process also in the intervening PC and playback device.
[0082]
On the other hand, in the example using the enabling key block (EKB) shown in the lower part of FIG. 11B, the enabling key block (EKB) and the node key obtained by the processing of the enabling key block (EKB) from the content provider. Or by decrypting and acquiring the content key Kcon only in a device capable of processing the distributed EKB by distributing data (Kroot (Kcon) in the example of the figure) obtained by encrypting the content key Kcon with the root key Is possible.
[0083]
Therefore, for example, an enabling key block (EKB) that can be used only at the right end of FIG. 11B is generated, and the contents are obtained by the enabling key block (EKB) and the node key or root key obtained by the EKB processing. By sending together the encrypted data of the key Kcon, PCs, playback devices, etc. existing between them cannot execute EKB processing depending on their own leaf keys and node keys. Therefore, a content key that can be safely used only for legitimate devices can be distributed without executing processing such as authentication processing between data transmitting / receiving devices, session key generation, and content key Kcon encryption processing using the session key. It becomes possible to do.
[0084]
If you want to distribute content keys that can also be used for PCs and recording / reproducing devices, you can acquire a common content key by generating and distributing an enabling key block (EKB) that can be processed by each. It becomes.
[0085]
[Distribution of authentication key using activation key block (EKB) (common key method)]
In the distribution of data or key using the above-described enabling key block (EKB), the enabling key block (EKB) and the content or content key transferred between devices always maintain the same encryption form. An illegal copy may be generated by a so-called replay attack in which the data transmission path is stolen and recorded, and then transferred again later. In order to prevent this, it is an effective means to execute authentication processing and key exchange processing similar to those in the past between data transfer devices. Here, the authentication key Kake used when executing the authentication process and the key exchange process is distributed to the device using the above-described activation key block (EKB), thereby sharing the authentication key as a secure secret key. A configuration for performing authentication processing in accordance with the common key method will be described. In other words, this is an example in which encrypted message data by EKB is used as an authentication key.
[0086]
FIG. 12 shows a mutual authentication method (ISO / IEC 9798-2) using a common key cryptosystem. In FIG. 12, DES is used as the common key encryption method, but other methods are possible as long as the common key encryption method is used. In FIG. 12, first, B generates a 64-bit random number Rb, and transmits Rb and its own ID (b) to A. Upon receiving this, A newly generates a 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 Ra are exclusive-ORed, and the DES encryption unit encrypts using the key Kab, A ciphertext E1 is generated, and the ciphertexts E1 and Rb are exclusive ORed together, and the DES encryption unit encrypts the ciphertext E2 using the key Kab, and further generates the ciphertext E2 and the ID. The transmission data (Token-AB) is generated from the ciphertext E3 generated by performing an exclusive OR with (b) and encrypting with the key Kab in the DES encryption unit.
[0087]
Upon receiving this, B decrypts the received data with a key Kab (authentication key) that is also stored in each recording element as a common secret key. As a method for decrypting received data, first, the ciphertext E1 is decrypted with the authentication key Kab to obtain the random number Ra. Next, the ciphertext E2 is decrypted with the authentication key Kab, and the result is exclusive-ORed with E1 to obtain Rb. Finally, the ciphertext E3 is decrypted with the authentication key Kab, and the result and E2 are exclusive ORed to obtain ID (b). Of Ra, Rb, and ID (b) obtained in this way, it is verified whether Rb and ID (b) match those transmitted by B. If this verification is passed, B authenticates A as valid.
[0088]
Next, B generates a session key (Kses) to be used after authentication (a random number is used as a generation method). Then, the data is encrypted using the authentication key Kab in the DES CBC mode in the order of Rb, Ra, and Kses, and returned to A.
[0089]
Upon receiving this, A decrypts the received data with the authentication key Kab. The method for decoding the received data is the same as the decoding process for B, so the details are omitted here. Of Rb, Ra, and Kses obtained in this way, it is verified whether Rb and Ra match those transmitted by A. If this verification is passed, A authenticates B as valid. After authenticating each other, the session key Kses is used as a common key for secret communication after authentication.
[0090]
In addition, when an illegality or a mismatch is found during the verification of the received data, the processing is interrupted on the assumption that mutual authentication has failed.
[0091]
In the above authentication process, A and B share a common authentication key Kab. This common key Kab is distributed to the device using the above-described enabling key block (EKB).
[0092]
For example, in the example of FIG. 12, the authentication key Kab is encrypted with the enabling key block (EKB) generated by generating the enabling key block (EKB) that either A or B can decrypt. It is good also as a structure which transmits to the other, or the 3rd party produces | generates the enabling key block (EKB) which both can use with respect to devices A and B, and the enabling key produced | generated with respect to devices A and B The authentication key Kab may be encrypted by a block (EKB) and distributed.
[0093]
FIG. 13 and FIG. 14 show configuration examples in which an authentication key Kake common to a plurality of devices is distributed by an enabling key block (EKB). FIG. 13 shows an example in which a decodable authentication key Kake is distributed to the devices 0, 1, 2, and 3. FIG. 14 shows a revocation (exclusion) of the device 3 in the devices 0, 1, 2, and 3, and the device 0, An example in which an authentication key that can be decrypted only for 1 and 2 is distributed will be shown.
[0094]
In the example of FIG. 13, the node key updated using the node key and leaf key of each of the devices 0, 1, 2, and 3 together with the data (b) obtained by encrypting the authentication key Kake with the updated node key K (t) 00. An enabling key block (EKB) that can decrypt K (t) 00 is generated and distributed. As shown on the right side of FIG. 13, each device first processes (decrypts) the EKB to obtain an updated node key K (t) 00, and then obtains the obtained node key K (t) 00. It becomes possible to obtain the authentication key Kake by decrypting the authentication key Enc (K (t) 00, Kake) encrypted by using the encrypted key.
[0095]
Even if the other devices 4, 5, 6, 7... Receive the same enabling key block (EKB), the node keys and leaf keys held by the other devices 4, EKB are processed and the updated node key K (t) 00 is used. Since the authentication key cannot be acquired, the authentication key can be sent only to a safe and legitimate device.
[0096]
On the other hand, in the example of FIG. 14, assuming that the device 3 is revoked (excluded) due to key leakage, for example, in the group surrounded by the dotted frame in FIG. , An enabling key block (EKB) that can be decrypted only is generated and distributed. The data obtained by encrypting (a) the enabling key block (EKB) and (b) the authentication key (Kake) with the node key (K (t) 00) shown in FIG. 14 is distributed.
[0097]
The decoding procedure is shown on the right side of FIG. The devices 0, 1, and 2 first obtain an updated node key (K (t) 00) from the received validation key block by a decryption process using the leaf key or node key held by the device. Next, an authentication key Kake is obtained by decryption with K (t) 00.
[0098]
Even if the devices 4, 5, 6,... Shown in FIG. 3 receive this similar data (EKB), the updated node key (K (t) 00) is obtained using the leaf key and node key held by itself. I can't get it. Similarly, the revoked device 3 cannot obtain the updated node key (K (t) 00) with its own leaf key and node key, and only a device having a legitimate right decrypts the authentication key. It can be used.
[0099]
As described above, if the authentication key delivery using the EKB is used, it is possible to reduce the amount of data and distribute the authentication key that can be safely decrypted only by the right holder.
[0100]
[Content key distribution using public key authentication and validation key block (EKB)]
Next, content key distribution processing using public key authentication and an enabling key block (EKB) will be described. First, a mutual authentication method using 160-bit elliptic curve cryptography, 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. 15, first, B generates a 64-bit random number Rb and transmits 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. Then, a point Av = Ak × G obtained by multiplying the base point G by Ak is obtained, and an electronic signature A.R. for Ra, Rb, Av (X coordinate and Y coordinate) is obtained. Sig is generated and returned to B along with A's public key certificate. Here, Ra and Rb are 64 bits each, and the X coordinate and Y coordinate of Av are 160 bits each, so that an electronic signature for a total of 448 bits is generated.
[0101]
A's public key certificate, Ra, Rb, Av, electronic signature B that received Sig verifies whether Rb transmitted by A matches that generated by B. As a result, if they match, the electronic signature in A's public key certificate is verified with the public key of the certificate authority, and A's public key is extracted. Then, the electronic signature A.A. Verify Sig.
[0102]
Next, B generates a random number Bk smaller than the prime number p. Then, a point Bv = Bk × G obtained by multiplying the base point G by Bk is obtained, and the electronic signature B.Rb, Ra, Bv (X coordinate and Y coordinate) is obtained. Sig is generated and returned to A along with B's public key certificate.
[0103]
B's public key certificate, Rb, Ra, Av, digital signature A who receives Sig verifies whether Ra transmitted by B 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 B public key extracted, the electronic signature B.B. Verify Sig. After successfully verifying the electronic signature, A authenticates B as legitimate.
[0104]
If both are successfully authenticated, B is calculated as Bk × Av (Bk is a random number, but Av is a point on the elliptic curve, so a scalar multiplication of the points on the elliptic curve is required) and A is Ak × Bv is calculated, and the lower 64 bits of the X coordinate of these points are used as a session key for subsequent communications (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, or may not be the lower 64 bits. In secret communication after mutual authentication, transmission data is not only encrypted with a session key, but an electronic signature may be attached.
[0105]
If invalidity or inconsistency is found during verification of the electronic signature or verification of the received data, the processing is interrupted assuming that mutual authentication has failed.
[0106]
FIG. 16 shows an example of content key distribution processing using public key authentication and an enabling key block (EKB). First, authentication processing by the public key method described with reference to FIG. 15 is executed between the content provider and the PC. The content provider generates a content key E (Kcon) that is decrypted with the updated node key by generating the 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 the activation key block (EKB) is encrypted with the session key Kses generated in the authentication process between the PCs and transmitted to the PC.
[0107]
The PC decrypts the content key E (Kcon) encrypted with the updated node key and the enabling key block (EKB) encrypted with the session key with the session key, and then transmits it to the playback device and recording medium .
[0108]
The playback device and the recording medium acquire the content key Kcon by decrypting [the content key E (Kcon) encrypted with the updated node key and the enabling key block (EKB)] using the node key or leaf key held by itself. To do.
[0109]
According to this configuration, since [content key E (Kcon) and encryption key block (EKB) that has been encrypted with an updated node key] is transmitted on the condition of authentication between the content provider and the PC, for example, Even if the node key is leaked, it is possible to transmit data to a reliable partner.
[0110]
[Delivery using program code validation key block (EKB)]
In the above-described example, the method of encrypting and distributing the content key, the authentication key, and the like using the enabling key block (EKB) has been described. However, various program codes are distributed using the enabling key block (EKB). Configuration 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.
[0111]
FIG. 17 shows an example in which a program code is encrypted between, for example, an update node key in an enabling key block (EKB) and transmitted between devices. The device 1701 transmits to the device 1702 the activation key block (EKB) that can be decrypted with the node key and leaf key of the device 1702, and the program code encrypted with the updated node key included in the activation key block (EKB). The device 1702 processes the received EKB to obtain an update node key, and further decrypts the program code using the obtained update node key to obtain a program code.
[0112]
In the example shown in FIG. 17, further, processing by the program code acquired in the device 1702 is executed, the result is returned to the device 1701, and the device 1701 further continues processing based on the result. Yes.
[0113]
By distributing the program code encrypted with the activation key block (EKB) and the update node key included in the activation key block (EKB) in this way, the program code that can be decrypted by a specific device is converted into the above-described FIG. It is possible to distribute to a specific device or group indicated by.
[0114]
[Configuration to correspond to the check value (ICV: Integrity Check Value) for transmitted content]
Next, a description will be given of a processing configuration for generating an integrity check value (ICV) of content in order to prevent content falsification, determining the presence / absence of content falsification by calculating the ICV in association with the content.
[0115]
The integrity check value (ICV) of the content is calculated using a hash function for the content, for example, and is calculated by ICV = hash (Kicv, C1, C2,...). Kicv is an ICV generation key. C1 and C2 are content information, and a message authentication code (MAC) of content important information is used.
[0116]
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 units of 8 bytes (hereinafter, the divided messages are referred to as M1, M2,..., MN). , IV)) and M1 are XORed (the result is I1). Next, I1 is put into the DES encryption unit and encrypted using a key (hereinafter referred to as K1) (the output is assumed to be E1). Subsequently, E1 and M2 are exclusively ORed, and the output I2 is input to the DES encryption unit and encrypted using the key K1 (output E2). Thereafter, this is repeated, and encryption processing is performed on all messages. The EN that comes out last is a message authentication code (MAC).
[0117]
A content integrity check value (ICV) is generated using a hash function applied to the MAC value and ICV generation key of the content. For example, if the same ICV is obtained by comparing an ICV generated at the time of content generation, which is guaranteed not to be falsified, with an ICV newly generated based on the content, it is guaranteed that the content will not be falsified. If they are different, it is determined that tampering has occurred.
[0118]
[Configuration for Distributing Check Value (ICV) Key Kicv via EKB]
Next, a configuration for sending Kicv, which is a content integrity check value (ICV) generation key, using the above-described activation key block will be described. That is, this is an example in which encrypted message data by EKB is used as a content integrity check value (ICV) generation key.
[0119]
19 and 20, when common contents are sent to a plurality of devices, an integrity check value generation key Kicv for verifying the presence / absence of falsification of these contents is delivered by an enabling key block (EKB). Indicates. FIG. 19 shows an example in which a decodable check value generation key Kicv is distributed to devices 0, 1, 2, and 3. FIG. 20 shows a device in which devices 3 in devices 0, 1, 2, and 3 are revoked (removed). An example is shown in which a check value generation key Kicv that can be decrypted only for 0, 1, and 2 is distributed.
[0120]
In the example of FIG. 19, the updated node key K (t) 00 is updated using the node key and leaf key of the devices 0, 1, 2, and 3 together with the data (b) obtained by encrypting the check value generation key Kicv. An enabling key block (EKB) that can decrypt the node key K (t) 00 is generated and distributed. As shown on the right side of FIG. 19, each device first processes (decrypts) the EKB to obtain an updated node key K (t) 00, and then obtains the obtained node key K (t) 00. The check value generation key Kicv can be obtained by decrypting the encrypted check value generation key: Enc (K (t) 00, Kicv).
[0121]
Even if the other devices 4, 5, 6, 7... Receive the same enabling key block (EKB), the node keys and leaf keys held by the other devices 4, EKB are processed and the updated node key K (t) 00 is used. Since it cannot be obtained, the check value generation key can be sent only to a safe and valid device.
[0122]
On the other hand, in the example of FIG. 20, it is assumed that the device 3 is revoked (excluded) due to key leakage, for example, in the group surrounded by the dotted frame in FIG. , An enabling key block (EKB) that can be decrypted only is generated and distributed. The data obtained by encrypting (a) the enabling key block (EKB) and (b) the check value generation key (Kicv) with the node key (K (t) 00) shown in FIG. 20 is distributed.
[0123]
The decoding procedure is shown on the right side of FIG. The devices 0, 1, and 2 first obtain an updated node key (K (t) 00) from the received validation key block by a decryption process using the leaf key or node key held by the device. Next, a check value generation key Kicv is obtained by decryption with K (t) 00.
[0124]
Even if the devices 4, 5, 6,... Shown in FIG. 3 receive this similar data (EKB), the updated node key (K (t) 00) is obtained using the leaf key and node key held by itself. I can't get it. Similarly, the revoked device 3 cannot acquire the updated node key (K (t) 00) with its own leaf key and node key, and only the device having a legitimate right decrypts the check value generation key. Can be used.
[0125]
As described above, if the delivery of the check value generation key using the EKB is used, it is possible to distribute the check value generation key that can be decrypted only by the rightful owner safely while reducing the data amount.
[0126]
By using such an integrity check value (ICV) of content, unauthorized copying of EKB and encrypted content can be eliminated. For example, as shown in FIG. 21, it is assumed that there is a medium 1 that stores content C1 and content C2 together with an enabling key block (EKB) that can acquire the respective content keys, and this is copied to the medium 2 as it is. . Copying of EKB and encrypted content is possible, and this can be used in a device capable of decrypting EKB.
[0127]
As shown in FIG. 21 (b), the integrity check value (ICV (C1, C2)) is stored in association with the content properly stored in each medium. Note that (ICV (C1, C2)) indicates ICV = hash (Kicv, C1, C2), which is a content integrity check value calculated using a hash function for the contents C1 and C2. In the configuration of FIG. 21 (b), the contents 1 and 2 are properly stored in the medium 1, and the integrity check value (ICV (C1, C2)) generated based on the contents C1 and C2 is stored. Is done. Further, the content 2 is legitimately stored in the medium 2, and the 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, when a content check value is newly generated in the medium 2, ICV (C1, C2) is generated. Unlike the Kicv (C1) stored in the media, it becomes clear that new content is stored by falsification or illegal copy of the content. In the device for reproducing media, an ICV check is executed before the reproduction step to determine whether the generated ICV and the stored ICV match, and if they do not match, the reproduction is not executed. Can be prevented from being reproduced.
[0128]
Further, in order to further enhance safety, the content integrity check value (ICV) may be generated based on data including a rewrite counter. That is, the calculation is performed by ICV = hash (Kicv, 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. The counter value needs to be stored in a secure memory.
[0129]
Further, in a configuration in which the content integrity check value (ICV) cannot be stored on the same medium as the content, the content integrity check value (ICV) may be stored on a medium different from the content. .
[0130]
For example, when content is stored in a read-only medium or a medium that is not subjected to copy prevention measures such as ordinary MO, if an integrity check value (ICV) is stored in the same medium, the ICV is rewritten by an unauthorized user. There is a possibility that ICV safety cannot be maintained. In such a case, the ICV is stored in a secure medium on the host machine, and the ICV is used for content copy control (for example, check-in / check-out, move). Management and content tampering can be checked.
[0131]
An example of this configuration is shown in FIG. In FIG. 22, contents are stored in a read-only medium or a medium 2201 that is not subjected to copy prevention measures such as a normal MO, and the user is allowed to freely access the integrity check value (ICV) regarding these contents. This is an example in which it is stored in a secure medium 2202 on the host machine that is not used, and unauthorized rewriting of the integrity check value (ICV) by the user is prevented. As such a configuration, for example, when a device equipped with the media 2201 executes playback of the media 2201, it is illegal if the PC or server that is the host machine performs an ICV check to determine whether playback is possible. Reproduction of copy content or altered content can be prevented.
[0132]
[Categorization of hierarchical tree structure]
The encryption key is configured as the root tree, node key, leaf key, etc., in the hierarchical tree structure shown in FIG. 3, and the content key, authentication key, ICV generation key, program code, data, etc. are encrypted and delivered together with the activation key block (EKB). The configuration that performs efficient key update processing, encryption key distribution, and data distribution by classifying the hierarchical tree structure defining node keys and the like into categories for each device has been described below. To do.
[0133]
FIG. 23 shows an example of category classification of a hierarchical tree structure. In FIG. 23, a root key Kroot 2301 is set at the top level of the hierarchical tree structure, a node key 2302 is set at the intermediate level below, and a leaf key 2303 is set at the bottom level. Each device has an individual leaf key and a series of node keys and root keys from the leaf key to the root key.
[0134]
Here, as an example, a node at the M-th stage from the top is set as the category node 2304. That is, each of the M-th level nodes is set as a device setting node of a specific category. The nodes and leaves of the Mth stage below are assumed to be nodes and leaves related to devices included in the category, with one node at the Mth stage as a vertex.
[0135]
For example, a category [memory stick (trademark)] is set in one node 2305 in the M-th stage in FIG. 23, and nodes and leaves connected to this node are dedicated to the category including various devices using the memory stick. Set as a node or leaf. That is, nodes 2305 and below are defined as a set of related nodes and leaves of devices defined in the category of the memory stick.
[0136]
Furthermore, a stage that is several stages lower than the M stage can be set as the subcategory node 2306. For example, as shown in the figure, a node of “playback device” is set as a subcategory node included in the category of the device using the memory stick in a node two stages below the category [memory stick] node 2305. Further, a node 2307 of a telephone with a music playback function included in the category of the playback-only device is set below the node 2306 of the playback-only device that is a subcategory node, and further below that is included in the category of the telephone with a music playback function. [PHS] node 2308 and [mobile phone] node 2309 can be set.
[0137]
Furthermore, categories and subcategories are not limited to device types, for example, nodes managed independently by a certain manufacturer, content provider, payment institution, etc., that is, arbitrary units such as processing units, jurisdiction units, or service units provided (these are (Hereinafter collectively referred to as an entity). For example, if one category node is set as a vertex node dedicated to the game device XYZ sold by the game device manufacturer, the node key and leaf key below the vertex node can be stored and sold in the game device XYZ sold by the manufacturer. After that, distribution of encrypted contents or distribution and update of various keys is performed by generating and distributing an activation key block (EKB) composed of node keys and leaf keys below the vertex node key, and below the vertex nodes. Data that can be used only for these devices can be distributed.
[0138]
In this way, by setting one node as a vertex and setting the following node as a related node of the category or subcategory defined in the vertex node, one vertex in the category stage or subcategory stage It is possible for a manufacturer, content provider, etc. that manages a node to generate an enabling key block (EKB) that has that node as its vertex and distribute it to devices belonging to the node below the vertex node. The key update can be executed without affecting the devices belonging to the nodes in this category.
[0139]
[Key distribution configuration by simplified EKB]
In the tree structure shown in FIG. 3, for example, when a key, for example, a content key is sent to a predetermined device (leaf), an activation key that can be decrypted using the leaf key and node key owned by the key distribution destination device A block (EKB) is generated and provided. For example, in the tree configuration shown in FIG. 24A, when a key, for example, a content key is transmitted to devices a, g, and j constituting a leaf, an enabling key that can be decrypted at each node of a, g, and j A block (EKB) is generated and distributed.
[0140]
For example, consider a case where the content key K (t) con is encrypted with the updated root key K (t) root and distributed together with the EKB. In this case, each of the devices a, g, and j performs EKB processing using the leaf and node key shown in FIG. 24B to obtain K (t) root, and the obtained update root key K ( t) The content key K (t) con is decrypted by root to obtain the content key.
[0141]
The configuration of the enabling key block (EKB) provided in this case is as shown in FIG. The enabling key block (EKB) shown in FIG. 25 is configured in accordance with the format of the enabling key block (EKB) described in FIG. 6, and data (encryption key) and a corresponding tag are included. Have. As described above with reference to FIG. 7, the tag indicates 0 if there is data in the left (L) and right (R) directions, and 1 if there is no data.
[0142]
The device that has received the enabling key block (EKB) sequentially executes the decryption process of the encryption key based on the encryption key and tag of the enabling key block (EKB), and acquires the update key of the upper node. Go. As shown in FIG. 25, the data amount of the enabling key block (EKB) increases as the number of steps (depth) from the root to the leaf increases. The number of stages (depth) increases according to the number of devices (leafs), and when the number of devices to which keys are distributed is large, the amount of EKB data further increases.
[0143]
A configuration that can reduce the data amount of the enabling key block (EKB) will be described. FIG. 26 shows an example in which the enabling key block (EKB) is simplified according to the key distribution device.
[0144]
As in FIG. 25, it is assumed that a key, for example, a content key is transmitted to the devices a, g, and j constituting the leaf. As shown in FIG. 26A, a tree constructed only by the key distribution device 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. There is no branch from Kroot to Kj, and only one branch needs to exist. To reach from Kroot to Ka and Kg, only a branch point is formed at K0, and the two-branch configuration shown in FIG. A tree is built.
[0145]
As shown in FIG. 26A, a simplified tree having only K0 as a node is generated. An enabling key block (EKB) for renewal key distribution is generated based on these simplified trees. The tree shown in FIG. 26 (a) is regenerated by selecting a path constituting a two-branch tree with the end node or leaf being the lowest stage capable of decrypting the enabling key block (EKB) and omitting unnecessary nodes. It is a reconstructed hierarchical tree that is constructed. An enabling key block (EKB) for update key distribution is configured based only on keys corresponding to nodes or leaves of this reconstructed hierarchical tree.
[0146]
The enabling key block (EKB) described with reference to FIG. 25 stores data obtained by encrypting all keys from each leaf a, g, j to Kroot, but the simplified EKB is simplified. Encrypted data is stored only for the nodes that make up the tree. As shown in FIG. 26B, the tag has a 3-bit configuration. The first and second bits have the same meaning as in the example of FIG. 25, and indicate 0 if there is data in the left (L) and right (R) directions, and 1 if there is no data. The third bit is a bit for indicating whether or not the encryption key is stored in the EKB, and is set as 1 when data is stored and 0 when there is no data.
[0147]
As shown in FIG. 26 (b), the enabling key block (EKB) stored in the data communication network or storage medium and provided to the device (leaf) has a data amount as compared with the configuration shown in FIG. It will be greatly reduced. Each device that has received the enabling key block (EKB) shown in FIG. 26 realizes decryption of a predetermined encryption key by sequentially decrypting only the data in the portion where 1 is stored in the third bit of the tag. be able to. For example, the device a decrypts the encrypted data Enc (Ka, K (t) 0) with the leaf key Ka, obtains the node key K (t) 0, and uses the node key K (t) 0 to encrypt the encrypted data Enc (K (T) 0, K (t) root) is decoded to obtain K (t) root. The device j decrypts the encrypted data Enc (Kj, K (t) root) with the leaf key Kj, and acquires K (t) root.
[0148]
In this way, a simplified new tree configuration configured only by the delivery destination device is constructed, and an enabling key block (EKB) is generated using only the leaf and node keys that make up the constructed tree. By doing so, it becomes possible to generate an enabling key block (EKB) with a small amount of data, and data distribution of the enabling key block (EKB) can be executed efficiently.
[0149]
It should be noted that the simplified hierarchical tree configuration can be used particularly effectively in the entity-by-entity EKB management configuration described later. An entity is an aggregate block of a plurality of nodes or leaves selected from nodes or leaves constituting a tree structure as a key distribution structure. An entity is a set that is set according to the type of device, or a processing unit, jurisdiction unit, or service unit that has a common point, such as a management unit such as a device provider, content provider, or payment institution. Are set as a set of various modes. One entity is a collection of devices that fall into a common category. For example, the EKB is generated by reconstructing a simplified tree similar to that described above with vertex nodes (sub-roots) of a plurality of entities. Thus, it becomes possible to generate and distribute a simplified enabling key block (EKB) that can be decrypted by devices belonging to the selected entity. The management configuration of entity units will be described in detail later.
[0150]
Such an enabling key block (EKB) can be stored in an information recording medium such as an optical disk or a DVD. For example, an enabling key block (EKB) including a data part constituted by the above-described encryption key data and a tag part 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 an information recording medium storing message data such as content to each device. The device can extract and decrypt the encryption key data contained in the enabling key block (EKB) sequentially according to the identification data of the tag part, obtain the key necessary for decrypting the content, and use the content It becomes. Of course, the enabling key block (EKB) may be distributed via a network such as the Internet.
[0151]
[Entity-based EKB management configuration]
Next, a configuration in which nodes or leaves constituting a tree configuration as a key distribution configuration are managed by blocks as a set of a plurality of nodes or leaves will be described. 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 service unit that has a common point, such as a management unit such as a device provider, content provider, or payment institution. Are set as a set of various modes. That is, an entity is defined as a device or entity management entity that belongs to a common category such as a device type, a service type, or a management means type.
[0152]
The entity will be described with reference to FIG. FIG. 27A is a diagram illustrating a management configuration in units of tree entities. In the figure, one entity is shown as a triangle. For example, one entity 2701 includes a plurality of nodes. (B) shows a node configuration within one entity. One entity is constituted by a two-stage bifurcated tree having one node as a vertex. Hereinafter, the vertex node 2702 of the entity is called a sub-root.
[0153]
The end of the tree is constituted by leaves, ie devices, as shown in (c). A device belongs to any entity constituted by a tree having a plurality of devices as leaves and having a vertex node 2702 as a sub-root.
[0154]
As understood from FIG. 27A, the entity has a hierarchical structure. This hierarchical structure will be described with reference to FIG.
[0155]
FIG. 28 (a) is a diagram for explaining the hierarchical structure in a simplified manner. Entities A01 to Ann are configured a few steps below Kroot, and an entity B01 is further subordinate to the entities A1 to An. ~ Bnk, and further, entities C1 to Cnq are set in the lower order. Each entity has a tree shape composed of a plurality of stages of nodes and leaves, as shown in FIGS.
[0156]
For example, the configuration of the entity Bnk has a plurality of nodes from the sub route 2811 to the end node 2812 as shown in FIG. This entity has an identifier Bnk, and by managing the node key corresponding to the node in the entity Bnk independently of the entity Bnk, the management of the lower (child) entity set with the end node 2812 as the vertex is executed. On the other hand, the entity Bnk is under the management of a higher-level (parent) entity Ann having the sub-route 2811 as a terminal node.
[0157]
As shown in (c), the configuration of the entity Cn3 has a sub-root 2851 as a vertex node, a terminal node 2852 that is each device, in this case, a plurality of nodes and leaves up to the leaf. This entity has an identifier Cn3 and executes management of a leaf (device) corresponding to the end 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 the upper (parent) entity Bn2 having the sub-route 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.
[0158]
The device which is the leaf of the lowest entity stores the node key and leaf key of each node located in the path from the leaf key of the entity to which the device belongs to the sub-root node which is the vertex node of the entity to which the device belongs. For example, the device of the end node 2852 stores each key from the end node (leaf) 2852 to the sub-root node 2851.
[0159]
The configuration of the entity will be further described with reference to FIG. An entity can have a tree structure composed of various levels. 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.
[0160]
When the vertical entity configuration as shown in FIG. 29A is embodied, the mode shown in FIG. 29B is obtained. The root entity is an uppermost entity having a root key. Entities A, B, and C are set as a plurality of lower entities at the end node of the root entity, and entity D is set as a lower entity of entity C. When entity C 2901 holds one or more of its end nodes as reserve nodes 2950 and increases the entity managed by itself, entity C '2902 having a multi-stage tree structure is further set as reserve node 2950. By newly providing a vertex node, it is possible to increase the management end node 2970 and add the increased lower-level entity to the management end node.
[0161]
The reserve node will be further described with reference to FIG. The entity A, 3011 has lower-level entities B, C, D... To be managed, and has one reserve node 3021. If the entity wants to further increase the lower-level entity to be managed, the self-managed lower-level entity A ′, 3012 is set in the reserve node 3021, and the lower-level entity F, to be managed is further set at the end node of the lower-level entity A ′, 3012. G can be set. The self-managed lower entity A ′, 3012 can further increase the management entity by setting the lower entity A ″ 3013 by setting at least one of its end nodes as the reserve node 3022. 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 lower-level entities managed by a certain entity can be increased without limit. In addition, it is good also as a structure which sets multiple reserve entities instead of only one of the terminal nodes.
[0162]
In each entity, an enabling key block (EKB) is configured in units of entities, and key updating and revoke processing are performed in units of entities. As shown in FIG. 30, the plurality of entities A, A ′, A ″ are set with the individual enabling key blocks (EKB) of the entities, and these are the entities A, A ′, A ″. For example, a certain device manufacturer can manage all of them in a batch.
[0163]
[New entity registration process]
Next, a new entity registration process will be described. FIG. 31 shows the registration processing sequence. This will be described according to the sequence of FIG. The new (child) entity (N-En) newly added in the tree structure executes a new registration request to the upper (parent) entity (P-En). Each entity has a public key in accordance with the public key cryptosystem, and the new entity sends its public key to the higher-level entity (P-En) upon requesting registration.
[0164]
Upon receiving the registration request, the upper entity (P-En) transfers the received public key of the new (child) entity (N-En) to a certificate authority (CA) and adds the CA signature. A new (child) entity (N-En) public key is received. These procedures are performed as a mutual authentication procedure between the upper entity (P-En) and the new (child) entity (N-En).
[0165]
When the authentication of the new registration request entity is completed by these processes, the upper entity (P-En) permits the registration of the new (child) entity (N-En), and the new (child) entity (N-En). Are transmitted to the new (child) entity (N-En). This node key is one node key of the terminal node of the upper entity (P-En) and corresponds to the vertex node of the new (child) entity (N-En), that is, the sub-root key.
[0166]
When this node key transmission is completed, the new (child) entity (N-En) constructs a tree structure of the new (child) entity (N-En), and sets the received sub-root key of the vertex node at the vertex of the constructed tree. Set and set keys for each node and leaf to generate an enabling key block (EKB) in the entity. An enabling key block (EKB) in one entity is called a sub-EKB.
[0167]
On the other hand, the upper entity (P-En) 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).
[0168]
When the new (child) entity (N-En) generates a sub-EKB composed of the node key and leaf key in the new (child) entity (N-En), the new (child) entity (N-En) transmits this to the higher-level entity (P-En).
[0169]
The upper entity (P-En) that has received the sub-EKB from the new (child) entity (N-En) receives the received sub-EKB and the updated sub-EKB of the upper entity (P-En) as the key issuing center (KDC). : Key Distribute Center).
[0170]
Based on the sub-EKB of all entities, the key distribution center (KDC) can generate various modes of EKB, that is, EKB that can be decrypted only by a specific entity or device. Providing an EKB in which an entity or device that can be decrypted in this way is set to, for example, a content provider, the content provider encrypts the content key based on the EKB, and stores the encrypted content key via a network or a recording medium. Thus, it is possible to provide content that can be used only on a specific device.
[0171]
The registration process of the new entity sub-EKB to the key issuing center (KDC) is not limited to the method of sequentially transferring the sub-EKB through the upper entity and executing it, and the new entity is registered without going through the upper entity. It may be configured to execute a process of registering with the key issuing center (KDC) directly from the entity.
[0172]
The correspondence between the upper entity and the lower entity newly added to the upper entity will be described with reference to FIG. The lower entity is added as an entity under the management of the higher entity by providing one of the higher entity end nodes 3201 as the apex node of the newly added entity to the lower entity. The entity under the management of the upper entity, which will be described in detail later, includes the meaning that the upper entity can execute the revocation (exclusion) processing of the lower entity.
[0173]
As shown in FIG. 32, when a new entity is set in the higher entity, one node 3201 of the end node that is the leaf of the higher entity and the vertex node 3202 of the new additional entity are set as equal nodes. That is, one terminal node, which is one leaf of the upper node, is set as a sub-root of the newly added entity. With this setting, the newly added entity is validated under the entire tree structure.
[0174]
FIG. 33 shows an example of an update EKB generated by a higher entity when a new additional entity is set. FIG. 33 shows the configuration shown in (a), that is, there are a terminal node (node000) 3301 and a terminal node (node001) 3302 that are already valid, and a new entity additional terminal node (node100) 3303 is assigned to the new additional entity. This is an example of a sub-EKB generated by a higher-order entity when it is performed.
[0175]
The sub EKB has a configuration as shown in FIG. Each of the nodes has an upper node key encrypted with a terminal node key that exists effectively, a further upper node key encrypted with the upper node key,... With this configuration, a sub-EKB is generated. As shown in FIG. 33 (b), each entity is a valid end node, or a higher node key encrypted with a leaf key, and a higher node key is encrypted with the upper node key, and the higher node key is sequentially encrypted deeper to the sub-root. It has an EKB composed of data and manages it.
[0176]
[Revocation processing under entity management]
Next, device or entity revocation (exclusion) processing in a configuration in which the key distribution tree configuration is managed as entity units will be described. 3 and 4 described the processing for distributing an enabling key block (EKB) in which only a specific device can be decrypted from the entire tree structure and the revoked device cannot decrypt. The revocation process described with reference to FIGS. 3 and 4 is a process 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 process can be executed for each entity.
[0177]
The revoke process in the tree structure under entity management will be described with reference to FIG. 34 and subsequent figures. FIG. 34 is a diagram for explaining device revocation processing by the lowest entity among the entities constituting the tree, that is, the entity that manages each device.
[0178]
FIG. 34A shows a key distribution tree structure based on entity management. A root node is set at the top of the tree, and entities A01 to Ann are arranged several stages below, entities B01 to Bnk are further arranged at the lower stages thereof, and entities C1 to cn are arranged at the lower stages thereof. In the lowest entity, it is assumed that the end node (leaf) is an individual device, for example, a recording / reproducing device, a reproducing-only device, or the like.
[0179]
Here, the revoke process is independently executed in each entity. For example, in the lowest entity C1 to Cn, the revocation processing of the leaf device is executed. FIG. 34B shows a tree configuration of entities Cn, 3430, which is one of the lowest-level entities. The entity Cn, 3430 has a vertex node 3431 and a plurality of devices in a leaf that is a terminal node.
[0180]
If there is a device to be revoked, for example, a device 3432, in the leaf that is the terminal node, the entities Cn and 3430 have an activation key block (sub-key) composed of the node key and leaf key in the entity Cn that has been independently updated. EKB). This activation key block is a key block constituted by an encryption key that cannot be decrypted by the revoke device 3432 but can be decrypted only by devices constituting other leaves. The administrator of entity Cn generates this as an updated sub-EKB. Specifically, the node key of each of the nodes 3431, 3434, and 3435 constituting the path connected from the sub-root to the revocation device 3432 is updated, and this updated node key is used as an encryption key that can be decrypted only by leaf devices other than the revocation device 3432. The constructed block is set as an update 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 revocation processing configuration described with reference to FIGS.
[0181]
Thus, the validation key block (sub EKB) updated by the entity Cn, 3430 by the revoke process is transmitted to the upper entity. In this case, the upper entity is entity Bnk, 3420, and is an entity having vertex node 3431 of entity Cn, 3430 as a terminal node.
[0182]
When entity Bnk, 3420 receives the enabling key block (sub-EKB) from lower entity Cn, 3430, entity Bnk, 3420 changes end node 3431 of entity Bnk, 3420 corresponding to vertex node 3431 of entity Cnk, 3430 included in the key block. Then, the key updated in the lower entity Cn, 3430 is set and the sub-EKB of the entity Bnk, 3420 is updated. FIG. 34C shows the tree structure of the entities Bnk and 3420. In the entity Bnk, 3420, the node key to be updated is a node key on the path from the sub-route 3421 in FIG. 34C to the terminal node 3431 constituting the entity including the revocation device. That is, the node key of each of the nodes 3421, 3424, 3425 constituting the path connected to the entity node 3431 that has transmitted the update sub-EKB is to be updated. The node key of each node is updated to generate a new update sub-EKB of the entity Bnk, 3420.
[0183]
Alternatively, when the entity Bnk, 3720 executes the revocation of the lower entity Cn, 3730, the terminal node 3731 of the entity Bnk, 3720 corresponding to the vertex node 3731 of the entity Cnk, 3730 is not updated, and from the revocency 3730 An updated sub-EKB may be generated by updating the node keys excluding the terminal node 3731 on the path to the sub-root of the entity Bnk, 3720 to generate an enabling key block.
[0184]
Further, the enabling key block (sub EKB) updated by the entity Bnk, 3420 is transmitted to the upper entity. In this case, the superior entity is the entity Ann, 3410, and is an entity having the vertex node 3421 of the entity Bnk, 3420 as a terminal node.
[0185]
When the entity Ann, 3410 receives the activation key block (sub EKB) from the lower entity Bnk, 3420, the entity Ann, 3410 sets the end node 3421 of the entity Ann, 3410 corresponding to the vertex node 3421 of the entity Bnk, 3420 included in the key block. Then, the key updated in the lower entity Bnk, 3420 is set, and the sub-EKB update process of its own entity Ann, 3410 is executed. FIG. 34D shows a tree structure of the entity Ann, 3410. In the entity Ann, 3410, the node key to be updated is the node key of each of the nodes 3411, 3414, 3415 constituting the path connected to the entity node 3421 that has transmitted the updated sub-EKB from the sub-route 3411 in FIG. . The node key of each node is updated to generate a new update sub-EKB of the entity Ann, 3410.
[0186]
These processes are sequentially executed in the upper entity and executed up to the root entity described with reference to FIG. This series of processing completes the device revocation process. The sub-EKB updated in each entity is finally transmitted to the key issuing center (KDC) and stored. The key distribution center (KDC) generates various EKBs based on all entity update sub-EKBs. The update EKB becomes an encryption key block that cannot be decrypted by the revoked device.
[0187]
FIG. 35 shows a sequence diagram of the device revocation process. 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 performs key update necessary to eliminate the revoked leaf in the device management entity (D-En), and the device management entity (D -New sub-EKB (D) of (En) is generated. The updated sub EKB (D) is sent to the upper entity. The upper (parent) entity (P1-En) that has received the updated sub-EKB (D) updates the terminal node key corresponding to the updated vertex node of the updated sub-EKB (D) and is on the path from the terminal node to the sub-root. An updated sub EKB (P1) with the updated node key is generated. These processes are sequentially executed in the upper entity, and all the sub-EKBs finally updated are stored and managed in the key issuing center (KDC).
[0188]
FIG. 36 shows an example of an enabling key block (EKB) generated by a higher entity performing an update process by a device revocation process.
[0189]
FIG. 36 is a diagram for explaining an example of EKB generated in the upper entity that has received the updated sub-EKB from the lower entity including the revocation device in the configuration illustrated in FIG. The vertex node of the lower entity including the revocation device corresponds to the terminal node (node 100) 3601 of the upper entity.
[0190]
The upper entity updates a node key existing in the path from the sub-root of the upper entity to the terminal node (node 100) 3601, and generates a new update sub-EKB. The update sub EKB is as shown in FIG. The updated key is shown with an underline and [']. The node key on the path from the terminal node thus updated to the sub-root is updated to be an updated sub-EKB in that entity.
[0191]
Next, processing when an object to be revoked is an entity, that is, an entity revoking process will be described.
[0192]
FIG. 37 (a) shows a key distribution tree structure based on entity management. A root node is set at the top of the tree, and entities A01 to Ann are arranged several stages below, entities B01 to Bnk are further arranged at the lower stages thereof, and entities C1 to cn are arranged at the lower stages thereof. In the lowest entity, it is assumed that the end node (leaf) is an individual device, for example, a recording / reproducing device, a reproducing-only device, or the like.
[0193]
Here, a case where the revoke process is executed for the entities Cn and 3730 will be described. The lowest entity Cn, 3730 has a vertex node 3431 as shown in FIG. 37 (b) and a plurality of devices in a leaf which is a terminal node.
[0194]
By revoking the entity Cn, 3730, it becomes possible to eliminate all devices belonging to the entity Cn, 3730 from the tree structure. The revoke process of the entity Cn, 3730 is executed in the entity Bnk, 3720, which is the higher entity of the entity Cn, 3730. The entity Bnk, 3720 is an entity having the vertex node 3731 of the entity Cn, 3730 as a terminal node.
[0195]
When the entity Bnk, 3720 executes the revocation of the lower entity Cn, 3730, the entity Bnk, 3720 updates the terminal node 3731 of the entity Bnk, 3720 corresponding to the vertex node 3731 of the entity Cnk, 3730, and further updates the entity Bnk, 3720 from the entity 3730. The node key on the path up to the sub-root of Bnk, 3720 is updated to generate an enabling key block to generate an updated sub-EKB. The node key to be updated is a node key on the path from the sub-root 3721 in FIG. 37C to the terminal node 3731 constituting the vertex node of the revouncity. That is, the node keys of the nodes 3721, 3724, 3725, and 3731 are to be updated. The node key of each node is updated to generate a new update sub-EKB of the entity Bnk, 3720.
[0196]
Further, the enabling key block (sub EKB) updated by the entity Bnk, 3720 is transmitted to the upper entity. In this case, the upper entity is the entity Ann, 3710, and is an entity having the vertex node 3721 of the entity Bnk, 3720 as a terminal node.
[0197]
When entity Ann, 3710 receives the enabling key block (sub-EKB) from lower entity Bnk, 3720, entity Ann, 3710 receives end node 3721 of entity Ann, 3710 corresponding to vertex node 3721 of entity Bnk, 3720 included in the key block. Then, the key updated in the lower entity Bnk, 3720 is set, and the sub-EKB update process of its own entity Ann, 3710 is executed. FIG. 37 (d) shows the tree structure of the entity Ann 3710. In the entity Ann, 3710, the node key to be updated is the node key of each of the nodes 3711, 3714, 3715 constituting the path connected to the entity node 3721 that has transmitted the updated sub-EKB from the sub-route 3711 in FIG. . The node key of each of these nodes is updated to generate a new update sub-EKB of the entity Ann, 3710.
[0198]
These processes are sequentially executed in the upper entity and executed up to the root entity described with reference to FIG. Through this series of processes, the entity revocation process is completed. The sub-EKB updated in each entity is finally transmitted to the key issuing center (KDC) and stored. The key distribution center (KDC) generates various EKBs based on all entity update sub-EKBs. The update EKB becomes an encryption key block that cannot be decrypted by a device belonging to the revoked entity.
[0199]
FIG. 38 shows a sequence diagram of the entity revocation process. The processing procedure will be described with reference to the sequence diagram of FIG. First, the entity management entity (E-En) that intends to revoke the entity performs key update necessary to eliminate the terminal node to be revoked in the entity management entity (E-En), and the entity management entity (E -New sub-EKB (E) of (En) is generated. The updated sub-EKB (E) is sent to the upper entity. The upper (parent) entity (P1-En) that has received the updated sub-EKB (E) updates the terminal node key corresponding to the updated vertex node of the updated sub-EKB (E) and is on the path from the terminal node to the sub-root. An updated sub EKB (P1) with the updated node key is generated. These processes are sequentially executed in the upper entity, and all the sub-EKBs finally updated are stored and managed in the key issuing center (KDC). The key distribution center (KDC) generates various EKBs based on all entity update sub-EKBs. The update EKB becomes an encryption key block that cannot be decrypted by a device belonging to the revoked entity.
[0200]
FIG. 39 is a diagram for explaining the correspondence between the revoked lower entity and the higher entity that has been revoked. The upper entity end node 3901 is updated by the entity revocation, and a new sub-EKB is generated by updating the node key existing in the path from the end node 3901 to the sub-root in the upper entity tree. As a result, the node key of the vertex node 3902 of the revoked lower entity and the node key of the end node 3901 of the higher entity do not match. Since the EKB generated by the key distribution center (KDC) after the entity revocation is generated based on the key of the terminal node 3901 updated in the upper entity, the leaf of the lower entity that does not hold the updated key is generated. The corresponding device will be unable to decrypt the EKB generated by the key distribution center (KDC).
[0201]
In the above description, the revoking process of the lowest entity that manages the device has been described. However, the process of revoking the entity management entity in the middle of the tree by the higher entity is also possible by the same process as described above. By revoking the middle-stage entity management entity, all of the plurality of entities and devices belonging to the subordinates of the revoked entity management entity can be revoked at once.
[0202]
In this way, by executing revocation in units of entities, it is possible to perform revocation processing in a simple process compared to revocation processing executed in units of devices.
[0203]
[Management of entity capabilities]
Next, in the key distribution tree configuration in units of entities, a processing configuration for managing the capability (Capability) allowed by each entity and performing content distribution according to the capability will be described. Here, the capability means what kind of content or program the device has such as being capable of decoding specific compressed audio data, allowing a specific audio reproduction method, or processing a specific image processing program. It is the definition information of the data processing capability of the device.
[0204]
FIG. 40 shows an example of an entity configuration in which capabilities are defined. In this tree configuration, a root node is located at the top of the key distribution tree configuration, a plurality of entities are connected to the lower layer, and each node has two branches. Here, for example, the entity 4001 is defined as an entity having a capability that allows any one of the audio reproduction modes A, B, and C. Specifically, for example, when music data compressed by an audio compression program-A, B, or C method is distributed, a device belonging to an entity configured under the entity 4001 can perform a process of decompressing the compressed data. is there.
[0205]
Similarly, the entity 4002 is defined as an entity having a capability capable of processing the audio reproduction method B or C, the entity 4003 is an audio reproduction method A or B, the entity 4004 is an audio reproduction method B, and the entity 4005 is an audio reproduction method C. Is done.
[0206]
On the other hand, the entity 4021 is defined as an entity that allows the image reproduction methods p, q, and r, the entity 4022 is an image reproduction method of the methods p and q, and the entity 4023 is an entity having a capability capable of image reproduction of the method p. Defined.
[0207]
Such capability information of each entity is managed in a key issuing center (KDC). For example, when a content provider wants to distribute music data compressed by a specific compression program to various devices, the key distribution center (KDC) enables the specific compression program to be decrypted only to a device that can play the specific compression program. A key block (EKB) can be generated based on capability information of each entity. The content provider that provides the content distributes the content key encrypted with the enabling key block (EKB) generated based on the capability information, and provides the compressed audio data encrypted with the content key to each device. With this configuration, it is possible to reliably provide a specific processing program only to a device that can process data.
[0208]
In FIG. 40, the capability information is defined for all entities. However, it is not always necessary to define the capability information for all entities as shown in FIG. 40. For example, as shown in FIG. Capabilities can be defined only for the lowest entity to which the device belongs, and the capabilities of the devices belonging to the lowest entity can be managed in the key distribution center (KDC) so that only the devices that can be processed by the content provider can be decrypted The enabling key block (EKB) may be generated based on capability information defined in the lowest entity. In FIG. 41, capabilities in entities 4101 = 4105 in which devices are defined in the end nodes are defined, and the capabilities for these entities are managed in the key issuing center (KDC). For example, the entity 4101 belongs to a device capable of processing method B for sound reproduction and method r for image reproduction. The entity 4102 includes a device capable of processing method A for sound reproduction and method q for image reproduction.
[0209]
FIG. 42 shows a configuration example of a capability management table managed in the key issuing center (KDC). The capability management table has a data structure as shown in FIG. That is, an entity ID as an identifier for identifying each entity, a capability list indicating the capabilities defined for the entity, and this capability list is processed by, for example, the audio data reproduction processing method (A) as shown in FIG. [1] if it is possible, [0] if it cannot be processed, [1] if the audio data reproduction processing method (B) can be processed, [0] if it cannot be processed, etc. Whether or not the data processing of the mode is possible is configured by setting [1] or [0] bit by bit. Note that the capability information setting method is not limited to such a format, and any other configuration may be used as long as the capability of the entity management device can be identified.
[0210]
The capability management table further stores the sub-EKB of each entity or, if the sub-EKB is stored in another database, the sub-EKB identification information, and further stores the sub-root node identification data of each entity. The
[0211]
Based on the capability management table, for example, the key issuing center (KDC) generates an enabling key block (EKB) that can be decrypted only by a device capable of reproducing specific content. With reference to FIG. 43, a process for generating an enabling key block based on capability information will be described.
[0212]
First, in step S4301, the key issuing center (KDC) selects an entity having a specified capability from the capability management table. Specifically, for example, when a content provider wants to distribute reproducible data based on the audio data reproduction processing method A, for example, the item of the audio data reproduction processing (method A) is [from the capability list of FIG. 1] Select the entity set in [1].
[0213]
Next, in step S4302, a list of selected entity IDs constituted by the selected entities is generated. Next, in step S4303, a path required for the tree configured by the selected entity ID (a path having a key distribution tree configuration) is selected. In step S4304, it is determined whether or not all paths included in the list of selected entity IDs have been completed, and paths are generated in step S4303 until completion. This means a process of sequentially selecting each path when a plurality of entities are selected.
[0214]
When all the paths included in the list of selected entity IDs have been selected, the process advances to step S4305 to construct a key distribution tree structure configured only by the selected path and the selected entity.
[0215]
In step S4306, the node key having the tree structure generated in step S4305 is updated to generate an updated node key. Further, the sub-EKB of the selected entity constituting the tree is extracted from the capability management table, and an enabling key block (EKB) that can be decrypted only by the device of the selected entity based on the sub-EKB and the updated node key generated in step S4306 is obtained. Generate. The enabling key block (EKB) generated in this way becomes an enabling key block (EKB) that can be used, that is, decrypted only in a device having a specific capability. Selected by the key distribution center (KDC) by, for example, encrypting the content key with this enabling key block (EKB) and encrypting the content compressed based on the specific program with the content key and providing it to the device The content is used only on a specific processable device.
[0216]
In this way, the key issuing center (KDC) generates an enabling key block (EKB) that can be decrypted only by, for example, a device capable of reproducing specific content, 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 accompanying this new entity registration will be described with reference to FIG.
[0217]
FIG. 44 is a diagram showing a capability notification processing sequence when a new entity participates in the key distribution tree configuration.
[0218]
The new (child) entity (N-En) newly added in the tree structure executes a new registration request to the upper (parent) entity (P-En). Each entity has a public key in accordance with the public key cryptosystem, and the new entity sends its public key to the higher-level entity (P-En) upon requesting registration.
[0219]
Upon receiving the registration request, the upper entity (P-En) transfers the received public key of the new (child) entity (N-En) to a certificate authority (CA) and adds the CA signature. A new (child) entity (N-En) public key is received. These procedures are performed as a mutual authentication procedure between the upper entity (P-En) and the new (child) entity (N-En).
[0220]
When the authentication of the new registration request entity is completed by these processes, the upper entity (P-En) permits the registration of the new (child) entity (N-En), and the new (child) entity (N-En). Are transmitted to the new (child) entity (N-En). This node key is one node key of the terminal node of the upper entity (P-En) and corresponds to the vertex node of the new (child) entity (N-En), that is, the sub-root key.
[0221]
When this node key transmission is completed, the new (child) entity (N-En) constructs a tree structure of the new (child) entity (N-En), and sets the received sub-root key of the vertex node at the vertex of the constructed tree. Set, and set keys for each node and leaf to generate an enabling key block (sub-EKB) in the entity. 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).
[0222]
When the new (child) entity (N-En) generates a sub-EKB composed of the node key and leaf key in the new (child) entity (N-En), it transmits this to the higher-order entity (P-En). Furthermore, the capability information about the device managed by its own entity is notified to the upper entity.
[0223]
The upper entity (P-En) that has received the sub-EKB and capability information from the new (child) entity (N-En) is the received sub-EKB and capability information, and the updated sub-EKB of the upper entity (P-En). To the Key Distribute Center (KDC).
[0224]
The key issuing center (KDC) registers the received sub EKB and 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 various types of EKB, that is, an EKB that can be decrypted only by an entity or a device having a specific capability.
[0225]
The present invention has been described in detail above with reference to specific embodiments. However, it is obvious that those skilled in the art can make modifications and substitutions of the embodiments without departing from the gist of the present invention. In other words, the present invention has been disclosed in the form of exemplification, and should not be interpreted in a limited manner. In order to determine the gist of the present invention, the claims section described at the beginning should be considered.
[0226]
【The invention's effect】
As described above, according to the information processing system and method of the present invention, each key is associated with a route, a node, and a leaf on a path from a tree root to a leaf in which a plurality of devices are configured as leaves. A plurality of entities for managing a subtree as a partial tree constituting a key tree and generating a sub-validating key block (sub-EKB) based only on keys set corresponding to nodes or leaves belonging to the sub-tree are set. Since the sub-validation key block (sub-EKB) generated by a plurality of entities is used to generate and deliver the enabling key block (EKB) that can be decrypted only in the selected entity, the hierarchical structure The key tree configuration can be divided and managed, and detailed processing according to the device is possible To become.
[0227]
Furthermore, according to the information processing system and method of the present invention, a device or entity revocation process can be executed at the entity, and an increase in processing amount due to an increase in devices in the case of batch device management is prevented.
[0228]
Furthermore, according to the information processing system and method of the present invention, since the reserve node is set to the end 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 showing a configuration example of a recording / reproducing apparatus applicable in the information processing system of the present invention.
FIG. 3 is a tree configuration diagram illustrating encryption processing of various keys and data in the information processing system of the present invention.
FIG. 4 is a diagram showing an example of an enabling key block (EKB) used for distributing various keys and data in the information processing system of the present invention.
FIG. 5 is a diagram showing a distribution example and a decryption processing example using a content key validation 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 a data configuration example in which an enabling key block (EKB), a content key, and content are distributed together in the information processing system of the present invention.
FIG. 9 is a diagram showing an example of processing in a device when an enabling 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 for explaining the correspondence when an enabling key block (EKB) and content are stored in a recording medium in the information processing system of the present invention.
FIG. 11 is a diagram comparing processing for sending an enabling key block (EKB) and a content key in the information processing system of the present invention with conventional sending processing.
FIG. 12 is a diagram showing an authentication processing sequence by a common key cryptosystem applicable in the information processing system of the present invention.
FIG. 13 is a diagram (No. 1) showing a data configuration for delivering an enabling key block (EKB) and an authentication key together in the information processing system of the present invention, and a processing example in the device;
FIG. 14 is a diagram (part 2) illustrating an example of processing performed by a device and a data configuration in which an enabling key block (EKB) and an authentication key are delivered together in the information processing system of the present invention;
FIG. 15 is a diagram showing an authentication processing sequence by a public key cryptosystem applicable in the information processing system of the present invention.
FIG. 16 is a diagram showing processing for distributing an enabling key block (EKB) and a content key together using authentication processing by a public key cryptosystem in the information processing system of the present invention.
FIG. 17 is a diagram showing processing for distributing an enabling key block (EKB) and encrypted program data in the information processing system of the present invention.
FIG. 18 is a diagram showing an example of generating a MAC value used for generating a content integrity check value (ICV) applicable in the information processing system of the present invention.
FIG. 19 is a diagram (No. 1) illustrating a data configuration in which an enabling key block (EKB) and an ICV generation key are distributed together in the information processing system of the present invention, and a processing example in the device;
FIG. 20 is a diagram (part 2) illustrating a data configuration in which an enabling key block (EKB) and an ICV generation key are distributed together in the information processing system of the present invention, and a processing example in the device;
FIG. 21 is a diagram illustrating a copy prevention function when a content integrity check value (ICV) applicable in the information processing system of the present invention is stored in a medium.
FIG. 22 is a diagram for explaining a configuration for managing a content integrity check value (ICV) applicable to the information processing system of the present invention separately from the content storage medium.
FIG. 23 is a diagram illustrating an example of category classification of a hierarchical tree structure in the information processing system of the present invention.
FIG. 24 is a diagram for explaining a generation process of a simplified validation key block (EKB) in the information processing system of the present invention.
FIG. 25 is a diagram for explaining an enabling key block (EKB) generation process in the information processing system of the present invention;
FIG. 26 is a diagram for explaining 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 reserve node in the hierarchical tree structure entity management configuration 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 with a hierarchical tree structure in the information processing system of the present invention.
FIG. 32 is a diagram illustrating a relationship between a new entity and a higher entity in an entity management configuration with a hierarchical tree structure in the information processing system of the present invention.
FIG. 33 is a diagram for explaining a sub-EKB used in an entity management configuration with a hierarchical tree structure in the information processing system of the present invention.
FIG. 34 is a diagram for explaining device revocation processing in the hierarchical tree structure entity management configuration in the information processing system of the present invention;
FIG. 35 is a diagram illustrating a device revocation process sequence in the hierarchical tree structure entity management configuration in the information processing system of the present invention.
FIG. 36 is a diagram for explaining an update sub EKB at the time of device revocation in the hierarchical tree structure entity management configuration in the information processing system of the present invention;
FIG. 37 is a diagram illustrating an entity revocation process in an entity management configuration with a hierarchical tree structure in the information processing system of the present invention.
FIG. 38 is a diagram for explaining an entity revocation processing sequence in the hierarchical tree structure entity management configuration in the information processing system of the present invention;
FIG. 39 is a diagram for explaining a relationship between revotionality and higher entity in the hierarchical tree structure entity management configuration in the information processing system of the present invention;
FIG. 40 is a diagram illustrating capability setting in an entity management configuration with a hierarchical tree structure in the information processing system of the present invention.
FIG. 41 is a diagram for describing capability setting in the hierarchical tree structure entity management configuration in the information processing system of the present invention;
FIG. 42 is a diagram for explaining 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 an EKB generation processing flowchart 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 for explaining capability notification processing at the time of new entity registration in the information processing system of the present invention;
[Explanation of symbols]
10 Content distribution side
11 Internet
12 Satellite broadcasting
13 Telephone line
14 Media
20 Content receiver
21 Personal computer (PC)
22 Portable Device (PD)
23 Mobile phones, PDAs
24 Recording / playback device
25 Reproduction-only device
30 media
100 Recording / reproducing apparatus
110 bus
120 Input / output I / F
130 MPEG codec
140 I / O I / F
141 A / D, D / A converter
150 Cryptographic 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 section
607 Tag part
608 Signature
1101 Recording device
2301 Root key
2302 Node key
2303 Leaf Key
2304 Category node
2306 Subcategory node
2701 Entity
2702 Subroute
2811,2851 Subroute
2812,2852 Entity end node
2901, 2902 Entity
2950 Reserve Node
2970 Management end node
3011, 3012, 3013 Entity
3021, 3022, 3023 Reserve node
3201 Terminal node
3202 Vertex node
3301, 3302 Terminal node
3303 New entity added end node
3410, 3420, 3430 Entity
3411, 3421, 3431 Subroute
3432 Revocation Device Node
3601 Terminal node
3710, 3720, 3730 Entity
3711, 3721, 3731 Subroute
3901 Terminal node
3902 Vertex node (sub-root node)
4001 to 4005 Entity
4021, 4022, 4023 Entity
4101-4105 Entity

Claims (25)

Configure a key tree by associating keys with the root, nodes, and leaves on the path from the root of the tree that configures multiple devices as leaves to the leaf, and select the path that configures the key tree and select it 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 executing upper key update processing and upper key encryption processing using a lower key In
Said key a predetermined node constituting a tree of subtrees to the sub-root node and the leaf nodes belonging to subtree which consists of a set or leaf corresponding to set the key based only on the sub-enabling key block (sub-EKB) A sub-enabling key block generating means of the sub- tree management entity for executing generation of
Using said sub enabling key block sub enabling key block generated by the generating means (sub EKB), an enabling key decodable only in the selected device corresponding to the lowermost Li-safe in the key tree An enabling key block generating means for generating a block (EKB);
An information processing system using an encryption key block characterized by comprising: The subtree is
Using an encryption key block according to the lowermost end node of one subtree to claim 1, characterized in that it has a layered structure of upper subtrees and subtree constructed as another subtree top node (sub-root) Information processing system. The sub-validating key block generating means
2. The information processing system using an encryption key block according to claim 1, wherein the information processing system has an authority to set and update a key corresponding to a node or leaf belonging to its own management subtree . During the subtree, each device belonging to the lowest layer of the subtree the lowermost leaf was a leaf corresponding to individual devices within a subtree, the leaves corresponding from the top node of the subtree that self belongs (sub-root) in the self-device 2. The information processing system using an encryption key block according to claim 1, wherein a node key and a leaf key set in a node, a leaf on a path to reach, and a leaf key are stored. The sub-validating key block generating means
The lower of its own management subtree, further to add the self-management subtree, and characterized in that setting pending one or more nodes or leaves of the lowermost node or in a leaf in the management subtree of the self as reserve nodes An information processing system using the encryption key block according to claim 1. The sub-activation key block generating means for managing the upper sub-tree that adds the new sub-tree to the end node is:
2. The encryption key block according to claim 1, wherein a key corresponding to a terminal node of an upper subtree which is a node for setting a new subtree is set as a vertex node (subroot) key of the new subtree. Information processing system used. The sub-activation key block generation means for managing the newly added sub-tree is as follows:
A sub-enabling key block (sub-EKB) based only on a key set corresponding to a node or leaf in the new sub-tree is generated, and a sub-EKB providing process for the enabling key block generating means is executed. The information processing system using the encryption key block according to claim 1. Sub enabling key block generating means for executing a revoke processing of the device, updates the node key set in nodes on a path leading to the leaf corresponding to the revoked device from the top node in the management subtree (sub-root), the renewed node key An updated sub-EKB configured as an encryption key that can be decrypted only by leaf devices other than the revoked device is generated and transmitted to the management entity of the upper subtree , and the sub-validation key block generating means of the upper subtree management entity generates the updated sub-EKB. send the sub enabling key block generation unit of the management Entite Lee further upper subtree generates a renewed sub-EKB updating the node key on the path from the provided terminal node in its own sub-route, the management of the uppermost subtree Entite sub-enabling key Lee Until the lock generating means executes the update sub-EKB generation and sending processing on the sub-enabling key block generating means units of subtrees of the management entity sequentially performs node key update on the path from the revoked device to the root, the rekeying The encryption key block according to claim 1, wherein the revoked process of the device is executed by performing a process of providing the generated updated sub-EKB to the validation key block generating means. Information processing system. Sub enabling key block generating means for executing a revoke processing in the subtree units, a set from the top node in the subtree managed (sub-root) in the nodes on the path to the terminal node corresponding to the revoked subtree node key The updated update sub-EKB is generated and transmitted to the sub-validation key block generation means for the management entity of the upper subtree. The sub-validation key block generation means for the management entity of the upper subtree is self- generated from the terminal node that provided the update sub-EKB. of sending the sub-enabling key block generation unit of the management Entite Lee further upper subtree generates a renewed sub-EKB updating the node key on a path leading to the sub-route, the sub-enabling key block generated to manage the top-level entity Update means for each entity. EKB to generate and execute a transmission process sequentially performs node key update on the path from the revoke subtree root, by performing providing processing to the enabling key block generation means updating sub-EKB produced by the key update The information processing system using an encryption key block according to claim 1, wherein the information processing system has a configuration for executing a revoke process in units of subtrees . The sub-validation key block generation means for executing revocation processing in units of lower subtrees is set to nodes other than the end node on the path from the vertex node (subroot) in the management subtree to the end node corresponding to the revocation subtree. is generated the updated update sub-EKB node keys sent to sub enabling key block generation unit of the management Entite Lee upper subtree, the sub enabling key block generation unit of the management Entite Lee upper subtree renewed sub EKB from providing the end node sends a sub-enabling key block generation unit of the management Entite Lee further upper subtree generates a renewed sub-EKB updating the node key on a path leading to its sub-route, the uppermost subtree until sub-enabling key block generating unit of the management Entite Lee, en Sequentially executes the update sub-EKB generation and sending processing in Itei unit performs node key update, except for the terminal node corresponding to the revoked subtrees on the path from the revoke subtree root key updating of the update sub-EKB produced by 2. The information processing system using an encryption key block according to claim 1, wherein a revoking process is performed in units of subtrees by performing a provision process to the validation key block generation unit. Said sub enabling key block generating means, device type, service type, encryption key block according to claim 1, characterized in that configured to perform the device of the management belonging to a common category such as the management unit type Information processing system using The management entity of the sub- tree is classified based on capability information indicating a data processing capability of a device that is a leaf of the key tree,
The sub-validation key block generation unit generates a sub-activation key block based only on a key set corresponding to a node or leaf having a common capability belonging to a managed sub-tree. An information processing system using the encryption key block described in 1. The enabling key block generating means includes an identifier of each management entity of a plurality of subtrees, capability information of each device belonging to the subtree, and sub-enabling key block (sub-EKB) information set corresponding to each subtree. And a capability management table that associates with each other. Based on the capability management table, a subtree including devices that can process distribution data for a device is selected , and can be decoded only by leaf-compatible devices belonging to the selected subtree. The information processing system using an encryption key block according to claim 1, wherein the information processing system has a configuration for generating an enabling key block (EKB). Sub enabling key block generation unit of the management entity of the newly added sub-tree for said key tree,該新regulations adds subtrees in nodes or sub-enabling key block (sub-EKB based only on a key set corresponding to the leaf The encryption key block according to claim 1 is used to execute a notification process of capability information of the generated sub-EKB and its own entity to the validation key block generation unit. Information processing system. Configure a key tree in which a key is associated with each root, node, and leaf on the path from the root of the tree that configures multiple devices as leaves to the leaf, and select the path that configures the key tree and select it Using the encryption key block in the information processing system that executes the above key update and the encryption process of the upper key by the lower key to generate an enabling key block (EKB) that can be decrypted only by a specific device and provides it to the device In the information processing method that was
Sub enabling key block generating means subtrees management entity is set corresponding to the belonging nodes or leaves the subtree which consists of a set node and leaf of the subtree to sub-route a predetermined node constituting the key tree Generating a sub-activation key block (sub-EKB) based only on the key;
In the enabling key block generating means, using said sub enabling key block generation sub enabling key block generating means (sub EKB), the selected device corresponding to the lowermost Li-safe in the key tree Generating an enabling key block (EKB) that can only be decrypted;
An information processing method using an encryption key block characterized by comprising: In the information processing method,
The sub-validating key block generating means
16. The information processing method using an encryption key block according to claim 15, wherein key setting / updating processing corresponding to a node or leaf belonging to its own management subtree is executed. The sub-activation key block generating means for managing the upper sub-tree that adds the new sub-tree to the end node is:
16. The information using the encryption key block according to claim 15, wherein a key corresponding to a terminal node of an upper subtree which is a node for setting a new subtree is set as a vertex node (subroot) key of the new subtree. Processing method. The sub-activation key block generation means for managing the newly added sub-tree is as follows:
The generate a new subtree of nodes or leaves in correspondingly sub enabling key block based only on a key set (sub-EKB), to perform the process of providing the sub-EKB to said enabling key block generating means An information processing method using the encryption key block according to claim 15. Sub enabling key block generating means for executing a revoke processing of the device, updates the node key set in nodes on a path leading to the leaf corresponding to the revoked device from the top node in the management subtree (sub-root), the renewed node key An updated sub-EKB configured as an encryption key that can be decrypted only by leaf devices other than the revoked device is generated and transmitted to the management entity of the upper subtree , and the sub-validation key block generating means of the upper subtree management entity generates the updated sub-EKB. send the sub enabling key block generation unit of the management Entite Lee further upper subtree generates a renewed sub-EKB updating the node key on the path from the provided terminal node in its own sub-route, the management of the uppermost subtree Entite sub-enabling key Lee Until the lock generating means executes the update sub-EKB generation and sending processing on the sub-enabling key block generating means units of subtrees of the management entity sequentially performs node key update on the path from the revoked device to the root, the rekeying 16. The information processing method using an encryption key block according to claim 15, wherein the revoking process of the device is executed by performing a process of providing the generated updated sub-EKB to the validation key block generating unit. . The sub-validation key block generation means for executing the revocation processing in units of lower subtrees uses the node key set in the node on the path from the vertex node (subroot) in the managed subtree to the terminal node corresponding to the revocation subtree. and generates the updated update sub-EKB is sent to the sub-enabling key block generation unit of the management Entite Lee upper subtree, sub enabling key block generation unit of the management Entite Lee upper subtree provided a renewed sub-EKB transmitted from the terminal node to the sub enabling key block generation unit of the management Entite Lee further upper subtree generates a renewed sub-EKB updating the node key on a path leading to its own sub-route, effective sub to manage the top-level entity Update support in entity units up to EKB to generate and execute a transmission process sequentially performs node key update on the path from the revoke subtree root, by performing providing processing to the enabling key block generation means updating sub-EKB produced by the key update The information processing method using an encryption key block according to claim 15, wherein revocation processing is performed in units of subtrees . The sub-validation key block generation means for executing revocation processing in units of lower subtrees is set to nodes other than the end node on the path from the vertex node (subroot) in the management subtree to the end node corresponding to the revocation subtree. is generated the updated update sub-EKB node keys sent to sub enabling key block generation unit of the management Entite Lee upper subtree, the sub enabling key block generation unit of the management Entite Lee upper subtree renewed sub EKB from providing the end node sends a sub-enabling key block generation unit of the management Entite Lee further upper subtree generates a renewed sub-EKB updating the node key on a path leading to its sub-route, the uppermost Butsuri until the sub-enabling key block generating unit of the management Entite Lee, Ente Sequentially executes the update sub-EKB generation and sending processing in Tay unit performs node key update, except for the terminal node corresponding to the revoked subtrees on the path from the revoke subtree root key updating of the update sub-EKB produced by 16. The information processing method using an encryption key block according to claim 15, wherein a revocation process in units of subtrees is executed by performing a provision process to the validation key block generation unit. The management entity of the sub- tree is classified based on capability information indicating a data processing capability of a device that is a leaf of the key tree,
16. The sub-activation key block generation unit generates a sub-activation key block based only on a key set corresponding to a node or leaf having a common capability belonging to a managed sub-tree. An information processing method using the encryption key block described in 1. The enabling key block generating means includes an identifier of each management entity of a plurality of subtrees, capability information of each device belonging to the subtree, and sub-enabling key block (sub-EKB) information set corresponding to each subtree. And a capability management table that associates with each other. Based on the capability management table, a subtree including a device capable of processing distribution data for a device is selected , and can be decoded only by a leaf-compatible device belonging to the selected subtree. 16. The information processing method using an encryption key block according to claim 15, wherein an enabling key block (EKB) is generated. Sub enabling key block generation unit of the management entity of the newly added sub-tree for said key tree,該新regulations adds subtrees in nodes or sub-enabling key block (sub-EKB based only on a key set corresponding to the leaf 16. The information processing using the encryption key block according to claim 15, wherein notification processing of capability information of the generated sub-EKB and its own entity is executed with respect to the validation key block generation means. Method. Configure a key tree by associating keys with the root, nodes, and leaves on the path from the root of the tree that configures multiple devices as leaves to the leaf, and select the path that configures the key tree and select it An activation key block in an information processing system that executes the above key update and the encryption process of the upper key with the lower key to generate an activation key block (EKB) that can be decrypted only by a specific device and provides it to the device ( EKB) A program recording medium recording a computer program that causes a generation process to be executed on a computer system, the computer program comprising:
The sub enabling key block generating means subtrees management entity, is set corresponding to the belonging nodes or leaves the subtree which consists of a set node and leaf of the subtree to sub-route a predetermined node constituting the key tree Generating a sub-validation key block (sub-EKB) based only on the key;
In the enabling key block generating means, using said sub enabling key block generation sub enabling key block generating means (sub EKB), the selected device corresponding to the lowermost Li-safe in the key tree Generating an enabling key block (EKB) that can only be decrypted;
A program recording medium comprising:

Images