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.

Das zu dieser Anmeldung führende Projekt wurde durch das Horizon 2020 Forschungsund Innovationsrahmenprogramm der Europäischen Union unter Grant Agreement Nummer 653454 ('CREDENTIAL') unterstützt.

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.

Typischerweise 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 U 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 c _{l 5} c _n aufweist, wobei die verschlüsselten Datenfelder c c _n nach ihrer Entschlüsselung dem Service die Freigabe der vom Client U angefragten Daten erlauben. Die Verschlüsselung der betreffenden Datenfelder c c _n 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 c c _n des Dokuments Dok tatsächlich zertifiziert bzw. signiert hat und ob sich diese Signatur σ aus den verschlüsselten Datenfeldern Ci , c _n des 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 U und der Zertifizierungsstelle vereinbarten Klartext- Datenfeldern a _u a _n 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 a _u a _n des Dokuments Dok mit einem eigenen vorgegebenen Schlüssel und erstellt basierend auf den verschlüsselten Datenfeldern c _{l 5} c _n eine Signatur s. Bei der Erstellung dieser Signatur wird vorteilhafterweise ein privater Schlüssel sk _CA der Zertifizierungsstelle CA verwendet, wobei zur externen Überprüfung der Gültigkeit der Signatur von der Zertifizierungsstelle CA ein öffentlicher Schlüssel pk _CA allgemein bekannt gegeben wird.

Darüber hinaus besteht auch die Möglichkeit, dass die Verschlüsselung der einzelnen Datenfelder Ci , c _n 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 Ci , c _n des Dokuments Dok durch Verschlüsselung aus den zwischen dem Client U und der Zertifizierungsstelle CA vereinbarten Klartext- Datenfeldern a a _n ergeben. So kann beispielsweise der Client U 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 Ci , c _n des Dokuments Dok durch Verschlüsselung der von der Zertifizierungsstelle CA zu bestätigenden Klartext-Datenfeldern a a _n 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 a _n werden jeweils von einander unabhängig verschlüsselt, wobei durchaus die Möglichkeit besteht, dass einzelne der resultierenden verschlüsselten Datenfelder Ci , c _n 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 Ci , c _n 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 c c _n des 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 Ci enthält, das zufällig erstellt wurde und dessen Datenfeldgröße so groß ist, dass ausgeschlossen werden kann, dass ein Datenfeld Ci 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 Ci , 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 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 c c _n sowie eine Signatur, die von den verschlüsselten Datenfeldern c _{l 5} c _n abhängig ist. Die Signatur σ kann bei Kenntnis der betreffenden Zertifizierungsstelle CA dahingehend überprüft werden, ob die verschlüsselten Datenfelder c c _n 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 Ci , c _n 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 , c _n des 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 c _{l 5} c _n 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 c _{l 5} c _n 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 c ₃ mitteilt. Die Modifikationsvorschrift m, die der Client U dem Authentisierungsserver A übermittelt, gibt an, dass das Geburtsdatum betreffende Datenfeld d ₃ des Dokuments Dok vom Authentisierungsserver A an das Service S übertragen werden darf während die den Vornamen und Nachnamen betreffenden Datenfelder Ci , c ₂ 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 sku, sk _s bzw. pku, pk _s sowie den öffentlichen Schlüssel der Zertifizierungsstelle pk _C A- Auf Grundlage eines privaten und/oder öffentlichen Schlüssels des Service sowie auf Grundlage des privaten Schlüssels des Clients U wird ein Reencryption-Schlüssel rku _^s erstellt und dem Authentisierungsserver A übergeben. Mit diesem Reencryption-Schlüssel rku _^s können Datenfelder c c _n 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 sk _s 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 d', c _n ', die dem modifizierten Dokument Dok' zugewiesen werden. Diejenigen Datenfelder Ci , c ₂ , 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 U 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 c , c _n ' 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 Ci , c _n sowie Löschen oder Überschreiben der nicht zu übermittelnden Datenfelder Ci , c ₂ 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 c ₃ 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 d', c _n ' 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 Systemparameter 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 pk _C A, sowie den eigenen öffentlichen und privaten Schlüssel pku, sku. Die CA hat die angegebenen Eingabewerte, wobei pk _C A, sk _C A, abweichend vom Benutzer U die eigenen privaten und öffentlichen Schlüssel bezeichnen. Die Klartext- Datenfelder a, werden in Zeile 3-4 verschlüsselt zu q, 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, (r,) , _{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 rku _^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 pk _s und sk _s 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,) , _< = _Di (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 sk _s 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 201 1 , LNCS vol 6841 , pp. 649-666, Springer Verlag, 201 1 .) liefert das folgende konkrete Signatur- Protokoll:

Der öffentliche Schlüssel der Zertifizierungsstelle pk _C A besteht in diesem konkreten Fall aus G,H,W ₁ ,...,W _2n+ 2, wobei das algebraische Setting in der Originalpublikation beschrieben ist. Der private Schlüssel der Zertifizierungsstelle (CA) sk _C A besteht aus r,v,w ₁ ,...,w _2n+ 2- Die Schritte 7-1 1 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 referenzierten Literatur realisiert werden kann. Die zu beweisenden Werte würden konkret wie folgt belegt werden:

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 d ₃ entschlüsseln. Dazu verfügt das Service S über entsprechendes Schlüsselmaterial, das es ihm ermöglicht, die in der Übereinkunft angegebenen Datenfelder d ₃ 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 sk _s verfügt, mit dem es ihm möglich ist, die im modifizierten Dokument Dok' enthaltenen Datenfelder d ₃ zu entschlüsseln. Das Service entschlüsselt die betreffenden Datenfelder d ₃ des modifizierten Dokuments Dok' und erstellt auf diese Weise entschlüsselte Datenfelder a ₃ ^* 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 Ci , c _n des Dokuments Dok vornimmt, sondern abgeleitete private Schlüssel sku' des Clients U 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 sku und einen öffentlichen Schlüssel pku. Der Client U erstellt aus dem privaten Schlüssel sku einen abgeleiteten privaten Schlüssel sku', wobei die in der Übereinkunft vereinbarten Datenfelder c _{l 5} c _n des Dokuments Dok derart verschlüsselt werden, dass sie nicht nur mit dem privaten Schlüssel sku sondern auch mit dem abgeleiteten privaten Schlüssel sku' entschlüsselbar sind. Alle anderen Datenfelder des Dokuments Dok können hingegen nicht mit dem abgeleiteten privaten Schlüssel sku' entschlüsselt werden. Der abgeleitete private Schlüssel sku' 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 , c _n des Dokuments im Zuge der Modifikation reandomisiert werden, wobei zumindest die in der Übereinkunft vereinbarten verschlüsselten Datenfelder c c _n 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 sku' des privaten Schlüssels sku des Clients U. 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 c , c _n ' des modifizierten Dokuments Dok' zu entschlüsseln.

The project leading to this application has received funding from the European Union's Horizon 2020 research and Innovation programme under grant agreement No 653454.

Bezuqszeichenliste:

Client U

Service S

Authentisierungsserver A

Dokument Dok verschlüsselte Datenfelder Ci , ... , C _n

Signatur σ

Modifikationsvorschrift m

Zertifikat z

modifiziertes Dokument Dok'

Datenfelder des modifizierten Dokuments Ci , C _n entschlüsselte Datenfelder a _n ^*

Reencryption-Schlüssel rku _^ s öffentlicher Schlüssel pku, pk _s , pk _CA privater Schlüssel sku, sk _s , sk _CA abgeleiteter privater Schlüssel sku'

Zertifizierungsstelle CA

Klartext-Datenfelder a-i , a _n