Method for reading attributes from an id token

0001The invention relates to a method for reading attributes from an ID token, an ID token and a computer system.

0002Various methods for managing the so-called digital identity of a user are known from the prior art: Microsoft Windows CardSpace is a client-based digital identity system designed to allow Internet users to communicate their digital identity to online services. The disadvantage here is, inter alia, that the user can manipulate his digital identity.

0003OPENID, on the other hand, is a server-based system. A so-called identity server stores a database with the digital identities of the registered users. One disadvantage of this is, inter alia, inadequate data protection, since the digital identities of the users are stored centrally and the user behavior can be recorded.

0004Out <patcit id="pcit0001" dnum="US20070294431A1"><text>US 2007/0294431 A1</text></patcit> Another method for managing digital identities is known, which also requires user registration.

0005Out <patcit id="pcit0002" dnum="DE102008000067A1"><text>DE 10 2008 000 067 Al</text></patcit> For example, there is known a method of reading at least one attribute from an ID token from which the present invention proceeds as the closest prior art. Further developments of this method are in the patent applications<patcit id="pcit0003" dnum="DE102008040416"><text>DE 10 2008 040 416</text></patcit>. <patcit id="pcit0004" dnum="DE102008042262"><text>DE 10 2008 042 262</text></patcit>. <patcit id="pcit0005" dnum="DE102009026953"><text>DE 10 2009 026 953</text></patcit>. <patcit id="pcit0006" dnum="DE102009027723"><text>DE 10 2009 027 723</text></patcit>. <patcit id="pcit0007" dnum="DE102009027681"><text>DE 10 2009 027 681</text></patcit> and <patcit id="pcit0008" dnum="DE102010028133"><text>DE 10 2010 028133</text></patcit> disclosed.

0006Technical Guideline TR-03 110-2 "Advanced Security Mechanisms for Machine Readable Travel Documents and eIDAS Token - Part 2" describes the use of the electronic identity card. It shows a method for reading and updating attributes from an ID token (eIDAS), in which missing attributes are provided after mutual authentication by an attribute provider. The invention is based on the object to provide an improved method for reading attributes from an ID token a corresponding ID token, a corresponding attribute provider directory computer system, a corresponding attribute provider computer system, a corresponding user Computer system and computer system.

0007The objects underlying the invention are each achieved with the features of the independent claims. Embodiments of the invention are indicated in the dependent claims. Embodiments of the invention are freely combinable with each other unless they are mutually exclusive. An "ID token" is understood here in particular as a portable electronic device which has at least one protected electronic data memory for storing the attributes and a communication interface for reading out the attributes. The memory area is protected in order to prevent the attribute stored in the memory area from being altered in an unauthorized manner or read out without the authorization required for it.

0008In particular, the ID token can be a USB stick or a document, in particular a value or security document. According to the invention, a "document" is understood to mean paper-based and / or plastic-based documents, such as electronic identity documents, in particular passports, identity cards, visas and driving licenses, vehicle registration documents, vehicle documents, company ID cards, health cards or other ID documents as well as chip cards, payment means, in particular bank notes , Bank cards and credit cards, bills of lading or other credentials, in which a data memory for storing the at least one attribute is integrated.

0009The ID token can be a hardware token or a soft token if it is cryptographically bound to a hardware token, that is, for example, to a so-called secure element.

0010In particular, such a cryptographically bound to a secure element soft token according to <patcit id="pcit0009" dnum="DE102011082101"><text>DE 10 2011 082 101</text></patcit>, the disclosure content of which is fully incorporated into the disclosure of the present patent application.

0011An "ID provider module" is understood here to mean a program logic module which is designed to read attributes from the ID token of a user and to write an attribute specification in the ID token. The ID provider module can be designed, for example, as a software component but also as a computer system. The ID provider module can be designed, for example, as an ID provider computer system which is preferably operated in a so-called trust center in order to create the highest possible level of security. In some embodiments, the ID provider module and the service computer system belong to the same IT infrastructure, eg, to the same intranet of a company. It is even possible that the ID provider module is installed and running on the service computer system, in this case, the ID provider module and the service computer system, or the electronic service operated thereon, are in this case functionally different, interoperating modules. An ID provider module has eg specific credentials, eg certificates or cryptographic keys or the like, which allow the ID provider module access to certain selected memory areas of an ID token.

0012An "attribute provider computer system" or "AP computer system" is understood here as a computer system which is designed to provide attributes on applications. In particular, the provision can be made attribute-class-specific and / or specific for a specific user of an ID token. Preferably, an attribute provider computer system is adapted to read an attribute specification from the ID token of a user and to write attributes in the ID token.

0013As used herein, an "attribute provider directory computer system" or "APV computer system" is understood to mean a computer system that is configured to identify, for particular classes of attributes, one or more attribute provider computer systems that are capable of: Fully or at least partially provide attributes of these classes. According to some embodiments, in addition to the identity of the attribute provider computer systems, even further information such as a contact address, performance data, historical availability data regarding the respective attribute provider computer systems may be identified and communicated to the requesting system.

0014The attribute classes can be (arbitrarily) predefined groups of attributes. The classes can be disjoint or overlapping. Examples of different attribute classes are: address data of a user; medical data of a user; Bank details of a user; Information that provides information about the creditworthiness of a user; and other.

0015An "attribute" is understood in particular to mean data relating to the user of the ID token or the ID token itself, in particular personalization data, such as personal data of the user, a period of validity or the issuer of the ID token or payment information, such as credit card information or other data for an electronic payment system.

0016As used herein, an "attribute specification" is understood to mean a description of those attributes needed, for example, by a service computer system to provide a service. The attributes may be identified via field names of data fields in which the respective attribute values ​​are stored, and / or via a semantic network, ie, a convention of how attributes are referred to across systems.

0017A "service computer system" is understood here to mean a computer system which has a network interface for connection to the network, so that an internet browser or another application program can be used to access web pages stored or generated by the service computer system. In particular, the service computer system may be an internet server for providing an e-commerce or e-government application, in particular an online shop or a government server.

0018A "user computer system" is understood here as a computer system to which the user has access. This may be, for example, a personal computer (PC), a tablet PC or a mobile device, in particular a smartphone, with a conventional Internet browser, such as Microsoft Internet Explorer, Safari, Google Chrome, Firefox or any other application for access to act on the service computer system. The user computer system has an interface for connection to the network, wherein the network may be a private or public network, in particular the Internet. Depending on the embodiment, this connection can also be made via a mobile network.

0019A "reader" is understood here as an electronic device which allows read access and also write access to the ID token, in particular a so-called chip card terminal. The reader may form an integral part of the user computer system or be implemented as a separate component, for example as a peripheral device of the user computer system. In particular, the reader may be a so-called class 1, 2 or 3 chip card reader.

0020A "non-volatile electronic memory" is understood here as a memory for storing data, in particular attributes, which is also referred to as non-volatile memory (NVM). In particular, this may be an EEPROM, for example a flash EEPROM, referred to as flash for short.

0021A "protected memory area" is understood here as meaning an area of ​​an electronic memory to which access, that is to say a read access or a write access, is only made possible by a processor coupled to the memory if a condition required for this purpose is fulfilled. This may be, for example, a cryptographic condition, in particular a successful authentication and / or a successful authorization check.

0022A "processor" is here understood to mean a logic circuit which serves to execute program instructions. The logic circuit may be implemented on one or more discrete components, in particular on a chip.

0023A "certificate" here means a digital certificate, which is also referred to as a public-key certificate. A certificate is structured data that serves to associate a public key of an asymmetric cryptosystem with an identity, such as a person or device. Alternatively, certificates based on zero-knowledge cryptosystems are also possible. For example, the certificate may conform to the standard X.509 or another standard. For example, the certificate is a Card Verifiable Certificate (CVC).

0024The certificate may specify for which attribute or attributes of the user stored in the protected memory area of ​​the ID token the ID provider module or the attribute provider computer system is authorized to perform the read access. Furthermore, the respective write permissions for attribute specifications or attributes in a certificate can also be defined. Such a certificate is also called an authorization certificate. The authorization certificate can be designed as a CVC certificate (card verifiable certificate).

0025A "secure", "protected" or "secure" "transmission channel" is understood here as a transmission channel which is cryptographically secured in order to prevent spying and / or manipulation of the transmission, in which case a so-called secure messaging method is used can be.

0026The checking of read and write rights can be done, for example, attribute class specific. For example, each identified attribute class may be assigned an area, also called "sector", on the protected memory area of ​​the ID token. For example, the entitlement certificate may selectively authorize the AP computer system to write attributes of a particular attribute class to a particular attribute class specific sector of the memory area of ​​the ID token, whereas the attributes of another class may be stored in a different sector to which the AP computer system does not can access. In other embodiments, an AP computer system may not only write attributes to the sector of its attribute class,

0027For example, a protected transmission channel may be established between an ID token, eg, a chip, and a remote computer (eg, service computer system, attribute provider system) or a local computer (eg, user computer system), eg, by means of a PACE protocol. Protected connections between computer systems can be established eg by means of SSL / TLS. A "local" transmission channel is here understood to mean a transmission channel which is established between the ID token and the user computer system via the reading device, wherein in particular the connection between the ID token and the reading device can be contact-based or contactless, the latter in particular according to an NFC or RFID standard.

0028By end-to-end encryption is meant here an encryption of transmitted data across all transmission stations. The data to be transmitted is encrypted on the sender side and decrypted again at the receiver. Stations can not decrypt the transmitted content.

0029In one aspect, the invention relates to a method for reading attributes from an ID token associated with a user. The ID token has a nonvolatile electronic memory with a protected memory area. Access to the protected memory area is only possible via a processor of the ID token. The method comprises the following steps:<ul><li>Sending a service request of a user from a user computer system to a service computer system coupled to an ID provider module;</li><li>In response to receiving the service request, sending a first attribute specification from the service computer system to the ID provider module, wherein the first attribute specification specifies the attributes that the service computer system needs to provide the service requested with the service request, and reciprocal Authentication of the ID provider module and the ID token;</li><li>Upon successful mutual authentication of the ID provider module and the ID token, writing the first attribute specification to the protected memory area of ​​the ID token by the ID provider module and sending a first message that the first attribute specification was written, of the Service computer system to the user computer system;</li><li>In response to receiving the first message, sending a trigger signal from the user computer system to an APV computer system, the APV computer system being an attribute provider directory computer system, wherein the first trigger signal is free from the first attribute specification and their parts and an address of the ID token includes;</li><li>In response to receipt of the trigger signal, mutual authentication of the APV computer system and the ID token using the address;</li><li>Upon successful mutual authentication of the APV computer system and the ID token, reading the first attribute specification from the protected memory area of ​​the ID token and dividing the read first attribute specification into at least a second and a third attribute specification by the APV computer system;</li><li>Sending the second attribute specification and the address from the APV computer system to a first AP computer system configured to provide the attributes specified in the second attribute specification, wherein the first AP computer system is a first attribute provider computer system, and transmitting the third and each further attribute specification and the address of the ID token from the APV computer system to each another AP computer system each adapted to provide the attributes specified in the third or further attribute specification;</li><li>In response to receipt of the second attribute specification and the address by the first AP computer system, determination of a first set of attributes specified in the second attribute specification and initialization of mutual authentication of the first AP computer system and the ID token using Address;</li><li>After the mutual authentication of the first AP computer system and the ID token, writing the first attribute set by the first AP computer system to the protected memory area of ​​the ID token and sending an acknowledgment signal from the first attribute provider computer system to the attribute provider Directory computer system;</li><li>Upon receipt of an acknowledgment signal indicating that the respective AP computer system could fully provide the attribute set to be determined by it and write to the protected memory of the ID token, from the first and each of the further AP computer systems, sending a termination signal from the APV computer system to the user computer system;</li><li>In response to receipt of the termination signal, sending a second message from the user computer system to the service computer system to cause the service computer system to retrieve the written attribute sets from the protected storage area via the first ID provider module.</li></ul>

0030This can be advantageous since a large number of attributes that are provided by different attribute providers can be queried in single methods and made available to a legitimate service. It is thus possible to store user-specific attributes decentrally in a multiplicity of attribute provider computer systems. This can increase data security because none of the attribute providers have all the user's personal attributes. In addition, attributes are often collected on a decentralized basis (health data, credit history, address information, age information, driving license data, and others). Thus, it is possible to provide decentralized data to a service, without initially combining these attributes in a central memory. This increases data security by avoiding duplication of data. In addition, the necessary transmission of data (for example via network) is avoided. This also reduces other problems that occur when using a single central AP computer system, namely the problem that the centrally stored attributes are often obsolete because the transmission of updated attributes (changes in creditworthiness, home address, permission to drive a vehicle etc.) are often only delayed, incomplete or, for reasons of data protection, not at all transmitted by official branch offices or private offices to a central server. According to the invention, not even the attempt is made store all user attributes that may be relevant to services centrally. Rather, a uniform method is provided that enables the provision of distributed and distributed stored attributes to a service, and in the most efficient way, which offers the user the highest possible protection with regard to the anonymity of his data or with respect to the requested service.

0031Many ID tokens, such as smartcards, are also passive elements that are unable to control communication with several other communication partners. On the other hand, no other communication participant should have access to all attributes and attribute specifications, so that the problem arises as to how another communication participant can take control. The user computer system, for example, has no insight into the transmitted attribute specifications or the attributes transmitted, which makes it difficult to control the communication by, for example, the user computer system.

0032In the present case, the service computer system, the APV computer system, and the user computer system communicate with one another to allow coordinated data flow between a plurality of communication participants without the user computer system gaining insight into the transmitted attribute specifications or attributes.

0033The above-presented steps have the advantage that the service computer system is enabled to store the attributes it requires in the form of a first attribute specification on the ID token and then to transfer control to other components, in particular the user computer system, which in turn uses Trigger signals passes the control to the APV computer system, which performed a mutual authentication with the ID token. Thus, a complex coordination of the data exchange is made possible by middleware components, without these components would need to have insight into the attribute specifications or attributes. This increases data security. It is thus a complex and at the same time secure method for providing distributed stored,

0034For example, for classes of attributes, the APV computer system knows one or more AP computer systems that can provide the attributes specified in the first attribute specification. The APV computer system itself preferably does not manage attributes.

0035According to embodiments, the ID token is free of software or hardware-based program logic, which is adapted, depending on the content of the protected memory area, the establishment of new or the activation of existing communication channels to the user computer system, the ID provider module, the Initiate APV computer system and / or the first AP computer system. In other words, the ID token is a passive ID token that does not have its own power supply and is unable to actively initiate the establishment of one or more communication channels to different computer systems and that is incapable of use coordinate from several such communication channels.

0036According to embodiments, after successful mutual authentication of ID provider module and ID token, the ID provider module initializes the establishment of a first protected transmission channel between the ID provider module and the ID token. The first attribute specification is written over the first protected transmission channel. Upon successful mutual authentication of the APV computer system and ID tokens, the APV computer system initializes the establishment of a second protected transmission channel between the APV computer system and the ID token. The first attribute specification is read from the protected memory area of ​​the ID token via the second protected transmission channel.

0037Upon successful mutual authentication of the first AP computer system and ID token, the first AP computer system initializes the establishment of a third protected transmission channel between the first AP computer system and the ID token. The first attribute set is written to the protected memory area of ​​the ID token via the third protected transmission channel. The writing of all further attribute sets, which are each determined by one of the other AP computer systems, into the protected area of ​​the ID token takes place only after successful mutual authentication of the respective further AP computer system and the ID token and only after one another after mutual authentication each constructed further protected transmission channel.

0038The transmission of attributes or attribute specifications over protected transmission channels increases data security. In particular, therefore, the APV computer system and the user computer system have no way to access the transmitted attributes or attribute specifications.

0039According to embodiments, data transmitted over the first, second or third protected transmission channel is protected from access by the user computer system. The protection can be based, for example, on an encryption of the transmitted data, for example on an end-to-end encryption.

0040User computer systems, for example smartphones, notebooks or desktop PCs are often exposed to a variety of attacks. Viruses and Trojans can be transferred to the user computer system via USB sticks or e-mails. Even if the user computer system is operated by an authorized user who owns the transmitted attributes, it is nevertheless very advantageous that the user computer system can not access this sensitive data since it can never be ruled out with complete certainty, that there is malware on the user computer system that could communicate the transmitted data to the outside.

0041According to embodiments, the construction of the first protected transmission channel comprises the establishment of a local protected transmission channel between the user computer system and ID tokens; The structure of the local protected transmission channel can be done eg via a Diffie-Hellmann key exchange. Further, the construction of the first protected transmission channel comprises performing the mutual authentication of the user computer system and the ID token, whereby authentication data is transmitted over the local protected transmission channel.

0042The local protected data transmission channel thus enables in particular the secure transmission of authentication data of the user, for example a PIN, to the ID token.

0043According to embodiments, in response to the receipt of the termination signal, the user computer system sends a switchover command "SC [CA] # 1" from the user computer system to the ID token to cause the ID token the first protected transmission channel "SM Enable [CA] # 1 ". The switching command can thus specify, for example, the channel to which the switch should be made. The ID provider module reads the written attribute sets from the protected memory area over the activated protected first transmission channel.

0044Thus, the user computer system exercises control over the data transfer without having to analyze even the attributes transmitted to determine whether all attributes required by the service have already been successfully determined and transferred to the ID token. Rather, this "knowledge" is communicated via the trigger signal.

0045According to embodiments, after the first attribute specification has been written to the protected memory area, the APV computer system sends a switchover command "(SC [PACE])" to the ID token via the first protected communication channel, wherein the switchover command "SC [PACE]" Tokens to enable the local protected transmission channel "SM [PACE]". In response to receiving the termination signal by the user computer system, the user computer system sends another switchover command "SC [CA] # 1" to the ID token over the activated local broadcast channel. The further switching command "SC [CA] # 1" causes the ID token to activate the first protected transmission channel "SM [CA] # 1".

0046Thus, even with passive ID tokens it is ensured that as soon as all the attributes required by the service have been successfully stored on the ID token, a reading of these attributes by the ID provider module is initiated, which in turn provides the attributes to the service computer system.

0047Some ID tokens only support one active channel. In these ID tokens, activation of one of several communication channels, eg, in response to a switching signal, may involve deactivating all other channels. "Deactivation" here means that a deactivated channel can be reactivated with less computational effort than would be required, for example, for setting up a channel de novo.

0048According to embodiments, after writing the first set of attributes in the protected memory area, the first AP computer system sends a switchover command "SC [PACE]" to the ID token via the third protected communication channel. The switchover command "SC [PACE]" causes the ID token to activate the local protected transmission channel "SM [PACE]". Alternatively, the ID token can also automatically reactivate the local channel SM [PACE] after each successful write access, that is to say from the inactive to the active state.

0049For the mutual authentication of the next-used one of the other AP computer systems and the ID token, the activated local protected transmission channel between ID token and user computer system and the network between other AP computer system and the user computer system is used to transmit authentication data. The fact that, according to embodiments, the individual AP computer systems are also designed to transmit switching signals to the ID token thus enables the rapid and resource-saving (re-) activation of the local communication channel, so that via this sensitive authentication data between the next AP to be used Computer system and the ID token can be exchanged.

0050According to embodiments, the ID token stores the cryptographic keys used to construct each of the protected channels. The ID token is configured to each in response to a switching command "SC [PACE]", "SC [CA] # 1", "SC [CA] # 2", ..., "SC [CA] #n" the once established, protected transmission channels to activate and deactivate. Activation of a communication channel involves the reuse of the stored cryptographic key of the transmission channel to be activated.

0051This can considerably speed up the speed of the method and reduce the workload for the ID token since the generation of cryptographic keys and the creation of protected communication channels, for example by carrying out cryptographic protocols, is time-consuming and computationally intensive.

0052According to embodiments, the APV computer system analyzes the first attribute specification to determine all classes of attributes to which at least one of the attributes specified in the first attribute specification belongs. Further, the APV computer system determines the first, second, and each of the AP computer systems from a variety of AP computer systems other than those AP computer systems that are configured to provide user-related attributes of one of the determined attribute classes.

0053According to embodiments, the APV computer system is configured to identify a plurality of first AP computer systems, each configured to provide attributes of a particular attribute class. For example, the attributes of a class may be creditworthiness data, and the plurality of first AP computer systems may be computer systems of various banks and other institutions (eg, Schufa) having information regarding the creditworthiness of a person. The second attribute specification (AR1) and the address (# 106) of the ID token is preferably selectively sent to that of the identified first AP computer systems having a higher value than the other identified first AP computer systems for one of the following criteria:<ul><li>∘ number of attributes specified in the second attribute specification that can be provided; Thus, the number of contacted AP computer systems and, correspondingly, the duration of the process and the amount of data transmitted over the network can be reduced;</li><li>∘ granted confidence level of the provided attributes; Thus, it can be achieved that the attributes come from a particularly trustworthy AP computer system, for example, which has high security standards in its data center;</li><li>∘ amount of currently available computing resources; this may shorten the duration until the attributes are provided;</li><li>∘ Level of reliability and availability of the identified first AP computer system. For example, a log file or similar data source may be automatically evaluated for previous attribute requests to determine the reliability, measured, for example, in number or relative proportion of requests that resulted in successful delivery of the requested attributes.</li></ul>

0054According to embodiments, each of the identified first attribute provider computer systems may provide only a portion of the attributes specified in the second attribute specification. With regard to the example of creditworthiness, for example, a bank AP computer system of a first bank can only provide information about the reliable service of current loans at that first bank, while a bank AP computer system of a second bank only provides information about the reliable service of current loans in that second bank Bank can give; In another example, the attributes of a class may be health data and a first AP computer system provides patient data acquired by a cardiologist while a second AP computer system provides patient data. which were collected by a general practitioner. The APV computer system causes each of one of the identified first AP computer systems in multiple iterations to provide as many of the attributes specified in the second attribute specification as possible and to store them in the ID token and, for the next iteration, a new version of the second attribute specification in to store the ID token, the new version selectively contains only those attributes of the original second attribute specification, which were provided in any of the iterations performed so far. This can be advantageous in particular when the attributes of a class are collected from a plurality of different locations (decentralized). The service does not need to worry about where it can get all the needed data from. Not even the APV computer system needs to know for each attribute of a class which of the first AP computer systems can provide a particular attribute. It is sufficient that the APV computer system knows those AP computer systems that can provide in their entirety the requested attributes, with the respective contribution of each AP occurring dynamically during the execution of the method. The process is therefore also very flexible and particularly suitable for the integration of multiple data or attribute sources without central data pooling. which, in their entirety, can provide the requested attributes, with the respective contribution of each AP occurring dynamically during the execution of the method. The process is therefore also very flexible and particularly suitable for the integration of multiple data or attribute sources without central data pooling. which, in their entirety, can provide the requested attributes, with the respective contribution of each AP occurring dynamically during the execution of the method. The process is therefore also very flexible and particularly suitable for the integration of multiple data or attribute sources without central data pooling.

0055According to embodiments, the address of the ID token includes a URL that allows access to the ID token over the network by means of a reader coupled to the user computer system. The URL includes the address of the ID token, eg an IP address of the user computer system and a port number via which the reader is connected to the user computer system so that the ID token in the reader can be uniquely identified and addressed.

0056For example, the first attribute provider computer system may use the URL in the request to authenticate against the ID token specified in the URL, and after successful authentication, write the second set of attributes over the protected third communication channel in the ID token.

0057The transmission of the attribute specifications to the respective AP computer systems can, for example, take place in parallel, which increases the speed of the method. In an analogous manner, the storage of the respectively determined attribute sets by the first and second AP computer systems can take place in parallel. This may be particularly advantageous when the second and third attribute specifications specify disjoint attribute sets.

0058However, in other embodiments, the transmission of the attribute specifications may also be sequential, for example, for AP computer systems that provide attributes of the same attribute class. This may be particularly advantageous if an AP computer system only provides those attributes that have not already been stored in the ID token by another AP computer system of the same attribute class.

0059According to embodiments, the first AP computer system transmits a first signature request for generating a digital signature of the second attribute specification to the ID token. In response to this request, the ID token generates the digital signature of the second attribute specification and transmits it to the first AP computer system. The first AP computer system checks the digital signature with a public signature verification key. The first AP computer system determines the first set of attributes according to the second attribute specification only if the check determines that the digital signature is valid. Accordingly, only in this case is the first set of attributes stored in the ID token.

0060This can be advantageous if the attribute provider computer system has to prove to third parties that the attributes have been created or for later proof of the correct attribute creation, that a request for an ID token has actually been or has been present. This avoids the situation where an attribute provider computer system unauthorizedly collects data in the form of attributes that were not requested by ID tokens. However, since the anonymity of the attributes suffers in this procedure, this method is preferably used only if the protection against unauthorized queries regarding user-specific attributes is more important than complete anonymity of the attributes.

0061According to embodiments, the ID token creates signatures via attribute specifications only if the user has consented to this signature through a PIN entry. In this case, the reading device or the user computer system requests the user to enter a signature PIN for the activation of a signature function of the ID token for generating a digital signature of the second attribute specification and / or third attribute specification. The request for PIN entry ("signature confirmation request") is sent from the first AP computer system to the user computer system, which is coupled to corresponding input means. The entered PIN itself is transmitted from the user CS to the AP computer system and from there via the protected transmission channel SM [CA] # 3 to the ID token.

0062In an analogous manner, according to some embodiments of the invention, the second AP computer system may transmit a second request for PIN input to the user computer system.

0063According to embodiments, a separate private signing key associated with one of the AP computer systems is stored in the protected memory area of ​​the ID token for each of the AP computer systems. Each of the AP computer systems has access to a public signature verification key which forms an asymmetric cryptographic key pair with the private signing key associated with the AP computer system. The public signature verification key is designed to check the validity of a digital signature generated by the corresponding private signing key.

0064According to embodiments, the ID token includes a communication interface for communicating with a reader of the user computer system. The communication interface of the ID token is adapted for wireless communication and for the wireless coupling of energy into the ID token by the reading device, in order to supply the ID token with the electrical energy required for its operation. For example, the ID token is a passive ID token, eg a passive transponder, ie an ID token that does not have its own internal power supply.

0065According to embodiments, the ID token includes a volatile electronic memory in which the first attribute specification is stored. The ID token or its volatile memory is configured so that the first attribute specification is deleted from the volatile electronic memory when the ID token is removed from the range of the reader. This can increase data security.

0066A new protocol flow should be started in this case if the token is removed from the range of the reader before providing all requested attributes. This avoids that the ID token is in an undefined state, for example, if the token is removed from the range of the reader after storing the second attribute specification.

0067The first and second and other sets of attributes stored in the ID token based on the write access of the first and second attribute provider computer systems are stored in the nonvolatile electronic memory so that they can be accessed by a subsequent further read access based on another service request ,

0068The first and second sets of attributes stored in the ID token due to the write access of the first and second AP computer systems are stored in the nonvolatile electronic memory so that they can be accessed by a subsequent further read access based on another service request. Alternatively, the first attribute specification and the first and second sets of attributes are stored in the non-volatile memory.

0069According to embodiments, the user computer system or the reader requests the user to input a signature PIN for the activation of a signature function of the ID token for the generation of a digital signature of the first, second and / or third attribute specification by the reader or the user computer system on.

0070According to embodiments, the ID provider module is authenticated to the ID token using an authorization certificate of the ID provider module. This permission certificate specifies read permissions of the ID provider module for reading attributes from the ID token. The ID token precedes the approval of a read operation of the ID provider module, that is, before the attributes are provided to the ID provider module by the procThe ID token of the ID token is checked by the authorization certificate by the ID provider module for read authorization. Write permission of the ID provider module for writing the first attribute specification in the ID token is further specified in the authorization certificate. The ID token performs a write authorization check of the ID provider prior to the authorization of the write operation of the ID provider module, that is, prior to the execution of a write operation of the data provided by the ID provider module by the processor of the ID token Modules using the authorization certificate.

0071According to embodiments, the authentication of the first AP computer system to the ID token is performed using an authentication certificate of the first AP computer system in which write permissions of the first AP computer system are specified for writing the first set of attributes in the ID token. The ID token verifies the write permission of the first AP computer system by using the authorization certificate before the ID token authorizes the first AP computer system to write the first set of attributes.

0072According to embodiments, the entitlement certificate of the first AP computer system does not entitle the first AP computer system to read the first attribute specification nor to read attributes stored in the protected storage area of ​​the ID token.

0073According to alternative embodiments, the authorization certificate of the first AP computer system additionally additionally entitles the first AP computer system to read only a specific part of the first attribute specification, which selectively specifies only attributes of a specific attribute class.

0074According to embodiments, the protected memory area of ​​the ID token contains a plurality of subareas. Each of the sub-areas is specifically associated with an attribute class. The ID token allows a read and / or write access of the first AP computer system to one of the subregions only if the entitlement certificate of the first AP computer system includes proof of read and / or write permission for that subarea. The authorization certificate of the first attribute provider computer system grants the first AP computer system authorization to write the second attribute set and optionally also to read attribute specifications only to those of the subregions to which the attribute class is assigned, for the provision of which the first attribute provider is trained. This ensures that an AP computer system can not read the attributes provided by the other AP computer systems or the corresponding attribute specifications. The AP computer system thus contains no insight into personal data that it does not already have, and can also make no conclusions about the nature of the requested service based on the attribute specification.

0075According to embodiments, the ID token is a value or security document, in particular an identity document, that is to say an ID document, in particular an electronic identity card, passport, driving license, company identity card or a means of payment, such as a banknote, a credit card or any other proof of entitlement, such as an admission ticket, a bill of lading or a visa, in particular a chip card, in particular with an RFID and / or NFC interface.

0076In a further aspect, the invention relates to an ID token associated with a user, the ID token having an electronic memory with a protected memory area in which attributes are stored. Access to the protected memory area is only possible via a processor of the ID token. The ID token has a communication interface for communicating with a reader of a user computer system. The user computer system is coupled to an ID provider module via a network. The ID token is configured to perform the following steps:<ul><li>Mutual authentication of the ID provider module and the ID token in interoperation with the ID provider module;</li><li>Establishing a first protected transmission channel with end-to-end encryption between the ID token and the ID provider module over the network;</li><li>Receiving a first attribute specification from the ID provider module and storing the received first attribute specification in a protected storage area of ​​the ID token, the first attribute specification specifying those attributes that the service computer system requires to provide the service requested with the service request;</li><li>Mutual authentication of an APV computer system and the ID token;</li><li>Upon mutual authentication of the APV computer system and the ID token, examining an APV computer system specific entitlement certificate to determine if the APV computer system is authorized to read the first attribute specification from the protected storage area; If the APV computer system is authorized to read the first attribute specification, permitting read access to read the first attribute specification to allow the APV computer system to split the read first attribute specification into at least one second and one third attribute specification;</li><li>Mutual authentication of a first AP computer system configured to provide attributes, the attributes specified in the second attribute specification, and the ID token;</li><li>Upon mutual authentication of the first AP computer system and the ID token, checking a first AP computer system-specific authentication certificate to determine if the first AP computer system is authorized to read the first attribute specification from the protected memory area; If the first AP computer system is authorized to write attributes in the protected memory area of ​​the ID token, permission of the write access of the first AP computer system to the protected memory area to store a first attribute set in the ID token, wherein the first set of attributes which are specified in the second attribute specification and determined by the first attribute provider computer system.</li></ul>

0077According to embodiments, the ID token is configured to mutually authenticate each other with a second and one or more other AP computer systems each configured to provide attributes of a particular attribute class, the ID token being different from the authenticating one Attribute provider computer systems receives an AP computer system-specific authorization certificate and uses this for authentication checking for each write access for writing attribute sets.

0078The communication interface of the ID token is designed, for example, for wireless communication and for wireless coupling of energy into the ID token by the reading device in order to supply the ID token with the electrical energy required for its operation.

0079According to embodiments, the ID token comprises a volatile electronic memory in which the first attribute specification is stored so that the first attribute specification is deleted from the volatile electronic memory when the ID token is removed from the range of the reader, and wherein the the write access of the first and second AP computer systems are stored in the ID token stored first and second sets of the attributes in the nonvolatile electronic memory, so that they can be accessed by a subsequent further read access due to another service request. Alternatively, the first attribute specification and the first and second sets of attributes are stored in the non-volatile memory.

0080In another aspect, the invention relates to an AP computer system having a network interface for accessing an ID token over a network. The AP computer system is an attribute provider computer system and configured to perform the following steps:<ul><li>Receiving from a APV computer system a second attribute specification that is a subset of the attribute specification generated in a first attribute specification generated by a service computer system, the APV computer system being an attribute provider directory computer system configured to divide the first attribute specification into the second and further attribute specifications are formed, and receiving an address of the ID token from the APV computer system;</li><li>In response to receipt of the second attribute specification and the address, determination of a first set of attributes specified in the second attribute specification, and initialization of mutual authentication of the AP computer system and the ID token using the address;</li><li>After mutual authentication of the AP computer system and the ID token, writing the first attribute set by the AP computer system to the protected memory area of ​​the ID token and sending an acknowledgment signal from the AP computer system to the APV computer system;</li><li>Sending an acknowledgment signal indicating whether the AP computer system was able to fully deploy the first set of attributes and write to the protected memory of the ID token from the AP computer system to the APV computer system.</li></ul>

0081According to embodiments, the AP computer system transmits a signature request to the ID token to cause the ID token to digitally sign the second attribute specification. In response to receiving the signature request, the ID token signs the second attribute specification. The AP computer system receives the signature of the second attribute specification from the ID token and performs a signature check of the signed second attribute specification. Preferably, upon successful mutual authentication, the AP computer system and the ID token establish a protected communication channel (SM [CA] # 2) and use it around the attribute specification, the attributes, the signature request and the signature over the protected communication channel (SM [CA ] # 3).

0082According to embodiments, the AP computer system includes an authentication certificate for authentication against the ID token. The authorization certificate specifies rights of the AP computer system to write the first set of attributes in the ID token. Preferably, the entitlement certificate does not allow the AP computer system read access to attributes stored in the ID token. Optionally, the entitlement certificate includes rights of the AP computer system to read and write different versions of the second attribute specification.

0083Preferably, the read and / or write privilege selectively relates only to a subregion of the memory area of ​​the ID token associated with an attribute class that the AP computer system is configured to provide.

0084In another aspect, the invention relates to an attribute provider directory computer system, also referred to as an "APV computer system", which is connected via a network to a user computer system, a first AP computer system, and a second AP computer system. The user computer system is coupled via a reader to an ID token having a nonvolatile electronic memory with a protected memory area. Access to the protected memory area is only possible via a processor of the ID token. The APV computer system is configured to perform the following procedure:<ul><li>Receiving a trigger signal from the user computer system, wherein the first trigger signal is free of a first attribute specification and its parts and includes an address of the ID token, wherein the first attribute specification specifies user-related attributes that are requested by a user of the user computer system Service required for its provision;</li><li>In response to receipt of the trigger signal, mutual authentication of the APV computer system and the ID token using the address;</li><li>Upon successful mutual authentication of the APV computer system and the ID token, reading the first attribute specification from the protected memory area of ​​the ID token and dividing the read first attribute specification into at least a second and a third attribute specification by the APV computer system;</li><li>Sending the second attribute specification and the address from the APV computer system to a first AP computer system configured to provide the attributes specified in the second attribute specification, wherein the first AP computer system is a first attribute provider computer system, and transmitting the third attribute specification and the address of the ID token from the APV computer system to the second AP computer system configured to provide the attributes specified in the third attribute specification;</li><li>In response to receipt of acknowledgment signals, indicating that the first, second, and each further AP computer system that has received from the APV computer system a subset of the first attribute specification fully provides the attribute set to be determined by that AP computer system, and into the protected memory of the ID token, sending a termination signal (SAPV) to the user computer system.</li></ul>

0085In a further aspect, the invention relates to a computer system with an ID token according to one of the embodiments described herein, having at least a first and a second AP computer system according to any of the embodiments described herein, with an APV computer system according to any of the embodiments described herein with a user computer system and an ID provider module according to one of the embodiments described herein. The user computer system is coupled via a reader to the ID token and via a network to a service computer system and at least to the APV computer system. The ID provider module is part of the service computer system or operatively coupled to the service computer system via a network.

0086The identification and inclusion of multiple first and / or second attribute provider computer systems may include several advantages: on the one hand, the reliability is increased if, for example, one of the attribute provider systems is currently not available for technical or other reasons, but the attributes can be obtained from another attribute provider computer system. Simultaneously requesting attributes from multiple attribute provider computer systems simultaneously has the advantage that the speed of the attribute determination can be increased, in particular if the respectively requested attribute sets are disjoint. A sequential, iterative request for attributes on multiple attribute provider computer systems so long until all attributes of a particular class or all attributes specified in the first attribute specification are determined and stored in the ID token, it may be advantageous since a very wide range of attributes can be provided by including a plurality of attribute provider computer systems. This is also privacy, because it is now possible that individual attribute providers know only a very small section of the attributes of a person.

0087In the following, embodiments of the invention will be explained in more detail with reference to the drawings. Show it:<dl id="dl0001" compact="compact"><dt>FIG. 1</dt><dd>a block diagram of an embodiment of a computer system according to the invention,</dd><dt>FIG. 2</dt><dd>a block diagram of an embodiment of a computer system according to the invention, taking into account the exchanged data,</dd><dt>FIG. 3</dt><dd>a flowchart of an embodiment of a method according to the invention with at least one attribute provider computer system,</dd><dt>FIG. 4</dt><dd>a diagram of the data exchange according to an embodiment of the method according to the invention.</dd></dl>

0088Elements of the following embodiments, which are equal to each other or correspond to each other, are each denoted by identical reference numerals.

0089The <figref idref="f0001"><b>FIG. 1</b></figref> The user computer system 100 may be a personal computer, a portable computer such as a laptop or palmtop computer, a personal digital assistant, a mobile telecommunications device, in particular a smart phone , or the like act. The user computer system 100 has a reader 101 with an interface 104 for communicating with an ID token 106 having a corresponding interface 108.

0090The user computer system 100 has at least one processor 110 for executing program instructions 112 and a network interface 114 for communicating over a network 116. The network may be a computer network, such as the Internet.

0091The ID token 106 has an electronic memory 118 with protected memory areas 120, 122, and 124. The protected memory area 120 serves to store a reference value needed for authenticating the user 102 to the ID token 106. This reference value is, for example, an identifier, in particular a so-called Personal Identification Number (PIN), or reference data for a biometric feature of the user 102, which can be used for the authentication of the user against the ID token 106.

0092The protected area 122 serves, for example, for storing a private key, and the protected memory area 124 is used, for example, for storing attributes, for example of the user 102, such as, for example, his name, place of residence, date of birth, gender, and / or attributes that correspond to the ID Tokens themselves, such as the institution that created or issued the ID token, the validity period of the ID token, an identifier of the ID token, such as a passport number or a credit card number. For example, the user's address data 176 may belong to a different attribute class and be provided by a different AP computer system than the attributes specifying the ID token or attributes 179 specifying, for example, health data.

0093The electronic memory 118 may further include a memory area 126 for storing a certificate. The certificate includes a public key associated with the private key stored in the protected storage area 122. The certificate may have been created according to a public key infrastructure (PKI) standard, for example according to the X.509 standard.

0094The certificate does not necessarily have to be stored in the electronic memory 118 of the ID token 106. Alternatively or additionally, the certificate can also be stored in a public directory server.

0095The ID token 106 has a processor 128. The processor 128 is for executing program instructions 130, 132, and 134. The program instructions 130 are for user authentication, that is, for authenticating the user 102 to the ID token.

0096In an embodiment with a PIN, the user 102 enters his PIN for his authentication, for example in the user computer system 100. Execution of the program instructions 130 then accesses the protected memory area 120 in order to assign the entered PIN with the reference value of the PIN stored there to compare. In the event that the entered PIN matches the reference value of the PIN, the user 102 is considered authenticated.

0097Alternatively, a biometric feature of the user 102 is captured. For example, the ID token 106 has a fingerprint sensor or a fingerprint sensor is connected to the user's computer system 100. The biometric data acquired by the user 102 is compared to the biometric reference data stored in the protected memory area 120 by executing the program instructions 130 in this embodiment. If the biometric data acquired by the user 102 sufficiently matches the biometric reference data, the user 102 is considered to be authenticated.

0098The program instructions 134 are used to execute the ID token 106 steps of a cryptographic protocol for authentication of an ID provider module 136 against the ID token 106. The cryptographic protocol may be a challenge-response protocol based on a act symmetric key or an asymmetric key pair.

0099For example, the cryptographic protocol implements an Extended Access Control method as specified for machine-readable travel documents (MRTD) by the International Aviation Authority (ICAO). Upon successful completion of the cryptographic protocol, the ID provider module 136 authenticates against the ID token and thereby has its read permission to read the attributes stored in the protected storage area 124 already present on the ID token and / or of one or more several of the AP computer systems 172, 173, 174 were provided after. The authentication can also be mutually, ie also the ID token 106 must then authenticate to the ID provider module 136 according to the same or another cryptographic protocol. The program instructions 132 serve for the end-to-end encryption of data transmitted between the ID token 106 and the ID provider module 136, but at least the attributes read from the protected memory area 124 by the ID provider module 136. For the end-to-end encryption, a symmetric key may be used, which is agreed, for example, during the execution of the cryptographic protocol between the ID token 106 and the ID provider module 136. but at least the attributes read by the ID provider module 136 from the protected memory area 124. For the end-to-end encryption, a symmetric key may be used, which is agreed, for example, during the execution of the cryptographic protocol between the ID token 106 and the ID provider module 136. but at least the attributes read by the ID provider module 136 from the protected memory area 124. For the end-to-end encryption, a symmetric key may be used, which is agreed, for example, during the execution of the cryptographic protocol between the ID token 106 and the ID provider module 136.

0100Alternative to that in the <figref idref="f0001">FIG. 1</figref> In the embodiment shown, the user computer system 100 with its interface 104 can not communicate directly with the interface 108, but via a reader 104 connected to the interface 104 for the ID token 106. Via this reading device, for example a so-called class 2 chip card Terminal, the PIN can also be entered.

0101The ID provider module 136 has a network interface 138 for communication over the network 116. The ID provider module 136 further has a memory 140 in which a private key 142 of the ID provider module 136 and the corresponding certificate 144 is stored. Also, this certificate may be, for example, a certificate according to a PKI standard, such as X.509.

0102The ID provider module 136 further has at least one processor 145 for executing program instructions 146 and 148. By executing the program instructions 146, the steps of the cryptographic protocol concerning the ID provider module 136 are executed. Overall, therefore, the cryptographic protocol is implemented by executing the program instructions 134 by the processor 128 of the ID token 106 and by executing the program instructions 146 by the processor 145 of the ID provider module 136.

0103The program instructions 148 are used to implement the end-to-end encryption on the part of the ID provider module 136, for example based on the symmetric key, which is used when executing the cryptographic protocol between the ID token 106 and the ID provider. Module 136 has been agreed. In principle, any method known per se for agreeing the symmetric key for the end-to-end encryption, such as, for example, a Diffie-Hellman key exchange, can be used.

0104The ID provider module 136 is preferably located in a particularly protected environment, in particular in a so-called trust center, so that the ID provider module 136 in combination with the necessity of authenticating the user 102 with respect to the ID token 106 Trust anchor for the authenticity of the read from the ID token 106 attributes.

0105A service computer system 150 may be configured to receive an order or order for a service or product, particularly an online service. For example, the user 102 may open an account online with a bank via the network 116, or may use other financial or banking services. The service computer system 150 may also be embodied as an online store, such that the user 102 may, for example, purchase a mobile phone or the like online. Furthermore, the service computer system 150 can also be designed for the delivery of digital content, for example for the download of music and / or video data or as a government server for an eGovernment application.

0106The service computer system 150 has for this purpose a network interface 152 for connection to the network 116. Further, the service computer system 150 has at least one processor 154 for executing program instructions 156. By executing the program instructions 156, for example, dynamic HTML pages are generated the user 102 can enter his order or his order.

0107Depending on the type of product or service ordered or ordered, the service computer system 150 must review attributes of the user 102 and / or its ID token 106 based on one or more predetermined criteria. Only if this check is passed will the order or order of the user 102 be accepted and / or executed.

0108For example, to open a bank account or purchase a mobile phone with a related contract, it is required that the user 102 reveal his identity to the service computer system 150 and that this identity be verified. In the prior art, for example, the user 102 has to present his identity card for this purpose. This process is replaced by the reading of the digital identity of the user 102 from its ID token 106.

0109Depending on the application, further attributes may be required for the provision of the service, which are initially not present in the ID token. This can be done in the<figref idref="f0001">FIG. 1</figref> have shown computer system 172 and 173 and an APV computer system 199. The AP computer systems can in principle have the same structure as the ID provider module or include such or be operatively coupled to it (for example, with the ID token perform a mutual authentication and build an end-to-end encrypted channel ) and have additional functionality to receive attribute specifications from an APV computer system 199 and to write attributes in the ID tokens.

0110<figref idref="f0002"><b>FIG. 2</b></figref> shows an embodiment of a distributed system, which substantially already in <figref idref="f0001">FIG. 1</figref> described components and computer systems. The transmission channels protected by end-to-end encryption between the ID token and the respective communication partners (ID provider module, various AP computer systems, user computer system, APV computer system) are shown by dashed lines. For example, the APV computer system can perform a function as a relay station by protocol translation and initiate the establishment of the individual channels, but it is not the end point in the end-to-end encrypted communication links.

0111To take advantage of a service provided by the service computer system 150, for example, the procedure is as follows (reference being made below to FIGS <figref idref="f0001"><b>FIGS. 1</b></figref><b>.</b><figref idref="f0002"><b>2</b></figref><b>and</b><figref idref="f0003"><b>3</b></figref>):<ul><li>The user 102 first builds an Internet session via the network 116 to the service computer system 150 using his user computer system 100. Through this Internet session, at step 200, a service request 103 is transmitted from the user computer system 100 to the service computer system 150, whereby the user 102 requests the provision of a service of the service computer system 150. The service computer system 150 responds to this service request 103 by transmitting an attribute specification 105 (via a network or within a single computer system to the ID provider module in step 202. The attribute specification is also referred to as a "first attribute specification";</li><li>The receipt of the first attribute specification by the ID provider module directs the mutual authentication of ID provider module and ID token in step 204 and the establishment of a first protected transmission channel SM [CA] # 1 between ID provider module and ID Token in step 206; thus, the first secure transmission channel becomes the active data transmission channel of the ID token;</li><li>In step 208, the ID provider module 136 writes the first attribute specification 105, which specifies the attributes to be met for the service requested with the service request 103, to the protected memory 183 of the ID token. The first attribute specification 105 is transmitted via the first protected transmission channel SM [CA] # 1.</li><li>In step 210, the ID provider module, along with the first attribute specification or even after transmission of the first attribute specification, transmits a toggle signal SC [CA] PACE to the ID token to cause it to switch to the local channel SM [PACE]. Switching to the local channel, which provides a secure communication link between the user's computer system and the ID token via the reader, allows other computer systems, such as the APV computer system 199, to mutually authenticate with the ID token and build an end -to-end encryption between this additional computer system and the ID token via the user's computer system.</li><li>The user computer system receives a signal from the service computer system, the ID provider module, or the ID token that the first attribute specification has been stored in the ID token;</li><li>In step 212, the user computer system then sends the address of the ID token 106 # and a trigger signal T1 to the APV computer system. The address 106 # may include, for example, an IP address of the user computer system and a port number via which the ID token can be addressed via the reader. The trigger signal T1 includes the information that the first attribute specification has been successfully stored in the ID token. The trigger signal and the address can be sent together or sequentially. The token address may be part of the trigger signal;</li><li>In response to the receipt of the trigger signal T1 and the address 106 #, the APV computer system and the ID token perform a mutual authentication in step 214 (at the initiative of the APV computer system); this can be done via the network and the user computer system to which the ID token is yes connected via the active local communication channel. In this case, the address # 106 of the ID token, for example a URL with port information, is used;</li><li>In step 226, following mutual successful authentication, the establishment of a second protected communication channel SM [PACE] between the APV computer system and the ID token follows; thus, the second secure transmission channel becomes the active communication channel of the ID token;</li><li>In step 218, the APV computer system 199 reads the first attribute specification 105 from the ID token over the second protected communication channel;</li><li>In step 220, the APV computer system sends a toggle signal to the ID token, which causes the ID token to reactivate the protected local communication channel SM [PACE];</li><li>In step 222, the APV computer system analyzes the first attribute specification 105 and determines a plurality of APV computer systems that are capable of providing at least portions of the attributes specified in the attribute specification 105. For example, the analysis may involve identifying multiple attribute classes to which the specified attributes belong (eg, address data, health data, age, credit, and the like). Then, AP computer systems capable of providing attributes of the respective classes are identified. For example, the APV computer system may identify the AP computer systems 172, 173, and 174, each of which may provide attributes of a different attribute class. In addition, the APV computer system divides the first attribute specification 105 into a plurality of partial attribute specifications AR1, AR2, AR3, each of which specifies only those attributes that belong to a particular attribute class or that may be provided by one of the determined AP computer systems. The APV computer system now sends one of these sub-specifications, also called "second attribute specification" AR1 via the network to a corresponding first AP computer system 172. The AP computer system 172 thus does not learn the entirety of the requested attributes, but receives only a section of the requested Attributes that usually do not allow conclusions about the requesting service. Preferably, the transmission of the attribute specification is encrypted, for example, over the Internet using the HTTPS protocol. In addition, the APV computer system transmits the token address 106 # to the first HP computer system 172;</li><li>In response to receiving the second attribute specification and the address, the first AP computer system determines, in step 224, the attributes specified in the second attribute specification AR1. For example, the attributes are read from a database 175 operatively coupled to the AP1 computer system; In step 226, the AP1 computer system and the ID token perform mutual authentication. This is made possible by the fact that the switching signal sent in step 220 has reactivated the local communication channel between the ID token and the user computer system, so that a data exchange between the AP1 computer system and the user computer system 100 via the network 116 and between the user computer system 100 and the ID token 106 are possible over the local data communication channel;</li><li>In step 228, after successful mutual authentication of the AP1 computer system and the ID token, a third secure transmission channel SM [CA] # 3 is established between the AP1 computer system and the ID token; thus, the third secure transmission channel becomes the active communication channel of the ID token;</li><li>The third secure transmission channel SM [CA] # 3 is used by the AP1 computer system in step 230 to store the determined first attribute set A1 in a protected memory area of ​​the memory 118 of the ID token;</li><li>After successful storage, in step 232 the AP1 computer system sends a toggle signal to the ID token which causes the ID token to re-enable the protected local communication channel SM [PACE];</li><li>In addition, in step 232, the AP1 computer system sends an acknowledgment signal S1 to the APV computer system 199. As in FIG <figref idref="f0002">FIG. 2</figref> 1, the acknowledgment signal includes information as to whether the first attribute set A1 could be successfully determined and written to the ID token. Although neither user computer system nor the APV computer system can not read the data transmitted over the protected first, second, third and further channels and thus can not determine if and when the attributes specified in the second attribute specification AR1 are successfully determined Thus, in the ID token, the acknowledgment signal allows coordination of the data exchange over the user computer system by the APV computer system. This is achieved by the AP1 computer system sending the first acknowledgment signal S1 to the user computer system 100, once the first set of attributes A1 has been successfully written to the ID token 106 or as soon as an error occurred. The error can also lie in the exceeding of a maximum time for write access. The confirmation signal S1 preferably indicates to the APV computer system whether all attributes specified in the second attribute specification AR1 have been successfully determined and written in the ID token. Optionally, the confirmation signal may contain further information, for example error codes or the like, which allow conclusions to be drawn on causes of errors. The confirmation signal could eg contain the value "F" if no attribute could be determined at all, "N" if a subset of the attribute specification determined for the respective AP could be determined and "J"</li></ul>

0112Steps 222-234 are now repeated for each of the determined AP computer systems 173, 174, .... Here, for example, the third attribute specification AR2 is communicated to the second attribute provider computer system AP2 173 via the network, preferably encrypted, a fourth protected data transmission channel SM [CA] # is established after mutual authentication between the AP2 computer system and the ID token. 4, transmitting a second attribute set A2 by the AP2 computer system, writing the second attribute set to the ID token 106 via the fourth protected communication channel, sending a second acknowledgment signal S2 from the AP2 computer system to the APV computer system and reactivating a switchover signal of the local communication channel sent to the ID token.

0113In some embodiments, the repetition of steps 222-234 is performed sequentially as in FIG <figref idref="f0003">FIG. 3</figref> shown. For example, the APV computer system sends the third attribute specification AR2 to the AP2 computer system only after receiving the acknowledgment signal S1 and the fourth attribute specification AR3 to the AP3 computer system only after receiving the acknowledgment signal S2.

0114In alternative embodiments, the APV computer system sends the generated partial attribute specifications AR1, AR2, AR3, etc. in parallel to the respective AP computer systems 172, 173, 174 so that parallel determination of the respective attribute sets is possible. In order to ensure a complete transfer of the attributes from the respective AP computer systems to the ID token, the ID token reserves its associated protected transmission channel at the reader and the user computer system coupled thereto at least until the protected channel is established to the ID token or has been reactivated, the writing of the attributes has been terminated, and optionally the context of the protected channel (ie, generated cryptographic keys, session keys, etc.) has been stored for quick re-activation of the channel. Thereafter, the AP computer system "releases" the ID token to other AP computer systems. According to embodiments, the ID token is configured to support quasi-parallel writing via logical channels so that the attributes or attribute sets are written atomically (that is, according to the ASIC model for data transactions).

0115The APV computer system 199, after each receipt of an acknowledgment signal S1, S2, S3 ... checks whether a corresponding acknowledgment signal has already been received from each of the determined AP computer systems which received a partial attribute specification AR1, AR2, AR3. If the APV computer system determines in step 236 that an acknowledgment signal has been received from each of these AP computer systems that indicates to all of the determined AP computer systems that the respective specified attributes could be successfully determined and stored in the ID token the APV computer system sends a termination signal SAPV to the user computer system via the network 116. If an acknowledgment signal was received with an error message from one of the AP computer systems, For example, the APV computer system may abort the entire process with an error message to the service computer system. Alternatively, it may send the partial attribute specification for which no or not all attributes could be determined to a replacement AP computer system capable of providing the attributes that the AP computer system was originally intended to provide the error occurred;<ul><li>In response to receiving the termination signal, the user computer system sends a "second" message to the service computer system to notify the service computer system that all attributes relevant to the service and specified in the first attribute specification 105 succeed and are now in the ID token. This allows the ID provider module of the service computer system to reactivate the first data transmission channel and use it to read out all the attributes stored on the ID token and specified in the first attribute specification and to make them available to the service. The service may now parse the attributes and provide the service to the user 102 depending on the result of that analysis.</li></ul>

0116To set up the above-mentioned protected first transmission channel from the ID provider module of the service computer system to the ID token, several steps may be necessary. Thus, in some embodiments, the user computer system 100 may prompt the user 102 to authenticate to the ID token 106. For this purpose, the user 102 enters his PIN via the reader 101 or a keyboard of the user computer system 100, for example. For verification of the PIN, a local secure transmission channel SM [PACE] is set up between the user computer system 100, that is to say its reader 101, and the ID token 106, for example using a Diffie-Hellman key exchange, in particular according to the Federal Office for Security in Information Processing (BSI) specified PACE protocol.

0117Optionally, the ID provider module 136 may first try to read out all the attributes specified in the first attribute specification and already stored in the ID token and transmit to the service computer system and the first attribute specification by a new version which no longer specifies the already read attributes. The read-out attributes are transmitted over the first protected transmission channel SM [CA] # 1.

0118Preferably, a mutual authentication of the IT token 106 and the respective authentication partner (ie ID provider module 136, APV computer system and AP1, AP2 and AP3 computer system) is carried out using certificates, that is, there is a so-called CA and TA , In this case, a session key is also agreed with which the respective established protected transmission channel is constructed with end-to-end encryption between the ID token 106 and the authentication partner via the user computer system 100 and the network 116, wherein the local protected transmission channel SM [PACE] persists in some embodiments in addition to the respectively constructed first, second or third protected data communication channel SM [CA] X.

0119The service provider's ID provider module may be an integral component of the service computer system or an external component that is interoperable with the service CS. According to embodiments, each of the AP computer systems and also the APV computer system also each use an ID provider module (which may be implemented as an internal or external component of the AP or APV computer system) for data exchange with the ID token. The service computer system, the AP computer systems and the APV computer system each use their own ID provider modules to ensure the privacy of the exchanged attributes.

0120According to one embodiment, the protected memory of the ID token is subdivided into different sectors, each sector being associated with a particular attribute class and the write permissions for the individual AP computer systems being restricted to individual sectors. Preferably, the AP computer systems selectively store the attribute sets each of them, specified in the second AR1, third AR2 and fourth AR3 attribute specification, each in a sector associated with a particular attribute class. An AP computer system that provides attributes of a specific attribute class, In this case, it can selectively write attribute sets from its assigned sector and, optionally, in some embodiments, also read and / or write access to attribute specifications stored there. The latter can be particularly advantageous if several AP computer systems 1722, 172, possibly sequentially, are to provide attributes of a certain class, whereby each of these AP computer systems writes an attribute specification in the ID after writing the attributes determined by it to the sector. Token stores selectively specifies the attributes that could not be determined by the writing AP computer system.

0121The communication between the user computer system 100 and the ID token 106 preferably takes place via the local transmission channel SM [PACE]. The communication between the ID token and the ID provider module 136 is via a first protected transmission channel SM [CA] # 1. The communication between the ID token and the APV computer system 199 is via a second protected transmission channel SM [CA] # 2. The communication between the ID token and each of the AP computer systems 172, 173, 174 is in each case via a corresponding third SM [CA] # 3, fourth SM [CA] # 4 and fifth SM [CA] # 5 protected transmission channel.

0122In some embodiments, alternative to steps 236 and 238, immediately upon receipt of an acknowledgment signal S1, S2, S3 from each of the AP computer systems, the APV computer system first activates the first protected transmission channel SM [CA] # 1 (FIG. eg by sending a corresponding switchover command) to allow the ID provider module 136 to immediately read out the attributes determined by that one attribute provider computer system for transmission to the service computer system. After a successful readout of a subset A1, A2, A3 of the attributes, the ID provider module in each case sends a read acknowledgment to the APV computer system. The APV computer system then sends a toggle signal SC [CA] PACE to the ID token to cause it to switch to the local channel, and sends one of the partial attribute specifications AR2 and the token 106 # to another 173 of the AP. Computer systems that have not been requested so far. After successful mutual authentication, a secure transmission channel SM [CA] # 3, SM [CA] # 4 SM [CA] # 5 is set up for this AP computer system as previously described. This protected transmission channel becomes the active channel, the first secure SM [CA] # 1 to the ID provider module becomes an inactive transmission channel. After successful mutual authentication, a secure transmission channel SM [CA] # 3, SM [CA] # 4 SM [CA] # 5 is set up for this AP computer system as previously described. This protected transmission channel becomes the active channel, the first secure SM [CA] # 1 to the ID provider module becomes an inactive transmission channel. After successful mutual authentication, a secure transmission channel SM [CA] # 3, SM [CA] # 4 SM [CA] # 5 is set up for this AP computer system as previously described. This protected transmission channel becomes the active channel, the first secure SM [CA] # 1 to the ID provider module becomes an inactive transmission channel.

0123An inactive transmission channel is a channel for which a session and a secure, for example, encrypted connection is maintained, although this channel is not currently used for data transmission. An active channel is a channel that is currently being used for data transmission. The transmission channel can thus be reactivated very quickly and resource-conserving by a switching command without the need to negotiate new session keys. In this sequential provision of attribute sets A1, A2, A3 and the immediate reading of these attribute sets immediately after their provision by the ID provider module activates and deactivates the user computer system the first secure channel to the ID provider module in response to the receipt of switching signals from the ID provider module and in response to receipt of acknowledgment signals S1, S2, S3 from the respective attribute provider computer systems. This speeds up the process by eliminating the need to negotiate new session keys to establish the first protected transmission channel between the IT token and the ID provider module, which can be particularly beneficial given the limited processing power of many ID tokens.

0124In some embodiments, the APV computer system is configured to first make a signature request to the ID over the protected communication channel SM [CA] # 2 for all generated partial attribute specifications (ie, the second AR1, third AR2, fourth AR3, etc. attribute specification) Token sends. The signature request may be communicated to the ID token along with the partial attribute specifications. The ID token signs (optional: after an explicit confirmation of the signature by the user eg by a PIN entry) each of the partial attribute specifications. The APV computer system receives the signed partial attribute specifications AR1_sign, AR2_sign, AR3_sign, ..., or only the respective generated signature from the ID token and forwards the signed partial attribute specifications or signatures respectively to that of the AP computer systems, which is designed to provide the relevant partial attribute specification. Each of the AP computer systems thus receives "its" partial attribute specification from the APV computer system in a form signed by the ID token and, before it determines the attributes specified in it, checks the validity of the signature, eg by means of a public signature verification key ID token is assigned. For example, the token may already be configured by the user to automatically automatically sign attribute specifications provided by a particular APV computer system or affecting a particular attribute class.

0125This method is advantageous because the individual AP computer systems can check whether the attributes have been legitimately requested (ie with the user's knowledge and will) even before they establish a communication connection with the ID token or provide the corresponding attributes. This reduces the consumption of computing capacity by the AP computer systems and speeds up the process. In addition, the structure of the channel or the attribute determination can be omitted from the outset in case of signature disability. It is also advantageous for data protection that signature invalidation does not result in read or write access to the protected memory of the ID token.

0126In an alternative embodiment, each AP computer system itself verifies that the attributes were really requested with the user's knowledge and will. After an AP computer system (eg, AP1) has received a corresponding partial attribute specification (eg, AR1) from the APV computer system and has established a secure communication channel (eg, SM [CA] # 3) to the ID token, the AP computer system sends the part Attribute specification over the protected channel to the ID token along with a signature request. The ID token is signed, optionally after an explicit confirmation of the signature by the user, eg by a PIN entry, the partial attribute specification. The AP computer system receives the signed partial attribute specifications AR1 from the ID token over the protected channel (eg SM [CA] # 3) and performs a signature check of the signed partial attribute specification, eg by means of a public signature check key of the ID token. The AP computer system determines the ones in the signed partial attribute specification only if the signature is valid.

0127This method has the advantage that each AP computer system can individually determine whether a signature check should be performed before the attributes are provided, so that greater flexibility of the data security is possible, for example, depending on the confidentiality of the attributes to be provided. However, this procedure initially builds the secure channel between the AP computer system and the ID token, regardless of whether the token will sign the attribute specification or not. In addition, there is a risk that other (partial) attribute specifications, or even attributes that may be stored in the token, will be read by the AP computer system.

0128In some embodiments, the computer system that creates the signature request (ie, the APV computer system or an AP computer system 172, 173, 174) generates a signature confirmation request and sends this signature confirmation request to the user computer system 100. The signature confirmation request is a request to the user 102 the user computer system, which is also assigned to the ID token to approve the signing of an attribute specification by the ID token. For example, the signature confirmation request may contain an indication of the attributes requested by the service and specified in an attribute specification that is displayed to the user via the display of the user computer system. A signature confirmation request allows the user to explicitly grant permission to the ID token to sign an attribute specification in response to a signature request. The permission can be obtained, for example, by the user computer system requesting the user to enter a PIN in order to use it to authenticate himself to the ID token as the owner of the ID token. If the user grants the permission to sign an attribute specification, the ID token signs the attribute specification for which the signature confirmation of the user 102 is present.

0129The ID token generates the signature each time by executing program instructions 135 by the processor 128 of the ID token 106 forming a generator for generating digital signatures, using, for example, the private key 122 of the ID token. The signature authorization request can be configured as a request for a signature PIN from the user 102. The PIN input may be, for example, via a user interface, such as a keyboard of the user computer system 100 or the reader 101. To enable the execution of the program instructions 135, the ID token 106 checks whether the identifier entered by the user 102 matches the reference value for the signature PIN (SPIN) stored in the memory 118 stored in the protected memory area 121.

0130The ID token 106 sends the signed second attribute specification or only the signature thereof to the AP1 computer system 172. The AP1 computer system 172 checks the validity of the signature and determines the attributes specified therein only if the check reveals that the signature is valid , In an analogous manner, the further AP computer systems 173, 174, 1722 can also obtain and check a signature of the respectively read attribute specifications and, if necessary, in the case of the validity of the signature, determine the attributes specified in the respectively obtained attribute specification. After mutual authentication of the respective AP computer system and the ID token, a corresponding protected communication channel SM [CA] # 3, SM [CA] # 4, SM [CA] # 5 is set up via which the attributes are written into the ID token. Upon successful writing, the respective AP computer system sends an acknowledgment signal S1-Sn to the APV computer system. The further steps, including sending a termination signal to the service computer system, are for example in the description of<figref idref="f0004">Fig. 4</figref> explained.

0131In response to receiving the termination signal, the service computer system may retrieve the attributes stored in the memory 118 of the ID token via the ID provider module 136 from the ID token and provide the service requested with the service request 103. The service computer system receives the attributes from the ID provider module 136 over a network, such as the Internet, in particular when the module 136 is a self-contained ID provider computer system, in accordance with some embodiments. Alternatively, the attributes may also be communicated to the service or program modules associated with the service of the service computer system via a system bus of a service computer system, eg if the ID provider module is an integral part of the service computer system.

0132The AP computer systems 172, 173, 174, 1722 ... may be constructed analogously to the ID provider module 136, that is, they each have a network interface 138, a processor 145 for executing program instructions 146, 148 and a memory 140 in which a certificate and a private key are stored. The certificate is preferably an authorization certificate in each of which an authorization for write access to the ID token 106 or individual sectors is specified.

0133The APV computer system 199 preferably has only rights to read the first attribute specification from the ID token, but has no right to store an attribute specification itself in the ID token or to read already stored attributes (in particular of other sectors).

0134Preferably, the user computer system 100 also has neither read nor write permissions to the attribute specifications and attributes of the ID token.

0135In addition to the first attribute provider computer system 172, which can provide attributes of a particular class, for example, address data, the distributed system also includes other attribute provider computer systems 1722 that are also configured to provide attributes of the same class as that first attribute provider computer system 172. For example, if the AP computer system 172 is unable to provide all of the attributes specified in the second attribute specification AR1, the AP computer system 172 generates a new version of the second attribute specification AR1 'which only specify those attributes of the original second attribute specification AR1 that could not be provided by the AP computer system 172. The user computer system 100 or

0136<figref idref="f0004"><b>FIG. 4</b></figref> shows a schematic representation of a method according to embodiment of the invention.

0137In step (1), the user computer system 100 sends a service request 103 from a user 102 via a network 116 to a service computer system 150 that is coupled to an ID provider module 136. For this purpose, for example, the user enters a URL in an Internet browser of his user computer system in order to set up a so-called Internet session with the service computer system. The service computer system may be, for example, an online shop or other e-commerce portal, or a government server providing an e-government application. The service request of the user may be the transmission of a purchase decision of the user, which the user for example by clicking a virtual control on the website of the service computer system, such as "buy" or "buy now", wherein this service request can be transmitted as an http request or https request via the Internet session to the service computer system, for example. An eGovernment application may analogously be the service request for the transmission of a request of the user of an official procedure, such as the issuing of a registration certificate, the registration of a motor vehicle or the notification of a change of residence or the like.

0138The service computer system requires attributes of the user for the service requested with the service request, and also attributes of the ID token itself, depending on the application. These may be specified by the service computer system in a first attribute specification 105 ("AR"). For example, the first attribute specification may include the attributes name, date of birth, address of the user, account number of the user, creditworthiness of the user and validity period of the ID token. The attributes according to this first attribute specification thus require the service computer system to provide the service to the user.

0139In response to receiving the service request, the service computer system 150 at step 304 sends the first attribute specification 105 to the ID provider module 136. The first attribute specification specifies those attributes that the service computer system requires to provide the requested service. The transmission can take place via the network. Alternatively, the ID provider module is an integral part of the service computer system, such that sending the first attribute specification occurs, for example, via an internal data bus or a LAN connection.

0140In a further step, the user 102 authenticates himself to the ID token. For this purpose, the user enters a secret identifier, such as the so-called Personal Identification Number (PIN). Depending on the embodiment, this can be done directly by input to the ID token, by input to the reader or by input to the user computer system. Preferably, the authentication of the user with respect to the ID token by means of a "remote verification", which here any method is understood in which the identifier to be checked is not entered directly into the ID tokens to compare with the identifier stored there, but in which the check is made by means of a protocol involving the reader and the ID token, in which the identifier entered in the reader is does not have to be transferred to the ID token. Such protocols are well known in the art, such as Strong Password Only Authentication Key Exchange (SPEKE), Diffie-Hellman Encrypted Key Exchange (DH-EKE), Bellovin-Merritt Protocol or Password Authenticated Connection Establishment (PACE). For example, the SPEKE protocol is known<u>www.jablon.ora / speke97.html</u>. <patcit id="pcit0010" dnum="US6792533B2"><text>US 6,792,533 B2</text></patcit> and <patcit id="pcit0011" dnum="US7139917B2"><text>US 7,139,917 B2</text></patcit>, Among other things also out<u>www.jablon.org/speke97.html</u> the DH-EKE protocol is known. Among other things<patcit id="pcit0012" dnum="US5241599A"><text>US 5,241,599</text></patcit> is the Bellovin-Merritt protocol known. The PACE protocol is known from Technical Guideline TR-03110 of the Federal Office for Security in Information Technology, which is particularly suitable for elliptic curve cryptography, cf.<patcit id="pcit0013" dnum="DE102007000587A1"><text>DE 102007000587 A1</text></patcit> and <patcit id="pcit0014" dnum="DE102013202001A1"><text>DE 102013202001 A1</text></patcit>, In addition to the user, the user computer system preferably also authenticates to the ID token, wherein in step (2) there is also a locally secured transmission channel SM [PACE], ie a so-called secure messaging channel, between the ID token and the user Computer system can be established, for example, by a session key according to a Diffie-Hellman protocol between the ID token and the user computer system is agreed. The local transmission channel is thus now the active transmission channel.

0141The ID provider module and the ID token mutually authenticate each other. For example, the ID provider module authenticates over the ID token over the network 116, and preferably also grants its read or write permission by, for example, transmitting its entitlement certificate over the network to the ID token. The ID token also authenticates to the ID provider module, that is, both the so-called terminal authentication (TA) of the ID provider module against the ID token in step (3) and the chip authentication (CA ) of the ID token, that is, the chip included in the ID token with the processor, opposite the ID provider module in step (4). The TA and the CA can be performed in accordance with BSI TR-03110.

0142In this case, in step (5) a first secured transmission channel SM [CA] # 1 can be set up according to a secure messaging method in that a session key is interposed between the ID token and the ID provider at the TA and / or the CA. Module for end-to-end encryption, with the local protected transmission channel remaining intact.

0143After successful mutual authentication, in an optional step, the ID provider module can perform a read access to the ID token to retrieve the attributes required by the service. If the required attributes can not be read, or by default, in step 6 the ID provider module writes the first attribute specification AR 105 into a protected memory area of ​​the ID token. When the AR is stored in the non-volatile memory of the ID token, an attribute specification stored from previous protocol sessions can be replaced. The ID provider module then generates a first switchover command. The first switch command is sent from the ID provider module to the ID token over the first protected transmission channel. The switch command causes a switchover from the first protected transmission channel SM [CA] # 1 to the local protected transmission channel SM [PACE] in step (7). In addition, after the service computer system successfully stores the first attribute specification in the ID token via the ID provider module, it generates a "first message" containing the information that a first attribute specification is stored in the ID token, the attributes of which are not could be read from the token and that needs to be edited. The first message is transmitted from the service computer system to the user computer system. In addition, after the service computer system successfully stores the first attribute specification in the ID token via the ID provider module, it generates a "first message" containing the information that a first attribute specification is stored in the ID token, the attributes of which are not could be read from the token and that needs to be edited. The first message is transmitted from the service computer system to the user computer system. In addition, after the service computer system successfully stores the first attribute specification in the ID token via the ID provider module, it generates a "first message" containing the information that a first attribute specification is stored in the ID token, the attributes of which are not could be read from the token and that needs to be edited. The first message is transmitted from the service computer system to the user computer system.

0144In step (8), in response to receiving the first message, the user computer system sends a trigger signal T1 with the address of the token to an APV computer system 199. The first trigger signal does not contain any information regarding the attributes requested by the service and thus does not include the first attribute specification still parts of it. Thus, the confidentiality of the requested attributes and also the type of requested service is guaranteed if the trigger signal should be intercepted by unauthorized third parties. However, the trigger signal T1 includes an address # 106 of the ID token 106, for example, a URL in combination with a port number that allows the first attribute provider computer system to contact the ID token and initiate mutual authentication , This causes the APV computer system to perform a TA and a CA with the ID token in steps (9) and (10) as already described and, after successful mutual authentication in step (11), a second protected communication channel SM [CA] # 2 build. In this case, a second secure transmission channel SM [CA] # 2 can be established with end-to-end encryption between the ID token and the APV computer system, whereby the first protected transmission channel is deactivated.

0145In step (12), the APV computer system reads out the first attribute specification AR from the ID token over the second protected channel, analyzes it, divides it into a plurality of partial attribute specifications AR1, AR2, AR3, and identifies a plurality of AP computer systems 172. 173, 174 capable of providing the attributes specified in the specification AR. For example, address data from AP computer system 172, credit-worth information may be provided by AP computer system 173.

0146In several subsequent steps (13),..., (14), the APV computer system forwards each of the partial attribute specifications to one of the determined AP computer systems together with an ID tokens address 106 #, and in each case initiates the ID Token via a switching command SC [CA] PACE to reactivate the local communication channel, so that can be done via this mutual authentication of the ID token and the corresponding AP computer system. The ID token and each of these AP computer systems each build a protected channel to each other via which the attributes determined by the AP computer system according to the respectively received partial attribute specification are written into the protected memory area of ​​the ID token (in<figref idref="f0004">Fig. 4</figref>: dashed box). For example, after a successful mutual authentication between the first AP computer system 172 and the ID token 106, a secured transmission channel SM [CA] # 3 is established between the two communication partners by means of end-to-end encryption. Preferably, the first protected transmission channel SM [CA] # 1 remains and is inactivated. In the course of mutual authentication, preferably both a terminal authentication (TA) and a chip authentication (CA) are performed. The first AP computer system determines the attributes specified in the second attribute specification and writes them into a protected memory area of ​​the IT token 106.

0147When the APV computer system has received from all AP1 APn computer systems to which a partial attribute specification has been sent an acknowledgment signal S1-Sn confirming the successful writing of the respective determined attributes in the ID token, the APV computer system sends Termination signal SAPV to the user computer system, which in turn sends a Umschaltkommando to reactivate the first communication channel to the ID token and a "second" message to the service computer system. The second message states that the attributes are now available and can be read from the token. In step (15), in response to the switching command, the ID token reactivates the first protected communication channel SM [CA] # 1, thereby enabling the ID-provider module of the service computer system,

0148Switching to the protected first transmission channel SM [CA] # 1 can be done, for example, such that the ID token "automatically" falls back to the local secure channel SM [PACE] after the write access of an AP computer system, ie after a successful write access automatically re-enabled the local secure channel. The user computer system, upon receipt of a termination signal SAPV, switches from the channel of the last-write AP computer system (or the local secure communication channel) to the secure first transmission channel SM [CA] # 1 by sending a switching command UK over the local transmission channel SM [ PACE] to the ID token, thereby causing the ID token to switch to the first secure transmission channel.

0149Optionally, in step (17), the service computer system may send another switchover command to the ID token to reactivate the local channel. In step (18), the service computer system provides the requested service if the read attributes are valid.

0150Possible advantageous embodiments include the following feature combinations:<ol id="ol0001" ol-style=""><li>A method of reading attributes from an ID token associated with a user, the ID token comprising non-volatile electronic memory having a protected memory area, wherein access to the protected memory area is possible only via a processor of the ID token is, with the following steps:<ul><li>Sending a service request of a user from a user computer system to a service computer system coupled to an ID provider module;</li><li>In response to receiving the service request, sending a first attribute specification from the service computer system to the ID provider module, wherein the first attribute specification specifies the attributes that the service computer system needs to provide the service requested with the service request, and reciprocal Authentication of the ID provider module and the ID token;</li><li>Upon successful mutual authentication of the ID provider module and the ID token, writing the first attribute specification to the protected memory area of ​​the ID token by the ID provider module and sending a first message that the first attribute specification was written, of the Service computer system to the user computer system;</li><li>In response to receiving the first message, sending a trigger signal from the user computer system to an APV computer system, the APV computer system being an attribute provider directory computer system, wherein the first trigger signal is free from the first attribute specification and their parts and an address of the ID token includes;</li><li>In response to receipt of the trigger signal, mutual authentication of the APV computer system and the ID token using the address;</li><li>Upon successful mutual authentication of the APV computer system and the ID token, reading the first attribute specification from the protected memory area of ​​the ID token and dividing the read first attribute specification into at least a second and a third attribute specification by the APV computer system;</li><li>Sending the second attribute specification and the address from the APV computer system to a first AP computer system configured to provide the attributes specified in the second attribute specification, wherein the first AP computer system is a first attribute provider computer system, and transmitting the third and each further attribute specification and the address of the ID token from the APV computer system to each another AP computer system each adapted to provide the attributes specified in the third or further attribute specification;</li><li>In response to receipt of the second attribute specification and the address by the first AP computer system, determination of a first set of attributes specified in the second attribute specification and initialization of mutual authentication of the first AP computer system and the ID token using Address;</li><li>After the mutual authentication of the first AP computer system and the ID token, writing the first attribute set by the first AP computer system to the protected memory area of ​​the ID token and sending an acknowledgment signal from the first attribute provider computer system to the attribute provider Directory computer system;</li><li>Upon receipt of an acknowledgment signal indicating that the respective AP computer system could fully provide the attribute set to be determined by it and write to the protected memory of the ID token, from the first and each of the further AP computer systems, sending a termination signal from the APV computer system to the user computer system;</li><li>In response to receipt of the termination signal, sending a second message from the user computer system to the service computer system to cause the service computer system to retrieve the written attribute sets from the protected storage area via the first ID provider module.</li></ul></li><li>2. The method of item 1, wherein the ID token is free of software or hardware-based program logic, which is adapted depending on the content of the protected memory area, the establishment of new or the activation of existing communication channels to the user computer system, the ID Provider module, the APV computer system, and / or the first AP computer system.</li><li>3. Method according to one of the preceding points, further comprising:<ul><li>After successful mutual authentication of ID provider module and ID token, initialization of the construction of a first protected transmission channel between the ID provider module and the ID token by the ID provider module, wherein the writing of the first attribute specification via the first protected transmission channel takes place;</li><li>Upon successful mutual authentication of the APV computer system and ID tokens, initialization by the APV computer system of the establishment of a second protected transmission channel between the APV computer system and the ID token, wherein reading the first attribute specification from the protected memory area of ​​the ID token via the second protected transmission channel;</li><li>After successful mutual authentication of the first AP computer system and ID token, initialization of the construction of a third protected transmission channel between the first AP computer system and the ID token by the first AP computer system, wherein writing the first attribute set to the protected memory area of ​​the first AP computer system ID token over the third protected transmission channel takes place;</li><li>wherein the writing of all other attribute sets, each determined by one of the other AP computer systems, in the protected area of ​​the ID token only after successful mutual authentication of the respective other AP computer system and the ID token and only one after mutual authentication each constructed further protected transmission channel takes place.</li></ul></li><li>4. The method of item 3, wherein data transmitted over the first, second or third protected transmission channel is protected from access by the user computer system.</li><li>5. The method of item 3 or 4, wherein the structure of the first protected transmission channel comprises:<ul><li>Establishing or reactivating a local protected transmission channel between the user computer system and ID tokens;</li><li>Performing mutual authentication of the user computer system and ID token to establish the first protected transmission channel, wherein authentication data is transmitted over the local protected transmission channel.</li></ul></li><li>6. The method according to any preceding item, further comprising:<ul><li>In response to receipt of the termination signal, sending a toggle command from the user computer system to the ID token to enable the ID token to activate the first protected transmission channel;</li><li>Reading out the written attribute sets from the protected memory area by the ID provider module via the activated protected first transmission channel.</li></ul></li><li>7. Method according to one of the previous points, further comprising:<ul><li>After writing the first attribute specification in the protected memory area, sending a toggle command from the APV computer system to the ID token over the first protected communication channel, the toggle command causing the ID token to activate the local protected transmission channel; and or</li><li>In response to receipt of the termination signal by the user computer system, sending another switchover command over the activated local broadcast channel, the further switchover command causing the ID token to activate the first protected broadcast channel</li><li>Reading out the written attribute sets from the protected memory area by the ID provider module via the activated protected first transmission channel.</li></ul></li><li>8. The method according to any one of items 3-7, further comprising:<ul><li>After writing the first set of attributes in the protected memory area, sending a toggle command from the first AP computer system to the ID token over the third protected communication channel, the toggle command causing the ID token to activate the local protected transmission channel;</li><li>Use of the activated local protected transmission channel to transmit authentication data over the local protected transmission channel in the course of the mutual authentication of the next used one of the further AP computer systems and the ID token.</li></ul></li><li>9. The method of any one of items 3-8, further comprising:<ul><li>Storing the cryptographic keys used to build each of the protected channels</li><li>wherein the ID token is configured to enable and disable each of the protected transmission channels in response to a switching command, wherein activation includes reusing the stored cryptographic key of the transmission channel to be activated.</li></ul></li><li>10. The method according to any preceding item, further comprising:<ul><li>Analyzing the first attribute specification by the APV computer system to determine all classes of attributes to which at least one of the attributes specified in the first attribute specification belongs; and</li><li>Determining the first, second, and each other of the AP computer systems as those AP computer systems configured to provide user-related attributes of one of the determined attribute classes.</li></ul></li><li>11. Method according to one of the preceding points,<ul><li>wherein the APV computer system is adapted to identify a plurality of first AP computer systems each configured to provide attributes of a particular attribute class; and</li><li>wherein the sending of the second attribute specification and the address is selective to that of the identified first AP computer systems having a higher value than the other identified first AP computer systems in one of the following criteria:<ul><li>∘ number of attributes specified in the second attribute specification that can be provided;</li><li>∘ granted confidence level of the provided attributes,</li><li>∘ amount of currently available computing resources;</li><li>∘ Level of reliability and availability of the identified first AP computer system.</li></ul></li></ul></li><li>12. Method according to item 11,<ul><li>wherein each of the identified first attribute provider computer systems can provide only a portion of the attributes specified in the second attribute specification;</li><li>wherein the APV computer system, in multiple iterations, each cause one of the identified first AP computer systems to provide as many as possible of the attributes specified in the second attribute specification and to store in the ID token and cause a new version of the second for the next iteration Attribute specification in the ID token, the new version selectively containing only those attributes of the original second attribute specification that were not provided in any of the iterations performed so far.</li></ul></li><li>13. The method of any preceding item, wherein the address of the ID token includes a URL that allows access to the ID token over the network by means of a reader coupled to the user computer system, the URL containing the address of the ID. Includes tokens.</li><li>14. Method according to one of the preceding points, further comprising:<ul><li>Transmitting a first signature request from the first AP computer system to the ID token to generate a digital signature of the second attribute specification;</li><li>Generating the digital signature of the second attribute specification by the ID token;</li><li>Transmitting the generated digital signature to the first AP computer system;</li><li>Checking the transmitted digital signature by the first AP computer system with a public signature verification key, wherein the determination of the first set of attributes according to the second attribute specification by the first AP computer system and the storage of the first set of attributes in the ID token only if the check shows that the digital signature is valid.</li></ul></li><li>15. The method of item 14, wherein in the protected memory area of ​​the ID token for each of the AP computer systems is stored a separate private signing key associated with one of the AP computer systems, each of the AP computer systems having access to a public signature verification key which forms an asymmetric cryptographic key pair with the private signing key associated with the AP computer system, wherein the public signature verification key is adapted to check the validity of a digital signature generated by the corresponding private signing key.</li><li>16. Method according to one of the preceding points, wherein the ID token has a communication interface for communication with a reading device of the user computer system,<ul><li>wherein the communication interface of the ID token for wireless communication and for the wireless coupling of energy into the ID token by the reader is designed to provide the ID token with the required for its operation electrical energy; and or</li><li>wherein the ID token comprises a volatile electronic memory in which the first attribute specification is stored so that the first attribute specification is deleted from the volatile electronic memory when the ID token is removed from the range of the reader, and wherein the due to the write access the first and second AP computer systems are stored in the ID token stored first and second sets of the attributes in the nonvolatile electronic memory, so that they can be accessed by a subsequent further read access due to another service request; or</li><li>alternatively storing the first attribute specification and the first and second sets of the attributes in the non-volatile memory.</li></ul></li><li>17. The method according to one of the preceding points, with: request of the user to enter a signature PIN for the activation of a signature function of the ID token for the generation of a digital signature of the first, second and / or third attribute specification by the reader or the user computer system.</li><li>18. Method according to one of the preceding points,<ul><li>wherein the authentication of the ID provider module with respect to the ID token takes place by means of an authorization certificate of the ID provider module in which reading rights of the ID provider module for reading attributes from the ID token are specified, whereby the ID ID Provider Module read access token tests the read authorization of the ID provider module using the authorization certificate; and</li><li>wherein the authorization certificate specifies write permissions of the ID provider module for writing the first attribute specification in the ID token, wherein the ID token for the write accesses of the ID provider module, a check of the write authorization of the ID provider module using the Authorization certificate.</li></ul></li><li>19. Method according to one of the preceding points,<ul><li>wherein the authentication of the first AP computer system to the ID token is performed using an authentication certificate of the first AP computer system specifying write permissions of the first AP computer system to write the first set of attributes in the ID token; and</li><li>wherein the ID token performs a write authorization of the first AP computer system using the authorization certificate before the ID token authorizes the first AP computer system to write the first attribute set.</li></ul></li><li>20. The method of item 19, wherein the entitlement certificate of the first AP computer system is:<ul><li>neither assigns the first AP computer system permission to read the first attribute specification nor to read attributes stored in the protected memory area of ​​the ID token; or</li><li>grant the first AP computer system permission to read only a particular portion of the first attribute specification that selectively specifies only attributes of a particular attribute class.</li></ul></li><li>21. Method according to one of the preceding points 19-20,<ul><li>wherein the protected memory area of ​​the ID token contains a plurality of sub-areas, each of the sub-areas being specifically associated with an attribute class,</li><li>wherein the ID token enables read and / or write access of the first AP computer system to one of the subregions only if the entitlement certificate of the first AP computer system includes proof of read and / or write permission for that subarea; and</li><li>wherein the authorization certificate of the first attribute provider computer system grants the first AP computer system authorization to write the second attribute set and optionally also to read attribute specifications only to those of the subregions to which the attribute class is assigned, for the provision of which the first attribute provider is trained.</li></ul></li><li>22. Method according to one of the preceding points, wherein the ID token is a value or security document, in particular an identity document, that is to say an ID document, in particular an electronic identity card, passport, driving license, Company card or a means of payment, such as a banknote, a credit card or other credentials, such as an entrance ticket, a bill of lading or a visa, in particular a smart card, especially with RFID and / or NFC interface.</li><li>23. ID tokens assigned to a user, the ID token having an electronic memory with a protected memory area in which attributes are stored, wherein access to the protected memory area is possible only via a processor of the ID token, wherein the ID token comprises a communication interface for communicating with a reader of a user computer system, wherein the user computer system is coupled to an ID provider module via a network, and wherein the ID token is configured to perform the following steps:<ul><li>Mutual authentication of the ID provider module and the ID token in interoperation with the ID provider module;</li><li>Establishing a first protected transmission channel with end-to-end encryption between the ID token and the ID provider module over the network;</li><li>Receiving a first attribute specification from the ID provider module and storing the received first attribute specification in a protected storage area of ​​the ID token, the first attribute specification specifying those attributes that the service computer system requires to provide the service requested with the service request;</li><li>Mutual authentication of an APV computer system and the ID token;</li><li>Upon mutual authentication of the APV computer system and the ID token, examining an APV computer system specific entitlement certificate to determine if the APV computer system is authorized to read the first attribute specification from the protected storage area; If the APV computer system is authorized to read the first attribute specification, permitting read access to read the first attribute specification to allow the APV computer system to split the read first attribute specification into at least one second and one third attribute specification;</li><li>Mutual authentication of a first AP computer system configured to provide attributes, the attributes specified in the second attribute specification, and the ID token;</li><li>Upon mutual authentication of the first AP computer system and the ID token, checking a first AP computer system-specific authentication certificate to determine if the first AP computer system is authorized to read the first attribute specification from the protected memory area; If the first AP computer system is authorized to write attributes in the protected memory area of ​​the ID token, permission of the write access of the first AP computer system to the protected memory area to store a first attribute set in the ID token, wherein the first set of attributes which are specified in the second attribute specification and determined by the first attribute provider computer system.</li></ul></li><li>24. The ID token of item 23, wherein the ID token is adapted to mutually authenticate with a second and one or more other AP computer systems each adapted to provide attributes of a particular attribute class, the ID Token hereby receives from the authenticating attribute provider computer systems an AP computer system specific authorization certificate and uses this for authentication checking for each write access for writing attribute sets.</li><li>25. ID token according to item 23 or 24,<ul><li>wherein the communication interface of the ID token for wireless communication and for the wireless coupling of energy into the ID token by the reader is designed to provide the ID token with the required for its operation electrical energy; and or</li><li>wherein the ID token comprises a volatile electronic memory in which the first attribute specification is stored so that the first attribute specification is deleted from the volatile electronic memory when the ID token is removed from the range of the reader, and wherein the due to the write access the first and second AP computer systems are stored in the ID token stored first and second sets of the attributes in the nonvolatile electronic memory, so that they can be accessed by a subsequent further read access due to another service request; or</li><li>alternatively storing the first attribute specification and the first and second sets of the attributes in the non-volatile memory.</li></ul></li><li>26. An AP computer system having a network interface for accessing an ID token over a network, the AP computer system being an attribute provider computer system and configured to perform the following steps:<ul><li>Receiving from a APV computer system a second attribute specification that is a subset of the attribute specification generated in a first attribute specification generated by a service computer system, the APV computer system being an attribute provider directory computer system configured to divide the first attribute specification into the second and further attribute specifications are formed, and receiving an address of the ID token from the APV computer system;</li><li>In response to receipt of the second attribute specification and the address, determination of a first set of attributes specified in the second attribute specification, and initialization of mutual authentication of the AP computer system and the ID token using the address;</li><li>After mutually authenticating the AP computer system and the ID token, establishing a protected communication channel, writing the first attribute set by the AP computer system over the protected communication channel to the protected memory area of ​​the ID token; and</li><li>Sending an acknowledgment signal indicating whether the AP computer system was able to fully deploy the first set of attributes and write to the protected memory of the ID token from the AP computer system to the APV computer system.</li></ul></li><li>27. The AP computer system of item 26, wherein the AP computer system is configured to perform the following steps:<ul><li>Transmitting a signature request to the ID token for causing the ID token to digitally sign the second attribute specification,</li><li>Receiving the signature of the second attribute specification by the AP computer system from the ID token;</li><li>Performing a signature check of the signed second attribute specification;</li><li>wherein the first attribute set specified in the read second attribute specification is determined by the AP computer system and stored in the ID token only if the signature check determines that the signature of the second attribute specification is valid, and preferably the signature request and the signature over the protected communication channel between the ID token and the AP computer system.</li></ul></li><li>28. AP computer system according to any one of items 26-27, with an authentication certificate for authentication to the ID token,<ul><li>wherein rights of the AP computer system for writing the first attribute set into the ID token are specified in the authorization certificate,</li><li>wherein the entitlement certificate preferably does not allow the AP computer system read access to attributes stored in the ID token;</li><li>wherein the authorization certificate optionally includes rights of the AP computer system to read and write different versions of the second attribute specification; and or</li><li>wherein preferably the read and / or write permission relates selectively only to a subregion of the memory area of ​​the ID token assigned to an attribute class that the AP computer system is configured to provide.</li></ul></li><li>29. APV computer system connected via a network to a user computer system, a first AP computer system and a second AP computer system, wherein the user computer system is coupled via a reader to an ID token, which is a non-volatile electronic Storage having a protected storage area, wherein access to the protected storage area is only possible via a processor of the ID token, wherein the APV computer system is an attribute provider directory computer system and is configured to:<ul><li>Receiving a trigger signal from the user computer system, wherein the first trigger signal is free of a first attribute specification and its parts and includes an address of the ID token, wherein the first attribute specification specifies user-related attributes that are requested by a user of the user computer system Service required for its provision;</li><li>In response to receipt of the trigger signal, mutual authentication of the APV computer system and the ID token using the address;</li><li>Upon successful mutual authentication of the APV computer system and the ID token, reading the first attribute specification from the protected memory area of ​​the ID token and dividing the read first attribute specification into at least a second and a third attribute specification by the APV computer system;</li><li>Sending the second attribute specification and the address from the APV computer system to a first AP computer system configured to provide the attributes specified in the second attribute specification, wherein the first AP computer system is a first attribute provider computer system, and transmitting the third attribute specification and the address of the ID token from the APV computer system to the second AP computer system configured to provide the attributes specified in the third attribute specification;</li><li>In response to receipt of acknowledgment signals indicating that the first, second, and each further AP computer system that has received from the APV computer system a subset of the first attribute specification fully provides the attribute set to be determined by that AP computer system, and written in the protected memory of the ID token, sending a termination signal to the user computer system.</li></ul></li><li>30. Computer system with<ul><li>an ID token according to one of the preceding points 23-25,</li><li>with a first and a second AP computer system according to one of the points 26-28,</li><li>an APV computer system under point 29;</li><li>a user computer system coupled via a reader to the ID token and via a network to a service computer system and at least to the APV computer system; and</li><li>an ID provider module, wherein the ID provider module is part of the service computer system or is operatively coupled to the service computer system via a network.</li></ul></li></ol>

LIST OF REFERENCE NUMBERS

0151<dl id="dl0002" compact="compact"><dt>100</dt><dd>User computer system</dd><dt>101</dt><dd>reader</dd><dt>102</dt><dd>user</dd><dt>103</dt><dd>service request</dd><dt>104</dt><dd>Reader interface</dd><dt>105, AR</dt><dd>first attribute specification</dd><dt>106</dt><dd>ID token</dd><dt>108</dt><dd>interface</dd><dt>110</dt><dd>processor</dd><dt>112</dt><dd>program instructions</dd><dt>113</dt><dd>volatile memory</dd><dt>114</dt><dd>Network interface</dd><dt>116</dt><dd>network</dd><dt>118</dt><dd>electronic memory</dd><dt>120</dt><dd>protected storage area</dd><dt>122</dt><dd>protected storage area</dd><dt>124</dt><dd>protected storage area</dd><dt>126</dt><dd>storage area</dd><dt>128</dt><dd>processor</dd><dt>130</dt><dd>program instructions</dd><dt>131</dt><dd>program instructions</dd><dt>132</dt><dd>program instructions</dd><dt>134</dt><dd>program instructions</dd><dt>136</dt><dd>ID provider module</dd><dt>138</dt><dd>Network interface</dd><dt>140</dt><dd>Storage</dd><dt>142</dt><dd>private key</dd><dt>144</dt><dd>certificate</dd><dt>145</dt><dd>processor</dd><dt>146</dt><dd>program instructions</dd><dt>150</dt><dd>Service computer system</dd><dt>152</dt><dd>Network interface</dd><dt>154</dt><dd>processor</dd><dt>156</dt><dd>program instructions</dd><dt>172-174</dt><dd>Attribute provider computer systems</dd><dt>175</dt><dd>Database</dd><dt>176, 179</dt><dd>attributes</dd><dt>180</dt><dd>second message</dd><dt>181</dt><dd>display</dd><dt>182</dt><dd>operating element</dd><dt>183</dt><dd>Storage</dd><dt>199</dt><dd>Attribute provider directory computer system</dd><dt>AR1</dt><dd>second attribute specification</dd><dt>AR2</dt><dd>third attribute specification</dd><dt>AR3</dt><dd>fourth attribute specification</dd><dt>S1-S3</dt><dd>confirmation signals</dd><dt>A1</dt><dd>first set of attributes according to AR1</dd><dt>A2</dt><dd>second set of attributes according to AR2</dd><dt>A3</dt><dd>third set of attributes according to AR3</dd><dt>T1</dt><dd>trigger signal</dd><dt>202-238</dt><dd>steps</dd><dt>SM [PACE] PACE</dt><dd>local transmission channel</dd><dt>SM [CA] # 1</dt><dd>first protected transmission channel</dd><dt>SM [CA] # 2</dt><dd>second protected transmission channel</dd><dt>SM [CA] # 3</dt><dd>third protected transmission channel</dd><dt># 106</dt><dd>Address ID tokens 106</dd><dt>SC [CA] #PACE</dt><dd>Changeover command to SM [PACE]</dd><dt>SC [CA] # 1</dt><dd>Changeover command to SM [CA] # 1</dd><dt>SC [CA] # 2</dt><dd>Changeover command to SM [CA] # 2</dd><dt>SC [CA] # 3</dt><dd>Changeover command to SM [CA] # 3</dd></dl>