WO2018012078A1 - Dispositif et procédé d'authentification - Google Patents

Dispositif et procédé d'authentification Download PDF

Info

Publication number
WO2018012078A1
WO2018012078A1 PCT/JP2017/016093 JP2017016093W WO2018012078A1 WO 2018012078 A1 WO2018012078 A1 WO 2018012078A1 JP 2017016093 W JP2017016093 W JP 2017016093W WO 2018012078 A1 WO2018012078 A1 WO 2018012078A1
Authority
WO
WIPO (PCT)
Prior art keywords
certificate
authentication
model
identification information
partner
Prior art date
Application number
PCT/JP2017/016093
Other languages
English (en)
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
Application filed by ソニー株式会社 filed Critical ソニー株式会社
Priority to JP2018527402A priority Critical patent/JP6791247B2/ja
Publication of WO2018012078A1 publication Critical patent/WO2018012078A1/fr

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols 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

Definitions

  • the technology disclosed in this 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.
  • 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 with a key based on shared information. Has been done.
  • Digitized content is relatively easy to perform illegal operations such as copying and falsification. For this reason, when content is transmitted between devices, it is particularly strongly demanded by content providers to protect the transmitted content appropriately.
  • DTCP Digital Transmission Content Protection
  • DTLA Digital Transmission Licensing Administrator
  • content is protected by defining a mechanism in which authentication processing is performed between a transmission device and a reception device, and the content is encrypted and transmitted using a key based on information shared as a result.
  • SRM System Renewability Message
  • the licensor issues an SRM that includes a list of device IDs of unauthorized devices. Each legitimate device refers to the SRM at the time of authentication, and interrupts the authentication process when the device ID received from the authentication partner device is included in the SRM. In this way, since the device indicated by the SRM is excluded at the time of authentication, the device authorized as an unauthorized device is excluded from the content transmission system.
  • the device ID is generally included in a device certificate with an electronic signature provided by the licensor to the licensee, tampering prevention and forgery by a non-licensee are prevented.
  • the device certificate is incorporated into the product by the licensee and is passed to the authentication partner during the authentication process (described later).
  • An object of the technology disclosed in the present specification is to provide an authentication device and an authentication method for performing an authentication process based on a predetermined standard.
  • the technology disclosed in the present specification has been made in consideration of the above-mentioned problems, and the first aspect thereof is A communication unit that communicates with the authentication partner; A control unit that controls authentication processing based on information transmitted to and received from the authentication partner via the communication unit; A holding unit that holds identification information that is common in products that have a common implementation of a predetermined function; Comprising The control unit causes the authentication partner to transmit the identification information in which measures for preventing falsification are taken during the authentication process. It is an authentication device.
  • control unit of the authentication device is configured to cause the authentication partner to transmit the identification information protected by a signature from a certificate authority. Has been.
  • the holding unit of the authentication device holds the device certificate that includes the identification information and is protected by a signature from a certificate authority,
  • the control unit is configured to transmit the device certificate to the authentication partner.
  • the holding unit of the authentication apparatus is protected by a signature from a certificate authority that includes the identification information different from the device certificate.
  • the second certificate is held and the control unit is configured to cause the second certificate to be transmitted to the authentication partner.
  • the holding unit of the authentication device includes a device certificate including at least a device public key and a device secret corresponding to the device public key.
  • the key is further held, and the control unit is configured to transmit a message including the identification information and protected by a signature with the device secret key to the authentication partner.
  • the holding unit of the authentication device 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 with the manufacturer private key to the authentication partner together with the manufacturer certificate.
  • control unit of the authentication device provides the identification information in a phase in which a device certificate is exchanged with the authentication partner during the authentication process. Is transmitted to the authentication partner.
  • the holding unit of the authentication device includes a device certificate including information indicating that it is incorporated in a component, the identification information, A second certificate that includes information associated with the device certificate and protected by a signature with a predetermined private key is stored, and the control unit uses the device certificate and the second certificate as the authentication partner. It is configured to send.
  • the device certificate includes a device ID of a part used in the authentication device, and the second certificate. Contains information on the range of valid device ID values.
  • the tenth aspect of the technology disclosed in this specification is: An authentication method for performing an authentication process based on information transmitted and received by an authentication device with an authentication partner, Taking measures for preventing falsification of identification information that is common to products having a common implementation related to a predetermined function held by the authentication device; Transmitting the identification information to which tampering prevention measures have been taken to the authentication partner; Is an authentication method.
  • the eleventh aspect of the technology disclosed in this specification is as follows: A communication unit that communicates with the authentication partner; A control unit that controls authentication processing 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 have a common implementation regarding a predetermined function; Comprising During the authentication process, the communication unit receives identification information for which tampering prevention measures have been taken from the authentication partner, The control unit verifies the authenticity of the received identification information and checks whether it exists in the list; It is an authentication device.
  • the communication unit of the authentication device receives the identification information of the authentication partner protected by a signature from a certificate authority, and performs 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.
  • the communication unit of the authentication device includes the authentication certificate that includes the identification information of the authentication partner and is protected by a signature from 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 check the identification information included in the device certificate with the list.
  • the communication unit of the authentication device includes a signature by a certificate authority that includes identification information different from the device certificate of the authentication partner.
  • the control unit verifies the authenticity of the second certificate with the public key of the certificate authority and includes the second certificate in the second certificate.
  • the identification information to be checked is checked in the list.
  • the communication unit of the authentication device includes a device certificate including at least the device public key of the authentication partner, and identification information.
  • a message protected by a signature with a device private key corresponding to the device public key is received from the authentication partner, and the control unit verifies the authenticity of the received message with the device public key and includes the identification included in the message Information is configured to be checked in the list.
  • the communication unit of the authentication device includes a signature by a manufacturer private key including identification information and issued to the manufacturer of the authentication partner.
  • the control unit receives the authenticity of the received second certificate.
  • the second certificate protected by the authentication partner and the manufacturer certificate issued to the authentication partner manufacturer are received from the authentication partner. Verification is performed using a manufacturer public key included in the manufacturer certificate, and identification information included in the second certificate is checked in the list.
  • the communication unit of the authentication device includes the authentication partner in a phase of exchanging a device certificate with the authentication partner during the authentication process. It is configured to receive identification information from.
  • the communication unit of the authentication apparatus includes the authentication partner device certificate including information indicating that the communication apparatus is incorporated in a component;
  • the control unit receives a second certificate that includes the identification information of the authentication partner and the information associated with the device certificate and is protected by a signature with a predetermined private key, and the control unit receives the device certificate and the second certificate. And verifying whether the second certificate is linked to the device certificate.
  • the communication unit of the authentication device includes the device certificate including a device ID of a component used as the authentication partner,
  • the second certificate including the range information of the device ID value is received from the authentication partner, and the control unit includes the device ID included in the device certificate in the second certificate. It is configured to confirm that it is within the range of the device ID value.
  • the twentieth aspect of the technology disclosed in this specification is: An authentication method for performing an authentication process based on information transmitted and received by an authentication device with an authentication partner,
  • the authentication device holds a list of identification information common to products to be excluded that have a common implementation related to a predetermined function, Receiving from the authentication partner identification information that has been tampered with; Verifying the authenticity of the received identification information; Checking whether the received identification information does not exist in the list; Is an authentication method.
  • the identification information is assigned to a unique manufacturer name for each corresponding product manufacturer and is not duplicated in each manufacturer. At least information on the specified model number.
  • the identification information further includes information on the version of the corresponding product model.
  • the identification information further includes information related to the provision date of the version of the corresponding product model.
  • an excellent apparatus and authentication method that can suitably exclude unauthorized devices using an exclusion target list are provided. can do.
  • FIG. 1 is a diagram showing an outline of a communication flow of a complete 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 shows an SRM packet format.
  • FIG. 4 is a diagram illustrating a configuration example of the model ID.
  • FIG. 5 is a diagram illustrating a configuration example of the model ID.
  • FIG. 6 is a diagram illustrating a configuration example of the model ID.
  • FIG. 7 is a diagram illustrating a configuration example of the device certificate in which the model ID is inserted.
  • FIG. 8 is a diagram showing a configuration example of a model certificate protected by an electronic signature by a certificate authority.
  • FIG. 8 is a diagram showing a configuration example of a model certificate protected by an electronic signature by a certificate authority.
  • FIG. 9 is a diagram illustrating a configuration example of a message including a model ID and attached with an electronic signature using a device secret key.
  • FIG. 10 is a diagram illustrating 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 illustrating a configuration example of a device certificate provided with a CC flag.
  • FIG. 12 is a diagram illustrating a configuration example of a model certificate including information on a range of device ID values.
  • FIG. 13 is a diagram illustrating another configuration example of a model certificate including information on a range of device ID values.
  • FIG. 14 is a diagram illustrating 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 an authentication partner should be excluded based on the model ID included in the device certificate of the authentication partner.
  • FIG. 16 is a diagram showing another example of an authentication protocol communication flow including a mechanism for excluding all devices of the same model.
  • FIG. 17 is a flowchart showing a processing procedure for determining whether or not an authentication partner should be excluded 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 an authentication partner should be excluded based on the model ID included in the model certificate of the authentication partner.
  • FIG. 19 is a diagram showing another example of an authentication protocol communication flow including a mechanism for excluding all devices of the same model.
  • FIG. 20 is a flowchart showing a processing procedure for determining whether or not an authentication partner should be excluded based on the model ID included in the signed message of the authentication partner.
  • FIG. 21 is a diagram illustrating another example of an authentication protocol communication flow 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 an authentication partner should be excluded based on the model ID included in the model certificate of the authentication partner.
  • FIG. 23 is a flowchart showing another processing procedure for determining whether or not an authentication partner should be excluded based on the model ID included in the model certificate of the authentication partner.
  • FIG. 24 is a diagram illustrating a configuration example of a model ID with a CA digital signature for a manufacturer name.
  • FIG. 25 is a diagram illustrating a configuration example of a model ID with a CA digital signature for a manufacturer name.
  • FIG. 26 is a diagram illustrating a configuration example of a model ID with a CA digital signature for a manufacturer name.
  • FIG. 27 is a diagram showing another example of an authentication protocol communication flow including a mechanism for excluding all devices of the same model.
  • FIG. 28 is a flowchart showing a processing procedure for determining whether or not an authentication partner should be excluded based on the model ID included in the signed message of the authentication partner.
  • DTCP copyright protection technologies
  • 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 shared information, thereby protecting the content.
  • an SRM is defined for transmitting information of a device authorized as an unauthorized device, and a device indicated by the SRM is excluded at the time of authentication.
  • FIG. 1 schematically shows a communication flow of an authentication protocol defined between DTCP and performed between a transmitting device (device A) 101 and a receiving device (device B) 102 that perform content transmission.
  • the transmitting device 101 here corresponds to “Source”, and the receiving device 102 corresponds to “Sink”. It is assumed that the transmission device 101 and the reception device 102 can communicate via a network (not shown).
  • 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 uses public key cryptography.
  • the transmitting device 101 and the receiving device 102 hold a device certificate 210, a device private key 220, and a CA public key 230 as shown in FIG. 2 on the premise that authentication processing is performed according to the protocol shown in FIG. Yes.
  • the device certificate 210 includes at least a device ID (uniquely identifying a device) indicated by a reference number 211 and a device public key indicated by a reference number 212. These pieces of information (shaded in the figure) Accompanying the electronic signature 213 of the certificate authority (CA) for the (part).
  • the device secret key 220 is a secret key corresponding to the device public key included in the device certificate 210.
  • the CA public key 230 is held for verifying the device certificate of the authentication partner.
  • the licensor issues a device certificate 210 and a device private key 220 corresponding to the device public key 212 included in the device certificate for each device, and distributes them to the manufacturer of the licensee. Then, the manufacturer embeds the device certificate 210, the device private key 220, and the CA public key 230 in each device manufactured by the company (for example, the transmitting device 101 serving as the source and the receiving device 102 serving as the sink). Accordingly, a device manufacturer needs to obtain device certificates 210 for the number of devices to be manufactured or sold from the licensor.
  • each of the transmitting device 101 and the receiving device 102 also holds an SRM including an exclusion target list (Certificate Revocation List: CRL).
  • CRL Certificate Revocation List
  • the receiving device 102 sends an authentication request by transmitting a random challenge including a random number challenge and the device certificate B (device B certificate) of the receiving device 102 to the transmitting device 101 (P111). For example, when the receiving device 102 tries to access copyright-protected content on the transmitting device 101 side, an authentication request is made.
  • the transmitting device 101 returns a response (RSP) to the command for sending the random challenge, but is not shown in FIG.
  • RSP response
  • certate 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 CA digital signature created by the certificate authority is attached to the device certificate B, the transmitting device 101 can verify the authenticity 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.
  • 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 SRM exclusion target list (Examine SRM). If the device ID is found in the exclusion target list (CRL Entries), the authentication process is aborted at this point, and the receiving device 102 is excluded. The SRM check is performed only when a DTLA signature (described later) included in the SRM is valid.
  • the transmitting device 101 succeeds in verifying the authenticity of the device certificate B, and if the device ID of the receiving device 102 is not included in the exclusion target list, the transmitting device 101 itself and the transmitting device 101 itself.
  • a random challenge including the device certificate A (device A certificate) is transmitted to the receiving device 102 (P112), and the authentication process is continued.
  • the receiving device 102 returns a response (RSP) to the command for sending the random challenge, but is not shown in FIG.
  • the receiving device 102 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 It is checked whether the ID is in the SRM exclusion list (Examine SRM).
  • EC-DH key exchange Elliptic curve Diffi-Hellman first-phase value: EC-DH key exchange first phase value
  • the receiving device 102 also calculates information (EC-DH key exchange first phase value) B for sharing the key with the transmitting device 101.
  • the transmitting device 101 calculates the information A for key sharing calculated by itself, the version number and generation information of the SRM stored in the transmitting device 101, and the random number received from the receiving device 102 by the random challenge (P111).
  • a message with a signature in which an electronic signature with the device private key of the transmitting device 101 itself is added to the information including the above information is transmitted to the receiving device 102 (P113a).
  • the receiving device 102 returns a response (RSP) to the command for sending the signed message, but is not shown in FIG.
  • the receiving device 102 may also check the version number of the SRM and call the SRM update process thereafter.
  • the receiving device 102 fails to verify the message with the signature of the transmitting device 101, the receiving device 102 refuses to continue the authentication process.
  • the receiving device 102 includes the key sharing information A received from the transmitting device 101 and the key sharing information B calculated by itself. Based on both, an authentication key (Kauth) is calculated (Compute Auth key).
  • the receiving device 102 calculates the information B for key sharing calculated by itself, the version number and generation information of the SRM stored in the receiving device 102, and the random number received from the transmitting device 101 by the random challenge (P112).
  • a message with a signature in which an electronic signature with the device private key of the receiving device 102 itself is added to the information including the above information is transmitted to the transmitting device 101 (P113b).
  • the transmitting device 101 returns a response (RSP) to the command for sending the signed message, but is not shown in FIG.
  • the signed message received from the receiving device 102 has not been tampered with using the device public key included in the device certificate B received from the receiving device 102 with 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 update process thereafter.
  • the transmitting device 101 fails to verify the signed message of the receiving device 102, the transmitting device 101 refuses to continue the authentication process.
  • the transmitting device 101 succeeds in verifying the signed message of the receiving device 102, the information B for key sharing received from the receiving device 102 and the information A for key sharing calculated by itself are transmitted. Based on both, an authentication key (Kauth) having the same value as that calculated on the receiving device 102 side is calculated (Compute Auth key).
  • the transmitting device 101 and the receiving device 102 can share the authentication key (Kauth), and use the encryption key shared based on this authentication key to protect the copyright.
  • the encrypted content can be encrypted and transmitted.
  • the validity period of the authentication key is defined in DTCP, and encrypted transmission of content using a secret key based on the same authentication key is limited to the validity period of the authentication key.
  • FIG. 3 shows the current SRM packet format (packet format of the first generation (before update)).
  • a CRL entry (CRL Entries) is a list of devices authorized as unauthorized devices (Certificate Revocation List).
  • the CRL length (CRL Length) indicates the size of the CRL including the CRL Length field, the CRL Entries field, and the DTLA signature (DTLA signature) field.
  • the version number (Version Number) is a monotonically increasing numerical value indicating the version of the list.
  • the device When the device receives the SRM, it compares it with the version number of the SRM that it owns, and if the received SRM is newer, it updates its information with the received SRM. In this way, devices can share a list of device IDs of unauthorized devices that should be excluded. Incidentally, the SRM can be exchanged between devices during the authentication process.
  • the SRM For example, if consecutive device IDs are assigned to devices of the same model, the first device ID and last device ID of the model that must be excluded are registered in the SRM, and the devices that perform authentication are within that range. By performing the operation of excluding all the devices having the device ID value, the amount of information registered in the SRM can be suppressed. However, if the device IDs of the devices of the same model are not consecutive, the individual device IDs must be registered, which may not fit within the predetermined upper limit size of the SRM as described above, and is registered in the SRM. Is difficult.
  • Maker sometimes manufactures multiple models of products at the same time. If these models support the same type of copyright protection technology, the licensor issues a device certificate for each device to the manufacturer that is the licensee. Here, even if the licensor issues a device certificate so that the device ID is continuous with respect to one licensee, the device ID of the device certificate incorporated in one model on the maker side that is the licensee is continued. It is difficult. Then, when it becomes necessary to exclude all devices for any model, as described above, registration to the SRM may be difficult.
  • the device certificate In order to make the device IDs included in the device certificate incorporated into the product of the same model by the licensee, the device certificate must be obtained from the licensor in advance with the device IDs for the number of products manufactured or shipped. I must. When a plurality of models of products are manufactured in parallel at the same time, a device certificate in which a necessary number of device IDs are continuous for each model must be acquired in advance from the licensor. If the manufacturing plan (the number of units manufactured for each model) is changed, there is a risk that the device certificate will be insufficient or vice versa.
  • one model ID is assigned to a product having a common implementation related to a predetermined function, that is, the same model, and the SRM should be excluded (in addition to the device ID of an unauthorized device to be excluded).
  • the SRM should be excluded (in addition to the device ID of an unauthorized device to be excluded).
  • the model ID registered in the SRM (or CRL) needs to have different IDs for different models, and is determined so as to be unique information for each model of the product.
  • 4 to 6 show configuration examples of model IDs, respectively.
  • the model ID is composed of a combination of a product manufacturer name and a model model number.
  • the licensor centrally manages the manufacturer names so that the manufacturer names are not duplicated between different manufacturers.
  • each manufacturer assigns model numbers to their product models so as not to overlap.
  • the model ID is configured by adding a model version number.
  • the model ID is configured by adding the version number of the product model and the provision time of the version of the product model.
  • an error in the version number can be covered by adding the provision time to the model ID together with the version number.
  • a model of a product to be excluded can be specified by a combination of a model model number and a provision time.
  • a method for preventing falsification of the model ID (1) a method of protecting the model ID with an electronic signature by a licensor or a certificate authority, or (2) an electronic signature using a secret key issued by the licensor to the licensee.
  • a method for protecting the model ID can be considered.
  • the authentication partner can verify the authenticity of the model ID by performing signature authentication with a public key issued by the licensor or certificate authority.
  • FIG. 7 schematically shows a configuration example of the device certificate 700 in which the model ID is inserted, which is used in the method (1a).
  • the device certificate 700 includes at least a device ID unique to the device indicated by reference number 701 (a device uniquely identifying the device), a device public key indicated by reference number 702, and a model ID indicated by reference number 703. Accompanied by the CA digital signature 704 of the certificate authority for the information (the shaded portion in the figure).
  • the authentication partner who has received the device certificate 700 verifies the authenticity of the device certificate 700 using the CA public key and checks the SRM for the device ID 701 and the model ID 703 extracted from the device certificate 700. it can.
  • FIG. 8 schematically shows a configuration example of the model certificate 800 that is used in the method (1b) and protected by the digital signature by the certificate authority.
  • the model certificate 800 at least the CA digital signature 802 by the certificate authority is added to the information including the common model ID of the same model indicated by reference numeral 801 (the shaded portion in the figure).
  • the authentication partner who has received the model certificate 800 can verify the authenticity of the model certificate 800 using the CA public key and check the SRM for the model ID 801 extracted from the model certificate 800.
  • the device certificate can be used only for a specific model. For this reason, when the manufacturer who is the licensee runs out of device certificates for a certain model, the device certificate obtained from the licensor for other models is not used. Also, if there is a surplus device certificate acquired for a certain model, it cannot be diverted to another model and is wasted. On the other hand, according to the method in which the model ID is not included in the device certificate as in (1b), it is possible to ensure the degree of freedom that the device certificate acquired from the licensor can be used for any model device.
  • FIG. 9 shows a configuration example of a message 900 that is used in the method (2a) and includes a model ID and an electronic signature with a device private key is added.
  • an electronic signature 902 using a device private key for each device is added to information (shaded portion in the figure) including the common model ID of the same model indicated by the reference number 901. .
  • 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 from the authentication partner in a random challenge Random numbers etc. are included in the message.
  • the authentication partner who has received the signed message 900 verifies the authenticity of the message 900 using the device public key included in the device certificate received by the random challenge from the message transmission source, and is extracted from the signed message 900.
  • SRM can be checked for the model ID 901.
  • FIG. 10 shows a configuration example of a model ID and a manufacturer certificate protected by an electronic signature using a manufacturer private key, which is used in the method (2b).
  • the model ID becomes a protected model certificate by adding an electronic signature 1012 with a manufacturer private key to the information 1011 to the information 1011 including the model ID of the device.
  • the manufacturer certificate 1020 is accompanied by information including the manufacturer public key 1021 corresponding to the manufacturer private key and the CA digital signature 1022 by the certificate authority.
  • the authentication partner who has received the model certificate 1010 protected by the electronic signature 1012 using 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 certificate 1020 is verified, the authenticity of the model certificate 1010 is verified using the manufacturer public key 1021 included in the manufacturer certificate 1020, and the information 1011 included in the model certificate 1010 is extracted.
  • SRM can be checked for the model ID.
  • the present specification further proposes a technique for preventing unauthorized devices manufactured by non-licensers from succeeding in the authentication process using model certificates generated only by legitimate manufacturers as licensees.
  • CC Component Certificate
  • a licensor delivers (sells) a part including a device certificate (with a CC flag) to a manufacturer to a component vendor as a licensee
  • the device ID is consecutive.
  • the licensor must be notified of the ID value (or the range of valid device ID values used for such components).
  • the licensor shall include information on the range of valid device ID values as information to be linked to the device certificate in addition to the model ID in the model certificate for manufacturers using such parts. Ask for.
  • FIG. 11 shows a configuration example of the device certificate 1100 provided with the CC flag.
  • the device certificate 1100 includes at least a CC flag indicated by a reference number 1101, a device ID indicated by a reference number 1102, and a device public key indicated by a reference number 1103, and these pieces of information (the shaded portion in the figure). Accompanied by the digital signature 1104 of the certificate authority.
  • the device ID of the device certificate is used in a divided manner. If it is possible to determine whether or not the device certificate is for a semi-finished product based on the value of the device ID, such as by using it for a finished product, the CC flag can be eliminated.
  • the format of the information indicating that the device certificate is incorporated in the component is not particularly limited.
  • FIG. 12 shows a configuration example of the model certificate 1200 including information on the range of the device ID value.
  • the model certificate 1200 includes at least a model ID indicated by a reference number 1201 and information indicating a range of a valid device ID value indicated by a reference number 1202, and for these pieces of information (shaded portions in the figure).
  • the CA digital signature 1203 of the certificate authority Accompanying with the CA digital signature 1203 of the certificate authority.
  • FIG. 13 shows another configuration example of the model certificate 1300 including information on 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 the model ID indicated by the reference number 1301 and information indicating the range of the valid device ID value indicated by the reference number 1302. is there.
  • the model certificate 1300 is shown in FIG. 12 in that the information (shaded part in the figure) is accompanied by the electronic signature 1303 by the manufacturer private key instead of the CA digital signature of the certificate authority. It is different from 1200.
  • the model certificate 1300 protected with the manufacturer private key it is necessary to transmit the manufacturer certificate (see FIG. 10) to the authentication partner.
  • the device authenticating such a product checks whether or not the CC flag of the received device certificate is set, and if the CC flag is set, the device ID included in the device certificate Is further within the range of the device ID value specified in the model certificate. If it is not possible to confirm that the device ID included in the device certificate is within the range of the device ID value specified in the model certificate, the authentication partner is an unauthorized device using a legitimate part that has been crossed. If there is, the authentication process is interrupted.
  • 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.
  • a transmitting device 1401 corresponds to “Source”
  • a receiving device 1402 corresponds to “Sink”.
  • the transmitting device 1401 and the receiving device 1402 communicate via a network (not shown). Basically, a communication procedure is performed according to the full authentication protocol defined by DTCP. Further, in the illustrated authentication protocol, the method of transmitting the model ID into the device certificate (1a) and transmitting it to the authentication partner is applied, and both the transmitting device 1401 and the receiving device 1402 are shown in FIG. It is assumed that the device certificate will be held.
  • 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) to the command for sending the 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.
  • the transmitting device 1401 extracts the device ID and model ID of the receiving device 1402 from the device certificate B, and checks whether the device ID and model ID of the receiving device 1402 are in the SRM exclusion list. Details of the processing procedure for checking the model ID will be described later. When 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 receiving device 1402 is excluded.
  • the transmitting device 1401 succeeds in verifying the authenticity of the device certificate B, and if the device ID and model ID of the receiving device 1402 are not in the exclusion target list, the random number and the device certificate of the transmitting device 1401 are obtained.
  • 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) to the command for sending the random challenge, but is not shown in FIG.
  • the receiving device 1402 verifies the authenticity of the device certificate A received from the transmitting device 1401 and extracts the device ID and model ID of the transmitting device 1401 from the device certificate A to obtain the device ID of the transmitting device 1401. And whether the model ID is in the SRM exclusion list. Details of the processing procedure for checking the model ID will be described later.
  • the verification of the authenticity of the device certificate A has failed and when at least one of the device ID or the model ID is found in the exclusion target list, the authentication process is aborted at this point, and the transmitting device 1401 is excluded.
  • the transmitting device 1401 succeeds in verifying the authenticity of the device certificate B and SRM checking of the device ID and model ID, information for sharing a key with the receiving device 1402 (EC-DH key exchange first phase value) Calculate A. Further, when the authenticity of the device certificate A and the SRM check are successful, the receiving device 1402 also calculates information (EC-DH key exchange first phase value) B for sharing the key with the transmitting device 1401.
  • the transmitting device 1401 receives the information A for key sharing calculated by itself, the version number and generation information of the SRM stored in the transmitting device 1401, and the random number received from the receiving device 1402 by the random challenge (P1411).
  • a message with a signature in which an electronic signature using the device private key of the transmitting device 1401 itself is added to the information including the above information is transmitted to the receiving device 1402 (P1413a).
  • the receiving device 1402 returns a response (RSP) to the command for sending the signed message, but is not shown in FIG.
  • the receiving device 1402 fails to verify the message with the signature of the transmitting device 1401, the receiving device 1402 refuses to continue the authentication process.
  • the receiving device 1402 succeeds in verifying the signed message of the transmitting device 1401
  • the information A for key sharing received from the transmitting device 1401 and the information B for key sharing calculated by itself are received. Based on both, an authentication key (Kauth) is calculated (Compute Auth key).
  • the receiving device 1402 receives the information B for key sharing calculated by itself, the version number and generation information of the SRM stored in the receiving device 1402, and the random number received from the transmitting device 1401 by the random challenge (P1412).
  • a message with a signature in which an electronic signature with the device private key of the receiving device 1402 itself is added to the information including the above information is transmitted to the transmitting device 1401 (P1413b).
  • the transmitting device 1401 returns a response (RSP) to the command for sending the signed message, but is not shown in FIG.
  • the sending device 1401 may also check the version number of the SRM and call the SRM update process thereafter.
  • the sending device 1401 fails to verify the signed message of the receiving device 1402, the sending device 1401 refuses to continue the authentication process.
  • the transmitting device 1401 succeeds in verifying the signed message of the receiving device 1402, the information B for key sharing received from the receiving device 1402 and the information A for key sharing calculated by itself are transmitted. Based on both, an authentication key (Kauth) having the same value as that calculated on the receiving device 1402 side is calculated (Compute Auth key).
  • the transmission device 1401 and the reception device 1402 can share the authentication key (Kauth). Thereafter, the transmission device 1401 and the reception device 1402 can perform encrypted transmission of copyright-protected content using an encryption key shared based on the authentication key.
  • the validity period of the authentication key is defined in DTCP, and encrypted transmission of content using a secret key based on the same authentication key is limited to the validity 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 to exclude an authentication partner based on the model ID included in the device certificate of the authentication partner. Is shown. However, in the illustrated processing procedure, it is assumed that the system uses the device certificate shown in FIG.
  • the device verifies the device certificate received by the random challenge from the authentication partner with the CA public key of the certificate authority, and then extracts the model ID included in the device certificate (step S1501). Then, it is checked whether or not the model ID exists in the exclusion target list stored in the CRL Entries field of the SRM held by the device (step S1502).
  • step S1503 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 and the authentication partner is excluded.
  • FIG. 16 schematically shows another example of an authentication protocol communication flow including a mechanism for excluding all devices of the same model.
  • the transmitting device 1601 corresponds to “Source”
  • the receiving device 1602 corresponds to “Sink”
  • the transmitting device 1601 and the receiving device 1602 can communicate via a network (not shown).
  • a communication procedure according to the full authentication protocol defined by DTCP is executed.
  • a method of transmitting to the authentication partner in the form of a model certificate with an electronic signature of the certificate authority, which is different from the device certificate of (1b) above is applied, and the transmitting device 1601 and the receiving device 1602 is a combination of the device certificate shown in FIG. 7 (including the model ID) and the model certificate shown in FIG. 8, or the device certificate shown in FIG. 11 (including the CC flag) and FIG. It is assumed that a combination of model certificates (including information on a range of device IDs) is held.
  • the receiving device 1602 sends an authentication request by transmitting a random challenge obtained by adding the model certificate B to the random number and the device certificate B of the receiving device 1602 to the transmitting device 1601 (P1611).
  • the transmitting device 1601 returns a response (RSP) to the command for sending the 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 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, and the receiving device 1602 is excluded.
  • the transmitting device 1601 verifies the authenticity of the model certificate B received from the receiving device 1602 by using the CA public key of the certificate authority, and when the authenticity verification fails, the authentication processing is performed at this time. Is aborted. 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 included in the exclusion target list. Details of the processing procedure for checking the model certificate will be described later. If the model ID is found in the exclusion target list, the authentication process is aborted at this point, and the receiving device 1602 is excluded.
  • the transmission device 1601 checks the CC flag of the device certificate B in addition to checking the model ID exclusion target list.
  • the CC flag is set, that is, when it is found that the device certificate is a part (semi-finished product)
  • the device ID included in the device certificate B is indicated by the model certificate B.
  • the model certificate B It is also checked whether it is within the valid device ID value range, that is, whether the model certificate B is associated with the device certificate B. Details of the processing procedure for checking the model certificate associated with the device certificate will be described later. If it is not possible to confirm that the model certificate B is associated with the device certificate B, the receiving device 1602 is known to be a product that uses a cross-flowed part. At this time, the authentication process is aborted and the receiving device 1602 is excluded.
  • the transmitting device 1601 succeeds in verifying the authenticity of the device certificate B and the model certificate B, and if neither the device ID nor the model ID of the receiving device 1602 is included in the exclusion target list, A random challenge including the model certificate A in addition to the device certificate A of the transmitting device 1601 is returned to the receiving device 1602 (P1612), and the authentication processing is continued.
  • the receiving device 1602 returns a response (RSP) to the command for sending the random challenge, but is not shown in FIG.
  • the receiving device 1602 verifies the authenticity of the device certificate A and the model certificate A received from the transmitting device 1601, and includes the device ID and the model certificate A included in the device certificate A. It is checked whether the model ID of the current model is not included in the SRM exclusion target list. Details of the processing procedure for checking the model certificate will be described later. If verification of the authenticity of at least one of device certificate A or model certificate A fails, and if at least one of device ID or model ID is found in the exclusion target list, the authentication process is interrupted at this point (Abort) to exclude the transmission device 1601.
  • the receiving device 1602 checks the CC flag of the device certificate A in addition to checking the model ID exclusion target list.
  • the CC flag is set, that is, when it is found that the device certificate is a part (semi-finished product)
  • the device ID included in the device certificate A is indicated by the model certificate A.
  • the transmitting device 1601 is known to be a product using a cross-flowed part. At this point, the authentication process is aborted and the transmitting device 1601 is excluded.
  • the transmitting device 1601 shares information (EC-DH key exchange) with the receiving device 1602.
  • First phase value) A is calculated.
  • information (EC-DH) for sharing the key with the transmitting device 1601 is also obtained.
  • Key exchange first phase value) B is calculated.
  • the transmitting device 1601 calculates the information A for key sharing calculated by itself, the version number and generation information of the SRM stored in the transmitting device 1601, and the random number received from the receiving device 1602 by the random challenge (P1611).
  • a message with a signature in which an electronic signature with the device private key of the transmitting device 1601 itself is added to the information including the above information is transmitted to the receiving device 1602 (P1613a).
  • the receiving device 1602 returns a response (RSP) to the command for sending the signed message, but is not shown in FIG.
  • the receiving device 1602 may also check the version number of the SRM and call the SRM update process thereafter.
  • the receiving device 1602 fails to verify the signed message of the transmitting device 1601, the receiving device 1602 refuses to continue the authentication process.
  • the receiving device 1602 succeeds in verifying the signed message of the transmitting device 1601
  • the information A for key sharing received from the transmitting device 1601 and the information B for key sharing calculated by itself are received. Based on both, an authentication key (Kauth) is calculated (Compute Auth key).
  • the receiving device 1602 receives the information B for key sharing calculated by itself, the version number and generation information of the SRM stored in the receiving device 1602, and the random number received from the transmitting device 1601 by the random challenge (P1612).
  • a message with a signature in which an electronic signature using the device private key of the receiving device 1602 itself is added to the information including the above information is transmitted to the transmitting device 101 (P1613b).
  • the transmitting device 1601 returns a response (RSP) to the command for sending the signed message, but is not shown in FIG.
  • the sending device 1601 may also check the version number of the SRM and call the SRM update process thereafter.
  • the transmitting device 1601 fails to verify the signed message of the receiving device 1602, the transmitting device 1601 refuses to continue the authentication process.
  • the transmitting device 1601 succeeds in verifying the signed message of the receiving device 1602, the information B for key sharing received from the receiving device 1602 and the information A for key sharing calculated by itself are transmitted. Based on both, an authentication key (Kauth) having the same value as that calculated on the receiving device 1602 side is calculated (Compute Auth key).
  • the transmission device 1601 and the reception device 1602 can share the authentication key (Kauth). Thereafter, the transmission device 1601 and the reception device 1602 can perform encrypted transmission of copyright-protected content using an encryption key shared based on the authentication key.
  • the validity period of the authentication key is defined in DTCP, and encrypted transmission of content using a secret key based on the same authentication key is limited to the validity 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 to exclude an authentication partner based on the model ID included in the authentication partner's model certificate. Is shown. However, in the illustrated processing procedure, it is assumed that the system uses a combination of the device certificate shown in FIG. 7 and the model certificate shown in FIG.
  • the device verifies the device certificate received from the authentication partner with a random challenge with the CA public key of the certificate authority, and further verifies the model certificate received with the random challenge from the authentication partner with the CA public key of the certificate authority. (Step S1701).
  • the device aborts the authentication process and excludes the authentication partner.
  • step S1702 If the authenticity of the model certificate is successfully verified (Yes in step S1702), then the device has the model ID included in the model certificate in the CRL Entries field of the SRM held by the device. It is checked whether or not the model ID exists in the stored exclusion target list (step S1703).
  • step S1704 If the model ID is not found in the exclusion 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 and the authentication partner is excluded.
  • FIG. 18 shows another processing procedure for determining whether the transmitting device 1601 and the receiving device 1602 should exclude the authentication partner based on the model ID included in the authentication partner's model certificate. Is shown in the form of a flowchart. However, in the illustrated processing procedure, it is assumed that the system uses a combination of the device certificate shown in FIG. 11 and the model certificate (including information associated with the device certificate) shown in FIG. .
  • the device verifies the device certificate received from the authentication partner with a random challenge with the CA public key of the certificate authority, and further verifies the model certificate received with the random challenge from the authentication partner with the CA public key of the certificate authority. (Step S1801). Here, if the verification of the authenticity of the model certificate has failed (No in step S1802), the device aborts the authentication process and excludes the authentication partner.
  • step S1803 If the authenticity of the model certificate is successfully verified (Yes in step S1802), the device then checks the CC flag of the device certificate (step S1803). If the CC flag is set (Yes in step S1804), it can be seen that the device certificate being verified is a device certificate incorporated in a part (semi-finished product), so that the authentication partner continues. It is checked whether the model certificate is associated with the device certificate of the authentication partner (step S1805). Specifically, it is confirmed whether or not the device ID included in the device certificate is within a valid device ID value range indicated by the model certificate. If it cannot be confirmed that the model certificate is associated with the device certificate (No in step S1806), the device aborts the authentication process and excludes the authentication partner.
  • step S1804 If the CC flag is not set and the device certificate is not a part (semi-finished product) (No in step S1804), and if it is confirmed that the model certificate is linked to the device certificate (Yes in step S1806) Subsequently, the device has the model ID included in the model certificate in the exclusion target list stored in the CRL Entries field of the SRM held by the device. It is checked whether or not to do so (step S1807).
  • the device continues the authentication process with the authentication partner.
  • the authentication process is aborted and the authentication partner is excluded.
  • FIG. 19 schematically shows another example of the communication flow of the authentication protocol including a mechanism for excluding all devices of the same model.
  • the transmitting device 1901 corresponds to “Source”
  • the receiving device 1902 corresponds to “Sink”
  • the transmitting device 1901 and the receiving device 1902 can communicate via a network (not shown).
  • a communication procedure according to the full authentication protocol defined by DTCP is executed.
  • the method of protecting the model ID with an electronic signature using a device secret key issued by the licensor (2a) for each device is applied, and both the transmitting device 1901 and the receiving device 1902 are device certificates.
  • a device secret key see FIG. 2.
  • 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) to the command for sending the random challenge, but is not shown 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 in the SRM exclusion list. If the device ID is found in the exclusion target list, the authentication process is aborted at this point, and the receiving device 1902 is excluded.
  • the transmitting device 1901 succeeds in verifying the authenticity of the device certificate B, and if the device ID of the receiving device 1902 is not in the exclusion target list, the transmitting device 1901 obtains the random number and the device certificate A of the transmitting device 1901.
  • the included random challenge is returned to the receiving device 1902 (P1912), and the authentication process is continued.
  • the receiving device 1902 returns a response (RSP) to the command for sending the random challenge, but is not shown in FIG.
  • 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 has failed, and if the device ID is found in the exclusion target list, the authentication process is aborted at this point, and the transmission device 1901 is excluded. To do.
  • the transmitting device 1901 Upon successful verification of the authenticity of the device certificate B and SRM check of the device ID, the transmitting device 1901 calculates information (EC-DH key exchange first phase value) A for sharing the key with the receiving device 1902. To do. Also, if the receiving device 1902 succeeds in verifying the authenticity of the device certificate A and SRM checking of the device ID, information (EC-DH key exchange first phase value) B for sharing the key with the transmitting device 1901 is also obtained. calculate.
  • the transmitting device 1901 receives the information A for key sharing calculated by itself, the version number and generation information of the SRM stored in the transmitting device 1901, and the random number received from the receiving device 1902 by the random challenge (P1911). Further, a message with a signature (see FIG. 9) obtained by adding an electronic signature with the device private key of the transmission device 1901 itself to the information including the model ID of the transmission device 1901 is transmitted to the reception device 1902 (P1913a). . Note that the receiving device 1902 returns a response (RSP) to the command for sending the signed message, but is not shown in FIG.
  • RSS response
  • the receiving device 1902 may also check the version number of the SRM and call the SRM update process thereafter.
  • the receiving device 1902 fails to verify the message with the signature of the transmitting device 1901, the receiving device 1902 refuses to continue the authentication process. If the receiving device 1902 can confirm that the signed message from the transmitting device 1901 has not been tampered with, the model ID of the transmitting device 1901 included in the signed message is the SRM exclusion list. Check to see if it is in. Details of the processing procedure for checking the model ID will be described later. When the model ID is found in the exclusion target list, the receiving device 1902 aborts the authentication process at this point to exclude the transmitting device 1901.
  • the receiving device 1902 If the receiving device 1902 succeeds in verifying the message with the signature of the transmitting device 1901 and also checks the model ID, the receiving device 1902 calculates the information A for key sharing received from the transmitting device 1901 and the calculation itself.
  • An authentication key (Kauth) is calculated based on both of the information B for key sharing (Compute Auth key).
  • the receiving device 1902 also calculates the information B for key sharing calculated by itself, the version number and generation information of the SRM stored in the receiving device 1902, and the random number received from the transmitting device 1901 by the random challenge (P 1912). Further, a message with a signature (see FIG. 9) obtained by adding an electronic signature with the device private key of the receiving device 1902 itself to information including the model ID of the receiving device 1902 is transmitted to the transmitting device 1901 (P1913b). . The transmitting device 1901 returns a response (RSP) to the command for sending the signed message, but is not shown in FIG.
  • RSS response
  • the sending device 1901 may also check the version number of the SRM and call the SRM update process thereafter.
  • the sending device 1901 fails to verify the signed message of the receiving device 1902, the sending device 1901 refuses to continue the authentication process. If the sending device 1901 can confirm that the signed message from the receiving device 1902 has not been tampered with, the model ID of the receiving device 1902 included in this signed message is the SRM exclusion list. Check to see if it is in. Details of the processing procedure for checking the model ID will be described later. If the model ID is found in the exclusion target list, the transmitting device 1901 aborts the authentication process at this point to exclude the receiving device 1902.
  • the transmitting device 1901 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.
  • An authentication key (Kauth) is calculated based on both of the information A for key sharing (Compute Auth key).
  • the transmission device 1901 and the reception device 1902 can share the authentication key (Kauth). Thereafter, the transmission device 1901 and the reception device 1902 can perform encrypted transmission of copyright-protected content using an encryption key shared based on the authentication key.
  • the validity period of the authentication key is defined in DTCP, and encrypted transmission of content using a secret key based on the same authentication key is limited to the validity period of the authentication key.
  • FIG. 20 is a flowchart illustrating a processing procedure for the transmitting device 1901 and the receiving device 1902 to determine whether to exclude an authentication partner based on the model ID included in the signed message of the authentication partner. Is shown.
  • the device verifies the signed message received from the authentication partner with the device public key included in the device certificate received by the random challenge from the authentication partner (step S2001), and is included in this message.
  • a model ID is extracted (step S2002).
  • the device checks whether the model ID exists in the exclusion target list stored in the CRL Entries field of the held SRM (step S2003).
  • the device continues the authentication process with the authentication partner.
  • the authentication process is aborted and the authentication partner is excluded.
  • FIG. 21 schematically shows another example of an authentication protocol communication flow including a mechanism for excluding all devices of the same model.
  • the transmitting device 2101 corresponds to “Source”
  • the receiving device 2102 corresponds to “Sink”
  • the transmitting device 2101 and the receiving device 2102 can communicate via a network (not shown).
  • a communication procedure according to the full authentication protocol defined by DTCP is executed.
  • the method of protecting the model ID with the electronic signature by the manufacturer private key issued by the licensor (2b) to each licensee is applied.
  • Both the transmitting device 2101 and the receiving device 2102 hold a manufacturer certificate (see FIG. 10) including a manufacturer private key and a manufacturer public key corresponding to the manufacturer private key, and store the model ID. It is assumed that a model certificate (see FIG. 10) in which information included is protected by an electronic signature using a manufacturer private key is used.
  • the receiving device 2102 transmits a random challenge including a random number and the device certificate B of the receiving device 2102 together with the manufacturer certificate B and the model certificate B protected by the electronic signature with the manufacturer private key.
  • 2101 is sent to make an authentication request (P2111).
  • the transmitting device 2101 returns a response (RSP) to the command for sending the random challenge, but is not shown 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. When 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 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, and the receiving device 2102 is excluded.
  • 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 the authenticity verification fails. At this point, the authentication process is aborted.
  • the transmitting device 2101 checks whether the model ID included in the model certificate B is included in the exclusion target list. Details of the processing procedure for checking the manufacturer certificate and the model certificate will be described later. If the model ID is found in the exclusion target list, the authentication process is aborted at this point, and the receiving device 2102 is excluded.
  • the model certificate B In the case of a system that uses a combination of a device certificate and a model certificate, check whether the model certificate is correctly linked to the device certificate. For example, when the CC flag is provided in the device certificate B (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 within the range of the valid device ID value. Details of the processing procedure for checking the model certificate associated with the manufacturer certificate will be described later. If it is not possible to confirm that the model certificate B is associated with the device certificate B, the receiving device 2102 is known to be a product using parts that have been cross-flowed. At this point, the authentication process is aborted, and the receiving device 2102 is excluded.
  • 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 model ID of the receiving device 2102 are included in the exclusion list. If not, the receiving device receives a random challenge in which the manufacturer certificate A and the model certificate A protected by the electronic signature with the manufacturer private key are added in addition to the random number and the device certificate A of the transmitting device 2101 It returns to 2102 (P2112), and the authentication process is continued. The receiving device 2102 returns a response (RSP) to the command for sending the random challenge, but is not shown in FIG.
  • RSP response
  • 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 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.
  • the receiving device 2102 checks whether the device ID included in the device certificate A is 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, and the transmission device 2101 is excluded.
  • 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 the authenticity verification fails. At this point, the authentication process is aborted.
  • the receiving device 2102 checks whether the model ID included in the model certificate A is included in the exclusion target list. Details of the processing procedure for checking the manufacturer certificate and the model certificate will be described later. If the model ID is found in the exclusion target list, the authentication process is aborted at this point, and the transmitting device 2101 is excluded.
  • the model certificate A 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. If 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 it is within the range of the valid device ID value. Details of the processing procedure for checking the model certificate associated with the manufacturer certificate will be described later.
  • the transmitting device 2101 is a product using a part that has been cross-flowed. At this time, the authentication process is aborted and the transmitting device 2101 is excluded.
  • the transmitting device 2101 receives the information A for key sharing calculated by itself, the version number and generation information of the SRM stored in the transmitting device 2101, and the random number received from the receiving device 2102 by the random challenge (P2111).
  • a message with a signature in which an electronic signature using the device private key of the transmitting device 2101 itself is added to the information including the above information is transmitted to the receiving device 2102 (P2113a).
  • the receiving device 2102 returns a response (RSP) to the command for sending the signed message, but is not shown in FIG.
  • the receiving device 2102 may also check the version number of the SRM and call the SRM update process thereafter.
  • the receiving device 2102 When the receiving device 2102 fails to verify the signed message of the transmitting device 2101, the receiving device 2102 refuses to continue the authentication process. On the other hand, when the receiving device 2102 succeeds in verifying the signed message of the transmitting device 2101, the receiving device 2102 receives the information A for key sharing received from the transmitting device 2101 and the information B for key sharing calculated by itself. Based on both, an authentication key (Kauth) is calculated (Compute Auth key).
  • the receiving device 2102 receives the information B for key sharing calculated by itself, the version number and generation information of the SRM stored in the receiving device 2102, and the random number received from the transmitting device 2101 by the random challenge (P2112).
  • a message with a signature in which an electronic signature using the device private key of the receiving device 2102 itself is added to the information including the above information is transmitted to the transmitting device 101 (P2113b).
  • the transmitting device 2101 returns a response (RSP) to the command for sending the signed message, but is not shown in FIG.
  • the transmitting device 2101 may also check the version number of the SRM and call the SRM update process thereafter.
  • the transmitting device 2101 fails to verify the signed message of the receiving device 2102, the transmitting device 2101 refuses to continue the authentication process.
  • the transmitting device 2101 succeeds in verifying the signed message of the receiving device 2102, the information B for key sharing received from the receiving device 2102 and the information A for key sharing calculated by itself are transmitted. Based on both, an authentication key (Kauth) having the same value as that calculated on the receiving device 2102 side is calculated (Compute Auth key).
  • the transmitting device 2101 and the receiving device 2102 can share the authentication key (Kauth). Thereafter, the transmitting device 2101 and the receiving device 2102 can perform encrypted transmission of copyright-protected content using an encryption key shared based on the authentication key.
  • the validity period of the authentication key is defined in DTCP, and encrypted transmission of content using a secret key based on the same authentication key is limited to the validity 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 to exclude the authentication partner based on the model ID included in the authentication partner model certificate. Is shown. However, in the illustrated processing procedure, it is assumed that the system uses a combination of the model certificate and the manufacturer certificate shown in FIG. 10 together with the device certificate shown in FIG.
  • the device verifies the device certificate received from the authentication partner with the CA public key of the certificate authority, and further verifies the manufacturer certificate received from the authentication partner with the CA public key of the certificate authority (step S2201). If the authenticity verification of the manufacturer certificate has failed (No in step S2202), the device aborts the authentication process and excludes the authentication partner.
  • the device verifies the model certificate received from the authentication partner with the manufacturer public key included in the manufacturer certificate whose authenticity has been confirmed (step S2203).
  • the device aborts the authentication process and excludes the authentication partner.
  • the device subsequently stores the model ID included in the model certificate in the CRL Entries field of the SRM held by the device. It is checked whether or not the model ID exists in the stored exclusion target list (step S2205).
  • step S2206 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 process is aborted and the authentication partner is excluded.
  • FIG. 23 shows another processing procedure for determining whether or not the transmitting device 2101 and the receiving device 2102 should exclude the authentication partner based on the model ID included in the authentication partner's model certificate. Is shown in the form of a flowchart. However, in the illustrated processing procedure, the combination of the device certificate shown in FIG. 11, the manufacturer certificate shown in FIG. 10, and the model certificate shown in FIG. 13 (including information associated with the device certificate). It is assumed that the system uses
  • the device After verifying the device certificate received from the authentication partner with the CA public key of the certificate authority, the device further verifies the manufacturer certificate received from the authentication partner with the CA public key of the certificate authority (step S2301). If verification of the authenticity of the manufacturer certificate has failed (No in step S2302), the device aborts the authentication process and excludes the authentication partner.
  • the device verifies the model certificate received from the authentication partner with the manufacturer public key included in the manufacturer certificate whose authenticity has been confirmed (step S2303). If verification of the authenticity of the model certificate has failed (No in step S2304), the device aborts the authentication process and excludes the authentication partner.
  • the device checks the CC flag of the device certificate (step S2305). If the CC flag is set (Yes in step S2306), it can be seen that the device certificate being verified is a device certificate incorporated in a part (semi-finished product). It is checked whether the model certificate is associated with the device certificate received by the random challenge from the authentication partner (step S2307). Specifically, it is confirmed whether or not the device ID included in the device certificate is within a valid device ID value range indicated by the model certificate. If it cannot be confirmed that the model certificate is associated with the device certificate (No in step S2308), the device aborts the authentication process and excludes the authentication partner.
  • step S2306 When the CC flag is not set and the device certificate is not a part (semi-finished product) (No in step S2306), and when it is confirmed that the model certificate is linked to the device certificate (Yes in step S2308) Subsequently, the device has the model ID contained in the model certificate in the exclusion target list stored in the CRL Entries field of the SRM held by the device. It is checked whether or not (step S2309).
  • the device continues the authentication process with the authentication partner.
  • the authentication process is aborted and the authentication partner is excluded.
  • a common model ID is assigned to products of the same model, and in addition to the device ID of an unauthorized device that should be excluded, SRMs
  • the model ID can also be registered.
  • each device that performs authentication takes the mutual model ID as an anti-tampering measure and passes it to the authentication partner.
  • the model ID of the authentication partner is found in the SRM, the authentication is interrupted. All devices of the same model can be eliminated.
  • Manufacturers that manufacture and sell devices do not need to ensure continuity of device IDs for the same model by incorporating corresponding model IDs for each device of the same model. In other words, even if the device IDs of devices of the same model are discontinuous, all devices of the same model can be excluded by registering only a small amount of information called model ID in the SRM.
  • a device passes a model ID to an authentication partner, as a method for preventing tampering of the model ID, (1) a method of protecting the model ID with an electronic signature by a licensor or certificate authority, and (2) a licensor Has described two methods of protecting the model ID with an electronic signature using a private key issued to the licensee.
  • FIG. 19 which is one of the authentication methods including the already explained mechanism for excluding all devices of the same model, A modification to FIG. 20 will be described.
  • the model ID registered in the SRM is identification information determined so that different models have different IDs and unique information for each product model.
  • the model ID basically consists of a combination of product manufacturer name and model model number.
  • the licensor centrally manages the manufacturer names so that the manufacturer names are not duplicated between different manufacturers.
  • each manufacturer assigns model numbers to their product models so as not to overlap.
  • information such as the model version number and the provision date of the product model version may be added to the model ID.
  • the manufacturer name and the model number may be managed by the licensor in a unified manner, and other manufacturers may assign information such as other version numbers and provision dates.
  • the product manufacturer name does not change from model to model.
  • information such as the model model number changes for each model, or changes within the same model.
  • the CA digital signature for the manufacturer name is arranged at the end of the model ID including the manufacturer name and the model number.
  • the CA digital signature for the manufacturer name is arranged at the head of the model ID including the manufacturer name and the model model number.
  • the CA digital signature for the manufacturer name is arranged inside the model ID including the manufacturer name and the model number. As shown in FIG. 26, each information element of the model ID does not need to be seamlessly connected.
  • the CA digital signature for the manufacturer name is provided by the licensor and cannot be generated by the manufacturer of the licensee.
  • a device certificate (see FIG. 7) that protects information including the entire model ID with a CA electronic signature in that only the manufacturer name, which is part of the model ID information, is protected with a CA electronic signature. It is different from the model certificate (see FIG. 8). In other words, although limited to some information, the model ID is protected with a CA electronic signature.
  • a signed message that protects information including the model ID with an electronic signature using a device private key (see FIG. 9).
  • a model certificate (see FIG. 10) that protects information including a model ID with an electronic signature using a manufacturer private key.
  • the authenticating partner can reliably exclude the device including such a model ID.
  • the CA digital signature is applied only to the manufacturer name (that is, some information) in the model ID, but the data other than the manufacturer name in the model ID or the model A CA digital signature for the entire ID may be added to the model ID.
  • FIG. 27 schematically shows another example of an authentication protocol communication flow including a mechanism for excluding all devices of the same model.
  • a transmitting device 2701 corresponds to “Source”
  • a receiving device 2702 corresponds to “Sink”
  • the transmitting device 2701 and the receiving device 2702 can communicate via a network (not shown).
  • a communication procedure according to the full authentication protocol defined by DTCP is executed.
  • a third method for protecting the model ID that is, a method in which a CA digital signature for a manufacturer name is added to a model ID including a product manufacturer name and a model model number for distribution
  • Both the transmitting device 2701 and the receiving device 2702 hold a device certificate, a device private key (see FIG. 2), and a model ID (see FIGS. 24 to 26) with a CA electronic signature for the manufacturer name.
  • a device certificate that is, a device private key, and a model ID (see FIGS. 24 to 26) with a CA electronic signature for the manufacturer name.
  • 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) to the command for sending the 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. Also, the transmitting device 2701 extracts the device ID of the receiving device 2702 from the device certificate B and checks whether the device ID of the receiving device 2702 is included in the SRM exclusion list (Examine SRM on Device ID). If the device ID is found in the exclusion target list, the authentication process is aborted at this point, and the receiving device 2702 is excluded.
  • the transmitting device 2701 succeeds in verifying the authenticity of the device certificate B, and if the device ID of the receiving device 2702 is not in the exclusion target list, the transmitting device 2701 receives the random number and the device certificate A of the transmitting device 2701.
  • the included random challenge is returned to the receiving device 1902 (P2712), and the authentication process is continued.
  • the receiving device 1902 returns a response (RSP # 2) to the command for sending the random challenge.
  • 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 SRM exclusion target list (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 and the transmitting device 2701 is excluded. To do.
  • the transmitting device 2701 Upon successful verification of the authenticity of the device certificate B and SRM check of the device ID, the transmitting device 2701 calculates information (EC-DH key exchange first phase value) A for sharing the key with the receiving device 2702. To do. Also, when the receiving device 2702 succeeds in verifying the authenticity of the device certificate A and the SRM check of the device ID, information (EC-DH key exchange first phase value) B for sharing the key with the transmitting device 2701 is also obtained. calculate.
  • the transmitting device 2701 receives the information A for key sharing calculated by itself, the version number and generation information of the SRM stored in the transmitting device 1901, and the random number received from the receiving device 1902 by the random challenge (P2711). Is transmitted to the receiving device 2702 (P2713a).
  • the receiving device 2702 may also check the version number of the SRM, and call the SRM update process thereafter.
  • the receiving device 2702 refuses to continue the authentication process.
  • the receiving device 2702 receives information A for key sharing received from the transmitting device 2701 and the key sharing calculated by itself.
  • An authentication key (Kauth) is calculated based on both of the information B for (Compute Auth key).
  • the receiving device 2702 receives the encryption key B based on the secret data shared with the transmitting device 2701 by the EC-DH key exchange algorithm or the authentication key Kauth through the exchange of the EC-DH key exchange first phase value. Also calculate.
  • the result of processing the authentication key with a hash function such as SHA-2 can be used as the encryption key.
  • a hash function such as SHA-2
  • data other than the part used for sharing the encryption key for encrypted transmission of content, and the result of processing the data with a hash function should be used as the encryption key (The same applies hereinafter).
  • the receiving device 2702 When the receiving device 2702 encrypts the model ID with the CA digital signature for the manufacturer name of the receiving device 2702 itself with the encryption key B, the response (RSP) to the command for sending the message with the signature (P2713a) from the transmitting device 2701 is received. In step # 3), the data is transmitted to the transmission device 2701.
  • the receiving device 2702 receives the information B for key sharing calculated by itself, the version number and generation information of the SRM stored in the receiving device 1902, and the random challenge (P2712) from the transmitting device 2701.
  • a message with a signature in which an electronic signature with the device private key of the receiving device 2702 itself is added to the information including the random number is transmitted to the transmitting device 2701 (P2713b).
  • the transmission device 2701 verifies whether the signed message received from the reception device 2702 has been tampered with using the device public key included in the device certificate B received by the random challenge (P2711). . Note that the transmission / reception device 2701 may also check the version number of the SRM and call the SRM update process thereafter.
  • the transmitting device 2701 refuses to continue the authentication process.
  • the transmitting device 2701 receives information B for key sharing received from the receiving device 2702 and the key sharing calculated by itself.
  • the authentication key (Kauth) is calculated based on both of the information A for (Compute Auth key).
  • the transmitting device 2701 transmits an encryption key A based on secret data shared with the receiving device 2702 by an EC-DH key exchange algorithm or an authentication key Kauth through an EC-DH key exchange first phase value exchange. 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.
  • different secret values shared in advance by the transmitting device 2701 and the receiving device 2702 are connected to the input data to the hash function in the case of one encryption key A and the other encryption key.
  • changing the number of times the encryption key A and encryption key B are processed with the hash function for example, in the case of the encryption key B, the result of processing the hash function output again with the hash function is used).
  • the transmitting device 2701 decrypts the encrypted model ID and the CA electronic signature for the manufacturer name received as a response (RSP # 3) with the encryption key A (Decrypt B's Model-ID and signature). Then, the transmitting device 2701 verifies the authenticity of the CA digital signature for the manufacturer name (Verify B's Model-ID) using the CA public key of the certificate authority, and verifies the authenticity of the manufacturer name in the model ID. At the same time, it is checked whether the model ID of the receiving device 2702 is included in the SRM exclusion list (Examine SRM on Model-ID).
  • the transmitting device 2701 If at least one of the verification of the authenticity of the CA digital signature for the manufacturer name of the receiving device 2702 and the check of the model ID exclusion target list fails, the transmitting device 2701 aborts the authentication process at this point. Thus, the receiving device 2702 is excluded. On the other hand, when both the verification of the authenticity of the CA electronic signature for the manufacturer name of the receiving device 2702 and the check of the model ID exclusion target list are successful, the transmitting device 2701 adds the CA electronic signature to the manufacturer name of the transmitting device 2701 itself.
  • the model ID is encrypted with the encryption key A and included in a response (RSP # 4) to a command for sending a signed message (P2713b) from the receiving device 2702 and transmitted to the receiving device 2702.
  • the receiving device 2702 decrypts the encrypted model ID and the CA electronic signature for the manufacturer name received as a response (RSP # 4) with the encryption key B (Decrypt A's Model-ID and signature). Then, the receiving device 2702 verifies the authenticity of the CA electronic signature for the manufacturer name using the CA public key of the certificate authority (Verify A's Model-ID), and verifies the authenticity of the manufacturer name in the model ID. At the same time, it is checked whether the model ID of the transmission device 2701 is not included in the SRM exclusion target list (Examine SRM on Model-ID).
  • the receiving device 2702 If at least one of the verification of the authenticity of the CA digital signature for the manufacturer name of the transmitting device 2701 and the check of the model ID exclusion target list fails, the receiving device 2702 aborts the authentication process at this point. Thus, the receiving device 2702 is excluded.
  • the transmission device 2701 and the reception device 2702 can share an authentication key (Kauth). Thereafter, the transmitting device 2701 and the receiving device 2702 can perform encrypted transmission of copyright-protected content using an encryption key shared based on the authentication key.
  • the validity period of the authentication key is defined in DTCP, and encrypted transmission of content using a secret key based on the same authentication key is limited to the validity period of the authentication key.
  • both the transmitting device 2701 and the receiving device 2701 encrypt the CA digital signature for the model ID and the manufacturer name by using the response to the signed message from the authentication partner.
  • the encrypted information is transmitted, but such encrypted information may be transmitted by other methods.
  • each of the transmitting device 2701 and the receiving device 2701 can transmit the encryption information of the CA digital 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 to exclude the authentication partner based on the model ID transmitted as a response to the signed message of the authentication partner. Shown in format.
  • the device verifies the signed message received from the authentication partner with the device public key included in the device certificate received by the random challenge from the authentication partner (step S2801).
  • the device calculates an encryption key based on the secret data shared with the authentication partner or the authentication key Kauth by the EC-DH key exchange algorithm through the EC-DH key exchange first phase value exchange (step S2802). .
  • the device decrypts the CA digital signature for the encrypted model ID and manufacturer name included in the response from the authentication partner to the signed message transmitted by itself (step S2803).
  • the device verifies the authenticity of the CA electronic signature for the manufacturer name using the CA public key of the certificate authority, and verifies the authenticity of the manufacturer name in the model ID based on the CA electronic signature for the manufacturer name. (Step S2804). If verification of the authenticity of the manufacturer name has failed (No in step S2805), the device aborts the authentication process at this point to exclude the authentication partner.
  • step S2805 If the authenticity of the manufacturer name is successfully verified (Yes in step S2805), the device checks whether the model ID decoded in step S2803 is in the SRM exclusion list (step S2806). ).
  • the device continues the authentication process with the authentication partner. On the other hand, when the model ID is found in the exclusion target list, the device aborts the authentication process at this point to exclude the authentication partner.
  • a communication unit that communicates with an authentication partner; A control unit that controls authentication processing based on information transmitted to and received from the authentication partner via the communication unit; A holding unit that holds identification information that is common in products that have a common implementation of a predetermined function; Comprising The control unit causes the authentication partner to transmit the identification information in which measures for preventing falsification are taken during the authentication process.
  • Authentication device (2) The control unit transmits the identification information protected by a signature by a certificate authority to the authentication partner. The authentication device according to (1) above.
  • the holding unit holds a device certificate including the identification information and protected by a signature from a certificate authority, The control unit causes the device certificate to be transmitted to the authentication partner.
  • the authentication device according to (2) above.
  • the holding unit holds a second certificate that is different from the device certificate and includes the identification information and protected by a signature by a certificate authority, The control unit causes the second certificate to be transmitted to the authentication partner.
  • the holding unit further holds a device certificate including at least a device public key and a device private key corresponding to the device public key, The control unit causes the authentication partner 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.
  • the holding unit further holds a manufacturer private key and a manufacturer certificate issued for each manufacturer, The control unit causes the second certificate including the identification information and protected by a signature by the manufacturer private key to be transmitted to the authentication partner together with the manufacturer certificate; The authentication device according to (1) above.
  • the control unit transmits the identification information to the authentication partner in a phase of exchanging a device certificate with the authentication partner during the authentication process.
  • the authentication device according to any one of (2) to (4) and (6) above.
  • the holding unit includes a device certificate including information indicating that it is incorporated in a component, and information that is associated with the identification information and the device certificate, and is protected by a signature with a predetermined secret key. Keep the certificate of The control unit causes the device certificate and the second certificate to be transmitted to the authentication partner.
  • the authentication device includes a device ID of a component used in the authentication device, and the second certificate includes information on a range of valid device ID values.
  • the authentication device according to (8) above.
  • a communication unit that communicates with the authentication partner; A control unit that controls authentication processing 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 have a common implementation regarding a predetermined function; Comprising During the authentication process, the communication unit receives identification information for which tampering prevention measures have been taken from the authentication partner, The control unit verifies the authenticity of the received identification information and checks whether it exists in the list; Authentication device. (12) The communication unit receives the 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.
  • the communication unit receives a device certificate including the identification information of the authentication partner and protected by a signature from a certificate authority, The control unit verifies the authenticity of the device certificate with the public key of the certificate authority and checks the identification information included in the device certificate in the list.
  • the communication unit receives, from the authentication partner, a second certificate that includes identification information and is protected by a signature from a certificate authority, which is different from the device certificate of the authentication partner.
  • the control unit verifies the authenticity of the second certificate with the public key of the certificate authority and checks the identification information included in the second certificate with the list.
  • the communication unit receives, from the authentication partner, a message that includes at least a device certificate including the device public key of the authentication partner and a signature that includes identification information and is protected by a device private key corresponding to the device public key. And The control unit verifies the authenticity of the received message with the device public key and checks the identification information included in the message with the list.
  • the authentication device according to (11) above.
  • the communication unit includes a second certificate that includes identification information and is protected by a signature with a manufacturer private key issued to the manufacturer of the authentication partner, and a manufacturing issued to the manufacturer of the authentication partner. A user certificate from the authentication partner, The control unit verifies the authenticity of the received second certificate with a manufacturer public key included in the manufacturer certificate and checks the identification information included in the second certificate with the list.
  • the authentication device receives identification information from the authentication partner in a phase of exchanging a device certificate with the authentication partner during the authentication process.
  • the authentication device according to any one of (12) to (14) and (16).
  • the communication unit includes a predetermined private key including a device certificate of the authentication partner including information indicating that it is incorporated in a component, identification information of the authentication partner, and information associated with the device certificate. Receive a second certificate protected by the signature of 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.
  • the communication unit receives the device certificate including a device ID of a component used as the authentication partner and the second certificate including information on a valid device ID value range from the authentication partner. , The control unit confirms that a device ID included in the device certificate is within a range of a device ID value included in the second certificate;
  • the authentication device according to (18) above.
  • An authentication method for performing an authentication process based on information transmitted / received by an authentication device to / from an authentication partner The authentication device holds a list of identification information common to products to be excluded that have a common implementation related to a predetermined function, Receiving from the authentication partner identification information that has been tampered with; Verifying the authenticity of the received identification information; Checking whether the received identification information does not exist in the list; An authentication method.
  • the identification information includes at least information of a manufacturer name unique to each corresponding product manufacturer and information of a model model number assigned so as not to be duplicated in each manufacturer.
  • the authentication device according to any one of (1) to (9) and (11) to (19).
  • the identification information further includes information on the version of the corresponding product model.
  • the identification information further includes information related to the provision time of the version of the corresponding product model.
  • the holding unit holds the identification information including a first part, a second part, and a signature by a certificate authority for the first part,
  • the control unit encrypts the identification information and transmits it to the authentication partner during the authentication process.
  • the control unit encrypts the identification information using data shared in the process of generating an authentication key with the authentication partner or an encryption key calculated based on the authentication key.
  • the control unit causes the encrypted identification information to be transmitted in response to receiving a signed message from the authentication partner.
  • the control unit causes the encrypted identification information to be transmitted by a command transmitted after exchanging a signed message with the authentication partner.
  • the authentication device according to any one of (24) or (25) above.
  • the holding unit holds the list of the second part of the identification information including the first part and the second part
  • the communication unit receives, from the authentication partner, information obtained by encrypting the identification information and the signature of the certificate authority for the first part
  • the control unit decrypts the encrypted information, verifies the authenticity of the first part of the identification information based on the signature, and the second part of the identification information does not exist in the list
  • the control unit performs the decryption using data shared in the process of generating an authentication key with the authentication partner or an encryption key calculated based on the authentication key.
  • the communication unit receives the encrypted information in a response to the signed message transmitted to the authentication partner.
  • the authentication device according to any one of (28) or (29).
  • the communication unit receives the encrypted information by a command received after exchanging a signed message with the authentication partner.
  • the authentication device according to any one of (28) or (29).
  • the first part consists of information that is invariant to the manufacturer of the product, and the second part consists of variable information.
  • the authentication device according to any one of (24) to (31) above.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)

Abstract

La présente invention concerne, à l'aide d'une liste de sujets d'exclusion, l'exclusion efficace de tous les produits ayant la même mise en œuvre. L'invention concerne un dispositif d'authentification qui comprend : une unité de communication communiquant avec une partie à authentifier ; une unité de commande commandant un processus d'authentification, sur la base d'informations envoyées par la partie à l'authentification, et reçues de celle-ci, par l'intermédiaire de l'unité de communication ; une unité de retenue qui retient des informations d'identification communes aux produits ayant une mise en œuvre en commun concernant une fonction prescrite. L'unité de commande amène les informations d'identification protégées par une signature, exécutée par une autorité d'authentification, à être transmises à la partie à authentifier, et, lors de la mise en œuvre du processus d'authentification, amène les informations d'identification, sur lesquelles une mesure anti-falsification a été effectuée, à être transmises à la partie à authentifier.
PCT/JP2017/016093 2016-07-14 2017-04-21 Dispositif et procédé d'authentification WO2018012078A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2018527402A JP6791247B2 (ja) 2016-07-14 2017-04-21 認証装置及び認証方法、並びにコンテンツ送信装置

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2016-139766 2016-07-14
JP2016139766 2016-07-14
JP2016-208879 2016-10-25
JP2016208879 2016-10-25

Publications (1)

Publication Number Publication Date
WO2018012078A1 true WO2018012078A1 (fr) 2018-01-18

Family

ID=60952882

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/016093 WO2018012078A1 (fr) 2016-07-14 2017-04-21 Dispositif et procédé d'authentification

Country Status (2)

Country Link
JP (2) JP6791247B2 (fr)
WO (1) WO2018012078A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113037472A (zh) * 2021-02-25 2021-06-25 西安电子科技大学 一种基于接收端数量控制的数字内容保护方法
JP2022531815A (ja) * 2019-09-19 2022-07-12 華為技術有限公司 デバイス認証方法および装置

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006333520A (ja) * 1995-06-05 2006-12-07 Certco Inc マルチステップディジタル署名方法およびそのシステム
JP2007208897A (ja) * 2006-02-06 2007-08-16 Sony Corp 情報処理装置、情報記録媒体製造装置、情報記録媒体、および方法、並びにコンピュータ・プログラム
JP2009163676A (ja) * 2008-01-10 2009-07-23 Nec Corp 構成証明機器接続システム、検証端末、構成証明機器接続方法、及びプログラム
JP2010507285A (ja) * 2006-10-13 2010-03-04 マイクロソフト コーポレーション Ｕｐｎｐ認証及び認可
JP2011118855A (ja) * 2009-11-05 2011-06-16 Kyocera Mita Corp ファイル配信装置及びシステム並びにファイル配信プログラム
JP2014048983A (ja) * 2012-08-31 2014-03-17 Fujitsu Fsas Inc ネットワーク接続方法および電子機器

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006521591A (ja) * 2003-01-15 2006-09-21 コーニンクレッカ　フィリップス　エレクトロニクス　エヌ　ヴィ 埋め込みによる失効の伝達
JP2007215154A (ja) * 2006-01-12 2007-08-23 Matsushita Electric Ind Co Ltd 電子機器、機器認証管理方法および機器認証管理プログラム
JP2008004065A (ja) * 2006-05-23 2008-01-10 Matsushita Electric Ind Co Ltd 半導体装置、電子機器及び機器認証プログラム
JP2008131557A (ja) * 2006-11-24 2008-06-05 Matsushita Electric Ind Co Ltd 映像音声出力機器、認証処理方法及び映像音声処理システム
JP2009123002A (ja) * 2007-11-15 2009-06-04 Panasonic Corp 再生装置、機器認証確認方法及びプログラム
US9032494B2 (en) * 2011-11-10 2015-05-12 Sony Corporation Network-based revocation, compliance and keying of copy protection systems

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006333520A (ja) * 1995-06-05 2006-12-07 Certco Inc マルチステップディジタル署名方法およびそのシステム
JP2007208897A (ja) * 2006-02-06 2007-08-16 Sony Corp 情報処理装置、情報記録媒体製造装置、情報記録媒体、および方法、並びにコンピュータ・プログラム
JP2010507285A (ja) * 2006-10-13 2010-03-04 マイクロソフト コーポレーション Ｕｐｎｐ認証及び認可
JP2009163676A (ja) * 2008-01-10 2009-07-23 Nec Corp 構成証明機器接続システム、検証端末、構成証明機器接続方法、及びプログラム
JP2011118855A (ja) * 2009-11-05 2011-06-16 Kyocera Mita Corp ファイル配信装置及びシステム並びにファイル配信プログラム
JP2014048983A (ja) * 2012-08-31 2014-03-17 Fujitsu Fsas Inc ネットワーク接続方法および電子機器

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2022531815A (ja) * 2019-09-19 2022-07-12 華為技術有限公司 デバイス認証方法および装置
CN113037472A (zh) * 2021-02-25 2021-06-25 西安电子科技大学 一种基于接收端数量控制的数字内容保护方法

Also Published As

Publication number Publication date
JP6791247B2 (ja) 2020-11-25
JP2021007053A (ja) 2021-01-21
JPWO2018012078A1 (ja) 2019-04-25

Similar Documents

Publication Publication Date Title
US11743054B2 (en) Method and system for creating and checking the validity of device certificates
CN107566116B (zh) 用于数字资产确权登记的方法及装置
KR100912276B1 (ko) 하드웨어 식별에 기초한 디지털권 관리 방법을 이용한 전자소프트웨어 배포 방법 및 시스템
US6957344B1 (en) Manufacturing trusted devices
KR100746030B1 (ko) 권리 위임에 의해 권리 객체를 대리하여 생성하는 방법 및장치
CN101145906B (zh) 对单向网络中的接收终端进行合法性认证的方法及系统
JP5885178B2 (ja) 機器真贋判定システム、機器真贋判定方法、および半導体チップが搭載された組み込み機器
KR100895462B1 (ko) 디지털 저작권 관리 시스템에서의 콘텐츠 유통 관리 방법
KR101495535B1 (ko) 컨텐츠 디바이스의 폐기 여부를 확인하여 데이터를전송하는 전송 방법과 시스템, 데이터 서버
US20110299679A1 (en) Controller, control method, computer program, recording medium for computer program, recording apparatus, and manufacturing method for recording apparatus
CN104580250A (zh) 一种基于安全芯片进行可信身份认证的系统和方法
KR20070046982A (ko) 하드웨어 식별에 기초한 디지털권 관리 시스템
CN102427449A (zh) 一种基于安全芯片的可信移动存储方法
US20140369496A1 (en) Key implementation system
KR100502580B1 (ko) 보안성이 향상된 디지털 컨텐츠 유통 방법
CN104484584A (zh) 一种基于三维打印设备的三维模型版权保护的方法
CN101694685A (zh) 采用基于xml加密和数字证书的安全产品许可证管理方法
CN103186723B (zh) 数字内容安全协作的方法和系统
JP2021007053A (ja) コンテンツ送信方法
KR20080021423A (ko) 권한 재위임에 의해 권리 객체를 생성하는 방법 및 그 장치
KR20100114321A (ko) 디지털 콘텐츠 거래내역 인증확인 시스템 및 그 방법
CN101286987B (zh) 一种转移软件授权许可的方法
CN202276360U (zh) 一种基于安全芯片的可信移动存储系统
KR100834754B1 (ko) 실행흐름 측정 및 검증이 가능한 프로그램 배포 방법
CN102236753A (zh) 版权管理方法及系统

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 2018527402

Country of ref document: JP

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17827212

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17827212

Country of ref document: EP

Kind code of ref document: A1