JP2010288291A - Information processing system, information processing method and program recording medium - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To accomplish an information processing system and method for achieving efficient processing, in a processing using an effective key block (EKB) using a categorized tree structure. <P>SOLUTION: In a configuration for generating and providing to a device an EKB comprised of encrypted processing data of an upper key due to a lower key on a selection path of a key tree having a plurality of sub trees categorized and managed by a category entity, when requesting EKB generation, a configuration for generating a route key by itself and a configuration for requesting the generation of the route key to a key issuing center can be selectively performed. Furthermore, when the EKB is generated at the EKB issuing center, generation of a sub EKB is requested to the category entity, thereby the efficiency of EKB generation and management is improved. <P>COPYRIGHT: (C)2011,JPO&INPIT

Description

  The present invention relates to an information processing system, an information processing method, and a program recording medium, and more particularly, to a distribution system and method involving encryption processing for providing various data such as content to a specific legitimate user. In particular, a hierarchical key distribution method having a tree structure is used, and a key block generated according to a distribution device is used, for example, content key distribution as a content encryption key, or other various security is maintained. The present invention relates to an information processing system, an information processing method, and a program recording medium.

  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 distributed contents are reproduced by receiving data by a PC (Personal Computer) or game device owned by the user or mounting a storage medium, or a recording device in a recording / reproducing device attached to the PC, such as a memory. It is stored in a card, hard disk, etc., and used by new reproduction from the storage medium.

  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.

  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.

  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.

  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.

  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.

  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).

  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.

  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.

  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. In order to prevent unauthorized copying of the content key itself, the content key is encrypted and provided to the authorized user, and the encrypted content key can be decrypted using the decryption key possessed only by the authorized user and the content key can be used. A configuration has been proposed.

  In general, it is possible to determine whether or not the user is a legitimate user, 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.

  In the present invention, it is possible to securely transmit data only to legitimate users without relying on the mutual authentication processing between the sender and receiver of data as described above, and hierarchical key distribution. A configuration is proposed in which a sub-tree with a tree as a unit, that is, a category tree is formed, and an encryption key block that can be applied (decryption processing) within a plurality of category trees is used.

  Further, an enabling key block (EKB), which is an encryption key data block that can be decrypted in one or more selected category trees, is generated and used in common among devices belonging to each category tree, and which category tree An information processing system, an information processing method, and a program recording medium that enable efficient EKB generation and management processing by using an EKB type definition list indicating whether processing is possible, that is, decoding is possible For the purpose.

  Further, in the request for generating the enabling key block (EKB), the configuration for generating the root key itself and the configuration for requesting the key issuing center to generate the root key can be selectively executed, thereby requesting the EKB generation requester. It is possible to reduce the burden on the EKB, and in the EKB generation at the EKB issuing center, the EKB generation and the management process can be made more efficient by requesting the category entity that is the category administrator to generate the sub-EKB when the EKB generation is requested. It is an object to provide an information processing system, an information processing method, and a program recording medium.

The first aspect of the present invention is:
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 A configuration for providing an enabling key block (EKB) that can be decrypted only by a device that has encryption processing data of the upper key by the upper lower key and that can use the node key set corresponding to the selected path. An information processing system
The key tree is configured based on categories, and has a plurality of category trees as sub-trees managed by category entities,
The key issuing center (KDC) that generates the enabling key block (EKB)
In the generation of the enabling key block (EKB) based on the request of the EKB requester which is the request entity of the EKB generation, each of the one or more category entities that manage the decodable category tree of the generated enabling key block (EKB) A configuration for generating a sub-EKB generation request that can be processed in the category tree and generating an EKB that can be processed in one or more category trees based on the sub-validation key block (sub-EKB) received from the category entity. In an information processing system characterized by

  Furthermore, in an embodiment of the information processing system of the present invention, the key issuing center (KDC) has an EKB type definition list in which an EKB type identifier is associated with identification data of a category tree capable of EKB processing. The category tree identification data is extracted by searching the EKB type definition list based on the EKB type identifier included in the EKB generation request received from the EKB requester that is the entity that requests the generation of the EKB, and the extracted category tree is identified. Based on a sub-EKB generated by one or more category entities corresponding to data, an EKB that can be commonly used for the category tree set in the EKB type definition list is generated and provided. .

  Furthermore, in one embodiment of the information processing system of the present invention, the category entity that has received the sub-EKB generation request from the key issuing center (KDC) is associated with a node or leaf belonging to the category tree managed by the category entity. A sub-validation key block (sub-EKB) as an EKB that can be processed based on a key is generated.

  Furthermore, in an embodiment of the information processing system of the present invention, the key tree includes a plurality of root trees at the top, a top-level category tree directly connected to the root tree, and the top-level category tree. The category entity is composed of subcategory trees linked to the lower level, and the category entity manages the top level category tree and the subcategory tree connected to the lower level of the top level category tree as the management entity of the top level category tree. The category entity is an EKB that can be processed based on a key set corresponding to a node or leaf belonging to a top-level category tree managed by itself and a sub-category tree connected to a lower stage of the top-level category tree. Wherein the to is configured to generate sub-enabling key block (sub-EKB) of.

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 A configuration for providing an enabling key block (EKB) that can be decrypted only by a device that has encryption processing data of the upper key by the upper lower key and that can use the node key set corresponding to the selected path. Information processing method in the system
The key tree is configured based on categories, and has a plurality of category trees as sub-trees managed by category entities,
The key issuing center (KDC) that generates the enabling key block (EKB)
In the generation of the enabling key block (EKB) based on the request of the EKB requester that is the request entity for generating the EKB, each of the one or more category entities that manage the decodable category tree of the generated enabling key block (EKB) A sub-KB generation request that can be processed in the category tree is output, and an EKB that can be processed in one or more category trees is generated based on the sub-validation key block (sub-EKB) received from the category entity. There is an information processing method to do.

  Furthermore, in an embodiment of the information processing method of the present invention, the key issuing center (KDC) has an EKB type definition list in which an EKB type identifier is associated with identification data of a category tree capable of EKB processing. The category tree identification data is extracted by searching the EKB type definition list based on the EKB type identifier included in the EKB generation request received from the EKB requester that is the entity that requests the generation of the EKB, and the extracted category tree is identified. Based on a sub-EKB generated by one or more category entities corresponding to data, an EKB that can be commonly used for the category tree set in the EKB type definition list is generated and provided. .

  Furthermore, in one embodiment of the information processing method of the present invention, the category entity that receives the sub-EKB generation request from the key issuing center (KDC) is associated with a node or leaf belonging to the category tree managed by the category entity. A sub-validation key block (sub-EKB) as an EKB that can be processed based on the key is generated.

  Furthermore, in an embodiment of the information processing method of the present invention, the key tree includes a plurality of root trees at the top, a top level category tree directly connected to the root tree, and the top level category tree. The category entity is composed of subcategory trees linked to the lower level, and the category entity manages the top level category tree and the subcategory tree connected to the lower level of the top level category tree as the management entity of the top level category tree. The category entity is an EKB that can be processed on the basis of a key set corresponding to a node or leaf belonging to a top-level category tree managed by itself and a sub-category tree connected to the lower level of the top-level category tree. And generating a sub-enabling key block (sub-EKB).

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 A configuration for providing an enabling key block (EKB) that can be decrypted only by a device that has encryption processing data of the upper key by the upper lower key and that can use the node key set corresponding to the selected path. A computer-readable recording medium storing a computer program that causes a computer system to execute information processing in a system having the computer program,
Extracting the identification data of the category tree from the EKB type definition list in which the EKB type identifier is associated with the identification data of one or more category trees capable of EKB processing based on the EKB type identifier included in the EKB generation request; ,
Outputting a generation request for a sub-enabling key block (sub-EKB) that can be processed in each category tree to one or more category entities that manage the category tree corresponding to the extracted identification data of the category tree;
Generating an EKB that can be processed in one or more category trees based on a sub-enabling key block (sub-EKB) received from a category entity;
The program recording medium is characterized by comprising:

  Note that the program recording medium 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.

  Such a program recording medium defines a structural or functional cooperative relationship between a computer program and a recording 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 recording 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.

  The system in the description of the present invention is a logical set configuration of a plurality of devices, and is not limited to one in which each configuration device is in the same casing.

  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.

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

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

  Further, an enabling key block (EKB), which is an encryption key data block that can be decrypted in one or more selected category trees, is generated and used in common for devices belonging to each category tree, and which category tree By using the EKB type definition list indicating whether processing is possible, that is, decoding is possible, the efficiency of EKB generation management processing can be improved.

It is a figure explaining the structural example of the information processing system of this invention. It is a block diagram which shows the structural example of the recording / reproducing apparatus applicable in the information processing system of this invention. It is a tree block diagram explaining the encryption process of the various keys in the information processing system of this invention, and data. It is a figure which shows the example of the enabling key block (EKB) used for distribution of the various keys and data in the information processing system of this invention. It is a figure which shows the example of distribution and the example of a decoding process which used the key block (EKB) of the content key in the information processing system of this invention. It is a figure which shows the example of a format of the enabling key block (EKB) in the information processing system of this invention. It is a figure explaining the structure of the tag of the enabling key block (EKB) in the information processing system of this invention. It is a figure which shows the example of a data structure which delivers together the enabling key block (EKB), content key, and content in the information processing system of this invention. It is a figure which shows the example of a process in the device at the time of delivering together the enabling key block (EKB) in the information processing system of this invention, a content key, and a content. It is a figure explaining the response | compatibility at the time of storing the enabling key block (EKB) and content in a recording medium in the information processing system of this invention. It is the figure which compared the process of sending the enabling key block (EKB) and content key in the information processing system of this invention with the conventional sending process. It is a figure which shows the authentication process sequence by the common key encryption method applicable in the information processing system of this invention. It is the figure (the 1) which shows the data structure which delivers together the validation key block (EKB) and authentication key in the information processing system of this invention, and the process example in a device. It is the figure (the 2) which shows the data structure which delivers together the validation key block (EKB) and authentication key in the information processing system of this invention, and the process example in a device. It is a figure which shows the authentication process sequence by the public key cryptosystem applicable in the information processing system of this invention. It is a figure which shows the process which delivers together an enabling key block (EKB) and a content key using the authentication process by a public key cryptosystem in the information processing system of this invention. It is a figure which shows the process which delivers together an enabling key block (EKB) and encryption program data in the information processing system of this invention. It is a figure which shows the example of MAC value generation used for the production | generation of the content integrity check value (ICV) applicable in the information processing system of this invention. It is the figure (the 1) which shows the data structure which delivers together the enabling key block (EKB) and ICV generation key in the information processing system of this invention, and the processing example in a device. It is the figure (the 2) which shows the data structure which delivers together the enabling key block (EKB) and ICV production | generation key in the information processing system of this invention, and the processing example in a device. It is a figure explaining the copy prevention function at the time of storing the content integrity check value (ICV) applicable in the information processing system of this invention on a medium. It is a figure explaining the structure which manages the content integrity check value (ICV) applicable in the information processing system of this invention separately from a content storage medium. It is a figure explaining the example of the category classification | category of the hierarchical tree structure in the information processing system of this invention. It is a figure explaining the production | generation process of the simplification validation key block (EKB) in the information processing system of this invention. It is a figure explaining the production | generation process of the enabling key block (EKB) in the information processing system of this invention. It is a figure explaining the simplification validation key block (EKB) (example 1) in the information processing system of this invention. It is a figure explaining the simplification validation key block (EKB) (example 2) in the information processing system of this invention. It is a figure explaining the category tree management structure of the hierarchical tree structure in the information processing system of this invention. It is a figure explaining the detail of the category tree management structure of the hierarchical tree structure in the information processing system of this invention. It is a figure explaining the category tree management structure of the hierarchical tree structure in the information processing system of this invention. It is a figure explaining the reserve node in the category tree management structure of the hierarchical tree structure in the information processing system of this invention. It is a figure explaining the new category tree registration process sequence in the category tree management structure of the hierarchical tree structure in the information processing system of this invention. It is a figure explaining the relationship between the new category tree and the upper category tree in the category tree management configuration of the hierarchical tree structure in the information processing system of the present invention. It is a figure explaining the sub EKB used by the category tree management structure of the hierarchical tree structure in the information processing system of this invention. It is a figure explaining the device revocation process by the category tree management structure of the hierarchical tree structure in the information processing system of this invention. It is a figure explaining the device revocation process sequence in the category tree management structure of the hierarchical tree structure in the information processing system of this invention. It is a figure explaining the update sub EKB at the time of device revocation in the category tree management structure of the hierarchical tree structure in the information processing system of this invention. It is a figure explaining the category tree revocation process by the category tree management structure of the hierarchical tree structure in the information processing system of this invention. It is a figure explaining the category tree revocation process sequence in the category tree management structure of the hierarchical tree structure in the information processing system of this invention. It is a figure explaining the relationship between the revocation category tree and the upper category tree in the category tree management configuration of the hierarchical tree structure in the information processing system of the present invention. It is a figure explaining the capability setting in the category tree management structure of the hierarchical tree structure in the information processing system of this invention. It is a figure explaining the capability setting in the category tree management structure of the hierarchical tree structure in the information processing system of this invention. It is a figure explaining the capability management table structure which the key issuing center (KDC) manages in the information processing system of this invention. It is an EKB production | generation process flowchart based on the capability management table which the key issuing center (KDC) manages in the information processing system of this invention. It is a figure explaining the capability notification process at the time of new category tree registration in the information processing system of this invention. It is a figure explaining the structure of the category tree in the information processing system of this invention. It is a figure explaining the relationship with an EKB requester, a key issue center, a top level category entity (TLCE), and a processing example in the information processing system of the present invention. It is a figure explaining the hardware structural example of the EKB requester in the information processing system of this invention, a key issue center, and a top level category entity (TLCE). It is a figure explaining the device node key (DNK) which the device in the information processing system of this invention has. It is a figure explaining the data structure of the EKB type definition list in the information processing system of this invention. It is a figure which shows the EKB type registration process flow in the information processing system of this invention. It is a figure which shows the EKB type invalidation processing flow in the information processing system of this invention. It is a figure which shows the tree change notification process flow in the information processing system of this invention. It is a figure which shows the EKB type list request | requirement processing flow in the information processing system of this invention. It is a figure explaining the production | generation process of the sub EKB in the information processing system of this invention. It is a figure explaining the production | generation process of the sub EKB in the information processing system of this invention. It is a figure explaining the process which produces | generates the EKB synthesized | combined from the sub EKB in the information processing system of this invention. It is a figure explaining the production | generation process of sub EKB when there exists a revoke device in the information processing system of this invention. It is a figure explaining the process which produces | generates EKB synthesized | combined from sub EKB when there exists a revoke device in the information processing system of this invention. It is a figure explaining the data structure of EKB synthesized from sub EKB in the information processing system of the present invention. It is a figure explaining the data structure of EKB synthesized from sub EKB in the information processing system of the present invention. It is a figure explaining the data structure of EKB synthesize | combined from sub EKB when there exists a revoke device in the information processing system of this invention. It is a figure explaining the revoke process in the data delivery type | system | group in the information processing system of this invention. It is a figure explaining the revoke process in the self-recording type | system | group system in the information processing system of this invention.

[System Overview]
FIG. 1 shows an example of a content distribution system to which the information 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.

  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, and the like, while the device on the content reception side 20 includes a personal computer (PC) 21. A portable device 23 such as a portable device (PD) 22, a mobile phone, a PDA (Personal Digital Assistants), a recording / reproducing device 24 such as a DVD or a CD player, and a dedicated reproduction device 25 such as a game terminal. Each device on the content receiving side 20 acquires the content provided from the content distribution side 10 from a communication means such as a network or the medium 30.

[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.

  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.

  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.

  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.

  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.

  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.

[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.

  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.

  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 of FIG. 3 are leaf keys assigned to the respective devices 0 to 15, respectively. Keys described from the topmost KR (root key) to the second node (node) from the bottom : KR to K111 are used as node keys.

  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.

  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.

  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.

  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.

  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.

  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), the system (devices 0, 1) , 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.

  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).

  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.

  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 the updated key K (t) R. The index in FIG. 4A indicates the absolute address of the node key and leaf key used as the decryption key.

  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.

  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.

  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. .

[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.

  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, and 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.

[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.

  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.

  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.

The tag is set to indicate where the data Enc (Kxxx, Kyyy) is located in the tree structure. Since the key data Enc (Kxxx, Kyyy)... Stored in the data portion is merely enumerated data of the encrypted keys, the key data Enc (Kxxxx, Kyyy). The position can be discriminated. Without using the above-described tag, using the node index corresponding to the 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)
Although it is possible to adopt a data configuration such as ..., a configuration using such an index results in redundant data and increases the amount of data, which is not preferable in 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.

  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.

[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.

  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.

  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.

  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.

  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.

  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. .

  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 acquired with its own leaf key and node key, and only the device having a legitimate right can obtain the content. It can be used after being decrypted.

  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.

  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.

  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.

  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.

  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.

  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.

  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.

  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.

  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.

  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.

[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.

  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.

  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.

  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.

  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.

  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.

  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).

  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.

  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, An example in which an authentication key that can be decrypted only for 1 and 2 is distributed will be shown.

  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.

  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.

  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.

  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.

  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.

  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.

[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.

  A's public key certificate, Ra, Rb, Av, electronic signature B that receives 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.

  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 an 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.

  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.

  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.

  If an illegality or a mismatch is found during the verification of the electronic signature or the received data, the processing is interrupted assuming that the mutual authentication has failed.

  FIG. 16 shows an example of content key distribution processing using public key authentication and an 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.

  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 .

  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.

  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.

[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.

  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.

  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.

  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.

[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.

  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.

  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).

  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.

[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.

  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. An example is shown in which a check value generation key Kicv that can be decrypted only for 0, 1, and 2 is distributed.

  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).

  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.

  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.

  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.

  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.

  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.

  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.

  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.

  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.

  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. .

  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.

  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.

[Category classification 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 for performing efficient key update processing, encryption key distribution, and data distribution by classifying the hierarchical tree structure defining node keys and the like for each device category has been described below. To do.

  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.

  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.

  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.

  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 sub-category node, and further included in the category of the telephone with a music playback function. [PHS] node 2308 and [mobile phone] node 2309 can be set.

  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.

  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.

[Key distribution configuration by simplified EKB (1)]
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.

  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.

  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.

  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.

  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.

  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.

  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.

  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 second and third 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 first 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.

  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 first 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.

  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.

[Key distribution configuration using simplified EKB (2)]
A configuration that further simplifies the enabling key block (EKB) generated based on the simplified tree shown in FIG. 26 to reduce the amount of data and enables efficient processing will be described.

  The configuration described with reference to FIG. 26 is re-executed by selecting an end node that can decrypt the enabling key block (EKB) or a path constituting a bifurcated tree with leaves at the bottom and omitting unnecessary nodes. It was a reconstructed hierarchical tree that was built. 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.

  In the reconstructed hierarchical tree shown in FIG. 26 (a), the update key key (EKB) shown in FIG. 26 (b) is obtained so that the updated root key K (t) root can be acquired in the leaves a, g, and j. To deliver. In the processing of the enabling key block (EKB) in FIG. 26B, the leaf j can acquire the root key: K (t) root by one-time decryption processing of Enc (Kj, K (t) root). However, after the leaves a and g obtain K (t) 0 by decoding Enc (Ka, K (t) 0) or Enc (Kg, K (t) 0), Enc (K ( t) The decryption process of 0, K (t) root) is executed to obtain the root key: K (t) root. That is, the leaves a and g need to execute the decryption process twice.

  26, when the node K0 is performing its own management as the management node of the lower leaves a and g, for example, the lower leaf management is performed as a sub-root node described later. Is effective in confirming that the leaves a and g have acquired the update key, but if the node K0 is not managing the lower leaf, or even if it is, If the update key distribution is permitted, the reconstructed hierarchical tree shown in FIG. 26A is further simplified, the key of the node K0 is omitted, and the enabling key block (EKB) is generated and distributed. May be.

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

  As shown in FIG. 27A, a simplified tree in which the node K0 is omitted from the reconstructed hierarchical tree shown in FIG. An enabling key block (EKB) for renewal key distribution is generated based on these simplified trees. The tree shown in FIG. 27A is a reconstructed hierarchical tree that is reconstructed only by a path that directly connects a leaf that can decrypt the enabling key block (EKB) and the root. An enabling key block (EKB) for renewal key distribution is configured based only on keys corresponding to the leaves of this reconstructed hierarchical tree.

  The example of FIG. 27A is a configuration example in which the end is a leaf. However, for example, when a key is distributed to the highest node or a plurality of middle and lower nodes, the highest node and the middle node are also used. It is possible to generate an enabling key block (EKB) based on a simplified tree in which lower nodes are directly connected to execute key distribution. As described above, the reconstructed hierarchical tree has a configuration in which the vertex nodes constituting the simplified tree and the end nodes or leaves constituting the simplified tree are directly connected. In this simplified tree, the number of branches from the vertex node is not limited to 2, but can be configured as a tree having three or more branches according to the distribution node or the number of leaves.

  The enabling key block (EKB) described with reference to FIG. 25 stores data obtained by encrypting all keys from the leaves a, g, j to Kroot, and the enabling key block described with reference to FIG. (EKB) has a configuration in which leaf keys of leaves a, g, and j, K0 as a common node of a and g, and a root key are stored, but is based on the simplified hierarchical tree shown in FIG. Since the key of the node K0 is omitted, the validation key block (EKB) becomes an validation key block (EKB) with a smaller amount of data as shown in FIG.

  The enabling key block (EKB) in FIG. 27 (b) has a 3-bit tag, similar to the enabling key block (EKB) in FIG. 26 (b). As described with reference to FIG. 26, the second and third bits indicate 0 if there is data in the left (L) and right (R) directions, and 1 if there is no data. The first 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.

  In the enabling key block (EKB) of FIG. 27B, each leaf a, g, j is Enc (Ka, K (t) root) or Enc (Kg, K (t) root) Enc (Kj, The root key: K (t) root can be acquired by one decryption process of K (t) root).

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

  As in the enabling key block (EKB) described with reference to FIG. 26 or FIG. 27, a simplified new tree configuration configured only by the device of the delivery destination is constructed, and only the leaves constituting the constructed tree are configured. Alternatively, by generating an enabling key block (EKB) using only the keys of the leaf and the common node, it becomes possible to generate an enabling key block (EKB) with a small amount of data, and the enabling key block (EKB). Data distribution can be performed efficiently.

  The simplified hierarchical tree configuration can be used particularly effectively in the category tree unit EKB management configuration set as a sub-tree described later. The category tree is an aggregate block of a plurality of nodes or leaves selected from the nodes or leaves constituting the tree structure as the key distribution structure. The category tree 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. Etc., and a set of various modes. In one category tree, devices classified into a common category are gathered. For example, a simplified tree similar to the above is reconstructed by using vertex nodes (sub-roots) of a plurality of category trees, and an EKB is generated. By doing so, it becomes possible to generate and distribute a simplified enabling key block (EKB) that can be decrypted by the devices belonging to the selected category tree. The management configuration for each category tree will be described in detail later.

  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.

[EKB management configuration for each category tree]
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 a category tree. The category tree 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. Etc., and a set of various modes.

  The category tree will be described with reference to FIG. FIG. 28A is a diagram for explaining a management configuration of a tree in a category tree unit. One category tree is shown as a triangle in the figure. For example, one category tree 2701 includes a plurality of nodes. (B) shows a node configuration in one category tree. One category tree is constituted by a two-stage bifurcated tree having one node as a vertex. Hereinafter, the vertex node 2702 of the category tree is referred to as a sub-root.

  The end of the tree is constituted by leaves, ie devices, as shown in (c). A device belongs to one of category trees constituted by a tree having a plurality of devices as leaves and a vertex node 2702 as a sub-root.

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

  FIG. 29A is a diagram for explaining the hierarchical structure in a simplified manner, in which category trees A01 to Ann are configured several steps below Kroot, and further below category trees A1 to An, The category trees B01 to Bnk, and further, the category trees C1 to Cnq are set below the category trees B01 to Bnk. Each category tree has a tree shape composed of a plurality of stages of nodes and leaves, as shown in FIGS.

  For example, the configuration of the category tree Bnk includes a plurality of nodes from the sub-root 2811 to the end node 2812 as shown in FIG. This category tree has an identifier Bnk, and the node key management corresponding to the nodes in the category tree Bnk is performed independently by the category tree Bnk, thereby managing the lower (child) category tree set with the end node 2812 as the vertex. To do. On the other hand, the category tree Bnk is under the management of the upper (parent) category tree Ann having the sub-root 2811 as a terminal node.

  As shown in (c), the category tree 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 category tree has an identifier Cn3, and the management of the leaf (device) corresponding to the end node 2852 is executed by executing the node key and leaf key management corresponding to the nodes and leaves in the category tree Cn3 independently of the category tree Cn3. . On the other hand, the category tree Cn3 is under the management of the upper (parent) category tree Bn2 having the sub-root 2851 as a terminal node. Key management in each category tree includes, for example, key update processing, revocation processing, and the like, which will be described in detail later.

  The device which is the leaf of the lowest category tree stores the node key and leaf key of each node located in the path from the leaf key of the category tree to which the device belongs to the sub-root node which is the vertex node of the category tree 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.

  The configuration of the category tree will be further described with reference to FIG. A category tree 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) category trees corresponding to the end nodes managed by the category tree or the number of devices as leaves.

  When the upper and lower category tree configuration as shown in FIG. 30A is embodied, the form shown in FIG. 30B is obtained. The root tree is a topmost tree having a root key. The category trees A, B, and C are set as a plurality of lower category trees at the end node of the root tree, and the category tree D is set as the lower category tree of the category tree C. When the category tree C2901 holds one or more of its end nodes as reserve nodes 2950 and increases the category tree managed by itself, the category tree C2901 further includes a category tree C′2902 having a multi-level tree configuration as a reserve node 2950. As a vertex node, the management end node 2970 can be increased, and the increased lower category tree can be added to the management end node.

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

  In each category tree, an enabling key block (EKB) is configured for each category tree, and key update and revoke processing are performed for each category tree. As shown in FIG. 31, each category tree A, A ′, A ″ is set with an enabling key block (EKB) for each category tree. For example, a certain device manufacturer that manages A ″ in common can manage it collectively.

[New category tree registration process]
Next, a new category tree registration process will be described. The registration processing sequence is shown in FIG. This will be described according to the sequence of FIG. The new (child) category tree (N-En) newly added in the tree structure executes a new registration request for the upper (parent) category tree (P-En). Each category tree has a public key in accordance with the public key cryptosystem, and the new category tree sends its own public key to the upper category tree (P-En) upon a registration request.

  Upon receiving the registration request, the higher-level category tree (P-En) transfers the received public key of the new (child) category tree (N-En) to a certificate authority (CA) and signs the CA signature. The public key of the added new (child) category tree (N-En) is received. These procedures are performed as a mutual authentication procedure between the upper category tree (P-En) and the new (child) category tree (N-En).

  When the authentication of the new registration request category tree is completed by these processes, the upper category tree (P-En) permits registration of the new (child) category tree (N-En), and the new (child) category tree ( N-En) node key is sent to the new (child) category tree (N-En). This node key is one node key of the end node of the upper category tree (P-En), and corresponds to the vertex node of the new (child) category tree (N-En), that is, the sub-root key.

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

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

  When the new (child) category tree (N-En) generates a sub-EKB composed of node keys and leaf keys in the new (child) category tree (N-En), this is converted into a higher-level category tree (P-En). Send.

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

  The key distribution center (KDC) can generate various types of EKBs, that is, EKBs that can be decrypted only by a specific category tree or device, based on the sub-EKBs of all category trees. The EKB in which the category tree or device that can be decrypted in this way is set is provided to the content provider, for example, and the content provider encrypts the content key based on the EKB and provides it via the network or stored in a recording medium. Thus, it is possible to provide content that can be used only on a specific device.

  The registration process of the new category tree with respect to the sub-EKB key issuing center (KDC) is not limited to the method of sequentially transferring the sub-EKB through the upper category tree and executing it. Alternatively, a process of registering in the key issuing center (KDC) directly from the new registration category tree may be executed.

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

  As shown in FIG. 33, when a new category tree is set in the upper category tree, one node 3201 of a terminal node that is a leaf of the upper category tree and a vertex node 3202 of the new added category tree are set as equal nodes. The That is, one terminal node that is one leaf of the upper node is set as a sub-root of the newly added category tree. By setting in this way, the newly added category tree is validated under the entire tree structure.

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

  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. Each category tree, as shown in FIG. 34 (b), is a valid end node or a higher node key encrypted with a leaf key, and a higher node key is encrypted with an upper node key, and the encryption that reaches the sub-root is made deeper in order. It has an EKB composed of digitized data and manages it.

[Revocation processing under category tree management]
Next, a device or category tree revocation (exclusion) process in a configuration for managing the key distribution tree configuration in units of category trees 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 of revoking a device that is a specific leaf from the entire tree. However, in the configuration based on the category tree management of the tree, the revocation process can be executed for each category tree. Become.

  The revoke process in the tree configuration under category tree management will be described with reference to FIG. FIG. 35 is a diagram for explaining device revoke processing by a category tree at the bottom of the category trees constituting the tree, that is, a category tree managing individual devices.

  FIG. 35A shows a key distribution tree structure based on category tree management. A root node is set at the top of the tree, and a category tree A01 to Ann is formed several stages below, a category tree of B01 to Bnk is further formed at a lower stage thereof, and a category tree of C1 to cn is further formed at a lower stage thereof. . In the lowest category tree, it is assumed that the end node (leaf) is an individual device, for example, a recording / reproducing device, a reproduction-only device, or the like.

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

  If there is a device to be revoked, for example, a device 3432, in the leaf that is the terminal node, the category tree Cn, 3430 is an activation key block constituted by the node key and leaf key in the category tree Cn that has been independently updated. (Sub-EKB) is generated. 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 the category tree 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 that is the vertex key of the category tree in the revocation processing configuration described with reference to FIGS.

  The activation key block (sub-EKB) updated by the category tree Cn, 3430 by the revocation process is transmitted to the upper category tree. In this case, the upper category tree is the category tree Bnk, 3420, and is a category tree having the vertex node 3431 of the category tree Cn, 3430 as a terminal node.

  When category tree Bnk, 3420 receives the enabling key block (sub EKB) from lower category tree Cn, 3430, category tree Bnk, 3420 corresponds to vertex node 3431 of category tree Cnk, 3430 included in the key block. The terminal node 3431 is set as a key updated in the lower category tree Cn, 3430, and the update processing of the sub EKB of its own category tree Bnk, 3420 is executed. FIG. 35 (c) shows the tree structure of the category tree Bnk, 3420. In the category tree Bnk, 3420, the node key to be updated is a node key on the path from the sub-root 3421 in FIG. 35C to the terminal node 3431 constituting the category tree including the revocation device. That is, the node key of each of the nodes 3421, 3424, and 3425 constituting the path connected to the node 3431 of the category tree that has transmitted the update sub-EKB is to be updated. The node key of each node is updated to generate a new update sub-EKB of the category tree Bnk, 3420.

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

  When the category tree Ann, 3410 receives the enabling key block (sub EKB) from the lower category tree Bnk, 3420, the category tree Ann, 3410 corresponds to the vertex node 3421 of the category tree Bnk, 3420 included in the key block. The terminal node 3421 is set as a key updated in the lower category tree Bnk, 3420, and the update processing of the sub EKB of its own category tree Ann, 3410 is executed. FIG. 35D shows a tree structure of the category tree Ann, 3410. In the category tree 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 node 3421 of the category tree that has transmitted the updated sub EKB from the sub-route 3411 in FIG. It is. The node key of each node is updated to generate a new update sub EKB of the category tree Ann, 3410.

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

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

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

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

  The upper category tree updates the node key existing in the path from the sub-root of the upper category tree to the terminal node (node 100) 3601, and generates a new updated sub-EKB. The update sub EKB is as shown in FIG. The updated key is shown underlined and [']. The node key on the path from the end node updated to the sub-root is updated as described above to obtain an updated sub EKB in the category tree.

  Next, processing when a revocation target is a category tree, that is, category tree revocation processing will be described.

  FIG. 38A shows a key distribution tree structure based on category tree management. A root node is set at the top of the tree, and a category tree A01 to Ann is formed several stages below, a category tree of B01 to Bnk is further formed at a lower stage thereof, and a category tree of C1 to cn is further formed at a lower stage thereof. . In the lowest category tree, it is assumed that the end node (leaf) is an individual device, for example, a recording / reproducing device, a reproduction-only device, or the like.

  Here, a case where the revoke process is executed on the category trees Cn and 3730 will be described. The lowermost category tree Cn, 3730 has a vertex node 3431 as shown in FIG. 38B, and has a plurality of devices in a leaf which is a terminal node.

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

  When the category tree Bnk, 3720 executes the revocation of the lower category tree Cn, 3730, the category tree Bnk, 3720 updates the end node 3731 of the category tree Bnk, 3720 corresponding to the vertex node 3731 of the category tree Cnk, 3730, and further, the revocation category. The node key on the path from the tree 3730 to the sub-root of the category tree 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. 38C to the terminal node 3731 constituting the vertex node of the revoke category tree. 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 category tree Bnk, 3720.

  Alternatively, when the category tree Bnk, 3720 executes the revocation of the lower category tree Cn, 3730, the terminal node 3731 of the category tree Bnk, 3720 corresponding to the vertex node 3731 of the category tree Cnk, 3730 is not updated, and the revocation is performed. An updated sub-EKB may be generated by updating the node key excluding the terminal node 3731 on the path from the category tree 3730 to the sub-root of the category tree Bnk, 3720 to generate an enabling key block.

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

  When the category tree Ann, 3710 receives the enabling key block (sub EKB) from the lower category tree Bnk, 3720, the category tree Ann, 3710 corresponds to the vertex node 3721 of the category tree Bnk, 3720 included in the key block. The terminal node 3721 is set as a key updated in the lower category tree Bnk, 3720, and the sub EKB update process of its own category tree Ann, 3710 is executed. FIG. 38D shows the tree structure of the category tree Ann, 3710. In the category tree 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 node 3721 of the category tree that has transmitted the updated sub EKB from the sub-root 3711 in FIG. It is. The node key of each node is updated to generate a new update sub-EKB of the category tree Ann, 3710.

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

  FIG. 39 shows a sequence diagram of category tree revocation processing. The processing procedure will be described with reference to the sequence diagram of FIG. First, the category tree management category tree (E-En) that intends to revoke the category tree performs the key update necessary for eliminating the revoked terminal node in the category tree management category tree (E-En). A new sub-EKB (E) of the category tree management category tree (E-En) is generated. The updated sub-EKB (E) is sent to the upper category tree. The upper (parent) category tree (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 the path from the terminal node to the sub-root. An updated sub EKB (P1) in which the node key is updated is generated. These processes are sequentially executed in the upper category tree, 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 the updated sub-EKBs of all category trees. The update EKB becomes an encryption key block that cannot be decrypted by a device belonging to the revoked category tree.

  FIG. 40 illustrates a correspondence between the revoked lower category tree and the revoked upper category tree. The terminal node 3901 of the upper category tree is updated by revoking the category tree, and a new sub-EKB is generated by updating the node key existing in the path from the terminal node 3901 to the subroot in the tree of the upper category tree. As a result, the node key of the vertex node 3902 of the revoked lower category tree and the node key of the end node 3901 of the upper category tree are inconsistent. Since the EKB generated by the key distribution center (KDC) after the category tree is revoked is generated based on the key of the terminal node 3901 updated in the upper category tree, the lower category tree that does not hold the updated key. The device corresponding to this leaf cannot decrypt the EKB generated by the key distribution center (KDC).

  In the above description, the revoking process of the lowermost category tree for managing the device has been described. However, the process for revoking the category tree management category tree in the middle of the tree by the upper category tree is performed by the same process as described above. Is possible. By revoking the middle entity management category tree, it is possible to revoke all multiple category trees and devices belonging to the subordinates of the revoked category tree management category tree in a lump.

  As described above, by executing the revocation in the unit of category tree, the revocation process can be performed in a simple process as compared with the revocation process executed in units of each device.

[Category tree capability management]
Next, in the key distribution tree configuration in units of category trees, a processing configuration that manages the capabilities (Capability) allowed by each entity and performs content distribution according to the capabilities 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.

  FIG. 41 shows a configuration example of a category tree in which capabilities are defined. A root node is located at the top of the key distribution tree structure, a plurality of category trees are connected to the lower layer, and each node has two branches. Here, for example, the category tree 4001 is defined as a category tree having a capability that allows any one of the audio reproduction modes A, B, and C. Specifically, for example, when music data compressed by a certain audio compression program-A, B, or C method is distributed, a device belonging to a category tree configured under the category tree 4001 has a process of decompressing the compressed data. Is possible.

  Similarly, the category tree 4002 has the capability of processing the audio playback mode B or C, the category tree 4003 has the capability of processing the audio playback mode A or B, the category tree 4004 has the capability of processing the audio playback mode B, and the category tree 4005 has the capability of processing the audio playback mode C. It is defined as having a category tree.

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

  Such capability information of each category tree 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 category tree. 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.

  In FIG. 41, the capability information is defined for all category trees. However, it is not always necessary to define the capability information for all category trees as shown in FIG. 41. For example, as shown in FIG. In this way, the capability is defined only for the lowermost category tree to which the device belongs, and the capabilities of the devices belonging to the lowermost category tree are managed in the key issuing center (KDC), so that the device that can be processed by the content provider is obtained. Only an enabling key block (EKB) that can be decrypted may be generated based on capability information defined in the category tree at the bottom. In FIG. 42, the capabilities in the category tree 4101 = 4105 in which devices are defined in the end nodes are defined, and the capabilities for these category trees are managed in the key issuing center (KDC). For example, the category tree 4101 belongs to a device capable of processing the method B for sound reproduction and the method r for image reproduction. The category tree 4102 includes devices that can process the method A for audio reproduction and the method q for image reproduction.

  FIG. 43 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, a category tree ID as an identifier for identifying each category tree, a capability list indicating the capabilities defined in the category tree, and this capability list is, for example, an audio data reproduction processing method (A ) Can be processed [1], if it cannot be processed [0], if the audio data reproduction processing method (B) can be processed [1], if it cannot be processed [0], etc. , [1] or [0] is set for each bit as to whether data processing in various modes is possible. Note that the capability information setting method is not limited to such a format, and other configurations may be used as long as the capabilities of the category tree management device can be identified.

  In the capability management table, when the sub-EKB of each category tree or the sub-EKB is stored in another database, the identification information of the sub-EKB is stored, and further, the sub-root node identification data of each category tree is stored. Stored.

  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. 44, the generation process of the activation key block based on the capability information will be described.

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

  Next, in step S4302, a list of selected category tree IDs configured by the selected category tree is generated. Next, in step S4303, a path required for the tree configured by the selected category tree ID (a path of the key distribution tree configuration) is selected. In step S4304, it is determined whether or not all paths included in the list of selected category tree 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 category trees are selected.

  When all the paths included in the list of selected category tree IDs have been selected, the process advances to step S4305 to construct a key distribution tree structure constituted only by the selected path and the selected category tree.

  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 category tree 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 category tree based on the sub-EKB and the updated node key generated in step S4306. ) Is generated. 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.

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

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

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

  Upon receiving the registration request, the higher-level category tree (P-En) transfers the received public key of the new (child) category tree (N-En) to a certificate authority (CA) and signs the CA signature. The public key of the added new (child) category tree (N-En) is received. These procedures are performed as a mutual authentication procedure between the upper category tree (P-En) and the new (child) category tree (N-En).

  When the authentication of the new registration request category tree is completed by these processes, the upper category tree (P-En) permits registration of the new (child) category tree (N-En), and the new (child) category tree ( N-En) node key is sent to the new (child) category tree (N-En). This node key is one node key of the end node of the upper category tree (P-En), and corresponds to the vertex node of the new (child) category tree (N-En), that is, the sub-root key.

  When this node key transmission is completed, the new (child) category tree (N-En) constructs a tree structure of the new (child) category tree (N-En) and receives the sub-root of the received vertex node at the vertex of the constructed tree. A key is set, and a key for each node and leaf is set to generate an enabling key block (sub-EKB) in the category tree. On the other hand, the upper category tree (P-En) also generates a sub-EKB in the upper category tree (P-En) to which the terminal node to be activated is added by adding a new (child) category tree (N-En). .

  When the new (child) category tree (N-En) generates a sub-EKB composed of node keys and leaf keys in the new (child) category tree (N-En), this is converted into a higher-level category tree (P-En). Further, the capability information about the device managed by its own category tree is notified to the upper category tree.

  The upper category tree (P-En) that has received the sub-EKB and capability information from the new (child) category tree (N-En) is updated from the received sub-EKB and capability information and the upper category tree (P-En). The sub-EKB is transmitted to the key distribution center (KDC).

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

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

  In this configuration, the key issuing center (KDC) receives an EKB issuing request from an EKB requester that desires to use and issue an EKB such as a content provider. The EKB issue request includes an EKB type identification number indicating the EKB type defined in the EKB type definition list, and the key issue center (KDC) can be processed (decrypted) in one or more category trees according to the EKB type identification number. A new EKB is generated.

  When generating the EKB, the key distribution center (KDC), based on the top node identifier of each category tree set corresponding to the EKB type identification number in the EKB type definition list, is a top level category as a category tree manager. -An EKB that requests generation of a sub-EKB from an entity (TLCE: Top Level Category Entity), receives a sub-EKB generated by each TLCE, and performs a process of synthesizing a plurality of sub-EKBs to be processed in a plurality of category trees. Is generated.

  In this configuration, an EKB issuing requester such as a content provider (CP) can select a specific category tree based on the EKB type definition list. An EKB issuance requester such as a content provider (CP) refers to the EKB type definition list and requests the key issuance center (KDC) to issue an EKB that can be processed in the specific category tree. The key issuing center (KDC) makes a sub-EKB issuing request to the management entity of the selected category tree based on the EKB issuing request, and the management entity of each selected category tree is revoked from the management entity. A sub-EKB that can be processed only by a non-legitimate device is generated and transmitted to the key issuing center (KDC). The key issuance center (KDC) generates one EKB that can be processed only in the selected category tree requested by the EKB issuance requester by combining one or more sub-EKBs, and provides the EKB issuance requester. The EKB issuance requester receives the EKB from the key issuance center (KDC), and executes the distribution of the encryption key or the encrypted content that can be decrypted only with the key that can be obtained by the EKB process.

First, the configuration entity in the following description will be briefly described.
Key distribution center (KDC)
An enabling key block (EKB) is issued, and an EKB type definition list relating to the issued EKB is managed.

Top Level Category Entity (TLCE)
An entity that manages a category tree. For example, a format holder for recording devices. The category tree is managed, and a sub EKB that is an EKB that can be processed (decrypted) in a device in the managed category tree is generated and submitted to the key distribution center (KDC).

EKB requester (EKB requester)
For example, a content provider (CP) that executes an electronic content distribution (ECD) service, such as an entity that provides various contents such as images, sounds, and programs to a user device, or a format holder for a recording medium Content and media are provided as a setting that uses a key that can be acquired by EKB processing as an encryption key for the provided content. A request for issuing an EKB used at this time is sent to the key issuing center (KDC).

  For example, the content provider (CP) encrypts and distributes its content using the EKB root key generated by the key issuing center (KDC). The format holder of the recording medium writes and distributes the EKB when the recording medium is manufactured, and the recorded content is encrypted using the root key of the EKB.

(TLCE and category-based tree management)
The category-based tree management has been described above. The relationship between the top-level category entity (TLCE) and the category tree will be described with reference to FIG.

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

  In FIG. 46, the uppermost root tree has, for example, an eight-stage configuration (number of node stages), and the top node of the category tree is set at the lowermost stage of the root tree. A plurality of category trees can have an upper and lower relationship, and the category tree C corresponds to the upper level of the category tree D in FIG.

  A category tree directly connected to the root tree at the top is called a top level category tree, and an entity that manages the top level category tree is called a top level category entity (TLCE). In FIG. 46, A, B, and C are top level categories, and the entity that manages them is a top level category entity (TLCE). A top level category entity (TLCE) is basically responsible for managing the entire tree below it. In other words, the TLCE that manages the tree C in FIG. If there is a lower category tree below D, the lower category tree is also managed. However, for example, it is possible to place a category entity (Sub Category Entity) that manages the lower category tree D and delegate responsibility and rights thereof.

  Each device such as a recording / playback apparatus that uses content is assigned to a leaf of a tree by a top-level category entity (TLCE), and keys of some nodes between paths from the leaf to the root are used. Own. A set of node keys possessed by one device is called a device node key (DNK). The top-level category entity (TLCE) determines how many keys each device has (how many keys are included in the DNK).

  FIG. 47 is a diagram for explaining the outline of the correspondence and processing of each key issuing center (KDC), top level category entity (TLCE), EKB / requester entity.

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

  A key issuance center (KDC) 4511 performs key management of a subtree such as a top-level category tree, and manages an EKB type definition list and generates an EKB, which will be described later. The certificate authority (CA) 4512 executes a signature on the EKB generated by the key issuing center (KDC) and issues a public key corresponding to the signed secret key as a signature verification key.

  The EKB requester 4520 makes an EKB issue request to the key issue center (KDC) 4511. The EKB requester is, for example, a content provider (CP) related to a content storage medium that provides a medium such as a CD or DVD that stores content, a content provider (CP) that executes distribution of electronic content, and a format of a storage system such as a flash memory. Such as a storage system licensor that provides a license.

  These EKB requesters 4520 provide EKB in which necessary keys are set as keys obtained by EKB processing in association with contents, media, license formats, and the like when using the media, contents, and licenses provided. The EKB is generated by the key issuing center (KDC) 4511 in accordance with an EKB issuing request from the EKB requester 4520 to the key issuing center (KDC) 4511.

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

  In this system, various types of EKB such as EKB that can be processed in common in two or more category trees, for example, EKB that can be processed only in one category tree, are generated and used. Become. The EKB type definition list is a list of various types of EKB. The EKB type definition list is managed by the key distribution center (KDC). The EKB type definition list will be described in detail later. The EKB requester 4520 can request the EKB type definition list from the key issuing center (KDC) 4511 to obtain the list. If there is a change in the list data, the EKB requester 4520 can receive the list from the key issuing center (KDC) 4511. The EKB requester 4520 is notified.

  As described above, the top level category entity (TLCE) 4530 is a management entity of the category tree connected to the root tree. The key management of the subtree, the management device ID, and the node key for EKB processing stored in each device A correspondence list with a device node key (DNK) that is a set is managed. Further, a device node key (DNK) for storing a device is generated and provided to a device manufacturer 4550 that manufactures a device corresponding to the device under management.

  When the key issuing center (KDC) 4511 receives the EKB issuing request from the EKB requester 4520, the key issuing center (KDC) 4511 generates an EKB according to the issuing request. If the EKB to be generated is an EKB that can be processed in, for example, two top level category trees, a sub EKB issue request is transmitted to the two top level category entities (TLCE) 4530, and the sub EKB is issued. The top-level category entity (TLCE) 4530 that has received the issuance request generates a sub-EKB that can be acquired by the legitimate device in each category tree and transmits it to the key issuance center (KDC) 4511. A key issuing center (KDC) 4511 generates an EKB based on one or more sub-EKBs received from the TLCE. The EKB generation process based on the sub-EKB will be further described later.

  Similar to the EKB requester 4520, the top level category entity (TLCE) 4530 can request the key issuing center (KDC) 4511 to request an EKB type definition list and obtain the list.

  The top level category entity (TLCE) 4530 may further request the key distribution center (KDC) 4511 to request a deletion of the type defined for its tree in the EKB type definition list. For example, a request for deleting an EKB type defined as an EKB shared with another category tree from the list. The top level category entity (TLCE) 4530 further notifies the key issuing center (KDC) 4511 of the change information when there is a change related to the tree managed by the top level category entity (TLCE) 4530. These processes will be described later using a flow.

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

  FIG. 48 is a block diagram showing a configuration example of each of the key issue center (KDC), EKB requester, and top level category entity (TLCE) shown in FIG. A key processing center (KDC) is an EKB issuing information processing device, an EKB requester is an EKB request information processing device, and a top-level category entity (TLCE) is a category tree management information processing device. Configured as

  Each information processing apparatus constituting each entity has an encryption processing unit that performs mutual authentication with other entities and overall encryption processing during data communication. The control unit in the encryption processing unit is a control unit that executes control related to the entire encryption processing such as authentication processing and encryption / decryption processing. The internal memory stores key data, identification data, and the like necessary for various processes such as mutual authentication processing, encryption, and decryption processing. The identification data is used, for example, in mutual authentication processing with other entities.

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

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

  Since the internal memory of the encryption processing unit holds important information such as an encryption key, it is necessary to have a structure that prevents unauthorized reading from the outside. Therefore, the encryption processing unit is configured as a tamper-resistant memory composed of, for example, a semiconductor chip having a structure that is difficult to access from the outside.

  In addition to these cryptographic processing functions, each entity has a central processing unit (CPU), a random access memory (RAM), a read only memory (ROM), an input unit, a display unit, a database I / F, Has a database.

  A central processing unit (CPU), a random access memory (RAM), and a read only memory (ROM) are components that function as a control system for each entity body. The RAM is used as a main storage memory for various processes in the CPU, and is used as a work area for processing by the CPU. The ROM stores a startup program in the CPU.

  In the database or other storage means of the information processing apparatus constituting each entity, data managed by each entity, for example, management data related to the issued EKB if it is a key issuing center (KDC), further an EKB type definition list, etc. The top level category entity (TLCE) database stores management data of devices belonging to the category tree, such as correspondence between management devices and device node keys (DNK), and is stored in the EKB requester database. Stores management data in which the relationship between the provided content and the EKB used for the content is associated, management data on the content providing device, and the like. The EKB type definition list is preferably stored in an information processing apparatus that constitutes an EKB requester and a top level category entity (TLCE) so that it can be referred to. Or it is good also as a structure put on the Web (Web) site which the key issuing center (KDC) which an EKB requester and a top level category entity (TLCE) can access is managed.

  As described above, the device uses a device node key (DNK) for EKB processing (decryption). A device node key (DNK) possessed by one device will be described with reference to FIG. The tree shown in FIG. 49 shows one category tree, and the lowest level is a leaf associated with a device, and corresponds to, for example, a management tree of a top level category entity (TLCE). Furthermore, a root tree (ex. 8 stage configuration) is connected to the upper stage. Here, the device has a node key on the path from the device to the upper level as shown in FIG. These key sets are held as device node keys (DNK), and the EKB is decrypted using the device node keys (DNK).

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

  The top-level category entity (TLCE) may be a provider (manufacturer) of the device itself, and a device node key (DNK) is stored in advance for the manufactured device and provided (sold) to the user. It is possible. That is, a node key set of a specific category tree can be stored in a memory in advance as a device node key (DNK) for a device such as a recording / reproducing apparatus and provided (sold) to a user.

(EKB type definition list)
The EKB distribution in the category unit is as described above, but when an EKB that is common to a plurality of categories, that is, an EKB that can be processed in devices belonging to different category trees, is generated and issued, Problems may occur.

  For example, there are two different rewritable media (recording media), for example, portable flash memory format licensees (license recipients), company A and company B, and the media (portable flash memory) In a configuration in which a manufacturer that is a licensor (license licensor) exists as a top-level category and there is a category tree managed by A company and a category tree managed by B company, A company and B company are mutual devices. Can be used in common, and various distribution contents can be used in common, so that EKB that can be processed (decrypted) in the devices belonging to two category trees, the category tree of company A and the category tree of company B Is generated and issued at the key issuing center (KDC).

  In such a situation, if the device node key (DNK) of one device belonging to the category tree managed by company A leaks, the device node key (DNK) is used to There is a possibility that all the distributed contents that can be used in the mutual devices are illegally used. In order to eliminate use, EKB update processing as revocation processing is required. In this case, EKB that is common to the two category trees of Company A and Company B is not the revocation processing related to the category tree of Company A. Therefore, the EKB update process needs to be executed for two category trees of Company A and Company B.

  As described above, when a common EKB is generated and provided for a plurality of category trees, not only in the revocation process and the EKB update process in one category tree, but in all other category trees using the common EKB. It is necessary to execute an EKB update process accompanying revocation. For company B, it will be affected by another management category tree different from the device that it manages, and the processing load will increase.

  In order to solve such a situation, the category entity that manages each category has a permission authority to issue EKB that can be commonly used in a plurality of categories. In other words, in order to ensure compatibility, the issuance of compatible EKB is permitted only when the risk to the device in its category caused by the malfunction of the device belonging to the partner category is allowed, and the risk is not acceptable Shall not issue or use a commonly usable EKB.

  When such processing is performed, various types of EKB are generated, such as EKB that can be processed in common, for example, two or more category trees, or EKB that can be processed only in one category tree. , Will be the situation used. The EKB type definition list is a list of various types of EKB. FIG. 50 shows an example of the EKB type definition list. The EKB type definition list is recorded and managed by a key issuing center (KDC) on a recording medium. Further, the EKB requester and the TLCE can be provided or viewed as necessary.

  As shown in FIG. 50, the EKB type definition list has fields of “EKB type identification number”, “node”, and “description”, and “EKB type identification number” is listed in the EKB type definition list. In addition, this is a number for identifying various types of EKBs. If the identification numbers are different, the category trees or combinations thereof that can process the EKBs are different.

  The “node” field is a field for recording a top node ID of a category tree to which EKB can be applied. For example, the EKB with the EKB type identification number: 1 records the top node ID of the category tree of MS (Memory Stick). The EKB with an EKB type identification number: 3 records the top node ID of the MS (Memory Stick) category tree and the top node ID of the PHS category tree.

  The “description” field is a field for recording descriptions of various types of EKBs listed in the EKB type definition list. For example, an EKB with an EKB type identification number of 1 is an EKB for MS (Memory Stick). It is shown that. An EKB with an EKB type identification number: 3 indicates that the EKB can be used in common for devices in the MS (Memory Stick) and PHS category trees.

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

  However, in various types of EKB registration processing for the EKB type definition list, approval of the top level category entity (TLCE) of the category tree to be registered is required. For example, if the TLCE-A of the category tree A refuses to issue an EKB shared with another category, the EKB type shared by the category tree A and the other category tree is not registered in the EKB type definition list.

  For example, if each of TLCE-A in category tree A, TLCE-B in category tree B, and TLCE-C in category tree C approves the issuance of a shared EKB, a common EKB that can be processed in these three category trees The type is registered in the EKB type definition list. For example, the content provider can specify an EKB type identification number indicating the registered type and request the key issuing center (KDC) to perform an EKB generation process.

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

  The EKB type definition list is sent to all TLCE and EKB requesters, and is made available to all TLCE and EKB requesters by placing it on a web site. Therefore, the TLCE and EKB requester can always acquire the EKB type information registered in the latest EKB type definition list.

(EKB type registration process)
FIG. 51 shows a processing flow for explaining processing executed by the key issuing center (KDC) when a new EKB type is registered in the EKB type definition list. First, the key issuing center (KDC) receives an EKB type registration request from the TLCE that makes a new EKB type registration request (S101). The EKB type registration request from the TLCE includes the number of categories that the registration request EKB can use in common. The key issuing center (KDC) determines whether or not a similar EKB type registration request has been received from the TLCE corresponding to the number of categories that matches the number of categories in the request (S102), and matches the number of categories in the request. On the condition that the requests from the TLCE corresponding to the number of categories to be received are received, a new EKB type according to the request is registered in the EKB type definition list, the list update process, the list update notification process (S103) ). The update notification process is performed for the TLCE and EKB requester.

  In this way, the key distribution center (KDC) manages all of one or more category trees selected as the processable category tree of the EKB type to be registered in the new registration process of the EKB type identifier for the EKB type definition list. Registration is subject to approval of the category / entity.

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

(EKB type invalidation processing)
For example, when all devices belonging to a category must be revoked, the top-level category entity (TLCE) sends a request to the key distribution center (KDC) to invalidate the EKB type of which the category is an element. It is necessary to put out. Also, the top level category entity (TLCE) can issue a request to the KDC to invalidate the currently registered EKB type, for example, for stopping a certain service.

  The flow of this EKB type invalidation processing will be described according to the processing flow of FIG. The key issuing center (KDC) receives an EKB type invalidation request from the TLCE that makes an EKB type invalidation request (S201). Upon receiving an EKB type revocation request from a TLCE, the Key Distribution Center (KDC) confirms that the TLCE that manages the category that is the element of the EKB type revoked by the request is the originator of the request. After confirmation, the EKB type identification number corresponding to the type specified in the invalidation request in the EKB type definition list is invalidated, the EKB type definition list is updated, and a list update notification process (S202) is performed. The update notification process is performed for the TLCE and EKB requester.

  As described above, the key issuing center (KDC) has selected one or more category trees selected as processable category trees of the EKB type to be invalidated in the invalidation process of the EKB type identifier registered in the EKB type definition list. The invalidation processing is performed on the condition that an invalidation request for at least one category entity managing In this case, approval of other category entities is not required.

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

(EKB type definition list change notification process)
For example, in a certain category tree, processing for changing the state in the tree, such as device revocation (device exclusion) or updating a device node key (DNK) for exchanging DNK stored in a certain device, is performed in the category tree. When the TLCE managing the device is performed, it is necessary to inform the EKB requester or the related TLCE using the EKB intended for those devices that these processes have occurred.

  This is because if a device revocation occurs but the content provider (CP) continues to use the old EKB and encrypts and distributes the content, the old EKB uses the EKB process even on the revoked device. This is because (decryption) is possible and unauthorized use of the content may continue. When the device node key (DNK) is updated, the old DNK that was replaced is usually discarded and the device has a new DNK. However, the content provider uses the EKB corresponding to this new DNK. Otherwise, the device having the new DNK cannot process (decrypt) the EKB and cannot access the content.

In order to avoid such harmful effects,
* If the EKB tag part changes as a result of device revocation, etc.
* If the DNK value of at least one device changes as a result of updating the device node key (DNK), etc.
In these cases, the TLCE needs to send a tree change notification (Tree Change Notification) to the key issuing center (KDC). The tree change notification includes an EKB type identification number registered in the EKB type definition list that needs to be changed, information indicating which category has been registered corresponding to the EKB type identification number, Information about what happened in the application or DNK update.

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

(EKB type definition list request)
Top-level category entities (TLCE), subcategory entities other than TLCE (SCE), or EKB requesters such as content providers, issue a key to send the EKB type definition list to know the latest version of the EKB type definition list You can request from the center (KDC). In response to this request, the key distribution center (KDC) sends the latest version of the EKB type definition list back to the requester.

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

(EKB issue processing)
The EKB issuance process is performed based on an EKB issuance request by the EKB requester. The EKB requester
[A] A content provider (CP) that provides a content storage medium such as a CD or a DVD.
[B] A content provider that provides an electronic content distribution (ECD) service.
[C] Format holder for recording system.
For example, an entity that provides services, media, and devices that enable the use of content and the use of formats by using a key obtained by decrypting the EKB.

The format holder of the above [c] recording system includes
[C1] A format holder that gives an EKB acquired to a recording medium manufacturer in a format in which the EKB is stored in the recording medium at the time of manufacture.
[C2] A format holder that gives the EKB acquired to the manufacturer of the recording device in a format that stores the EKB in the recording device at the time of manufacture.
There are two types of format holders.

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

(1) Creation of content key First, an EKB requester such as a content provider generates a content key to be used corresponding to the content, device, and media provided by the EKB requester.
For example, an EKB requester
[A] A content provider (CP) that provides a content storage medium such as a CD or a DVD.
[B] A content provider that provides an electronic content distribution (ECD) service.
If it is,
The content key to be generated is used as a key for protecting (encrypting) the content on the media or in an electronic information distribution (ECD) service.

In addition, the EKB requester
[C1] A format holder that gives an EKB acquired to a recording medium manufacturer in a format in which the EKB is stored in the recording medium at the time of manufacture.
The content key is used as a key for protecting (encrypting) the content recorded on the recording medium.
In addition, the EKB requester
[C2] A format holder that gives the EKB acquired to the manufacturer of the recording device in a format in which the EKB is stored in the recording device at the time of manufacture.
The content key is used as a key for protecting (encrypting) the content recorded using the recording device.

  Note that a mechanism such as an encryption algorithm for protecting content using a content key can be arbitrarily determined for each format.

(2) Generation of root key The EKB requester generates a root key that can be acquired by the EKB decryption process. Note that the EKB requester does not generate the root key itself but may request the key issuing center (KDC) to generate it. The root key is used to protect (encrypt) the content key. Note that a mechanism such as an encryption algorithm for protecting the content key using the root key can be arbitrarily determined for each format.

(3) EKB issue request The EKB requester sends an EKB issue request to the key issue center (KDC).
This request includes the above root key and one of the EKB type identification numbers registered in the EKB type definition list indicating to which category of device the root key is sent by EKB. The EKB requester starts from a category including a device that is a target for providing a service such as content provision based on an EKB type definition list stored in the storage means of the own device or an EKB type definition list acquired from a browsable site on the network. The EKB type is selected, and an EKB type identification number indicating the selected EKB type is included in the EKB issuance request and transmitted to the key issuance center (KDC).

(4) EKB Issuance Processing Based on the EKB issuance request from the EKB requester, the key issuance center (KDC) generates an EKB including the root key if the EKB issuance request includes the root key. If a root key is not included in the request and a root key generation processing request is made, the KDC generates a root key, generates an EKB including the generated root key, and transmits it to the EKB requester.

  The EKB generated by the key issuing center may be an EKB that can be processed in a single category tree or an EKB that can be processed in common in a plurality of category trees. Based on the EKB type identification number included in the EKB issuance request, the key issuing center (KDC), in the category constituting the EKB type identification number, that is, the EKB type identification number specified in the EKB type definition list. Extract the node recorded in the node field. In the node field, the top node ID of the category tree is recorded. This is a node ID corresponding to the management entity of the category tree. Based on this node ID, a sub-EKB issue request is issued to the top-level category entity (TLCE), which is the management entity of the category tree. The sub-EKB issue request includes a root key and information representing each category.

  The TLCE that has received the sub-EKB issue request from the key distribution center (KDC) can finally obtain a root key from each device (not revoked) in one or more designated categories. Is generated and transmitted to the key issuing center (KDC).

  The sub-EKB generated by the top-level category entity (TLCE) has the same structure as a normal EKB (see FIG. 6), except that it does not have a version number or verification information (Version Check Value). It is a pair. Here, the algorithm, key length, and mode for encrypting the upper node key and root key using the leaf key and node key in the sub-EKB can be arbitrarily determined for each TLCE (format holder) that generates the sub-EKB. Thus, a unique security method can be used separately from other formats. Further, for example, the encryption algorithm may be determined to be FIPS46-2 triple DES (Triple-DES) as a default, and TLCE that is not different from this may be configured to apply the triple DES algorithm. Even when TLCE arbitrarily decides the encryption algorithm and key length, each EKB that is combined with the sub-EKB created by another TLCE can be processed by other devices under the control of TLCE. The key is determined to be represented by data of a predetermined length, for example, 16 bytes (16 bytes). In this way, when a common EKB is generated in a plurality of category trees, data is set according to a predetermined rule, so that each device in a different category tree traces the EKB tag to determine what key data Can be determined. That is, if each of the key data included in the EKB is 16 bytes, it is possible to sequentially extract and process key data that can be processed by the own device, and finally obtain a root key. .

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

  The key issuing center (KDC) rearranges and synthesizes the sub-EKB sent from the TLCE as necessary, completes the synthesized EKB by adding the version number and verification information, and then completes the EKB requester. Send to. However, digital signatures using public key cryptography may be requested from a certificate authority (CA) other than the key issuing center (KDC).

  Generation of sub-EKB and generation of synthetic EKB from sub-EKB will be described with reference to the drawings. FIG. 55 is a diagram for explaining the configuration of sub-EKB- (A) generated by the TLCE of category trees A and 5100 in the process of generating a combined EKB common to category trees A and 5100 and category trees B and 5200. . The sub-EKB- (A) is generated as an EKB from which each device in the category tree A, 5100 can obtain a root key. In the figure, the root tree region 5300 has been described as having an eight-stage configuration in the above description, but here has a two-stage structure in order to simplify the description.

  In FIG. 55, a 3-digit numerical value [XXX] with an underline described in the tree structure indicates a tag (e, l, r) in the EKB, as described above (see FIGS. 26 and 27). E = 1 with data, e = 0 with no data, l = 1 with no branches on the left, l = 0 with branches on the left, r = 1 with no branches on the right, r = 0 A branch is shown on the right.

  In order for each device (leaf) in the category trees A and 5100 in FIG. 55 to acquire the root key, an EKB storing data obtained by encrypting the root key with a node key stored in common in each leaf is generated. Good. Since each device has a node key of each path of the tree in the device node key (DNK) area 5120 of the category tree A, 5100 in FIG. 55, the root key is encrypted with the uppermost node key in the DNK area 5120. What is necessary is just to produce | generate EKB.

  Accordingly, the sub-EKB- (A) generated by the TLCE of the category tree A, 5100 includes tag parts: 101, 010,000, 111, 111, key parts: Enc (K010, Kroot), Enc (K011, Kroot). Sub-EKB- (A) The TLCE of category tree A 5100 transmits this sub-EKB- (A) to the key issuing center (KDC).

  Next, sub-EKB- (B) generated by category tree B 5200 will be described with reference to FIG. In order for each device (leaf) in the category tree B and 5200 to acquire the root key, an EKB storing data obtained by encrypting the root key with a node key stored in each leaf may be generated. Since each device has a node key of each path of the tree in the device node key (DNK) area 5220 of the category tree B 5200 in FIG. 56, an EKB obtained by encrypting the root key with the uppermost node key in the DNK area 5220 is stored. It only has to be generated.

  Therefore, the sub-EKB- (B) generated by the TLCE of the category tree B, 5200 includes tag parts: 110, 010,000, 111, 111, key parts: Enc (K110, Kroot), Enc (K111, Kroot). Sub-EKB- (B). The TLCE of category tree B 5200 transmits this sub-EKB- (B) to the key issuing center (KDC).

  The key issuing center generates a composite EKB from the sub-EKB- (A) and the sub-EKB- (B) generated by each TLCE. The generation of the combined EKB will be described with reference to FIG. The combined EKB is configured as an EKB that allows a device belonging to each of the category trees A and 5100 and the category trees B and 5200 to obtain a root key. Basically, a composite EKB is generated by mixing the received key data arrays of a plurality of sub-EKBs and aligning them from the top of the tree. In the same stage, data arrangement is performed with the left side first.

  As a result, the synthetic EKB has tag parts: 100, 010, 010,000,000, 111, 111, 111, 111, key parts: Enc (K010, Kroot), Enc (K011, Kroot), Enc (K110, Kroot) ), Enc (K111, Kroot). By setting the key data of each key part as 16 bytes, for example, as described above, the device in each category tree can detect the key data position that can be processed by the device itself. It can be acquired.

  The above is the generation configuration of sub-EKB and synthetic EKB when there is no revoked device in any category tree. Next, generation of sub-EKB and generation of synthetic EKB when there is a revoked device Will be described.

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

  In this case, a sub-EKB having a key data configuration in which paths indicated by bold lines in the figure are connected is generated. Accordingly, the sub-EKB- (A ′) generated by the TLCE of the category tree A, 5100 includes a tag part: 101,010,000,111,000,001,111,111, a key part: Enc (K010, Kroot), Sub-EKB- (A ′) which becomes Enc (K0111, Kroot), Enc (K01100, Kroot). The TLCE of the category tree A, 5100 transmits this sub-EKB- (A ′) to the key issuing center (KDC).

  The key issuing center generates a synthetic EKB from the sub-EKB- (A ′) generated by each TLCE and the sub-EKB- (B) (see FIG. 56) received from the TLCE of the category tree B, 5200 having no revoke device. To do. The generation of the composite EKB will be described with reference to FIG. The combined EKB is configured as an EKB that allows a device other than the revoke device (01101) 5150 in the category tree A, 5100 and devices belonging to the tree in the category tree B, 5200 to obtain the root key. Basically, a composite EKB is generated by mixing the received key data arrays of a plurality of sub-EKBs and aligning them from the top of the tree. In the same stage, data arrangement is performed with the left side first.

  As a result, the synthesized EKB has tag parts: 100,010,010,000,000,111,000,111,111,001,111,111, key parts: Enc (K010, Kroot), Enc (K110, Kroot) , Enc (K111, Kroot), Enc (K0111, Kroot), and Enc (K01100, Kroot). This combined EKB is an EKB from which devices other than the revoke device (01101) 5150 in the category tree A, 5100 and devices belonging to the tree in the category tree B, 5200 can obtain the root key.

(5) Use of EKB The EKB generated by the key issuing center (KDC) by the above-described processing is transmitted to the EKB requester.
For example, an EKB requester
[A] A content provider (CP) that provides a content storage medium such as a CD or a DVD.
[B] A content provider that provides an electronic content distribution (ECD) service.
If it is,
The content key is encrypted with a root key that can be acquired by EKB, and the content provided to the user device is encrypted with the content key to distribute the content. With this configuration, only devices belonging to a specific category tree that can be processed by EKB can use the content.

In addition, the EKB requester
[C1] A format holder that gives an EKB acquired to a recording medium manufacturer in a format in which the EKB is stored in the recording medium at the time of manufacture.
If this is the case, the generated EKB and the content key encrypted with the root key are provided to the recording medium manufacturer, and the recording medium storing the content key encrypted with the EKB and the root key is manufactured, or the recording medium is manufactured by itself. And distribute. With this configuration, only devices belonging to a specific category tree that can be processed by EKB can perform encryption processing and decryption processing during content recording / playback using EKB of the recording medium.

In addition, the EKB requester
[C2] A format holder that gives the EKB acquired to the manufacturer of the recording device in a format in which the EKB is stored in the recording device at the time of manufacture.
If this is the case, the content key encrypted with the generated EKB and the root key is provided to the recording device manufacturer, and the recording device storing the content key encrypted with the EKB and the root key is manufactured, or the recording device is manufactured by itself. And distribute. With this configuration, only devices belonging to a specific category tree that can be processed by EKB can perform encryption processing and decryption processing during content recording / playback using EKB.

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

(Configuration example in which a simple set of sub-EKBs is a composite EKB)
In the process of generating the composite EKB from the sub EKB described above, the process of rearranging the arrangement of the encryption key data included in each sub EKB from the upper stage to the lower stage of the entire tree is performed. Next, a description will be given of a configuration in which the sub EKB generated by the TLCE of each category tree is sequentially stored in the composite EKB as it is without executing such a rearrangement process to generate the composite EKB.

  FIG. 60 is a diagram showing an example of a combined EKB 6000 in which a plurality of sub-EKBs generated by TLCEs of a plurality of category trees are stored as they are.

  In the EKB issuance process, the key issuance center (KDC) sends the sub EKB to the TLCE which is the management entity of the category tree recorded in the EKB type definition list corresponding to the EKB type identification number designated by the EKB requester. A generation request is issued, and the sub-EKBs 6110, 6120... Submitted from each TLCE are simply collected and stored in the composite EKB. However, the size (ex. Data length) 6111 of each sub-EKB portion so that the device belonging to each category can select the sub-EKB corresponding to the category to which the device can process from the combined EKB. Data (ex. Node ID) 6112 indicating which category the sub-EKB is for is added.

  That is, each sub-EKB selected as a storage target is associated with a length indicating the data length of the sub-EKB storage area and a node ID as a node identifier of the corresponding category tree of each sub-EKB as sub-EKB identification data. Stored. The number of sub-EKBs included in the combined EKB is added as header information 6200. A signature (ex. Certificate authority (CA) signature) 6300 is generated and added based on all data of the combined EKB.

  When a synthetic EKB corresponding to the description using FIG. 57 described above is generated according to this method, a synthetic EKB as shown in FIG. 61 is generated. The storage EKB of the sub EKB 6110 is the sub EKB- (A) itself generated by the TLCE of the category tree A described with reference to FIG. 55, the tag part: 101,010,000, 111,111, the key part: Enc (K010, Kroot), Enc (K011, Kroot). Further, the storage EKB of the sub EKB 6120 is the sub EKB- (B) itself generated by the TLCE of the category tree B described with reference to FIG. 56, the tag part: 110, 010,000, 111, 111, the key part: Enc ( K110, Kroot), Enc (K111, Kroot).

  Further, the combined EKB in the case where there is a revoke device described with reference to FIGS. 58 and 59 described above has a data configuration shown in FIG. The stored EKB of the sub EKB 6110 is the sub EKB- (A ′) itself generated by the TLCE of the category tree A described with reference to FIG. 58, and the sub EKB- (A ′) is the tag part: 101,1010,000,111. , 000, 001, 111, 111, key parts: Enc (K010, Kroot), Enc (K0111, Kroot), Enc (K01100, Kroot). Further, the stored EKB of the sub-EKB 6120 in which no revocation device is generated is the sub-EKB- (B) itself generated by the TLCE of the category tree B described in FIG. 56, and the tag parts: 110, 010,000, 111, 111, key parts: Enc (K110, Kroot), Enc (K111, Kroot).

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

  For the key issuing center (KDC), it is not necessary to disassemble and reassemble the sub-EKB tags and key data parts collected from each TLCE, and the load is reduced.

  A device that has obtained an EKB according to this method can obtain a root key by finding a sub-EKB of the category to which the device belongs and processing it in a unique method determined by the TLCE that manages the device. There is no need to know the methods defined by other categories of TLCEs for processing other sub-EKBs, and there is no need for ingenuity such as representing individual keys in fixed lengths in sub-EKBs. Even large-sized keys can be used.

(Revocation process-(1))
Processing executed when revocation occurs in processing using EKB that can be commonly used in a plurality of categories will be described below. A revoke process in the case where encrypted content is received from the outside by a network or media and a content key is acquired using a key acquired by EKB will be described first.

  This will be described with reference to FIG. Assume that an EKB 7000 that is commonly used in the category trees A and 7100 and the category trees B and 7200 is used. Further, it is assumed that EKB 7000 commonly used in category tree A, 7100 and category tree B, 7200 has an EKB type identification number defined as # 1 in the EKB type definition list.

  In such a situation, the content provider provides the content encrypted with the content key by the network or media, and the devices belonging to the category trees A and 7100 and the category tree B and 7200 obtain the root key using the EKB 7000, Content is obtained by executing acquisition of a content key by decryption processing using a root key and acquisition of encrypted content using a content key.

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

  In this case, the TLCEs of the category trees A and 7100 execute a tree change notification (see FIG. 53) to the key issuing center (KDC), and the key issuing center (KDC) manages based on the received tree change notification. Notify each TLCE and EKB requester below. The notification at this point only informs that the tree change notification has been received, and the update process of the EKB type definition list is not executed.

  It should be noted that the tree change notification based on the occurrence of revocation is performed only for an EKB requester as an entity using an EKB that can be processed in the category tree where the revocation occurred, or in addition, an EKB shared with the category tree where the revocation occurred. It may be configured to execute only for a category entity that manages another category tree to which is applied. In order to perform this process, the key issuing center (KDC) holds a list in which an EKB type identification number and an EKB requester using the EKB type are associated with each other as a user list of issued EKBs.

  A content provider as an EKB requester that executes content distribution for devices in the category tree that has executed revocation processing issues a key so as to generate an updated EKB that can be processed only on devices that are not subject to revocation processing. An EKB issue request is made to the center (KDC). In this case, the content provider as an EKB requester designates an EKB type identification number # 1 defined as an EKB type commonly used in the category trees A and 7100 and the category trees B and 7200. In addition, the EKB requester itself generates a new root key and sends it to the KDC, or requests the KDC to generate a new root key.

  The key distribution center (KDC) refers to the EKB type definition list based on the designated EKB type identification number # 1, and based on the corresponding category tree node, the category tree A, 7100 and the category tree B, 7200 The TLCE is requested to generate a sub EKB that can acquire a new root key in a valid device.

  Each of the TLCEs of category tree A, 7100 and category tree B, 7200 generates a sub-EKB based on the request. In this case, in the category tree A, 7100, a sub-EKB- (A) that can acquire a new root key is generated only in other devices excluding the revoked devices A1, 7120. If there is no revoked device in the category tree B, 7200, a sub-EKB- (B) capable of acquiring a new root key is generated in all devices belonging to the category and is generated to the key issuing center (KDC). Send.

  The key issuing center (KDC) generates a composite EKB based on the sub-EKB received from each TLCE according to the method described above, and transmits the generated EKB to the EKB requester (ex. Content provider).

  The EKB requester (ex. Content provider) distributes content by applying the new EKB received from the key issuing center (KDC). Specifically, the content encrypted with the content key is provided, and the content key is encrypted with the root key obtained by decrypting the EKB. Devices belonging to the category trees A and 7100 and the category trees B and 7200 execute the acquisition of the root key using the EKB, the acquisition of the content key by the decryption process using the root key, and the acquisition of the encrypted content using the content key. Is available. However, since the revocation devices A1 and 7120 of the category tree A and 7100 cannot process the updated EKB, the contents cannot be used.

  In the above description, when the key issuing center (KDC) receives the tree change notification from the TLCE, the update process of the EKB type definition list is not executed at that time, but the KDC has changed the tree. When the notification is received, the key distribution center (KDC) executes the update process of the EKB type definition list and the EKB update process based on the tree change information, and the EKB type definition list updated by each EKB requester and TLCE It is good also as a structure to send.

(Revocation process-(2))
Next, for example, in a configuration in which EKB is stored in a recording device or a recording medium, a user encrypts and records various contents on the recording medium, and keys necessary for encryption processing and decryption processing are recorded on the recording device or recording medium. A process associated with the revoke process in the so-called self-recording type using the root key acquired from the EKB stored in the EKB will be described.

  This will be described with reference to FIG. Assume a situation in which EKB 8000 that is used in common in category tree A, 8100 and category tree B, 8200 is used. That is, a common EKB is stored in a recording device or a recording medium that is commonly used in the category trees A and 8100 and the category trees B and 8200, and the user can record and reproduce content by content encryption and decryption processing using the EKB. It is assumed that Note that EKB 8000 commonly used in category tree A, 8100 and category tree B, 8200 has an EKB type identification number defined as # 1 in the EKB type definition list.

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

  In this case, the TLCEs of the category trees A and 8100 execute a tree change notification (see FIG. 53) to the key issuing center (KDC), and the key issuing center (KDC) manages based on the received tree change notification. Notify each TLCE and associated EKB requester below. The notification at this point only informs that the tree change notification has been received, and the update process of the EKB type definition list is not executed.

  The TLCE of the category tree that has executed the revocation processing is updated so that it can be processed only by a device other than the revocation processing target as an EKB requester in order to stop new content processing using the EKB in the future in the revocation devices A1 and 8120. An EKB issuance request is made to the key issuance center (KDC) so as to generate an EKB. In this case, the TLCE as the EKB requester designates an EKB type identification number # 1 defined as an EKB type commonly used in the category trees A and 8100 and the category trees B and 8200. In addition, the EKB requester itself generates a new root key and sends it to the KDC, or requests the KDC to generate a new root key.

  The key distribution center (KDC) refers to the EKB type definition list on the basis of the designated EKB type identification number # 1, and on the category tree A, 8100 and category tree B, 8200 on the basis of the corresponding category tree node. The TLCE is requested to generate a sub EKB that can acquire a new root key in a valid device.

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

  The key issuing center (KDC) generates a composite EKB based on the sub-EKB received from each TLCE according to the method described above, and transmits the generated EKB to each TLCE (ex. Format holder).

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

  The present invention has been described in detail 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.

  As described above, according to the information processing system and method of the present invention, a key tree having a plurality of subtrees divided based on categories and managed by category entities is formed, and paths constituting the key tree are determined. In the configuration of selecting and generating an EKB consisting of encryption processing data of the upper key by the lower key on the selected path and providing it to the device, an EKB type identifier and identification data of one or more category trees capable of EKB processing are provided. Since the EKB issuance management is executed based on the associated EKB type definition list, the EKB requester as the EKB generation requester can easily select the category to be applied.

  Further, according to the information processing system and method of the present invention, in the request for generating the enabling key block (EKB), a configuration for generating the root key itself and a configuration for requesting the key issuing center to generate the root key are selectively used. The load on the EKB generation requester can be reduced, and the EKB generation at the EKB issuing center can request the category entity that is the category manager to generate the sub-EKB when the EKB generation is requested. Therefore, the efficiency of EKB generation and management processing can be improved.

10 Content Distribution Side 11 Internet 12 Satellite Broadcasting 13 Telephone Line 14 Media 20 Content Reception Side 21 Personal Computer (PC)
22 Portable Device (PD)
23 Mobile phones, PDAs
24 Recording / Reproducing Device 25 Dedicated Reproducing Device 30 Media 100 Recording / Reproducing Device 110 Bus 120
130 MPEG codec 140 Input / output 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 part 607 Tag part 608 Signature 1101 Recording device 2301 Root key 2302 Node key 2303 Leaf key 2304 Category node 2306 Subcategory node 2701 Category tree 2702 Subroot 2811 , 2851 Sub-root 2812, 2852 Category tree end node 2901, 2902 Category tree 2950 Reserve node 2970 Management end node 3011, 3012, 3013 Category tree 3021, 3022, 3023 Reserve node 3201 End node 3202 Vertex node 3301, 3302 End node 3303 New category Tree -Additional end nodes 3410, 3420, 3430 Category tree 3411, 3421, 3431 Sub-root 3432 Revocation device node 3601 End node 3710, 3720, 3730 Category tree 3711, 3721, 3731 Sub-root 3901 End node 3902 Vertex node (sub-root node)
4001 to 4005 Category tree 4021, 4022, 4023 Category tree 4101 to 4105 Category tree 4510 Management entity 4511 Key issuing center (KDC)
4520 EKB Requester 4530 Top Level Category Entity (TLCE)
4540 Media Manufacturer 4550 Device Manufacturer 4551 DNKE Device Manufacturer 4552 DNK Device Manufacturer 5100 Category Tree A
5120 Device node key area 5150 Revocation device 5200 Category tree B
5220 Device node key area 5300 Root tree 6000 EKB
6110, 6120 Sub EKB
6111, 6121 Length data 6112, 6122 Category identification data 6200 Header information 6300 Signature data 7000 EKB
7100 Category tree A
7120 Revocation Device 7200 Category Tree B
8000 EKB
8100 Category tree A
8120 Revocation device 8200 Category tree B

Claims (9)

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 A configuration for providing an enabling key block (EKB) that can be decrypted only by a device that has encryption processing data of the upper key by the upper lower key and that can use the node key set corresponding to the selected path. An information processing system
The key tree is configured based on categories, and has a plurality of category trees as sub-trees managed by category entities,
The key issuing center (KDC) that generates the enabling key block (EKB)
In the generation of the enabling key block (EKB) based on the request of the EKB requester which is the request entity of the EKB generation, each of the one or more category entities that manage the decodable category tree of the generated enabling key block (EKB) A configuration for generating a sub-EKB generation request that can be processed in the category tree and generating an EKB that can be processed in one or more category trees based on the sub-validation key block (sub-EKB) received from the category entity. An information processing system characterized by The key issuing center (KDC)
An EKB type included in an EKB generation request received from an EKB requester that has an EKB type definition list in which an EKB type identifier is associated with identification data of an EKB processable category tree, and is an entity that requests generation of an EKB The identification data of the category tree is extracted by searching the EKB type definition list based on the identifier, and based on the sub EKB generated by one or more category entities corresponding to the extracted identification data of the category tree, the EKB type definition list The information processing system according to claim 1, wherein the information processing system is configured to generate and provide an EKB that can be commonly used for the category tree set to “1”.   The category entity that has received the sub-EKB generation request from the key issuing center (KDC) has a sub-validation key as an EKB that can be processed based on a key associated with a node or leaf belonging to the category tree managed by the category entity. The information processing system according to claim 1, wherein the information processing system is configured to generate a block (sub-EKB). The key tree is composed of a root tree of a plurality of stages at the top, a top-level category tree directly connected to the root tree, and a sub-category tree connected to the bottom of the top-level category tree,
The category entity manages the top-level category tree and a sub-category tree connected to the lower level of the top-level category tree as a management entity of the top-level category tree.
The category entity is an EKB that can be processed based on a key set corresponding to a node or leaf belonging to a top-level category tree managed by itself and a sub-category tree connected to a lower level of the top-level category tree. The information processing system according to claim 1, wherein the information processing system is configured to generate a sub-validation key block (sub-EKB). 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 A configuration for providing an enabling key block (EKB) that can be decrypted only by a device that has encryption processing data of the upper key by the upper lower key and that can use the node key set corresponding to the selected path. Information processing method in the system
The key tree is configured based on categories, and has a plurality of category trees as sub-trees managed by category entities,
The key issuing center (KDC) that generates the enabling key block (EKB)
In the generation of the enabling key block (EKB) based on the request of the EKB requester which is the request entity of the EKB generation, each of the one or more category entities that manage the decodable category tree of the generated enabling key block (EKB) A sub-KB generation request that can be processed in the category tree is output, and an EKB that can be processed in one or more category trees is generated based on the sub-validation key block (sub-EKB) received from the category entity. Information processing method. The key issuing center (KDC)
An EKB type included in an EKB generation request received from an EKB requester that has an EKB type definition list in which an EKB type identifier is associated with identification data of an EKB processable category tree, and is an entity that requests generation of an EKB The identification data of the category tree is extracted by searching the EKB type definition list based on the identifier, and based on the sub EKB generated by one or more category entities corresponding to the extracted identification data of the category tree, the EKB type definition list 6. The information processing method according to claim 5, wherein an EKB that can be commonly used in a category tree set to be generated and provided.   The category entity that has received the sub-EKB generation request from the key issuing center (KDC) has a sub-validation key as an EKB that can be processed based on a key associated with a node or leaf belonging to the category tree managed by the category entity. 6. The information processing method according to claim 5, wherein a block (sub-EKB) is generated. The key tree is composed of a root tree of a plurality of stages at the top, a top-level category tree directly connected to the root tree, and a sub-category tree connected to the bottom of the top-level category tree,
The category entity manages the top-level category tree and a sub-category tree connected to the lower level of the top-level category tree as a management entity of the top-level category tree.
The category entity is an EKB that can be processed based on a key set corresponding to a node or leaf belonging to a top-level category tree managed by itself and a sub-category tree connected to a lower level of the top-level category tree. 6. The information processing method according to claim 5, wherein a sub validation key block (sub EKB) is generated. 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 A configuration for providing an enabling key block (EKB) that can be decrypted only by a device that has encryption processing data of the upper key by the upper lower key and that can use the node key set corresponding to the selected path. A computer-readable recording medium storing a computer program that causes a computer system to execute information processing in a system having the computer program,
Extracting the identification data of the category tree from the EKB type definition list in which the EKB type identifier is associated with the identification data of one or more category trees capable of EKB processing based on the EKB type identifier included in the EKB generation request; ,
Outputting a generation request for a sub-enabling key block (sub-EKB) that can be processed in each category tree to one or more category entities that manage the category tree corresponding to the extracted identification data of the category tree;
Generating an EKB that can be processed in one or more category trees based on a sub-enabling key block (sub-EKB) received from a category entity;
A program recording medium comprising: