Method for generating a provisioning token by way of a terminal

Abstract

Disclosed is a method for providing a digital provisioning token (112) on a terminal (100) for provisioning a digital document (412) to be issued. The provisioning token (112) demonstrates an authorization to receive the digital document (412) to be issued and is cryptographically coupled to the terminal (100). The terminal (100) generates a first asymmetrical key pair with a first private cryptographic key (108) and a first public cryptographic key (110), receives a first data element (114) assigned to the document (412) to be issued, sends a request containing the first public cryptographic key (110) and the first data element (114) to an ID provider server (130) of an ID provider service for creating an identification data set (142), receives a data set ID (144) of the created identification data set (142) and generates the provisioning token (112) which comprises the data set ID (144) and is signed using the first private cryptographic key (108).

Description

METHOD FOR PROVIDING A PROVISION TOKEN BY A FINAL DEVICE FIELD OF TECHNOLOGY

[0001] The invention relates to a method for providing a digital provisioning token on an end device, a method for issuing a digital document to be issued for the end device using the digital provisioning token of the end device, the end device for providing the digital provisioning token on the end device, an ID provider server for providing the digital provisioning token on the end device, an issuer server for issuing the digital document to be issued for the end device and a system comprising the end device and the ID provider server. STATE OF THE ART

[0002] Mobile devices, such as smartphones, are ubiquitous. They are used in many areas of life and situations to perform a wide variety of tasks in the digital realm or with the aid of digital tools.

[0003] However, it is a technical challenge to provide digital documents in a cryptographically secure manner for such end devices.

[0004] The invention is based on the object of creating a method for cryptographically secure provision of a provisioning token for a digital document.

[0005] The problem underlying the invention is solved by the features of the independent claims. Embodiments of the invention are specified in the dependent claims. SUMMARY

[0006] Embodiments include a method for providing a digital provisioning token on an end device for provisioning a digital to be issued Document. The provisioning token proves authorization to receive the digital document to be issued and is cryptographically linked to the end device.

[0007] The method comprises generating a first asymmetric key pair by the terminal device, which comprises a first public cryptographic key and a first private cryptographic key. The terminal device receives a first data element associated with the document to be issued. The first data element identifies the document to be issued. A request is sent by the terminal device to an ID provider server of an ID provider service to create an identification data record with identification data of a user of the terminal device. The identification data record comprises, for example, a data record ID, the first public cryptographic key of the terminal device, and the first data element.Furthermore, the identification record, as user identification data of the end device, includes, for example, user attributes read from the end device user's ID token and an attribute certificate that assigns the read user attributes to the end device's first public cryptographic key. The request includes the first public cryptographic key and the first data element for entry into the identification record to be created. The end device receives the record ID of the created identification record from the ID provider server and generates the provisioning token. The provisioning token includes the record ID and is signed by the end device during its generation using the first private cryptographic key.

[0008] Implementations can offer the advantage that a provisioning token can be generated by an end device, which is cryptographically linked to the end device or an asymmetric key pair of the end device. This linkage is implemented by signing the provisioning token using the first private cryptographic key of the end device as the signature key. Furthermore, the provisioning token is cryptographically linked by the signature to the identification data record whose record ID is included in the provisioning token. This linkage is implemented using the first public cryptographic key of the end device, which is included in the identification data record and serves as the signature verification key for verifying the signature of the provisioning token.In addition to the assignment by the data record ID, the signature of the provisioning token and the first public cryptographic key included in the identification data record can thus be used to cryptographically verify, by validating the signature, whether the provisioning token and the identification data record or the... The identification data provided by the identification data record belong together. The provisioning token grants authorization to receive a digital document to be issued via a terminal device. This digital document to be issued is identified by the first data element entered into the identification data record cryptographically linked to the provisioning token. Presenting the first data element and the corresponding identification data is a prerequisite for issuing the document; that is, presenting the correct data proves authorization to receive a digital document to be issued.Since the provisioning token is cryptographically linked to the identification data record with the corresponding data, the provisioning token, via the reference to the identification data record by the data record ID, proves authorization to receive the digital document to be issued.

[0009] The record ID encompassed by the provisioning token identifies the identification record without revealing any information about the identification data contained within the identification record or the first data element that identifies the document to be issued. For example, the record ID is a Universally Unique Identifier (UUID). A UUID is a 128-bit number used to identify information in computer systems. When generated using standard methods, UUIDs can be considered globally unique for practical purposes. This means that the probability of a collision is so low that it can be disregarded for practical purposes. The UUID is documented as part of the standard ISO / IEC 11578:1996 and as a separate standard, ISO / IEC 9834-8:2005. Furthermore, the IETF has published RFC 4122, which is based on UUIDs.

[0010] The first data element can, for example, be received via a user input. Likewise, the first data element can, for example, be read from a file received electronically. The first data element, for example, uniquely identifies the document to be issued. For example, the first data element uniquely identifies the document to be issued in combination with an indication of the document type. For example, only a document of the specified document type is to be issued for the first data element. Using the first data element, for example, a first data record in a first database can be identified in which data elements are stored that are to be included in the document to be issued. For example, the first data element itself serves as a database access key, e.g. a Primary key, or for deriving a database access key, e.g., a Primary key.

[0011] For ease of reading, reference is made here and in the following to a single first data element. It is understood that this should be read as at least one first data element, and the corresponding procedural steps can be carried out identically with multiple first data elements that together identify the document to be issued.

[0012] If the document to be issued is an identification document, the first data element could, for example, be one or more user attributes. If the corresponding user attributes are read from an ID token during the identification of the end device user, the read user attributes can be used in addition to the first data element or, if they are identical, replace it. This means that if the following refers to the use of user attributes and a first data element, an identity between the first data element and a user attribute can refer to the use of the corresponding user attribute and the identical first data element. Alternatively, the corresponding user attribute can also replace the first data element, so that no redundant data is used.

[0013] For example, the first asymmetric key pair generated by the terminal device is a document-specific asymmetric key pair, i.e., the terminal device generates a separate asymmetric key pair for each document to be issued or the associated provisioning token.

[0014] For example, the first private cryptographic key is stored as the terminal's signature key for issuing the provisioning token in a protected storage area of ​​the terminal's memory. This protected storage area is, for instance, a storage area to which access is only granted after successful user authentication of the terminal's user.

[0015] In this context, a document is understood to mean in particular an official certificate, such as a birth certificate, a marriage certificate, proof of citizenship, an identity document, in particular a passport, identity card, visa, as well as a driver's license, vehicle registration certificate, or vehicle title.

[0016] Depending on the form of execution, the document to be issued is a Vehicle document, for example an electronic registration certificate part I.

[0017] Implementation methods can have the advantage that a provisioning token can be used to prove authorization to receive an electronic registration certificate Part I to be issued with an end device and to cryptographically couple it to the end device during the issuance process.

[0018] In Germany and Austria, the vehicle registration certificate is an official document confirming the registration of a vehicle for road use. The certificate includes data elements for individualizing the vehicle, generally using the vehicle identification number (VIN) assigned by the manufacturer (also known as the chassis number), for assigning a license plate to a specific person or entity, and for proving that the vehicle meets technical approval requirements, i.e., type approval. The person or entity listed in the vehicle registration certificate is the registered keeper of the vehicle, who may or may not be the same as the owner or possessor.

[0019] In detail, an electronic registration certificate Part I includes, for example, the following data elements: (B) Date of first registration of the vehicle; (2.1) Code for 2; (2.2) Code for D.2 with check digit; (J) Vehicle class; (4) Type of bodywork; (E) Vehicle- Identification number; (3) Check digit of the vehicle identification number; (D1) Make; (D.2) Type / Variant / Version; (D.3) Trade name(s); (2) Manufacturer's abbreviation; (5) Designation of vehicle class and body type; (V.9) Emission class relevant for EC type approval; (14) Designation of national emission class; (P.3) Fuel type or energy source; (10) Code for P.3; (14.1) Code for V.9 or 14; (Pl) Engine displacement in cm³ 3 ; (22) Remarks and exceptions; (L) Number of axles; (9) Number of drive axles; (P.2 / P.4) Rated power in kW / Rated speed at min" 1; (T) Maximum speed in km / h; (18) Length in mm; (19) Width in mm excluding mirrors and attachments; (20) Height in mm; (G) Mass of vehicle in operation in kg; (12) Unladen mass of tank vehicles in m³ 3 ; (13) Vertical load in kg; (Q) Power-to-weight ratio in kW / kg (only for motorcycles); (V.7) CO2 (in g / km) combined value; (Fl) Technically permissible maximum mass in kg; (F.2) Maximum permissible mass in the Member State of registration in kg; (7.1) Maximum axle load axle 1 in kg; (7.2) Maximum axle load axle 2 in kg; (7.3) Maximum axle load axle 3 in kg; (8.1) Maximum axle load axle 1 in kg; (8.2) Maximum axle load axle 2 in kg; (8.3) Maximum axle load axle 3 in kg; (Ul) Stationary noise level in dB(A); (U.2) Engine speed in min 1 to Ul; (U.3) Driving noise in dB(A); (Ol) Technically permissible braked trailer load in kg; (O.2) Technically permissible unbraked trailer load in kg; (Sl) Seating capacity including driver's seat; (S.2) Standing capacity; (15.1) Tires on axle 1; (15.2) Tires on axle 2; (15.3) Tires on axle 3; (R) Vehicle colour; (11) Code for R; (K) EC type-approval or ABE number; (6) Date for K; (17) Operating permit feature; (16) Registration certificate Part II number; (21) Other remarks; (H) Validity period; (I) Date of this registration; (7) Technically permissible maximum axle load / mass per axle group in kg; (7.1) Axle 1 to (7.3) Axle 3; (8) Permissible maximum axle load in the Member State of registration in kg; (8.1) Axle 1 to (8.3) Axle 3; and / or (15) Tires.

[0020] According to embodiments, the first data element is a unique vehicle ID, for example a vehicle registration number or a chassis number.

[0021] Design features can have the advantage of using a unique vehicle ID, such as the vehicle registration number and / or a chassis number.

[0022] A database with database entries containing data elements for documents to be issued may, for example, be an official database or register, particularly a central register. In the case of registration certificates, this may, for example, be the central vehicle register of the Federal Motor Transport Authority.

[0023] For example, the method further comprises receiving a read request by the terminal device for reading the identification data of the identification data record in the form of user attributes of the user of the terminal device from an ID token of the user from an attribute readout server. The read request includes the first public cryptographic key of the terminal device and assigns the first public cryptographic key to the readout process. In response to the read request, the terminal device provides the requested user attributes of the user of the terminal device using the ID token.

[0024] For example, the identification data is read from the end device to create the identification record. Since the read process is associated with the first public cryptographic key, the read identification data is also associated with the first public cryptographic key and thus with the provisioning token signed with the first private cryptographic key. This ensures that the provisioning token is generated for or by the end device through which the user identified themselves during the read process to create the identification record. Since the issuance of the document to be issued or whose receipt only occurs for or by the end device for which the provisioning token is issued, it can thus be ensured that the document is issued for the same end device or that the same end device receives the document via which the user has identified himself.

[0025] For example, the issued document also includes a first public cryptographic key, which is made available by the identification data set. This allows the issued document, which is signed, for example, to be linked to the end device in a cryptographically secure manner. This makes it possible to prevent the issued document from being cryptographically linked to a different end device than the one used to identify the user. This increases the security of the issuing process or of the issued document. In particular, this makes it possible to prevent attack scenarios in which a document is issued using identification data of a first user of a first end device but for a second end device to which the first user has no access or which has nothing to do with the first user. Such an attack scenario would constitute a type of identity theft orThis constitutes theft of the relevant digital document, which should actually be provided to the first identifying user.

[0026] The extraction of identification data constitutes the first step in a two-step process for issuing the document. Extracting the identification data identifies the user, and this data is then assigned to the device used for identification via the first public cryptographic key. In a subsequent step, the document is issued to that device. By ensuring that the document is assigned to the same first public cryptographic key used to extract the identification data, it is guaranteed that a document is only issued to the device that the user has used for identification.

[0027] For example, user attributes are sent to the attribute read server via an encrypted communication connection.

[0028] For example, the ID token is provided by the end device in the form of an ID application, whose program instructions are stored in the end device's memory. The user attributes are stored in a protected memory area of ​​the end device. A prerequisite for providing the requested user attributes is... Successful verification of an authorization credential of the attribute read server to read the requested user attributes.

[0029] The ID token containing the user attributes of the endpoint device can thus be provided by the endpoint device itself. The user attributes are stored securely on the endpoint device, for example, using a security element. For instance, the user attributes are stored in a protected memory area of ​​the security element. Therefore, reading the user attributes is only possible using the security element. Alternatively, the user attributes can be stored on the endpoint device in encrypted form, with one or more cryptographic keys for decrypting the user attributes stored in a protected memory area of ​​the security element. Therefore, access to the user attributes in unencrypted form is only possible using the endpoint device's security element.

[0030] Therefore, reading user attributes from the ID token is not readily possible. Rather, the user attributes are effectively protected against unauthorized access. For example, to read user attributes from the endpoint device—that is, to access the protected storage area of ​​the security element containing the corresponding user attributes and / or the one or more cryptographic keys for decrypting the encrypted user attributes stored on the endpoint device—authorization using an authorization certificate is required. For example, the attribute read server possesses an authorization certificate with which it can prove its authorization to read the user attributes. For example, the authorization certificate assigns a public cryptographic key of an asymmetric key pair to the attribute read server.The attribute reading server also has a private cryptographic key of the asymmetric key pair. For example, the attribute reading server sends a read request to read the user's attributes to the end device or the ID application implemented on the end device. The read request is signed, for example, with the private cryptographic key of the asymmetric key pair. The end device or the ID application checks the validity of the signature of the read request using the authorization certificate or the public cryptographic key provided by the authorization certificate. Upon a successful validity check, the end device or the security element of the end device grants the attribute reading server read access to the user attributes.

[0031] To read the user's attributes from the end device, an encrypted communication connection is established between the end device and the attribute readout server. For example, this communication connection is encrypted using end-to-end encryption.

[0032] For example, the ID token is provided as a standalone device with which the end device communicates via a communication interface. The end device forwards the read request to retrieve the user attributes to the ID token, and in response to the read request, the ID token forwards the requested user attributes to the attribute retrieval server.

[0033] The ID token includes, for example, a processor, memory, and a communication interface for communicating with the end device. This communication interface can be, for example, contactless or contact-based.

[0034] For example, reading the requested user attributes requires successful verification of the attribute retrieval server's authorization to read the requested user attributes using the ID token. For instance, the user attributes are sent from the ID token to the attribute retrieval server via an encrypted communication connection from the end device. This encryption of the communication connection is, for example, end-to-end encryption between the ID token and the attribute retrieval server.

[0035] Reading user attributes from the ID token is therefore not easily possible. Rather, the user attributes are effectively protected against unauthorized reading. For example, the user attributes are stored in a protected memory area of ​​the ID token's memory. For example, access to the protected memory area requires authorization using an authorization certificate. For example, the attribute reading server has an authorization certificate with which it can prove its authorization to read user attributes. For example, the authorization certificate assigns a public cryptographic key of an asymmetric key pair to the attribute reading server. The attribute reading server also has a private cryptographic key of the asymmetric key pair.For example, the attribute read server sends a read request to the user's attributes via the endpoint to the ID token. The read request is, for example, linked to the private ID. The cryptographic key of the asymmetric key pair is signed. The ID token verifies the validity of the read request signature using the authorization certificate or the public cryptographic key provided by the authorization certificate. Upon successful validity verification, the ID token grants the attribute read server read access to the requested user attributes.

[0036] An "ID token" as a standalone device is understood here to be a mobile, portable electronic device, for example a chip card, on which personal attributes of a user, i.e. user attributes, are stored. The "ID token" can, for example, be provided in the form of an identification, valuables, or security document. The corresponding identification, valuables, or security document that provides the user attributes is, for example, a sovereign document, in particular a paper-based and / or plastic-based document, such as an electronic identification document, in particular a passport, identity card, visa, driver's license, vehicle registration document, vehicle registration document, health card, or a company ID card, or another ID document, a chip card, means of payment, in particular a banknote, bank card or credit card, waybill, or other proof of authorization.In particular, the ID token may be a machine-readable travel document, as standardized, for example, by the International Civil Aviation Organization (ICAO) and / or the Federal Office for Information Security (BSI).

[0037] For example, granting read access to user attributes via the ID token requires confirmation of the read request by the user of the end device to the ID token. This confirmation includes successful authentication of the user to the ID token using the end device.

[0038] User authentication with the end device can generally be achieved, for example, by entering a password or PIN. Alternatively, user authentication can be performed using biometric authentication data.

[0039] Biometric authentication data can include, for example, the following data, which is collected by the end device using a sensor configured to capture the corresponding biometric data: DNA data, fingerprint data, body geometry / anthropometry data such as facial, hand, and ear geometry data, palmar ridge structure data, vein structure data such as hand vein structure data, iris data, retinal data, voice recognition data, nail bed patterns, dental pattern data, and / or Behavioral data, such as movement patterns, gait patterns, arm, hand, and finger movement patterns, and lip movement patterns. To capture the corresponding biometric authentication data, the biometric sensor includes, for example, an optical sensor component for detecting electromagnetic radiation in the visible and / or beyond-visual spectrum, an acoustic sensor component for detecting acoustic signals, and / or a motion sensor for detecting movements of the device when the user carries and / or uses it.

[0040] Biometric authentication data includes, for example, behavioral data of the user. Behavioral data is data based on the user's intrinsic behavior and can include, for example, movement patterns, gait patterns, arm, hand, and finger movement patterns, and lip movement patterns. Using behavioral data for biometric user authentication can have the advantage that the user can continue their usual, characteristic behavior for authentication purposes without requiring any atypical additional actions. In particular, the user does not have to interrupt their usual behavior.

[0041] To capture behavioral data, the device uses a biometric sensor configured for this purpose. This behavioral data includes, for example, motion data, which is captured using a sensor component to detect the device's movements. This motion sensor component might include an accelerometer. Motion can be calculated, for instance, by integrating acceleration measurements from the accelerometer. The motion sensor component can also detect the device's orientation in space and / or changes in orientation. For example, this sensor component might include a gyroscope.The motion data captured by the sensor component for detecting movements includes, for example, acceleration, tilt and / or position data.

[0042] Captured motion data includes, for example, data on the movements of the device caused by the user carrying it, such as on their body. The user's characteristic movements cause the device to move in a way that is characteristic of the user. This is even the Case where the user does not actively interact with the device, e.g., no user interface of the uses an end device, such as a button, a keyboard, a touchscreen or a microphone.

[0043] For example, the device displays a confirmation prompt to confirm the read request.

[0044] To confirm the read request or to grant permission to read user attributes from the ID token, the user authenticates themselves to the endpoint. For example, the endpoint confirms successful user authentication to the ID token. For instance, the endpoint forwards received authentication data from the user to the ID token, allowing the ID token to authenticate the user using this forwarded authentication data.

[0045] For example, the confirmation request includes a specification of the first public cryptographic key. The confirmation of the read request by the endpoint user against the ID token is a confirmation of the reading of the endpoint user's attributes for use together with the first public cryptographic key.

[0046] This can have the advantage that the first public cryptographic key is confirmed by the user of the end device as the intended use for the user attributes to be read. For example, the end device automatically compares the first public cryptographic key included in the read request with the first public cryptographic key stored on the end device. If the first public cryptographic key included in the read request is identical to the first public cryptographic key stored on the end device, this is confirmed, for example, by a confirmation prompt displayed to the user. The user thus knows that the first public cryptographic key for which they are granting read access is the first public cryptographic key of the end device.

[0047] The communication between the endpoint and the ID token to confirm the read request includes, for example, the use of the first private cryptographic key and verification by the endpoint, such as in the form of a signature or as part of a challenge-response procedure between the endpoint and the ID token, so that the ID token can verify whether the private cryptographic key used matches the first public cryptographic key of the read request. For example, in the case of a signature, Using the first private cryptographic key as the signature key, the first public cryptographic key provided by the read request is used as the signature verification key. If validation of the signature with the first public cryptographic key provided by the read request as the signature verification key is successful, this proves that the confirmation of the read request actually originates from the device for which the user attributes are to be read.

[0048] For example, in addition to specifying the requested user attributes, the read request also includes the first data element and / or the record ID. This has the advantage that the read user attributes, or the read user attributes themselves, can be explicitly assigned to the document to be issued using the first data element and / or to the identification record to be created using the record ID.

[0049] For example, the confirmation request also includes one or more of the following details: a specification of the requested user attributes, the first data element, record ID.

[0050] This has the advantage that the user's read access confirmation is explicitly granted for the user attributes specified in the confirmation request; that is, the confirmation is user-attribute-specific. Furthermore, the user's read access confirmation can be explicitly bound to the first data element and thus explicitly applies to the document identified by that first data element. Finally, the user's read access confirmation can be explicitly bound to the identification record to be created and thus explicitly applies to the identification record identified by the record ID.

[0051] For example, generating the first asymmetric key pair requires successful authentication of the endpoint user by the endpoint.

[0052] This ensures, for example, that the first asymmetric key pair for the provisioning token or document to be generated is actually generated for the user of the end device and with their consent.

[0053] For example, at least the first private cryptographic key is stored in the protected storage area of ​​the endpoint's memory. For example, the protected storage area is configured to prevent access to the data stored therein. The first private cryptographic key stored in the storage area was successfully encrypted. This requires authentication of the user of the end device by the end device itself.

[0054] This can have the advantage that the first private cryptographic key is securely stored on the terminal device, thus ensuring that only the terminal device is authorized to use the provisioning token and / or the issued document.

[0055] For example, the terminal device is a mobile, portable device. A mobile, portable device could be, for example, a tablet, a laptop, a smartphone, a smartwatch, smartglasses, or another mobile, portable smart device. A smart device is understood here to be a device with a processor and a memory for storing program instructions of an application for execution by the processor. Furthermore, the smart device can be understood to have a communication interface for establishing a wireless communication connection, for example, to a network such as an intranet or the internet.

[0056] Alternatively, the terminal device may be, for example, a stationary computer or a stationary computer system, such as a personal computer (PC).

[0057] For example, in addition to the data record ID, the end device receives a network address of the issuer of the digital document to be issued. The provisioning token also includes the network address of the issuer of the digital document to be issued.

[0058] The network address specifies, for example, to which issuer or to which address of the issuer of the document to be issued requests to issue the corresponding document using the provisioning token.

[0059] For example, the attribute attestation further assigns the read user attributes to the first data element and / or the data record ID.

[0060] This can have the advantage that the extracted user attributes can be assigned to the first data element and thus to the document to be issued identified by the first data element. Furthermore, this can have the advantage that the The extracted user attributes can be assigned to the data record ID and thus to the identification data record identified by the data record ID.

[0061] For example, the process further includes the sending of an issuance request from the end device to an issuer server of the issuer of the digital document to be issued. The issuance request includes the provisioning token. In response to the sending of the issuance request, the end device receives the issued document.

[0062] The provisioning token is used to issue the document to the end device. Using the signature of the provisioning token and the first public cryptographic key stored in the identification record, it can be verified, with the first public cryptographic key acting as a signature verification key, whether the provisioning token was actually generated by the end device whose identification record is identified by the provisioning token via the record ID and is to be used to issue the document.

[0063] The issued document includes, for example, the first public cryptographic key of the end device, which binds it to the end device. For example, proof of authorization to use the issued document is required to use it. Such authorization to use can include, for example, proof of possession of the first private cryptographic key associated with the first public cryptographic key. This ownership can be verified, for example, by means of a signature, such as in the course of a usage request or a challenge-response procedure, using cryptographic means. The issued document is linked to the end device in a cryptographically secured manner by the first public cryptographic key.This connection is cryptographically secured, for example, by a signature on the issued document using a signature key from the document issuer. This ensures that only the device with the first private cryptographic key can use the issued document.

[0064] Embodiments further include a method for providing a digital provisioning token on a terminal device for provisioning a digital document to be issued. The provisioning token verifies authorization to receive the digital document to be issued and is cryptographically linked to the terminal device.

[0065] The method comprises receiving a request from the terminal device by an ID provider server of an ID provider service for creating an identification data record. The request comprises a first public cryptographic key of a first asymmetric key pair of the terminal device and a first data element for entries in the identification data record to be created. The first data element identifies the document to be issued. The ID provider server creates the identification data record with identification data of a user of the terminal device. The identification data record further comprises a data record ID created by the ID provider server. Upon successful creation of the identification data record, the ID provider server sends the data record ID of the created identification data record to the terminal device for the terminal device to generate the provisioning token with the data record ID.

[0066] This can have the advantage that the ID provider service's server creates an identification record containing the user's identification data and links it to the provisioning token generated by the end device via the record ID. This ensures that the identification record can only be used to issue the document if a corresponding issuance request includes the linked provisioning token. Furthermore, it ensures that a document can only be issued using the linked provisioning token and the identification data it provides. Using the provisioning token with a different identification record with a different record ID can thus be effectively prevented.

[0067] For example, the identification data record further comprises the received first public cryptographic key of the terminal device and the received first data element of the document to be issued.

[0068] The identification record can also be cryptographically linked to the provisioning token, which is signed with the device's first private cryptographic key, using the device's public cryptographic key. This effectively prevents the identification record from being used with a different provisioning token. For example, the identification record can only be used with, or for, the provisioning token whose signature can be successfully validated using the device's first public cryptographic key as a signature verification key.

[0069] For example, the identification record is signed by the ID provider server of the ID provider service with a signature key from the ID provider server.

[0070] If the identification data record also includes the first data element that identifies the document to be issued, it can be ensured that the identification data record itself identifies for which document it is to be used.

[0071] For example, the identification data includes user attributes of the endpoint user, which are cryptographically secured by an attribute attestation and assigned to the endpoint's first public cryptographic key. Creating the identification record also involves the ID provider server sending a user attribute request to an attribute read server to provide the endpoint user's attributes. The user attribute request includes the endpoint's first public cryptographic key for mapping the retrieved user attributes to that first public cryptographic key. In response to the user attribute request, the ID provider server receives an attribute record from the attribute read server. This attribute record is signed by the attribute read server and contains the retrieved user attributes.The signed attribute record also includes an attribute certificate, which assigns the extracted user attributes to the first public cryptographic key of the end device. The ID provider server verifies the attribute certificate by assigning the first public cryptographic key to the extracted user attributes. Upon successful verification of the attribute certificate, the ID provider server enters the received user attributes, along with the attribute certificate, into the identification record.

[0072] The ID provider server can thus use the attribute certificate, with the assignment of the first public cryptographic key to the read user attributes, to ensure that the user attributes entered in the identification data record are user attributes that were read for the first public cryptographic key and therefore for the corresponding end device.

[0073] The signature of the attribute data set confirms and cryptographically secures that the attribute certificate is valid for the received user attributes, or the verification of the attribute certificate may include checking the signature of the attribute data set with a signature verification key of the attribute retrieval server.

[0074] For example, the attribute read server possesses an authorization certificate with which it can prove its authorization to read user attributes. For instance, the authorization certificate assigns a public cryptographic key of an asymmetric key pair to the attribute read server. The attribute read server also possesses a private cryptographic key of the asymmetric key pair. For example, the attribute read server sends a read request to the endpoint or the ID application implemented on the endpoint to read the user's attributes. The read request is signed, for example, with the private cryptographic key of the asymmetric key pair. The endpoint or ID application verifies the validity of the read request signature using the authorization certificate or the public cryptographic key provided by the authorization certificate.Upon successful validation, the end device or the security element of the end device grants the attribute reading server read access to the user attributes.

[0075] For example, the user attribute query also includes the first data element and the process for assigning the extracted user attributes to that first data element. The attribute certificate then cryptographically assigns the extracted user attributes to the first data element.

[0076] For example, the user attribute query also includes the record ID for mapping the extracted user attributes to the record ID. The attribute certificate further assigns the extracted user attributes to the record ID in a cryptographically secure manner.

[0077] For example, in addition to the data record ID of the created identification data record, the ID provider server sends a network address of an issuer of the digital document to be issued to the terminal device.

[0078] The network address specifies, for example, to which issuer or to which address of the issuer of the document to be issued requests to issue the corresponding document using the provisioning token.

[0079] For example, the method further comprises receiving an identification data record request by the ID provider server for sending the identification data record to an issuer server. The identification data record request includes a network address of an issuer of the digital document to be issued. The identification data record is sent by the ID provider server to the issuer server using the network address.

[0080] In response to a corresponding identification data set request, the identification data set is sent from the ID provider server, for example, to the predetermined issuer server.

[0081] For example, a prerequisite for sending the identification data record is successful verification of an authorization to read the data in the identification data record.

[0082] Such authorization can be verified, for example, using an authorization certificate. For example, the authorization certificate includes a public cryptographic key of an asymmetric key pair. The corresponding asymmetric key pair further includes a private cryptographic key. For example, the identification data set request is signed with the private cryptographic key of the asymmetric key pair. The ID provider server checks the validity of the signature of the identification data set request using the corresponding authorization certificate or the public cryptographic key provided by the corresponding authorization certificate. Upon a successful validity check, the identification data set is sent to the issuer server, for example, using the network address.

[0083] Further embodiments include a method for issuing a digital document to be issued to an end device using a digital provisioning token of the end device. To prove authorization to receive the digital document, the provisioning token includes a record ID of an identification record associated with the digital document. For cryptographic coupling to the end device, the provisioning token is further signed with a first private cryptographic key of a first asymmetric key pair of the end device. The method is executed using one or more issuer servers to issue the digital document.

[0084] The process carried out by the one or more issuing servers comprises receiving an issuance request for issuing the digital document to be issued from the terminal device. The issuance request comprises the provisioning token. An identification data record request is sent to an ID provider server of an ID provider service. The identification data record request comprises the data record ID provided by the provisioning token. In response to the identification data record request, the An identification record containing the user's identification data is received. This record includes a record ID, the device's first public cryptographic key, and a first data element that identifies the document to be issued. The provisioning token's signature is verified using the device's first public cryptographic key provided by the identification record. A database query is then sent to retrieve the first database entry from a first database. This first database entry contains data elements of the document to be issued. The database query includes the first data element and the identification data provided by the identification record to identify the first database entry.In response to the database query, the data elements of the document to be issued are retrieved from the first database entry of the first database. The digital document to be issued is then issued. The issued document comprises the received data elements from the first database entry of the first database and is signed with a second private cryptographic key from a second asymmetric key pair, which is assigned to an issuing service for issuing the digital document. The issued digital document is then sent to the end device.

[0085] By validating the signature of the provisioning token using the first public cryptographic key of the terminal provided by the identification record, it is possible to cryptographically verify whether the provisioning token and the identification record belong together, i.e., whether the provisioning token authorizes the issuance of a document using the corresponding identification record.

[0086] The data elements of the document to be issued are stored in a first database entry of a first database. The database query for identifying the first database entry uses the first data element provided by the identification record and the identification data provided by the identification record to identify the first database entry to be retrieved. For example, the first data element itself serves as a database access key, such as a primary key, or for deriving a database access key, such as a primary key. The identification data serves, for example, as a consistency test to verify whether the identification data included in the database query and verifiable by the attribute certificate matches the identification data that the first database entry contains as a data element and / or which are assigned to the first database entry. A corresponding match, ie, a successful consistency test, is a prerequisite for providing the data elements from the first database entry.

[0087] For example, the identification data includes user attributes of the user of the terminal device read from an ID token of a user of the terminal device, which are cryptographically secured by an attribute certificate and assigned to the first public cryptographic key of the terminal device.

[0088] For example, the attribute certificate further assigns the extracted user attributes to the first data element. Thus, the attribute certificate can be used to verify that the user attributes are available for issuing the document identified by the first data element. For example, the attribute certificate also assigns the extracted user attributes to the record ID. Thus, the attribute certificate can be used to verify that the user attributes actually belong to the corresponding identification record, which is identified by the record ID, and were extracted for that identification record.

[0089] For example, the issued digital document further comprises the first public cryptographic key of the terminal device provided by the identification data set.

[0090] The issued document includes, for example, the terminal's first public cryptographic key, thus binding it to that terminal. For instance, using the issued document requires proof of authorization. Such authorization could, for example, include proof of possession of the first private cryptographic key associated with the first public key. This possession can be verified, for example, by means of a signature, such as during a usage request or a challenge-response process, using cryptographic methods. The issued document is cryptographically linked to the terminal via the first public key.This connection is cryptographically secured, for example, by signing the issued document using a signature key belonging to the document's issuer. This ensures that only the device with the first private cryptographic key can use the issued document.

[0091] For example, the procedure also includes sending a database entry request to a second database to create and enter a second database entry in the second database, which includes a reference ID for the issued digital document and the first public cryptographic key of the terminal device.

[0092] This has the advantage that a second database entry is provided in the second database, in which a reference ID for the issued digital document and the first public cryptographic key of the end device are stored. Using this second database entry, it can be checked whether a document has been issued using the first public cryptographic key of the end device. This prevents the provisioning token or the first asymmetric key pair of the end device from being used multiple times to issue a document. For example, when issuing a document, the issuer server first queries the second database to check whether a provisioning token or the associated asymmetric key pair of the end device, which was used to generate the provisioning token, has already been used to issue a document.If an entry already exists in the second database containing the public cryptographic key of the corresponding asymmetric key pair of the terminal device, issuance of the requested document will be refused. If no such entry exists, issuance of the requested document will proceed.

[0093] By using a reference ID, which is, for example, a pseudonymized reference to the issued document, the corresponding document can be identified without revealing any information about its content from the reference ID. The pseudonymized reference could be, for example, a random number or the result of applying a one-way function, such as a hash function, to one or more data elements of the document.

[0094] In some embodiments, the first database and the second database are parts of one and the same database. In other embodiments, the first database and the second database are independent databases.

[0095] For example, the database entry request includes the reference ID and the terminal's first public cryptographic key.

[0096] This makes the information to be entered directly available to the second database. For example, during the entry process, a check is first performed to determine whether the corresponding first public cryptographic key and / or the reference ID are already entered in the second database. If a corresponding entry already exists in the second database, an error message is returned to the issuing server, and the issuance of the requested document is aborted. If no such entry exists, the reference ID and the first public cryptographic key of the end device are entered into the second database, and the issuance of the requested document continues.

[0097] For example, the database query for reading the first database entry of the first database further includes a request to generate and enter the reference ID into the first database entry. The reference ID is received along with the data elements from the first database entry of the first database in response to the database query.

[0098] In this case, for example, the reference ID is issued by the first database and included in the first database entry, so that the data elements of the first database entry are assigned to the reference ID.

[0099] For example, the database entry request further comprises a request to send an entry confirmation of the reference ID to the first database upon successful entry of the reference ID into the second database.

[0100] Thus, once the reference ID has been successfully entered into the second database, a corresponding confirmation can be sent to the first database. For example, the final assignment of the reference ID to the first database entry only occurs after confirmation of the successful entry of the reference ID into the second database. For example, such a final assignment is implemented by setting a corresponding flag.

[0101] For example, the database entry request includes the first data element and the first public cryptographic key of the terminal device. The database entry request further includes a request to generate the reference ID and, upon successful entry of the reference ID into the second database, to send an entry confirmation containing the reference ID and the first data element to the first database for entering the reference ID into the first database entry.

[0102] In this case, the reference ID is generated by the second database, which, upon successful entry of the reference ID into the second database, sends a corresponding confirmation to the first database. This confirmation includes, for example, the generated reference ID and the first data element. The first database can then use this first data element to identify the first database entry in which the reference ID needs to be added. Upon sending the confirmation, the first database element is deleted, for example, from a temporary storage area of ​​the first database or from the first database system providing the first database.

[0103] For example, the reference ID is a random value.

[0104] For example, a provisioning token can also be generated for issuing multiple documents. In this case, the endpoint generates multiple asymmetric key pairs for the multiple documents to be issued and receives multiple initial data elements, each identifying one of the documents to be issued. One or more identification records can then be created. For example, one identification record is created for all documents in the multiple set of documents. In this case, a record ID is used. Alternatively, for each of the documents in the multiple set of documents, an identification record is created. In this case, a record ID is generated for each of the created identification records and included in the provisioning token.Issuing multiple documents then proceeds analogously to issuing a single document, with the analogous issuance procedure being executed for each document within the set. If there is one identification record for all documents, the same identification record is used to issue all documents. However, if there are multiple documents, the same provisioning token is initially used, the actual issuance of each individual document then accesses its respective, individually assigned identification record.

[0105] Further embodiments include an end device for providing a digital provisioning token to the end device for provisioning a digital document to be issued. The end device includes a processor, memory containing program instructions, and a communication interface for communication over a network. The provisioning token grants authorization to receive the digital document to be issued. document and is cryptographically coupled to the terminal device. Execution of the program instructions by the processor causes the processor to control the terminal device to execute a method for providing the digital provisioning token to the terminal device according to one of the preceding examples.

[0106] Further embodiments include an ID provider server for providing a digital provisioning token to an end device for provisioning a digital document to be issued. The ID provider server comprises a processor, memory containing program instructions, and a communication interface for communication over a network. The provisioning token qualifies the user to receive the digital document to be issued and is cryptographically linked to the end device. Execution of the program instructions by the processor causes the processor to control the ID provider server to execute a procedure for providing the digital provisioning token to the end device according to one of the preceding examples.

[0107] Further embodiments include an issuer server for issuing a digital document to an end device using a digital provisioning token of the end device. The issuer server includes a processor, memory containing program instructions, and a communication interface for communication over a network. To prove authorization to receive the digital document, the provisioning token includes a record ID of an identification record associated with the digital document. For cryptographic coupling to the end device, the provisioning token is also signed with a first private cryptographic key of a first asymmetric key pair of the end device.When the processor executes the program instructions, it directs the issuer server to execute one or more steps of a procedure for issuing the digital document to be issued to the terminal device according to one of the preceding examples.

[0108] For example, when the processor executes the program instructions, it causes the processor to control the issuer server to execute a procedure to issue the digital document to be issued to the terminal device according to one of the preceding examples.

[0109] Embodiments further include a system comprising the terminal device of any of the preceding examples and the ID provider server of any of the preceding examples.

[0110] For example, the system further comprises the issuer server according to any of the preceding examples.

[0111] The term "program" or "program instructions" here refers without restriction to any type of computer program that includes machine-readable instructions for controlling a functionality of the computer.

[0112] In this and the following text, a "processor" is understood to be a logic circuit used to execute program instructions. The logic circuit can be implemented on one or more discrete components, particularly on a chip. A processor includes, for example, an arithmetic logic unit (ALU), a control unit, registers, and data lines for communication with other components. Specifically, a "processor" is understood to be a microprocessor or a microprocessor system consisting of multiple processor cores and / or multiple microprocessors.

[0113] A security element is a protected component of a mobile device that provides cryptographic means. These cryptographic means are protected against manipulation and are accessible only to authorized services and applications, for example, via cryptographic keys. Specifically, the cryptographic means can only be added to, supplemented, modified, and / or deleted from the security element by authorized services and applications. A security element thus provides a tamper-proof platform, for example, implemented as a secure single-chip microcontroller, on which applets and / or confidential and / or cryptographic data can be stored according to predefined rules and security requirements by reliably identified trusted entities and thus made available to authorized applications and / or operating systems.A security element can be embedded or integrated, for example, it can be non-destructively removable or permanently attached, i.e., not non-destructively removable. A security element can be implemented, for example, in the form of a Secure Element (SE). The security element can include, for example, a SIM, UICC, SmartMicroSD, smartcard, eSE, eSIM, or eUlCC. For example, cryptographic keys are stored on a security element; that is, the security element includes a data vault for cryptographic keys or a "key." TI Store". Such a key store or security element can also be implemented as part of the main processor, for example in a TEE ("Trusted Execution Environment"). For example, the security element can be implemented using a TEE. Security elements are implemented, for example, as hardware and / or firmware. According to embodiments, security elements or key stores can also be implemented as software.

[0114] The term "storage" here refers to both volatile and non-volatile electronic storage media or digital storage media.

[0115] In this context, "non-volatile memory" refers to electronic storage for the permanent storage of data, particularly static cryptographic keys, attributes, or identifiers. Non-volatile memory can be configured as immutable memory, also known as Read-Only Memory (ROM), or as modifiable memory, also known as Non-Volatile Memory (NVM). Specifically, it can be an EEPROM, for example, a Flash EEPROM, or simply Flash. A key characteristic of non-volatile memory is that the data stored on it is retained even after the power supply is switched off.

[0116] In this context, "volatile memory" refers to an electronic storage device for the temporary storage of data, characterized by the fact that the stored data is lost after the power supply is switched off. In particular, this can refer to volatile direct-access memory, also known as random-access memory (RAM), or to the volatile working memory of the processor.

[0117] A "protected memory area" is understood here to be an area of ​​an electronic memory to which access, i.e., read or write access, is only possible via a processor of the corresponding electronic device. According to embodiments, access by the processor coupled to the memory is only possible if a necessary condition is met. This can be, for example, a cryptographic condition, in particular successful authentication and / or successful authorization verification of an access request.

[0118] An "interface" or "communication interface" is understood here as an interface through which data can be received and sent, whereby the communication interface can be configured with contact or contactless. A communication interface can, for example, enable communication via a network Depending on the configuration, a communication interface can, for example, provide wireless communication according to a cellular standard, Bluetooth, RFID, Wi-Fi, and / or NFC standard. Depending on the configuration, a communication interface can, for example, provide cable-based communication.

[0119] Communication can take place, for example, via a network. Here, "network" refers to any transmission medium with a connection for communication, in particular a local connection or local network, especially a Local Area Network (LAN), a private network, especially an intranet, and a digital private network (Virtual Private Network - VPN). For example, a device may have a standard wireless interface for connecting to a WLAN. Furthermore, it may be a public network, such as the internet. Depending on the specific implementation, this connection can also be established via a mobile network.

[0120] An encrypted communication channel refers, for example, to encrypted end-to-end connections. An "encrypted end-to-end connection" or "encrypted end-to-end communication channel" is understood here as a connection between a sender and a receiver with end-to-end encryption, in which the data to be transmitted is encrypted by the sender and only decrypted by the receiver. The encryption of transmitted data thus takes place across all transmission stations, so that intermediate stations cannot gain knowledge of the content of the transmitted data due to the encryption. The connection is cryptographically secured by the encryption to prevent eavesdropping and / or manipulation of the transmission, for which a so-called secure messaging method can be used.End-to-end encryption, for example, relies on two symmetric cryptographic keys. One symmetric key is used to encrypt messages, and the other is used to authenticate the sender, for instance, using Message Authentication Code (MAC) algorithms. For example, during the setup of an encrypted communication channel, ephemeral keys are negotiated for encryption. These keys become invalid when the communication channel is terminated. Using different ephemeral keys for different communication channels allows for the parallel operation of multiple communication channels.

[0121] An encrypted communication channel can be established, for example, using the Transport Layer Security (TLS) protocol, such as part of the Hypertext Transfer Protocol Secure (HTTPS) protocol.

[0122] Asymmetric key pairs are used in a variety of cryptosystems and play a crucial role in the secure transmission of electronic data. An asymmetric key pair consists of a public cryptographic key, which is used to encrypt and / or decrypt data and may be shared with third parties, such as a sender or recipient of data, and a private cryptographic key, which is used for encryption and / or decryption, as well as for signing data, and must generally be kept secret. The public key allows anyone to encrypt data for the holder of the private cryptographic key and / or to verify digital signatures created with the private cryptographic key.A private key allows its owner to decrypt data encrypted with the public cryptographic key and / or to create digital signatures of data.

[0123] A digital signature of data involves, for example, generating a verification value of the data, such as a hash value, which is encrypted using a private cryptographic key from an asymmetric key pair that serves as the signature key. In the case of a signature, only the signer knows the private cryptographic key used to create the signature, i.e., the signature key, of the asymmetric key pair used. The signature recipient only possesses the public cryptographic key, i.e., the signature verification key, of the asymmetric key pair used. The signature recipient can therefore verify the signature, but cannot calculate it themselves. For signature verification, the signature recipient calculates, for example, the verification value of the signed data and compares it with the result of decrypting the signature using the signature verification key.If the calculated hash value matches the decryption result, the signature is correct. If the authenticity of the signature verification key is also confirmed, for example, by a certificate, especially a PKI certificate, the signature is valid.

[0124] A "certificate" is understood here as a digital certificate, which is also called a public key certificate (PKI certificate). A certificate is structured data that serves to identify a public cryptographic key of an asymmetric cryptosystem of an identity, such as a person, institution or a device. For cryptographic security and to verify the authenticity of the certificate data, it is signed by a certificate issuer. A Public Key Infrastructure (PKI) is realized through PKI certificates, which are based on asymmetric key pairs and, with the exception of a root certificate, are each signed by a certificate issuer with a signature key. The corresponding signature verification key is assigned to the certificate issuer by a PKI certificate from the respective certificate issuer. For example, the certificate can conform to the X.509 standard or another standard. For instance, the certificate could be a Card Verifiable Certificate (CVC). An authorization certificate includes structured data that additionally defines rights of identity.

[0125] The PKI provides a system for issuing, distributing, and verifying digital certificates. In an asymmetric cryptosystem, a digital certificate can confirm the authenticity of a public cryptographic key and its permissible scope. The digital certificate itself is protected by a digital signature, the authenticity of which can be verified using the public cryptographic key of the certificate issuer. To verify the authenticity of the issuer's key, another digital certificate is used. In this way, a chain of digital certificates can be built, each confirming the authenticity of the public cryptographic key used to verify the preceding certificate. Such a chain of certificates forms a so-called validation path or certification path.Participants in the PKI must be able to rely on the authenticity of the last certificate, the so-called root certificate, and the key it certifies, without needing any further certificates. The root certificate is managed by a so-called root certification authority, whose assumed authenticity underpins the authenticity of all certificates in the PKI.

[0126] Digital certificates are verified, for example, by an independent, credible authority (certification service provider / CSP or trust service provider / TSP), i.e., the certification authority that issues the certificate. Certificates can be made available to a wide range of people to enable them to verify the authenticity and validity of electronic signatures. A certificate can be associated with an electronic signature and provide a signature verification key in the form of the public cryptographic key if the private key belonging to the signature verification key was used as the signature key. By issuing a certificate in association with By making a public cryptographic key available to the public, it enables users of asymmetric cryptosystems to associate the public cryptographic key with an identity, such as a person, an organization, or a computer system.

[0127] It is understood that one or more of the aforementioned embodiments may be combined with one another, as long as the embodiments do not exclude one another. BRIEF DESCRIPTION OF THE DRAWINGS

[0128] The following examples are explained in more detail using the drawings. They show:

[0129] Fig. 1 is a flowchart of an exemplary method for providing a digital provisioning token on a terminal device,

[0130] Fig. 2 is a flowchart of another exemplary method for providing a digital provisioning token on a terminal device,

[0131] Fig. 3 shows a flowchart of another exemplary procedure for providing a digital provisioning token to an end device,

[0132] Fig. 4 shows a flowchart of another exemplary procedure for providing a digital provisioning token to an end device,

[0133] Fig. 5 shows a flowchart of another exemplary procedure for providing a digital provisioning token to an end device,

[0134] Fig. 6 shows a flowchart of another exemplary procedure for providing a digital provisioning token to an end device,

[0135] Fig. 7 shows a flowchart of an exemplary procedure for providing an identification data set,

[0136] Fig. 8 shows a flowchart of an exemplary procedure for issuing a digital document to be issued to an end device.

[0137] Fig. 9 shows a flowchart of another exemplary procedure for issuing a digital document to be issued for an end device,

[0138] Fig. 10 shows a flowchart of another exemplary procedure for issuing a digital document to be issued for an end device,

[0139] Figures 11A and 11B show a schematic block diagram of an exemplary system for providing a digital provisioning token and issuing a digital document to be issued to an end device.

[0140] Figs. 12A and 12B show a schematic block diagram of another exemplary system for providing a digital provisioning token and issuing a digital document to be issued to an end device.

[0141] Fig. 13 shows a schematic block diagram of an exemplary provisioning token for a digital document,

[0142] Fig. 14 is a schematic block diagram of an exemplary digital document,

[0143] Fig. 15 is a flowchart of an exemplary method for providing a digital provisioning token on a terminal device and

[0144] Fig. 16 is a flowchart of an exemplary method for issuing a digital document to be issued for a terminal device. DETAILED DESCRIPTION

[0145] In the following, similar elements are identified by the same reference numerals.

[0146] Figure 1 shows an exemplary procedure for providing a digital provisioning token to an end device for provisioning a digital document to be issued. The provisioning token proves authorization to receive the digital document to be issued and is cryptographically linked to the end device.

[0147] In block 300, the terminal generates an asymmetric key pair consisting of a public cryptographic key and a private cryptographic key. In block 302, the terminal receives a data element associated with the document to be issued, which identifies the document. In block 304, the terminal sends a request to create an identification record containing the identification data of a user of the terminal to an ID provider server of an ID provider service. The request includes the first public cryptographic key and the first data element for the document to be issued. Entries in the identification record to be created. In block 310, the end device receives a record ID of the created identification record from the ID provider server. In block 312, the end device generates the provisioning token, which includes the record ID and is signed by the end device during its generation using the generated private cryptographic key.

[0148] Figure 2 shows another exemplary method for providing a digital provisioning token to an end device for provisioning a digital document to be issued. The provisioning token proves authorization to receive the digital document to be issued and is cryptographically linked to the end device.

[0149] In block 300, the terminal generates an asymmetric key pair consisting of a public cryptographic key and a private cryptographic key. In block 302, the terminal receives a data element associated with the document to be issued, which identifies the document. In block 304, the terminal sends a request to an ID provider server of an ID provider service to create an identification record containing the identification data of a user of the terminal. The request includes the first public cryptographic key and the first data element to be entered into the identification record to be created. In block 306, the terminal receives a read request from an attribute read server to retrieve the identification data of the identification record in the form of user attributes of the user of the terminal from an ID token of the user.The read request assigns at least the first public cryptographic key of the terminal to the read operation. In block 308, the terminal, in response to the read request, provides the requested user attributes of the terminal's user using the ID token. In block 310, the terminal receives a record ID of the created identification record from the ID provider server. In block 312, the terminal generates the provisioning token, which includes the record ID and is signed by the terminal during its generation using the generated private cryptographic key.

[0150] Figure 3 shows another exemplary method for providing a digital provisioning token to an end device for provisioning a digital document to be issued. The provisioning token proves authorization to receive the digital document to be issued and is cryptographically linked to the end device.

[0151] In block 300, the terminal generates an asymmetric key pair consisting of a public cryptographic key and a private cryptographic key. The process begins in block 302. The terminal receives a data element associated with the document to be issued, which identifies the document. In block 304, the terminal sends a request to an ID provider server of an ID provider service to create an identification record containing the identification data of a user of the terminal. The request includes the first public cryptographic key and the first data element to be entered into the identification record to be created. In block 310, the terminal receives a record ID of the created identification record from the ID provider server. In block 312, the terminal generates the provisioning token, which includes the record ID and is signed by the terminal during its generation using the generated private cryptographic key.In block 314, the terminal sends an issuance request to an issuer server of the digital document issuer. The issuance request includes the provisioning token generated by the terminal. In block 316, the terminal receives the issued document in response to the issuance request.

[0152] Figure 4 shows another exemplary method for providing a digital provisioning token to an end device for provisioning a digital document to be issued. The provisioning token proves authorization to receive the digital document to be issued and is cryptographically linked to the end device.

[0153] In block 300, the terminal generates an asymmetric key pair consisting of a public cryptographic key and a private cryptographic key. In block 302, the terminal receives a data element associated with the document to be issued, which identifies the document. In block 304, the terminal sends a request to an ID provider server of an ID provider service to create an identification record containing the identification data of a user of the terminal. The request includes the first public cryptographic key and the first data element to be entered into the identification record to be created. In block 306, the terminal receives a read request from an attribute read server to retrieve the identification data of the identification record in the form of user attributes of the user of the terminal from an ID token of the user.The read request assigns at least the first public cryptographic key of the terminal to the read operation. In block 308, the terminal, in response to the read request, provides the requested user attributes of the terminal's user using the ID token. In block 310, the terminal receives a record ID of the created record. The identification data record is obtained from the ID provider server. In block 312, the terminal generates the provisioning token, which includes the data record ID and is signed by the terminal using the generated private cryptographic key during its generation. In block 314, the terminal sends an issuance request to an issuer server of an issuer of the digital document to be issued. The issuance request includes the provisioning token generated by the terminal. In block 316, the terminal receives the issued document in response to the issuance request.

[0154] Figure 5 shows an exemplary method for providing a digital provisioning token on a terminal device for provisioning a digital document to be issued. The provisioning token verifies authorization to receive the digital document to be issued and is cryptographically linked to the terminal device. The method is executed by an ID provider server of an ID provider service.

[0155] In block 320, the ID provider server receives a request from the terminal device to create an identification record. The request identifies a public cryptographic key from the terminal device's asymmetric key pair and includes a data element for entries in the identification record to be created. This data element identifies the document to be issued. In block 322, the ID provider server creates the identification record containing the identification data of a user of the terminal device. The identification record also includes a record ID generated by the ID provider server. In block 332, upon successful creation of the identification record, the ID provider server sends the record ID of the created identification record to the terminal device for the terminal device to generate the provisioning token, which includes the record ID.

[0156] Figure 6 shows another exemplary method for providing a digital provisioning token on a terminal device for provisioning a digital document to be issued. The provisioning token verifies authorization to receive the digital document to be issued and is cryptographically linked to the terminal device. The method is executed by an ID provider server of an ID provider service.

[0157] In block 320, the ID provider server receives a request from the terminal device to create an identification data record. The request identifies a public cryptographic key of an asymmetric key pair of the terminal device and a data element for The data element identifies the document to be issued. In block 322, the ID provider server creates the identification record containing the identification data of a user of the terminal device. The identification record also includes a record ID created by the ID provider server. In block 324, the ID provider server sends a user attribute request to an attribute read server to provide the user attributes of the terminal device user. The user attribute request includes the terminal device's public cryptographic key for mapping the read user attributes to the public cryptographic key. In block 326, the ID provider server receives an attribute record from the attribute read server in response to the user attribute request. The attribute record is signed by the attribute read server and includes the read user attributes.The signed attribute record also includes an attribute certificate, which maps the extracted user attributes to the terminal's public cryptographic key. In block 328, the ID provider server verifies the attribute certificate by mapping the public cryptographic key to the extracted user attributes. In block 330, upon successful verification of the attribute certificate, the ID provider server inserts the received user attributes, along with the attribute certificate, into the identification record. In block 332, upon successful creation of the identification record, the ID provider server sends the record ID of the created identification record to the terminal for the terminal to generate the provisioning token, which includes the record ID.

[0158] Figure 7 shows an exemplary procedure for providing an identification data set, which was created, for example, in the course of the procedure in Figure 5 or Figure 6, for issuing a digital document to be issued.

[0159] In block 340, the ID provider server receives an identification data record request for sending the identification data record to an issuer server. The identification data record request includes a network address of an issuer of the digital document to be issued. In block 342, the ID provider server sends the identification data record to the issuer server using the network address.

[0160] Figure 8 shows an exemplary procedure for issuing a digital document to an end device using a digital provisioning token of the end device. To prove authorization to receive the digital document, the provisioning token includes a record ID of the device to be issued. The digital document is associated with an identification data record. The provisioning token is further signed with a first private cryptographic key from a first asymmetric key pair of the terminal device for cryptographic coupling to the terminal. The process is executed using one or more issuing servers to issue the digital document.

[0161] In block 350, an issue request for the digital document to be issued is received from the terminal device, which includes the provisioning token. In block 352, an identification record request is sent to an ID provider server of an ID provider service. The identification record request includes the record ID provided by the provisioning token. In block 354, in response to the identification record request, the identification record containing the identification data of a user of the terminal device is received. This record includes a record ID, a first public cryptographic key of the terminal device, and a first data element, which identifies the document to be issued. In block 356, the signature of the provisioning token is validated using the terminal device's first public cryptographic key provided by the identification record.

[0162] Block 358 sends a database query to retrieve the first database entry from a first database. This first database entry contains data elements of the document to be issued. To identify the first database entry, the database query includes the first data element provided by the identification record and the identification data provided by that record. In Block 360, in response to the database query, the data elements of the document to be issued are received from the first database entry of the first database. In Block 362, the digital document to be issued is generated. This document contains the received data elements from the first database entry of the first database and is signed with a second private cryptographic key from a second asymmetric key pair.The second asymmetric key pair is assigned to an issuer service for issuing the digital document. In block 364, the issued digital document is sent to the terminal device.

[0163] Figure 9 shows another exemplary procedure for issuing a digital document to be issued to an end device using a digital provisioning token of the end device. The provisioning token includes a record ID of a [missing information - likely a specific entity or entity] to prove authorization to receive the digital document to be issued. The identification data record associated with the digital document to be issued is used. The provisioning token is further signed with a first private cryptographic key from a first asymmetric key pair of the terminal device for cryptographic coupling to the terminal. The process is executed using one or more issuing servers to issue the digital document.

[0164] In block 350, an issuance request for issuing the digital document to be issued is received from the terminal device, which request comprises the provisioning token. In block 352, an identification data record request is sent to an ID provider server of an ID provider service. The identification data record request comprises the data record ID provided by the provisioning token. In block 354, in response to the identification data record request, the identification data record with identification data of a user of the terminal device is received, which includes a data record ID, a first public cryptographic key of the terminal device, and a first data element, which identifies the document to be issued. In block 356, the signature of the provisioning token is validated using the first public cryptographic key of the terminal device provided by the identification data record.

[0165] In block 358, a database query is sent to read a first database entry of a first database. Data elements of the document to be issued are stored in the first database entry. To identify the first database entry, the database query includes the first data element provided by the identification data record and the identification data provided by the identification data record. Furthermore, the database query for reading the first database entry of the first database includes a request to generate and enter the reference ID in the first database entry. In block 360, in response to the database query, the data elements of the document to be issued are received from the first database entry of the first database, along with the reference ID.In block 362, the digital document to be issued is issued, which comprises the received data elements from the first database entry of the first database and is signed with a second private cryptographic key of a second asymmetric key pair. The second asymmetric key pair is assigned to an issuing service for issuing the digital document to be issued. In block 364, the issued digital document is sent to the terminal device.

[0166] In block 366, a database entry request is sent to a second database for creating and entering a second database entry in the second database, which includes a reference ID for the issued digital document and the first public cryptographic key of the terminal device. The database entry request includes the reference ID and the first public cryptographic key of the terminal device. For example, the database entry request further includes a request to send an entry confirmation of the reference ID to the first database upon successful entry of the reference ID in the second database. In block 368, confirmation of the entry of the second database entry in the second database is received.

[0167] Figure 10 shows another exemplary method for issuing a digital document to be issued for a terminal device using a digital provisioning token of the terminal device. To verify authorization to receive the digital document to be issued, the provisioning token comprises a data record ID of an identification data record associated with the digital document to be issued. For cryptographic coupling to the terminal device, the provisioning token is further signed with a first private cryptographic key of a first asymmetric key pair of the terminal device. The method is carried out using one or more issuer servers to issue the digital document.

[0168] In block 350, an issuance request for issuing the digital document to be issued is received from the terminal device, which request comprises the provisioning token. In block 352, an identification data record request is sent to an ID provider server of an ID provider service. The identification data record request comprises the data record ID provided by the provisioning token. In block 354, in response to the identification data record request, the identification data record with identification data of a user of the terminal device is received, which includes a data record ID, a first public cryptographic key of the terminal device, and a first data element, which identifies the document to be issued. In block 356, the signature of the provisioning token is validated using the first public cryptographic key of the terminal device provided by the identification data record.

[0169] In block 358, a database query is sent to read a first database entry of a first database. Data elements of the document to be issued are stored in the first database entry. The database query includes, for the identification of the first database entry, the first data element provided by the identification data record, and the identification data provided by the identification data record. In block 360, in response to the database query, the data elements of the document to be issued are received from the first database entry of the first database. In block 362, the digital document to be issued is issued, which comprises the received data elements from the first database entry of the first database and is signed with a second private cryptographic key of a second asymmetric key pair. The second asymmetric key pair is assigned to an issuer service for issuing the digital document to be issued. In block 364, the issued digital document is sent to the terminal device.

[0170] In block 366, a database entry request is sent to a second database for creating and entering a second database entry in the second database, which includes a reference ID for the issued digital document and the first public cryptographic key of the terminal device. The database entry request includes the first data element and the first public cryptographic key of the terminal device. The database entry request further includes a request to generate the reference ID and, upon successful entry of the reference ID in the second database, to send an entry confirmation containing the reference ID and the first data element to the first database for entering the reference ID in the first database entry. In block 368, confirmation of the entry of the second database entry in the second database is received.

[0171] Figures 11A and 11B together show an exemplary system 182 for providing a digital provisioning token and issuing a digital document to be issued for a terminal device 100. The system 182 has been divided into two figures, i.e., Figures 11A and 11B, which belong together and together represent the complete system 182. The system 182 comprises, for example, the terminal device 100, an ID provider server 130, an attribute retrieval server 160, an issuer server 400, a first database server 430 of a first database 440, and / or a second database server 450 of a second database 460.

[0172] The terminal 100, which is for example a mobile terminal such as a smartphone, comprises a processor 102, a memory 104 with Program instructions 116 and a communication interface 120 for communication via the network 180. In addition, the terminal device 100 comprises, for example, a user interface 118, via which a user can control the terminal device 100, for example, to request the creation of a provisioning token 112 for a digital document 412. Furthermore, the user interface 118 can be configured to allow the user to authenticate themselves to the terminal device 100. Execution of the program instructions 116, which, for example, implement a corresponding app on the terminal device 100, by the processor 102 causes the processor 102 to control the terminal device 100 to generate the provisioning token 112.

[0173] For example, to generate the provisioning token 112, the terminal device 100 executes one of the exemplary methods from Figures 1 to 4. In doing so, the terminal device 100 generates an asymmetric key pair comprising a private cryptographic key 108 and a public cryptographic key 110. The private cryptographic key 108 is stored, for example, in a protected memory area 106 of the memory 104 of the terminal device 100. Furthermore, the terminal device receives, for example via the user interface 118 or the communication interface 120, a first data element 114 associated with the document 412 to be issued, which identifies the document 412 to be issued. The terminal device sends a request via the network 180 to an ID provider server 130 of an ID provider service to create an identification data record 142 with identification data 508 of a user of the terminal device 100.The request includes, for example, the public cryptographic key 110 and the first data element 114 for entries in the identification data record 142 to be created.

[0174] Upon creation of the identification data record 142, the terminal device 100 receives a data record ID 144 from the ID provider server 130 via the network 180, which identifies the created identification data record 142. The terminal device 100 uses the data record ID 144 to generate the provisioning token 112. For example, the terminal device 100 signs the data record ID 144 using the private cryptographic key 108.

[0175] The provisioning token 112 thus generated can be used by the terminal device 100 to request an issuance of the digital document 412 to be issued by an issuer server 400 of an issuer of the digital document 412 to be issued via the network 180. In response to sending a corresponding issuance request, the terminal device 100 receives, for example, the issued document 412.

[0176] The ID provider server 130 of the ID provider service comprises, for example, a processor 132, a memory 134 with program instructions 148, and a communication interface 150 for communication via the network 180. Furthermore, the ID provider server 130 comprises, for example, an asymmetric key pair comprising a private cryptographic key 138 and a public cryptographic key 140. The private cryptographic key 138 is stored, for example, in a protected memory area 136 of the memory 134 of the ID provider server 130. The ID provider server 130 can use the private cryptographic key 138, for example, to sign the created identification data record 142.

[0177] For example, the ID provider server 130 executes one of the exemplary methods from Figures 5 or 6 to generate the identification data record 142. Upon receiving the request from the terminal device 100 to create the identification data record 142, the ID provider server 130 creates the identification data record 142 and sends the data record ID 144 of the created identification data record 142 to the terminal device 100 to generate the provisioning token 112.

[0178] The identification data record 142 created by the ID provider server 130 comprises, for example, the data record ID 144 generated by the ID provider server 130. Furthermore, the identification data record 142 comprises, for example, the first data element 114 received from the terminal 100 and the public cryptographic key 110 of the terminal 100. Furthermore, the ID provider server 130 requests identification cards in the form of user attributes 508 of the user of the terminal 100 via the network 180 via an attribute readout server 160. In response to the corresponding user attribute request, which includes, for example, the public cryptographic key 110 of the terminal device 100, the ID provider server 130 receives the read user attributes 508 together with an attribute certificate 146. The attribute certificate 146 assigns the read user attributes 508 to the first public cryptographic key 110 of the terminal device 100.The ID provider server 130 verifies the attribute certificate 146 and, upon successful verification of the attribute certificate 146, the ID provider server enters the received user attributes 508 together with the attribute certificate 146 into the identification data record 142.

[0179] The attribute reading server 160 comprises, for example, a processor 162, a Memory 164 with program instructions 174 and a communication interface 176 for Communication via the network 180. Furthermore, the attribute reading server 160 comprises For example, an asymmetric key pair comprising a private cryptographic key 168 and a public cryptographic key 172. The private cryptographic key 168 is stored, for example, in a protected storage area 166 of the memory 164 of the attribute reading server 160. The public cryptographic key 172 is provided, for example, as part of an authorization certificate 170, with which the attribute reading server 160 can verify authorization to read user attributes 508. The attribute reading server 160 can also use the private cryptographic key 168, for example, to sign the read user attributes 508 and an attribute certificate 146.Alternatively, the attribute readout server 160 can also have another asymmetric key pair with another private cryptographic key for signing the readout user attributes 508 and an attribute certificate 146. The attribute readout server 160 sends a read request for reading the user attributes 508 to the terminal device 100 via the network 180. For example, the terminal device 100 itself provides the user attributes 508, for example, in the protected memory area 106. The read request includes, for example, the public cryptographic key 112 of the terminal device 100. Furthermore, the read request can include, for example, the first data element 114 and / or the data record ID 144.

[0180] The user attributes 508 are managed, for example, by an ID application implemented by the instructions 116 on the terminal device 100. Upon successful verification of authorization to read the user attributes 508, for example, using the authorization certificate 170, the attribute readout server 160 receives the requested user attributes 508, creates an attribute certificate 146, signs the read user attributes 508 and the attribute certificate 146, and sends both to the ID provider server 130 for entry into the identification data record 142.

[0181] The document 412 to be issued is issued, for example, using the issuer server 400 of an issuer of the document 412 to be issued. The issuer server 400 comprises, for example, a processor 402, a memory 404 with program instructions 414, and a communication interface 416 for communication via the network 180. Furthermore, the issuer server 400 comprises, for example, an asymmetric key pair, which comprises a private cryptographic key 408 and a public cryptographic key 410. The private cryptographic key 408 is stored, for example, in a protected memory area 406 of the memory 404 of the issuer server 400. The private cryptographic key 408 can be used by the issuer server 400, for example, to sign the issued document 412.

[0182] For example, to issue the document 412 to be issued, the issuer server 400 executes one of the exemplary methods from Figures 8 to 10. For example, the issuer server 400 identifies the identification data record 142 to be used to issue the document 412 using the provisioning token 112. For example, the issuer server 400 receives the provisioning token 112 from the terminal 100 and queries the identification data record 142 from the ID provider server 130 using the data record ID 144 provided by the provisioning token 112. The signature of the provisioning token 112 can be verified, for example, with the public cryptographic key 110 provided by the identification data record 142.

[0183] Upon a successful verification, the issuer server 400 uses, for example, the first data element 114 provided by the identification data record 142 and the user attributes 508 to identify a first database entry 442 in a first database 440. The identified first database entry 442 comprises data elements of the document 412 to be issued, which are provided to the issuer server 400 by the first database 440.

[0184] Access to the first database 440 occurs, for example, via a first database server 430 managing the first database 440. The first database server 430 includes, for example, a processor 432, a memory 434 with program instructions 436, and a communication interface 438 for communication via the network 180. The program instructions 436 implement, for example, a database management system for managing the first database 440.

[0185] The issuing server 400 uses the data elements of the first database entry 442 provided by the first database server 430 to issue the document 412, which, for example, includes the public cryptographic key 110 of the terminal 100 for cryptographically secure coupling to the terminal 100. The issued document 412 is sent to the terminal 100 for use.

[0186] In order to prevent multiple use of the provisioning token 112 or the asymmetric key pair 108. 110 of the terminal device underlying the provisioning token 112 for issuing a document, a second database entry 462 is additionally entered into a second database 460.

[0187] Access to the second database 460 occurs, for example, via a second database server 450 managing the second database 460. The second database server 450 includes, for example, a processor 452, a memory 454 with program instructions 456, and a communication interface 458 for communication via the network 180. The program instructions 456 implement, for example, a database management system for managing the second database 460.

[0188] The second database entry 462 of the second database 460, which is entered upon request from the issuer server 400, includes, for example, the public cryptographic key 110 of the terminal device 100 and a reference ID of the document 412. For example, the corresponding reference ID of the document 412 is created by the first database server 430, entered into the first database entry 442, and made available to the issuer server 400 together with the data elements from the first database entry 442. Upon successful issuance of the document 412, the issuer server 400 then forwards the public cryptographic key 110 of the terminal device 100 and the reference ID of the document 412 to the second database server 450 for entry into the second database 460.For example, the second database server 450 informs the first database server 430 about entering the reference ID of the document 412 into the second database entry 462.

[0189] Alternatively, the reference ID of the document 412 can also be created by the second database server 450 at the request of the issuer server 400. Upon entering the reference ID of the document 412 in the second database entry 462 of the second database 460, the second database server 450 sends, for example, the reference ID of the document 412 to the first database server 430 and informs it about the entry of the reference ID of the document 412 in the second database entry 462. For example, the second database server 450 sends the reference ID of the document 412 together with the first data element 114, which the issuer server 400 provides, to the first database server 430. Thus, the database server 430 can enter the reference ID of the document 412, for example, in the first database entry 442 of the first database 440.

[0190] Figures 12A and 12B together show another exemplary system 182 for providing a digital provisioning token and issuing a digital document to be issued for a terminal device 100. The system 182 has been divided into two figures, ie Figure 12A and Figure 12B, which belong together and together represent the complete system 182. The system 182 comprises, for example, the terminal device 100, an ID token, an ID provider server 130, an attribute retrieval server 160, an issuer server 400, a first database server 430 of a first database 440 and / or a second database server 450 of a second database 460.

[0191] The system 182 shown in Figure 12 corresponds to the system 182 shown in Figures 11A and 11B, except that the user attributes 508 in Figure 12A, unlike in Figure 11A, are not read from the terminal 100, but via the terminal 100 from a standalone ID token 500.

[0192] The ID token 500 comprises, for example, a processor 502, a memory 504 with program instructions 508, and a communication interface 512 for communication with the terminal device 100. The communication interface 512 is, for example, a communication interface for contactless communication with a corresponding communication interface 122 of the terminal device 100. The program instructions 508 control, for example, the provision of user attributes 508, which are stored in a protected memory area 506 of the memory 504 of the ID token 500.

[0193] In this case, the attribute readout server 160 reads the user attributes 508 from the ID token 500, for example, via the terminal device 100. Upon successful verification of authorization to read the user attributes 508 from the ID token, for example using the authorization certificate 170, the attribute readout server 160 receives the requested user attributes 508 via the terminal device, creates an attribute certificate 146, signs the read user attributes 508 and the attribute certificate 146, and sends both to the ID provider server 130 for entry in the identification data record 142. For example, to read the user attributes 508 from the ID token 550, an encrypted communication connection is established between the attribute readout server 160 and the ID token 500. An encrypted communication connection is, for example, a communication connection secured by end-to-end encryption.

[0194] Figure 13 shows an exemplary digital provisioning token 112 issued by a terminal device, which is cryptographically linked to the terminal device. The provisioning token 112 includes, for example, a data set ID 144, which identifies an identification data set containing identification data of a user of the terminal device, and a signature 107, which is created using a private cryptographic key of the terminal device.

[0195] Figure 14 shows an exemplary digital document 412, which comprises a data record 413 with data elements 114, 415. The data elements comprise, for example, the first data element 114, which identifies the document 142. Furthermore, the data elements comprise, for example, data elements 415, which were read from a first database entry of a first database. A corresponding document 412 can be issued, for example, using one of the methods described in Figures 8 to 10. The data record 411 is signed with a signature key of an issuer issuing the document, i.e., with the signature 411. The data record 413 further comprises a public cryptographic key 110 of a terminal device for cryptographically coupling the document 412 to the corresponding terminal device. In addition, the data record 413 also comprises, for example, an indication 417 of a time of issue of the document 412.

[0196] Figure 15 shows an exemplary method for providing a digital provisioning token on a terminal device 100. In step 600, the method is started by a user 10 of the terminal device 100. In step 602, an asymmetric key pair is generated on the terminal device, which comprises a private cryptographic key PrK and a public cryptographic key PuK. For example, a prerequisite for generating the asymmetric key pair is successful authentication of the user 10 to the terminal device 100. For example, the private cryptographic key is stored in a protected memory area of ​​the memory of the terminal device 100, access to which requires successful authentication of the user 10 to the terminal device 100. In step 604, the terminal device 100 receives a first data element, for example as input from the user 10, which identifies the document to be issued.In step 606, the terminal 100 sends a request to create the identification data record to an ID provider server 130 of an ID provider service. The request includes the public cryptographic key PuK and the first data element.

[0197] In step 608, the ID provider server 130 generates the identity data record with a data record ID, the public cryptographic key PuK, and the first data element. The ID provider server 130 sends a user attribute request to provide user attributes of the user 10 of the terminal device 100 to an attribute retrieval server 160. In step 610, the ID provider server 130 initially sends the user attribute request, for example, to the terminal device 100, which forwards the user attribute request to the attribute retrieval server 160 in step 612. In step 614, the attribute retrieval server 160 sends a read request to the terminal device 100 to read the requested user attributes. In step 616A confirmation request for confirming the reading of the requested user attributes is displayed on the terminal device 100. In step 618, the user 10 confirms the reading of the requested user attributes to the terminal device 100, for example, by entering a PIN or another form of authentication to the terminal device 100. In step 620, the user attributes are sent to the attribute readout server 160 in response to the read request. If the user attributes are provided by the terminal device, they are read out from a memory of the terminal device 100, in particular from a protected memory area of ​​the corresponding memory. If the user attributes are provided on a standalone ID token, they are read out via the terminal device 100 from the ID token.The attribute readout server 160 generates an attribute certificate that assigns the user attributes to the public cryptographic key PuK, signs the received user attributes together with the attribute certificate, and sends both to the ID provider server 130. In step 622, the attribute readout server 160 sends the read user attributes together with the attribute certificate, for example, initially to the terminal 100, which forwards both to the ID provider server 130 in step 624. In step 626, the ID provider server 130 verifies the attribute certificate and, upon successful verification, enters the user attributes together with the attribute certificate into the identity data record in step 628.

[0198] Upon successful creation of the identity record with the user attributes of user 10 of the terminal device 100 as identity data, the ID provider server 130 sends the record ID to the terminal device in step 630. In step 632, the terminal device 100 uses the record ID to generate a provisioning token. For example, the terminal device 100 signs the record ID using the private cryptographic key to generate the provisioning token.

[0199] Figure 16 shows an exemplary method for issuing a digital document to be issued for a terminal device. In step 634, the terminal device 100 sends an issuance request with the provisioning token to a server 161, which is, for example, a first issuer server. The server 161 performs, for example, distribution and / or forwarding tasks. In step 636, the server 161 sends an identity data record request to the ID provider server 130. The identity data record request includes the data record ID provided by the provisioning token for identifying the requested identity data record. In step 638, the ID provider server 130 sends the requested identity data record to the server 161. For example, The server 161 can verify the signature of the provisioning token using the public cryptographic key PuK of the terminal device 100 provided by the identification data record. For example, the server 161 can also send the data record ID in the form of the provisioning token to the ID provider server 130, and the ID provider server 130 can verify the signature of the provisioning token. This ensures that the provisioning token actually belongs to the identity data record identified by the data record ID and authorizes its use to issue the document to be issued.

[0200] In step 640, the server 161 forwards the identification data record to a (second) issuing server 160 for issuing the document to be issued. In step 642, the issuing server 160 sends a database query to a first database server 430 for reading data elements of the document to be issued from a first data record of a first database. The database query includes the identification data in the form of the user attributes and the first data element from the identification data record. Based on this information from the identification data record, the first database server 430 can identify the requested database entry. Furthermore, the user attributes can be used to check, for example, whether the requested database entry is actually assigned to the person who identified themselves using the user attributes.In step 644, the first database server 430 generates a reference ID for the document to be issued and enters it in the first database entry. The reference ID can be used to identify the document without allowing any conclusions to be drawn about the content of the document and / or the data elements of the document to be issued stored in the first database entry. In step 646, in response to a database query, the first database server 430 sends the data elements read from the first database entry, together with the reference ID, to the issuing server 160. In step 648, the issuing server 160 issues the document to be issued using the received data elements from the first database entry. For example, the issued document further includes the public cryptographic key PuK of the terminal 100 provided by the identification data record, whereby the document is assigned to the terminal 100.The issuing server 160 signs the document with a signature key and sends it to the terminal 100. For this purpose, the document is first sent together with the reference ID to the server 161 in step 650, which forwards the document to the terminal 100 in step 652.

[0201] Finally, in step 654, the server 161 sends a database entry request to a second database server 450 of a second database. The database entry request includes the reference ID and the public cryptographic key PuK of the terminal device 100 provided by the identification data record. In step 656, the reference ID and the public cryptographic key PuK of the terminal device 100 are entered together into a second database entry in the second database. This can ensure, for example, that the public cryptographic key PuK of the terminal device 100 is not used again to issue a document. The second database can be used to check whether a public cryptographic key PuK has already been used once to issue a document.In addition, the reference ID can be used to identify the document for which the public cryptographic key PuK was used. Finally, in step 658, the second database server 450 sends entry information to the first database server 430, which informs about the entry of the public cryptographic key PuK in the second database. For example, the first database server 430 can note the entry in the first database entry, which is identified by the reference ID.

[0202] Alternatively, the reference ID can also be generated, for example, by the second database server 450 in step 656 for entry into the second database and sent to the first database server 430 in step 658 for entry. In this case, for example, the first data element and the public cryptographic key PuK are sent to the second database server 450 in step 654.

[0203] Although the invention has been fully illustrated and described in the drawings and the foregoing description, this illustration and description is to be considered as illustrative and not restrictive; the invention is not limited to the disclosed embodiments. LIST OF REFERENCE SYMBOLS 10 users 100 devices 102 processor 104 memory 106 protected memory area 107 Signatur 108 private cryptographic keys 110 public cryptographic key 112 provisioning tokens 114 first data element 116 Program instructions 118 User interface 120 Communication interface 130 ID provider servers 132 processor 134 memory 136 protected memory area 138 private cryptographic key 140 public cryptographic key 142 Identification data record 144 Record ID 146 Attribute Certificate 148 program instructions 150 communication interface 160 attribute reading servers 160 servers 162 processor 164 memory 166 protected memory area 168 private cryptographic key 170 Authorization Certificate 172 public cryptographic key 174 program instructions 176 Communication interface 180 Network 182 systems 400 exhibitor servers 402 processor 404 Memory 406 protected memory area 408 private cryptographic key 410 public cryptographic key 411 Signatur 412 Document 413 data set 414 program instructions 415 document data elements 416 Communication interface 417 Date of issue 430 first database server 432 processor 434 memory 436 program instructions 438 Communication interface 440 first database 442 first database entry 450 second database server 452 processor 454 memory 456 program instructions 458 Communication interface 460 second database 462 second database entry 500 ID tokens 502 processor 504 memory protected memory area user attributes program instructions communication interface

Claims

CLAIMS 1. A method for providing a digital provisioning token (112) on a terminal (100) for provisioning a digital document (412) to be issued, wherein the provisioning token (112) proves an authorization to receive the digital document (412) to be issued and is cryptographically coupled to the terminal (100), the method comprising: • generating a first asymmetric key pair by the terminal (100), which comprises a first public cryptographic key (110) and a first private cryptographic key (108), • Receiving a first data element (114) associated with the document (412) to be issued by the terminal (100), wherein the first data element (114) identifies the document (412) to be issued, • Sending a request by the terminal (100) to an ID provider server (130) of an ID provider service for creating an identification data record (142) with identification data of a user of the terminal (100), wherein the request comprises the first public cryptographic key (110) and the first data element (114) for entries in the identification data record (142) to be created, • Receiving a data record ID (144) of the created identification data record (142) from the ID provider server (130) by the terminal device (100), • Generating the provisioning token (112) by the terminal (100), wherein the provisioning token (112) comprises the data record ID (144) and is signed by the terminal (100) using the first private cryptographic key (110) during the generation process.

2. The method of claim 1, wherein the method further comprises: • Receiving a read request for reading the identification data of the identification data record (142) in the form of user attributes (508) of the user of the terminal (100) from an ID token (116; 500) of the user from an attribute readout server (160) by the terminal (100), wherein the read request comprises the first public cryptographic key (110) of the terminal (100) and assigns it to the readout process, in response to the read request, providing the requested user attributes (508) of the user of the terminal device (100) using the ID token (116; 500) by the terminal device (100).

3. The method according to claim 2, wherein the ID token (116) is provided by the terminal (100) in the form of an ID application, the program instructions (116) of which are stored in a memory (104) of the terminal (100), wherein the user attributes (508) are stored in a protected memory area (106) of the memory (104) of the terminal (100), wherein a prerequisite for providing the requested user attributes (508) is a successful verification of an authorization credential (170) of the attribute reading server (160) for reading the requested user attributes (508).

4. The method according to claim 2, wherein the ID token (500) is provided as a standalone device with which the terminal (100) communicates via a communication interface, wherein the terminal (100) forwards the read request for reading the user attributes (508) to the ID token (500) and, in response to the read request, forwards the requested user attributes (508) from the ID token (500) to the attribute readout server (160).

5. The method according to any one of claims 2 to 4, wherein a prerequisite for enabling read access to the user attributes (508) by the ID token (116; 500) is confirmation of the read request by the user of the terminal (100) to the ID token (116; 500), wherein the confirmation comprises successful authentication of the user to the ID token (116; 500) using the terminal (100).

6. The method according to any one of claims 2 to 5, wherein the terminal (100) displays a confirmation request to confirm the read request.

7. The method according to claim 6, wherein the confirmation request comprises an indication of the first public cryptographic key (110), wherein the confirmation of the read request by the user of the terminal (100) to the ID token (116; 500) is a confirmation of the reading of the user attributes (508) of the user of the terminal (100) for use together with the first public cryptographic key (110).

8. The method of claim 7, wherein the confirmation request further comprises one or more of the following: an indication of the requested user attributes (508), the first data element (114), record ID (144).

9. Method according to one of the preceding claims, wherein the generation of the first asymmetric key pair requires successful authentication of the user of the terminal (100) by the terminal (100).

10. The method according to claim 9, wherein at least the first private cryptographic key (108) is stored in the protected memory area (106) of the memory (104) of the terminal (100), wherein the protected memory area (106) is configured such that access to the first private cryptographic key (108) stored in the protected memory area (106) requires successful authentication of the user of the terminal (100) by the terminal (100).

11. Method according to one of the preceding claims, wherein the terminal (100) is a mobile, portable terminal (100).

12. Method according to one of the preceding claims, wherein the terminal (100) receives, in addition to the data record ID (144), a network address of an issuer of the digital document (412) to be issued, wherein the provisioning token (112) additionally comprises the network address of the issuer of the digital document (412) to be issued.

13. A method according to any one of the preceding claims, wherein the method further comprises: • Sending an issuance request for issuing the digital document (412) to be issued by the terminal (100) to an issuer server (400) of an issuer of the digital document (412) to be issued, wherein the issuance request comprises the provisioning token (112), • in response to sending the issuance request, receiving the issued document (412) by the terminal (100).

14. A method for providing a digital provisioning token (112) on a Terminal (100) for provisioning a digital document (412) to be issued, wherein the Provisioning token (112) proves an authorization to receive the digital document (412) to be issued and is cryptographically coupled to the terminal (100), the method comprising: • Receiving a request from the terminal (100) by an ID provider server (130) of an ID provider service for creating an identification data record (142), wherein the request comprises a first public cryptographic key (110) of a first asymmetric key pair of the terminal (100) and a first data element (114) for entries in the identification data record (142) to be created, the first data element (114) identifies the document (412) to be issued, • Creating the identification data record (142) by the ID provider server (130) with identification data of a user of the terminal (100), wherein the identification data record (142) further comprises a data record ID (144) created by the ID provider server (130), • upon successful creation of the identification data record (142), sending the data record ID (144) of the created identification data record (142) by the ID provider server (130) to the terminal device (100) for generating the provisioning token (112) with the data record ID (144) by the terminal device (100).

15. The method according to claim 14, wherein the identification data record (142) further comprises the received first public cryptographic key (110) of the terminal (100) and the received first data element (114) of the document to be issued (412).

16. The method according to any one of claims 14 to 15, wherein the identification data comprise user attributes (508) of the user of the terminal (100), which are cryptographically secured by an attribute certificate (146) and are assigned to the first public cryptographic key (110) of the terminal (100), wherein the creation of the identification data record (142) further comprises: • Sending a user attribute request for providing the user attributes (508) of the user of the terminal (100) to an attribute readout server (160) by the ID provider server, wherein the user attribute request comprises the first public cryptographic key (110) of the terminal (100) for assigning the read-out user attributes (508) to the first public cryptographic key (110), • in response to the user attribute request, receiving an attribute data record from the attribute retrieval server (160) by the ID provider server, wherein the Attribute data set is signed by the attribute readout server (160) and comprises the read-out user attributes (508), wherein the signed attribute data set further comprises an attribute certificate (146) which assigns the read-out user attributes (508) to the first public cryptographic key (110) of the terminal (100), • Verifying the attribute certificate (146) with the assignment of the first public cryptographic key (110) to the read user attributes (508) by the ID provider server (130), • upon successful verification of the attribute certificate (146), entries of the received user attributes together with the attribute certificate (146) in the identification data record (142) by the ID provider server.

17. The method according to claim 16, wherein the user attribute request further comprises the first data element (114) and / or the data record ID (144) for assigning the read user attributes to the first data element (114) and / or the data record ID (144), wherein the attribute certificate (146) further assigns the read user attributes (508) to the first data element (114) and / or the data record ID (144) in a cryptographically secured manner.

18. The method according to any one of claims 14 to 17, wherein the ID provider server (130) sends a network address of an issuer of the digital document (412) to be issued to the terminal (100) in addition to the data record ID (144) of the created identification data record (142).

19. The method according to any one of claims 14 to 18, wherein the method further comprises: • Receiving an identification data record request for sending the identification data record (142) to an issuer server by the ID provider server, wherein the identification data record request comprises a network address of an issuer of the digital document (412) to be issued, • Sending the identification data record (142) to the issuer server by the ID provider server (130) using the network address.

20. The method according to claim 19, wherein a prerequisite for sending the identification data record (142) is a successful verification of an authorization to read the data of the identification data record (142).

21. A method for issuing a digital document (412) to be issued for a terminal device (100) using a digital provisioning token (112) of the terminal device (100), wherein the provisioning token (112) comprises a data record ID (144) of an identification data record (142) assigned to the digital document (412) to be issued to prove authorization to receive the digital document (412) to be issued, wherein the provisioning token (112) is further signed with a first private cryptographic key (108) of a first asymmetric key pair of the terminal device (100) for cryptographic coupling to the terminal device (100), wherein the method is carried out using one or more issuing servers to issue the digital document (412), wherein the method comprises: • Receiving an issuance request for issuing the digital document (412) to be issued from the terminal (100), wherein the issuance request comprises the provisioning token (112), • Sending an identification data record request to an ID provider server (130) of an ID provider service, wherein the identification data record request comprises the data record ID (144) provided by the provisioning token (112), • in response to the identification data record request, receiving the identification data record (142) with identification data of a user of the terminal (100), which comprises a data record ID (144), a first public cryptographic key (110) of the terminal (100) and a first data element (114) which identifies the first data element (114) of the document (412) to be issued, • Validating the signature (107) of the provisioning token (112) using the first public cryptographic key (110) of the terminal device (100) provided by the identification data record (142), • Sending a database query to read a first database entry (442) of a first database (440), wherein data elements (415) of the document (412) to be issued are stored in the first database entry (442), wherein the database query for identifying the first database entry (442) comprises the first data element (114) provided by the identification data record (142) and the identification data provided by the identification data record (142), • in response to the database query, receiving the data elements (415) of the document to be issued (412) from the first database entry (442) of the first database (440), • issuing the digital document (412) to be issued, which comprises the received data elements (415) from the first database entry (442) of the first database (440) and is signed with a second private cryptographic key (408) of a second asymmetric key pair, which is assigned to an issuer service for issuing the digital document (412) to be issued, • Sending the issued digital document (412) to the terminal (100).

22. The method according to claim 21, wherein the identification data comprise user attributes (508) of the user of the terminal (100) read from an ID token (116; 500) of a user of the terminal (100), which are assigned to the first public cryptographic key (110) of the terminal (100) in a cryptographically secured manner by an attribute certificate (146).

23. The method of claim 22, wherein the attribute certificate (146) further associates the read user attributes (508) with the first data element (114) and / or the data record ID (144).

24. The method according to any one of claims 21 to 23, wherein the issued digital document (412) further comprises the first public cryptographic key (110) of the terminal (100) provided by the identification data record (142).

25. The method according to any one of claims 21 to 24, wherein the method further comprises: • Sending a database entry request to a second database (460) to create and enter a second database entry (462) in the second database (460) which includes a reference ID for the issued digital document (412) and the first public cryptographic key (110) of the terminal (100), • Receiving a confirmation of the entry of the second database entry (462) in the second database (460).

26. The method of claim 25, wherein the database entry request comprises the reference ID and the first public cryptographic key (110) of the terminal (100).

27. The method according to claim 26, wherein the database query for reading the first database entry (442) of the first database (440) further comprises a request to generate and enter the reference ID in the first database entry (442), wherein the reference ID is received together with the data elements (415) from the first database entry (442) of the first database (440) in response to the database query.

28. The method of claim 25, wherein the database entry request comprises the first data element (114) and the first public cryptographic key (110) of the terminal (100), the database entry request further comprising a request to generate the reference ID and, upon successful entry of the reference ID in the second database (460), to send an entry confirmation with the reference ID and the first data element (114) to the first database (440) for entering the reference ID in the first database entry (442).

29. The method according to any one of claims 25 to 28, wherein the reference ID is a random value.

30. Terminal (100) for providing a digital provisioning token (112) on the terminal (100) for provisioning a digital document (412) to be issued, wherein the terminal (100) comprises a processor (102), a memory (104) with program instructions (116) and a communication interface (120) for communication via a network (180), wherein the provisioning token (112) proves an authorization to receive the digital document (412) to be issued and is cryptographically coupled to the terminal (100), wherein execution of the program instructions (116) by the processor (102) causes the processor (102) to control the terminal (100) to carry out a method according to one of claims 1 to 13.

31. ID provider server (130) for providing a digital provisioning token (112) on a terminal (100) for provisioning a digital document (412) to be issued, wherein the ID provider server (130) comprises a processor (132), a memory (134) with program instructions (148) and a communication interface (150) for communication via a network (180), wherein the provisioning token (112) proves an authorization to receive the digital document (412) to be issued and is cryptographically coupled to the terminal (100), wherein execution of the program instructions (148) by the processor (132) causes the processor (132) to control the ID provider server (130) to perform a method according to any one of claims 14 to 20.

32. Issuer server (400) for issuing a digital document (412) to be issued for a terminal device (100) using a digital provisioning token (112) of the terminal device (100), wherein the issuer server (400) comprises a processor, a memory with program instructions and a communication interface for communication via a network (180), wherein the provisioning token (112) for proving an authorization to receive the digital document (412) to be issued comprises a data record ID (144) of an identification data record (142) assigned to the digital document (412) to be issued, wherein the provisioning token (112) for cryptographic coupling to the terminal device (100) is further signed with a first private cryptographic key (108) of a first asymmetric key pair of the terminal device (100), wherein execution of the program instructions by the processor causes the processor toto control the issuer server (400) to execute a method according to one of claims 21 to 29., 33. System (182) comprising the terminal (100) according to claim 30 and the ID provider server (130) according to claim 31.

34. The system (182) of claim 33, wherein the system (182) further comprises the issuer server (400) according to claim 32.

Images