EP4115586A1 - Procédé et dispositif de certification d'une clé spécifique à une application et demande d'une certification de ce type - Google Patents

Procédé et dispositif de certification d'une clé spécifique à une application et demande d'une certification de ce type

Info

Publication number
EP4115586A1
EP4115586A1 EP21727351.5A EP21727351A EP4115586A1 EP 4115586 A1 EP4115586 A1 EP 4115586A1 EP 21727351 A EP21727351 A EP 21727351A EP 4115586 A1 EP4115586 A1 EP 4115586A1
Authority
EP
European Patent Office
Prior art keywords
certificate
application
specific
authentication
key
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP21727351.5A
Other languages
German (de)
English (en)
Inventor
Christoph BURGER-SCHEIDLIN
Kai HELBIG
Johannes EBKE
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Robert Bosch GmbH
Original Assignee
Robert Bosch GmbH
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 Robert Bosch GmbH filed Critical Robert Bosch GmbH
Publication of EP4115586A1 publication Critical patent/EP4115586A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/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
    • H04L9/3247—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 involving digital 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
    • H04L9/3263—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 involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—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 involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • 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/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3066—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves
    • H04L9/3073—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves involving pairings, e.g. identity based encryption [IBE], bilinear mappings or bilinear pairings, e.g. Weil or Tate pairing
    • 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
    • H04L9/3263—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 involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3265—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 involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate chains, trees or paths; Hierarchical trust model
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/64—Self-signed certificates

Definitions

  • the present invention relates to a method for certification of an application-specific key and a method for requesting such certification, as well as a processing unit and a computer program for performing it.
  • Encrypted communication is an essential part of modern, secure communication. In situations in which previously unknown communication partners meet, encryption can only contribute to security if the identity of the communication partner can be ensured. If this is not the case, an attacker can install himself as part of a communication chain and thus decrypt and read the communication (man-in-the-middle attacks).
  • cryptographic certificates are used in modern data traffic to identify the communication partner. Such a certificate is used to identify the owner of a specific cryptographic public key and thus the associated key pair.
  • CSR Certificate Signing Request'
  • This request includes data about the person or entity to be authenticated, e.g. the name.
  • the CA carries out a corresponding identity check on the basis of this data and creates the requested certificate if the check is successful.
  • the certificate contains the public key of the requesting unit, the certificate usually being digitally signed by the trustworthy body. The certificate issued can thus indicate that the trustworthy body has checked the unit to be authenticated, so that all communication partners who trust the trustworthy body can consider this check to be successful on the basis of the certificate.
  • Devices can also be equipped with certificates in this way.
  • the manufacturer of the device has a manufacturer certificate with special authorization to form a trustworthy body (local CA), the manufacturer certificate preferably being issued by an existing Certification Authority (CA).
  • CA Certification Authority
  • a device certificate and an associated secret key are generated. Different features suitable for identifying a device can be used, e.g. a serial number. It is common for the process to be carried out locally by the manufacturer during the manufacture of the devices, with the secret key preferably being generated directly in the device.
  • the device certificate is then signed by means of the manufacturer certificate and, if necessary, applied to the device together with the key belonging to the device certificate.
  • the confidentiality of the secret key is of fundamental importance in all cryptographic systems.
  • a communication partner can only be trusted as long as the secret key remains secret.
  • specialized hardware can be used to ensure particularly secure storage of the keys.
  • Access control to the keys is particularly important for external additional components such as external applications (apps), since not every application can be trusted to the same extent. For example, for an application that can carry out banking transactions, it is of particular importance that no other application on the device has access to the secret key used.
  • a key attestation procedure for example, can be used for this purpose.
  • the properties of a generated key or key pair are confirmed by certification.
  • a third party such as a network service, can then ensure that a key is stored in a secure hardware component and that only one application has access to the key.
  • the generated key can be authenticated by a trustworthy component that usually comes from the manufacturer of the device.
  • This trustworthy component certifies an exact description of the associated secret key, its access controls, its storage in secure hardware and, if necessary, an "Attestation Challenge" of the network service in an authentication certificate or "Attestation Certificate”.
  • the certificates issued in this way are not suitable to be accepted as proof of identity for external services, since the certificate on the device does not correspond to a local certification authority.
  • the invention creates a simple system for the safe use, in particular, of modules and applications that have been applied subsequently.
  • a method for certification of an application-specific cryptographic key e.g. in a certificate exchange service, which comprises the following steps: receiving a cryptographic authentication certificate for an application-specific public key from an application in a device; Checking the validity of the authentication certificate; and if the authentication certificate has been recognized as valid, comparing at least part of the information extracted from the authentication certificate with predetermined reference information, and if the comparison shows that a new certificate is to be created, forming a new application-specific certificate, which comprises at least the application-specific public key extracted from the authentication certificate and at least part of the information from the authentication certificate; and sending the new application-specific certificate to the application.
  • an application can receive an external certificate for a generated key pair, which the application marks as trustworthy for other services. Since initially only the authentication certificate and no queries or information generated by the application (initially not yet identified as secure) are used, the issue of the new certificate is based only on data validated by the device system. This centralizes the checking of the information in the authentication certificate and the application makes it possible to use cloud systems or software packages that do not support any further checking of information in the device's own certificates.
  • the checking of the validity of the authentication certificate can in particular include the validation of a device-specific certificate chain which is linked to the authentication certificate and was received together with the authentication certificate, the certificate chain comprising one or more intermediate certificates and the last intermediate certificate being signed by a manufacturer certificate of the device and checking the signature of the last intermediate certificate on the basis of one or more stored manufacturer certificates.
  • an implicit trustworthy chain (“Chain of Trust”) can be established from the application via the certificate exchange service to the manufacturer, which is then used by all network services that trust the certificate exchange service and up to can be validated for the certificate of the certificate exchange service.
  • the network services used only have to trust the certificate exchange service and do not have to check the chain to the manufacturer themselves.
  • the newly issued certificate itself no longer has to be explicitly linked to the device authentication certificate or the manufacturer certificate.
  • it can be further checked whether the authentication certificate has already been received and / or checked at an earlier point in time, and if this is the case, the result can be sent that was created for the authentication certificate at an earlier point in time.
  • This can be a previously issued application-specific certificate or a message about an invalid check of the data.
  • an error message can be sent or the process can be canceled without a message.
  • one or more key parameters for generating a key pair can also be sent to the application in response to the establishment of a connection by an application with the certificate exchange service, the key pair to be generated comprising an application-specific secret and the application-specific public key.
  • a challenge can be sent to the application in response to a connection being established by an application. After receiving the authentication certificate, it can then be checked whether the received authentication certificate includes the challenge sent by extracting the challenge from the authentication certificate and validating the challenge with an associated response. If the received certification certificate does not include the challenge sent, i.e. there is no challenge or the validation cannot be carried out successfully, the certification process can be aborted or terminated again.
  • Such a challenge can ensure a close temporal connection between the creation of the authentication certificate in the device and the use of the certificate exchange service, i.e. the creation of a new application-specific certificate. An older authentication certificate that was created before the connection was established cannot then contain a valid challenge. It goes without saying that a new, unique challenge can preferably be used for each query.
  • Such information can be predetermined or from a certain suitable, even distant, place to be available. It can, for example, be data for the licensing of the application or a restriction of the certificate to a single service or to exactly one service for which the certificate is to be valid.
  • a method for requesting certification for an application-specific key pair by an application in a device comprises the following steps: generating an application-specific cryptographic key pair, which comprises a secret application-specific key and a public application-specific key; Obtaining an authentication certificate for the application-specific key pair from an authentication module in the device; Sending the authentication certificate to a certificate exchange service; Obtaining a new application-specific certificate for the key pair from the certificate exchange service, the new application-specific certificate comprising at least the public application-specific key and further information.
  • Sending the authentication certificate can include sending a certificate chain linked to the authentication certificate to the certificate exchange service, the certificate chain comprising one or more intermediate certificates and the last intermediate certificate being signed by a manufacturer certificate of the device.
  • the manufacturer certificate itself does not have to be transmitted.
  • the request to the certificate exchange service therefore also remains relatively small, so that no large amounts of data are required and the method can also be used, for example, in hardware-based systems with limited resources.
  • key parameters can be received from the certificate exchange service, which are then to be used for the local generation of the application-specific key pair.
  • the authentication certificate can include, for example, one or more of the following information: a unique identifier of the device, a signature of the application, information on the validity of system files of the device, information about the application-specific public key and / or about an associated application-specific secret Key.
  • a unique identifier of the device e.g., a unique identifier of the device
  • a signature of the application e.g., information on the validity of system files of the device
  • information about the application-specific public key and / or about an associated application-specific secret Key e.g., a unique identifier of the device, a signature of the application, information on the validity of system files of the device, information about the application-specific public key and / or about an associated application-specific secret Key.
  • the generation and storage methods for the keys or other information can also be contained in the certificate.
  • a computing unit for example a processor or a virtual machine in a data processing device, is set up, in particular in terms of programming, to carry out a method according to the invention.
  • Suitable data carriers for providing the computer program are, in particular, magnetic, optical and electrical memories, such as hard drives, flash memories, EEPROMs, DVDs, etc.
  • a program can also be downloaded via computer networks (Internet, intranet, etc.).
  • FIG. 1 shows an exemplary system in which various certificates and keys can be created and checked in accordance with exemplary embodiments
  • FIG. 2 shows an exemplary sequence of process steps in a possible embodiment.
  • FIG. 1 shows an exemplary system in which, according to an exemplary embodiment of the invention, various cryptographic certificates can be created and checked.
  • a device 10 for example a user terminal, which comprises at least one computing unit for data processing, such as a suitable processor and storage elements as well as other elements.
  • the terminal can comprise communication means, which, among other things, a communication can have communication interface to other devices in order to send and receive data using suitable protocols.
  • the communication means can be connected to the computing unit, memory elements and other elements. In this way, the terminal can be integrated into one or more networks, for example, and communicate with the services of these networks (not shown).
  • Program modules or applications that can be executed by a processing unit can be present in the device 10, whereby in particular one or more applications 20 can also be present that were subsequently introduced into the terminal, e.g. as an application subsequently installed by a user.
  • Such an application 20 is now to be certified as trustworthy and secure for internal and external services, e.g. for network services communicating with the application. It should therefore be possible for the services to ensure that communication takes place with a special, subsequently applied application that has not been changed or replaced.
  • the certification can take place specifically in connection with the respective device 10 on which the application 20 is installed. For example, it is also possible to assign a device in a network service.
  • a manufacturer-dependent manufacturer certificate 12 can initially be present on the device 10, which contains manufacturer-specific information and has preferably already been applied to the device 10 by the manufacturer.
  • the device is provided by the manufacturer with a secret, device-specific key 16, which can be used to generate authentication certificates (Attestati on), and an associated, device-specific device authentication certificate 14, 'Device Attestation Certificate', which contains device-specific information.
  • the device authentication certificate 14 can be signed either directly or indirectly, ie with further intermediate certificates, by the manufacturer certificate 12, step 40 in FIG. at least includes the manufacturer certificate 12 and the device authentication certificate 14 as the last certificate in the chain.
  • the manufacturer certificate does not necessarily have to be present on the device as long as it is present in the certificate exchange service 30 and can be identified by a unique identifier.
  • the application 20 can now generate a cryptographic asymmetric key pair 18 in step 110, for example by using a corresponding interface with the device that is able to generate such keys, e.g. the 'Android KeyStore API' or another suitable key generation module implemented on the device.
  • the application can then request authentication of the generated key pair from the device in step 112, so that a corresponding module on the device issues an authentication certificate 22 for the application-specific key in step 114 and signs it with the device authentication certificate 14, step 42.
  • the authentication certificate 22 for the application-specific key at least the public key of the application-specific key pair and various information for identifying the key and / or the device are available. In this way, the authentication certificate 22 generated in this way for the application-specific key is also incorporated into the trustworthy chain.
  • the associated secret application-specific key 18 is stored in a suitable manner by the application and / or the key generation module on the device 10.
  • This authentication certificate 22 generated in the device for the application-specific key can now be passed on to the application (step 116) and transmitted from the application to a certificate exchange service 30 in step 120, for example using appropriate wireless or wired communication means and optionally also interconnected networks .
  • this certificate exchange service 30 can form a trustworthy body that can create and sign application-specific certificates.
  • the certificate exchange service 30 receives the authentication certificate 22 for the application-specific key in step 130, it can check its signature chain in step 136.
  • the application can preferably transmit each certificate in the chain to the certificate exchange service in order to check the entire chain.
  • the data transmission 120 of the application to the certificate exchange service can thus include the authentication certificate 22, the underlying device authentication certificate 14 and optionally further intermediate certificates of a trustworthy chain above the manufacturer certificate for validation of the entire chain.
  • no further information other than the certificates is preferably transmitted, with the manufacturer certificate 12 itself usually not being transmitted either.
  • the manufacturer certificates are present as part of the trustworthy certificates 32 in the certificate exchange service and thus enable the last certificate or intermediate certificate of the chain that was signed by the manufacturer certificate to be checked.
  • the sending application 20 can optionally sign the data transmission 120, i.e. the transmitted certificates, with its own communication key and / or encrypt it cryptographically. Conversely, the application in particular should be able to correctly identify the certificate exchange service. Additionally or alternatively, the authentication certificate 22 for the application-specific key, which was created and signed by the corresponding authentication module of the device for the application-specific key, may include information about the application 20 which generated the authenticated key and requested the authentication certificate .
  • the check of the certificate chain can be considered to have failed.
  • the processing of the transmitted authentication certificate can be canceled and, optionally, a message can also be sent to the sending application 20 indicating that none valid certificate chain is available.
  • the appropriate manufacturer certificate from the trustworthy certificates 32 can uniquely identify the manufacturer.
  • step 136 various information can now be extracted by the certificate exchange service 30 from the transmitted authentication certificate.
  • relevant information can first be taken that can be used to check in step 138 whether the sending application 20 and / or the device 10 used are trustworthy. It can be specified in the certificate exchange service which information is to be used for this check 138. Information can also be specified which is only to be used optionally for the check and whose validation can also be omitted.
  • Examples of information that can be taken from the authentication certificate and checked are, for example, a serial number or another identifier for the unambiguous identification of a device; an identifier (which is as tamper-proof as possible) for unambiguous identification, e.g. of a specific version of an application; Information on system files of the device, e.g. information on whether a specified group of system files is unchanged and undamaged (verified boot); and more. This information can be compared with information stored in the certificate exchange service 30 or retrieved from it from another location in order to validate it.
  • the application-specific public key can be extracted from the authentication certificate. It goes without saying that the information does not necessarily have to be extracted from the certificate in this order. For example, it is possible to only remove the key when the previous comparison of the information from the authentication certificate was successful, or alternatively to extract the key with the remaining information before the check.
  • a new certificate can be created in step 140 36.
  • further information can also be evaluated, for example information about the application 20 which is requesting the certificate.
  • license information can be available to the certificate exchange service, which indicates whether a valid license has been acquired for this application and optionally also how long this license is valid. Using this information, a certificate 24 created by the certificate exchange service can then be restricted to the validity of the license or, for example, the issuance of the certificate can be completely prevented if there is no valid license.
  • the certificate exchange service which issues the new application-specific certificate, can alternatively or additionally store such data for licensing locally and on this basis, for example, keep a list or other data available for a network service, in which it is indicated whether an already issued one new certificate is still valid.
  • the process can be canceled again and / or canceled with a corresponding error message to the requesting application.
  • the certificate exchange service can now create the new, application-specific certificate 24 in step 140 and sign it with its own secret key, which is provided for the certification.
  • the new application-specific certificate 24 contains the public application-specific key and other relevant information. This can be, for example, the checked information from the authentication certificate 22, or all information that was contained in the authentication certificate or only a subset thereof. In addition, further information can be incorporated into the application-specific certificate, which is available for the certificate exchange. eg a period of validity based on the license data described above. It can also be stated that the certificate is only valid for communication with one or more specific network services.
  • the certificate exchange service can then send the new application-specific certificate 24 to the application 20 in step 150.
  • the application 20 can now store this certificate together with the associated, application-specific secret key 18 in step 160 and use the certificate 24 for mutual authentication in the future for services that trust the certificate exchange service. If the application-specific certificate 24 is restricted to certain services, the application can also select the respective certificate suitable for a service from a group of stored certificates. For this purpose, the application 20 and / or the device 10 can store the certificate 24 in suitable memory modules.
  • a specification can be stored in the certificate exchange service 30 which specifies which data are to be retrieved from the authentication certificate and which data are to be integrated into a new application-specific certificate 24.
  • This specification can also optionally be changed from another point and / or can be different for different applications.
  • the certificate exchange service can also carry out a check in an additional step 134 at the beginning of the method, that is to say after receiving 130 the authentication certificate for the application-specific key, as to whether an identical certificate has already been sent.
  • the certificate exchange service can, for example, store all previous authentication certificates received for exchange in a suitable manner, locally or retrievable in some other way, so that a comparison is possible. Initially, only a single or a few data elements of the authentication certificate can be compared. If the check reveals that an identical certificate was received earlier, it can be stipulated that, for example, the old result (e.g. an application certificate issued as a result or a message about an invalid certificate chain) is returned to the addressee. application that sent the authentication certificate. Alternatively, an error message can be output and sent to the application.
  • the old result e.g. an application certificate issued as a result or a message about an invalid certificate chain
  • the certificate exchange service 30 can, for example, additionally replace a method such as a challenge-response method, so that when the connection is established between the device and the certificate exchange service, a corresponding challenge in step 104 and / or certain key parameters in step 102 sent to the application.
  • the application can create an application-specific key pair, with the key parameters used by the certificate exchange service or a part thereof being able to be used to generate the key.
  • an authentication certificate can be issued by the device for the generated keys, in which the challenge received should also be included.
  • the authentication certificate created in this way can then be sent again in steps 116, 120 to the certificate exchange service, where the challenge is validated in step 132.
  • Any suitable challenges known to a person skilled in the art are possible as a challenge. If the challenge is checked successfully, the further checking of the authentication certificate and the issuing of the new certificate can take place as described above in accordance with the following steps 134 to 150.
  • Sending challenge 104 during connection establishment 100 e.g. during a handshake), which is included in the authentication certificate, ensures that a temporal relationship between the key generation and / or the creation 114 of the authentication certificate and the creation 140 of a new application-specific certificate is maintained will.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Algebra (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Physics (AREA)
  • Pure & Applied Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention concerne un procédé de certification d'une clé cryptographique spécifique à une application dans un service d'échange de certificats (30), ledit procédé comprenant les étapes suivantes : Recevoir (130), d'une application (20) dans un dispositif (10), un certificat d'authentification (22) cryptographique pour une clé publique spécifique à l'application, vérifier (34 ; 136) la validité du certificat d'authentification (22) et si ledit certificat d'authentification (22) a été reconnu comme valide, comparer (34 ; 138) au moins une partie des informations, qui ont été extraites du certificat d'authentification (22), avec des informations de référence prédéfinies, et si la comparaison indique qu'un nouveau certificat doit être établi, établir un nouveau certificat (24) spécifique à l'application, lequel comprend au moins la clé publique spécifique à l'application extraite du certificat d'authentification (22) et au moins une partie des informations provenant du certificat d'authentification, envoyer (150) le nouveau certificat spécifique à l'application (24) à l'application (20), l'invention concernant également un procédé de demande d'une certification de ce type.
EP21727351.5A 2020-03-06 2021-03-02 Procédé et dispositif de certification d'une clé spécifique à une application et demande d'une certification de ce type Pending EP4115586A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102020202879.6A DE102020202879A1 (de) 2020-03-06 2020-03-06 Verfahren und Vorrichtung zur Zertifizierung eines anwendungsspezifischen Schlüssels und zur Anforderung einer derartigen Zertifizierung
PCT/DE2021/100209 WO2021175372A1 (fr) 2020-03-06 2021-03-02 Procédé et dispositif de certification d'une clé spécifique à une application et demande d'une certification de ce type

Publications (1)

Publication Number Publication Date
EP4115586A1 true EP4115586A1 (fr) 2023-01-11

Family

ID=76076177

Family Applications (1)

Application Number Title Priority Date Filing Date
EP21727351.5A Pending EP4115586A1 (fr) 2020-03-06 2021-03-02 Procédé et dispositif de certification d'une clé spécifique à une application et demande d'une certification de ce type

Country Status (8)

Country Link
US (1) US20230155842A1 (fr)
EP (1) EP4115586A1 (fr)
KR (1) KR20220153602A (fr)
CN (1) CN115280719A (fr)
CA (1) CA3169475A1 (fr)
DE (2) DE102020202879A1 (fr)
TW (1) TW202139037A (fr)
WO (1) WO2021175372A1 (fr)

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9654463B2 (en) * 2014-05-20 2017-05-16 Airwatch Llc Application specific certificate management
DE102015201599A1 (de) 2015-01-30 2016-08-04 Robert Bosch Gmbh Datenverarbeitungssystem und Verfahren
DE102015208176A1 (de) * 2015-05-04 2016-03-24 Siemens Aktiengesellschaft Gerät und Verfahren zur Autorisierung eines privaten kryptographischen Schlüssels in einem Gerät
US9916452B2 (en) * 2016-05-18 2018-03-13 Microsoft Technology Licensing, Llc Self-contained cryptographic boot policy validation
JP7208707B2 (ja) * 2017-02-17 2023-01-19 キヤノン株式会社 情報処理装置及びその制御方法とプログラム
US10397005B2 (en) * 2017-03-31 2019-08-27 Intel Corporation Using a trusted execution environment as a trusted third party providing privacy for attestation
US9992029B1 (en) * 2017-04-05 2018-06-05 Stripe, Inc. Systems and methods for providing authentication to a plurality of devices

Also Published As

Publication number Publication date
DE102020202879A1 (de) 2021-09-09
CN115280719A (zh) 2022-11-01
WO2021175372A1 (fr) 2021-09-10
TW202139037A (zh) 2021-10-16
US20230155842A1 (en) 2023-05-18
DE112021001486A5 (de) 2023-01-12
KR20220153602A (ko) 2022-11-18
CA3169475A1 (fr) 2021-09-10

Similar Documents

Publication Publication Date Title
EP3157281B1 (fr) Procédé de communication protégée dans un véhicule
EP3731119B1 (fr) Procédé mis en uvre par ordinateur destiné au contrôle d'accès
DE102011081804B4 (de) Verfahren und System zum Bereitstellen von gerätespezifischen Betreiberdaten, welche an ein Authentisierungs-Credential gebunden werden, für ein Automatisierungsgerät einer Automatisierungsanlage
EP2338255B1 (fr) Méthode, produit logiciel et système d'authentification d'un utilisateur d'un réseau de télécommunication
DE102012224421A1 (de) Fahrzeuggebundenes system und kommunikationsverfahren
EP4357945A2 (fr) Procédé de lecture d'un attribut à partir d'un jeton id
EP2446390B1 (fr) Système et procédé pour authentifier de manière fiable un appareil
DE102008042262A1 (de) Verfahren zur Speicherung von Daten, Computerprogrammprodukt, ID-Token und Computersystem
EP3699791B1 (fr) Contrôle d'accès comprenant un appareil radio mobile
EP3909221B1 (fr) Procédé pour fournir en toute sécurité une identité électronique personnalisée sur un terminal
EP3417395B1 (fr) Détermination de l'authenticité d'un appareil à l'aide d'un certificat d'autorisation
WO2015132403A1 (fr) Système de sécurité à contrôle d'accès
EP3908946B1 (fr) Procédé pour fournir en toute sécurité une identité électronique personnalisée sur un terminal
EP3321832A1 (fr) Distribution de lecture d'attributs à partir d'un jeton d'identification
DE102008042582A1 (de) Telekommunikationsverfahren, Computerprogrammprodukt und Computersystem
EP3244360A1 (fr) Procede d'enregistrement d'appareils, en particulier de dispositifs de controle d'acces ou{j}d'automates de vente ou d'achat dans un serveur d'un systeme comprenant plusieurs desdits appareils
EP3244331B1 (fr) Procédé de lecture d'attributs à partir d'un jeton d'identification
EP4115586A1 (fr) Procédé et dispositif de certification d'une clé spécifique à une application et demande d'une certification de ce type
EP3125464B1 (fr) Service de révocation pour un certificat généré par un jeton d'id
EP3271855B1 (fr) Procédé de génération d'un certificat pour un jeton de sécurité
EP2381712B1 (fr) Lecture sécurisée de données à partir d'un appareil mobile avec TPM fixe
EP4115584B1 (fr) Accès sécure et documenté d'une application à une clé
EP3244332B1 (fr) Procédé de lecture d'attributs à partir d'un jeton d'identification
DE102018132979A1 (de) Abgesichertes und intelligentes Betreiben einer Ladeinfrastruktur
DE102009053230A1 (de) Verfahren zur Autorisierung eines externen Systems auf einem Steuergerät eines Fahrzeugs, insbesondere eines Kraftfahrzeugs

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20221006

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)