WO2019096489A1 - Verfahren und vorrichtung zur behandlung von authentizitätsbescheinigungen für entitäten, insbesondere von personenbezogenen, dienstbezogenen und/oder objektbezogenen digitalen zertifikaten - Google Patents

Verfahren und vorrichtung zur behandlung von authentizitätsbescheinigungen für entitäten, insbesondere von personenbezogenen, dienstbezogenen und/oder objektbezogenen digitalen zertifikaten Download PDF

Info

Publication number
WO2019096489A1
WO2019096489A1 PCT/EP2018/077028 EP2018077028W WO2019096489A1 WO 2019096489 A1 WO2019096489 A1 WO 2019096489A1 EP 2018077028 W EP2018077028 W EP 2018077028W WO 2019096489 A1 WO2019096489 A1 WO 2019096489A1
Authority
WO
WIPO (PCT)
Prior art keywords
certificate
data
certificates
authentication
status
Prior art date
Application number
PCT/EP2018/077028
Other languages
English (en)
French (fr)
Inventor
Hendrik Brockhaus
Jens-Uwe Busser
Original Assignee
Siemens Aktiengesellschaft
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 Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Publication of WO2019096489A1 publication Critical patent/WO2019096489A1/de

Links

Classifications

    • 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
    • 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/3236—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 using cryptographic hash functions
    • H04L9/3239—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 using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • 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
    • 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/3297—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 time stamps, e.g. generation of time stamps
    • 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/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Definitions

  • the invention relates to a method for the treatment of authenticity certificates for entities, in particular personal, service-related and / or object-related digital certificates, according to the preamble of claim 1 and a device for handling authenticity certificates for entities, in particular personal, service-related and / or or object-related digital certificates, according to the preamble of claim 15. It also relates to a computer program product according to the preamble of claim 16.
  • Object-related certificates are known, in particular equipment certificates and certificates issued by the manufacturer for products produced by him.
  • Certificates are becoming increasingly important, not only in information technology. Also in the so-called "Operational Technology” (OT), under which the monitoring and control of physical states of a system, for example, the process control in the industrial environment, can be understood by computer simplified, digital certificates are increasingly used for the protection ,
  • Certificates are certificates of authenticity, and in the case of a certificate-based system, each person or object is known has a digital certificate containing information about its identity, in the case of key certificates also a public key, the person or the object.
  • Each certificate is certified by a issuing authority, a so-called Certificate Authority (CA), by a digital signature, which in turn may be certified by higher authorities.
  • CA Certificate Authority
  • the trust system of such a Public Key Infrastructure PKI is strictly hierarchical.
  • the common trust anchor is a so-called root certificate, also called "root certificate”.
  • the domain owner currently has a large selection of providers who create certificates because in current operating systems and browsers a very large number of so-called “Root Certification Authority” (Root CA) certificates are trusted by the CA Browser Forum as public
  • unauthorized third parties try to obtain a TLS server certificate for a foreign domain. If this succeeds, the unauthorized third party can set up its own web server and mask it as the web server of that domain; A user will then no longer receive a warning in the browser and may become the target of criminal attacks on the part of the unauthorized third party.
  • Certificate Revocation Lists (certificate revocation list CRL, RFC5280) regularly issued by the Certification Authority, at least until the end of the validity period contained in the certificate, and / or the status is determined by means of OCSP (online certificate status protocol OCSP, RFC6960).
  • the certificate or domain owner currently has no control over whether a revocation of his certificate is comprehensive and permanent, i. E. that the revoked certificate is included in all revocation lists created by the CA, at least until the validity period contained in the certificate expires, and that OCSP services correctly communicate the status of all requests.
  • the problem underlying the invention is to provide a solution which overcomes the disadvantages of the prior art.
  • This object is achieved by the method for handling authenticity certificates for entities, in particular personal, service-related and / or object-related certificates, based on the preamble of claim 1, solved by the characterizing features, and by the device for handling authenticity certificates for entities, in particular personal,dienstbezo gene and / or object-related certificates, starting from the preamble of the claim 15 solved by its characterizing features. Furthermore, it solves the computer program product according to the preamble of claim 16 by its characterizing features.
  • a. generating a certificate is at least initiated by the authentication enabling device
  • the generated certificate is transmitted to the authentication enabling device, c. the authentication-enabling device is at least initiated so that each entity to be certified is provided with a uniquely assigned digital certificate,
  • second data clearly related to the certificate are stored in such a way that the second data are stored trustworthy over a communication network, in particular the Internet, preferably publicly, retrievable,
  • the second data are supplemented at the occurrence of a certificate to the certificate, the time of the creation subsequent event following at the respective time point by third data that uniquely identify the respective event.
  • the method of the invention provides a solution that is independent of who creates a certificate and regardless of where that certificate is created is, because the Authentleitersermögli- device according to the invention initiates at least the creation.
  • the flexibility that allows the certification is carried out on behalf of the claimant or sides of the claimant itself.
  • the invention also makes it possible to reconstruct whether the product produced, in particular an industrially manufactured device, has been manufactured in a legitimate manner or has entered the market by the claimant, since the network, in particular internet, communi As a trusted data handling method, it will enable reliable and, for anyone, product authentication, in application to the certificates and their associated data.
  • the invention is characterized above all by the fact that, additionally, management of the certificate life cycle is made transparent and at the same time tamper-proof. This makes a significant contribution to the "Internet of Things" and digitalization in the industry, which helps solving technical security issues, and also enables a customer to check the authentication of mobile communication devices, such as smartphones, at the time of purchase can refrain from the purchase of illegal goods.
  • the deposit of the first, second and third data can be done locally separately. However, it is also advantageous to continue education in which the second and / or third data are stored together in association with the first data, so that, for example, it is easier to access associated data or to simply produce affiliation, in particular through the structure of the storage.
  • a simple and effective realization of the publicly accessible storage is considered in the further development of the invention.
  • the method according to the invention is achieved, in which the trustworthy storage of the data is carried out as a continuous archiving of the first, second and / or third data in the manner of a logbook, in particular as at least one logging file.
  • a log book also allows the tracking of events over time by means of the respective structured entries, given in particular by the design as a protocol file.
  • the method according to the invention is preferably developed in such a way that the archiving is carried out in such a way that the data is stored invariably. This increases the reliability of the data both at the current time and in terms of time.
  • the method according to the invention can be developed in such a way that at least one of each issued certificates is reproduced as second data in the logging file. This at least provides the opportunity to determine which certificates have been issued.
  • the second data stored is a chain of certification bodies assigned to each certificate, originating from one issuing to one original certification authority.
  • the creation of the certificate can be traced without gaps. be done.
  • This transparency also makes it possible to identify and / or find any corrupted and / or unsafe places.
  • the reliability is further ge increases in the context of the invention, if the inventive method is further developed such that the preceding claim, characterized in that a link of the entries of the first and or second information by means of a digital signature Ver proceedings, in particular according to the so-called Merkle hash tree or Merkle signature method or a derivative thereof, are deposited in the log file.
  • the generation of the certificate by at least one trustworthy Zertaimssein direction is made.
  • the authentication device sends a status change message structured in particular according to RFC5820, Chapter 5.1, "CRL Fields” or De rivaten thereof, that at least parts of it form
  • the third data can be used, then for events in the life cycle of a certificate, in particular the recall of a certificate, by anyone in a standardized Wei se to trusted, especially the logbook leading, third parties involved in these operations.
  • the method according to the invention is preferably developed in such a way that a confirmation message containing at least one acknowledgment message, in particular structured in accordance with RF 6962, Chapter 3.2, "Structure of the Signed Certificate Timestamp” or derivatives thereof, is sent to the authentication device on the status change message This ensures that the validity of the recall goes hand in hand with the time of the public deposit of this event.
  • queries status response messages are formed according to the protocol such that they contain at least a reproducing from a issuing to a ur nal certification authority resulting chain of certification authority information and at least parts of the third data , This allows manipulation of possible status changes /
  • the method according to the invention is preferably embodied in such a way that the third data are formed in such a way that they contain at least the generation, the recall, the expiration of the validity or other information describing the status of the certificate.
  • the Vorrich device helps to enable the authentication of, in particular persons, services and / or industrially manufactured objects or devices, which is characterized by means for performing the method and / or its training.
  • FIG. 1 shows an embodiment of the method according to the invention as a flowchart.
  • That it is e.g. a device in circulation or in operation, to which a certificate has been created, and this fact is traceable by a third party via Internet retrievable, especially formed by the type of certificate transparency, log file.
  • a recall of the certificate for example by a certificate authority (CA), in particular also derived from the Certificate Transparency (CT) method, initiated.
  • CA certificate authority
  • CT Certificate Transparency
  • This initiation then leads, in a third step S3, to the transmission of a message to the device carrying the log.
  • the message can, for example, as a
  • step S4 After receipt of the message at the device CT is then responded in a fourth step S4 to the initiator of the call back with a digitally signed timestamp, wel cher indicating the time at which the A device log entry to the event of the recall of the certificate the logbook entry has been carried out in a fifth step S5 according to CT Ver.
  • the message with the time stamp for example, can be structured as a "Signed Revocation Timestamp” based on the RFC6962, 3.2 "Structure of the Signed Certificate Timestamp” as follows: struct ⁇
  • SignatureType signature_type cer tificate ⁇ imestamp
  • Pre_Revoke_entry PreRevoke
  • a device If a device is equipped with a new certificate, for example during maintenance of the device, it can use the new certificate for authentication. If this is not the case, the device remains in a state with an invalid, verifiably recalled certificate. The further operation would therefore no longer be safe, and the
  • any events in the lifecycle of a certificate can be continuously archived in a logfile using the CT scan. Also, there is no limit to the way of applying the certificate and the entity provided with it.
  • Root CA Room Certification Authority
  • a new certificate If a new certificate is to be issued, the certificate will be sent to the log.
  • the log responds with a digitally signed timestamp that represents the promise of the log to complete the certificate within a defined time (Medium Merge Delay, MMD) into the hash tree.
  • New certificates are then added to the list and the hash tree is expanded.
  • the property of the log that each hash tree completely encloses the previous hash tree does not require trusting the log operator, and the CA can no longer remove or deny the exhibit at a later date.
  • the invention advantageously accommodates this development by providing Certificate Transparency (CT) for more than just logging the issuance of TLS server certificates that can be tested for a root certificate that has been trusted by the CA Browser Forum. Namely, it enables public documents to be publicly documented of other types of certificates and other relevant events related to the management of a certificate through the inven tion beyond the certificate transparency.
  • CT Certificate Transparency
  • TLS server certificates e.g. Expiration, recall or
  • Certificate Revocation List listing the recalled certificate.
  • the owner of the certificate must rely on the security of the operation of the CA, because an attacker who can misuse the CA key can, if the inventive method is not used, issue a CRL without the new entry.
  • the invention achieves that transparency for the issuance of TLS server certificates by publicly trustworthy certificate authorities is extended to further certificate management activities.
  • se / status changes are stored in a log file associated with each other. This can also be done in separate, if necessary by se paraten institutions supervised, log files, which are just if set up so that a clear assignment of certificate to management events / status changes is guaranteed.
  • the CA in the event of a certificate recall, the CA is to send the new entry of the CRL as a pre-revocation entry to the log and from there receive a Signed Revocation Timestamp (SRT). Similar to the SCT, a list of SRTs, for example, can be entered as an extension in the new CRL entry or in the OCSP response.
  • SRT Signed Revocation Timestamp
  • the owner of a certificate has the opportunity to publicly carry out the successful recall of his certificate.
  • users of a certificate can verify in the certificate status information whether the specified time for the recall of the certificate is authentic and was not changed by the CA in error.
  • a certificate check instead of CRLs or OCSP, both typically operated by the CA, can also be done by querying a monitor according to Certificate Transparency.
  • the invention is not limited to the Principalsbei games discussed. Rather, it encompasses all variants covered by the claims, provided that they have the feature in particular that (in addition to the issuance of certificates), further certificate management events can be invariably documented in public and thus also events such as e.g. the revocation of a certificate by the holder can be monitored in detail.
  • the OCSP Response can contain the path to the root of the hash tree; This allows the recipient to additionally check the OCSP response.

Abstract

Die Erfindung betrifft ein Verfahren zur Behandlung von Authentizitätsbescheinigungen für Entitäten, insbesondere von personenbezogenen, dienstbezogenen und/oder objektbezogenen digitalen Zertifikaten, bei dem a. ein Erzeugen eines Zertifikats durch die Authentisierungsermöglichungseinrichtung zumindest initiiert wird, b. das erzeugte Zertifikat an die Authentisierungsermöglichungseinrichtung übermittelt wird, c. durch die Authentisierungsermöglichungseinrichtung zumindest initiiert wird, dass jede zu zertifizierende Entität mit einem eindeutig zugeordneten digitalen Zertifikat versehen wird, d. zumindest für jedes Zertifikat zweite mit dem Zertifikat eindeutig in Bezug stehende Daten derart gespeichert werden, dass die zweiten Daten über ein Kommunikationsnetzwerk, insbesondere dem Internet, vorzugsweise öffentlich, abrufbar vertrauenswürdig hinterlegt werden, e. die Hinterlegung der zweiten Daten bei Eintritt eines eindeutig zum Zertifikat bezogenen zeitlich der Erstellung nachfolgenden Ereignisses zum jeweiligen Zeitpunkt durch dritte Daten ergänzt werden, die das jeweilige Ereignis eindeutig kennzeichnen. Die Erfindung betrifft weiterhin eine Vorrichtung mit Mitteln zur Durchführung des Verfahrens sowie ein Computerprogrammprodukt.

Description

Beschreibung
Verfahren und Vorrichtung zur Behandlung von Authentizitäts bescheinigungen für Entitäten, insbesondere von personenbezo genen, dienstbezogenen und/oder objektbezogenen digitalen Zertifikaten
Die Erfindung betrifft ein Verfahren zur Behandlung von Au thentizitätsbescheinigungen für Entitäten, insbesondere von personenbezogenen, dienstbezogenen und/oder objektbezogenen digitalen Zertifikaten, gemäß dem Oberbegriff des Anspruchs 1 sowie eine Vorrichtung zur Behandlung von Authentizitätsbe scheinigungen für Entitäten, insbesondere von personenbezoge nen, dienstbezogenen und/oder objektbezogenen digitalen Zer tifikaten, gemäß dem Oberbegriff des Anspruchs 15. Sie be trifft ferner ein Computerprogrammprodukt gemäß dem Oberbe griff des Anspruchs 16.
Objektbezogene Zertifikate sind bekannt, insbesondere Geräte zertifikate sowie vom Hersteller für von ihm produzierte Pro dukte erstellte Zertifikate.
Es ist ferner bekannt, dass in der so genannten „Information Technology" (IT) im Zuge der stark zunehmenden Bedrohung von Hacking sich die Nutzung von digitalen Zertifikaten stark verbreitet hat.
Nicht nur in der Information Technology gewinnen Zertifikate zunehmend an Bedeutung. Auch in der so genannten „Operational Technology", (OT) , unter der vereinfacht das Monitoring und die Steuerung von physikalischen Zuständen eines Systems, beispielweise die Prozessteuerung im industriellen Umfeld, durch Computer verstanden werden kann, werden für die Absi cherung vermehrt digitale Zertifikate eingesetzt.
Bei (Schlüssel-) Zertifikaten handelt es sich um Authentizi- tätsbescheinigungen, wobei es bei einem zertifikatbasierten System bekannt ist, dass jede Person oder jedes Objekt ein digitales Zertifikat besitzt, welches Angaben zu seiner Iden tität, im Falle von Schlüsselzertifikaten auch einen öffent lichen Schlüssel, der Person bzw. des Objekts enthält. Jedes Zertifikat ist von einer ausgebenden Stelle, einer so genann ten Certificate Authority (CA) , durch eine digitale Signatur beglaubigt, die ihrerseits wieder von höheren Stellen beglau bigt sein kann. Das Vertrauenssystem einer solchen Public Key Infrastructure PKI ist streng hierarchisch. Den gemeinsamen Vertrauensanker bildet ein sogenanntes Wurzelzertifikat, auch „Root Certificate" genannt.
Der Domäneninhaber hat derzeit eine große Auswahl an Anbie tern, die Zertifikate erstellen, da in aktuellen Betriebssys temen und Browsern eine sehr große Zahl von so genannten „Root Certification Authority" (Root CA) Zertifikaten durch das CA-Browser Forum als öffentlich vertrauenswürdig
(„publicly trusted") eingestuft sind.
Gelegentlich kommt es vor, dass unberechtigte Dritte versu chen ein TLS-Serverzertifikat für eine fremde Domäne zu er langen. Gelingt dies, so kann der unberechtigte Dritte einen eigenen Webserver aufsetzen und diesen als Webserver jener Domäne maskieren; ein Anwender bekommt dann keine Warnung mehr im Browser angezeigt und kann Ziel von kriminellen An griffen seitens des unberechtigten Dritten werden.
In der Vergangenheit hat es bereits verschiedene Vorfälle dieser Art gegeben, bei denen Angreifern unrechtmäßig ein Zertifikat von einer vertrauenswürdigen Certificate Authority ausgestellt wurde. Dies liegt unter anderem an unzureichenden Prüfungen der Certificate Authorities, ob der Antragsteller wirklich der berechtigte Inhaber für die beantragte Domäne ist. Selbst bei einer überschaubaren Anzahl von als vertrau enswürdig eingestuften Certificate Authorities wäre es schon schwierig, die Rechtmäßigkeit aller erstellten Zertifikaten nachzuvollziehen und gegebenenfalls unrechtmäßig ausgestellte Zertifikate widerrufen zu lassen. Doch durch die hohe Anzahl der als vertrauenswürdig einge stuften Certificate Authorities ist es für den Domäneninhaber nahezu unmöglich herauszufinden, welche TLS-Serverzertifikate von diesen vertrauenswürdigen Certificate Authorities für seine Domäne ausgestellt wurden. Der Domäneninhaber kann also in der Regel vor einem Vorfall nicht wissen, ob es auch unbe fugt ausgestellte Zertifikate für seine Domäne gibt, und kann diese daher nicht widerrufen lassen.
Durch die Zunahme von Angeboten zur Zertifikatsausstellung wird deren Qualitätskontrolle, vor Allem im Hinblick auf die Sicherheit der Angebote, immer schwieriger.
Digitale Zertifikate können widerrufen werden, beispielsweise wenn sie unberechtigt oder fehlerhaft ausgestellt wurden, wenn die zugehörigen privaten Schlüssel kompromittiert wurden oder wenn sie nicht mehr verwendet werden. Diese Zertifikate werden dann - zumindest bis zum Ablauf des im Zertifikat ent haltenen Gültigkeitszeitraums - in regelmäßig von der Certi- fication Authority ausgestellte Zertifikatssperrlisten (cer tificate revocation list CRL, RFC5280) eingetragen, und/oder der Status wird mittels OCSP (online certificate Status protocol OCSP, RFC6960) kommuniziert.
Auch hier hat der Zertifikats- bzw. Domäneninhaber derzeit keine Kontrolle darüber, dass ein Widerruf seines Zertifika tes umfassend und dauerhaft ist, d.h. dass das widerrufene Zertifikat - zumindest bis zum Ablauf des im Zertifikat ent haltenen Gültigkeitszeitraums - in allen von der CA erstell ten Widerrufslisten enthalten ist, und dass OCSP-Dienste bei allen Anfragen den Status korrekt kommunizieren.
Die der Erfindung zugrundeliegende Aufgabe ist es eine Lösung anzugeben, die die Nachteile des Standes der Technik überwin det .
Diese Aufgabe wird durch das Verfahren zur Behandlung von Au thentizitätsbescheinigungen für Entitäten, insbesondere zu personenbezogenen, dienstbezogenen und/oder objektbezogenen Zertifikaten, ausgehend vom Oberbegriff des Anspruchs 1, durch dessen kennzeichnenden Merkmale gelöst, sowie durch die Vorrichtung zur Behandlung von Authentizitätsbescheinigungen für Entitäten, insbesondere zu personenbezogenen, dienstbezo genen und/oder objektbezogenen Zertifikaten, ausgehend vom Oberbegriff des Anspruchs 15 durch dessen kennzeichnende Merkmale gelöst. Ferner löst es das Computerprogrammprodukt gemäß dem Oberbegriff des Anspruchs 16 durch dessen kenn zeichnende Merkmale.
Beim erfindungsgemäßen Verfahren zur Behandlung von Authenti- zitätsbescheinigungen für Entitäten, insbesondere zu perso nenbezogenen, dienstbezogenen und/oder Gerätezertifikaten, a. wird ein Erzeugen eines Zertifikats durch die Au- thentisierungsermöglichungseinrichtung, zumindest initiiert,
b. wird das erzeugte Zertifikat an die Authentisie- rungsermöglichungseinrichtung übermittelt, c. wird die Authentisierungsermöglichungseinrichtung zumindest initiiert, dass jede zu zertifizierende Entität mit einem eindeutig zugeordneten digitalen Zertifikat versehen wird,
d. werden zumindest für jedes Zertifikat zweite mit dem Zertifikat eindeutig in Bezug stehende Daten derart gespeichert, dass die zweiten Daten über ein Kommunikationsnetzwerk, insbesondere dem Internet, vorzugsweise öffentlich, abrufbar vertrauenswürdig hinterlegt,
e. werden die zweiten Daten bei Eintritt eines eindeu tig zum Zertifikat bezogenen, zeitlich der Erstel lung nachfolgenden Ereignisses zum jeweiligen Zeit punkt durch dritte Daten ergänzt, die das jeweilige Ereignis eindeutig kennzeichnen.
Durch die erfindungsgemäße Verfahrensweise wird eine Lösung bereitgestellt, die unabhängig davon ist, wer ein Zertifikat erstellt, und unabhängig davon, wo dieses Zertifikat erstellt wird, denn die erfindungsgemäße Authentisierungsermögli- chungsvorrichtung initiiert zumindest die Erstellung. Hier durch ergibt sich als ein erster Vorteil der Erfindung die Flexibilität, die erlaubt, dass die Zertifizierung im Auftrag des Berechtigten oder Seiten des Berechtigten selbst erfolgt. Die Erfindung ermöglicht weiterhin, dass nachvollzogen werden kann, ob das hergestellte Erzeugnis, insbesondere ein indust riell gefertigtes Gerät, berechtigt hergestellt worden ist bzw. durch den Berechtigten auf den Markt gelangt ist, da durch die in der Netzwerk-, insbesondere Internet-, Kommuni kation als vertrauenswürdige (trusted) Datenbehandlung be kannten Verfahren in Anwendung auf die Zertifikate und ihnen zugeordneten Daten eine zuverlässige und für jedermann er sichtliche Produktauthentisierung ermöglicht wird. Die Erfin dung zeichnet sich vor allem dadurch aus, dass hierzu zusätz lich ein Management des Zertifikatslebenszyklus transparent und zugleich manipulationssicher zugänglich gemacht wird. Hierdurch wird ein maßgeblicher Beitrag zum „Internet of Things" und der Digitalisierung in der Industrie geleistet, der aufgeworfenen Sicherheitsfragen technisch zu lösen hilft. Letzeres ermöglicht auch, dass ein Kunde bereits beim Kauf die Authentisierung durch mobile Kommunikationsgeräte, wie beispielsweise den Smartphones, prüfen und so den Kauf ille galer Ware unterlassen kann.
Weitere vorteilhafte Ausgestaltungen der Erfindung sind in den Unteransprüchen gegeben.
Die Hinterlegung der ersten, zweiten und dritten Daten kann örtlich separat erfolgen. Von Vorteil ist jedoch auch Weiter bildung bei der die zweiten und/oder dritten Daten zu den ersten Daten zugeordnet gemeinsam hinterlegt werden, so lässt sich beispielsweise schneller auf zugehörige Daten zugreifen bzw. die Zugehörigkeit, insbesondere durch die Struktur der Speicherung, einfach hersteilen.
Eine einfache und effektive Realisierung der öffentlich zu gänglichen Speicherung wird bei der Weiterbildung des erfin- dungsgemäßen Verfahrens erreicht, bei der die vertrauenswür dige Hinterlegung der Daten als fortlaufende Archivierung der ersten, zweiten und/oder dritten Daten nach Art eines, insbe sondere als zumindest eine Protokollierungsdatei ausgestalte ten, Logbuchs durchgeführt wird. Ein Logbuch ermöglicht auch die Verfolgung der Ereignisse über die Zeit mittels der je weiligen, insbesondere durch die Ausgestaltung als Protokol lierungsdatei gegebenen, strukturierten Einträge.
Bevorzugt wird das erfindungsgemäße Verfahren dabei derart weitergebildet, dass die Archivierung derart durchgeführt wird, dass die Daten unveränderlich gespeichert sind. Dies erhöht die Verlässlichkeit der Daten sowohl zum aktuellen Zeitpunkt aber auch zeitlichen Rückschau.
Um eine, insbesondere gerichtliche, Anforderungen an die Be weiskraft der protokollierten Ereignisse zu gewährleisten, eignet sich besonders die Weiterbildung des erfindungsgemäßen Verfahrens bei dem die Archivierung revisionssicher, insbe sondere zumindest eine der nach dem Handelsgesetzbuch - HGB - abgeleiteten Kriterien für eine elektronische Archivierung erfolgt. Revisionssicher ist dabei länderspezifisch nach der dortigen Jurisdiktion zu verstehen. Daher ist insbesondere die Erfüllung der Kriterien nach HGB beispielsweise für die in Deutschland definierte Revisionssicherheit von Vorteil.
Alternativ oder ergänzend kann das erfindungsgemäße Verfahren derart weitergebildet sein, dass als zweite Daten in der Protokollierungsdatei zumindest eine jedes ausgestellten Zer tifikate wiedergebende erste Information gespeichert wird. Hierdurch wird zumindest die Möglichkeit gegeben festzustel len, welche Zertifikate ausgestellt worden sind.
Vorteilhaft weitergebildet wird dies wenn als zweite Daten eine die zu jedem Zertifikat zugeordnete sich von einer aus gebenden bis zur einer ursprünglichen Zertifizierungsstelle ergebende Kette von Zertifizierungsstellen gespeichert wird. Hierdurch kann lückenlos die Erstellung des Zertifikats nach- vollzogen werden. Diese Transparenz lässt es auch zu etwaige korrumpierte und/oder unsichere Stellen zu erkennen und/oder aufzufinden .
Die Zuverlässigkeit wird weiter im Sinne der Erfindung ge steigert, wenn das erfindungsgemäße Verfahren derart weiter gebildet wird, dass vorhergehenden Anspruch, dadurch gekenn zeichnet, dass eine Verknüpfung der Einträge der ersten und oder zweiten Information mittels eines digitalen Signaturver fahrens, insbesondere gemäß dem so genannten Merkle-Hash-Tree oder Merkle-Signatur-Verfahren oder einem Derivat hiervon, in der Protokollierungsdatei hinterlegt werden.
Bei einer weiteren vorteilhaften Ausgestaltung des erfin dungsgemäßen Verfahrens wird das Erzeugen des Zertifikats durch zumindest eine vertrauenswürdige Zertifizierungsein richtung (certification authority) vorgenommen.
Hiermit wird auf ein erprobtes und verbreitetes Verfahren zu rückgegriffen, so dass eine Implementierung aber auch Nutzung in vorteilhafter Weise gefördert wird, beispielswiese weil entweder der berechtige Hersteller bzw. Markeninhaber selbst diese Zertifizierung vornehmen kann, in dem er bekannte Kom ponenten zur Implementierung einkauft und zumindest teilweise in seinem Einflussbereich einrichtet, indem er in dem hierfür bestehenden Netzwerk diese Komponenten integriert. Aufwands ärmer und für eher kleinere Unternehmen geeignet ist es, wenn die Leistung der Zertifizierung bei externen Anbietern einge kauft wird. Die Auslagerung dieser Dienstleistung ganz oder teilweise ist unter anderem dank der öffentlichen Protokol lierung gleichwertig möglich, da sich beide Varianten dem Zu griff eines unberechtigten Herstellers entziehen.
Dieser Vorteil wird noch verstärkt, wenn das erfindungsgemäße Verfahren derart weitergebildet wird, dass die Zertifizie rungseinrichtung gemäß dem RFC6962, insbesondere dem so ge nannten „Certificate Transparency" oder Derivaten hiervon, betrieben und funktional mit der Authentisierungseinrichtung verbunden wird. Hierdurch bemächtigt man sich eines erprobten Verfahrens, das sich nicht zuletzt durch den Einfluss des Initiators Google bei der Erstellung von TLS- Serverzertifikaten durchsetzt. Da hierdurch Manipulationen der Zertifikatserzeugung erkennen lassen, eignet es sich her vorragend für den Einsatz im Zusammenhang mit dem erfindungs gemäßen Verfahren und bietet eine bereits bestehende Infra struktur, die mit geringer Anpassung das erfindungsgemäße Verfahren implementieren kann.
Wird das erfindungsgemäße Verfahren derart weitergebildet, dass die Authentisierungseinrichtung nach Auftreten eines ei nen Status eines Zertifikats verändernden Ereignisses eine, insbesondere nach RFC5820, Kapitel 5.1, „CRL Fields" oder De rivaten hiervon strukturierte, Statusänderungsnachricht der art versendet, dass zumindest Teile davon zur Bildung der dritten Daten herangezogen werden, dann können für Ereignisse im Lebenszyklus eines Zertifikats, insbesondere dem Rückruf eines Zertifikats, durch jeden in einer standardisierten Wei se an vertrauenswürdige, insbesondere das Logbuch führende, Dritte in diese Vorgänge involviert werden.
Bevorzugt wird das erfindungsgemäße Verfahren dabei derart weitergebildet, dass an die Authentisierungsermöglichungsein- richtung auf die Statusänderungsnachricht eine zumindest ei nen, insbesondere nach dem RF 6962, Kapitel 3.2, „Structure of the Signed Certificate Timestamp" oder Derivaten hiervon strukturierten, Zeitstempel enthaltende Bestätigungsnachricht versandt wird. Hierdurch kann gewährleistet werden, dass die Gültigkeit des Rückrufs mit dem Zeitpunkt der öffentlichen Hinterlegung dieses Ereignisses einhergeht.
Von Vorteil ist es dabei, wenn das erfindungsgemäße Verfahren derart weitergebildet wird, dass Abfragen zum Status von Zer tifikaten mittels Protokoll, insbesondere dem Online Certifi cate Status Protocol, „OCSP" oder, insbesondere Positivaus künfte realisierenden, Derivaten hiervon, erfolgen. Hierdurch kann die Abfrage strukturiert, insbesondere ausgehend von OCSP bei der Implementierung geringe Anpassung erforderlich machend, realisiert werden.
Eine weitere vorteilhafte Weiterbildung des erfindungsgemäßen Verfahrens ist gegeben, wenn auf die Abfragen Statusantwort nachrichten gemäß dem Protokoll derart gebildet werden, dass zumindest sie eine von einer ausgebenden bis zur einer ur sprünglichen Zertifizierungsstelle ergebende gespeicherte Kette von Zertifizierungsstellen wiedergebende Information und zumindest Teile der dritten Daten enthalten. Hierdurch können Manipulationen von möglichen Statusänderungen/
-ereignissen von Seiten unberechtigter Dritter erkannt wer den, da dies anhand der Kette und der dritten Daten nachvoll ziehbar wird.
Vorzugsweise wird das erfindungsgemäße Verfahren derart wei tergebildet, dass die dritten Daten derart gebildet werden, dass sie zumindest die Erzeugung, den Rückruf, den Ablauf der Gültigkeit oder andere den Status des Zertifikats beschrei bende Informationen enthalten. Hierdurch werden alle im Rah men des Managements eines Zertifikats anfallenden Ereignisse und/oder der jeweilige Status für Dritte nachvollziehbar, so mit transparent und jeder Status eines Zertifikats für unbe merkte Manipulationen weniger anfällig.
Für die Implementierung und damit bei der Realisierung der Vorteile des Verfahrens hilft die erfindungsgemäße Vorrich tung zur Ermöglichung der Authentisierung von, insbesondere Personen, Diensten und/oder industriell gefertigten Objekten bzw. Geräten, welches gekennzeichnet ist durch Mittel zur Durchführung des Verfahrens und/oder seiner Weiterbildungen.
Gleiches gilt für Computerprogrammprodukt, welches die Aufga be ebenfalls löst und die Vorteile des Verfahrens dadurch verwirklichen hilft, dass es direkt in einen Speicher eines digitalen Prozessors ladbar ist, umfassend Programmcodeteile, die dazu geeignet sind, die Funktionen des Verfahrens bzw. seiner vorstehend genannten Weiterbildungen durchzuführen. Ausführungsbeispiele sowie weitere Vorteile und Ausgestal tungsvarianten des erfindungsgemäßen Verfahrens werden anhand der in der einzigen Figur dargestellten Zeichnung im Rahmen der nachfolgenden Beschreibung näher erläutert. Es zeigt die
Figur eine Ausführungsform des erfindungsgemäßen Verfah rens als Ablaufdiagramm.
In der Figur ist schematisch ein Ablauf eines Ausführungsbei spiels des erfindungsgemäßen Verfahrens dargestellt und wird zunächst anhand der Schritte skizziert. Es beginnt mit einem als erster Schritt S1 bezeichneten Zustand „Zertifikat gül tig" .
D.h. es ist z.B. ein Gerät im Umlauf bzw. im Betrieb, zu dem ein Zertifikat erstellt worden ist, und diese Tatsache ist durch ein für Dritte über Internet abrufbaren, insbesondere nach Art des Certificate Transparency Verfahren gebildetes, Logfile nachvollziehbar.
Aus diesem Zustand heraus wird in einem zweiten Schritt S2, ein Rückruf des Zertifikats, beispielsweise durch eine Certi ficate Authority (CA) , insbesondere ebenfalls abgeleitet vom Certificate Transparency (CT) Verfahren, initiiert.
Diese Initiierung führt dann in einem dritten Schritt S3 zur Übermittlung einer Nachricht an die den Log führende Einrich tung .
Die Nachricht kann dabei beispielsweise als ein
„Prerevocation Entry" beruhend auf dem RFC5820, 5.1. „CRL Fields" wie folgt strukturiert aufgebaut sein: tbs_revoked SEQUENCE {
userCertificate CertificateSerialNumber, revocationDate Time,
crlEntryExtensions Extensions OPTIONAL -- if present, version MUST be v2
}
Nach Eingang der Nachricht bei der Einrichtung wird gemäß CT sodann in einem vierten Schritt S4 an den Initiator des Rück rufs mit einem digital signierten Zeitstempel antwortet, wel cher die Angabe des Zeitpunkts wiedergibt, an dem die Ein richtung einen Logbucheintrag zum Ereignis des Rückrufs des Zertifikats vorgenommen haben wird, wobei die Durchführung des Logbucheintrags in einem fünften Schritt S5 gemäß CT Ver fahren erfolgt.
Die Nachricht mit dem Zeitstempel kann dabei beispielsweise als „Signed Revokation Timestamp" beruhend auf dem RFC6962, 3.2. „Structure of the Signed Certificate Timestamp" wie folgt strukturiert aufgebaut sein: struct {
Version srt_version;
LogID id;
uint64 timestamp;
CtExtensions extensions;
digitally-signed struct {
Version srt_version;
SignatureType signature_type = cer tificate^imestamp;
uint64 timestamp;
LogEntryType entry_type;
Pre_Revoke_entry : PreRevoke;
} signed_entry;
CtExtensions extensions;
} ;
} SignedRevokationTimestamp;
struct {
opaque issuer_key_hash [ 32 ] ;
TBSRevoked tbs revoked;
} PreRevoke; In einem sechsten Schritt S6 ist nun das Zertifikat nicht mehr gültig.
Sofern ein Gerät mit einem neuen Zertifikat ausgestattet wird, beispielsweise während einer Wartung des Gerätes, kann es das neue Zertifikat zur Authentisierung verwenden. Erfolgt dies nicht, verbleibt das Gerät in einem Zustand mit einem ungültigen, da nachweisbar zurückgerufenen Zertifikat. Der weitere Betrieb wäre somit nicht mehr sicher, und die
Authentisierung würde gemäß diesem Anwendungsbeispiel von an deren Geräten entsprechend deren Richtlinien zur Akzeptanz von Zertifikaten abgelehnt werden.
Die Erfindung ist nicht auf dieses Ausführungsbeispiel be schränkt. Vielmehr können beliebige Ereignisse im Lebenszyk lus eines Zertifikats mit Hilfe des CT fortlaufend und abruf bar in einem Logfile archiviert werden. Auch ist für die Art der Anwendung des Zertifikats und der Entität, die mit ihm versehen wird, keine Grenze gesetzt.
Die Erfindung begegnet auf vorteilhafte Weise der im Folgen den skizierten Entwicklung:
In aktuellen Betriebssystemen und Browsern wird eine sehr große Zahl von so genannten „Root Certification Authority" (Root CA) Zertifikaten durch das CA-Browser Forum als öffent lich vertrauenswürdig („publicly trusted") eingestuft. Be zieht ein Domäneninhaber ein TLS-Serverzertifikat für seine Domäne (z.B. für einen Web-Shop) von einer dieser Certificate Authorities, wird einem Anwender (Kunden) über seinen Browser eine sichere Verbindung zu dieser Website angezeigt; andern falls erhält der Anwender eine Warnung, dass eine sichere Verbindung zur gewünschten Webseiten nicht aufgebaut werden konnte. Gelingt es einem Angreifer, ein TLS-Serverzertifikat für eine fremde Domäne zu erlangen, so kann er einen eigenen Webserver aufsetzen und diesen als Webserver jener Domäne maskieren; ein Anwender bekommt dann keine Warnung mehr im Browser angezeigt.
In der Vergangenheit hat es bereits verschiedene Vorfälle ge geben, bei denen Angreifern unrechtmäßig ein Zertifikat von einer vertrauenswürdigen Certificate Authority ausgestellt wurde. Mit diesem Zertifikat konnte sich der Angreifer mit der Identität seines Opfers, z.B. einem Webserver der Domäne google.com, maskieren.
Durch die hohe Anzahl der als vertrauenswürdig eingestuften Certificate Authorities ist es für den Domäneninhaber prak tisch unmöglich herauszufinden, welche TLS-Serverzertifikate von diesen vertrauenswürdigen Certificate Authorities für seine Domäne ausgestellt wurden. Der Domäneninhaber kann also i.d.R. vor einem Vorfall nicht wissen, ob es auch unbefugt ausgestellte Zertifikate für seine Domäne gibt, und kann die se daher nicht widerrufen lassen.
Da es einem Domäneninhaber nahezu unmöglich war herauszufin den, wer für seine Domäne ein Zertifikat beantragt oder er halten hat, hat Google die Initiative „Certificate
Transparency" ins Leben gerufen. Mit Certificate Transparency wird das Ereignis einer Ausstellung eines Webserverzertifi- kats durch eine von Browsern als vertrauenswürdig eingestuf ten Certificate Authority in (mindestens) zwei sogenannten „Log" (Protokollierungsdatei) öffentlich dokumentiert. Das Log besteht dabei aus
1) einer vollständigen Liste aller erzeugten Zertifikate (jeweils die Zertifikatskette bis zur Root-CA) , und
2) der Verknüpfung dieser Listeneinträge mittels eines
Merkle Hash Tree.
Soll ein neues Zertifikat ausgestellt werden, wird das Zerti fikat an den Log geschickt. Der Log antwortet mit einem digi tal signiertem Zeitstempel, der das Versprechen des Logs dar stellt, das Zertifikat binnen einer definierten Zeit (Medium Merge Delay, MMD) in den Hash Tree zu integrieren. Neue Zer tifikate werden dann in die Liste hinzugefügt und der Hash Tree wird erweitert. Durch die Eigenschaft des Logs, dass je der Hash Tree den vorhergehenden Hash Tree vollständig ent hält, muss dem Log-Betreiber nicht vertraut werden, und die CA kann die Ausstellung zu einem späteren Zeitpunkt nicht mehr aus dem Log entfernen oder abstreiten. Durch das
Monitoring aller Logs, deren Anzahl deutlich kleiner ist als die Anzahl der Certificate Authorities, soll es dem Domänen inhaber möglich werden herauszufinden, welche CA für seine Domäne TLS-Serverzertifikate ausgestellt hat.
Die Erfindung begegnet dieser Entwicklung vorteilhaft, da sie Certificate Transparency (CT) zugänglich macht für mehr als nur das Protokollieren der Ausstellung von TLS- Serverzertifikaten, die auf ein Root Zertifikat hin geprüft werden können, das vom CA-Browser Forum als vertrauenswürdig ausgewiesenen wurde. Es ermöglicht nämlich, dass andere Arten von Zertifikaten sowie damit verknüpfte weitere maßgebliche Ereignisse zum Management eines Zertifikates durch die Erfin dung über das Certificate Transparency hinausgehend öffent lich dokumentiert werden.
Damit geht es also über CT hinaus, in dem sie beispielsweise auch die Aktivitäten von Certificate Authorities bezüglich
1) anderer Managementaktivitäten von TLS- Serverzertifikaten, z.B. Ablauf, Rückruf oder
Entsperrung, sowie
2) anderer Zertifikate, z.B. zur Signatur von Software oder zur Authentifizierung von Personen oder Maschinen, überwachbar zu machen.
Weitere über das dargestellte Ausführungsbeispiel hinausge hende Zertifikatsmanagementereignisse ergeben sich beispiels weise auch, wenn ein Eigentümer eines Zertifikates dieses zu rückgerufen will, weil es beispielsweise im Zuge eines An- griffs möglicherweise kompromittiert wurde. Dann wird die CA eine neue Zertifikatswiderrufliste (Certificate Revocation List CRL) ausstellen, auf der das zurückgerufene Zertifikat aufgelistet ist. Der Eigentümer des Zertifikates muss sich auf die Sicherheit des Betriebs der CA verlassen, denn ein Angreifer, der den CA Schlüssel missbrauchen kann, kann, wenn das erfindungsgemäße Verfahren nicht zum Einsatz kommt, eine CRL ohne den neuen Eintrag ausstellen.
Die Erfindung erreicht, dass die Transparenz für die Ausstel lung von TLS-Serverzertifikaten durch öffentlich vertrauens würdige Certificate Authorities auf weitere Zertifikatsmana gementaktivitäten ausgedehnt wird.
Dies wird gemäß den Ausführungsvarianten im Kern dadurch er reicht, dass die Funktionsweise von Logs so erweitert wird, dass, insbesondere neben der Ausstellung von Zertifikaten, auch weitere Managementaktivitäten für Zertifikate unverän derlich öffentlich dokumentiert werden können bzw. müssen. Beispielsweise kann die Dokumentation sowohl der Ausstellung der Zertifikate, als auch der Managementereignis
se/Statusänderungen in einem Logfile zueinander zugeordnet gespeichert werden. Dies kann auch in separaten, ggf. von se paraten Einrichtungen betreuten, Logfiles erfolgen, die eben falls derart eingerichtet sind, dass eine eindeutige Zuord nung von Zertifikat zu Managementereignissen/Statusänderungen gewährleistet ist.
Es sollen also in denselben Logs oder in anderen Logs weitere Ereignisse zu Zertifikaten protokolliert werden.
Beispielsweise soll bei einer Ausgestaltung der Erfindung, wie oben erläutert, bei einen Zertifikatsrückruf die CA den neuen Eintrag der CRL als Pre-revocation-entry an den Log schicken und von dort einen Signed Revocation Timestamp (SRT) zurück erhalten. Eine Liste von SRTs kann beispielsweise ähn lich dem SCT als Extension in den neuen CRL Eintrag oder in die OCSP Response eintragen werden. Durch die Veröffentlichung von Zertifikatsrückrufevents hat der Eigentümer eines Zertifikates die Möglichkeit, den er folgreichen Rückruf seines Zertifikates öffentlich nachzu vollziehen. Weiterhin können Nutzer eines Zertifikates in der Zertifikatsstatusauskunft nachvollziehen, ob der angegebene Zeitpunkt für den Rückruf des Zertifikates authentisch ist und von der CA nicht fälschlicherweise verändert wurde. So kann eine Zertifikatsprüfung anstelle mit CRLs oder OCSP, die beide typischerweise von der CA betrieben wird, auch durch Abfragen eines Monitors entsprechend Certificate Transparency erfolgen .
Die Erfindung ist nicht auf die erörterten Ausführungsbei spiele beschränkt. Vielmehr umfasst sie alle durch die An sprüche abgedeckten Varianten, sofern sie insbesondere das Merkmal aufweisen, dass (außer der Ausstellung von Zertifika ten) auch weitere Zertifikatsmanagementereignisse unveränder lich öffentlich dokumentiert werden können und damit auch Er eignisse wie z.B. der Widerruf eines Zertifikats durch den Inhaber detailliert überwacht werden können.
Sie umfasst daher neben den dargelegten Varianten und Vortei len insbesondere auch die folgenden Varianten und Vorteile:
• Unveränderliche und öffentliche Dokumentation von weite ren Zertifikatsmanagementereignissen .
• Möglichkeit von Inhabern von Zertifikaten, die seine
Person, seine Dienste oder seine Gerätschaften betref fen, Zertifikatsmanagementereignisse zu überwachen.
• Besonders vorteilhaft ist die Kombination dieses Verfah rens mit OCSP: Die OCSP Response kann den Pfad zur Root des Hash-Trees enthalten; damit kann die OCSP Response vom Empfänger zusätzlich geprüft werden.

Claims

Patenansprüche
1. Verfahren zur Behandlung von Authentizitätsbescheinigungen für Entitäten, insbesondere zu personenbezogenen, dienstbezo genen und/oder objektbezogenen digitalen Zertifikaten, da durch gekennzeichnet, dass
a. ein Erzeugen eines Zertifikats durch die Authenti- sierungsermöglichungseinrichtung, zumindest initi iert wird,
b. das erzeugte Zertifikat an die Authentisierungser- möglichungseinrichtung übermittelt wird, c. die Authentisierungsermöglichungseinrichtung zumin dest initiiert, dass jede zu zertifizierende Enti tät mit einem eindeutig zugeordneten digitalen Zer tifikat versehen wird, wobei der Entität das digi tale Zertifikat als erste Daten derart zur Verfü gung gestellt werden, dass die Entität sie bei An fragen zur Authentisierung übermitteln kann, d. zumindest für jedes Zertifikat zweite mit dem Zer tifikat eindeutig in Bezug stehende Daten, derart gespeichert werden, dass zweite Daten über ein Kom munikationsnetzwerk, insbesondere dem Internet, vorzugsweise öffentlich, abrufbar vertrauenswürdig hinterlegt werden,
e. die zweiten Daten bei Eintritt eines eindeutig zum Zertifikat bezogenen, zeitlich der Erstellung nach folgenden Ereignisses, zum jeweiligen Zeitpunkt durch dritte Daten ergänzt werden, die das jeweili ge Ereignis eindeutig kennzeichnen.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die zweiten und/oder dritten Daten zu den ersten Daten zuge ordnet gemeinsam hinterlegt werden.
3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die vertrauenswürdige Hinterlegung der ersten, zweiten und/oder dritten Daten als fortlaufende Archivierung der Da- ten nach Art eines insbesondere als zumindest eine Protokol lierungsdatei ausgestalteten Logbuchs durchgeführt wird.
4. Verfahren nach dem vorhergehenden Anspruch, dadurch ge kennzeichnet, dass die Archivierung derart durchgeführt wird, dass die Daten unveränderlich gespeichert sind.
5. Verfahren nach einem der drei vorhergehenden Ansprüche, dadurch gekennzeichnet, dass als zweite Daten in der Proto kollierungsdatei zumindest eine jedes der ausgestellten Zer tifikate wiedergebende erste Information gespeichert wird.
6. Verfahren nach dem vorhergehenden Anspruch, dadurch ge kennzeichnet, dass als zweite Daten eine die zu jedem Zerti fikat zugeordnete sich von einer ausgebenden bis zur einer ursprünglichen Zertifizierungsstelle ergebende Kette von Zer tifizierungsstellen gespeichert wird.
7. Verfahren nach einem der Ansprüche 2 bis 6, dadurch ge kennzeichnet, dass eine Verknüpfung der Einträge der ersten und oder zweiten Daten mittels eines digitalen Signaturver fahrens, insbesondere gemäß dem so genannten Merkle-Hash-Tree oder Merkle-Signatur-Verfahren oder einem Derivat hiervon, in der Protokollierungsdatei hinterlegt werden.
8. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Erzeugen des Zertifikats durch zu mindest eine vertrauenswürdige Zertifizierungseinrichtung vorgenommen wird.
9. Verfahren nach dem vorhergehenden Anspruch, dass die Zer tifizierungseinrichtung gemäß dem RFC6962, insbesondere dem so genannten „Certificate Transparency" oder Derivaten hier von, betrieben und funktional mit der Authentisierungsermög- lichungseinrichtung verbunden wird.
10. Verfahren nach einem der vorhergehenden Ansprüche, dass die Authentisierungsermöglichungseinrichtung nach Auftreten eines einen Status eines Zertifikats verändernden Ereignisses eine, insbesondere nach RFC5820, Kapitel 5.1, „CRL Fields" oder Derivaten hiervon strukturierte, Statusänderungsnach richt derart versendet, dass zumindest Teile davon zur Bil dung der dritten Daten herangezogen werden.
11. Verfahren nach dem vorhergehenden Anspruch, dadurch ge kennzeichnet, dass an die Authentisierungsermöglichungsein- richtung auf die Statusänderungsnachricht eine zumindest ei nen, insbesondere nach dem RF 6962, Kapitel 3.2, „Structure of the Signed Certificate Timestamp" oder Derivaten hiervon strukturierten, Zeitstempel enthaltende Bestätigungsnachricht versandt wird.
12. Verfahren nach einem der vorhergehenden Ansprüche, da durch gekennzeichnet, dass Abfragen zum Status von Zertifika ten mittels Protokoll, insbesondere dem Online Certificate Status Protocol, „OCSP" oder, insbesondere Positivauskünfte realisierenden, Derivaten hiervon, erfolgt.
13. Verfahren nach dem vorhergehenden Anspruch, dadurch ge kennzeichnet, dass auf die Abfragen Statusantwortnachrichten gemäß dem Protokoll derart gebildet werden, dass zumindest sie eine von einer ausgebenden bis zur einer ursprünglichen Zertifizierungsstelle ergebende gespeicherte Kette von Zerti fizierungsstellen wiedergebende Information und zumindest Teile der dritten Daten enthalten.
14. Verfahren nach einem der vorhergehenden Ansprüche, da durch gekennzeichnet, dass die dritten Daten derart gebildet werden, dass sie zumindest die Erzeugung, den Rückruf, den Ablauf der Gültigkeit oder andere den Status des Zertifikats beschreibende Informationen enthalten.
15. Vorrichtung zur Ermöglichung der Authentisierung von En titäten, insbesondere Personen, Diensten und/oder Objekten, gekennzeichnet durch Mittel zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 14.
16. Computerprogrammprodukt, das direkt in einen Speicher ei nes digitalen Prozessors ladbar ist, umfassend Programmcode teile, die dazu geeignet sind, die Funktionen des Verfahrens nach einem der Ansprüche 1 bis 14 durchzuführen.
PCT/EP2018/077028 2017-11-16 2018-10-04 Verfahren und vorrichtung zur behandlung von authentizitätsbescheinigungen für entitäten, insbesondere von personenbezogenen, dienstbezogenen und/oder objektbezogenen digitalen zertifikaten WO2019096489A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102017220493.1 2017-11-16
DE102017220493.1A DE102017220493A1 (de) 2017-11-16 2017-11-16 Verfahren und Vorrichtung zur Behandlung von Authentizitätsbescheinigungen für Entitäten, insbesondere von personenbezogenen, dienstbezogenen und/oder objektbezogenen digitalen Zertifikaten

Publications (1)

Publication Number Publication Date
WO2019096489A1 true WO2019096489A1 (de) 2019-05-23

Family

ID=63857882

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2018/077028 WO2019096489A1 (de) 2017-11-16 2018-10-04 Verfahren und vorrichtung zur behandlung von authentizitätsbescheinigungen für entitäten, insbesondere von personenbezogenen, dienstbezogenen und/oder objektbezogenen digitalen zertifikaten

Country Status (2)

Country Link
DE (1) DE102017220493A1 (de)
WO (1) WO2019096489A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111917554A (zh) * 2020-07-13 2020-11-10 北京天空卫士网络安全技术有限公司 一种数字证书验证的方法和装置

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU6620000A (en) * 1999-08-06 2001-03-05 Frank W Sudia Blocked tree authorization and status systems

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
FIEDLER ARNO ET AL: "Certificate Transparency", DATENSCHUTZ UND DATENSICHERHEIT - DUD, SP GABLER VERLAG, WIESBADEN, vol. 38, no. 10, 1 October 2014 (2014-10-01), pages 679 - 683, XP035400884, ISSN: 1614-0702, [retrieved on 20141001], DOI: 10.1007/S11623-014-0270-Y *
LAURIE A LANGLEY E KASPER E MESSERI GOOGLE R STRADLING COMODO B: "Certificate Transparency Version 2.0; draft-ietf-trans-rfc6962-bis-24.txt", CERTIFICATE TRANSPARENCY VERSION 2.0; DRAFT-IETF-TRANS-RFC6962-BIS-24.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERLAND, 29 December 2016 (2016-12-29), pages 1 - 54, XP015117192 *
MARK D RYAN: "Enhanced certificate transparency and end-to-end encrypted mail", INTERNATIONAL ASSOCIATION FOR CRYPTOLOGIC RESEARCH,, vol. 20131216:144259, 16 December 2013 (2013-12-16), pages 1 - 14, XP061015228, DOI: 10.14722/NDSS.2014.23379 *
TIFFANY HYUN-JIN KIM ET AL: "Accountable key infrastructure (AKI)", WORLD WIDE WEB, INTERNATIONAL WORLD WIDE WEB CONFERENCES STEERING COMMITTEE, REPUBLIC AND CANTON OF GENEVA SWITZERLAND, 13 May 2013 (2013-05-13), pages 679 - 690, XP058019888, ISBN: 978-1-4503-2035-1, DOI: 10.1145/2488388.2488448 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111917554A (zh) * 2020-07-13 2020-11-10 北京天空卫士网络安全技术有限公司 一种数字证书验证的方法和装置
CN111917554B (zh) * 2020-07-13 2023-06-30 北京天空卫士网络安全技术有限公司 一种数字证书验证的方法和装置

Also Published As

Publication number Publication date
DE102017220493A1 (de) 2019-05-16

Similar Documents

Publication Publication Date Title
EP3488555B1 (de) Gesichertes verarbeiten einer berechtigungsnachweisanfrage
DE60220959T2 (de) Verfahren und Vorrichtung zur Bereitstellung einer Liste von öffentlichen Schlüsseln in einem Public-Key-System
EP3125492B1 (de) Verfahren und system zum erzeugen eines sicheren kommunikationskanals für endgeräte
EP3108610B1 (de) Verfarhen und system zum erstellen und zur gültigkeitsprüfung von gerätezertifikaten
DE60214632T2 (de) Multidomäne Berechtigung und Authentifizierung
DE60102490T2 (de) Infrastruktur für öffentliche Schlüssel
DE60119857T2 (de) Verfahren und Vorrichtung zur Ausführung von gesicherten Transaktionen
DE112011100182T5 (de) Transaktionsprüfung für Datensicherheitsvorrichtungen
WO2019034509A1 (de) Verfahren zum sicheren ersetzen eines bereits in ein gerät eingebrachten ersten herstellerzertifikats
EP3681102B1 (de) Verfahren zur validierung eines digitalen nutzerzertifikats
WO2007045395A1 (de) Vorrichtungen und verfahren zum durchführen von kryptographischen operationen in einem server-client-rechnernetzwerksystem
WO2003013167A1 (de) Vorrichtung zur digitalen signatur eines elektronischen dokuments
EP3743844B1 (de) Blockchain-basiertes identitätssystem
DE602005003631T2 (de) Ausschluss der Passwortaufdeckung bei Attributzertifikatausgabe
WO2019096491A1 (de) Verfahren und vorrichtung zur ermöglichung der authentisierung von erzeugnissen, insbesondere industriell gefertigten geräten, sowie computerprogrammprodukt
WO2019096489A1 (de) Verfahren und vorrichtung zur behandlung von authentizitätsbescheinigungen für entitäten, insbesondere von personenbezogenen, dienstbezogenen und/oder objektbezogenen digitalen zertifikaten
EP1921556A1 (de) Signaturerweiterung
EP3906653B1 (de) Verfahren zum ausstellen einer kryptographisch geschützten authentizitätsbescheinigung für einen benutzer
EP3713189A1 (de) Intrusionserkennung bei computersystemen
EP3881486B1 (de) Verfahren zur bereitstellung eines herkunftsortnachweises für ein digitales schlüsselpaar
DE102010021655A1 (de) Verfahren zum Bereitstellen von EDRM (Enterprise Digital Rights Management) geschützten Datenobjekten
DE102005061999A1 (de) Verfahren zum sicheren, elektronischen Übertragen von Daten von einer ersten Datenverarbeitungseinrichtung an eine zweite Datenverarbeitungseinrichtung
EP1847091A1 (de) Verfahren und vorrichtung zur kontrolle von netzelementen in einem dezentralen netzwerk
WO2023169926A1 (de) Nachvollziehbares anfordern eines zertifikats durch eine registrierungsstelle
DE10112166A1 (de) Verfahren zum Transaktionsnachweis

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: 18786245

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18786245

Country of ref document: EP

Kind code of ref document: A1