HK1061613B - Information processing apparatus - Google Patents

Description

Information processing apparatus

Technical Field

The present invention relates to an information processing apparatus, and particularly to an information processing apparatus which can manage contents belonging to different types with a single apparatus.

Background

Recently, with the spread of the internet, proposals have been made to distribute various contents such as audio and video via the internet, and the proposals have been partially put into practical use. In this case, various usage conditions are defined for the content in order to protect the copyright of the content, and only a device satisfying the usage conditions can be used.

However, conventionally, all contents are managed in the same management form in a single device. As a result, it is not possible to change the management form of the content for each type of service, use condition, supply source of the content, and the like, and it is not possible to flexibly manage the content provider, which causes a problem in operability of the device.

Disclosure of Invention

The present invention is directed to such a situation, and it is possible to improve convenience of content providers and users and operability of devices by using a plurality of contents belonging to different types such as different services, use conditions, and contents providing sources by a single device.

The 1 st information processing apparatus of the present invention is characterized by comprising: an assigning unit that uniquely assigns the other information processing apparatus to a leaf lower than a 1 st node in a key management hierarchical tree structure in which a first classification is assigned to the 1 st node in a predetermined hierarchy; and a providing unit that provides the device node key corresponding to the path from the leaf allocated by the allocating unit to the 1 st node to the other information processing device.

The providing unit provides the device node key together with leaf identification information for identifying the leaf.

The method can also comprise the following steps: a receiving unit that receives a license request including leaf identification information from the other information processing apparatus and license identification information identifying a license for permitting use of the content; a transmission unit for transmitting a license composed of an electronic signature to which the leaf identification information included in the license request is added.

The providing unit provides the public key of the device itself together with the secret key and the public key of the other information processing device.

The 1 st information processing method of the present invention is characterized by comprising: an assigning step of assigning the other information processing apparatuses uniquely to a leaf lower than a 1 st node in a key management hierarchical tree structure in which a classification of a provision form of the content is assigned to the 1 st node in a predetermined hierarchy; a providing step of providing the device node key corresponding to the path from the leaf to the 1 st node allocated in the processing of the allocating step to the other information processing device.

The program of the 1 st recording medium of the present invention is characterized by comprising: an assigning step of assigning the other information processing apparatuses uniquely to a leaf lower than a 1 st node in a key management hierarchical tree structure in which a classification of a provision form of the content is assigned to the 1 st node in a predetermined hierarchy; a providing step of providing the device node key corresponding to the path from the leaf to the 1 st node allocated in the processing of the allocating step to the other information processing device.

The 1 st program of the present invention causes a computer to realize the steps of: an assigning step of assigning the other information processing apparatuses uniquely to a leaf lower than a 1 st node in a key management hierarchical tree structure in which a classification of a provision form of the content is assigned to the 1 st node in a predetermined hierarchy; a providing step of providing the device node key corresponding to the path from the leaf to the 1 st node allocated in the processing of the allocating step to the other information processing device.

The 2 nd information processing apparatus of the present invention is characterized by comprising: a receiving unit that receives leaf identification information supplied from another information processing apparatus to identify a leaf of a key management hierarchical tree structure assigned to an information processing apparatus that uses content; and a transmitting unit that transmits a license including the leaf identification information when the leaf identification information received by the receiving unit is leaf identification information of a leaf lower than the 1 st node in a key management hierarchical tree structure in which the classification of the provision form of the content is assigned to the 1 st node in the predetermined hierarchy.

The 2 nd information processing method of the present invention is characterized by comprising: a reception step of receiving leaf identification information supplied from another information processing apparatus to identify a leaf of a key management hierarchical tree structure assigned to the other information processing apparatus; a transmission step of transmitting a license including leaf identification information when the leaf identification information received by the processing of the reception step is leaf identification information of a leaf lower than the 1 st node in a key management hierarchical tree structure in which the classification of the provision form of the content is assigned to the 1 st node in the predetermined hierarchy.

The program of the 2 nd recording medium of the present invention is characterized by comprising: a reception step of receiving leaf identification information supplied from another information processing apparatus to identify a leaf of a key management hierarchical tree structure assigned to the other information processing apparatus; a transmission step of transmitting a license including leaf identification information when the leaf identification information received by the processing of the reception step is leaf identification information of a leaf lower than the 1 st node in a key management hierarchical tree structure in which the classification of the provision form of the content is assigned to the 1 st node in the predetermined hierarchy.

The 2 nd program of the present invention causes a computer to realize the steps of: a reception step of receiving leaf identification information supplied from another information processing apparatus to identify a leaf of a key management hierarchical tree structure assigned to the other information processing apparatus; a transmission step of transmitting a license including leaf identification information when the leaf identification information received by the processing of the reception step is leaf identification information of a leaf lower than the 1 st node in a key management hierarchical tree structure in which the classification of the provision form of the content is assigned to the 1 st node in the predetermined hierarchy.

The 3 rd information processing apparatus of the present invention is characterized by comprising: a receiving unit that receives a content request including content identification information identifying a content; a transmission unit transmits encrypted content including an Effective Key Block (EKB) that can be decrypted by a device node key corresponding to a path from a lower leaf of the 1 st node to the 1 st node in a key management hierarchical tree structure in which a classification of a content provision form is assigned to the 1 st node of a predetermined hierarchy.

The 3 rd information processing method of the present invention is characterized by comprising: a receiving step of receiving a content request including content identification information identifying a content; a transmission step of transmitting encrypted content including an Effective Key Block (EKB) that can be decrypted by a device node key corresponding to a path from a lower leaf of the 1 st node to the 1 st node in a key management hierarchical tree structure in which a classification of a content provision form is assigned to the 1 st node of a predetermined hierarchy.

A program of a 3 rd recording medium of the present invention is characterized by comprising: a receiving step of receiving a content request including content identification information identifying a content; a transmission step of transmitting encrypted content including an Effective Key Block (EKB) that can be decrypted by a device node key corresponding to a path from a lower leaf of the 1 st node to the 1 st node in a key management hierarchical tree structure in which a classification of a content provision form is assigned to the 1 st node of a predetermined hierarchy.

The 3 rd program of the present invention causes a computer to realize the steps of: a receiving step of receiving a content request including content identification information identifying a content; a transmission step of transmitting encrypted content including an Effective Key Block (EKB) that can be decrypted by a device node key corresponding to a path from a lower leaf of the 1 st node to the 1 st node in a key management hierarchical tree structure in which a classification of a content provision form is assigned to the 1 st node of a predetermined hierarchy.

The 4 th information processing apparatus of the present invention is characterized by comprising: a storage unit that stores a device node key assigned to itself, the key corresponding to a leaf from the lower order of the 1 st node to the 1 st node in a key management hierarchical tree structure that assigns a classification of a provision form of content to the 1 st node in a predetermined hierarchy; a content acquisition unit that acquires encrypted content including an Effective Key Block (EKB) in which the 1 st node corresponds to a root key; a decryption unit that decrypts the encrypted content by performing decryption processing using the device node key stored in the storage unit on an Effective Key Block (EKB) included in the encrypted content acquired by the content acquisition unit; and an output unit that outputs the content decrypted by the decryption unit.

The 4 th information processing method of the present invention is characterized by comprising: a storage control step of controlling storage of a device node key assigned to the device node key, the key corresponding to a leaf from the lower order of the 1 st node to the 1 st node in a key management hierarchical tree structure in which classification of a provision form of content is assigned to the 1 st node in a predetermined hierarchy; a content acquisition step of acquiring encrypted content including an Effective Key Block (EKB) in which a 1 st node corresponds to a root key; a decryption step of decrypting the encrypted content by decryption processing of an Effective Key Block (EKB) included in the encrypted content acquired by the processing of the content acquisition step using the device node key stored in the processing of the storage control step; an output step of outputting the content decrypted by the processing of the decryption step.

The program of the 4 th recording medium of the present invention is characterized by comprising: a storage control step of controlling storage of a device node key assigned to the device node key, the key corresponding to a leaf from the lower order of the 1 st node to the 1 st node in a key management hierarchical tree structure in which classification of a provision form of content is assigned to the 1 st node in a predetermined hierarchy; a content acquisition step of acquiring encrypted content including an Effective Key Block (EKB) in which a 1 st node corresponds to a root key; a decryption step of decrypting the encrypted content by decryption processing of an Effective Key Block (EKB) included in the encrypted content acquired by the processing of the content acquisition step using the device node key stored in the processing of the storage control step; an output step of outputting the content decrypted by the processing of the decryption step.

The 4 th program of the present invention causes a computer to realize the steps of: a storage control step of controlling storage of a device node key assigned to the device node key, the key corresponding to a leaf from the lower order of the 1 st node to the 1 st node in a key management hierarchical tree structure in which classification of a provision form of content is assigned to the 1 st node in a predetermined hierarchy; a content acquisition step of acquiring encrypted content including an Effective Key Block (EKB) in which a 1 st node corresponds to a root key; a decryption step of decrypting the encrypted content by decryption processing of an Effective Key Block (EKB) included in the encrypted content acquired by the processing of the content acquisition step using the device node key stored in the processing of the storage control step; an output step of outputting the content decrypted by the processing of the decryption step.

In the 1 st information processing apparatus, method, and program according to the present invention, in a key management hierarchical tree structure in which a classification of a content provision form is assigned to the 1 st node in a predetermined hierarchy, other information processing apparatuses are uniquely assigned to a leaf lower than the 1 st node, and an apparatus node key corresponding to a path from the assigned leaf to the 1 st node is provided to the other information processing apparatuses.

In the 2 nd information processing apparatus, method, and program of the present invention, leaf identification information supplied from another information processing apparatus for identifying a leaf of a key management hierarchical tree structure assigned to the other information processing apparatus is received; in a key management hierarchical tree structure in which a category of a content provision form is assigned to a 1 st node in a predetermined hierarchy, when the received leaf identification information is leaf identification information of a leaf lower than the 1 st node, a license including the leaf identification information is transmitted.

In the 3 rd information processing apparatus, method, and program of the present invention, a content request including content identification information identifying a content is received; in a key management hierarchical tree structure in which a category of a content provision form is assigned to a 1 st node in a predetermined hierarchy, encrypted content including an Effective Key Block (EKB) which can be decrypted by a device node key corresponding to a path from a lower leaf of the 1 st node to the 1 st node is transmitted.

In a 4 th information processing apparatus, method, and program according to the present invention, storage of a device node key assigned to the apparatus node is controlled, and the key is assigned to a 1 st node in a predetermined hierarchy in a key management hierarchical tree structure in which classification of a provision form of content is assigned to the 1 st node, the key corresponding to the 1 st node from a lower leaf of the 1 st node; acquiring encrypted content including a valid key block (EKB) in which a 1 st node corresponds to a root key; decrypting the encrypted content by performing decryption processing on an Effective Key Block (EKB) included in the acquired encrypted content by using the device node key; outputting the decrypted content.

Drawings

Fig. 1 is a block diagram showing a configuration of a content providing system according to the present invention.

Fig. 2 is a block diagram showing a configuration of the client of fig. 1.

Fig. 3 is a flowchart illustrating a downloading process of content of the client of fig. 1.

Fig. 4 is a flowchart illustrating a content providing process of the content server of fig. 1.

Fig. 5 is a diagram showing an example of the format in step S26 of fig. 4.

Fig. 6 is a flowchart illustrating a content reproduction process of the client of fig. 1.

Fig. 7 is a flowchart illustrating the license acquisition process in step S43 in fig. 6 in detail.

Fig. 8 is a diagram showing a configuration of a license.

Fig. 9 is a flowchart illustrating a process of license provision by the license server of fig. 1.

Fig. 10 is a detailed flowchart illustrating the license updating process in step S45 of fig. 6.

Fig. 11 is a flowchart illustrating a license update process of the license server of fig. 1.

Fig. 12 is a structural diagram illustrating a key.

Fig. 13 is a diagram illustrating type nodes.

Fig. 14 is a diagram showing a specific example of correspondence between nodes and devices.

Fig. 15A is a structural diagram illustrating an effective key block.

Fig. 15B is a structural diagram illustrating an effective key block.

Fig. 16 is a diagram illustrating the use of an effective key block.

Fig. 17 is a diagram showing an example of the format of an effective key block.

Fig. 18 is a structural diagram illustrating a marker of an effective key block.

Fig. 19 is a diagram illustrating content decryption processing using DNK.

Fig. 20 is a diagram showing an example of an effective key block.

Fig. 21 is a diagram illustrating the distribution of a plurality of contents to a single device.

Fig. 22 is a diagram illustrating the type of license.

Fig. 23 is a sequence diagram illustrating login processing.

Fig. 24 is a flowchart illustrating the client's stripping process.

Fig. 25 is a structural diagram illustrating a watermark.

Fig. 26 is a diagram showing an example of the format of content.

Fig. 27 is a diagram showing an example of a public key certificate.

Fig. 28 is a diagram illustrating distribution of content.

Fig. 29 is a flowchart illustrating the logout process of the content of the client.

Fig. 30 is a diagram illustrating an example of tracing a valid key block by a marker.

Fig. 31 is a diagram showing an example of the configuration of an effective key block.

Fig. 32 is a structural diagram illustrating a flag.

Fig. 33 is a flowchart illustrating the license purchase processing of the client.

Fig. 34 is a flowchart illustrating the license purchase processing of the license server.

Fig. 35 is a diagram showing an example of the configuration of the flag.

Fig. 36 is a flowchart illustrating a login process of a client's certificate.

Fig. 37 is a flowchart illustrating the certificate registration processing of the content server.

Fig. 38 is a diagram showing an example of a certificate of a group.

Fig. 39 is a flowchart illustrating a process of the content server when grouping is performed.

Fig. 40 is a diagram showing an example of encryption of a content key.

Fig. 41 is a flowchart illustrating the processing of the client belonging to the group.

Fig. 42 is a flowchart illustrating a process of a client performing license deregistration to other clients.

Fig. 43 is a flowchart illustrating a process of receiving a client that has permitted logout from another client.

Fig. 44 is a flowchart illustrating the reproduction processing of the client that received the license logout.

Fig. 45 is a flowchart illustrating a process of the client that accepts registration of a license from another client.

Fig. 46 is a flowchart illustrating a process of a client that registers a license with another client.

Fig. 47 is a diagram illustrating generation of a MAC.

Fig. 48 is a flowchart illustrating the decryption process of the ICV generated key.

Fig. 49 is a diagram for explaining another decryption process of the ICV generated key.

Fig. 50A is a diagram illustrating management of licensed copying by an ICV.

Fig. 50B is a diagram illustrating management of licensed copying by an ICV.

Fig. 51 is a diagram illustrating management of a license.

Detailed Description

Fig. 1 shows a configuration of a content providing system according to the present invention. Clients 1-1 and 1-2 are connected to the internet 2 (hereinafter, these clients will be simply referred to as clients 1 when there is no need to distinguish them). In this example, only 2 clients are shown, but any number of clients can be connected to the internet 2.

A content server 3 for providing content to the client 1 is connected to the internet 2; a license server 4 that gives a license necessary for using the content provided by the content server 3 to the client 1; and a charging server 5 for performing charging processing to the client 1 when the client 1 receives the license.

The content server 3, the license server 4, and the charging server 5 may be connected to the internet 2 in any number.

Fig. 2 shows the configuration of the client 1.

In fig. 2, a CPU (Central Processing Unit) 21 performs various processes based on a program stored in a ROM (Read Only Memory) 22 or a program loaded from a storage Unit 28 into a ram (random Access Memory) 23. The timer 20 performs a time counting operation and supplies time information to the CPU 21. The RAM23 also stores data and the like necessary for the CPU21 to perform various processes as appropriate.

The encryption/decryption section 24 encrypts the content data and performs decryption processing on the encrypted content data. The codec unit 25 encodes content data by, for example, the ATRAC (Adaptive transformed audio Coding) 3 method or the like, and supplies the encoded content data to the semiconductor memory 44 connected to the drive 30 through the input/output interface 32 to record the encoded content data. Alternatively, the codec unit 25 reads the encoded data from the semiconductor memory 44 via the driver 30 and decodes the data.

Semiconductor memory 44, e.g. from メモリステ_イツク (trade mark), etc.

The CPU21, ROM22, RAM23, encryption/decryption section 24, and codec section 25 are connected to each other via a bus 31. The bus 31 is also connected to an input/output interface 32.

The input/output interface 32 is connected to an input unit 26 such as a keyboard and a mouse, a display such as a CRT and an LCD, an output unit 27 such as a speaker, a storage unit 28 such as a hard disk, and a communication unit 29 such as a modem and a terminal adapter. The communication unit 29 performs communication processing via the internet 2. The communication unit 29 also performs communication processing of analog signals or digital signals with other clients.

The input/output interface 32 is also connected to the drive 30 as necessary, and a magnetic disk 41, an optical disk 42, a magneto-optical disk 43, a semiconductor memory 44, and the like are mounted as appropriate, and a computer program read therefrom is installed in the storage unit 28 as necessary.

Although not shown, the content server 3, the license server 4, and the charging server 5 are also configured by computers having basically the same configuration as the client 1 shown in fig. 2. Here, in the following description, the configuration of fig. 2 is also referred to as the configurations of the content server 3, the license server 4, the charging server 5, and the like.

Hereinafter, a process in which the client 1 receives the content provided by the content server 3 will be described with reference to the flowchart of fig. 3.

When the user instructs to access the content server 3 by operating the input unit 26, the CPU21 controls the communication unit 29 to access the content server 3 through the internet 2 in step S1. In step S2, when the user operates the input unit 26 to designate that the provided content is to be received, the CPU21 receives the designation information and notifies the designated content from the communication unit 29 to the content server 3 via the internet 2. Referring to the flowchart of fig. 4, as will be described later, since the content server 3 that received the notification transmits the encrypted content data, when the CPU21 receives the content data via the communication unit 29 in step S3, the encrypted content data is supplied to the hard disk constituting the storage unit 28 and stored in step S4.

Hereinafter, the content providing process of the content server 3 corresponding to the above process of the client 1 will be described with reference to the flowchart of fig. 4. In the following description, the configuration of the client 1 in fig. 2 is also referred to as the configuration of the content server 3.

In step S21, until the CPU21 of the content server 3 is in a standby state and receives access from the client 1 via the communication unit 29 from the internet 2, and when it is determined that the access is received, the process proceeds to step S22, and information specifying the content transmitted from the client 1 is acquired. The information specifying the content is the information notified by the client 1 in step S2 of fig. 3.

In step S23, the CPU21 of the content server 3 reads out the content specified by the information acquired in the process of step S22 from the content data stored in the storage unit 28. In step S24, the CPU21 supplies the content data read from the storage unit 28 to the encryption/decryption unit 24, and encrypts the content data with the content key Kc.

Since the content data stored in the storage unit 28 has been encoded by the ATRAC3 system by the codec unit 25, the encoded content data is in an encrypted state.

It is needless to say that the content data may be stored in the storage unit 28 in a state of being encrypted in advance. In this case, the process of step S24 may be omitted.

Next, in step S25, the CPU21 of the content server 3 adds Key information (ekb (encryption Key block) described later, see fig. 5) and K necessary for decrypting the encrypted content to the header constituting the format for transmitting the encrypted content data_EKBC(Kc)) and a license ID to identify a license necessary for content utilization. Then, in step S26, the CPU21 of the content server 3 transmits the content encrypted in the process of step S24 and the data formatted with the key and the header of the license ID added in the process of step S25 from the communication unit 29 to the client 1 accessing through the internet 2.

Fig. 5 shows a configuration of a format when the content is supplied from the content server 3 to the client 1 in this manner. As shown, the format is composed of a Header (Header) and Data (Data).

The header includes Content information (Content information), a URL (uniform resource Locator), a license id (license id), a valid Key block (EKB (encryption Key block)), and a Key K generated by the EKB_EKBCEncrypted content key Kc, i.e. data K_EKBC(Kc). In addition, EKB will be described later with reference to fig. 15A and 15B.

The content information includes information such as a content id (cid), which is identification information for identifying content data formatted as data, and a codec scheme of the content.

The URL is address information to be accessed when the license specified by the license ID is acquired, and in the case of the system of fig. 1, specifically, is an address of the license server 4 necessary for receiving the license. The license ID identifies a necessary license when using the content recorded as data.

The data is composed of an arbitrary number of Encryption blocks (Encryption blocks). Each encrypted block is composed of an initial vector (iv), a Seed (Seed), and data EK' c (data) obtained by encrypting content data with a key Kc.

The key Kc is constituted by a value calculated by applying a hash function to the content key Kc and a value Seed set by a random number, as shown in the following expression.

K’c＝Hash(Kc，Seed)

The initial vector IV and the Seed are set to different values for each cipher block.

The encryption is performed for each 8 bits after content data is divided in units of 8 bits. The 8-bit encryption of the subsequent stage is performed in a CBC (Cipher Block Chaining) mode using the 8-bit encryption result of the previous stage.

In the CBC mode, when the first 8-bit content data is encrypted, since there is no 8-bit encryption result of the previous stage, when the first 8-bit content data is encrypted, the initial vector IV is encrypted as an initial value.

By performing the encryption in the CBC mode, even if one encrypted block is decoded, the other encrypted block is not affected.

In addition, the encryption will be described in detail later with reference to fig. 47.

The encryption method is not limited to this, and the content data may be encrypted with only the content key Kc.

In this way, the client 1 can freely obtain content from the content server 3 for free. Thus, the content itself can be distributed in large quantities.

However, each client 1 needs to maintain a license when using the acquired content. Here, with reference to fig. 6, a process when the client 1 reproduces a content will be described.

In step S41, the CPU21 of the client 1 acquires identification information (CID) of the content instructed by the user through the operation input unit 26. The identification information is constituted by, for example, the title of the content, the number assigned to each stored content, and the like.

Then, when the content is instructed, the CPU21 reads a license ID (license ID necessary for using the content) corresponding to the content. As shown in fig. 5, the license ID is described in the header of the encrypted content data.

Thereafter, the process proceeds to step S42, and the CPU21 determines whether or not the license corresponding to the license ID read in step S41 has been acquired by the client 1 and stored in the storage unit 28. If the license is not acquired, the process proceeds to step S43, and the CPU21 executes the license acquisition process. The details of this license acquisition process will be described later with reference to the flowchart of fig. 7.

If it is determined in step S42 that the license has been acquired, or if the license has been acquired as a result of execution of the license acquisition process in step S43, the process proceeds to step S44, and the CPU21 determines whether the acquired license is within the valid period. Whether or not the license is within the valid period is determined by comparing a predetermined period (see fig. 8 described later) as the license content with the current date and time counted by the timer 20. When it is determined that the validity period of the license has expired, the flow proceeds to step S45, and the license update process is executed by the CPU 21. The details of this license update process will be described later with reference to the flowchart of fig. 10.

If it is determined in step S44 that the license is still within the expiration date or if the license is updated in step S45, the process proceeds to step S46, and the CPU21 reads the encrypted content data from the storage unit 28 and stores the content data in the RAM 23. Then, in step S47, in units of encrypted blocks of data arranged as in fig. 5, the CPU21 supplies the data of the encrypted blocks stored in the RAM23 to the encryption/decryption section 24, and decrypts the data with the content key Kc.

An example of a method for obtaining the content key Kc will be described later with reference to fig. 15A and 15B, and the key K included in the EKB (fig. 5) can be obtained by using a device Node key (dnk)_EKBCUsing the secret key K_EKBCCan be derived from data K_EKBC(Kc) (FIG. 5) obtains the content key Kc.

In step S48, the CPU21 also supplies the content data decrypted by the encryption/decryption section 24 to the codec section 25 for decoding. Then, the CPU21 supplies the data decoded by the codec unit 25 from the input/output interface 32 to the output unit 27, performs D/a conversion, and outputs the data from the speaker.

The license acquisition process performed in step S43 in fig. 6 will be described in detail below with reference to the flowchart in fig. 7.

The client 1 accesses the license server in advance to perform login processing, and acquires a leaf ID, a DNK (Device Node Key), a secret Key/public Key pair of the client 1, a public Key of the license server, and service data including a certificate of each public Key. Details of the client registration process will be described later with reference to fig. 23.

The leaf ID indicates identification information assigned to each client, and the DNK is a device node key (described later with reference to fig. 12) necessary for decrypting the encrypted content key Kc included in the EKB (valid key block) corresponding to the license.

First, in step S61, the CPU21 acquires a URL corresponding to the license ID that is the current processing target from the header shown in fig. 5. As described above, this URL is also an address to be accessed when a license corresponding to the license ID described in the header is acquired. Here, in step S62, the CPU21 accesses the URL acquired in step S61. Specifically, the license server 4 is accessed via the internet 2 by the communication unit 29. At this time, the license server 4 requests the client 1 to input license specification information specifying a purchase license (license necessary for content use), and a user ID and a password (step S102 of fig. 9 described later). The CPU21 displays the request on the display unit of the output unit 27. The user inputs the license specification information, the user ID, and the password by the display operation input unit 26. The user ID and the password are acquired by the user of the client 1 accessing the license server 4 via the internet 2.

In steps S63, S64, the CPU21 acquires the license specifying information input by the input section 26, and the user ID and password. In step S65, the CPU21 controls the communication unit 29 to transmit the input user ID and password, the license specification information, and the license request including the leaf ID included in the service data (described later) to the license server 4 via the internet 2.

Referring to fig. 9, as will be described later, the license server 4 transmits a license based on the user ID, the password, and the license specifying information (step S109), or, when the condition is not satisfied, does not transmit a license (step S112).

In step S66, the CPU21 determines whether or not the license server 4 has transmitted the license, and when the license is transmitted, the process proceeds to step S67, where the license is supplied to the storage unit 28 and stored.

If it is determined in step S66 that the license has not been transmitted, the process proceeds to step S68, and the CPU21 executes error processing. Specifically, since the CPU21 does not obtain permission to utilize the content, the reproduction process of the content is prohibited.

In this way, each client 1 acquires the license corresponding to the license ID to which the content data is attached, and can start using the content.

The license acquisition process in fig. 7 may be performed in advance before each user acquires the content.

As shown in fig. 8, the license provided to the client 1 includes a use condition, a leaf ID, and the like.

The use conditions include the following information: a life time for which the content can be used according to the license; a download deadline for the downloadable content according to the license; the number of times the content can be copied (permitted copy number), the number of times of logout, the maximum number of times of logout, according to the permission; a right to record the content to the CD-R based on the license; number of times that can be copied to a PD (Portable Device); the right to transfer the license to ownership (purchase status), obligations to use the record, etc.

Next, a license providing process of the license server 4 executed in association with the license acquisition process of the client 1 in fig. 7 will be described with reference to a flowchart in fig. 9. In addition, in this case, the structure of the client 1 of fig. 2 is also cited as the structure of the license server 4.

In step S101, the CPU21 of the license server 4 is in a standby state until the access of the client 1 is accepted, and when the access is accepted, the flow proceeds to step S102, and the client 1 requesting the access transmits the user ID and the password together with the license specifying information. In this way, when the client 1 transmits the user ID, the password, the leaf ID, and the license specification information (license ID) in the process of step S65 of fig. 7, the CPU21 of the license server 4 executes the reception and acquisition process through the communication section 29.

Then, in step S103, the CPU21 of the license server 4 accesses the charging server 5 via the communication unit 29 and requests the credit verification process of the user corresponding to the user ID and the password. When receiving a request for credit approval processing from the approval server 4 via the internet 2, the charging server 5 examines the past payment history of the user corresponding to the user ID and the password, and examines whether or not the user has past results of the price for which the user has not paid the approval, and if not, transmits a credit approval result for which the approval is permitted, and if not, transmits a credit approval result for which the approval is not permitted.

In step S104, the CPU21 of the license server 4 determines whether or not the credit verification result from the charging server 5 is a credit verification result for allowing the grant, and if the result is that the grant is allowed, the process proceeds to step S105, and the license corresponding to the license designation information acquired in the process of step S102 is extracted from the licenses stored in the storage unit 28. The license stored in the storage unit 28 has information such as a license ID, a version, a date and time of generation, and a valid period described in advance. In step S106, the CPU21 attaches the received leaf ID to the license. In step S107, the CPU21 selects a use condition corresponding to the license selected in step S105. Alternatively, when the use condition is specified by the user in the processing of step S102, the use condition is added to the use condition prepared in advance as necessary. The CPU21 appends the selected use condition to the license.

In step S108, the CPU21 generates a license having the configuration shown in fig. 8 by signing the license with the secret key of the license server.

Thereafter, the process proceeds to step S109, and the CPU21 of the license server 4 transmits the license (having the configuration shown in fig. 8) from the communication unit 29 to the client 1 via the internet 2.

In step S110, the CPU21 of the license server 4 stores the license (usage condition, including the leaf ID) currently transmitted in the processing in step S109 in the storage unit 28 in association with the user ID and the password acquired in the processing in step S102. Also, in step S111, the CPU21 executes the charging process. Specifically, the CPU21 requests the charging server 5 to perform charging processing for the user corresponding to the user ID and the password via the communication unit 29. The charging server 5 performs charging processing for the user in accordance with the request for charging. In this way, in the charging process, if the user does not pay, the user cannot accept the license even if the user requests the license to be given again later.

That is, in this case, since the credit verification result that the grant is not permitted is transmitted from the charging server 5, the process proceeds from step S104 to step S112, and the CPU21 executes an error process. Specifically, the CPU21 of the license server 4 controls the communication unit 29 to output a message that the license cannot be given to the client 1 that has accessed, and ends the process.

In this case, as described above, since the client 1 cannot accept the license, the content cannot be used (the encryption is decrypted).

Fig. 10 shows details of the license update processing in step S45 of fig. 6. The processing of steps S131 to S135 of fig. 10 is basically the same as the processing of steps S61 to S65 of fig. 7. However, in step S133, the CPU21 does not purchase the license, but acquires the license ID of the updated license. Then, in step S135, the CPU21 transmits the user ID and the password, and the license ID of the updated license to the license server 4.

In response to the transmission processing in step S135, the license server 4 presents the use condition as described later (step S153 in fig. 11). In step S136, the CPU21 of the client 1 receives the indication of the usage condition from the license server 4, outputs it to the output unit 27, and displays it. The user selects a predetermined use condition from among the use conditions or newly adds a predetermined use condition by operating the input unit 26. In step S137, the CPU21 sends an application to the license server 4 to purchase the use condition (condition for updating the license) selected as above. As described later, the license server 4 transmits the final usage condition in response to the application (step S154 in fig. 11). In step S138, the CPU21 of the client 1 acquires the usage conditions from the license server 4, and in step S139, updates the usage conditions of the corresponding license stored in the storage unit 28 with the usage conditions.

Fig. 11 shows the license update process executed by the license server 4 in response to the above license update process by the client 1.

First, when the CPU21 of the license server 4 receives the access of the client 1 in step S151, the license specification information and the license update request information transmitted by the client 1 in step S135 are also received in step S152.

In step S153, upon receiving the request for updating the license, the CPU21 reads the usage conditions (updated usage conditions) corresponding to the license from the storage unit 28 and transmits the read usage conditions to the client 1.

In response to this presentation, as described above, when the client 1 requests purchase of the use condition through the processing of step S137 of fig. 10, the CPU21 of the license server 4 generates data corresponding to the requested use condition in step S154, and transmits the data to the client 1 in step S154. As described above, the client 1 updates the registered usage condition of the license by using the usage condition received in the process of step S139.

In the present invention, as shown in fig. 12, the device and the license key are managed according to the principle of the Broadcast Encryption (Broadcast Encryption) (see japanese patent laid-open No. 2001-352321). The keys are in a hierarchical tree structure, and the leaf (leaf) at the lowest level corresponds to the key of each device. In the case of the example of fig. 12, keys corresponding to 16 devices or licenses from number 0 to number 15 are generated.

Each key is specified to correspond to each node of the tree structure indicated by a circled symbol in the figure. In this example, the root key KR corresponds to the uppermost level root node, the keys K0, K1 correspond to the level 2 nodes, the keys K00 to K11 correspond to the level 3 nodes, and the keys K000 to K111 correspond to the level 4 nodes. The keys K0000 to K1111 respectively correspond to leaves (device nodes) of the lowest level nodes.

Due to the hierarchical structure, the upper key of the key K0010 and the key K0011 is K001, and the upper key of the key K000 and the key K001 is K00. Hereinafter, similarly, the key K00 and the key K01 have a higher-order key of K0, and the key K0 and the key K1 have a higher-order key of KR.

The content-using key is managed by a key corresponding to each node of a single path from a leaf of the lowest level to a root node of the highest level. For example, the keys of the content are used according to the license corresponding to the node (leaf ID) of number 3, and are managed by the keys of the paths including the keys K0011, K001, K00, K0, KR.

In the system of the present invention, as shown in fig. 13, the key of the device and the key of the license are managed by the key system configured according to the principle of fig. 12. In the example of fig. 13, the 8+24+ 32-level nodes have a tree structure, and the types correspond to the nodes from the root node to the lower 8 levels. The type here means, for example, メモリステ_イツク, etc., or a type of machine that receives digital playback. The present system (referred to as a T-system) as a management permission system corresponds to a single node in the type of node.

That is, the license is associated with a key corresponding to a 24-level node of a hierarchy lower than the T system node. In this example, a 24 power (about 16 million) license of 2 can be specified. Further, a user (or client 1) of the power of 32 of 2 (about 4 giga) can be specified by the 32-level hierarchy at the lowest side. The key corresponding to each Node of the path from the leaf corresponding to the lowest 32-level Node to the root Node constitutes a dnk (device Node key), and the ID corresponding to the lowest level leaf is a leaf ID.

Each device and permitted key corresponds to one of the paths formed by nodes of 64 (8 +24+32) stages. For example, a content key of an encrypted content is encrypted with a key corresponding to a node constituting a path assigned to a corresponding license. The key of the upper hierarchy is encrypted with the key of the nearest lower hierarchy, and is arranged in the EKB (described later with reference to fig. 15A and 15B). The DNK is not disposed in the EKB, but is described in service data and provided to the client 1 of the user. The client 1 decrypts the key of the nearest upper layer described in the EKB (fig. 15A and 15B) distributed together with the content data by using the DNK described in the service data, and decrypts the key of the higher layer described in the EKB by using the key obtained by the decryption. By performing the above processes in sequence, the client 1 can obtain all keys belonging to the path.

Fig. 14 shows a specific example of classification of types of the hierarchical tree structure. In fig. 14, a root key KR2301 is set at the uppermost level of the hierarchical tree structure, a node key 2302 is set at the following intermediate level, and a leaf key 2303 is set at the lowermost level. Each device holds a respective leaf key, a series of node keys from the leaf key to the root key, and the root key.

A predetermined node of the mth stage (in the example of fig. 13, M is 8) from the uppermost stage to the next is set as the type node 2304. That is, each node of the M-th level is a device setting node of a specified type. Nodes and leaves below level M +1 that are peaked by a single node at level M are the device-related nodes and leaves included in the type.

For example, the type [ メモリステ ] is set at one node 2305 of the M-th stage in FIG. 14_イツク (trade mark)]The node, leaf connected below the node is set to contain usage メモリステ_イツク, or leaves, specific to the type of the various devices. That is, node 2305 is hereinafter defined as being represented by メモリステ_イツク type defines the set of associated nodes and leaves of the device.

Also, the lower order stages from the M stage to the next stage may be set as the subtype node 2306. In the example of FIG. 14, in type [ メモリステ ]_イツク]In the nodes below level 2 of the node 2305, [ playback dedicater ]]Node 2306 is set to include usage メモリステ_イツク, a subtype node of the type of device. Further, a telephone node 2307 with a music reproduction function included in the type of reproduction-dedicated device is set below the reproduction-dedicated device node 2306 which is a subtype node, and [ PHS ] included in the type of telephone with a music reproduction function is set below the reproduction-dedicated device node 2306]Node 2308 and [ cell phone]Node 2309.

The type and subtype are not limited to the type of the device, and may be set in any unit (hereinafter, generally referred to as an entity) such as a processing unit, a jurisdiction unit, or a service providing unit, which is a node independently managed by a certain manufacturer, content provider, and settlement institution. For example, if a single type node is set as a vertex node dedicated to game machine XYZ sold by a game machine manufacturer, game machine XYZ sold by the manufacturer can store and sell lower node keys and leaf keys below the vertex node, and then generate and distribute an Effective Key Block (EKB) including node keys and leaf keys below the vertex node key by distribution of encrypted contents or distribution and update processing of various keys, so that only usable data can be distributed to devices below the vertex node.

In this way, by configuring such that a single node is used as a vertex and the following nodes are set as nodes related to the type or subtype defined by the vertex node, the manufacturer or content provider who manages one vertex node of the type or subtype can generate an Effective Key Block (EKB) with the node as the vertex by itself, and the key block can be distributed to devices included in the vertex node or the following nodes, and the key update can be performed without affecting devices included in other types of nodes not belonging to the vertex node.

For example, in the tree structure shown in fig. 12, four devices 0, 1, 2, and 3 included in a single group hold common keys K00, K0, and KR as node keys. With this node key sharing structure, the common content key can be provided only to the devices 0, 1, 2, 3. For example, if the node key K00 itself that is commonly held is set as the content key, the content key that is common to only the devices 0, 1, 2, and 3 may be set without performing new key transmission. Further, when the value Enc (K00, Kcon) obtained by encrypting the new content key Kcon with the node key K00 is distributed to the devices 0, 1, 2, and 3 via a network or a storage medium, only the devices 0, 1, 2, and 3 can decrypt the encryption Enc (K00, Kcon) with the common node key K00 held by the devices to obtain the content key Kcon. Enc (Ka, Kb) indicates data obtained by encrypting Kb with Ka.

When it is found that all the keys K0011, K001, K00, K0, and KR of the device 3 are analyzed and exposed by an attacker (hacker) at a certain time t, the device 3 needs to be separated from the system in order to keep secret the data transmitted and received in the system (the group of devices 0, 1, 2, and 3). Thus, the node keys K001, K00, K0, KR must be updated with the new keys K (t)001, K (t)00, K (t)0, K (t) R, respectively, and the updated keys sent to devices 0, 1, 2. Here, k (t) aaa represents an update key of the t-th Generation (Generation) of the key Kaaa.

The following describes the distribution process of the update key. The updating of the Key is performed by supplying a table made up of Block data called an Effective Key Block (EKB) shown in fig. 15A to the devices 0, 1, 2 via a network or by storing it in a recording medium. The valid key block (EKB) is configured by an encryption key for distributing a newly updated key to a device corresponding to each leaf (lowest node) constituting the tree structure shown in fig. 12. The valid Key Block (EKB) is also called a Key update Block (KRB).

The Effective Key Block (EKB) shown in fig. 15A is configured as block data having such a data structure that only a device that needs to update a node key can be updated. The example of fig. 15A is block data formed with the purpose of distributing updated node keys of the t-th generation to the devices 0, 1, 2 in the tree structure shown in fig. 12. As is apparent from fig. 12, the device 0 and the device 1 need to update the node keys k (t)00, k (t)0, k (t) R, and the device 2 needs to update the node keys k (t)001, k (t)00, k (t)0, k (t) R.

As shown in the EKB of fig. 15A, the EKB includes a plurality of encryption keys. The lowest-level encryption key of fig. 15A is Enc (K0010, K (t) 001). It is an update node key K (t)001 encrypted with a leaf key K0010 held by the device 2, and the device 2 decrypts the encrypted key with the leaf key K0010 held by itself to obtain an update node key K (t) 001. Further, with the update node key k (t)001 obtained by decryption, the encryption key Enc (k (t)001, k (t)00) at the level 2 from the bottom in fig. 15A becomes decryptable, and the update node key k (t)00 can be obtained.

In the following, in order, by decrypting the encryption key Enc (k (t)00, k (t)0) of the 2 nd level from the top in fig. 15A, the update node key k (t)0 can be obtained, and by decrypting the encryption key Enc (k (t)0, k (t) R) of the 1 st level from the top in fig. 15A, the update root key k (t) R can be obtained.

On the other hand, the node key K000 is not included in the update target, and the update node keys required by the nodes 0 and 1 are K (t)00, K (t)0, and K (t) R. The nodes 0 and 1 decrypt the encryption key Enc (K000, K (t)00) of the 3 rd stage from the top in fig. 15A by using the node key K000 included in the device node key to obtain the updated node key K (t)00, and then sequentially decrypt the encryption keys Enc (K (t)00, K (t)0) of the 2 nd stage from the top in fig. 15A to obtain the updated node key K (t)0, and decrypt the encryption key Enc (K (t)0, K (t) R) of the 1 st stage from the top in fig. 15A to obtain the updated root key K (t) R. Thus, the devices 0, 1, 2 may obtain an updated key k (t) R.

The index in fig. 15A indicates the absolute address of the node key and leaf key used as the decryption key for decrypting the encryption key on the right side of the diagram.

When it is not necessary to update the upper node keys K (t)0, K (t) R of the tree structure shown in fig. 12 but only the node key K00 is to be updated, the updated node key K (t)00 can be distributed to the devices 0, 1, 2 by using the Effective Key Block (EKB) of fig. 15B.

The EKB shown in fig. 15B may be used, for example, in the case of distributing a common new content key in a specified group. For example, the devices 0, 1, 2, and 3 in the group indicated by the broken line in fig. 12 need a new common content key k (t) con using a certain recording medium. At this time, the data Enc (K (t)00, K (t) con) obtained by encrypting the new common updated content key K (t) con with the K (t)00 updated by the common node key K00 of the devices 0, 1, 2, and 3 is distributed together with the EKB shown in fig. 15B. By this distribution, data that cannot be decrypted by the other group of devices such as the apparatus 4 can be distributed.

That is, when the apparatuses 0, 1, and 2 decrypt the encrypted text using the key k (t)00 obtained by processing the EKB, the content key k (t) con at time t can be obtained.

Fig. 16 shows an example of processing for obtaining the content key k (t) con at time t, which is processing performed by the device 0 receiving, via a recording medium, data Enc (k (t)00, k (t) con) obtained by encrypting the new common content key k (t) con with k (t)00, and EKB shown in fig. 15B. That is, this example is an example in which message data encrypted by EKB is used as the content key k (t) con.

As shown in fig. 16, the apparatus 0 performs the same EKB process as in the above case using the EKB at the tth generation time stored in the recording medium and the node key K000 included in the DNK stored in advance, and generates the node key K (t) 00. Furthermore, the device 0 decrypts the update content key K (t) con with the decrypted update node key K (t)00, and encrypts and stores it with the leaf key K0000 held by itself for later use.

Fig. 17 shows an example of the format of an Effective Key Block (EKB). The version 601 is an identifier indicating a version of the valid key block (EKB). The version has a function of identifying the latest EKB and a function of indicating the correspondence relationship with the content. The depth indicates the number of layers of a distribution destination device of an Effective Key Block (EKB) in a hierarchical tree. The data pointer 603 is a pointer indicating the position of the data unit 606 in the valid key block (EKB), the marker pointer 604 is a pointer indicating the position of the marker unit 607, and the signature pointer 605 is a pointer indicating the position of the signature 608.

The data unit 606 stores data obtained by encrypting the updated node key. For example, each encryption key or the like associated with the update node key shown in fig. 16 is stored.

The flag unit 607 indicates the positional relationship between the encryption node key and the leaf key stored in the data unit 606. The rule of assigning the mark will be described with reference to fig. 18.

Fig. 18 shows an example of transmitting the valid key block (EKB) previously explained in fig. 15A as data. The data at this time are shown in the table of fig. 18. The address of the top node included in the encryption key at this time is the top node address. In this example, since the update key k (t) R including the root key is included, the top node address becomes KR. In this case, for example, the uppermost data Enc (k (t)0, k (t) R) corresponds to the position P0 indicating the hierarchical tree shown in fig. 18. The next level of data is Enc (k (t)00k (t)0), which corresponds to the lower left position P00 of the previous data in the tree. When viewed from a predetermined position of the tree structure, the flag is set to 0 when data exists and is set to 1 when data does not exist. The flag is set to { left (L) flag, right (R) flag }. Since data exists in the lower left position P00 of the position P0 corresponding to the uppermost data Enc (k (t)0, k (t) R) of the table of fig. 18, the L flag is 0, and data does not exist on the right side, and the R flag is 1. Hereinafter, flags are set for all data, and a data sequence and a flag sequence as shown in fig. 18 are configured.

The flag is set to indicate where the corresponding data Enc (Kxxx, Kyyy) is located in the tree structure. The key data Enc (Kxxx, Kyyy) stored in the data section 606 is simply listed data of a simple encryption key, and the position of the encryption key stored as data on the tree can be determined by the above-described marker. Instead of the above-described flag, the node index corresponding to the encrypted data may be used, for example, in the same manner as the configuration described in fig. 15A and 15B

0：Enc(K(t)0，K(t)R)

00：Enc(K(t)00，K(t)0)

000：Enc(K((t)000，K(t)00)

.., when such an index structure is adopted, data becomes redundant and the amount of data increases, which is not suitable for distribution via a network or the like. In contrast, by using the above-described marker as index data indicating the key position, the key position can be determined with a small amount of data.

Turning back to FIG. 17, the EKB format is further illustrated. The Signature (Signature)608 is an electronic Signature executed by a key management center (license server 4) that issues an Effective Key Block (EKB), a content provider (content server 3), a settlement body (billing server 5), and the like. The device that has received the EKB confirms the valid key block (EKB) issued by the valid key block (EKB) issuer as being legitimate by signature verification.

In this way, the process of using the content supplied from the content server 3 in accordance with the license supplied from the license server 4 is summarized as shown in fig. 19.

That is, the client 1 is provided with the content from the content server 3, and the client 1 is provided with the license from the license server 4. The Content is encrypted with a Content key Kc (Enc, Content), and the Content key Kc is encrypted with a root key KR (a key obtained from EKB, and a key K in fig. 5)_EKBCCorrespondingly), encrypted (Enc (KR, Kc)), and attached to the encrypted content together with the EKB, and provided to the client 1.

In the EKB in the example of fig. 19, for example, as shown in fig. 20, a root key KR (Enc (DNK, KR)) that can be decrypted with DNK is included. Thus, the client 1 can obtain the root key KR from the EKB by using the DNK included in the service data. Further, the Content key Kc can be decrypted from Enc (KR, Kc) using the root key KR, and the Content can be decrypted from Enc (Kc, Content) using the Content key Kc.

By individually assigning DNKs to the clients 1 in this manner, revocation (revoke) of each client 1 can be performed according to the principle described with reference to fig. 12, 15A, and 15B.

Further, by assigning a leaf ID to a license and distributing the same, the client 1 can associate service data with the license, and illegal copying of the license can be prevented.

Further, by distributing the certificate and the secret key for the client as service data, the end user can also generate content that can be protected against illegal copying using the certificate and the secret key.

The use of certificates and secret keys will be described later with reference to the flowchart of fig. 29.

In the present invention, as described with reference to fig. 13, since the content distribution system of the present invention that manages licenses corresponds to the types of devices that utilize various types of content in the type node, the same device can hold a plurality of DNKs. As a result, different types of content can be managed with a single device.

Fig. 21 shows this relationship. That is, in the device D1, DNK1 is assigned by the content distribution system, and the license to use the content 1 and the service data are recorded. Also in this device D1, for example, DNK2 may be assigned and set at メモリステ_イツク, content 2 stripped from the CD is recorded. In this case, the device D1 can simultaneously process content distributed by different systems (content distribution system and device management system) called content 1 and content 2. When a new DNK is assigned, the assigned DNK is deleted, whereas when only one DNK corresponds to the device, the deletion cannot be performed.

In fig. 13, for example, by assigning the license type 1 and the license type 2 shown in fig. 22 to each triangle at the lower 32-level, the same intra-genre can be managed by being classified into a small set of the category, the level, the sales outlet, the distribution service, the provenance of the content, the providing method, and the like of the content by the subtype.

In the example of fig. 22, for example, the license type 1 belongs to the category of jazz music, and the license type 2 belongs to the category of rock music. In license type 1, content 1 and content 2 having a license ID of 1 are distributed to user 1 to user 3, respectively. Content 3, content 4, and content 5, which are license type 2 and include license ID2, are provided to user 1 and user 3, respectively.

Thus, in the present invention, independent key management can be performed for each type.

Further, a system can be realized in which the DNK is not embedded in the device and the media in advance, and the user can acquire the key by downloading the DNK to each device and media from the license server 4 at the time of login processing.

The login process of the client 1 in this case is explained with reference to fig. 23.

In step S161, the CPU21 of the client 1 controls the communication unit 29 to transmit a service data request to the license server 4. When the CPU21 of the license server 4 receives the input service data request via the communication unit 29 in step S165, it transmits a user information request to the client 1 via the communication unit 29 in step S166.

In step S162, when the CPU21 of the client 1 receives a user information request via the communication unit 29, it controls the output unit 27 to display a message prompting the user to input user information on a display or the like. When the user inputs user information such as personal information of the user himself or the settlement information from the input unit 26 by operating the keyboard or the like, the CPU21 of the client 1 transmits the input user information to the license server 4 via the communication unit 29 in step S163.

When the CPU21 of the license server 4 receives the user information via the communication unit 29 in step S167, in step S168, the unassigned leaf is assigned to the client 1 in the leaf below the type node of the license server 4, and a node key group assigned to a node on the path from the leaf to the type node assigned to the license server 4 is generated as the device node key. The generated device node key, the leaf ID assigned to the leaf of the client 1, the secret key public key pair of the client 1, the public key of the license server, and the certificates of the public keys are integrated to generate service data, and in step S169, the generated service data is transmitted to the client via the communication unit 29, and the drive 30 is controlled to record the user information in a recording medium such as a hard disk in association with the leaf ID.

In step S164, when the CPU21 of the client 1 receives the service data via the communication unit 29, it controls the encryption/decryption unit 24 to encrypt the received service data, controls the drive 30, and records the encrypted service data on a recording medium such as a hard disk.

In this way, the license server 4 logs in the client 1 and the user, and the client 1 can receive service data including a device node key necessary for using a desired content distribution service.

After the content is created, it is desired that the content can be used for all purposes regardless of the method of use. For example, even in the case of different content distribution services or usage conditions of different domains, it is desirable that the same content can be utilized. For the above purpose, in the present invention, as described above, a certificate (certificates) of a secret key and a corresponding public key is distributed from the license server 4 as a certificate authority to each user (client 1). Each user generates a Signature (Signature) by using the secret key and adds the Signature to the content, thereby ensuring the integrity (integrity) of the content and preventing falsification of the content.

An example of the processing of this case is described with reference to the flowchart of fig. 24. The processing of fig. 24 explains the ripping processing in which the user stores the reproduction data from the CD in the storage section 28.

First, in step S171, the CPU21 of the client 1 acquires the reproduced data of the CD input via the communication unit 29 as recorded data. In step S172, the CPU21 determines whether the recording data obtained in the processing of step S171 contains a watermark. The watermark is composed of 3-bit copy management information (CCI) and 1-bit Trigger signal (Trigger), and is embedded in the data of the content. When detecting the watermark, the CPU21 proceeds to step S173 to execute a process of extracting the watermark. If the watermark does not exist, the process of step S173 is skipped.

Thereafter, in step S174, the CPU21 generates header data recorded in accordance with the content. The header data is composed of a URL indicating an access point to acquire a content ID, a license, copy management information (CCI) including a watermark, and a Trigger signal (Trigger).

Thereafter, the process proceeds to step S175, and the CPU21 generates a digital signature based on the header data generated in the process of step S174, using its own secret key. The secret key is acquired from the license server 4 (step S67 in fig. 7).

In step S176, the CPU21 controls the encryption/decryption unit 24 to encrypt the content with the content key. The content key is generated using a random number or the like.

Next, in step S177, the CPU21 records data on the magneto-optical disk 43, which is, for example, a compact disk, according to the file format.

When the recording medium is a compact disc, the CPU21 supplies the content to the codec unit 25 in step S176, and encodes the content by, for example, ATRAC 3. Then, the encoded data is further encrypted by the encryption/decryption section 24.

Fig. 25 is a schematic diagram of a state of the content recorded on the recording medium in this manner. The Watermark (WM) extracted from the encrypted content (E (At3)) is recorded outside the content (header).

Fig. 26 shows a more detailed structure of a file format when content is recorded on a recording medium. In this example, in addition to the Content id (cid), the license id (lid), the URL, and the header including the Watermark (WM), EKB, Data (Enc (KR, Kc) obtained by encrypting the Content key Kc with the root key KR, certificate (Cert), digital signature (sig (header)) generated based on the header, Data (Enc (Content)) obtained by encrypting the Content with the Content key Kc, intermediate Data (Meta Data), and a Mark (Mark) are recorded.

Although the watermark is embedded in the content, as shown in fig. 25 and 26, the watermark may be arranged not in the content but in the header, and information of the watermark embedded in the content can be detected quickly and easily. Thus, it can be quickly determined whether the content is available for copying.

The intermediate data represents data such as envelopes, photographs, lyrics, and the like. The flags will be described later with reference to fig. 32.

Fig. 27 shows an example of a public key certificate as a certificate. A public key Certificate is generally a Certificate issued by a Certificate Authority (CA) in a public key encryption system, and is generated by the Certificate Authority adding information such as a validity period and a digital signature of the Certificate Authority to an ID and a public key of a user of the Certificate Authority. In the present invention, since the license server 4 (or the content server 3) issues the certificate, the secret key, and the public key, the user can obtain the public key certificate by providing the user ID, the password, and the like to the license server 4 to perform login processing.

The public key certificate in fig. 27 contains the following messages: the version number of the certificate, the serial number of the certificate assigned to the user of the certificate (user) by the license server 4, the algorithm and parameters used for the digital signature, the name of the certificate authority (license server 4), the validity period of the certificate, the ID (node ID or leaf ID) of the certificate user, and the public key of the certificate user. The message is added with a digital signature generated by the license server 4 as a certificate authority. The digital signature is data generated using a secret key of the license server 4 based on a hash value generated by applying a hash function to a message.

The node ID or leaf ID, for example, in the case of the example of fig. 12, is "0000" in the case of device 0, is "0001" in the case of device 1, and is "1111" in the case of device 15. From such an ID, it is possible to identify where in the tree structure (leaf or node) the device (entity) is located.

In this way, by distributing the license necessary for using the content separately from the content, the content can be freely distributed. The content obtained by any method or path may be processed once.

It is needless to say that by configuring the file format shown in fig. 26, it is possible to distribute the contents in this format via the internet, and even when the contents are provided to an SDMI (Secure Digital music initiative) device, it is possible to manage the copyright of the contents.

For example, as shown in fig. 28, the user can log out in a predetermined PD (Portable Device) or the like as an SDMI (secure digital Music Initiative) Device by the same processing regardless of whether the content is provided via a recording medium or via the internet 2.

Hereinafter, a process when the client 1 performs the content logout with respect to another client (for example, PD) will be described with reference to a flowchart of fig. 29.

First, in step S191, the CPU21 determines whether or not a digital signature is attached to the content. When it is determined that the digital signature is added, the process proceeds to step S192, in which the CPU21 extracts the certificate, performs a verification process using the public key of the certificate authority (license server 4), that is, the client 1 obtains the public key corresponding to the secret key of the license server 4 from the license server 4, and decrypts the digital signature added to the public key certificate using the public key. As described with reference to fig. 27, the digital signature is generated from the secret key of the certificate authority (license server 4) and can be decrypted with the public key of the license server 4. Also, the CPU21 applies a hash function to all messages of the certificate to calculate a hash value. Then, the CPU21 compares the calculated hash value with the hash value obtained by decrypting the digital signature, and determines that the message has not been tampered if the two match. If the two are not in agreement, the certificate is tampered.

In step S193, the CPU21 determines whether or not the certificate has been tampered with, and if it is determined that the certificate has not been tampered with, the process proceeds to step S194, where the process of verifying the certificate is executed by the EKB. This verification process is performed by checking whether or not the EKB can be traced based on the leaf ID (fig. 27) included in the certificate. This verification is explained with reference to fig. 30 and 31.

Now, as shown in fig. 30, for example, the device holding the leaf key K1001 is made a revoked device. At this time, EKBs having data (encryption keys) and marks as shown in fig. 31 are distributed to the respective devices (leaves). When the device "1001" in fig. 30 is revoked, the EKB becomes an EKB of the update keys KR, K1, K10, and K100.

All leaves except the revoked device "1001" can obtain the updated root key k (t) R. That is, since the leaf connected below the node key K0 holds the node key K0 that is not updated within the device, the update root key K (t) R can be obtained by decrypting the encryption key Enc (K0, K (t) R) with the key K0.

In addition, the leaves below the node 11 can obtain the updated node key K (t)1 by decrypting Enc (K11, K (t)1) with the node key K11 using the non-updated node key K11. Further, by decrypting Enc (k (t)1, k (t) R) with the node key k (t)1, the update root key k (t) R can be obtained. The lower leaf of the node key K101 may also obtain the update root key K (t) R.

The device "1000" holding the unreleased leaf key K1000 decrypts Enc (K1000, K (t)100) with its own leaf key K1000 to obtain the node key K (t)100, and further decrypts the upper node keys in sequence with the node key K (t)100 to obtain the update root key K (t) R.

On the other hand, the revoked device "1001" cannot obtain the update root key k (t) R because it cannot obtain the update node key k (t)100 of the upper stage of its own leaf by the EKB process.

The license server 4 distributes and stores the EKB having the data and the flag shown in fig. 31 to a valid device (client 1) which is not revoked.

The client can perform EKB trace processing using the tag. The EKB tracing process is a process of determining whether or not a key distribution tree can be traced from a higher-level root key.

For example, the ID (leaf ID) of the leaf "1001" in fig. 30, that is, "1001" can be regarded as 4 bits of "1", "0", "1", and it is determined whether or not the tree can be traced by going from the top bit to the lower bit. In this determination, if the bit is 1, the right side is entered, and if the bit is 0, the left side is entered.

Since the most significant bit of ID "1001" is 1, the root key KR in fig. 30 enters the right side. The first mark (mark No. 0) of EKB is 0: {0, 0}, it can be determined that both branches have data. In this case, since the right side can be entered, the node key K1 can be traced.

Next, the lower node of the node key K1 is entered. Since the 2 nd bit of ID "1001" is 0, the left side is entered. The mark No. 1 indicates the presence or absence of the lower data of the left node key K0, and the mark No. 2 indicates the presence or absence of the lower data of the node key K1. The label is shown in fig. 31 as 2: {0, 0}, meaning both branches have data. Thus, entry to the left may track to node key K10.

Then, the 3 rd bit of ID "1001" is 0 and enters the left side. In this case, the flag indicating the presence or absence of the lower data of K10 (flag No. 3) is 3: {0, 0}, it is determined that both branches have data. So that entry to the left side can be traced to the node key K100.

Then, the lowest bit of ID "1001" is 1, and goes to the right. The label of number 4 corresponds to the node key K11, and the label of number 5 indicates the code of the data of the lower order of K100. The label is 5: {0,1}. Thus, no data is present on the right. As a result, the node "1001" cannot be tracked, and the device with ID "1001" is determined to be a revoked device that cannot obtain the update root key by the EKB.

On the other hand, for example, if the device ID holding the leaf key K1000 is "1000", and the EKB tracking process is performed based on the marker in the EKB as in the above case, the node "1000" can be tracked. Thus, the device with ID "1000" is determined to be a legitimate device.

Returning to fig. 29, the CPU21 determines whether or not the certificate is revoked at step S195 based on the verification processing at step S194, and if the certificate is not revoked, the process proceeds to step S196, where the processing for verifying the digital signature using the public key included in the certificate is executed.

That is, as shown in fig. 27, the certificate includes the public key of the certificate user (content creator), and the signature (sig (header)) shown in fig. 26 is verified using the public key. That is, by comparing the data (hash value) obtained by decrypting the digital signature sig (Header) with the public key and the hash value obtained by applying the hash function operation to the Header shown in fig. 26, it can be confirmed that the Header has not been tampered when both of the two values match. In contrast, if the two are not in agreement, the Header is tampered.

In step S197, the CPU21 determines whether the Header has been tampered with, and if not, the process proceeds to step S198 to verify the watermark. In step S199, the CPU21 determines whether the authentication result of the watermark can be revoked. If the logout is possible, the process proceeds to step S200, and the CPU21 performs the logout. That is, the content is forwarded to the client 1 of the logout destination and copied.

When it is determined in step S191 that the digital signature is not present, when it is determined in step S193 that the certificate is falsified, when it is determined in step S195 that the certificate cannot be verified with the EKB, when it is determined in step S197 that the verification result of the digital signature indicates that the header is falsified, or when it is determined in step S199 that logout is prohibited, the process proceeds to step S201, and an error process is executed. I.e. logoff is prohibited in this case.

In this way, the integrity of the creator of the content can be ensured by distributing the certificate and the secret key from the license server 4 to the user and attaching the digital signature at the time of content creation. Thus, illegal distribution of the content can be prevented.

Moreover, by detecting the watermark at the time of content creation and adding this information to the digital signature, it is possible to prevent falsification of watermark information and ensure the integrity of the content.

As a result, once the content is generated, the integrity of the original content can be ensured regardless of the form of distribution.

Further, since the content does not have the use condition and the use condition is added to the license, the use condition of the content related thereto can be changed together by changing the use condition in the license.

The method of using the flag will be described below. In the present invention, as described above, the use condition is attached to the license instead of the content. However, the usage situation varies from content to content. In the present invention, as shown in fig. 26, a mark is attached to the content.

Since the license and the content are in a one-to-many relationship, it becomes difficult to specify the respective usage states of the content only under the usage conditions of the license. By thus attaching the usage status to the content, it is possible to manage the respective contents while managing with the license.

As shown in fig. 32, for example, the flag includes a user ID (leaf ID), an ownership flag, a use start time, and the number of copies.

The flag is added with a digital signature generated from a message including a leaf ID, an ownership flag, a use start time, and the number of copies.

The ownership flag is attached when a license for a content which can be used for a predetermined period is directly purchased (in the case of changing to a permanent use period). The use start time is described in the case where the use of the content is started within a predetermined period. For example, when the time for downloading the content is limited, the date and time when the content is actually downloaded is described in the time when the content is downloaded within the time limit. Thus, it proves to be effective use during the period.

The number of copies of the content is described as a history (log).

An example of flag addition processing for adding a flag to content when a user purchases a license is described below with reference to the flowchart of fig. 33.

First, in step S221, the CPU21 accesses the license server 4 via the internet 2 in accordance with an instruction from the user of the input unit 26.

In step S222, the CPU21 obtains an input from the user via the input unit 26, and requests the purchase permission from the permission server 4 in response to the input.

In response to this request, referring to the flowchart of fig. 34, as will be described later, the license server 4 presents the price necessary for purchasing the license (step S242 of fig. 34). In step S223, upon receiving the price presentation from the license server 4, the CPU21 of the client 1 outputs the price presentation to the output unit 27 and displays the price presentation.

The user determines whether or not to accept the presented price based on the display, and inputs the determination result from the input unit 26 based on the determination result.

In step S224, the CPU21 determines whether or not the user accepts the presented price based on the input from the input unit 26, and if it determines that the user accepts, the process proceeds to step S225, where the acceptance is notified to the license server 4.

Upon receiving the acceptance notification, the license server 4 transmits information indicating purchase of the price, that is, a flag in which an ownership flag is described (step S244 in fig. 34). When the CPU21 of the client 1 receives the flag from the license server 4 in step S226, the CPU executes a process of embedding the received flag in the content in step S227. That is, as a flag of the content corresponding to the purchased license, a flag described by an ownership flag shown in fig. 32 is recorded in association with the content. At this time, since the message is updated, the CPU21 also updates the digital signature (fig. 26) and records it on the recording medium.

In step S224, when it is determined that the price presented from the license server 4 is not accepted, the flow proceeds to step S228, and the CPU21 notifies the license server 4 of the price for which the presentation is not accepted.

In response to the processing of the client 1, the license server 4 executes the processing shown in the flowchart of fig. 34.

That is, first, when a request for permission of purchase is transmitted from the client 1 in step S241 (step S222 in fig. 33), the CPU21 of the permission server 4 receives the request, reads out the price necessary for purchase of the target permission from the storage unit 28 in step S242, and transmits the price to the client 1.

As described above, the notification of whether or not the presented price is accepted is transmitted from the client 1 to the price presented in this way.

In step S243, the CPU21 of the license server 4 determines whether or not the reception notification is received from the client 1, and when it determines that the reception notification is received, the process proceeds to step S244, where a flag including a message indicating purchase of the target license is generated, a digital signature is appended with its own secret key, and the generated flag is transmitted to the client 1. As described above, the flag thus transmitted is recorded in the corresponding content in the storage unit 28 of the client 1 (step S227 in fig. 33).

In step S243, when it is determined that the acceptance notification is not received from the client 1, the process of step S244 is skipped. That is, in this case, since the license purchase processing is not finally performed, the flag is not transmitted.

Fig. 35 shows an example of the configuration of the flag transmitted from the license server 4 to the client 1 in step S244. In this example, the flag is composed of the leaf ID of the user, the ownership flag (Own), and the digital signature (leaf ID, Own) generated using the leaf ID and the ownership flag based on the secret key S of the license server 4.

Since the flag is valid only for the content designated by the designated user, the flag attached to the copied content becomes invalid after the target content is copied.

In this way, even if the content and the license are separated, when the usage condition corresponds to the license, a service corresponding to the usage status of each content can be realized.

The grouping is explained below. Grouping refers to appropriately concentrating a plurality of machines and media, and freely transmitting and receiving contents within one set. Typically, this grouping is done in a machine and media owned by an individual. Conventionally, the same group key is set for each group in the grouping, but grouping can be easily performed by associating a plurality of devices and media that are packetized with the same license.

In addition, the devices may be registered in advance to perform grouping. The following describes the grouping of this case.

In this case, the user must register the certificate of the device to be grouped with the server in advance. This certificate registration process will be described with reference to the flowcharts of fig. 36 and 37.

First, a certificate registration process of a client (a device to be grouped) will be described with reference to a flowchart of fig. 36. In step S261, the CPU21 of the client 1 generates a certificate of itself of the machine as the grouping target. The certificate contains its own public key.

Thereafter, the process proceeds to step S262, the CPU21 accesses the content server 3 in response to the input of the input unit 26 by the user, and executes a process of transmitting the certificate generated in the process of step S261 to the content server 3 in step S263.

In addition, the certificate received from the license server 4 may be used directly.

The above processing is performed for all machines to be grouped.

Hereinafter, a description will be given of a certificate registration process of the content server 3 performed in accordance with the certificate registration process of the client 1 in fig. 36, with reference to a flowchart in fig. 37.

First, when receiving the certificate transmitted from the client 1 in step S271, the CPU21 of the content server 3 registers the certificate in the storage unit 28 in step S272.

The above processing is performed for each machine as a group object. As a result, as shown in fig. 38, for example, for each group, the certificates of the devices constituting the group are registered in the storage unit 28 of the content server 3.

In the example shown in fig. 38, the certificates C11 to C14 are registered as the certificates of group 1. These certificates C11 to C14 contain corresponding public keys K_P11To K_P14。

Likewise, certificates C21 through C23 are registered as group 2 certificates, which contain corresponding public keys K_P21To K_P23。

When the user requests the devices included in the group to provide content in a state where the certificate is registered in each of the devices constituting the group, the content server 3 executes the processing shown in the flowchart of fig. 39.

First, in step S281, the CPU21 of the content server 3 executes the verification process of the certificate belonging to the group among the certificates stored in the storage unit 28.

As described with reference to fig. 30 and 31, this authentication process tracks the EKB with a marker based on the leaf ID included in the certificate of each device. EKBs are also distributed from the license server 4 to the content server 3. By this verification process, the revoked certificate can be excluded.

In step S282, the CPU21 of the content server 3 selects a certificate valid in the result of the authentication processing of step S281. Then, in step S283, the CPU21 encrypts the content key with each public key of the certificate of each device selected in the processing of step S282. In step S284, the CPU21 transmits the content key encrypted in the processing of step S283 to each device of the group as the object together with the content.

In group 1 shown in fig. 38, for example, if the certificate C14 is revoked, encrypted data shown in fig. 40, for example, can be generated by the processing of step S283.

That is, in the example of fig. 40, the public key K of the certificate C11 for the content key Kc_P11Public key K of certificate C12_P12Or public key K of certificate C13_P13To carry outAnd (4) encrypting.

In accordance with the processing shown in fig. 39 of the content server 3, the machines (clients) of the groups receiving the provision of the content execute the processing shown in the flowchart of fig. 41.

First, in step S291, the CPU21 of the client 1 receives the content and the content key transmitted by the content server 3 in the process of step S284 of fig. 39. The content is encrypted in advance with the content key Kc, and as described above, the content key is encrypted with the public key held by each device (fig. 40).

In step S292, the CPU21 decrypts the content with its own secret key to acquire the content key of its own address received in the processing in step S291. Then, the content is decrypted by using the acquired content key.

For example, a machine corresponding to certificate C11, shown in the example of FIG. 40, utilizes a public key K corresponding to the public key K_P11The encrypted content key Kc is decrypted by the corresponding private key, and the content key Kc is obtained. The content is then further decrypted with the content key Kc.

The same processing is also performed for the machines corresponding to the certificates C12 and C13. Since the apparatus of the revoked certificate C14 does not transmit the content key Kc encrypted with its own public key attached to the content, the content key Kc cannot be decrypted, and thus the content cannot be decrypted with the content key Kc.

Although the content keys (i.e., contents) have been grouped as described above, the license keys (licenses) may be grouped.

Thus, it is possible to perform grouping without using a special group key and an ICV (Integrity check value) described later. This grouping is suitable for small-scale groups.

In the present invention, the license may be checked out or registered, moved, or copied. However, these processes are performed according to the rules defined by SDMI.

The process of canceling the license of the client as described above will be described below with reference to flowcharts of fig. 42 and 43.

First, a process of a client that deregisters a license to another client will be described with reference to a flowchart of fig. 42. First, in step S301, the CPU21 of the client 1 reads out the logout count N1 of the permission of the logout object. Since it is embedded in the usage condition shown in fig. 8, the number of logouts can be read from the usage condition.

Thereafter, in step S302, the CPU21 still reads out the maximum number of logouts N2 of the permission of the logout object from the permitted use condition.

Then, in step S303, the CPU21 compares the logout count N1 read out in the processing of step S301 with the maximum logout count N2 read out in the processing of step S302, and determines whether the logout count N1 is smaller than the maximum logout count N2.

When it is determined that the number of times of logout N1 is smaller than the maximum number of times of logout N2, the process proceeds to step S304, and the CPU21 acquires the leaf key of the partner device (the client of the logout destination) from each of the partner devices, and stores the leaf key in the logout list in the storage unit 28 in association with the permission ID of the current logout target.

Thereafter, in step S305, the CPU21 increments the value of the permitted number of logout times N1 read out in the processing of step S301 by one. In step S306, the CPU21 calculates the ICV from the permitted message. The ICV will be described later with reference to fig. 47 to 51. Tampering of the license can be prevented using ICV.

Thereafter, in step S307, the CPU21 encrypts the authorization of the logout target and the ICV calculated in the processing of step S306 with its own public key, and outputs and copies the encrypted information together with the EKB and the certificate to the other device. In step S308, the CPU21 stores the ICV calculated in the process of step S306 in the revocation list of the storage unit 28 in association with the leaf key and the license ID of the partner device.

In step S303, when it is determined that the number of times of logout N1 is not less than (e.g., equal to) the maximum number of times of logout N2, since logout has already been performed the permitted number of times, logout cannot be performed any more. Proceeding to step S309, the CPU21 executes error processing. That is, the logout process is not performed in this case.

Hereinafter, the process of the client that receives the permitted logout will be described with reference to the flowchart of fig. 43, with reference to the logout process of fig. 42.

First, in step S321, the own leaf key is transmitted to the partner device (the client 1 that cancels the license). In step S304, the leaf key is stored by the client of the other party in association with the license ID.

Thereafter, in step S322, when the encrypted license, ICV, EKB, and certificate are transmitted from the client 1 of the other party, the CPU21 receives them. That is, the license, the ICV, the EKB, and the certificate are transmitted from the device of the other party in the process of step S307 in fig. 42.

In step S323, the CPU21 stores the license, the ICV, the EKB, and the certificate received in the processing in step S322 in the storage unit 28.

As described above, the client 1 that accepts the logout of the license executes the processing shown in the flowchart of fig. 44 when reproducing the predetermined content using the license that accepts the logout.

That is, first, in step S341, the CPU21 of the client 1 calculates the ICV of the content specified by the user via the input unit 26 for playback. Then, in step S342, the CPU21 decrypts the encrypted ICV stored in the storage unit 28 based on the public key included in the certificate.

Thereafter, in step S343, the CPU21 determines through the processing in step S341 whether or not the currently operated ICV matches the ICV read out and decrypted by the processing in step S342. If the two match, the license is not tampered. Then, proceeding to step S344, the CPU21 executes processing for reproducing the corresponding content.

In contrast, if it is determined in step S343 that the two ICVs do not match, the license may have been tampered with. Thus proceeding to step S345, the CPU21 executes error processing. That is, at this time, the content cannot be reproduced with the license.

Hereinafter, a process in which a client accepts registration of a license that has been previously revoked from another client will be described with reference to the flowchart of fig. 45.

First, in step S361, the CPU21 acquires the leaf key of the partner device (client 1 that returns (registers) the license) and the license ID of the registration target. Next, in step S362, the CPU21 determines whether or not the registration target license acquired in step S361 is a license for itself to be checked out to the partner apparatus. This determination is made based on the ICV, the leaf key, and the license ID stored in the processing of step S308 in fig. 42. That is, it is determined whether or not the leaf key, the license ID, and the ICV acquired in step S361 are stored in the revocation list, and if they are stored in the revocation list, it is determined that the leaf key, the license ID, and the ICV are a license for self-revocation.

When the license is a license for self-logout, the CPU21 requests deletion of the license, the EKB, and the certificate of the partner device in step S363. As described later, the other device executes permission, EKB, and certificate deletion in response to the request (step S383 in fig. 46).

In step S364, since the previously revoked license is registered again, the CPU21 decrements the number of logouts of this license N1 by one.

In step S365, the CPU21 determines whether or not other permission is being checked out to the device of the other party, and if there is no other permission to be checked out, the process proceeds to step S366, and the CPU21 deletes the stored content in the check-out list with the device of the other party as the registration target device. In contrast, when it is determined in step S365 that there is a possibility that the other license is canceled with the device of the other party, the process of step S366 is skipped because the registration of the other license is accepted.

If it is determined in step S362 that the registration target license is not a license for logout with the partner apparatus, the CPU21 proceeds to step S367 to execute error processing. That is, in this case, since it is not a license of its own jurisdiction, the registration process is not executed.

When the user illegally copies the license, the stored ICV value is different from the ICV value calculated based on the license acquired in the processing of step S361, and thus registration cannot be performed.

Fig. 46 shows a process of registering a client having a license of its own corresponding to the client executing the license registration process shown in the flowchart of fig. 45.

In step S381, the CPU21 of the client 1 transmits the leaf key and the license ID of the registration target to the apparatus of the other party (the client 1 that executes the processing shown in the flowchart of fig. 45). As described above, the partner device acquires the leaf key and the license ID in step S361, and executes the process of authenticating the license to be registered based on the leaf key and the license ID in step S362.

In step S382, the CPU21 of the client 1 determines whether or not there is a request for deletion of the license from the partner apparatus. That is, when the license is a license of a legitimate registration target, the partner device requests deletion of the license, the EKB, and the certificate in the process of step S363 as described above. When receiving the request, the process proceeds to step S383, and the CPU21 deletes the license, the EKB, and the certificate. That is, the client 1 becomes unable to use the license later, and the registration is terminated by reducing the number of logouts N1 by one by the processing of step S364 in fig. 45.

When it is determined in step S382 that the deletion permission is not requested from the other device, the process proceeds to step S384, and an error process is executed. That is, in this case, registration cannot be performed for the reason such as the difference in ICV value.

The registration and the cancellation are described above, as are the copying or moving of the license.

A description will be given below of a processing configuration in which an Integrity Check Value (ICV) of a license for preventing tampering (the same applies to content) is generated, and the presence or absence of tampering of the license is determined by calculating the ICV in accordance with the license.

The Integrity Check Value (ICV) of the license is calculated from ICV ═ hash (Kicv, L1, L2..) by applying a hash function to the license. Kicv is an ICV generation key. L1 and L2 are information of the license, and use Message Authentication Code (MAC) which is important information of the license.

The MAC value generation using the DES encryption processing structure is shown in fig. 47, for example. As shown in the configuration of fig. 47, the target message is divided into 8-bit units (hereinafter, the divided messages are referred to as M1, M2.. and MN), and the arithmetic unit 24-1A performs exclusive or on the Initial Values (IV) and M1 (the result is referred to as I1). Subsequently, I1 is input to the DES encryption unit 24-1B, and encrypted with a key (hereinafter, K1) (the output is E1). Then, the arithmetic unit 24-2A performs exclusive OR between E1 and M2, and the output 12 is input to the DES encryption unit 24-2B and encrypted with the key K1 (output E2). The above operation is repeated below, and encryption processing is performed on all messages. Finally, the EN output from the DES encryption unit 24-NB is a message authentication code (mac).

A licensed Integrity Check Value (ICV) is generated by applying a hash function to such a licensed MAC value and an ICV generation key. For example, the ICV generated at the time of license generation and the ICV generated based on a new license are compared, and if the same ICV is available, it is possible to ensure that the license is not falsified, and if the ICVs are different, it is determined that there is falsification.

The following describes a structure of Kicv, which is a key for generating an Integrity Check Value (ICV) of a license by using the above-described valid key block. That is, an example of generating a key with message data encrypted by EKB as an Integrity Check Value (ICV) of a license.

Fig. 48 and 49 show an example of the configuration in which when a shared license is transmitted to a plurality of apparatuses, an integrity check value generation key Kicv for verifying the presence or absence of tampering with the license is distributed by an Effective Key Block (EKB). Fig. 48 shows an example of the verification value generation key Kicv that can be decrypted by the distribution apparatuses 0, 1, 2, and 3, and fig. 49 shows an example of the verification value generation key Kicv that can be decrypted by only the apparatuses 0, 1, and 2 after the apparatus 3 of the apparatuses 0, 1, 2, and 3 is revoked (excluded).

In the example of fig. 48, the check value generation key Kicv is encrypted by the updated node key k (t)00 to generate and distribute data Enc (k (t)00, Kicv), and at the same time, an Effective Key Block (EKB) is generated and distributed so that the updated node key k (t)00 can be decrypted by the node key and the leaf key held by each of the devices 0, 1, 2, and 3. As shown in the right side of fig. 48, each device first obtains the updated node key k (t)00 by processing (decrypting) the EKB, and then decrypts the encrypted check value generation key Enc (k (t)00, Kicv) using the obtained node key k (t)00, thereby obtaining the check value generation key Kicv.

Even if the same valid key block (EKB) is received, the other devices 4, 5, 6, and 7 cannot process the EKB with the node key and leaf key held by the devices themselves and acquire the updated node key k (t)00, and thus can securely transmit the check value generation key only to the legitimate device.

On the other hand, the example of fig. 49 shows that, in the group surrounded by the dotted line frame of fig. 12, after the device 3 is revoked (excluded) because of the leaked key, a valid key block (EKB) that can be decrypted by only the devices 0, 1, and 2 that are members of the other group is generated and distributed. The valid key block (EKB) shown in fig. 49 and the data Enc (k (t)00, Kicv) encrypted by the node key (k (t)00) to the check value generation key (Kicv) are distributed.

The right side of fig. 49 shows the decryption order. First, the devices 0, 1, and 2 decrypt the received valid key block using the leaf key or node key held by the devices themselves, and acquire the updated node key (k (t) 00). Then, the verification value generation key Kicv is obtained by decryption of k (t) 00.

The other groups of devices 4, 5, and 6 shown in fig. 12 cannot acquire the updated node key (k (t)00) using the leaf key and the node key that are owned by the devices themselves, even if the same data (EKB) is received. Similarly, the revoked device 3 cannot acquire the updated node key (k (t)00) using the leaf key or the node key that it has, and only a device having a legitimate right can decrypt the check value generation key and use it.

In this way, if the distribution of the check value generation key is performed using the EKB, the data amount can be reduced, and the check value generation key that can be decrypted only by a legitimate right can be securely distributed.

With such a license Integrity Check Value (ICV), illegal copies of EKBs and encrypted licenses can be excluded. For example, as shown in fig. 50A, assume a case where a license L1 and a license L2 are stored together with a valid key block (EKB) from which a license key can be obtained on media 1, and are directly copied to media 2. The EKB and encrypted license may be copied and utilized in a device that can decrypt the EKB.

In the example shown in fig. 50B, the integrity check value (ICV (L1, L2)) is stored in correspondence with the license legally stored in each medium. In addition, (ICV (L1, L2)) indicates that the integrity check value ICV ═ hash of the license calculated using the hash function in the license L1 and the license L2 (Kicv, L1, L2). In the structure of fig. 50B, the medium 1 legitimately stores therein the license 1 and the license 2, and stores therein the integrity check value (ICV (L1, L2)) generated based on the license L1 and the license L2. In addition, the medium 2 legitimately stores the license 1, and stores the integrity check value (ICV (L1)) generated from the license L1.

In this configuration, when { EKB, license 2} stored in the medium 1 is copied to the medium 2, if the license check value is newly generated in the medium 2, ICVs (L1, L2) different from the Kicv (L1) stored in the medium 2 can be generated, and it can be understood that the new license is stored by tampering or illegal copying of the license. In a device for reproducing a medium, an ICV check is performed in a step prior to a reproducing step to determine whether the generated ICV and the stored ICV match each other, and if they do not match, the reproduction is not performed, thereby preventing the reproduction from being permitted by an illegal copy.

In order to further improve security, a structure may be adopted in which a permitted Integrity Check Value (ICV) is generated from data including a rewrite count value. I.e. the structure calculated by ICV hash (Kicv, counter +1, L1, L2.). Here, the count value (counter +1) is set to a value that is incremented each time the ICV is rewritten. In addition, the count value must be stored in a secure memory.

Furthermore, in a configuration where the license Integrity Check Value (ICV) may not be stored on the same medium as the license, the license Integrity Check Value (ICV) may be stored on another medium.

For example, when a license is read from a medium such as a dedicated medium or a general MO that does not take a copy protection measure, if an Integrity Check Value (ICV) is stored in the same medium, an unauthorized user may rewrite the ICV, and the security of the ICV cannot be ensured. In this case, by adopting a configuration in which the ICV is stored in a secure medium on the host and the ICV is used for copy control of the license (for example, registration/deregistration, movement), it is possible to perform security management of the ICV and tamper verification of the license.

This structure is shown in fig. 51, for example. In the example shown in fig. 51, licenses 1 to 3 are stored in a medium 2201 which is read out from a dedicated medium or a medium which is not provided with a copy protection measure such as a general MO, and an Integrity Check Value (ICV) relating to these licenses is stored in a secure medium 2202 on a host which is not allowed to be freely accessed by a user, so that the user can be prevented from illegally rewriting the Integrity Check Value (ICV). With such a configuration, for example, when the device on which the medium 2201 is mounted executes reproduction of the medium 2201, the host PC or the server checks the ICV to determine whether or not reproduction is possible, thereby preventing unauthorized copy permission or falsification of the permitted reproduction.

The client to which the present invention is applied may be a Personal Digital Assistant (PDA), a mobile phone, a game terminal, or the like, in addition to a Personal computer.

When a series of processes are executed by software, a program constituting the software can be installed from a network or a recording medium to a computer embedded in dedicated hardware, or a general-purpose personal computer or the like which can execute various functions by installing various programs.

As shown in fig. 2, the recording medium may be constituted by a packet medium including a magnetic Disk 41 (including a flexible Disk), an optical Disk 42 (including a cd ROM (Compact disc Read Only memory), a DVD (Digital Versatile disc)), an optical Disk 43 (including an MD (Mini Disk)), a semiconductor memory 44, and the like, which are provided to the user in a state of being built in the apparatus main body in advance, and may be constituted by a ROM22 in which programs are recorded, a hard Disk included in the storage unit 28, and the like, which are separately provided from the apparatus main body.

In the present specification, the steps describing the program recorded in the recording medium include not only processing performed in time series in the described order but also processing not necessarily performed in parallel or individually in time series.

Further, in order to prevent the process from being analyzed, it is preferable that the program itself which executes the process related to the security is encrypted. For example, the program may be configured as a tamper-resistant module for performing a process such as an encryption process.

The information described in the header of the content to specify the license allowing the use of the content may not be a license ID uniquely identifying the license. In the above-described embodiment, the license ID is information for specifying a license necessary for using the content, and a license is information for specifying a content permitted to be used and identifying a license in accordance with a license request from the client 1. The content may be a list in which various attribute information related to the content itself is described, and the license may be a conditional expression of the content permitted to be used by the license. In this case, the attribute information included in the content is information specifying a license that permits use of the content, the conditional expression included in the license is information specifying the content permitted to be used by the license, and the license ID is information that uniquely identifies the license. In this case, a plurality of licenses can be associated with one content, and the licenses can be distributed flexibly.

In addition, the content data is not limited to music data. For example, the content may be image data, animation data, text data, animation data, a software program, or a combination thereof.

In this specification, a system refers to an entire apparatus including a plurality of apparatuses.

Industrial applicability of the invention

As described above, according to the 1 st information processing apparatus of the present invention, it is possible to manage keys for respective provision forms.

According to the 2 nd information processing apparatus of the present invention, the form management key can be provided for each.

According to the 3 rd information processing apparatus of the present invention, it is possible to support a plurality of content providing modes.

According to the 4 th information processing apparatus of the present invention, a plurality of different apparatus node keys can be held.

Claims (9)

1. An information processing apparatus that supplies a device node key used for decryption processing of an Effective Key Block (EKB) contained in content to a client terminal assigned to a leaf of the lowermost layer of a key management hierarchical tree structure, comprising:

an assigning unit that assigns a plurality of nodes in a predetermined hierarchy of the key management hierarchical tree structure to a plurality of types, assigns a client terminal to a lower leaf of each node with each node managed in each type as a vertex node;

and a providing unit configured to assign at least two leaves to the client terminal by the assigning unit, and provide the client terminal processing device with device node keys included in at least two types including the leaves.

2. The information processing apparatus according to claim 1, wherein: the providing unit provides the device node key together with leaf identification information for identifying the leaf.

3. The information processing apparatus according to claim 2, characterized by further comprising:

a communication section for receiving a license request requesting a license specifying a condition for using the content from the client terminal based on the leaf identification information and content identification information identifying the content,

the leaf identification information included in the license request is added to the license, and the license formed with the electronic signature is transmitted.

4. The information processing apparatus according to claim 1, wherein: the providing unit provides the device node key together with the secret key and the public key of the client terminal and the public key of the providing unit.

5. An information processing method of providing a device node key used for decryption processing of an Effective Key Block (EKB) contained in a content to a client terminal assigned to a leaf of a lowermost layer of a key management hierarchical tree structure, comprising:

an assigning step of assigning a plurality of nodes of a predetermined hierarchy of the key management hierarchical tree structure to a plurality of types, and assigning a client terminal to a lower leaf of each node with each node managed in each type as a vertex node;

a providing step of assigning at least two of the leaves to the client terminal in the assigning step, and providing the device node keys included in at least two types including the leaves to the client terminal processing device.

6. An information processing apparatus that provides a client terminal that utilizes a content with a license to utilize the content, comprising:

a communication section that receives at least two or more leaf identification information from the client terminal, the leaf identification information identifying a leaf of a lowermost layer of a key management hierarchical tree structure assigned to the client terminal;

and a control unit (21) which takes a node of a predetermined hierarchy of the key management hierarchical tree structure as a vertex node, manages the vertex node as a top node, assigns the vertex node to each type, and adds the leaf identification information received by the communication unit to the permission corresponding to the type when the leaf identification information received by the communication unit is included below the vertex node.

7. An information processing method for providing a license to utilize a content to a client terminal utilizing the content, comprising:

a communication step of receiving at least two or more leaf identification information from the client terminal, the leaf identification information identifying a leaf of a lowermost layer of a key management hierarchical tree structure assigned to the client terminal;

and a control step of assigning a node of a predetermined hierarchy of the key management hierarchical tree structure as a vertex node managed as a top node to each type, and adding the leaf identification information received in the communication step to a license corresponding to the type when the leaf identification information received in the communication step is included below the vertex node.

8. An information processing apparatus for a client terminal that reproduces content on a leaf assigned to a lowermost layer of a key management hierarchical tree structure, characterized by comprising:

a storage unit configured to store device node keys belonging to two types at a minimum, the device node keys being assigned to a plurality of nodes in a predetermined hierarchy of the key management hierarchical tree structure as vertex nodes of respective types, and the device node keys being assigned to nodes in a predetermined hierarchy from the leaf to a lower level than the vertex nodes as device node keys;

an acquisition unit that acquires, among the node keys from the top node of the type described above to the node of the uppermost layer of the device node key, a valid key block (EKB) obtained by encrypting the node key of the upper layer with the node key of the lower layer, together with the content;

a decryption unit (24) for decrypting the content by decrypting the valid key block (EKB) with the device node key stored in the storage unit;

and an output unit that outputs the content decrypted by the decryption unit.

9. An information processing method for a client terminal that reproduces content, assigned to a leaf of the lowermost layer of a key management hierarchical tree structure, comprising:

a storage control step of assigning a plurality of nodes of a predetermined hierarchy of the key management hierarchical tree structure as vertex nodes of each type, and storing device node keys belonging to the two lowest types, with nodes of the predetermined hierarchy from the leaf to a lower level than the vertex node being device node keys;

an acquisition step of acquiring, among the node keys from the top node of the type described above to the node of the uppermost layer of the device node key, a valid key block (EKB) obtained by encrypting the node key of the upper layer with the node key of the lower layer together with the content;

a decryption step of decrypting the contents by decrypting the Effective Key Block (EKB) with the device node key stored in the storage control step;

and an output step of outputting the content decrypted by the decryption step.