JPWO2018012078A1 - Authentication device and authentication method - Google Patents

Authentication device and authentication method Download PDF

Info

Publication number
JPWO2018012078A1
JPWO2018012078A1 JP2017016093A JP2018527402A JPWO2018012078A1 JP WO2018012078 A1 JPWO2018012078 A1 JP WO2018012078A1 JP 2017016093 A JP2017016093 A JP 2017016093A JP 2018527402 A JP2018527402 A JP 2018527402A JP WO2018012078 A1 JPWO2018012078 A1 JP WO2018012078A1
Authority
JP
Japan
Prior art keywords
device
authentication
certificate
model
identification information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2017016093A
Other languages
Japanese (ja)
Inventor
中野 雄彦
雄彦 中野
Original Assignee
ソニー株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to JP2016139766 priority Critical
Priority to JP2016139766 priority
Priority to JP2016208879 priority
Priority to JP2016208879 priority
Application filed by ソニー株式会社 filed Critical ソニー株式会社
Priority to PCT/JP2017/016093 priority patent/WO2018012078A1/en
Publication of JPWO2018012078A1 publication Critical patent/JPWO2018012078A1/en
Application status is Pending legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44Program or device authentication
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/64Protecting data integrity, e.g. using checksums, certificates or signatures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communication
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communication including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials

Abstract

Use the exclusion list to efficiently eliminate all products that implement the same. The authentication apparatus includes a communication unit for communicating with an authentication party, a control unit for controlling an authentication process based on information transmitted to and received from the authentication party via the communication unit, and a common implementation related to a predetermined function. A holding unit for holding identification information is provided. Then, the control unit causes the authentication party to transmit the identification information protected by the signature by the certificate authority to the authentication party, and transmits the identification information for which tampering prevention measures have been taken to the authentication party during the authentication process.

Description

  The technology disclosed in the present specification relates to an authentication device and an authentication method that perform authentication processing based on a predetermined standard, and more particularly to an authentication device and an authentication method that use an exclusion target list.

  In a system for transmitting content, in order to appropriately 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 using a key based on the information to be shared. Has been done. By ensuring that only the licensee who has a contract to properly protect the content can obtain the information necessary for the authentication process, the appropriate protection of the content is sufficient as long as the licensee manufactures a device that meets the contract requirements. To be realized.

  Digitized content is relatively easy to perform unauthorized operations such as copying and falsification. For this reason, when transmitting content between devices, it is strongly demanded, among other things, that the content provider properly protect the transmitted content.

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

  In addition, by allowing only the licensee who has a contract to appropriately protect the content to obtain the necessary information for the authentication process, the content is appropriate as long as the licensee produces a device that meets the contract requirements. Protection is realized.

  If a licensee or non-licensee produces an unauthorized device that does not meet the content protection regulations, it is necessary to eliminate the unauthorized device in order to prevent the leakage of the content. Specifically, in authentication processing between devices, when it is found that the authentication partner is an unauthorized device, it is conceivable to interrupt authentication and prevent content transmission from occurring.

  Currently, copyright protection technologies such as DTCP and High-bandwidth Digital Content Protection (HDCP) define a System Renewability Message (SRM) to transmit information on devices identified as unauthorized devices (for example, a patent). See literature 2). The licensor issues an SRM containing a list of device IDs of unauthorized devices. Then, each valid device refers to the SRM at the time of authentication, and interrupts the authentication process when the device ID received from the device of the authentication counterpart is included in the SRM. In this way, since the device indicated by the SRM is excluded at the time of authentication, the device identified as an unauthorized device is excluded from the system for transmitting content.

  Note that the device ID is generally included in a device certificate with a digital signature provided by the licensor to the licensee, so that tampering prevention and forgery by a non-licensee are prevented. The device certificate is incorporated into the product by the licensee and passed to the certification party during the certification process (described later).

JP, 2015-103890, A JP 2005-45641 A

  An object of the technology disclosed in the present specification is to provide an authentication device and an authentication method that perform an authentication process based on a predetermined standard.

The technology disclosed in the present specification is made in consideration of the above problems, and the first aspect thereof is
A communication unit that communicates with the authentication party;
A control unit that controls an 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 products having a common implementation regarding a predetermined function;
Equipped with
The control unit causes the authentication party to transmit the identification information for which tampering prevention measures have been taken during the authentication process.
It is an authentication device.

  According to a second aspect of the technology 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 counterpart. It is done.

  According to a third aspect of the technology disclosed in the present specification, the holding unit of the authentication device according to the second aspect holds the 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 party.

  According to a fourth aspect of the technology disclosed in the present specification, the holding unit of the authentication device according to the second aspect includes the identification information other than the device certificate and is protected by a signature by a certificate authority A second certificate is held, and the control unit is configured to transmit the second certificate to the authentication party.

  According to a fifth aspect of the technology disclosed in the present specification, the holding unit of the authentication device according to the first aspect includes a device certificate including at least a device public key, and a device secret corresponding to the device public key. A key is further held, and the control unit is configured to transmit the message protected by the signature using the device secret key including the identification information to the authentication counterpart.

  According to a sixth aspect of the technology disclosed in the present specification, the holding unit of the authentication device according to the first aspect further holds a manufacturer private key and a manufacturer 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 private key to the authentication counterpart along with the manufacturer certificate.

  According to a seventh aspect of the technology disclosed in the present specification, the control unit of the authentication device according to the second aspect performs the identification information in the phase of exchanging a device certificate with the authentication partner in the authentication process. Are sent to the authentication party.

  According to an eighth aspect of the technology disclosed in the present specification, the holding unit of the authentication device according to the first aspect includes a device certificate including information indicating that it is incorporated into a component, and the identification information. The second certificate protected by the signature with a predetermined secret key including the information to be associated with the device certificate is held, and the control unit uses the device certificate and the second certificate as the authentication party. It is configured to be sent.

  According to a ninth aspect of the technology disclosed in the specification, in the authentication device according to the eighth aspect, the device certificate includes a device ID of a component used for the authentication device, and the second certificate Contains information on the range of valid device ID values.

Further, a tenth aspect of the technology disclosed in the present specification is
An authentication method for performing an authentication process based on information that an authentication device exchanges with an authentication party,
Taking steps to prevent tampering with identification information common to products having a common implementation related to a predetermined function held by the authentication device;
Transmitting the identification information for which tampering prevention measures have been taken to the authentication party;
Authentication method.

In addition, an eleventh aspect of the technology disclosed in the present specification is
A communication unit that communicates with the authentication party;
A control unit that controls an 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 common to products to be excluded that are common to implementations regarding a predetermined function, and
Equipped with
At the time of the authentication process, the communication unit receives, from the authentication party, identification information for which a measure to prevent tampering has been taken;
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 a twelfth aspect of the technology disclosed in the present specification, the communication unit of the authentication device according to the eleventh aspect receives identification information of the authentication partner protected by a signature by a certificate authority, and the control The unit is configured to verify the authenticity of the identification information with the public key of the certificate authority and to check the list.

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

  According to a fourteenth aspect of the technology disclosed in the present specification, the communication unit of the authentication device according to the twelfth aspect includes identification information other than the device certificate of the authentication partner and is signed by a certificate authority Receiving the second certificate protected by the authentication certificate from the authentication party, and the control unit verifies the authenticity of the second certificate with the public key of the certificate authority and is included in the second certificate The identification information to be checked is configured to be checked in the list.

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

  According to a sixteenth aspect of the technology disclosed in the present specification, the communication unit of the authentication device according to the eleventh aspect includes a signature and a manufacturer's private key issued to a manufacturer of the authentication partner, including identification information. A second certificate protected by the second party certificate and a manufacturer certificate issued to the manufacturer of the second party from the second party, and the control unit determines the authenticity of the second certificate received. The verification is performed using the manufacturer public key included in the manufacturer certificate and the identification information included in the second certificate is checked in the list.

  According to a seventeenth aspect of the technology disclosed in the present specification, the communication unit of the authentication apparatus according to the twelfth aspect exchanges the device certificate with the authentication partner during the authentication process. Are configured to receive identification information from

  According to an eighteenth aspect of the technology disclosed in the specification, the communication unit of the authentication device according to the eleventh aspect includes a device certificate of the authentication partner including information indicating that the communication device has been incorporated into a component. A second certificate is received that includes identification information of the authentication party and information associated with the device certificate, and is protected by a signature with a predetermined secret key, and the control unit receives the device certificate and the second certificate. And verify that the second certificate is associated with the device certificate.

  According to a nineteenth aspect of the technology disclosed in the present specification, the communication unit of the authentication device according to the eighteenth aspect includes the device certificate including a device ID of a component used as the authentication partner, and The second certificate including information on a range of device ID values is received from the authentication party, 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.

Also, a twentieth aspect of the technology disclosed in the present specification is
An authentication method for performing an authentication process based on information that an authentication device exchanges with an authentication party,
The authentication device holds a list of identification information common to the products to be excluded and common to the implementation regarding a predetermined function,
Receiving from the authentication party identification information for which a tampering prevention measure has been taken;
Verifying the authenticity of the received identification information;
Checking whether the received identification information is present in the list;
Authentication method.

  According to a twenty-first aspect of the technology disclosed in the specification, in the authentication device according to the first aspect, the identification information is assigned so as not to be duplicated in each maker with a unique maker name for each corresponding product maker. It contains at least the information of the identified model number.

  According to a twenty-second aspect of the technology disclosed in the specification, in the authentication device according to the twenty-first aspect, the identification information further includes information on a version of a corresponding product model.

  According to a twenty-third aspect of the technology disclosed in the specification, in the authentication device according to the twenty-second aspect, the identification information further includes information on provision time of the version of the corresponding product model.

  According to the technology disclosed in the present specification, when performing authentication processing based on a predetermined standard, it is possible to provide an excellent apparatus and authentication method capable of suitably excluding an unauthorized device by using an exclusion target list. 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 to the effects described above, the present invention may exhibit additional effects.

  Other objects, features, and advantages of the technology disclosed herein will be apparent from the more detailed description based on the embodiments described below and the accompanying drawings.

FIG. 1 is a diagram schematically showing the communication flow of a full authentication protocol defined by DTCP. FIG. 2 is a diagram showing a device certificate, a device private key, and a CA public key held by a device that performs authentication processing. FIG. 3 is a diagram showing the packet format of the SRM. FIG. 4 is a diagram showing a configuration example of a 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 a model ID. FIG. 7 is a diagram showing a configuration example of a device certificate into which a model ID is inserted. FIG. 8 is a diagram showing a configuration example of a model certificate protected by a digital signature by a certificate authority. FIG. 9 is a diagram showing a configuration example of a message including a model ID and to which an electronic signature by the device secret key is added. FIG. 10 is a diagram showing a configuration example of a model ID protected by an electronic signature with a manufacturer private key issued to a licensee and a manufacturer 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 of a range of device ID values. FIG. 13 is a diagram showing another configuration example of the model certificate including the information of the range of the device ID value. 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 remove 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 the mechanism of excluding all devices of the same model. FIG. 17 is a flowchart showing a processing procedure for determining whether or not to remove 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 remove 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 the mechanism of excluding all the devices of the same model. FIG. 20 is a flowchart showing a processing procedure for determining whether or not to remove 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 remove the authentication partner based on the model ID contained in the model certificate of the authentication partner. FIG. 23 is a flowchart showing another processing procedure for determining whether or not to remove the authentication partner based on the model ID contained 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 with respect to a manufacturer name. FIG. 25 is a diagram showing a configuration example of a model ID with a CA electronic signature with respect to a manufacturer name. FIG. 26 is a diagram showing a configuration example of a model ID with a CA electronic signature with respect to a manufacturer name. FIG. 27 is a diagram showing another example of the communication flow of the authentication protocol including the mechanism of excluding all devices of the same model. FIG. 28 is a flowchart showing a processing procedure for determining whether or not to remove the authentication partner based on the model ID included in the signed message of the authentication partner.

  Hereinafter, embodiments of the technology disclosed herein will be described in detail with reference to the drawings.

  In the copyright protection technology such as DTCP, content protection is performed by specifying the mechanism for performing authentication processing between the transmitting device and the receiving device and encrypting the content with a key based on the information to be shared as a result. It has been realized. Also, in DTCP, SRM is defined to transmit information on devices identified as unauthorized devices, and devices indicated by SRM are excluded at the time of authentication.

  FIG. 1 schematically shows a communication flow of an authentication protocol performed between a transmitting device (device A) 101 for performing content transmission and a receiving device (device B) 102 defined by DTCP. The transmitting device 101 mentioned here corresponds to "Source", and the receiving device 102 corresponds to "Sink". The transmitting device 101 and the receiving device 102 can communicate via a network (not shown). Further, the communication flow shown in FIG. 1 corresponds to a Full Authentication protocol corresponding to the contents of all copy management information defined by DTCP, and public key encryption 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 authentication processing is performed according to the protocol shown in FIG. There is.

  The device certificate 210 includes at least a device ID unique to the device indicated by reference numeral 211 (device identification is unique) and a device public key indicated by reference numeral 212, and these informations (shaded in FIG. (Certificate Authority (CA)) electronic signature 213 for The device secret key 220 is a secret key corresponding to the device public key included in the device certificate 210. Also, the CA public key 230 is held to verify the device certificate of the authentication counterpart.

  Usually, the licensor issues the device certificate 210 and the device secret key 220 corresponding to the device public key 212 included in the device certificate for each device, and distributes it to the maker of the device who is the licensee. Then, the manufacturer embeds the device certificate 210, the device secret key 220, and the CA public key 230 in each device (for example, the transmitting device 101 serving as the Source and the receiving device 102 serving as the Sink) manufactured in-house. Therefore, the manufacturer of the device needs to obtain the device certificate 210 for the number of devices 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 that includes an exclusion target list (Certificate Revocation List: CRL). The transmitting device 101 and the receiving device 102 update their own information each time they receive a new version of the SRM from the authentication party.

  The process 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 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) in response to a command for sending this random challenge, but 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 integrity of the device certificate B using the CA public key of the certificate authority. . If the verification of authenticity fails, the authentication process is aborted at this point.

  Also, the transmitting device 101 extracts the device ID of the receiving device 102 from the device certificate B, and checks whether it is in the exclusion target list of SRM (Examine SRM). If 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 transmission device 101 succeeds in verifying the authenticity of the device certificate B, and when the device ID of the reception device 102 is not included in the exclusion target list, the random number and the transmission device 101 A random challenge including a device certificate A (device A certificate) is sent to the receiving device 102 (P112), and the authentication process is continued. Although the receiving device 102 returns a response (RSP) to the command for sending the random challenge, it is not shown in FIG.

  The receiving device 102 similarly verifies the integrity of the device certificate A received from the transmitting device 101 (Verify A's device certificate), and the device of the transmitting device 101 extracted from the device certificate A. Check if the ID is not in the exclusion list of SRM (Examine SRM).

  When the transmitting device 101 succeeds in verifying the authenticity of the device certificate B and checking the SRM, information for sharing a 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. Also, when the verification of the authenticity of the device certificate A and the SRM check succeed, the receiving device 102 also calculates information (EC-DH key exchange first phase value) B for sharing a key with the transmitting device 101.

  Next, the transmitting device 101 calculates 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 the random challenge (P111). And the like, to the receiving device 102 a message with a signature in which the electronic signature by the device private key of the transmitting device 101 itself is added to the information including the information (P113a). Although the receiving device 102 returns a response (RSP) in response to a command for sending this signed message, it is not shown in FIG.

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

  When the reception device 102 fails in the verification of the signed message of the transmission device 101, the reception device 102 rejects the continuation of the authentication process. On the other hand, when the receiving device 102 succeeds in verifying the signed message of the transmitting device 101, the receiving device 102 receives the information A for key sharing received from the transmitting device 101 and the information B for the key sharing calculated by itself. The authentication key (Kauth) is calculated based on both (Compute Auth key).

  The receiving device 102 then calculates 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 the random challenge (P112). , And the like, and transmits a signed message in which the electronic signature by the device private key of the receiving device 102 itself is added to the information including the etc. to the transmitting device 101 (P113 b). Although the transmitting device 101 returns a response (RSP) in response to the command for sending the signed message, it is not shown in FIG.

  On the transmitting device 101 side, the signed message received from the receiving device 102 is not falsified using the device public key included in the device certificate B received from the receiving device 102 by the random challenge (P111). Verify whether or not. The transmitting device 101 may also check the version number of the SRM and call the SRM updating process thereafter.

  When the transmission device 101 fails in the verification of the signed message of the reception device 102, the transmission device 101 rejects the continuation of the authentication process. On the other hand, when the transmitting device 101 succeeds in verifying the signed message of the receiving device 102, the transmitting device 101 receives the information B for key sharing received from the receiving device 102 and the information A for the key sharing calculated by itself. Based on both of them, an authentication key (Kauth) having the same value as that calculated at the receiving device 102 side is calculated (Compute Auth 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 using the encryption key shared based on the authentication key, the copyright protection is performed. Encrypted transmission of the content can be implemented. However, in DTCP, the valid period of the authentication key is defined, and the encrypted transmission of the content using the PIN key based on the same authentication key is limited to the valid period of the authentication key.

  In the copyright protection technology such as DTCP and HDCP, SRM is defined to transmit information of devices identified as unauthorized devices (described above). FIG. 3 shows the current SRM packet format (first generation (before update) packet format). In the figure, a CRL entry (CRL Entries) is a list of devices recognized as unauthorized devices (Certificate Revocation List). The CRL length (CRL Length) indicates the size of a CRL including the CRL Length field, the CRL Entries field, and the DTLA signature (DTLA signature) field. Also, the version number (Version Number) consists 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 owned by the device, and when the received SRM is newer, updates the own information by the received SRM. In this way, the devices can share the list of device IDs of fraudulent devices to be excluded. Incidentally, the SRM can be exchanged between devices at the time of authentication processing.

  With the spread of ultra high definition (UHD) content called 4K and 8K in the future, the need for security enhancement in copyright protection technology is increasing more and more. Specifically, if a product is found to be fraudulent (or if it does not meet the requirements for copyright protection technology such as DTCP or HDCP), it is not enough to just remove a specific device, and the same implementation is performed. There is a strong demand to eliminate all products (ie all products of the same model). In the following, products that implement the same (or have a common implementation) will be referred to as the same "model".

  In the current SRM, it is necessary to register an individual device ID for each device to be excluded in the CRL Entries. To exclude all devices of the same model, all device IDs of the corresponding devices must be registered in the SRM. In the case of a mass-produced model, the amount of information registered in the SRM can be enormous, and there is also the possibility that the information does not fit within the predetermined upper limit size of the SRM.

  For example, if consecutive device IDs are allocated to devices of the same model, the device ID of the top of the model and the last device ID of the model to be excluded must be registered in SRM, and the devices to be authenticated are in the range The amount of information registered in the SRM can be reduced by performing an operation of excluding all the devices having the device ID value in the inside. However, when the device IDs of devices of the same model do not continue, the individual device IDs must be registered, and as described above, there is a possibility that they will not fit within the predetermined upper limit size of SRM, and registration with SRM Is difficult.

  Manufacturers may produce multiple models in parallel at the same time. If the models support the same copyright protection technology, the licensor issues a device certificate for each device to the manufacturer who is the licensee. Here, even if the licensor issues a device certificate so that the device ID is continuous to one licensee, the licensee makes the device ID of the device certificate incorporated in one model continuous by the maker who is the licensee. It is difficult. And when it becomes necessary to exclude all devices for any of the models, it may be difficult to register in SRM as described above.

  In order to make equipment IDs included in equipment certificates that licensees incorporate into products of the same model continuous, equipment certificates must be obtained in advance from the licensor as equipment IDs for the number of products manufactured or shipped from the model. You must. In the case where products of a plurality of models are manufactured in parallel at the same time, it is necessary to obtain, from the licensor in advance, a device certificate in which device IDs of only a required number of units continue for each model. If the manufacturing plan (the number of manufactured models) is changed, there is a risk that the device certificate will not be sufficient or will be left.

  Therefore, in this specification, one model ID should be assigned to a product having a common implementation relating to a predetermined function, ie, the same model, and should be excluded from the SRM (in addition to the device ID of the unauthorized device to be excluded). We propose a technology to enable registration of model ID of model. Each device passes its own model ID to the authentication partner during the authentication process, and interrupts the authentication if the authentication partner's model ID is found in the SRM, thereby all the devices of the same model. Can be eliminated (that is, even fraudulent equipment can be eliminated on a model basis). The manufacturer does not need to ensure the continuity of the device ID for the same model by incorporating the corresponding model ID into each device of the same model. In other words, even if the device ID of the device of the same model is discontinuous, it is possible to exclude all the devices of the same model only by registering a small amount of information called the model ID in the SRM.

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

  In the example shown in FIG. 4, the model ID is configured by a combination of a maker name of a product and a model model number. For example, the licensor centrally manages manufacturer names so that manufacturer names do not overlap among different manufacturers. In addition, each maker assigns a model model number to an own product model so as not to be duplicated.

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

  Further, in the example shown in FIG. 6, the model ID is configured by adding the provision time of the product model version together with the model version number. In very rare cases, it is assumed that there is an error in the version number due to a manufacturing mistake or the like (for example, the version number is not updated even though the model has been upgraded, or for a new model version Old version numbers are assigned). By adding the version number and the distribution date to the model ID, it is possible to cover the error of the version number. In this case, for example, it is possible to specify a model of a product to be excluded by a combination of a model model number and a provision time.

  In addition, in order to ensure the uniqueness of a model, you may further add the other information which is not illustrated about the structural example of each model ID shown to FIGS.

  Next, consider how the device passes the model ID to the authentication partner. Anti-tampering measures should be taken when passing the model ID to the certified party in order to ensure that the fraudulent product is eliminated.

  Specifically, (1) a method of protecting a model ID by an electronic signature by a licensor or a certificate authority, or (2) an electronic signature by a secret key issued to a licensee by a licensor as a method of preventing falsification of the model ID. Methods to protect the model ID. In either method, the authentication partner can verify the authenticity of the model ID by performing signature authentication with the public key issued by the licensor or the certificate authority.

  First, (1) as a method of protecting a model ID by an electronic signature by a licensor or a certificate authority, (1a) a method of inserting a model ID in a device certificate and transmitting it to an authentication party, and (1b) a device certificate Another possible method is to transmit it to the certification party in the form of a model certificate (Model Certificate) accompanied by the digital signature of the certification authority.

  FIG. 7 schematically shows a configuration example of the device certificate 700 into which a 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 indicated by reference numeral 701 (device identification uniquely), a device public key indicated by reference numeral 702, and a model ID indicated by reference numeral 703. It is accompanied by the CA digital signature 704 of the certification authority for the information (the shaded portion in the figure). The authentication party having received the device certificate 700 verifies the authenticity of the device certificate 700 using the CA public key, and performs SRM check on 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 a model certificate 800 protected by an electronic signature by the certificate authority, which is used in the method (1b). In the model certificate 800, a CA electronic signature 802 by a certificate authority is added to information (a shaded portion in the figure) including at least a common model ID in the same model indicated by reference numeral 801. The authentication party having received the model certificate 800 can verify the authenticity of the model certificate 800 using the CA public key, and can perform SRM check on the model ID 801 extracted from the model certificate 800.

  If the model ID is included in the device certificate according to the method of (1a), the device certificate can only be used for a specific model. For this reason, if the licensee maker lacks a model of the device certificate, the licensee does not use the device certificate acquired from the licensor for another model. In addition, when there is a device certificate acquired for a certain model, it can not 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), it is possible to secure the freedom of using the device certificate acquired from the licensor for any model device.

  (2) As a method of protecting the model ID by the electronic signature by the private key issued by the licensor to the licensee, (2a) a method of protecting the model ID by the electronic signature by the private key of the device issued by the licensor for each device. And (2b) the licensor issues a manufacturer private key and a manufacturer certificate to each licensee, and each licensee generates an electronic signature for the model ID with the respective manufacturer private key, along with the manufacturer certificate There is a conceivable way to send to the authentication partner.

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

  FIG. 9 shows an example of the configuration of a message 900 including a model ID and to which a digital signature by the device secret key is added, which is used in the method (2a). In the signed message 900, an electronic signature 902 by the device secret key for each device is added to information (a shaded portion in the figure) including the common model ID in the same model indicated by the reference numeral 901. . 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, received by random challenge from the authentication party Random numbers are included in the same message. The authentication party receiving the signed message 900 verifies the authenticity of the message 900 using the device public key included in the device certificate received from the message transmission source in the 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 a model ID protected by an electronic signature using a manufacturer private key and a manufacturer certificate, which are used in the method (2b). As indicated by reference numeral 1010, the model ID becomes a protected model certificate by adding the digital signature 1012 with 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 is accompanied by the information including the manufacturer public key 1021 corresponding to the manufacturer private key and the CA electronic signature 1022 by the certificate authority. The authentication partner who receives the model certificate 1010 protected by the electronic signature 1012 with the manufacturer 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 authenticate the manufacturer. The authenticity of the document 1020, and subsequently verify the authenticity of the model certificate 1010 using the manufacturer's public key 1021 contained in the manufacturer certificate 1020, and extract it from the information 1011 contained in the model certificate 1010. SRM can be checked for the selected model ID.

  Here, consider how to deal with the case where a non-licensee manufactures a fraudulent device. It can not be expected that an unauthorized manufacturer trying to manufacture an unauthorized device sets a model ID that includes information that leads to the elimination of the own product. In addition, the continuity of the device ID of the unauthorized device can not be expected as well, and it is difficult to eliminate it by the SRM in model units.

  Therefore, the present specification further proposes a technique for preventing unauthorized devices manufactured by a non-licensee from succeeding in authentication processing by a model certificate generated only by a licensee who is a legitimate manufacturer.

  It is not easy to identify the source of the leak when the device certificate issued by the licensor and the part incorporating the device private key are illegally flowed sideways and the non-licensee manufactures the unauthorized device using such parts Of particular concern because of the reason. The components referred to here correspond to, for example, semi-finished products such as circuit chips.

  In order to prevent unauthorized use of legitimate parts by non-licensees, a device certificate (CC) is provided with a CC (Component Certificate) flag indicating whether or not the part is issued for the part. Then, the licensor sets a CC flag (i.e., sets CC = 1) in the device certificate incorporated into the part such as a semi-finished product.

  In addition, the licensor makes it possible for equipment IDs to be continuous when delivering (sold) parts including such equipment certificates (provided with a CC flag) to a part vendor who is a licensee. And require the licensor to be notified of its ID value (or the range of legal device ID values used for such parts).

  In addition to the model ID, the licensor must include, within the model certificate, information on the range of valid device ID values as information to be associated with the device certificate for the manufacturer 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 at least includes a CC flag indicated by reference numeral 1101, a device ID indicated by reference numeral 1102, and a device public key indicated by reference numeral 1103. These pieces of information (shaded in the figure) With the digital signature 1104 of the certificate authority for

  Note that, as shown in FIG. 11, the device ID of the device certificate is divided and used without adding the special information of the CC flag in the device certificate, for example, when the device ID is a predetermined value P or more, If it is possible to determine whether the device certificate is for a semi-finished product based on the value of the device ID, for example, by using it for a finished product, the CC flag can be eliminated. In other words, the format of the information indicating that the device certificate is embedded in the part is not particularly limited.

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

  FIG. 13 shows another configuration example of the model certificate 1300 including the information of the range of the device ID value. The model certificate 1300 is common to the model certificate 1200 shown in FIG. 12 in that it includes at least a model ID indicated by reference numeral 1301 and information indicating a range of valid device ID values indicated by reference numeral 1302. is there. However, the model certificate 1300 shown in FIG. 12 is that the information of these (the shaded portion in the figure) is not the CA electronic signature of the certificate authority but the electronic signature 1303 by the manufacturer's private key. It is different from 1200. In the case of using the model certificate 1300 protected by the manufacturer's private key, it is necessary to transmit the manufacturer's certificate (see FIG. 10) together with the authentication party.

  The device that authenticates such a product checks whether the CC flag of the received device certificate is set or not, and if the CC flag is set, the device ID included in the device certificate Is further checked whether it is within the device ID value range specified in the model certificate. Then, if it can not 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 unauthorized device is an unauthorized device using a legitimate part of which the horizontal flow is performed If it exists, interrupt the authentication process.

  When using a device certificate with a CC flag set, imposing the authentication of a model certificate including information associated with the device certificate can make unauthorized use of the leaked component difficult. A non-licensee manufactures an unauthorized device that can be authenticated because it is difficult to obtain a model certificate that is associated with a device certificate even though it is possible to obtain a part incorporating a valid 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). The communication procedure is carried out basically in accordance with the full authentication protocol defined by DTCP. Also, in the illustrated authentication protocol, the method of inserting the model ID into the device certificate of (1a) and transmitting it to the authentication partner is applied, and both of the transmitting device 1401 and the receiving device 1402 are shown in FIG. It is assumed that the device certificate is held.

  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, and makes an authentication request (P1411). The transmitting device 1401 returns a response (RSP) in response to a command for sending this random challenge, but is not shown in FIG.

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

  Also, 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 exclusion target list of SRM. Details of the processing procedure for checking the model ID will be given 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 A random challenge including the letter A is returned to the receiving device 1402 (P1412), and the authentication process is continued. The receiving device 1402 returns a response (RSP) in response to a command for sending this random challenge, but illustration is omitted in FIG.

  Similarly, the receiving device 1402 verifies the authenticity of the device certificate A received from the transmitting device 1401, extracts the device ID and model ID of the transmitting device 1401 from the device certificate A, and transmits the device ID of the transmitting device 1401. And check whether the model ID is not included in the exclusion target list of SRM. Details of the processing procedure for checking the model ID will be given later. If the verification of the authenticity of the device certificate A fails, and 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, and the transmission device is sent. Try to eliminate 1401.

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

  Next, the transmitting device 1401 receives 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). And the like, to the receiving device 1402 a message with a signature in which the electronic signature by the device private key of the transmitting device 1401 is added is transmitted to the receiving device 1402 (P1413a). Although the receiving device 1402 returns a response (RSP) in response to the command for sending the signed message, it is not shown in FIG.

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

  If the reception device 1402 fails to verify the signed message of the transmission device 1401, the reception device 1402 rejects the continuation of the authentication process. On the other hand, when the receiving device 1402 succeeds in verifying the signed message of the transmitting device 1401, the receiving device 1402 receives the information A for key sharing received from the transmitting device 1401 and the information B for the key sharing calculated by itself. The authentication key (Kauth) is calculated based on both (Compute Auth key).

  Then, the receiving device 1402 calculates 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). And the like, and transmits a signed message to the transmitting device 1401 with an electronic signature added by the receiving device 1402's own device private key to the information including the information (P1413b). Although the transmitting device 1401 returns a response (RSP) in response to the command for sending the signed message, it is not shown in FIG.

  The transmitting device 1401 has not falsified 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 by the random challenge (P1411). Verify if. The transmitting device 1401 may also check the version number of the SRM and may call the SRM update process thereafter.

  When the transmission device 1401 fails to verify the signed message of the reception device 1402, the transmission device 1401 rejects the continuation of the authentication process. On the other hand, if the transmitting device 1401 succeeds in verifying the signed message of the receiving device 1402, the transmitting device 1401 receives the information B for key sharing received from the receiving device 1402 and the information A for the key sharing calculated by itself. Based on both of them, an authentication key (Kauth) having the same value as that calculated at the receiving device 1402 side is calculated (Compute Auth key).

  If the above authentication process is successfully completed, the transmitting device 1401 and the receiving device 1402 can share the authentication key (Kauth). Thereafter, the transmitting device 1401 and the receiving device 1402 can perform encrypted transmission of the copyright-protected content using the encryption key shared based on the authentication key. However, in DTCP, the valid period of the authentication key is defined, and the encrypted transmission of the content using the PIN key based on the same authentication key is limited to the valid period of the authentication key.

  FIG. 15 is a flowchart showing a processing procedure for the transmitting device 1401 and the receiving device 1402 to determine whether or not the authentication partner should be excluded based on the model ID included in the device certificate of the authentication partner. It shows by. However, in the illustrated procedure, it is assumed that the system uses the device certificate shown in FIG.

  The device verifies the device certificate received by random challenge from the authentication party 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 the model ID is present 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, if the model ID is found in the exclusion target list (Yes in step S1503), the authentication process is aborted (abort) to exclude the authentication partner.

  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" and 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 performed in accordance with the full authentication protocol defined by DTCP. Also, in the illustrated authentication protocol, a method of transmitting to the other party of authentication in the form of a model certificate accompanied by the electronic signature of the certificate authority other than the device certificate of (1b) is applied. Both the combination of the device certificate (including the model ID) 1602 and the model certificate shown in FIG. 8 or the device certificate (including the CC flag) shown in FIG. It is assumed that a combination of model certificates (including information on the range of device IDs) is held.

  First, the receiving device 1602 transmits a random challenge and a random challenge in which the model certificate B is added 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) in response to a command for sending this random challenge, but is not shown in FIG.

  The transmitting device 1601 verifies the authenticity of the device certificate B received from the receiving device 1602 using the CA public key of the certificate authority. If the verification of authenticity fails, the authentication process is aborted at this point. If it is confirmed that the device certificate B is authentic, 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, at this point, the authentication process is aborted so that the receiving device 1602 is excluded.

  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 verification of the authenticity fails, the authentication process is performed at this time. Abort (abort) Then, if it is confirmed that the model certificate B is authentic, 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 using a combination of the device certificate shown in FIG. 11 and the model certificate shown in FIG. 12, it is checked whether the model certificate is correctly linked to the device certificate. Specifically, the transmitting device 1601 checks the CC flag of the device certificate B in addition to the check of 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 for a part (semi-finished product), the device ID included in the device certificate B is indicated by the model certificate B. Check whether the range is a valid device ID value range, that is, whether model certificate B is associated with device certificate B. Details of the processing procedure for checking the model certificate linked to the device certificate will be given later. If it can not be confirmed that the model certificate B is linked to the device certificate B, it is known that the receiving device 1602 is a product using a component that has been flowed horizontally, so the transmitting device 1601 At this point, the authentication process is aborted so that the receiving device 1602 is excluded.

  Then, the transmitting device 1601 succeeds in verifying the authenticity of the device certificate B and the model certificate B, and when neither the device ID and the model ID of the receiving device 1602 are included in the exclusion target list, random numbers A random challenge including the model certificate A in addition to the device certificate A of the transmission device 1601 is returned to the reception device 1602 (P1612), and the authentication process is continued. The receiving device 1602 returns a response (RSP) in response to a command for sending this random challenge, but 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 is in the SRM exclusion target list. Details of the processing procedure for checking the model certificate will be given later. If verification of the authenticity 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 the sending device 1601.

  Further, in the case of a system using a combination of the device certificate shown in FIG. 11 and the model certificate shown in FIG. 12, it is checked whether the model certificate is properly linked to the device certificate. Specifically, the receiving device 1602 checks the CC flag of the device certificate A in addition to the check of 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 for a part (semi-finished product), the device ID included in the device certificate A is indicated by the model certificate A. At the same time, a check is made as to whether or not there is a valid device ID value range, that is, whether the model certificate A is linked to the device certificate A. Details of the processing procedure for checking the model certificate linked to the device certificate will be given later. If it can not be confirmed that the model certificate A is linked to the device certificate A, it is known that the transmitting device 1601 is a product using a component that has been flowed horizontally, so the receiving device 1602 At this point, the authentication process is aborted so that the transmitting device 1601 is excluded.

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

  Next, the transmitting device 1601 receives 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). And the like, to the receiving device 1602 a message with a signature in which the electronic signature by the device private key of the transmitting device 1601 is added is transmitted to the receiving device 1602 (P1613a). Note that the receiving device 1602 returns a response (RSP) in response to a command for sending this signed message, but illustration is omitted in FIG.

  Whether the receiving device 1602 has tampered with the signed message received from the transmitting device 1601 using the device public key included in the device certificate A received by the random challenge (P 1612) from the transmitting device 1601 Verify if. The receiving device 1602 may also check the version number of the SRM, and may call the SRM update process thereafter.

  If the reception device 1602 fails to verify the signed message of the transmission device 1601, the reception device 1602 rejects the continuation of the authentication process. On the other hand, if the receiving device 1602 succeeds in verifying the signed message of the transmitting device 1601, the receiving device 1602 receives the information A for key sharing received from the transmitting device 1601 and the information B for the key sharing calculated by itself. The authentication key (Kauth) is calculated based on both (Compute Auth key).

  The receiving device 1602 then calculates 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 (P 1612). And a digital signature of the receiving device 1602 with its own device private key is sent to the transmitting device 101 (P1613b). Although the transmitting device 1601 returns a response (RSP) in response to the command for sending the signed message, it is not shown in FIG.

  The transmitting device 1601 has not falsified 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 by random challenge (P 1611) Verify if. The transmission device 1601 may also check the version number of the SRM, and may call the SRM update process thereafter.

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

  If the above authentication process is successfully completed, the transmitting device 1601 and the receiving device 1602 can share the authentication key (Kauth). Thereafter, the transmitting device 1601 and the receiving device 1602 can perform encrypted transmission of the copyright-protected content using the encryption key shared based on the authentication key. However, in DTCP, the valid period of the authentication key is defined, and the encrypted transmission of the content using the PIN key based on the same authentication key is limited to the valid period of the authentication key.

  FIG. 17 is a flowchart showing a processing procedure for the transmitting device 1601 and the receiving device 1602 to determine whether or not the authentication partner should be excluded based on the model ID included in the model certificate of the authentication partner. It shows by. However, in the illustrated 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 random challenge from the authentication party with the CA public key of the certificate authority, and further verifies the model certificate received by the random challenge from the authentication party 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 eliminates the authentication partner.

  If the verification of the authenticity of the model certificate is successful (Yes in step S1702), then the device receives the model ID included in the model certificate in the CRL Entries field of the SRM that the device holds. 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, if the model ID is found in the exclusion target list (Yes in step S1704), the authentication process is aborted (abort) to exclude the authentication partner.

  Also, in FIG. 18, another processing procedure for the transmitting device 1601 and the receiving device 1602 to determine whether to 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 flow chart. 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 shown in FIG. 12 (including information associated with the device certificate). .

  The device verifies the device certificate received by the random challenge from the authentication party with the CA public key of the certificate authority, and further verifies the model certificate received by the random challenge from the authentication party 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 verification of the authenticity of the model certificate is successful (Yes in step S1802), then the device checks the CC flag of the device certificate (step S1803). Then, if the CC flag is set (Yes in step S1804), it is known that the device certificate under verification is the device certificate incorporated in the part (semi-finished product), so that the authentication partner continues to be It is checked whether or not the model certificate of (1) is linked to the device certificate of the authentication party (step S1805). Specifically, it is checked whether the device ID included in the device certificate is within the range of valid device ID values indicated in the model certificate. If the device certificate can not be confirmed as the model certificate linked to the device certificate (No in step S1806), the device aborts the authentication process and excludes the authentication partner.

  If the CC flag is not set and it is not the device certificate of the part (semi-finished product) (No in step S1804), and if it can be confirmed that it is the model certificate linked to the device certificate (Yes in step S1806), subsequently, the device has the model ID included in the exclusion target list stored in the CRL Entries field of the SRM that the device holds, as the model ID included in the model certificate. It is checked whether it is 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, if the model ID is found in the exclusion target list (Yes in step S1808), the authentication process is aborted (abort) to exclude the authentication partner.

  FIG. 19 schematically shows another example of the communication flow of the authentication protocol including the mechanism of 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 is performed in accordance with the full authentication protocol defined by DTCP. Also, in the illustrated authentication protocol, the method (2a) of protecting the model ID by the electronic signature by the device secret key issued by the licensor for each device is applied, and both the transmitting device 1901 and the receiving device 1902 are device certificates. And holding the device secret key (see FIG. 2).

  First, the receiving device 1902 transmits a random challenge including the 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) in response to a command for sending this random challenge, but illustration is omitted in FIG.

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

  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 not included in the exclusion target list of SRM. If the device ID is found in the exclusion target list, the authentication process is aborted at this point to cause the receiving device 1902 to be excluded.

  Then, the transmission device 1901 succeeds in verifying the authenticity of the device certificate B, and when the device ID of the reception device 1902 is not in the exclusion target list, the random number and the device certificate A of the transmission device 1901 are used. The received random challenge is returned to the receiving device 1902 (P1912), and the authentication process is continued. Note that the receiving device 1902 returns a response (RSP) in response to a command to send this random challenge, but 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 the device ID of the transmitting device 1901 is SRM. Check if it is in the exclusion list. If the verification of the authenticity of the device certificate A fails, and if the device ID is found in the exclusion target list, the authentication process is aborted at this point, and the transmitting device 1901 is removed. Do.

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

  Next, the transmitting device 1901 receives 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 the random challenge (P1911). Furthermore, a message with a signature (see FIG. 9) in which the electronic signature of the transmitting device 1901 itself is added to the information including the model ID of the transmitting device 1901 (see FIG. 9) is transmitted to the receiving device 1902 (P1913a) . Although the receiving device 1902 returns a response (RSP) in response to the command for sending the signed message, it is not shown in FIG.

  Whether the receiving device 1902 has tampered 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 by random challenge (P1912) Verify if. The receiving device 1902 may also check the version number of the SRM, and may call the SRM update process thereafter.

  When the reception device 1902 fails to verify the signed message of the transmission device 1901, the reception device 1902 rejects the continuation of the authentication process. Also, when the receiving device 1902 can confirm that the signed message from the transmitting device 1901 is not falsified, the model ID of the transmitting device 1901 included in the signed message is a list to be excluded from SRM Check further if it has not been entered. Details of the processing procedure for checking the model ID will be given later. If the model ID is found in the exclusion target list, the reception device 1902 aborts the authentication process at this point to cause the transmission device 1901 to be excluded.

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

  Also, the receiving device 1902 is also 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) Furthermore, a signed message (see FIG. 9) in which the electronic signature by the receiving device 1902 own device private key is added to the information including the model ID of the receiving device 1902 (see FIG. 9) is transmitted to the transmitting device 1901 (P1913b) . Although the transmission device 1901 returns a response (RSP) in response to the command for sending the signed message, it is not shown in FIG.

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

  When the transmission device 1901 fails to verify the signed message of the reception device 1902, the transmission device 1901 rejects the continuation of the authentication process. Also, when the transmitting device 1901 can confirm that the signed message from the receiving device 1902 is not falsified, the model ID of the receiving device 1902 included in the signed message is a list to be excluded from SRM Check further if it has not been entered. Details of the processing procedure for checking the model ID will be given later. If the model ID is found in the exclusion target list, the transmitting device 1901 aborts the authentication process at this point to cause the receiving device 1902 to be excluded.

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

  If the above authentication process is successfully completed, the transmitting device 1901 and the receiving device 1902 can share the authentication key (Kauth). Thereafter, the transmitting device 1901 and the receiving device 1902 can perform encrypted transmission of the copyright-protected content using the encryption key shared based on the authentication key. However, in DTCP, the valid period of the authentication key is defined, and the encrypted transmission of the content using the PIN key based on the same authentication key is limited to the valid period of the authentication key.

  FIG. 20 is a flowchart showing a processing procedure for the transmitting device 1901 and the receiving device 1902 to determine whether or not the authentication partner should be excluded based on the model ID included in the signed message of the authentication partner. It shows by.

  The device verifies the signed message received from the authentication party with the device public key included in the device certificate received from the authentication party in a random challenge (step S2001), and the message is included in the message. The model ID is extracted (step S2002).

  Next, the device checks whether or not the model ID exists in the exclusion target list stored in the CRL Entries field of the held SRM (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 aborted (abort) to exclude the authentication partner.

  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" and 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 is performed in accordance with the full authentication protocol defined by DTCP. Further, in the illustrated authentication protocol, the method (2b) for protecting the model ID with the electronic signature by the manufacturer's private key issued to each licensee is applied. The transmitting device 2101 and the receiving device 2102 both hold the manufacturer certificate (see FIG. 10) including the manufacturer private key and the manufacturer public key corresponding to the manufacturer private key, and the model ID It is assumed to use a model certificate (see FIG. 10) in which the contained information is protected by the manufacturer's private key with a digital signature.

  First, the receiving device 2102 transmits a random challenge in which a manufacturer certificate B and a model certificate B protected by a digital signature using a manufacturer private key are added together with a random number and a device certificate B of the receiving device 2102 It transmits to 2101 and makes an authentication request (P2111). The transmitting device 2101 returns a response (RSP) in response to a command for sending this random challenge, but 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 using the CA public key of the certificate authority. If verification of the authenticity of at least one of the device certificate B and the manufacturer certificate B fails, the authentication process is aborted at this point. If it is confirmed that the device certificate B is authentic, 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 to cause the receiving device 2102 to be excluded.

  Also, the transmitting device 2101 verifies the authenticity of the model certificate B received from the receiving device 2102 using the manufacturer public key included in the manufacturer certificate B, and fails in the verification of authenticity. Abort the authentication process at this point. Then, if 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 procedure for checking the manufacturer certificate and the model certificate will be given later. If the model ID is found in the exclusion target list, at this point, the authentication process is aborted so that the receiving device 2102 is excluded.

  In the case of a system using 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 a CC flag (see FIG. 11), it is checked whether the CC flag is set. In addition, when the model certificate B includes information on 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 linked to the device certificate B depending on whether it is in the range of valid device ID values. Details of the processing procedure for checking the model certificate linked to the manufacturer certificate will be given later. If it can not be confirmed that the model certificate B is linked to the device certificate B, it is known that the receiving device 2102 is a product using a component that has been flowed horizontally, so the transmitting device 2101 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 both the device ID and the model ID of the receiving device 2102 are included in the exclusion target list. If not, in addition to the random number and the device certificate A of the transmission device 2101, a random challenge including the manufacturer certificate A and the model certificate A protected by the digital signature by the manufacturer private key is received A response is sent to 2102 (P2112), and the authentication process is continued. The receiving device 2102 returns a response (RSP) in response to a command for sending this random challenge, but 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 and the manufacturer certificate A fails, the authentication process is aborted at this point. If it is confirmed that the device certificate A is authentic, 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, at this point, the authentication process is aborted and the transmitting device 2101 is excluded.

  Also, the receiving device 2102 verifies the authenticity of the model certificate A received from the transmitting device 2101 using the manufacturer public key included in the manufacturer certificate A, and fails in the verification of authenticity. Abort the authentication process at this point. Then, when it is confirmed that the model certificate A is authentic, 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 procedure for checking the manufacturer certificate and the model certificate will be given later. If the model ID is found in the exclusion target list, at this point, the authentication process is aborted and the transmitting device 2101 is excluded.

  Also, 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 CC flag is provided in the device certificate A (see FIG. 11), it is checked whether the CC flag is set. Also, when the model certificate A includes information on 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 linked to the device certificate A depending on whether or not it is within the range of valid device ID values. Details of the processing procedure for checking the model certificate linked to the manufacturer certificate will be given later. If it can not be confirmed that the model certificate A is linked to the device certificate A, it is known that the transmitting device 2101 is a product using a component which has been flowed horizontally, so the receiving device 2102 At this point, the authentication process is aborted so that the transmitting device 2101 is excluded.

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

  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 the random challenge (P2111). And a digital signature based on the device private key of the transmitting device 2101 itself is sent to the receiving device 2102 (P2113a). Although the receiving device 2102 returns a response (RSP) in response to the command for sending the signed message, it is not shown in FIG.

  Whether the receiving device 2102 has tampered with the signed message received from the transmitting device 1601 using the device public key included in the device certificate A received by the random challenge (P2112) from the transmitting device 2101 Verify if. Note that the receiving device 2102 may also check the version number of the SRM and may call the SRM update process thereafter.

  When the verification of the signed message of the transmission device 2101 fails, the reception device 2102 rejects the continuation of the authentication process. On the other hand, when the receiving device 2102 succeeds in verifying the signed message of the transmitting device 2101, the receiving device 2102 receives the information A for key sharing received from the transmitting device 2101 and the information B for the key sharing calculated by itself. The authentication key (Kauth) is calculated based on both (Compute Auth key).

  The receiving device 2102 then calculates 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). And a digital signature based on the device private key of the receiving device 2102 itself is sent to the transmitting device 101 (P2113b). Although the transmission device 2101 returns a response (RSP) in response to the command for sending the signed message, it is not shown in FIG.

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

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

  When the above authentication process is successfully completed, the transmission device 2101 and the reception device 2102 can share the authentication key (Kauth). Thereafter, the transmitting device 2101 and the receiving device 2102 can perform encrypted transmission of the copyright-protected content using the encryption key shared based on the authentication key. However, in DTCP, the valid period of the authentication key is defined, and the encrypted transmission of the content using the PIN key based on the same authentication key is limited to the valid period of the authentication key.

  FIG. 22 is a flowchart showing a processing procedure for the transmitting device 2101 and the receiving device 2102 to determine whether or not the authentication partner should be excluded based on the model ID included in the model certificate of the authentication partner. It shows by. However, in the illustrated process 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 party with the CA public key of the certificate authority, and further verifies the manufacturer certificate received from the authentication party with the CA public key of the certificate authority (step S2201). 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 party.

  Next, the device verifies the model certificate received from the authentication party with the manufacturer public key included in the manufacturer certificate whose authenticity is 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 eliminates the authentication partner.

  If the verification of the authenticity of the model certificate is successful (Yes in step S2204), then the device receives the model ID included in the model certificate in the CRL Entries field of the SRM that the device holds. It is checked whether the model ID is present 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, if the model ID is found in the exclusion target list (Yes in step S2206), the authentication processing is aborted (abort) to exclude the authentication partner.

  Also, in FIG. 23, another processing procedure for the transmitting device 2101 and the receiving device 2102 to determine whether or not the authentication partner should be excluded based on the model ID included in the model certificate of the authentication partner. Is shown in the form of a flow chart. However, in the illustrated processing procedure, a combination of the device certificate shown in FIG. 11, the manufacturer certificate shown in FIG. 10, and the model certificate (including information associated with the device certificate) shown in FIG. Is assumed to be a system that uses

  The device verifies the device certificate received from the authentication party with the CA public key of the certificate authority, and further verifies the manufacturer certificate received from the authentication party with the CA public key of the certificate authority (step S2301). 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 party.

  Next, the device verifies the model certificate received from the authentication party with the manufacturer public key included in the manufacturer certificate whose authenticity is 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 eliminates the authentication partner.

  If the verification of the authenticity of the model certificate is successful (Yes in step S2304), the device then checks the CC flag of the device certificate (step S2305). Then, when the CC flag is set (Yes in step S2306), it is known that the device certificate under verification is the device certificate incorporated in the part (semi-finished product), so that the authentication partner continues to be It is checked whether or not the model certificate of is associated with the device certificate received by random challenge from the authentication party (step S2307). Specifically, it is checked whether the device ID included in the device certificate is within the range of valid device ID values indicated in the model certificate. If the device certificate can not be confirmed as a model certificate linked to the device certificate (No in step S2308), the device aborts the authentication process and excludes the authentication partner.

  If the CC flag is not set and it is not the device certificate of the part (semi-finished product) (No in step S2306), and if it can be confirmed that it is the model certificate linked to the device certificate (Yes in step S2308), subsequently, the device has a model ID included in the exclusion target list stored in the CRL Entries field of the SRM held by the device. It is checked whether it is 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 aborted (abort) to exclude the authentication partner.

  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 unauthorized device to be excluded, the SRM is a model to be excluded. Model ID is also registered. Then, each device performing authentication takes measures of tampering with each other's model ID, passes it to the authentication partner, and interrupts the authentication if the model ID of the authentication partner is found in the SRM. All devices of the same model can be eliminated.

  A manufacturer who manufactures and sells devices need not ensure continuity of device IDs for the same model by incorporating a corresponding model ID into each device of the same model. In other words, even if the device ID of the device of the same model is discontinuous, it is possible to exclude all the devices of the same model only by registering a small amount of information called the model ID in the SRM.

  So far, when a device passes a model ID to an authentication partner, (1) a method of protecting the model ID with an electronic signature by a licensor or a certificate authority as a method of preventing falsification of the model ID; We have described two ways to protect your model ID with a digital signature with a private key issued to licensees.

  About any method to these methods (1) or (2), the following points (A) and (B) can be transformed into the example which considered further.

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

  By (A), it is not necessary to generate a CA electronic signature for each model while reducing the use of an arbitrary model ID by the CA electronic signature, thereby reducing the burden on device manufacture. be able to.

  Also, by doing (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 product and the CA electronic signature corresponding thereto.

  In the following, as one of the modifications of the embodiment in consideration of the above (A) and (B), one of the authentication methods including the mechanism for excluding all the devices of the same model described above is described. A modification of FIG. 20 will be described.

  FIGS. 24 to 26 show configuration examples of information in which a CA electronic signature for a maker name is added to a model ID. The model ID to be registered in the SRM (or the CRL) needs to cause different models to have different IDs, and is identification information determined to be unique information for each model of a product.

  The model ID basically includes a combination of a manufacturer name of a product and a model model number. For example, the licensor centrally manages manufacturer names so that manufacturer names do not overlap among different manufacturers. In addition, each maker assigns a model model number to an own product model so as not to be duplicated. As shown in FIGS. 5 and 6, in addition to the model model number, information such as the model version number and the provision time of the product model version may be added to the model ID. When a version number is added, the licensor centrally manages the maker name and the model model number, and each maker may allocate other information such as the version number and the provision time. The manufacturer name of the product does not change from model to model. On the other hand, information such as 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 maker name is disposed at the end of the model ID including the maker name and the model number. Further, in the example shown in FIG. 25, the CA electronic signature for the maker name is arranged at the head of the model ID including the maker name and the model number. Further, in the example shown in FIG. 26, the CA electronic signature for the maker name is disposed inside the model ID including the maker name and the model number. As shown in FIG. 26, the information elements of the model ID do not have to be seamlessly linked.

  The CA electronic signature for the manufacturer name is provided by the licensor, and can not be generated by the licensee manufacturer. A device certificate that protects information including the entire model ID with a CA electronic signature (see FIG. 7) or in that it protects only the manufacturer name, which is part of the model ID, with the CA electronic signature. It differs from the model certificate (see FIG. 8). In addition, although it is limited to a part of information, a signed message for protecting 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 (see FIG. 9) And a model certificate (see FIG. 10) that protects information including a model ID with a digital signature using a manufacturer private key. Therefore, even if a maker (non-licensee) other than the licensee tries to operate a model ID using an arbitrary maker name, the CA electronic signature for the maker name can not be obtained. The verification of the authenticity of can not be successful, and the authentication partner can reliably exclude the device including such a model ID.

  In the example shown in FIGS. 24 to 26, although only the maker name (that is, a part of the information) in the model ID is subjected to the CA electronic signature, data other than the maker name in the model ID or the model A 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" and 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 performed in accordance with the full authentication protocol defined by DTCP. Also, in the illustrated authentication protocol, the third method of protecting the model ID (that is, the method of distributing the CA electronic signature for the maker name to the model ID consisting of the maker name and model model number of the product and the like) is applied The transmitting device 2701 and the receiving device 2702 both hold the device certificate and the device secret key (see FIG. 2), and the model ID (see FIGS. 24 to 26) with the CA electronic signature for the maker name. Are supposed to do.

  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, and makes an authentication request (P2711). The transmitting device 2701 returns a response (RSP # 1) in response to a 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 verification of authenticity fails, the authentication process is aborted at this point. 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 not included in the exclusion target list of SRM (Examine SRM on Device ID). If the device ID is found in the exclusion target list, the authentication process is aborted at this point to cause the receiving device 2702 to be 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 in the exclusion target list, the random number and the device certificate A of the transmitting device 2701 are used. The received 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 it. It is checked whether the device ID of the device 2701 is not included in the exclusion target list of SRM (Examine SRM on Device ID). If the verification of the authenticity of the device certificate A fails, and if the device ID is found in the exclusion target list, the authentication process is aborted at this point so that the transmitting device 2701 is removed. Do.

  When the transmitting device 2701 succeeds in verifying the authenticity of the device certificate B and checking the SRM of the device ID, it calculates information (EC-DH key exchange first phase value) A for sharing the key with the receiving device 2702 Do. Also, when the receiving device 2702 succeeds in the verification of 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 used. calculate.

  Next, the transmitting device 2701 calculates 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 the random challenge (P2711). And a signed message obtained by adding an electronic signature by the device private key of the transmitting device 2701 itself to the information including the information to the receiving device 2702 (P2713a).

  Whether the receiving device 2702 has tampered 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 by the random challenge (P2712) Verify if. Note that the receiving device 2702 may also check the SRM version number and call the SRM update process thereafter.

  Here, when the verification of the signed message of the transmitting device 2701 fails, the receiving device 2702 rejects the continuation of 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 falsified, the information A for key sharing received from the transmitting device 2701 and the key sharing calculated by itself are used. The authentication key (Kauth) is calculated based on both of the information B for (Compute Auth key). Also, the receiving device 2702 can encrypt the encryption key B on the basis of secret data shared with the transmitting device 2701 according to the EC-DH key exchange algorithm through the exchange of EC-DH key exchange first phase values, or the authentication key Kauth. 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 secret data shared by EC-DH key exchange, data other than the portion used for sharing the encryption key for encrypted transmission of content, or using the result of processing the data with the hash function as the encryption key You can also (following, the same).

  When the receiving device 2702 encrypts the model ID with the CA electronic signature for the manufacturer name of the receiving device 2702 with the encryption key B, a response (RSP) to the command for sending the signed message (P2713a) from the transmitting device 2701 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 random challenge (P2712) from the transmitting device 2701. A message with a signature in which a digital signature by the receiving device 2702 own device private key is added to the information including the random number is transmitted to the sending device 2701 (P2713b).

  The transmitting device 2701 verifies whether the signed message received from the receiving device 2702 has been tampered with the device public key included in the device certificate B received in the random challenge (P 2711). . The transmission / reception device 2701 may also check the version number of the SRM and call the SRM update process thereafter.

  Here, if the transmission device 2701 fails to verify the signed message of the reception device 2702, the transmission device 2701 rejects the continuation of the authentication process.

  On the other hand, when the transmitting device 2701 can confirm that the signed message from the receiving device 2702 is not falsified, the information B for key sharing received from the receiving device 2702 and the key sharing calculated by itself are shared. The authentication key (Kauth) is calculated based on both of the information A for (Compute Auth key). Also, the transmitting device 2701 can encrypt the encryption key A based on the secret data shared with the receiving device 2702 according to the EC-DH key exchange algorithm through the exchange of EC-DH key exchange first phase values, or the authentication key Kauth. 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. In such a case, different secret values shared in advance by the transmitting device 2701 and the receiving device 2702 are linked to the input data to the hash function between the case of one encryption key A and the case of the other encryption key. Or change the number of times of processing by the hash function between the encryption key A and the encryption key B (for example, in the case of the encryption key B, use the result of processing the output of the hash function again by the hash function) .

  Also, the transmitting device 2701 decrypts the CA electronic signature for the encrypted model ID and manufacturer name received as a response (RSP # 3) using the encryption key A (Decrypt B's Model-ID and signature). Then, the transmitting device 2701 verifies the authenticity of the CA electronic signature for the maker name using the CA public key of the certificate authority (Verify B's Model-ID), and verifies the authenticity of the maker 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 exclusion target list of the SRM (Examine SRM on Model-ID).

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

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

  If at least one of the verification of the authenticity of the CA electronic signature against the manufacturer name of the transmission device 2701 and the check of the exclusion target list of the model ID fails, the reception device 2702 aborts the authentication process at this point. , And 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). Thereafter, the transmitting device 2701 and the receiving device 2702 can perform encrypted transmission of the copyright-protected content using the encryption key shared based on the authentication key. However, in DTCP, the valid period of the authentication key is defined, and the encrypted transmission of the content using the PIN key based on the same authentication key is limited to the valid 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 party to encrypt the CA electronic signature for the model ID and the maker name. Although encrypted information is transmitted, such encrypted information may be transmitted by other methods. For example, after the authentication protocol is extended and signed messages are exchanged, each of the transmitting device 2701 and the receiving device 2701 can also transmit the encrypted information of the CA electronic signature for the model ID and the manufacturer name with a new command. It is.

  FIG. 28 is a flowchart showing a processing procedure for the transmitting device 2701 and the receiving device 2702 to determine whether or not the authentication partner should be excluded based on the model ID transmitted as a response to the signed message of the authentication partner. It shows in the form.

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

  Next, the device calculates an encryption key based on the secret data shared with the authentication partner or the authentication key Kauth according to the EC-DH key exchange algorithm through the exchange of EC-DH key exchange first phase values (step S2802). .

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

  Then, the device verifies the authenticity of the CA electronic signature for the maker name using the CA public key of the certificate authority, and verifies the authenticity of the maker name in the model ID based on the CA electronic signature for the maker 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 verification of the authenticity of the manufacturer name is successful (Yes in step S2805), the device checks whether the model ID decrypted in step S2803 is not included in the exclusion target list of SRM (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, if the model ID is found in the exclusion target list, the device aborts the authentication process at this point to exclude the authentication partner.

  Even if a non-licensee maker (non-licensee) tries to operate a model ID using an arbitrary maker name, it can not obtain a CA electronic signature for the maker name. Therefore, verification of the authenticity of the CA electronic signature against the manufacturer name can not be successful in the authentication procedure shown in FIGS. 27 and 28, and the authentication partner reliably excludes the device including such a model ID. be able to.

  The technology disclosed herein has been described in detail above with reference to specific embodiments. However, it is obvious that those skilled in the art can make modifications and substitutions of the embodiment without departing from the scope of the technology disclosed herein.

  In the present specification, although the technology disclosed in the present specification has been described focusing on an embodiment applied to a network of the DTCP specification, the gist of the technology disclosed herein is not limited thereto.

  In short, the technology disclosed in the present specification has been described in the form of exemplification, and the contents described in the present specification should not be interpreted in a limited manner. In order to determine the scope of the technology disclosed herein, the claims should be referred to.

Note that the technology disclosed in the present specification can also be configured as follows.
(1) a communication unit that communicates with the authentication party;
A control unit that controls an 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 products having a common implementation regarding a predetermined function;
Equipped with
The control unit causes the authentication party to transmit the identification information for which tampering prevention measures have been taken during the authentication process.
Authentication device.
(2) The control unit causes the authentication party 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 the device certificate that includes the identification information and is protected by a signature by a certificate authority.
The control unit causes the device certificate to be transmitted to the authentication counterpart.
The authentication device according to (2) above.
(4) The holding unit holds a second certificate different from the device certificate and protected by a signature by the certificate authority that includes the identification information.
The control unit causes the second party to transmit the second certificate.
The authentication device according to (2) above.
(5) The holding unit further holds an apparatus certificate including at least an apparatus public key, and an apparatus private key corresponding to the apparatus public key.
The control unit causes the authentication party to transmit a message that includes the identification information and is protected by a signature using the device secret key.
The authentication device according to (1) above.
(6) The holding unit further holds a manufacturer private key and a manufacturer certificate issued for each manufacturer,
The control unit causes the authentication party to transmit a second certificate that includes the identification information and is protected by a signature with the manufacturer private key, along with the manufacturer certificate.
The authentication device according to (1) above.
(7) The control unit causes the authentication party to transmit the identification information in a phase of exchanging a device certificate with the authentication party in the authentication process.
The authentication apparatus according to any one of the above (2) to (4) and (6).
(8) The holding unit includes a device certificate including information indicating incorporation into a part, and information protected from the identification information and the device certificate by a signature using a predetermined secret key. Hold the certificate of
The control unit transmits the device certificate and the second certificate to the authentication party.
The authentication device according to (1) above.
(9) The device certificate includes the device ID of the component used for the authentication device, and the second certificate includes information on the range of valid device ID values.
The authentication device according to (8) above.
(10) An authentication method for performing an authentication process based on information that an authentication device exchanges with an authentication party,
Taking steps to prevent tampering with identification information common to products having a common implementation related to a predetermined function held by the authentication device;
Transmitting the identification information for which tampering prevention measures have been taken to the authentication party;
With an authentication method.
(11) a communication unit that communicates with the authentication party;
A control unit that controls an 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 common to products to be excluded that are common to implementations regarding a predetermined function, and
Equipped with
At the time of the authentication process, the communication unit receives, from the authentication party, identification information for which a measure to prevent tampering has been taken;
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 identification information of the authentication partner protected by a signature by a certificate authority,
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 a device certificate that includes identification information of the authentication party and is protected by a signature by a certificate authority,
The control unit verifies the authenticity of the device certificate with the public key of the certificate authority and checks identification information included in the device certificate from the list.
The authentication device according to (12).
(14) The communication unit receives, from the authentication party, 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 party.
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 from the list.
The authentication device according to (12).
(15) The communication unit receives, from the authentication party, a device certificate including at least the device public key of the authentication party, and a message protected by a signature with an apparatus private key that includes identification information and corresponds to the device public key. And
The control unit verifies the authenticity of the received message using the device public key, and checks identification information included in the message from the list.
The authentication device according to (11) above.
(16) The communication unit includes a second certificate that includes identification information and is protected by a signature with a manufacturer's private key issued to the manufacturer of the authentication party, and a manufacturing issued to the manufacturer of the authentication party. The certificate of the party from the other party,
The control unit verifies the authenticity of the received second certificate with the manufacturer public key included in the manufacturer certificate and checks the identification information included in the second certificate from the list. ,
The authentication device according to (11) above.
(17) The communication unit receives identification information from the authentication party in a phase of exchanging a device certificate with the authentication party in the authentication process.
The authentication apparatus according to any one of the above (12) to (14) and (16).
(18) The communication unit includes a device certificate of the authentication party including information indicating incorporation into a part, and information associated with identification information of the authentication party and the device certificate, and a predetermined secret key Receive a second certificate protected by a
The control unit verifies the authenticity of the device certificate and the second certificate, and checks whether the second certificate is linked to the device certificate.
The authentication device according to (11) above.
(19) The communication unit receives, from the authentication party, the device certificate including the device ID of the component used for the authentication party, and the second certificate including information on a range of valid device ID values. ,
The control unit confirms that a device ID included in the device certificate is within a range of device ID values included in the second certificate.
The authentication device according to (18).
(20) An authentication method for performing an authentication process based on information that the authentication apparatus transmits and receives with an authentication party,
The authentication device holds a list of identification information common to the products to be excluded and common to the implementation regarding a predetermined function,
Receiving from the authentication party identification information for which a tampering prevention measure has been taken;
Verifying the authenticity of the received identification information;
Checking whether the received identification information is present in the list;
With an authentication method.
(21) The identification information includes at least information on a maker name unique to each applicable product maker and a model model number assigned so as not to be duplicated in each maker.
The authentication device according to any one of (1) to (9) and (11) to (19).
(22) The identification information further includes information on the version of the applicable product model,
The authentication device according to (21) above.
(23) The identification information further includes information on provision date of the version of the applicable product model,
The authentication device according to (22).
(24) The holding unit holds the identification information including a first part, a second part, and a signature of the first part by the certificate authority,
The control unit encrypts the identification information and causes the authentication party to transmit the identification information in the authentication process.
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 party or an encryption key calculated based on the authentication key.
The authentication device according to (24).
(26) The control unit causes the encrypted identification information to be transmitted in response to the reception of the signed message from the authentication party.
The authentication apparatus according to any one of the above (24) or (25).
(27) The control unit causes the encrypted identification information to be transmitted by a command transmitted after exchanging the signed message with the authentication partner.
The authentication apparatus according to any one of the above (24) or (25).
(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 authentication processing, the communication unit receives, from the authentication partner, information in which the identification information and the signature by the certificate authority for the first part are encrypted.
The control unit decrypts the encrypted information, verifies the authenticity of the first portion of the identification information based on the signature, and the second portion of the identification information does not exist in the list To check the
The authentication device according to (11) above.
(29) The control unit performs the decryption using data shared in the process of generating an authentication key with the authentication party or an encryption key calculated based on the authentication key.
The authentication device according to (28).
(30) The communication unit receives the encrypted information in response to the signed message transmitted to the authentication party.
The authentication device according to any one of the above (28) or (29).
(31) The communication unit receives the encrypted information by a command received after exchanging a message with a signature with the authentication counterpart.
The authentication device according to any one of the above (28) or (29).
(32) The first part comprises invariant information at the manufacturer of the product, and the second part comprises variable information,
The authentication apparatus according to any one of (24) to (31).

101, 1401, 1601, 1901, 2101 ... transmitting device 102, 1402, 1602, 1902, 2102 ... receiving device

Claims (20)

  1. A communication unit that communicates with the authentication party;
    A control unit that controls an 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 products having a common implementation regarding a predetermined function;
    Equipped with
    The control unit causes the authentication party to transmit the identification information for which tampering prevention measures have been taken during the authentication process.
    Authentication device.
  2. The control unit causes the authentication party to transmit the identification information protected by a signature by a certificate authority.
    The authentication device according to claim 1.
  3. The holding unit holds the device certificate that includes the identification information and is protected by a signature by a certificate authority.
    The control unit causes the device certificate to be transmitted to the authentication counterpart.
    The authentication device according to claim 2.
  4. The holding unit holds a second certificate other than the device certificate, the second certificate including the identification information and protected by a signature by a certificate authority,
    The control unit causes the second party to transmit the second certificate.
    The authentication device according to claim 2.
  5. The holding unit further holds an apparatus certificate including at least an apparatus public key, and an apparatus private key corresponding to the apparatus public key.
    The control unit causes the authentication party to transmit a message that includes the identification information and is protected by a signature using the device secret key.
    The authentication device according to claim 1.
  6. The holding unit further holds a manufacturer private key and a manufacturer certificate issued for each manufacturer,
    The control unit causes the authentication party to transmit a second certificate that includes the identification information and is protected by a signature with the manufacturer private key, along with the manufacturer certificate.
    The authentication device according to claim 1.
  7. The control unit causes the authentication party to transmit the identification information in a phase of exchanging a device certificate with the authentication party in the authentication process.
    The authentication device according to claim 2.
  8. The holding unit includes a device certificate including information indicating incorporation into a part, and a second certificate protected by a predetermined private key and including information associated with the identification information and the device certificate. Hold
    The control unit transmits the device certificate and the second certificate to the authentication party.
    The authentication device according to claim 1.
  9. The device certificate includes the device ID of the component used for the authentication device, and the second certificate includes information of a range of valid device ID values.
    The authentication device according to claim 8.
  10. An authentication method for performing an authentication process based on information that an authentication device exchanges with an authentication party,
    Taking steps to prevent tampering with identification information common to products having a common implementation related to a predetermined function held by the authentication device;
    Transmitting the identification information for which tampering prevention measures have been taken to the authentication party;
    With an authentication method.
  11. A communication unit that communicates with the authentication party;
    A control unit that controls an 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 common to products to be excluded that are common to implementations regarding a predetermined function, and
    Equipped with
    At the time of the authentication process, the communication unit receives, from the authentication party, identification information for which a measure to prevent tampering has been taken;
    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 identification information of the authentication partner protected by a signature by a certificate authority,
    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 claim 11.
  13. The communication unit receives an apparatus certificate that includes identification information of the authentication party and is protected by a signature by a certificate authority.
    The control unit verifies the authenticity of the device certificate with the public key of the certificate authority and checks identification information included in the device certificate from the list.
    The authentication device according to claim 12.
  14. The communication unit receives, from the authentication party, 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 party.
    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 from the list.
    The authentication device according to claim 12.
  15. The communication unit receives, from the authentication party, a device certificate including at least the device public key of the authentication party, and a message protected by a signature with a device private key that includes identification information and corresponds to the device public key.
    The control unit verifies the authenticity of the received message using the device public key, and checks identification information included in the message from the list.
    The authentication device according to claim 11.
  16. The communication unit includes a second certificate including identification information and protected by a signature with a manufacturer private key issued to the manufacturer of the authentication party, and a manufacturer certificate issued to the manufacturer of the authentication party. Received from the authentication party,
    The control unit verifies the authenticity of the received second certificate with the manufacturer public key included in the manufacturer certificate and checks the identification information included in the second certificate from the list. ,
    The authentication device according to claim 11.
  17. The communication unit receives identification information from the authentication party in a phase of exchanging a device certificate with the authentication party in the authentication process.
    The authentication device according to claim 12.
  18. The communication unit includes a device certificate of the authentication party including information indicating incorporation into a part, information identifying the authentication party and information associated with the device certificate, and a signature using a predetermined secret key Receive a second protected certificate,
    The control unit verifies the authenticity of the device certificate and the second certificate, and checks whether the second certificate is linked to the device certificate.
    The authentication device according to claim 11.
  19. The communication unit receives, from the authentication party, the second certificate including the device certificate including a device ID of a component used for the authentication party and information of a range of valid device ID values.
    The control unit confirms that a device ID included in the device certificate is within a range of device ID values included in the second certificate.
    The authentication device according to claim 18.
  20. An authentication method for performing an authentication process based on information that an authentication device exchanges with an authentication party,
    The authentication device holds a list of identification information common to the products to be excluded and common to the implementation regarding a predetermined function,
    Receiving from the authentication party identification information for which a tampering prevention measure has been taken;
    Verifying the authenticity of the received identification information;
    Checking whether the received identification information is present in the list;
    With an authentication method.
JP2017016093A 2016-07-14 2017-04-21 Authentication device and authentication method Pending JPWO2018012078A1 (en)

Priority Applications (5)

Application Number Priority Date Filing Date Title
JP2016139766 2016-07-14
JP2016139766 2016-07-14
JP2016208879 2016-10-25
JP2016208879 2016-10-25
PCT/JP2017/016093 WO2018012078A1 (en) 2016-07-14 2017-04-21 Authentication device and authentication method

Publications (1)

Publication Number Publication Date
JPWO2018012078A1 true JPWO2018012078A1 (en) 2019-04-25

Family

ID=60952882

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017016093A Pending JPWO2018012078A1 (en) 2016-07-14 2017-04-21 Authentication device and authentication method

Country Status (2)

Country Link
JP (1) JPWO2018012078A1 (en)
WO (1) WO2018012078A1 (en)

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4083218B2 (en) * 1995-06-05 2008-04-30 サートコ・インコーポレーテッド Multi-step digital signature method and system
JP4655951B2 (en) * 2006-02-06 2011-03-23 ソニー株式会社 Information processing apparatus, information recording medium manufacturing apparatus, information recording medium and method, and computer program
US7882356B2 (en) * 2006-10-13 2011-02-01 Microsoft Corporation UPnP authentication and authorization
JP2009163676A (en) * 2008-01-10 2009-07-23 Nec Corp Connection system for configuration verifying equipment, verification terminal, connection method for configuration verifying equipment, and program
JP5474593B2 (en) * 2009-11-05 2014-04-16 京セラドキュメントソリューションズ株式会社 File distribution system
JP5946374B2 (en) * 2012-08-31 2016-07-06 株式会社富士通エフサス Network connection method and electronic device

Also Published As

Publication number Publication date
WO2018012078A1 (en) 2018-01-18

Similar Documents

Publication Publication Date Title
US8874936B2 (en) Terminal device, verification device, key distribution device, content playback method, key distribution method, and recording medium
JP4806235B2 (en) System and method for enforcing location privacy using rights management
CN101189827B (en) Method for inclusive authentication and management of service provider, terminal and user identity module, and system and terminal device using the method
US9607131B2 (en) Secure and efficient content screening in a networked environment
CN103729942B (en) The transmission key transmitted from the key server to the terminal server system and a method
CA2556155C (en) Token provisioning
CA2560570C (en) Authentication between device and portable storage
EP1844418B1 (en) Private and controlled ownership sharing
US5568552A (en) Method for providing a roving software license from one node to another node
JP3867388B2 (en) Conditional authentication apparatus and method
KR100912276B1 (en) Electronic Software Distribution Method and System Using a Digital Rights Management Method Based on Hardware Identification
KR20120100046A (en) Apparatus and method for access control of contents in distributed environment network
US10003604B2 (en) Authenticated communication between security devices
US7296147B2 (en) Authentication system and key registration apparatus
JP4113274B2 (en) Authentication apparatus and method
US7831831B2 (en) Authentication communication system, authentication communication apparatus, and authentication communication method
US20040088541A1 (en) Digital-rights management system
WO2004038568A2 (en) Method and device for authorizing content operations
KR20070046982A (en) Digital rights management system based on hardware identification
KR20080084480A (en) Method for mutual authenticating between devices using mediated module and system thereof
US7464274B2 (en) Manufacturing trusted devices
JPH10308732A (en) Access right authenticating device and method therefor
JP3971890B2 (en) Signature verification support apparatus, signature verification support method, and electronic signature verification method
JP2007511810A (en) Proof of execution using random number functions
CN101872399B (en) Dynamic digital copyright protection method based on dual identity authentication