JP6791247B2 - Authentication device and authentication method, and content transmission device - Google Patents

Description

The technology disclosed in the present specification relates to an authentication device and an authentication method for performing an authentication process based on a predetermined standard, and more particularly to an authentication device and an authentication method using an exclusion target list.

In a system that transmits content, in order to properly protect the transmitted content, authentication processing is performed between the transmitting device and the receiving device, and as a result, the content is encrypted and transmitted with a key based on the shared information. Is being done. By making the information necessary for the authentication process available only to the licensee who has a contract to properly protect the content, as long as the licensee manufactures a device that meets the provisions of the contract, the content can be properly protected. It will be realized.

Digitized content is relatively easy to perform unauthorized operations such as copying and tampering. For this reason, when transmitting content between devices, it is particularly strongly required by the content provider to appropriately protect the transmitted content.

As an industry standard technology for content transmission protection, for example, DTCP (Digital Transmission Content Protection) managed by DTLA (Digital Transmission Licensing Administrator) can be mentioned (see, for example, Patent Document 1). In DTCP, the content is protected by performing an authentication process between the transmitting device and the receiving device and defining a mechanism for encrypting and transmitting the content with a key based on the shared information as a result.

In addition, by making the information necessary for the authentication process available only to the licensee who has a contract to properly protect the content, as long as the licensee manufactures a device that meets the provisions of the contract, the content is appropriate. Protection is realized.

If a licensee or non-licensee creates a fraudulent device that does not meet the content protection regulations, it is necessary to eliminate the fraudulent device in order to prevent the leakage of the content. Specifically, in the authentication process between devices, if it is found that the authentication partner is an unauthorized device, the authentication may be interrupted to prevent content transmission.

Currently, in copyright protection technologies such as DTCP and HDCP (High-bandwidth Digital Content Protection), SRM (System Renewability Message) is defined in order to transmit information on devices recognized as fraudulent devices (for example, patents). See Reference 2). The licensor issues an SRM containing a list of device IDs of fraudulent devices. Then, each legitimate device refers to the SRM at the time of authentication, and if the device ID received from the device of the authentication partner is included in the SRM, the authentication process is interrupted. In this way, the device indicated by the SRM is excluded at the time of authentication, so that the device identified as a fraudulent device is excluded from the system for transmitting the content.

Since the device ID is generally included in the device certificate with an electronic signature provided by the licensor to the licensee, falsification prevention and counterfeiting by non-licensees are prevented. The device certificate is incorporated into the product by the licensee and passed to the authentication partner during the authentication process (described later).

Japanese Unexamined Patent Publication No. 2015-103890 Japanese Unexamined Patent Publication No. 2005-45641

An object of the technique disclosed in the present specification is to provide an authentication device and an authentication method for performing an authentication process based on a predetermined standard.

The technology disclosed in the present specification has been made in consideration of the above-mentioned problems, and the first aspect thereof is.
With the communication unit that communicates with the authentication partner,
A control unit that controls the authentication process based on information transmitted to and received from the authentication partner via the communication unit.
A holding unit that holds identification information common to common products with implementations related to a given function,
Equipped with
The control unit causes the authentication partner to transmit the identification information for which falsification prevention measures have been taken during the authentication process.
It is an authentication device.

According to the second aspect of the technique disclosed in the present specification, the control unit of the authentication device according to the first aspect is configured to transmit the identification information protected by a signature by a certificate authority to the authentication partner. Has been done.

According to a third aspect of the technology disclosed herein, the holding unit of the authentication device according to the second aspect holds a device certificate that includes the identification information and is protected by a signature by a certificate authority. The control unit is configured to transmit the device certificate to the authentication partner.

According to a fourth aspect of the technology disclosed herein, the holding portion of the authentication device according to the second aspect is protected by a signature by a certificate authority, including the identification information, separate from the device certificate. The control unit holds the second certificate, and the control unit is configured to transmit the second certificate to the authentication partner.

According to the fifth aspect of the technique disclosed in the present specification, the holding unit of the authentication device according to the first aspect has at least a device certificate including a device public key and a device secret corresponding to the device public key. The key is further held, and the control unit is configured to send a message including the identification information and protected by the signature of the device private key to the authentication partner.

According to the sixth aspect of the technique disclosed herein, the holding unit of the authentication device according to the first aspect further holds a manufacturer's private key and a manufacturer's certificate issued for each manufacturer. The control unit is configured to transmit a second certificate including the identification information and protected by a signature by the manufacturer's private key to the authentication partner together with the manufacturer's certificate.

According to the seventh aspect of the technique disclosed in the present specification, the control unit of the authentication device according to the second aspect has said identification information in a phase of exchanging a device certificate with the authentication partner during the authentication process. Is configured to be transmitted to the authentication partner.

According to the eighth aspect of the technique disclosed herein, the holding portion of the authentication device according to the first aspect includes a device certificate including information indicating that it is incorporated in a component, and the identification information. A second certificate including information associated with the device certificate and protected by a signature with a predetermined private key is held, and the control unit sends the device certificate and the second certificate to the authentication partner. It is configured to be sent.

According to the ninth aspect of the technique disclosed herein, in the authentication device according to the eighth aspect, the device certificate includes the device ID of the component used in the authentication device, and the second certificate. Contains information in the range of legitimate device ID values.

In addition, the tenth aspect of the technique disclosed herein is:
It is an authentication method that performs authentication processing based on the information that the authentication device sends and receives with the authentication partner.
A step of taking measures to prevent falsification of the identification information held by the authentication device and having a common implementation related to a predetermined function in a common product.
A step of transmitting the identification information for which falsification prevention measures have been taken to the authentication partner, and
It is an authentication method having.

In addition, the eleventh aspect of the technique disclosed herein is:
With the communication unit that communicates with the authentication partner,
A control unit that controls the authentication process based on information transmitted to and received from the authentication partner via the communication unit.
A holding unit that holds a list of identification information that is common to products that are common to implementations related to a given function and are excluded.
Equipped with
At the time of the authentication process, the communication unit receives the identification information for which falsification prevention measures have been taken from the authentication partner, and receives the identification information.
The control unit verifies the authenticity of the received identification information and checks whether it is present in the list.
It is an authentication device.

According to the twelfth aspect of the technique disclosed in the present specification, the communication unit of the authentication device according to the eleventh aspect receives the identification information of the authentication partner protected by the signature by the certificate authority and controls the control. The unit is configured to verify the authenticity of the identification information with the public key of the certificate authority and check the list.

According to the thirteenth aspect of the technique disclosed in the present specification, the communication unit of the authentication device according to the twelfth aspect includes the identification information of the authentication partner and is a device certificate protected by a signature by a certificate authority. Is received, the control unit is configured to verify the authenticity of the device certificate with the public key of the certificate authority and check the identification information included in the device certificate in the list.

According to the fourteenth aspect of the technique disclosed in the present specification, the communication unit of the authentication device according to the twelfth aspect is signed by a certificate authority including identification information, which is different from the device certificate of the authentication partner. The second certificate protected by the above is received from the authentication partner, and the control unit verifies the authenticity of the second certificate with the public key of the certificate authority and includes it in the second certificate. The identification information is configured to be checked in the list.

According to the fifteenth aspect of the technique disclosed in the present specification, the communication unit of the authentication device according to the eleventh aspect includes at least a device certificate including the device public key of the authentication partner and identification information. A message protected by a signature with the device private key corresponding to the device public key is received from the authentication partner, and the control unit verifies the authenticity of the received message with the device public key and identifies the message included in the message. The information is configured to be checked in the list.

According to the 16th aspect of the technique disclosed in the present specification, the communication unit of the authentication device according to the 11th aspect is signed by the manufacturer's private key issued to the manufacturer of the authentication partner including the identification information. The second certificate protected by the above and the manufacturer certificate issued to the manufacturer of the authentication partner are received from the authentication partner, and the control unit determines the authenticity of the received second certificate. It is configured to be verified by the manufacturer public key included in the manufacturer certificate and to check the identification information included in the second certificate in the list.

According to the 17th aspect of the technique disclosed in the present specification, the communication unit of the authentication device according to the 12th aspect is the authentication partner in the phase of exchanging the device certificate with the authentication partner during the authentication process. It is configured to receive identification information from.

According to the eighteenth aspect of the technique disclosed herein, the communication unit of the authentication device according to the eleventh aspect comprises a device certificate of the authentication partner including information indicating that it is incorporated in a component. Upon receiving a second certificate that includes the identification information of the authentication partner and the information associated with the device certificate and is protected by a signature with a predetermined private key, the control unit receives the device certificate and the second device. It is configured to verify the authenticity of the certificate and check whether the second certificate is associated with the device certificate.

According to the nineteenth aspect of the technique disclosed herein, the communication unit of the authentication device according to the eighteenth aspect is legitimate with the device certificate including the device ID of the component used for the authentication partner. The second certificate including the information in the range of the device ID value is received from the authentication partner, and the control unit includes the device ID included in the device certificate in the second certificate. It is configured to confirm that it is within the range of the device ID value.

In addition, the twentieth aspect of the technique disclosed herein is:
It is an authentication method that performs authentication processing based on the information that the authentication device sends and receives with the authentication partner.
The authentication device holds a list of identification information that is common to products that are common to implementations related to a predetermined function and are excluded.
The step of receiving the identification information for which falsification prevention measures have been taken from the authentication partner, and
Steps to verify the authenticity of the received identification information,
A step to check if the received identification information exists in the list, and
It is an authentication method having.

According to the 21st aspect of the technology disclosed in the present specification, in the authentication device according to the 1st aspect, the identification information is assigned to the manufacturer name unique to each applicable product manufacturer so as not to be duplicated in each manufacturer. It contains at least the information of the model model number given.

According to the 22nd aspect of the technique disclosed herein, in the authentication device according to the 21st aspect, the identification information further includes information about the version of the corresponding product model.

According to the 23rd aspect of the technology disclosed herein, in the authentication device according to the 22nd aspect, the identification information further includes information regarding the availability of a version of the corresponding product model.

According to the technique disclosed in the present specification, when performing an authentication process based on a predetermined standard, an excellent device and an authentication method capable of appropriately excluding fraudulent devices by using an exclusion target list are provided. can do.

The effects described in the present specification are merely examples, and the effects of the present invention are not limited thereto. In addition, the present invention may exert additional effects in addition to the above effects.

Still other objectives, features and advantages of the techniques disclosed herein will become apparent by more detailed description based on embodiments and accompanying drawings described below.

FIG. 1 is a diagram showing an outline of a communication flow of a fully authenticated protocol defined by DTCP. FIG. 2 is a diagram showing a device certificate, a device private key, and a CA public key held by the device performing the authentication process. FIG. 3 is a diagram showing a packet format of SRM. FIG. 4 is a diagram showing a configuration example of the model ID. FIG. 5 is a diagram showing a configuration example of a model ID. FIG. 6 is a diagram showing a configuration example of the model ID. FIG. 7 is a diagram showing a configuration example of a device certificate in which a model ID is inserted. FIG. 8 is a diagram showing a configuration example of a model certificate protected by an electronic signature by a certificate authority. FIG. 9 is a diagram showing a configuration example of a message including a model ID and an electronic signature added by a device private key. FIG. 10 is a diagram showing a model ID protected by an electronic signature with a manufacturer's private key issued to the licensee and a configuration example of the manufacturer's certificate. FIG. 11 is a diagram showing a configuration example of a device certificate provided with a CC flag. FIG. 12 is a diagram showing a configuration example of a model certificate including information on a range of device ID values. FIG. 13 is a diagram showing another configuration example of the model certificate including the information of the device ID value range. FIG. 14 is a diagram showing an example of a communication flow of an authentication protocol including a mechanism for excluding all devices of the same model. FIG. 15 is a flowchart showing a processing procedure for determining whether or not to exclude the authentication partner based on the model ID included in the device certificate of the authentication partner. FIG. 16 is a diagram showing another example of the communication flow of the authentication protocol including a mechanism for excluding all devices of the same model. FIG. 17 is a flowchart showing a processing procedure for determining whether or not to exclude the authentication partner based on the model ID included in the model certificate of the authentication partner. FIG. 18 is a flowchart showing a processing procedure for determining whether or not to exclude the authentication partner based on the model ID included in the model certificate of the authentication partner. FIG. 19 is a diagram showing another example of the communication flow of the authentication protocol including a mechanism for excluding all devices of the same model. FIG. 20 is a flowchart showing a processing procedure for determining whether or not to exclude the authentication partner based on the model ID included in the signed message of the authentication partner. FIG. 21 is a diagram showing another example of the communication flow of the authentication protocol including a mechanism for excluding all devices of the same model. FIG. 22 is a flowchart showing another processing procedure for determining whether or not to exclude the authentication partner based on the model ID included in the model certificate of the authentication partner. FIG. 23 is a flowchart showing another processing procedure for determining whether or not to exclude the authentication partner based on the model ID included in the model certificate of the authentication partner. FIG. 24 is a diagram showing a configuration example of a model ID with a CA electronic signature for the manufacturer name. FIG. 25 is a diagram showing a configuration example of a model ID with a CA electronic signature for the manufacturer name. FIG. 26 is a diagram showing a configuration example of a model ID with a CA electronic signature for the manufacturer name. FIG. 27 is a diagram showing another example of the communication flow of the authentication protocol including a mechanism for excluding all devices of the same model. FIG. 28 is a flowchart showing a processing procedure for determining whether or not to exclude the authentication partner based on the model ID included in the signed message of the authentication partner.

Hereinafter, embodiments of the techniques disclosed in the present specification will be described in detail with reference to the drawings.

Copyright protection technology such as DTCP protects content by performing authentication processing between the transmitting device and receiving device, and defining a mechanism for encrypting and transmitting the content with a key based on the shared information as a result. It has been realized. Further, in DTCP, SRM is defined in order to transmit information of a device recognized as an unauthorized device, and the device indicated by SRM is excluded at the time of authentication.

FIG. 1 schematically shows a communication flow of an authentication protocol defined by DTCP, which is performed between a transmitting device (device A) 101 and a receiving device (device B) 102 that perform content transmission. The transmitting device 101 referred to here corresponds to "Source", and the receiving device 102 corresponds to "Sink". It is assumed that the transmitting device 101 and the receiving device 102 can communicate with each other via a network (not shown). Further, the communication flow shown in FIG. 1 corresponds to the Full Authentication protocol corresponding to the contents of all copy management information defined by DTCP, and public key cryptography is used.

The transmitting device 101 and the receiving device 102 hold the device certificate 210, the device private key 220, and the CA public key 230 as shown in FIG. 2 on the premise that the authentication process is performed according to the protocol shown in FIG. There is.

The device certificate 210 includes at least a device-specific (device uniquely identified) device ID indicated by reference number 211 and a device public key indicated by reference number 212, and these information (shaded in the figure). Accompanied by the digital signature 213 of the Certificate Authority (CA) for the part). The device private key 220 is a private key corresponding to the device public key included in the device certificate 210. Further, the CA public key 230 is held for verifying the device certificate of the authentication partner.

Normally, the licensor issues the device certificate 210 and the device private key 220 corresponding to the device public key 212 included in the device certificate for each device and distributes it to the manufacturer of the device that is the licensee. Then, the manufacturer embeds the device certificate 210, the device private key 220, and the CA public key 230 in each device manufactured in-house (for example, a transmitting device 101 serving as a source and a receiving device 102 serving as a sink). Therefore, the equipment manufacturer needs to obtain the equipment certificate 210 for the number of equipment to be manufactured or sold from the licensor.

Although not shown in FIG. 2, each of the transmitting device 101 and the receiving device 102 also holds an SRM including a certificate revocation list (CRL). The transmitting device 101 and the receiving device 102 update their information each time a new version of SRM is received from the authentication partner.

The processing in the full authentication protocol shown in FIG. 1 will be briefly described.

First, the receiving device 102 transmits a random challenge including a random number (random challenge) and a device certificate B (device B certificate) of the receiving device 102 itself to the transmitting device 101 to make an authentication request (P111). For example, when the receiving device 102 tries to access the copyright-protected content on the transmitting device 101 side, an authentication request is made. The transmitting device 101 returns a response (RSP) to the command to send the random challenge, but the illustration is omitted in FIG. In the figure, "certificate" may be abbreviated as "cert".

The transmitting device 101 verifies the authenticity of the device certificate B received from the receiving device 102 (Verify B's device certificate). Since the device certificate B has a CA electronic signature created by the certificate authority, the transmitting device 101 can verify the authenticity of the device certificate B by using the CA public key of the certificate authority. .. If the authenticity verification fails, the authentication process is aborted at this point.

Further, the transmitting device 101 takes out the device ID of the receiving device 102 from the device certificate B and checks whether or not it is included in the SRM exclusion target list (Examine SRM). When the device ID is found in the exclusion target list (CRL Entries), the authentication process is aborted at this point so that the receiving device 102 is excluded. The SRM check is performed only when the DTLA signature (described later) included in the SRM is valid.

Then, the transmitting device 101 succeeds in verifying the authenticity of the device certificate B, and when the device ID of the receiving device 102 is not included in the exclusion target list, the random number (random challenge) and the transmitting device 101 itself A random challenge including the device certificate A (device A certificate) is transmitted to the receiving device 102 (P112), and the authentication process is continued. The receiving device 102 returns a response (RSP) to the command for sending this random challenge, but the illustration is omitted in FIG.

Similarly, the receiving device 102 verifies the authenticity of the device certificate A received from the transmitting device 101 (Verify A's device certificate), and the device of the transmitting device 101 taken out from the device certificate A. Check if the ID is in the SRM exclusion target list (Examine SRM).

When the transmitting device 101 succeeds in verifying the authenticity of the device certificate B and the SRM check, the information for sharing the key with the receiving device 102 (EC-DH key exchange (Elliptic curve Diffie-Hellman) first-phase value: EC-DH key exchange first phase value) A is calculated. Further, when the receiving device 102 also succeeds in verifying the authenticity of the device certificate A and the SRM check, it also calculates the information (EC-DH key exchange first phase value) B for sharing the key with the transmitting device 101.

Next, the transmitting device 101 includes the information A for key sharing calculated by itself, the SRM version number and generation information stored in the transmitting device 101, and the random number received from the receiving device 102 by a random challenge (P111). A signed message in which an electronic signature by the device private key of the transmitting device 101 itself is added to the information including the above is transmitted to the receiving device 102 (P113a). The receiving device 102 returns a response (RSP) to the command for sending the signed message, but the illustration is omitted in FIG.

Is the receiving device 102 tampered with the signed message received from the transmitting device 101 by using the device public key included in the device certificate A received from the transmitting device 101 in a random challenge (P112)? Verify if. The receiving device 102 may also check the SRM version number and then call the SRM update process.

If the receiving device 102 fails to verify the signed message of the transmitting device 101, the receiving device 102 refuses to continue the authentication process. On the other hand, when the receiving device 102 succeeds in verifying the signed message of the transmitting device 101, the information A for key sharing received from the transmitting device 101 and the information B for key sharing calculated by itself Based on both, the authentication key (Kauth) is calculated (Compute Each key).

Then, the receiving device 102 includes the information B for key sharing calculated by itself, the SRM version number and generation information stored in the receiving device 102, and the random number received from the transmitting device 101 by a random challenge (P112). A signed message in which an electronic signature by the device private key of the receiving device 102 itself is added to the information including the above is transmitted to the transmitting device 101 (P113b). The transmitting device 101 returns a response (RSP) to the command for sending the signed message, but the illustration is omitted in FIG.

On the transmitting device 101 side, the signed message received from the receiving device 102 has not been tampered with by using the device public key included in the device certificate B received from the receiving device 102 in a random challenge (P111). Verify if. The transmitting device 101 may also check the SRM version number and then call the SRM update process.

If the transmitting device 101 fails to verify the signed message of the receiving device 102, the transmitting device 101 refuses to continue the authentication process. On the other hand, when the transmitting device 101 succeeds in verifying the signed message of the receiving device 102, the information B for key sharing received from the receiving device 102 and the information A for key sharing calculated by itself Based on both, an authentication key (Kauth) having the same value as that calculated on the receiving device 102 side is calculated (Compute Each key).

When the above authentication process is successfully completed, the transmitting device 101 and the receiving device 102 can share the authentication key (Kauth), and the encryption key shared based on the authentication key is used for copyright protection. It is possible to carry out encrypted transmission of the created content. However, DTCP defines the validity period of the authentication key, and the encrypted transmission of the content using the password key based on the same authentication key is limited to the validity period of the authentication key.

In copyright protection technologies such as DTCP and HDCP, SRM is defined to transmit information on devices certified as fraudulent devices (described above). FIG. 3 shows the current SRM packet format (first generation (before update) packet format). In the figure, the CRL entries are a list of devices certified as fraudulent devices (Certificate Revocation List). The CRL Length indicates the size of the CRL, including the CRL Lents field, the CRL Entries field, and the DTLA signature field. Further, the version number (Version Number) is composed of a monotonically increasing numerical value indicating the version of the list.

When the device receives the SRM, it compares it with the version number of the SRM possessed by the device, and if the received SRM is newer, the device updates its own information by the received SRM. In this way, the device can share a list of device IDs of fraudulent devices to be excluded. By the way, the SRM can be exchanged between devices during the authentication process.

In the future, as ultra-high resolution (Ultra High Definition: UHD) content called 4K or 8K becomes widespread, the demand for enhanced security in copyright protection technology will increase more and more. Specifically, when fraud is discovered for a certain product (or when it does not meet the regulations regarding copyright protection technology such as DTCP and HDCP), it is not enough to exclude specific devices, and the same implementation is performed. There is a strong need to eliminate all products (ie, all products of the same model). In the following, products having the same implementation (or common implementation) will also be referred to as the same "model".

In the current SRM, it is necessary to register individual device IDs for each device to be excluded in CRL Entries. In order to exclude all devices of the same model, all device IDs of the corresponding devices must be registered in SRM. In the case of a model manufactured in large quantities, the amount of information registered in the SRM may be enormous, and the size may not fit within the predetermined upper limit size of the SRM.

For example, if continuous device IDs are assigned to devices of the same model, the first device ID and the last device ID of the model that must be excluded are registered in SRM, and the range of devices to be authenticated is the range. The amount of information registered in the SRM can be suppressed by performing the operation of excluding all the devices having the device ID value in the device. However, if the device IDs of devices of the same model are not continuous, individual device IDs must be registered, and as described above, there is a possibility that the size does not fit within the predetermined upper limit size of SRM, and registration in SRM. Is difficult.

Manufacturers may manufacture multiple models of products in parallel at the same time. If those models support similar copyright protection technologies, the licensor will issue a device-specific device certificate to the licensee manufacturer. Here, even if the licensor issues the device certificate so that the device IDs are continuous for one licensee, the device ID of the device certificate incorporated in one model is made continuous on the manufacturer side of the licensee. Is difficult. And when all the equipment has to be eliminated for any model, it can be difficult to register with the SRM as described above.

In order for the device ID included in the device certificate to be incorporated into the product of the same model by the licensee to be continuous, the device certificate with consecutive device IDs for the number of manufactured or shipped products of the model must be obtained from the licensor in advance. Must be. When manufacturing multiple models of products in parallel at the same time, it is necessary to obtain in advance a device certificate from the licensor for each model, in which the required number of device IDs are consecutive. If the manufacturing plan (the number of units manufactured for each model) is changed, there is a risk that the device certificate will be insufficient or, conversely, will be left over.

Therefore, in the present specification, one model ID should be assigned to a product having a common implementation related to a predetermined function, that is, the same model, and the SRM should be excluded (in addition to the device ID of the unauthorized device to be excluded). We propose a technology that enables registration of model IDs of models. Each device passes its model ID to the authentication partner during the authentication process, and if the model ID of the authentication partner is found in the SRM, the authentication is interrupted, so that all devices of the same model (That is, fraudulent equipment can be excluded even on a model basis). By incorporating the corresponding model ID for each device of the same model, the manufacturer does not need to ensure the continuity of the device ID for the same model. In other words, even if the device IDs of the devices of the same model are discontinuous, it is possible to exclude all the devices of the same model by registering a small amount of information called the model ID in the SRM.

Here, a method of configuring the model ID will be considered. The model ID registered in the SRM (or CRL) needs to be different for different models, and is determined to be unique information for each model of the product. 4 to 6 show configuration examples of model IDs, respectively.

In the example shown in FIG. 4, the model ID is composed of a combination of the manufacturer name of the product and the model model number. For example, the licensor centrally manages the manufacturer name so that the manufacturer name is not duplicated between different manufacturers. In addition, each manufacturer should assign the model model number to its own product model so that it does not overlap.

In the example shown in FIG. 5, the model ID is configured by further adding the model version number. In this case, it is possible to specify the model of the product to be excluded for each version.

Further, in the example shown in FIG. 6, the model ID is configured by adding the version number of the model and the provision time of the version of the product model. In a very rare case, it is assumed that the version number is incorrect due to a manufacturing error (for example, the version number is not updated even though the model has been upgraded, or for a new model version. Old version number will be assigned). By adding the provision time together with the version number to the model ID, it is possible to cover the error of the version number. In this case, for example, the model of the product to be excluded can be specified by the combination of the model model number and the delivery time.

In addition, in order to ensure the uniqueness of the model, other information (not shown) may be further added to the configuration examples of the model IDs shown in FIGS. 4 to 6.

Next, the method in which the device passes the model ID to the authentication partner will be considered. To ensure the elimination of fraudulent products, tamper-proof measures should be taken when passing the model ID to the authentication partner.

Specifically, as a method of preventing falsification of the model ID, (1) a method of protecting the model ID with an electronic signature by a licensor or a certificate authority, and (2) an electronic signature with a private key issued by the licensor to the licensee. A method of protecting the model ID can be considered. In either method, the authentication partner can verify the authenticity of the model ID by signing and authenticating with a public key issued by a licensor or a certificate authority.

First, as a method of (1) protecting a model ID with an electronic signature by a licensor or a certificate authority, (1a) a method of putting the model ID in a device certificate and transmitting it to an authentication partner, and (1b) a device certificate? Another method of transmitting to the authentication partner in the form of a model certificate accompanied by an electronic signature of the certificate authority can be considered.

FIG. 7 schematically shows a configuration example of the device certificate 700 in which the model ID is inserted, which is used in the method (1a). The device certificate 700 includes, at least, a device ID unique to the device (uniquely identifying the device) indicated by the reference number 701, a device public key indicated by the reference number 702, and a model ID indicated by the reference number 703. It is accompanied by the CA electronic signature 704 of the certificate authority for the information (shaded part in the figure). The authentication partner who receives the device certificate 700 can verify the authenticity of the device certificate 700 using the CA public key and check the SRM for the device ID 701 and model ID 703 extracted from the device certificate 700. it can.

Further, FIG. 8 schematically shows a configuration example of the model certificate 800 protected by the electronic signature by the certificate authority used in the method (1b). In the model certificate 800, at least the CA electronic signature 802 by the certification authority is added to the information including the model ID common to the same model indicated by the reference number 801 (the shaded portion in the figure). The authentication partner who receives the model certificate 800 can verify the authenticity of the model certificate 800 by using the CA public key, and can check the SRM for the model ID 801 extracted from the model certificate 800.

If the model ID is included in the device certificate according to the method (1a), the device certificate can be used only for a specific model. For this reason, the licensee manufacturer does not use the device certificate obtained from the licensor for another model when the device certificate of one model becomes insufficient. In addition, if the device certificate obtained for a certain model is left over, it cannot be diverted to another model and is wasted. On the other hand, according to the method in which the model ID is not included in the device certificate as in (1b), the degree of freedom that the device certificate obtained from the licensor can be used for any model of device can be ensured.

Further, as a method of (2) protecting the model ID with an electronic signature with a private key issued by the licensor to the licensee, (2a) a method of protecting the model ID with an electronic signature with a device private key issued by the licensor for each device. (2b) The licensor issues a manufacturer's private key and a manufacturer's certificate to each licensee, and each licensee generates an electronic signature for the model ID with each manufacturer's private key, together with the manufacturer's certificate. A method of sending to the authentication partner can be considered.

In the authentication protocol defined by DTCP shown in FIG. 1, in the communication phases P113a and P113b, a message with an electronic signature added by each other's device private key is transmitted. Therefore, when the method (2a) is adopted, if the model ID is included in the message, the transmission process of the model ID and the signature verification process on the receiving side are simplified.

FIG. 9 shows a configuration example of the message 900, which includes the model ID and is digitally signed by the device private key, which is used in the method (2a). In the signed message 900, an electronic signature 902 with a device private key for each device is added to information including a common model ID in the same model indicated by reference number 901 (shaded part in the figure). .. In addition to the model ID, information for key sharing calculated by the device (EC-DH key exchange first phase value), SRM version number and generation information stored in the device, and received from the authentication partner by random challenge. Random numbers etc. are included in the message. The authentication partner who receives the signed message 900 verifies the authenticity of the message 900 using the device public key included in the device certificate received by the message sender in a random challenge, and is extracted from the signed message 900. The SRM can be checked for the model ID 901.

Further, FIG. 10 shows a configuration example of the model ID protected by the electronic signature by the manufacturer's private key and the manufacturer's certificate used in the method (2b). As shown by the reference number 1010, the model ID becomes a protected model certificate by adding the electronic signature 1012 of the manufacturer's private key to the information 1011 to the information 1011 including the model ID of the device. On the other hand, the manufacturer certificate 1020 includes information including the manufacturer public key 1021 corresponding to the manufacturer private key, and a CA electronic signature 1022 by a certificate authority for the information. The authentication partner who receives the model certificate 1010 protected by the electronic signature 1012 with the manufacturer's private key and the manufacturer certificate 1020 protected by the CA electronic signature 1022 first uses the CA public key of the certificate authority to certify the manufacturer. The authenticity of the document 1020 is verified, then the authenticity of the model certificate 1010 is verified using the manufacturer public key 1021 included in the manufacturer certificate 1020, and further extracted from the information 1011 contained in the model certificate 1010. The SRM can be checked for the model ID.

Now, let us consider how to deal with cases where non-licensees manufacture fraudulent equipment. It cannot be expected that a fraudulent manufacturer who intends to manufacture a fraudulent device will set a model ID that includes information that leads to the exclusion of its own product. Similarly, the continuity of device IDs of fraudulent devices cannot be expected, and it is difficult to eliminate them by model by SRM.

Therefore, this specification further proposes a technique for preventing an unauthorized device manufactured by a non-licensee from succeeding in the authentication process by using a model certificate generated only by a legitimate manufacturer who is a licensee.

It is not easy to identify the source of the leak in the case where a part containing a device certificate issued by a licensor and a device private key is illegally diverted and a non-licensee manufactures a fraudulent device using such a part. Of particular concern for reasons. The parts referred to here correspond to, for example, semi-finished products such as circuit chips.

In order to prevent unauthorized diversion of legitimate parts by non-licensees, a CC (Companent Certificate) flag indicating whether or not the parts are issued is provided in the device certificate. Then, the licensor sets the CC flag (that is, CC = 1) in the device certificate incorporated in the part such as the semi-finished product.

In addition, the licensor ensures that the device IDs are continuous when delivering (selling) parts containing such a device certificate (with a CC flag) to a certain manufacturer to the parts vendor who is the licensee. And oblige the licensor to be notified of its ID value (or the range of legitimate device ID values used for such parts).

Further, the licensor includes, in addition to the model ID, information in the range of valid device ID values as information associated with the device certificate in the model certificate for manufacturers using such parts. Ask for.

FIG. 11 shows a configuration example of the device certificate 1100 provided with the CC flag. The device certificate 1100 includes at least the CC flag indicated by the reference number 1101, the device ID indicated by the reference number 1102, and the device public key indicated by the reference number 1103, and these information (shaded portion in the figure). Accompanied by the certificate authority's electronic signature 1104.

As shown in FIG. 11, even if a special information called a CC flag is not added to the device certificate, the device ID of the device certificate is divided and used, for example, a device ID having a predetermined value P or more is half. If it is possible to determine whether or not the device certificate is for a semi-finished product based on the value of the device ID, such as by using it for a finished product, the CC flag can be omitted. In other words, the format of the information indicating that the device certificate is embedded in the component is not particularly limited.

Further, FIG. 12 shows a configuration example of the model certificate 1200 including the information of the device ID value range. The model certificate 1200 includes at least the model ID indicated by the reference number 1201 and the information indicating the range of the legitimate device ID values indicated by the reference number 1202, and for these information (the shaded portion in the figure). Accompanied by the CA electronic signature 1203 of the certificate authority.

FIG. 13 shows another configuration example of the model certificate 1300 including information on the range of device ID values. The model certificate 1300 is common to the model certificate 1200 shown in FIG. 12 in that it includes at least the model ID indicated by the reference number 1301 and the information indicating the range of valid device ID values indicated by the reference number 1302. is there. However, the model certificate shown in FIG. 12 is that the model certificate 1300 is accompanied by the electronic signature 1303 by the manufacturer's private key instead of the CA electronic signature of the certificate authority for these information (the shaded part in the figure). It is different from 1200. When using the model certificate 1300 protected by the manufacturer's private key, it is necessary to also send the manufacturer's certificate (see FIG. 10) to the authentication partner.

The device that authenticates such a product checks whether or not the CC flag of the received device certificate is set, and if the CC flag is set, the device ID included in the device certificate is set. Further checks whether is within the range of the device ID value specified in the model certificate. Then, if it cannot be confirmed that the device ID included in the device certificate is within the range of the device ID value specified in the model certificate, the authentication partner is an unauthorized device using a legitimate part that has been circulated. If so, interrupt the authentication process.

When using a device certificate with the CC flag set, it is possible to make it difficult to illegally use the leaked parts by imposing the authentication of the model certificate including the information associated with the device certificate. Non-licensees can obtain parts with a legitimate device certificate, but it is difficult to obtain a model certificate associated with the device certificate. It can be difficult to do.

FIG. 14 schematically shows an example of a communication flow of an authentication protocol including a mechanism for excluding all devices of the same model. In the figure, the transmitting device 1401 (device A) corresponds to "Source", the receiving device 1402 (device B) 1402 corresponds to "Sink", and the transmitting device 1401 and the receiving device 1402 communicate via a network (not shown). It is possible, and basically, the communication procedure according to the full authentication protocol specified by DTCP is carried out. Further, in the illustrated authentication protocol, the method of inserting the model ID into the device certificate of the above (1a) and transmitting the model ID to the authentication partner is applied, and both the transmitting device 1401 and the receiving device 1402 are shown in FIG. 7 (the model ID is shown in FIG. 7). (Including) It is assumed to hold the device certificate.

First, the receiving device 1402 transmits a random challenge including the random number and the device certificate B of the receiving device 1402 to the transmitting device 1401 to make an authentication request (P1411). The transmitting device 1401 returns a response (RSP) to the command for sending this random challenge, but the illustration is omitted in FIG.

The transmitting device 1401 verifies the authenticity of the device certificate B received from the receiving device 1402 by using the CA public key of the certificate authority. If the authenticity verification fails, the authentication process is aborted at this point.

Further, the transmitting device 1401 extracts the device ID and the model ID of the receiving device 1402 from the device certificate B, and checks whether the device ID and the model ID of the receiving device 1402 are not included in the SRM exclusion target list. Details of the processing procedure for checking the model ID will be described later. If at least one of the device ID and the model ID is found in the exclusion target list, the authentication process is aborted at this point so that the receiving device 1402 is excluded.

Then, the transmitting device 1401 succeeds in verifying the authenticity of the device certificate B, and when the device ID and the model ID of the receiving device 1402 are not included in the exclusion target list, the random number and the device certification of the transmitting device 1401 The random challenge including the document A is returned to the receiving device 1402 (P1412), and the authentication process is continued. The receiving device 1402 returns a response (RSP) to the command for sending this random challenge, but the illustration is omitted in FIG.

Similarly, the receiving device 1402 verifies the authenticity of the device certificate A received from the transmitting device 1401 and extracts the device ID and model ID of the transmitting device 1401 from the device certificate A to obtain the device ID of the transmitting device 1401. And check if the model ID is in the SRM exclusion target list. Details of the processing procedure for checking the model ID will be described later. If the verification of the authenticity of the device certificate A fails, or if at least one of the device ID or the model ID is found in the exclusion target list, the authentication process is interrupted at this point and the transmitting device is transmitted. Try to eliminate 1401.

When the transmitting device 1401 succeeds in verifying the authenticity of the device certificate B and the SRM check of the device ID and the model ID, the information for sharing the key with the receiving device 1402 (EC-DH key exchange first phase value). Calculate A. Further, when the receiving device 1402 also succeeds in verifying the authenticity of the device certificate A and the SRM check, it also calculates the information (EC-DH key exchange first phase value) B for sharing the key with the transmitting device 1401.

Next, the transmitting device 1401 includes the information A for key sharing calculated by itself, the SRM version number and generation information stored in the transmitting device 1401, and the random number received from the receiving device 1402 by the random challenge (P1411). A signed message in which an electronic signature by the device private key of the transmitting device 1401 itself is added to the information including the above is transmitted to the receiving device 1402 (P1413a). The receiving device 1402 returns a response (RSP) to the command for sending the signed message, but the illustration is omitted in FIG.

Is the receiving device 1402 tampered with the signed message received from the transmitting device 1401 by using the device public key included in the device certificate A received from the transmitting device 1401 in a random challenge (P1412)? Verify if. The receiving device 1402 may also check the version number of the SRM and then call the SRM update process.

If the receiving device 1402 fails to verify the signed message of the transmitting device 1401, the receiving device 1402 refuses to continue the authentication process. On the other hand, when the receiving device 1402 succeeds in verifying the signed message of the transmitting device 1401, the information A for key sharing received from the transmitting device 1401 and the information B for key sharing calculated by itself Based on both, the authentication key (Kauth) is calculated (Compute Each key).

Then, the receiving device 1402 receives the information B for key sharing calculated by itself, the SRM version number and generation information stored in the receiving device 1402, and the random number received from the transmitting device 1401 by the random challenge (P1412). A signed message in which an electronic signature by the device private key of the receiving device 1402 itself is added to the information including the above is transmitted to the transmitting device 1401 (P1413b). The transmitting device 1401 returns a response (RSP) to the command for sending the signed message, but the illustration is omitted in FIG.

Is the transmitting device 1401 tampered with the signed message received from the receiving device 1402 using the device public key included in the device certificate B received from the receiving device 1402 in a random challenge (P1411)? Verify if. The transmitting device 1401 may also check the version number of the SRM and then call the SRM update process.

If the transmitting device 1401 fails to verify the signed message of the receiving device 1402, the transmitting device 1401 refuses to continue the authentication process. On the other hand, when the transmitting device 1401 succeeds in verifying the signed message of the receiving device 1402, the information B for key sharing received from the receiving device 1402 and the information A for key sharing calculated by itself Based on both, an authentication key (Kauth) having the same value as that calculated on the receiving device 1402 side is calculated (Compute Each key).

When the above authentication process is successfully completed, the transmitting device 1401 and the receiving device 1402 can share the authentication key (Kauth). After that, the transmitting device 1401 and the receiving device 1402 can carry out encrypted transmission of the copyright-protected content by using the encryption key shared based on the authentication key. However, DTCP defines the validity period of the authentication key, and the encrypted transmission of the content using the password key based on the same authentication key is limited to the validity period of the authentication key.

FIG. 15 shows a flow chart format for a processing procedure for determining whether or not the transmitting device 1401 and the receiving device 1402 should exclude the authentication partner based on the model ID included in the device certificate of the authentication partner. It is shown by. However, in the illustrated processing procedure, it is assumed that the system uses the device certificate shown in FIG.

The device verifies the device certificate received by the authentication partner in a random challenge with the CA public key of the certificate authority, and then extracts the model ID included in the device certificate (step S1501). Then, it is checked whether or not the model ID exists in the exclusion target list stored in the CRL Entries field of the SRM held by the device (step S1502).

If the model ID is not found in the exclusion target list (No in step S1503), the device continues the authentication process with the authentication partner. On the other hand, when the model ID is found in the exclusion target list (Yes in step S1503), the authentication process is interrupted and the authentication partner is excluded.

FIG. 16 schematically shows another example of the communication flow of the authentication protocol including a mechanism for excluding all devices of the same model. In the figure, the transmitting device 1601 (device A) corresponds to "Source", the receiving device 1602 (device B) corresponds to "Sink", and the transmitting device 1601 and the receiving device 1602 can communicate via a network (not shown). Basically, the communication procedure is carried out according to the complete authentication protocol defined by DTCP. Further, in the illustrated authentication protocol, a method of transmitting to an authentication partner in the form of a model certificate accompanied by an electronic signature of a certificate authority, which is different from the device certificate of (1b) above, is applied, and the transmitting device 1601 and the receiving device are used. Both 1602 are a combination of the device certificate (including the model ID) shown in FIG. 7 and the model certificate shown in FIG. 8, or the device certificate (including the CC flag) shown in FIG. 11 and the device certificate shown in FIG. It is also assumed that a combination of model certificates (including information on the range of device IDs) will be retained.

First, the receiving device 1602 transmits a random number and a random challenge obtained by adding the model certificate B to the device certificate B of the receiving device 1602 to the transmitting device 1601 to make an authentication request (P1611). The transmitting device 1601 returns a response (RSP) to the command to send this random challenge, but the illustration is omitted in FIG.

The transmitting device 1601 verifies the authenticity of the device certificate B received from the receiving device 1602 by using the CA public key of the certificate authority. If the authenticity verification fails, the authentication process is aborted at this point. When it is confirmed that the device certificate B is genuine, the transmitting device 1601 checks whether the device ID included in the device certificate B is not included in the exclusion target list. If the device ID is found in the exclusion target list, the authentication process is aborted at this point so that the receiving device 1602 is excluded.

In addition, the transmitting device 1601 also verifies the authenticity of the model certificate B received from the receiving device 1602 using the CA public key of the certificate authority, and if the authenticity verification fails, the authentication process is performed at this point. Is interrupted. Then, when it is confirmed that the model certificate B is genuine, the transmitting device 1601 checks whether the model ID included in the model certificate B is not included in the exclusion target list. Details of the processing procedure for checking the model certificate will be given later. If the model ID is found in the exclusion target list, the authentication process is aborted at this point so that the receiving device 1602 is excluded.

In the case of a system that uses the combination of the device certificate shown in FIG. 11 and the model certificate shown in FIG. 12, it is checked whether or not the model certificate is correctly associated with the device certificate. Specifically, the transmitting device 1601 checks the CC flag of the device certificate B in addition to checking the exclusion target list of the model ID. Then, when the CC flag is set, that is, when it is found that the device certificate is a part (semi-finished product), the device ID included in the device certificate B is indicated by the model certificate B. It is also checked whether or not it is within the range of valid device ID values, that is, whether or not the model certificate B is associated with the device certificate B. Details of the processing procedure for checking the model certificate associated with the device certificate will be described later. If it cannot be confirmed that the model certificate B is associated with the device certificate B, it is known that the receiving device 1602 is a product using the parts that have been circulated, so that the transmitting device 1601 is used. At this point, the authentication process is aborted so that the receiving device 1602 is eliminated.

Then, the transmitting device 1601 succeeds in verifying the authenticity of the device certificate B and the model certificate B, and if neither the device ID nor the model ID of the receiving device 1602 is included in the exclusion target list, a random number is obtained. A random challenge including the model certificate A in addition to the device certificate A of the transmitting device 1601 is returned to the receiving device 1602 (P1612), and the authentication process is continued. The receiving device 1602 returns a response (RSP) to the command to send this random challenge, but the illustration is omitted in FIG.

Similarly, the receiving device 1602 verifies the authenticity of the device certificate A and the model certificate A received from the transmitting device 1601, and is included in the device ID and the model certificate A included in the device certificate A. Check if the model ID you are using is not included in the SRM exclusion target list. Details of the processing procedure for checking the model certificate will be given later. If the authenticity verification of at least one of the device certificate A or the model certificate A fails, and if at least one of the device ID or the model ID is found in the exclusion target list, the authentication process is interrupted at this point. (Abort) to eliminate the transmitting device 1601.

Further, in the case of a system that uses the combination of the device certificate shown in FIG. 11 and the model certificate shown in FIG. 12, it is checked whether or not the model certificate is correctly associated with the device certificate. Specifically, the receiving device 1602 checks the CC flag of the device certificate A in addition to checking the exclusion target list of the model ID. Then, when the CC flag is set, that is, when it is found that the device certificate is a part (semi-finished product), the device ID included in the device certificate A is indicated by the model certificate A. It is also checked whether or not the model certificate A is within the range of valid device ID values, that is, whether or not the model certificate A is associated with the device certificate A. Details of the processing procedure for checking the model certificate associated with the device certificate will be described later. If it cannot be confirmed that the model certificate A is associated with the device certificate A, it is known that the transmitting device 1601 is a product using the parts that have been circulated, so that the receiving device 1602 is used. At this point, the authentication process is aborted so that the transmitting device 1601 is eliminated.

When the transmitting device 1601 succeeds in verifying the authenticity of the device certificate B and the model certificate B and the SRM check of the device ID and the model ID, the information (EC-DH key exchange) for sharing the key with the receiving device 1602 First phase value) A is calculated. Further, when the receiving device 1602 also succeeds in verifying the authenticity of the device certificate A and the model certificate A and the SRM check of the device ID and the model ID, the information (EC-DH) for sharing the key with the transmitting device 1601. Key exchange first phase value) B is calculated.

Next, the transmitting device 1601 includes the information A for key sharing calculated by itself, the SRM version number and generation information stored in the transmitting device 1601, and the random number received from the receiving device 1602 by the random challenge (P1611). A signed message in which an electronic signature by the device private key of the transmitting device 1601 itself is added to the information including the above is transmitted to the receiving device 1602 (P1613a). The receiving device 1602 returns a response (RSP) to the command for sending the signed message, but the illustration is omitted in FIG.

Is the receiving device 1602 tampering with the signed message received from the transmitting device 1601 using the device public key included in the device certificate A received from the transmitting device 1601 in a random challenge (P1612)? Verify if. The receiving device 1602 may also check the version number of the SRM and then call the SRM update process.

If the receiving device 1602 fails to verify the signed message of the transmitting device 1601, the receiving device 1602 refuses to continue the authentication process. On the other hand, when the receiving device 1602 succeeds in verifying the signed message of the transmitting device 1601, the information A for key sharing received from the transmitting device 1601 and the information B for key sharing calculated by itself Based on both, the authentication key (Kauth) is calculated (Compute Another key).

Then, the receiving device 1602 includes the information B for key sharing calculated by itself, the SRM version number and generation information stored in the receiving device 1602, and the random number received from the transmitting device 1601 by the random challenge (P1612). A signed message in which an electronic signature by the device private key of the receiving device 1602 itself is added to the information including the above is transmitted to the transmitting device 101 (P1613b). The transmitting device 1601 returns a response (RSP) to the command for sending the signed message, but the illustration is omitted in FIG.

Is the transmitting device 1601 tampered with the signed message received from the receiving device 1602 using the device public key included in the device certificate B received from the receiving device 1602 in a random challenge (P1611)? Verify if. The transmitting device 1601 may also check the version number of the SRM and then call the SRM update process.

If the transmitting device 1601 fails to verify the signed message of the receiving device 1602, the transmitting device 1601 refuses to continue the authentication process. On the other hand, when the transmitting device 1601 succeeds in verifying the signed message of the receiving device 1602, the information B for key sharing received from the receiving device 1602 and the information A for key sharing calculated by itself Based on both, an authentication key (Kauth) having the same value as that calculated on the receiving device 1602 side is calculated (Compute Each key).

When the above authentication process is successfully completed, the transmitting device 1601 and the receiving device 1602 can share the authentication key (Kauth). After that, the transmitting device 1601 and the receiving device 1602 can perform encrypted transmission of the copyright-protected content by using the encryption key shared based on the authentication key. However, DTCP defines the validity period of the authentication key, and the encrypted transmission of the content using the password key based on the same authentication key is limited to the validity period of the authentication key.

FIG. 17 shows a flow chart format for a processing procedure for the transmitting device 1601 and the receiving device 1602 to determine whether or not to exclude the authentication partner based on the model ID included in the model certificate of the authentication partner. It is shown by. However, in the illustrated processing procedure, it is assumed that the system uses a combination of the device certificate shown in FIG. 7 and the model certificate shown in FIG.

The device verifies the device certificate received by the authentication partner in the random challenge with the CA public key of the certificate authority, and then verifies the model certificate received by the certificate authority in the random challenge with the CA public key of the certificate authority. (Step S1701). Here, if the verification of the authenticity of the model certificate fails (No in step S1702), the device aborts the authentication process and excludes the authentication partner.

If the authenticity of the model certificate is successfully verified (Yes in step S1702), the device is subsequently subjected to the model ID included in the model certificate in the CRL Entries field of the SRM held by the device. It is checked whether the model ID exists in the stored exclusion target list (step S1703).

If the model ID is not found in the exclusion target list (No in step S1704), the device continues the authentication process with the authentication partner. On the other hand, when the model ID is found in the exclusion target list (Yes in step S1704), the authentication process is interrupted and the authentication partner is excluded.

Further, FIG. 18 shows another processing procedure for determining whether or not the transmitting device 1601 and the receiving device 1602 should exclude the authentication partner based on the model ID included in the model certificate of the authentication partner. Is shown in the form of a flowchart. However, in the illustrated processing procedure, it is assumed that the system uses a combination of the device certificate shown in FIG. 11 and the model certificate (including the information associated with the device certificate) shown in FIG. ..

The device verifies the device certificate received by the authentication partner in the random challenge with the CA public key of the certificate authority, and then verifies the model certificate received by the certificate authority in the random challenge with the CA public key of the certificate authority. (Step S1801). Here, if the verification of the authenticity of the model certificate fails (No in step S1802), the device aborts the authentication process and excludes the authentication partner.

If the authenticity of the model certificate is successfully verified (Yes in step S1802), the device subsequently checks the CC flag of the device certificate (step S1803). Then, when the CC flag is set (Yes in step S1804), it can be seen that the device certificate being verified is the device certificate incorporated in the part (semi-finished product). It is checked whether or not the model certificate of the above is linked to the device certificate of the authentication partner (step S1805). Specifically, it is confirmed whether or not the device ID included in the device certificate is within the range of the legitimate device ID value indicated in the model certificate. If it cannot be confirmed that the model certificate is associated with the device certificate (No in step S1806), the device aborts the authentication process and excludes the authentication partner.

When the CC flag is not set and it is not the device certificate of the part (semi-finished product) (No in step S1804), and when it can be confirmed that it is the model certificate linked to the device certificate. (Yes in step S1806), subsequently, the model ID included in the model certificate exists in the exclusion target list stored in the CRL Entries field of SRM held by the device. Check whether or not (step S1807).

If the model ID is not found in the exclusion target list (No in step S1808), the device continues the authentication process with the authentication partner. On the other hand, when the model ID is found in the exclusion target list (Yes in step S1808), the authentication process is interrupted and the authentication partner is excluded.

FIG. 19 schematically shows another example of the communication flow of the authentication protocol including a mechanism for excluding all devices of the same model. In the figure, the transmitting device 1901 (device A) corresponds to "Source", the receiving device 1902 (device B) corresponds to "Sink", and the transmitting device 1901 and the receiving device 1902 can communicate via a network (not shown). Basically, the communication procedure according to the full authentication protocol defined by DTCP is carried out. Further, in the illustrated authentication protocol, the method of protecting the model ID by the electronic signature by the device private key issued by the licensor of the above (2a) for each device is applied, and both the transmitting device 1901 and the receiving device 1902 are device certificates. And the device private key (see Figure 2).

First, the receiving device 1902 transmits a random challenge including a random number and the device certificate B of the receiving device 1902 to the transmitting device 1901, and makes an authentication request (P1911). The transmitting device 1901 returns a response (RSP) to the command for sending this random challenge, but the illustration is omitted in FIG.

The transmitting device 1901 verifies the authenticity of the device certificate B received from the receiving device 1902 by using the CA public key of the certificate authority. If the authenticity verification fails, the authentication process is aborted at this point.

Further, the transmitting device 1901 extracts the device ID of the receiving device 1902 from the device certificate B, and checks whether the device ID of the receiving device 1902 is included in the SRM exclusion target list. If the device ID is found in the exclusion target list, the authentication process is aborted at this point so that the receiving device 1902 is excluded.

Then, the transmitting device 1901 succeeds in verifying the authenticity of the device certificate B, and when the device ID of the receiving device 1902 is not included in the exclusion target list, the random number and the device certificate A of the transmitting device 1901 are used. The included random challenge is returned to the receiving device 1902 (P1912), and the authentication process is continued. The receiving device 1902 returns a response (RSP) to the command for sending this random challenge, but the illustration is omitted in FIG.

Similarly, the receiving device 1902 verifies the authenticity of the device certificate A received from the transmitting device 1901, extracts the device ID of the transmitting device 1901 from the device certificate A, and sets the device ID of the transmitting device 1901 to SRM. Check if it is on the exclusion list. If the verification of the authenticity of the device certificate A fails, or if the device ID is found in the exclusion target list, the authentication process is aborted at this point so that the transmitting device 1901 is excluded. To do.

When the transmitting device 1901 succeeds in verifying the authenticity of the device certificate B and the SRM check of the device ID, it calculates the information (EC-DH key exchange first phase value) A for sharing the key with the receiving device 1902. To do. Further, when the receiving device 1902 also succeeds in verifying the authenticity of the device certificate A and the SRM check of the device ID, the information (EC-DH key exchange first phase value) B for sharing the key with the transmitting device 1901 is displayed. calculate.

Next, the transmitting device 1901 includes the information A for key sharing calculated by itself, the SRM version number and generation information stored in the transmitting device 1901, and the random number received from the receiving device 1902 by a random challenge (P1911). Further, a signed message (see FIG. 9) in which an electronic signature by the device private key of the transmitting device 1901 itself is added to the information including the model ID of the transmitting device 1901 is transmitted to the receiving device 1902 (P1913a). .. The receiving device 1902 returns a response (RSP) to the command for sending the signed message, but the illustration is omitted in FIG.

Is the receiving device 1902 tampering with the signed message received from the transmitting device 1901 using the device public key included in the device certificate A received from the transmitting device 1901 in a random challenge (P1912)? Verify if. The receiving device 1902 may also check the SRM version number and then call the SRM update process.

If the receiving device 1902 fails to verify the signed message of the transmitting device 1901, the receiving device 1902 refuses to continue the authentication process. If the receiving device 1902 can confirm that the signed message from the transmitting device 1901 has not been tampered with, the model ID of the transmitting device 1901 included in the signed message is the SRM exclusion target list. Check further to see if it is in. Details of the processing procedure for checking the model ID will be described later. If the model ID is found in the exclusion target list, the receiving device 1902 aborts the authentication process at this point so that the transmitting device 1901 is excluded.

Then, when the receiving device 1902 succeeds in verifying the signed message of the transmitting device 1901 and also succeeds in checking the model ID, the receiving device 1902 calculates the information A for key sharing received from the transmitting device 1901 by itself. The authentication key (Kauth) is calculated based on both of the information B for the key sharing (Compute Each key).

In addition, the receiving device 1902 also has the information B for key sharing calculated by itself, the SRM version number and generation information stored in the receiving device 1902, and the random number received from the transmitting device 1901 by the random challenge (P1912). Further, a signed message (see FIG. 9) in which an electronic signature by the device private key of the receiving device 1902 is added to the information including the model ID of the receiving device 1902 is transmitted to the transmitting device 1901 (P1913b). .. The transmitting device 1901 returns a response (RSP) to the command for sending the signed message, but the illustration is omitted in FIG.

Is the transmitting device 1901 tampered with the signed message received from the receiving device 1902 by using the device public key included in the device certificate B received from the receiving device 1902 in a random challenge (P1911)? Verify if. The transmitting device 1901 may also check the SRM version number and then call the SRM update process.

If the transmitting device 1901 fails to verify the signed message of the receiving device 1902, the transmitting device 1901 refuses to continue the authentication process. If the transmitting device 1901 can confirm that the signed message from the receiving device 1902 has not been tampered with, the model ID of the receiving device 1902 included in the signed message is the SRM exclusion target list. Check further to see if it is in. Details of the processing procedure for checking the model ID will be described later. If the model ID is found in the exclusion target list, the transmitting device 1901 aborts the authentication process at this point so that the receiving device 1902 is excluded.

Then, when the transmitting device 1901 succeeds in verifying the signed message of the receiving device 1902 and also succeeds in checking the model ID, the transmitting device 1901 calculates the information B for key sharing received from the receiving device 1902 by itself. The authentication key (Kauth) is calculated based on both the information A for key sharing (Compute Each key).

When the above authentication process is successfully completed, the transmitting device 1901 and the receiving device 1902 can share the authentication key (Kauth). After that, the transmitting device 1901 and the receiving device 1902 can perform encrypted transmission of the copyright-protected content by using the encryption key shared based on the authentication key. However, DTCP defines the validity period of the authentication key, and the encrypted transmission of the content using the password key based on the same authentication key is limited to the validity period of the authentication key.

FIG. 20 shows a flow chart format for a processing procedure for the transmitting device 1901 and the receiving device 1902 to determine whether or not to exclude the authentication partner based on the model ID included in the signed message of the authentication partner. It is shown by.

The device is included in this message after verifying the signed message received from the authentication partner with the device public key included in the device certificate received from the authentication partner in a random challenge (step S2001). The model ID is taken out (step S2002).

Next, the device checks whether the model ID exists in the exclusion target list stored in the CRL Entries field of the SRM held (step S2003).

If the model ID is not found in the exclusion target list (No in step S2004), the device continues the authentication process with the authentication partner. On the other hand, when the model ID is found in the exclusion target list (Yes in step S2004), the authentication process is interrupted and the authentication partner is excluded.

FIG. 21 schematically shows another example of the communication flow of the authentication protocol including a mechanism for excluding all devices of the same model. In the figure, the transmitting device 2101 (device A) corresponds to "Source", the receiving device 2102 (device B) corresponds to "Sink", and the transmitting device 2101 and the receiving device 2102 can communicate via a network (not shown). Basically, the communication procedure according to the complete authentication protocol defined by DTCP is carried out. Further, in the illustrated authentication protocol, it is assumed that the method of protecting the model ID by the electronic signature by the manufacturer's private key issued by the licensor of the above (2b) to each licensee is applied. Then, both the transmitting device 2101 and the receiving device 2102 hold the manufacturer certificate (see FIG. 10) including the manufacturer private key and the manufacturer public key corresponding to the manufacturer private key, and hold the model ID. It is assumed that a model certificate (see FIG. 10) in which the contained information is digitally signed by the manufacturer's private key is used.

First, the receiving device 2102 transmits a random challenge in which the random number and the device certificate B of the receiving device 2102 are added together with the manufacturer certificate B and the model certificate B protected by the electronic signature by the manufacturer's private key. It is transmitted to 2101 to make an authentication request (P2111). The transmitting device 2101 returns a response (RSP) to the command for sending this random challenge, but the illustration is omitted in FIG.

The transmitting device 2101 verifies the authenticity of the device certificate B and the manufacturer certificate B received from the receiving device 2102 by using the CA public key of the certificate authority. If the verification of the authenticity of at least one of the device certificate B or the manufacturer certificate B fails, the authentication process is aborted at this point. When it is confirmed that the device certificate B is genuine, the transmitting device 2101 checks whether the device ID included in the device certificate B is not included in the exclusion target list. If the device ID is found in the exclusion target list, the authentication process is aborted at this point so that the receiving device 2102 is excluded.

Further, when the transmitting device 2101 verifies the authenticity of the model certificate B received from the receiving device 2102 using the manufacturer's public key included in the manufacturer's certificate B, and fails to verify the authenticity. At this point, the authentication process is aborted. Then, when it is confirmed that the model certificate B is genuine, the transmitting device 2101 checks whether the model ID included in the model certificate B is not included in the exclusion target list. Details of the processing procedure for checking the manufacturer certificate and model certificate will be given later. If the model ID is found in the exclusion target list, the authentication process is aborted at this point so that the receiving device 2102 is excluded.

In the case of a system that uses a combination of a device certificate and a model certificate, it is checked whether the model certificate is correctly linked to the device certificate. For example, when the device certificate B is provided with the CC flag (see FIG. 11), it is checked whether or not the CC flag is set. If the model certificate B contains information in the range of valid device ID values (see FIG. 13), the device ID included in the device certificate B is indicated by the model certificate B. It is confirmed that the model certificate B is associated with the device certificate B depending on whether or not it is within the range of the valid device ID value. Details of the processing procedure for checking the model certificate associated with the manufacturer certificate will be given later. If it cannot be confirmed that the model certificate B is associated with the device certificate B, it is known that the receiving device 2102 is a product using the parts that have been circulated, so that the transmitting device 2101 is used. At this point, the authentication process is aborted so that the receiving device 2102 is excluded.

Then, the transmitting device 2101 succeeds in verifying the authenticity of the device certificate B, the manufacturer certificate B, and the model certificate B, and the device ID and the model ID of the receiving device 2102 are all included in the exclusion target list. If not, a random challenge is received by adding the manufacturer certificate A and the model certificate A protected by the electronic signature of the manufacturer's private key in addition to the random number and the device certificate A of the transmitting device 2101. Reply to 2102 (P2112) to continue the authentication process. The receiving device 2102 returns a response (RSP) to the command for sending this random challenge, but the illustration is omitted in FIG.

Similarly, the receiving device 2102 verifies the authenticity of the device certificate A and the manufacturer certificate A received from the transmitting device 2101 using the CA public key of the certificate authority. If the verification of the authenticity of at least one of the device certificate A or the manufacturer certificate A fails, the authentication process is aborted at this point. When it is confirmed that the device certificate A is genuine, the receiving device 2102 checks whether the device ID included in the device certificate A is not included in the exclusion target list. If the device ID is found in the exclusion target list, the authentication process is aborted at this point so that the transmitting device 2101 is excluded.

Further, when the receiving device 2102 verifies the authenticity of the model certificate A received from the transmitting device 2101 using the manufacturer's public key included in the manufacturer's certificate A, and fails to verify the authenticity. At this point, the authentication process is aborted. Then, when it is confirmed that the model certificate A is genuine, the receiving device 2102 checks whether the model ID included in the model certificate A is not included in the exclusion target list. Details of the processing procedure for checking the manufacturer certificate and model certificate will be given later. If the model ID is found in the exclusion target list, the authentication process is aborted at this point so that the transmitting device 2101 is excluded.

In the case of a system that uses a combination of a device certificate and a model certificate, it is checked whether the model certificate is correctly linked to the device certificate. For example, when the device certificate A is provided with the CC flag (see FIG. 11), it is checked whether or not the CC flag is set. If the model certificate A contains information in the range of valid device ID values (see FIG. 13), the device ID included in the device certificate A is indicated by the model certificate A. It is confirmed that the model certificate A is associated with the device certificate A depending on whether or not it is within the range of the valid device ID value. Details of the processing procedure for checking the model certificate associated with the manufacturer certificate will be given later. If it cannot be confirmed that the model certificate A is associated with the device certificate A, it is known that the transmitting device 2101 is a product using the parts that have been circulated, so that the receiving device 2102 is used. At this point, the authentication process is aborted so that the transmitting device 2101 is eliminated.

When the transmitting device 2101 succeeds in verifying the authenticity of the device certificate B and the model certificate B and the SRM check of the device ID and the model ID, the information for sharing the key with the receiving device 2102 (EC-DH key exchange). First phase value) A is calculated. Further, when the receiving device 2102 also succeeds in verifying the authenticity of the device certificate A and the model certificate A and the SRM check of the device ID and the model ID, the information (EC-DH) for sharing the key with the transmitting device 2101. Key exchange first phase value) B is calculated.

Next, the transmitting device 2101 receives the information A for key sharing calculated by itself, the SRM version number and generation information stored in the transmitting device 2101, and the random number received from the receiving device 2102 by a random challenge (P2111). A signed message in which an electronic signature by the device private key of the transmitting device 2101 is added to the information including the above is transmitted to the receiving device 2102 (P2113a). The receiving device 2102 returns a response (RSP) to the command for sending the signed message, but the illustration is omitted in FIG.

Is the receiving device 2102 tampering with the signed message received from the transmitting device 1601 using the device public key included in the device certificate A received from the transmitting device 2101 in a random challenge (P2112)? Verify if. The receiving device 2102 may also check the SRM version number and then call the SRM update process.

If the receiving device 2102 fails to verify the signed message of the transmitting device 2101, the receiving device 2102 refuses to continue the authentication process. On the other hand, when the receiving device 2102 succeeds in verifying the signed message of the transmitting device 2101, the information A for key sharing received from the transmitting device 2101 and the information B for key sharing calculated by itself Based on both, the authentication key (Kauth) is calculated (Compute Another key).

Then, the receiving device 2102 includes the information B for key sharing calculated by itself, the SRM version number and generation information stored in the receiving device 2102, and the random number received from the transmitting device 2101 by the random challenge (P2112). A signed message in which an electronic signature by the device private key of the receiving device 2102 itself is added to the information including the above is transmitted to the transmitting device 101 (P2113b). The transmitting device 2101 returns a response (RSP) to the command for sending the signed message, but the illustration is omitted in FIG.

Is the transmitting device 2101 tampered with the signed message received from the receiving device 2102 by using the device public key included in the device certificate B received from the receiving device 2102 in a random challenge (P2111)? Verify if. The transmitting device 2101 may also check the version number of the SRM and then call the SRM update process.

If the transmitting device 2101 fails to verify the signed message of the receiving device 2102, the transmitting device 2101 refuses to continue the authentication process. On the other hand, when the transmitting device 2101 succeeds in verifying the signed message of the receiving device 2102, the information B for key sharing received from the receiving device 2102 and the information A for key sharing calculated by itself Based on both, an authentication key (Kauth) having the same value as that calculated on the receiving device 2102 side is calculated (Compute Each key).

When the above authentication process is successfully completed, the transmitting device 2101 and the receiving device 2102 can share the authentication key (Kauth). After that, the transmitting device 2101 and the receiving device 2102 can perform encrypted transmission of the copyright-protected content by using the encryption key shared based on the authentication key. However, DTCP defines the validity period of the authentication key, and the encrypted transmission of the content using the password key based on the same authentication key is limited to the validity period of the authentication key.

In FIG. 22, a flow chart format shows a processing procedure for the transmitting device 2101 and the receiving device 2102 to determine whether or not to exclude the authentication partner based on the model ID included in the model certificate of the authentication partner. It is shown by. However, in the illustrated processing procedure, it is assumed that the system uses a combination of the model certificate and the manufacturer certificate shown in FIG. 10 together with the device certificate shown in FIG.

The device verifies the device certificate received from the authentication partner with the CA public key of the certificate authority, and then verifies the manufacturer certificate received from the certificate authority with the CA public key of the certificate authority (step S2201). Here, if the verification of the authenticity of the manufacturer's certificate fails (No in step S2202), the device aborts the authentication process and excludes the authentication partner.

Next, the device verifies the model certificate received from the authentication partner with the manufacturer's public key included in the manufacturer's certificate whose authenticity has been confirmed (step S2203). Here, if the verification of the authenticity of the model certificate fails (No in step S2204), the device aborts the authentication process and excludes the authentication partner.

If the authenticity of the model certificate is successfully verified (Yes in step S2204), the device is subsequently subjected to the model ID included in the model certificate in the CRL Entries field of the SRM held by the device. It is checked whether the model ID exists in the stored exclusion target list (step S2205).

If the model ID is not found in the exclusion target list (No in step S2206), the device continues the authentication process with the authentication partner. On the other hand, when the model ID is found in the exclusion target list (Yes in step S2206), the authentication process is interrupted and the authentication partner is excluded.

Further, in FIG. 23, another processing procedure for determining whether or not the transmitting device 2101 and the receiving device 2102 should exclude the authentication partner based on the model ID included in the model certificate of the authentication partner. Is shown in the form of a flowchart. However, in the illustrated processing procedure, the device certificate shown in FIG. 11, the manufacturer certificate shown in FIG. 10, and the model certificate (including the information associated with the device certificate) shown in FIG. 13 are combined. It is assumed that the system uses.

The device verifies the device certificate received from the authentication partner with the CA public key of the certificate authority, and then verifies the manufacturer certificate received from the certificate authority with the CA public key of the certificate authority (step S2301). Here, if the verification of the authenticity of the manufacturer's certificate fails (No in step S2302), the device aborts the authentication process and excludes the authentication partner.

Next, the device verifies the model certificate received from the authentication partner with the manufacturer's public key included in the manufacturer's certificate whose authenticity has been confirmed (step S2303). Here, if the verification of the authenticity of the model certificate fails (No in step S2304), the device aborts the authentication process and excludes the authentication partner.

If the authenticity of the model certificate is successfully verified (Yes in step S2304), the device subsequently checks the CC flag of the device certificate (step S2305). Then, when the CC flag is set (Yes in step S2306), it can be seen that the device certificate being verified is the device certificate incorporated in the part (semi-finished product). It is checked whether or not the model certificate of is associated with the device certificate received by the authentication partner in the random challenge (step S2307). Specifically, it is confirmed whether or not the device ID included in the device certificate is within the range of the legitimate device ID value indicated in the model certificate. If it cannot be confirmed that the model certificate is associated with the device certificate (No in step S2308), the device aborts the authentication process and excludes the authentication partner.

When the CC flag is not set and it is not the device certificate of the part (semi-finished product) (No in step S2306), and when it can be confirmed that it is the model certificate linked to the device certificate. (Yes in step S2308) Subsequently, the model ID included in the model certificate of the device exists in the exclusion target list stored in the CRL Entries field of the SRM held by the device. Check whether or not (step S2309).

If the model ID is not found in the exclusion target list (No in step S2310), the device continues the authentication process with the authentication partner. On the other hand, when the model ID is found in the exclusion target list (Yes in step S2310), the authentication process is interrupted and the authentication partner is excluded.

As described above, in the technology disclosed in the present specification, a common model ID is assigned to products of the same model, and in addition to the device ID of the fraudulent device to be excluded, the model to be excluded is assigned to the SRM. The model ID can also be registered. Then, each device that authenticates passes each other's model ID to the authentication partner by taking measures to prevent tampering, and if the model ID of the authentication partner is found in the SRM, the authentication is interrupted. All devices of the same model can be eliminated.

Manufacturers that manufacture and sell devices do not need to ensure the continuity of device IDs for the same model by incorporating the corresponding model IDs for each device of the same model. In other words, even if the device IDs of the devices of the same model are discontinuous, it is possible to exclude all the devices of the same model by registering a small amount of information called the model ID in the SRM.

Until now, when the device passes the model ID to the authentication partner, the methods to prevent the model ID from being tampered with are (1) a method of protecting the model ID with an electronic signature by a licensor or a certificate authority, and (2) a licensor. Has explained two ways to protect a model ID with a digital signature issued by a private key issued to a licensee.

Any of the methods (1) or (2) can be modified into an embodiment in which the following points (A) and (B) are further considered.

(A) Instead of using the information protected by the electronic signature by the licensor or the certificate authority as the entire model ID, only the information that does not change for each model, such as the manufacturer name, is used.
(B) When performing the authentication process between the transmitting device and the receiving device, the model ID and the electronic signature of the information in the model ID are encrypted and transmitted.

By doing so as in (A), it is not necessary to generate a CA electronic signature for each model while preventing an arbitrary model ID from being used by the CA electronic signature, and the burden at the time of manufacturing the device is reduced. be able to.

Further, by performing the method (B), it is possible to prevent a product other than the licensee from impersonating the licensee product by using the model ID used by the licensee's product and the CA electronic signature for the model ID.

In the following, as one of the modified examples of the implementation in consideration of the above (A) and (B), FIG. 19 and FIG. 19 which is one of the authentication methods including the mechanism for excluding all the devices of the same model already described. This will be described as a modification of FIG. 20.

FIGS. 24 to 26 show a configuration example of information in which a CA electronic signature is added to the model ID for the manufacturer name. The model ID registered in the SRM (or CRL) is identification information that needs to be different for different models and is unique to each model of the product.

The model ID is basically composed of a combination of the manufacturer name of the product and the model model number. For example, the licensor centrally manages the manufacturer name so that the manufacturer name is not duplicated between different manufacturers. In addition, each manufacturer should assign the model model number to its own product model so that it does not overlap. As shown in FIGS. 5 and 6, in addition to the model model number, information such as a model version number and a product model version provision time may be added to the model ID. When adding a version number, the licensor may centrally manage the manufacturer name and model model number, and each manufacturer may assign other information such as the version number and the provision time. The manufacturer name of the product does not change for each model. On the other hand, information such as the model model number changes for each model, or even within the same model.

In the example shown in FIG. 24, the CA electronic signature for the manufacturer name is arranged at the end of the model ID including the manufacturer name and the model model number. Further, in the example shown in FIG. 25, the CA electronic signature for the manufacturer name is arranged at the beginning of the model ID including the manufacturer name and the model model number. Further, in the example shown in FIG. 26, the CA electronic signature for the manufacturer name is arranged inside the model ID including the manufacturer name and the model model number. As shown in FIG. 26, it is not necessary that the information elements of the model ID are seamlessly connected.

The CA electronic signature for the manufacturer name is provided by the licensor and cannot be arbitrarily generated by the manufacturer of the device as the licensee. A device certificate (see FIG. 7) that protects information including the entire model ID with a CA digital signature in that only the manufacturer name, which is part of the model ID information, is protected by the CA digital signature. It differs from the model certificate (see Figure 8). In addition, a signed message (see FIG. 9) that protects the information including the model ID by the electronic signature by the device private key in that the model ID is protected by the CA electronic signature, although it is limited to some information. It is also different from the model certificate (see FIG. 10) that protects the information including the model ID by the electronic signature by the manufacturer's private key. Therefore, even if a manufacturer other than the licensee (non-licensee) tries to operate the model ID using an arbitrary manufacturer name, the CA electronic signature for the manufacturer name cannot be obtained. Therefore, the CA electronic signature for the manufacturer name in the authentication procedure. The authenticity of the device cannot be successfully verified, and the authentication partner can reliably exclude the device including such a model ID.

In the examples shown in FIGS. 24 to 26, the CA electronic signature is applied only to the manufacturer name (that is, some information) in the model ID, but the data other than the manufacturer name in the model ID or the model. The CA electronic signature for the entire ID may be added to the model ID.

FIG. 27 schematically shows another example of the communication flow of the authentication protocol including a mechanism for excluding all devices of the same model. In the figure, the transmitting device 2701 (device A) corresponds to "Source", the receiving device 2702 (device B) corresponds to "Sink", and the transmitting device 2701 and the receiving device 2702 can communicate via a network (not shown). Basically, the communication procedure is carried out according to the complete authentication protocol defined by DTCP. Further, in the illustrated authentication protocol, a third method of protecting the model ID (that is, a method of adding a CA electronic signature to the manufacturer name to the model ID consisting of the manufacturer name and model model number of the product and distributing the model ID) is applied. , The transmitting device 2701 and the receiving device 2702 both hold the device certificate, the device private key (see FIG. 2), and the model ID with the CA digital signature for the manufacturer name (see FIGS. 24 to 26). It is supposed to be done.

First, the receiving device 2702 transmits a random challenge including the random number and the device certificate B of the receiving device 2702 to the transmitting device 2701 to make an authentication request (P2711). The transmitting device 2701 returns a response (RSP # 1) to the command to send this random challenge.

The transmitting device 2701 verifies the authenticity of the device certificate B received from the receiving device 2702 using the CA public key of the certificate authority (Verify B's device certificate). If the authenticity verification fails, the authentication process is aborted at this point. Further, the transmitting device 2701 extracts the device ID of the receiving device 2702 from the device certificate B, and checks whether the device ID of the receiving device 2702 is included in the SRM exclusion target list (Examine SRM on Device ID). If the device ID is found in the exclusion target list, the authentication process is aborted at this point so that the receiving device 2702 is excluded.

Then, the transmitting device 2701 succeeds in verifying the authenticity of the device certificate B, and when the device ID of the receiving device 2702 is not included in the exclusion target list, the random number and the device certificate A of the transmitting device 2701 are used. The included random challenge is returned to the receiving device 1902 (P2712), and the authentication process is continued. The receiving device 1902 returns a response (RSP # 2) to the command to send this random challenge.

Similarly, the receiving device 2702 verifies the authenticity of the device certificate A received from the transmitting device 2701 (Verify A's Device certificate), extracts the device ID of the transmitting device 2701 from the device certificate A, and transmits the device. It is checked whether the device ID of the device 2701 is not included in the SRM exclusion target list (Examine SRM on Device ID). If the verification of the authenticity of the device certificate A fails, or if the device ID is found in the exclusion target list, the authentication process is aborted at this point to exclude the transmitting device 2701. To do.

When the transmitting device 2701 succeeds in verifying the authenticity of the device certificate B and the SRM check of the device ID, the transmitting device 2701 calculates the information (EC-DH key exchange first phase value) A for sharing the key with the receiving device 2702. To do. Further, when the receiving device 2702 also succeeds in verifying the authenticity of the device certificate A and the SRM check of the device ID, the information (EC-DH key exchange first phase value) B for sharing the key with the transmitting device 2701 is displayed. calculate.

Next, the transmitting device 2701 includes the information A for key sharing calculated by itself, the SRM version number and generation information stored in the transmitting device 1901, and the random number received from the receiving device 1902 by a random challenge (P2711). A signed message in which an electronic signature by the device private key of the transmitting device 2701 itself is added to the information including the above is transmitted to the receiving device 2702 (P2713a).

Is the receiving device 2702 tampering with the signed message received from the transmitting device 2701 using the device public key included in the device certificate A received from the transmitting device 2701 in a random challenge (P2712)? Verify if. The receiving device 2702 may also check the SRM version number and then call the SRM update process.

Here, when the receiving device 2702 fails to verify the signed message of the transmitting device 2701, the receiving device 2702 refuses to continue the authentication process.

On the other hand, when the receiving device 2702 can confirm that the signed message from the transmitting device 2701 has not been tampered with, the receiving device 2702 and the information A for key sharing received from the transmitting device 2701 and the key sharing calculated by itself. Based on both of the information B for, the authentication key (Kauth) is calculated (Compute Another key). In addition, the receiving device 2702 receives the encryption key B based on the secret data shared with the transmitting device 2701 by the EC-DH key exchange algorithm through the exchange of the EC-DH key exchange first phase value or the authentication key Kath. Also calculate.

For example, the result of processing the authentication key with a hash function such as SHA-2 can be used as the encryption key. In addition, among the secret data shared by the EC-DH key exchange, the data other than the part used for sharing the encryption key for encrypted transmission of the content and the result of processing the data by the hash function are used as the encryption key. You can also (the same applies below).

Then, when the receiving device 2702 encrypts the model ID with the CA electronic signature for the manufacturer name of the receiving device 2702 itself with the encryption key B, the receiving device 2702 responds to the command to send the signed message (P2713a) from the transmitting device 2701 (RSP). It is included in # 3) and transmitted to the transmitting device 2701.

Subsequently, the receiving device 2702 received the information B for key sharing calculated by itself, the SRM version number and generation information stored in the receiving device 1902, and the transmitting device 2701 by a random challenge (P2712). A signed message in which an electronic signature by the device private key of the receiving device 2702 itself is added to the information including the random number is transmitted to the transmitting device 2701 (P2713b).

The transmitting device 2701 verifies whether or not the signed message received from the receiving device 2702 has been tampered with by using the device public key included in the device certificate B received in the random challenge (P2711). .. The transmitting / receiving device 2701 may also check the version number of the SRM and then call the SRM update process.

Here, if the transmitting device 2701 fails to verify the signed message of the receiving device 2702, the transmitting device 2701 refuses to continue the authentication process.

On the other hand, when the transmitting device 2701 can confirm that the signed message from the receiving device 2702 has not been tampered with, the transmitting device 2701 and the information B for key sharing received from the receiving device 2702 and the key sharing calculated by itself. Based on both of the information A for, the authentication key (Kauth) is calculated (Compute Another key). Further, the transmitting device 2701 uses the encryption key A based on the secret data shared with the receiving device 2702 by the EC-DH key exchange algorithm through the exchange of the EC-DH key exchange first phase value or the authentication key Kath. Also calculate.

The transmitting device 2701 and the receiving device 2702 may perform calculations so that the encryption key A and the encryption key B are different from each other. In that case, different secret values shared in advance by the transmitting device 2701 and the receiving device 2702 are concatenated with respect to the input data to the hash function in the case of one encryption key A and the case of the other encryption key. Or, the number of times of processing by the hash function is changed between the encryption key A and the encryption key B (for example, in the case of the encryption key B, the result of processing the output of the hash function by the hash function is used again). ..

Further, the transmitting device 2701 decrypts the CA electronic signature for the encrypted model ID and the manufacturer name received as the response (RSP # 3) with the encryption key A (Decrypt B's Model-ID and signature). Then, the transmitting device 2701 verifies the authenticity of the CA electronic signature with respect to the manufacturer name using the CA public key of the certificate authority (Verify B's Model-ID), and verifies the authenticity of the manufacturer name in the model ID. At the same time, it is checked whether the model ID of the receiving device 2702 is not included in the SRM exclusion target list (Excel SRM on Model-ID).

If at least one of the verification of the authenticity of the CA digital signature for the manufacturer name of the receiving device 2702 and the check of the exclusion target list of the model ID fails, the transmitting device 2701 aborts the authentication process at this point. Therefore, the receiving device 2702 is excluded. On the other hand, when the transmitting device 2701 succeeds in both verifying the authenticity of the CA electronic signature for the manufacturer name of the receiving device 2702 and checking the exclusion target list of the model ID, the transmitting device 2701 has the CA electronic signature for the manufacturer name of the transmitting device 2701 itself. The model ID is encrypted with the encryption key A, included in the response (RSP # 4) to the command for sending the signed message (P2713b) from the receiving device 2702, and transmitted to the receiving device 2702.

The receiving device 2702 decrypts the CA electronic signature for the encrypted model ID and the manufacturer name received as the response (RSP # 4) with the encryption key B (Decrypt A's Model-ID and signature). Then, the receiving device 2702 verifies the authenticity of the CA electronic signature with respect to the manufacturer name using the CA public key of the certificate authority (Verify A's Model-ID), and verifies the authenticity of the manufacturer name in the model ID. At the same time, it is checked whether or not the model ID of the transmitting device 2701 is included in the SRM exclusion target list (Excel SRM on Model-ID).

If at least one of the verification of the authenticity of the CA electronic signature for the manufacturer name of the transmitting device 2701 and the check of the exclusion target list of the model ID fails, the receiving device 2702 aborts the authentication process at this point. Therefore, the receiving device 2702 is excluded.

When the above authentication process is successfully completed, the transmitting device 2701 and the receiving device 2702 can share the authentication key (Kauth). After that, the transmitting device 2701 and the receiving device 2702 can perform encrypted transmission of the copyright-protected content by using the encryption key shared based on the authentication key. However, DTCP defines the validity period of the authentication key, and the encrypted transmission of the content using the password key based on the same authentication key is limited to the validity period of the authentication key.

In the communication flow of the authentication protocol shown in FIG. 27, both the transmitting device 2701 and the receiving device 2701 use the response to the signed message from the authentication partner to encrypt the CA electronic signature for the model ID and the manufacturer name. Although the encrypted information is transmitted, such encrypted information may be transmitted by other methods. For example, after extending the authentication protocol and exchanging signed messages, each of the transmitting device 2701 and the receiving device 2701 can send the encrypted information of the CA digital signature for the model ID and the manufacturer name with a new command. Is.

FIG. 28 shows a flow chart showing a processing procedure for the transmitting device 2701 and the receiving device 2702 to determine whether or not to exclude the authentication partner based on the model ID transmitted as a response to the signed message of the authentication partner. Shown in format.

First, the device verifies the signed message received from the authentication partner with the device public key included in the device certificate received from the authentication partner in a random challenge (step S2801).

Next, the device calculates the encryption key based on the secret data shared with the authentication partner by the EC-DH key exchange algorithm through the exchange of the EC-DH key exchange first phase value or the authentication key Kath (step S2802). ..

Next, the device decrypts the CA electronic signature for the encrypted model ID and the manufacturer name included in the response from the authentication partner to the signed message transmitted by itself (step S2803).

Then, the device verifies the authenticity of the CA electronic signature for the manufacturer name using the CA public key of the certificate authority, and verifies the authenticity of the manufacturer name in the model ID based on the CA electronic signature for the manufacturer name. (Step S2804). Here, if the verification of the authenticity of the manufacturer name fails (No in step S2805), the device aborts the authentication process at this point to exclude the authentication partner.

If the authenticity of the manufacturer name is successfully verified (Yes in step S2805), the device checks whether the model ID decoded in step S2803 is not included in the SRM exclusion target list (step S2806). ).

Then, if the model ID is not found in the exclusion target list (No in step S2807), the device continues the authentication process with the authentication partner. On the other hand, when the model ID is found in the exclusion target list, the device aborts the authentication process at this point so as to exclude the authentication partner.

Even if a manufacturer other than the licensee (non-licensey) tries to operate the model ID using an arbitrary manufacturer name, the CA electronic signature for the manufacturer name cannot be obtained. Therefore, in the authentication procedure shown in FIGS. 27 and 28, the authenticity of the CA electronic signature for the manufacturer name cannot be successfully verified, and the authentication partner reliably excludes the device including such a model ID. be able to.

The techniques disclosed in the present specification have been described in detail with reference to the specific embodiments. However, it is self-evident that a person skilled in the art can modify or substitute the embodiment without departing from the gist of the technique disclosed herein.

Although the present specification has mainly described embodiments in which the technology disclosed in the present specification is applied to a network of DTCP specifications, the gist of the technology disclosed in the present specification is not limited thereto.

In short, the techniques disclosed in this specification have been described in the form of examples, and the contents of the present specification should not be interpreted in a limited manner. In order to determine the gist of the technology disclosed in this specification, the scope of claims should be taken into consideration.

The technology disclosed in the present specification can also have the following configuration.
(1) With the communication unit that communicates with the authentication partner
A control unit that controls the authentication process based on information transmitted to and received from the authentication partner via the communication unit.
A holding unit that holds identification information common to common products with implementations related to a given function,
Equipped with
The control unit causes the authentication partner to transmit the identification information for which falsification prevention measures have been taken during the authentication process.
Authentication device.
(2) The control unit causes the authentication partner to transmit the identification information protected by a signature by a certificate authority.
The authentication device according to (1) above.
(3) The holding unit holds a device certificate that includes the identification information and is protected by a signature by a certificate authority.
The control unit causes the authentication partner to transmit the device certificate.
The authentication device according to (2) above.
(4) The holding unit holds a second certificate that includes the identification information and is protected by a signature by a certificate authority, which is different from the device certificate.
The control unit causes the authentication partner to send the second certificate.
The authentication device according to (2) above.
(5) The holding unit further holds a device certificate including at least the device public key and a device private key corresponding to the device public key.
The control unit causes the authentication partner to send a message including the identification information and protected by a signature by the device private key.
The authentication device according to (1) above.
(6) The holding unit further holds the manufacturer's private key and the manufacturer's certificate issued for each manufacturer.
The control unit causes the authentication partner to send a second certificate including the identification information and protected by a signature by the manufacturer's private key together with the manufacturer's certificate.
The authentication device according to (1) above.
(7) The control unit causes the authentication partner to transmit the identification information in the phase of exchanging the device certificate with the authentication partner during the authentication process.
The authentication device according to any one of (2) to (4) and (6) above.
(8) The holding unit is a second device that includes a device certificate including information indicating that it is incorporated in a component, an identification information, and information associated with the device certificate, and is protected by a signature with a predetermined private key. Hold the certificate of
The control unit causes the authentication partner to transmit the device certificate and the second certificate.
The authentication device according to (1) above.
(9) The device certificate includes a device ID of a component used in the authentication device, and the second certificate includes information in a range of valid device ID values.
The authentication device according to (8) above.
(10) An authentication method in which an authentication process is performed based on information sent and received by an authentication device with an authentication partner.
A step of taking measures to prevent falsification of the identification information held by the authentication device and having a common implementation related to a predetermined function in a common product.
A step of transmitting the identification information for which falsification prevention measures have been taken to the authentication partner, and
Authentication method with.
(11) With the communication unit that communicates with the authentication partner
A control unit that controls the authentication process based on information transmitted to and received from the authentication partner via the communication unit.
A holding unit that holds a list of identification information that is common to products that are common to implementations related to a given function and are excluded.
Equipped with
At the time of the authentication process, the communication unit receives the identification information for which falsification prevention measures have been taken from the authentication partner, and receives the identification information.
The control unit verifies the authenticity of the received identification information and checks whether it is present in the list.
Authentication device.
(12) The communication unit receives the identification information of the authentication partner protected by the signature by the certificate authority, and receives the identification information.
The control unit verifies the authenticity of the identification information with the public key of the certificate authority and checks the list.
The authentication device according to (11) above.
(13) The communication unit receives the device certificate including the identification information of the authentication partner and protected by the signature by the certificate authority.
The control unit verifies the authenticity of the device certificate with the public key of the certificate authority and checks the identification information included in the device certificate in the list.
The authentication device according to (12) above.
(14) The communication unit receives from the authentication partner a second certificate that includes identification information and is protected by a signature by a certificate authority, which is different from the device certificate of the authentication partner.
The control unit verifies the authenticity of the second certificate with the public key of the certificate authority and checks the identification information included in the second certificate in the list.
The authentication device according to (12) above.
(15) The communication unit receives from the authentication partner a device certificate including at least the device public key of the authentication partner and a message including identification information and protected by a signature with the device private key corresponding to the device public key. And
The control unit verifies the authenticity of the received message with the device public key and checks the identification information included in the message in the list.
The authentication device according to (11) above.
(16) The communication unit includes a second certificate including identification information and protected by a signature with a manufacturer's private key issued to the manufacturer of the authentication partner, and a manufacturing issued to the manufacturer of the authentication partner. Receive the person certificate from the authentication partner
The control unit verifies the authenticity of the received second certificate with the manufacturer's public key included in the manufacturer's certificate, and checks the identification information included in the second certificate in the list. ,
The authentication device according to (11) above.
(17) The communication unit receives identification information from the authentication partner in the phase of exchanging the device certificate with the authentication partner during the authentication process.
The authentication device according to any one of (12) to (14) and (16) above.
(18) The communication unit includes a device certificate of the authentication partner including information indicating that it is incorporated in a component, an identification information of the authentication partner, and information associated with the device certificate, and a predetermined private key. Received a second certificate protected by a signature by
The control unit verifies the authenticity of the device certificate and the second certificate, and checks whether the second certificate is associated with the device certificate.
The authentication device according to (11) above.
(19) The communication unit receives the device certificate including the device ID of the component used for the authentication partner and the second certificate including information in the range of the valid device ID value from the authentication partner. ,
The control unit confirms that the device ID included in the device certificate is within the range of the device ID value included in the second certificate.
The authentication device according to (18) above.
(20) An authentication method in which an authentication process is performed based on information sent and received by an authentication device with an authentication partner.
The authentication device holds a list of identification information that is common to products that are commonly implemented for a predetermined function and are excluded.
The step of receiving the identification information for which falsification prevention measures have been taken from the authentication partner, and
Steps to verify the authenticity of the received identification information,
A step to check if the received identification information exists in the list, and
Authentication method with.
(21) The identification information includes at least the manufacturer name unique to each applicable product manufacturer and the model model number information assigned to each manufacturer so as not to be duplicated.
The authentication device according to any one of (1) to (9) and (11) to (19) above.
(22) The identification information further includes information regarding the version of the corresponding product model.
The authentication device according to (21) above.
(23) The identification information further includes information regarding when the version of the corresponding product model is available.
The authentication device according to (22) above.
(24) The holding unit holds the identification information consisting of a first part, a second part, and a signature of the first part by a certificate authority.
At the time of the authentication process, the control unit encrypts the identification information and causes the authentication partner to transmit the identification information.
The authentication device according to (1) above.
(25) The control unit encrypts the identification information using data shared in the process of generating an authentication key with the authentication partner or an encryption key calculated based on the authentication key.
The authentication device according to (24) above.
(26) The control unit causes the encrypted identification information to be transmitted in response to receiving the signed message from the authentication partner.
The authentication device according to any one of (24) and (25) above.
(27) The control unit transmits the encrypted identification information by a command transmitted after exchanging a signed message with the authentication partner.
The authentication device according to any one of (24) and (25) above.
(28) The holding unit holds the list of the second part of the identification information including the first part and the second part.
At the time of the authentication process, the communication unit receives the identification information and the information in which the signature of the first part by the certificate authority is encrypted from the authentication partner.
The control unit decrypts the encrypted information, verifies the authenticity of the first part of the identification information based on the signature, and does not have the second part of the identification information in the list. Check if
The authentication device according to (11) above.
(29) The control unit performs the decryption using the data shared in the process of generating the authentication key with the authentication partner or the encryption key calculated based on the authentication key.
The authentication device according to (28) above.
(30) The communication unit receives the encrypted information in response to the signed message transmitted to the authentication partner.
The authentication device according to any one of (28) and (29) above.
(31) The communication unit receives the encrypted information by a command received after exchanging a signed message with the authentication partner.
The authentication device according to any one of (28) and (29) above.
(32) The first part consists of information that is immutable in the manufacturer of the product, and the second part consists of variable information.
The authentication device according to any one of (24) to (31) above.

101, 1401, 1601, 1901, 2101 ... Transmitting device 102, 1402, 1602, 1902, 2102 ... Receiving device

Claims (10)

The communication unit that communicates with the receiving device ,
A control unit that controls authentication processing based on information transmitted to and received from the receiving device via the communication unit.
Equipped with
At the time of the authentication process, the control unit controls the receiving device to transmit a message describing identification information including device information and manufacturer information common to the implementation.
Authentication device. The communication unit that communicates with the receiving device,
A control unit that controls authentication processing based on information transmitted to and received from the receiving device via the communication unit.
A holding unit that holds a list of device information that is commonly implemented in the exclusion target,
Equipped with
During the authentication process
The communication unit receives a message from the receiving device that describes identification information including device information and manufacturer information that are commonly mounted.
The control unit verifies the authenticity of the received manufacturer's information and checks whether the received device information of a common implementation exists in the list.
Authentication device. A communication unit that communicates with a receiving device that receives content,
A control unit that controls the authentication process based on information transmitted to and received from the receiving device via the communication unit, and encrypts and transmits the content when the authentication is successful.
Equipped with
During the authentication process
The control unit controls the receiving device to send a message containing identification information including device information and manufacturer information common to the implementation.
Content transmitter. A communication unit that communicates with a receiving device that receives content,
A control unit that controls the authentication process based on information transmitted to and received from the receiving device via the communication unit, and encrypts and transmits the content when the authentication is successful.
A holding unit that holds a list of device information that is common to the implementations in the exclusion target,
Equipped with
During the authentication process
The communication unit receives a message from the receiving device that describes identification information including device information and manufacturer information that are commonly mounted.
The control unit verifies the authenticity of the received manufacturer's information and checks whether the received device information of a common implementation exists in the list.
Content transmitter. When the information of the device common to the received implementations exists in the list, the control unit controls so as not to transmit the contents as if the authentication process has failed.
The content transmitting device according to claim 4. The content is ultra-high resolution content.
The content transmitting device according to any one of claims 3 to 5. The device information having a common mounting includes model number information that identifies a device having a common mounting.
The content transmitting device according to any one of claims 3 to 6. The message includes a device certificate having the device public key of the receiving device.
The content transmitting device according to any one of claims 3 to 7. The message is protected by a signature with the device private key of the receiving device corresponding to the device public key.
The content transmitting device according to claim 8. Before SL control unit, said verifies the signature of authenticity, is controlled so as not to transmit the content upon failure to the verified using equipment public key of the receiving device,
The content transmitting device according to claim 9.

Images