WO2018085870A1 - Verfahren zum austausch von datenfeldern von zertifizierten dokumenten - Google Patents

Verfahren zum austausch von datenfeldern von zertifizierten dokumenten Download PDF

Info

Publication number
WO2018085870A1
WO2018085870A1 PCT/AT2017/060293 AT2017060293W WO2018085870A1 WO 2018085870 A1 WO2018085870 A1 WO 2018085870A1 AT 2017060293 W AT2017060293 W AT 2017060293W WO 2018085870 A1 WO2018085870 A1 WO 2018085870A1
Authority
WO
WIPO (PCT)
Prior art keywords
document
service
data fields
client
dok
Prior art date
Application number
PCT/AT2017/060293
Other languages
English (en)
French (fr)
Inventor
Stephan Krenn
Thomas LORÜNSER
Christoph STRIECKS
Original Assignee
Ait Austrian Institute Of Technology 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 Institute Of Technology Gmbh filed Critical Ait Austrian Institute Of Technology Gmbh
Publication of WO2018085870A1 publication Critical patent/WO2018085870A1/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

Definitions

  • the invention relates to a method for the selective exchange of individual data fields of certified documents between a client and a service via an authentication server while maintaining the authenticity of the data in a cloud environment.
  • the object of the invention is to provide a method for the selective exchange of data fields of certified documents between a client and a service via an authentication server, in which the authentication server receives no appreciable information about the exchanged between the client and the service data fields.
  • the invention solves this problem in a method of the type mentioned above with the features of claim 1.
  • a reencryption key is created based on a private and / or public key of the service and based on the private key of the client and made available to the authentication server,
  • Reencryption key encrypts data fields of the document which have been encrypted with the public key of the client in such a way that they can be decrypted with the private key of the service
  • the certificate additionally contains information indicating that the encryption was performed correctly using the Reencryption key created on the basis of the keys specified by the client and service
  • step j) the private key of the service is used for decryption.
  • That the certificate additionally contains information indicating that the re-randomization has been carried out correctly.
  • step e) at least the signature of the document is modified
  • That the certificate additionally contains information indicating that the re-randomization has been carried out correctly.
  • a certification authority creates a signature that depends on the encrypted data fields and on its own private key, and - that in step h) the public key of the certification authority is used to check the validity of the certificate.
  • the certification authority checks for a number of the encrypted data fields of the document before the signature is created, whether by default or between the client and Certification authority agreed plain text data fields.
  • the service requests the authentication server to transmit the modified document and checks the modified document according to the steps in step h), and
  • That the service checks the required authorization of the client based on the decrypted data fields, the certificate and the modified document and, where appropriate, granted access to the client according to the access request.
  • Fig. 1 shows schematically the procedure in a first embodiment of the invention.
  • a client U, a service S and an authentication server A are connected to one another via a computer network, in particular via the Internet, whereby a separate logical connection can be established between each of the aforementioned computers U, S, A.
  • the procedure according to the invention is used in order to make an access request from the client U to the service S, wherein the user does not necessarily have all the information required for authentication at the service S available to him on the client U currently being used by him.
  • This information is stored in the form of a document on the authentication server A.
  • the service S requests the authentication server A for the transmission of the authentication required data and then checks the required authorization of the client U based on the data transmitted by the authentication server A. If the data transmitted by the authentication server A to the service S for authentication allow access or authorize the client U to access the service, the service S allows the client U access according to the access request.
  • a document Dok For authentication, a document Dok is created, which has a number of encrypted data fields c 1 5 c n , wherein the encrypted data fields cc n after their decryption allow the service to release the data requested by the client U.
  • the encryption of the relevant data fields cc n of the document Dok can be carried out either by the relevant client U or by a certification authority CA.
  • a signature ⁇ is created by the certification authority CA or by the client U and added to the document Dok. With this signature ⁇ , it can be subsequently checked whether the certification authority CA has actually certified or signed the encrypted data fields cc n of the document doc and whether this signature ⁇ results from the encrypted data fields Ci, c n of the document doc.
  • the certification authority CA checks before creating the signature, if the signature actually agreed by encryption from the predetermined or between the client and the U CA. plain text data fields a u a n yield.
  • the certification authority CA prepares a digital document Dok with the data fields "first name”, “last name”, "date of birth” in the form of an authority entitled to issue an identity card
  • the document in question Dok are created directly by the CA CA.
  • the certification authority CA encrypts the individual plain-text data fields a u n n of the document doc with its own predefined key and, based on the encrypted data fields c l 5 c n , creates a signature s.
  • a private key sk CA of the certification authority CA is advantageously used, wherein a public key pk CA is generally disclosed for external verification of the validity of the signature by the certification authority CA.
  • the encryption of the individual data fields Ci, c n of the document Dok is made by the user or by the client U itself, wherein the certification authority CA is given the opportunity to check whether the encrypted data fields Ci, c n of the document Dok by encryption from between the client U and the CA CA agreed plain text data fields aa n revealed.
  • the client U can encrypt its personal data "first name”, “last name”, "date of birth” by a certification authority CA authorized to issue identification cards in a manner prescribed by it and can prove to the certification authority CA that the encrypted ones are authenticating Data fields Ci, c n of the document Dok by encryption of the clear to be confirmed by the certification authority CA plain text data fields aa n .
  • the CA verifies this and provides the document Dok with a corresponding signature ⁇ .
  • the document can be created if the client U, as indicated in this embodiment, has a private and a public key sku, pku.
  • the document Dok is created by the client U or the certification authority CA encrypts a number of plain text data fields with the client U public key.
  • the certification authority CA generates a signature ⁇ that depends on the encrypted data fields and on their own private signature keys sku.
  • the individual plaintext data fields aa n are each encrypted independently of one another, wherein it is quite possible that some of the resulting encrypted data fields Ci, c n are encrypted according to different encryption methods and / or with different keys and contained in the document doc.
  • the signature ⁇ issued by the certification authority CA is based on the encrypted data fields Ci, c n of the document Dok and allows an external check as to whether on the one hand the signature ⁇ actually originates from the certification authority CA and on the other hand that the encryption of the individual data fields cc n the document has expired correctly.
  • the certification authority CA agrees with the service S or cooperates with it. This can be advantageous, for example, if a particular service provides one-time codes with which certain services can be called up once, in particular, this relates to the case of the one-time retrieval of a movie via a portal.
  • the client U can create as desired a document Dok, which contains an encrypted data field Ci, which was created randomly and whose data field size is so large that can be excluded that a data field Ci des same content is randomly created twice or more times. Typically, a data field size of 16 to 32 bytes can be selected for this purpose.
  • the client U transmits to the certification authority CA, which is under the control of the service S, a document Dok with an encrypted data field Ci, the content of which has been defined by it.
  • the certification authority CA confirms, for example, after payment, the correctness or validity of the document Dok or of the encrypted data field created by the client U with regard to the usability for a single viewing of a film in the service S concerned.
  • the client U has one or more documents Doc after being created by the certification authority CA.
  • the or each document Dok has a number of encrypted data fields cc n and a signature derived from the encrypted data fields c l 5 c n is dependent.
  • the signature ⁇ can be checked as to whether the encrypted data fields cc n actually originate from the certification authority CA.
  • the authentication server A allows a configuration to the effect that this individual services S allows the query of different data fields Ci, c n of a document stored in his doc.
  • a modification rule m is specified which prescribes to the authentication server A which of the encrypted data fields Ci, c n of the document doc may not be transmitted from the authentication server A to the service S.
  • the client U and the service S reach an agreement which determines which service-readable data fields c l 5 c n should be contained in a document doc 'to be transmitted to the service.
  • the client U the authentication server A deposit a document Doc, in which are stored as data fields c l 5 c n both his name (first name and last name) and his date of birth. Furthermore, the client U agrees with the service S that the service S is only required to prove that the user has reached a certain age, so that the service S only informs the encrypted data field c 3 representing the date of birth which is contained in the document Dok.
  • the modification instruction m which the client U transmits to the authentication server A, indicates that the date of birth data field d 3 of the document doc may be transmitted from the authentication server A to the service S while those concerning the first name and last name Data fields Ci, c 2 of the document doc from the authentication server A may not be transmitted to the service S.
  • the client U and the service S have private and public keys sku, sk s and pku, pk s and the public key of the certification authority pk C A- Based on a private and / or public Key of the service and based on the private key of the client U a Reencryption key rku ⁇ s is created and passed to the authentication server A. With this reencryption key rku ⁇ s , data fields cc n of the document Dok, which are encrypted with the public key pku of the client U, can be re-encrypted in such a way that they can be decrypted with the private key sk s of the service S.
  • Such a procedure can be carried out, for example, in connection with an EIGamal-type encryption, see in particular 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.
  • modified document Dok ' In the context of the creation of the modified document Dok ', in which the individual data fields of the document Dok are re-encrypted, one obtains modified data fields d', c n ', which are assigned to the modified document Dok'. Those data fields Ci, c 2 , which may not be transmitted to the service S due to the modification rule m, are deleted or overwritten with random numbers.
  • a re-randomization of the document may be performed in which the encrypted data fields agreed upon in the agreement between the client U and the service are modified, the information contained in the encrypted data fields or the plain texts contained in the encrypted data fields remain unchanged.
  • the modified document Dok ' is further added a certificate z, with which it is comprehensible for the service S that the data fields c, c n ' of the modified document Dok 'were created on the basis of a document Dok with a valid signature ⁇ and the modification of the Document Dok comprising the steps of re-encrypting the data fields Ci, c n and deleting or overwriting the data fields Ci, c 2 not to be transmitted.
  • the certificate z additionally contains information indicating that the encryption is based on the Reencryption key rku ⁇ s created by client U and service S was executed correctly.
  • the certificate z is in addition to the correctness of the transcoding still added information with which it can be understood that the Rerandomtician was performed correctly.
  • the service S for example at the request of the client U, wants to check whether certain data fields c 3 correspond to predefined criteria, then it issues a request to the authentication server A for transmission of the modified document Doc '.
  • the authentication server A then transmits the modified document Dok 'including the certificate z to the service S.
  • the service S checks the modified document Dok' on the basis of the certificate z to determine whether the data fields d ', c n ' of the modified document doc 'are based on of a document Dok having a valid signature ⁇ have been created and the abovementioned modification corresponds to the modification rule m, ie whether the re-encryption and, if appropriate, re-randomization were carried out correctly.
  • the public key pku of the certification authority CA is used to check the validity of the certificate z.
  • the user U has as input values any system parameters sp, the plaintext data fields a, the range of permitted values for the data fields AS, the indices of the certification authority CA disclosed values D, the public key of the CA pk C A, and their own public and private keys pku, sku.
  • the CA has the specified input values, where pk C A, sk C A, deviating from the user U own private and public keys designate.
  • the plain text data fields a are encrypted into q in line 3-4 and transferred to the CA in line 5.
  • the user proves by means of a zero-knowledge proof that any disclosed data fields correspond to the agreed values, in concrete terms the values to be proved would be occupied by e, (r,), e D.
  • the CA signs the encrypted data fields by means of the signing algorithm Sign of the selected signature method, and returns the signature in line 8 to the user, who outputs the corresponding values and transmits them to the authentication server A.
  • the authentication server A and the service S carry out the following steps:
  • the authentication server A receives the specified input value, similar to the case of the above protocol. Furthermore, it receives a reencryption key rku ⁇ s , which allows to re-encrypt key texts from the user's public key to those of the service, the public and private keys of the service being designated by pk s and sk s . The service receives the corresponding specified input values.
  • step 1-2 the authentication server A rerandominstrument the key texts of the user.
  • step 3-4 the data fields not revealed to Service S are replaced by random values.
  • the actual encryption is done in step 5 and the results are transferred to S.
  • step 7 A now proves by means of zero-knowledge proof that the re-indirection and the re-encryption were correctly performed and the data fields that were not disclosed were correctly blackened, that only correct key material was used and that a signature is known on the original encrypted data fields of CA.
  • the public key of the certification authority pk C A in this specific case consists of G, H, W 1 , ..., W 2n + 2, the algebraic setting being described in the original publication.
  • the private key of the certification authority (CA) sk C A consists of r, v, w 1 , ..., w 2n + 2-. Steps 7-1 1 now describe the precise signature process.
  • Steps 6-13 as well as parts of the values sent in step 14 are used for precalculation for the zero-knowledge proof step carried out in step 15 for the creation of the certificate z, the concrete implementation of which can be realized directly by means of the referenced literature.
  • the values to be proved would be substantiated as follows:
  • the service can decrypt the individual data fields d 3 provided to it .
  • the service S has corresponding key material which enables it to decrypt the data fields d 3 of the modified document doc 'specified in the agreement. Due to the previously performed re-encryption, it is sufficient in the present embodiment of the invention, if the service has its own private key sk s , with which it is possible for him to decrypt the data contained in the modified document doc 'd 3 .
  • the service decrypts the relevant data fields d 3 of the modified document doc 'and thus creates decrypted data Data fields a 3 * which are available for further processing.
  • it is merely checked whether the date of birth contained in the relevant document is more than 18 years before the current time, ie whether the user concerned is older than 18 years and is therefore entitled to receive the service S in question.
  • FIG. 2 a second preferred embodiment of the invention is shown in more detail (FIG. 2), which does not carry out a re-encryption of the data fields Ci, c n of the document Dok, but uses derived private keys sku 'of the client U.
  • the creation of the document Dok between the certification authority CA and the client U takes place as in the first embodiment of the invention.
  • the client U has a private key sku and a public key pku.
  • the client U creates a derived private key sku 'from the private key sku, whereby the data fields c 1 5 c n of the document Dok agreed upon in the agreement are encrypted in such a way that they not only sku with the private key but also with the derived private key Key sku 'are decipherable. All other data fields of the document Dok, however, can not be decrypted with the derived private key sku '.
  • the derived private key sku ' is transmitted to the service S.
  • the authentication server A prepares a modified document Dok 'based on the document Dok, in which at least the signature ⁇ is modified with respect to the document doc.
  • the modification of the signature ⁇ of the document Dok can be carried out, for example, by means of rerandomization.
  • the remaining data fields Ci, c n of the document can be reandomized in the course of the modification, whereby at least the encrypted data fields cc n agreed in the convention are modified, but the information contained in the encrypted data fields remains unchanged.
  • the z certificate is appended with information indicating that the rerandomization was performed correctly.
  • the service S has a derived private key sku 'of the private key sku of the client U.
  • the Transfer of the derived private key sku 'can take place either directly between the client U and the service S or else the client U transmits the derived private key sku' to the authentication server A, which sku the derived private key on request to the service S transmitted.
  • the service S has sufficient key material, namely the derived private key sku ', which enables it to decrypt the data fields c, c n ' of the modified document doc specified in the agreement.
  • the project has received funding from the European Union's Horizon 2020 research and innovation program and grant agreement No 653454.

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

Verfahren zum Austausch von Datenfeldern von zertifizierten Dokumenten
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 cl 5 cn aufweist, wobei die verschlüsselten Datenfelder c cn nach ihrer Entschlüsselung dem Service die Freigabe der vom Client U angefragten Daten erlauben. Die Verschlüsselung der betreffenden Datenfelder c 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 c cn des Dokuments Dok tatsächlich zertifiziert bzw. signiert hat und ob sich diese Signatur σ aus den verschlüsselten Datenfeldern Ci , cn 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 au 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 au an des Dokuments Dok mit einem eigenen vorgegebenen Schlüssel und erstellt basierend auf den verschlüsselten Datenfeldern cl 5 cn eine Signatur s. Bei der Erstellung dieser Signatur wird vorteilhafterweise 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 Ci , 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 Ci , cn des 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 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 , cn des 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 Ci , 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 Ci , 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 c cn 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 cn sowie eine Signatur, die von den verschlüsselten Datenfeldern cl 5 cn abhängig ist. Die Signatur σ kann bei Kenntnis der betreffenden Zertifizierungsstelle CA dahingehend überprüft werden, ob die verschlüsselten Datenfelder c 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 Ci , 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 , cn 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 cl 5 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 cl 5 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 Ci , 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 sku, sks bzw. pku, 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 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 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 d', cn', die dem modifizierten Dokument Dok' zugewiesen werden. Diejenigen Datenfelder Ci , 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 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 , 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 Ci , cn sowie Löschen oder Überschreiben der nicht zu übermittelnden Datenfelder Ci , 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 d', 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:
Figure imgf000013_0001
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 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 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:
Figure imgf000014_0001
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 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,) , <= 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 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 201 1 , LNCS vol 6841 , pp. 649-666, Springer Verlag, 201 1 .) liefert das folgende konkrete Signatur- Protokoll:
Figure imgf000015_0001
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,w1 ,...,w2n+2- Die Schritte 7-1 1 beschreiben nun den präzisen Signaturvorgang.
Bei der Durchführung einer Authentisierung wird das folgende Protokoll durchgeführt:
Figure imgf000016_0001
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 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 Ci , cn 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 cl 5 cn 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 , cn des Dokuments im Zuge der Modifikation reandomisiert werden, wobei zumindest die in der Übereinkunft vereinbarten verschlüsselten Datenfelder c 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 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 , cn' 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 , ... , Cn
Signatur σ
Modifikationsvorschrift m
Zertifikat z
modifiziertes Dokument Dok'
Datenfelder des modifizierten Dokuments Ci , Cn entschlüsselte Datenfelder an *
Reencryption-Schlüssel rku^s öffentlicher Schlüssel pku, pks, pkCA privater Schlüssel sku, sks, skCA abgeleiteter privater Schlüssel sku'
Zertifizierungsstelle CA
Klartext-Datenfelder a-i , an

Claims

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 (cl 5 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 (cl 5 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 (cl 5 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 (c , 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 (c , 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 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. 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 (rku^s) erstellt und dem Authentisierungsserver (A) zur Verfügung gestellt wird,
- wobei mit dem Reencryption-Schlüssel (rku^s) Datenfelder (cl 5 cn) des Dokuments (Dok), die mit dem öffentlichen Schlüssel (pku) 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. 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 (c cn) modifiziert werden, die in den verschlüsselten Datenfeldern (c 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. 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 (c , cn') des modifizierten Dokuments (Dok') herangezogen wird.
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 (Ci , cn) modifiziert werden, die in den verschlüsselten Datenfeldern (Ci , 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. 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 (a 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 (c 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. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass die Zertifizierungsstelle (CA) vor der Erstellung der Signatur (σ) für eine Anzahl der verschlüsselten Datenfelder (Ci , 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 (ai , an) ergeben.
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. 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 (Ci , cn) sowie eine Signatur (σ) umfasst, die von den verschlüsselten Datenfeldern (Ci , 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 (c 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 (c 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/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 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 (c , 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 (c , cn') des modifizierten Dokuments (Dok') zu entschlüsseln.
10. System nach Anspruch 9, dadurch gekennzeichnet,
- dass der Client (U) und das Service (S) über private und öffentliche Schlüssel (sku, sks, pku, 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 (sku) des Clients (U) einen Reencryption-Schlüssel (rku^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 (rku^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 (rku^s) korrekt durchgeführt wurde, und
- dass das Service (S) dazu ausgebildet ist, die Datenfelder (c , cn') des modifizierten Dokuments (Dok') mit seinem privaten Schlüssel (sks) zu entschlüsseln.
1 1 . 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 (Ci , cn) modifiziert werden, die in den verschlüsselten Datenfeldern (Ci , 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. System nach Anspruch 9, dadurch gekennzeichnet,
- 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 (cl 5 cn) und/oder die Signatur (σ) gegenüber dem Dokument (Dok) derart modifiziert sind, dass die im betreffenden Datenfeld (c , cn') des modifizierten Dokuments (Dok') enthaltene Information für das Service (S) nicht rekonstruierbar ist,
- dass der Client (U) dazu ausgebildet ist, aus dem privaten Schlüssel (sku) einen abgeleiteten privaten Schlüssel (sku') 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 (sku'), 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 (c , cn') des modifizierten Dokuments (Dok') heranzuziehen.
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 (cl 5 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.
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 (cl 5 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. 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. 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 (Dok') zu überprüfen und im Falle einer positiven Überprüfung dem Client (U) Zugriff entsprechend der Zugriffsanfrage zu gewähren.
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.
PCT/AT2017/060293 2016-11-09 2017-11-06 Verfahren zum austausch von datenfeldern von zertifizierten dokumenten WO2018085870A1 (de)

Applications Claiming Priority (2)

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

Publications (1)

Publication Number Publication Date
WO2018085870A1 true WO2018085870A1 (de) 2018-05-17

Family

ID=60381971

Family Applications (1)

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

Country Status (2)

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

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112597118A (zh) * 2021-01-04 2021-04-02 杭州海量存储技术有限公司 一种共享文件的添加方法及装置
CN113452705A (zh) * 2021-06-28 2021-09-28 长春吉大正元信息技术股份有限公司 一种加密通信方法、装置、电子设备和存储介质
CN116132069A (zh) * 2023-04-10 2023-05-16 江苏省国信数字科技有限公司 一种实现多ca数字证书和多电子签章互联互通的方法

Families Citing this family (1)

* 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

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9015469B2 (en) * 2011-07-28 2015-04-21 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
US9565180B2 (en) * 2012-09-28 2017-02-07 Symantec Corporation Exchange of digital certificates in a client-proxy-server network configuration

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "Opportunities and Challenges of CREDENTIAL - Towards a Metadata-Privacy Respecting Identity Provider | Credential", 13 December 2016 (2016-12-13), XP055438725, Retrieved from the Internet <URL:https://credential.eu/publications/opportunities-and-challenges-of-credential-towards-a-metadata-privacy-respecting-identity-provider/> [retrieved on 20180108] *
FARZANEH KAREGAR ET AL: "Opportunities and Challenges of CREDENTIAL", PRIVACY AND IDENTITY MANAGEMENT. FACING UP TO NEXT STEPS. PRIVACY AND IDENTITY 2016, 26 August 2016 (2016-08-26), pages 76, XP055438597 *
HORANDNER FELIX ET AL: "CREDENTIAL: A Framework for Privacy-Preserving Cloud-Based Data Sharing", 2016 11TH INTERNATIONAL CONFERENCE ON AVAILABILITY, RELIABILITY AND SECURITY (ARES), IEEE, 31 August 2016 (2016-08-31), pages 742 - 749, XP033023133, DOI: 10.1109/ARES.2016.79 *
SABOURI AHMAD: "A Cloud-Based Model to Facilitate Mobility of Privacy-Preserving Attribute-Based Credential Users", 2015 IEEE TRUSTCOM/BIGDATASE/ISPA, IEEE, vol. 1, 20 August 2015 (2015-08-20), pages 958 - 965, XP032819726, DOI: 10.1109/TRUSTCOM.2015.470 *
ZWATTENDORFER BERND ET AL: "The Austrian eID ecosystem in the public cloud: How to obtain privacy while preserving practicality", JOURNAL OF INFORMATION SECURITY AND APPLICATIONS, vol. 27, 31 May 2016 (2016-05-31), pages 35 - 53, XP029529406, ISSN: 2214-2126, DOI: 10.1016/J.JISA.2015.11.004 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112597118A (zh) * 2021-01-04 2021-04-02 杭州海量存储技术有限公司 一种共享文件的添加方法及装置
CN112597118B (zh) * 2021-01-04 2024-03-29 杭州海量存储技术有限公司 一种共享文件的添加方法及装置
CN113452705A (zh) * 2021-06-28 2021-09-28 长春吉大正元信息技术股份有限公司 一种加密通信方法、装置、电子设备和存储介质
CN113452705B (zh) * 2021-06-28 2023-02-21 长春吉大正元信息技术股份有限公司 一种加密通信方法、装置、电子设备和存储介质
CN116132069A (zh) * 2023-04-10 2023-05-16 江苏省国信数字科技有限公司 一种实现多ca数字证书和多电子签章互联互通的方法

Also Published As

Publication number Publication date
AT519025A4 (de) 2018-03-15
AT519025B1 (de) 2018-03-15

Similar Documents

Publication Publication Date Title
DE112011100182B4 (de) Datensicherheitsvorrichtung, Rechenprogramm, Endgerät und System für Transaktionsprüfung
DE60029722T2 (de) Verfahren und vorrichtungen zur sicheren verteilung von öffentlichen und privaten schlüsselpaaren
EP3033855B1 (de) Unterstützung einer entschlüsselung von verschlüsselten daten
DE602004005219T2 (de) Verfahren und einrichtung zur sicherung der inhaltsablieferung über ein kommunikationsnetz über inhaltsschlüssel
EP3031226B1 (de) Unterstützung der nutzung eines geheimen schlüssels
EP2975570A1 (de) Verfahren und eine Vorrichtung zur Absicherung von Zugriffen auf Wallets in denen Kryptowährungen abgelegt sind
DE102009001719B4 (de) Verfahren zur Erzeugung von asymmetrischen kryptografischen Schlüsselpaaren
DE102015202308A1 (de) Computerimplementiertes Verfahren zur Zugriffskontrolle
AT519025B1 (de) Verfahren zum Austausch von Datenfeldern von zertifizierten Dokumenten
DE102009001718A1 (de) Verfahren zur Bereitstellung von kryptografischen Schlüsselpaaren
DE112012000358B4 (de) Unternehmensübergreifender Datenaustausch
DE102017223898A1 (de) Sicheres Ablegen und Zugreifen von Dateien mit einer Webanwendung
DE102009017221A1 (de) Information-Rights-Management
DE19622630C1 (de) Verfahren zum gruppenbasierten kryptographischen Schlüsselmanagement zwischen einer ersten Computereinheit und Gruppencomputereinheiten
DE602005003631T2 (de) Ausschluss der Passwortaufdeckung bei Attributzertifikatausgabe
EP3182318A1 (de) Signaturgenerierung durch ein sicherheitstoken
EP2098039A1 (de) Verfahren zum transferieren von verschlüsselten nachrichten
EP3248324B1 (de) Verteiltes bearbeiten eines produkts auf grund von zentral verschlüsselt gespeicherten daten
EP3629516A1 (de) Dezentralisierte identitätsmanagement-lösung
EP2491513B1 (de) Verfahren und system zum bereitstellen von edrm-geschützten datenobjekten
DE102013019487A1 (de) Verfahren, Vorrichtungen und System zur Online-Datensicherung
DE112007000419B4 (de) Digitale-Rechte-Managementsystem mit diversifiziertem Inhaltsschutzprozess
DE102022000857B3 (de) Verfahren zur sicheren Identifizierung einer Person durch eine Verifikationsinstanz
EP4270863B1 (de) Sichere wiederherstellung privater schlüssel
DE102010021655A1 (de) Verfahren zum Bereitstellen von EDRM (Enterprise Digital Rights Management) geschützten Datenobjekten

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17800364

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17800364

Country of ref document: EP

Kind code of ref document: A1