AT519025A4 - Verfahren zum Austausch von Datenfeldern von zertifizierten Dokumenten - Google Patents

Verfahren zum Austausch von Datenfeldern von zertifizierten Dokumenten Download PDF

Info

Publication number
AT519025A4
AT519025A4 ATA51019/2016A AT510192016A AT519025A4 AT 519025 A4 AT519025 A4 AT 519025A4 AT 510192016 A AT510192016 A AT 510192016A AT 519025 A4 AT519025 A4 AT 519025A4
Authority
AT
Austria
Prior art keywords
document
service
data fields
client
doc
Prior art date
Application number
ATA51019/2016A
Other languages
English (en)
Other versions
AT519025B1 (de
Inventor
Krenn Stephan
Loruenser Thomas
Striecks Christoph
Original Assignee
Ait Austrian Inst Tech 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 Ait Austrian Inst Tech Gmbh filed Critical Ait Austrian Inst Tech Gmbh
Priority to ATA51019/2016A priority Critical patent/AT519025B1/de
Priority to PCT/AT2017/060293 priority patent/WO2018085870A1/de
Application granted granted Critical
Publication of AT519025B1 publication Critical patent/AT519025B1/de
Publication of AT519025A4 publication Critical patent/AT519025A4/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
    • 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • 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/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • 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/006—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols involving public key infrastructure [PKI] trust models
    • 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/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • 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/321—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 a third party or a trusted authority
    • 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/3218—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 proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/02—Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]
    • 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/76—Proxy, i.e. using intermediary entity to perform cryptographic operations
    • 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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281—Proxies
    • 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/2876—Pairs of inter-processing entities at each side of the network, e.g. split proxies

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Storage Device Security (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum Austausch von Datenfeldern von zertifizierten Dokumenten zwischen einem Client (U) und einem Service (S) über einen Authentisierungsserver (A), - wobei der Client (U) über ein Dokument (Dok) verfügt, das eine Anzahl von verschlüsselten Datenfeldern (c1, ..., cn) sowie eine Signatur (σ) umfasst, - wobei das Dokument (Dok) vom Client (U) an den Authentisierungsserver (A) übertragen wird, - wobei der Client (U) dem Authentisierungsserver (A) eine Modifikationsvorschrift (m) mitteilt, die angibt welche der Datenfelder (c1, ..., cn) des Dokuments (Dok) vom Authentisierungsserver (A) an das Service (S) nicht übertragen werden dürfen, - der Authentisierungsserver (A) ein modifiziertes Dokument (Dok') erstellt, bei dem die vorgegebenen Datenfelder (c1, ..., cn) oder die Signatur (σ) modifiziert sind, - dass dem modifizierten Dokument (Dok') ein Zertifikat (z) angefügt wird, - dass das modifizierte Dokument (Dok') einschließlich des Zertifikats (z) vom Authentisierungsserver (A) an das Service (S) übertragen wird, - dass das Service (S) das modifizierte Dokument (Dok') anhand des Zertifikats (z) dahingehend überprüft, ob die Datenfelder (c1', ..., cn') des modifizierten Dokuments (Dok') auf Grundlage eines Dokuments (Dok) mit gültiger Signatur (σ) erstellt wurden und die in Schritt e) genannte Modifikation der Modifikationsvorschrift (m) entspricht, i) dass das Service (S) über Schlüsselmaterial verfügt, das es dem Service (S) ermöglicht, die Datenfelder (c1', ..., cn') zu entschlüsseln.

Description

Die Erfindung betrifft ein Verfahren zum selektiven Austausch von einzelnen Datenfeldern von zertifizierten Dokumenten zwischen einem Client und einem Service über einen Authentisierungsserver bei gleichzeitiger Wahrung der Authentizität der Daten in einer Cloud-Umgebung.
Aus dem Stand der Technik sind unterschiedliche Vorgehensweisen bekannt, mit denen es möglich ist, einzelne Zugriffsberechtigungen bei unterschiedlichen Services im Internet an unterschiedlichen Stellen nachzuweisen.
Aus dem Stand der Technik ist es insbesondere bekannt, einzelne Passwörter oder Zugriffsinformationen, die ein Benutzer für den Zugriff auf ein Service benötigt, auf einem lokalen Datenträger abzuspeichern. Soll derselbe Benutzer von einem Client-Rechner aus mit dem Service in Kontakt treten, so können die derart auf dem Datenträger abgespeicherten Dokumente bzw. die in den Datenfeldern der Dokumente enthaltenen Informationen wie z.B. Freischaltcodes vom Datenträger über den jeweiligen Client-Rechner zum Service übermittelt werden. In diesem Fall besteht jedoch das Problem, dass sämtliche Daten auf jedem aktuell benutzten Client-Rechner im Klartext zur Verfügung stehen, was wiederum den Nachteil mit sich bringt, dass bei der Benutzung eines unsicheren Client-Rechners die Gefahr besteht, dass die Dokumente von unberechtigten Dritten ausgelesen werden können.
Zudem ist es bekannt, Informationen, die den Zugriff auf einzelne Services ermöglichen, auf einem im Internet befindlichen Authentisierungsserver abzuspeichern, wobei die einzelnen Datenfelder der Dokumente, die normalerweise zwischen Client und Service ausgetauscht werden, im Klartext auf dem Authentisierungsserver abgespeichert sind. Mit dieser Vorgehensweise ist es möglich, die Dokumente von unterschiedlichen Clients aus zu nutzen, wobei der betreffende Client keine Kenntnis über die Dokumente zu haben braucht, da diese vom Authentisierungsserver an das betreffende Service übermittelt werden. Dies hat jedoch den erheblichen Nachteil, dass der Authentisierungsserver sämtliche Datenfelder der Dokumente des Benutzers im Klartext erhält.
Die im Stand der Technik genannten Vorgehensweisen haben insbesondere das Problem, dass ein Client-Rechner oder der Authentisierungsserver über sensible Daten im Klartext verfügt und daher eine Vielzahl von personenenbezogenen Informationen über den Benutzer erhalten kann.
Aufgabe der Erfindung ist es, ein Verfahren zum selektiven Austausch von Datenfeldern von zertifizierten Dokumenten zwischen einem Client und einem Service über einen Authentisierungsserver zur Verfügung zu stellen, bei dem der Authentisierungsserver keinen nennenswerten Informationsgewinn über die zwischen dem Client und dem Service ausgetauschten Datenfelder erhält.
Die Erfindung löst diese Aufgabe bei einem Verfahren der eingangs genannten Art mit den Merkmalen des Patentanspruchs 1.
Mit diesem Verfahren ist es vorteilhaft möglich, sämtliche Zugriffsinformationen, die ein Benutzer für verschiedene im Internet befindliche Services benötigt, um auf einen Authentisierungsserver abzuspeichern, der seinerseits keine Kenntnis über die betreffenden Zugriffsinformationen erhält. Darüber hinaus werden auch dem konkret verwendeten Client keine Informationen über die ausgetauschten Datenfelder übermittelt.
Ein vorteilhaftes Vorgehen, um zu vermeiden, dass Klartext-Daten dem
Authentisierungsserver bekannt werden, sieht vor, - dass der Client und das Service über private und öffentliche Schlüssel verfügen, - dass auf Grundlage eines privaten und/oder öffentlichen Schlüssels des Service sowie auf Grundlage des privaten Schlüssels des Clients ein Reencryption-Schlüssel erstellt und dem Authentisierungsserver zur Verfügung gestellt wird, - wobei mit dem Reencryption-Schlüssel Datenfelder des Dokuments, die mit dem öffentlichen Schlüssel des Clients verschlüsselt wurden, derart umverschlüsselt werden, dass sie mit dem privaten Schlüssel des Service entschlüsselbar sind, - dass vor der Erstellung des Zertifikats in Schritt f) die einzelnen in der Übereinkunft zwischen dem Client und dem Service vereinbarten Datenfelder des modifizierten Dokuments mittels des Reencryption-Schlüssels umverschlüsselt werden, - dass im Zertifikat zusätzlich Informationen enthalten sind, die angeben, dass die Umverschlüsselung mit dem auf Basis der vom Client und Service angegebenen Schlüssel erstellten Reencryption-Schlüssel korrekt durchgeführt wurde, und - dass in Schritt j) der private Schlüssel des Service zur Entschlüsselung verwendet wird.
Um eine Rückverfolgbarkeit bzw. Linkbarkeit des Clients anhand der übermittelten verschlüsselten Datenfelder zu vermeiden, kann vorgesehen sein, - dass vor dem Umverschlüsseln eine Rerandomisierung des Dokuments vorgenommen wird, bei der die in der Übereinkunft vereinbarten verschlüsselten Datenfelder modifiziert werden, die in den verschlüsselten Datenfeldern enthaltene Informationen jedoch unverändert bleiben, und - dass im Zertifikat zusätzlich Informationen enthalten sind, die angeben, dass die Rerandomisierung korrekt durchgeführt wurde.
Ein alternatives Vorgehen zur Vermeidung der Preisgabe von Klartext-Daten an den Authentisierungsserver sieht vor, - dass der Client über einen privaten und einen öffentlichen Schlüssel verfügt, - dass der Client aus dem privaten Schlüssel einen abgeleiteten privaten Schlüssel erstellt, - dass die in der Übereinkunft vereinbarten Datenfelder des Dokuments derart verschlüsselt werden, dass sie mit dem abgeleiteten privaten Schlüssel entschlüsselbar sind, - dass der abgeleitete private Schlüssel an das Service übertragen wird, - dass in Schritt e) zumindest die Signatur des Dokuments modifiziert wird, und - dass der abgeleitete private Schlüssel zur Entschlüsselung der Datenfelder des modifizierten Dokuments herangezogen wird.
Um eine Rückverfolgbarkeit bzw. Linkbarkeit des Clients anhand der übermittelten verschlüsselten Datenfelder zu vermeiden, kann vorgesehen sein, - dass im Zuge der Modifikation eine Rerandomisierung vorgenommen wird, bei der die in der Übereinkunft vereinbarten verschlüsselten Datenfelder modifiziert werden, die in den verschlüsselten Datenfeldern enthaltene Informationen jedoch unverändert bleiben, und - dass im Zertifikat zusätzlich Informationen enthalten sind, die angeben, dass die Rerandomisierung korrekt durchgeführt wurde.
Zur Erstellung eines Dokuments kann insbesondere vorgesehen sein, - dass der Client über einen privaten und einen öffentlichen Schlüssel verfügt, - dass das Dokument erstellt wird, indem eine Anzahl von Klartext-Datenfeldern mit dem öffentlichen Schlüssel des Clients verschlüsselt werden, - dass eine Zertifizierungsstelle eine Signatur erstellt, die von den verschlüsselten Datenfeldern und von ihrem eigenen privaten Schlüssel abhängig ist, und - dass in Schritt h) der öffentlichen Schlüssel der Zertifizierungsstelle verwendet wird, um die Gültigkeit des Zertifikats zu prüfen.
Um zu ermöglichen, dass die Zertifizierungsstelle vor der Vergabe der Signatur einzelne Datenfelder prüft, kann vorgesehen sein, dass die Zertifizierungsstelle vor der Erstellung der Signatur für eine Anzahl der verschlüsselten Datenfelder des Dokuments überprüft, ob sich diese durch Verschlüsselung aus vorgegebenen oder zwischen dem Client und Zertifizierungsstelle vereinbarten Klartext-Datenfeldern ergeben.
Der Zugriff auf das betreffende Service sieht insbesondere vor, - dass der Client an das Service nach Schritt d) eine Zugriffsanfrage stellt, - dass das Service dem Authentisierungsserver zur Übermittlung des modifizierten Dokuments auffordert und das modifizierte Dokument entsprechend der Schritte, in dem Schritt h), überprüft, und - dass das Service die erforderliche Berechtigung des Clients anhand der entschlüsselten Datenfelder, des Zertifikats und des modifizierten Dokuments prüft und gegebenenfalls dem Client den Zugriff entsprechend der Zugriffsanfrage gewährt.
Weiters löst die Erfindung diese Aufgabe bei einem System der eingangs genannten Art mit den Merkmalen des Patentanspruchs 9.
Mehrere Ausführungsformen der Erfindung werden nunmehr im Detail dargestellt:
Fig. 1 zeigt schematisch das Vorgehen bei einer ersten Ausführungsform der Erfindung. Bei dieser Ausführungsform sind ein Client U, ein Service S und ein Authentisierungsserver A über ein Computernetzwerk, insbesondere über das Internet, miteinander verbunden, wobei zwischen jedem der vorstehend genannten Rechner U, S, A jeweils eine separate logische Verbindung erstellt werden kann.
Typischenweise wird das erfindungsgemäße Vorgehen verwendet, um vom Client U an das Service S eine Zugriffsanfrage zu stellen, wobei dem Benutzer auf dem von ihm momentan verwendeten Client U nicht notwendigerweise sämtliche für die Authentisierung beim Service S erforderlichen Informationen zur Verfügung stehen. Diese Informationen sind in Form eines Dokuments auf dem Authentisierungsserver A gespeichert. Will ein Client U Zugriff auf das Service S erhalten, so fordert das Service S seinerseits den Authentisierungsserver A zur Übermittlung der für die Authentisierung erforderlichen Daten auf und überprüft anschließend die erforderliche Berechtigung des Clients U anhand der vom Authentisierungsserver A übermittelten Daten. Sofern die vom Authentisierungsserver A an das Service S zur Authentisierung übermittelten Daten einen Zugriff erlauben bzw. den Client zum Zugriff auf das Service berechtigen, ermöglicht das Service S dem Client U den Zugriff entsprechend der Zugriffsanfrage.
Zur Authentisierung wird ein Dokument Dok erstellt, das eine Anzahl von verschlüsselten Datenfeldern Ci,cn aufweist, wobei die verschlüsselten Datenfelder Ci,..., cn nach ihrer Entschlüsselung dem Service die Freigabe der vom Client angefragten Daten erlauben. Die Verschlüsselung der betreffenden Datenfelder Ci, ..., cn des Dokumentes Dok kann entweder vom betreffenden Client U oder von einer Zertifizierungsstelle CA vorgenommen werden. Anschließend wird von der Zertifizierungsstelle CA oder vom Client U eine Signatur σ erstellt und dem Dokument Dok hinzugefügt. Mit dieser Signatur σ lässt sich nachträglich überprüfen, ob die Zertifizierungsstelle CA die verschlüsselten Datenfelder Ci, ..., cn des Dokuments Dok tatsächlich zertifiziert bzw. signiert hat und ob sich diese Signatur σ aus den verschlüsselten Datenfeldern c^ ..., cndes Dokuments Dok ergibt. Die Zertifizierungsstelle CA überprüft vor der Erstellung der Signatur, ob sich die Signatur tatsächlich durch Verschlüsselung aus den vorgegebenen oder zwischen dem Client und der Zertifizierungsstelle vereinbarten Klartext-Datenfeldern a^ ..., an ergeben.
Soll also beispielsweise von der Zertifizierungsstele CA in Form einer Behörde, die zur Ausstellung eines Personalausweises berechtigt ist, ein digitales Dokument Dok mit den Datenfeldern "Vorname", "Nachname", "Geburtsdatum" erstellt werden, dann kann in einer besonders einfachen Ausführungsform der Erfindung das betreffende Dokument Dok unmittelbar von der Zertifizierungsstelle CA erstellt werden. Dabei verschlüsselt die Zertifizierungsstelle CA die einzelnen Klartext-Datenfelder ai, ..., andes Dokuments Dok mit einem eigenen vorgegebenen Schlüssel und erstellt basierend auf den verschlüsselten Datenfeldern Ci, ..., cneine Signatur s. Bei der Erstellung dieser Signatur wird vorteilhaftenweise ein privater Schlüssel skCA der Zertifizierungsstelle CA verwendet, wobei zur externen Überprüfung der Gültigkeit der Signatur von der Zertifizierungsstelle CA ein öffentlicher Schlüssel pkCA allgemein bekannt gegeben wird.
Darüber hinaus besteht auch die Möglichkeit, dass die Verschlüsselung der einzelnen Datenfelder c^ ..., cn des Dokuments Dok vom Benutzer bzw. vom Client U selbst vorgenommen wird, wobei der Zertifizierungsstelle CA die Möglichkeit gegeben wird, nachzuprüfen, ob sich die verschlüsselten Datenfelder c^ ..., cndes Dokuments Dok durch Verschlüsselung aus den zwischen dem Client U und der Zertifizierungsstelle CA vereinbarten Klartext-Datenfeldern a^ ..., an ergeben. So kann beispielsweise der Client von einer Zertifizierungsstelle CA, die zur Ausgabe von Personalausweisen berechtigt ist, seine persönlichen Daten "Vorname", "Nachname", "Geburtsdatum" in einer von ihm vorgegebenen Weise verschlüsseln und der Zertifizierungsstelle CA nachweisen, dass sich die verschlüsselten Datenfelder C!,..., cndes Dokuments Dok durch Verschlüsselung der von der Zertifizierungsstelle CA zu bestätigenden Klartext-Datenfeldern a^ an ergeben. Die Zertifizierungsstelle CA prüft dies nach und versieht das Dokument Dok mit einer entsprechenden Signatur σ.
Besonders vorteilhaft kann das Dokument erstellt werden, wenn der Client U, wie in diesem Ausführungsbeispiel angegeben, über einen privaten und einen öffentlichen Schlüssel sku, pku verfügt. Das Dokument Dok wird erstellt, indem der Client U oder die Zertifizierungsstelle CA eine Anzahl von Klartext-Datenfeldern mit dem öffentlichen Schlüssel des Clients U verschlüsselt. Die Zertifizierungsstelle CA erzeugt eine Signatur σ, die von den verschlüsselten Datenfeldern und von ihren eigenen privaten Signaturschlüssel sku abhängig ist.
Die einzelnen Klartext-Datenfelder a^ ..., an werden jeweils von einander unabhängig verschlüsselt, wobei durchaus die Möglichkeit besteht, dass einzelne der resultierenden verschlüsselten Datenfelder c^ ..., cn nach unterschiedlichen Verschlüsselungsmethoden und/oder mit unterschiedlichen Schlüsseln verschlüsselt und im Dokument Dok enthalten sind. Die von der Zertifizierungsstelle CA ausgegebene Signatur σ beruht auf den verschlüsselten Datenfelder c^ ..., cn des Dokuments Dok und ermöglicht eine externe Prüfung, dahingehend ob einerseits die Signatur σ tatsächlich von der Zertifizierungsstelle CA stammt und andererseits dahingehend, dass die Verschlüsselung der einzelnen Datenfelder Ci,..., cndes Dokuments Dok korrekt abgelaufen ist.
In einer bevorzugten Ausführungsform der Erfindung besteht auch die Möglichkeit, dass die Zertifizierungsstelle CA mit dem Service S übereinstimmt oder mit dessen kooperiert. Dies kann beispielsweise dann von Vorteil sein, wenn ein bestimmtes Service Einmalcodes zur Verfügung stellt, mit denen bestimmte Leistungen einmal abgerufen werden können, insbesondere betrifft dies den Fall des einmaligen Abrufs eines Films über ein Portal.
Zu diesem Zweck kann der Client U nach seinem Belieben ein Dokument Dok erstellen, das ein verschlüsseltes Datenfeld C! enthält, das zufällig erstellt wurde und dessen Datenfeldgröße so groß ist, dass ausgeschlossen werden kann, dass ein Datenfeld C! des selben Inhalts zufällig zweifach oder mehrfach erstellt wird. Typischerweise kann dafür eine Datenfeldgröße von 16 bis 32 Bytes gewählt werden. Der Client U übermittelt der Zertifizierungsstelle CA, die unter Kontrolle des Service S steht, ein Dokument Dok mit einem verschlüsselten Datenfeld c^ dessen Inhalt von ihm festgelegt wurde. Die Zertifizierungsstelle CA bestätigt, beispielsweise nach Bezahlung, die Korrektheit bzw.
Validität des vom Client U erstellten Dokuments Dok bzw. des darin befindlichen verschlüsselten Datenfelds Ci im Hinblick auf die Verwendbarkeit zum einmaligen Ansehen eines Films beim betreffenden Service S.
Wie in Fig. 1 dargestellt, verfügt der Client U nach der Erstellung durch die Zertifizierungsstelle CA über ein oder mehrere Dokumente Dok. Das oder jedes Dokument Dok verfügt über eine Anzahl von verschlüsselten Datenfeldern Ci, cn sowie eine Signatur, die von den verschlüsselten Datenfeldern Ci, ..., cn abhängig ist. Die Signatur σ kann bei Kenntnis der betreffenden Zertifizierungsstelle CA dahingehend überprüft werden, ob die verschlüsselten Datenfelder Ci, ..., cn tatsächlich von der Zertifizierungsstelle CA stammen bzw. herrühren.
Um das oder die Dokumente Dok für eine Vielzahl unterschiedlicher Services S zur Verfügung zu halten, werden diese vom Client U auf dem Authentisierungsserver A übertragen. Der Authentisierungsserver A ermöglicht eine Konfiguration dahingehend, dass dieser einzelnen Services S die Abfrage unterschiedlicher Datenfelder ..., cn eines bei ihm abgelegten Dokuments Dok ermöglicht. Dabei wird eine Modifikationsvorschrift m angegeben, die dem Authentisierungsserver A vorschreibt, welche der verschlüsselten Datenfelder Ci,..., cndes Dokuments Dok vom Authentisierungsserver A an das Service S nicht übertragen werden dürfen. Der Client U und das Service S treffen eine Übereinkunft, in der festgelegt wird, welche für das Service lesbaren Datenfelder Ci, ..., cn in einem an das Service zu übermittelten Dokument Dok' enthalten sein sollen. So kann beispielsweise der Client U dem Authentisierungsserver A ein Dokument Dok hinterlegen, in dem als Datenfelder Ci, ..., cn sowohl sein Name (Vorname und Nachname) sowie sein Geburtsdatum abgespeichert sind. Weiters trifft der Client U mit dem Service S eine Übereinkunft dahingehend, dass dem Service S lediglich gegenüber nachzuweisen ist, dass der Benutzer ein bestimmtes Alter erreicht hat, sodass dem Service S lediglich das im Dokument Dok enthaltene das Geburtsdatum repräsentierende verschlüsselte Datenfeld c3 mitteilt. Die Modifikationsvorschrift m, die der Client U dem Authentisierungsserver A übermittelt, gibt an, dass das Geburtsdatum betreffende Datenfeld d3 des Dokuments Dok vom Authentisierungsserver A an das Service S übertragen werden darf während die den Vornamen und Nachnamen betreffenden Datenfelder c1; c2 des Dokuments Dok vom Authentisierungsserver A nicht an das Service S übertragen werden dürfen.
Bei dem im folgenden dargestellten ersten Ausführungsbeispiel der Erfindung verfügen der Client U und das Service S über private und öffentliche Schlüssel sky, sks bzw. pky, pks sowie den öffentlichen Schlüssel der Zertifizierungsstelle pkCA· Auf Grundlage eines privaten und/oder öffentlichen Schlüssels des Service sowie auf Grundlage des privaten Schlüssels des Clients wird ein Reencryption-Schlüssel rku^s erstellt und dem Authentisierungsserver A übergeben. Mit diesem Reencryption-Schlüssel rku^s können Datenfelder Ci, cn des Dokuments Dok, die mit dem öffentlichen Schlüssel pku des Clients U verschlüsselt vorliegen, derart umverschlüsselt werden, dass sie mit dem privaten Schlüssel sks des Service S entschlüsselbar sind. Ein derartiges Vorgehen kann beispielsweise im Zusammenhang mit einer EIGamal-artigen Verschlüsselung vorgenommen werden, siehe insbesondere M. Blaze, G. Bleumer, and M. Strauss. „Divertible protocols and atomic proxy cryptography“. In K. Nyberg (ed.), EUROCRYPT 1998, LNCS vol 1403, pp. 127-144, Springer Verlag, 1998.
Im Rahmen der Erstellung des modifizierten Dokuments Dok', bei dem die einzelnen Datenfelder des Dokuments Dok umverschlüsselt werden, erhält man modifizierte Datenfelder Ci', ..., cn', die dem modifizierten Dokument Dok' zugewiesen werden. Diejenigen Datenfelder c1; c2, die aufgrund der Modifikationsvorschrift m nicht an das Service S übertragen werden dürfen, werden gelöscht oder mit Zufallszahlen überschrieben.
Vor dem Umverschlüsseln kann eine Rerandomisierung des Dokuments vorgenommen werden, bei der die in der Übereinkunft zwischen dem Client und dem Service vereinbarten verschlüsselten Datenfelder modifiziert werden, die in den verschlüsselten Datenfeldern enthaltene Information bzw. die in den verschlüsselten Datenfeldern enthaltenden Klartexte unverändert bleiben.
Dem modifizierten Dokument Dok' wird weiters ein Zertifikat z angefügt, mit dem für das Service S nachvollziehbar ist, dass die Datenfelder Ci', ..., cn' des modifizierten Dokuments Dok' auf Grundlage eines Dokuments Dok mit gültiger Signatur σ erstellt wurden und die vorgenommene Modifikation des Dokuments Dok umfassend die Schritte Umverschlüsseln der Datenfelder c1; ..., cn sowie Löschen oder Überschreiben der nicht zu übermittelnden Datenfelder c1; c2 entspricht. Im Zertifikat z sind zusätzlich Informationen enthalten, die angeben, dass die Umverschlüsselung mit dem auf der Basis vom Client U und Service S angegebenen Schlüssel erstellten Reencryption-Schlüssel rku^s korrekt durchgeführt wurde.
Sofern vor der Umverschlüsselung eine Rerandomisierung vorgenommen wird, wird dem Zertifikat z neben der Korrektheit der Umverschlüsselung noch Informationen hinzugefügt, mit denen nachvollzogen werden kann, dass die Rerandomisierung korrekt durchgeführt wurde.
Auch wenn es das Zertifikat z ermöglicht, die Korrektheit der vorgenommenen Schritte zu prüfen, erlangt das Service S als Empfänger des Zertifikats z keine Kenntnisse über die einzelnen dem Zertifikat z zugrunde liegenden Klartext-Datenfelder oder die bei der Verschlüsselung verwendeten Schlüssel oder Reencryption-Schlüssel. Aufgrund des Zertifikats z lässt sich für das Service S ohne Kenntnis der betreffenden nicht öffentlichen Schlüssel nachweisen, dass im Rahmen der Erstellung und Modifikation des Dokuments sämtliche Modifikationsvorschriften eingehalten wurden. Dass ein solcher Nachweis möglich ist, ist aus O. Goldreich, S. Micali, A. Widgerson. „How to Prove all NP-Statements in Zero-Knowledge, and a Methodology of Cryptographic Protocol Design“. In A. Odlyzko (ed.), CRYPTO 1986, LNCS vol 263, pp. 171-185, Springer Verlag, 1986 theoretisch bekannt. Praktikable konkrete Protokolle sind ein Standard-Bausteil moderner kryptographischer Protokolle und basieren sehr oft auf C.-P. Schnorr. „Efficient Signature Generation by Smart Cards“. In Journal of Cryptology, vol. 4(3), pp. 161-174, Springer Verlag, 1991. Eine detailierte Anleitung zur Realisierung solcher Protokolle findet sich, z.B., in S. Krenn: “Bringing zero-knowledge proofs of knowledge to practice”. Logos Verlag, 2012, ISBN 978-3-8325-3217-8, and in U. Maurer. “Unifying Zero-Knowledge Proofs of Knowledge”, In B. Preneel (ed.), AFRICACRYPT 2009, LNCS vol 5580, pp. 272-286, Springer Verlag, 2009. Insbesondere ist es mit derartigen Methoden möglich, die Korrektheit der Ausführung mehrerer hintereinander folgender Schritte zu prüfen, ohne dass es erforderlich ist, dass das prüfende Service S Kenntnis über alle erfolgten Zwischenschritte hat. Diese einzelnen Schritte sind beispielsweise: - die Gültigkeit des Vorgehens bei der Erstellung der Signatur des Dokuments, - die Umverschlüsselung durch den Authentisierungsserver, - das Überschreiben der nicht weiterzuleitenden verschlüsselten Datenfelder, - die Rerandomisierung der weiterzuleidenden verschlüsselten Datenfelder,
Will das Service S, beispielsweise auf Anfrage des Clients U, überprüfen, ob bestimmte Datenfelder c3 vorgegebenen Kriterien entsprechen, so stellt es beim Authentisierungsserver A eine Anfrage auf Übermittlung des modifizierten Dokuments Dok'. Daraufhin übermittelt der Authentisierungsserver A das modifizierte Dokument Dok' einschließlich des Zertifikats z an das Service S. Das Service S prüft das modifizierte Dokument Dok' anhand des Zertifikats z dahingehend, ob die Datenfelder Ci', ..., cn' des modifizierten Dokuments Dok' auf Grundlage eines Dokuments Dok mit gültiger Signatur σ erstellt wurden und die vorstehend genannte Modifikation der Modifikationsvorschrift m entspricht, d.h. ob die Umverschlüsselung und gegebenenfalls Rerandomisierung korrekt vorgenommen wurde.
Bei der Prüfung der Gültigkeit des Zertifikats wird der öffentliche Schlüssel pku der Zertifizierungsstelle CA verwendet, um die Gültigkeit des Zertifikats z zu prüfen.
Im Folgenden wird eine semi-abstrakte Beschreibung des Signatur- und des Authentisierungs-Prozesses gegeben. Der Konkretheit halber wird das zugrundeliegende Proxy-Re-Encryption-Verfahren auf das von Blaze et al. (siehe oben) festgelegt, das von der Zertifizierungsstelle CA verwendete Signaturverfahren jedoch frei wählbar gelassen.
In diesem Fall beschreibt das folgende Protokoll den Signatur-Vorgang:
Dabei hat der Benutzer U als Eingabe-Werte etwaige System parameter sp, die Klartext-Datenfelder a,, den Bereich zulässiger Werte für die Datenfelder AS, die Indizes der Zertifizierungsstelle CA offengelegten Werte D, den öffentlichen Schlüssel der CA pkCA, sowie den eigenen öffentlichen und privaten Schlüssel pku, sku. Die CA hat die angegebenen Eingabewerte, wobei pkCA, skCA, abweichend vom Benutzer U die eigenen privaten und öffentlichen Schlüssel bezeichnen. Die Klartext-Datenfelder a, werden in Zeile 3-4 verschlüsselt zu c, und in Zeile 5 an die CA übertragen. In Zeile 6 beweist der Benutzer mit Hilfe eines Zero-Knowledge-Beweises, dass etwaige offengelegte Datenfelder den vereinbarten Werten entsprechen, konkret würden die zu beweisenden Werte durch e, (n) , e D belegt werden. In Zeile 7 signiert die CA die verschlüsselten Datenfelder mittels des Signier-Algorithmus Sign des gewählten Signaturverfahrens, und retourniert die Signatur in Zeile 8 an den Benutzer, welcher die entsprechenden Werte ausgibt und an den Authentisierungsserver A übertragt.
Um nun eine Authentisierung des Benutzers durchzuführen, führen der Authentisierungsserver A und der Service S die folgenden Schritte aus:
Der Authentisierungsserver A erhält die angegeben Eingabewert, ähnlich wie im Falle des obigen Protokolls. Weiters erhält er einen Reencryption-Schlüssel rky^s, welcher es erlaubt, Schlüsseltexte vom öffentlichen Schlüssel des Benutzers auf jenen des Service umzuverschlüsseln, wobei der öffentliche und private Schlüssel des Services durch pks und sks bezeichnet werden. Der Service erhält die entsprechenden angegebenen Eingabe-Werte.
In den Schritten 1-2 rerandomisiert der Authentisierungsserver A die Schlüsseltexte des Benutzers. In 3-4 werden die dem Service S nicht offen gelegten Datenfelder durch Zufallswerte ersetzt. Die tatsächliche Umverschlüsselung erfolgt in Schritt 5 und die Resultate werden an S übertragen. In Schritt 7 beweist A nun mittels Zero-Knowledge-Beweis, dass die Rerandomiserung und die Umverschlüsselung korrekt durchgeführt wurden sowie die nicht offengelegten Datenfelder korrekt geschwärzt wurden, dass ausschließlich korrektes Schlüsselmaterial verwendet wurde und dass auf die ursprünglichen verschlüsselten Datenfelder von CA eine Signatur bekannt ist, welche die Signatur-Verifikationsprüfung Ver des gewählten Signaturverfahrens besteht (die zu beweisenden Werte würden konkret wie folgt belegt werden: (σ, (f,) , eD, (v,, w,), $ D, rku^s, e). Die Gesamtheit der in Schritt 7 gesendeten Werte bildet das Zertifikat z. Im Fall, dass dieses Zertifikat korrekt ist, entschlüsselt der Service S in Schritt 8 die entsprechenden Schlüsseltexte unter Verwendung seines eigenen geheimen Schlüssels sks mittels des Entschlüsselungsalgorithmus Dec des Blaze et al.-Verschlüsselungsverfahrens, und erhält die Klartext-Datenfelder.
Eine konkrete Instanziierung des Signaturverfahrens mit dem Verfahren von Abe et al. (M. Abe and J. Groth and K. Haralambiev and M. Ohkubo. „Optimal Structure-Preserving Signatures in Asymmetrie Bilinear Groups“. In P. Rogaway (ed.), CRYPTO 2011, LNCS vol 6841, pp. 649-666, Springer Verlag, 2011.) liefert das folgende konkrete Signatur-Protokoll:
Der öffentliche Schlüssel der Zertifizierungsstelle pkCA besteht in diesem konkreten Fall aus G,H,W1,...,W2n+2! wobei das algebraische Setting in der Originalpublikation beschrieben ist. Der private Schlüssel der Zertifizierungsstelle (CA) skCA besteht aus r,v,Wi,...,w2n+2· Die Schritte 7-11 beschreiben nun den präzisen Signaturvorgang.
Bei der Durchführung einer Authentisierung wird das folgende Protokoll durchgeführt:
Die Schritte 6-13 sowie Teile der in Schritt 14 gesendeten Werte dienen zur Vorberechnung für den in Schritt 15 durchgeführten Zero-Knowledge-Beweisschritt zur Erstellung des Zertifikats z, dessen konkrete Implementierung direkt mittels der referenziellen Literatur realisiert werden kann. Die zu beweisenden Werte würden konkret wie folgt belegt werden: ((i?, 6’, x)t {fiJii, rliu ->s/i - bi ~ bfi)i±Di {Vi, rku^sc, 6, b' ~ 6e\rku...s.s> e).
Nachdem sichergestellt ist, dass das betreffende modifizierte Dokument Dok' aufgrund einer korrekten Behandlung bzw. Modifikation entsprechend der Modifikationsvorschrift m an das Service S gelangt ist, kann das Service die einzelnen ihm zur Verfügung gestellten Datenfelder d3 entschlüsseln. Dazu verfügt das Service S über entsprechendes Schlüsselmaterial, das es ihm ermöglicht, die in der Übereinkunft angegebenen Datenfelder d3 des modifizierten Dokuments Dok' zu entschlüsseln. Aufgrund der zuvor bereits vorgenommenen Umverschlüsselung ist es im vorliegenden Ausführungsbeispiel der Erfindung ausreichend, wenn das Service über seinen eigenen privaten Schlüssel sks verfügt, mit dem es ihm möglich ist, die im modifizierten Dokument Dok' enthaltenen Datenfelder d3 zu entschlüsseln. Das Service entschlüsselt die betreffenden Datenfelder d3 des modifizierten Dokuments Dok' und erstellt auf diese Weise entschlüsselte
Datenfelder a3* die für die weitere Verarbeitung zur Verfügung gehalten werden. Insbesondere wird im vorliegenden Ausführungsbeispiel lediglich überprüft, ob das im betreffenden Dokument enthaltene Geburtsdatum mehr als 18 Jahre vor der aktuellen Zeit ist, d.h. ob der betreffende Benutzer älter als 18 Jahre ist und damit berechtigt ist, die betreffende Dienstleistung des Service S zu erhalten.
Im Folgenden wird eine zweite bevorzugte Ausführungsform der Erfindung näher dargestellt (Fig. 2), die keine Umverschlüsselung der Datenfelder c1; ..., cn des Dokuments Dok vornimmt, sondern abgeleitete private Schlüssel sku‘ des Clients verwendet. Die Erstellung des Dokuments Dok zwischen der Zertifizierungsstelle CA und dem Client U erfolgen wie beim ersten Ausführungsbeispiel der Erfindung. Der Client U verfügt über einen privaten Schlüssel sky und einen öffentlichen Schlüssel pky. Der Client U erstellt aus dem privaten Schlüssel sky einen abgeleiteten privaten Schlüssel sky‘, wobei die in der Übereinkunft vereinbarten Datenfelder Ci, ..., cn des Dokuments Dok derart verschlüsselt werden, dass sie nicht nur mit dem privaten Schlüssel sky sondern auch mit dem abgeleiteten privaten Schlüssel sky' entschlüsselbar sind. Alle anderen Datenfelder des Dokuments Dok können hingegen nicht mit dem abgeleiteten privaten Schlüssel sky“ entschlüsselt werden. Der abgeleitete private Schlüssel sky“ wird an das Service S übertragen. Der Authentisierungsserver A erstellt auf Anfrage des Service basierend auf dem Dokument Dok ein modifiziertes Dokument Dok', bei dem zumindest die Signatur σ gegenüber dem Dokument Dok modifiziert ist. Die Modifikation der Signatur σ des Dokuments Dok kann dabei beispielsweise mittels Rerandomisierung vorgenommen werden. Ebenso können die übrigen Datenfelder Ci, ..., cndes Dokuments im Zuge der Modifikation reandomisiert werden, wobei zumindest die in der Übereinkunft vereinbarten verschlüsselten Datenfelder Ci, ..., cn modifiziert werden, die in den verschlüsselten Datenfeldern enthaltenen Informationen jedoch unverändert bleiben. Dem Zertifikat z werden zusätzlich Informationen angefügt, die angeben, dass die Rerandomisierung korrekt durchgeführt wurde.
Die Prüfung des modifizierten Dokuments Dok' durch das Service S anhand des Zertifikats z erfolgt wie auch bei der ersten Ausführungsform der Erfindung, wobei insbesondere die Korrektheit der Rerandomisierung anhand des Zertifikats geprüft werden kann. Wie auch bei der ersten Ausführungsform der Erfindung kann dies konkret ohne Kenntnis der der Rerandomisierung zugrunde liegenden Daten erfolgen.
Anders als bei der ersten Ausführungsform der Erfindung verfügt das Service S über einen abgeleiteten privaten Schlüssel sky' des privaten Schlüssels sky des Clients C. Die Übertragung des abgeleiteten privaten Schlüssels sku‘ kann dabei entweder zwischen dem Client U und dem Service S direkt erfolgen oder aber der Client U überträgt den abgeleiteten privaten Schlüssel sku‘ an den Authentisierungsserver A, der den abgeleiteten privaten Schlüssel sku‘ auf Anfrage an das Service S übermittelt. In beiden Fällen verfügt das Service S über ausreichendes Schlüsselmaterial, namentlich über den abgeleiteten privaten Schlüssel sku‘, das es ihm ermöglicht, die in der Übereinkunft angegebenen Datenfelder Ci', ..., cn' des modifizierten Dokuments Dok' zu entschlüsseln.
Bezuaszeichenliste:

Claims (17)

  1. Patentansprüche:
    1. Verfahren zum Austausch von Datenfeldern von zertifizierten Dokumenten zwischen einem Client (U) und einem Service (S) über einen Authentisierungsserver (A), a) wobei der Client (U) über ein Dokument (Dok) verfügt, das eine Anzahl von verschlüsselten Datenfeldern (ci, cn) sowie eine Signatur (σ) umfasst, die von den verschlüsselten Datenfeldern (ci,..., cn) abhängig ist, b) wobei das Dokument (Dok) vom Client (U) an den Authentisierungsserver (A) übertragen wird, c) wobei der Client (U) dem Authentisierungsserver (A) eine Modifikationsvorschrift (m) mitteilt, die angibt welche der Datenfelder (ci, ..., cn) des Dokuments (Dok) vom Authentisierungsserver (A) an das Service (S) nicht übertragen werden dürfen, d) wobei der Client (U) und das Service (S) entsprechend der Modifikationsvorschrift (m) eine Übereinkunft treffen, in der festgelegt wird, welche für das Service (S) lesbaren Datenfelder (c1; ..., cn) in einem vom Server an das Service (S) zu übermittelnden modifizierten Dokument (Dok') enthalten sein sollen, dadurch gekennzeichnet, e) dass der Authentisierungsserver (A) basierend auf dem Dokument (Dok) ein modifiziertes Dokument (Dok') erstellt, bei dem die in der Modifikationsvorschrift (m) vorgegebenen Datenfelder (ci, ..., cn) und/oder die Signatur (σ) gegenüber dem Dokument (Dok) derart modifiziert sind, dass die im betreffenden Datenfeld (ci', cn') des modifizierten Dokuments (Dok') enthaltene Information für das Service (S) nicht rekonstruierbar ist, f) dass dem modifizierten Dokument (Dok') ein Zertifikat (z) angefügt wird, mit dem für das Service (S) nachvollziehbar ist, dass die Datenfelder (ci\ cn') des modifizierten Dokuments (Dok') auf Grundlage eines Dokuments (Dok) mit gültiger Signatur (S) erstellt wurden und die in Schritt e) genannte Modifikation der Modifikationsvorschrift (m) entspricht, g) dass das modifizierte Dokument (Dok') einschließlich des Zertifikats (z) vom Authentisierungsserver (A) an das Service (S) übertragen wird, h) dass das Service (S) das modifizierte Dokument (Dok') anhand des Zertifikats (z) dahingehend überprüft, ob die Datenfelder (cV,cn') des modifizierten Dokuments (Dok') auf Grundlage eines Dokuments (Dok) mit gültiger Signatur (σ) erstellt wurden und die in Schritt e) genannte Modifikation der Modifikationsvorschrift (m) entspricht, i) dass das Service (S) über Schlüsselmaterial verfügt, insbesondere dass an das Service (S) Schlüsselmaterial übertragen wird, das es dem Service (S) ermöglicht, die in der Übereinkunft angegebenen Datenfelder (c^, cn') des modifizierten Dokuments (Dok') zu entschlüsseln, j) dass das Service (S) die Datenfelder (ci\ cn') des modifizierten Dokuments (Dok') entschlüsselt, und k) dass das Service (S) die derart entschlüsselten Datenfelder (ai*, ..., an*) für die weitere Verarbeitung zur Verfügung hält.
  2. 2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, - dass der Client (U) und das Service (S) über private und öffentliche Schlüssel (sku, sks, pku, pks) verfügen, - dass auf Grundlage eines privaten und/oder öffentlichen Schlüssels (sks ,pks) des Service (S) sowie auf Grundlage des privaten Schlüssels (sku) des Clients (U) ein Reencryption-Schlüssel (rky^s) erstellt und dem Authentisierungsserver (A) zur Verfügung gestellt wird, - wobei mit dem Reencryption-Schlüssel (rky^s) Datenfelder (c1; ..., cn) des Dokuments (Dok), die mit dem öffentlichen Schlüssel (pky) des Clients (U) verschlüsselt wurden, derart umverschlüsselt werden, dass sie mit dem privaten Schlüssel (sks) des Service (S) entschlüsselbar sind, - dass vor der Erstellung des Zertifikats (z) in Schritt f) die einzelnen in der Übereinkunft zwischen dem Client (U) und dem Service (S) vereinbarten Datenfelder (Ci', ..., cn') des modifizierten Dokuments (Dok') mittels des Reencryption-Schlüssels (rku^s) umverschlüsselt werden, - dass im Zertifikat (z) zusätzlich Informationen enthalten sind, die angeben, dass die Umverschlüsselung mit dem auf Basis der vom Client (U) und Service (S) angegebenen Schlüssel erstellten Reencryption-Schlüssel (rku^s) korrekt durchgeführt wurde, und - dass in Schritt j) der private Schlüssel (sks) des Service (S) zur Entschlüsselung verwendet wird.
  3. 3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, - dass vor dem Umverschlüsseln eine Rerandomisierung des Dokuments (Dok) vorgenommen wird, bei der die in der Übereinkunft vereinbarten verschlüsselten Datenfelder (c1; ..., cn) modifiziert werden, die in den verschlüsselten Datenfeldern (c1; ..., cn) enthaltene Informationen jedoch unverändert bleiben, und - dass im Zertifikat (z) zusätzlich Informationen enthalten sind, die angeben, dass die Rerandomisierung korrekt durchgeführt wurde.
  4. 4. Verfahren nach Anspruch 1, dadurch gekennzeichnet, - dass der Client (U) über einen privaten und einen öffentlichen Schlüssel (sku, pku) verfügt, - dass der Client (U) aus dem privaten Schlüssel (sku) einen abgeleiteten privaten Schlüssel (sku‘) erstellt, - dass die in der Übereinkunft vereinbarten Datenfelder (Ci, ..., cn) des Dokuments (Dok) derart verschlüsselt werden, dass sie mit dem abgeleiteten privaten Schlüssel (sku‘) entschlüsselbar sind, - dass der abgeleitete private Schlüssel (sku‘) an das Service (S) übertragen wird, - dass in Schritt e) zumindest die Signatur (σ) des Dokuments (Dok) modifiziert wird, und - dass der abgeleitete private Schlüssel (sku‘) zur Entschlüsselung der Datenfelder (cA ..., cn') des modifizierten Dokuments (Dok') herangezogen wird.
  5. 5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, - dass im Zuge der Modifikation eine Rerandomisierung vorgenommen wird, bei der die in der Übereinkunft vereinbarten verschlüsselten Datenfelder (c1; ..., cn) modifiziert werden, die in den verschlüsselten Datenfeldern (c1; ..., cn) enthaltene Informationen jedoch unverändert bleiben, und - dass im Zertifikat (z) zusätzlich Informationen enthalten sind, die angeben, dass die Rerandomisierung korrekt durchgeführt wurde.
  6. 6. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, - dass der Client (U) über einen privaten und einen öffentlichen Schlüssel (sku, pku) verfügt, - dass das Dokument (Dok) erstellt wird, indem eine Anzahl von Klartext-Datenfeldern (ai, ..., an) mit dem öffentlichen Schlüssel (pku) des Clients (U) verschlüsselt werden, - dass eine Zertifizierungsstelle (CA) eine Signatur (σ) erstellt, die von den verschlüsselten Datenfeldern (Ci, ..., cn) und von ihrem eigenen privaten Schlüssel (skCA) abhängig ist, und - dass in Schritt h) der öffentlichen Schlüssel (pkCA) der Zertifizierungsstelle (CA) verwendet wird, um die Gültigkeit des Zertifikats (z) zu prüfen.
  7. 7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass die Zertifizierungsstelle (CA) vor der Erstellung der Signatur (σ) für eine Anzahl der verschlüsselten Datenfelder (c1; ..., cn) des Dokuments (Dok) überprüft, ob sich diese durch Verschlüsselung aus vorgegebenen oder zwischen dem Client (U) und Zertifizierungsstelle (CA) vereinbarten Klartext-Datenfeldern (a1;..., an) ergeben.
  8. 8. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, - dass der Client (U) an das Service (S) nach Schritt d) eine Zugriffsanfrage stellt, - dass das Service (S) dem Authentisierungsserver (A) zur Übermittlung des modifizierten Dokuments (Dok') auffordert und das modifizierte Dokument (Dok') entsprechend der Schritte, in dem Schritt h), überprüft, und - dass das Service (S) die erforderliche Berechtigung des Clients (U) anhand der entschlüsselten Datenfelder (a/, ..., an*), des Zertifikats (z) und des modifizierten Dokuments (Dok') prüft und gegebenenfalls dem Client (U) den Zugriff entsprechend der Zugriffsanfrage gewährt.
  9. 9. System zum Austausch von Datenfeldern (c^ ..., cn) und von zertifizierten Dokumenten umfassend einen Client (U), einen Server, auf dem ein Service (S) abläuft und einen Authentisierungsserver (A), a) wobei der Client (U) über ein Dokument (Dok) verfügt, das eine Anzahl von verschlüsselten Datenfeldern (c1; ..., cn) sowie eine Signatur (σ) umfasst, die von den verschlüsselten Datenfeldern (c1;..., cn) abhängig ist, b) wobei der Client (U) dazu ausgebildet ist, das Dokument (Dok) an den Authentisierungsserver (A) zu übertragen und der Authentisierungsserver (A) dazu ausgebildet ist, das Dokument (Dok) vom Client (U) zu empfangen und abzuspeichern, c) wobei der Client (U) dazu ausgebildet ist, dem Authentisierungsserver (A) eine Modifikationsvorschrift (m) mitzuteilen, die angibt, welche der Datenfelder (Ci, ..., cn) des Dokuments (Dok) vom Authentisierungsserver (A) an das Service (S) nicht übertragen werden dürfen und der Authentisierungsserver (A) dazu ausgebildet ist, die Modifikationsvorschrift (m) abzuspeichern, d) wobei eine der Modifikationsvorschrift (m) entsprechende Übereinkunft zwischen Client (U) und Service (S) festgelegt ist, die angibt, welche für das Service (S) lesbaren Datenfelder (Ci, ..., cn) in einem vom Server an das Service (S) zu übermittelnden modifizierten Dokument (Dok') enthalten sein sollen, dadurch gekennzeichnet, e) dass der Authentisierungsserver (A) dazu ausgebildet ist, basierend auf dem Dokument (Dok) ein modifizierten Dokument (Dok') zu erstellen, bei dem die in der Modifikationsvorschrift (m) vorgegebenen Datenfelder (ci, ..., cn) und/oderdie Signatur (σ) gegenüber dem Dokument (Dok) derart modifiziert sind, dass die im betreffenden Datenfeld (Ci1, ..., cn') des modifizierten Dokuments (Dok') enthaltene Information für das Service (S) nicht rekonstruierbar ist, f) dass der Authentisierungsserver (A) dazu ausgebildet ist, dem modifizierten Dokument (Dok') ein Zertifikat (z) anzufügen, mit dem für das Service (S) nachvollziehbar ist, dass die Datenfelder (ci', ..., cn') des modifizierten Dokuments (Dok') auf Grundlage des Dokuments (Dok) mit gültiger Signatur (σ) erstellt wurden und die vom Authentisierungsserver (A) vorgenommene Modifikation der Modifikationsvorschrift (m) entspricht, g) dass der Authentisierungsserver (A) dazu ausgebildet ist, das modifizierte Dokument (Dok') einschließlich des Zertifikats (z), insbesondere auf Anfrage, an das Service (S) zu übertragen, h) dass das Service (S) dazu ausgebildet ist, das modifizierte Dokument (Dok') anhand des Zertifikats (z) dahingehend zu überprüfen, ob die Datenfelder (ci', cn') des modifizierten Dokuments (Dok') auf Grundlage eines Dokuments (Dok) mit gültiger Signatur (σ) erstellt wurden und die vom Authentisierungsserver (A) vorgenommene Modifikation der Modifikationsvorschrift (m) entspricht, i) dass das Service (S) über Schlüsselmaterial verfügt, insbesondere dass es ausgebildet ist, Schlüsselmaterial vom Authentisierungsserver (A) zu empfangen, wobei das Schlüsselmaterial dem Service (S) ermöglicht, die in der Übereinkunft angegebenen Datenfelder (c/,..., cn') des modifizierten Dokuments (Dok') zu entschlüsseln, j) dass das Service (S) dazu ausgebildet ist, die Datenfelder (cV, ..., cn') des modifizierten Dokuments (Dok') zu entschlüsseln.
  10. 10. System nach Anspruch 9, dadurch gekennzeichnet, - dass der Client (U) und das Service (S) über private und öffentliche Schlüssel (sky, sks, pky, pks) verfügen, - dass der User (U) dazu ausgebildet ist, auf Grundlage eines privaten und/oder öffentlichen Schlüssels (sks, pks) des Service (S) sowie auf Grundlage des privaten Schlüssels (sky) des Clients (U) einen Reencryption-Schlüssel (rky^s) zu erstellen und ihn dem Authentisierungsserver (A) zur Verfügung zu stellen, - dass der Authentisierungsserver (A) dazu ausgebildet ist, mit dem Reencryption-Schlüssel (rky^s) Datenfelder (Ci, ..., cn) des Dokuments (Dok), die mit dem öffentliche Schlüssel (pku) des Clients (U) verschlüsselt wurden, derart umzuverschlüsseln, dass sie mit dem privaten Schlüssel (sks) des Service (S) entschlüsselbar sind, - dass der Authentisierungsserver (A) dazu ausgebildet ist, dem Zertifikat (z) Informationen hinzuzufügen, die angeben, dass die Umverschlüsselung mit dem auf Basis der vom Client (U) und Service (S) angegebenen Schlüssel erstellten Reencryption-Schlüssel (rky^s) korrekt durchgeführt wurde, und - dass das Service (S) dazu ausgebildet ist, die Datenfelder (cV, ..., cn') des modifizierten Dokuments (Dok') mit seinem privaten Schlüssel (sks) zu entschlüsseln.
  11. 11. System nach Anspruch 10, dadurch gekennzeichnet, - dass der Authentisierungsserver (A) dazu ausgebildet ist, vor dem Umverschlüsseln eine Rerandomisierung des Dokuments (Dok) vorzunehmen, bei der die in der Übereinkunft vereinbarten verschlüsselten Datenfelder (c^ ..., cn) modifiziert werden, die in den verschlüsselten Datenfeldern (c^ ..., cn) enthaltenen Informationen jedoch unverändert bleiben, und - dass der Authentisierungsserver (A) dazu ausgebildet ist, dem Zertifikat (z) zusätzlich Informationen hinzuzufügen, die angeben, dass die Rerandomisierung korrekt durchgeführt wurde.
  12. 12. System nach Anspruch 9, dadurch gekennzeichnet, - dass der Authentisierungsserver (A) dazu ausgebildet ist, basierend auf dem Dokument (Dok) ein modifizierten Dokument (Dok1) zu erstellen, bei dem die in der Modifikationsvorschrift (m) vorgegebenen Datenfelder (Ci, ..., cn) und/oderdie Signatur (o) gegenüber dem Dokument (Dok) derart modifiziert sind, dass die im betreffenden Datenfeld (Ci', ..., cn') des modifizierten Dokuments (Dok1) enthaltene Information für das Service (S) nicht rekonstruierbar ist, - dass der Client (U) dazu ausgebildet ist, aus dem privaten Schlüssel (sky) einen abgeleiteten privaten Schlüssel (sky‘) zu erstellen, - dass der Client (U) dazu ausgebildet ist, die in der Übereinkunft vereinbarten Datenfelder (Ci, ..., cn) des Dokuments (Dok) derart zu verschlüsseln, dass sie mit dem abgeleiteten privaten Schlüssel (sku‘) entschlüsselbar sind, - dass der Client (U) dazu ausgebildet ist, den abgeleiteten privaten Schlüssel (sky‘), insbesondere mittelbar durch eine unter einem öffentlichen Schlüssel (pks) des Servers (S) verschlüsselte Übertragung an den Authentisierungsserver (A), der diese Verschlüsselung des privaten Schlüssels (sku‘) dem Service (S) zum Abruf zur Verfügung hält, an das Service (S) zu übertragen, - dass der Authentisierungsserver (A) dazu ausgebildet ist, im Rahmen der Erstellung des modifizierten Dokuments (Dok') zumindest die Signatur (σ) des Dokuments (Dok) zu modifizieren, und - dass das Service (S) dazu ausgebildet ist, den abgeleiteten privaten Schlüssel (sku‘) zur Entschlüsselung der Datenfelder (Ci', ..., cn') des modifizierten Dokuments (Dok') heranzuziehen.
  13. 13. System nach Anspruch 12, dadurch gekennzeichnet, - dass der Authentisierungsserver (A) dazu ausgebildet ist, vor dem Umverschlüsseln eine Rerandomisierung des Dokuments (Dok) vorzunehmen, bei der die in der Übereinkunft vereinbarten verschlüsselten Datenfelder (c1; ..., cn) modifiziert werden, die in den verschlüsselten Datenfeldern (c1; ..., cn) enthaltenen Informationen jedoch unverändert bleiben, und - dass der Authentisierungsserver (A) dazu ausgebildet ist, dem Zertifikat (z) zusätzlich Informationen hinzuzufügen, die angeben, dass die Rerandomisierung korrekt durchgeführt wurde.
  14. 14. System nach einem der Ansprüche 9 bis 13, dadurch gekennzeichnet, - dass der Client (U) über einen öffentlichen und einen privaten Schlüssel (pks, sks) verfügt, - dass der Client (U) dazu ausgebildet ist, eine Anzahl von Klartext-Datenfeldern (ai, ..., an) mit seinem öffentlichen Schlüssel (pku) zu verschlüsseln und derart ein Dokument (Dok) zu erstellen und das Dokument (Dok) an einer Zertifizierungsstelle (CA) zu übertragen, - dass eine Zertifizierungsstelle (CA) vorgesehen ist, die dazu ausgebildet ist, eine Signatur (σ) zu erstellen, die von den verschlüsselten Datenfeldern (c1; ..., cn) und von einem der Zertifizierungsstelle (CA) zugehörigen privaten Schlüssel (skCA) abhängig ist, und - dass das Service (S) dazu ausgebildet ist, den öffentlichen Schlüssel (pkCA) der Zertifizierungsstelle (CA) abzufragen, um zu überprüfen, ob das modifizierten Dokument (Dok') unter korrekter Anwendung der Modifikationsvorschrift (m) auf Grundlage einer gültigen Signatur (σ) der Zertifizierungsstelle (CA) erstellt wurde.
  15. 15. System nach einem der Ansprüche 9 bis 14, dadurch gekennzeichnet, dass die Zertifizierungsstelle (CA) dazu ausgebildet ist, vor der Erstellung der Signatur (σ) für eine Anzahl der verschlüsselten Datenfelder (Ci, ..., cn) des Dokuments (Dok) zu überprüfen, ob sich diese durch Verschlüsselung aus vorgegebenen oder zwischen dem Client (U) und der Zertifizierungsstelle (CA) vereinbarten Klartext-Datenfeldern (ai,..., an) ergeben.
  16. 16. System nach einem der Ansprüche 9 bis 15, dadurch gekennzeichnet, - dass der Client (U) dazu ausgebildet ist, an das Service (S) eine Zugriffsanfrage zu stellen nach Übermittlung des Dokuments an den Authentisierungsserver (A), - dass das Service (S) dazu ausgebildet ist, dem Authentisierungsserver (A) zur Übermittlung des modifizierten Dokuments (Dok') aufzufordern und das modifizierten Dokument (Dok') anhand der Modifikationsvorschrift (m) zu überprüfen, und - dass das Service dazu ausgebildet ist, die erforderliche Berechtigung des Clients (U) anhand der entschlüsselten Datenfelder (a^, ..., an*) des Zertifikats (z) und des modifizierten Dokuments (Dok1) zu überprüfen und im Falle einer positiven Überprüfung dem Client (U) Zugriff entsprechend der Zugriffsanfrage zu gewähren.
  17. 17. Datenträger auf dem ein Programm zur Durchführung eines Verfahrens im Client (U), Service (S) oder Authentisierungsserver (A) nach einem der Ansprüche 1 bis 8 abgespeichert ist.
ATA51019/2016A 2016-11-09 2016-11-09 Verfahren zum Austausch von Datenfeldern von zertifizierten Dokumenten AT519025B1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
ATA51019/2016A AT519025B1 (de) 2016-11-09 2016-11-09 Verfahren zum Austausch von Datenfeldern von zertifizierten Dokumenten
PCT/AT2017/060293 WO2018085870A1 (de) 2016-11-09 2017-11-06 Verfahren zum austausch von datenfeldern von zertifizierten dokumenten

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
ATA51019/2016A AT519025B1 (de) 2016-11-09 2016-11-09 Verfahren zum Austausch von Datenfeldern von zertifizierten Dokumenten

Publications (2)

Publication Number Publication Date
AT519025B1 AT519025B1 (de) 2018-03-15
AT519025A4 true AT519025A4 (de) 2018-03-15

Family

ID=60381971

Family Applications (1)

Application Number Title Priority Date Filing Date
ATA51019/2016A AT519025B1 (de) 2016-11-09 2016-11-09 Verfahren zum Austausch von Datenfeldern von zertifizierten Dokumenten

Country Status (2)

Country Link
AT (1) AT519025B1 (de)
WO (1) WO2018085870A1 (de)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10944783B2 (en) 2018-07-12 2021-03-09 At&T Intellectual Property I, L.P. Dynamic denial of service mitigation system
CN112597118B (zh) * 2021-01-04 2024-03-29 杭州海量存储技术有限公司 一种共享文件的添加方法及装置
CN113452705B (zh) * 2021-06-28 2023-02-21 长春吉大正元信息技术股份有限公司 一种加密通信方法、装置、电子设备和存储介质
CN116132069B (zh) * 2023-04-10 2023-06-27 江苏省国信数字科技有限公司 一种实现多ca数字证书和多电子签章互联互通的方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8327128B1 (en) * 2011-07-28 2012-12-04 Cloudflare, Inc. Supporting secure sessions in a cloud-based proxy service
WO2013188875A1 (en) * 2012-06-15 2013-12-19 Massachusetts Institute Of Technology Optimized transport layer security
US20140095865A1 (en) * 2012-09-28 2014-04-03 Blue Coat Systems, Inc. Exchange of digital certificates in a client-proxy-server network configuration

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8327128B1 (en) * 2011-07-28 2012-12-04 Cloudflare, Inc. Supporting secure sessions in a cloud-based proxy service
WO2013188875A1 (en) * 2012-06-15 2013-12-19 Massachusetts Institute Of Technology Optimized transport layer security
US20140095865A1 (en) * 2012-09-28 2014-04-03 Blue Coat Systems, Inc. Exchange of digital certificates in a client-proxy-server network configuration

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
C. P. SCHNORR: "Efficient Signature Generation by Smart Cards." Journal of Cryptology, Nr.4, 1991, Seiten 161-174. *
E. BANGERTER et al.: " Bringing Zero-Knowledge Proofs of Knowledge to Practice." In: B. Christianson et al. (eds.): Security Protocols '09. Proceedings, 2013, Springer LNCS 7028, Seiten 51-62. *
M. BLAZE et al.: "Divertible Protocols and Atomic Proxy Cryptography." In: K. Nyberg (ed.): EUROCRYPT '98. Proceedings, 1998, Springer LNCS 1403, Seiten 127-144. *
O. GOLDREICH, et al.: "How to Prove All NP Statements in Zero-Knowledge and a Methodology of Cryptographic Protocol Design." In: A. Odlyzko (ed.), "Advances in Cryptology - CRYPTO '86". Proceedings, 1987, Springer LNCS 263, Seiten 171-185. *
U. MAURER: "Unifying Zero-Knowledge Proofs of Knowledge." In: B. Preneel (ed.): AFRICACRYPT '09. Proceedings, 2009, Springer LNCS 5580, Seiten 272-286. *

Also Published As

Publication number Publication date
AT519025B1 (de) 2018-03-15
WO2018085870A1 (de) 2018-05-17

Similar Documents

Publication Publication Date Title
DE102012206341B4 (de) Gemeinsame Verschlüsselung von Daten
DE112011100182B4 (de) Datensicherheitsvorrichtung, Rechenprogramm, Endgerät und System für Transaktionsprüfung
DE60304744T2 (de) Verfahren,vorrichtung und computerprogramme zur erzeugung und/oder verwendungkonditionaler elektronischer signaturen zur meldung von statusänderungen
EP3033855B1 (de) Unterstützung einer entschlüsselung von verschlüsselten daten
EP3031226B1 (de) Unterstützung der nutzung eines geheimen schlüssels
DE102009001719B4 (de) Verfahren zur Erzeugung von asymmetrischen kryptografischen Schlüsselpaaren
EP2975570A1 (de) Verfahren und eine Vorrichtung zur Absicherung von Zugriffen auf Wallets in denen Kryptowährungen abgelegt sind
AT519025B1 (de) Verfahren zum Austausch von Datenfeldern von zertifizierten Dokumenten
EP3452941B1 (de) Verfahren zur elektronischen dokumentation von lizenzinformationen
EP1290530A1 (de) Verschlüsseln von abzuspeichernden daten in einem iv-system
DE102009017221A1 (de) Information-Rights-Management
DE602005003631T2 (de) Ausschluss der Passwortaufdeckung bei Attributzertifikatausgabe
EP3672142A1 (de) Verfahren und system zur sicheren übertragung eines datensatzes
EP3629516A1 (de) Dezentralisierte identitätsmanagement-lösung
EP2491513B1 (de) Verfahren und system zum bereitstellen von edrm-geschützten datenobjekten
DE112007000419B4 (de) Digitale-Rechte-Managementsystem mit diversifiziertem Inhaltsschutzprozess
DE102006009725A1 (de) Verfahren und Vorrichtung zum Authentifizieren eines öffentlichen Schlüssels
EP2184695A1 (de) Verfahren zum Kombinieren von Daten mit einer zur Verarbeitung der Daten vorgesehenen Vorrichtung, korrespondierende Funktionalität zur Ausführung einzelner Schritte des Verfahrens und Computerprogram zur Implementierung des Verfahrens
DE102010021655A1 (de) Verfahren zum Bereitstellen von EDRM (Enterprise Digital Rights Management) geschützten Datenobjekten
DE102022000857B3 (de) Verfahren zur sicheren Identifizierung einer Person durch eine Verifikationsinstanz
EP4033694B1 (de) Verfahren und vorrichtung zur vereinheitlichung von blockchain adressen
DE102012220774B4 (de) Verfahren zur Durchführung von Transaktionen
WO2022002502A1 (de) Anonymisiertes bereitstellen eines dienstes
DE102019202381A1 (de) Verfahren zum Transfer von Daten
CH717898A1 (de) Server zur Abwicklung von Finanz-Transaktionen.