WO2021175372A1 - Verfahren und vorrichtung zur zertifizierung eines anwendungsspezifischen schlüssels und zur anforderung einer derartigen zertifizierung - Google Patents

Verfahren und vorrichtung zur zertifizierung eines anwendungsspezifischen schlüssels und zur anforderung einer derartigen zertifizierung Download PDF

Info

Publication number
WO2021175372A1
WO2021175372A1 PCT/DE2021/100209 DE2021100209W WO2021175372A1 WO 2021175372 A1 WO2021175372 A1 WO 2021175372A1 DE 2021100209 W DE2021100209 W DE 2021100209W WO 2021175372 A1 WO2021175372 A1 WO 2021175372A1
Authority
WO
WIPO (PCT)
Prior art keywords
certificate
application
specific
authentication
key
Prior art date
Application number
PCT/DE2021/100209
Other languages
English (en)
French (fr)
Inventor
Christoph BURGER-SCHEIDLIN
Kai HELBIG
Johannes EBKE
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
Priority to EP21727351.5A priority Critical patent/EP4115586A1/de
Priority to CA3169475A priority patent/CA3169475A1/en
Priority to CN202180019378.4A priority patent/CN115280719A/zh
Priority to KR1020227034161A priority patent/KR20220153602A/ko
Priority to DE112021001486.2T priority patent/DE112021001486A5/de
Priority to US17/909,487 priority patent/US20230155842A1/en
Publication of WO2021175372A1 publication Critical patent/WO2021175372A1/de

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/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/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/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.

Abstract

Die Erfindung betrifft ein Verfahren zur Zertifizierung eines anwendungsspezifischen kryptographischen Schlüssels in einem Zertifikatsaustauschdienst (30), umfassend: Empfangen (130), von einer Anwendung (20) in einer Vorrichtung (10), eines kryptographischen Beglaubigungszertifikats (22) für einen anwendungsspezifischen öffentlichen Schlüssel; Prüfen (34; 136) der Gültigkeit des Beglaubigungszertifikats (22); und falls das Beglaubigungszertifikat (22) als gültig erkannt wurde, Vergleichen (34; 138) von zumindest einem Teil von Informationen, die aus dem Beglaubigungszertifikat (22) extrahiert wurden, mit vorgegebenen Referenzinformationen, und falls der Vergleich ergibt, dass ein neues Zertifikat erstellt werden soll, Bilden (36; 140) eines neuen anwendungsspezifischen Zertifikats (24), welches mindestens den aus dem Beglaubigungszertifikat (22) extrahierten anwendungsspezifischen öffentlichen Schlüssel und zumindest einen Teil der Informationen aus dem Beglaubigungszertifikat umfasst; Senden (150) des neuen anwendungsspezifischen Zertifikats (24) an die Anwendung (20), sowie ein Verfahren zur Anforderung einer derartigen Zertifizierung.

Description

Beschreibung
Titel
Verfahren und Vorrichtung zur Zertifizierung eines anwendungsspezifischen
Schlüssels und zur Anforderung einer derartigen Zertifizierung
Die vorliegende Erfindung betrifft ein Verfahren zur Zertifizierung eines anwen dungsspezifischen Schlüssels und ein Verfahren zur Anforderung einer derarti gen Zertifizierung, sowie eine Recheneinheit und ein Computerprogramm zu de ren Durchführung.
Stand der Technik
Verschlüsselte Kommunikation ist ein essentieller Bestandteil moderner, sicherer Kommunikation. In Situationen, in denen sich zuvor unbekannte Kommunikati onspartner begegnen, kann Verschlüsselung aber nur dann zur Sicherheit bei tragen, wenn die Identität des Kommunikationspartners sichergestellt werden kann. Ist dies nicht der Fall, kann ein Angreifer sich als Teil einer Kommunikati onskette installieren und so die Kommunikation entschlüsseln und mitlesen (Man-in-the-Middle-Angriffe).
Daher werden im modernen Datenverkehr kryptographische Zertifikate verwen det, um den Kommunikationspartner zu identifizieren. Mit einem solchen Zertifi kat wird der Eigentümer eines bestimmten kryptographischen öffentlichen Schlüssels und damit des zugehörigen Schlüsselpaars identifiziert. Grundsätzlich ist es möglich, beide Partner einer Kommunikation durch Zertifikate zu validieren. Im 'World Wide Web' wird jedoch in der Regel nur der Server im Web validiert, von den Clients (d.h. vom Browser des Benutzers) wird kein Zertifikat verlangt. Zertifikate werden von speziellen, besonders vertrauenswürdigen Stelle, den 'Certification Authorities' (CA) ausgestellt. Jeder Kommunikationspartner vertraut bestimmten dieser vertrauenswürdigen Stellen und akzeptiert von diesen jedes zeitlich gültige Zertifikat, das bestimmten Kriterien genügt. Zertifikate werden da bei auf Basis einer Anfrage ('Certificate Signing Request', CSR) an die vertrau enswürdige Stelle bzw. CA erstellt. Diese Anfrage umfasst Daten über die zu au thentifizierende Person bzw. Einheit, z.B. den Namen. Die CA führt auf Basis dieser Daten eine entsprechende Identitätsprüfung durch und erstellt das ange forderte Zertifikat, falls die Prüfung erfolgreich ist. In dem Zertifikat ist der öffentli che Schlüssel der anfragenden Einheit enthalten, wobei das Zertifikat von der vertrauenswürdigen Stelle üblicherweise digital signiert wird. Das ausgestellte Zertifikat kann also anzeigen, dass die vertrauenswürdige Stelle die zu authenti fizierende Einheit geprüft hat, so dass alle Kommunikationspartner, die der ver trauenswürdigen Stelle vertrauen, diese Prüfung aufgrund des Zertifikats als er folgreich betrachten können.
Auch Geräte können auf diese Art und Weise mit Zertifikaten ausgestattet wer den. Der Hersteller des Geräts besitzt hierzu ein Herstellerzertifikat mit einer speziellen Berechtigung, eine vertrauenswürdige Stelle (lokale CA) zu bilden, wobei das Herstellerzertifikat vorzugsweise von einer bestehenden Certification Authority (CA) ausgestellt ist. Zunächst wird ein Gerätezertifikat und ein dazuge höriger geheimer Schlüssel generiert. Hierbei können unterschiedliche, zur Iden tifizierung eines Geräts geeignete Merkmale verwendet werden, z.B. eine Se riennummer. Es ist üblich, dass der Prozess während der Herstellung der Geräte lokal vom Hersteller durchgeführt wird, wobei der geheime Schlüssel vorzugs weise direkt im Gerät generiert wird. Das Gerätezertifikat wird sodann mittels des Herstellerzertifikats signiert und, ggfs zusammen mit dem zum Gerätezertifikat gehörenden Schlüssel, auf das Gerät aufgebracht.
Damit ergibt sich aber bei Geräten, die mit Zusatzkomponenten von Dritten ver sehen sind (z.B. nachträglich installierte Programmmodule bzw. Anwendungen) das Problem, dass zunächst alle oder keine der Anwendungen auf dieses Gerä tezertifikat zugreifen können. Es gibt keine zusätzliche Information darüber, wel che Anwendung auf dem Gerät das Gerätezertifikat nutzt.
Darüber hinaus ist bei allen kryptographischen Systemen die Vertraulichkeit der geheimen Schlüssel von grundlegender Bedeutung. Ein Kommunikationspartner ist nur dann vertrauenswürdig, solange der geheime Schlüssel auch geheim bleibt. Zu diesem Zweck kann beispielsweise spezialisierte Hardware verwendet werden, die eine besonders sichere Aufbewahrung der Schlüssel sicherstellen soll. Die Zugriffskontrolle auf die Schlüssel ist insbesondere bei externen Zusatz komponenten wie externen Anwendungen (Apps) von Bedeutung, da nicht jeder Anwendung gleichermaßen vertraut werden kann. So ist es beispielsweise für ei ne Anwendung, die Bankgeschäfte tätigen kann, von besonderer Bedeutung, dass keine andere Anwendung auf dem Gerät Zugriff auf den verwendeten ge heimen Schlüssel hat.
Zu diesem Zweck kann beispielsweise ein Schlüsselbeglaubigungs-Verfahren (Key Attestation) verwendet werden. Dabei werden Eigenschaften eines gene rierten Schlüssels bzw. Schlüsselpaares durch Zertifizierung bestätigt. Eine dritte Partei, wie etwa ein Netzwerkdienst, kann sich dann davon überzeugen, dass ein Schlüssel in einem sicheren Hardwarebaustein aufbewahrt wird und dass nur ei ne Anwendung Zugriff auf den Schlüssel hat. Dabei kann die Beglaubigung des erzeugten Schlüssels durch eine vertrauenswürdige Komponente durchgeführt werden, die in der Regel vom Hersteller des Gerätes stammt. Diese vertrauens würdige Komponente zertifiziert eine genaue Beschreibung des zugehörigen ge heimen Schlüssels, dessen Zugangskontrollen, dessen Aufbewahrung in sicherer Hardware, sowie gegebenenfalls eine "Attestation Challenge" des Netzwerk dienstes in einem Beglaubigungszertifikat bzw. 'Attestation Certificate'. Die so ausgestellten Zertifikate sind jedoch nicht geeignet, um als Beweis einer Identität für externe Dienste akzeptiert zu werden, da das Zertifikat auf dem Gerät keiner lokalen Zertifizierungsstelle entspricht.
Es ist darüber hinaus beispielsweise möglich, wie in DE 102015201 599 A1 ein System zu implementieren, in dem eine Recheneinrichtung das Verhalten von in stallierten Programmmodulen überwacht, z.B. die Kommunikation nach außen und die Verwendung von Nutzerdaten. Zu diesem Zweck wird die Recheneinrich tung selbst als vertrauenswürdig und korrekt funktionierend zertifiziert, indem von einer entsprechenden Zertifizierungsstelle ein Zertifikat für die Recheneinrichtung angefordert wird. Dazu sind aber beispielsweise umfangreiche Überprüfungsme chanismen durch die Recheneinheit erforderlich. Offenbarung der Erfindung
Erfindungsgemäß werden ein Verfahren zur Zertifizierung eines anwendungs spezifischen kryptographischen Schlüssels und ein Verfahren zur Anforderung einer derartigen Zertifizierung, sowie eine Recheneinheit und ein Computerpro gramm zu deren Durchführung mit den Merkmalen der unabhängigen Patentan sprüche vorgeschlagen. Vorteilhafte Ausgestaltungen sind Gegenstand der Un teransprüche sowie der nachfolgenden Beschreibung.
Die Erfindung schafft ein einfaches System zur sicheren Nutzung insbesondere nachträglich aufgebrachter Module und Anwendungen. Insbesondere wird dabei ein Verfahren zur Zertifizierung eines anwendungsspezifischen kryptographi schen Schlüssels, z.B. in einem Zertifikatsaustauschdienst, vorgeschlagen, wel ches die folgenden Schritte umfasst: Empfangen eines kryptographischen Be glaubigungszertifikats für einen anwendungsspezifischen öffentlichen Schlüssel von einer Anwendung in einer Vorrichtung; Prüfen der Gültigkeit des Beglaubi gungszertifikats; und falls das Beglaubigungszertifikat als gültig erkannt wurde, Vergleichen von zumindest einem Teil von Informationen, die aus dem Beglaubi gungszertifikat extrahiert wurden, mit vorgegebenen Referenzinformationen, und falls der Vergleich ergibt, dass ein neues Zertifikat erstellt werden soll, Bilden ei nes neuen anwendungsspezifischen Zertifikats, welches mindestens den aus dem Beglaubigungszertifikat extrahierten anwendungsspezifischen öffentlichen Schlüssel und zumindest einen Teil der Informationen aus dem Beglaubigungs zertifikat umfasst; sowie Senden des neuen anwendungsspezifischen Zertifikats an die Anwendung.
Auf diese Weise kann eine Anwendung ein externes Zertifikat für ein erzeugtes Schlüsselpaar erhalten, welches die Anwendung für andere Dienste als vertrau enswürdig markiert. Da zunächst nur das Beglaubigungszertifikat und keine von der (zunächst noch nicht als sicher identifizierten) Anwendung erzeugten Anfra gen oder Informationen verwendet werden, beruht die Ausstellung des neuen Zertifikats nur auf vom Gerätesystem validierten Daten. Damit wird die Prüfung der Informationen im Beglaubigungszertifikat zentralisiert und es wird der An- wendung ermöglicht, auch Cloud-Systeme oder Softwarepakete zu nutzen, die keine weitere Prüfung von Informationen in geräteeigenen Zertifikaten unterstüt zen.
Dabei kann das Prüfen der Gültigkeit des Beglaubigungszertifikats insbesondere das Validieren einer vorrichtungsspezifischen Zertifikatekette umfassen, die mit dem Beglaubigungszertifikat verknüpft ist und zusammen mit dem Beglaubi gungszertifikat empfangen wurde, wobei die Zertifikatekette eines oder mehrere Zwischenzertifikate umfasst und das letzte Zwischenzertifikat durch ein Herstel lerzertifikat der Vorrichtung signiert ist, und das Prüfen der Signatur des letzten Zwischenzertifikats auf Grundlage von einem oder mehreren gespeicherten Her stellerzertifikaten.
Auf diese Weise kann auch mit dem neuen ausgestellten Zertifikat für die An wendung eine implizite vertrauenswürdige Kette ("Chain of Trust") von der An wendung über den Zertifikatsaustauschdienst zum Hersteller hergestellt werden, die dann von allen, dem Zertifikatsaustauschdienst vertrauenden Netzwerkdiens ten verwendet und bis zum Zertifikat des Zertifikatsaustauschdienstes validiert werden kann. Dabei müssen die verwendenden Netzwerkdienste nur dem Zertifi katsaustauschdienst vertrauen und nicht selbst die Kette bis zum Hersteller überprüfen. Das neu ausgestellte Zertifikat selbst muss nicht mehr explizit an das Gerätebeglaubigungszertifikat oder das Herstellerzertifikat gebunden sein. Optional kann, bevorzugt vor Beginn der Validierung des Beglaubigungszertifi kats und der Prüfung der Zertifikatsdaten, weiter geprüft werden, ob das Beglau bigungszertifikat bereits zu einem früheren Zeitpunkt empfangen und/oder ge prüft wurde, und falls dies der Fall ist, kann das Ergebnis gesendet werden, das für das Beglaubigungszertifikat zu einem früheren Zeitpunkt erstellt wurde. Dabei kann es sich um ein schon früher ausgestelltes anwendungsspezifisches Zertifi kat handeln oder um eine Meldung über eine ungültige Prüfung der Daten. Eben so kann anstelle des früheren Ergebnisses auch eine Fehlermeldung gesendet werden oder der Vorgang ohne Meldung abgebrochen werden.
Es ist dabei möglich, das Verfahren zur Zertifizierung jeweils abzubrechen bzw. mit oder ohne entsprechende Rückmeldung an die Anwendung zu beenden, falls das Beglaubigungszertifikat als nicht gültig erkannt wurde oder falls der Vergleich der extrahierten Informationen ergibt, dass kein neues Zertifikat erstellt werden soll.
In beispielhaften Ausführungsformen können außerdem in Reaktion auf einen Verbindungsaufbau durch eine Anwendung mit dem Zertifikatsaustauschdienst ein oder mehrere Schlüsselparameter zur Erzeugung eines Schlüsselpaars an die Anwendung gesendet werden, wobei das zu erzeugende Schlüsselpaar ei nen anwendungsspezifischen geheimen und den anwendungsspezifischen öf fentlichen Schlüssel umfasst.
Alternativ oder zusätzlich kann in Reaktion auf einen Verbindungsaufbau durch eine Anwendung eine Herausforderung an die Anwendung gesendet werden. Nach dem Empfangen des Beglaubigungszertifikats kann dann geprüft werden, ob das empfangene Beglaubigungszertifikat die gesendete Herausforderung um fasst, indem die Herausforderung aus dem Beglaubigungszertifikat extrahiert wird und die Herausforderung mit einer zugehörigen Antwort validiert wird. Falls das empfangene Beglaubigungszertifikat die gesendete Herausforderung nicht umfasst, d.h. keine Herausforderung vorhanden ist oder die Validierung nicht er folgreich durchgeführt werden kann, kann das Verfahren zur Zertifizierung wieder abgebrochen bzw. beendet werden.
Durch eine derartige Herausforderung bzw. Challenge kann ein enger zeitlicher Zusammenhang zwischen der Erstellung des Beglaubigungszertifikats in der Vor richtung und der Nutzung des Zertifikatsaustauschdiensts, d.h. der Erstellung ei nes neuen anwendungsspezifischen Zertifikats, sichergestellt werden. Ein älteres Beglaubigungszertifikat, das schon vor Aufbau der Verbindung erstellt wurde, kann dann keine gültige Challenge enthalten. Es versteht sich, dass für jede An frage bevorzugt jeweils eine neue, eindeutige Challenge verwendet werden kann.
Es ist außerdem möglich, in das neue anwendungsspezifische Zertifikat weiter Informationen über eine zeitliche Gültigkeit des Zertifikats und/oder Informationen über einen oder mehrere Netzwerkdienste, für die das Zertifikat einsetzbar ist, einzubringen. Solche Informationen können vorgegeben sein oder von einer ge- eigneten, auch entfernten, Stelle abrufbar sein. Es kann sich beispielsweise um Daten zur Lizenzierung der Anwendung handeln, oder um eine Beschränkung des Zertifikats auf einzelne oder genau einen Dienst, für den das Zertifikat gültig sein soll.
Weiter wird ein Verfahren zur Anforderung einer Zertifizierung für ein anwen dungsspezifisches Schlüsselpaar durch eine Anwendung in einer Vorrichtung vorgeschlagen, welches die folgenden Schritte umfasst: Erzeugen eines anwen dungsspezifischen kryptographischen Schlüsselpaars, welches einen geheimen anwendungsspezifischen Schlüssel und einen öffentlichen anwendungsspezifi schen Schlüssel umfasst; Erhalten eines Beglaubigungszertifikats für das an wendungsspezifische Schlüsselpaar von einem Beglaubigungsmodul in der Vor richtung; Senden des Beglaubigungszertifikats an einen Zertifikatsaustausch dienst; Erhalten eines neuen anwendungsspezifischen Zertifikats für das Schlüs selpaar von dem Zertifikatsaustauschdienst, wobei das neue anwendungsspezi fische Zertifikat mindestens den öffentlichen anwendungsspezifischen Schlüssel und weitere Informationen umfasst.
Da keine zusätzlichen Schritte wie bei der Erzeugung einer üblichen Anfrage zur Zertifikatserstellung benötigt werden, sondern nur die Zertifikate ausgetauscht werden, ist das Verfahren insgesamt deutlich weniger fehleranfällig und ermög licht der Anwendung eine Authentifizierung gegenüber anderen Diensten, die den Zertifikatsaustauschdienst als vertrauenswürdig markiert haben.
Dabei kann das Senden des Beglaubigungszertifikats das Senden einer mit dem Beglaubigungszertifikat verknüpften Zertifikatekette an den Zertifikatsaustausch dienst, wobei die Zertifikatekette eines oder mehrere Zwischenzertifikate umfasst und das letzte Zwischenzertifikat durch ein Herstellerzertifikat der Vorrichtung signiert ist, umfassen. Das Herstellerzertifikat selbst muss dabei nicht übermittelt werden. Damit bleibt die Anfrage an den Zertifikatsaustauschdienst auch relativ klein, so dass keine großen Datenmengen erforderlich sind und das Verfahren beispielsweise auch in hardwarebasierten Systemen mit beschränkten Ressour cen einsetzbar ist. In weiteren Ausführungsformen können beispielsweise zusätzlich in Reaktion auf den Aufbau einer Verbindung zu dem Zertifikatsaustauschdienst Schlüsselpara metern von dem Zertifikatsaustauschdienst empfangen werden, die dann für das lokale Erzeugen des anwendungsspezifischen Schlüsselpaars verwendet werden sollen.
Alternativ oder zusätzlich ist es möglich, beim Verbindungsaufbau (z.B. während oder nach einem Handshake) eine Herausforderung von dem Zertifikatsaus tauschdienst zu empfangen, und diese Herausforderung an das Beglaubigungs modul zum Erstellen des Beglaubigungszertifikats für das anwendungsspezifi sche Schlüsselpaar weiterzuleiten.
Sobald ein neues anwendungsspezifisches Zertifikat erhalten wurde, kann dieses abgespeichert werden und in Zukunft für eine gesicherte Kommunikation mit mindestens einem Netzwerkdienst verwendet werden. Damit kann sich die An wendung gegenüber jedem Netzwerkdienst authentifizieren, welcher der Stelle vertraut, die das neue Zertifikat ausgestellt hat.
In allen Varianten kann das Beglaubigungszertifikat beispielsweise eine oder mehrere der folgenden Informationen umfassen: eine eindeutige Kennung der Vorrichtung, eine Signatur der Anwendung, Informationen zur Gültigkeit von Sys temdateien der Vorrichtung, Informationen über den anwendungsspezifischen öf fentlichen Schlüssel und/oder über einen zugehörigen anwendungsspezifischen geheimen Schlüssel. Ebenso können auch weitere, hier nicht angeführte Daten in Bezug auf die Vorrichtung und/oder die Anwendung und/oder die verwendeten Schlüssel, die Erzeugungs- und Speicherverfahren für die Schlüssel oder sonsti ge Informationen in dem Zertifikat enthalten sein.
Eine erfindungsgemäße Recheneinheit, z.B. ein Prozessor oder eine virtuelle Maschine in einer datenverarbeitenden Vorrichtung ist, insbesondere programm technisch, dazu eingerichtet, ein erfindungsgemäßes Verfahren durchzuführen.
Auch die Implementierung eines erfindungsgemäßen Verfahrens in Form eines Computerprogramms oder Computerprogrammprodukts mit Programmcode zur Durchführung aller Verfahrensschritte ist vorteilhaft, da dies besonders geringe Kosten verursacht, insbesondere wenn eine ausführendes Einheit noch für weite re Aufgaben genutzt wird und daher ohnehin vorhanden ist. Geeignete Datenträ ger zur Bereitstellung des Computerprogramms sind insbesondere magnetische, optische und elektrische Speicher, wie z.B. Festplatten, Flash-Speicher, EEPROMs, DVDs u.a.m. Auch ein Download eines Programms über Computer netze (Internet, Intranet usw.) ist möglich.
Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Be schreibung und der beiliegenden Zeichnung.
Die Erfindung ist anhand von Ausführungsbeispielen in der Zeichnung schema tisch dargestellt und wird im Folgenden unter Bezugnahme auf die Zeichnung beschrieben.
Kurze Beschreibung der Zeichnungen
Figur 1 zeigt ein beispielhaftes System, in dem verschiedene Zertifikate und Schlüssel gemäß beispielhaften Ausführungsformen erstellt und geprüft werden können; und
Figur 2 zeigt einen beispielhaften Ablauf von Verfahrensschritten in einer mögli chen Ausführungsform.
Ausführungsform(en) der Erfindung
In Figur 1 ist ein beispielhaftes System gezeigt, in dem gemäß einer beispielhaf ten Ausführungsform der Erfindung verschiedene kryptographische Zertifikate er stellt und geprüft werden können.
Dabei ist eine Vorrichtung 10, z.B. ein Nutzerendgerät vorhanden, das mindes tens eine Recheneinheit zur Datenverarbeitung, wie etwa einen geeigneten Pro zessor und Speicherelemente sowie andere Elemente umfasst. Außerdem kann das Endgerät Kommunikationsmittel umfassen, die unter anderem eine Kommu- nikationsschnittstelle zu anderen Vorrichtungen aufweisen können, um damit über geeignete Protokolle Daten zu senden und zu empfangen. Die Kommunika tionsmittel können mit der Recheneinheit, Speicherelementen und anderen Ele menten verbunden sein. Auf diese Weise kann das Endgerät beispielsweise in ein oder mehrere Netzwerke eingebunden sein und mit Diensten dieser Netzwer ke kommunizieren (nicht gezeigt).
In der Vorrichtung 10 können durch eine Recheneinheit ausführbare Programm- module bzw. Anwendungen vorhanden sein, wobei insbesondere auch eine oder mehrere Anwendungen 20 vorhanden sein können, die nachträglich in das End gerät eingebracht wurden, also z.B. als nachträglich durch einen Nutzer installier te Anwendung. Eine solche Anwendung 20 soll nun für interne und externe Dienste, z.B. für mit der Anwendung kommunizierende Netzwerkdienste, als ver trauenswürdig und sicher zertifiziert werden. Es soll also für die Dienste möglich sein, sicherzustellen, dass mit einer speziellen, nachträglich aufgebrachten An wendung kommuniziert wird, die nicht verändert oder ausgetauscht wurde. Dabei kann die Zertifizierung spezifisch in Zusammenhang mit dem jeweiligen Gerät 10 stattfinden, auf dem die Anwendung 20 installiert ist. So wird es beispielsweise zusätzlich möglich, ein Gerät in einem Netzwerkdienst zuzuordnen.
Die Schritte zur Zertifizierung gemäß beispielhafter Ausführungsformen werden zusätzlich in Bezug auf Figur 2 erläutert.
Dabei kann zunächst ein herstellerabhängiges Herstellerzertifikat 12 auf der Vor richtung 10 vorhanden sein, welches herstellerspezifische Informationen enthält und bevorzugt schon vom Hersteller auf der Vorrichtung 10 aufgebracht wurde. Außerdem ist die Vorrichtung vom Hersteller mit einem geheimen, gerätespezifi schen Schlüssel 16, der zur Erstellung von Beglaubigungszertifikaten (Attestati on) verwendet werden kann, sowie einem dazugehörigen, gerätespezifischen Gerätebeglaubigungszertifikat 14, 'Device Attestation Certificate', welches gerä tespezifische Informationen enthält, ausgestattet. Das Gerätebeglaubigungszerti fikat 14 kann entweder direkt oder indirekt, d.h. mit weiteren Zwischenzertifika ten, durch das Herstellerzertifikat 12 signiert sein, Schritt 40 in Figur 1, so dass eine vertrauenswürdige Kette von zwei oder mehr Zertifikaten entsteht, die min- destens das Herstellerzertifikat 12 und das Gerätebeglaubigungszertifikat 14 als letztes Zertifikat der Kette umfasst. Das Herstellerzertifikat muss dabei nicht zwingend auf der Vorrichtung vorhanden sein, solange es in dem Zertifikats tauschdienst 30 vorliegt und durch eine eindeutige Kennung identifizierbar ist.
Die Anwendung 20 kann nun in Schritt 110 ein kryptographisches asymmetri sches Schlüsselpaar 18 erzeugen, beispielsweise durch Verwendung einer ent sprechenden Schnittstelle mit dem Gerät, die in der Lage ist, derartige Schlüssel zu erzeugen, z.B. die 'Android KeyStore API' oder ein anderes geeignetes Schlüsselerzeugungsmodul, das auf dem Gerät implementiert ist. Die Anwen dung kann dann in Schritt 112 von dem Gerät eine Beglaubigung des erzeugten Schlüsselpaares anfordern, so dass ein entsprechendes Modul auf dem Gerät ein Beglaubigungszertifikat 22 für den anwendungsspezifischen Schlüssel in Schritt 114 ausstellt und mit dem Gerätebeglaubigungszertifikat 14 signiert, Schritt 42. In dem Beglaubigungszertifikat 22 für den anwendungsspezifischen Schlüssel sind also zumindest der öffentliche Schlüssel des anwendungsspezifi schen Schlüsselpaares sowie verschiedene Informationen zur Identifizierung des Schlüssels und/oder des Geräts vorhanden. Auf diese Weise wird auch das so erzeugte Beglaubigungszertifikat 22 für den anwendungsspezifischen Schlüssel in die vertrauenswürdige Kette eingebunden. Der zugehörige geheime anwen dungsspezifische Schlüssel 18 wird von der Anwendung und/oder dem Schlüs selerzeugungsmodul auf dem Gerät 10 in geeigneter Weise abgespeichert.
Dieses im Gerät erzeugte Beglaubigungszertifikat 22 für den anwendungsspezifi schen Schlüssel kann nun an die Anwendung weitergegeben werden (Schritt 116) und in Schritt 120 von der Anwendung an einen Zertifikatsaustauschdienst 30 übermittelt werden, beispielsweise unter Nutzung entsprechender drahtloser oder drahtgebundener Kommunikationsmittel und optional auch zwischenge schalteter Netzwerke. Dieser Zertifikatsaustauschdienst 30 kann ähnlich einer CA eine vertrauenswürdige Stelle bilden, die anwendungsspezifische Zertifikate erstellen und signieren kann. In dem Zertifikatsaustauschdienst sollen zumindest vertrauenswürdige Zertifikate 32 mehrerer verschiedener Hersteller und/oder Ge räte vorliegen sowie weitere Informationen, die zur Validierung 34 erforderlich sind. Wenn der Zertifikatsaustauschdienst 30 das Beglaubigungszertifikat 22 für den anwendungsspezifischen Schlüssel in Schritt 130 erhält, kann er dessen Signa turkette in Schritt 136 überprüfen. Zu diesem Zweck kann von der Anwendung bevorzugt jedes Zertifikat der Kette an den Zertifikatsaustauschdienst übermittelt werden, um die gesamte Kette zu prüfen. Die Datenübermittlung 120 der An wendung an den Zertifikatsaustauschdienst kann also zur Validierung der ge samten Kette das Beglaubigungszertifikat 22, das darunter liegende Gerätebe glaubigungszertifikat 14 sowie optional weitere Zwischenzertifikate einer vertrau enswürdigen Kette über dem Herstellerzertifikat umfassen. Bevorzugt werden dabei keine weiteren Informationen außer den Zertifikaten übermittelt, wobei auch das Herstellerzertifikat 12 selbst üblicherweise nicht übermittelt wird. Die Herstellerzertifikate liegen als Teil der vertrauenswürdigen Zertifikate 32 in dem Zertifikatsaustauschdienst vor und ermöglichen so die Prüfung des letzten Zertifi kats bzw. Zwischenzertifikats der Kette, das von dem Herstellerzertifikat signiert wurde.
Die sendende Anwendung 20 kann dabei optional die Datenübermittlung 120, d.h. die übermittelten Zertifikate, mit einem eigenen Kommunikationsschlüssel signieren und/oder kryptographisch verschlüsseln. Umgekehrt soll insbesondere die Anwendung in der Lage sein, den Zertifikatsautauschdienst korrekt zu identi fizieren. Zusätzlich oder alternativ können in dem Beglaubigungszertifikat 22 für die anwendungsspezifischen Schlüssel, das von dem entsprechenden Beglaubi gungsmodul des Geräts für die anwendungsspezifischen Schlüssel erstellt und signiert wurde, Informationen über die Anwendung 20 eingeschlossen sein, wel che die beglaubigten Schlüssel erzeugt und das Beglaubigungszertifikat ange fordert hat.
Falls bei der Prüfung 34, 136 der Zertifikate festgestellt wird, dass mindestens ein Zertifikat der Kette nicht gültig ist und/oder dass das Herstellerzertifikat nicht validiert werden kann, kann die Prüfung der Zertifikatskette als fehlgeschlagen gelten. In diesem Fall kann beispielsweise die Verarbeitung des übermittelten Beglaubigungszertifikats abgebrochen werden und optional zusätzlich eine Mel dung an die sendenden Anwendung 20 gesendet werden, die angibt, dass keine gültige Zertifikatskette vorliegt. Das passende Herstellerzertifikat aus den ver trauenswürdigen Zertifikaten 32 kann dabei den Hersteller eindeutig identifizie ren.
Falls dagegen in diesem Prüfungsschritt 136 die Zertifikatskette zwischen dem Beglaubigungszertifikat und dem Herstellerzertifikat erfolgreich validiert wurde, können nun verschiedene Informationen durch den Zertifikatsaustauschdienst 30 aus dem übermittelten Beglaubigungszertifikat extrahiert werden. Dabei können zunächst relevante Informationen entnommen werden, die verwendet werden können, um in Schritt 138 zu prüfen, ob die sendende Anwendung 20 und/oder das verwendete Gerät 10 vertrauenswürdig sind. Dabei kann in dem Zertifikats austauschdienst vorgegeben sein, welche Informationen für diese Prüfung 138 verwendet werden sollen. Es können auch Informationen vorgegeben sein, die nur optional zur Prüfung verwendet werden sollen, und deren Validierung auch ausgelassen werden kann. Beispiele für Informationen, die dem Beglaubigungs zertifikat entnommen und geprüft werden können, sind etwa eine Seriennummer oder eine andere Kennung zur eindeutigen Identifizierung eines Geräts; eine (möglichst manipulationssichere) Kennung zur eindeutigen Identifizierung z.B. einer bestimmten Version einer Anwendung; Informationen zu Systemdateien des Geräts, z.B. eine Information darüber, ob eine vorgegebene Gruppe von Systemdateien unverändert und unbeschädigt ist (Verified Boot); und weitere. Diese Informationen können mit Informationen, die in dem Zertifikatsaustausch dienst 30 gespeichert sind oder von diesem von anderer Stelle abgerufen wer den, verglichen werden, um sie zu validieren. Darüber hinaus kann der anwen dungsspezifische öffentliche Schlüssel aus dem Beglaubigungszertifikat extra hiert werden. Dabei versteht sich, dass die Informationen nicht zwingend in die ser Reihenfolge aus dem Zertifikat extrahiert werden müssen. Es ist beispiels weise möglich, den Schlüssel erst dann zu entnehmen, wenn der vorherige Ab gleich der Informationen aus dem Beglaubigungszertifikat erfolgreich war, oder alternativ den Schlüssel bereits mit den übrigen Informationen vor der Prüfung zu extrahieren.
Falls die Validierung 138 bzw. der Abgleich der Informationen aus dem Beglau bigungszertifikat erfolgreich war, kann in Schritt 140 ein neues Zertifikat erstellt werden 36. Dabei können auch weitere Informationen neben den Informationen aus dem Beglaubigungszertifikat ausgewertet werden, die dem Zertifikatsaus tauschdienst 30 vorliegen, z.B. Informationen über die Anwendung 20, welche das Zertifikat anfordert. Als Beispiel können dem Zertifikatsaustauschdienst Li zenzinformationen zur Verfügung stehen, die angeben, ob für diese Anwendung eine gültige Lizenz erworben wurde und optional auch, wie lange diese Lizenz gültig ist. Unter Verwendung dieser Information kann dann ein von dem Zertifi katsaustauschdienst erstelltes Zertifikat 24 auf die Gültigkeit der Lizenz be schränkt werden oder beispielsweise die Ausstellung des Zertifikats vollständig verhindert werden, falls keine gültige Lizenz vorliegt.
Darüber hinaus kann der Zertifikatsaustauschdienst, der das neue anwendungs spezifische Zertifikat ausstellt, auch alternativ oder zusätzlich solche Daten zur Lizenzierung lokal speichern und auf dieser Grundlage beispielsweise eine Liste oder anderweitig für einen Netzwerkdienst abrufbare Daten bereithalten, in de nen angegeben ist, ob ein bereits ausgestelltes neues Zertifikat noch gültig ist. Damit können beispielsweise veränderte Lizenzdaten (nicht bezahlte Lizenzen, Rückruf aus anderen Gründen) bereitgestellt werden, so dass ein Dienst vor der Nutzung des Zertifikats prüfen kann, ob der Zertifikatsaustauschdienst angibt, dass das Zertifikat nicht mehr gültig ist oder nicht mehr verwendet werden soll.
Falls die Prüfung 138 der Daten nicht erfolgreich war, kann wieder der Vorgang abgebrochen werden und/oder mit einer entsprechenden Fehlermeldung an die anfordernde Anwendung abgebrochen werden.
Ansonsten kann der Zertifikatsaustauschdienst nun in Schritt 140 das neue, an wendungsspezifische Zertifikat 24 erstellen und mit seinem eigenen geheimen Schlüssel, der für die Zertifizierung vorgesehen ist, signieren. Das neue anwen dungsspezifische Zertifikat 24 enthält dabei den öffentlichen anwendungsspezifi schen Schlüssel sowie weitere relevante Informationen. Dies können beispiels weise die geprüften Informationen aus dem Beglaubigungszertifikat 22 sein, oder alle Informationen, die in dem Beglaubigungszertifikat enthalten waren oder nur eine Teilmenge davon. Außerdem können weitere Informationen in das anwen dungsspezifische Zertifikat einfließen, die dem Zertifikatsaustausch vorliegen, z.B. eine Gültigkeitsdauer auf Grundlage der oben beschriebenen Lizenzdaten. Ebenso kann angegeben sein, dass das Zertifikat nur zur Kommunikation mit ei nem oder mehreren bestimmten Netzwerkdiensten gültig ist.
Anschließend kann der Zertifikatsaustauschdienst das neue anwendungsspezifi sche Zertifikat 24 in Schritt 150 an die Anwendung 20 senden. Die Anwen dung 20 kann dieses Zertifikat nun zusammen mit dem zugehörigen, anwen dungsspezifischen geheimen Schlüssel 18 in Schritt 160 speichern und das Zerti fikat 24 zukünftig zur wechselseitigen Authentifizierung bei Diensten verwenden, die dem Zertifikatsaustauschdienst vertrauen. Falls das anwendungsspezifische Zertifikat 24 auf bestimmte Dienste beschränkt ist, kann die Anwendung auch das jeweils für einen Dienst geeignete Zertifikat aus einer Gruppe gespeicherter Zertifikate auswählen. Zu diesem Zweck kann die Anwendung 20 und/oder das Gerät 10 das Zertifikat 24 in geeigneten Speichermodulen ablegen.
Allgemein kann in dem Zertifikatsaustauschdienst 30 eine Vorgabe abgespei chert sein, die angibt, welche Daten aus dem Beglaubigungszertifikat abgerufen werden sollen, und welche Daten in ein neues anwendungsspezifisches Zertifikat 24 integriert werden sollen. Diese Vorgabe kann auch von einer anderen Stelle optional verändert werden, und/oder kann für unterschiedliche Anwendungen verschieden sein.
Optional kann der Zertifikatsaustauschdienst auch zu Beginn des Verfahrens, al so nach Erhalt 130 des Beglaubigungszertifikats für den anwendungsspezifi schen Schlüssel, in einem zusätzlichen Schritt 134 eine Prüfung durchführen, ob ein identisches Zertifikat schon einmal geschickt wurde. Zu diesem Zweck kann der Zertifikatsaustauschdienst beispielsweise alle bisherigen zum Austausch er haltenen Beglaubigungszertifikate auf geeignete Weise lokal oder auf andere Weise abrufbar speichern, so dass ein Abgleich möglich ist. Dabei kann auch zunächst nur ein einzelnes oder wenige Datenelemente des Beglaubigungszerti fikats abgeglichen werden. Falls es sich bei der Prüfung ergibt, dass ein identi sches Zertifikat bereits früher erhalten wurde, kann festgelegt sein, dass bei spielsweise das alte Ergebnis (z.B. ein daraufhin ausgestelltes Anwendungszerti fikat oder eine Meldung über eine ungültige Zertifikatskette) zurück an die An- wendung gesendet wird, die das Beglaubigungszertifikat verschickt hat. Alterna tiv kann auch eine Fehlermeldung ausgegeben und an die Anwendung versendet werden.
In einerweiteren beispielhaften Ausführungsform können zusätzliche Schritte implementiert werden. Dabei kann der Zertifikatsaustauschdienst 30 beispiels weise ein Verfahren wie ein Challenge-Response-Verfahren zusätzlich erset zen, so dass bei Aufbau der Verbindung zwischen dem Gerät und dem Zertifikat saustauschdienst eine entsprechende Herausforderung (Challenge) in Schritt 104 und/oder bestimmte Schlüsselparameter in Schritt 102 an die Anwendung gesendet werden. Anschließend kann die Anwendung wie im vorherigen Ausfüh rungsbeispiel (Schritt 110) ein anwendungsspezifisches Schlüsselpaar erstellen, wobei gegebenenfalls die von dem Zertifikatsaustauschdienst verwendeten Schlüsselparameter oder ein Teil davon zur Erzeugung der Schlüssel verwendet werden können. Daraufhin kann, ebenfalls wie im vorherigen Beispiel, in Schritt 114 ein Beglaubigungszertifikat durch das Gerät für die erzeugten Schlüssel ausgestellt werden, in dem zusätzlich die erhaltene Herausforderung enthalten sein soll. Das so erstellte Beglaubigungszertifikat kann dann wieder in den Schrit ten 116, 120 an den Zertifikatsaustauschdienst gesendet werden, wo die Heraus forderung in Schritt 132 validiert wird. Als Herausforderung sind dabei beliebige geeignete Challenges möglich, die dem Fachmann bekannt sind. Bei erfolgrei cher Prüfung der Challenge kann die weitere Prüfung des Beglaubigungszertifi kats und die Ausstellung des neuen Zertifikats wie zuvor beschrieben gemäß den folgenden Schritten 134 bis 150 stattfinden stattfinden. Durch das Senden der Herausforderung 104 beim Verbindungsaufbau 100 (z.B. bei einem Handshake), die in das Beglaubigungszertifikat eingeschlossen wird, wird sichergestellt, dass ein zeitlicher Zusammenhang zwischen der Schlüsselerzeugung und/oder der Erstellung 114 des Beglaubigungszertifikats und der Erstellung 140 eines neuen anwendungsspezifischen Zertifikats eingehalten wird.
Die beschriebene Idee und sämtliche Ausführungsformen sind mit Vorrichtungen bzw. Endgeräten eines Nutzers verwendbar, wie etwa Smartphones, Tablets, Computer, aber auch mit anderen Geräten, die eine Kommunikationsschnittstelle aufweisen und eine Möglichkeit zur sicheren Kommunikation benötigen, wie etwa Smart Ho e-Geräte bzw. "Internet of Things" (loT), vernetzte Fahrzeuge, und viele weitere.
Ebenso denkbar ist eine Anwendung im industriellen Kontext, wo zunehmend Produktionsmaschinen, Fertigungseinrichtungen, Roboter, teilautonome Systeme und andere Einheiten lokal oder global vernetzt sind und durch herstellerseitige oder vom Endkunden selbst bereitgestellte Zusatzanwendungen später erweiter bar sind. Es versteht sich, dass alle beschriebenen Varianten nur als Beispiele dargestellt wurden und diese unter anderem durch weitere Verfahrensschritte ergänzt wer den könnten bzw. einzelne Verfahrensschritte auch ausgelassen werden könn ten. Ebenso können die verschiedenen beispielhaften Ausführungsformen und insbesondere ihre einzelnen Bestandteile und Verfahrensschritte auch miteinan- der kombiniert werden.

Claims

Ansprüche
1. Verfahren zur Zertifizierung eines anwendungsspezifischen kryptographi- schen Schlüssels in einem Zertifikatsaustauschdienst (30), umfassend:
Empfangen (130), von einer Anwendung (20) in einer Vorrichtung (10), eines kryptographischen Beglaubigungszertifikats (22) für einen anwen dungsspezifischen öffentlichen Schlüssel;
Prüfen (34; 136) der Gültigkeit des Beglaubigungszertifikats (22); und falls das Beglaubigungszertifikat (22) als gültig erkannt wurde, Verglei chen (34; 138) von zumindest einem Teil von Informationen, die aus dem Beglaubigungszertifikat (22) extrahiert wurden, mit vorgegebenen Referenz informationen, und falls der Vergleich ergibt, dass ein neues Zertifikat erstellt werden soll, Bilden (36; 140) eines neuen anwendungsspezifischen Zertifikats (24), welches mindestens den aus dem Beglaubigungszertifikat (22) extrahierten anwendungsspezifischen öffentlichen Schlüssel und zumin dest einen Teil der Informationen aus dem Beglaubigungszertifikat um fasst; und Senden (150) des neuen anwendungsspezifischen Zertifikats (24) an die Anwendung (20).
2. Verfahren nach Anspruch 1, wobei das Prüfen der Gültigkeit (34; 136) des Beglaubigungszertifikats umfasst:
Validieren einer vorrichtungsspezifischen Zertifikatekette (14), die mit dem Beglaubigungszertifikat (22) verknüpft ist und zusammen mit dem Be glaubigungszertifikat empfangen wurde, wobei die Zertifikatekette eines oder mehrere Zwischenzertifikate umfasst und das letzte Zwischenzertifikat durch ein Herstellerzertifikat (12) der Vorrichtung signiert ist, und
Prüfen der Signatur des letzten Zwischenzertifikats auf Grundlage von einem oder mehreren gespeicherten, vertrauenswürdigen Zertifikaten (32).
3. Verfahren nach Anspruch 1 oder 2, weiter umfassend:
Prüfen (134), ob das Beglaubigungszertifikat (22) bereits zu einem früheren Zeitpunkt empfangen und/oder geprüft wurde, und falls dies der Fall ist,
Senden des Ergebnisses, das für das Beglaubigungszertifikat zu einem früheren Zeitpunkt erstellt wurde.
4. Verfahren nach einem der vorhergehenden Ansprüche, weiter umfassend:
Beenden des Verfahrens zur Zertifizierung, falls das Beglaubigungszerti fikat (22) als nicht gültig erkannt (136) wurde oder falls der Vergleich (138) der extrahierten Informationen ergibt, dass kein neues Zertifikat erstellt wer den soll.
5. Verfahren nach einem der vorhergehenden Ansprüche, weiter umfassend: in Reaktion auf einen Verbindungsaufbau (100) durch eine Anwendung (20), Senden (102) von Schlüsselparametern zur Erzeugung eines Schlüs selpaars, welches einen anwendungsspezifischen geheimen und den an wendungsspezifischen öffentlichen Schlüssel umfasst, an die Anwendung (20).
6. Verfahren nach einem der vorhergehenden Ansprüche, weiter umfassend:
Senden (104) einer Herausforderung an die Anwendung (20) in Reakti on auf einen Verbindungsaufbau (100) durch die Anwendung; und nach dem Empfangen (130) des Beglaubigungszertifikats (22), Prü fen (132), ob das empfangene Beglaubigungszertifikat (22) die gesendete Herausforderung umfasst, durch Extrahieren der Herausforderung und Vali dieren der Herausforderung mit einer zugehörigen Antwort, und Beenden des Verfahrens zur Zertifizierung, falls das empfangene Beglaubigungszerti fikat die gesendete Herausforderung nicht umfasst.
7. Verfahren zur Anforderung einer Zertifizierung für ein anwendungsspezifi sches Schlüsselpaar durch eine Anwendung (20) in einer Vorrichtung (10), umfassend: Erzeugen (110) eines anwendungsspezifischen kryptographischen Schlüsselpaars, welches einen geheimen anwendungsspezifischen Schlüs sel (18) und einen öffentlichen anwendungsspezifischen Schlüssel umfasst;
Erhalten (116) eines Beglaubigungszertifikats (22) für das anwendungs spezifische Schlüsselpaar von einem Beglaubigungsmodul in der Vorrich tung (10);
Senden (120) des Beglaubigungszertifikats (22) an einen Zertifikatsaus tauschdienst (30);
Erhalten (150) eines neuen anwendungsspezifischen Zertifikats (24) für das Schlüsselpaar von dem Zertifikatsaustauschdienst, wobei das neue an wendungsspezifische Zertifikat (24) mindestens den öffentlichen anwen dungsspezifischen Schlüssel und weitere Informationen umfasst.
8. Verfahren nach Anspruch 7, wobei das Senden (120) des Beglaubigungszer tifikats weiter umfasst:
Senden einer mit dem Beglaubigungszertifikat verknüpften Zertifikate kette an den Zertifikatsaustauschdienst, wobei die Zertifikatekette eines oder mehrere Zwischenzertifikate (14) umfasst und das letzte Zwischenzertifikat durch ein Herstellerzertifikat (12) der Vorrichtung (10) signiert ist.
9. Verfahren nach einem der Ansprüche 7 oder 8, weiter umfassend:
Empfangen (102) von Schlüssel Parametern von dem Zertifikatsaus tauschdienst (30) in Reaktion auf den Aufbau einer Verbindung (100) zu dem Zertifikatsaustauschdienst (30); und
Verwenden der Schlüsselparameter für das Erzeugen des anwendungs spezifischen Schlüsselpaars.
10. Verfahren nach einem der Ansprüche 7 bis 9, weiter umfassend:
Empfangen (104) einer Herausforderung von dem Zertifikatsaustausch dienst (30) in Reaktion auf den Aufbau einer Verbindung zu dem Zertifikat saustauschdienst, und
Weiterleiten (106) der Herausforderung an das Beglaubigungsmodul zum Erstellen des Beglaubigungszertifikats (22) für das anwendungsspezifi sche Schlüsselpaar.
11. Verfahren nach einem der Ansprüche 7 bis 10, weiter umfassend:
Verwenden des neuen anwendungsspezifischen Zertifikats (24) für eine gesicherte Kommunikation mit mindestens einem Netzwerkdienst.
12. Verfahren nach einem der vorhergehenden Ansprüche, wobei das Beglaubi gungszertifikat (22) eine oder mehrere der folgenden Informationen umfasst: eine eindeutige Kennung der Vorrichtung (10), eine Kennung zur ein deutigen Identifizierung einer bestimmten Version der Anwendung (20), In formationen über die Anwendung (20), Informationen zur Gültigkeit von Sys temdateien der Vorrichtung, Informationen über den anwendungsspezifi schen öffentlichen Schlüssel und/oder über einen zugehörigen anwendungs spezifischen geheimen Schlüssel (18).
13. Verfahren nach einem der vorhergehenden Ansprüche, wobei das neue an wendungsspezifische Zertifikat (24) weiter Informationen über eine zeitliche Gültigkeit des Zertifikats auf Basis weiterer Informationen in Bezug auf die Anwendung und/oder Informationen über einen oder mehrere Netzwerk dienste, für die das Zertifikat (24) einsetzbar ist, umfasst.
14. Recheneinheit, die dazu eingerichtet ist, alle Verfahrensschritte eines Ver fahrens nach einem der vorstehenden Ansprüche durchzuführen.
15. Computerprogramm, das eine Recheneinheit dazu veranlasst, alle Verfah rensschritte eines Verfahrens nach einem der Ansprüche 1 bis 13 durchzu führen, wenn es auf der Recheneinheit ausgeführt wird.
16. Maschinenlesbares Speichermedium mit einem darauf gespeicherten Com puterprogramm nach Anspruch 15.
PCT/DE2021/100209 2020-03-06 2021-03-02 Verfahren und vorrichtung zur zertifizierung eines anwendungsspezifischen schlüssels und zur anforderung einer derartigen zertifizierung WO2021175372A1 (de)

Priority Applications (6)

Application Number Priority Date Filing Date Title
EP21727351.5A EP4115586A1 (de) 2020-03-06 2021-03-02 Verfahren und vorrichtung zur zertifizierung eines anwendungsspezifischen schlüssels und zur anforderung einer derartigen zertifizierung
CA3169475A CA3169475A1 (en) 2020-03-06 2021-03-02 Method and apparatus for certifying an application-specific key and for requesting such certification
CN202180019378.4A CN115280719A (zh) 2020-03-06 2021-03-02 用于认证应用程序特定的密钥和用于请求这类认证的方法和设备
KR1020227034161A KR20220153602A (ko) 2020-03-06 2021-03-02 애플리케이션별 키를 인증하고 이런 인증을 요청하는 방법 및 디바이스
DE112021001486.2T DE112021001486A5 (de) 2020-03-06 2021-03-02 Verfahren und vorrichtung zur zertifizierung eines anwendungsspezifischen schlüssels und zur anforderung einer derartigen zertifizierung
US17/909,487 US20230155842A1 (en) 2020-03-06 2021-03-02 Method and apparatus for certifying an application-specific key and for requesting such certification

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102020202879.6 2020-03-06
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

Publications (1)

Publication Number Publication Date
WO2021175372A1 true WO2021175372A1 (de) 2021-09-10

Family

ID=76076177

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE2021/100209 WO2021175372A1 (de) 2020-03-06 2021-03-02 Verfahren und vorrichtung zur zertifizierung eines anwendungsspezifischen schlüssels und zur anforderung einer derartigen zertifizierung

Country Status (8)

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

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140258711A1 (en) * 2014-05-20 2014-09-11 Airwatch Llc Application Specific Certificate Management
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
DE102015201599A1 (de) 2015-01-30 2016-08-04 Robert Bosch Gmbh Datenverarbeitungssystem und Verfahren
US20170337380A1 (en) * 2016-05-18 2017-11-23 Microsoft Technology Licensing, Llc Self-contained cryptographic boot policy validation
US9992029B1 (en) * 2017-04-05 2018-06-05 Stripe, Inc. Systems and methods for providing authentication to a plurality of devices
US20180241574A1 (en) * 2017-02-17 2018-08-23 Canon Kabushiki Kaisha Information processing apparatus, method of controlling the same, and storage medium
US20180287802A1 (en) * 2017-03-31 2018-10-04 Intel Corporation Using A Trusted Execution Environment As A Trusted Third Party Providing Privacy For Attestation

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140258711A1 (en) * 2014-05-20 2014-09-11 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
US20170337380A1 (en) * 2016-05-18 2017-11-23 Microsoft Technology Licensing, Llc Self-contained cryptographic boot policy validation
US20180241574A1 (en) * 2017-02-17 2018-08-23 Canon Kabushiki Kaisha Information processing apparatus, method of controlling the same, and storage medium
US20180287802A1 (en) * 2017-03-31 2018-10-04 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
US20230155842A1 (en) 2023-05-18
TW202139037A (zh) 2021-10-16
CN115280719A (zh) 2022-11-01
EP4115586A1 (de) 2023-01-11
CA3169475A1 (en) 2021-09-10
DE112021001486A5 (de) 2023-01-12
DE102020202879A1 (de) 2021-09-09
KR20220153602A (ko) 2022-11-18

Similar Documents

Publication Publication Date Title
EP3157281B1 (de) Verfahren zur geschützten kommunikation eines fahrzeugs
EP3731119B1 (de) Computerimplementiertes verfahren zur zugriffskontrolle
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 (de) Verfahren, computerprogrammprodukt und system zur authentifizierung eines benutzers eines telekommunikationsnetzwerkes
DE102010028133A1 (de) Verfahren zum Lesen eines Attributs aus einem ID-Token
DE102012224421A1 (de) Fahrzeuggebundenes system und kommunikationsverfahren
EP2446390B1 (de) System und verfahren zur zuverlässigen authentisierung eines gerätes
DE102008042262A1 (de) Verfahren zur Speicherung von Daten, Computerprogrammprodukt, ID-Token und Computersystem
EP3699791B1 (de) Zugangskontrolle mit einem mobilfunkgerät
DE102013108020A1 (de) Authentifizierungsschema zum Aktivieren eines Spezial-Privileg-Modus in einem gesicherten elektronischen Steuergerät
EP3909221B1 (de) Verfahren zum sicheren bereitstellen einer personalisierten elektronischen identität auf einem endgerät
EP3417395B1 (de) Nachweisen einer authentizität eines gerätes mithilfe eines berechtigungsnachweises
EP3908946B1 (de) Verfahren zum sicheren bereitstellen einer personalisierten elektronischen identität auf einem endgerät
EP3114600A1 (de) Sicherheitssystem mit Zugriffskontrolle
EP3321832A1 (de) Verteilen zum lesen von attributen aus einem id-token
EP3244360A1 (de) Verfahren zur registrierung von geräten, insbesondere von zugangskontrollvorrichtungen oder bezahl- bzw. verkaufsautomaten bei einem server eines systems, welches mehrere derartige geräte umfasst
EP3244331B1 (de) Verfahren zum lesen von attributen aus einem id-token
EP4115586A1 (de) Verfahren und vorrichtung zur zertifizierung eines anwendungsspezifischen schlüssels und zur anforderung einer derartigen zertifizierung
EP3125464B1 (de) Sperrdienst für ein durch einen id-token erzeugtes zertifikat
EP3271855B1 (de) Verfahren zur erzeugung eines zertifikats für einen sicherheitstoken
EP2381712B1 (de) Sicheres Auslesen von Daten aus einem Funkgerät mit festintegriertem TPM
EP3244332B1 (de) Verfahren zum lesen von attributen aus einem id-token
WO2021175371A1 (de) Gesicherter und dokumentierter schlüsselzugriff durch eine anwendung
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
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21727351

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 3169475

Country of ref document: CA

ENP Entry into the national phase

Ref document number: 20227034161

Country of ref document: KR

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2021727351

Country of ref document: EP

Effective date: 20221006

REG Reference to national code

Ref country code: DE

Ref legal event code: R225

Ref document number: 112021001486

Country of ref document: DE