WO2002052780A1 - Systeme et procede de traitement d'informations - Google Patents

Systeme et procede de traitement d'informations Download PDF

Info

Publication number
WO2002052780A1
WO2002052780A1 PCT/JP2001/011236 JP0111236W WO02052780A1 WO 2002052780 A1 WO2002052780 A1 WO 2002052780A1 JP 0111236 W JP0111236 W JP 0111236W WO 02052780 A1 WO02052780 A1 WO 02052780A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
ekb
category
sub
tree
Prior art date
Application number
PCT/JP2001/011236
Other languages
English (en)
French (fr)
Inventor
Tomoyuki Asano
Yoshitomo Osawa
Tateo Oishi
Ryuji Ishiguro
Ryuta Taki
Original Assignee
Sony Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corporation filed Critical Sony Corporation
Priority to KR1020027011170A priority Critical patent/KR100859622B1/ko
Priority to AT01272280T priority patent/ATE444616T1/de
Priority to US10/204,731 priority patent/US7346170B2/en
Priority to EP01272280A priority patent/EP1249962B1/en
Priority to DE60140041T priority patent/DE60140041D1/de
Publication of WO2002052780A1 publication Critical patent/WO2002052780A1/ja
Priority to HK03109358.4A priority patent/HK1058589A1/xx

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0822—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using key encryption key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H04L9/0833—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP] involving conference or group key
    • H04L9/0836—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP] involving conference or group key using tree structure or hierarchical structure
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
    • G11B20/0021—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
    • G11B20/00855—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving a step of exchanging information with a remote server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/60—Digital content management, e.g. content distribution
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/104—Grouping of entities

Definitions

  • the present invention relates to an information processing system, an information processing method, an information recording medium, and a program recording medium, and more particularly, to a distribution system and method involving an encryption process for providing various data such as contents to a specific authorized user.
  • a hierarchical key distribution system with a tree structure is used, and a key block generated according to a distribution device is used, for example, distribution of a content key as a content encryption key, or various other security methods.
  • TECHNICAL FIELD The present invention relates to an information processing system, an information processing method, an information recording medium, and a program recording medium that can maintain the security. Background art
  • Content software programs such as game programs, audio data, image data, etc.
  • networks such as the Internet or on DVDs and CDs.
  • Distribution via storage media is increasing.
  • These distributed contents can be played back by receiving data from a PC (Personal Computer) or game machine owned by the user, or by mounting a storage medium, or by using a recording device in a recording / playback device attached to the PC or the like.
  • PC Personal Computer
  • a recording device in a recording / playback device attached to the PC or the like.
  • it is stored in a memory card, hard disk, etc., and is used by new reproduction from a storage medium.
  • Information devices such as video game devices and PCs have an interface for receiving distribution content from a network or accessing a DVD, CD, etc., and control means necessary for content reproduction, It has RAM and ROM used as memory area for programs and data.
  • the encrypted data can be returned to the decrypted data (plaintext) that can be used by the decryption processing according to a predetermined procedure.
  • Data encryption and decryption methods using an encryption key for such information encryption processing and a decryption key for decryption processing have been well known.
  • the encryption key and the 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 or the like.
  • a one-way function is a function that makes it very difficult to find its input from its output. For example, a one-way function is applied with a password determined by the user as an input, and an encryption key and a decryption key are generated based on the output. in this way On the contrary, it is virtually impossible to obtain a password that is the original data from the encryption key and the decryption key obtained by the above.
  • a method in which processing using an encryption key used for encryption and processing for a decryption key used for decryption are set to 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 a public key issued by the specific individual. Documents encrypted with the public key can be decrypted only with the private key corresponding to the public key used for the encryption. Since the private key is owned only by the individual who issued the public key, documents encrypted with the public key can be decrypted only by the individual who has the private key.
  • a typical public key cryptosystem is the RSA (Rivest-Shamir-Adleman) cipher.
  • the content is encrypted and stored in the network or on a recording medium such as a DVD or CD for the user, and the content key for decrypting the encrypted content is provided only to the legitimate user.
  • a recording medium such as a DVD or CD for the user
  • the content key for decrypting the encrypted content is provided only to the legitimate user.
  • Many configurations have been adopted.
  • the content key is encrypted and provided to the legitimate user, and the content key is decrypted using the decryption key possessed only by the legitimate user to make the content key usable.
  • a configuration has been proposed.
  • the present invention it is possible to safely transmit data only to a valid user without relying on the mutual authentication processing between the sender and the receiver in the above-described manner.
  • an activation key block which is an encryption key data block that can be decrypted in one or more selected category trees, is generated so that it can be commonly used by devices belonging to each category tree.
  • An information processing system, an information processing method, and an information recording medium that make it possible to increase the efficiency of EKB generation and management processing by using an EKB type definition list that indicates whether processing is possible in a tree, that is, whether decoding is possible.
  • An information recording medium that make it possible to increase the efficiency of EKB generation and management processing by using an EKB type definition list that indicates whether processing is possible in a tree, that is, whether decoding is possible.
  • a key tree is created by associating keys with the roots, nodes, and leaves on the path from the root of the tree that configures multiple devices as leaves to the leaves, and the paths that make up the key tree are selected.
  • An enabling key block (EKB) that has the encryption processing data of the upper key by the lower key on the selected path and that can be decrypted only in a device that can use the node key set corresponding to the selected path is written to the device.
  • An information processing system having a configuration to provide,
  • a first EKB generation request as an EKB generation request that includes the generated root key, or
  • the key issuing center is configured to execute an EKB generation including a reception root key or a generation root key in response to receiving the first EKB generation request or the second EKB generation request.
  • An information processing system comprising: Further, in one embodiment of the information processing system of the present invention, the key tree is divided based on a category, and has a configuration having a plurality of category trees as sub-trees managed by a category 'entity. Selects an EKB type identifier based on an EKB type definition list that associates EKB type identifiers with the identification data of category trees that can be EKB processed, and generates an EKB that includes the selected EKB type identifier. A request is output to the key issuing center (KDC) as the first EKB generation request or the second EKB generation request.
  • the EKB request is selected from an EKB type identifier based on an EKB type definition list obtained from a storage unit or a browsable site on a network. It is characterized by the configuration that
  • the identification data of the category directory in which the EKB processing is possible in the EKB type definition list is a node ID which is an identifier of the node of the category directory.
  • the EKB type definition list is configured to include a description of a device belonging to a category tree.
  • a second aspect of the present invention provides:
  • a key tree is created by associating keys with roots, nodes, and leaves on the path from the root of the tree, which has a plurality of devises as leaves, to the leaf, and the path that constitutes the key tree is selected. Then, an activation key block (EKB) having encryption processing data of an upper key by a lower key on the selected path and capable of decrypting only in a device that can use a node key set corresponding to the selected path is divided.
  • EKB activation key block
  • the key tree is divided on the basis of the category, and has a configuration having a plurality of category trees as sub-trees managed by the category entity.
  • the key issuing center (KD) generates an activation key block (EKB).
  • EKB activation key block
  • C) manages the decryptable category tree of the generated activation key block (EKB).
  • a request to generate a sub-EKB that can be processed in the category tree is output to the category entity, and 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 having a configuration for generating an EKB.
  • the key issuance center includes an EKB type identifier that associates an EKB type identifier with identification data of a category tree that can be EKB processed.
  • An entity that has a definition list and receives an EKB request which is an entity that requests the generation of an EKB.
  • a category tree is identified by searching the EKB definition list based on the EKB type identifier included in the EKB generation request received in the EKB generation request. And extract one or more categories corresponding to the extracted identification data of the category list.
  • the EKB that can be commonly used for the category list set in the EKB type definition list is extracted. It is characterized in that it is generated and provided.
  • the category 'entity receiving the sub-EKB generation request from the key issuing center (KDC) is assigned to a node or leaf belonging to the category tree managed by itself. It is characterized in that it generates a sub-validation keep mark (sub-EKB) as an EKB that can be processed based on the associated key.
  • KDC key issuing center
  • the key tree includes a plurality of route trees at the top, and a top level category tree directly connected to the root tree, and a bottom level category tree below the top level category tree.
  • the category 'entity is composed of subcategory trees that are linked, and the category' It manages the top level category sub-category as the management entity of the top level category category and the sub-categories connected to the lower level of the top level category category, and the category entity manages the top level category category managed by itself.
  • sub-EKB sub-validated key block
  • a third aspect of the present invention is that
  • a key tree is created by associating keys with the roots, nodes, and leaves on the path from the root of the tree that configures multiple devices as leaves to the leaves, and the paths that make up the key tree are selected. Then, an enable key block (EKB) that has the encryption processing data of the upper key by the lower key on the selected path and that can be decrypted only by a device that can use the node key set corresponding to the selected path is divided.
  • EKB enable key block
  • the EKB request requesting the key issuance center (KDC), which generates the activation key block (EKB), to generate an EKB,
  • a first EKB generation request as an EKB generation request that includes the generated root key, or
  • a second EKB generation request requesting the generation of a root key at the key issuing center (KD C) and the generation of an EKB including the generated root key;
  • the key issuance center performs the EKB generation including the reception root key or the generation root key in response to receiving the first EKB generation request or the second EKB generation request.
  • the feature is an information processing method.
  • the key tree is divided based on a power category, and has a configuration having a plurality of category trees as sub-trees managed by category entities.
  • the requester maps the EKB type identifier to the identification data of the category tree that can be processed by EKB.
  • An EKB type identifier is selected based on the attached EKB type definition list, and an EKB generation request including the selected EKB type identifier is defined as the first EKB generation request or the second EKB generation request as the key issuing center. (KD C).
  • the EKB requester stores an EKB type identifier based on an EKB type definition list obtained from a storage means or a browsable site on a network. It is characterized by selecting.
  • the identification data of the category that can be EKB-processed in the EKB type definition list is a node ID that is an identifier of a node of the category tree. I do.
  • the EKB type definition list is configured to include a description of a device belonging to a category tree.
  • a fourth aspect of the present invention is that
  • a key is associated with each of the roots, nodes, and leaves on the path from the root of the tree to the leaf, in which a plurality of devices are configured as leaves, and a path that configures the key tree is selected.
  • An effective key block (EKB) that has an encryption process of the upper key by the lower key on the selected path and that can be decrypted only in a device that can use the node set corresponding to the selected path.
  • the key tree is divided based on the category, and has a configuration having a plurality of categories as subtrees managed by the category 'entity.
  • the key issuing center (KDC) that generates an activation key block (EKB) is In the generation of the EKB requester, which is the requesting entity of the EKB generation entity, in the generation of the EKB requester, manages the decodable category list of the generated activation keepalogue (EKB).
  • Output sub-EKB generation requests to categories and entities that can be processed in each category, and process them in one or more category trees based on the sub-activation key block (sub-EKB) received from the category-entity Information characterized by generating a unique E KB Processing method.
  • the key issuance key is an EKB type in which an EKB type identifier is associated with identification data of an EKB-processable category.
  • An EKB request that is an entity that has a definition list and requests generation of EKB Requests received from an EKB request message Searches the EKB type definition list based on the EKB type identifier included in the EKB generation request to extract the identification data of the category
  • an EKB that can be commonly used for the category tree set in the EKB type definition list is generated. It is characterized in that it is a configuration to provide.
  • KDC key issuing center
  • the entity is a node or leaf belonging to the category tree managed by itself. It is characterized by generating a sub-validated key block (sub-EKB) as an EKB that can be processed based on the associated key.
  • sub-EKB sub-validated key block
  • the key tree includes a plurality of root trees at the top, and a top level category tree directly connected to the root tree, and a lower level tree connected to the top level category tree.
  • the category is an entity
  • the top-level category management entity manages the top-level category category and the sub-category series connected to the lower level of the top-level category category.
  • the category 'entity can be processed based on the key set corresponding to the node or leaf belonging to the top level' category managed by itself and the subcategory connected to the lower level of the top level category. And generating a sub-enabling Kipurodzuku (sub EKB) as a E KB.
  • a fifth aspect of the present invention provides:
  • a key tree is formed by associating keys with roots, nodes, and leaves on the path from the root of the tree to the leaf, where a plurality of devices are configured as leaves, A path constituting the key tree is selected, and upper-order key encryption processing data based on a lower-order key on the selected path is provided, and decryption can be performed only by a device that can use the node key set corresponding to the selected path.
  • a computer having a configuration for providing an activation key block (EKB) to a device; a computer for causing a computer to execute information processing on the system; and a program recording medium on which a program is recorded.
  • EKB activation key block
  • KDC key issuing center
  • a sixth aspect of the present invention provides
  • a key tree is formed by associating keys with respective roots, nodes, and leaves on a path from a root of the tree where a plurality of devices are configured as leaves to the leaves, and a path forming the key tree is selected.
  • a configuration that provides an encryption key block (EKB) to a device that has encryption processing data of an upper key by a lower key on a selected path and that can decrypt only a device that can use a node key set corresponding to the selected path.
  • EKB encryption key block
  • a computer-readable storage medium storing a computer program for causing a computer to execute information processing in a system having a computer program.
  • the EKB type identifier is associated with the identification data of one or more category trees that can be EKB processed. Extracting the identification data, and managing one or more categories corresponding to the identification data of the extracted category tree. One or more categories.
  • the sub-validated key block (sub EKB) that can be processed in each category tree by the entity. ), And outputting a request to generate A step of generating an EKB that can be processed in one or more category trees based on the sub-activation key block (sub-EKB) received from the category entity;
  • a seventh aspect of the present invention provides
  • a key is associated with each of the roots, nodes, and leaves on the path from the root of the tree where a plurality of devices are configured as leaves to the leaves, and the paths forming the key tree are configured.
  • An enable key block (EKB) that has selected and has the encryption data of the upper key by the lower key on the selected path and that can be decrypted only in a device that can use the node key set corresponding to the selected path.
  • Information processing system with a configuration to provide
  • the activation key block (EKB) is
  • Each of the sub-trees set as a sub-tree of the key tree is configured as a composite E KB of a sub-validation keep-up packet (sub-E KB) that can be decrypted, and a plurality of keys included in the composite E KB
  • An information processing system is characterized in that each data has a configuration stored in a fixed-length data field.
  • the sub-tree is a category that is divided based on a category and is managed by a category and an entity
  • the sub-activation key block (sub-EKB) is Generated as an EKB that can be processed based on the keys associated with the nodes or leaves belonging to the category tree that the category entity manages in the category entity. It is characterized in that it is configured to generate a composite EKB as an EKB that can be used in common for a plurality of category trees based on the sub-EKB thus obtained.
  • each of the sub-validation key blocks includes a sub-validation key block having a unique algorithm and a unique key.
  • the key issuance Sen Yuichi (KD C) fixes each key in the sub EKB that composes the composite EKB in the generation process of the composite EKB based on the sub EKB.
  • Long data file Characterized in that it is configured to execute processing for storing in a field.
  • the combined EKB includes an encryption in which a node key set corresponding to each node configuring the key tree is encrypted using a lower node key or a lower leaf key.
  • the configuration shall include a key and a tag indicating the presence / absence of encryption key data at the lower left / right node or leaf position of each node position of one or more encryption key data stored in the composite EKB. It is characterized by.
  • the combined EKB is a terminal node capable of decoding the combined EKB or a path constituting a simplified tree having a leaf at the bottom, and unnecessary nodes are selected.
  • the key corresponding to the node or leaf of the reconstructed hierarchy tree that is reconstructed by omitting the key is as encryption key data.
  • the combined EKB rearranges a plurality of encryption key data included in each of a plurality of sub EKBs according to a node or leaf position in a key tree. It is characterized by having a configuration generated by the above.
  • an eighth aspect of the present invention provides
  • It is composed of a category tree as a sub-tree divided based on the category, and a key tree in which a key is associated with each of the root, node, and leaf on the path from the root of the tree configured with a plurality of devices to the leaf to the leaf. And only a device that selects a path constituting the key tree, has encryption data of an upper key by a lower key on the selected path, and can use a node key set corresponding to the selected path.
  • An information recording medium that stores an enabling key block (EKB) that can be decrypted.
  • EKB enabling key block
  • Each of the subtrees set as the partial tree of the key tree stores a combined EKB of a sub-validated key block (sub EKB) that can be decrypted, and stores a plurality of key data included in the combined EKB.
  • An information recording medium is characterized in that each has a configuration stored in a fixed-length data field.
  • the sub-activation keep Each lock (sub-EKB) is configured as a sub-validated key block (sub-EKB) with its own algorithm and its own key and data length, and the storage area for the key and data is fixed. It is characterized by having a configuration.
  • a ninth aspect of the present invention is a
  • a key tree is formed by associating a key with each of the root, node, and leaf on the path from the root of the tree, which has a plurality of devices as leaves, to the leaves, and the path constituting the key tree is selected and selected.
  • a configuration is provided in which a device is provided with an enabling key block (EKB) having encryption processing data of an upper key by an upper lower key and enabling decryption only by a device capable of using a node key set corresponding to the selected path.
  • EKB enabling key block
  • the activation key block (EKB) is
  • Each of the subtrees set as the partial tree of the key tree is configured as a composite EKB of a sub-validation keep-up packet (sub-EKB) that can be decrypted, and a plurality of key data included in the composite EKB.
  • the sub-period is a category that is partitioned based on a power category and is managed by a category 'entity, and the sub-validation keep-opening (sub-EKB).
  • a composite EKB is generated as an EKB that can be commonly used for a plurality of category trees.
  • each of the sub-validation key blocks (sub-EKBs) includes a sub-validation key block (sub-EKB) having a unique algorithm and a unique key length.
  • EKB the key issue sen yuichi
  • KD C the key issue sen yuichi
  • the activation key block (EKB) includes a node key set corresponding to each node constituting the key directory as a lower node key or a lower leaf key.
  • the activation key block (EKB) is a simplified tree in which a terminal node or leaf capable of decoding the activation key block (EKB) is at the bottom.
  • a key corresponding to a node or a leaf of a reconstructed hierarchy tree to be reconstructed by selecting a path constituting the network and omitting unnecessary nodes is generated as a configuration having encryption key data.
  • the combined EKB re-encrypts a plurality of encrypted key data included in each of a plurality of sub-EKBs according to a node or leaf position in a key directory. It is characterized by being arranged and generated.
  • a tenth aspect of the present invention provides:
  • a key tree is formed by associating a key with each of the root, node, and leaf on the path from the root of the tree configured with a plurality of devices to the leaves to the leaves, and the path constituting the key tree is selected and selected.
  • a sub-validation key block (sub-EKB) combining process step that can be decrypted in each of the sub-trees set as the sub-tree of the key directory; and each of the plurality of key data included in the combined EKB has a fixed length.
  • a program recording medium characterized by having: Further, the eleventh aspect of the present invention,
  • a key tree in which a key is associated with each of the root, node, and leaf on the path from the root of the tree where a plurality of devices are configured as leaves to the leaves is configured, and the path configuring the key tree is selected.
  • An enabling key block (EKB) that has the encryption processing data of the upper key by the lower key on the selected path and that can be decrypted only in a device that can use the node key set corresponding to the selected path to the device
  • the activation key block (EKB) is
  • Each of the sub-trees set as a sub-tree of the key tree is configured as a composite E KB of a sub-validation keep-up packet (sub-E KB) that can be decrypted, and the composite E KB is stored in each of the sub-validations to be stored.
  • the key arrangement in the key block (sub EKB) is retained, and the data length of the sub EKB storage area and the sub EKB identification data are added for each sub EKB.
  • the sub-tree is a category tree that is partitioned based on a category and managed by a category entity
  • the sub-validation key block (sub-EKB) is:
  • the category / entity is generated as an EKB that can be processed based on a key associated with a node or leaf belonging to a category tree managed by itself in the category / entity.
  • the key issuing center (KDC) generates the category / entity. It is characterized in that it is configured to generate a composite EKB as an EKB that can be used in common for a plurality of category trees based on the sub-EKB thus obtained.
  • each of the sub-activation key blocks has its own algorithm, its own key. EKB).
  • the sub-tree is a category that is partitioned based on a category and managed by a category entity
  • the sub-activation key block (sub-EKB) is category Generated as an EKB that can be processed based on the key associated with the node or leaf belonging to the category tree managed by the re-entity, and stored corresponding to each sub-EKB in the composite EKB
  • the sub-EKB identification data is a node ID which is an identifier of a node constituting a category tree.
  • each of the sub-activation keep locks (sub-EKBs) stored in the composite EKB includes a node key set corresponding to each node constituting the key directory. Indicates the encryption key data encrypted using the lower node key or lower life key, and the presence or absence of the encryption key data at the lower left / right node or leaf position of each node position of the encryption key data. It is characterized by including a tag.
  • each of the sub-activation key blocks (sub-EKBs) stored in the composite EKB includes a terminal node or a leaf capable of decoding the sub-EKB.
  • the key corresponding to the node or leaf of the reconstructed hierarchical tree reconstructed by selecting the path constituting the simplified tree at the bottom and omitting unnecessary nodes is characterized as having encryption key data.
  • a twelfth aspect of the present invention provides:
  • It is composed of a category tree as a sub-tree divided based on the category, and a key that associates a key with each of the routes, nodes, and leaves on the path from the root of the tree to the leaf, where a plurality of devices are configured as leaves. And the path constituting the key tree is selected, and the encryption processing data of the upper key by the lower key on the selected path is included, and the node set corresponding to the selected path can be used.
  • EKB activation key block
  • each of the sub-trees set as a sub-tree of the key tree a combined EKB of a sub-validated key block (sub-EKB) that can be decrypted is stored, and each sub-EKB included in the combined EKB is stored.
  • An information recording medium having a configuration in which the data length of the sub-EKB storage area and the sub-EKB identification data are stored corresponding to the In the body.
  • each of the sub-validation key blocks includes a sub-validation key block (sub-EKB) having a unique algorithm and a unique key length. EKB).
  • a thirteenth aspect of the present invention provides:
  • a key tree in which a key is associated with each of the route, node, and leaf on the path from the root of the tree, which has a plurality of devices as leaves, to the leaf, and the path constituting the key tree is selected.
  • EKB encryption key
  • the activation key block (EKB) is
  • Each of the subtrees set as the partial tree of the key tree is configured as a composite EKB of a sub-validation key block (sub-EKB) that can be decrypted, and the composite EKB is stored in each of the sub-validation key blocks (
  • the key arrangement in the (sub EKB) is retained and provided to the device as a composite EKB with a configuration in which the data length of the sub EKB storage area and the sub EKB identification data are added for each sub EKB.
  • the sub-period is a category that is divided based on a power category and is managed by a category entity.
  • the sub-validation key block (sub-EKB) is generated as an EKB that can be processed based on a key associated with a node or leaf belonging to a category tree managed by the category 'entity in the category' entity, and is issued.
  • KDC the center
  • a composite EKB is generated as an EKB that can be commonly used for a plurality of category trees.
  • the sub-activation keep Each lock (sub-EKB) is characterized as being configured as a sub-validated key block (sub-EKB) with its own algorithm and its own key and data length.
  • the sub-category is a category that is partitioned based on a power category and managed by a category “entity,” and the sub-validation keep opening (sub-EKB) ) Is generated as an EKB that can be processed based on a key associated with a node or a life belonging to a category tree managed by the category-entity, and corresponds to each sub-EKB in the composite EKB.
  • the sub-EKB identification data stored as an ID is a node ID which is an identifier of a node constituting a power category.
  • each of the sub-validated key blocks (sub-EKB) stored in the composite EKB is set corresponding to each node constituting the key tree.
  • Key data obtained by encrypting a node key using a lower node key or a lower key, and the presence or absence of encryption key data at the lower left / right node or leaf position of each node position of the encrypted key data is characterized by including a tag indicating
  • each of the sub-validation key blocks (sub-EKBs) stored in the composite EKB includes a terminal node or a leaf capable of decoding the sub-EKB at the lowest level.
  • a key corresponding to a node or leaf of a reconstructed hierarchy tree that is reconstructed by selecting a path that constitutes a simplified tree that has been simplified and omitting unnecessary nodes is characterized by having encryption key data.
  • a fourteenth aspect of the present invention provides:
  • An enabling key block (EKB) that has encrypted data of the upper key by the lower key on the path and that can be decrypted only by a device that can use the node key set corresponding to the selected path
  • a program recording medium recording a program, wherein the computer program comprises:
  • sub EKB sub-validating key block
  • a key distribution method having a configuration in which each device is arranged on each leaf (leaf) of an n-ary tree using an encryption key distribution configuration having a hierarchical structure of a tree (tree) structure,
  • a content key which is an encryption key for content data, or an authentication key used for authentication processing, or a program code, for example, is distributed via a communication line together with an activation keep-alive.
  • the activation key block is composed of an encryption key data part and a tag part that indicates the position of the encryption key, so that the data amount can be reduced, and the decryption processing in the device can be prepared and executed quickly. I have. With this configuration, it is possible to safely deliver data that only a legitimate device can decrypt.
  • an activation key block which is a decryption key data block that can be decrypted in one or more selected categories, is generated and commonly used by devices belonging to each category tree.
  • EKB activation key block
  • the program recording medium of the present invention is, for example, a medium that provides a computer-readable program to 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, and MO, or a transmission medium such as a network.
  • Such a program recording medium stores a computer program and a recording medium for realizing a predetermined function of a computer program on a computer system. It defines a structural or functional cooperative relationship with the medium. In other words, by installing the computer 'program' in the computer 'system via the recording medium, a cooperative operation is exerted on the computer system, and the same operation and effect as the other aspects of the present invention are obtained. You can do it.
  • the system in the description of the present invention is a logical set of a plurality of devices, and is not limited to a device in which each component is in the same housing.
  • FIG. 1 is a diagram illustrating a configuration example of an information processing system according to the present invention.
  • FIG. 2 is a block diagram showing a configuration example of a recording / reproducing device applicable to the information processing system of the present invention.
  • FIG. 3 is a configuration diagram illustrating a key and data encryption processing in the information processing system of the present invention.
  • FIG. 4 is a diagram showing an example of an activation key block (EKB) used for distribution of various keys and data in the information processing system of the present invention.
  • EKB activation key block
  • FIG. 5 is a diagram showing an example of distribution and an example of decryption processing using a content key activation keep-up key (EKB) in the information processing system of the present invention.
  • EKB content key activation keep-up key
  • FIG. 6 is a diagram showing an example of a format of an enabling key block (EKB) in the information processing system of the present invention.
  • EKB enabling key block
  • FIG. 7 is a diagram for explaining a configuration of a tag of an enabling key block (EKB) in the information processing system of the present invention.
  • EKB enabling key block
  • FIG. 8 is a diagram showing an example of a data configuration for distributing together an activation key block (EKB), a content key, and a content in the information processing system of the present invention.
  • FIG. 9 is a diagram showing a processing example in the device when the activation key block (EKB), the content key, and the content are distributed together in the information processing system of the present invention.
  • FIG. 10 shows the activation key block (EKB) in the information processing system of the present invention.
  • FIG. 7 is a diagram for explaining the correspondence when content and content are stored in a recording medium.
  • FIG. 11 is a diagram comparing the process of sending an enabling key block (EKB) and a content key in the information processing system of the present invention with the conventional sending process.
  • FIG. 12 is a diagram showing an authentication processing sequence using a common key cryptosystem applicable to the information processing system of the present invention.
  • FIG. 13 is a diagram (part 1) illustrating a data configuration for distributing an activation key block (EKB) and an authentication key together in the information processing system of the present invention, and a processing example in a device.
  • EKB activation key block
  • FIG. 14 is a diagram (part 2) showing a data configuration for distributing an enabling key block (EKB) and an authentication key together in the information processing system of the present invention and a processing example in a device.
  • EKB enabling key block
  • FIG. 15 is a diagram showing an authentication processing sequence by a public key cryptosystem applicable to the information processing system of the present invention.
  • FIG. 16 is a diagram illustrating a process of distributing an enabling key block (EKB) and a content key together using an authentication process based on a public key cryptosystem in the information processing system of the present invention.
  • EKB enabling key block
  • FIG. 17 is a diagram showing a process of distributing the activation key block (EKB) and the encrypted program data together in the information processing system of the present invention.
  • FIG. 18 is a diagram showing an example of generating a MAC value used for generating a content integrity check value (ICV) applicable to the information processing system of the present invention.
  • FIG. 19 is a diagram (part 1) illustrating a data configuration for distributing an activation key block (EKB) and an ICV generation key together in the information processing system of the present invention, and a processing example in a device.
  • EKB activation key block
  • FIG. 20 is a diagram (part 2) showing a data configuration for distributing an activation key block (EKB) and an ICV generation key together in the information processing system of the present invention, and a processing example in a device.
  • EKB activation key block
  • FIG. 21 shows a copy protection function when a content integrity (ICV) value applicable to the information processing system of the present invention is stored in a medium.
  • FIG. 21 shows a copy protection function when a content integrity (ICV) value applicable to the information processing system of the present invention is stored in a medium.
  • FIG. 22 is a diagram illustrating a configuration for managing the content integrity 'chip value (ICV) applicable to the information processing system of the present invention separately from the content storage medium.
  • IOV content integrity 'chip value
  • FIG. 23 is a diagram for explaining an example of category classification of a hierarchical tree structure in the information processing system of the present invention.
  • FIG. 24 is a diagram illustrating a process of generating a simplified enabling key block (EKB) in the information processing system of the present invention.
  • FIG. 25 is a diagram for explaining a generation process of an enabling key block (EKB) in the information processing system of the present invention.
  • EKB enabling key block
  • FIG. 26 is a diagram illustrating a simplified enabling key block (EKB) (Example 1) in the information processing system of the present invention.
  • FIG. 27 is a diagram illustrating a simplified activation keep lock (EKB) (Example 2) in the information processing system of the present invention.
  • EKB activation keep lock
  • FIG. 28 is a diagram for explaining a category tree management configuration having a hierarchical tree structure in the information processing system of the present invention.
  • FIG. 29 is a diagram for explaining the details of a categorized management structure having a hierarchical structure in the information processing system of the present invention.
  • FIG. 30 is a diagram for explaining a category tree management configuration having a hierarchical tree structure in the information processing system of the present invention.
  • FIG. 31 is a diagram for explaining a reservoir in a category tree management configuration having a hierarchical tree structure in the information processing system of the present invention.
  • FIG. 32 is a diagram for explaining a new category tree registration processing sequence in a category tree management configuration having a hierarchical tree structure in the information processing system of the present invention.
  • FIG. 33 is a diagram for explaining the relationship between a new category tree and a higher-level category tree in the category tree-management configuration of the hierarchical tree structure in the information processing system of the present invention.
  • FIG. 34 is a diagram showing a category list having a hierarchical structure in the information processing system according to the present invention.
  • FIG. 10 is a diagram illustrating a sub EKB used in one management configuration.
  • FIG. 35 is a diagram illustrating device revocation processing in a category tree management configuration having a hierarchical tree structure in the information processing system of the present invention.
  • FIG. 36 is a diagram for explaining a device revocation processing sequence in a category tree management configuration having a hierarchical tree structure in the information processing system of the present invention.
  • FIG. 37 is a diagram for explaining the update sub EKB at the time of device revocation in the category tree management configuration of the hierarchical tree structure in the information processing system of the present invention.
  • FIG. 38 is a diagram illustrating the category tree revocation processing in the category tree management configuration of the hierarchical tree structure in the information processing system of the present invention.
  • FIG. 39 is a diagram illustrating a category tree re-poke process sequence in a category tree management configuration having a hierarchical tree structure in the information processing system of the present invention. '
  • FIG. 40 is a diagram for explaining the relationship between a repo category tree and a higher-level category tree in a category tree management configuration having a hierarchical tree structure in the information processing system of the present invention.
  • FIG. 41 is a diagram for explaining the setting of the capacity in the category tree management configuration having a hierarchical tree structure in the information processing system of the present invention.
  • FIG. 42 is a diagram for explaining the setting of the capacity in the category tree management configuration having a hierarchical tree structure in the information processing system of the present invention.
  • FIG. 43 is a diagram for explaining a configuration of a capacity management table managed by a key issuing center (KDC) in the information processing system of the present invention.
  • KDC key issuing center
  • FIG. 44 is a flowchart of an EKB generation process based on a capacity management table managed by a key issuing center (KDC) in the information processing system of the present invention.
  • FIG. 45 is a diagram for explaining the capability notification processing at the time of registration of a new category in the information processing system of the present invention.
  • FIG. 46 is a diagram illustrating the configuration of a category tree in the information processing system of the present invention.
  • Figure 47 shows the relationship between the EKB request, the key issuing center, and the top-level 'category' entity (TLCE) in the information processing system of the present invention, and a processing example.
  • FIG. 1 shows the relationship between the EKB request, the key issuing center, and the top-level 'category' entity (TLCE) in the information processing system of the present invention, and a processing example.
  • FIG. 1 shows the relationship between the EKB request, the key issuing center, and the top-level 'category' entity (TLCE) in the information processing system of the present invention, and a processing example.
  • FIG. 48 is a diagram illustrating an example of a hardware configuration of an EKB requester, a key issuing center, and a top-level 'category' entity (TLC E) in the information processing system of the present invention.
  • FIG. 49 is a diagram illustrating a device node key (DNK) held by a device in the information processing system of the present invention.
  • DNS device node key
  • FIG. 50 is a view for explaining a data structure of an EKB type definition list in the information processing system of the present invention.
  • FIG. 51 is a diagram showing an EKB type registration processing flow in the information processing system of the present invention.
  • FIG. 52 is a diagram showing an EKB type invalidation processing flow in the information processing system of the present invention.
  • FIG. 53 is a diagram showing a flow of a parity change notification process in the information processing system of the present invention.
  • FIG. 54 is a diagram showing an EKB type list request processing flow in the information processing system of the present invention.
  • FIG. 55 is a view for explaining the process of generating a sub-EKB in the information processing system of the present invention.
  • FIG. 56 is a view for explaining the generation processing of the sub EKB in the information processing system of the present invention.
  • FIG. 57 is a diagram illustrating a process of generating an EKB synthesized from a sub EKB in the information processing system of the present invention.
  • FIG. 58 is a view for explaining the process of generating a sub-EKB when there is a revoke device in the information processing system of the present invention.
  • FIG. 59 is a diagram illustrating a process of generating an EKB synthesized from a sub-EKB when there is a revoke device in the information processing system of the present invention.
  • FIG. 60 is a view for explaining a data configuration of EKB synthesized from sub EKB in the information processing system of the present invention.
  • FIG. 4 is a diagram for explaining the configuration of the night.
  • FIG. 62 is a view for explaining a data configuration of EKB synthesized from sub EKB in the case where there is a repo device in the information processing system of the present invention.
  • FIG. 63 is a diagram illustrating a revoke process in a data distribution system in the information processing system of the present invention.
  • FIG. 64 is a diagram for explaining a revoke process in the self-recording system in the information processing system of the present invention.
  • 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 the content or the content key and transmits the content or the content key to the various content reproduction 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 obtain the content or content, and reproduces image data and audio data, or executes various programs.
  • Data exchange between the content distribution side 10 and the content reception side 20 is performed via a network such as the Internet Network or via a circulating storage medium such as a DVD or CD. Be executed.
  • the data distribution means of the content distribution side 10 there are the Internet 11, satellite broadcasting 12, telephone line 13, DVD, CD and other media 14 and the like, while the content receiving side 20 device are personal computers (PC) 21; portable devices (PD) 22; portable devices 23 such as mobile phones and PDAs (Personal Digital Assistants); recording / reproducing devices 24 such as DVD and CD players; game terminals, etc. There is a dedicated playback device 25 etc.
  • Each of the devices 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 from the media 30.
  • FIG. 2 shows an example of the device of the content receiving side 20 shown in FIG.
  • FIG. 3 shows a block diagram of the configuration of the device 100.
  • the recording / reproducing apparatus 100 includes an input / output I / F (Interface) 120, an MPEG (Moving Picture Experts Group) codec 130, and an input / output I / F (Interface) including an A / D and a D / A converter 141. 140, cryptographic processing means 150, ROM (Read Only Memory) 160, CPU (Central Processing Unit) 170, memory 180, storage medium 195, and drive 190, which are connected by bus 110 Interconnected.
  • I / F Interface
  • MPEG Motion Picture Experts Group
  • I / F Interface
  • 140 cryptographic processing means 150
  • ROM Read Only Memory
  • CPU Central Processing Unit
  • the input / output I / F 120 receives digital signals that constitute various contents such as images, sounds, and programs supplied from the outside, outputs them on the bus 110, and outputs the digital signals on the bus 110. Receives signals and outputs to outside.
  • the MPEG codec 130 decodes the MPEG-encoded data supplied via the path 110 into MPEG, outputs the data to the input / output I / F 140, and outputs the input / output I / F 140 MPEG encodes the digitized signal supplied from, and outputs it on bus 110.
  • the input / output I / F 140 has a built-in AZD and D / A converter 141.
  • the input / output I / F 140 receives an externally supplied analog signal as content and converts it to AZD (Analog Digital) by the AZD / D / A converter 141 to convert it into a digital signal.
  • AZD Analog Digital
  • the encryption processing means 150 is composed of, for example, a one-chip LSI (Large Scale Integrated Curcuit), and encrypts, decrypts, or authenticates a digital signal as content supplied via the bus 110. And outputs encrypted data, decrypted data, and the like on the bus 110.
  • the cryptographic processing means 150 is not limited to one-chip LSI, but can be realized by a configuration combining various software or hardware. The configuration as the processing means by the software configuration will be described later.
  • the ROM 160 stores the program data processed by the recording / reproducing device.
  • the CPU 170 executes the programs stored in the ROM 160 and the memory 180 to control the MPEG codec 130, the encryption processing means 150, and the like.
  • 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 reads (reproduces) digital data from the recording medium 195 by driving a recording medium 195 capable of recording and reproducing digital data, outputs the digital data to the bus 110, and outputs the digital data to the bus 110.
  • the digital data supplied via 110 is supplied to a recording medium 195 for recording.
  • the recording medium 195 is a medium capable of storing digital data such as an optical disk such as a DVD or a CD, a magneto-optical disk, a magnetic disk, a magnetic tape, or a semiconductor memory such as a RAM. It is assumed here that the configuration is such that it can be attached to and detached from the drive 190. However, the recording medium 195 may be built in the recording / reproducing apparatus 100.
  • the encryption processing means 150 shown in FIG. 2 may be configured as one one-chip LSI, or may be configured to be realized by a configuration combining software and hardware.
  • Namers 0 to 15 shown at the bottom of FIG. 3 are individual devices of the content receiving side 20.
  • each leaf in the hierarchical tree structure shown in Fig. 3 corresponds to a device.
  • Each device 0 to 15 has a key (node key) assigned to a node from its own leaf to the root in the hierarchical tree structure shown in FIG.
  • the key set consisting of the leaf key of the leaf is stored in the memory.
  • K 0 000 to K 1 1 1 1 shown at the bottom of FIG. 3 are leaf keys assigned to each of the devices 0 to 15 from the top KR (root key) to the second node from the bottom.
  • Key described in (node): KR to ⁇ 1 1 1 is the node key.
  • device 0 owns leaf key K 0000 and node keys: K 000, K 00, K 0, and KR.
  • Device 5 owns K 0101, K 010, K 01, K 0, and KR.
  • Device 15 owns K1111, Kill, Kll, Kl, KR.
  • K1111, Kill, Kll, Kl, KR In the tree of FIG. 3, only 16 devices (0 to 15) are described, and the complete structure is also shown as a four-stage balanced balanced symmetrical configuration. It is possible to have a different number of stages in each part of the cell.
  • each device included in the array structure of FIG. 3 includes various recording media such as a DVD, a CD, an MD, a flash memory, and the like, which are embedded in a device or detachably attached to the device.
  • Type devices are included.
  • various application services can coexist. On such a coexistence configuration of different devices and different applications, a hierarchical tree structure, which is a content or key distribution configuration shown in FIG. 3, is applied.
  • a portion surrounded by a dotted line in FIG. 3, that is, devices 0, 1, 2, and 3 are set as one group using the same recording medium.
  • the common content is encrypted and sent from the provider, the content key used commonly for each device is sent, or each device is sent.
  • the payment data of the content fee is encrypted and output from the service provider or the settlement institution, the process is executed.
  • Institutions that send and receive data to and from each device such as content providers or payment processing institutions, collectively collect data as a group surrounded by the dotted line in Figure 3, that is, devices 0, 1, 2, and 3. Is executed.
  • An organization that transmits and receives data to and from each device functions as a message data distribution means. .
  • the node key and leaf key may be managed collectively by a single key management center, or may be managed for each group by message data distribution means such as a provider that performs various types of data transmission / reception for each group and a payment institution. Configuration and May be. These node keys and leaf keys are updated in the event of, for example, a key leak, and this update process is executed by a key management center, a provider, or a payment institution.
  • the three devices 0, 1, 2, and 3 included in one group have common keys K00, K0, and KR as node keys.
  • this node key sharing configuration for example, it becomes possible to provide a common content to only devices 0, 1, 2, and 3.
  • the common node key # 00 itself is set as a content key, only the devices 0, 1, 2, and 3 can set a common content key without sending a new key.
  • the value Enc (00, Kcon) obtained by encrypting the new content key K c 0 ⁇ with the node key 00 is stored via the network or in a recording medium, and the device 0, 1, 2 , If you distribute to 3, device
  • K con by decrypting the encryption Enc (K 0, K con) using the shared node key K 00 held in each device.
  • Enc (K a, Kb) indicates that Kb is data encrypted by Ka.
  • a key owned by the device 3 ⁇ ⁇ ⁇ ⁇ ⁇ , ⁇ ⁇ ⁇ ⁇ ,
  • K (t) 0 0, K ( ⁇ ) ⁇ , ⁇ (t) R needs to be updated and the updated key must be sent to devices 0, 1, 2.
  • K (t) a a a is the generation of the key K a a a
  • a table composed of block data called an enabling key block (EKB) shown in Fig. 4 (A) is stored on a network or a recording medium, for example. This is performed by supplying the data to devices 0, 1, and 2.
  • the activation key block (EKB) is assigned to each leaf that makes up the tree structure shown in Fig. 3. It consists of an encryption key for distributing the newly updated key to the corresponding device.
  • An enabling key block (EKB) is sometimes called a key renewal block (KRB).
  • the activation key block (EKB) shown in Fig. 4 (A) is configured as block data that has a data structure that allows only devices that require node key updates to be updated.
  • the example in FIG. 4 is a block diagram formed for the purpose of distributing an updated node key of generation t to devices 0, 1, and 2 in the tree structure shown in FIG.
  • device 0 and device 1 require (t) 0 0, K (t) 0, and K (t) R as update node keys, and device 2 as an update node key.
  • K (t) 001, K (t) 00, K (t) 0, and K (t) R are required.
  • EKB contains multiple encryption keys.
  • the encryption key at the bottom is Enc (K 0 0 10, K (t) 0 0 1). This is the updated node key K (t) 00 1 encrypted with the leaf key K 00 10 held by device 2, and device 2 decrypts this encrypted key with its own leaf key, and K (t) 0 0 You can get one. Also, using K (t) 00 1 obtained by decryption, the encryption key Enc (K (t) 01, K (t) 0 0) in the second stage from the bottom in FIG. Decoding becomes possible, and an updated node key K (t) 00 can be obtained.
  • the encryption key Enc (K (t) 00, K (t) 0) of the second stage from the top in FIG.4 (A) is sequentially decrypted, and the updated node key K (t) 0, FIG.4 (A) ) Decrypts the encryption key Enc (K (t) 0, ⁇ ( ⁇ ) R) from the top to obtain ⁇ (t) R.
  • the encryption key Enc (K (t) 00, K (t) 0) of the second stage from the top in FIG.4 (A) is sequentially decrypted, and the updated node key K (t) 0, FIG.4 (A) ) Decrypts the encryption key Enc (K (t) 0, ⁇ ( ⁇ ) R) from the top to obtain ⁇ (t) R.
  • node key KOO 0 is not included in the update target, and K (t) 00, K (t) 0, K (t) R It is.
  • Device 0 000.K 0 00 1 decrypts the third encryption key Enc (K 00 0, K (t) 0 0) from the top in FIG. After that, the encryption key Enc (K (t) 00, K (t) 0) in the second stage from the top in Fig. 4 (A) is decrypted, and the updated node key K (t) 0, Fig. 4 ( A) decrypts the first encryption key Enc (K ( ⁇ ) 0, ⁇ (t) R) from above to obtain K (t) R. In this way, devices 0, 1, and 2 can obtain the updated key K (t) R.
  • the index in Fig. 4 (A) indicates the absolute address of the node key and leaf key used as the decryption key.
  • the EKB shown in Fig. 4 (B) can be used, for example, when distributing new content shared by a specific group.
  • a specific group it is assumed that devices 0, 1, 2, and 3 in the group indicated by the dotted line in FIG. 3 use a recording medium and a new common content key K (t) con is required.
  • data obtained by encrypting a new common updated content key: K (t) con using K (t) 00 obtained by updating the common key K00 of devices 0, 1, 2, and 3 Enc (K (t), ⁇ (t) con) is distributed along with the E KB shown in Fig. 4 (B). This distribution makes it possible to distribute data that cannot be decrypted by devices of other groups, such as Depais4.
  • devices 0, 1, and 2 can obtain the content key K (t) con at time t by decrypting the ciphertext using K (t) 00 obtained by processing the EKB. Become.
  • FIG. 5 as an example of processing for obtaining a content key K (t) con at time t, a data Enc (en) obtained by encrypting a new common content key K (t) con using K (t) 00.
  • the device 0 performs the same EKB processing as described above using the generation stored at the recording medium: the EKB at time t and the node key K0000 stored in advance by itself. Generate the node key K (t) 00. Furthermore, the updated content key K (t) con is decrypted using the decrypted updated node key K (t) 0 0, and is encrypted using the leaf key K 0000 that is held only by the user in order to use it later. And store it.
  • Figure 6 shows an example of the format of the activation keep mouth (EKB).
  • Purgeyon 6001 is an identifier indicating the version of the activation key block (EKB).
  • the version has the function to identify the latest EKB and the function to show the correspondence between the contents.
  • Depth indicates the number of layers in the hierarchy per device to which the activation key pro- cess (EKB) is distributed.
  • the data pointer 603 is a pointer that indicates the position of the data part in the activation key block (EKB), 604 is the position of the tag part, and 605 is the pointer that indicates the position of the signature. is there.
  • the data section 606 stores, for example, data obtained by encrypting a node key to be updated. For example, each encryption key related to the updated node key as shown in FIG. 5 is stored.
  • the tag section 607 is a tag indicating the positional relationship between the encrypted node key and leaf key stored in the data section.
  • This tag assignment rule will be described with reference to FIG. Fig. 7 shows an example of sending the activation keep lock (EKB) described in Fig. 4 (A) as data.
  • the data at this time is as shown in Table (b) of FIG.
  • the top node address included in the encryption key at this time is the top door address.
  • the update key K (t) R of the root key is included, so the top node address is KR.
  • the data E nc (K (t) 0, K (t) R) at the top is at the position shown in the hierarchical tree shown in FIG.
  • tags are set for all data, and the data column and evening column shown in Fig. 7 (c) are configured.
  • the tag is set to indicate where the data Enc (Kxxx, Kyy) is located in the tree structure.
  • a signature is an electronic signature executed by, for example, a key management center, a content provider, or a payment institution that issued an activation key block (EKB).
  • the device that has received the EKB verifies the signature by verifying that it is a valid activation key block (EKB) issued by the issuer.
  • FIG. 8 shows the data structure.
  • Enc (K con, cont ent) 801 is data obtained by encrypting the content with the content key (K con)
  • Enc (KEK, K con) 802 is data obtained by encrypting a content key (K con) with a content key encryption key (KEK).
  • Enc (EKB, KEK) 803 is a content key encryption key KEK. Activate the key block (EKB) Indicates that there is.
  • the content key encryption key KEK may be the node key (K 000, K 00%) Shown in FIG. 3 or the root key (KR) itself, or the node key (K 00 0, K 00). ⁇ ), or a key encrypted by a root key (KR).
  • Fig. 8 (b) shows an example of a configuration in which a plurality of contents are recorded on a medium, and each uses the same Enc (EKB, KEK) 805.
  • Enc EKB, KEK
  • data indicating the link destination linked to Enc EKB, KEK
  • 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 K 00 shown in FIG.
  • device 3 is revoked (excluded) due to, for example, leakage of a key in a group surrounded by a dotted line frame in FIG. 3, and the members of other groups, that is, devices 0, 1, and 2, are As shown in Fig.
  • the decoding procedure in device 0 is shown on the right side of FIG.
  • the content key K con is obtained by decryption using K (t) 00, and the content is further decrypted using the content key K con.
  • the device 0 can use the content.
  • the activation key block (EKB), content key, encryption content, etc. can be safely distributed via the network.
  • the activation key block (EKB), content key, encryption It is also possible to store the content on a recording medium such as a DVD or CD and provide it to the user.
  • the encrypted content stored on the recording medium is decrypted by using a content key obtained by decrypting the activation keep packet (EKB) stored on the same recording medium, Distribution processing of encrypted content that can be used only with leaf keys and node keys held only by the rightful holders, that is, content distribution with limited available user devices can be realized with a simple configuration.
  • FIG. 10 shows an example of a configuration in which an enabling key block (EKB) is stored together with encrypted content on a recording medium.
  • contents C 1 to C 4 are stored on a recording medium, and data in which an activation keep-opening (EKB) corresponding to each storage content is stored.
  • EKB—M the activation keep block
  • EKB-1 is used to generate a content key Kcon1 that encrypts content C1.
  • EKB-2 is used to generate a content key Kcon2 that encrypts content C2. used.
  • the activation key block (EKB-M) of version M is stored in the recording medium, and the contents C 3 and C 4 are associated with the activation key block (EKB-M).
  • the content keys of the contents C 3 and C 4 can be obtained by decrypting the activation key block (EKB-M).
  • EKB 1 Since EKB-2 is not stored on the disc, acquire EKB-1 and EKB-2 required for decrypting each content key by new means of distribution, such as network distribution or distribution by recording medium It is necessary to do.
  • Figure 11 shows a comparative example of content key distribution using the EKB when content keys are distributed between multiple devices and conventional content key distribution processing.
  • the upper part (a) shows a conventional configuration
  • the lower part (b) shows an example using the enabling key block (EK B) of the present invention.
  • Ka (Kb) indicates that the data is obtained by encrypting Kb with Ka.
  • authentication processing is performed between devices in order to confirm the validity of the data sender and receiver and to share the session key K ses used for encryption of data transmission.
  • a key exchange process (AKE: Authentication and Key Exchange) is executed, and the content key Kc ⁇ ⁇ is encrypted and transmitted by the session key Kses on condition that the authentication is established.
  • the content key K ses (K con) encrypted with the received session key can be decrypted with the session key to obtain K con. It becomes possible to encrypt con with the storage key K str held by the PC itself and save it in its own memory.
  • Fig. 11 (a) even if the content provider wants to distribute data in a form that can be used only to the recording device 111 in Fig. 11 (a), there is a PC and playback device in between As shown in Fig. 11 (a), it is necessary to execute the authentication process, encrypt the content key with each session key, and distribute it. Also, the PC and playback device interposed therebetween can use the session key generated and shared in the authentication process to decrypt the encrypted content key and obtain the content key.
  • the content provider processes the activation key block (EKB) and the activation key block (EKB).
  • K root K con in the example in the figure
  • EKB activation key block
  • an activation key block (EKB) that can be used only at the right end of Fig. 11 (b) is generated, and the activation key block (EKB) and the key obtained by the EKB processing are generated.
  • the intervening PC, playback device, etc. may execute EKB processing depending on its own leaf key and node key. Can not do it. Therefore, content keys that can only be used safely and with valid devices without performing processes such as authentication between data transmitting and receiving devices, generation of session keys, and encryption of content keys K con by session keys. Can be distributed.
  • EKB enabling key block
  • Figure 12 shows a mutual authentication method (IS0 / IEC 9798-2) using a common key cryptosystem.
  • DES is used as a common key encryption method, but other methods can be used as long as the common key encryption method is used.
  • B generates a 64-bit random number Rb, and transmits Rb and its own ID (b) to A.
  • this A receives the key, generates a new 64-bit random number Ra, and 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 that is stored in each recording element as a secret key common to A and B.
  • the initial value and the Ra are exclusive-ORed, and the key K ab is used in the DES encryption unit.
  • a ciphertext E1 is generated, and then the ciphertext E1 and Rb are exclusive-ORed, and in the DES encryption unit, the ciphertext E2 is encrypted using the key Kab.
  • the ciphertext E 2 and the ID (b) are exclusive-ORed, and the DES encrypting unit encrypts the ciphertext E2 with the key Kab and generates the transmission data (Token -AB).
  • B decrypts the received data with the key K ab (authentication key), which is also stored in each storage element as a common secret key.
  • the received data is decrypted by first decrypting the ciphertext E1 with the authentication key Kab to obtain a random number Ra.
  • the ciphertext E 2 is decrypted with the authentication key K ab, and the result is exclusively ORed with E 1 to obtain R b.
  • the ciphertext E 3 is decrypted with the authentication key K ab, and the result is XORed with E 2 to obtain I D (b). From the obtained Ra and R bit ID (b), it is verified that Rb and ID (b) match those transmitted by B. If it passes, B authenticates A as valid.
  • B generates a session key (K se s) to be used after authentication (the generation method uses random numbers). Then, in the order of R b, R a, and K se s, the data is encrypted using the authentication key K ab in the C CBC mode of DES, and is returned to A.
  • A decrypts the received data with the authentication key K ab. Since the decoding method of the received data is the same as the decoding process of B, the details are omitted here. Of the R b, R a, and K se s thus obtained, it is verified whether R b and R a match those transmitted by A. If it passes, A authenticates B as valid. After mutually authenticating each other, the session key K ses is used as a common key for secret communication after authentication.
  • a and B share a common authentication key Kab.
  • the common key Kab is delivered to the device using the above-mentioned activation key block (EKB).
  • either A or B generates an activation key block (EKB) that the other can decrypt and encrypts the authentication key Kab using the generated activation key block (EKB).
  • a third party may generate an enabling key block (EK B) that can be used by both parties for devices A and B, and send them to devices A and B.
  • the authentication key K ab may be encrypted and distributed using an activation key block (EKB) generated by the above.
  • Figures 13 and 14 show configuration examples in which an authentication key Kake common to multiple devices is distributed by an activation key block (EKB).
  • Fig. 13 shows an example of distributing a decryptable authentication key K ae to devices 0, 1, 2, and 3.
  • Fig. 14 revokes (excludes) device 3 of devices 0, 1, 2, and 3.
  • an authentication key that can be decrypted is distributed only to devices 0, 1, and 2.
  • the updated node key K (t) 00 is used together with the data (b) obtained by encrypting the authentication key Kake and the node keys and leaf keys of the devices 0, 1, 2, and 3 respectively.
  • Each device first obtains an updated node key K (t) 00 by processing (decrypting) the EKB as shown on the right side of FIG. 13, and then obtains the obtained node key K (t)
  • the authentication key encrypted using 00: En c (K (t) 00, Kake) can be decrypted to obtain an authentication key K ake.
  • the other devices 4, 5, 6, 7 ... receive the same activation key block (EKB), but their own node keys and leaf keys process the EKB and update the node key K (t) 00 Since the authentication key cannot be obtained, the authentication key can be safely sent only to the legitimate device.
  • EKB activation key block
  • EKB EKB
  • data is transmitted by encrypting (a) the activation keep key (EKB) and (b) the authentication key (Kake) with the node key (K () 00).
  • the decoding procedure is shown on the right side of FIG. First, the devices 0, 1, and 2 acquire the updated node key (K (t) 00) from the received activation keep-up packet by decryption processing using the leaf key or the node key owned by the device. Next, an authentication key Kake is obtained by decryption using K (t) 00.
  • the devices 4, 5, 6,... Of the other groups shown in FIG. 3 receive the similar data (EK B), but update their node keys (K (t) 00) using their own leaf keys and node keys. Can not get. Similarly, the revoked device 3 cannot acquire the renewal node key (K (t) 0 0) with its own leaf key and node key, and only the depayes who have valid rights have the authentication key. Can be decrypted and used.
  • EKB activation key block
  • Ra and Rb are each 64 bits, and since the X coordinate and the coordinate of Av are each 160 bits, the electric power for a total of 448 bits is obtained. Generate a child signature.
  • Receives A's public key certificate, Ra, Rb, Av, digital signature ⁇ . 31: 8 verifies that Rb sent by A matches the one generated by B. As a result, if they match, the electronic signature in the public key certificate of A is verified with the public key of the certificate authority, and the public key of A is extracted. Then, the electronic signature A. Sig is verified using the extracted public key of A.
  • Ra, Av, electronic signature B. Public key certificate of B, R; Av. Receiving Big Sig verifies that Ra sent by B matches the one generated by A. As a result, if they match, the digital 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, the digital signature B.Sig is verified using the extracted public key of B. After successfully verifying the electronic signature, A authenticates B as valid.
  • B is calculated as BkxAv (Bk is a random number, but Av is a point on the elliptic curve, so scalar multiplication of the point on the elliptic curve is required), and ⁇ is Ak XBV is calculated, and the lower 64 bits of the X coordinate of these points are used as a session key for subsequent communication (when the common key encryption is a 64-bit key length common key encryption).
  • the session key may be generated from the Y coordinate, and may not be the lower 64 bits.
  • the transmitted data may not only be encrypted with the session key, but also may be digitally signed.
  • FIG 16 shows an example of content key distribution using public key authentication and an activation key block (EKB).
  • authentication processing using the public key method described in Fig. 15 is executed between the content provider and the PC.
  • the content provider generates an EKB that can be decrypted by the playback device to which the content key is distributed, the node key of the recording medium, and the leaf key, and encrypts the content using the updated node key.
  • the content key E (K con) and the activation key block (EKB) are encrypted with the session key K ses generated in the authentication process between the PCs and transmitted to the PC.
  • the PC decrypts the content key E (Kcon) that was encrypted with the updated node key and the activation key block (EKB) encrypted with the session key using the session key, and then sends it to the playback device or recording medium. I do.
  • the playback device or recording medium decrypts the content by decrypting the content key E (K con) that has been encrypted with the updated node key and the activation key process (E KB) using its own node key or leaf key. Get the key Kcon.
  • Fig. 17 shows an example of encrypting the program code by an update key block (EKB), for example, and transmitting it between devices.
  • the device 1701 is a device that uses an activation key block (EKB) that can be decrypted by the node key and leaf key of the device 17002, and a program code that has been encrypted using the updated node key included in the activation key block (EKB). 1 Send to 702.
  • the device 1702 processes the received EKB to obtain an updated node key, and further decrypts the program code using the obtained updated node key to obtain a program code.
  • the processing according to the program code acquired in the device 1702 is executed, and the result is returned to the device 1701, and 1701 shows an example in which processing is further continued based on the result.
  • C l and C 2 are content information, and a message authentication code (M AC: Message authentication Code) of important information of the content is used.
  • Figure 18 shows an example of MAC value generation using the DES encryption configuration.
  • the target message is divided into 8-byte units (hereinafter, the divided messages are referred to as Ml, ⁇ 2, ⁇ , ⁇ ), and first, the initial value ( Exclusive OR the Initial Value (hereinafter referred to as IV)) and M 1 (the result is referred to as I 1).
  • I 1 is put into a DES encryption unit, and is encrypted using a key (hereinafter, referred to as K 1) (the output is E 1).
  • K1 and M2 are exclusive-ORed, and the output I2 is input to the DES encryption unit, and is encrypted using the key 1 (output E2).
  • E2 message authentication code
  • a content integrity check value is generated using a hash function applied to the MAC value of the content and the ICV generation key. For example, comparing the ICV generated at the time of content generation and the ICV generated based on the new content to ensure that there is no tampering, if the same I CV is obtained, it is guaranteed that the content has not been tampered with If the I CV is different, it is determined that tampering has occurred. It is.
  • Fig. 19 shows an example of distributing a decryptable check value generation key KicV to devices 0, 1, 2, and 3.
  • Fig. 20 shows that device 3 of devices 0, 1, 2, and 3 is revoked.
  • An example of distributing a peak value generation key KicV that can be decrypted only to devices 0, 1, and 2 is shown below.
  • the update value K (t) 00 is used to encrypt the check value generation key KicV together with the data (b), and the device 0, 1, 2, 3 Generate and distribute an enabling key block (EKB) capable of decrypting the node key K (t) 00 updated using the node key and the leaf key having the key.
  • Each device first obtains an updated node key K (t) 00 by processing (decrypting) the EKB as shown on the right side of FIG. 19, and then obtains the obtained node key K (t).
  • the other devices 4, 5, 6, 7 ... receive the same activation key block (EKB), but their own node keys and leaf keys process the EKB and update the node key K (t) 00. Since it cannot be obtained, the check value generation key can be safely sent only to valid devices.
  • the device 3 is revoked (excluded) due to, for example, key leakage in the group surrounded by the dotted line frame in FIG. 3, and the men of other groups, that is, the devices 0, 1,
  • an activation key block (E KB) that can be decrypted only for, is generated and distributed.
  • the decoding procedure is shown on the right side of FIG. First, the devices 0, 1, and 2 obtain the updated node key (K (t) 00) from the received activation keep-up packet by performing decryption processing using the leaf key or node key owned by the device. Next, a check value generation key K i c V is obtained by decryption using K (t) 00.
  • the devices 4, 5, 6, ... of the other groups shown in Fig. 3 receive the similar data (EK B), but update their node keys (K (t) 00) using their own leaf keys and node keys. Can not get. Similarly, the revoked device 3 cannot obtain the update node key (K (t) 0 0) with its own leaf key and node key, and only the device having the right has the check value generation key. Can be decrypted and used.
  • the configuration is such that the integrity 'check value (ICV (C1, C2)) is stored in association with the content properly stored in each medium.
  • (ICV (C1, C2)) is the content integrity calculated using the number of hash values for the contents C1 and C2.
  • Check value ICV hash (Kiev, CI, C 2).
  • content 1 and content 2 are properly stored in media 1, and the integrity check value generated based on content C1 and content C2.
  • ICV (CI, C2) is stored.
  • the content 2 is properly stored in the medium 2, and the integrity check value (ICV (C1)) generated based on the content C1 is stored.
  • the counter count e r + l
  • the counter value must be stored in a secure memory.
  • the content integrity check value (ICV) may be stored on a different media from the content. Good.
  • the integrity check value (ICV)
  • the ICV integrity check value
  • the ICV is stored on a secure medium on the host machine, and the ICV is used for content copy control (for example, check-in / check-out, move).
  • safe management of ICV and falsification check of content are enabled.
  • FIG. 22 shows an example of this configuration.
  • Figure 22 shows read-only media and normal MO Content is stored on non-copy-protected media 222 and the integrity check value (ICV) for these contents can be secured on a host machine that is not allowed to be freely accessed by users.
  • the user is stored in a safe medium 222 to prevent the user from rewriting the integrity check value (ICV).
  • the PC or server as a host machine performs an ICV check to determine whether or not the media can be played.
  • ICV check integrity check
  • the encryption key is configured as the hierarchical tree structure shown in Fig. 3 with the root key, node key, leaf key, etc., and the content key, authentication key, ICV generation key, or program code, data, etc. together with the activation key block (EKB)
  • EKB activation key block
  • Fig. 23 shows an example of category classification in a hierarchical tree structure.
  • a root key K root 2301 is set at the top of the hierarchical tree structure
  • a node key 2302 is set at the following middle
  • a leaf key 2 is set at the bottom. 3 0 3 is set.
  • Each device has an individual leaf key and a series of node keys from the leaf key to the root key, the root key.
  • a node having an M-th stage from the top is set as a category node 2304.
  • each of the M-th nodes is a device setting node of a specific category.
  • One node in the Mth stage is defined as a vertex, and the nodes and leaves in the M + 1th stage and below are nodes and leaves related to devices included in the category.
  • the category [MemoryStick (trademark)] is set to one node 2305 in the M-th stage in Fig. 23, and the nodes and leaves following this node include various devices using the memory stick. Configured as a category-specific node or leaf.
  • nodes 2 and 3 Is defined as a set of related nodes and leaves of the device defined in.
  • a stage several stages lower than the M stage can be set as a subcategory node 2306.
  • a node below the category [Memory Stick] node 2305 is a sub-category node included in the category of the device using Memory Stick.
  • the node 2303 of the telephone with a music playback function included in the category of the playback-only device is set below the node 2303 of the playback-only device, which is a subcategory node, and further below that, [PHS] node 2308 and [mobile phone] node 2309 included in the category of phones with music playback function can be set.
  • categories and sub-categories are not only device types, but also arbitrary units (eg, nodes managed by a certain manufacturer, content provider, payment institution, etc., ie, processing units, jurisdiction units, or provided service units, etc.) These are collectively referred to as entities below).
  • entities eg, nodes managed by a certain manufacturer, content provider, payment institution, etc., ie, processing units, jurisdiction units, or provided service units, etc.
  • entities below For example, if one category node is set as a dedicated vertex node for a game device XYZ sold by a game device manufacturer, the game device XYZ sold by the manufacturer stores the lower node key and leaf key below that vertex node for sale. After that, the distribution of the encrypted content, or the distribution and update of various keys, is performed by generating an activation keep key (EKB) composed of the node keys and leaf keys below the top node key. Data that can be used only for devices below the top node.
  • EKB activation keep key
  • one vertex of the category stage or the subcategory stage is set. It is possible for a manufacturer or a content provider that manages a node to independently generate an activation key procedure (EKB) having the node as a vertex and distribute it to devices belonging to the vertex node and below.
  • EKB activation key procedure
  • a key such as a content key
  • an activation key block (EKB) that can be decrypted using the leaf key and node key owned by the key distribution destination device is generated and provided.
  • keys for example, content keys are transmitted to the devices a, g, and j that make up the leaf
  • each node of a, g, and j can enable decryption.
  • EKB key block
  • a content key K (t) con is encrypted using an updated root key K (t) root and distributed with EKB.
  • the devices a, g, and j each execute EKB processing to obtain a K (t) root using the leaf and node keys shown in FIG. 24 (b), and obtain the obtained update root key K ( t)
  • the content key K ( ⁇ ) c ⁇ ⁇ is decrypted by root to obtain the content.
  • the configuration of the activation key block ( ⁇ ) provided in this case is as shown in Fig. 25.
  • the activation key block ( ⁇ ) shown in Fig. 25 is configured according to the format of the activation key block ( ⁇ ) described in Fig. 6 above, and corresponds to data (encryption key).
  • tag As described with reference to Fig. 7, the tag indicates left (L), right (R), 0 if there is data in each direction, and 1 if there is no data.
  • the device that has received the activation key block (E KB) executes the decryption processing of the encryption key sequentially based on the encryption key and the tag of the activation key block (E KB) to update the upper node. Get keys.
  • the data volume of the activation key block (EKB) increases as the number of steps (debs) from the root to the leaf increases.
  • the number of steps (depth) increases with the number of devices (leaves). If the number of devices to which keys are distributed is large, the EKB data size will be even larger.
  • FIG. 26 shows an example in which the activation key block (EKB) is simplified according to the key distribution device.
  • the keys for devices a, g, and j that make up the leaf It is assumed that the content is transmitted.
  • a tree composed only of key distribution devices is constructed.
  • the parity configuration shown in FIG. 26B is constructed as a new parity configuration based on the configuration shown in FIG. 24B. It is sufficient if there is no branch from Kroot to Kj and there is only one branch.In order to reach from Kr0 ot to Ka and Kg, only a branch point is formed at K0.
  • the tree shown in Fig. 26 (a) is constructed.
  • a simplified tree having only K 0 as a node is generated.
  • the activation key block (EKB) for update key distribution is generated based on these simplified sequences.
  • the tree shown in Fig. 26 (a) is an unnecessary node by selecting a path that constitutes a terminal node that can decode the activation keep-up packet (EKB) or a bifurcated tree with leaves at the bottom. Is a reconstructed hierarchy tree that is reconstructed by omitting.
  • the activation key block (EKB) for update key distribution is constructed based only on the keys corresponding to the nodes or leaves of this rebuilding hierarchy.
  • the activation key block (EKB) described in Fig. 25 stores the encrypted data of all keys from each leaf a, g, j to K root. KB stores the encrypted data only for the nodes that make up the simplified tree.
  • 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 in that direction.
  • the first bit is a bit that indicates whether the encryption key is stored in EKB, and is set to 1 if data is stored and set to 0 if there is no data. Is done.
  • device a decrypts encrypted data Enc (Ka, K ( ⁇ ) 0) with leaf key ⁇ a, obtains node key K (t) 0,
  • the encrypted data Enc (K (t) 0, K (t) root) is decrypted by one key K (t) 0 to obtain K (t) root.
  • the decryption j decrypts the encrypted data Enc (K j, K ( ⁇ ) root) with the leaf key ⁇ j to obtain K (t) root.
  • EKB activation key block
  • the configuration described with reference to Fig. 26 is based on selecting an end node that can decode the enabling key block (EKB) or a path that constitutes a two-branch tree with the leaf at the bottom, and omit unnecessary nodes. It was a reconstructed hierarchical tree that was rebuilt.
  • the activation key block (EKB) for renewal key distribution is based solely on the keys corresponding to the nodes or leaves of this reconstructed hierarchical tree.
  • the restructured hierarchical tree shown in Fig. 26 (a) enables the update root key K (t) root to be acquired at leaves a, g, and j. Therefore, the activation key block (EKB) shown in Fig. 26 (b) can be obtained. ).
  • leaf j uses a single decryption process of Enc (Kj, K (t) root) to change the root key: K (t) root. Can be obtained.
  • leaves a and g obtain K (t) 0 by decoding E nc (Ka, K (t) 0) or E nc (Kg, K (t) 0), and then nc (K (t) 0, K (t) root) is decrypted to obtain a root key: K (t) root. That is, the leafs a and g need to execute the decoding process twice.
  • the simplified rebuilding hierarchy shown in FIG. 26 shows that node K0 performs its own management as the management node of its lower leaves a and g.
  • the node manages the lower leaf it is effective to confirm that the leaves a and g have obtained the update key, but the node K0 manages the lower leaf. If not, or if the update key distribution from the upper node is permitted even if it has been performed, the reconstructed hierarchy shown in Fig. 26 (a) is further simplified and the node K0
  • the activation key block (EK B) may be generated and distributed by omitting the key of (1).
  • Figure 27 shows the configuration of such an activation key block (EKB).
  • EKB activation key block
  • a key for example, a content key is transmitted to devices a, g, and j constituting a leaf.
  • a tree is constructed by directly connecting the root Kroot and each of the lives a, g, and j.
  • a simplified tree with the node K0 omitted is generated from the reconstructed hierarchy tree shown in FIG. 26 (a).
  • the activation key block (EKB) for update key distribution is generated based on these simplified trees.
  • the tree shown in Fig. 27 (a) is a reconstructed hierarchy tree that is reconstructed only by the path directly connecting the leaf that can decrypt the activation key block (EKB) and the root.
  • the activation key block (EKB) for update key distribution is based solely on the key corresponding to the leaf of this reconstructed hierarchical tree.
  • Fig. 27 (a) is a configuration example in which the end is a leaf.
  • EKB activation keep key
  • the reconstructed hierarchy tree has a configuration in which the vertex nodes forming the simplified tree and the terminal nodes or leaves forming the simplified tree are directly connected.
  • the number of branches from the top node is not limited to two, and it can be configured as a tree having three or more branches according to the number of distribution nodes or leaves.
  • the activation key block (EKB) described in Fig. 25 stores data obtained by encrypting all keys from each leaf a, g, j to K root, and is described in Fig. 26.
  • the activation key block (EKB) was configured to store leaf keys for leaves a, g, and j, K 0 as a common node for a and g, and a root key.
  • the activation key block (EKB) based on the simplified hierarchy tree shown in Fig. 27 (a), the key of node K0 is omitted, and as shown in Fig. 27 (b), the data volume is further reduced. Less activation key block (EKB).
  • the activation keep block (EKB) in Fig. 27 (b) has a 3-bit configuration tag like the activation key block (EKB) in Fig. 26 (b).
  • the second and third bits indicate 0 when there is data in the left (L :) and right (R) directions, and 1 when there is no data in each direction, as described with reference to FIG.
  • the first bit is a bit that indicates whether the encryption key is stored in the EKB, and is 1 if data is stored and 1 if no data is stored. , Set as 0.
  • each leaf a, g, j is En c (K a, K (t) root) or Enc (Kg, K (t) root)
  • the root key: K (t) root can be obtained by one decryption process of £] 10 (1 ⁇ ', 1 ⁇ (1) 0 0 1:).
  • An activation key block generated based on a tree that has a configuration in which the top node of the simplified reconstructed tree is directly connected to the terminal node or leaf that constitutes the tree. As shown in FIG. 27 (b), is constructed based only on the keys corresponding to the top node and the terminal node or leaf of the reconstructed hierarchy tree.
  • the simplified new tree structure composed only of the destination device is constructed, and the leaf composing the constructed tree is constructed.
  • Generating the activation key block (EKB) using only the key of the leaf or the common node it is possible to generate the activation key block (EKB) with a small amount of data. EKB) data distribution can be executed efficiently.
  • the category tree is a collective pro- gram of a plurality of nodes or leaves selected from the nodes or leaves constituting the key structure as a key distribution structure.
  • the category is a set set according to the type of device, or a category. It is set as a set of various modes, such as a processing unit having a common point, a jurisdiction unit, or a provided service unit, such as a management unit of a vice provider manufacturer, a content provider, a payment institution, or the like.
  • devices that fall into a common category are collected.
  • a simplified tree similar to that described above is reconstructed using vertex nodes (subroutines) of a plurality of category trees.
  • vertex nodes subroutines
  • EKB simplified enabling key block
  • an enabling key block can be configured to be stored on an information recording medium such as an optical disk or a DVD.
  • an update node key is added to an activation keep block (EKB) including a data portion composed of the above-described encryption key data and a tag portion as position identification data in a hierarchical tree structure of the encryption key data.
  • each device is provided with an information recording medium storing the encrypted message data such as content and the like.
  • the device can sequentially extract and decrypt the encryption key data contained in the activation key block (EKB) according to the identification data of the tag part, obtain the key necessary for decrypting the content, and use the content. It becomes possible.
  • the configuration may be such that the validation keep-up (EKB) is distributed via a network such as the Internet.
  • a block as a set of a plurality of nodes or leaves is hereinafter referred to as a category.
  • a category is a set that is set according to the type of device, or a processing unit, jurisdiction unit, or provided service that has a certain common point, such as a management unit of a device provider, content provider, or payment institution. It is set as a set of various aspects such as units.
  • FIG. 28 (a) is a diagram for explaining a management configuration of a per-category unit.
  • One category tree is shown as a triangle in the figure.
  • there are multiple nodes. Mode is included.
  • (B) shows the node configuration in one category tree.
  • One category tree is composed of a multi-stage two-branch tree with one node as a vertex.
  • the vertex node 2702 of the category tree is called a sub root.
  • the end of the tree is composed of leaves, that is, devices, as shown in (c).
  • the device belongs to one of the categories formed by a tree having a plurality of devices as leaves and having a vertex node 2 702 as a subroot.
  • the category tree has a hierarchical structure. This hierarchical structure will be described with reference to FIG.
  • FIG. 29 (a) is a diagram for simplifying and explaining the hierarchical structure, in which the category trees A 0 l to Ann are configured several levels below Kroot, and the lower levels of the category trees A l to An Has a category tree B01-: Bnk, and a category tree C1-Cnq below it.
  • Each category tree has a tree shape composed of multiple stages of nodes and leaves, as shown in Figs. 29 (b) and (c).
  • the configuration of the category tree Bnk has a plurality of nodes from the subroot 2811 as a vertex node to the terminal node 2812.
  • This category tree has an identifier B nk, and the node key management corresponding to the nodes in the category tree B nk is performed independently by the category tree B nk, so that the terminal node 28 1 2 is set as a vertex. Performs management of lower (child) category trees.
  • the category tree B nk is under the management of the upper (parent) category tree Ann having the sub root 2811 as a terminal node.
  • the configuration of the category tree Cn3 has, as shown in (c), a terminal 2851 as a top node, a terminal node 2852 as each device, in this case, a plurality of nodes and leaves up to the leaf. .
  • This category tree has an identifier Cn3, and executes a node key corresponding to a node and a leaf in the category tree Cn3, and leaf key management by the category tree Cn3 independently, so that a leaf (depice) corresponding to the terminal node 2852 can be obtained.
  • the category tree C n 3 is an upper (parent) category tree B having a sub root 285 1 as a terminal node. Under the control of n2.
  • the key management in each category tree includes, for example, key update processing, repoke processing, and the like, which will be described in detail later.
  • the device that is the leaf of the bottom category tree has the node key and leaf key of each node located on the path from the leaf key of the category tree to which the device belongs to the top node of the category to which the device belongs. Is stored.
  • the depice of terminal node 285 2 stores each key from the terminal node (leaf) 285 2 to the sub root node 285 1.
  • the configuration of the category tree will be further described with reference to FIG.
  • the category tree can have a tree structure composed of various stages.
  • the number of stages, ie, depth can be set according to the number of lower (child) category trees corresponding to the terminal nodes managed by the category tree, or the number of devices as leaves. .
  • the root tree is the top row tree with the root key.
  • Category trees A, B, and C are set as a plurality of lower category trees at the terminal node of the root directory, and category D is set as a lower category tree of the category tree C.
  • the category tree C 290 1 holds one or more of its end nodes as a reserved node 295 0, and increases the number of categories managed by itself.
  • the newly configured category C, 2902, with the reserved node 2950 as the top node increases the number of managed terminal nodes 2970, and adds the increased lower category tree to the managed terminal nodes. can do.
  • the reservoir node will be further described with reference to FIG.
  • the category tree A, 3 0 1 1 has lower category trees B, C, D ... to manage, and has one reserved node 3 0 2 1. If the category tree wants to further increase the number of lower category trees to be managed, the self-managed lower category tree A ,, 3102 is set in the reserved node 3021, and the lower category tree A, The lower-level category trees F and G to be managed can be further set at the terminal node of 301.
  • the self-managed sub-categories A ,, 3012 also use at least one of the terminal nodes as a resource. By setting it as the node 3022, it is possible to further set the lower-level category tree A ,, 301, and further increase the management category tree.
  • One or more reserved nodes are also reserved at the terminal nodes of the lower category tree A, 3103.
  • the number of lower category trees managed by a certain category tree can be increased without limit.
  • the reserved category tree may be configured not only in one of the terminal nodes but in plurals.
  • an activation keep (E KB) is configured for each category tree, and key update and revoke processing are performed for each category tree.
  • E KB activation key block
  • FIG. 32 shows the registration processing sequence. This will be described according to the sequence in FIG.
  • Each category tree holds a public key in accordance with the public key cryptosystem, and the new category tree sends its own public key to the upper category tree (P-En) upon a registration request.
  • the upper category tree (P—En) Upon receiving the registration request, the upper category tree (P—En) transfers the received public key of the new (child) category tree (N—E n) to the certificate authority (CA), Receive the public key of the new (child) category tree (N-E n) signed by the CA. These procedures are performed as a procedure for mutual authentication between the upper category tree (P-E n) and the new (child) category tree (N-E n).
  • the upper category tree (P-En) permits the registration of the new (child) category tree (N-En) and the new (child) category tree.
  • the new (child) category tree (N-En) constructs a new configuration of the new (child) category tree (N-En) and receives it at the top of the constructed tree.
  • the activation key block (EKB) in one category tree is called a sub EKB.
  • the upper category tree (P-E n) is in the upper category tree (P-E n) to which the terminal node to be activated is added by adding a new (child) category tree (N-E n).
  • the new (child) category tree (N-E n) generates a sub-EKB composed of the node keys and leaf keys in the new (child) category tree (N-En). E n).
  • the upper category (P—En) that has received the sub EKB from the new (child) category tree (N—E n) has the received sub EKB and the updated sub EKB of the upper category tree (P—E n).
  • KDC Key Distribute Center
  • KDC Key issuing center
  • EKB can generate EKB in various modes based on sub-EKB of all category trees, that is, EKB that can be decrypted only by specific category tree or device.
  • EKB that can be decrypted only by specific category tree or device.
  • An EKB with a categorical tree or device that can be decrypted in this way is provided to, for example, a content provider, and the content provider encrypts the content key based on the EKB and stores it on a network or in a recording medium.
  • the registration process of the sub-EKB of the new category tree to the key issue center (KDC) is not limited to the method of sequentially transferring and executing the sub-EKB via the upper-level category. It may be configured to execute the process of registering directly with the key issuing center (KDC) from the newly registered category tree without going through the upper category category.
  • 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.
  • 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, has a meaning that the upper category tree can bypass the revocation (exclusion) processing of the lower category tree.
  • one node 32 0 1 of the terminal node which is a leaf of the upper category tree is equal to the top node 3 202 of the new additional category tree.
  • One terminal node that is set as a node c, that is, one leaf of the upper node, is set as a subroot of the newly added category. With this setting, the new additional category tree is enabled under the entire structure.
  • Figure 34 shows an example of the updated EKB generated by the upper category tree when a new additional category tree is set.
  • Fig. 34 shows the configuration shown in (a), that is, there are already valid end nodes (node 000) 3301 and end nodes (no de 0 1) 3 302, and here the new category tree is This is an example of the sub-EKB generated by the upper category tree when a per-tree additional end node (no del OO) 330 is added.
  • the sub-EKB has a configuration as shown in (b) of FIG.
  • the upper node key is encrypted by the effective end node key, the upper node key is encrypted by the upper node key, and so on.
  • a sub EKB is generated.
  • each category tree encrypts the valid terminal node or the upper node key encrypted with the leaf key, the upper node key is further encrypted with the upper node key, and the sub root It has an EKB composed of encrypted data up to and manages it.
  • FIG. 35 is a diagram for explaining a device repoke process based on a category tree at the bottom of the category tree constituting the tree, that is, a category tree managing individual devices.
  • Figure 35 (a) shows the key delivery tree structure by category tree management.
  • the root node is set at the top of the category, and the category trees A01 to Ann are several levels below it, and B01 to B011 to the lower level, and the category tree of Bnk, and C is further below that. 1 ⁇ cn category is composed.
  • the terminal node (leaf) is an individual device, for example, a recording / reproducing device, a reproducing-only device, or the like.
  • Figure 35 (b) shows the tree structure of category tree Cn, 340, which is one of the category trees at the bottom.
  • the category tree C n, 3 4 3 0 has a vertex node 3 4 3 1, and has a configuration in which a leaf as a terminal node has a plurality of devices.
  • the category tree C n, 3430 is a node key in the independently updated category tree C n.
  • This activation key block is a key block composed of an encryption key that cannot be decrypted by the revoke device 3432 but can be decrypted only by the depice configuring another leaf.
  • the administrator of the category tree C n generates this as an updated sub-EKB.
  • the updated block is used as the update sub-EKB.
  • the activation key block (sub EKB) updated by the category tree C n, 3430 by the revocation processing is transmitted to the upper category tree.
  • the upper category tree is a category tree Bnk, 3340, and is a category tree having the vertex node 3431 of the category tree Cn, 3340 as a terminal node.
  • the category tree B nk, 3420 Upon receiving the activation key block (sub-EKB) from the lower-level category tree C n, 3430, the category tree B nk, 3420 converts the vertex node 343 1 of the category tree C nk, 3430 included in the key block. By setting the terminal node 343 1 of the corresponding category tree B nk, 3 420 to the key updated in the lower category tree C n, 343 0, the sub-EKB of the own category tree B nk, 342 0 is set. Execute the update process.
  • Figure 35 (c) shows the configuration of the category tree Bnk, 3420. In the category tree Bnk, 3420, the node key to be updated is the node key on the path from the subroot 3421 in FIG.
  • the activation key block (sub EKB) updated by the category tree B nk, 3420 is transmitted to the upper category tree.
  • the higher-order category 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.
  • the category tree Ann, 341 0 is a lower category tree Bnk, 3420
  • the end node 342 1 of the category tree Ann, 3410 corresponding to the vertex node 342 1 of the category tree B nk, 342 0 included in the key block is added to the lower level.
  • the sub-EKB of the own category tree Ann, 3410 is updated by setting the key updated in the category tree Bnk, 3420.
  • Figure 35 (d) shows the configuration of the category tree Ann, 3410.
  • the node key to be updated constitutes a path connected to the node 342 1 of the category tree that has transmitted the update sub EKB from the sub 3411 in FIG. 35 (d).
  • the node key of each of these nodes is updated to generate a new updated sub EKB of the category tree An n, 3410.
  • FIG. 36 shows a sequence diagram of the device revocation processing.
  • the device management category tree (D-En) at the bottom of the tree structure performs key update necessary to eliminate revoked leaves in the device management category tree (D-En).
  • the update sub-EKB (D) is sent to the upper category tree.
  • the upper (parent) category tree (P1—En) that receives the update sub-EKB (D) updates the update sub-EKB (D), updates the terminal node key corresponding to the vertex node, and updates the key from the terminal node.
  • An updated sub EKB (P 1) is generated by updating the node key on the path leading to the sub route. These processes are sequentially executed in the upper category tree, and all sub EKBs that are finally updated are stored and managed in the key issuing center (KDC).
  • Figure 37 shows an example of an enabling key block (EKB) generated by updating the upper category tree by revoking the device.
  • FIG. 37 is a diagram illustrating an example of an EKB generated in an upper category tree that has received an updated sub EKB from a lower category tree including a revoke device in the configuration illustrated in (a).
  • the top node of the lower category tree including the revoke device corresponds to the terminal node (node del OO) 3601 of the upper category tree.
  • the upper category tree updates a node key existing in the path from the subroot of the upper category tree to the terminal node (node o O) 3601 to generate a new updated sub EKB.
  • the update sub-EKB is as shown in Fig. 37 (b). Updated keys are underlined and marked with []. The node key on the path from the terminal node to the sub root updated in this way is updated to the updated sub EKB in the category tree.
  • Figure 38 (a) shows the key distribution tree structure by category tree management.
  • the root node is set at the top of the tree, and the category trees A01 to Ann are several levels below, B01 to B01 to the lower level, and the category tree of Bnk, and C1 is further lower.
  • ⁇ ⁇ Cn category is composed.
  • the terminal node (leaf) is an individual device, for example, a recording / reproducing device, a reproducing-only device, or the like.
  • the category tree Cn, 3730 at the bottom has a vertex node 3431 as shown in FIG. 38 (b), and has a plurality of devices at the leaf which is the terminal node.
  • the category tree Bnk, 3720 is a category tree having the vertex node 3731 of the category tree C n, 3730 as a terminal node.
  • the category tree B nk, 3720 is a terminal node of the category tree B nk, 3 720 corresponding to the vertex node 37 3 1 of the category tree C nk, 3 730 when executing the revoking of the lower category tree C ⁇ , 3 730. 1 is updated, and the node keys on the path from the revoke category tree 3730 to the subroot of the category tree B nk, 372 0 are updated to generate an activation keep key and generate an update sub-E. Generate KB.
  • the node key to be updated is the node key on the path from the sub root 372 1 in FIG. 38 (c) to the terminal node 373 1 constituting the top node of the revoked category tree. That is, the node keys of the nodes 372 1, 3724, 3725, and 3731 are to be updated.
  • the node key of each of these nodes is updated, and a new updated sub EKB of category 720B, 3720 is generated.
  • the category tree B nk, 3720 is the end of the category tree B nk, 3720 corresponding to the vertex node 3731 of the category tree Cnk, 3730 when revoking the lower category tree C n, 3 730.
  • the node 373 1 is not updated, and the node key is updated except for the terminal node 373 1 on the path from the revoked category tree 3730 to the category tree Bnk, 3720, and the activation keep is performed.
  • a spoke may be generated to generate an update sub-EKB.
  • the activation key block (sub EKB) updated by the category tree B nk, 3720 is transmitted to the upper category tree.
  • the upper-level category is a category tree An n, 37 10, and a category tree having a vertex node 3721 of the category tree: B nk, 3702 as a terminal node.
  • the category tree Ann, 3710 When the category tree Ann, 3710 receives the activation key block (sub-EKB) from the lower category tree Bnk, 3720, the category tree Ann, 3710 enters the vertex node 3721 of the category tree Bnk, 3720 included in the key block. By setting the terminal node 3 72 1 of the corresponding category tree Ann, 3 7 10 to the key updated in the lower category tree B nk, 3 720, the sub EKB of its own category tree Ann, 3 7 10 Execute the update process.
  • Figure 38 (d) shows the category tree An ⁇ , 37 shows a tree structure of 10.
  • the node key to be updated constitutes a path connected to the node 3721 of the category tree that has transmitted the updated sub-EKB from the subroute 3711 in Fig. 38 (d). This is a node key for each node 37 11, 37 14, 37 15. The node key of each of these nodes is updated to generate a new updated sub-EKB of the category Ann, 3710.
  • the category tree management category tree (E—E n) that is trying to revoke the category tree is necessary to eliminate the revoked end nodes in the category tree management category tree (E—E n).
  • Key update and a new sub EKB (E) of the category tree management category tree (E-En) is generated.
  • the update sub EKB (E) is sent to the upper category category.
  • the upper (parent) category tree (P1 En) that receives the update sub-EKB (E) updates the end node key corresponding to the update vertex node of the update sub-EKB (E), and subroots from that end node.
  • An updated sub EKB (P 1) is generated by updating the node key on the path leading to.
  • the key issuing center (KDC) generates various EKBs based on the updated sub-EKBs of all category trees.
  • the updated EKB is an encryption keep-up that cannot be decrypted by devices belonging to the revoked category.
  • FIG. 3 is a diagram illustrating a correspondence of a goal.
  • the terminal node 390 1 of the upper category tree is updated by revocation of the category tree, and a new sub-EKB is updated by updating the node key existing in the path from the terminal node 390 1 to the sub root in the tree of the upper category tree. Is generated.
  • the node key of the vertex node 3902 of the revoked lower-level category does not match the node key of the terminal node 3901 of the upper-level category directory.
  • the EKB generated by the key publishing center (KDC) after revoking the category tree will be generated based on the key of the terminal node 391 updated in the upper category tree.
  • KDC key publishing center
  • the capability means what kind of content the device has, such as being able to decode specific compressed audio data, permitting a specific audio reproduction method, or being able to process a specific image processing program.
  • it is a device capable of processing a program or the like, that is, definition information of the data processing capability of the device.
  • Figure 41 shows an example of a category tree configuration with defined key capabilities.
  • Key distribution ⁇ A root node is located at the top of the tree structure, a plurality of category trees are connected to the lower layer, and each node has a tree structure with two branches.
  • the category tree 4001 is defined as a category tree having a capacity that allows any one of the audio reproduction methods A, B, and C. Specifically, for example, when music data compressed by a certain audio compression program A, B, or C is distributed, devices belonging to a category tree configured under the category tree 401 are compressed data. 1. Data expansion is possible.
  • category tree 4002 is audio playback method B or C
  • category tree 4003 is audio playback method A or B
  • category tree 4004 is audio playback method B
  • category tree 4005 Is defined as a category tree that has the capability to process audio reproduction method C.
  • the category tree 4 0 2 1 is defined as a category that allows the image reproduction methods p, q, and r
  • the category tree 4 0 2 2 is an image reproduction method of the methods p and q
  • the category tree 4 0 2 3 Is defined as a category that has the capability to reproduce images of the method p.
  • Such key property information of each category is managed in the key issuing center (KDC). For example, if a content provider wants to distribute music data compressed with a specific compression program to various devices, the key distribution center (KDC) can decrypt only the device that can reproduce the specific compression program. A chemical key block (EKB) can be generated based on the capability information of each category. The content provider that provides the content distributes the content encrypted by the activation keep-up (EKB) generated based on the key property information, and provides the compressed audio data encrypted with the content key to each device. I do. With this configuration, it is possible to reliably provide a specific processing program only to a device capable of processing data.
  • EKB activation keep-up
  • FIG. 41 shows the configuration in which the capability information is defined for all the categories, it is not always necessary to define the capability information in all the category trees as shown in FIG.
  • Capability is defined only for the lowest category to which the device belongs, and the capabilities of the devices belonging to the lowest category are managed by the key issuing center (KDC), enabling the content provider to perform the processing desired by the content provider.
  • the configuration may be such that an enabling key block (EKB) that can be decrypted only by a specific device is generated based on the capacity information defined in the lowest category tree.
  • KDC Key Publishing Center
  • Figure 43 shows an example of the structure of the cable management table managed by the key issuing center (KDC).
  • the key property management table has a data structure as shown in Fig. 43 (a).
  • a category ID as an identifier for identifying each category tree
  • a capability list indicating the capabilities defined in the category tree
  • the capability list as shown in FIG. [1] if the method (A) can be processed, [0] if it cannot be processed, [1] if the audio data playback processing method (B) can be processed, [0] if it cannot be processed.
  • It is configured by setting [1] or [0] bit by bit for the availability of various types of data processing.
  • the method of setting the capacity information is not limited to such a format, and any other configuration may be used as long as the capability of the management device of the category directory can be identified.
  • the cable property management table further stores the sub-EKB of each category tree or, if the sub-EKB is stored in another database, the identification information of the sub-EKB. Stores the sub-root node identification data of the category tree.
  • the key issuance key (KD C) is based on the key property management table, for example, an activation keep key that can be decrypted only by a device that can play specific content. Generate an EKB. With reference to FIG. 44, a description will be given of a process of generating an activation keep-up based on capability information.
  • the key issuing center selects a category tree having the specified capability from the capability management table. Specifically, for example, if the content provider wants to distribute reproducible data based on the audio data reproduction processing method A, the item of the audio data reproduction processing (method A) is selected from the capability list in Fig. 43 (a). Select the category set in [1].
  • step S4302 a list of selected category trees ID constituted by the selected categories is generated.
  • step S4303 a path (key distribution tree configuration path) required for the tree constituted by the selected category tree ID is selected.
  • step S4304 it is determined whether or not all the path selections included in the selection category list ID have been selected, and a path is generated in step S4303 until completion. This means a process of sequentially selecting each path when a plurality of categories are selected. When the selection of all the paths included in the list of the selected category tree ID is completed, the process proceeds to step S4305, and the key distribution tree structure constituted only by the selected path and the selected category tree is constructed.
  • step S4306 an update process of the node key of the tree structure generated in step S4305 is performed to generate an updated node key.
  • the sub EKB of the selected category tree constituting the tree is extracted from the key management table, and can be decrypted only in the device of the selected category tree based on the sub EKB and the updated node key generated in step S4306.
  • the activation key block (EKB) generated in this way is used only by devices with a specific capacity, that is, the activation key block (EKB) that can be decrypted.
  • This activation key block (EKB) encrypts, for example, the content key, and uses the content key to encrypt the compressed content based on a specific program and provides it to the device. Only on certain processable devices Content is used.
  • the key issuing center KDC
  • KDC key issuing center
  • EKB activation key block
  • 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 during the tree construction executes a new registration request for the upper (parent) category tree (P-E n).
  • Each category tree holds a public key in accordance with the public key cryptosystem, and the new category tree sends its own public key to the upper category tree (P-En) at the time of a registration request.
  • the upper category tree (P—E n) that receives the registration request transfers the received public key of the new (child) category ⁇ ⁇ tree (N—E n) to the Certificate Authority (CA).
  • Receive the public key of the new (child) category (N—E n) with the signature of These procedures are performed as a procedure for mutual authentication between the upper category tree (P-En) and the new (child) category tree (N-En).
  • the upper category tree (P-En) permits the registration of the new (child) category tree (N-En) and the new (child) category tree.
  • Send the (N—E n) node key to the new (child) power category (N—E n).
  • This node key is one of the terminal nodes of the upper category category (P-En), and corresponds to the top node of the new (child) category tree (N-E n), that is, the subroot key.
  • the new (child) category tree (N-E n) constructs a new (child) category tree (N-E n) tree structure and receives it at the top of the constructed tree. Set the subroot key of the vertex node, set the key of each node and leaf, and generate the activation key block (sub EKB) in the category tree You.
  • the upper-level category tree (P-E n) also has a new (child) category tree (N-E n), and the sub-E in the upper-level category tree (P-E n) to which the terminal node to be activated is added. Generate KB.
  • the new (child) category tree (N—E n) generates a sub-EKB composed of the node keys and leaf keys in the new (child) category tree (N—En). ), And informs the upper category tree of the capability information on the devices managed in its own category directory.
  • the upper category tree (P—En) that has received the sub-EKB and the capability information from the new (child) category tree (N—E n) is the same as the received sub-EKB and the capability information, and the upper category tree (P—En). En) and the updated sub-EKB to the Key Distribute Center (KDC).
  • KDC Key Distribute Center
  • the key issuance center registers the received sub-EKB and category information of the category tree in the capacity management table described in Fig. 43, and updates the capacity management table.
  • the key issuance center (KDC) will be able to generate EKBs in various modes based on the updated keyability management table, that is, EKBs that can only be issued later to a category or device that has a specific capacity. Become.
  • the key issuance center receives an EKB issuance request from an EKB request requesting use and issuance of EKB such as a content provider.
  • the EKB issuance request includes an EKB type identification number indicating the EKB type defined in the EKB type definition list, and the key issuance center (KDC) issues one or more category entries according to the EKB type identification number.
  • the key issuer (KDC) will provide the category administrator based on the top node identifier of each category set according to the EKB type identification number in the EKB type definition list.
  • a requester of EKB such as a content provider (CP)
  • CP content provider
  • KDC key issuing center
  • the key issuance center (KD C) issues a sub-EKB issuance request to the management entity of the selected category directory, and the management entity of each selected category directory is: Generates a sub-EKB that can be processed only by a legitimate device that has not been re-poked by the management entity and sends it to the key issuing center (KDC).
  • the key issuance center (KDC) combines one or more sub-EKBs, generates an EKB that can be processed only in the selected category tree requested by the EKB issuance requester, and provides it to the EKB issuance requester.
  • the EKB issuance requestor receives the EKB from the Key Issuing Center (KDC) and distributes an encryption key or encrypted content that can be decrypted only with a key that can be obtained by processing the EKB.
  • KD C Key Distribution Center
  • EKB activation block
  • Top Level 'Category' Entity An entity that manages a category tree. For example, a format holder for recording depth. It manages the category tree, generates a sub-EKB that can be processed (decrypted) by devices in the managed category tree, and submits it to Key Issuer Yuichi (KDC). EKB requester (EKB requester)
  • an entity that provides a variety of content such as images, audio, and programs, to user devices, such as a content provider (CP) that performs Electronic Content Distribution (ECD) services, or a recording medium.
  • CP content provider
  • ECD Electronic Content Distribution
  • This is a format holder that provides content and media as settings using a key that can be obtained by EKB processing as an encryption key for provided content.
  • a request is issued to the key issuing center (KDC) to issue an EKB to be used at this time.
  • KDC key issuing center
  • a content provider encrypts and distributes its content using the EKB root key (Root Key) generated by a key distribution center (KDC).
  • KDC key distribution center
  • the format holder of the recording medium writes and distributes the EKB at the time of manufacturing the recording medium so that the recorded content is encrypted using the root key (Root Key) of the EKB.
  • a category is a set of devices having the same properties as described above. Specifically, a category is a device manufactured by the same manufacturer or a device that can handle the same encoding format.
  • A, B, C, and D indicate categories, respectively.
  • the top-level route tree has, for example, an eight-stage configuration (the number of node stages), and the top node of the category tree is set at the bottom of the route tree.
  • a plurality of power categories can be in a high-order / low-order relationship.
  • a category tree C corresponds to a high-order category D.
  • the category tree that is directly linked to the top-level root tree is called a top-level category tree, and the entity that manages the top-level category tree is called a top-level 'category' entity (TLCE).
  • A, B, and C are top-level categories, and the entity that manages them is the top-level category.
  • the top-level 'category' entity (TL CE) is basically responsible for managing everything below its tree.
  • the TLCE that manages the tree C in FIG. 46 also manages the tree D as well as the tree C. If there is a lower category tree below D, the lower category tree is also managed. However, it is also possible to delegate its responsibilities and rights by placing a power category entity (Sub Category Entity) that manages the lower category tree D, for example.
  • Each device such as a recording / reproducing device that uses content, is assigned to a leaf of a tree by a top-level category 'entity (TLCE), and several nodes between paths from that leaf to the root are assigned. Own the key.
  • a set of node keys of one device is called a device node key (DNK: Device Node Key).
  • the top-level category entity (TLCE) determines how many keys each device has (how many keys are included in the DNK).
  • Figure 47 shows the key issuing center (KD C), top-level .category entity (TL CE), EKB, and requester.
  • the key issuer Sen-ichi (KDC) 4511 is positioned as the management entity 4510 of the EKB distribution system using the perimeter configuration.
  • the management entity 4510 further has a Certificate Authority (CA) 4512 that performs the signing process on the EKB.
  • CA Certificate Authority
  • the key issuance center (KDC) 451111 manages the key of the sub directory such as the top level category tree, manages the EKB type definition list described later, and generates the EKB.
  • the certification authority (CA) 45 1 12 signs the EKB generated by the key issuing center (KD C) and issues a public key corresponding to the signed private key as a key for signature verification.
  • the EKB Request Request 4520 issues an EKB issuance request to the Key Issue Center (KDC) 45 1 1.
  • the EKB requester is a content provider (CP) for content storage media that provides media such as CDs and DVDs that store content, and a content provider that distributes electronic content.
  • Storage system licensors that provide licenses for storage system formats such as binders (CPs) and flash memory.
  • EKB requests 4520 use the media, content, and licenses provided by EKB to set the required key as a key obtained by EKB processing.
  • An 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 provided the EKB received as a result of the issuance request to the Key Publishing Center (KDC) 4511 to the media manufacturer 4540 and the device manufacturer 45550, and stored the EKB. It is possible to supply media or devices to users.
  • KDC Key Publishing Center
  • These EKBs are generated, for example, as EKBs that can be processed in one or more category trees.
  • EKB EKB that can be processed in common in multiple, for example, two or more category trees, and EKB that can be processed in only one category tree.
  • EKB type definition lists C
  • the EKB type definition list is managed by the Key Publishing Center (KD C).
  • KDC Key Issue Center
  • the EKB type definition list will be described in detail later.
  • the EKB request 4250 can request a request for an EKB type definition list from the Key Issue Center (KDC) 4511 to obtain the list. If there is a change in the list data, the key It is notified from the issuing center (KDC) 45 11 1 to the EKB requester 4520.
  • KDC Key Issue Center
  • the top-level 'category' entity (TL CE) 4530 is the management entity of the category tree linked to the root tree, and manages the key of the subtree, the management device ID, and the EKB processing stored in each device. Manages the list of correspondence with the device 'node' key (DNK), which is a node key set.
  • the device manufacturer 4550 which manufactures devices corresponding to the devices under management, is provided with a device node key (DNK) for storing the devices. And execute the provision process.
  • the Key Issuing Center (KD C) 45 1 1 sends the EKB according to the issuance request. Generate. If the generated EKB is, for example, an EKB that can be processed in two top-level .category categories, a request to issue a sub-EKB to the two top-level 'power category' entities (TL CE) 4530 The top-level category entity (TLCE) 4530 that has transmitted the sub-EKB issuance request and generates a sub-EKB that can be obtained by a legitimate device in each category list and obtains a key issuance center (KD C ) 45 1 Send to 1.
  • the key issuer (KDC) 45 11 1 generates an EKB based on one or more sub-EKBs received from the TLCE. The EKB generation processing based on the sub-EKB will be further described later.
  • Top-level category entity (TL CE) 4530 can request EKB type definition list request from Key Publishing Center (KDC) 45 11 1 and obtain the same list as EKB request 4520 It is.
  • KDC Key Publishing Center
  • the top-level 'category' entity (TL CE) 4530 can also request the key publishing center (KDC) 4511 to delete the type defined for its own entry in the EKB type definition list. For example, a request to delete an EKB type defined as an EKB shared with another category from the list.
  • KDC Key Issue Center
  • Device Manufacturers 4550 is divided into two types of device manufacturers. One is a DNKE device manufacturer 45 5 1 that manufactures a device that stores both a device node key (DNK) and EKB data in the device to be manufactured, and the other is a device node key (DNK) only in the device. Is a DNK device manufacturer 4552 that manufactures a device storing the DNK device manufacturer 4552 .
  • KD C Key Issuer Senichi
  • EKB Requester EKB Requester
  • TCE Top Level 'Category' entity
  • KDC key issuance center
  • EKB requester is an EKB request information processing device
  • TCE category entity
  • the information processing device that constitutes each entity has a cryptographic processing unit that controls mutual authentication with other entities and overall cryptographic processing during data communication.
  • the control unit in the encryption processing unit is a control unit that executes control related to overall encryption processing such as authentication processing and encryption / decryption processing.
  • the internal memory stores key data and identification data required for various processes such as mutual authentication, encryption, and decryption.
  • the identification data is used, for example, in a mutual authentication process with another entity.
  • the encryption / decryption unit performs processing such as authentication processing, encryption processing, decryption processing, data verification, and random number generation at the time of data transfer using key data and the like stored in the internal memory.
  • an information processing device as an EKB request a configuration in which the key generation process is not executed in its own device is also possible. In this case, components necessary for key generation, for example, a random number generator can be omitted.
  • an information processing device as an EKB request requesting a key issuing center to generate an EKB including a root key generated by generating a root key to be included in the EKB by itself is used to generate a root key.
  • Means are required, but do not generate the root key to be included in the EKB itself, request the key issuing center to generate the root key, and generate the EKB including the root key generated at the key issuing center (KDC)
  • the information processing device as the EKB requester that requests the issuing center can omit components such as a random number generator that are involved in key generation processing.
  • the encryption processing unit Since the internal memory of the cryptographic processing unit holds important information such as cryptographic keys, it must have a structure that is difficult to read illegally from outside. Therefore, the encryption processing unit is configured as a tamper-resistant memory having a structure that is difficult to access from the outside, for example, a semiconductor chip.
  • Each entity has a central processing unit (CPU: Central Processing Unit) RAM (Random Access Memory) ⁇ R 0 M (Read Only Memory) ⁇ Equipped with input unit, display unit, data base I / F, and database.
  • CPU Central Processing Unit
  • RAM Random Access Memory
  • RAM random access memory
  • ROM read only memory
  • the RAM is used as a main storage memory for various processing in the CPU, and is used as a work area for processing by the CPU.
  • the ROM stores a startup program for the CPU and the like.
  • the database or other storage means of the information processing device that constitutes each entity data managed by each entity, such as the management data related to the issued EKB in the case of a key issuing center (KDC), and the EKB A type definition list is stored, and the management data of the devices belonging to the category tree, such as the correspondence between the management device and the device node key (DNK), is stored in the database of the top-level category entity (TLCE).
  • the database of the EKB request database stores management data that correlates the relationship between the provided content and the EKB used for the content, management data on the device to which the content is provided, and the like.
  • the EKB type definition list is stored in the information processing device that configures the EKB requester, the top-level 'category ⁇ entity (TLC E), and can be referred to.
  • TLC E top-level 'category ⁇ entity
  • TLCE key issue center
  • KDC key issue center
  • the device uses the device node key (DNK) for EKB processing (decryption).
  • the device-node.key (DNK) of one device will be described with reference to FIG.
  • the tree shown in FIG. 49 shows one category tree, and the bottom row is a leaf associated with a device, and corresponds to, for example, a management tree of a top-level 'category' entity (TLCE). Furthermore, at the top is a row of stories (ex. 8 levels).
  • the device has a node key on the path from the device to the upper stage as shown in FIG. Keep these keysets as device 'node' keys (DNK) And decrypt the EKB using the device 'node' key (DNK).
  • one device is assigned so that it does not overlap one leaf.
  • software such as PC software is associated with a leaf
  • all software packages of one version may be assigned to one leaf.
  • TL CE determines how devices are assigned to leaves and which node keys are assigned.
  • the top-level category entity may be the provider (manufacturer) of the device itself, and stores the device node key (DNK) for the manufactured device in advance and provides it to the user ( Sales).
  • DNK device node key
  • a set of node keys for a specific category tree can be stored in memory as a device.node.key (DNK) in advance for devices such as recording / playback devices and provided (sold) to users. It is.
  • the distribution of EKB by category is performed when an EKB common to multiple categories, that is, an EKB that can be processed by devices belonging to different category trees is generated and issued. May have some problems.
  • a certain rewritable medium For example, there are two different licensees (license recipients) of portable flash memory format: Company A and Company B.
  • Media portable flash memory
  • the devices belonging to the two categories of A category and B category Generate and issue a processable (decryptable) EKB at the key issuing center (KDC).
  • the category authority that manages each category has permission to issue an EKB that can be used in common in multiple categories.
  • EKB electronic book
  • there are various types of EKB such as an EKB that can be processed in a plurality of, for example, two or more categories, and an EKB that can be processed only in a single category. Is generated and used.
  • the EKB type definition list lists these various types of EKB.
  • Figure 50 shows an example of an EKB type definition list.
  • the EKB type definition list is recorded on a recording medium and managed by Key Issuer Senichi (KDC). In addition, they can be provided or browsed as needed for EKB requests and TL CE.
  • KDC Key Issuer Senichi
  • the EKB type definition list has fields of “EKB type identification number—”, “node”, and “description”, and “EKB type identification number” is an EKB type identification number. This is a number that identifies the various types of EKBs listed in the definition list. If the identification numbers are different, the category list that can process the EKBs One or a combination thereof has a different configuration.
  • the “node” field is a field for recording a top node ID of a category tree to which EKB can be applied. For example, as for EKB of EKB evening identification number: 1, the top node ID of category (MS) of Memory Stick (MS) is recorded. In addition, in the EKB of the EKB type identification number: 3, a top node ID of a category tree of MS (Memory Stick) and a top node ID of a category of PHS are recorded.
  • the “description” field is a field for recording the description of the EKB in various modes listed in the EKB type definition list.
  • the EKB with the EKB type identification number: 1 is stored in the MS (Memory Stick).
  • the EKB of the EKB type identification number: 3 indicates that it is an EKB that can be used in common for devices in the MS (Memory Stick) and PHS category.
  • the EKB type definition list shown in Fig. 50 is managed by the key issuing center (KDC).
  • KDC key issuing center
  • an entity that intends to deliver encrypted data such as an encryption key or an encryption content encrypted with a key that can be obtained by processing the EKB, for example, the content provider, uses the EKB type definition shown in Figure 50. Referring to the list, select the EKB type that can be processed by the category tree including the device for which content is to be provided, specify the EKB type identification number, and send it to the key issue center Yuichi (KDC). Request EKB generation processing.
  • TLCE top level 'category' entity
  • the content provider can specify the EKB type identification number that indicates the registration type and request the key issuing center (KDC) to perform EKB generation processing.
  • KDC key issuing center
  • the following processing is required to register a new EKB type in the EKB type definition list and define the EKB type identification number corresponding to that EKB type.
  • KD C The key issuance center
  • TL CEs top-level 'category' entities
  • KD C The key issuance center (KD C) sends an EKB type definition list change notification to all TLC E and E K to notify that the EKB type definition list has been changed.
  • the EKB type definition list will be sent to all TLC E and E KB requesters, and will be published on all TLC E and E KB requests such as by placing them on a Web site. Therefore, T L CE and E KB requesters always have the latest E
  • Figure 51 shows the process flow that describes the process performed by Key Issuer Yuichi (KDC) when registering a new EKB type in the EKB type definition list.
  • the key issue center (KDC) receives an EKB type registration request from TLCE that makes a new EKB type registration request (S101).
  • the EKB type registration request from TLCE includes the number of categories that the registration request EKB can commonly use.
  • Key distribution center (KD C) matches the number of categories in the request It is determined whether or not a similar EKB type registration request has been received from TL CEs corresponding to the number of categories (S102), and the TLCEs corresponding to the number of categories corresponding to the number of categories in the request are determined.
  • a new EKB type according to the request is registered in the EKB type definition list, and list update processing and list update notification processing (S103) are performed.
  • the update notification processing is performed for the TLCE and the EKB requester.
  • the key issuing center selects one or more categories that can be processed for the EKB type to be registered in the process of newly registering the EKB type identifier in the EKB type definition list. Registration is performed subject to the approval of all categories and entities that manage the category tree.
  • the top-level category entity (TLCE) sends a request to the distribution center to invalidate the EKB type of which the category is an element. KD C). Also, the top-level 'category' entity (TL CE) can issue a request to the KD C to deactivate the currently registered EKB type, for example, to shut down a service.
  • the key issuing center receives the EKB type invalidation request from the TL CE requesting the EKB type invalidation (S201).
  • the key issuance center sends the request to the TL CE, which manages the categories that are the elements of the EKB type revoked by the request.
  • the EKB type definition number corresponding to the type specified in the invalidation request in the type definition list is invalidated to update the EKB type definition list, and the list is updated (S202).
  • the update notification process is performed for TL CE and EKB requesters.
  • the key issuing center (KD C) was selected as a processable category of the EKB type to be invalidated in the invalidation processing of the EKB type identifier registered in the EKB type definition list 1
  • the above category trees are managed. Invalidation processing is performed on the condition that at least one category / entity is invalidated. In this case, approval of other categories and entities is not required.
  • mutual authentication and encryption of transmission data are performed as necessary in communication between the key issuing center (KDC) and the TLCE and EKB requesters. Further, a configuration may be employed in which other message encryption processing, digital signature generation, and verification processing are performed.
  • the procedure of holding the public key between the entities is performed in advance.
  • the process of changing the state of the tree such as device revocation (removal of device) or updating the device node key (DNK) that replaces the DNK stored by a device with a new one, is performed. If the TL CE that manages the category tree does so, it must inform the EKB requester or the associated TL CE that is using the EKB for those devices that this has happened.
  • the old EKB would have This is because EKB processing (decryption) is also possible, and there is a possibility that illegal use of content may be continued. Also, when a Vise Node Key (DNK) is updated, the old DNK normally replaced is discarded, and the device has a new DNK. Must be used by content providers For example, a device with the new DNK will not be able to process (decrypt) the EKB and will not be able to access the content.
  • DNK Vise Node Key
  • DNK of at least one device changes as a result of updating the device node key (DNK)
  • the TLCE must send a Tree Change Notification to the Key Issue Center (KDC).
  • KDC Key Issue Center
  • the Tree Change Notification contains information on the EKB type identification number registered in the EKB type definition list that needs to be changed and the category registered in correspondence with the EKB type identification number. And information on what happened in the repok- ing and DNK updates.
  • the key issuance center receives the tree change notification from the TLCE (S301). Upon receiving the notification of the change of the tree from the TL CE, the key issuing center (KDC) extracts the EKB type identification number having the category as an element from the EKB type definition list, and assigns the EKB type identification number to which EKB type identification number. Performs EKB type definition list change notification to all TL CE and EKB requesters with information on what type of change (ex. Relocation or DNK update (replacement) has occurred). .
  • EKB requests such as top-level 'category' entities (TL CE) and sub-categories' entities (SCE) other than TL CE's, or content providers ES may request the Key Issue Center (KDC) to send the EKB type definition list in order to know the latest version of the EKB type definition list.
  • KDC Key Issue Center
  • the key issuing center (KDC) sends back the latest version of the EKB type definition list to the requester.
  • the key issuance center (KDC) receives an EKB type definition list request from either the TL CE, the subcategory 'entity, or the EKB requester (S401).
  • the key distribution center (KDC) extracts the latest EKB type definition list and sends the latest EKB type definition list to the entity that performed the request ( S 402).
  • mutual authentication and encryption of transmission data are performed as necessary in communication between the key issuing center (KDC) and TLC E, subcategory. Entity, and EKB requester.
  • a configuration may be adopted in which other message encryption processing, digital signature generation, and verification processing are performed.
  • a content provider that provides content storage media such as CDs and DVDs.
  • ECD Electronic Content Distribution
  • the format holder for the [c] recording system described above includes:
  • an EKB requester such as a content provider, generates a content key to be used in response to the content, device, and media provided by itself.
  • EKB requester such as a content provider
  • CP Content providers that provide content storage media such as CDs and DVDs.
  • ECD Electronic Content Distribution
  • the generated content key is used as a key to protect (encrypt) content on media and in electronic information distribution (ECD) services.
  • [c1] A format holder that gives an EKB to a recording medium manufacturer in a format where the EKB is stored on the recording medium during manufacturing.
  • the content key is used as a key for protecting (encrypting) the content recorded on the recording medium.
  • [c2] A format holder that provides the recording device manufacturer with the acquired EKB in a format that stores the EKB in the recording device during manufacturing. If, the content key is used as a key to protect (encrypt) the content recorded using the recording device.
  • the mechanism such as an encryption algorithm, for protecting content using the content key can be arbitrarily determined for each format.
  • the EKB requester generates a root key that can be obtained by decrypting the EKB.
  • the EKB requester may not generate the root key itself, but may request the key issuer Yuichi Sen (KDC) to generate it.
  • the root key is used to protect (encrypt) the content.
  • a mechanism such as a cryptographic algorithm for protecting the content key using the root key can be arbitrarily determined for each format.
  • the EKB requester sends an EKB issuance request to the key issuance 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 device the root key is to be sent by EKB.
  • the EKB requester can provide services such as providing content based on the EKB type definition list stored in its own storage device or the EKB type definition list obtained from a browsable site on the network. Select the EKB group that includes the category containing the device, and include the EKB type identification number indicating the selected EKB type in the EKB issuance request and send it to the key issuance center (KDC).
  • the key issuing center Based on the EKB request from the EKB requester, if the root key is included in the EKB request, the key issuing center (KDC) generates an EKB that includes the root key. If the root key is not included in the issuance 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 sends it to the EKB requester.
  • KDC key issuing center
  • 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 multiple category trees.
  • the key issuance center (KDC) specifies the category that is a component of the EKB type identification number, that is, the EKB type definition list. Extract the node recorded in the node field of the entered EKB type identification number ( The top node ID of the category tree is recorded in the node field. This is the node ID corresponding to the management entity of the category tree. Based on this node ID, a sub-EKB issuance request is issued to the top-level 'category' entity (TLCE), which is the management entity of the category.
  • TCE top-level 'category' entity
  • the sub-EKB issuance request includes the root key and information indicating each category.
  • the TLCE that receives the sub-EKB issuance request from the key issuance center (KDC) has a configuration that can ultimately obtain the root key from each (unrevoked) device in one or more specified categories. Generate a sub EKB and send it to the key distribution center (KD C).
  • the sub-EKB generated by the top-level 'category' entity has no version number and no information for verification (Version Check Value), but has the same structure as a normal EKB (see Fig. 6).
  • the algorithm for encrypting the upper level node key using the leaf key in the sub EKB, the key length, and the mode are determined by each TLCE (format holder type) that generates the sub EKB. ) Can be determined arbitrarily. This allows you to use your own security scheme separately from other formats.
  • the cryptographic algorithm may be determined to be FIPS46-2 Triple DES (Triple-DES), and the TLCE that does not exist may adopt the Triple DES algorithm. .
  • each (TLCCE) can process an EKB combined with a sub-EKB created by another TLCE, using a device under the control of another TLCE.
  • the key is decided to be represented by a predetermined length, for example, 16 bytes (16 bytes).
  • a predetermined length for example, 16 bytes (16 bytes).
  • each device of a different category tree can use its own EKB tag, and It is possible to judge what key key is needed.
  • each of the key data included in the EKB is 16 bytes, it becomes possible to sequentially extract and process the key data that can be processed by the own device, and finally, the root key It becomes possible to acquire.
  • the composite EKB generated based on the sub-EKB has multiple keys Each evening has a configuration stored in a fixed length data field. Therefore, the composite EKB generated based on the sub-validation key block (sub-EKB), each having its own algorithm and its own key 'data length, can use multiple encrypted key data in the sub-EKB, Even if it is generated by rearranging according to the node or leaf position in the key tree, it is possible to obtain the necessary key data sequentially through the tags of the EKB.
  • Such a synthesized EKB is distributed or provided to a user (device) via a network or stored in various recording media.
  • the key issuance center rearranges and combines the sub-EKB sent from TLCE as needed, and completes the combined EKB by adding the version number and information for verification. Send it to EKB Request Evening.
  • digital signatures using public key cryptography may be requested to a Certificate Authority (CA) different from the key issuing center (KDC).
  • CA Certificate Authority
  • Fig. 55 shows the sub-EKB generated by the TLCE of category tree A, 5100 in the process of generating a composite EKB common to category tree A, 5100 and category tree B, 5200.
  • 3A is a diagram illustrating the configuration of FIG.
  • the sub EKB-(A) is generated as an EKB from which each device in the category tree A, 5100 can obtain the root key.
  • the root directory area 5300 has been described as having an eight-stage configuration in the above description, but here has a two-stage configuration for simplification of the description.
  • the 3-digit numerical value [XXX] with an underline added in the tree structure indicates the tag (e, 1, r) in the EKB, as described above (see Figs. 26 and 27).
  • the root key is stored by encrypting the root key with the node key stored in common by each leaf. You just need to generate E KB.
  • Figure 5 5 Category node A, device node key (DNK) of 5100
  • DNS device node key
  • the node key of each path of the 5121 directory is held, so the root is the root node key of the DNK region 5120.
  • the sub-EKB— (A) generated by the TL CE of category A, 5100 is as follows: evening part: 101, 010, 0000, 111, 111, key part:
  • the sub EKB-(A) becomes E nc (K 0 10, K r oot) and E nc (K 0 1 1, ⁇ r ⁇ ⁇ t).
  • the TLCE of category tree A, 5100 sends this sub EKB— (A) to the key issuing center (KDC).
  • the sub-EKB— (B) generated by the TL CE of category B, 5200 is the following: 1 1 0, 0 1 0, 0 00, 1 1 1, 1 1 1 : Sub EKB-(B) that becomes Enc (K111, Kroot) and Enc (K111, Kroot). TL CE of category tree B, 5200 sends this sub EKB— (B) to the key issuing center (KD C).
  • the key issuing center generates a combined EKB from the sub-EKB- (A) and sub-EKB- (B) generated by each TL CE.
  • the generation of the composite EKB will be described with reference to FIG.
  • the composite EKB is configured as an EKB that allows devices belonging to each of the categories Tree A, 5100 and Category Tree B, 5200 to obtain the root key.
  • a composite EKB is generated by mixing the received key data arrays of multiple sub-EKBs and aligning them from the top of the tree. In the same stage, data arrangement is performed with the left side first.
  • the synthesized EKB has the following tag parts: 100, 010, 010, 000, 0000, 1111, 1111, 1111, 1111, key part: E nc (K 0 1 0, K r oot), Enc (K011, Kroot), Enc (K110, Kroot), and Enc (K111, Kroot).
  • E nc K 0 1 0, K r oot
  • Enc K011, Kroot
  • Enc K110, Kroot
  • Enc K111, Kroot
  • FIG. 58 is a diagram for explaining generation of a sub-EKB when a repoke device (0 1 0 1) 5 150 is present in category A, 5100.
  • the sub-EKB in this case is generated as a sub-EKB— ( ⁇ ') that cannot be processed only by the repoke device (0 1 1 0 1) 5 150.
  • the sub-EKB— (A, :) generated by the CE of category A, 5100 is the tag part: 101, 010, 0000, 111, 000, 001, 11 1, 1 1 1, key part: En c (K 0 1 0, K root), En c (K 0 1 1 1, K root), Enc ( ⁇ 0 1 1 00, K r oot) KB-(A,)
  • the category AA, 5 1 00 1 1 ⁇ £ sends this sub EK B-(A,) to the key issuing center (KD C).
  • the key issuance center confirms the sub-EKB— ( ⁇ ') generated by each TLCE and the sub- ⁇ ⁇ ⁇ - ⁇ ( ⁇ ) received from the category tree ⁇ , 5 200 TL C ⁇ without revoked device (Fig. 56 To generate a composite ⁇ .
  • the generation of the composite ⁇ will be described with reference to FIG.
  • Synthetic EKB is based on the assumption that the root key can be obtained by devices other than the category tree ⁇ , 5100, except for the revoked device (0111001) 5150, and the devices belonging to category ⁇ , 520,000. It is configured as an EKB.
  • a composite EKB is generated by mixing the received key data arrays of multiple sub-EKBs and aligning them from the top of the tree. In the same row, data arrangement is performed with the left side first.
  • the synthesized EKB has the following tag parts: 100, 010, 010, 000, 0 00, 1 1 1, 000, 1 1 1, 1 1 1, 1, 1 1 1, 1 1 1, Key parts: Enc (K 0 1 0, K root), Enc (K 1 1 0, Generated as an EKB with K root), Enc (K111, Kroot), Enc (K0111, Kroot), Enc (K0111, 0, Kroot) .
  • This synthetic EKB is used for devices other than the repo devices (0111001) 5150 of category ⁇ A, 5100, and the devices belonging to the category BB, 5200. EKB that can be obtained.
  • the EKB generated by the key issuer (KDC) by the above processing is transmitted to the EKB request.
  • an EKB requester For example, an EKB requester
  • a content provider that provides content storage media such as CDs and DVDs.
  • ECD Electronic Content Distribution
  • the content key is encrypted using the root key that can be obtained by the EKB, and the content provided to the user device is encrypted using the content key to distribute the content.
  • [c 1] A format holder that gives an EKB to a recording medium manufacturer in a format in which the EKB is stored on the recording medium during manufacturing.
  • [c2] A format holder that provides the recording device manufacturer with the acquired EKB in a format that stores the EKB in the recording device during manufacturing. If it is, provide the generated EKB and the content key encrypted with the root key to the recording device manufacturer, and manufacture the recording device storing the content key encrypted with the EKB and the root key, or manufacture the recording device by itself And distribute it. With this configuration, only devices belonging to a specific category tree that can process EKB can perform encryption processing and decryption processing at the time of content recording and reproduction using EKB.
  • EKB is issued by the above processing.
  • mutual authentication processing and encryption processing of transmission data are performed as necessary.
  • other message encryption processing, digital signature generation, and verification processing may be performed.
  • FIG. 60 is a diagram showing an example of a composite EKB 6000 storing a plurality of sub-EKBs generated by TLCEs of a plurality of category trees as they are.
  • the key issuance center manages the TLCE, the first management entity of the category recorded in the EKB type definition list corresponding to the EKB type identification number specified by the EKB request. Issue a request to generate a sub-EKB, and simply collect and store the sub-EKBs 6110, 6120 ... submitted by each TLCE in the composite EKB. However, machines belonging to each category The size of each sub-EKB part (ex. De—evening length) so that the device can select the sub-EKB corresponding to the category of the device that the device can process from the synthesized EKB Add data (ex. Node ID) 6 1 1 2 that indicates which category the sub EKB is for.
  • each of the sub-EKBs selected as storage targets has a length indicating the data length of the sub-EKB storage area, and a node as a node identifier of a corresponding category tree of each sub-EKB as sub-EKB identification data.
  • the ID is stored in association with the ID.
  • the number of sub EKBs included in the combined EKB is added as header information 6200.
  • a signature (ex. Signature of a certificate authority ('CA)) 6300 is generated and added based on all data of the combined EKB.
  • the storage of the sub EKB 611 0 EKB is the sub EKB— (A) itself generated by the TLCE of the category tree A described in Fig. 55, and the evening part: 101, 010, 000, 1 1 1, 1 1 1, key part: En c (K 0 10, Kroot), En c (K 0 1 1, ⁇ r ⁇ ⁇ t).
  • the storage of the sub ⁇ ⁇ ⁇ ⁇ 6 120 2 KB is the sub EKB— (B) itself generated by the TLCE of the category tree B described in FIG. 56, and the tag parts are: 1 10, 0 10 , 000, 1 1 1, 1 1 1, key parts: Enc (K110, Kroot), Enc (Kill, Kroot).
  • the composite EKB in the case where there is a repoke device described with reference to FIGS. 58 and 59 has the data configuration shown in FIG. EK B is the sub EKB— ( ⁇ ') itself generated by the TLCE of category A described in FIG. 58, and the sub EKB— (A,) is the tag Parts: 101, 0110, 000, 111, 0 00, 00 1, 1 1 1, 1 1 1, Key parts: Enc (K 0 1 0, Kroot), Enc (K 0 1 1 1, Kroot) and Enc (K 0 1 1 00, Kroot).
  • the storage EKB of the sub-EKB 6 120 where no revoke 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 part: 1 1 0, 0 1 0, 000, 1 1 1, 1 1 1, Key parts: Enc (K1110, Kroot), Enc (Kill: Kroot).
  • TL CE a sub-EKB can be generated using a completely arbitrary encryption algorithm and key length. That is, TLCE can determine the encryption algorithm and key length without being affected by other categories.
  • KDC key issuing center
  • the load on the sub-EKB tags and key data collected from each TL CE does not have to be disassembled and reassembled, reducing the load.
  • a device that obtains an EKB according to this method can obtain a root key by finding a sub-EKB of the category to which it belongs and processing it in a unique way defined by the TL CE that manages its own 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 to devise individual keys in fixed lengths in the sub-EKB, so theoretically Will be able to use any size key.
  • EKB 7000 which is commonly used in category trees A and 7100 and category tree B and 7200
  • the EKB 700 which is commonly used in the category tree A, 7100 and the category tree B, 7200, has the EKB type identification number defined as # 1 in the EKB type definition list.
  • the content provider provides the content encrypted with the content key by the network or the media, and the devices belonging to the category A, 7100 and the category B, 7200 are provided with the EKB 7000. Root key is obtained by using and content key is decrypted by root key And the encrypted content is obtained using the content key, and the content is used.
  • the TL CE of category A, 7100 executes a key change notification (see Fig. 53) to the key issuing center (KDC), and the key issuing center (KDC) receives the notification. Notify each managed TLCE and EKB requester based on the tree change notification. The notification at this time only informs that the perimeter change notification has been received, and the EKB type definition list is not updated.
  • the tree change notification based on the revocation occurs only for the EKB requester as an entity using the EKB that can be processed in the revoked category, or for the revoked category. It may be configured to be executed only for the category entity that manages other categories to which the tree and the shared EKB are applied.
  • the Key Issuing Center KDC
  • Content providers as EKB requesters that deliver content to devices in the category that have undergone revoke processing will generate updated EKB that can be processed only on devices that are not revoked.
  • the content provider as an EKB request is an EKB type identification number that is defined as the type of EKB commonly used in category A, 7100 and category B, 7200.
  • the key issuing center refers to the EKB type definition list based on the specified EKB type identification number # 1, and the corresponding category tree node Based on Category A, 7100 and Category B, 7200! 1 1 ⁇ . Requests E to generate a sub-EKB that allows a valid device to obtain a new root key.
  • Each of the category tree A, 7100 and the category tree B, 7200 generates a sub-EKB based on the request.
  • a sub-EKB— (A) that can acquire a new root key only in other devices excluding the revoked device A 1, 7120 is generated in the category A, 7100 .
  • a sub-EKB— (B) that can acquire a new root key is generated for all devices belonging to the power category, and the key issuing center ( KD C).
  • the key issuance center (KDC) generates a combined EKB based on the sub-EKB received from each TLCE according to the method described above, and sends the generated EKB to the EKB request (ex. Content provider).
  • the EKB requester (ex. Content provider) distributes content by applying the new EKB received from the key distribution center (KDC). Specifically, it provides the content encrypted with the content key, and encrypts and provides the content key with the root key obtained by decrypting the EKB.
  • KDC key distribution center
  • Devices belonging to category tree A, 7100 and category tree B, 7200 execute acquisition of root key using EKB, acquisition of content key by decryption processing using root key, and acquisition of encrypted content by content key. Then the content is available.
  • the revoked devices A 1, 7 120 of the category tree A 7100 cannot process the updated EKB, so that the content cannot be used.
  • the key issue center (KD C) does not execute the update process of the EKB type definition list at the time when the key issue center (KD C) receives the local change notification from TL CE.
  • the key issuing center (KDC) updates the EKB type definition list and EKB based on the tree change information, and executes the EKB requester, TLCE It may be configured to send the updated EKB type definition list to the website.
  • EKB 80 ⁇ 0 which is commonly used in category trees A, 8100 and category trees B, 8200
  • a common EKB is stored in a recording device or a recording medium that is commonly used in the category A, 8100 and the category B, 8200, and the user performs content encryption using the EKB. It is assumed that content recording / reproducing is performed by decryption processing.
  • EKB 800 0, which is commonly used in Category Tree A, 8100 and Category Tree B, 8200 has the EKB type identification number defined as # 1 in the EKB type definition list. I do.
  • the TLCE of the category tree A, 8100 executes a tree change notification (see Fig. 53) to the key issuing center (KDC), and the key issuing center (KDC) receives the tree change notification. Notify each managed TL CE and related EKB request based on the The notification at this point only informs that the perimeter change notification has been received, and the EKB type definition list is not updated.
  • the TLCE of the category tree that executed the revocation processing stops itself from processing new content using EKB in the future in the revocation device A 1, 8120, Make an EKB issuance request to the key issuing center (KDC) to generate an updated EKB that can be processed only by the device.
  • TLCE as an EKB requester is an EKB type identification number defined as a type of EKB commonly used in category trees A and 8100 and category tree B and 8200, respectively.
  • the EKB requester generates a new root key and sends it to the KDC, or requests the KDC to generate a new root key.
  • the key issuer Senichi refers to the EKB type definition list based on the specified EKB type identification number # 1, and the category tree A, 8 10 based on the corresponding category tree node Requests 0 and E of category P B, 8200 to generate a sub EKB that can obtain a new root key on a legitimate device.
  • Each of the TL CEs of category tree A, 8100 and category tree B, 8200 generates a sub EKB based on the request.
  • a sub-EKB— (A) is generated in which a new root key can be obtained only in another device excluding the revoked device A1, 8120.
  • a sub-EKB-(B) that can acquire a new root key is generated for all devices belonging to the power category, and the key issuance center (KD C).
  • the key issuing center (KDC) generates a combined EKB based on the sub-EKB received from each TLCE according to the method described above, and sends the generated EKB to each TLCE (ex. Format holder 1).
  • Each TLCE (e. Format holder) distributes the new EKB received from the key issuer Senichi (KDC) to each device and causes the EKB to be updated.
  • KDC key issuer Senichi
  • Devices belonging to category A, 8100 and category B, 8200 are encrypted by applying a protocol obtained using the EKB that has updated the recording for the new content recording device. Run as Content that has been encrypted and recorded using the new EKB can only be decrypted when the corresponding EKB is applied, so that it cannot be used on a revoked device.
  • a key directory having a plurality of sub-trees that are partitioned based on a category and managed by a category entity is configured, and a path configuring the key directory is configured.
  • Select and select In a configuration in which an EKB consisting of the encryption processing data of the upper key by the lower key on the path is generated and provided to the device, the EKB type identifier, the identification data of one or more categories that can be EKB processed, and Since the configuration is such that the EKB issuance management is performed based on the EKB type definition list that is associated with the EKB, the category to which the EKB requester as the EKB generation requester can apply can be easily selected.
  • E KB activation keep
  • a configuration in which a root key is generated by itself, and generation of a root key is performed in a key issuing center. Since the requested configuration can be selectively executed, the burden on the EKB generation requester is reduced, and in the EKB generation at the EKB issuing center, the category administrator is responsible for generating the sub EKB at the time of the EKB generation request Since it was configured to request the category and entity, the efficiency of EKB generation and management processing becomes possible.
  • a key tree that has a plurality of subtrees that are classified based on a category and is managed by a category entity is formed, and a path that forms the key tree is selected and selected.
  • an EKB composed of data processed by the upper key using the lower key on the path is generated and provided to the device, the sub-validity that can be decrypted in each sub-tree set as a partial tree of the key tree
  • a composite EKB composed of encrypted key blocks (sub EKBs) was configured, and each key data in the composite EKB was stored in a fixed-length data field. Even in this case, each device can provide a decryptable EKB.
  • a keyword is formed based on a category and has a plurality of subtrees managed by a category entity, and a path constituting the keyword is selected to select a path.
  • Upper lower key In a configuration in which an EKB composed of encryption processing data of a higher-order key is generated and provided to a device, a sub-validation key block (a sub-validation key block that can be decrypted in each sub-tree set as a partial sub-tree of a key) Configure the composite EKB of the sub EKB, hold the key array in each sub-validated key block (sub EKB) to be stored in the composite EKB, and store the sub EKB corresponding to each sub EKB.
  • the data length and sub-EKB identification data are added, even if sub-EKBs are synthesized by various algorithms, it is possible to provide EKB that can be decoded by each device.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Storage Device Security (AREA)
  • Hardware Redundancy (AREA)
  • Debugging And Monitoring (AREA)
  • Electrical Discharge Machining, Electrochemical Machining, And Combined Machining (AREA)
  • Multi-Process Working Machines And Systems (AREA)

Description

明 細 書
情報処理システム及ぴ方法
技術分野
本発明は、 情報処理システム、 情報処理方法、 および情報記録媒体、 並びにプ ログラム記録媒体に関し、 特に、 コンテンツなど各種データを特定の正当なユー ザに提供する暗号処理を伴う配信システムおよび方法に関する。 特に、 木 （ッリ 一） 構造の階層的鍵配信方式を用い、 配信デバイスに応じて生成したキーブロヅ クを用いて、 例えばコンテンツの暗号化キーとしてのコンテンツキー配信、 ある いはその他各種の安全性を保持することを可能とする情報処理システム、 情報処 理方法、 および情報記録媒体、 並びにプログラム記録媒体に関する。 背景技術
昨今、 ゲームプログラム、 音声デ一夕、 画像データ等、 様々なソフ トウェアデ 一夕 （以下、 これらをコンテンツ （Content) と呼ぶ） を、 インターネッ ト等のネ ットワーク、 あるいは D V D、 C D等の流通可能な記憶媒体を介しての流通が盛 んになってきている。 これらの流通コンテンツは、 ユーザの所有する P C (Personal Computer), ゲーム機器によってデータ受信、 あるいは記憶媒体の装 着がなされて再生されたり、 あるいは P C等に付属する記録再生機器内の記録デ バイス、 例えばメモリカード、 ハードディスク等に格納されて、 格納媒体からの 新たな再生により利用される。
ビデオゲーム機器、 P C等の情報機器には、 流通コンテンツをネヅ トワークか ら受信するため、 あるいは D V D、 C D等にアクセスするためのインタフェース を有し、 さらにコンテンツの再生に必要となる制御手段、 プログラム、 デ一夕の メモリ領域として使用される R A M、 R O M等を有する。
音楽データ、 画像デ一夕、 あるいはプログラム等の様々なコンテンツは、 再生 機器として利用されるゲーム機器、 P C等の情報機器本体からのユーザ指示、 あ るいは接続された入力手段を介したユーザの指示により記憶媒体から呼び出され、 情報機器本体、 あるいは接続されたディスプレイ、 スピーカ等を通じて再生され る。
ゲームプログラム、 音楽データ、 画像データ等、 多くのソフ トウェア ' コンテ ンヅは、 一般的にその作成者、 販売者に頒布権等が保有されている。 従って、 こ れらのコンテンヅの配布に際しては、 一定の利用制限、 すなわち、 正規なユーザ に対してのみ、 ソフ トウェアの使用を許諾し、 許可のない複製等が行われないよ うにする、すなわちセキュリティを考慮した構成をとるのが一般的となっている。 ユーザに対する利用制限を実現する 1つの手法が、 配布コンテンヅの暗号化処 理である。すなわち、例えばイン夕一ネッ ト等を介して暗号化された音声データ、 画像データ、 ゲームプログラム等の各種コンテンヅを配布するとともに、 正規ュ 一ザであると確認された者に対してのみ、 配布された暗号化コンテンヅを復号す る手段、 すなわち復号鍵を付与する構成である。
暗号化データは、 所定の手続きによる復号化処理によつて利用可能な復号デ一 夕 （平文） に戻すことができる。 このような情報の暗号化処理に暗号化鍵を用い、 復号化処理に復号化鍵を用いるデータ暗号化、 復号化方法は従来からよく知られ ている。
暗号化鍵と復号化鍵を用いるデータ暗号化 ·復号化方法の態様には様々な種類 あるが、 その 1つの例としていわゆる共通鍵暗号化方式と呼ばれている方式があ る。 共通鍵暗号化方式は、 データの暗号化処理に用いる暗号化鍵とデータの復号 化に用いる復号化鍵を共通のものとして、 正規のユーザにこれら暗号化処理、 復 号化に用いる共通鍵を付与して、 鍵を持たない不正ユーザによるデータアクセス を排除するものである。この方式の代表的な方式に D E S (データ暗号標準： Deta encryption standard) がある 0
上述の暗号化処理、 復号化に用いられる暗号化鍵、 復号化鍵は、 例えばあるパ スワード等に基づいてハッシュ関数等の一方向性関数を適用して得ることができ る。 一方向性関数とは、 その出力から逆に入力を求めるのは非常に困難となる関 数である。 例えばユーザが決めたパスワードを入力として一方向性関数を適用し て、 その出力に基づいて暗号化鍵、 復号化鍵を生成するものである。 このように して得られた暗号化鍵、 復号化鍵から、 逆にそのオリジナルのデータであるパス ワードを求めることは実質上不可能となる。
また、 暗号化するときに使用する暗号化鍵による処理と、 復号するときに使用 する復号化鍵の処理とを異なるァルゴリズムとした方式がいわゆる公開鍵暗号化 方式と呼ばれる方式である。 公開鍵暗号化方式は、 不特定のユーザが使用可能な 公開鍵を使用する方法であり、 特定個人に対する暗号化文書を、 その特定個人が 発行した公開鍵を用いて暗号化処理を行なう。 公開鍵によって暗号化された文書 は、 その暗号化処理に使用された公開鍵に対応する秘密鍵によってのみ復号処理 が可能となる。 秘密鍵は、 公開鍵を発行した個人のみが所有するので、 その公開 鍵によって暗号化された文書は秘密鍵を持つ個人のみが復号することができる。 公開鍵暗号化方式の代表的なものには R S A (Rivest-Shamir-Adleman)暗号があ る。 このような暗号化方式を利用することにより、 暗号化コンテンツを正規ユー ザに対してのみ復号可能とするシステムが可能となる。
上記のようなコンテンヅ配信システムでは、 コンテンヅを暗号化してユーザに ネッ トワーク、 あるいは D V D、 C D等の記録媒体に格納して提供し、 暗号化コ ンテンヅを復号するコンテンツキーを正当なユーザにのみ提供する構成が多く採 用されている。 コンテンツキー自体の不正なコピー等を防ぐため、 コンテンヅキ 一を暗号化して正当なユーザに提供し、 正当なユーザのみが有する復号キーを用 いて暗号化コンテンヅキーを復号してコンテンツキーを使用可能とする構成が提 案されている。
正当なユーザであるか否かの判定は、 一般には、 例えばコンテンヅの送信者で あるコンテンツプロバイダとユーザデバイス間において、 コンテンツ、 あるいは コンテンヅキーの配信前に認証処理を実行することによって可能となる。 一般的 な認証処理においては、 相手の確認を行なうとともに、 その通信でのみ有効なセ ヅシヨンキーを生成して、 認証が成立した場合に、 生成したセヅシヨンキ一を用 いてデータ、 例えばコンテンヅあるいはコンテンツキーを暗号化して通信を行な う。 認証方式には、 共通鍵暗号方式を用いた相互認証と、 公開鍵方式を使用した 認証方式があるが、 共通鍵を使った認証においては、 システムワイ ドで共通な鍵 が必要になり、 更新処理等の際に不便である。 また、 公開鍵方式においては、 計 算負荷が大きくまた必要なメモリ量も大きくなり、 各デバイスにこのような処理 手段を設けることは望ましい構成とはいえない。 発明の開示
本発明では、 上述のようなデ一夕の送信者、 受信者間の相互認証処理に頼るこ となく、 正当なユーザに対してのみ、 安全にデータを送信することを可能とする とともに、 階層的鍵配信ヅリ一をカテゴリ単位としたサブツリー、 すなわちカテ ゴリヅリーを形成し、 複数のカテゴリヅリー内で適用 （復号処理） 可能な暗号化 キープ口ヅクを使用する構成を提案する。
さらに、 1以上の選択されたカテゴリツリーにおいて復号可能な暗号化鍵デー 夕ブロックである有効化キーブロック （EKB) を生成して各カテゴリツリーに 属するデバイスにおいて共通に使用可能とするとともに、 どのカテゴリヅリーで 処理可能、 すなわち復号可能であるかを示す E KBタイプ定義リストを使用する ことにより、 EKB生成、 管理処理の効率化を可能とした情報処理システム、 情 報処理方法、 および情報記録媒体、 並びにプログラム記録媒体を提供することを 目的とする。
本発明の第 1の側面は、
複数のデバイスをリーフとして構成したヅリ一のル一トからリーフまでのパス 上のルート、 ノード、およびリーフに各々キーを対応付けたキーツリーを構成し、 該キーツリーを構成するパスを選択して選択パス上の下位キーによる上位キーの 暗号化処理データを有し、 前記選択パスに対応するノードキーセッ トを利用可能 なデバイスにおいてのみ復号可能とした有効化キーブロック （EKB) をデバイ スに提供する構成を持つ情報処理システムであり、
有効化キーブロック （EKB) を生成するキー発行センター （KD C) に対し て EKBの生成を要求する EKBリクエス夕は、
生成済みルートキーを含む E KB生成要求としての第 1の E KB生成要求、 ま たは、
キ一発行センター （KD C) におけるル一トキ一生成および該生成ルートキ一 を含む E KB生成を要求する第 2の E KB生成要求、 のいずれかをキー発行センター （KD C) に対する E K B生成要求として出力 し、
キー発行センター （KD C) は、 前記第 1の E KB生成要求、 または前記第 2 の E KB生成要求の受信に応じて受信ルートキーまたは生成ルートキーを含めた E KB生成を実行する構成を有することを特徴とする情報処理システムにある。 さらに、本発明の情報処理システムの一実施態様において、前記キーツリーは、 カテゴリに基づいて区分され、 カテゴリ 'エンティティによって管理されるサブ ヅリーとしてのカテゴリツリーを複数有する構成であり、 前記 EKBリクエス夕 は、 EKBタイプ識別子と、 E KB処理可能なカテゴリヅリーの識別データとを 対応付けた E KBタイプ定義リストに基づいて E KBタイプ識別子を選択し、 選 択 E KBタイプ識別子を含む E KB生成要求を前記第 1の E KB生成要求または 前記第 2の EKB生成要求として前記キー発行センター （KD C) に対して出力 する構成であることを特徴とする。
さらに、 本発明の情報処理システムの一実施態様において、 前記 EKBリクェ ス夕は、 記憶手段、 または、 ネッ トワーク上の閲覧可能サイ トから取得される E K Bタイプ定義リストに基づいて E K Bタイプ識別子を選択する構成であること を特徴とする。
さらに、 本発明の情報処理システムの一実施態様において、 前記 E KBタイプ 定義リストの E K B処理可能なカテゴリヅリ一の識別データは、 カテゴリヅリ一 のノードの識別子であるノード I Dであることを特徴とする。
さらに、 本発明の情報処理システムの一実施態様において、 前記 EKBタイプ 定義リストには、 カテゴリツリーに属するデバイスに関する説明を含む構成であ ることを特徴とする。
さらに、 本発明の第 2の側面は、
複数のデパイスをリーフとして構成したッリ一のルートからリーフまでのパス 上のル一ト、 ノード、およびリーフに各々キーを対応付けたキーツリーを構成し、 該キーツリーを構成するパスを選択して選択パス上の下位キーによる上位キーの 暗号化処理データを有し、 前記選択パスに対応するノ一ドキーセヅトを利用可能 なデバイスにおいてのみ復号可能とした有効化キーブロック （EKB) をデバイ スに提供する構成を持つ情報処理システムであり、
前記キーヅリ一は、 カテゴリに基づいて区分され、 カテゴリ ·エンティティによ つて管理されるサブヅリーとしてのカテゴリヅリーを複数有する構成であり、 有効化キ一ブロック （EKB) を生成するキー発行センター （KD C) は、 EKB生成の要求エンティティである EKBリクエスタの要求に基づく有効化 キーブロック （EKB) の生成において、 生成する有効化キーブロック （EKB) の復号可能なカテゴリヅリーを管理する 1以上のカテゴリ ·エンティティに各力 テゴリツリーにおいて処理可能なサブ E KBの生成要求を出力し、 カテゴリ . ェ ンティティから受領したサブ有効化キーブロック （サブ EKB) に基づいて 1以 上のカテゴリツリーにおいて処理可能な E KBを生成する構成を有することを特 徴とする情報処理システムにある。
さらに、 本発明の情報処理システムの一実施態様において、 前記キー発行セン ター （KD C) は、 E KBタイプ識別子と、 E KB処理可能なカテゴリヅリーの 識別データとを対応付けた E KBタイプ定義リストを有し、 E KBの生成を要求 するエンティティである EKBリクエス夕から受領する E KB生成要求中に含ま れる E KBタイプ識別子に基づく E KB夕イブ定義リストの検索によりカテゴリ ヅリーの識別データを抽出して、 抽出されたカテゴリヅリ一の識別データに対応 する 1以上のカテゴリ .エンティティの生成したサブ E K Bに基づいて、 EKB タイプ定義リストに設定されたカテゴリヅリーに共通に使用可能な EKBを生成 して提供する構成であることを特徴とする。
さらに、 本発明の情報処理システムの一実施態様において、 前記キー発行セン 夕一 （KD C) からサブ EKB生成要求を受領したカテゴリ 'エンティティは、 自己の管理するカテゴリヅリーに属するノードまたはリーフに対応付けられたキ 一に基づいて処理可能な E KBとしてのサブ有効化キープ口ヅク （サブ EKB) を生成する構成であることを特徴とする。
さらに、本発明の情報処理システムの一実施態様において、前記キーヅリーは、 最上段に複数段のルートヅリ一が構成され、 該ルートッリ一に直結する トップレ ベル · カテゴリッリー、 該トヅプレベル · カテゴリヅリーの下段に連結されるサ ブカテゴリツリーによって構成され、 前記カテゴリ ' エンティティは、 前記トツ プレベル · カテゴリヅリ一の管理エンティティとして該トヅプレベル ■ カテゴリ ヅリ一および該トヅプレベル · カテゴリヅリ一の下段に連なるサブカテゴリッリ —の管理を行ない、 前記カテゴリ ·エンティティは、 自己の管理する トップレべ ル · カテゴリヅリ一および該トヅプレベル · カテゴリッリ一の下段に連なるサブ カテゴリヅリーに属するノードまたはリーフに対応して設定されるキーに基づい て処理可能な E KBとしてのサブ有効化キーブロック （サブ EKB) を生成する 構成であることを特徴とする。
さらに、 本発明の第 3の側面は、
複数のデバイスをリーフとして構成したヅリ一のル一トからリーフまでのパス 上のルート、 ノード、およびリーフに各々キーを対応付けたキーツリーを構成し、 該キーツリーを構成するパスを選択して選択パス上の下位キーによる上位キーの 暗号化処理データを有し、 前記選択パスに対応するノ一ドキーセッ トを利用可能 なデバイスにおいてのみ復号可能とした有効化キーブロック （EKB) をデバイ スに提供する構成を持つシステムにおける情報処理方法であり、
有効化キーブロック （EKB) を生成するキー発行センター （KD C) に対し て E KBの生成を要求する E KBリクエス夕は、
生成済みルートキーを含む E KB生成要求としての第 1の E KB生成要求、 ま たは、
キー発行センター （KD C) におけるルートキー生成および該生成ルートキ一 を含む EKB生成を要求する第 2の E KB生成要求、
のいずれかをキー発行センター （KD C) に対する E K B生成要求として出力 し、
キー発行センター （KD C) は、 前記第 1の E KB生成要求、 または前記第 2 の E KB生成要求の受信に応じて受信ルートキーまたは生成ルートキーを含めた E KB生成を実行することを特徴とする情報処理方法にある。
さらに、 本発明の情報処理方法の一実施態様において、 前記キーツリーは、 力 テゴリに基づいて区分され、 カテゴリ ·エンティティによって管理されるサブヅ リーとしてのカテゴリヅリ一を複数有する構成であり、前記 E KBリクエスタは、 EKBタイプ識別子と、 E KB処理可能なカテゴリヅリーの識別データとを対応 付けた E KBタイプ定義リストに基づいて E KBタイプ識別子を選択し、 選択 E KBタイプ識別子を含む E KB生成要求を前記第 1の EKB生成要求または前記 第 2の EKB生成要求として前記キー発行センター （KD C) に対して出力する ことを特徴とする。
さらに、 本発明の情報処理方法の一実施態様において、 前記 E KBリクエスタ は、 記憶手段、 または、 ネッ トワーク上の閲覧可能サイ トから取得される EKB タイプ定義リス トに基づいて E KBタイプ識別子を選択することを特徴とする。 さらに、 本発明の情報処理方法の一実施態様において、 前記 E KBタイプ定義 リストの EKB処理可能なカテゴリッリーの識別データは、 カテゴリヅリーのノ 一ドの識別子であるノード I Dであることを特徴とする。
さらに、 本発明の情報処理方法の一実施態様において、 前記 E KBタイプ定義 リストには、 カテゴリヅリーに属するデバイスに関する説明を含む構成であるこ とを特徴とする。
さらに、 本発明の第 4の側面は、
複数のデバイスをリーフとして構成したヅリーのル一トからリーフまでのパス 上のルート、 ノード、およびリーフに各々キーを対応付けたキ一ヅリーを構成し、 該キーツリーを構成するパスを選択して選択パス上の下位キーによる上位キーの 暗号化処理デ一夕を有し、 前記選択パスに対応するノードキ一セッ トを利用可能 なデバイスにおいてのみ復号可能とした有効化キーブロック （EKB) をデバイ スに提供する構成を持つシステムにおける情報処理方法であり、
前記キーツリーは、 カテゴリに基づいて区分され、 カテゴリ ' エンティティに よって管理されるサブツリーとしてのカテゴリヅリ一を複数有する構成であり、 有効化キーブロック （EKB) を生成するキー発行センター （KD C) は、 E KB生成の要求エンティティである E KBリクエスタの要求に基づく有効化 キープ口ヅク （EKB) の生成において、 生成する有効化キープ口ヅク （EKB) の復号可能なカテゴリヅリ一を管理する 1以上のカテゴリ · エンティティに各力 テゴリヅリーにおいて処理可能なサブ E KBの生成要求を出力し、 カテゴリ - ェ ンティティから受領したサブ有効化キーブロック （サブ EKB) に基づいて 1以 上のカテゴリヅリーにおいて処理可能な E KBを生成することを特徴とする情報 処理方法にある。
さらに、 本発明の情報処理方法の一実施態様において、 前記キー発行セン夕一 (KD C) は、 E KBタイプ識別子と、 E KB処理可能なカテゴリヅリーの識別 データとを対応付けた EKBタイプ定義リストを有し、 EKBの生成を要求する エンティティである EKBリクエス夕から受領する E KB生成要求中に含まれる E KBタイプ識別子に基づく E KBタイプ定義リストの検索によりカテゴリヅリ —の識別データを抽出して、 抽出されたカテゴリヅリ一の識別データに対応する 1以上のカテゴリ 'エンティティの生成したサブ E KBに基づいて、 EKBタイ プ定義リストに設定されたカテゴリッリーに共通に使用可能な E KBを生成して 提供する構成であることを特徴とする。
さらに、 本発明の情報処理方法の一実施態様において、 前記キー発行セン夕一 (KD C) からサブ EKB生成要求を受領したカテゴリ . エンティティは、 自己 の管理するカテゴリヅリーに属するノードまたはリーフに対応付けられたキーに 基づいて処理可能な E KBとしてのサブ有効化キ一ブロック （サブ EKB) を生 成することを特徴とする。
さらに、 本発明の情報処理方法の一実施態様において、 前記キーヅリ一は、 最 上段に複数段のルートヅリ一が構成され、 該ルートヅリーに直結するトップレベ ル · カテゴリッリー、 該トヅプレベル · カテゴリッリ一の下段に連結されるサブ カテゴリツリーによって構成され、 前記カテゴリ 'エンティティば、 前記トップ レベル · カテゴリヅリ一の管理ェンティティとして該トヅプレベル · カテゴリッ リ一および該トヅプレベル · カテゴリヅリ一の下段に連なるサブカテゴリヅリ一 の管理を行ない、前記カテゴリ 'エンティティは、 自己の管理する トップレベル ' カテゴリヅリ一および該トヅプレベル · カテゴリヅリ一の下段に連なるサブカテ ゴリヅリーに属するノードまたはリーフに対応して設定されるキーに基づいて処 理可能な E KBとしてのサブ有効化キープロヅク （サブ EKB) を生成すること を特徴とする。
さらに、 本発明の第 5の側面は、
複数のデバイスをリーフとして構成したッリーのルートからリーフまでのパス 上のルート、 ノード、およびリーフに各々キーを対応付けたキーツリ一を構成し、 該キーヅリーを構成するパスを選択して選択パス上の下位キーによる上位キーの 暗号化処理デ一タを有し、 前記選択パスに対応するノードキ一セヅトを利用可能 なデバイスにおいてのみ復号可能とした有効化キーブロック （EKB) をデバイ スに提供する構成を持つシステムにおける情報処理をコンピュータ · システム上 で実行せしめるコンピュータ · プログラムを記録したプログラム記録媒体であつ て、 前記コンピュータ · プログラムは、
生成済みルートキーを含む E KB生成要求としての第 1の E KB生成要求、 ま たは、 キー発行センタ一 （KD C) におけるルートキー生成および該生成ルート キーを含む E K B生成を要求する第 2の E KB生成要求のいずれかの E KB生成 要求を受信するステップと、
受信した E KB生成要求の種類に応じて、受信ルートキーを含めた E KB生成、 またはルートキーの生成および生成ルートキーを含めた E KB生成のいずれかの 処理を選択的に実行するステップと、
を有することを特徴とするプログラム記録媒体にある。
さらに、 本発明の第 6の側面は、
複数のデバイスをリーフとして構成したヅリ一のルートからリーフまでのパス 上のルート、 ノード、およびリーフに各々キーを対応付けたキーヅリ一を構成し、 該キーツリーを構成するパスを選択して選択パス上の下位キーによる上位キーの 暗号化処理データを有し、 前記選択パスに対応するノードキーセッ トを利用可能 なデバイスにおいてのみ復号可能とした有効化キープロヅク （EKB) をデバイ スに提供する構成を持つシステムにおける情報処理をコンピュータ . システム上 で実行せしめるコンピュータ · プログラムを記録したプログラム記録媒体であつ て、 前記コンピュータ · プログラムは、
E KB生成要求に含まれる E KBタイプ識別子に基づいて、 E KBタイプ識別 子と、 E KB処理可能な 1以上のカテゴリツリーの識別データとを対応付けた E KBタイプ定義リストからカテゴリヅリーの識別データを抽出するステップと、 抽出されたカテゴリヅリーの識別データに対応するカテゴリヅリーを管理する 1以上のカテゴリ .エンティティに各カテゴリヅリーにおいて処理可能なサブ有 効化キーブロック （サブ EKB) の生成要求を出力するステップと、 カテゴリ · エンティティから受領したサブ有効化キーブロック （サブ EKB) に基づいて 1以上のカテゴリヅリーにおいて処理可能な E KBを生成するステツ プと、
を有することを特徴とするプログラム記録媒体にある。
さらに、 本発明の第 7の側面は、
複数のデバイスをリーフとして構成したヅリ一のルートからリーフまでのパス 上のルート、 ノード、およびリーフに各々キーを対応付けたキ一ヅリ一を構成し、 該キーツリーを構成するパスを選択して選択パス上の下位キーによる上位キーの 暗号化処理データを有し、 前記選択パスに対応するノ一ドキーセットを利用可能 なデバイスにおいてのみ復号可能とした有効化キーブロック （EKB) をデバイ スに提供する構成を持つ情報処理システムであり、
前記有効化キーブロック （EKB) は、
前記キーヅリ一の部分ヅリーとして設定されるサブッリ一の各々において復号 処理可能なサブ有効化キープ口ヅク （サブ E KB)の合成 E KBとして構成され、 該合成 E KB内に含まれる複数のキー ·データの各々が固定長のデ一夕フィール ド内に格納された構成を有することを特徴とする情報処理システムにある。
さらに、本発明の情報処理システムの一実施態様において、前記サブヅリーは、 カテゴリに基づいて区分され、 カテゴリ ，エンティティによって管理されるカテ ゴリヅリーであり、 前記サブ有効化キーブロック （サブ EKB) は、 前記カテゴ リ ·エンティティにおいて自己の管理するカテゴリヅリーに属するノードまたは リーフに対応付けられたキーに基づいて処理可能な E KBとして生成され、 キー 発行センター （KD C) において、 前記カテゴリ 'エンティティの生成したサブ E KBに基づいて、 複数のカテゴリヅリーに共通に使用可能な E KBとしての合 成 E KBを生成する構成であることを特徴とする。
さらに、 本発明の情報処理システムの一実施態様において、 前記サブ有効化キ 一ブロック （サブ EKB) の各々は、 各々独自のアルゴリズム、 独自のキー ' デ —夕長を持つサブ有効化キーブロック （サブ EKB) として構成され、 キー発行 セン夕一 （KD C)は、 前記サブ EKBに基づく合成 EKBの生成処理において、 合成 E KBを構成するサブ E KB内のキー .デ一夕の各々を固定長のデータフィ ールド内に格納する処理を実行する構成であることを特徴とする。
さらに、本発明の情報処理システムの一実施態様において、前記合成 E K Bは、 前記キーツリーを構成する各ノードに対応して設定されるノードキーを下位ノー ドキーまたは下位リーフキーを用いて暗号化した暗号化キーデ一夕と、 前記合成 E K Bに格納された 1以上の暗号化キーデータ各々のノード位置の下位の左右位 置のノードまたはリーフ位置の暗号化キーデータの有無を示すタグを含む構成で あることを特徴とする。
さらに、本発明の情報処理システムの一実施態様において、前記合成 E K Bは、 該合成 E K Bを復号可能な末端ノードまたはリーフを最下段とした簡略化したヅ リーを構成するパスを選択して不要ノードを省略することにより再構築される再 構築階層ヅリーのノードまたはリーフに対応するキーを暗号化キーデータとして 有することを特徴とする。
さらに、本発明の情報処理システムの一実施態様において、前記合成 E K Bは、 複数のサブ E K Bの各々に含まれる複数の暗号化キーデータを、 キーツリーにお けるノードまたはリーフ位置に応じて再配列して生成された構成を有することを 特徴とする。
さらに、 本発明の第 8の側面は、
カテゴリに基づいて区分されたサブヅリ一としてのカテゴリヅリーにより構成 され、 複数のデバイスをリーフとして構成したヅリーのルートからリーフまでの パス上のルート、 ノード、 およびリーフに各々キーを対応付けたキーヅリーを構 成し、 該キーツリーを構成するパスを選択して選択パス上の下位キーによる上位 キーの暗号化処理データを有し、 前記選択パスに対応するノードキーセヅ トを利 用可能なデバイスにおいてのみ復号可能とした有効化キープロヅク （E K B ) を 格納した情報記録媒体であり、
前記キーツリ一の部分ッリーとして設定されるサブッリ一の各々において復号 処理可能なサブ有効化キ一ブロック （サブ E K B ) の合成 E K Bを格納し、 該合 成 E K B内に含まれる複数のキー ·データの各々が固定長のデータフィールド内 に格納された構成を有することを特徴とする情報記録媒体にある。
さらに、 本発明の情報記録媒体の一実施態様において、 前記サブ有効化キープ ロック （サブ EKB) の各々は、 各々独自のアルゴリズム、 独自のキー . データ 長を持つサブ有効化キーブロック （サブ EKB) として構成され、 キー . デ一夕 の格納領域が固定長とされている構成であることを特徴とする。
さらに、 本発明の第 9の側面は、
複数のデバイスをリーフとして構成したヅリ一のルートからリーフまでのパス 上のルート、 ノード、およびリーフに各々キーを対応付けたキーヅリーを構成し、 該キーヅリーを構成するパスを選択して選択パス上の下位キーによる上位キーの 暗号化処理データを有し、 前記選択パスに対応するノードキーセッ トを利用可能 なデバイスにおいてのみ復号可能とした有効化キーブロック （EKB) をデバイ スに提供する構成を持つシステムにおける情報処理方法であり、
前記有効化キーブロック （EKB) は、
前記キーツリ一の部分ヅリーとして設定されるサブヅリ一の各々において復号 処理可能なサブ有効化キープ口ヅク （サブ EKB)の合成 E KBとして構成され、 該合成 E KB内に含まれる複数のキー ·データの各々が固定長のデータフィール ド内に格納されてデバイスに提供することを特徴とする情報処理方法にある。 さらに、 本発明の情報処理方法の一実施態様において、 前記サブヅリ一は、 力 テゴリに基づいて区分され、 カテゴリ 'エンティティによって管理されるカテゴ リヅリーであり、前記サブ有効化キープ口ヅク （サブ E KB)は、前記カテゴリ . エンティティにおいて自己の管理するカテゴリッリーに属するノードまたはリー フに対応付けられたキ一に基づいて処理可能な EKBとして生成され、 キー発行 センター （KD C) において、 前記カテゴリ · エンティティの生成したサブ EK Bに基づいて、 複数のカテゴリヅリーに共通に使用可能な E KBとしての合成 E KBを生成することを特徴とする。
さらに、 本発明の情報処理方法の一実施態様において、 前記サブ有効化キープ ロック （サブ EKB) の各々は、 各々独自のアルゴリズム、 独自のキ一 . データ 長を持つサブ有効化キ一ブロック （サブ EKB) として構成され、 キ一発行セン 夕一 （KD C) は、 前記サブ E KBに基づく合成 E KBの生成処理において、 合 成 E KBを構成するサブ E KB内のキー ·データの各々を固定長のデータフィー ルド内に格納する処理を実行することを特徴とする。 さらに、 本発明の情報処理方法の一実施態様において、 前記有効化キーブロッ ク （EKB) は、 前記キーヅリ一を構成する各ノードに対応して設定されるノー ドキ一を下位ノードキ一または下位リーフキーを用いて暗号化した暗号化キーデ 一夕と、 前記有効化キーブロック （EKB) に格納された 1以上の暗号化キ一デ 一夕各々のノ一ド位置の下位の左右位置のノードまたはリーフ位置の暗号化キー デ一夕の有無を示すタグを含む構成として生成することを特徴とする。
さらに、 本発明の情報処理方法の一実施態様において、 前記有効化キーブロッ ク （EKB) は、 該有効化キーブロック （EKB) を復号可能な末端ノードまた はリーフを最下段とした簡略化したヅリーを構成するパスを選択して不要ノード を省略することにより再構築される再構築階層ヅリーのノードまたはリーフに対 応するキーを暗号化キーデータとして有する構成として生成することを特徴とす る。
さらに、 本発明の情報処理方法の一実施態様において、 前記合成 E KBは、 複 数のサブ EKBの各々に含まれる複数の暗号化キーデータを、 キーヅリーにおけ るノードまたはリーフ位置に応じて再配列して生成することを特徴とする。
さらに、 本発明の第 1 0の側面は、
複数のデバイスをリーフとして構成したヅリーのルートからリーフまでのパス 上のルート、 ノード、およびリーフに各々キーを対応付けたキーヅリ一を構成し、 該キーツリーを構成するパスを選択して選択パス上の下位キーによる上位キーの 暗号化処理データを有し、 前記選択パスに対応するノードキーセットを利用可能 なデバイスにおいてのみ復号可能とした有効化キーブロック （EKB) をデバイ スに提供する構成を持つシステムにおける有効化キーブロック （EKB) 生成処 理をコンピュータ · システム上で実行せしめるコンピュータ · プログラムを記録 したプログラム記録媒体であって、 前記コンピュータ · プログラムは、
前記キーヅリ一の部分ヅリーとして設定されるサブヅリ一の各々において復号 処理可能なサブ有効化キーブロック （サブ EKB) の合成処理ステップと、 合成 EKB内に含まれる複数のキー ·データの各々を固定長のデ一タフィール ド内に格納するステップと、
を有することを特徴とするプログラム記録媒体にある。 さらに本発明の第 1 1の側面は、
複数のデバイスをリーフとして構成したヅリ一のルートからリーフまでのパス 上のルート、 ノ一ド、およびリーフに各々キーを対応付けたキーヅリーを構成し、 該キーツリーを構成するパスを選択して選択パス上の下位キ一による上位キーの 暗号化処理データを有し、 前記選択パスに対応するノードキーセッ トを利用可能 なデバイスにおいてのみ復号可能とした有効化キーブロック （EKB) をデバイ スに提供する構成を持つ情報処理システムであり、
前記有効化キーブロック （EKB) は、
前記キーヅリ一の部分ヅリーとして設定されるサブヅリ一の各々において復号 処理可能なサブ有効化キープ口ヅク （サブ E KB)の合成 E KBとして構成され、 該合成 E KBは、 格納する各サブ有効化キーブロック （サブ EKB) 内のキー 配列を保持し、 かつ、 各サブ E KBに対応してサブ E KB格納領域のデータ長お よびサブ E K B識別デ一夕を付加した構成を有することを特徴とする情報処理シ ステムにある。
さらに、本発明の情報処理システムの一実施態様において、前記サブヅリ一は、 カテゴリに基づいて区分され、 カテゴリ ·エンティティによって管理されるカテ ゴリツリーであり、 前記サブ有効化キーブロック （サブ EKB) は、 前記カテゴ リ · エンティティにおいて自己の管理するカテゴリツリーに属するノードまたは リーフに対応付けられたキーに基づいて処理可能な EKBとして生成され、 キー 発行センタ一 （KD C) において、 前記カテゴリ 'エンティティの生成したサブ E KBに基づいて、 複数のカテゴリヅリーに共通に使用可能な E KBとしての合 成 E KBを生成する構成であることを特徴とする。
さらに、 本発明の情報処理システムの一実施態様において、 前記サブ有効化キ 一ブロック （サブ EKB) の各々は、 各々独自のアルゴリズム、 独自のキー . デ —夕長を持つサブ有効化キープロヅク （サブ EKB) として構成されていること を特徴とする。
さらに、本発明の情報処理システムの一実施態様において、前記サブヅリーは、 カテゴリに基づいて区分され、 カテゴリ ·エンティティによって管理されるカテ ゴリヅリーであり、 前記サブ有効化キーブロック （サブ EKB) は、 前記カテゴ リ ·エンティティにおいて自己の管理するカテゴリッリーに属するノードまたは リーフに対応付けられたキ一に基づいて処理可能な E KBとして生成され、 前記 合成 E KB内の各サブ E KBに対応して格納される前記サブ E KB識別データは、 カテゴリツリーを構成するノードの識別子であるノード I Dであることを特徴と する。
さらに、 本発明の情報処理システムの一実施態様において、 前記合成 E KBに 格納されるサブ有効化キープロック （サブ EKB) の各々は、 キーヅリーを構成 する各ノードに対応して設定されるノードキーを下位ノードキーまたは下位リ一 フキーを用いて暗号化した暗号化キーデータと、 前記暗号化キーデ一夕各々のノ 一ド位置の下位の左右位置のノードまたはリーフ位置の暗号化キーデータの有無 を示すタグを含む構成であることを特徴とする。
さらに、 本発明の情報処理システムの一実施態様において、 前記合成 E KBに 格納されるサブ有効化キーブロック （サブ EKB) の各々は、 該サブ EKBを復 号可能な末端ノードまたはリ一フを最下段とした簡略化したヅリーを構成するパ スを選択して不要ノードを省略することにより再構築される再構築階層ヅリーの ノードまたはリーフに対応するキーを暗号化キーデータとして有することを特徴 とする。
さらに、 本発明の第 12の側面は、
カテゴリに基づいて区分されたサブヅリーとしてのカテゴリッリーにより構成 され、 複数のデバイスをリーフとして構成したヅリーのルートからリーフまでの パス上のルート、 ノード、 およびリーフに各々キ一を対応付けたキ一ヅリーを構 成し、 該キーツリ一を構成するパスを選択して選択パス上の下位キーによる上位 キーの暗号化処理データを有し、 前記選択パスに対応するノ一ドキ一セッ トを利 用可能なデバイスにおいてのみ復号可能とした有効化キーブロック （EKB) を 格納した情報記録媒体であり、 '
前記キーヅリーの部分ヅリ一として設定されるサブヅリーの各々において復号 処理可能なサブ有効化キ一ブロック （サブ EKB) の合成 E KBを格納し、 該合 成 E KB内に含まれる各サブ E KBに対応してサブ E KB格納領域のデータ長お よびサブ E K B識別データを格納した構成を有することを特徴とする情報記録媒 体にある。
さらに、 本発明の情報記録媒体の一実施態様において、 前記サブ有効化キープ ロック （サブ EKB) の各々は、 各々独自のアルゴリズム、 独自のキー 'デ一夕 長を持つサブ有効化キーブロック （サブ EKB) として構成されていることを特 徴とする。
さらに、 本発明の第 13の側面は、
複数のデバイスをリーフとして構成したッリ一のルートからリーフまでのパス 上のルート、 ノ一ド、およびリーフに各々キーを対応付けたキーツリ一を構成し、 該キーヅリーを構成するパスを選択して選択パス上の下位キ一による上位キーの 暗号化処理データを有し、 前記選択パスに対応するノードキーセッ トを利用可能 なデバイスにおいてのみ復号可能とした有効化キ一プロック （EKB) をデバイ スに提供する構成を持つシステムにおける情報処理方法であり、
前記有効化キーブロック （EKB) は、
前記キーツリ一の部分ヅリーとして設定されるサブッリ一の各々において復号 処理可能なサブ有効化キーブロック （サブ EKB)の合成 E KBとして構成され、 該合成 EKBは、 格納する各サブ有効化キーブロック （サブ EKB) 内のキー 配列を保持し、 かつ、 各サブ E KBに対応してサブ E KB格納領域のデータ長お よびサブ E KB識別データを付加した構成を持つ合成 E KBとしてデバイスに提 供することを特徴とする情報処理方法にある。
さらに、 本発明の情報処理方法の一実施態様において、 前記サブヅリ一は、 力 テゴリに基づいて区分され、 カテゴリ ·エンティティによって管理されるカテゴ リッリ一であり、
前記サブ有効化キーブロック （サブ EKB) は、 前記カテゴリ 'エンティティ において自己の管理するカテゴリヅリーに属するノードまたはリーフに対応付け られたキ一に基づいて処理可能な EKBとして生成され、 キ一発行センター （K D C) において、 前記カテゴリ 'エンティティの生成したサブ E KBに基づいて、 複数のカテゴリヅリーに共通に使用可能な E KBとしての合成 EKBを生成する ことを特徴とする。
さらに、 本発明の情報処理方法の一実施態様において、 前記サブ有効化キープ ロック （サブ EKB) の各々は、 各々独自のアルゴリズム、 独自のキー .データ 長を持つサブ有効化キーブロック （サブ EKB) として構成されることを特徴と する。
さらに、 本発明の情報処理方法の一実施態様において、 前記サブヅリ一は、 力 テゴリに基づいて区分され、 カテゴリ 'エンティティによって管理されるカテゴ リヅリ一であり、前記サブ有効化キープ口ヅク （サブ E K B)は、前記カテゴリ - エンティティにおいて自己の管理するカテゴリッリーに属するノードまたはリ一 フに対応付けられたキーに基づいて処理可能な E KBとして生成され、 前記合成 E KB内の各サブ E KBに対応して格納される前記サブ E KB識別データは、 力 テゴリッリーを構成するノードの識別子であるノード I Dであることを特徴とす る。
さらに、 本発明の情報処理方法の一実施態様において、 前記合成 E KBに格納 されるサブ有効化キ一ブロック （サブ EKB) の各々は、 キ一ヅリーを構成する 各ノードに対応して設定されるノードキーを下位ノードキーまたは下位リ一フキ 一を用いて暗号化した暗号化キ一データと、 前記暗号化キーデータ各々のノード 位置の下位の左右位置のノードまたはリーフ位置の暗号化キーデータの有無を示 すタグを含むことを特徴とする。
さらに、 本発明の情報処理方法の一実施態様において、 前記合成 E KBに格納 されるサブ有効化キーブロック （サブ EKB) の各々は、 該サブ EKBを復号可 能な末端ノードまたはリーフを最下段とした簡略化したッリーを構成するパスを 選択して不要ノードを省略することにより再構築される再構築階層ヅリーのノー ドまたはリーフに対応するキーを暗号化キ一データとして有することを特徴とす る。
さらに、 本発明の第 14の側面は、
複数のデバイスをリーフとして構成したヅリ一のルートからリーフまでのパス 上のルート、 ノード、およびリーフに各々キーを対応付けたキーツリ一を構成し、 該キーヅリーを構成するパスを選択して選択パス上の下位キーによる上位キーの 暗号化処理データを有し、 前記選択パスに対応するノードキ一セッ トを利用可能 なデバイスにおいてのみ復号可能とした有効化キ一ブロック （EKB) をデバイ スに提供する構成を持つシステムにおける有効化キーブロック （E K B ) 生成処 理をコンピュータ · システム上で実行せしめるコンピュータ . プログラムを記録 したプログラム記録媒体であって、 前記コンピュータ · プログラムは、
前記キーツリ一の部分ヅリーとして設定されるサブヅリ一の各々において復号 処理可能なサブ有効化キ一ブロック （サブ E K B ) の選択ステップと、
各選択サブ E K Bに対応してサブ E K B格納領域のデータ長およびサブ E K B 識別データを付加するステップと、
を有することを特徴とするプログラム記録媒体にある。
本発明の構成においては、 ヅリー （木） 構造の階層的構造の暗号化鍵配信構成 を用い、 各機器を n分木の各葉 （リーフ） に配置した構成の鍵配信方法を用い、 記録媒体もしくは通信回線を介して、 例えばコンテンヅデータの暗号鍵であるコ ンテンヅキーも しくは認証処理に用いる認証キー、 あるいはプログラムコード等 を有効化キープ口ックとともに配信する構成としている。
さらに、 有効化キーブロックを暗号化キーデータ部と、 暗号化キーの位置を示 すタグ部てによって構成し、 データ量を少なく し、 デバイスにおける復号処理を 用意かつ迅速に実行することを可能としている。 本構成により、 正当なデバイス のみが復号可能なデータを安全に配信することが可能となる。
さらに、 1以上の選択されたカテゴリヅリ一において復号可能な暗号化鍵デー 夕ブロックである有効化キーブロック （E K B ) を生成して各カテゴリツリーに 属するデバイスに共通に使用可能とするとともに、 どのカテゴリヅリーで処理可 能、 すなわち復号可能であるかを示す E K Bタイプ定義リストを使用することに より、 E K Bの生成管理処理の効率化を可能としている。
なお、 本発明のプログラム記録媒体は、 例えば、 様々なプログラム ·コードを実 行可能な汎用コンピュー夕'システムに対して、 コンビュ一夕 'プログラムをコン ピュー夕可読な形式で提供する媒体である。 媒体は、 C Dや F D、 M Oなどの記 録媒体、 あるいは、 ネッ トワークなどの伝送媒体など、 その形態は特に限定され ない。
このようなプログラム記録媒体は、 コンピュータ · システム上で所定のコンビ ユータ · プ Dグラムの機能を実現するための、 コンピュータ · プログラムと記録 媒体との構造上又は機能上の協働的関係を定義したものである。 換言すれば、 該 記録媒体を介してコンピュータ ' プログラムをコンピュータ ' システムにインス トールすることによって、 コンピュータ ·システム上では協働的作用が発揮され、 本発明の他の側面と同様の作用効果を得ることができるのである。
なお、 本発明の説明中におけるシステムとは、 複数の装置の論理的集合構成で あり、 各構成 ©装置が同一筐体内にあるものには限らない。
本発明のさらに他の目的、 特徴や利点は、 後述する本発明の実施例や添付する 図面に基づくより詳細な説明によって明らかになるであろう。 図面の簡単な説明
図 1は、 本発明の情報処理システムの構成例を説明する図である。
図 2は、 本発明の情報処理システムにおいて適用可能な記録再生装置の構成例 を示すブロック図である。
図 3は、 本発明の情報処理システムにおける各種キ一、 データの暗号化処理に ついて説明するヅリ一構成図である。
図 4は、 本発明の情報処理システムにおける各種キ一、 データの配布に使用さ れる有効化キ一ブロック （EKB) の例を示す図である。
図 5は、 本発明の情報処理システムにおけるコンテンヅキーの有効化キープ口 ック （EKB) を使用した配布例と復号処理例を示す図である。
図 6は、 本発明の情報処理システムにおける有効化キープロヅク （EKB) の フォーマヅト例を示す図である。
図 7は、 本発明の情報処理システムにおける有効化キ一ブロック （EKB) の タグの構成を説明する図である。
図 8は、 本発明の情報処理システムにおける有効化キーブロック （EKB) と、 コンテンツキー、 コンテンヅを併せて配信するデータ構成例を示す図である。 図 9は、 本発明の情報処理システムにおける有効化キーブロック （EKB) と、 コンテンツキ一、 コンテンヅを併せて配信した場合のデバイスでの処理例を示す 図である。
図 1 0は、 本発明の情報処理システムにおける有効化キーブロック （EKB) とコンテンツを記録媒体に格納した場合の対応について説明する図である。 図 1 1は、 本発明の情報処理システムにおける有効化キーブロック （EKB) と、 コンテンヅキーを送付する処理を従来の送付処理と比較した図である。 図 1 2は、 本発明の情報処理システムにおいて適用可能な共通鍵暗号方式によ る認証処理シーケンスを示す図である。
図 13は、 本発明の情報処理システムにおける有効化キーブロック （EKB) と、 認証キーを併せて配信するデータ構成と、 デバイスでの処理例を示す図 （そ の 1 ) である。
図 14は、 本発明の情報処理システムにおける有効化キーブロック （EKB) と、 認証キ一を併せて配信するデ一夕構成と、 デバイスでの処理例を示す図 （そ の 2 ) である。
図 1 5は、 本発明の情報処理システムにおいて適用可能な公開鍵暗号方式によ る認証処理シーケンスを示す図である。
図 1 6は、 本発明の情報処理システムにおいて公開鍵暗号方式による認証処理 を用いて有効化キーブロック （EKB) と、 コンテンヅキーを併せて配信する処 理を示す図である。
図 1 7は、 本発明の情報処理システムにおいて有効化キ一ブロック （EKB) と、 暗号化プログラムデータを併せて配信する処理を示す図である。
図 1 8は、 本発明の情報処理システムにおいて適用可能なコンテンツ . ィンテ グリティ · チェック値 （I CV) の生成に使用する M A C値生成例を示す図であ る。
図 1 9は、 本発明の情報処理システムにおける有効化キーブロック （EKB) と、 I CV生成キーを併せて配信するデータ構成と、 デバイスでの処理例を示す 図 （その 1 ) である。
図 20は、 本発明の情報処理システムにおける有効化キーブロック （EKB) と、 I CV生成キーを併せて配信するデ一夕構成と、 デバイスでの処理例を示す 図 （その 2 ) である。
図 2 1は、 本発明の情報処理システムにおいて適用可能なコンテンツ · ィンテ グリティ . チヱヅク値 （I CV) をメディアに格納した場合のコピー防止機能を 説明する図である。
図 2 2は、 本発明の情報処理システムにおいて適用可能なコンテンヅ · インテ グリティ 'チヱヅク値 （ I C V ) をコンテンヅ格納媒体と別に管理する構成を説 明する図である。
図 2 3は、 本発明の情報処理システムにおける階層ヅリー構造のカテゴリ分類 の例を説明する図である。
図 2 4は、 本発明の情報処理システムにおける簡略化有効化キーブロック （E K B ) の生成過程を説明する図である。
図 2 5は、 本発明の情報処理システムにおける有効化キーブロック （E K B ) の生成過程を説明する図である。
図 2 6は、 本発明の情報処理システムにおける簡略化有効化キーブロック （E K B ) (例 1 ) を説明する図である。
図 2 7は、 本発明の情報処理システムにおける簡略化有効化キープロック （E K B ) (例 2 ) を説明する図である。
図 2 8は、 本発明の情報処理システムにおける階層ヅリー構造のカテゴリッリ 一管理構成について説明する図である。
図 2 9は、 本発明の情報処理システムにおける階層ヅリ一構造のカテゴリッリ 一管理構成の詳細について説明する図である。
図 3 0は、 本発明の情報処理システムにおける階層ヅリ一構造のカテゴリヅリ 一管理構成について説明する図である。
図 3 1は、 本発明の情報処理システムにおける階層ヅリ一構造のカテゴリヅリ 一管理構成でのリザ一プノ一ドについて説明する図である。
図 3 2は、 本発明の情報処理システムにおける階層ヅリー構造のカテゴリッリ 一管理構成での新規カテゴリヅリ一登録処理シ一ケンスについて説明する図であ る。
図 3 3は、 本発明の情報処理システムにおける階層ヅリー構造のカテゴリヅリ —管理構成での新規カテゴリヅリーと上位カテゴリヅリーの関係について説明す る図である。
図 3 4は、 本発明の情報処理システムにおける階層ヅリ一構造のカテゴリヅリ 一管理構成で用いるサブ E K Bについて説明する図である。
図 3 5は、 本発明の情報処理システムにおける階層ヅリー構造のカテゴリヅリ 一管理構成でのデバイスリボーク処理について説明する図である。
図 3 6は、 本発明の情報処理システムにおける階層ツリー構造のカテゴリヅリ 一管理構成でのデバイスリボーク処理シーケンスについて説明する図である。 図 3 7は、 本発明の情報処理システムにおける階層ヅリー構造のカテゴリヅリ 一管理構成でのデバイスリボーク時の更新サブ E K Bについて説明する図である。 図 3 8は、 本発明の情報処理システムにおける階層ヅリー構造のカテゴリヅリ 一管理構成でのカテゴリヅリ一リボーク処理について説明する図である。
図 3 9は、 本発明の情報処理システムにおける階層ヅリー構造のカテゴリヅリ 一管理構成でのカテゴリヅリーリポーク処理シーケンスについて説明する図であ る。 '
図 4 0は、 本発明の情報処理システムにおける階層ヅリ一構造のカテゴリヅリ 一管理構成でのリポークカテゴリツリーと上位カテゴリツリーの関係について説 明する図である。
図 4 1は、 本発明の情報処理システムにおける階層ヅリー構造のカテゴリッリ 一管理構成でのケィパピリティ設定について説明する図である。
図 4 2は、 本発明の情報処理システムにおける階層ヅリー構造のカテゴリッリ 一管理構成でのケィパピリティ設定について説明する図である。
図 4 3は、 本発明の情報処理システムにおけるキー発行センター （K D C ) の 管理するケィパピリティ管理テーブル構成を説明する図である。
図 4 4は、 本発明の情報処理システムにおけるキー発行センター （K D C ) の 管理するケィパピリティ管理テーブルに基づく E K B生成処理フロー図である。 図 4 5は、 本発明の情報処理システムにおける新規カテゴリッリ一登録時のケ ィパピリティ通知処理を説明する図である。
図 4 6は、 本発明の情報処理システムにおけるカテゴリツリーの構成を説明す る図である。
図 4 7は、 本発明の情報処理システムにおける E K Bリクエス夕、 キー発行セ ンター、 トヅプレベル ' カテゴリ ' エンティティ （T L C E ) との関係、 処理例 を説明する図である。
図 48は、 本発明の情報処理システムにおける E KBリクエスタ、 キー発行セ ンター、 トップレベル ' カテゴリ ' エンティティ （T L C E) のハード構成例を 説明する図である。
図 49は、 本発明の情報処理システムにおけるデバイスの保有するデバイスノ ードキー （DNK) について説明する図である。
図 50は、 本発明の情報処理システムにおける E KBタイプ定義リストのデ一 夕構成を説明する図である。
図 5 1は、 本発明の情報処理システムにおける EKBタイプ登録処理フローを 示す図である。
図 52は、 本発明の情報処理システムにおける E KBタイプ無効化処理フロー を示す図である。
図 53は、 本発明の情報処理システムにおけるヅリ一変更通知処理フローを示 す図である。
図 54は、 本発明の情報処理システムにおける E KBタイプリスト要求処理フ ローを示す図である。
図 55は、 本発明の情報処理システムにおけるサブ E KBの生成処理を説明す る図である。
図 56は、 本発明の情報処理システムにおけるサブ EKBの生成処理を説明す る図である。
図 57は、 本発明の情報処理システムにおけるサブ EKBから合成した EKB を生成する処理を説明する図である。
図 58は、 本発明の情報処理システムにおけるリボークデバイスがある場合の サブ E KBの生成処理を説明する図である。
'図 59は、 本発明の情報処理システムにおけるリボークデバイスがある場合の サブ E KBから合成した E KBを生成する処理を説明する図である。
図 60は、 本発明の情報処理システムにおけるサブ E K Bから合成した E KB のデ一夕構成を説明する図である。
図 6 1は、 本発明の情報処理システムにおけるサブ E KBから合成した E KB のデ一夕構成を説明する図である。
図 6 2は、 本発明の情報処理システムにおけるリポ一クデバイスがある場合の サブ E K Bから合成した E K Bのデ一夕構成を説明する図である。
図 6 3は、 本発明の情報処理システムにおけるデ一夕配信型のシステムにおけ るリボーク処理を説明する図である。
図 6 4は、 本発明の情報処理システムにおける自 3記録型のシステムにおける リボーク処理を説明する図である。 発明を実施するための最良の形態
[システム概要]
図 1に本発明の情報処理システムが適用可能なコンテンヅ配信システム例を示 す。 コンテンヅの配信側 1 0は、 コンテンヅ受信側 2 0の有する様々なコンテン ッ再生可能な機器に対してコンテンツ、 あるいはコンテンヅキーを暗号化して送 信する。 受信側 2 0における機器では、 受信した暗号化コンテンヅ、 あるいは暗 号化コンテンヅキー等を復号してコンテンヅあるいはコンテンヅキ一を取得して、 画像データ、 音声データの再生、 あるいは各種プログラムの実行等を行なう。 コ ンテンヅの配信側 1 0とコンテンツ受信側 2 0 との間のデータ交換は、 ィン夕一 ネッ ト等のネッ トワークを介して、 あるいは D V D、 C D等の流通可能な記憶媒 体を介して実行される。
コンテンツ配信側 1 0のデータ配信手段としては、 インターネッ ト 1 1、 衛星 放送 1 2、 電話回線 1 3、 D V D、 C D等のメディア 1 4等があり、 一方、 コン テンヅ受信側 2 0のデバイスとしては、 パーソナルコンピュータ （P C ) 2 1、 ポー夕プルデバィス（ P D ) 2 2、携帯電話、 P D A (Personal Digital Assistants) 等の携帯機器 2 3、 D V D、 C Dプレーヤ等の記録再生器 2 4、 ゲーム端末等の 再生専用器 2 5等がある。 これらコンテンヅ受信側 2 0の各デバイスは、 コンテ ンヅ配信側 1 0から提供されたコンテンツをネッ トワーク等の通信手段あるいは、 あるいはメディア 3 0から取得する。
[デバイス構成]
図 2に、 図 1に示すコンテンツ受信側 2 0のデバイスの一例として、 記録再生 装置 1 0 0の構成プロック図を示す。 記録再生装置 1 0 0は、 入出力 I /F (Interface) 1 20、 M P E G (Moving Picture Experts Group)コーデヅク 1 30、 A/D , D/Aコンバータ 141を備えた入出力 I /F (Interface) 140、暗号 処理手段 1 50、 ROM (Read Only Memory) 1 60、 C P U (Central Processing Unit) 1 70、 メモリ 1 80、 記録媒体 1 9 5のドライブ 1 90を有し、 これらは バス 1 1 0によって相互に接続されている。
入出力 I/F 1 20は、 外部から供給される画像、 音声、 プログラム等の各種 コンテンツを構成するディジタル信号を受信し、 バス 1 1 0上に出力するととも に、 バス 1 1 0上のディジタル信号を受信し、 外部に出力する。 MP E Gコーデ ック 1 30は、 パス 1 1 0を介して供給される MP E G符号化されたデータを、 MPEGデコードし、 入出力 I /F 140に出力するとともに、 入出力 I/F 1 40から供給されるディジ夕ル信号を MP E Gエンコードしてバス 1 1 0上に出 力する。 入出力 I/F 140は、 AZD， D/Aコンバータ 14 1を内蔵してい る。 入出力 I /F 140は、 外部から供給されるコンテンツとしてのアナログ信 号を受信し、 AZD, D/Aコンバータ 141で AZD (Analog Digital)変換す ることで、 ディジタル信号として、 MPEGコーデヅク 1 30に出力するととも に、 MPEGコ一デック 1 30からのディジ夕ル信号を、 A/D， D/Aコンパ —夕 1 41で D/A(Digital Analog)変換することで、 アナログ信号として、 外 部に出力する。
暗号処理手段 1 5 0は、 例えば、 1チップの L S I (Large Scale Integrated Curcuit)で構成され、 バス 1 1 0を介して供給されるコンテンツとしてのディジ タル信号の暗号化、 復号処理、 あるいは認証処理を実行し、 暗号データ、 復号デ 一夕等をバス 1 1 0上に出力する構成を持つ。 なお、 暗号処理手段 1 50は 1チ ヅプ L S Iに限らず、 各種のソフ トウエアまたはハードウエアを組み合わせた構 成によって実現することも可能である。 ソフ トゥヱァ構成による処理手段として の構成については後段で説明する。
ROM 1 60は、 記録再生装置によって処理されるプログラムデ一夕を格納す る。 CPU 1 7 0は、 ROM 1 60、 メモリ 1 80に記憶されたプログラムを実 行することで、 MP E Gコーデック 1 30や暗号処理手段 1 50等を制御する。 メモリ 18 0は、 例えば、 不揮発性メモリで、 CPU 1 70が実行するプログラ ムゃ、 C P U 1 70の動作上必要なデータ、 さらにデバイスによって実行される 暗号処理に使用されるキーセッ トを記憶する。 キ一セッ トについては後段で説明 する。 ドライブ 1 90は、 デジタルデ一タを記録再生可能な記録媒体 1 95を駆 動することにより、記録媒体 1 95からディジタルデータを読み出し（再生し）、 バス 1 1 0上に出力するとともに、 バス 1 1 0を介して供給されるディジタルデ —夕を、 記録媒体 1 95に供給して記録させる。
記録媒体 1 9 5は、 例えば、 DVD、 CD等の光ディスク、 光磁気ディスク、 磁気ディスク、 磁気テープ、 あるいは RAM等の半導体メモリ等のディジタルデ —夕の記憶可能な媒体であり、 本実施の形態では、 ドライブ 1 9 0に対して着脱 可能な構成であるとする。 但し、 記録媒体 1 9 5は、 記録再生装置 10 0に内蔵 する構成としてもよい。
なお、 図 2に示す暗号処理手段 1 5 0は、 1つのワンチップ L S Iとして構成 じてもよく、 また、 ソフ トウェア、 ハードウヱァを組み合わせた構成によって実 現する構成としてもよい。
[キー配信構成としてのツリー （木） 構造について]
次に、 図 1に示すコンテンツ配信側 1 0からコンテンヅ受信側 20の各デバイ スに暗号データを配信する場合における各デバイスにおける暗号処理鍵の保有構 成およびデータ配信構成を図 3を用いて説明する。
図 3の最下段に示すナンパ 0〜 1 5がコンテンヅ受信側 20の個々のデバイス である。 すなわち図 3に示す階層ッリ一 （木） 構造の各葉（リーフ ： leaf)がそれ それのデバイスに相当する。
各デバイス 0~ 1 5は、 製造時あるいは出荷時、 あるいはその後において、 図 3に示す階層ツリー （木） 構造における、 自分のリーフからルートに至るまでの ノードに割り当てられた鍵 （ノードキー） および各リーフのリーフキーからなる キーセヅ トをメモリに格納する。 図 3の最下段に示す K 0 000〜K 1 1 1 1が 各デバイス 0〜 1 5にそれそれ割り当てられたリーフキーであり、 最上段の KR (ルートキ一） から、 最下段から 2番目の節 （ノード） に記載されたキー ： KR 〜Κ 1 1 1をノードキーとする。 図 3に示すッリ一構成において、例えばデバイス 0はリーフキー K 0000と、 ノードキー ： K 000、 K 0 0、 K 0、 KRを所有する。 デバイス 5は K 0 1 0 1、 K 01 0、 K 0 1、 K 0、 KRを所有する。 デバイス 1 5は、 K 1 1 1 1、 K i l l, K l l、 K l、 KRを所有する。 なお、 図 3のツリーにはデバイスが 0~ 1 5の 1 6個のみ記載され、 ッリ一構造も 4段構成の均衡のとれた左右対称 構成として示しているが、 さらに多くのデパイスがヅリ一中に構成され、 また、 ッリ の各部において異なる段数構成を持つことが可能である。
また、 図 3のヅリ一構造に含まれる各デバイスには、 様々な記録媒体、 例えば、 デバイス埋め込み型あるいはデバイスに着脱自在に構成された DVD、 CD、 M D、 フラッシュメモリ等を使用する様々なタイプのデバイスが含まれている。 さ らに、 様々なアプリケーションサービスが共存可能である。 このような異なるデ バイス、 異なるアプリケーションの共存構成の上に図 3に示すコンテンツあるい は鍵配布構成である階層ッリー構造が適用される。
これらの様々なデバイス、 アプリケーションが共存するシステムにおいて、 例 えば図 3の点線で囲んだ部分、 すなわちデバイス 0 , 1， 2 , 3を同一の記録媒 体を用いる 1つのグループとして設定する。 例えば、 この点線で囲んだグループ 内に含まれるデバイスに対しては、 まとめて、 共通のコンテンヅを暗号化してブ ロバイダから送付したり、 各デバイス共通に使用するコンテンヅキーを送付した り、 あるいは各デバイスからプロバイダあるいは決済機関等にコンテンツ料金の 支払データをやはり暗号化して出力するといつた処理が実行される。 コンテンツ プロバイダ、 あるいは決済処理機関等、 各デバイスとのデータ送受信を行なう機 関は、 図 3の点線で囲んだ部分、 すなわちデバイス 0， 1， 2, 3を 1つのグル ープとして一括してデータを送付する処理を実行する。 このようなグループは、 図 3のヅリー中に複数存在する。 コンテンヅプロバイダ、 あるいは決済処理機関 等、 各デバイスとのデータ送受信を行なう機関は、 メッセージデータ配信手段と して機能する。 .
なお、 ノードキー、 リーフキーは、 ある 1つの鍵管理セン夕によって統括して 管理してもよいし、各グループに対する様々なデータ送受信を行なうプロパイダ、 決済機関等のメッセージデータ配信手段によってグループごとに管理する構成と してもよい。 これらのノードキー、 リーフキーは例えばキーの漏洩等の場合に更 新処理が実行され、 この更新処理は鍵管理セン夕、 プロバイダ、 決済機関等が実 行する。
このヅリー構造において、 図 3から明らかなように、 1つのグループに含まれ る 3つのデバイス 0 , 1 , 2， 3はノードキーとして共通のキ一K 00、 K 0、 KRを保有する。 このノードキー共有構成を利用することにより、 例えば共通の コンテンヅキ一をデバイス 0， 1， 2 , 3のみに提供することが可能となる。 た とえば、 共通に保有するノードキー Κ 00自体をコンテンツキーとして設定すれ ば、 新たな鍵送付を実行することなくデバイス 0， 1， 2， 3のみが共通のコン テンヅキーの設定が可能である。 また、 新たなコンテンヅキ一K c 0 ηをノード キ一 Κ 00で暗号化した値 E n c (Κ 00 , K c o n) を、 ネッ トワークを介し てあるいは記録媒体に格納してデバイス 0， 1， 2, 3に配布すれば、 デバイス
0. 1， 2， 3のみが、 それぞれのデバイスにおいて保有する共有ノードキ一K 00を用いて暗号 Enc (K 0 0 , K c o n) を解いてコンテンヅキー ： K c o nを得ることが可能となる。 なお、 E nc (K a, Kb) は Kbを Kaによって 暗号化したデータであることを示す。
また、 ある時点 tにおいて、 デバイス 3の所有する鍵： Κ Ο Ο Ι Ι,Κ Ο Ο Ι ,
Κ 0 0，Κ 0，KRが攻撃者 （ハヅカー） により解析されて露呈したことが発覚し た場合、 それ以降、 システム （デバイス 0, 1， 2, 3のグループ） で送受信さ れるデ一夕を守るために、 デバイス 3をシステムから切り離す必要がある。 その ためには、 ノードキー： K 00 1 ,Κ 00，K 0，KRをそれそれ新たな鍵 Κ ( t )
00 1 , K ( t ) 0 0, K (ΐ ) Ο,Κ ( t ) Rに更新し、 デバイス 0 , 1 , 2にそ の更新キーを伝える必要がある。 ここで、 K (t) a a aは、 鍵 K a a aの世代
(Generation)： tの更新キーであることを示す。
更新キーの配布処理ついて説明する。 キーの更新は、 例えば、 図 4 (A) に示 す有効化キーブロック （E KB： Enabling Key Block) と呼ばれるブロックデ一 夕によって構成されるテーブルをたとえばネッ トワーク、 あるいは記録媒体に格 納してデバイス 0, 1， 2に供給することによって実行される。 なお、 有効化キ 一ブロック （EKB) は、 図 3に示すようなヅリー構造を構成する各リーフに対 応するデバイスに新たに更新されたキーを配布するための暗号化キ一によって構 成される。 有効化キーブロック （EKB) は、 キー更新ブロック （KRB： Key Renewal Block) と呼ばれることもある。
図 4 (A) に示す有効化キーブロック （EKB) には、 ノードキーの更新の必 要なデバイスのみが更新可能なデータ構成を持つプロックデータとして構成され る。 図 4の例は、 図 3に示すヅリー構造中のデバイス 0 , 1， 2において、 世代 tの更新ノードキーを配布することを目的として形成されたプロックデ一夕であ る。 図 3から明らかなように、 デバイス 0， デバイス 1は、 更新ノードキーとし て ( t ) 0 0、 K (t ) 0、 K ( t ) Rが必要であり、 デバイス 2は、 更新ノ —ドキーとして K ( t ) 0 0 1、 K ( t ) 0 0、 K ( t ) 0、 K ( t ) Rが必要 である。
図 4 (A)の EKBに示されるように EKBには複数の暗号化キーが含まれる。 最下段の暗号化キ一は、 E n c (K 0 0 1 0 , K ( t ) 0 0 1) である。 これは デバイス 2の持つリーフキー K 00 1 0によって暗号化された更新ノードキー K ( t ) 00 1であり、 デバイス 2は、 自身の持つリーフキーによってこの暗号化 キーを復号し、 K ( t ) 0 0 1を得ることができる。 また、復号により得た K ( t ) 00 1を用いて、 図 4 (A) の下から 2段目の暗号化キー E n c (K (t ) 0 0 1， K (t ) 0 0) を復号可能となり、 更新ノードキ一 K ( t ) 00を得ること ができる。 以下順次、 図 4 (A) の上から 2段目の暗号化キー E n c (K ( t ) 00 , K (t ) 0) を復号し、 更新ノードキ一K ( t ) 0、 図 4 (A) の上から 1段巨の暗号化キー E nc (K (t) 0 , Κ (ΐ ) R) を復号し Κ (t ) Rを得 る。 一方、 デバイス K 00 00. K 0 00 1は、 ノードキー K O O 0は更新する 対象に含まれておらず、更新ノードキーとして必要なのは、 K (t ) 00、 K ( t ) 0、 K ( t ) Rである。 デバイス 0 000. K 0 00 1は、 図 4 (Α) の上か ら 3段目の暗号化キー E n c (K 00 0, K ( t ) 0 0) を復号し K ( t ) 00、 を取得し、 以下、 図 4 (A) の上から 2段目の暗号化キー E n c (K (t) 00 , K ( t ) 0) を復号し、 更新ノードキー K ( t ) 0、 図 4 (A) の上から 1段目 の暗号化キー E nc (K ( ΐ ) 0， Κ ( t ) R) を復号し K ( t ) Rを得る。 こ のようにして、 デバイス 0， 1 , 2は更新した鍵 K ( t ) Rを得ることができる。 なお、 図 4 (A) のインデックスは、 復号キーとして使用するノードキー、 リー フキーの絶対番地を示す。
図 3に示すッリ一構造の上位段のノードキー： K ( t ) 0 ,Κ (ΐ ) Rの更新が 不要であり、 ノードキー K 0 0のみの更新処理が必要である場合には、 図 4 (B) の有効化キ一ブロック （EKB) を用いることで、 更新ノードキー K ( t ) 0 0 をデバイス 0 , 1， 2に配布することができる。
図 4 (B) に示す E KBは、 例えば特定のグループにおいて共有する新たなコ ンテンツキ一を配布する場合に利用可能である。 具体例として、 図 3に点線で示 すグループ内のデバイス 0 , 1 , 2， 3がある記録媒体を用いており、 新たな共 通のコンテンツキー K ( t ) c o nが必要であるとする。 このとき、 デバイス 0 , 1 , 2 , 3の共通のノ一ドキ一 K 00を更新した K ( t ) 00を用いて新たな共 通の更新コンテンツキー： K ( t ) c o nを暗号化したデータ E n c (K ( t ), Κ ( t ) c o n) を図 4 (B) に示す E KBとともに配布する。 この配布により、 デパイス 4など、 その他のグループの機器においては復号されないデ一夕として の配布が可能となる。
すなわち、 デバイス 0， 1， 2は E KBを処理して得た K ( t ) 00を用いて 上記暗号文を復号すれば、 t時点でのコンテンツキー K ( t ) c o nを得ること が可能になる。
[E KBを使用したコンテンヅキーの配布]
図 5に、 t時点でのコンテンツキー K ( t ) c o nを得る処理例として、 K ( t ) 00を用いて新たな共通のコンテンツキー K ( t ) c o nを暗号化したデ一夕 E n c (K (t ) 00， K ( t ) c o n) と図 4 (B) に示す EKBとを記録媒体 を介して受領したデバイス 0の処理を示す。 すなわち EKBによる暗号化メッセ ージデータをコンテンツキー K ( t ) c o nとした例である。
図 5に示すように、 デバイス 0は、 記録媒体に格納されている世代： t 時点の E KBと自分があらかじめ格納しているノードキ一 K 00 0を用いて上述したと 同様の EKB処理により、 ノードキー K ( t ) 00を生成する。 さらに、 復号し た更新ノードキ一K ( t ) 0 0を用いて更新コンテンヅキー K (t ) c o nを復 号して、 後にそれを使用するために自分だけが持つリーフキー K 0000で暗号 化して格納する。
[E K Bのフォーマッ ト ]
図 6に有効化キープ口ヅク （EKB) のフォーマッ ト例を示す。 パージヨン 6 0 1は、 有効化キーブロック （EKB) のバージョンを示す識別子である。 なお、 バージョンは最新の E KBを識別する機能とコンテンツとの対応関係を示す機能 を持つ。 デプスは、 有効化キープロヅク （EKB) の配布先のデバイスに対する 階層ヅリ一の階層数を示す。 データポインタ 6 03は、 有効化キーブロック （E KB) 中のデータ部の位置を示すポインタであり、 夕グポイン夕 604はタグ部 の位置、 署名ポィン夕 60 5は署名の位置を示すポィン夕である。
データ部 6 0 6は、例えば更新するノードキーを暗号化したデータを格納する。 例えば図 5に示すような更新されたノードキーに関する各暗号化キー等を格納す る。
タグ部 6 0 7は、 データ部に格納された暗号化されたノードキー、 リーフキー の位置関係を示すタグである。 このタグの付与ルールを図 7を用いて説明する。 図 7では、 データとして先に図 4 (A) で説明した有効化キープロック （E KB) を送付する例を示している。 この時のデータは、 図 7の表 （b) に示すようにな る。 このときの暗号化キーに含まれる トヅプノードのアドレスをトツプノ一ドア ドレスとする。 この場合は、 ルートキーの更新キー K ( t ) Rが含まれているの で、 ト ヅプノードアドレスは KRとなる。 このとき、 例えば最上段のデータ E n c (K (t) 0 , K ( t ) R) は、 図 7の （a) に示す階層ヅリーに示す位置に ある。 ここで、 次のデータは、 E n c (K ( t ) 00， K ( t ) 0 ) であり、 ヅ リー上では前のデータの左下の位置にある。 データがある場合は、 タグが 0、 な い場合は 1が設定される。 タグは {左 （L) タグ， 右 （R) タグ } として設定さ れる。 最上段のデータ E n c (K (t ) 0 , K (t ) R) の左にはデータがある ので、 Lタグ = 0、 右にはデ一夕がないので、 Rタグ = 1となる。 以下、 すべて のデータにタグが設定され、 図 7 (c) に示すデータ列、 および夕グ列が構成さ れる。
タグは、 データ E n c (Kxxx, K y y y ) がツリー構造のどこに位置して いるのかを示すために設定されるものである。 データ部に格納されるキーデータ E n c (Kxxx, K y y y)... は、 単純に暗号化されたキーの羅列データに過 きないので、 上述したタグによってデ一夕として格納された暗号化キーのヅリ一 上の位置を判別可能としたものである。 上述したタグを用いずに、 先の図 4で説 明した構成のように暗号化データに対応させたノード · ィンデックスを用いて、 例えば、
0 ： En c (K (t) 0 , K (t) r o o t)
00 ： E n c (K ( t ) 00 , K ( t ) 0)
000 : E n c (K (( t ) 0 00 , K ( T) 0 0)
... のようなデータ構成とすることも可能であるが、 このようなインデックス を用いた構成とすると冗長なデータとなりデータ量が増大し、 ネッ トワークを介 する配信等においては好ましくない。 これに対し、 上述したタグをキー位置を示 す索引データとして用いることにより、 少ないデータ量でキ一位置の判別が可能 となる。
図 6に戻って、 E K Bフォーマツ トについてさらに説明する。署名（Signature) は、 有効化キーブロック （EKB) を発行した例えば鍵管理センタ、 コンテンツ ロバイダ、 決済機関等が実行する電子署名である。 EKBを受領したデバイスは 署名検証によって正当な有効化キーブロック （EKB) 発行者が発行した有効化 キーブロック （EKB) であることを確認する。
[E KBを使用したコンテンヅキーおよびコンテンヅの配信]
上述の例では、 コンテンツキーのみを E KBとともに送付する例について説明 したが、 コンテンツキーで暗号化したコンテンツと、 コンテンツキ一暗号キーで 暗号化したコンテンツキーと、 EKBによって暗号化したコンテンヅキー暗号鍵 を併せて送付する構成について以下説明する。
図 8にこのデータ構成を示す。 図 8 (a) に示す構成において、 E n c (K c o n, c o nt e nt) 8 0 1は、 コンテンッ （Content) をコンテンツキ一 （K c o n) で暗号化したデータであり、 Enc (KEK, K c o n) 802は、 コ ンテンヅキ一（K c o n)をコンテンツキー暗号キ一（K E K :Key Encryption Key) で暗号化したデータであり、 E n c (EKB, KEK) 8 03は、 コンテンヅキ 一暗号キー KEKを有効化キーブロック （EKB) によって暗号化したデ一夕で あることを示す。
ここで、 コンテンツキー暗号キー K E Kは、 図 3で示すノードキー（K 000， K 0 0···)、あるいはルートキ一（KR)自体であってもよく、 またノードキー（K 00 0 , K 0 0 ···)、 あるいはル一トキ一 （KR) によって暗号化されたキーであ つてもよい。
図 8 (b) は、 複数のコンテンツがメディアに記録され、 それそれが同じ E n c (EKB, KEK) 80 5を利用している場合の構成例を示す、 このような構 成においては、 各データに同じ E n c (EKB, KEK) を付加することなく、 En c (EKB, KEK) にリンクするリンク先を示すデータを各データに付加 する構成とすることができる。
図 9にコンテンヅキー暗号キー KE Kを、 図 3に示すノードキ一K 0 0を更新 した更新ノードキー K ( t ) 0 0として構成した場合の例を示す。 この場合、 図 3の点線枠で囲んだグループにおいてデバイス 3が、 例えば鍵の漏洩により リボ —ク （排除） されているとして、 他のグループのメンバ、 すなわち、 デバイス 0 , 1 , 2に対して図 9に示す （a) 有効化キーブロック （EKB) と、 （b) コンテ ンヅキ一 （K c o n) をコンテンツキー暗号キー （ΚΕΚ = Κ ( ΐ ) 0 0) で暗 号化したデータと、 （c) コンテンツ （content) をコンテンツキー （K c o n) で暗号化したデータとを配信することにより、 デバイス 0 , 1 , 2はコンテンツ を得ることができる。
図 9の右側には、 デバイス 0における復号手順を示してある。 デバイス 0は、 まず、 受領した有効化キープ口ックから自身の保有するリーフキー K 0 00を用 いた復号処理により、 コンテンヅキー暗号キー （KEK = K ( t ) 00) を取得 する。 次に、 K ( t ) 0 0による復号によりコンテンツキー K c o nを取得し、 さらにコンテンヅキー K c o nによりコンテンツの復号を行なう。 これらの処理 により、 デバイス 0はコンテンヅを利用可能となる。 デバイス 1 , 2においても 各々異なる処理手順で E K Bを処理することにより、コンテンツキー暗号キー（K EK = K ( t ) 0 0) を取得することが可能となり、 同様にコンテンツを利用す ることが可能となる。
図 3に示す他のグループのデバイス 4 , 5 , 6···は、 この同様のデータ （EK B) を受信したとしても、 自身の保有するリーフキー、 ノードキーを用いてコン テンヅキー暗号キー （KEK = K (t) 00) を取得することができない。 同様 にリボークされたデバイス 3においても、 自身の保有するリーフキー、 ノードキ —では、 コンテンヅキ一暗号キ一 （KEK = K (t) 00) を取得することがで きず、 正当な権利を有するデバイスのみがコンテンツを復号して利用することが 可能となる。
このように、 E KBを利用したコンテンヅキーの配送を用いれば、 デ一夕量を 少なく して、 かつ安全に正当権利者のみが復号可能とした暗号化コンテンヅを配 信することが可能となる。
なお、 有効化キ一ブロック （EKB)、 コンテンツキー、 暗号化コンテンヅ等は、 ネッ トワークを介して安全に配信することが可能な構成であるが、 有効化キープ ロック （EKB)、 コンテンヅキー、 暗号化コンテンツを D VD、 CD等の記録媒 体に格納してユーザに提供することも可能である。 この場合、 記録媒体に格納さ れた暗号化コンテンヅの復号には、 同一の記録媒体に格納された有効化キープ口 ヅク （EKB) の復号により得られるコンテンヅキーを使用するように構成すれ ば、 予め正当権利者のみが保有するリーフキー、 ノードキーによってのみ利用可 能な暗号化コンテンツの配布処理、 すなわち利用可能なユーザデバイスを限定し たコンテンツ配布が簡易な構成で実現可能となる。
図 1 0に記録媒体に暗号化コンテンツとともに有効化キーブロック （EKB) を格納した構成例を示す。 図 1 0に示す例においては、 記録媒体にコンテンツ C 1〜 C 4が格納され、 さらに各格納コンテンッに対応するの有効化キープ口ヅク (EKB) を対応付けたデータが格納され、 さらにバージョン Mの有効化キープ ロック （E KB— M) が格納されている。 例えば E KB— 1はコンテンヅ C 1を 暗号化したコンテンツキー K c o n 1を生成するのに使用され、 例えば E KB— 2はコンテンツ C 2を暗号化したコンテンツキ一 K c o n 2を生成するのに使用 される。 この例では、 バ一ジョン Mの有効化キ一ブロック （EKB— M) が記録 媒体に格納されており、 コンテンツ C 3 , C 4は有効化キ一ブロック （EKB— M) に対応付けられているので、 有効化キーブロック （EKB— M) の復号によ りコンテンツ C 3 , C 4のコンテンツキーを取得することができる。 E K B 1、 E KB— 2はディスクに格納されていないので、 新たな提供手段、 例えばネッ ト ワーク配信、 あるいは記録媒体による配信によってそれぞれのコンテンツキーを 復号するために必要な EKB— 1 , EKB— 2を取得することが必要となる。 図 1 1に、 複数のデバイス間でコンテンツキーが流通する場合の E KBを利用 したコンテンツキーの配信と、 従来のコンテンヅキー配信処理の比較例を示す。 上段 （a) が従来構成であり、 下段 （b) が本発明の有効化キーブロック （EK B) を利用した例である。 なお、 図 1 1において Ka (Kb) は、 Kbを Kaで 暗号化したデータであることを示す。
(a) に示すように、 従来は、 データ送受信者の正当性を確認し、 またデ一夕 送信の暗号化処理に使用するセッションキー K s e sを共有するために各デバイ ス間において、 認証処理および鍵交換処理 （AKE ： Authentication and Key Exchange) を実行し、 認証が成立したことを条件としてセッションキ一K s e s でコンテンヅキー K c ο ηを暗号化して送信する処理を行なっていた。
例えば図 1 1 (a) の P Cにおいては、 受信したセッションキーで暗号化した コンテンツキー K s e s (K c o n) をセッションキーで復号して K c o nを得 ることが可能であり、 さらに取得した K c o nを P C自体の保有する保存キー K s t rで暗号化して自身のメモリに保存することが可能となる。
図 1 1 (a) において、 コンテンツプロバイダは、 図 1 1 (a) の記録デバィ ス 1 1 0 1にのみデータを利用可能な形で配信したい場合でも、 間に P C、 再生 装置が存在する場合は、 図 1 1 (a) に示すように認証処理を実行し、 それそれ のセヅションキーでコンテンツキーを暗号化して配信するといった処理が必要と なる。 また、 間に介在する P C、 再生装置においても認証処理において生成し共 有することになつたセッションキーを用いることで暗号化コンテンツキ一を復号 してコンテンヅキーを取得可能となる。
—方、 図 1 1 (b) の下段に示す有効化キーブロック （EKB) を利用した例 においては、 コンテンツプロバイダから有効化キーブロック （EKB) と、 有効 化キ一ブロック （EKB) の処理によって得られるノードキー、 またはルートキ —によってコンテンヅキ一 K c o nを暗号化したデータ （図の例では K r o o t (K c o n))を配信することにより、配信した E KBの処理が可能な機器におい てのみコンテンヅキ一K c o nを復号して取得することが可能になる。
従って、 例えば図 1 1 (b) の右端にのみ利用可能な有効化キ一ブロック （E KB) を生成して、 その有効化キーブロック （EKB) と、 その EKB処理によ つて得られるノ一ドキ一、 またはルートキ一によってコンテンツキ一 K c o nを 暗号化したデータを併せて送ることにより、 間に存在する P C、 再生機器等は、 自身の有するリーフキ一、 ノードキーによっては、 EKBの処理を実行すること ができない。 従って、 データ送受信デバイス間での認証処理、 セッションキーの 生成、 セッションキ一によるコンテンツキー K c o nの暗号化処理といった処理 を実行することなく、 安全に正当なデバイスに対してのみ利用可能なコンテンツ キーを配信することが可能となる。
P C、 記録再生器にも利用可能なコンテンツキーを配信したい場合は、 それそ れにおいて処理可能な有効化キーブロック （EKB) を生成して、 配信すること により、 共通のコンテンヅキーを取得することが可能となる。
[有効化キーブロック .（EKB) を使用した認証キーの配信 （共通鍵方式）] 上述の有効化キーブロック （EKB) を使用したデータあるいはキーの配信に おいて、 デバイス間で転送される有効化キーブロック （EKB) およびコンテン ヅあるいはコンテンツキーは常に同じ暗号化形態を維持しているため、 データ伝 走路を盗み出して記録し、 再度、 後で転送する、 いわゆるリプレイアタックによ り、 不正コピーが生成される可能性がある。 これを防く、構成としては、 デ一夕転 送デバイス間において、 従来と同様の認証処理および鍵交換処理を実行すること が有効な手段である。 ここでは、 この認証処理および鍵交換処理を実行する際に 使用する認証キー K a k eを上述の有効化キーブロック （EKB) を使用してデ バイスに配信することにより、 安全な秘密鍵として共有する認証キ一を持ち、 共 通鍵方式に従った認証処理を実行する構成について説明する。 すなわち E KBに よる暗号化メッセージデータを認証キーとした例である。
図 1 2に、 共通鍵暗号方式を用いた相互認証方法 （IS0/IEC 9798-2) を示す。 図 1 2においては、 共通鍵暗号方式として D E Sを用いているが、 共通鍵暗号方 式であれば他の方式も可能である。 図 1 2において、 まず、 Bが 64ビッ トの乱 数 Rbを生成し、 Rbおよび自己の I Dである I D (b) を Aに送信する。 これ を受信した Aは、 新たに 6 4ビヅ トの乱数 R aを生成し、 R a、 R b、 I D (b ) の順に、 D E Sの C B Cモードで鍵 K a bを用いてデ一夕を暗号化し、 Bに返送 する。 なお、 鍵 K a bは、 Aおよび Bに共通の秘密鍵としてそれそれの記録素子 内に格納する鍵である。 D E Sの C B Cモードを用いた鍵 K a bによる暗号化処 理は、例えば D E Sを用いた処理においては、初期値と R aとを排他的論理和し、 D E S暗号化部において、 鍵 K a bを用いて暗号化し、 暗号文 E 1を生成し、 続 けて暗号文 E 1 と R bとを排他的論理和し、 D E S暗号化部において、 鍵 K a b を用いて暗号化し、 暗号文 E 2を生成し、 さらに、 暗号文 E 2と I D (b) とを 排他的論理和し、 D E S暗号化部において、 鍵 K a bを用いて暗号化して生成し た暗号文 E 3 とによって送信データ （Token-AB) を生成する。
これを受信した Bは、 受信データを、 やはり共通の秘密鍵としてそれぞれの記 録素子内に格納する鍵 K a b (認証キー） で復号化する。 受信データの復号化方 法は、 まず、 暗号文 E 1を認証キー K a bで復号化し、 乱数 R aを得る。 次に、 暗号文 E 2を認証キー K a bで復号化し、 その結果と E 1を排他的論理和し、 R bを得る。 最後に、 暗号文 E 3を認証キー K a bで復号化し、 その結果と E 2を 排他的論理和し、 I D (b )を得る。 こう して得られた R a、 R bit I D (b )のう ち、 R bおよび I D (b )が、 Bが送信したものと一致するか検証する。 この検証 に通った場合、 Bは Aを正当なものとして認証する。
次に Bは、 認証後に使用するセッションキー （K s e s ) を生成する （生成方 法は、 乱数を用いる）。 そして、 R b、 R a、 K s e sの順に、 D E Sの C B Cモ 一ドで認証キー K a bを用いて暗号化し、 Aに返送する。
これを受信した Aは、 受信データを認証キー K a bで復号化する。 受信データ の復号化方法は、 Bの復号化処理と同様であるので、 ここでは詳細を省略する。 こうして得られた R b、 R a、 K s e sの内、 R bおよび R aが、 Aが送信した ものと一致するか検証する。 この検証に通った場合、 Aは Bを正当なものとして 認証する。 互いに相手を認証した後には、 セッションキー K s e sは、 認証後の 秘密通信のための共通鍵として利用される。
なお、 受信データの検証の際に、 不正、 不一致が見つかった場合には、 相互認 証が失敗したものとして処理を中断する。 上述の認証処理においては、 A， Bは共通の認証キー Kabを共有する。 この 共通鍵 K a bを上述の有効化キ一ブロック （EKB) を使用してデバイスに配信 する。
例えば、 図 1 2の例では、 A, または Bのいずれかが他方が復号可能な有効化 キーブロック （EKB) を生成して生成した有効化キーブロック （EKB) によ つて認証キー Kabを暗号化して、 他方に送信する構成としてもよいし、 あるい は第 3者がデパイス A， Bに対して双方が利用可能な有効化キーブロック （EK B) を生成してデバイス A， Bに対して生成した有効化キーブロック （EKB) によって認証キー K a bを暗号化して配信する構成としてもよい。
図 1 3および図 14に複数のデバイスに共通の認証キー K a k eを有効化キ一 ブロック （EKB) によって配信する構成例を示す。 図 1 3はデバイス 0 , 1， 2, 3に対して復号可能な認証キー K ak eを配信する例、 図 14はデバイス 0， 1， 2 , 3中のデバイス 3をリボ一ク （排除） してデバイス 0， 1， 2に対して のみ復号可能な認証キーを配信する例を示す。
図 1 3の例では、 更新ノードキ一 K ( t ) 0 0によって、 認証キ一 Kakeを 暗号化したデータ （b) とともに、 デバイス 0 , 1， 2 , 3においてそれぞれの 有するノードキー、 リーフキーを用いて更新されたノードキー K ( t ) 00を復 号可能な有効化キーブロック （EKB) を生成して配信する。 それぞれのデバイ スは、 図 1 3の右側に示すようにまず、 EKBを処理 （復号） することにより、 更新されたノードキー K (t) 00を取得し、 次に、 取得したノードキー K ( t ) 00を用いて暗号化された認証キー ： En c (K ( t ) 0 0， Kake) を復号 して認証キ一 K a k eを得ることが可能となる。
その他のデバイス 4, 5 , 6 , 7…は同一の有効化キ一ブロック （EKB) を 受信しても自身の保有するノードキー、 リーフキーでは、 EKBを処理して更新 されたノードキー K ( t ) 00を取得することができないので、 安全に正当なデ バイスに対してのみ認証キーを送付することができる。
一方、 図 14の例は、 図 3の点線枠で囲んだグループにおいてデバイス 3が、 例えば鍵の漏洩により リポーク （排除） されているとして、 他のグループのメン バ、 すなわち、 デバイス 0， 1 , 2, に対してのみ復号可能な有効化キープロヅ ク （EKB) を生成して配信した例である。 図 14に示す （a) 有効化キープ口 ック （EKB) と、 （b) 認証キー （Kak e) をノードキー （K ( ) 0 0) で 暗号化したデータを配信する。
図 14の右側には、 復号手順を示してある。 デバイス 0， 1 , 2は、 まず、 受 領した有効化キープ口ックから自身の保有するリーフキーまたはノ一ドキーを用 いた復号処理により、 更新ノードキー （K (t ) 00)を取得する。次に、 K (t) 00による復号により認証キー Kakeを取得する。
図 3に示す他のグループのデバイス 4 , 5， 6…は、 この同様のデータ （EK B) を受信したとしても、 自身の保有するリーフキー、 ノードキーを用いて更新 ノードキー （K ( t ) 00) を取得することができない。 同様にリボークされた デバイス 3においても、 自身の保有するリーフキ一、 ノードキーでは、 更新ノ一 ドキー （K ( t ) 0 0) を取得することができず、 正当な権利を有するデパイス のみが認証キーを復号して利用することが可能となる。
このように、 E KBを利用した認証キーの配送を用いれば、 データ量を少なく して、 かつ安全に正当権利者のみが復号可能とした認証キーを配信することが可 能となる。
[公開鍵認証と有効化キ一ブロック （EKB) を使用したコンテンツキーの 配信]
次に、 公開鍵認証と有効化キーブロック （EKB) を使用したコンテンツキー の配信処理について説明する。 まず、 公開鍵暗号方式である 1 6 0ビヅ ト長の楕 円曲線暗号を用いた相互認証方法を、 図 1 5を用いて説明する。図 1 5において、 公開鍵暗号方式として E C Cを用いているが、 同様な公開鍵暗号方式であればい ずれでもよい。 また、 鍵サイズも 1 6 0ビッ トでなくてもよい。 図 1 5において、 まず Bが、 64ビヅ トの乱数 Rbを生成し、 Aに送信する。 これを受信した Aは、 新たに 64ビッ トの乱数 R aおよび素数 pより小さい乱数 A kを生成する。 そし て、 ベースポイント Gを Ak倍した点 Av = AkxGを求め、 Ra、 R b, A v (X座標と Y座標） に対する電子署名 A. S i gを生成し、 Aの公開鍵証明書と ともに Bに返送する。 ここで、 R aおよび Rbはそれそれ 64ビッ ト、 Avの X 座標と Υ座標がそれそれ 1 60ビヅ トであるので、 合計 448ビッ トに対する電 子署名を生成する。
Aの公開鍵証明書、 Ra、 Rb、 Av、 電子署名 Α. 31 を受信した：8は、 Aが送信してきた Rbが、 Bが生成したものと一致するか検証する。 その結果、 一致していた場合には、 Aの公開鍵証明書内の電子署名を認証局の公開鍵で検証 し、 Aの公開鍵を取り出す。 そして、 取り出した Aの公開鍵を用い電子署名 A. S i gを検証する。
次に、 Bは、 素数 pより小さい乱数 Bkを生成する。 そして、 ベースポイント Gを B k倍した点 B v = B k X Gを求め、 Rb、 Ra、 B v (X座標と Y座標） に対する電子署名 Β. S i gを生成し、 Bの公開鍵証明書とともに Aに返送する。
Bの公開鍵証明書、 Rb、 ； Ra、 Av、 電子署名 B. S i gを受信した Αは、 Bが送信してきた Raが、 Aが生成したものと一致するか検証する。 その結果、 一致していた場合には、 Bの公開鍵証明書内の電子署名を認証局の公開鍵で検証 し、 Bの公開鍵を取り出す。 そして、 取り出した Bの公開鍵を用い電子署名 B . S i gを検証する。 電子署名の検証に成功した後、 Aは Bを正当なものとして認 証する。
両者が認証に成功した場合には、 Bは BkxAv (Bkは乱数だが、 Avは楕 円曲線上の点であるため、 楕円曲線上の点のスカラー倍計算が必要） を計算し、 Αは Ak XB Vを計算し、 これら点の X座標の下位 64ビッ トをセッションキー として以降の通信に使用する （共通鍵暗号を 64ビッ ト鍵長の共通鍵暗号とした 場合）。 もちろん、 Y座標からセヅション鍵を生成してもよいし、 下位 64ビット でなくてもよい。 なお、 相互認証後の秘密通信においては、 送信データはセッシ ヨンキーで暗号化されるだけでなく、 電子署名も付されることがある。
電子署名の検証や受信データの検証の際に、 不正、 不一致が見つかった場合に は、 相互認証が失敗したものとして処理を中断する。
図 1 6に公開鍵認証と有効化キーブロック （EKB) を使用したコンテンヅキ 一の配信処理例を示す。 まずコンテンヅプロバイダと P C間において図 1 5で説 明した公開鍵方式による認証処理が実行される。 コンテンヅプロバイダは、 コン テンヅキー配信先である再生装置、 記録媒体の有するノードキ一、 リーフキーに よって復号可能な E KBを生成して、 更新ノードキーによる暗号化を実行したコ ンテンヅキー E (K c o n) と、 有効化キ一ブロック （EKB) とを P C間の認 証処理において生成したセヅションキー K s e sで暗号化して P Cに送信する。
P Cはセッションキーで暗号化された [更新ノードキーによる暗号化を実行し たコンテンヅキー E (Kc o n) と、 有効化キーブロック （EKB)] をセヅショ ンキーで復号した後、 再生装置、 記録媒体に送信する。
再生装置、 記録媒体は、 自身の保有するノードキーまたはリーフキーによって [更新ノードキーによる暗号化を実行したコンテンヅキー E (K co n) と、 有 効化キ一プロヅク （E KB)]を復号することによってコンテンツキー Kc o nを 取得する。
この構成によれば、 コンテンツプロバイダと P C間での認証を条件として [更 新ノードキーによる [^号化を実行したコンテンヅキー E (Kc o n) と、 有効化 キープ口ヅク （E KB)]が送信されるので、 例えば、 ノードキーの漏洩があった 場合でも、 確実な相手に対するデータ送信が可能となる。
[プログラムコードの有効化キ一ブロック （EKB) を使用した配信] 上述した例では、 コンテンツキー、 認証キー等を有効化キ一ブロック （EKB) を用いて暗号化して配信する方法を説明したが、 様々なプログラムコードを有効 化キーブロック （EKB) を用いて配信する構成も可能である。 すなわち EKB による暗号化メッセージデ一夕をプログラムコードとした例である。 以下、 この 構成について説明する。
図 1 7にプログラムコードを有効化キ一ブロック （EKB) の例えば更新ノー ドキ一によって暗号化してデバイス間で送信する例を示す。デパイス 1 70 1は、 デパイス 1 7 02の有するノードキー、 リーフキーによって復号可能な有効化キ 一ブロック （EKB) と、 有効化キーブロック （EKB) に含まれる更新ノード キーで暗号処理したプログラムコードをデバイス 1 702に送信する。 デバイス 1 70 2は受信した E KBを処理して更新ノードキーを取得して、 さらに取得し た更新ノードキーによってプログラムコードの復号を実行して、 プログラムコ一 ドを得る。
図 1 7に示す例では、 さらに、 デバイス 1 7 02において取得したプログラム コードによる処理を実行して、 その結果をデバイス 1 70 1に返して、 デバイス 1 70 1がその結果に基づいて、 さらに処理を続行する例を示している。
このように有効化キーブロック （EKB) と、 有効化キーブロック （EKB) に含まれる更新ノードキーで暗号処理したプログラムコードを配信することによ り、 特定のデバイスにおいて解読可能なプログラムコードを前述の図 3で示した 特定のデバイス、 あるいはグループに対して配信することが可能となる。
[送信コンテンヅに対するチヱヅク値 （I CV:Integrity Check Value) を 対応させる構成]
次に、 コンテンツの改竄を防止するためにコンテンツのインテグリティ · チェ ヅク値 （ I C V) を生成して、 コンテンツに対応付けて、 I CVの計算により、 コンテンヅ改竄の有無を判定する処理構成について説明する。
コンテンツのインテグリティ 'チェック値 （I CV) は、 例えばコンテンツに 対するハッシュ関数を用いて計算され、 I CV = ha s h (K i ev, C I , C 2 , ···) によって計算される。 K i c Vは I C V生成キ一である。 C l， C 2は コンテンヅの情報であり、コンテンツの重要情報のメッセージ認証符号（ M A C ： Message authentication Code) が使用される。
D E S暗号処理構成を用いた MA C値生成例を図 1 8に示す。 図 1 8の構成に 示すように対象となるメヅセージを 8バイ ト単位に分割し、 （以下、分割されたメ ヅセージを M l、 Μ2、 · · ·、 ΜΝとする）、 まず、 初期値 （Initial Value (以 下、 I Vとする）） と M 1を排他的論理和する （その結果を I 1とする）。 次に、 I 1を D E S暗号化部に入れ、 鍵 （以下、 K 1 とする） を用いて暗号化する （出 力を E 1とする）。続けて、 E 1および M 2を排他的論理和し、 その出力 I 2を D E S暗号化部へ入れ、 鍵 1を用いて暗号化する （出力 E 2 )。 以下、 これを繰り 返し、 全てのメッセージに対して暗号化処理を施す。 最後に出てきた ENがメヅ セージ認証符号 (MAC (Message Authentication Code)) となる。
このようなコンテンツの MAC値と I C V生成キーにハッシュ関数を適用して 用いてコンテンヅのィンテグリティ · チェック値 （I CV) が生成される。 改竄 のないことが保証された例えばコンテンヅ生成時に生成した I C Vと、 新たにコ ンテンッに基づいて生成した I CVとを比較して同一の I CVが得られればコン テンヅに改竄のないことが保証され、 I CVが異なれば、 改竄があつたと判定さ れる。
[チヱック値（I CV)の生成キー K i c vを E KBによって配布する構成] 次に、 コンテンヅのィンテグリティ 'チェック値 （I CV) 生成キーである K i c Vを上述の有効化キ一プロックによって送付する構成について説明する。 す なわち EKBによる暗号化メッセージデータをコンテンヅのインテグリティ . チ エック値 （ I C V) 生成キ一とした例である。
図 1 9および図 20に複数のデバイスに共通のコンテンヅを送付した場合、 そ れらのコンテンツの改竄の有無を検証するためのィンテグリティ ·チヱヅク値生 成キー K i c Vを有効化キープ口ヅク （EKB)によって配信する構成例を示す。 図 1 9はデバイス 0, 1， 2， 3に対して復号可能なチェック値生成キー K i c Vを配信する例、 図 2 0はデバイス 0 , 1 , 2， 3中のデバイス 3をリボーク （排 除） してデバイス 0， 1， 2に対してのみ復号可能なチヱヅク値生成キー K i c Vを配信する例を示す。 '
図 1 9の例では、 更新ノ一ドキ一 K ( t ) 0 0によって、 チェック値生成キー K i c Vを暗号化したデ一夕 （b) とともに、 デバイス 0， 1 , 2, 3において それぞれの有するノードキー、 リーフキーを用いて更新されたノードキー K (t ) 0 0を復号可能な有効化キーブロック （EKB) を生成して配信する。 それぞれ のデバイスは、 図 1 9の右側に示すようにまず、 E KBを処理 （復号） すること により、 更新されたノードキー K ( t ) 00を取得し、 次に、 取得したノードキ 一 K ( t ) 00を用いて暗号化されたチェック値生成キー ： E n c (K (t) 0 0 , K i c v)を復号してチェック値生成キー K i c vを得ることが可能となる。 その他のデバイス 4, 5 , 6, 7…は同一の有効化キーブロック （EKB) を 受信しても自身の保有するノードキー、 リーフキーでは、 EKBを処理して更新 されたノードキー K ( t ) 00を取得することができないので、 安全に正当なデ バイスに対してのみチェヅク値生成キーを送付することができる。
一方、 図 20の例は、 図 3の点線枠で囲んだグループにおいてデバイス 3が、 例えば鍵の漏洩により リボーク （排除） されているとして、 他のグループのメン ノ 、 すなわち、 デバイス 0， 1 , 2 , に対してのみ復号可能な有効化キーブロッ ク （E KB) を生成して配信した例である。 図 20に示す （a) 有効化キープ口 ヅク （EKB) と、 （b)チェック値生成キー （K i e v) をノードキー （K (t) 00) で暗号化したデータを配信する。
図 20の右側には、 復号手順を示してある。 デバイス 0， 1， 2は、 まず、 受 領した有効化キープ口ックから自身の保有するリーフキーまたはノードキーを用 い 復号処理により、 更新ノードキー （K (t ) 00)を取得する。次に、 K (t) 00による復号によりチェック値生成キー K i c Vを取得する。
図 3に示す他のグループのデバイス 4， 5, 6…は、 この同様のデータ （EK B) を受信したとしても、 自身の保有するリーフキー、 ノードキーを用いて更新 ノードキー （K ( t ) 00) を取得することができない。 同様にリボークされた デバイス 3においても、 自身の保有するリーフキー、 ノードキーでは、 更新ノー ドキー （K ( t ) 0 0) を取得することができず、 正当な権利を有するデバイス のみがチェック値生成キーを復号して利用することが可能となる。
このように、 E KBを利用したチェック値生成キーの配送を用いれば、 データ 量を少なく して、 かつ安全に正当権利者のみが復号可能としたチェック値生成キ 一を配信することが可能となる。
このようなコンテンツのインテグリティ 'チェック値 （ I CV) を用いること により、 E KBと暗号化コンテンヅの不正コピーを排除することができる。 例え ば図 2 1に示すように、 コンテンヅ C 1とコンテンヅ C 2とをそれぞれのコンテ ンヅキーを取得可能な有効化キ一ブロック （EKB) とともに格納したメディア 1があり、 これをそのままメディア 2にコピーした場合を想定する。 EKBと暗 号化コンテンヅのコピーは可能であり、 これを E K Bを復号可能なデバイスでは 利用できることになる。
図 2 1の （b) に示すように各メディアに正当に格納されたコンテンツに対応 付けてインテグリティ 'チェック値 （ I CV (C 1 , C 2)) を格納する構成とす る。 なお、 （ I C V ( C 1， C 2 )) は、 コンテンツ C 1とコンテンツ C 2にハヅ シュ閧数を用いて計算されるコンテンツのィンテグリティ ■ チェヅク値である I C V = h a s h (K i e v, C I , C 2 ) を示している。 図 2 1の （b) の構成 において、 メディア 1には正当にコンテンヅ 1 とコンテンヅ 2が格納され、 コン テンヅ C 1とコンテンヅ C 2に基づいて生成されたィンテグリティ .チェック値 ( I C V (C I , C 2)) が格納される。 また、 メディア 2には正当にコンテンヅ 1が格納され、 コンテンツ C 1に基づいて生成されたインテグリティ 'チェック 値 （ I C V (C 1 )) が格納される。 この構成において、 メディア 1に格納された
{EKB, コンテンツ 2} をメディア 2にコピーしたとすると、 メディア 2で、 コンテンツチェック値を新たに生成すると I CV (C 1， C 2) が生成されるこ とになり、 メディアに格納されている K i c V (C 1 ) と異なり、 コンテンツの 改竄あるいは不正なコピーによる新たなコンテンヅの格納が実行されたことが明 らかになる。 メディアを再生するデバイスにおいて、 再生ステップの前ステップ に I CVチェヅクを実行して、 生成 I CVと格納 I CVの一致を判別し、 一致し ない場合は、 再生を実行しない構成とすることにより、 不正コピーのコンテンヅ の再生を防止することが可能となる。
また、 さらに、 安全性を高めるため、 コンテンツのインテグリティ ' チェック 値 （I CV) を書き換えカウンタを含めたデータに基づいて生成する構成として もよい。 すなわち I CV=ha s h (K i cv， c o unt e r + 1 , C 1 , C 2 , ···) によって計算する構成とする。 ここで、 カウンタ （c o unt e r + l ) は、 I CVの書き換えごとに 1つインクリメントされる値として設定する。なお、 カウンタ値はセキュアなメモリに格納する構成とすることが必要である。
さらに、 コンテンツのインテグリティ 'チェック値 （ I C V ) をコンテンツと 同一メディアに格納することができない構成においては、 コンテンヅのィンテグ リティ .チェック値 （ I C V) をコンテンツとは別のメディァ上に格納する構成 としてもよい。
例えば、 読み込み専用メディァゃ通常の MO等のコピ一防止策のとられていな いメディアにコンテンツを格納する場合、 同一メディアにインテグリティ ·チェ ヅク値 （ I C V) を格納すると I CVの書き換えが不正なユーザによりなされる 可能性があり、 I CVの安全性が保てないおそれがある。 この様な場合、 ホス ト マシン上の安全なメディアに I CVを格納して、 コンテンツのコピーコントロ一 ル （例えば check-in/check-out、 move) に I C Vを使用する構成とすることによ り、 I CVの安全な管理およびコンテンヅの改竄チェックが可能となる。
この構成例を図 22に示す。 図 22では読み込み専用メディアや通常の MO等 のコピー防止策のとられていないメディア 2 2 0 1にコンテンヅが格納され、 こ れらのコンテンツに関するインテグリティ ·チェック値 （ I C V ) を、 ユーザが 自由にアクセスすることの許可されないホストマシン上の安全なメディア 2 2 0 2に格納し、 ユーザによる不正なインテグリティ ' チェック値 （ I C V ) の書き 換えを防止した例である。 このような構成として、 例えばメディア 2 2 0 1を装 着したデバイスがメディア 2 2 0 1の再生を実行する際にホストマシンである P C、 サーバにおいて I C Vのチェックを実行して再生の可否を判定する構成とす れば、 不正なコピーコンテンヅあるいは改竄コンテンヅの再生を防止できる。
[階層ッリ一構造のカテゴリ分類]
暗号鍵をルートキー、 ノードキー、 リーフキー等、 図 3の階層ツリー構造とし て構成し、 コンテンツキ一、 認証キー、 I C V生成キー、 あるいはプログラムコ ード、 データ等を有効化キーブロック （E K B ) とともに暗号化して配信する構 成について説明してきたが、 ノ一ドキ一等を定義している階層ヅリ一構造を各デ バイスのカテゴリ毎に分類して効率的なキー更新処理、 暗号化キー配信、 データ 配信を実行する構成について、 以下説明する。
図 2 3に階層ツリー構造のカテゴリの分類の一例を示す。 図 2 3において、 階 層ヅリー構造の最上段には、 ルートキー K r o o t 2 3 0 1が設定され、 以下の 中間段にはノードキー 2 3 0 2が設定され、 最下段には、 リーフキ一 2 3 0 3が 設定される。 各デバイスは個々のリーフキーと、 リーフキーからルートキーに至 る一連のノードキー、 ルートキーを保有する。
ここで、 一例として最上段から第 M段目のあるノードをカテゴリノード 2 3 0 4として設定する。 すなわち第 M段目のノードの各々を特定カテゴリのデバイス 設定ノードとする。 第 M段の 1つのノードを頂点として以下、 M + 1段以下のノ ード、 リーフは、 そのカテゴリに含まれるデバイスに関するノードおよびリーフ とする。
例えば図 2 3の第 M段目の 1つのノード 2 3 0 5にはカテゴリ [メモリステツ イク （商標）] が設定され、 このノード以下に連なるノード、 リーフはメモリステ ツイクを使用した様々なデバイスを含むカテゴリ専用のノードまたはリーフとし て設定される。 すなわち、 ノード 2 3 0 5以下を、 メモリスティ ックのカテゴリ に定義されるデパイスの関連ノード、 およびリーフの集合として定義する。
さらに、 M段から数段分下位の段をサブカテゴリノード 2 3 0 6として設定す ることができる。 例えば図に示すようにカテゴリ [メモリスティ ヅク] ノ一ド 2 3 0 5の 2段下のノードに、 メモリスティ ックを使用したデパイスのカテゴリに 含まれるサブカテゴリノードとして、 [再生専用器]のノードを設定する。 さらに、 サブカテゴリノ一ドである再生専用器のノード 2 3 0 6以下に、 再生専用器の力 テゴリに含まれる音楽再生機能付き電話のノード 2 3 0 7が設定され、 さらにそ の下位に、 音楽再生機能付き電話のカテゴリに含まれる [ P H S ] ノード 2 3 0 8と [携帯電話] ノード 2 3 0 9を設定することができる。
さらに、 カテゴリ、 サブカテゴリは、 デバイスの種類のみならず、 例えばある メーカー、 コンテンツプロバイダ、 決済機関等が独自に管理するノード、 すなわ ち処理単位、 管轄単位、 あるいは提供サービス単位等、 任意の単位 （これらを総 称して以下、 エンティティ と呼ぶ） で設定することが可能である。 例えば 1つの カテゴリノードをゲーム機器メーカーの販売するゲーム機器 X Y Z専用の頂点ノ ードとして設定すれば、 メーカーの販売するゲーム機器 X Y Zにその頂点ノード 以下の下段のノードキー、 リーフキーを格納して販売することが可能となり、 そ の後、 暗号化コンテンツの配信、 あるいは各種キーの配信、 更新処理を、 その頂 点ノードキ一以下のノードキー、 リーフキーによって構成される有効化キープ口 ヅク （E K B ) を生成して配信し、 頂点ノード以下のデバイスに対してのみ利用 可能なデータが配信可能となる。
このように、 1つのノードを頂点としして、 以下のノードをその頂点ノードに 定義されたカテゴリ、 あるいはサブカテゴリの関連ノードとして設定する構成と することにより、 カテゴリ段、 あるいはサブカテゴリ段の 1つの頂点ノードを管 理するメーカ一、 コンテンヅプロバイダ等がそのノードを頂点とする有効化キ一 プロヅク （E K B ) を独自に生成して、 頂点ノード以下に属するデバイスに配信 する構成が可能となり、 頂点ノードに属さない他のカテゴリのノードに属するデ バイスには全く影響を及ぼさずにキー更新を実行す'ることができる。
[簡略 E K Bによるキー配信構成 （ 1 ) ]
先に説明した例えば図 3のツリー構成において、 キ一、 例えばコンテンツキー を所定デバイス （リーフ） 宛に送付する場合、 キー配布先デバイスの所有してい るリーフキー、 ノードキーを用いて復号可能な有効化キーブロック （EKB) を 生成して提供する。 例えば図 24 (a) に示すヅリー構成において、 リーフを構 成するデバイス a, g, jに対してキー、 例えばコンテンヅキ一を送信する場合、 a, g, jの各ノードにおいて復号可能な有効化キーブロック （EKB) を生成 して配信する。
例えば更新ルートキー K ( t ) r o o tでコンテンツキー K ( t ) c o nを暗 号化処理し、 EKBとともに配信する場合を考える。 この場合、 デバイス a， g , jは、 それぞれが図 24 (b) に示すリーフおよびノードキーを用いて、 EKB の処理を実行して K ( t ) r o o tを取得し、 取得した更新ルートキー K ( t ) r o o tによってコンテンツキー K ( ΐ ) c ο ηの復号処理を実行してコンテン ツキ一を得る。
この場合に提供される有効化キーブロック （ΕΚΒ) の構成は、 図 25に示す ようになる。 図 2 5に示す有効化キーブロック （ΕΚΒ) は、 先の図 6で説明し た有効化キーブロック （ΕΚΒ) のフォーマッ トにしたがって構成されたもので あり、 データ （暗号化キー） と対応するタグとを持つ。 タグは、 先に図 7を用い て説明したように左 （L)、 右 （R)、 それそれの方向にデータがあれば 0、 無け れば 1を示している。
有効化キ一プロヅク （E KB)を受領したデバイスは、有効化キ一プロヅク （E KB) の暗号化キーとタグに基づいて、 順次暗号化キーの復号処理を実行して上 位ノードの更新キーを取得していく。 図 25に示すように、 有効化キーブロック (EKB) は、 ルートからリーフまでの段数 （デブス） が多いほど、 そのデータ 量は増加していく。 段数 （デプス） は、 デバイス （リーフ） 数に応じて増大する ものであり、 キーの配信先となるデバイス数が多い場合は、 EKBのデータ量が さらに增大することになる。
このような有効化キーブロック （EKB) のデータ量の削減を可能とした構成 について説明する。 図 26は、 有効化キーブロック （EKB) をキ一配信デバィ スに応じて簡略化して構成した例を示すものである。
図 25と同様、 リーフを構成するデバイス a， g, jに対してキー、 例えばコ ンテンツキ一を送信する場合を想定する。 図 2 6の （a) に示すように、 キ一配 信デバイスによってのみ構成されるツリーを構築する。 この場合、 図 24 (b) に示す構成に基づいて新たなヅリー構成として図 26 (b) のヅリ一構成が構築 される。 Kr o o tから K jまでは全く分岐がなく 1つの枝のみが存在すればよ く、 Kr 0 o tから Kaおよび Kgに至るためには、 K 0に分岐点を構成するの みで、 2分岐構成の図 26 (a) のツリーが構築される。
図 26 (a) に示すように、 ノードとして K 0のみを持つ簡略化したヅリーが 生成される。 更新キー配信のための有効化キーブロック （EKB) は、 これらの 簡略ヅリ一に基づいて生成する。 図 2 6 (a) に示すヅリ一は、 有効化キープ口 ック （EKB) を復号可能な末端ノードまたはリーフを最下段とした 2分岐型ッ リーを構成するパスを選択して不要ノードを省略することにより再構築される再 構築階層ヅリーである。更新キ一配信のための有効化キーブロック （EKB)は、 この再構築階層ヅリ一のノードまたはリーフに対応するキーのみに基づいて構成 される。
先の図 25で説明した有効化キーブロック （EKB) は、 各リーフ a， g, j から K r o o tに至るまでのすベてのキーを暗号化したデータを格納していたが、 簡略化 E KBは、 簡略化したッリーを構成するノードについてのみの暗号化デ一 夕を格納する。 図 2 6 (b) に示すようにタグは 3ビッ ト構成を有する。 第 2お よび第 3ビッ トは、 図 25の例と、 同様の意味を持ち、 左 （L)、 右 （R)、 それ それの方向にデータがあれば 0、 無ければ 1を示す。 第 1番目のビッ トは、 EK B内に暗号化キーが格納されているか否かを示すためのビッ トであり、 データが 格納されている場合は 1、 データが無い場合は、 0として設定される。
データ通信網、 あるいは記憶媒体に格納されてデバイス （リーフ） に提供され る有効化キ一ブロック （EKB) は、 図 26 (b) に示すように、 図 25に示す 構成に比較すると、 データ量が大幅に削減されたものとなる。 図 26に示す有効 化キーブロック （EKB) を受領した各デバイスは、 タグの第 1ビッ トに 1が格 納された部分のデータのみを順次復号することにより、 所定の暗号化キーの復号 を実現することができる。 例えばデバイス aは、 暗号化データ E n c (Ka， K (ΐ ) 0) をリーフキー Κ aで復号して、 ノードキ一 K ( t ) 0を取得して、 ノ 一ドキ一 K ( t ) 0によって暗号化データ E n c (K ( t ) 0， K ( t ) r o o t ) を復号して K (t ) r o o tを取得する。 デパイス jは、.暗号化デ一夕 E n c (K j， K ( ΐ ) r o o t) をリーフキー Κ jで復号して、 K ( t ) r o o t を取得する。
このように、 配信先のデバイスによってのみ構成される簡略化した新たなッリ 一構成を構築して、 構築されたッリーを構成するリーフおよびノードのキーのみ を用いて有効化キーブロック （EKB) を生成することにより、 少ないデータ量 の有効化キ一ブロック （EKB) を生成することが可能となり、 有効化キープ口 ヅク （EKB) のデータ配信が効率的に実行可能となる。
[簡略 EKBによるキー配信構成 （2)]
図 2 6で示した簡略化したヅリーに基づいて生成される有効化キープ口ヅク (EKB) をさらに、 簡略化してデータ量を削減し、 効率的な処理を可能とした 構成について説明する。
図 2 6を用いて説明した構成は、 有効化キーブロック （EKB) を復号可能な 末端ノードまたはリーフを最下段とした 2分岐型ヅリーを構成するパスを選択し て不要ノードを省略することにより再構築される再構築階層ツリーであった。 更 新キー配信のための有効化キーブロック （EKB) は、 この再構築階層ツリーの ノードまたはリーフに対応するキーのみに基づいて構成される。
図 2 6 (a) に示す再構築階層ツリーは、 リーフ a, g, jにおいて更新ルー トキ一 K (t ) r o o tを取得可能とするため、 図 26 (b) に示す有効化キー ブロック （EKB) を配信する。 図 2 6 (b) の有効化キーブロック （EKB) の処理において、 リーフ jは、 E n c (K j， K ( t ) r o o t) の 1回の復号 処理によりルートキー ： K ( t ) r o o tを取得できる。 しかし、 リーフ a， g は、 E nc (Ka, K ( t ) 0) または、 E n c (Kg, K (t ) 0) の復号処 理により K (t ) 0を得た後、 さらに、 E n c (K ( t ) 0 , K ( t ) r o o t) の復号処理を実行してルートキ一： K ( t ) r o o tを取得する。 すなわち、 リ ーフ a, gは、 2回の復号処理を実行することが必要となる。
図 26の簡略化した再構築階層ヅリ一は、 ノード K 0がその下位リーフ a， g の管理ノードとして独自の管理を実行している場合、 例えば後述するサブルー ト · ノードとして、 下位リーフの管理を実行している場合には、 リーフ a， gが 更新キーを取得したことを確認する意味で有効であるが、 ノード K 0が下位リ一 フの管理を行なっていない場合、 あるいは行なっていたとしても、 上位ノードか らの更新キー配信を許容している場合には、 図 26 (a) に示す再構築階層ヅリ 一をさらに簡略化して、 ノード K0のキ一を省略して有効化キーブロック （EK B) を生成して配信してもよい。
図 27に、 このような有効化キ一ブロック （EKB) の構成を示す。 図 26と 同様、 リーフを構成するデバイス a， g, jに対してキー、 例えばコンテンツキ 一を送信する場合を想定する。 図 27の （a) に示すように、 ルート Kr o o t と各リ一フ a， g， jを直接接続したツリーを構築する。
図 27 (a) に示すように、 図 26 (a) に示す再構築階層ヅリ一からノード K 0が省かれた簡略化したッリーが生成される。 更新キー配信のための有効化キ 一ブロック （E KB) は、 これらの簡略ヅリーに基づいて生成する。 図 27 (a) に示すヅリ一は、 有効化キーブロック （EKB) を復号可能なリーフをとルート とを直接結ぶパスのみによって再構築される再構築階層ヅリーである。 更新キー 配信のための有効化キーブロック （EKB) は、 この再構築階層ツリーのリーフ に対応するキーのみに基づいて構成される。
なお、 図 27 (a) の例は、 末端をリーフとした構成例であるが、 例えば最上 位ノードか複数の中位、 下位ノードに対してキーを配信する場合も、 最上位ノー ドと中位、 下位ノードとを直接接続した簡略化ヅリ一に基づいて有効化キープ口 ヅク （EKB) を生成してキー配信を実行することが可能である。 このように、 再構築階層ヅリ一は、 簡略化したツリーを構成する頂点ノードと、 簡略化したヅ リ一を構成する末端ノードまたはリーフとを直接、 接続した構成を持つ。 この簡 略化ツリーでは、 頂点ノードからの分岐は 2に限らず、 配信ノードまたはリーフ 数に応じて 3以上の多分岐を持つヅリーとして構成することが可能である。
先の図 25で説明した有効化キーブロック （EKB) は、 各リーフ a， g， j から K r o o tに至るまでのすベてのキーを暗号化したデータを格納し、 図 2 6 で説明した有効化キープロヅク （EKB) は、 リーフ a, g, jのリーフキー、 a , gの共通ノードとしての K 0、 さらに、 ルートキ一を格納した構成であった が、 図 27 (a) に示す簡略化階層ヅリーに基づく有効化キ一ブロック （EKB) は、 ノード K 0のキーを省略したので、 図 27 (b) に示すように、 さらにデー 夕量の少ない有効化キ一ブロック （EKB) となる。
図 27 (b) の有効化キープ口ヅク （EKB) は、 図 2 6 (b) の有効化キ一 ブロック （E KB) と同様、 3ビッ ト構成のタグを有する。 第 2および第 3ビヅ トは、 図 2 6で説明したと同様、 左 （L：)、 右 （R)、 それそれの方向にデータが あれば 0、 無ければ 1を示す。 第 1番目のビッ トは、 EKB内に暗号化キーが格 納されているか否かを示すためのビッ トであり、 デ一夕が格納されている場合は 1、 デ一夕が無い場合は、 0として設定される。
図 27 (b) の有効化キ一ブロック （EKB) において、 各リーフ a, g， j は、 En c (K a , K (t ) r o o t ), または E n c (Kg, K ( t ) r o o t) £ ]10 (1 <' , 1^ ( 1 ) 0 0 1: ) の 1回の復号処理によりルートキー： K ( t ) r o o tを取得できる。
このように簡略化された再構築ヅリ一の最上位ノードと、 ヅリーを構成する末 端ノードまたはリーフとを直接、 接続した構成を持つヅリーに基づいて生成され る有効化キーブロック （EKB) は、 図 2 7 (b) に示すように、 再構築階層ヅ リーの頂点ノードおよび末端ノードまたはリーフに対応するキーのみに基づいて 構成される。
図 26または図 27で説明した有効化キーブロック （EKB) のように、 配信 先のデバイスによってのみ構成される簡略化した新たなヅリー構成を構築して、 構築されたヅリ一を構成するリーフのみ、 あるいはリーフと共通ノードのキーの みを用いて有効化キープロヅク （EKB) を生成することにより、 少ないデータ 量の有効化キーブロック （EKB) を生成することが可能となり、 有効化キープ ロヅク （EKB) のデータ配信が効率的に実行可能となる。
なお、 簡略化した階層ヅリー構成は、 後段で説明するサブツリーとして設定さ れるカテゴリヅリー単位の E K B管理構成において特に有効に活用可能である。 カテゴリッリ一は、 キー配信構成としてのッリ一構成を構成するノードあるいは リーフから選択した複数のノードあるいはリーフの集合体プロヅクである。 カテ ゴリヅリ一は、 デバイスの種類に応じて設定される集合であったり、 あるいはデ バイス提供メーカー、 コンテンヅプロバイダ、 決済機関等の管理単位等、 ある共 通点を持った処理単位、 管轄単位、 あるいは提供サービス単位等、 様々な態様の 集合として設定される。 1つのカテゴリヅリーには、 ある共通のカテゴリに分類 されるデバイスが集まっており、 例えば複数のカテゴリヅリーの頂点ノード （サ ブルート） によって上述したと同様の簡略化したツリーを再構築して E K Bを生 成することにより、 選択されたカテゴリヅリーに属するデバイスにおいて復号可 能な簡略化された有効化キーブロック （E K B ) の生成、 配信が可能となる。 力 テゴリッリ一単位の管理構成については後段で詳細に説明する。
なお、 このような有効化キーブロック （E K B ) は、 光ディスク、 D V D等の 情報記録媒体に格納した構成とすることが可能である。 例えば、 上述の暗号化キ 一データによって構成されるデータ部と、 暗号化キーデータの階層ヅリー構造に おける位置識別データとしてのタグ部とを含む有効化キープロック （E K B ) に さらに、 更新ノードキーによって暗号化したコンテンヅ等のメヅセージデータと を格納した情報記録媒体を各デバイスに提供する構成が可能である。 デバイスは 有効化キーブロック （E K B ) に含まれる暗号化キーデータをタグ部の識別デー 夕にしたがって順次抽出して復号し、 コンテンッの復号に必要なキーを取得して コンテンヅの利用を行なうことが可能となる。もちろん、有効化キープ口ック（E K B ) をインターネ ヅ ト等のネ ヅ トワークを介して配信する構成としてもよい。
[カテゴリヅリ一単位の E K B管理構成]
次に、 キー配信構成としてのツリー構成を構成するノードあるいはリーフを、 複数のノードあるいはリーフの集合としてのプロックで管理する構成について説 明する。 なお、 複数のノードあるいはリーフの集合としてのブロックを以下カテ ゴリヅリーと呼ぶ。 カテゴリヅリ一は、 デバイスの種類に応じて設定される集合 であったり、 あるいはデバイス提供メーカー、 コンテンツプロバイダ、 決済機関 等の管理単位等、 ある共通点を持った処理単位、 管轄単位、 あるいは提供サービ ス単位等、 様々な態様の集合として設定される。
カテゴリヅリ一について、 図 2 8を用いて説明する。 図 2 8 ( a ) はヅリーの カテゴリヅリ一単位での管理構成を説明する図である。 1つのカテゴリヅリ一は 図では、 三角形として示し、 例えば 1カテゴリヅリー 2 7 0 1内には、 複数のノ ードが含まれる。 1カテゴリヅリー内のノード構成を示すのが （b) である。 1 つのカテゴリヅリーは、 1つのノードを頂点とした複数段の 2分岐形ヅリーによ つて構成される。 以下、 カテゴリヅリ一の頂点ノード 27 02をサブルートと呼 ぶ。
ツリーの末端は、 （c)に示すようにリーフ、 すなわちデバイスによって構成さ れる。 デバイスは、 複数デバイスをリーフとし、 サブルートである頂点ノード 2 702を持つヅリ一によって構成されるいずれかのカテゴリヅリ一に属する。 図 28 (a) から理解されるように、 カテゴリヅリ一は、 階層構造を持つ。 こ の階層構造について、 図 29を用いて説明する。
図 29 (a) は、 階層構造を簡略化して説明するための図であり、 Kr o o t から数段下の段にカテゴリヅリー A 0 l~Annが構成され、 カテゴリツリー A l~Anの下位には、 さらに、 カテゴリヅリ一 B 0 1〜： B n k、 さらに、 その下 位にカテゴリツリー C 1〜 C n qが設定されている。 各カテゴリツリーは、 図 2 9 (b), (c) に示す如く、 複数段のノード、 リーフによって構成されるヅリー 形状を持つ。
例えばカテゴリヅリー B nkの構成は、 （b)に示すように、サブルート 28 1 1を頂点ノードとして、 末端ノード 28 1 2に至るまでの複数ノードを有する。 このカテゴリヅリーは識別子 B nkを持ち、 カテゴリヅリー B nk内のノードに 対応するノードキ一管理をカテゴリヅリー B nk独自に実行することにより、 末 端ノード 28 1 2を頂点として設定される下位 （子） カテゴリヅリーの管理を実 行する。 また、 一方、 カテゴリッリー B nkは、 サブルート 28 1 1を末端ノー ドとして持つ上位 （親） カテゴリツリー Annの管理下にある。
カテゴリヅリ一 C n 3の構成は、 （ c )に示すように、サブル一ト 285 1を頂 点ノードとして、 各デバイスである末端ノード 2852、 この場合はリーフに至 るまで複数ノード、 リーフを有する。このカテゴリヅリ一は識別子 Cn3を持ち、 カテゴリツリー C n 3内のノード、 リーフに対応するノードキー、 リーフキー管 理をカテゴリヅリー Cn 3独自に実行することにより、 末端ノード 2852に対 応するリーフ （デパイス） の管理を実行する。 また、 一方、 カテゴリツリー C n 3は、 サブルート 285 1を末端ノードとして持つ上位 （親） カテゴリヅリー B n 2の管理下にある。 各カテゴリツリーにおけるキー管理とは、 例えばキー更新 処理、 リポーク処理等であるが、 これらは後段で詳細に説明する。
最下段カテゴリヅリーのリーフであるデバイスには、 デバイスの属するカテゴ リツリーのリーフキーから、 自己の属するカテゴリッリ一の頂点ノードであるサ ブル一トノ一ドに至るパスに位置する各ノードのノードキーおよびリーフキーが 格納される。 例えば末端ノード 2 8 5 2のデパイスは、 末端ノード （リーフ） 2 8 5 2から、 サブルートノード 2 8 5 1までの各キーを格納する。
図 3 0を用いて、 さらにカテゴリツリーの構成について説明する。 カテゴリヅ リーは様々な段数によって構成されるヅリー構造を持つことが可能である。段数、 すなわちデプス （depth) は、 カテゴリツリーで管理する末端ノードに対応する下 位 （子） カテゴリヅリーの数、 あるいはリーフとしてのデバイス数に応じて設定 可能である。 .
図 3 0の （a ) に示すような上下カテゴリヅリー構成を具体化すると、 （b ) に 示す態様となる。 ルートッリ一は、 ルートキーを持つ最上段のヅリーである。 ル ートヅリ一の末端ノードに複数の下位カテゴリツリーとしてカテゴリヅリ一 A， B， Cが設定され、 さらに、 カテゴリヅリー Cの下位カテゴリッリ一としてカテ ゴリヅリー Dが設定される。 カテゴリヅリー C 2 9 0 1は、 その末端ノードの' 1 つ以上のノードをリザーブノード 2 9 5 0として保持し、 自己の管理するカテゴ リヅリ一を増加させる場合、さらに複数段のッリ一構成を持つ テゴリヅリー C， 2 9 0 2をリザーブノード 2 9 5 0を頂点ノードとして新設することにより、 管 理末端ノード 2 9 7 0を増加させて、 管理末端ノードに増加した下位カテゴリヅ リーを追加することができる。
リザープノ一ドについて、 さらに図 3 1を用いて説明する。カテゴリヅリー A , 3 0 1 1は、 管理する下位カテゴリヅリー B , C , D…を持ち、 1つのリザーブ ノード 3 0 2 1を持つ。 カテゴリツリーは管理対象の下位カテゴリヅリーをさら に増加させたい場合、 リザーブノード 3 0 2 1 に、 自己管理の下位カテゴリヅリ 一 A，， 3 0 1 2を設定し、 下位カテゴリヅリー A，， 3 0 1 2の末端ノードにさ らに管理対象の下位カテゴリツリー F , Gを設定することができる。 自己管理の 下位カテゴリヅリ一 A，， 3 0 1 2も、 その末端ノ一ドの少なく とも 1っをリザ一 ブノード 302 2として設定することにより、 さらに下位カテゴリヅリ一 A，， 3 0 1 3を設定して、 さらに管理カテゴリヅリーを増加させることができる。 下位 カテゴリツリー A，， 3 0 1 3の末端ノードにも 1以上のリザーブノードを確保す る。 このようなリザーブノード保有構成をとることにより、 あるカテゴリツリー の管理する下位カテゴリヅリーは、 際限なく増加させることが可能となる。なお、 リザーブカテゴリヅリ一は、 末端ノードの 1つのみではなく、 複数個設定する構 成としてもよい。
それそれのカテゴリヅリ一では、カテゴリッリ一単位で有効化キープ口ック（E KB) が構成され、 カテゴリヅリ一単位でのキ一更新、 リボーク処理を実行する ことになる。 図 3 1のように複数のカテゴリツリー A, A，， A" には各カテゴ リヅリ一個々の有効化キーブロック （EKB) が設定されることになるが、 これ らは、 カテゴリヅリー A， A，， A" を共通に管理する例えばあるデバイスメー カーが一括して管理することが可能である。
[新規カテゴリヅリ一の登録処理]
次に、 新規カテゴリヅリーの登録処理について説明する。 登録処理シーケンス を図 32に示す。 図 32のシーケンスにしたがって説明する。 新たにツリー構成. 中に追加される新規 （子） カテゴリヅリー （N— En) は、 上位 （親） カテゴリ ツリー （P— E n) に対して新規登録要求を実行する。 なお、 各カテゴリヅリ一 は、 公開鍵暗号方式に従った公開鍵を保有し、 新規カテゴリツリーは自己の公開 鍵を登録要求に際して上位カテゴリツリー （P— En) に送付する。
登録要求を受領した上位カテゴリヅリー （P— En) は、 受領した新規 （子） カテゴリ ヅリ一 （N— E n ) の公開鍵を証明書発行局 （ C A ： Certificate Authority) に転送し、 C Aの署名を付加した新規 （子） カテゴリヅリー （N— E n) の公開鍵を受領す'る。 これらの手続きは、 上位カテゴリツリー （P— E n) と新規 （子） カテゴリヅリー （N— E n) との相互認証の手続きとして行われる。 これらの処理により、 新規登録要求カテゴリヅリーの認証が終了すると、 上位 カテゴリヅリ一 （P— En) は、 新規 （子） カテゴリツリー （N— En) の登録 を許可し、 新規 （子） カテゴリツリー （N— E n) のノードキーを新規 （子） 力 テゴリツリー （N— E n) に送信する。 このノードキーは、 上位カテゴリヅリー (P— En) の末端ノードの 1つのノードキーであり、 かつ、 新規 （子） カテゴ リヅリー （N— E n) の頂点ノ一ド、 すなわちサブルートキーに対応する。
このノードキー送信が終了すると、 新規 （子） カテゴリヅリー （N— E n) は、 新規 （子） カテゴリツリー （N— En) のヅリ一構成を構築し、 構築したツリー の頂点に受信した頂点ノードのサブルートキーを設定し、 各ノード、 リーフのキ 一を設定して、 カテゴリヅリー内の有効化キーブロック （EKB) を生成する。 1つのカテゴリツリー内の有効化キ一ブロック （EKB) をサブ EKBと呼ぶ。 —方、 上位カテゴリヅリー （P— E n) は、 新規 （子） カテゴリヅリー （N— E n) の追加により、 有効化する末端ノードを追加した上位カテゴリツリー （P 一 E n) 内のサブ E K Bを生成する。
新規 （子） カテゴリツリー （N— E n) は、 新規 （子） カテゴリヅリー （N— En)内のノードキー、 リーフキーによって構成されるサブ E KBを生成すると、 これを上位カテゴリツリー （P— E n) に送信する。
新規 （子） カテゴリヅリー （N— E n) からサブ E KBを受信した上位カテゴ リヅリー （P— En) は、 受信したサブ EKBと、 上位カテゴリヅリー （P— E n)の更新したサブ E KBとをキー発行センター（KD C： Key Distribute Center) に送信する。
キー発行センター （KD C) は、 すべてのカテゴリヅリーのサブ E KBに基づ いて、 様々な態様の EKB、 すなわち特定のカテゴリツリーあるいはデバイスの みが復号可能な E KBを生成することが可能となる。 このように復号可能なカテ ゴリツリーあるいはデバィスを設定した E K Bを例えばコンテンヅプロバイダに 提供し、コンテンヅプロバイダが E KBに基づいてコンテンツキーを暗号化して、 ネッ トワークを介して、 あるいは記録媒体に格納して提供することにより、 特定 のデバイスでのみ利用可能なコンテンツを提供することが可能となる。
なお、 新規カテゴリツリーのサブ E KBのキ一発行センター （KD C) に対す る登録処理は、 サブ E KBを上位カテゴリッリ一を介してを順次転送して実行す る方法に限るものではなく、 上位カテゴリヅリ一を介さずに、 新規登録カテゴリ ツリーから直接、 キー発行センタ一 （KD C) に登録する処理を実行する構成と してもよい。 上位カテゴリヅリーと、 上位カテゴリッリーに新規追加する下位カテゴリヅリ 一との対応について図 33を用いて説明する。 上位カテゴリヅリ一の末端ノード の 1つ 320 1を新規追加カテゴリヅリーの頂点ノードとして、 下位カテゴリッ リーに提供することによって下位カテゴリヅリ一は、 上位カテゴリヅリーの管理 下のカテゴリツリーとして追加される。 上位カテゴリツリーの管理下のカテゴリ ツリーとは、 後段で詳細に説明するが、 下位カテゴリツリーのリボーク （排除） 処理を上位カテゴリヅリーが矣行できる構成であるという意味を含むものである 図 33に示すように、 上位カテゴリヅリーに新規カテゴリヅリ一が設定される と、 上位カテゴリヅリ一のリーフである末端ノ一ドの 1つのノード 32 0 1と新 規追加カテゴリヅリーの頂点ノード 3 202とが等しいノードとして設定される c すなわち上位ノードの 1つのリーフである 1つの末端ノ.一ドが、 新規追加カテゴ リヅリーのサブルートとして設定される。 このように設定されることにより、 新 規追加カテゴリヅリーが全体ヅリ一構成の下で有効化される。
図 34に新規追加カテゴリヅリーを設定した際に上位カテゴリヅリ一が生成す る更新 EKBの例を示す。 図 34は、 （a) に示す構成、 すなわち既に有効に存在 する末端ノード （n o d e 000 ) 3 30 1と末端ノード （no d e 0 0 1) 3 302があり、 ここに新規追加カテゴリツリーに新規カテゴリヅリー追加末端ノ —ド （no d e l O O) 3 30 3を付与した際に上位カテゴリヅリーが生成する サブ E KBの例を示したものである。
サブ E KBは、 図 34の （b) に示すようにな構成を持つ。 それそれ有効に存 在する末端ノードキーにより暗号化された上位ノードキー、 上位ノードキーで暗 号化されたさらなる上位ノードキー、 …さらに上位に進行してサブルートキーに 至る構成となっている。 この構成によりサブ EKBが生成される。 各カテゴリッ リーは図 34 (b) に示すと同様、 有効な末端ノード、 あるいはリーフキーによ り暗号化された上位ノードキー、 上位ノードキーでさらに上位のノードキーを暗 号化し、 順次上位に深厚してサブルートに至る暗号化データによって構成される EKBを有し、 これを管理する。
[カテゴリヅリ一管理下におけるリボーク処理]
次に、 キー配信ヅリー構成をカテゴリヅリー単位として管理する構成における デバイスあるいはカテゴリヅリーのリポーク （排除） 処理について説明する。 先 の図 3 , 4では、 ヅリ一構成全体の中から特定のデバイスのみ復号可能で、 リポ ークされたデバイスは復号不可能な有効化キーブロック （E K B ) を配信する処 理について説明した。 図 3 , 4で説明したリポーク処理は、 ツリー全体の中から 特定のリーフであるデバイスをリボークする処理であつたが、 ヅリ一のカテゴリ ヅリ一管理による構成では、カテゴリヅリ一毎にリボーク処理が実行可能となる。 図 3 5以下の図を用いてカテゴリヅリ一管理下のッリ一構成におけるリポーク 処理について説明する。 図 3 5は、 ツリーを構成するカテゴリツリーのうち、 最 下段のカテゴリッリ一、 すなわち個々のデバイスを管理しているカテゴリヅリ一 によるデバイスのリポーク処理を説明する図である。
図 3 5 ( a ) は、 カテゴリツリー管理によるキ一配信ヅリー構造を示している。 ヅリー最上位にはルートノードが設定され、 その数段下にカテゴリヅリー A 0 1 〜A n n、 さらにその下位段に B 0 1〜： B n kのカテゴリヅリー、 さらにその下 位段に C 1〜 c nのカテゴリヅリ一が構成されている。 最も下のカテゴリヅリ一 は、 末端ノード （リーフ） が個々のデバイス、 例えば記録再生器、 再生専用器等 であるとする。
ここで、 リボーク処理は、 各カテゴリヅリーにおいて独自に実行される。 例え ば、 最下段のカテゴリヅリ一 C 1〜C nでは、 リーフのデバ.イスのリボーク処理 が実行される。 図 3 5 ( b ) には、 最下段のカテゴリツリーの 1つであるカテゴ リツリー C n， 3 4 3 0のヅリー構成を示している。 カテゴリツリー C n , 3 4 3 0は、 頂点ノード 3 4 3 1を持ち、 末端ノードであるリーフに複数のデバイス を持つ構成である。
この末端ノードであるリーフ中に、 リボーク対象となるデバイス、 例えばデバ イス 3 4 3 2があったとすると、 カテゴリヅリー C n , 3 4 3 0は、 独自に更新 したカテゴリツリー C n内のノードキー、 リーフキーによって構成される有効化 キーブロック （サブ E K B ) を生成する。 この有効化キーブロックは、 リボーク デバイス 3 4 3 2においては復号できず、 他のリーフを構成するデパイスにおい てのみ復号可能な暗号化キーにより構成されるキ一プロックである。 カテゴリッ リー C nの管理者は、 これを更新されたサブ E K Bとして生成する。具体的には、 サブルートからリポ一クデバイス 3432に連なるパスを構成する各ノード 34 3 1， 3434, 3435のノードキーを更新して、 この更新ノードキーをリボ ークデバイス 3432以外のリーフデバイスにおいてのみ復号可能な暗号化キー として構成したブロックを更新サブ E KBとする。 この処理は、 先の図 3 , 4に おいて説明したリボーク処理構成において、 ルートキ一を、 カテゴリツリーの頂 点キーであるサブルートキーに置き換えた処理に対応する。
このようにカテゴリツリー C n， 3430がリボーク処理によって更新した有 効化キーブロック （サブ EKB) は、 上位カテゴリツリーに送信される。 この場 合、 上位カテゴリツリーはカテゴリツリー B n k , 342 0であり、 カテゴリヅ リ一 Cn, 343 0の頂点ノード 343 1を末端ノードとして有するカテゴリヅ リーである。
カテゴリヅリー B nk, 3420は、 下位カテゴリツリー C n, 3430から 有効化キーブロック （サブ EKB) を受領すると、 そのキ一ブロックに含まれる カテゴリヅリ一 C nk， 3430の頂点ノ一ド 343 1に対応するカテゴリヅリ 一 B nk, 3 42 0の末端ノード 343 1を、 下位カテゴリヅリー C n, 343 0において更新されたキーに設定して、 自身のカテゴリヅリー B n.k， 342 0 のサブ E K Bの更新処理を実行する。 図 3 5 (c) にカテゴリヅリ一 B nk, 3 42 0のヅリ一構成を示す。 カテゴリツリー B nk, 3420において、 更新対 象となるノードキ一は、 図 35 ( c) のサブルート 342 1からリボークデバイ スを含むカテゴリヅリ一を構成する末端ノード 343 1に至るパス上のノードキ 一である。 すなわち、 更新サブ EKBを送信してきたカテゴリヅリーのノード 3 43 1に連なるパスを構成する各ノード 342 1 , 3424， 3425のノード キーが更新対象となる。 これら各ノードのノードキ一を更新してカテゴリヅリー Bnk, 342 0の新たな更新サブ E KBを生成する。
さらに、 カテゴリツリー B nk, 3420が更新した有効化キーブロック （サ ブ EKB) は、 上位カテゴリヅリーに送信される。 この場合、 上位カテゴリッリ —はカテゴリヅリ一 Ann， 34 1 0であり、 カテゴリヅリー B nk， 342 0 の頂点ノード 342 1を末端ノードとして有するカテゴリヅリーである。
カテゴリヅリー Ann, 341 0は、 下位カテゴリヅリー B n k, 3420か ら有効化キーブロック （サブ EKB) を受領すると、 そのキ一ブロックに含まれ るカテゴリツリー B nk, 342 0の頂点ノード 342 1に対応するカテゴリヅ リー Ann， 341 0の末端ノード 342 1を、 下位カテゴリヅリー B nk， 3 420において更新されたキーに設定して、 自身のカテゴリツリー Ann， 34 1 0のサブ E KBの更新処理を実行する。 図 3 5 (d) にカテゴリツリー Ann, 34 1 0のヅリ一構成を示す。 カテゴリヅリー An n， 341 0において、 更新 対象となるノードキーは、 図 35 (d) のサブル一ト 34 1 1から更新サブ E K Bを送信してきたカテゴリヅリーのノード 342 1に連なるパスを構成する各ノ ード 341 1 , 3414, 341 5のノードキーである。 これら各ノードのノー ドキーを更新してカテゴリツリー An n, 34 1 0の新たな更新サブ E K Bを生 成する。
これらの処理を順次、 上位のカテゴリヅリーにおいて実行し、 図 30 (b) で 説明したルートカテゴリヅリーまで実行する。 この一連の処理により、 デバイス のリボーク処理が完結する。 なお、 それぞれのカテゴリヅリーにおいて更新され たサブ E KBは、 最終的にキー発行センター （KD C) に送信され、 保管される。 キー発行セン夕一 （KD C) は、 すべてのカテゴリツリーの更新サブ EKBに基 づいて、 様々な EKBを生成する。 更新 EKBは、 リボークされたデバイスでの 復号が不可能な暗号化キープ口ックとなる。
デバイスのリボーク処理のシーケンス図を図 36に示す。 処理手順を図 3 6の シーケンス図に従って説明する。 まず、 ヅリ一構成の最下段にあるデバイス管理 カテゴリヅリー （D— En) は、 デバイス管理カテゴリヅリー （D— En) 内の リボーク対象のリーフを排除するために必要なキー更新を行ない、 デバイス管理 カテゴリツリー （D— E n) の新たなサブ EKB (D) を生成する。 更新サブ E KB (D) は、 上位カテゴリヅリーに送付される。 更新サブ E KB (D) を受領 した上位 （親） カテゴリヅリー （P 1— E n) は、 更新サブ E KB (D) の更新 頂点ノードに対応した末端ノードキーの更新および、 その末端ノードからサブル ートに至るパス上のノードキーを更新した更新サブ EKB (P 1 ) を生成する。 これらの処理を順次、 上位カテゴリツリーにおいて実行して、 最終的に更新され たすベてのサブ EKBがキー発行セン夕一 （KD C) に格納され管理される。 図 37にデバイスのリボーク処理によって上位カテゴリッリーが更新処理を行 なって生成する有効化キーブロック （EKB) の例を示す。
図 3 7は、 （a)に示す構成において、 リボークデバイスを含む下位カテゴリッ リーから更新サブ E K Bを受信した上位カテゴリヅリ一において生成する E K B の例を説明する図である。 リボークデバイスを含む下位カテゴリツリーの頂点ノ ードは、 上位カテゴリヅリーの末端ノード （no d e l O O) 360 1に対応す る。
上位カテゴリツリーは、 上位カテゴリツリーのサブルートから末端ノード （n o d e l O O) 36 0 1までのパスに存在するノードキーを更新して新たな更新 サブ EKBを生成する。 更新サブ EKBは、 図 37 (b) のようになる。 更新さ れたキーは、 下線および Γ]を付して示してある。 このように更新された末端ノ 一ドからサブルートまでのパス上のノードキ一を更新してそのカテゴリヅリーに おける更新サブ E K Bとする。
次に、 リボークする対象をカテゴリヅリーとした場合の処理、 すなわちカテゴ リヅリーのリポーク処理について説明する。
図 38 (a) は、 カテゴリヅリー管理によるキー配信ッリー構造を示している。 ツリー最上位にはルートノードが設定され、 その数段下にカテゴリヅリー A 0 1 〜Ann、 さらにその下位段に B 0 1〜： B n kのカテゴリヅリー、 さらにその下 位段に C 1〜 c nのカテゴリヅリ一が構成されている。 最も下のカテゴリッリ一 は、 末端ノード （リーフ） が個々のデバイス、 例えば記録再生器、 再生専用器等 であるとする。
ここで、 リボーク処理を、 カテゴリツリー Cn, 373 0に対して実行する場 合について説明する。 最下段のカテゴリツリー Cn, 37 30は、 図 38 (b) に示すように頂点ノード 343 1を持ち、 末端ノ一ドであるリーフに複数のデバ イスを持つ構成である。
カテゴリヅリー Cn, 3 73 0をリボークすることにより、 カテゴリヅリ一 C n, 3 730に属するすべてのデバイスのツリー構造からの一括排除が可能とな る。 カテゴリツリー Cn, 3 73 0のリボーク処理は、 カテゴリツリー Cn, 3 730の上位カテゴリッリーであるカテゴリヅリー B nk, 3720において実 行される。 カテゴリツリー B nk, 3 72 0は、 カテゴリツリー C n， 373 0 の頂点ノード 373 1を末端ノードとして有するカテゴリツリーである。
カテゴリッリ一 B n k， 3720は、 下位カテゴリツリー C η , 3 730のリ ボークを実行する場合、 カテゴリヅリ一 Cnk, 3 730の頂点ノード 37 3 1 に対応するカテゴリヅリ一 B nk, 3 720の末端ノード 373 1を更新し、 さ らに、 そのリボークカテゴリツリー 3 73 0からカテゴリツリー B n k， 3 7 2 0のサブルートまでのパス上のノードキーの更新を行ない有効化キープ口ヅクを 生成して更新サブ E KBを生成する。 更新対象となるノードキーは、 図 38 ( c ) のサブルート 3 72 1からリボークカテゴリツリーの頂点ノードを構成する末端 ノード 37 3 1に至るパス上のノードキ一である。 すなわち、 ノード 372 1， 3724, 3 725 , 37 3 1のノードキーが更新対象となる。 これら各ノード のノードキーを更新してカテゴリヅリー B nk， 3 720の新たな更新サブ E K Bを生成する。
あるいは、 カテゴリヅリ一 B nk， 3720は、 下位カテゴリヅリー C n， 3 730のリボークを実行する場合、 カテゴリツリー Cnk, 3730の頂点ノー ド 3 73 1に対応するカテゴリヅリー B nk, 3720の末端ノ一ド 373 1は 更新せず、 そのリボークカテゴリヅリー 3 73 0からカテゴリツリー B nk， 3 720のサブル一トまでのパス上の末端ノード 3 73 1を除くノードキーの更新 を行ない有効化キープ口ヅクを生成して更新サブ E KBを生成してもよい。
さらに、 カテゴリヅリ一 B nk, 3 72 0が更新した有効化キーブロック （サ ブ EKB) は、 上位カテゴリヅリーに送信される。 この場合、 上位カテゴリッリ 一はカテゴリヅリー An n, 37 1 0であり、 カテゴリヅリー: B nk， 372 0 の頂点ノード 372 1を末端ノ.一ドとして有するカテゴリヅリーである。
カテゴリヅリ一 Ann, 37 1 0は、 下位カテゴリヅリー B n k, 3720か ら有効化キーブロック （サブ EKB) を受領すると、 そのキーブロックに含まれ るカテゴリツリー B nk， 3720の頂点ノード 372 1に対応するカテゴリヅ リ一Ann, 3 7 1 0の末端ノード 3 72 1を、 下位カテゴリツリー B nk, 3 720において更新されたキーに設定して、 自身のカテゴリヅリ一 Ann, 3 7 1 0のサブ E K Bの更新処理を実行する。 図 38 (d)にカテゴリツリー An η , 37 1 0のツリー構成を示す。 カテゴリツリー Ann, 3 7 1 0において、 更新 対象となるノードキーは、 図 38 (d) のサブルート 37 1 1から更新サブ EK Bを送信してきたカテゴリヅリーのノード 3 72 1に連なるパスを構成する各ノ ード 37 1 1， 37 14 , 37 1 5のノ一ドキーである。 これら各ノードのノー ドキーを更新してカテゴリヅリ一 Ann, 3 7 1 0の新たな更新サブ E K Bを生 成する。
これらの処理を順次、 上位のカテゴリヅリーにおいて実行し、 図 30 (b) で 説明したルートカテゴリヅリーまで実行する。 この一連の処理により、 カテゴリ ツリーのリボーク処理が完結する。 なお、 それぞれのカテゴリツリーにおいて更 新されたサブ E KBは、 最終的にキ一発行センタ一 （KD C) に送信され、 保管 される。 キ一発行センタ一 （KD C) は、 すべてのカテゴリヅリーの更新サブ E KBに基づいて、 様々な EKBを生成する。 更新 EKBは、 リポークされたカテ ゴリッリーに属するデバイスでの復号が不可能な暗号化キープ口ックとなる。 カテゴリヅリ一のリボーク処理のシーケンス図を図 3 9に示す。 処理手順を図 39のシーケンス図に従って説明する。 まず、 カテゴリヅリーをリボークしょう とするカテゴリヅリー管理カテゴリヅリ一 （E— E n) は、 カテゴリツリー管理 カテゴリツリー （E— E n) 内のリボーク対象の末端ノード'を排除するために必 要なキー更新を行ない、 カテゴリツリー管理カテゴリツリー （E— En) の新た なサブ EKB (E) を生成する。 更新サブ EKB (E) は、 上位カテゴリヅリ一 に送付される。 更新サブ E KB (E) を受領した上位 （親） カテゴリツリー （P 1一 En) は、 更新サブ E KB (E) の更新頂点ノードに対応した末端ノードキ 一の更新および、 その末端ノードからサブルートに至るパス上のノードキーを更 新した更新サブ EKB (P 1 ) を生成する。 これらの処理を順次、 上位カテゴリ ヅリーにおいて実行して、 最終的に更新されたすベてのサブ E KBがキー発行セ ン夕ー （KD C) に格納され管理される。 キー発行センター （KD C) は、 すべ てのカテゴリヅリーの更新サブ E KBに基づいて、 様々な E KBを生成する。 更 新 E KBは、 リボークされたカテゴリッリーに属するデバイスでの復号が不可能 な暗号化キープ口ックとなる。
図 40にリポークされた下位カテゴリヅリ一と、 リポークを行なった上位カテ ゴリヅリーの対応を説明する図を示す。 上位カテゴリツリーの末端ノード 3 9 0 1は、 カテゴリヅリ一のリボークにより更新され、 上位カテゴリヅリーのヅリー における末端ノード 3 9 0 1からサブルートまでのパスに存在するノードキーの 更新により、 新たなサブ E K Bが生成される。 その結果、 リボークされた下位力 テゴリヅリ一の頂点ノ一ド 3 9 0 2のノードキ一と、 上位カテゴリヅリ一の末端 ノード 3 9 0 1のノードキーは不一致となる。 カテゴリヅリーのリボーク後にキ 一発行センタ一 （K D C ) によって生成される E K Bは、 上位カテゴリヅリーに おいて更新された末端ノード 3 9 0 1のキーに基づいて生成されることになるの で、 その更新キ一を保有しない下位カテゴリヅリーのリーフに対応するデバイス は、 キー発行センタ一 （K D C ) によって生成される E K Bの復号ガ不可能にな る。
なお、 上述の説明では、 デバイスを管理する最下段のカテゴリツリーのリボー ク処理について説明したが、 ヅリーの中段にあるカテゴリヅリー管理カテゴリッ リーをその上位カテゴリヅリーがリポークする処理も上記と同様のプロセスによ つて可能である。 中段のエンティティ管理カテゴリヅリーをリボークすることに より、 リボークされたカテゴリツリー管理カテゴリヅリーの下位に属するすべて の複数カテゴリヅリーおよびデバイスを一括してリボーク可能となる。
このように、 カテゴリヅリー単位でのリボークを実行することにより、 1つ 1 つのデバイス単位で実行するリボーク処理に比較して簡易なプロセスでのリボー ク処理が可能となる。
[カテゴリヅリーのケィパピリティ管理]
次に、 カテゴリツリー単位でのキー配信ヅリ一構成において、 各エンティティ の許容するケィパピリティ（Capabi l ity)を管理して、 ケィパピリティに応じたコ ンテンヅ配信を行なう処理構成について説明する。 ここでケィパピリティ とは、 例えば特定の圧縮音声データの復号が可能であるとか、 特定の音声再生方式を許 容するとか、 あるいは特定の画像処理プログラムを処理できる等、 デバイスがど のようなコンテンヅ、 あるいはプログラム等を処理できるデバイスであるか、 す なわちデバイスのデータ処理能力の定義情報である。
図 4 1にケィパピリティを定義したカテゴリヅリー構成例を示す。 キー配信ヅ リ一構成の最頂点ににル一トノードが位置し、 下層に複数のカテゴリヅリーが接 続されて各ノードが 2分岐を持つヅリー構成である。 ここで、 例えばカテゴリヅ リー 4 0 0 1は、 音声再生方式 A， B , Cのいずれかを許容するケィパピリティ を持つカテゴリヅリーとして定義される。 具体的には、 例えばある音声圧縮プロ グラム一 A、 B、 または C方式で圧縮した音楽データを配信した場合に、 カテゴ リツリー 4 0 0 1以下に構成されたカテゴリヅリーに属するデバイスは圧縮デ一. タを伸長する処理が可能である。
同様にカテゴリヅリー 4 0 0 2は音声再生方式 Bまたは C、 カテゴリツリー 4 0 0 3は音声再生方式 Aまたは B、 カテゴリヅリー 4 0 0 4は音声再生方式 B、 カテゴリツリー 4 0 0 5は音声再生方式 Cを処理することが可能なケィパビリテ ィを持つカテゴリツリーとして定義される。
一方、 カテゴリヅリ一 4 0 2 1は、 画像再生方式 p , q , rを許容するカテゴ リヅリーとして定義され、 カテゴリツリー 4 0 2 2は方式 p， qの画像再生方式、 カテゴリヅリー 4 0 2 3は方式 pの画像再生が可能なケィパピリティを持つカテ ゴリヅリーとして定義される。
このような各カテゴリヅリーのケィパピリティ情報は、 キー発行セン夕一 （K D C ) において管理される。 キー発行センター （K D C ) は、 例えばあるコンテ ンヅプロバイダが特定の圧縮プログラムで圧縮した音楽データを様々なデバイス に配信したい場合、 その特定の圧縮プログラムを再生可能なデバイスに対しての み復号可能な有効化キ一ブロック （E K B ) を各カテゴリヅリーのケィパビリテ ィ情報に基づいて生成することができる。 コンテンヅを提供するコンテンツプロ バイダは、 ケィパピリティ情報に基づいて生成した有効化キープ口ック （E K B ) によって暗号化したコンテンヅキ一を配信し、 そのコンテンツキーで暗号化した 圧縮音声データを各デバイスに提供する。 この構成により、 データの処理が可能 なデバイスに対してのみ特定の処理プログラムを確実に提供することが可能とな る。
なお、 図 4 1では全てのカテゴリヅリーについてケィパピリティ情報を定義し ている構成であるが、 図 4 1の構成ようにすベてのカテゴリツリーにケィパピリ ティ情報を定義することは必ずしも必要ではなく、 例えば図 4 2に示すようにデ バイスが属する最下段のカテゴリヅリ一についてのみケィパピリティを定義して、 最下段のカテゴリヅリーに属するデバイスのケィパピリティをキ一発行セン夕一 (KD C) において管理して、 コンテンツプロバイダが望む処理の可能なデバイ スにのみ復号可能な有効化キーブロック （EKB) を最下段のカテゴリヅリーに 定義されたケィパピリティ情報に基づいて生成する構成としてもよい。 図 42で は、 末端ノードにデバイスが定義されたカテゴリツリー 4 1 0 1 =41 0 5にお けるケィパピリティが定義され、 これらのカテゴリツリーについてのケィパピリ ティをキ一発行センター （KD C) において管理する構成である。 例えばカテゴ リヅリー 4 1 0 1には音声再生については方式 B、 画像再生については方式 rの 処理が可能なデバイスが属している。 カテゴリヅリー 41 02には音声再生につ いては方式 A、 画像再生については方式 qの処理が可能なデバイスが属している 等である。
図 43にキ一発行センター （KD C) において管理するケィパピリティ管理テ —ブルの構成例を示す。 ケィパピリティ管理テーブルは、 図 43 (a) のような データ構成を持つ。 すなわち、 各カテゴリツリーを識別する識別子としてのカテ ゴリヅリー I D、 そのカテゴリヅリーに定義されたケィパピリティを示すケィパ ピリティ リスト、 このケィパピリティ リストは図 43 (b) に示すように、 例え ぱ音声データ再生処理方式 （A) が処理可能であれば [1 ]、 処理不可能であれは [0]、 音声データ再生処理方式 （B) が処理可能であれば [1 ]、 処理不可能で あれは [ 0 ] …等、 様々な態様のデータ処理についての可否を 1ビッ トづっ [ 1 ] または [0] を設定して構成されている。 なお、 このケィパピリティ情報の設定 方法はこのような形式に限らず、 カテゴリヅリ一の管理デバイスについてのケィ パピリティを識別可能であれば他の構成でもよい。
ケィパピリティ管理テ一ブルには、 さらに、 各カテゴリツリーのサブ E KB、 あるいはサブ E KBが別のデ一夕ベースに格納されている場合は、 サブ E KBの 識別情報が格納され、 さらに、 各カテゴリヅリーのサブルートノード識別データ が格納される。
キー発行セン夕一 （KD C) は、 ケィパピリティ管理テーブルに基づいて、 例 えば特定のコンテンツの再生可能なデバイスのみが復号可能な有効化キープ口ッ ク （EKB) を生成する。 図 44を用いて、 ケィパビリティ情報に基づく有効化 キープ口ックの生成処理について説明する。
まず、 ステップ S 430 1において、 キー発行センタ一 （KD C) は、 ケィパ ピリティ管理テーブルから、 指定されたケィパピリティを持つカテゴリヅリーを 選択する。 具体的には、 例えばコンテンツプロバイダが音声データ再生処理方式 Aに基づく再生可能なデータを配信したい場合は、 図 43 (a) のケィパビリテ ィ リストから、 例えば音声データ再生処理 （方式 A) の項目が [ 1 ] に設定され たカテゴリッリ一を選択する。
次に、 ステップ S 4302において、 選択されたカテゴリッリ一によつて構成 される選択カテゴリヅリー I Dのリス トを生成する。 次に、 ステップ S 43 0 3 で、 選択カテゴリツリー I Dによって構成されるツリーに必要なパス （キー配信 ヅリー構成のパス） を選択する。 ステップ S 4304では、 選択カテゴリヅリ一 I Dのリストに含まれる全てのパス選択が完了したか否かを判定し、 完了するま で、 ステップ S 4303においてパスを生成する。 これは、 複数のカテゴリヅリ 一が選択された場合に、 それぞれのパスを順次選択する処理を意味している。 選択カテゴリ ヅリー I Dのリストに含まれる全てのパス選択が完了すると、 ス テヅプ S 430 5に進み、 選択したパスと、 選択カテゴリヅリーによってのみ構 成されるキー配信ヅリー構造を構築する。
次に、 ステップ S 430 6において、 ステップ S 430 5で生成したヅリー構 造のノードキーの更新処理を行ない、 更新ノードキ一を生成する。 さらに、 ヅリ ―を構成する選択カテゴリツリーのサブ E K Bをケィパピリティ管理テーブルか ら取り出し、 サブ EKBと、 ステップ S 43 0 6で生成した更新ノードキーとに 基づいて選択カテゴリツリーのデバイスにおいてのみ復号可能な有効化キープ口 ヅク （EKB) を生成する。 このようにして生成した有効化キーブロック （EK B) は、 特定のケィパピリティを持つデバイスにおいてのみ利用、 すなわち復号 可能な有効化キーブロック （EKB) となる。 この有効化キーブロック （EKB) で例えばコンテンツキ一を暗号化して、 そのコンテンヅキーで特定プログラムに 基づいて圧縮したコンテンツを暗号化してデバイスに提供することで、 キー発行 センター （KD C) によって選択された特定の処理可能なデバイスにおいてのみ コンテンヅが利用される。
このようにキー発行センター （KD C) は、 ケィパピリティ管理テーブルに基 づいて、 例えば特定のコンテンツの再生可能なデパイスのみが復号可能な有効化 キ一プロヅク （EKB) を生成する。 従って、 新たなカテゴリツリーが登録され る場合には、 その新規登録カテゴリヅリーのケィパビリティを予め取得すること が必要となる。 このカテゴリヅリー新規登録に伴うケィパピリティ通知処理につ いて図 45を用いて説明する。
図 45は、 新規カテゴリヅリーがキー配信ヅリー構成に参加する場合のケィパ ピリティ通知処理シーケンスを示した図である。
新たにツリー構成中に追加される新規 （子） カテゴリツリー （N— En) は、 上位 （親） カテゴリヅリー （P— E n) に対して新規登録要求を実行する。 なお、 各カテゴリヅリ一は、 公開鍵暗号方式に従った公開鍵を保有し、 新規カテゴリヅ リ一は自己の公開鍵を登録要求に際して上位カテゴリヅリー （P— En) に送付 する。
登録要求を受領した上位カテゴリツリー （P— E n) は、 受領した新規 （子） カテゴリ ヅ リー （N— E n ) の公開鍵を証明書発行局 （ C A ： Certificate Authority) に転送し、 C Aの署名を付加した新規 （子） カテゴリヅリ一 （N— E n) の公開鍵を受領する。 これらの手続きは、 上位カテゴリヅリ一 （P— E n) と新規 （子） カテゴリツリー （N— E n) との相互認証の手続きとして行われる。 これらの処理により、 新規登録要求カテゴリツリーの認証が終了すると、 上位 カテゴリヅリ一 （P— En) は、 新規 （子） カテゴリヅリー （N— En) の登録 を許可し、 新規 （子） カテゴリヅリ一 （N— E n) のノードキーを新規 （子） 力 テゴリヅリー （N— E n) に送信する。 このノードキーは、 上位カテゴリヅリ一 (P— En) の末端ノードの 1つのノードキーであり、 かつ、 新規 （子） カテゴ リツリー （N— E n) の頂点ノード、 すなわちサブルートキーに対応する。
このノードキー送信が終了すると、 新規 （子） カテゴリヅリー （N— E n) は、 新規 （子） カテゴリヅリー （N— E n) のヅリー構成を構築し、 構築したツリー の頂点に受信した頂点ノードのサブルートキーを設定し、 各ノード、 リーフのキ —を設定して、 カテゴリヅリー内の有効化キーブロック （サブ EKB) を生成す る。 一方、 上位カテゴリツリー （P— E n) も、 新規 （子） カテゴリツリー （N —E n)の追加により、有効化する末端ノードを追加した上位カテゴリツリー（P 一 E n) 内のサブ E KBを生成する。
新規 （子） カテゴリヅリ一 （N— E n) は、 新規 （子） カテゴリヅリー （N— En)内のノードキー、 リーフキーによって構成されるサブ EKBを生成すると、 これを上位カテゴリツリー （P— En) に送信し、 さらに、 自己のカテゴリッリ 一で管理するデバイスについてのケィパピリティ情報を上位カテゴリヅリーに通 知する。
新規 （子） カテゴリツリー （N— E n) からサブ EKBおよびケィパピリティ 情報を受信した上位カテゴリヅリー （P— En) は、 受信したサブ E KBとケィ パビリティ情報と、 上位カテゴリヅリー （P— En) の更新したサブ EKBとを キー発行センター （KD C ： Key Distribute Center) に送信する。
キー発行センター （KD C) は、 受領したカテゴリツリーのサブ EKBおよび ケィパピリティ情報とを図 43で説明したケィパピリティ管理テーブルに登録し、 ケィパピリティ管理テーブルを更新する。 キー発行センター （KD C) は、 更新 したケィパピリティ管理テーブルに基づいて、 様々な態様の EKB、 すなわち特 定のケィパピリティを持つカテゴリヅリ一あるいはデバイスのみが後号可能な E KBを生成することが可能となる。
[E KBタイプ定義リストを使用した E KB管理構成]
次に、 1以上の選択されたカテゴリツリーにおいて復号可能な E KBを生成し て各カテゴリツリーに属するデバイスに共通に使用可能な E K Bを提供する構成 において、 どのカテゴリヅリ一で処理可能、 すなわち復号可能であるかを示す E KBタイプ定義リストを使用した構成について説明する。
本構成においては、 キー発行センター （KD C) は、 コンテンツプロバイダな どの EKBの使用、 発行処理を望む E KBリクエス夕から E KB発行要求を受領 する。 E KB発行要求には E KBタイプ定義リストに定義された E KBタイプを 示す E KBタイプ識別ナンパ一が含まれ、 キー発行センター （KD C) は、 EK Bタイプ識別ナンバーに従って 1または複数のカテゴリヅリ一において処理 （復 号） 可能な EKBを生成する。 EKBの生成に際しては、 キ一発行セン夕一 （KD C) は、 EKBタイプ定義 リス トの E KBタイプ識別ナンバーに対応して設定された各カテゴリヅリ一のト ヅプノード識別子に基づき、 カテゴリヅリ一管理者としてのトヅプレベル · カテ ゴリ ' エンティティ （T L C E ： Top Level Category Entity) にサブ EKBの生 成を要求し、 各 T L CEの生成したサブ EKBを受領し、 複数のサブ EKBの合 成処理を実行して複数のカテゴリヅリ一において処理可能な E KBを生成する。 本構成においては、 コンテンツプロバイダ （CP) などの EKBの発行要求者 は、 E KBタイプ定義リス トに基づいて特定のカテゴリッリーの選択を実行する ことが可能となる。 コンテンツプロバイダ（CP)などの E KBの発行要求者は、 E K Bタイプ定義リストを参照して特定カテゴリツリーにおいて処理可能な E K Bの発行をキー発行センター （KD C) に依頼する。 キー発行センタ一 （KD C) は、 E KB発行要求に基づいて、 選択されたカテゴリヅリーの管理エンティティ に対してサブ E K B発行要求を行ない、 各選択されたカテゴリヅリ一の管理ェン ティティは、 管理ェンティティのリポークされていない正当なデバイスにおいて のみ処理可能なサブ EKBを生成してキー発行センター （KD C) に送信する。 キー発行センター （KD C) は、 1 以上のサブ E K Bを組み合わせて E K Bの発 行要求者の要求した選択カテゴリヅリーにのみ処理可能な E KBを生成して E K B発行要求者に提供する。 EKB発行要求者は、 キー発行センタ一 （KD C) か ら E KBを受領し、 E KBの処理によって取得可能なキーでのみ復号可能な暗号 化キー、 または暗号化コンテンツの配信を実行する。
まず、 以下の説明における構成エンティティについて簡単に説明する。
キー発行センター （KD C ： Key Distribution Center)
有効化キ ブロック （EKB) を発行し、 発行した EKBに関する EKBタイ プ定義リス トを管理する。
トップレベル 'カテゴリ 'エンティティ （T L CE： Top Level Category Entity) あるカテゴリッリーを管理するエンティティ。 たとえば記録デパイスのフォー マヅ トホルダ一。 カテゴリヅリーを管理し、 管理下のカテゴリヅリー内のデバイ スにおいて処理 （復号） 可能な E KBであるサブ E KBを生成し、 キー発行セン 夕一 （KD C) に提出する。 E KB · リクエス夕 （EKB requester)
たとえば、 電子コンテンツ提供 （E CD ： Electronic Content Distribution) サービスを実行するコンテンヅプロバイダ （CP) など、 画像、 音声、 プロダラ ムなど様々のコンテンツをユーザデバイスに対して提供するエンティティ、 ある いは記録メディアのフォーマヅ トホルダーであり、 提供コンテンツの暗号化キー などに E KB処理によって取得可能なキーを用いる設定としてコンテンヅ、 メデ ィァを提供する。 この際に用いる E KBの発行要求をキー発行センター（KD C) に対して要求する。
例えば、 コンテンヅプロバイダ （CP) は、 キー発行センター （KD C) の生 成した EKBのルートキー （Root Key) を用いて自分のコンテンヅを暗号化して 配信する。 記録メディアのフォーマヅ トホルダーは、 E K Bを記録メディァの製 造時に書きこんで配布し、記録されるコンテンヅがその E KBのル一トキー（Root Key) を用いて暗号化されるようにする。
(TL CEとカテゴリベースのヅリ一管理）
カテゴリベースのヅリー管理については、 前述したが、 トップレベル ' カテゴ リ -ェンティ 'ティ （T L C E ) とカテゴリヅリ一の関係について、 図 46を用い て説明する。
まず、 カテゴリは、 前述したように同じ性質を持ったデバイスの集合であり、 具体的には、 同じメーカー製のデバイス、 あるいは同じエンコードフォーマッ ト を扱えるデバイス等である。 図 46において、 A、 B、 C、 Dはそれそれカテゴ リヅリ一を示す。
図 46において、 最上段のルートヅリ一は、 例えば 8段構成 （ノード段数） で あり、 ル一トッリ一の最下段にカテゴリヅリーのトップノードが設定される。 力 テゴリヅリ一は、 複数が上位、 下位の関係になることが可能であり、 図 46にお いて、 カテゴリツリー Cは、 カテゴリヅリー Dの上位に対応する。
最上段のルートヅリーに直接連なるカテゴリヅリーをトヅプレベルカテゴリッ リーと呼び、 トップレベルカテゴリッリーを管理するエンティティをトヅプレベ ル ' カテゴリ ' エンティティ （TL CE) と呼ぶ。 図 46では、 A、 B、 Cがト ヅプレベルカテゴリであり、 これらを管理するエンティティがトップレベル · 力 テゴリ 'エンティティ （T L CE) である。 トップレベル ' カテゴリ 'ェンティ ティ （TL CE) は、 基本的に、 自己のヅリー以下全体を管理する責任がある。 つまり、 図 46のツリー Cを管理する T L C Eは、 ヅリ一 Cと同様ヅリ一 Dにつ いての管理も実行する。 D以下にさらに下層のカテゴリッリーが存在すればその 下層カテゴリツリー管理も行なう。 ただし、 例えば下層のカテゴリツリー Dを管 理する力テゴリエンティティ（Sub Category Entity)を置いて、 その責任と権利を 委譲することも可能である。
コンテンヅの利用を行なう記録再生装置などの各デバイスは、 トップレベル · カテゴリ 'エンティティ （TL CE) により、 あるヅリーのリーフにアサインさ れ、 そのリーフからルートに至るパスの間のいくつかのノードの鍵を所有する。 1つのデバィスが持つノードキーの組をデバイス .ノード .キ一（DNK : Device Node Key) と呼ぶ。 各デバイスが、 何個の鍵を持つか （DNKに何個の鍵が含ま れるか） はトヅプレベル · カテゴリ · エンティティ （TL CE) が決定する。 図 47にキー発行センター （KD C)、 トップレベル .カテゴリ ·エンティティ (TL CE) EKB · リクエスタ各エンティティの対応、 処理の概要を説明する 図を示す。
キー発行セン夕一 （KD C) 45 1 1は、 ヅリ一構成を用いた EKB配信シス テムの管理エンティティ 45 1 0として位置づけられる。 管理エンティティ 45 1 0には、 さらに、 E KBに対する署名処理を実行する認証局 （CA) 45 1 2 がある。
キー発行セン夕一 （KD C) 45 1 1は、 トップレベルカテゴリヅリーなどの サブヅリ一のキー管理を行ない、 後述する E KBタイプ定義リス トの管理、 EK Bの生成を実行する。 認証局 （C A) 45 1 2は、 キー発行センター （KD C) の生成した E KBに署名を実行するともに、 署名を施した秘密鍵に対応する公開 鍵を署名検証用の鍵として発行する。
キー発行センター （KD C) 45 1 1に対して E KBの発行要求を行なうのが E KBリクエス夕 4520である。 E KBリクエスタは、 例えばコンテンツを格 納した CD、 DVDなどのメディアを提供するコンテンツ格納メディアに関する コンテンヅプロバイダ（ C P)、電子コンテンヅの配信を実行するコンテンヅプロ バイダ（ C P )、 フラッシュメモリなどのス トレージシステムのフォーマツ トにつ いてのライセンスを提供するストレージシステムライセンサなどである。
これらの E KBリクエス夕 4520は、 それぞれの提供するメディア、 コンテ ンヅ、 ライセンスの使用に際し、 必要となるキーを EKB処理によって得られる キーとして設定した E KBをコンテンツ、 メディア、 ライセンスフォーマッ トな どに対応付けて提供する。 EKBは、 E KBリクエスタ 4520からキ一発行セ ンタ一（KD C) 45 1 1に対する E K B発行要求に従ってキー発行センター（K D C) 45 1 1が生成する。
EKBリクエスタ 452 0は、 キ一発行センター （KD C) 45 1 1に対する 発行要求の結果として受領した E KBをメディア製造者 4540、 デバイス製造 者 45 5 0に対して提供し、 E KBを格納したメディア、 またはデバイスをユー ザに対して供給する処理が可能である。 これらの E KBは、 例えば 1つまたは複 数のカテゴリヅリーにおいて処理可能な E KBとして生成される。
本システムでは、 複数、 例えば 2つあるいは 3以上のカテゴリヅリーにおいて 共通に処理可能な E K Bや、 唯一のカテゴリツリーにおいてのみ処理可能な E K Bなど、 様々なタイプの E KBが生成され、 使用される状況になる。 このような 様々なタイプの EKBについてリスト化したのが E KBタイプ定義リストである c EKBタイプ定義リストはキ一発行センター （KD C) が管理する。 EKBタイ プ定義リストについては、後段で詳細に説明する。 E KBリクエス夕 452 0は、 E KBタイプ定義リストの要求をキー発行センター （KD C) 45 1 1に要求し てリストを取得可能であり、 また、 リストのデータ変更があった場合は、 キー発 行センタ一 （KD C) 45 1 1から EKBリクエスタ 4520に対して通知され る。
トップレベル ' カテゴリ 'エンティティ （TL CE) 453 0は、 前述したよ うにルートヅリーに連なるカテゴリヅリ一の管理エンティティであり、 サブッリ 一のキー管理、 管理デバィス I Dと各デバイスに格納される E K B処理のための ノードキー · セヅ トであるデバイス ' ノード ' キー （DNK) との対応リストを 管理する。 さらに管理下のデバイスに対応するデバイスを製造するデバイス製造 者 4550に対して、 デバイス格納用のデバイス · ノード . キー （DNK) の生 成、 提供処理を実行する。
キー発行セン夕一 （KD C) 45 1 1が£1<3リクェスタ 4520から£1^8 発行要求を受信すると、 キー発行センター （KD C) 45 1 1は、 発行要求に従 つた E KBを生成する。 生成する E KBが例えば 2つのトップレベル . カテゴリ ヅリ一において処理可能な E KBであった場合は、 その 2つのトップレベル ' 力 テゴリ 'エンティティ （TL CE) 4530に対してサブ EKBの発行要求を送 信し、 サブ E K Bの発行要求を受信したトヅプレベル · カテゴリ ·エンティティ (TL CE) 4530はそれぞれのカテゴリヅリ一内の正当デバイスがルートキ —取得可能なサブ EKBを生成してキー発行センター （KD C) 45 1 1に送信 する。 キー発行セン夕一 （KD C) 45 1 1は、 T L C Eから受信した 1つまた は複数のサブ E K Bに基づいて E K Bを生成する。 サブ E KBに基づく EKB生 成処理については後段でさらに説明する。
ト ヅプレベル · カテゴリ · エンティティ （TL CE) 4530は、 EKBリ ク エス夕 452 0と同様、 E KBタイプ定義リス トの要求をキ一発行センター （K D C) 45 1 1に要求してリストを取得可能である。
トップレベル ' カテゴリ 'エンティティ （TL CE) 4530は、 さらに、 E K Bタイプ定義リストの自己のヅリーに関して定義されたタイプの削除要求をキ 一発行センター （KD C) 45 1 1に要求することができる。 例えば他のカテゴ リヅリーと共有の E KBとして定義された EKBタイプをリストから削除する要 求である。 トップレベル ' カテゴリ ' エンティティ （TL CE) 4530は、 さ らに、 自己の管理するツリーに関する変更があった場合には、 変更情報をキー発 行センター （KD C) 45 1 1に通知する。 これらの処理についてはフローを用 いて後段で説明する。
デバイス製造者 4550は、 2つの種類のデバイス製造者に区分される。 1つ は、 製造するデバイスにデバイスノードキー （DNK) と、 E KBの両データを 格納したデバイスを製造する DNKEデバイス製造者 45 5 1であり、 他方は、 デバイスにデバイスノードキー （DNK) のみを格納したデパイスを製造する D NKデバイス製造者 4552である。
図 48に図 47に示すキー発行セン夕一 （KD C)、 EKBリクエスタ、 トップ レベル ' カテゴリ ' エンティティ （T L C E ) それそれの構成例をプロヅク図と して示す。 キー発行センター （K D C ) は E K B発行情報処理装置、 E K Bリク エスタは E K B要求情報処理装置、 トップレベル . カテゴリ ·エンティティ （T L C E ) はカテゴリヅリ一管理情報処理装置として、 基本的に暗号通信可能なデ —タ処理装置として構成される。
各エンティティを構成する情報処理装置は、 それそれ他エンティティとの相互 認証、 データ通信時における暗号処理全般を司る暗号処理部を有する。 暗号処理 部内の制御部は、 認証処理、 暗号化/復号化処理等の暗号処理全般に関する制御 を実行する制御部である。 内部メモリは、 相互認証処理、 暗号化、 復号化処理等、 各種処理において必要となる鍵データ、識別データ等を格納する。識別デ一夕は、 例えば他エンティティとの相互認証処理等において用いられる。
暗号/復号化部は、 内部メモリに格納された鍵データ等を使用したデータ転送 時の認証処理、 暗号化処理、 復号化処理、 データの検証、 乱数の発生などの処理 を実行する。
ただし、 E K Bリクエス夕としての情報処理装置においては、 鍵の生成処理を 自装置内では実行しない構成も可能である。 この場合には、 鍵の生成に必要な構 成要素、 例えば乱数発生装置などを省略可能となる。 具体的には、 E K Bに含ま せるルートキーを自ら生成して生成したルートキ一を含む E K Bの生成をキー発 行センターに要求する E K Bリクエス夕としての情報処理装置はルートキ一を生 成するための手段が必要となるが、 E K Bに含ませるルートキーを自ら生成せず、 キー発行センタ一にルートキーの生成処理を要求し、 キー発行センター（K D C ) において生成したルートキーを含む E K B生成をキー発行センターに要求する E K Bリクエスタとしての情報処理装置は乱数発生装置などの鍵生成処理に伴う構 成要素が省略可能である。
暗号処理部の内部メモリは、 暗号鍵などの重要な情報を保持しているため、 外 部から不正に読み出しにくい構造にしておく必要がある。従って、暗号処理部は、 外部からアクセスしにくい構造を持った例えば半導体チップで構成された耐タン パメモリとして構成される。
各エンティティは、 これらの暗号処理機能の他に、中央演算処理装置（C P U ： Central Processing Unit) RAM (Random Access Memory)^ R 0 M(Read Only Memory)^ 入力部、 表示部、 デ一夕ベース I /F、 データベースを備えている。 中央演算処理装置 （CPU : Central Processing Unit), RAM (Random Access Memory), R O M (Read Only Memory)は、 各エンティティ本体の制御系として機能 する構成部である。 RAMは、 CPUにおける各種処理用の主記憶メモリとして 使用され、 C P ϋによる処理のための作業領域として使用される。 ROMは、 C P Uでの起動プログラム等が格納される。
各エンティティを構成する情報処理装置のデータベースまたはその他の記憶手 段には、それそれ各エンティティの管理するデータ、例えばキー発行センター（K D C) であれば、 発行した E KBに関する管理データ、 さらに E KBタイプ定義 リス トなどが格納され、 また、 トヅプレベル · カテゴリ · エンティティ （TL C E) のデータベースには、 管理デパイスとデバイスノードキー （DNK) の対応 など、 カテゴリヅリーに属するデバイスの管理データが格納され、 E KBリクェ ス夕のデータベースには、 提供コンテンヅとコンテンヅに対して使用されている E KBとの関係を対応付けた管理データ、 コンテンツの提供先デバイスについて の管理データなどが格納される。 なお、 E KBタイプ定義リス トは、 EKBリク エスタ、 トップレベル ' カテゴリ ■エンティティ （T L C E) を構成する情報処 理装置中にも格納し参照可能な状態とする構成が好ましい。 あるいは、 EKBリ クエスタ、 トヅプレベル · カテゴリ ' エンティティ （TL CE) のアクセス可能 なキ一発行センター （KD C) の管理するウェブ （Web)サイ トに置く構成として もよい。
前述したように、 デバイスは、 EKB処理（復号） のためにデバイス ·ノード · キ一 （DNK ： Device Node Key) を使用する。 1つのデバイスが持つデバイス - ノード . キ— （DNK) について図 49を用いて説明する。 図 49に示すヅリー は 1つのカテゴリヅリーを示し、 最下段がデバイスが対応付けられたリーフであ り、 例えばトップレベル ' カテゴリ ' エンティティ （T L C E) の管理ヅリーに 相当する。 さらに上段にはル一トヅリー （ex. 8段構成） が連なっている。 こ こでデバイスは、 図 49に示すようにデバイスから上段に至るパス上のノードキ 一を有する。 これらのキーセヅ トをデバイス ' ノード ' キー （DNK) として保 有し、 デバイス ' ノード ' キー （DNK) を用いて E KBの復号を行なう。
基本的に、 1つのデバイスが 1つのリーフに重ならないようにアサインされる。 例外として、 たとえば P Cソフ トなどのソフ トウェアをリーフに対応付ける場合 は、 1つのバ一ジヨンのソフトウェア 'パヅケージがすべて 1つのリーフにアサ インされる場合もある。 これも TL CEが決める。 つまり、 デバイスをどのよう にリーフにアサインし、 どのノードキ一を持たせるかは T L C Eが決める。
トップレベル · カテゴリ ·エンティティ （T LCE) は、 デバイス自体の提供 業者 （メーカ一） である場合もあり、 製造デバイスに対して予めデバイス · ノー ド · キー （DNK) を格納してユーザに提供 （販売） することが可能である。 す なわち、 記録再生装置などのデバイスに対して予め、 ある特定のカテゴリツリー のノードキーのセッ トをデバイス . ノード . キー （DNK) としてメモリに格納 してユーザに提供 （販売） することが可能である。
( E K B夕ィプ定義リスト）
カテゴリ単位での E KB配信については、 すでに説明した通りであるが、 複数 のカテゴリに共通の E KB、 すなわち異なるカテゴリツリーに属するデバイスに おいて処理可能な E KBを生成して発行した場合には、 いくつかの問題点が発生 する場合がある。
例えば、 ある再書き込み可能なメディア （記録媒体） 例えば、 携帯型フラッシ ュメモリのフォーマッ トのライセンシー （ライセンス受領者） として、 A社と B 社の異なる 2社が存在し、 メディア （携帯型フラッシュメモリ） のライセンサー (ライセンス許諾者） であるメーカ一がトップレベルカテゴリとして存在し、 そ の下に A社の管理するカテゴリッリーと B社の管理するカテゴリヅリーがある構 成において、 A社と B社は相互のデバイスに互換性を持たせ、 様々な配布コンテ ンヅを共通に利用することを可能とするため、 A社のカテゴリッリーと B社の力 テゴリヅリ一の 2つのカテゴリヅリーの所属デバイスにおいて処理 （復号） 可能 ' な E KBをキー発行センター （KD C) において生成し発行する。
このような状況で A社の管理するカテゴリヅリーに属する 1つのデバイスのデ バイス ' ノード ' キー （DNK) が漏洩してしまゔと、 そのデバイスノードキー (DNK) を利用して A社、 B社の相互のデバイスにおいて利用可能とした配布 コンテンヅがすべて不正に利用されてしまう可能性が発生することになる'。 利用 を排除するためには、 リポーク処理としての E KB更新処理が必要となるが、 こ の場合、 A社のカテゴリツリーに関するリボーク処理ではなく、 A社および B社 の 2つのカテゴリッリーに共通の E KBが存在するため、 E KB更新処理は A社 および B社の 2つのカテゴリヅリーに関して実行することが必要となる。
このように、 複数のカテゴリヅリーに共通の E KBを生成して提供した場合、 1つのカテゴリヅリー内でのリボーク処理、 E KB更新処理のみではなく、 共通 する E KBを使用するすべての他のカテゴリヅリーにおいてリボークに伴う E K B更新処理を実行することが必要となる。 これは B社にとっては、 自己の管理す るデバイスと異なる他の管理カテゴリヅリ一の影響を受けることになり、 処理負 荷が高まることになつてしまう。
このような状況を解決するため、 複数のカテゴリにおいて共通に使用可能な E KBの発行の許可権限を、 それぞれのカテゴリを管理するカテゴリ 'ェンティテ ィが有する構成とする。 つまり、 互換性をとるために、 相手のカテゴリに属する デバイスの不具合によって引き起こされる自分のカテゴリ内デバイスへのリスク を許容できる場合にのみ、 互換性をとる E KBの発行を認め、 リスクが許容でき ない場合は、共通に使用可能な E KBの発行、 または使用を認めないものとする。 このような処理を行なおうとすると、 複数、 例えば 2つあるいは 3以上のカテ ゴリヅリーにおいて共通に処理可能な E K Bや、 唯一のカテゴリヅリーにおいて のみ処理可能な E KBなど、 様々なタイプの E KBが生成され、 使用される状況 になる。 このような様々なタイプの EKBについてリスト化したのが EKBタイ プ定義リス トである。 図 5 0に E KBタイプ定義リス トの例を示す。 EKBタイ プ定義リストはキー発行セン夕一 （KD C) が記録媒体に記録して管理する。 ま た、 E KBリクエス夕、 TL CEに対しても必要に応じて提供または閲覧可能な 状態におかれる。
図 50に示すように、 E KBタイプ定義リス トは、 「E KBタイプ識別ナンパ ―」、 「ノード」、 「説明」の各フィールドを有し、 「E KBタイプ識別ナンバー」は、 E KBタイプ定義リストにリス トアップされた様々な態様の E KBを識別するナ ンバーであり、 識別ナンバーが異なれば、 その EKBを処理可能なカテゴリヅリ 一またはその組み合わせが異なる構成となっている。
「ノード」 フィールドは、 EKBを適用可能なカテゴリヅリーのトップノード I Dを記録するフィールドである。 例えば E KB夕イブ識別ナンバー ： 1の EK Bは、 MS (MemoryStick：メモリスティ ック） のカテゴリヅリ一のトップノード I Dが記録される。 また、 E K Bタイプ識別ナンバー ： 3の E KBは、 M S (MemoryStick：メモリスティ ック）のカテゴリツリーのトヅプノード I Dと PH Sのカテゴリッリ一のトップノード I Dが記録される。
「説明」 フィールドは、 EKBタイプ定義リストにリス トアップされた様々な 態様の EKBの説明を記録するフィールドであり、 例えば E KBタイプ識別ナン バ一： 1の E KBは、 MS (MemoryStick：メモリスティ ック） 用の EKBである ことを示している。 また、 E K Bタイプ識別ナンパ一： 3の EKBは、 M S (MemoryStick:メモリスティ ヅク） と P H Sのカテゴリヅリ一のデバィスに共通 に使用可能な E KBであることを示している。
図 50に示す E KBタイプ定義リス トはキー発行センター （KD C) が管理す る。 また、 E KBの処理により取得可能なキーによって暗号化した暗号化キーま たは暗号化コンテンヅ等の暗号化データ配信を行なおうとするエンティティ、 例 えばコンテンツプロバイダは、図 50に示す E K Bタイプ定義リストを参照して、 コンテンツの提供対象となるデバイスを含むカテゴリヅリーによって処理可能な EKBタイプを選択し、 その E KBタイプ識別ナンバーを指定して、 キー発行セ ン夕一 （KD C) に E KB生成処理を依頼する。
ただし、 E KBタイプ定義リストに対する様々なタイプの E KB登録処理にお いては、 登録対象となるカテゴリヅリーのトヅプレベル ' カテゴリ 'ェンティテ ィ （T L CE) の承認が必要となる。 例えばカテゴリツリー Aの TL CE— Aが 他のカテゴリ と共有する E KBの発行を拒否すれば、 カテゴリヅリー Aと他の力 テゴリツリーの共有となる EKBのタイプは EKBタイプ定義リストに登録され ない。
例えばカテゴリツリー Aの T L C E— A、 カテゴリヅリー Bの T L C E— B、 カテゴリヅリ一 Cの T L C E— Cの各々が共有の E KBの発行を承認すれば、 こ れら 3つのカテゴリッリーにおいて処理可能な共通の E K Bのタイプが EKB夕 ィプ定義リストに登録され、 例えばコンテンップロパイダがその登録タイプを示 す E KBタイプ識別ナンバーを指定してキー発行センター （KD C) に EKB生 成処理を依頼することが可能となる。
つまり、 E KBタイプ定義リストに新たな E KBタイプを登録し、 その EKB タイプに対応する E KBタイプ識別ナンバー ¾定義するためには、 下記の処理が 必要となる。
( 1 ) 定義しょうとする E KB夕ィプ識別ナンバーに対応する E KBの適用対 象となるカテゴリを管理するすべての T L CEが EKBタイプ登録リクエストを キー発行センター （KD C) に送る。
(2) キー発行センタ一 （KD C) は要求にある登録対象となる EKBを処理 可能な 1以上のカテゴリヅリーのトヅプレベル ' カテゴリ 'エンティティ （TL CE) のすべてが上記の E KBタイプ登録リクエストを送ってきたことを確認し た後に、 新たな EKBタイプ識別ナンバーを定義し、 EKBタイプ定義リストに 加える。
(3) キー発行センター （KD C) は EKBタイプ定義リストに変更があった ことを知らせるため、 E KBタイプ定義リスト変更通知を全 T L C Eおよび E K
Bリクエスタに送る。
なお、 E KBタイプ定義リストは、 全 T L C Eおよび E KBリクエスタに送ら れ、 またウェブ （Web)サイ トに置かれるなどして全 TL CEおよび E KBリクェ ス夕に公開される。 従って、 T L CEおよび E KBリクエスタは、 常に最新の E
KBタイプ定義リス トに登録された E KBタィプ情報を取得することが可能とな る。
(E KBタイプ登録処理）
E KBタイプ定義リス トに新たな E KBタイプを登録する際に、 キー発行セン 夕一 （KD C) の実行する処理を説明する処理フローを図 5 1に示す。 まず、 キ 一発行センター （KD C) は、 新たな E KBタイプの登録要求を行なう T L C E からの EKBタイプ登録リクエス トを受信 （S 1 0 1) する。 TLCEからの E KBタイプ登録リクエストには、 登録要求 E KBが共通に使用可能とするカテゴ リ数が含まれる。 キー発行センター （KD C) は、 要求内のカテゴリ数に一致す る数のカテゴリに対応する TL CEから同様の EKBタイプ登録リクエストを受 領したか否かを判定 （S 1 02 ) し、 要求内のカテゴリ数に一致する数のカテゴ リに対応する T L C Eからの要求を受理したことを条件として、 E KBタイプ定 義リストに対して要求に従った新たな E KBタイプを登録し、リストの更新処理、 リストの更新通知処理 （S 1 0 3) を行なう。 更新通知処理は、 TLCEおよび E KBリクエスタに対して行われる。
このように、 キー発行センター （KD C) は、 EKBタイプ定義リス トに対す る E KBタイプ識別子の新規登録処理において、 登録予定の E KBタイプの処理 可能なカテゴリヅリーとして選択された 1以上のカテゴリヅリーを管理するすべ てのカテゴリ · エンティティの承認を条件として登録を行なう。
なお、 これらの処理において、 キー発行センター （KD C) と TLCE、 EK Bリクエス夕間の通信においては必要に応じて相互認証処理、 送信データの暗号 化処理が行われる。 また、 その他のメッセージ暗号化処理、 デジタル署名生成、 検証処理を行なう構成としてもよい。 なお、 公開鍵暗号方式に基づく認証あるい は暗号通信を実行する場合は、 各エンティティ間において予め公開鍵を保有し合 う手続きを行なっておく。
(E KBタイプ無効化処理）
たとえば、 あるカテゴリに属するすべての機器をリボークしなければならない ときには、 トップレベル · カテゴリ · エンティティ （T L C E) はそのカテゴリ が要素となっている E KBタイプを無効化する要求をキ一配信センタ一（KD C) に出す必要がある。 また、 トップレベル ' カテゴリ 'エンティティ （TL CE) は、 たとえばあるサービスを停止するなどの理由で、 現在登録されている EKB タイプを無効化する要求を KD Cに出すことができる。
この E KBタイプ無効化処理の流れを図 52の処理フローに従って説明する。 キー発行センター （KD C) は、 EKBタイプの無効化要求を行なう TL CEか らの E K Bタイプ無効化リクエストを受信 （S 20 1 ) する。 T L CEからの E KBタイプ無効化リクエス トを受信すると、 キー発行センター （KD C) は、 そ のリクエス トにより無効化される EKBタイプの要素となっているカテゴリを管 理する TL CEがそのリクエストの発信者であることを確認した上で、 EKB夕 ィプ定義リス ト内の無効化リクエストにおいて指定されたタイプに対応する E K Bタイプ識別ナンバーを無効化して E KBタイプ定義リス トを更新し、 リストの 更新通知処理 （S 2 02 ) を行なう。 更新通知処理は、 T L CEおよび EKBリ クエスタに対して行われる。
このように、 キー発行センタ一 （KD C) は、 EKBタイプ定義リストに登録 された E KBタイプ識別子の無効化処理において、 無効化予定の E KBタイプの 処理可能なカテゴリヅリ一として選択された 1以上のカテゴリヅリーを管理する 少なく とも 1つのカテゴリ ·エンティティの無効化要求を条件として無効化処理 を行なう。 この場合、 他のカテゴリ · エンティティの承認は必要としない。 なお、 これらの処理において、 キー発行センター （KD C) と TL CE、 E K Bリクエスタ間の通信においては必要に応じて相互認証処理、 送信データの暗号 化処理が行われる。 また、 その他のメッセージ暗号化処理、 デジタル署名生成、 検証処理を行なう構成としてもよい。 なお、 公開鍵暗号方式に基づく認証あるい は暗号通信を実行する場合は、 各エンティティ間において予め公開鍵を保有し合 う手続きを行なっておく。
( E K Bタイプ定義リスト変更通知処理）
たとえばあるカテゴリヅリ一内において、 デバイスリボケ一シヨン （デパイス 排除） や、 あるデバイスが格納した DNKを新しいものに交換するデバイスノー ドキー （DNK) の更新などのツリー内の状態を変化させる処理をそのカテゴリ ツリーを管理する T L CEが行った場合、 それらのデバイスを対象とする E K B を使用している E KBリクエスタまたは関連 T L CEに対して、 これらの処理が 起こったことを知らせる必要がある。
なぜならば、 デバイスリボケ一シヨンが起こったのにそれを知らせず、 コンテ ンヅプロバイダ （CP) が古い EKBを使いつづけてコンテンツを暗号化して配 信したとすると、 古い E K Bでは、 リボークされたデバイスにおいても E KB処 理 （復号） が可能であり、 コンテ,ンッの不正利用が続けられる可能性があるから である。 また、 バイスノードキー （DNK) の更新を行なった場合、 通常は置 きかえられた古い D NKは捨てられ、 デバイスは新しい D NKを持つことになる が、 この新しい； DNKに対応した EKBをコンテンヅプロバイダが使用しなけれ ば、 新しい DNKを持つデバイスは E KBを処理 （復号） することができなくな り、 コンテンツにアクセスできなくなってしまうからである。
このような弊害を避けるため、
*デバイスリボケーションなどの結果として、 E KBの夕グパートに変更が生じ た場合、
*デバイスノードキー（DNK)の更新などの結果として少なく ともひとつの機 器が持つ D NKの値に変更が生じた場合、
これらの場合には、 TL CEは、 ヅリー変更通知 （Tree Change Notification) をキ一発行センター （KD C) に送る必要がある。 ヅリー変更通知 （Tree Change Notification) には、 変更を要する E K Bタイプ定義リストに登録済みの E K B タイプ識別ナンパ一、 EKBタイプ識別ナンパ一に対応して登録されているどの カテゴリで起こつたかを示す情報と、 リポケ一シヨン、 DNK更新の何が起こつ たかという情報が含まれる。
E KBタイプ定義リスト変更通知処理の流れを図 53の処理フローに従って説 明する。 キー発行センター （KD C)は、 T L C Eからヅリー変更通知を受信（ S 30 1) する。 TL CEからのヅリー変更通知を受信すると、 キー発行センタ一 (KD C) は、 E KBタイプ定義リス トから、 そのカテゴリを要素に持つ E K B タイプ識別ナンバーを抽出し、 どの E KBタイプ識別ナンバーに、 どのような変 ィ匕 （ex. リポケーシヨンか、 DNK更新 （リプレイスメント） か） が起こった かの情報を持つ EKBタイプ定義リス ト変更通知をすベての TL CEおよび EK Bリクエスタに対して行なう。 なお、 これらの処理において、 キー発行センタ一 (KD C) と TL CE、 E KBリクエス夕間の通信においては必要に応じて相互 認証処理、 送信データの暗号化処理が行われる。 また、 その他のメッセージ暗号 化処理、 デジタル署名生成、 検証処理を行なう構成としてもよい。 なお、 公開鍵 暗号方式に基づく認証あるいは暗号通信を実行する場合は、 各ェ j ティティ間に おいて予め公開鍵を保有し合う手続きを行なっておく。
(E KBタイプ定義リスト要求）
トヅプレベル ' カテゴリ 'エンティティ （TL CE) や TL C E以外のサブ力 テゴリ 'エンティティ （S C E)、 あるいはコンテンツプロバイダ等の E K Bリク エス夕は、 最新版の E KBタイプ定義リストを知るために、 E KBタイプ定義リ ストの送付をキ一発行センター （KD C) に要求することができる。 キー発行セ ン夕ー （KD C) はこの要求に対して、 最新版の EKBタイプ定義リストを要求 者に送り返す。
EKBタイプ定義リスト要求処理の流れを図 54の処理フローに従って説明す る。 キー発行センター （KD C) は、 TL CE、 サブカテゴリ ' エンティティ、 または E KBリクエスタのいずれかから E KBタイプ定義リスト要求を受信 （S 40 1 )する。 E KBタイプ定義リス ト要求を受信すると、 キー発行センター（K D C) は、 最新の EKBタイプ定義リストを抽出し、 要求処理を行なったェンテ ィティに対して最新の E KBタイプ定義リス トを送信 （S 402 ) する。 なお、 これらの処理において、 キー発行センター（KD C) と T L C E、 サブカテゴリ . エンティティ、 E KBリクエスタ間の通信においては必要に応じて相互認証処理、 送信データの暗号化処理が行われる。 また、 その他のメッセージ暗号化処理、 デ ジタル署名生成、 検証処理を行なう構成としてもよい。 なお、 公開鍵暗号方式に 基づく認証あるいは暗号通信を実行する場合は、 各エンティティ間において予め 公開鍵を保有し合う手続きを行なっておく。
(EKB発行処理）
E KBの発行.処理は、 EKBリクエスタによる E KB発行要求に基づいて行わ れる。 E KBリクエス夕は、
[a] CD、 DVDなどの、 コンテンツ格納メディアを提供するコンテンツプ ロバイダ （CP)。
[b] 電子情報配信 （E CD ： Electronic Content Distribution) サービスを 提供するコンテンツプロバイダ。
[ c ] 記録システムのフォーマツ トホルダー。
など、 EKBの復号によって取得されるキーを用いてコンテンツの利用、 フォ 一マッ トの使用を可能とするサービス、 メディア、 デバイスを提供するェンティ ティである。
上記の [c] 記録システムのフォーマッ トホルダーには、
[ c 1 ]たとえば製造時に記録媒体に E KBを格納するようなフォーマツ トに おいて、 記録媒体の製造業社に取得した E K Bを与えるフォーマッ トホルダ一。
[c 2] たとえば製造時に記録デバイスに E KBを格納するようなフォーマツ トにおいて、 記録デバィスの製造業社に取得した EKBを与えるフォーマットホ ルダ一。
の 2種類のフォーマッ トホルダ一がある。
E KB発行処理の手順について、 以下説明する。
( 1 ) コンテンヅキ一の作成
まず、 コンテンツプロバイダなどの E KBリクエスタは、 自己の提供するコン テンヅ、 デバイス、 メディアに対応して使用されるコンテンヅキーを生成する。 例えば E K Bリクエスタが、
[a] CD、 DVDなどの、 コンテンヅ格納メディアを提供するコンテンヅプ ロバィダ （ C P)。
[b] 電子情報配信 （E CD ： Electronic Content Distribution) サービスを 提供するコンテンップロバイダ。
である場合、
生成するコンテンツキーは、 メディア上や電子情報配信 （E CD) サービスに おいて、 コンテンヅを守る （暗号化する） 鍵として使用される。
また、 E KBリクエスタが、
[ c 1 ]製造時に記録媒体に E KBを格納するようなフォーマツ トにおいて、記 録媒体の製造業社に取得した E KBを与えるフォーマツ トホルダー。
である場合、 コンテンヅキーは、 その記録媒体上に記録されるコンテンヅを守 る （暗号化する） 鍵として使用される。
さらに、 E KBリクエスタが、
[ c 2 ] 製造時に記録デバイスに E KBを格納するようなフォーマヅ トにおい て、 記録デバイスの製造業社に取得した E KBを与えるフォーマッ トホルダ一。 である場合、 コンテンヅキーは、 その記録デバイスを用いて記録されるコンテ ンヅを守る （暗号化する） 鍵として使用される。
なお、 コンテンヅキーを用いてコンテンツを保護するための暗号アルゴリズム などのメカニズムは、 各フォーマツトごとに任意に決めることができる。 ( 2 ) ルートキーの生成
E KBリクエスタは E KBの復号処理によって取得可能としたルートキーを生 成する。 なお、 E KBリクエスタは自らはルートキーを生成せず、 キ一発行セン 夕一 （KD C) に生成を依頼してもよい。 ルートキーはコンテンヅキ一を保護す る （暗号化する） ために使用される。 なおルートキ一を用いてコンテンヅキ一を 保護するための暗号アルゴリズムなどのメカニズムは、 各フォーマッ トごとに任 意に決めることができる。
(3) EKB発行要求
EKBリクエスタは EKBの発行要求をキー発行センター （KD C) に送る。 このリクエス トには上記のルートキーおよび、 EKBによりルートキ一をどの カテゴリの機器に送るかという、 E KBタイプ定義リストに登録されている EK Bタイプ識別ナンバーのひとつが含まれる。 E KBリクエスタは、 自装置の記憶 手段に格納した EKBタイプ定義リス ト、 あるいはネヅトワーク上の閲覧可能サ ィ トから取得した E KBタイプ定義リストに基づいてコンテンヅ提供などのサー ビスを提供する対象となるデバイスを含むカテゴリからなる E K B夕イブを選択 して、 選択した E K Bタイプを示す E K Bタイプ識別ナンバーを E K B発行要求 中に含ませてキー発行セン夕一 （KD C) に送信する。
(4) E KB発行処理
キー発行センタ一 （KD C) は E KBリクエスタからの E KB発行要求に基づ き、 E KB発行要求中にルートキーが含まれてい場合は、 そのルートキ一を含む EKBの生成を行ない、 E K B発行要求中にルートキーが含まれず、 ルートキー 生成処理依頼がなされた場合は、 KD Cがルートキ一を生成し、 生成ルートキー を含む E KBを生成して E KBリクエスタに送信する。
キー発行センタ一の生成する EKBは、 単一のカテゴリヅリーにおいて処理可 能な EKBである場合と、 複数のカテゴリヅリーにおいて共通に処理可能な E K Bである場合がある。 キー発行センタ一 （KD C) は EKB発行要求に含まれる E KBタイプ識別ナンバーに基づいて、 その E KBタイプ識別ナンバーの構成要 素となっているカテゴリ、 すなわち E KBタイプ定義リス トにおいて、 指定され た E KBタイプ識別ナンバーのノードフィ一ルドに記録されたノ一ドを抽出する ( ノードフィールドにはカテゴリツリーのトップノード I Dが記録されている。 こ れは、 そのカテゴリヅリーの管理エンティティに対応するノード I Dである。 こ のノード I Dに基づいて、 カテゴリッリ一の管理ェンティティである トヅプレベ ル 'カテゴリ 'エンティティ （TL CE) に対し、 サブ E KBの発行要求を出す。 サブ EKBの発行要求にはルートキーと、 各カテゴリを表す情報が含まれる。 キー発行センター（KD C)からサブ E KB発行要求を受け取った TLCEは、 指定された 1つ以上のカテゴリ内の （リボークされていない） 各機器から、 最終 的にルートキーを得られる構成を持つサブ E K Bを生成してキー発行センター (KD C) に送信する。
トヅプレベル 'カテゴリ 'エンティティ （TL CE) の生成するサブ EKBは、 バージョン番号やその検証用の情報 （Version Check Value) を持たないほかは、 通常の EKB (図 6参照） と同様の構造を持つ情報の組である。 ここで、 サブ E KBにおけるリーフキーゃノ一ドキ一を用いて上位のノードキ一ゃル一トキ一を 暗号化するァルゴリズムゃ鍵長、モードは、サブ E KBを生成する各 T L C E (フ ォーマッ トホルダ一） ごとに任意に決めることができる。 これにより、 他のフォ —マッ トとは別個に独自のセキュリティ方式を用いることができる。 また、 デフ オル ト と してたとえば 暗号アルゴリ ズムを FIPS46-2 の ト リ プル D E S (Triple-DES) と決めておき、 これに異存のない T L C Eはト リプル D E Sアル ゴリズムを適用する構成としてもよい。 T L C Eが任意に暗号アルゴリズムや鍵 長を決める場合でも、 別の TL CEが作ったサブ EKBと合成された EKBを、 他の TLCEの支配下にある機器でも処理できるように、 ひとつひとつの （暗号 化された） 鍵は、 所定長、 たとえば 1 6バイ ト （16Byte) のデ一夕で表すと決め る。 このように複数のカテゴリヅリーで共通の EKBを生成する場合に所定のル ールに従って、 データを設定することにより、異なるカテゴリヅリーの各機器は、 E KBのタグを迪つて、 自分が何番目の鍵デ一夕が必要か判断可能となる。 すな わち E KB内に含まれる鍵データの各々が 1 6バイ トであれば、 自デバイスで処 理可能な鍵データを順次抽出して処理することが可能となり、 最終的にルートキ —を取得することが可能となる。
すなわち、 サブ E KBに基づいて生成される合成 E KBは、 複数のキー ' デ一 夕の各々が固定長のデータフィールド内に格納された構成を有する。従って、各々 独自のアルゴリズム、 独自のキー ' データ長を持つサブ有効化キーブロック （サ ブ EKB) に基づいて生成される合成 E KBは、 サブ E KB内の複数の暗号化キ 一データを、 キーツリーにおけるノードまたはリーフ位置に応じて再配列して生 成されても、 E KBのタグを迪つて必要なキー ·データを順次取得可能となる。 このような合成 E KBは、 ネヅ トワークを介してあるいは様々な記録媒体に格納 して、 ユーザ （デバイス） に対して配信または提供される。
キー発行センター （KD C) は、 T L C Eから送られてきたサブ E KBを、 必 要に応じて組替え、 合成し、 バージョン番号と、 その検証用の情報を付加して合 成した合成 EKBを完成させて EKBリクエス夕に送信する。 ただし公開鍵暗号 技術を用いたデジタル署名は、 キー発行センター （KD C) とは別の認証局 （C A： Certificate Authority) に依頼する場合もある。
サブ EKBの生成、 サブ EKBから合成 EKBの生成について、 図を参照して 説明する。 図 5 5は、 カテゴリヅリー A， 5 1 00とカテゴリツリー B, 52 0 0に共通の合成 E K Bを生成する処理において、 カテゴリヅリー A, 5 1 00の T L C Eの生成するサブ E KB— (A) の構成を説明する図である。 サブ EKB - (A) は、 カテゴリツリー A， 5 1 00の各デバイスがルートキーを取得可能 な E K Bとして生成される。 なお、 図においてルートヅリ一領域 5300は上述 の説明では 8段構成として説明してきたが、 ここでは説明を簡略化するため 2段 構成としてある。
図 5 5において、 ヅリー構成内に記載されたアンダーラインを付加した 3桁の 数値 [XXX] は EKB内のタグ （e, 1 , r ) を示し、 前述 （図 26 , 図 27 参照） したように、 e= lはデータあり、 e = 0はデータなしを示し、 1 = 1は 左に枝なし、 1 = 0は左に枝ありを示し、 r= lは右に枝なし、 r= 0は右に枝 ありを示している。 図 55のカテゴリヅリ一 Α, 5 1 0 0の各デバイス （リーフ） がルートキ一を 取得するためには、 各リーフが共通に格納しているノードキーによってルートキ —を暗号化したデ一夕を格納した E KBを生成すればよい。 各デバイスは、 図 5 5のカテゴリヅリー A, 5 1 0 0のデバイスノードキー （D NK) 領域 5 1 2 0 のヅリーの各パスのノードキーを保有しているので、 DNK領域 5 1 20の最上 段のノードキーでルートキーを暗号化した E KBを生成すればよい。
従って、 カテゴリヅリー A, 5 1 0 0の TL CEの生成するサブ EKB— (A) は、 夕グパート ： 1 0 1， 0 1 0， 0 00, 1 1 1 , 1 1 1、 キーパート ： E n c (K 0 1 0 , Kr o o t ), E n c (K 0 1 1 , Κ r ο ο t ) となるサブ EKB - (A) となる。 カテゴリツリー A, 5 1 00の TLCEは、 このサブ EKB— (A) をキー発行センタ一 （KD C) に送信する。
次に、 カテゴリヅリ一 B , 520 0の生成するサブ E K B— (B) について図 56を用いて説明する。 カテゴリヅリー B， 520 0の各デバイス （リーフ） が ルートキーを取得するためには、 各リーフが共通に格納しているノードキーによ つてルートキーを暗号化したデータを格納した E KBを生成すればよい。 各デバ イスは、 図 5 6のカテゴリヅリー B 5 200のデバイスノードキー （DNK) 領 域 5220のヅリ一の各パスのノードキ一を保有しているので、 D NK領域 5 2 20の最上段のノードキーでルートキーを暗号化した EKBを生成すればよい。 従って、 カテゴリヅリ一 B， 520 0の TL C Eの生成するサプ E KB— (B ) は、 夕グパ一ト ： 1 1 0 , 0 1 0, 0 00 , 1 1 1， 1 1 1、 キーパート ： E n c (K 1 1 0 , K r o o t ), E nc (K 1 1 1， K r o o t) となるサブ EKB - (B) となる。 カテゴリツリー B, 5200の TL CEは、 このサブ EKB— (B) をキー発行センター （KD C) に送信する。
キー発行センターは、 各 TL CEの生成したサブ EKB— (A) とサブ EKB ― (B) とから合成 EKBを生成する。 合成 EKBの生成について図 57を用い て説明する。 合成 E KBは、 カテゴリヅリー A, 5 1 00、 およびカテゴリヅリ — B, 520 0の各ッリーに属するデバイスがルートキーを取得可能とした E K Bとして構成される。 基本的には、 受領した複数のサブ E KBの鍵データ配列を 混合してツリー上段から揃える作業によって合成 E KBが生成される。 なお、 同 一段では左側を先とするデータ配列を行なう。
この結果、 合成 E KBは、 タグパート ： 1 00， 0 1 0 , 0 1 0 , 00 0 , 0 00， 1 1 1 , 1 1 1， 1 1 1， 1 1 1、 キ一パ一ト ： E nc (K 0 1 0 , K r o o t)， E n c (K 0 1 1 , K r o o t ), E n c (K 1 1 0， Kr o o t)， E n c (K 1 1 1 , Kr o o t) を持つ E K Bとして生成される。 各キ一パートの 鍵データは前述したように各々例えば 1 6バイ トとして設定することにより、 各 カテゴリツリー内のデバイスは自デバイスで処理可能な鍵デ一夕位置を検出可能 であるので、 合成 E KBからル一トキ一を取得することが可能となる。
以上は、 いずれのカテゴリヅリーにもリボークされたデバイスがない場合のサ ブ E KBの生成および合成 E KBの生成処理構成であるが、 次に、 リボークデバ イスがある場合のサブ E KBの生成および合成 E KBの生成について説明する。 図 58は、 カテゴリッリー A, 5 1 00にリポークデバイス （0 1 1 0 1 ) 5 1 50が存在する場合のサブ E KBの生成について説明する図である。 この場合 のサブ E KBは、 リポークデバイス （0 1 1 0 1) 5 1 5 0のみが処理できない サブ EKB— (Α') として生成される。
この場合、 図の太線で示すパスを接続した鍵データ構成を持つサブ E KBを生 成することになる。 従って、 カテゴリヅリ一 A, 5 1 00の丁 C Eの生成する サブ EKB— (A，：） は、 タグパート ： 1 0 1， 0 1 0 , 0 00 , 1 1 1， 000， 00 1， 1 1 1 , 1 1 1、 キーパート ： En c (K 0 1 0 , Kr o o t), En c (K 0 1 1 1 , K r o o t ), E n c (Κ 0 1 1 00 , Kr o o t ) となるサブ Ε KB - (A，） となる。 カテゴリヅリー A, 5 1 00の11 〇£は、 このサブ EK B - (A，） をキー発行センター （KD C) に送信する。
キー発行センターは、 各 T L C Eの生成したサブ E KB— (Α') と、 リボーク デバイスのないカテゴリヅリー Β, 5 200の TL C Εから受領したサブ Ε Κ Β 一 (Β) (図 5 6参照） とから合成 ΕΚΒを生成する。合成 ΕΚΒの生成について 図 5 9を用いて説明する。 合成 E KBは、 カテゴリツリー Α， 5 1 00のリボー クデバイス （ 0 1 1 0 1 ) 5 1 50を除くデバイス、 およびカテゴリヅリー Β， 520 0のヅリーに属するデバイスがルートキーを取得可能とした E KBとして 構成される。 基本的には、 受領した複数のサブ E KBの鍵データ配列を混合して ツリー上段から揃える作業によって合成 EKBが生成される。 なお、 同一段では 左側を先とするデータ配列を行なう。
この結果、 合成 E KBは、 タグパート ： 1 0 0 , 0 1 0 , 0 1 0 , 000 , 0 00 , 1 1 1 , 000， 1 1 1 , 1 1 1 , 00 1 , 1 1 1 , 1 1 1、 キーパート ： E n c (K 0 1 0 , K r o o t ), E n c (K 1 1 0， K r o o t ), E n c (K 1 1 1 , Kr o o t), E n c (K 0 1 1 1 , K r o o t ), E n c (K 0 1 1 0 0， Kr o o t ) を持つ E KBとして生成される。 この合成 EKBは、 カテゴリ ヅリ一 A, 5 1 00のリポークデバイス （0 1 1 0 1 ) 5 1 50を除くデバイス、 およびカテゴリヅリー B， 52 00のッリーに属するデバイスがルートキーを取 得可能な E KBである。
(5) E KBの利用
上述のような処理によってキー発行セン夕一 （KD C) の生成した EKBは、 E KBリクエス夕に送信される。
例えば E KBリクエスタが、
[a] CD、 DVDなどの、 コンテンツ格納メディアを提供するコンテンツプ ロバイダ （CP)。
[b] 電子情報配信 （E CD ： Electronic Content Distribution) サービスを 提供するコンテンヅプロバイダ。
である場合、
E KBによって取得可能なルートキーでコンテンツキ一を暗号化し、 コンテン ツキ一でユーザデバイスに提供するコンテンツを暗号化してコンテンツを流通さ せることになる。 この構成により、 E KBの処理可能な特定のカテゴリツリーに 属するデバイスのみがコンテンッの利用が可能となる。
また、 E K Bリクエス夕が、
[c 1 ]製造時に記録媒体に E KBを格納するようなフォーマツ トにおいて、記 録媒体の製造業社に取得した E KBを与えるフォーマツ トホルダー。
である場合、 生成した EKB、 ルートキーで暗号化したコンテンヅキーを記録 媒体製造業者に提供して、 E KBおよびルートキーで暗号化したコンテンツキー を格納した記録媒体を製造、 あるいは自ら記録媒体を製造'して流通させる。 この 構成により、 E KBの処理可能な特定のカテゴリヅリーに属するデバイスのみが 記録媒体の E K Bを利用したコンテンッ記録再生時の暗号化処理、 復号処理が可 能となる。 さらに、 E KBリクエスタが、
[ c 2] 製造時に記録デバイスに E KBを格納するようなフォーマツ トにおい て、 記録デバイスの製造業社に取得した E KBを与えるフォーマツ トホルダー。 である場合、 生成した EKB、 ルートキ一で暗号化したコンテンヅキーを記録 デバイス製造業者に提供して、 E KBおよびルートキーで暗号化したコンテンツ キーを格納した記録デバィスを製造、 あるいは自ら記録デバィスを製造して流通 させる。 この構成により、 EKBの処理可能な特定のカテゴリツリーに属するデ バイスのみが E K Bを利用したコンテンツ記録再生時の暗号化処理、 復号処理が 可能となる。
以上のような処理によって EKBが発行されることになる。 なお、 EKB発行 処理プロセスにおける各エンティティ、 E KBリクエスタ、キー発行センター（K D C) T L CE間の通信においては必要に応じて相互認証処理、送信データの暗 号化処理が行われる。 また、 その他のメッセ一ジ暗号化処理、 デジタル署名生成、 検証処理を行なう構成としてもよい。 なお、 公開鍵暗号方式に基づく認証あるい は暗号通信を実行する場合は、 各エンティティ間において予め公開鍵を保有し合 う手続きを行なっておく。
(サブ E KBの単純集合を合成 E KBとする構成例）
上述したサブ E KBから合成 E KBを生成する処理においては、 個々のサブ E KBに含まれる暗号化鍵データの配列を全体ヅリーの上段から下段に至るように 並び替える処理を行なっていた。 次に、 このような並び替え処理を実行すること なく、 各カテゴリヅリ一の TL C Eの生成したサブ E KBをそのまま合成 E KB に順次格納して合成 EKBを生成する構成について説明する。
図 60は、 複数のカテゴリヅリーの TLCEの生成したサブ E KBをそのまま の形で複数格納した合成 E KB 600 0の例を示した図である。
E KBの発行処理において、 キー発行センター （KD C) は、 EKBリクエス 夕によって指定された E KBタイプ識別ナンバーに対応して E KBタイプ定義リ ストに記録されたカテゴリッリ一の管理エンティティである T L C Eに対してサ ブ E KBの生成要求を発行し、 各 T L C Eから提出されたサブ E KB 6 1 1 0 , 6 1 20…を単に集めて合成 EKB内に格納する。 ただし各カテゴリに属する機 器がその合成 E K B中からその機器が処理可能な自デバイスの属するカテゴリに 対応するサブ EKBを選択できるように、 各サブ EKB部分の大きさ （ex. デ —夕レングス） 6 1 1 1、 そのサブ EKBがどのカテゴリ用のものかを表すデー 夕 （ex. ノード I D) 6 1 1 2を付加する。
すなわち、 格納対象として選択されたサブ E KBの各々には、 サブ EKB格納 領域のデータ長を示すレングス、 およびサブ E KB識別データとしての各サブ E KBの対応カテゴリヅリーのノード識別子としてのノード I Dが対応付けられて 格納される。 また合成 EKBに含まれるサブ EKBの数がヘッダ情報 62 0 0と して付加される。 合成 E KBの全データに基づいて署名 （ex. 認証局 （'CA) の署名） 63 0 0が生成されて付加される。
本方式に従って、 前述の図 57を用いた説明に対応する合成 E KBを生成する と、 図 6 1に示すような合成 E KBが生成されることになる。 サブ E KB 6 1 1 0の格納 EKBは、 図 55で説明したカテゴリツリー Aの TLCEの生成したサ ブ EKB— (A) そのものであり、 夕グパート ： 1 0 1 , 0 1 0， 000 , 1 1 1 , 1 1 1、 キーパート ： En c (K 0 1 0 , Kr o o t), En c (K 0 1 1 , Κ r ο ο t ) となる。 また、 サブ Ε Κ Β 6 1 2 0の格納 Ε KBは、 図 56で説明 したカテゴリヅリー Bの T L C Eの生成したサブ E K B—（B)そのものであり、 タグパート ： 1 1 0 , 0 1 0, 000， 1 1 1， 1 1 1、 キーパート ： E n c (K 1 1 0， Kr o o t), En c (K i l l , Kr o o t) となる。
また、 前述の図 58、 図 5 9を用いて説明したリポークデバイスがある場合の 合成 E KBは、 図 62に示すデータ構成となる。 サブ E KB 6 1 1 0の格納 EK Bは、 図 5 8で説明したカテゴリヅリ一 Aの T L C Eの生成したサブ E KB— (Α') そのものであり、 サブ E KB— （A，） は、 タグパート ： 1 0 1 , 0 1 0 , 000， 1 1 1 , 0 00, 00 1 , 1 1 1 , 1 1 1、 キーパート ： E n c (K 0 1 0 , Kr o o t), E n c (K 0 1 1 1 , Kr o o t), E n c (K 0 1 1 00 , Kr o o t) となる。 また、 リボークデバイスの発生していないサブ E KB 6 1 20の格納 EKBは、 図 5 6で説明したカテゴリツリー Bの T L C Eの生成した サブ E KB - (B) そのものであり、 タグパート ： 1 1 0 , 0 1 0， 000， 1 1 1 , 1 1 1、 キーパート ： E n c (K 1 1 0 , Kr o o t), E n c (K i l l : Kr o o t) となる。
このような構成をとることにより、 各カテゴリに属するデバイスは自己のデバ イスが属するカテゴリに対応するサブ EKBを選択して処理 （復号） することが 可能となる。 従って、 各カテゴリ （TL CE) ごとに、 完全に任意の暗号アルゴ リズムや鍵長を用いて、 サブ EKBを生成することができる。 すなわち、 他の力 テゴリに左右されず、 TL C Eが暗号アルゴリズムや鍵長を決めることができる。 キー発行センター （KD C) にとつては、 各 TL CEから集めたサブ EKBの タグ、 および鍵データ部分を分解、 組み直ししなくてよくなり、 負荷が軽くなる。 この方式に従った E KBを入手した機器は、 自分が属するカテゴリのサブ E K Bを見つけ、 それを、 自デバイスを管理する T L CEが定める独自の方法で処理 することによりルートキ一を得ることができる。 他のサブ E K Bを処理するため の、 他のカテゴリの TL CEが定めた方法は知る必要がなく、 またサブ EKBに おいて個々の鍵を固定長で表すなどの工夫が不要なため、 理論的にはどの大きさ の鍵でも用いることができるようになる。
(リボケーシヨン処理— （ 1 ))
複数カテゴリにおいて共通に使用可能な E K Bを利用した処理におけるリボー クの発生に際して実行される処理について、 以下説明する。 暗号化コンテンツを ネッ トワークまたはメディァによって外部から受領して E KBによって取得した キーを用いてコンテンツキーを取得してコンテンツ利用を行なう場合のリボーク 処理についてまず説明する。
図 63を参照しながら説明する。 カテゴリヅリ一A， 7 1 00とカテゴリヅリ 一 B , 720 0において共通に使用される E K B 700 0が利用されている状況 を想定する。 また、 カテゴリヅリー A, 7 1 0 0とカテゴリツリー B , 72 0 0 において共通に使用される E KB 7 0 00は EKBタイプ定義リストでは、 EK Bタイプ識別ナンパ一が # 1に定義されているものとする。
このような状況において、 コンテンツプロバイダは、 ネッ トワークまたはメデ ィァによってコンテンヅキーで暗号化したコンテンツを提供し、 カテゴリッリー A, 7 1 00とカテゴリヅリー B, 7200に属するデバイスは、 EKB 7 0 0 0を用いてルートキーの取得、 ルートキーによる復号処理によるコンテンツキー の取得、 コンテンヅキーによる暗号化コンテンツの取得を実行してコンテンヅを 利用している。
この状況でカテゴリツリー A， 7 1 00に属するデバイス A 1 , 7 120の鍵 デ一夕の漏洩など不正処理可能な状況が発覚し、 デバイス A 1 , 7 120のリボ —クを行なうとする。
この場合、 カテゴリヅリー A, 7 1 00の TL CEは、 キー発行センター （K D C) に対してヅリ一変更通知 （図 5 3参照） を実行し、 キー発行センター （K D C) は、 受信したツリー変更通知に基づいて管理下の各 T L C E、 EKBリク エスタに対して通知する。 この時点の通知は、 ヅリー変更通知を受領したことを 知らせるのみであり、 EKBタイプ定義リストの更新処理は実行されない。
なお、 リボ一ク発生に基づくヅリー変更通知は、 リボークの発生したカテゴリ ヅリ一において処理可能な EKBを利用しているエンティティとしての EKBリ クエスタに対してのみ、 あるいはさらに、 リボークの発生したカテゴリツリーと 共有の E KBが適用されている他のカテゴリッリーを管理するカテゴリ ·ェンテ ィティに対してのみ実行する構成としてもよい。 この処理を行なうため、 キー発 行センター （KD C) は、 発行済み E KBの利用者リス トとして、 E KBタイプ 識別ナンバーとその EKBタイプを利用している E' KBリクエスタとを対応付け たリス トを保有する。
リボーク処理を実行したカテゴリヅリ一のデバイスを対象としてコンテンツの 配信を実行している E KBリクエスタとしてのコンテンツプロバイダは、 リボー ク処理対象以外のデバイスにおいてのみ処理可能な更新された E KBを生成する ようにキー発行センター （KD C) に対して E KB発行要求を行なう。 この場合、 E KBリクエス夕としてのコンテンツプロバイダは、 カテゴリヅリー A, 7 1 0 0とカテゴリヅリ一 B , 720 0において共通に使用される E KBのタイプとし て定義されている E KBタイプ識別ナンバー # 1を指定する。 また、 新たなルー トキ一を EKBリクエス夕自ら生成して KD Cに送付するか、 あるいは新たなル 一トキ一の生成を KD Cに依頼する。
キー発行センター （KD C) は、 指定された E KBタイプ識別ナンバー # 1に 基づいて、 E KBタイプ定義リストを参照し、 対応するカテゴリツリーのノード に基づいてカテゴリヅリ一 A, 7 1 0 0とカテゴリヅリ一 B， 7200の！11^。 Eに対して新たなルートキーを正当なデバイスにおいて取得可能なサブ E KBの 生成を依頼する。
カテゴリツリー A, 7 1 0 0とカテゴリヅリー B , 72 00の丁 〇£の各々 は、 依頼に基づいてサブ E KBを生成する。 この場合、 カテゴリヅリー A, 7 1 00においてはリボークされたデバイス A 1 , 7 1 20を排除した他のデバィス においてのみ新規のルートキーを取得可能なサブ E KB— (A) が生成される。 カテゴリツリー B， 720 0ではリポークされたデバイスが存在しなければ、 力 テゴリに属するすべてのデバイスにおいて新規のル一トキーを取得可能なサブ E KB— (B) を生成してキー発行センタ一 （KD C) に対して送信する。
キー発行センター （KD C) は各 T LCEから受信したサブ EKBに基づいて 合成 E KBを前述した方法に従って生成し、 生成した E KBを E KBリクエス夕 (ex. コンテンツプロバイダ） に送信する。
E KBリクエスタ （ex. コンテンツプロバイダ） はキー発行センター （KD C) から受領した新たな E KBを適用してコンテンツ配信を行なう。 具体的には コンテンツキーで暗号化したコンテンツを提供し、 E KBの復号によって得られ るルートキーでコンテンヅキーを暗号化して提供する。 カテゴリヅリー A, 7 1 00とカテゴリヅリー B， 7200に属するデバイスは、 EKBを用いてルート キーの取得、 ルートキーによる復号処理によるコンテンヅキーの取得、 コンテン ヅキ一による暗号化コンテンヅの取得を実行してコンテンヅが利用可能である。 ただし、 カテゴリツリー A, 7 1 00のリボークデバイス A 1 , 7 1 20は更新 された E KBを処理できないのでコンテンヅの利用ができなくなる。
なお、 上述の説明においては、 キー発行センター （KD C) は TL CEからの ヅリ一変更通知を受領した場合、 その時点では、 E KBタイプ定義リストの更新 処理を実行しない例を説明したが、 KD Cがヅリー変更通知を受領した時点で、 キー発行センター （KD C) がツリー変更情報に基づいて、 E KBタイプ定義リ ストの更新処理、 EKB更新処理を実行し、 各 EKBリクエスタ、 TLCEに更 新された E KBタイプ定義リストを送付する構成としてもよい。
(リボケーション処理一 （2)) 次に、 例えば記録デバイスあるいは記録媒体に E KBを格納した構成で、 記録 媒体に対してユーザが様々なコンテンツを暗号化して記録し暗号化処理、 復号処 理に必要となるキーを記録デバイスあるいは記録媒体に格納した E K Bから取得 されるルートキーを用いたものとするいわゆる自己記録型の形態におけるリポー ク処理に伴う処理について説明する。
図 64を参照しながら説明する。 カテゴリヅリー A, 8 1 00とカテゴリッリ 一 B , 8200において共通に使用される E K B 80◦ 0が利用されている状況 を想定する。 すなわちカテゴリヅリ一 A， 8 1 00とカテゴリヅリー B， 82 0 0において共通に使用される記録デバイスあるいは記録媒体には、 共通の E KB が格納され、 ユーザは、 E KBを利用したコンテンツ暗号化、 復号処理によるコ ンテンヅ記録再生を行なっているものとする。 なお、 カテゴリヅリー A, 8 1 0 0とカテゴリヅリー B， 8200において共通に使用される E KB 800 0は E KBタイプ定義リストでは、 EKBタイプ識別ナンバーが # 1に定義されている ものとする。
この状況でカテゴリヅリー A, 8 1 00に属するデバイス A 1 , 8 12 0の鍵 デ一夕の漏洩など不正処理可能な状況が発覚し、 デバイス A 1， 8 120のリポ ークを行なうとする。 .
この場合、 カテゴリツリー A, 8 1 0 0の T L C Eは、 キー発行センター （K D C) に対してヅリー変更通知 （図 5 3参照） を実行し、 キー発行センター （K D C) は、 受信したツリー変更通知に基づいて管理下の各 TL CE、 関連 EKB リクエス夕に対して通知する。 この時点の通知は、 ヅリー変更通知を受領したこ とを知らせるのみであり、 EKBタイプ定義リストの更新処理は実行されない。 リボーク処理を実行したカテゴリヅリーの T L C Eは、リボークデバイス A 1， 8 1 20における将来における E KBを利用した新たなコンテンツ処理を停止さ せるため、 自ら E KBリクエス夕として、 リボーク処理対象以外のデバイスにお いてのみ処理可能な更新された E KBを生成するようにキー発行センター （KD C) に対して E KB発行要求を行なう。 この場合、 E KBリクエスタとしての T LCEは、 カテゴリツリー A, 8 1 0 0とカテゴリヅリー B， 8200において 共通に使用される E KBのタイプとして定義されている E KBタイプ識別ナンパ — # 1を指定する。 また、 新たなルートキーを EKBリクエスタ自ら生成して K D Cに送付するか、 あるいは新たなルートキーの生成を KD Cに依頼する。
キ一発行セン夕一 （KD C) は、 指定された E KBタイプ識別ナンバー # 1に 基づいて、 EKBタイプ定義リストを参照し、 対応するカテゴリツリーのノード に基づいてカテゴリツリー A, 8 1 0 0とカテゴリヅリー B , 8200の丁し〇 Eに対して新たなルートキーを正当なデバイスにおいて取得可能なサブ E KBの 生成を依頼する。
カテゴリヅリ一 A， 8 1 00とカテゴリツリー B, 8200の TL CEの各々 は、 依頼に基づいてサブ EKBを生成する。 この場合、 カテゴリヅリー A, 8 1 00においてはリボークされたデバイス A 1 , 8 1 20を排除した他のデバイス においてのみ新規のルートキーを取得可能なサブ E KB— (A) が生成される。 カテゴリヅリー B， 820 0ではリポークされたデバイスが存在しなければ、 力 テゴリに属するすべてのデバイスにおいて新規のルートキ一を取得可能なサブ E KB - (B) を生成してキー発行センター （KD C) に対して送信する。
キー発行センター （KD C) は各 T L CEから受信したサブ EKBに基づいて 合成 E KBを前述した方法に従って生成し、生成した EKBを各 TLCE (ex. フォーマッ トホルダ一） に送信する。
各 TLCE (e . フォーマットホルダー） はキー発行セン夕一 （KD C) か ら受領した新たな E KBを各デバイスに配信して、 EKBの更新を実行させる。 カテゴリヅリ一 A， 8 1 0 0とカテゴリヅリー B， 820 0に属するデバイスは、 新たなコンテンヅの記録デバイスに対する記録を更新した E KBを用いて取得し たル一トキ一を適用した暗号化処理として実行する。 新たな EKBを用いて暗号 化記録されたコンテンツは対応する E KBを適用した場合にのみ復号可能となる ので、 リボークされたデバイスにおいては利用不可能となる。
以上、 特定の実施例を参照しながら、 本発明について詳解してきた。 しかしな がら、 本発明の要旨を逸脱しない範囲で当業者が該実施例の修正や代用を成し得 ることは自明である。 すなわち、 例示という形態で本発明を開示してきたのであ り、 限定的に解釈されるべきではない。 本発明の要旨を判断するためには、 冒頭 に記載した特許請求の範囲の欄を参酌すべきである。 産業上の利用可能性
以上、 説明したように、 本発明の情報処理システムおよび方法によれば、 カテ ゴリに基づいて区分され、 カテゴリ · エンティティによって管理されるサブッリ 一を複数有するキーヅリーを構成し、 キーヅリーを構成するパスを選択して選択 パス上の下位キーによる上位キーの暗号化処理データからなる E KBを生成して デバイスに提供する構成において、 EKBタイプ識別子と、 EKB処理可能な 1 以上のカテゴリッリ一の識別データとを対応付けた E K Bタイプ定義リストに基 づいて E KBの発行管理を実行するように構成したので、 E KB生成要求者とし ての E KBリクエスタが容易に適用対象となるカテゴリを選択できる。
また、本発明の情報処理システムおよび方法によれば、有効化キープ口ック（E KB) の生成要求において、 ルートキーを自ら生成する構成と、 ルートキーの生 成をキー発行セン夕一に依頼する構成を選択的に実行可能としたので、 EKB生 成要求者の負担軽減が実現され、 また、 EKB発行センターにおける EKB生成 において、 E K B生成要求時にサブ E KBの生成をカテゴリ管理者であるカテゴ リ ·エンティティに依頼する構成としたので E KB生成、 管理処理の効率化が可 能となる。
また、 本発明の情報処理システムおよび方法によれば、 カテゴリに基づいて区 分され、 カテゴリ · エンティティによって管理されるサブヅリーを複数有するキ 一ツリーを構成し、 キーヅリーを構成するパスを選択して選択パス上の下位キー による上位キーの暗号化処理データからなる E KBを生成してデバイスに提供す る構成において、 キーツリ一の部分ヅリーとして設定されるサブヅリーの各々に おいて復号処理可能なサブ有効化キーブロック （サブ EKB) の合成 E KBを構 成し、 合成 EKB内のキ一 ·データの各々を固定長のデータフィールド内に格納 する構成としたので、 様々なアルゴリズムによるサブ EKBを合成した場合でも 各デバイスにおいて復号可能な E KBの提供が可能となる。
また、 本発明の情報処理システムおよび方法によれば、 カテゴリに基づいて区 分され、 カテゴリ · エンティティによって管理されるサブヅリーを複数有するキ ーッリーを構成し、 キーヅリーを構成するパスを選択して選択パス上の下位キー による上位キーの暗号化処理データからなる E KBを生成してデバイスに提供す る構成において、 キ一ヅリーの部分ヅリーとして設定されるサブヅリーの各々に おいて復号処理可能なサブ有効化キーブロック （サブ EKB) の合成 E KBを構 成し、 合成 EKBに格納する各サブ有効化キーブロック （サブ EKB) 内のキー 配列を保持し、 かつ、 各サブ E KBに対応してサブ E KB格納領域のデータ長お よびサブ EKB識別データを付加した構成として、 様々なアルゴリズムによるサ ブ E KBを合成した場合でも各デバイスにおいて復号可能な E KBの提供が可能 となる。

Claims

請求の範囲
1. 複数のデバイスをリーフとして構成したッリーのルートからリーフまでの パス上のルート、 ノード、 およびリーフに各々キーを対応付けたキーツリーを構 成し、 該キ一ヅリーを構成するパスを選択して選択パス上の下位キ一による上位 キーの暗号化処理デ一夕を有し、 前記選択パスに対応するノードキ一セッ トを利 用可能なデバイスにおいてのみ復号可能とした有効化キーブロック （EKB) を デバイスに提供する構成を持つ情報処理システムであり、
有効化キーブロック （EKB) を生成するキ一発行センター （KD C) に対し て EKBの生成を要求する EKBリクエスタは、
生成済みル一小キーを含む E KB生成要求としての第 1の E KB生成要求、 ま たは、
キー発行センター （KD C) におけるルートキ一生成および該生成ルートキー を含む E KB生成を要求する第 2の E KB生成要求、
のいずれかをキー発行センタ一 （KD C) に対する E K B生成要求として出力 し、
キー発行センター （KD C) は、 前記第 1の E KB生成要求、 または前記第 2 の E KB生成要求の受信に応じて受信ルートキ一または生成ルートキ一を含めた E KB生成を実行する構成を有することを特徴とする情報処瑪システム。
2. 前記キーヅリ一は、 カテゴリに基づいて区分され、 カテゴリ 'ェンティテ ィによって管理されるサブヅリーとしてのカテゴリヅリーを複数有する構成であ り、
前記 EKBリクエスタは、
E KBタイプ識別子と、 E KB処理可能なカテゴリツリーの識別データとを対 応付けた E KBタイプ定義リストに基づいて E KBタイプ識別子を選択し、 選択 E KBタイプ識別子を含む E KB生成要求を前記第 1の E KB生成要求または前 記第 2の EKB生成要求として前記キー発行センタ一 （KD C) に対して出力す る構成であることを特徴とする請求項 1に記載の情報処理システム。
3. 前記 E KBリクエスタは、
記憶手段、 または、 ネッ トワーク上の閲覧可能サイ トから取得される EKB夕 ィプ定義リストに基づいて E KBタイプ識別子を選択する構成であることを特徴 とする請求項 2に記載の情報処理システム。
4. 前記 E KBタイプ定義リストの E KB処理可能なカテゴリヅリーの識別デ 一夕は、 カテゴリヅリ一のノードの識別子であるノード I Dであることを特徴と する請求項 2に記載の情報処理システム。
5. 前記 EKBタイプ定義リストには、 カテゴリツリーに属するデバイスに関 する説明を含む構成であることを特徴とする請求項 2に記載の情報処理システム
6. 複数のデパイスをリーフとして構成したヅリーのルートからリーフまでの パス上のルート、 ノード、 およびリーフに各々キーを対応付けたキ一ヅリーを構 成し、 該キーヅリ一を構成するパスを選択して選択パス上 C 下位キ一による上位 ' キーの暗号化処理データを有し、 前記選択パスに対応するノードキーセッ トを利 用可能なデパイスにおいてのみ復号可能とした有効化キープロ ヅク （EKB) を デバイスに提供する構成を持つ情報処理システムであり、
前記キーヅリ一は、 カテゴリに基づいて区分され、 カテゴリ 'エンティティに よって管理されるサブッリーとしてのカテゴリヅリーを複数有する構成であり、 有効化キ一ブロック （EKB) を生成するキー発行センター （KD C) は、 E KB生成の要求エンティティである E KBリクエス夕の要求に基づく有効化 キープロック （EKB) の生成において、 生成する有効化キーブロック （EKB) の復号可能なカテゴリヅリーを管理する 1以上のカテゴリ ·エンディティに各力 テゴリツリーにおいて処理可能なサブ E KBの生成要求を出力し、 カテゴリ * ェ ンティティから受領したサブ有効化キーブロック （サブ EKB) に基づいて 1以 上のカテゴリヅリ一において処理可能な E KBを生成する構成を有することを特 徴とする情報処理システム。
7. 前記キー発行セン夕一 （KD C) は、
E KBタイプ識別子と、 E KB処理可能なカテゴリヅリ一の識別データとを対 応付けた E KBタイプ定義リストを有し、 E KBの生成を要求するエンティティ である E KBリクエスタから受領する E KB生成要求中に含まれる E KB夕ィプ 識別子に基づく E K Bタイプ定義リス トの検索によりカテゴリヅリ一の識別デー 夕を抽出して、 抽出されたカテゴリヅリーの識別デ一夕に対応する 1以上のカテ ゴリ · エンティティの生成したサブ E KBに基づいて、 E KBタイプ定義リス ト に設定されたカテゴリヅリ一に共通に使用可能な E KBを生成して提供する構成 であることを特徴とする請求項 6に記載の情報処理システム。
8. 前記キー発行センター （KD C) からサブ EKB生成要求を受領したカテ ゴリ ·エンティティは、 自己の管理するカテゴリツリーに属するノードまたはリ ーフに対応付けられたキーに基づいて処理可能な E KBとしてのサブ有効化キー ブロック （サブ EKB) を生成する構成であることを特徴とする請求項 6に記載 の情報処理システム。
9. 前記キ一ヅリーは、 最上段に複数段のルートヅリーが構成され、 該ルート ヅリ一に直結する ト ヅプレベル · カテゴリヅリー、 該トヅプレベル · カテゴリヅ リ一の下段に連結されるサブカテゴリヅリーによって構成され、
前記カテゴリ · ェンティティは、 前記トップレベル · カテゴリッリーの管理工 ンティティ として該トヅプレベル · カテゴリッリ一および該トップレベル . カテ ゴリヅリーの下段に連なるサブカテゴリヅリーの管理を行ない、
前記カテゴ 'リ ·エンティティは、 自己の管理する トップレベル · カテゴリッリ 一および該ト ヅプレベル · カテゴリッリ一の下段に連なるサブカテゴリッリーに 属するノードまたはリーフに対応して設定されるキーに基づいて処理可能な E K Bとしてのサブ有効化キーブロック （サブ EKB) を生成する構成であることを 特徴とする請求項 6に記載の情報処理システム。
1 0. 複数のデバイスをリーフとして構成したヅリーのルートからリーフまで のパス上のルート、 ノード、 およびリーフに各々キーを対 付けたキーヅリ一を 構成し、 該キ一ヅリーを構成するパスを選択して選択パス上の下位キーによる上 位キーの暗号化処理データを有し、 前記選択パスに対応するノードキーセヅ トを 利用可能なデバイスにおいてのみ復号可能とした有効化キ一ブロック （ΕΚΒ) をデバイスに提供する構成を持つシステムにおける情報処理方法であり、 有効化キーブロック （ΕΚΒ) を生成するキー発行センタ一 （KD C) に対し て E KBの生成を要求する E KBリクエスタは、
生成済みルートキーを含む E KB生成要求としての第 1の E KB生成要求、 ま たは、
キー発行センタ一 （KD C) におけるルートキー生成および該生成ルートキー を含む E KB生成を要求する第 2の E KB生成要求、
のいずれかをキー発行センター （KD C) に対する E KB生成要求として出力 し、
キー発行センター （KD C) は、 前記第 1の EKB生成要求、 または前記第 2 の E KB生成要求の受信に応じて受信ルートキーまたは生成ルートキーを含めた E KB生成を実行することを特徴とする情報処理方法。
1 1. 前記キ一ヅリーは、 カテゴリに基づいて区分され、 カテゴリ · ェンティ ティによって管理されるサブヅリーとしてのカテゴリヅリ一を複数有する構成で あり、
前記 EKBリクエスタは、
E KBタイプ識別子と、 E KB処理可能なカテゴリヅリーの識別デ一夕とを対 応付けた E KBタイプ定義リストに基づいて E KBタイプ識別子を選択し、 選択 E KBタイプ識別子を含む E KB生成要求を前記第 1の E KB生成要求または前 記第 2の EKB生成要求として前記キー発行センター （KD C) に対して出力す ることを特徴とする請求項 1 0に記載の情報処理方法。
12. 前記 E KBリクエスタは、 記憶手段、 または、 ネッ トワーク上の閲覧可能サイ トから取得される EKB夕 ィプ定義リストに基づいて E KBタイプ識別子を選択することを特徴とする請求 項 1 1に記載の情報処理方法。
1 3. 前記 E KBタイプ定義リストの E KB処理可能なカテゴリヅリーの識別 データは、 カテゴリヅリーのノードの識別子であるノード I Dであることを特徴 とする請求項 1 1に記載の情報処理方法。
14. 前記 E KBタイプ定義リストには、 カテゴリツリーに属するデバイスに 関する説明を含む構成であることを特徴とする請求項 1 1に記載の情報処理方法。
1 5. 複数のデバイスをリーフとして構成したヅリ一のル一トからリーフまで のパス上のルート、 ード、 およびリーフに各々キーを対応付けたキーツリーを 構成し、 該キーヅリーを構成するパスを選択して選択パス上の下位キーによる上 位キーの暗号化処理データを有し、 前記選択パスに対応するノードキーセッ トを 利用可能なデバイスにおいてのみ復号可能とした有効化キ一プロック （EKB) をデバイスに提供する構成を持つシステムにおける情報処理方法であり、
前記キーツリーは、 カテゴリに基づいて区分され、 カテゴリ ' エンティティに よって管理されるサブヅリーとしてのカテゴリヅリーを複数有する構成であり、 有効化キーブロック （EKB) を生成するキー発行センター （KD C) は、
E KB生成の要求エンティティである E KBリクエスタの要求に基づく有効化 キーブロック （EKB) の生成において、 生成する有効化キーブロック （EKB) の復号可能なカテゴリヅリ一を管理する 1以上のカテゴリ · エンティティに各力 テゴリツリーにおいて処理可能なサブ E KBの生成要求を出力し、 カテゴリ ' ェ ンティティから受領したサブ有効化キーブロック （サブ EKB) に基づいて 1以 上のカテゴリヅリ一において処理可能な E KBを生成することを特徴とする情報 処理方法。
1 6. 前記キー発行センター （KD C) は、 E KBタイプ識別子と、 E KB処理可能なカテゴリッリーの識別データとを対 応付けた E KBタイプ定義リストを有し、 E KBの生成を要求するエンティティ である E KBリクエスタから受領する E KB生成要求中に含まれる E KBタイプ 識別子に基づく E K Bタイプ定義リストの検索によりカテゴリヅリ一の識別デー 夕を抽出して、 抽出されたカテゴリヅリーの識別データに対応する 1以上のカテ ゴリ . エンティティの生成したサブ E KBに基づいて、 E KBタイプ定義リス ト に設定されたカテゴリヅリ一に共通に使用可能な E KBを生成して提供する構成 であることを特徴とする請求項 1 5に記載の情報処理方法。
1 7. 前記キー発行センター （KD C) からサブ E KB生成要求を受領した力 テゴリ ·エンティティは、 自己の管理するカテゴリヅリーに属するノードまたは リーフに対応付けられたキーに基づいて処理可能な EKBとしてのサブ有効化キ 一ブロック （サブ EKB) を生成することを特徴とする請求項 1 5に記載の情報 処理方法。
1 8. 前記キーヅリ一は、 最上段に複数段のルートツリーが構成され、 該ルー トヅリ一に直結する ト ヅプレベル ' カテゴリツリー、 該トヅプレベル · カテゴリ ッリーの下段に連結されるサブカテゴリヅリーによって構成され、
前記カテゴリ ' エンティティは、 前記トップレベル ' カテゴリヅリーの管理工 ンティティとして該トップレベル ' カテゴリヅリ一および該トップレベル ' カテ ゴリッリ一の下段に連なるサブカテゴリヅリ一の管理を行ない、
前記カテゴリ ·エンティティは、 自 3の管理するトヅプレベル · カテゴリヅリ 一および該トヅプレベル · カテゴリッリーの下段に連なるサブカテゴリヅリーに 属するノードまたはリーフに対応して設定されるキーに基づいて処理可能な E K Bとしてのサブ有効化キーブロック （サブ EKB) を生成することを特徴とする 請求項 1 5に記載の情報処理方法。
1 9. 複数のデバイスをリーフとして構成したヅリ一のルートからリーフまで のパス上のルート、 ノード、 およびリーフに各々キーを対応付けたキーツリーを 構成し、 該キーツリーを構成するパスを選択して選択パス上の下位キーによる上 位キーの暗号化処理データを有し、 前記選択パスに対応するノードキーセッ トを 利用可能なデバイスにおいてのみ復号可能とした有効化キーブロック （ E K B ) をデパイスに提供する構成を持つシステムにおける情報処理をコンピュータ · シ ステム上で実行せしめるコンピュータ · プログラムを記録したプログラム記録媒 体であって、 前記コンピュータ · プログラムは、
生成済みルートキーを含む E K B生成要求としての第 1の E K B生成要求、 ま たは、 キー発行センター （K D C ) におけるルートキー生成および該生成ルート キーを含む E K B生成を要求する第 2の E K B生成要求のいずれかの E K B生成 要求を受信するステップと、
受信した E K B生成要求の種類に応じて、受信ルートキーを含めた E K B生成、 またはルートキ一の生成および生成ルートキーを含めた E K B生成のいずれかの 処理を選択的に実行するステップと、
を有することを特徴とするプログラム記録媒体。
2 0 . 複数のデバイスをリーフとして構成したヅリ一のルートからリーフまで のパス上のルート、 ノード、 およびリーフに各々キ一を対応付けたキーツリーを 構成し、 該キーヅリーを構成するパスを選択して選択パス上の下位キーによる上 位キーの暗号化処理データを有し、 前記選択パスに対応するノードキーセッ トを 利用可能なデバイスにおいてのみ復号可能とした有効化キーブロック （E K B ) をデバイスに提供する構成を持つシステムにおける情報処理をコンピュータ · シ ステム上で実行せしめるコンピュータ · プログラムを記録したプログラム記録媒 体であって、 前記コンピュータ · プログラムは、
E K B生成要求に含まれる E K Bタイプ識別子に基づいて、 E K Bタイプ識別 子と、 E K B処理可能な 1以上のカテゴリツリーの識別データとを対応付けた E K Bタイプ定義リストからカテゴリッリーの識別デ一夕を抽出するステップと、 抽出されたカテゴリヅリ一の識別データに対応するカテゴリヅリーを管理する 1以上のカテゴリ · エンティティに各カテゴリヅリーにおいて処理可能なサブ有 効化キーブロック （サブ E K B ) の生成要求を出力するステップと、 カテゴリ、, ' エンティティから受領したサブ有効化キーブロック （サブ EKB) に基づいて 1以上のカテゴリヅリーにおいて処理可能な E KBを生成するステヅ プと、
を有することを特徴とするプログラム記録媒体。
2 1. 複数のデバイスをリーフとして構成したッリ一のルートからリーフまで のパス上のルート、 ノード、 およびリーフに各々キーを対応付けたキーヅリ一を 構成し、 該キーツリ一を構成するパスを選択して選択パス上の下位キーによる上 位キーの暗号化処理データを有し、 前記選択パスに対応するノードキーセヅ トを 利用可能なデバイスにおいてのみ復号可能とした有効化キーブロック （EKB) をデパイスに提供する構成を持つ情報処理システムであり、
前記有効化キーブロック （EKB) は、
前記キーツリ一の部分ヅリーとして設定されるサブヅリ一の各々において復号 処理可能なサブ有効化キープ口ック （サブ E KB)の合成 E KBとして構成され、 該合成 E KB内に含まれる複数のキー ·デ一夕の各々が固定長のデ一タフィ一ル ド内に格納された構成を有することを特徴とする情報処理システム。
22. 前記サブツリーは、 カテゴリに基づいて区分され、 カテゴリ 'ェンティ ティによつて管理されるカテゴリッリ一であり、
前記サブ有効化キーブロック （サブ EKB) は、 前記カテゴリ 'エンティティ において自己の管理するカテゴリヅリーに属するノードまたはリーフに対応付け られたキーに基づいて処理可能な E K Bとして生成され、
キー発行センタ一 （KD C) において、 前記カテゴリ ' エンティティの生成し たサブ E K Bに基づいて、 複数のカテゴリヅリーに共通に使用可能な E K Bとし ての合成 E KBを生成する構成であることを特徴とする請求項 2 1に記載の情報 処理システム。
23. 前記サブ有効化キーブロック （サブ EKB) の各々は、 各々独自のアル ゴリズム、 独自のキー 'データ長を持つサブ有効化キーブロック （サブ EKB) として構成され、
キー発行セン夕一 （K D C ) は、
前記サブ E K Bに基づく合成 E K Bの生成処理において、 合成 E K Bを構成す るサブ E K B内のキー .データの各々を固定長のデータフィールド内に格納する 処理を実行する構成であることを特徴とする請求項 2 1に記載の情報処理システ ム。
2 4 . 前記合成 E K Bは、
前記キーヅリ一を構成する各ノードに対応して設定されるノードキーを下位ノ 一ドキーまたは下位リーフキーを用いて暗号化した暗号化キーデータと、 前記合成 E K Bに格納された 1以上の暗号化キーデ一夕各々のノード位置の下 位の左右位置のノードまたはリーフ位置の暗号化キーデータの有無を示すタグを 含む構成であることを特徴とする請求項 2 1に記載の情報処理システム。
2 5 . 前記合成 E K Bは、
該合成 E K Bを復号可能な末端ノードまたはリーフを最下段とした簡略化した ヅリーを構成するパスを選択して不要ノードを省略することにより再構築される 再構築階層ヅリーのノードまたはリーフに対応するキーを暗号化キーデ一夕とし て有することを特徴とする請求項 2 1に記載の情報処理システム。
2 6 . 前記合成 E K Bは、
複数のサブ E K Bの各々に含まれる複数の暗号化キーデータを、 キーヅリーに おけるノードまたはリーフ位置に応じて再配列して生成された構成を有すること を特徴とする請求項 2 1に記載の情報処理システム。
2 7 . カテゴリに基づいて区分されたサブヅリーとしてのカテゴリツリーによ り構成され、 複数のデバイスをリーフとして構成したヅリーのルートからリーフ までのパス上のルート、 ノード、 およびリーフに各々キーを対応付けたキ一ヅリ 一を構成し、 該キーツリーを構成するパスを選択して選択パス上の下位キーによ る上位キーの暗号化処理データを有し、 前記選択パスに対応するノードキーセヅ トを利用可能なデバイスにおいてのみ復号可能とした有効化キ一プロック （E K B) を格納した情報記録媒体であり、
前記キーツリ一の部分ヅリーとして設定されるサブッリ一の各々において復号 処理可能なサブ有効化キーブロック （サブ EKB) の合成 E KBを格納し、 該合 成 E KB内に含まれる複数のキー ·データの各々が固定長のデ一夕フィールド内 に格納された構成を有することを特徴とする情報記録媒体。
28. 前記サブ有効化キーブロック （サブ EKB) の各々は、 各々独自のアル ゴリズム、 独自のキ一 'データ長を持つサブ有効化キ一ブロック （サブ EKB) として構成され、 キー ·データの格納領域が固定長とされている構成であること を特徴とする請求項 27に記載の情報記録媒体。
29. 複数のデバイスをリーフとして構成したヅリーのルートからリーフまで のパス上のルート、 ノード、 およびリーフに各々キーを対応付けたキーヅリ一を 構成し、 該キーツリーを構成するパスを選択して選択パス上の下位キーによる上 位キーの暗号化処理データを有し、 前記選択パスに対応するノードキーセットを 利用可能なデバイスにおいてのみ復号可能とした有効化キープ口ック （EKB) をデバイスに提供する構成を持つシステムにおける情報処理方法であり、 前記有効化キーブロック （EKB) は、
前記キーヅリ一の部分ヅリーとして設定されるサブヅリ一の各々において復号 処理可能なサブ有効化キ一プロヅク （サブ E KB)の合成 EKBとして構成され、 該合成 E KB内に含まれる複数のキー ·デ一夕の各々が固定長のデータフィ一ル ド内に格納されてデバイスに提供することを特徴とする情報処理方法。
3 0. 前記サブツリーは、 カテゴリに基づいて区分され、 カテゴリ ·ェンティ ティによって管理されるカテゴリヅリーであり、
前記サブ有効化キープロック （サブ EKB) は、 前記カテゴリ 'エンティティ において自己の管理するカテゴリヅリ一に属するノードまたはリーフに対応付け られたキーに基づいて処理可能な EKBとして生成され、
キー発行センター （KD C) において、 前記カテゴリ ' エンティティの生成し たサブ E KBに基づいて、 複数のカテゴリッリーに共通に使用可能な E KBとし ての合成 E KBを生成することを特徴とする請求項 29に記載の情報処理方法。
3 1. 前記サブ有効化キーブロック （サブ EKB) の各々は、 各々独自のアル ゴリズム、 独自のキー ' デ一夕長を持つサブ有効化キ一ブロック （サブ EKB) として構成され、
キー発行センター （KD C) は、
前記サブ E KBに基づく合成 E KBの生成処理において、 合成 E KBを構成す るサブ EKB内のキー · データの各々を固定長のデ一タフィ一ルド内に格納する 処理を実行することを特徴とする請求項 29に記載の情報処理方法。
32. 前記有効化キ一ブロック （EKB) は、
前記キーツリ一を構成する各ノードに対応して設定されるノードキーを下位ノ 一ドキ一または下位リーフキーを用いて暗号化した暗号化キーデータと、 前記有効化キープ口ヅク（E KB)に格納された 1以上の暗号化キーデータ各々 のノード位置の下位の左右位置のノードまたはリーフ位置の暗号化キーデータの 有無を示すタグを含む構成として生成することを特徴とする請求項 29に記載の 情報処理方法。
33. 前記有効化キーブロック （EKB) は、
該有効化キーブロック （EKB) を復号可能な末端ノードまたはリーフを最下 段とした簡略化したツリーを構成するパスを選択して不要ノードを省略すること により再構築される再構築階層ヅリーのノードまたはリーフに対応するキーを暗 号化キーデータとして有する構成として生成することを特徴とする請求項 29に 記載の情報処理方法。
34. 前記合成 E KBは、 複数のサブ E K Bの各々に含まれる複数の暗号化キーデータを、 キーツリ一に おけるノードまたはリーフ位置に応じて再配列して生成することを特徴とする請 求項 2 9に記載の情報処理方法。
3 5 . 複数のデバイスをリーフとして構成したヅリーのルートからリーフま でのパス上のルート、 ノード、 およびリーフに各々キ一を対応付けたキーツリー を構成し、 該キ一ヅリーを構成するパスを選択して選択パス上の下位キーによる 上位キーの暗号化処理データを有し、 前記選択パスに対応するノードキーセッ ト を利用可能なデバイスにおいてのみ復号可能とした有効化キ一ブロック（ E K B ) をデバイスに提供する構成を持つシステムにおける有効化キープロック（ E K B ) 生成処理をコンピュータ · システム上で実行せしめるコンピュータ · プログラム を記録したプログラム記録媒体であって、 前記コンピュータ · プログラムは、 前記キーヅリ一の部分ッリーとして設定されるサブヅリ一の各々において復号 処理可能なサブ有効化キ一ブロック （サブ E K B ) の合成処理ステップと、 合成 E K B内に含まれる複数のキー ·データの各々を固定長のデータフィール ド内に格納するステヅプと、
を有することを特徴とするプログラム記録媒体。
3 6 . 複数のデバイスをリーフとして構成したヅリーのルートからリーフまで のパス上のルート、 ノード、 およびリーフに各々キーを対応付けたキ一ツリーを 構成し、 該キーツリーを構成するパスを選択して選択パス上の下位キーによる上 位キーの暗号化処理データを有し、 前記選択パスに対応するノードキーセッ トを 利用可能なデバイスにおいてのみ復号可能とした有効化キ一ブロック （ E K B ) をデパイスに提供する構成を持つ情報処理システムであり、
前記有効化キーブロック （E K B ) は、
前記キーツリ一の部分ッリーとして設定されるサブヅリ一の各々において復号 処理可能なサブ有効化キープ Dヅク （サブ E K B )の合成 E K Bとして構成され、 該合成 E K Bは、 格納する各サブ有効化ギ一ブロック （サブ E K B ) 内のキー 配列を保持し、 かつ、 各サブ E K Bに対応してサブ E K B格納領域のデータ長お よびサブ E K B識別デ一夕を付加した構成を有することを特徴とする情報処理シ ステム。
37. 前記サブヅリ一は、 カテゴリに基づいて区分され、 カテゴリ ·ェンティ ティによって管理されるカテゴリツリーであり、
前記サブ有効化キ一ブロック （サブ EKB) は、 前記カテゴリ 'エンティティ において自己の管理するカテゴリッリーに属するノードまたはリーフに対応付け られたキーに基づいて処理可能な E K Bとして生成され、
キー発行センタ一 （KD C) において、 前記カテゴリ · エンティティの生成し たサブ E KBに基づいて、 複数のカテゴリヅリ一に共通に使用可能な E KBとし ての合成 E KBを生成する構成であることを特徴とする請求項 3 6に記載の情報 処理システム。
38. 前記サブ有効化キ一ブロック （サブ EKB) の各々は、 各々独自のアル ゴリズム、 独自のキー 'データ長を持つサブ有効化キーブロック （サブ EKB) として構成されていることを特徴とする請求項 36に記載の情報処理システム。
3 9. 前記サブヅリ一は、 カテゴリに基づいて区分され、 カテゴリ ' ェンティ ティによって管理されるカテゴリッリ一であり、
前記サブ有効化キ一ブロック （サブ EKB) は、 前記カテゴリ 'エンティティ において自己の管理するカテゴリッリーに属するノードまたはリーフに対応付け られたキーに基づいて処理可能な E K Bとして生成され、
前記合成 E KB内の各サブ E KBに対応して格納される前記サブ E KB識別デ 一夕は、 カテゴリヅリーを構成するノードの識別子であるノード I Dであること を特徴とする請求項 36に記載の情報処理システム。
40. 前記合成 E KBに格納されるサブ有効化キーブロック （サブ EKB) の 各々は、
キーツリーを構成する各ノードに対応して設定されるノードキーを下位ノード キーまたは下位リーフキーを用いて暗号化した暗号化キ一データと、
前記暗号化キーデータ各々のノード位置の下位の左右位置のノードまたはリ一 フ位置の暗号化キーデータの有無を示す夕グを含む構成であることを特徴とする 請求項 3 6に記載の情報処理システム。
41. 前記合成 E KBに格納されるサブ有効化キーブロック （サブ EKB) の 各々は、
該サブ E K Bを復号可能な末端ノードまたはリーフを最下段とした簡略化した ヅリーを構成するパスを選択して不要ノードを省略することにより再構築される 再構築階層ヅリ一のノードまたはリーフに対応するキーを暗号化キーデータとし て有することを特徴とする請求項 3 6に記載の情報処理システム。
42. カテゴリに基づいて区分されたサブヅリーとしてのカテゴリッリ一によ り構成され、 複数のデバイスをリーフとして構成したヅリーのルートからリーフ までのパス上のルート、 ノード、 およびリーフに各々キーを対応付けたキーツリ —を構成し、 該キーツリーを構成するパスを選択して選択パス上の下位キーによ る上位キーの暗号化処理データを有し、 前記選択パスに対応するノードキーセッ トを利用可能なデバイスにおいてのみ復号可能とした有効化キープ口ック （E K B) を格納した情報記録媒体であり、
前記キーヅリ一の部分ッリ一として設定されるサブッリ一の各々において復号 処理可能なサブ有効化キ一ブロック （サブ EKB) の合成 E KBを格納し、 該合 成 E KB内に含まれる各サブ E KBに対応してサブ E KB格納領域のデ一夕長お よびサブ E KB識別データを格納した構成を有することを特徴とする情報記録媒 体。
43. 前記サブ有効化キーブロック （サブ EKB) の各々は、 各々独自のアル ゴリズム、 独自のキー 'データ長を持つサブ有効化キーブロック （サブ EKB) として構成されていることを特徴とする請求項 42に記載の情報記録媒体。
44. 複数のデバイスをリーフとして構成したヅリ一のルートからリーフまで のパス上のルート、 ノード、 およびリーフに各々キーを対応付けたキーヅリーを 構成し、 該キーヅリーを構成するパスを選択して選択パス上の下位キーによる上 位キーの暗号化処理データを有し、 前記選択パスに対応するノードキーセッ トを 利用可能なデバイスにおいてのみ復号可能とした有効化キーブロック （EKB) をデバイスに提供する構成を持つシステムにおける情報処理方法であり、 前記有効化キーブロック （EKB) は、
前記キ一ヅリ一の部分ヅリーとして設定されるサブヅリ一の各々において復号 処理可能なサブ有効化キープ口ヅク （サブ E KB)の合成 E KBとして構成され、 該合成 E KBは、 格納する各サブ有効化キ一ブロック （サブ EKB) 内のキー 配列を保持し、 かつ、 各サブ E KBに対応してサブ E KB格納領域のデータ長お よびサブ E KB識別デ一夕を付加した構成を持つ合成 E K Bとしてデバイスに提 供することを特徴とする情報処理方法。
45. 前記サブヅリ一は、 カテゴリに基づいて区分され、 カテゴリ · ェンティ ティによって管理されるカテゴリヅリーであり、
前記サブ有効化キーブロック （サブ EKB) は、 前記カテゴリ 'エンティティ において自己の管理するカテゴリヅリーに属するノードまたはリーフに対応付け られたキーに基づいて処理可能な E KBとして生成され、
キー発行センター （KD C) において、 前記カテゴリ ' エンティティの生成し たサブ E KBに基づいて、 複数のカテゴリッリ一に共通に使用可能な E KBとし ての合成 E KBを生成することを特徴とする請求項 44に記載の情報処理方法。
46. 前記サブ有効化キーブロック （サブ EKB) の各々は、 各々独自の.アル ゴリズム、 独自のキー 'データ長を持つサブ有効化キーブロック （サブ EKB) として構成されることを特徴とする請求項 44に記載の情報処理方法。
47. 前記サブツリーは、 カテゴリに基づいて区分され、 カテゴリ ' ェンティ ティによって管理されるカテゴリツリーであり、 前記サブ有効化キーブロック （サブ E K B ) は、 前記カテゴリ 'エンティティ において自己の管理するカテゴリッリ一に属するノ一ドまたはリーフに対応付け られたキ一に基づいて処理可能な E K Bとして生成され、
前記合成 E K B内の各サブ E K Bに対応して格納される前記サブ E K B識別デ 一夕は、 カテゴリヅリ一を構成するノードの識別子であるノード I Dであること を特徴とする請求項 4 4に記載の情報処理方法。
4 8 . 前記合成 E K Bに格納されるサブ有効化キーブロック （サブ E K B ) の 各々は、
キーツリ一を構成する各ノードに対応して設定されるノードキーを下位ノード キーまたは下位リーフキーを用いて暗号化した暗号化キーデータと、
前記暗号化キーデータ各々のノード位置の下位の左右位置のノードまたはリ一 フ位置の暗号化キーデータの有無を示す夕グを含むことを特徴とする請求項 4 4 に記載の情報処理方法。
4 9 . 前記合成 E K Bに格納されるサブ有効化キーブロック （サブ E K B ) の 各々は、
該サブ E K Bを復号可能な末端ノードまたはリーフを最下段とした簡略化した ヅリ一を構成するパスを選択して不要ノードを省略することにより再構築される 再構築階層ヅリーのノードまたはリーフに対応するキーを暗号化キーデータとし て有することを特徴とする請求項 4 に記載の情報処理方法。
5 0 . 複数のデバイスをリーフとして構成したヅリーのル一トからリーフまで のパス上のルート、 ノード、 およびリーフに各々キ一を対応付けたキーヅリーを 構成し、 該キーヅリ一を構成するパスを選択して選択パス上の下位キーによる上 位キーの暗号化処理データを有し、 前記選択パスに対応するノードキーセッ トを 利用可能なデバイスにおいてのみ復号可能とした有効化キーブロック （ E K B ) をデバイスに提供する構成を持つシステムにおける有効化キープロック（ E K B ) 生成処理をコンピュータ · システム上で実行せしめるコンピュータ · プログラム を記録したプログラム記録媒体であって、 前記コンピュータ · プログラムは、 前記キーツリ一の部分ヅリーとして設定されるサブヅリーの各々において復号 処理可能なサブ有効化キーブロック （サブ EKB) の選択ステップと、
各選択サブ E KB.に対応してサブ E KB格納領域のデータ長およびサブ E K B 識別デ一夕を付加するステップと、
を有することを特徴とするプログラム記録媒体。
PCT/JP2001/011236 2000-12-26 2001-12-21 Systeme et procede de traitement d'informations WO2002052780A1 (fr)

Priority Applications (6)

Application Number Priority Date Filing Date Title
KR1020027011170A KR100859622B1 (ko) 2000-12-26 2001-12-21 정보 처리 시스템 및 방법
AT01272280T ATE444616T1 (de) 2000-12-26 2001-12-21 Verfahren und vorrichtung zur informationsverarbeitung
US10/204,731 US7346170B2 (en) 2000-12-26 2001-12-21 Information processing system and method
EP01272280A EP1249962B1 (en) 2000-12-26 2001-12-21 Information processing system and method
DE60140041T DE60140041D1 (de) 2000-12-26 2001-12-21 Verfahren und vorrichtung zur informationsverarbeitung
HK03109358.4A HK1058589A1 (en) 2000-12-26 2003-12-23 Information processing system and method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2000-395844 2000-12-26
JP2000395844A JP4581246B2 (ja) 2000-12-26 2000-12-26 情報処理システム、および情報処理方法、並びにプログラム記録媒体

Publications (1)

Publication Number Publication Date
WO2002052780A1 true WO2002052780A1 (fr) 2002-07-04

Family

ID=18861236

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2001/011236 WO2002052780A1 (fr) 2000-12-26 2001-12-21 Systeme et procede de traitement d'informations

Country Status (9)

Country Link
US (1) US7346170B2 (ja)
EP (1) EP1249962B1 (ja)
JP (1) JP4581246B2 (ja)
KR (1) KR100859622B1 (ja)
CN (1) CN100418316C (ja)
AT (1) ATE444616T1 (ja)
DE (1) DE60140041D1 (ja)
HK (1) HK1058589A1 (ja)
WO (1) WO2002052780A1 (ja)

Families Citing this family (50)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4581246B2 (ja) * 2000-12-26 2010-11-17 ソニー株式会社 情報処理システム、および情報処理方法、並びにプログラム記録媒体
MXPA02011835A (es) * 2001-03-29 2003-10-06 Matsushita Electric Ind Co Ltd Sistema de proteccion de datos que proteje datos al encriptar los datos.
WO2003034425A1 (en) * 2001-10-12 2003-04-24 Koninklijke Philips Electronics N.V. Apparatus and method for reading or writing block-wise stored user data
US7340603B2 (en) * 2002-01-30 2008-03-04 Sony Corporation Efficient revocation of receivers
US7451310B2 (en) * 2002-12-02 2008-11-11 International Business Machines Corporation Parallelizable authentication tree for random access storage
US8015301B2 (en) * 2003-09-30 2011-09-06 Novell, Inc. Policy and attribute based access to a resource
US7467415B2 (en) * 2003-09-30 2008-12-16 Novell, Inc. Distributed dynamic security for document collaboration
US7299493B1 (en) * 2003-09-30 2007-11-20 Novell, Inc. Techniques for dynamically establishing and managing authentication and trust relationships
EP1601154A1 (en) * 2004-05-28 2005-11-30 Sap Ag Client authentication using a challenge provider
JP2006041737A (ja) * 2004-07-23 2006-02-09 Toshiba Corp コンテンツ利用方法及びプログラム
US11734393B2 (en) * 2004-09-20 2023-08-22 Warner Bros. Entertainment Inc. Content distribution with renewable content protection
US7813510B2 (en) * 2005-02-28 2010-10-12 Motorola, Inc Key management for group communications
KR20060109237A (ko) * 2005-04-13 2006-10-19 삼성전자주식회사 라이센스 정보에 기초하여 컨텐트의 사용을 제어하기 위한암호화/복호화 방법 및 장치
CA2603230C (en) * 2005-04-18 2013-03-26 Research In Motion Limited System and method for secure messaging between wireless device and application gateway
JP4537882B2 (ja) * 2005-04-18 2010-09-08 株式会社東芝 情報端末装置
JP4596256B2 (ja) * 2005-08-02 2010-12-08 ソニー株式会社 送受信システムおよび方法、送信装置および方法、受信装置および方法、並びにプログラム
WO2007028406A1 (en) * 2005-09-06 2007-03-15 Nero Ag Method and apparatus for establishing a communication key between a first communication partner and a second communication partner using a third party
JP4975035B2 (ja) * 2005-09-16 2012-07-11 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ 暗号化による役割ベースのアクセス制御
JP2007150846A (ja) * 2005-11-29 2007-06-14 Toshiba Corp コンテンツ再生システム
FR2899748B1 (fr) * 2006-04-07 2008-11-28 Thales Sa Schema de diffusion hybride efficace, adapte a une faible bande passante
CN101051899B (zh) * 2006-05-22 2011-05-04 华为技术有限公司 无线通信网络中生成移动ip密钥的方法及系统
JP4837463B2 (ja) * 2006-07-11 2011-12-14 Ｋｄｄｉ株式会社 鍵管理システム、鍵管理方法およびプログラム
FR2921530A1 (fr) * 2007-09-20 2009-03-27 France Telecom Procede de generation d'une cle cryptographique associee a un sous-groupe dans une hierarchie, programme d'ordinateur et dispositifs associes
US8627079B2 (en) * 2007-11-01 2014-01-07 Infineon Technologies Ag Method and system for controlling a device
US8908870B2 (en) * 2007-11-01 2014-12-09 Infineon Technologies Ag Method and system for transferring information to a device
US9729316B2 (en) * 2008-02-27 2017-08-08 International Business Machines Corporation Unified broadcast encryption system
US8254580B2 (en) * 2009-09-30 2012-08-28 Telefonaktiebolaget L M Ericsson (Publ) Key distribution in a hierarchy of nodes
CN102238146B (zh) * 2010-04-27 2014-10-08 中国移动通信集团公司 认证方法、装置、认证中心及系统
US8335921B2 (en) 2010-12-17 2012-12-18 Google, Inc. Writing application data to a secure element
US8807440B1 (en) 2010-12-17 2014-08-19 Google Inc. Routing secure element payment requests to an alternate application
US8352749B2 (en) 2010-12-17 2013-01-08 Google Inc. Local trusted services manager for a contactless smart card
US9691055B2 (en) 2010-12-17 2017-06-27 Google Inc. Digital wallet
US8171525B1 (en) 2011-09-15 2012-05-01 Google Inc. Enabling users to select between secure service providers using a central trusted service manager
US8255687B1 (en) * 2011-09-15 2012-08-28 Google Inc. Enabling users to select between secure service providers using a key escrow service
US8313036B1 (en) 2011-09-16 2012-11-20 Google Inc. Secure application directory
US20130159526A1 (en) * 2011-12-20 2013-06-20 Htc Corporation Method of handling access control information and related communication device
US8385553B1 (en) 2012-02-28 2013-02-26 Google Inc. Portable secure element
US9008316B2 (en) * 2012-03-29 2015-04-14 Microsoft Technology Licensing, Llc Role-based distributed key management
US10327032B2 (en) 2012-03-29 2019-06-18 Sony Interactive Entertainment LLC Extracting media content from social networking services
US9986273B2 (en) * 2012-03-29 2018-05-29 Sony Interactive Entertainment, LLC Extracting media content from social networking services
US8429409B1 (en) 2012-04-06 2013-04-23 Google Inc. Secure reset of personal and service provider information on mobile devices
US9342699B2 (en) * 2013-11-06 2016-05-17 Blackberry Limited Method and apparatus for controlling access to encrypted data
US9172532B1 (en) * 2013-11-19 2015-10-27 Amazon Technologies, Inc. Multi-tiered encryption system for efficiently regulating use of encryption keys
EP3248360B1 (en) 2015-01-19 2020-05-06 Inauth, Inc. Systems and methods for trusted path secure communication
EP3411835B1 (en) * 2016-02-05 2023-07-05 DeepMind Technologies Limited Augmenting neural networks with hierarchical external memory
US10467384B2 (en) * 2016-05-18 2019-11-05 International Business Machines Corporation Subset-difference broadcast encryption with blacklisting
CN106790464A (zh) * 2016-12-09 2017-05-31 光科技股份有限公司 一种基于智能网荷互动终端的数据交换网络
CN107800704A (zh) * 2017-10-27 2018-03-13 山东大学 适应于轻型同步相量测量仪通信的数据加密方法和系统
CN108063756B (zh) * 2017-11-21 2020-07-03 阿里巴巴集团控股有限公司 一种密钥管理方法、装置及设备
US11303632B1 (en) * 2018-06-08 2022-04-12 Wells Fargo Bank, N.A. Two-way authentication system and method

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5748736A (en) * 1996-06-14 1998-05-05 Mittra; Suvo System and method for secure group communications via multicast or broadcast
JPH11187013A (ja) * 1997-12-24 1999-07-09 Ibm Japan Ltd 暗号鍵配信システム
US6049878A (en) * 1998-01-20 2000-04-11 Sun Microsystems, Inc. Efficient, secure multicasting with global knowledge
WO2001003364A1 (en) * 1999-07-06 2001-01-11 Matsushita Electric Industrial Co., Ltd. Dual encryption protocol for scalable secure group communication
WO2001003365A1 (en) * 1999-07-06 2001-01-11 Matsushita Electric Industrial Co., Ltd. Distributed group key management scheme for secure many-to-many communication

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US574836A (en) * 1897-01-05 Wilson d
US548736A (en) * 1895-10-29 Machine for sewing long lengths of fabric
IL130963A (en) * 1999-07-15 2006-04-10 Nds Ltd Key management for content protection
EP1075108A1 (en) * 1999-07-23 2001-02-07 BRITISH TELECOMMUNICATIONS public limited company Cryptographic data distribution
JP2001358707A (ja) * 2000-06-15 2001-12-26 Sony Corp 暗号鍵ブロックを用いた情報処理システムおよび情報処理方法、並びにプログラム提供媒体
JP4581246B2 (ja) * 2000-12-26 2010-11-17 ソニー株式会社 情報処理システム、および情報処理方法、並びにプログラム記録媒体
JP4078802B2 (ja) * 2000-12-26 2008-04-23 ソニー株式会社 情報処理システム、情報処理方法、情報処理装置、および情報記録媒体、並びにプログラム記録媒体
JP4710132B2 (ja) * 2000-12-26 2011-06-29 ソニー株式会社 情報処理システム、および情報処理方法、並びにプログラム記録媒体
US7039803B2 (en) * 2001-01-26 2006-05-02 International Business Machines Corporation Method for broadcast encryption and key revocation of stateless receivers
US7043024B1 (en) * 2001-04-18 2006-05-09 Mcafee, Inc. System and method for key distribution in a hierarchical tree
US7308583B2 (en) * 2002-01-25 2007-12-11 Matsushita Electric Industrial Co., Ltd. Data distribution system
JP3818503B2 (ja) * 2002-04-15 2006-09-06 ソニー株式会社 情報処理装置および方法、並びにプログラム
KR20060013333A (ko) * 2003-04-30 2006-02-09 소니 가부시끼 가이샤 데이터 처리 방법, 그 프로그램, 그 장치 및 기록 매체
US20050210014A1 (en) * 2004-03-08 2005-09-22 Sony Corporation Information-processing method, decryption method, information-processing apparatus and computer program

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5748736A (en) * 1996-06-14 1998-05-05 Mittra; Suvo System and method for secure group communications via multicast or broadcast
JPH11187013A (ja) * 1997-12-24 1999-07-09 Ibm Japan Ltd 暗号鍵配信システム
US6049878A (en) * 1998-01-20 2000-04-11 Sun Microsystems, Inc. Efficient, secure multicasting with global knowledge
WO2001003364A1 (en) * 1999-07-06 2001-01-11 Matsushita Electric Industrial Co., Ltd. Dual encryption protocol for scalable secure group communication
WO2001003365A1 (en) * 1999-07-06 2001-01-11 Matsushita Electric Industrial Co., Ltd. Distributed group key management scheme for secure many-to-many communication

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
DONDETI L.R. ET AL.: "A dual encryption protocol for scalable secure multicasting", PROCEEDINGS OF IEEE INTERNATIONAL SYMPOSIUM ON COMPUTERS AND COMMUNICATIONS, 1999, pages 2 - 8, XP010344148 *
MOYER M.J. ET AL.: "A survey of security issues in multicast communications", IEEE NETWORK, vol. 13, no. 6, November 1999 (1999-11-01) - December 1999 (1999-12-01), pages 12 - 23, XP000875727 *
WALDVOGEL M. ET AL.: "The VersaKey framework: Versatile group key management", IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, vol. 17, no. 9, September 1999 (1999-09-01), pages 1614 - 1631, XP002941560 *
WONG C.K. ET AL.: "Secure group communications using key graphs", PROCEEDINGS OF ACM SIGCOMM'98, 1998, pages 68 - 79, XP000914425, Retrieved from the Internet <URL:http://www.acm.org/sigcomm/sigcomm98/tp/technical.html> *

Also Published As

Publication number Publication date
EP1249962B1 (en) 2009-09-30
US7346170B2 (en) 2008-03-18
DE60140041D1 (de) 2009-11-12
JP2002198950A (ja) 2002-07-12
KR100859622B1 (ko) 2008-09-23
US20030185396A1 (en) 2003-10-02
EP1249962A4 (en) 2005-02-02
EP1249962A1 (en) 2002-10-16
JP4581246B2 (ja) 2010-11-17
ATE444616T1 (de) 2009-10-15
HK1058589A1 (en) 2004-05-21
CN1426642A (zh) 2003-06-25
CN100418316C (zh) 2008-09-10
KR20030019317A (ko) 2003-03-06

Similar Documents

Publication Publication Date Title
KR100859622B1 (ko) 정보 처리 시스템 및 방법
JP4710132B2 (ja) 情報処理システム、および情報処理方法、並びにプログラム記録媒体
JP4078802B2 (ja) 情報処理システム、情報処理方法、情報処理装置、および情報記録媒体、並びにプログラム記録媒体
KR100840823B1 (ko) 암호 키 블록을 이용한 정보 처리 시스템 및 방법
JP4023083B2 (ja) 情報処理システム、情報処理方法、および情報記録媒体、並びにプログラム提供媒体
WO2001078298A1 (fr) Systeme et procede de traitement d&#39;informations
JP2001358707A (ja) 暗号鍵ブロックを用いた情報処理システムおよび情報処理方法、並びにプログラム提供媒体
WO2002087147A1 (fr) Dispositif et procede d&#39;enregistrement/de reproduction d&#39;informations
JP4120135B2 (ja) 暗号鍵ブロックを用いた情報処理システムおよび情報処理方法、並びにプログラム提供媒体
JP4806847B2 (ja) 情報処理システム、情報処理方法、および情報記録媒体、並びにプログラム記録媒体
JP3988385B2 (ja) 情報処理システム、情報処理方法、および情報記録媒体、並びにプログラム記録媒体
JP2010288291A (ja) 情報処理システム、および情報処理方法、並びにプログラム記録媒体

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): CN KR SG US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR

WWE Wipo information: entry into national phase

Ref document number: 2001272280

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 1020027011170

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 2001272280

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 018084214

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 10204731

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 1020027011170

Country of ref document: KR