AT519025A4 - Procedure for exchanging data fields of certified documents - Google Patents

Abstract

The invention relates to a method for exchanging data fields of certified documents between a client (U) and a service (S) via an authentication server (A), wherein the client (U) has a document (Doc) containing a number of encrypted data fields (c1, ..., cn) and a signature (σ), - wherein the document (Dok) is transmitted from the client (U) to the authentication server (A), - wherein the client (U) the authentication server ( A) communicates a modification rule (m) indicating which of the data fields (c1, ..., cn) of the document (doc) may not be transmitted from the authentication server (A) to the service (S), - the authentication server (A) a modified document (Dok ') is created, in which the given data fields (c1, ..., cn) or the signature (σ) are modified, - that a certificate (z) is added to the modified document (doc'), that the modified document (doc ') including the certificate s (z) is transmitted from the authentication server (A) to the service (S), - that the service (S) checks the modified document (Dok ') on the basis of the certificate (z) as to whether the data fields (c1', .. ., cn ') of the modified document (Dok') were created on the basis of a document (Doc) with a valid signature (σ) and the modification mentioned in step e) corresponds to the modification instruction (m), i) that the service (S) has key material that allows the service (S) to decrypt the data fields (c1 ', ..., cn').

Description

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.

Different approaches are known from the prior art, with which it is possible to prove individual access permissions for different services on the Internet at different locations.

In particular, it is known from the prior art to store individual passwords or access information, which a user requires for access to a service, on a local data carrier. If the same user is to contact the service from a client computer, the documents thus stored on the data carrier or the information contained in the data fields of the documents, such as e.g. Activation codes are transmitted from the data carrier via the respective client computer to the service. In this case, however, there is the problem that all data on each currently used client computer are available in plain text, which in turn has the disadvantage that when using an insecure client computer, there is a risk that the documents are unauthorized Can be read out to third parties.

In addition, it is known to store information enabling access to individual services on an Internet-based authentication server, wherein the individual data fields of the documents that are normally exchanged between client and service are stored in clear text on the authentication server. With this procedure, it is possible to use the documents from different clients, whereby the client concerned does not need to know anything about the documents since these are transmitted by the authentication server to the relevant service. However, this has the considerable disadvantage that the authentication server receives all the data fields of the user's documents in plain text.

The methods mentioned in the prior art have the particular problem that a client computer or the authentication server has sensitive data in plain text and therefore can receive a variety of personal information about the user.

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.

With this method, it is advantageously possible to store all the access information that a user requires for various services located on the Internet in order to store them on an authentication server, which itself is not informed of the access information concerned. In addition, no information about the exchanged data fields is transmitted to the specifically used client.

An advantageous procedure to avoid that plain text data the

Authentication server, provides that - the client and the service have private and public keys, - that creates a Reencryption key based on a private and / or public key of the service and based on the private key of the client and the authentication server is provided with the Reencryption key data fields of the document, which were encrypted with the public key of the client, are decrypted so that they can be decrypted with the private key of the service, - that before the creation of the certificate in step f) the individual data fields of the modified document agreed upon in the agreement between the client and the service are re-encrypted by means of the reencryption key, that the certificate additionally contains information indicating that the re-encryption is based on that of the client and Service specified key Reencryption key was performed correctly, and - that in step j) the private key of the service is used for decryption.

In order to avoid traceability or linkability of the client on the basis of the transmitted encrypted data fields, provision can be made for - a re-randomization of the document before the transcoding, in which the encrypted data fields agreed in the agreement are modified, which are contained in the encrypted data fields However, that information remains unchanged, and that the certificate additionally contains information indicating that the rerandomization was performed correctly.

An alternative way of avoiding the disclosure of plain text data to the authentication server is to: - that the client has a private and a public key, - that the client creates a derived private key from the private key, - that in the agreement agreed data fields of the document are encrypted such that they can be decrypted with the derived private key, - that the derived private key is transmitted to the service, - that in step e) at least the signature of the document is modified, and - that the derived private Key used to decrypt the data fields of the modified document.

In order to avoid traceability or linkability of the client on the basis of the transmitted encrypted data fields, it can be provided that in the course of the modification a re-randomization is carried out in which the encrypted data fields agreed in the agreement are modified, the information contained in the encrypted data fields however, remain unchanged, and - that the certificate additionally contains information indicating that the re-randomization was performed correctly.

In particular, to create a document, it can be provided that the client has a private and a public key, that the document is created by encrypting a number of clear-text data fields with the client's public key, that a certification authority uses a Creates a signature that depends on the encrypted data fields and their own private key, and that - in step h) the public key of the certification authority is used to check the validity of the certificate.

In order to enable the certification authority to check individual data fields before the signature is assigned, it can be provided that 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.

In particular, access to the service in question provides that - the client makes an access request to the service after step d), - that the service requests the authentication server to transmit the modified document and the modified document corresponding to the steps in step h) , verifies, and - that the service verifies the required authority of the client based on the decrypted data fields, the certificate and the modified document, and optionally grants access to the client according to the access request.

Furthermore, the invention solves this problem in a system of the type mentioned above with the features of claim 9.

Several embodiments of the invention will now be described in detail:

Fig. 1 shows schematically the procedure in a first embodiment of the invention. In this embodiment, 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.

Typically, the procedure according to the invention is used 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. If a client U wants to receive access to the service S, the service S in turn requests the authentication server A to transmit the data required for the authentication 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 entitle the client to access the service, the service S allows the client U access according to the access request.

For authentication, a document Dok is created which has a number of encrypted data fields Ci, cn, wherein the encrypted data fields Ci, ..., cn after decryption allow the service to release the data requested by the client. The encryption of the relevant data fields Ci,..., Cn of the document Dok can be carried out either by the relevant client U or by a certification authority CA. Subsequently, 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 subsequently be checked whether the certification authority CA has actually certified or signed the encrypted data fields Ci,..., Cn of the document Dok and whether this signature .sigma. Is made up of the encrypted data fields c..., Cndes document Doc results. Before the signature is created, the certification authority CA checks whether the signature actually results by encryption from the plaintext data fields agreed upon or specified between the client and the certification authority.

If, for example, 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, then in a particularly simple embodiment of the invention the document in question Dok are created directly by the CA CA. In this case, the certification authority CA encrypts the individual plaintext data fields ai, ..., of the document doc with its own predefined key and, based on the encrypted data fields Ci,..., Creates a signature s. When creating this signature, advantageously, a private key skCA of the certification authority CA is used, wherein a public key pkCA is generally disclosed for external verification of the validity of the signature by the certification authority CA.

In addition, there is also the possibility that the encryption of the individual data fields c ^ ..., cn of the document Dok is made by the user or the client U itself, the CA is given the opportunity to check whether the encrypted data fields c ... of the document Dok by encryption from the agreed between the client U and the CA CA clear text data fields a ^ ..., an. For example, the client of a certification authority CA, which is authorized to issue identity cards, encrypt his personal data "first name", "last name", "date of birth" in a manner prescribed by him and prove to the certification authority CA that the encrypted data fields C!, ..., of the document Dok by encrypting the plain text data fields to be confirmed by the CA CA. The CA verifies this and provides the document Dok with a corresponding signature σ.

Particularly advantageously, 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 a 1,..., An are respectively encrypted independently of one another, with the possibility that individual of the resulting encrypted data fields c 1..., Cn are encrypted according to different encryption methods and / or with different keys and encrypted Document doc are included. The signature σ issued by the certification authority CA is based on the encrypted data fields c 1..., Cn of the document doc 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 Ci, ..., cndes document Dok has expired correctly.

In a preferred embodiment of the invention, there is also the possibility that 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.

For this purpose, the client U can create as desired a document Dok, which is an encrypted data field C! contains, which was created at random and whose data field size is so large that it can be excluded that a data field C! of the 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 c ^ whose content has been specified 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 Ci created by the client U with regard to the usability for a single viewing of a movie at the respective service S.

As shown in FIG. 1, the client U has one or more documents Doc after it has been created by the certification authority CA. The or each document Dok has a number of encrypted data fields Ci, cn and a signature which is derived from the encrypted data fields Ci , ..., cn is dependent. With the knowledge of the relevant certification authority CA, the signature σ can be checked to see whether the encrypted data fields Ci,..., Cn actually originate from the certification authority CA or originate from it.

In order to keep the document or documents Dok available for a plurality of different services S, they are transmitted by the client U on the authentication server A. The authentication server A allows a configuration to the effect that this individual services S allows the query of different data fields ..., cn of a document Dok deposited with him. In this case, a modification rule m is specified which prescribes to the authentication server A which of the encrypted data fields Ci,..., Cn 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 in which it is determined which data fields Ci, ..., cn readable for the service are to be contained in a document doc 'to be transmitted to the service. Thus, for example, the client U the authentication server A deposit a document Doc, in which are stored as data fields Ci, ..., cn 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 communicates the encrypted data field c3, which contains the date of birth, 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 d3 of the document doc may be transmitted from the authentication server A to the service S while the data fields c1; c2 of the document doc from the authentication server A may not be transmitted to the service S.

In the first exemplary embodiment of the invention presented below, the client U and the service S have private and public keys sky, sks or pky, pks and the public key of the certification authority pkCA · based on a private and / or public key of the service as well Based on the private key of the client, a reencryption key rku ^ s is created and passed to the authentication server A. With this reencryption key rku ^ s, data fields Ci, cn 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 sks 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.

As part 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 Ci', ..., cn ', which are assigned to the modified document Dok'. Those data fields c1; c2, which may not be transmitted to service S due to the modification rule m, are deleted or overwritten with random numbers.

Before re-encrypting, a re-randomization of the document may be performed, in which the encrypted data fields agreed upon in the agreement between the client 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 attached a certificate z, with which it is comprehensible for the service S that the data fields Ci', ..., cn '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 c1; ..., cn and deleting or overwriting the data fields c1 not to be transmitted; c2 corresponds. The certificate z additionally contains information indicating that the re-encryption was performed correctly with the reencryption key rku ^ s created on the basis of the client U and service S keys.

If a re-randomization is carried out before the re-encryption, the certificate z is in addition to the correctness of the transcoding still added information with which it can be understood that the Rerandomisierung was performed correctly.

Even if the certificate z makes it possible to check the correctness of the steps taken, the service S, as the recipient of the certificate z, does not obtain any knowledge about the individual plaintext data fields underlying the certificate z or the keys or reencryption keys used in the encryption. Based on certificate z, it is possible to demonstrate for S without knowledge of the relevant non-public key that all modification requirements were complied with during the preparation and modification of the document. That such evidence is possible is from 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 known theoretically. Practical concrete protocols are a standard part of modern cryptographic protocols and are very often based on C.-P. Schnorr. "Efficient Signature Generation by Smart Cards". In the Journal of Cryptology, vol. 4 (3), pp. 161-174, Springer Verlag, 1991. A detailed guide to the realization of such protocols can be found, for example, 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. In particular, it is possible with such methods to check the correctness of the execution of several successive steps, without it being necessary for the checking service S to have knowledge about all the intermediate steps that have been taken. These individual steps are, for example: the validity of the procedure for creating the signature of the document, the re-encryption by the authentication server, the overwriting of the encrypted data fields which are not to be forwarded, the re-randomization of the encrypted data fields to be passed on,

Will the service S, for example, at the request of the client U, to check whether certain data c3 correspond to predetermined criteria, so it provides the authentication server A a request for transmission of the modified document Dok '. 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 doc' on the basis of the certificate z as to whether the data fields Ci ', ..., cn' of the modified document doc 'were created on the basis of a document Dok valid signature σ and the aforementioned modification of the modification rule m corresponds, ie whether the re-encryption and, if necessary, re-randomization has been carried out correctly.

When checking the validity of the certificate, the public key pku of the certification authority CA is used to check the validity of the certificate z.

The following is a semi-abstract description of the signature and authentication process. For the sake of concretization, the underlying proxy re-encryption method is based on the method described by Blaze et al. (see above), but left the signature method used by the certification authority CA arbitrary.

In this case, the following protocol describes the signature process:

In this case, 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 pkCA, as well as the own public and private key pku, sku. The CA has the specified input values, whereby pkCA, skCA, unlike user U, designate their own private and public keys. The plain text data fields a, are encrypted in c. 3-4 to c, and transferred to the CA in line 5. In line 6, the user proves with the help 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, (n), e D. In line 7, 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.

In order to perform an authentication of the user, 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 rky ^ s which allows to rewrite key texts from the user's public key to those of the service, where the public and private keys of the service are denoted by pks and sks. The service receives the corresponding specified input values.

In steps 1-2, the authentication server A rerandomisiert the key texts of the user. In 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. In step 7, A now proves by means of zero-knowledge proof that the re-indirection and the re-encryption were correctly performed, the undefended data fields were correctly blackened, that only correct key material was used and that a signature is known on the original encrypted data fields of CA. which consists of the signature verification test Ver of the selected signature method (the values to be proved would be concretely substantiated as follows: (σ, (f,), eD, (v ,, w,), $ D, rku ^ s, e) The totality of the values sent in step 7 forms the certificate z. In the case that this certificate is correct, the service S decrypts the corresponding key texts in step 8 using its own secret key sks by means of the decryption algorithm Dec of Blaze et al. Encryption method, and receives the plaintext data fields.

A concrete instantiation of the signature procedure with the method of Abe et al. (M. Abe and J. Groth and K. Haralambiev and M. Ohkubo. "Optimal Structure-Preserving Signatures in Asymmetry Bilinear Groups." In P. Rogaway (ed.), CRYPTO 2011, LNCS vol 6841, pp. 649-666 , Springer Verlag, 2011.) provides the following concrete signature protocol:

The public key of the certification authority pkCA consists in this specific case of G, H, W1, ..., W2n + 2! the algebraic setting is described in the original publication. The private key of the certification authority (CA) skCA consists of r, v, Wi, ..., w2n + 2. Steps 7-11 now describe the precise signature process.

When performing an authentication, the following protocol is performed:

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 referential literature. Concretely, the values to be proved would be given as follows: ((i, 6 ', x) t {fiJii, rliu -> s / i - bi ~ bfi) i ± Di {Vi, rku ^ sc, 6, b' ~ 6e \ rku ... ss> e).

After it has been ensured that the relevant modified document doc 'has reached the service S on the basis of a correct treatment or modification in accordance with the modification rule m, the service can decrypt the individual data fields d3 made available to it. For this purpose, the service S has corresponding key material which enables it to decrypt the data fields d3 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 sks, with which it is possible for him to decrypt the data contained in the modified document doc 'data fields d3. The service decrypts the relevant data fields d3 of the modified document doc 'and thus creates decrypted data

Data fields a3 * which are available for further processing. In particular, in the present embodiment, it is merely checked whether the date of birth contained in the document in question is more than 18 years before the current time, i. whether the user in question is older than 18 years of age and is therefore entitled to receive the Service S service concerned.

In the following, a second preferred embodiment of the invention is shown in more detail (FIG. 2), which does not encode the data fields c1; ..., cn of the document Doc does, but uses derived private keys sku 'of the client. 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 sky and a public key pky. The client U creates a derived private key sky 'from the private key sky, whereby the data fields Ci,..., Cn of the document Dok agreed upon in the agreement are encrypted in such a way that they are encrypted not only with the private key sky but also with the private key derived private key sky 'are decipherable. However, all other data fields of the document Dok can not be decrypted with the derived private key sky. The derived private key sky "is transmitted to the service S. At the request of the service, 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. Likewise, the remaining data fields Ci, ..., cndes document reandomisiert in the course of the modification, wherein at least the agreed in the agreement encrypted data fields Ci, ..., cn are modified, but the information contained in the encrypted data fields remain unchanged. In addition, the z certificate is appended with information indicating that the rerandomization was performed correctly.

The examination of the modified document Dok 'by the service S on the basis of the certificate z takes place as well as in the first embodiment of the invention, wherein in particular the correctness of the re-randomization can be checked on the basis of the certificate. As with the first embodiment of the invention, this can be done concretely without knowledge of the data underlying the Rerandomisierung.

Unlike the first embodiment of the invention, the service S has a derived private key sky 'of the private key sky of the client C. The transfer of the derived private key sku' can be done 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 transmits the derived private key sku' to the service S on request. In both cases, the service S has sufficient key material, namely the derived private key sku ', which enables it to decrypt the data fields Ci', ..., cn 'of the modified document Dok' specified in the agreement.

Bezuaszeichenliste:

Claims (17)

claims: A method of exchanging data fields of certified documents between a client (U) and a service (S) via an authentication server (A), a) wherein the client (U) has a document (Doc) containing a number of encrypted ones Data fields (ci, cn) and a signature (σ), which depends on the encrypted data fields (ci, ..., cn), b) wherein the document (Dok) from the client (U) to the authentication server (A) c) the client (U) notifies the authentication server (A) of a modification rule (m) indicating which of the data fields (ci, ..., cn) of the document (Doc) from the authentication server (A) to the service (S) may not be transmitted, d) wherein the client (U) and the service (S), in accordance with the modification rule (m), make an agreement specifying which data fields (c1; .., cn) in a from the server to the service (S) to be transmitted modifizie e) that the authentication server (A) based on the document (Dok) creates a modified document (Dok '), wherein the specified in the modification rule (m) data fields (ci , ..., cn) and / or the signature (σ) relative to the document (doc) are modified such that the information contained in the relevant data field (ci ', cn') of the modified document (doc ') ( S) is not reconstructable, f) that the certificate (z) is added to the modified document (doc '), with which it is comprehensible for the service (S) that the data fields (ci \ cn') of the modified document (doc. ) were created on the basis of a document (Doc) with a valid signature (S) and the modification referred to in step e) corresponds to the modification rule (m), g) that the modified document (Dok ') including the certificate (z) from the authentication server ( A) to the service (S) transfer h) that the service (S) checks the modified document (Dok ') on the basis of the certificate (z) as to whether the data fields (cV, cn') of the modified document (doc ') are based on a document (Doc) i) that the service (S) has key material, in particular that key material is transmitted to the service (S), that it has been assigned to the service (S) with the valid signature (σ) and the modification mentioned in step e) corresponds to the modification rule (m) Service (S) allows to decrypt the data fields (c ^, cn ') of the modified document (doc') specified in the agreement, j) that the service (S) stores the data fields (ci \ cn ') of the modified document (doc ') and k) that the service (S) keeps the data fields (ai *, ..., an *) thus decrypted for further processing. 2. Method according to claim 1, characterized in that - the client (U) and the service (S) have private and public keys (sku, sks, pku, pks), - that based on a private and / or public key (sks, pks) of the service (S) and on the basis of the private key (sku) of the client (U) a reencryption key (rky ^ s) created and the authentication server (A) is provided, - where with the Reencryption Key (rky ^ s) data fields (c1; ..., cn) of the document (Dok) encrypted with the public key (pky) of the client (U) are re-encrypted so that they are encrypted with the private key ( sks) of the service (S) are decryptable, - that prior to the creation of the certificate (z) in step f), the individual data fields agreed in the agreement between the client (U) and the service (S) (Ci ', ... , cn ') of the modified document (doc') by means of the reencryption key (rku ^ s) In addition, the certificate (z) contains additional information indicating that the re-encryption was carried out correctly using the reencryption key (rku ^ s) created on the basis of the keys specified by the client (U) and service (S) , and - that in step j) the private key (sks) of the service (S) is used for decryption. A method according to claim 2, characterized in that before re-encrypting a re-randomization of the document (Doc) is carried out, in which the encrypted data fields (c1; ..., cn) agreed upon in the convention are modified, which in the encrypted However, that information contained in the certificate (z) in addition to information indicating that the Rerandomisierung was performed correctly. 4. The method according to claim 1, characterized in that - the client (U) has a private and a public key (sku, pku), - that the client (U) from the private key (sku) a derived private key ( sku '), - that the data fields (Ci, ..., cn) of the document (Doc) agreed in the agreement are encrypted in such a way that they can be decrypted with the derived private key (sku'), - that the derived private Key (sku ') is transmitted to the service (S), - that in step e) at least the signature (σ) of the document (doc) is modified, and - that the derived private key (sku') for decrypting the data fields ( cA ..., cn ') of the modified document (Doc'). 5. The method according to claim 4, characterized in that - in the course of the modification, a rerandomization is carried out in which the agreed upon in the agreement encrypted data fields (c1; ..., cn) are modified in the encrypted data fields (c1; ..., cn) remain unchanged, and - that in the certificate (z) additional information is included, indicating that the Rerandomisierung was performed correctly. Method according to one of the preceding claims, characterized in that - the client (U) has a private and a public key (sku, pku), - that the document (doc) is created by a number of plain text data fields (ai, ..., an) are encrypted with the public key (pku) of the client (U), - that a certification authority (CA) creates a signature (σ) that can be used by the encrypted data fields (Ci, ..., cn) and is dependent on its own private key (skCA), and - that in step h) the public key (pkCA) of the certification authority (CA) is used to check the validity of the certificate (z). 7. The method according to claim 6, characterized in that before the creation of the signature (σ) for a number of the encrypted data fields (c1; ..., cn) of the document (doc) the certification authority (CA) checks whether they pass through Encryption from specified or agreed between the client (U) and certification authority (CA) plain text data fields (a1, ..., an). 8. The method according to any one of the preceding claims, characterized in that - the client (U) to the service (S) after step d) an access request, - that the service (S) the authentication server (A) for transmitting the modified document (Dok ') and checks the modified document (Dok') according to the steps in step h), and - that the service (S) the required authorization of the client (U) from the decrypted data fields (a /,. .., to *), the certificate (z) and the modified document (doc ') checks and, where appropriate, the client (U) granted the access according to the access request. A system for exchanging data fields (c ^ ..., cn) and certified documents comprising a client (U), a server running a service (S) and an authentication server (A), a) the client (U) has a document (Dok) comprising a number of encrypted data fields (c1; ..., cn) and a signature (σ) dependent on the encrypted data fields (c1; ..., cn) , b) wherein the client (U) is adapted to transmit the document (Dok) to the authentication server (A) and the authentication server (A) is adapted to receive and store the document (Dok) from the client (U) , c) wherein the client (U) is adapted to notify the authentication server (A) of a modification rule (m) indicating which of the data fields (Ci, ..., cn) of the document (Doc) from the authentication server (A) to the service (S) may not be transmitted and the authentication server (A) is adapted to Modification rule (m) to be stored, d) wherein an agreement of the modification (m) agreement between the client (U) and service (S) is specified, indicating which of the service (S) readable data fields (Ci, ..., cn ) should be contained in a modified document (Dok ') to be transmitted by the server to the service (S), characterized in that e) the authentication server (A) is designed to implement a modified document (Doc ') in which the data fields (ci,..., cn) specified in the modification instruction (m) and / or the signature (σ) are modified relative to the document (Doc) such that the data fields (Ci1, ..., cn ') of the modified document (Dok') contained information for the service (S) is not reconstructable, f) that the authentication server (A) is adapted to the modified document (Dok ') a certificate (z) add to the service (s) it can be understood that the data fields (ci ', ..., cn') of the modified document (doc ') were created on the basis of the document (doc) with a valid signature (σ) and the modification of the modification rule made by the authentication server (A) (m), g) that the authentication server (A) is adapted to transmit the modified document (Dok ') including the certificate (z), in particular on request, to the service (S), h) that the service ( S) is adapted to check the modified document (Dok ') on the basis of the certificate (z) as to whether the data fields (ci', cn ') of the modified document (doc') are based on a document (doc) with a valid signature (σ) were created and the modified by the authentication server (A) modification of the modification (m) corresponds, i) that the service (S) has key material, in particular that it is designed, key material of the Authentisierungsse rver (A), the key material allowing the service (S) to decrypt the data fields (c /, ..., cn ') of the modified document (doc') specified in the agreement, j) the service ( S) is adapted to decrypt the data fields (cV, ..., cn ') of the modified document (Dok'). 10. System according to claim 9, characterized in that - the client (U) and the service (S) have private and public keys (sky, sks, pky, pks), - that the user (U) is trained to based on a private and / or public key (sks, pks) of the service (S) and based on the private key (sky) of the client (U) to create a reencryption key (rky ^ s) and the authentication server (A ), that the authentication server (A) is adapted to use the reencryption key (rky ^ s) data fields (Ci, ..., cn) of the document (Dok) associated with the public key (pku ) of the client (U) have been encrypted so that they can be decrypted with the private key (sks) of the service (S), - that the authentication server (A) is adapted to add information to the certificate (z) indicating that the re-encryption with the on the basis of the Cli ent (U) and service (S) specified key reencryption key (rky ^ s) was performed correctly, and - that the service (S) is adapted to the data fields (cV, ..., cn ') of the modified Document (Dok ') with his private key (sks). 11. System according to claim 10, characterized in that - the authentication server (A) is adapted to re-randomize the document (Doc) before the re-encryption, in which the encrypted data fields (c ^ ..., cn ), the information contained in the encrypted data fields (c ^ ..., cn) remain unchanged, and - that the authentication server (A) is adapted to add additional information to the certificate (z) indicating that the Rerandomisierung was carried out correctly. 12. The system according to claim 9, characterized in that - the authentication server (A) is adapted to create based on the document (Dok) a modified document (Dok1), in which the specified in the modification rule (m) data fields (Ci , ..., cn) and / or the signature (o) are modified relative to the document (Doc) such that the information contained in the relevant data field (Ci ', ..., cn') of the modified document (Doc1) for the Service (S) is not reconstructable, - that the client (U) is adapted to create from the private key (sky) a derived private key (sky '), - that the client (U) is adapted to the in the agreement agreed to encrypt data fields (Ci, ..., cn) of the document (Doc) such that they are decipherable with the derived private key (sku '), - that the client (U) is adapted to the derived private Key (sky '), especially mitt elbar by a transmission encrypted under a public key (pks) of the server (S) to the authentication server (A), which makes this encryption of the private key (sku ') available to the service (S) for retrieval, to the service (S ) - that the authentication server (A) is designed to modify at least the signature (σ) of the document (Doc) during the creation of the modified document (Dok '), and - that the service (S) is designed to do so is to use the derived private key (sku ') for decrypting the data fields (Ci', ..., cn ') of the modified document (Dok'). 13. System according to claim 12, characterized in that - the authentication server (A) is adapted to perform a re-randomization of the document (Doc) before the transcoding, in which the encrypted data fields agreed in the agreement (c1; ..., cn ), the information contained in the encrypted data fields (c1; ..., cn) remains unchanged, and - that the authentication server (A) is adapted to add to the certificate (z) additional information indicating that the Rerandomisierung was carried out correctly. 14. System according to any one of claims 9 to 13, characterized in that - the client (U) has a public and a private key (pks, sks), - that the client (U) is adapted to a number of plain text Encrypt data fields (ai, ..., an) with their public key (pku) and thus create a document (doc) and transfer the document (doc) to a certification authority (CA), - that a certification authority (CA ), which is designed to create a signature (σ) which depends on the encrypted data fields (c1; ..., cn) and on a private key (skCA) associated with the certification authority (CA), and that the service (S) is adapted to query the public key (pkCA) of the certification authority (CA) to check whether the modified document (Dok '), with the correct application of the modification instruction (m), is based on a valid signature (σ ) the certification authority (CA). 15. System according to any one of claims 9 to 14, characterized in that the certification authority (CA) is adapted, before the creation of the signature (σ) for a number of encrypted data fields (Ci, ..., cn) of the document ( Doc) to check whether these result from encryption from predetermined or agreed between the client (U) and the certification authority (CA) plain text data fields (ai, ..., an). 16. System according to any one of claims 9 to 15, characterized in - that the client (U) is adapted to provide the service (S) an access request after transmission of the document to the authentication server (A), - that the service (S) is adapted to prompt the authentication server (A) to transmit the modified document (Dok ') and to verify the modified document (Dok') using the modification rule (m), and - that the service is adapted to the required one Authorization of the client (U) based on the decrypted data fields (a ^, ..., an *) of the certificate (z) and the modified document (doc1) to check and in case of a positive check the client (U) access according to the access request to grant. 17. Data carrier on which a program for carrying out a method in the client (U), service (S) or authentication server (A) according to one of claims 1 to 8 is stored.