Securing data stored in a token by adding a signature

Abstract

The invention relates to a method and electronic system for supplementing and verifying a supplementary cryptographic signature in a digital token. For this purpose, after mutual authentication of the digital token and a terminal, a supplementary cryptographic signature is created by a signature device based on a secret key not previously used for this digital token and stored in the digital token. The supplementary signature can then be verified using an associated public key.

Description

[0001] The present invention relates to a method and system for securing data stored on a token. In particular, the present invention relates to methods for adding a new cryptographic signature to a token, methods for verifying the authenticity of the data stored in the token using the new signature, and corresponding arrangements and systems.

[0002] The use of chip cards and other ID tokens for identity verification is a known technology. These ID tokens, such as passports, identity cards, or other ID documents, have a microprocessor and integrated memory in which, among other things, personal data is stored alongside program instructions. During checks, this data can be read by a reader with the appropriate authorization after successful execution of certain program instructions to verify the identity of the token holder.

[0003] To prevent manipulation of personal data stored in a token, the personal data can be protected by various mechanisms. One option for protecting data from manipulation is to create a cryptographic signature over the data.

[0004] This procedure, also known as "passive authentication," is currently prescribed in International Civil Aviation Organization (ICAO) document 9303 for verifying the authenticity of stored identity data. The signature is generated using a state-of-the-art private key based on elliptic curve cryptography (ECC), which is considered more secure than currently available computational methods.

[0005] Given the increasing research and development in the field of quantum computing, there is a risk that decryption of the private key, and thus the creation of manipulated ID tokens, could become possible within the next few years. Since ID tokens, especially passports and other official documents, generally have a long validity period, one challenge is to develop additional security mechanisms for ID tokens that allow for verification of the authenticity and tamper-proof nature of the data stored on an ID token, even in the case of a cryptographically powerful quantum computer.

[0006] The object of the present invention is therefore to secure the data stored on an ID token in addition to the existing protection mechanisms.

[0007] This problem is solved by the method and the system according to the independent claims. Preferred embodiments of the invention result from the features mentioned in the dependent claims and also from the present disclosure as a whole.

[0008] A first aspect of the invention relates to a method for adding a supplementary cryptographic signature to a digital token, wherein the digital token comprises a data structure. The method comprises the following steps: - Mutual authentication of the digital token and a terminal; - Receiving, by the terminal, readout data of the digital token's data structure; - Transmitting, through the terminal, a hash value of at least a part of the data structure to a signature device, wherein the hash value is part of the readout data or was generated based on the readout data; - Creating the supplementary cryptographic signature for the hash value by the signature device using a secret key of the signature device, wherein the secret key differs from cryptographic keys previously used for the digital token; - Transferring the supplementary cryptographic signature to the digital token; and - Storing the supplementary cryptographic signature in a digital token storage location.

[0009] Before describing the process steps in more detail, the terms used will first be defined and explained.

[0010] The term "token" refers in this context to any realization of a portable microcomputer with an external interface, a microprocessor and non-volatile memory that is indirectly accessible via the external interface for an external read and / or write operation.

[0011] A "token," also referred to as an "ID token," is understood here to be a portable electronic device that, for example, has at least one protected electronic data storage area for storing data and one communication interface for reading the data. The storage area is protected, for example, to prevent the data stored therein from being altered without authorization or read without the necessary permission. In other words, the storage area can only be accessed if the required access authorization has been granted.

[0012] The token can have a communication interface and a microprocessor connected to the protected memory area via an internal data bus. External access to the protected memory area via the communication interface is only possible through the processor, after the processor has verified the existence of the appropriate access authorization by executing a program.

[0013] The communication interface is therefore an interface through which data can be received and sent. This interface can be configured as either contact-based or contactless, for example, according to an RFID and / or NFC standard. The communication interface can be internal or external, connected to an associated device, for example, via a cable or wirelessly.

[0014] In particular, the token can be a USB stick, a chip card, or another Secure Element (SE), such as those specified by Global Platform (www.globalplatform.org), or a document, especially a document of value or security. According to the invention, a "document" is understood to be a paper-based and / or plastic-based document, such as electronic identification documents, in particular passports, identity cards, visas, as well as driver's licenses, vehicle registration documents, vehicle titles, company ID cards, health insurance cards, or other ID documents, as well as chip cards, means of payment, in particular banknotes, bank cards, and credit cards, bills of lading, or other authorization documents such as access cards, into which a data storage device for storing data is integrated.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).

[0015] The term "external interface" is used in relation to a token to refer to any technical device for exchanging digitally encoded data between the token and a separate data processing device. Examples of external token interfaces include the contact pads familiar from bank and credit cards and the RFID interfaces used for high-frequency wireless signal transmission in electronic identity documents.

[0016] The term "administrative data," which can alternatively be referred to as "control data," in the non-volatile memory of a token refers to administrative data that, in contrast to user data, defines, in particular, an access condition for accessing the user data. Furthermore, the administrative data can also include information about the position of the relevant file in the token's file system, for example, in the form of a pointer to the respective successor node in the token's file tree, as well as, for example, a file identifier (FID) and an application identifier (AID).

[0017] "Usage data" here refers in particular to data in the non-volatile memory of a token that is required by an application program of a terminal that is interoperable with the token, such as biometric data, in particular fingerprint data, facial biometric data and / or iris scan data, which a terminal needs for biometric authentication.

[0018] The data stored on the token (user data and administrative data) can be stored in the form of a so-called "data structure". A "data structure" in this context refers to structured data storage, such as in a tree structure or a sequence.

[0019] A "data group" is still understood to be an element of the data structure that can contain one or more data values. Data groups can, for example, be understood as data groups in the sense of ICAO Specification 9303.

[0020] The "address space" of a token's non-volatile memory is the set of binary identifiers, namely the addresses, with which the token's microprocessor selects the units of the non-volatile memory during access operations. Typically, the addresses are generated by the microprocessor in a register and / or via an instruction parameter. In tokens without a memory management unit (MMU), the addresses appear directly on the data bus. However, this is not a requirement. Even in the case of virtualization of memory access by a memory management unit and / or scrambling of memory accesses, the address space is understood here as the set of virtual and / or scrambled addresses with which an actually available memory element can be selected at the processor logic level for an access instruction.

[0021] A "fragment" is defined as a maximally contiguous address range within free non-volatile memory. Maximally contiguous means that neither the address preceding nor following the fragment belongs to the free non-volatile memory.

[0022] "Metadata" refers to data stored in the non-volatile memory of a token that describes details of how user data is stored. Therefore, for memory management purposes, a unique link must be established between the metadata and the user data it describes. Such a unique link is achieved, for example, through data organization where the metadata precedes the user data as a header of fixed or definable length in the logical address space.

[0023] In this context, a "file" is defined as a self-descriptive, structured, or structureable collection of data. The portion of the data used to describe the file is called metadata. The remaining portion of the data is user data.

[0024] A "reference structure" is a structured or structurable compilation of addresses with references to other data.

[0025] An "access logic" is an abstract, programmatically implementable organizational scheme for accessing data in a memory. In this sense, a reference structure is a specific type of access logic, namely an access logic mapped onto the stored data. Other implementations of an access logic can be procedural or object-oriented.

[0026] A "file system" is defined as a structure of administrative data in non-volatile memory that is already at least partially established at the time the token is issued. Typical tokens are equipped at the time of issue with software features that allow for the expansion or general modification of the file system at later times while maintaining the underlying abstract organizational scheme. These software features are typically provided as part of a hardware-specific basic software package, also known as a smart card operating system. For further details on the structure and, in particular, the access logic of typical token file systems, reference is made to the ISO / IEC 7816-4 standard.

[0027] In this context, a "terminal" refers to an electronic device that includes a reader enabling read and / or write access to the token, for example, in the form of a smart card terminal. The terminal with the reader can be an integral part of a user's computer system or a separate component, such as a peripheral device. Specifically, the reader can be a Class 1, 2, or 3 smart card reader. The reader can be equipped with a contactless and / or contact-based interface for data exchange with a token.

[0028] In some embodiments, the ID token does not have its own power supply. Instead, a device for "harvesting" energy, such as an RFID antenna, can serve as the energy source, transferring the energy from the terminal to the ID token.

[0029] Here, a "certificate" refers to a digital certificate, also known as a public-key certificate. Such certificates, based on asymmetric key pairs, enable the implementation of a Public Key Infrastructure (PKI). A certificate consists of structured data used to associate a public key of an asymmetric cryptosystem with an identity, such as a person or device. A certificate can, for example, contain a public key and be signed. Alternatively, certificates based on zero-knowledge cryptosystems are also possible. For instance, the certificate might conform to the X.509 standard or another standard. One example of such a certificate is a CV certificate, or Card Verifiable Certificate (CVC). An implementation of such CVCs is specified, for example, in ISO / IEC 7816-8.

[0030] The Public Key Infrastructure (PKI) provides a system for issuing, distributing, and verifying digital certificates. In an asymmetric cryptosystem, a digital certificate serves to confirm the authenticity of a public key and its permissible scope and application. The digital certificate itself is protected by a digital signature, the authenticity of which can be verified using the issuer's public key. 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 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 certified by it, without requiring 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.

[0031] A "document PKI" is understood here to be a public key infrastructure (PKI) that serves to create certificates for ID tokens, i.e. documents, whereby the certificates are used to verify the authenticity of the ID token in question.

[0032] Digital certificates are a proven method for verifying authorization when securing electronic communication using asymmetric cryptographic methods. Certificates are structured data that document the authenticity and / or other attributes / authorizations of the owner of a public key (signature verification key) and are confirmed by an independent, credible authority (certification service provider / CSP), generally the issuing certification authority. Certificates are typically made available to a broad range of people to enable them to verify the authenticity and validity of electronic signatures.

[0033] A certificate can be associated with an electronic signature if the private key belonging to the public key was used to generate the electronic signature being verified. By making a certificate associated with a public key publicly available, a certificate authority (CFA) enables users of asymmetric cryptosystems to associate the public key with an identity, such as a person, an organization, an energy system, or a computer system.

[0034] Asymmetric key pairs are used in a variety of cryptosystems and also play a crucial role in the signing of electronic documents. An asymmetric key pair consists of a private key, which is used to encrypt data and must generally be kept secret, and a public key, which may be shared with third parties, such as a service provider and / or a central authority. The public key allows anyone to encrypt data for the owner of the private key, verify digital signatures on their documents, or authenticate them. A private key allows its owner to decrypt data encrypted with the public key or to create digital signatures for electronic documents.

[0035] With symmetric keys, both participants in the corresponding symmetric cryptosystem use the same key. In some symmetric methods, the two keys are not identical, but can be easily calculated from each other. Symmetric keys are used, for example, to calculate Message Authentication Codes (MACs).

[0036] In the following, a "static" key refers to a cryptographic key or data value that is stored on a non-volatile storage medium and can be used for more than one session. In contrast, "ephemeral" keys, i.e., temporary cryptographic keys or data values, are generated only for one session and are not permanently stored, meaning they cannot be used in subsequent sessions.

[0037] In the following, a "static" certificate refers to a digital certificate that can be used for more than one session. A static certificate can, for example, include a static public key and be signed with a static private key. In contrast, "ephemeral" certificates are generated using temporary keys for only one session and therefore cannot be used in subsequent sessions.

[0038] Digital signatures are used for secure electronic data exchange, for example on the internet, and enable the verification of identities and / or authorizations and the integrity of the exchanged data. To ensure this, a public key infrastructure is generally required, which confirms the validity of the keys used through certificates.

[0039] The creation of a digital signature, hereinafter also referred to simply as a "signature" or "electronic signature," is a cryptographic process in which an additional data value, called a "signature," is calculated for any data, such as an electronic document. The signature can, for example, be an encrypted hash value of the electronic document, in particular a hash value encrypted with a private key associated with a certificate from a cryptographic key pair. The special feature of such a signature is that its authorship and affiliation with a specific person or entity can be verified by any third party.

[0040] In this context, a "security domain" refers to a computer infrastructure that is cryptographically and / or physically protected against unauthorized access by third parties. A security domain can therefore consist of multiple programs with cryptographically secured communication between them, a secure storage area of ​​a computer, a standalone computer with secure access methods such as a firewall, password authentication, or cryptographic encryption, or a secure network that includes secure access methods and cryptographically encrypted communication channels, such as a VPN.

[0041] In the method described in the first aspect of the invention, the mutual authentication of the digital token and the terminal can be performed, for example, based on the Basic Access Control (BAC) protocol, the Extended Access Control (EAC) protocol, or the Password Authenticated Connection Establishment (PACE) protocol. Information on these protocols is disclosed, for example, in the Technical Guideline TR-03110-1 of the German Federal Office for Information Security (BSI).

[0042] After mutual authentication between the digital token and the terminal, data can be exchanged between the terminal and the digital token. The terminal can then receive the read data, i.e., the data required for reading in the respective implementation, either by accessing the digital token or by sending the read data from the digital token to the terminal.

[0043] The terminal can then send a hash value of a portion of the read data structure to the signature device. This hash value can be part of the read data itself, meaning it was stored on the digital token and received by the terminal. Alternatively, the terminal can generate the hash value based on the read data. In this case, the process can optionally include the step of the terminal generating the hash value based on at least a portion of the read data. Furthermore, it is also possible for the signature device to generate the hash value itself based on read data from the digital token transmitted to the signature device.

[0044] The signature device then uses the hash value to create the supplementary cryptographic signature, hereinafter also referred to as the supplementary signature, using a secret key of the signature device, also referred to as the "secret signature key." The secret signature key is stored, for example, in the internal memory of the signature device or in another secure storage location to which the signature device has access. The secret key used here differs from the cryptographic keys previously used for the digital token. These include, for example, keys stored on the digital token itself or keys used to encrypt or sign data stored on the digital token.Externally stored keys that are associated with the digital token, or that are stored or have been used in relation to the digital token, can also be considered keys previously used for the digital token. The secret key has therefore not yet been used for the digital token.

[0045] The supplementary cryptographic signature generated by the signature device is transferred to the digital token after its creation, thus being added to the digital token. Adding the supplementary cryptographic signature therefore means incorporating the supplementary cryptographic signature into the digital token. For example, the cryptographic signature can first be transferred from the signature device to the terminal, and then transferred from the terminal to the digital token via a secure channel established between the terminal and the digital token based on the previously performed mutual authentication. Direct transfer of the supplementary cryptographic signature from the signature device to the digital token is also possible, provided a suitable data transmission channel exists.

[0046] The supplementary cryptographic signature is then stored in a memory of the digital token, preferably persistently.

[0047] In one embodiment, a flag is added to indicate that the digital token contains the supplementary digital signature. Optionally, a digital pointer to the supplementary cryptographic signature is also added, preferably in the management data of the digital token. The storage location of the supplementary cryptographic signature within the digital token can, for example, be part of the digital token's data structure, or there can be an additional secure storage area of ​​the digital token that stores data requiring protection in addition to the data structure. Likewise, the management data can be part of the data structure or stored separately from the data structure on the digital token.

[0048] The flag and pointer can, for example, be stored in the digital token's administrative data. Alternatively, a flag, which can be understood as information about the presence of a supplementary signature in the digital token, can also be stored externally, for example in an external database.

[0049] Storing the supplementary cryptographic signature and / or optionally adding the flag and pointer can be performed, for example, by the digital token itself after the supplementary signature has been transmitted to it, based on program instructions stored in the digital token. Alternatively, storing the supplementary cryptographic signature and adding the flag and pointer can also be performed by an external write access to the digital token, such as a write access from the terminal using the secure channel between the terminal and the digital token.

[0050] The described method allows a cryptographic signature to be added to the digital token, either in addition to existing signatures or for the first time to digital tokens that previously lacked a cryptographic signature. This additional digital signature increases the tamper-proof nature of the data stored on the digital token, as any manipulation after the addition of the cryptographic signature can be detected by verifying it. Furthermore, adding a supplementary cryptographic signature ensures that the security features previously present on the digital token remain intact, thus maintaining backward compatibility.Since the supplementary cryptographic signature refers to readout data already present on the digital token, the additional storage effort is minimal, which is an advantage of the method given the small storage capacities of the digital token.

[0051] In one exemplary embodiment of the described procedure, the secret key used by the signature device to create the supplementary cryptographic signature is generated by a cryptographic method that differs from those previously used to generate the keys for the digital token. This further enhances the tamper-proof nature of the data stored on the digital token, as an attack on the supplementary cryptographic signature would require a different attack method than an attack on the existing security mechanisms protecting the data stored on the digital token. An "attack" in this context refers to a cryptographic attack or hacking attack that attempts to discover the key used for a security feature.

[0052] In one implementation, a post-quantum key (PQC key) is used as the secret key. Unlike some standard cryptographic methods such as RSA or ECC, a post-quantum key has the characteristic that no quantum computer-based algorithm is known for efficiently deriving it from publicly available data. Therefore, using a post-quantum key to supplement a signature makes it possible to ensure the tamper-proof nature of the data stored in the digital token, even in the presence of cryptographically relevant quantum computers. Since digital tokens sometimes have very long lifespans of 5, 10 years, or more, additional safeguards against data tampering are of great importance.

[0053] For example, the secret key could have been generated based on one of the following asymmetric cryptographic methods: lattice-based cryptography, hash-based cryptography, multivariate polynomials, error-correcting codes, and / or supersingular elliptic curves. A corresponding public key can then be used to verify the complementary signature.

[0054] In one exemplary implementation of the described procedure, the digital token can further include an initial cryptographic signature that was already stored on the digital token before the procedure began. In this case, the initial cryptographic signature was created by an initial signature device using an initial private key. The supplementary cryptographic signature is then stored on the digital token in addition to the initial cryptographic signature.

[0055] By storing a supplementary cryptographic signature on the digital token in addition to an existing primary cryptographic signature, data already protected by the primary signature can be further protected by the supplementary signature. This increases tamper resistance while simultaneously ensuring backward compatibility. Therefore, when verifying data stored on the digital token, the primary signature, the supplementary signature, or both signatures can be used, depending on the capabilities of the respective verification device. The optional flag stored in the administrative data, along with the pointer to the supplementary signature, allows a verification device, such as a terminal, to query whether a supplementary signature is present after establishing a connection with the digital token.Furthermore, information about the type of supplementary signature can be stored along with the flag or pointer. Depending on its implementation and the applicable legal and / or technical framework, the verification device can then decide which of the available signatures should be verified. However, since the signature only guarantees that the stored data has not been tampered with, an additional verification of the person presenting the digital token should always be carried out to check whether the person matches the personal data stored on the digital token.

[0056] In the case where two signatures are stored on the digital token, the first signature could, for example, have been created with a first private key based on RSA or ECC. The second signature could, for example, have been created based on a post-quantum secure key.

[0057] By combining an initial “classical” signature based on RSA or ECC and a supplementary PQC signature, both backward compatibility and protection against manipulation by cryptographically relevant quantum computers can be ensured.

[0058] In one implementation, the supplementary cryptographic signature and, if present, the initial cryptographic signature can be stored in a protected memory area of ​​the ID token. This protected memory area is secured, for example, so that it can only be read and / or written after secure authentication using predefined protocols. For instance, accessing the protected memory area might require an additional certificate from the accessing device, such as a terminal. This minimizes the number of read accesses to the signatures, further enhancing security. Additionally, the risk of unauthorized write access is reduced by this extra layer of protection for the memory area.

[0059] In one embodiment, the digital token can, for example, include a security object, which can be stored in the digital token's memory, preferably in a protected area of ​​the memory. The security object can include at least one hash value generated from at least one part of the data structure. Furthermore, the security object can include the first cryptographic signature, which is generated based on the at least one hash value. If the security object includes multiple hash values, a combination of these hash values ​​can be used to generate the supplementary signature. The supplementary cryptographic signature can also be stored in the security object. The security object can, for example, be part of the data structure or, alternatively, be stored on the digital token in addition to the data structure.Using a predefined security object to store security-relevant signatures and their associated hash values ​​has the additional benefit of standardizing the storage structure. This allows different providers to implement access to the relevant data without needing further information about the internal data organization of the digital token. Furthermore, this enables the implementation of the ICAO standardization for machine-readable travel documents, as mentioned above.

[0060] Another aspect of this patent application concerns a method for verifying the authenticity of a data structure stored on a digital token, wherein the digital token includes a supplementary cryptographic signature, which has been added as described above. The method for verifying the authenticity of the stored data structure and the data it contains comprises the following steps. - Mutual authentication of the digital token and a second terminal; - Determine, through the second terminal, the presence of the supplementary cryptographic signature on the digital token and the location of the supplementary cryptographic signature on the digital token; - Reading at least a part of the data structure of the digital token by means of a read access from the second terminal, the read part of the data structure including data to be verified; - Reading, by means of a read access of the second terminal, the supplementary cryptographic signature using the specified storage location; - Verify, through the second terminal, the authenticity of the data to be verified using the supplementary cryptographic signature and a public key associated with the supplementary cryptographic signature.

[0061] Mutual authentication between the digital token and the second terminal can be implemented as described above for the first terminal. The second terminal is another terminal used to verify the signature, for example, during an identity check where the digital token is presented. The second terminal is generally not involved in adding the supplementary signature.

[0062] After authentication, the second terminal can read the data on the digital token. Alternatively, data can also be sent from the digital token to the second terminal. The second terminal first determines whether a supplemental signature exists on the digital token and where this supplemental cryptographic signature is stored. This can be done, for example, using a flag that the second terminal can read from the digital token's management data or from external storage. The second terminal can then receive or read data from the digital token to be verified. This data is part of the data read from the digital token.

[0063] The second terminal can still read or receive the supplementary cryptographic signature from the digital token. The previously defined storage location can be used for this purpose. For example, the storage location can be defined as a digital pointer to the storage address of the supplementary cryptographic signature, associated with a flag.

[0064] Using the signature and the data to be verified, the second terminal can then verify the authenticity of the data using a public key associated with the supplementary cryptographic signature. For this purpose, the second terminal may, for example, have stored the public key in internal memory or be able to access it via an online service. Optionally, the process can include a further step in which the second terminal, based on the flag or other information associated with the extracted supplementary cryptographic signature, reads, downloads, requests, and / or receives the required public key.

[0065] The procedure for verifying the authenticity of the digital token's data based on the supplementary signature has the effect of increasing security.

[0066] Additionally, the second terminal can also verify a first signature stored on the digital token, either before or after verifying the supplementary signature. Verifying multiple signatures has the beneficial effect of further increasing security, as manipulation can be detected if even a single signature is incorrect for the signed data being read.

[0067] It should be noted that the described procedure verifies authenticity in the sense of immutability. This means that the signature can be used to check whether the stored data matches the signature. If this is the case, then the stored data has almost certainly not been altered, provided that the signature is secure. This security is primarily based on the fact that the secret key used to create the signature is unknown and cannot be determined using efficient methods.

[0068] During a personal identity check, after verifying the authenticity of the personal data stored on the digital token, the personal data must still be compared with the person, since the signature only prevents manipulation but not copying of the data on the digital token.

[0069] In another aspect, the present patent application covers an electronic system for supplementing a supplementary cryptographic signature in a digital token. The electronic system comprises the digital token, a terminal, and a signature device. Hereinafter, the electronic system for supplementing the supplementary cryptographic signature will also be referred to as the "first electronic system."

[0070] The digital token comprises a data structure and is configured to perform the following steps: - Authenticating to the terminal; - Establishing a read / write connection with the terminal; and - Storing a supplementary cryptographic signature transmitted from the terminal.

[0071] The terminal is configured to perform the following steps: - Authenticating against the digital token; - Establishing a read / write connection with the digital token; - Obtaining read data from the data structure of the digital token through a read access by the terminal; - Transmitting a hash value of at least a part of the data structure to the signature device, wherein the hash value is either part of the readout data or was generated based on the readout data.

[0072] The signature device includes a secret key that differs from the cryptographic keys previously used for the digital token. The signature device is configured to perform the following steps: - Creating the supplementary cryptographic signature for the hash value using the signature device and the secret key; - Transmitting the supplementary cryptographic signature to the token.

[0073] Optionally, the digital token can also be configured to - Adding, in the administrative data of the digital token, a flag indicating that the digital token contains the supplementary cryptographic signature, as well as a pointer to the supplementary cryptographic signature.

[0074] The flag and pointer can be added, for example, by the terminal writing to the digital token. Alternatively, the flag and pointer can also be added using the digital token.

[0075] Further details of the components of the electronic system and the individual process steps, as well as the advantageous effect achieved, have already been described above in this patent application in the context of the process according to the invention.

[0076] For example, the signature device can still be configured to transmit the supplementary cryptographic signature to the terminal, and the terminal can still be configured to receive the supplementary cryptographic signature from the signature device and transmit the supplementary cryptographic signature to the token. This achieves the effect that the secure connection established between the terminal and the digital token can be used, and no additional secure channel needs to be established between the digital token and the signature device.

[0077] The electronic system for supplementing the supplementary signature can be further configured to perform the optional procedural steps described above. In particular, the components of the electronic system, i.e., the signature device, the terminal, and the digital token, are each configured to perform the procedural steps that were described in the context of the procedure as being performed by or capable of being performed by the respective component.

[0078] In a further aspect, the present application also includes an electronic system for verifying the authenticity of a supplementary cryptographic signature stored on a digital token, which was created using a first electronic system as described above. The electronic system for verifying the authenticity of the supplementary cryptographic signature is hereinafter also referred to as the "second electronic system." The second electronic system comprises the digital token and a second terminal. The digital token includes a data structure and is configured to perform the following steps: - Authenticate to the second terminal; and

[0079] The second terminal remains configured to perform the following steps: - Authenticating against the digital token, - Determining the presence of the supplementary cryptographic signature on the digital token and the storage location of the supplementary cryptographic signature on the digital token; - Reading at least a part of the data structure of the digital token, the read part of the data structure comprehensively to be verified; - Reading the token's supplementary cryptographic signature using the specified storage location; - Verifying the authenticity of the data to be verified using the supplementary cryptographic signature and a public key associated with the supplementary cryptographic signature.

[0080] The presence of the supplementary digital signature and its storage location can be implemented, for example, by reading a flag and a pointer associated with the flag to the storage address of the supplementary cryptographic signature through the second terminal and then using it to read the supplementary cryptographic signature.

[0081] Alternatively, the verification of the authenticity of the data to be verified could also be carried out by another device to which the relevant data was transferred from the second terminal.

[0082] In other words, the invention relates to a method and electronic system for adding and verifying a supplementary cryptographic signature in a digital token. For this purpose, after mutual authentication of the digital token and a terminal, a supplementary cryptographic signature is created by a signature device based on a secret key not previously used for this digital token and stored in the digital token. The supplementary signature can then be verified using an associated public key.

[0083] It is generally noted that all features disclosed in relation to specific aspects or embodiments of the invention can also be combined in a technically meaningful way with other aspects or embodiments of the invention. This also applies across different technical objects and categories of objects. In particular, this also applies to individual features disclosed in part, unless explicitly stated therein or it is obvious through a technical contradiction that an inseparable functional-technical relationship exists between certain features, which must be maintained for the implementation of the invention.

[0084] The invention is explained below with reference to exemplary embodiments and their sketched representations. These show: Fig. 1A a block diagram of an embodiment of the described electronic system for supplementing a supplementary cryptographic signature in an ID token; Fig. 1B a block diagram of a further embodiment of the described electronic system to supplement the supplementary cryptographic signature in the ID token; Fig. 2A a block diagram of an embodiment of the described electronic system for verifying the authenticity of the supplementary cryptographic signature of the ID token; Fig. 2B a block diagram of a further embodiment of the described electronic system for verifying the authenticity of the supplementary cryptographic signature of the ID token; Fig. 4 a sequence diagram of an embodiment of the described procedure for supplementing the supplementary cryptographic signature in the ID token; Fig. 5 a sequence diagram of a further embodiment of the described procedure for supplementing the supplementary cryptographic signature in the ID token; Fig. 6 a sequence diagram of an embodiment of the described procedure for verifying the supplementary cryptographic signature of the ID token.

[0085] The electronic systems and procedures described below serve to provide additional cryptographic security for ID tokens, such as smart cards or security documents. Current smart cards, such as passports or identity cards, allow authentication and verification based on various cryptographic methods, most of which are based on asymmetric cryptographic algorithms like RSA or ECC. With the potential development of quantum computers in the near future, RSA- or ECC-based cryptographic algorithms may be vulnerable, as the use of Shor's algorithm or similar methods could break these cryptographic algorithms, potentially allowing unauthorized individuals to decrypt them.

[0086] In particular, passports and identity cards contain identification data in the ePassport application, which is protected by a signature stored in the security object EF.SOD. Currently, RSA- or ECC-based cryptographic methods are commonly used to create this signature. With the development of a potentially cryptographically relevant quantum computer, these signatures would become insecure.

[0087] The data of the eID application of the identity card is not currently protected by a signature, but is also secured by RSA or ECC-based cryptographic methods and would therefore no longer be secure in the case of a cryptographically relevant quantum computer.

[0088] Therefore, there is a need for additional or alternative approaches to securing chip-based security documents and the identity data stored on them. In particular, the following describes embodiments of methods and systems that protect the identity data of these security documents, such as passports or identity cards, against manipulation by an attack using a quantum computer.

[0089] It should be noted that when describing the transfer of data from a first component to a second component, the term "transfer" typically encompasses both read access by the second component to the first component, sending data from the first component to the second component, and writing access by the first component to the second component.

[0090] Fig. Figure 1A shows a schematic representation of an electronic system 100 for supplementing a supplementary signature 1123 in an ID token 110, which is also referred to as a chip card 110.

[0091] The chip card 110 includes a microprocessor 111, an internal memory 112, and a communication interface 118. The internal memory 112 contains at least one data structure 1121 and instructions 1122 that can be executed on the microprocessor 111. The data structure 1121 can be understood, for example, as a logical data structure (LDS) or a part of the data groups of the LDS according to the ICAO specification 9303 referenced above.

[0092] The chip card 110 also contains a communication interface 113, via which a data connection to a terminal 120 can be established. The terminal 120 could, for example, be a card reader 120 in a government office. The card reader 120 has the necessary authorizations to establish a data connection with the chip card 110, for example, using the EAC, BAC, or PACE protocol.

[0093] The card reader 120 also has a processor 121 and internal memory 122, as well as at least one communication interface 123, through which data exchange with the chip card 110 and a signature device 130 is possible. The internal memory 122 of the card reader 120 preferably comprises data 1221 and instructions 1222 for carrying out the functionalities of the card reader 120.

[0094] After a secure connection is established between the chip card 110 and the card reader 120, certain data, also referred to as read data, from the data structure 1221 can be read by the card reader 120. This read data includes, for example, personal data stored on the chip card 110. The read data may also contain security data, such as existing signatures and hash values.

[0095] The electronic system 100 also includes a signature device 130, which can be assigned to the card reader, for example, either physically or logically. The signature device 130 also includes a processor 131, internal memory 132, and a communication interface 133. The signature device can establish a connection to the card reader 120 via the communication interface 133. This connection can be secured by mutual authentication, but this is not necessary in all cases, as the card reader 120 and the signature device 130 can be physically and / or permanently connected.

[0096] The memory 132 of the signature device 130 also preferably comprises data 1321, instructions 1322 for executing functions of the signature device 130 on the processor 131, and a secret key 1323. In one embodiment, the secret key 1323 is a PQC key that is stored in a protected memory area of ​​the signature device 130 and preferably cannot be exported and / or read out. Alternatively, the secret key 1323 can also be stored within the data 1321 of the signature device 130.

[0097] The signature device 130 is then configured to sign read data received from the card reader 120 and / or the hash value of the read data using the secret key 1323, thus creating a supplementary signature 1123 for the read data. The secret key 1323 is a key that differs from the keys previously used for the chip card 110. The supplementary signature thus created is then transferred from the signature device 130 to the chip card 110, for example, using the card reader 120 as an intermediary device through which the connection between the signature device 130 and the chip card 110 is established.

[0098] The supplementary signature 1123 is then stored by the chip card in the internal memory 112 of the chip card 110, and information about the supplementary signature 1123 is added to the management data of the chip card 110. The management data of the chip card is either part of the data structure 1121 or it is stored in an area of ​​the internal memory 112 that is stored separately from the data structure 1121. For example, a flag is added to the management data, such as a bit or byte, indicating that a supplementary signature 1123 is stored on the chip card 110. Additionally, a pointer, preferably in the form of a memory address, is stored that points to the supplementary signature 1123 and thus enables access to it.

[0099] Fig. 1B shows an alternative embodiment of the design with reference to Fig. The electronic system 100 described in 1A includes another electronic system 101. In addition to the systems already described for Fig. The components described in 1A already contain in the internal memory 112 a first signature 1124 at the beginning of the procedure, which was created based on a classic encryption method such as ECC or RSA.

[0100] The card reader 120 can now be additionally configured with instructions to verify the first signature 1124 with respect to the read data. For this, the card reader 120 only needs access to one of the public keys associated with the signature. Further details regarding the verification of the signatures are described with reference to the following figures.

[0101] Fig. 2A shows an electronic system 200 for verifying the authenticity of a supplementary signature, which was added to the chip card 110 by an electronic system 100 as described above.

[0102] The electronic system 200 comprises chip card 110, on which a supplementary signature has already been added. The internal memory of chip card 112 therefore contains the supplementary signature, the flag, and the pointer to the supplementary signature.

[0103] The electronic system 200 comprises, in addition to the chip card 110, a verification device 140, which is usually different from the card reader 120 used for adding the supplementary signature. For example, the card reader 120 used for adding the supplementary signature could be located at a government office such as a citizens' registration office, while the verification device might be located at a border post, for example. However, it is also possible that the card reader 120 and the verification device 140 are identical.

[0104] The verification device contains in its internal memory 142 the public key associated with the supplementary signature. Alternatively, the public key can also be stored in an external database and retrieved by the verification device 140 only for the purpose of verification.

[0105] The chip card 110 and the verification device 140 also have communication interfaces 113 and 143, which enable a connection for data exchange between the chip card 110 and the verification device 140. Establishing such a connection requires mutual authentication, for example using the EAC or BAC protocol, between the chip card 110 and the verification device.

[0106] After establishing a secure connection, the verification device 140 reads the data to be verified from the chip card 110. This includes, for example, personal data that can be used for identity checks at an international border. The verification device also reads the flag and then, using the pointer assigned to the flag, accesses and reads the supplementary signature 1123 of the chip card 110.

[0107] The supplementary signature 1123 is then used by the verification device 140 to confirm the authenticity of the data to be verified, using the public key 1423 assigned to the supplementary signature 1123.

[0108] The verification process ensures that the data being verified has not been manipulated. Subsequently, as part of the identity check, a visual comparison must be made between the person presenting the chip card and the verified data, since the authenticity of a signature does not guarantee that the data has not been copied.

[0109] Alternatively, instead of using a flag, the presence and location of the supplementary signature can be implemented in other ways. For example, the information about the presence of the supplementary signature can be stored externally, or the supplementary signature can be stored at a predefined memory address that has a predefined default value in the absence of a supplementary signature.

[0110] Fig. 2B shows, as well as Fig. 2A an electronic system 201 for verifying a supplementary signature, but in a further embodiment. Like electronic system 200, electronic system 201 comprises the chip card 110 and a verification device 140. In contrast to the one described in Fig. In the embodiment shown in 2A, the chip card 110 of the electronic system 201 additionally stores a first signature 1124, which was already present before the addition of the supplementary signature 1123.

[0111] Furthermore, the verification device 140 of the electronic system 201 has a first public key 1424, which is assigned to the first signature 1124. Thus, in the electronic system from Fig. 2B. It is possible to verify not only the supplementary signature 1123 but also the first signature 1124. In this way, the absence of manipulation can be confirmed by multiple signatures.

[0112] The supplementary signature 1123 is generated using an asymmetric post-quantum (PQC) method. This means that an asymmetric key pair is used, which cannot be broken by a cryptographically relevant quantum computer in a significantly simpler way than by a classical computer. "Significantly simpler" in this context can be understood as a change in complexity class. Possible methods for generating post-quantum key pairs are based on lattice-based cryptography, hash-based cryptography, multivariate polynomials, error-correcting codes, and / or supersingular elliptic curves.

[0113] The additional first signature, however, is generated and verified using a classic cryptographic method, for example based on RSA or ECC.

[0114] Fig. Figure 4 shows a flowchart of the interactions between the chip card 110, the card reader 120, and the signature device 130 during the generation of a supplementary signature 1123. First, in step S301, mutual authentication takes place between the chip card 110 and the card reader 120. After authentication, in step S302-1, read data from the chip card is transferred, and in step S302-2, a hash value associated with the read data is transferred from the chip card to the card reader. The hash value is then transferred from the card reader to the signature device 130 in step S303.

[0115] In step S304, the signature device creates a supplementary signature 1123 using a PQC key, which is then transmitted back from the signature device to the card reader 120 in step S305. In step S306, the card reader 120 then transmits the supplementary signature 1123 to the smart card 110. The smart card 110 then stores the received supplementary signature 1123 in its internal memory 112 and, furthermore, in step S307, adds a flag and a pointer to the supplementary signature to its management data. Alternatively, instead of storing a flag and pointer in the smart card, the information about the supplementary signature 1123 stored in the smart card 110 can also be stored elsewhere, for example, in an external database.

[0116] The supplementary signature 1123 can therefore be added to the existing EF.SOD on the chip card, for example, by means of a chip update, or the EF.SOD can be modified so that it subsequently includes the supplementary signature 1123. Alternatively, a new data group can be added to the data structure of the chip card 110, with the new data group then containing the supplementary signature 1123.

[0117] Preferably, the data previously present in the EF-SOD is still present after the addition of the supplementary signature 1123, so that backward compatibility can be ensured.

[0118] Fig. Figure 5 shows an alternative method for adding a supplementary signature 1123 to the chip card 110. In this case, the signatures already mentioned in the context of Fig. Two further steps have been added to the 4 described procedural steps.

[0119] After the secure connection between the chip card and the card reader is established in step S301, in addition to the read data and the hash value, a first signature 1124 stored on the chip card 110 is also transmitted in step S401.

[0120] This initial signature 1124 is then verified in step S402 by the card reader 120 using a public key 1424 assigned to the initial signature 1124. Only after the integrity of the read data has been confirmed by the initial signature 1124 are the subsequent steps to add the supplementary signature 1123 carried out.

[0121] This method allows PQC signatures to be added securely at a time before the existence of cryptographically relevant quantum computers, based on the tamper resistance currently guaranteed with a high probability by an ECC-based signature. Given the long lifespan of smart cards such as passports and identity cards, verification can then be switched to the PQC signature at a future point, with the PQC signature being secured by the previously existing ECC signature.

[0122] Fig. Figure 6 shows a flowchart of the procedure for verifying the authenticity of the data stored on the chip card 110 using the supplementary signature 1123.

[0123] For this purpose, a secure connection is again first established in step S501 between the chip card 110 and the verification device 140, for example by mutual authentication using BAC or EAC protocol.

[0124] Once the secure connection is established, flag information is transmitted from the chip card 110 to the verification device 140, for example, via a read access by the verification device. Alternatively, the flag information could also be received by the verification device in another way, for example, by accessing an external database.

[0125] After the verification device 140 has determined, based on the flag, that a supplementary signature 1123 is stored on the chip card 110, this supplementary signature 1123 is requested from the chip card 110 by the verification device 140 in step S503 and then read from the chip card 110 according to the pointer in step S504 and transmitted to the verification device 140 in step S505. The verification data is also transmitted from the chip card 110 to the verification device 140. The verification device 140 can then use the supplementary signature 1123 and the public key 1423 associated with the supplementary signature to verify the authenticity, or rather the lack of tampering, of the verification data received from the chip card 110 in step S506.

[0126] After successful verification, the data verified using the supplementary signature 1123 can be used as part of a personal check.

[0127] Thus, the supplementary, preferably PQC-secure, signature can be used to increase the quantum security of smart cards and other security documents. Reference symbol list 100 electronic system 101 electronic system 110 chip card 111 Microprocessor of the chip card 112 Memory slots of the chip card 1121 Data structure of the chip card 1122 Instructions for the chip card 1123 supplementary signature 1124 first signature 113 Communication interface of the chip card 120 card readers 121 Processor of the card reader 122 memory slots of the card reader 1221 Card reader data 1222 Instructions for the card reader 123 Communication interface of the card reader 130 Signature device 131 Signature Device Processor 132 Signature device memory 1321 Signature device data 1322 Instructions for the signature device 1323 secret key 133 Communication interface of the signature device 140 testing device 141 Processor of the verification device 142 Memory slots of the verification device 1421 Data from the verification device 1422 Instructions for the verification device 1423 public supplementary key 1424 public first key 143 Communication interface of the verification device 200 electronic system 201 electronic system S301 mutual authentication S302-1 Transfer from chip card to card reader S302-2 Transfer from chip card to card reader S303 Transfer from card reader to signature device S304 Creation of the supplementary signature S305 Transmission from signature device to card reader S306 Transfer from card reader to chip card S307 Saving to the chip card S401 Transfer from chip card to card reader S402 Verify first signature S501 mutual authentication S502 Transfer from chip card to card reader S503 Transfer from card reader to chip card S504 Reading the supplementary signature S505 Transfer from chip card to card reader S506 Check supplementary signature QUOTES INCLUDED IN THE DESCRIPTION

[0000] This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited non-patent literature

[0000] ISO / IEC 7816-4

[0026]

Claims

[1] Method for adding a supplementary cryptographic signature (1123) to a digital token (110), the digital token (110) comprising a data structure (1121), the method comprising the following steps: - Mutual authentication (S301) of the digital token (110) and a terminal (120); - Received (S302-1), by the terminal (120), of read data from the data structure (1121) of the digital token (110); - Transmitting (S302-2), through the terminal (120), a hash value of at least a part of the data structure (1121) to a signature device (130), wherein the hash value is part of the read data or was generated on the basis of the read data; - Creating (S304) the supplementary cryptographic signature (1123) for the hash value by the signature device (130) using a secret key (1323) of the signature device, wherein the secret key (1323) differs from cryptographic keys previously used for the digital token (110); - Transfer (S305, S306) of the supplementary cryptographic signature (1123) to the digital token (110); and - Storing (S307) the supplementary cryptographic signature (1123) in a memory (112) of the digital token (110). [2] Method according to claim 1, further comprising: - Adding a flag indicating that the digital token (110) contains the supplementary cryptographic signature (1123), and a pointer to the supplementary cryptographic signature (1123). [3] Method according to claim 2, wherein the flag and the digital pointer are added to the management data of the digital token (110). [4] Method according to any of the preceding claims, wherein the secret key (1323) was created using a cryptographic method which differs from cryptographic methods used to create the keys previously used for the digital token (110). [5] Method according to any of the preceding claims, wherein the secret key (1323) is a post-quantum cryptography key. [6] Method according to one of the preceding claims, wherein the secret key (1323) is a private key created based on one of the following asymmetric cryptographic methods: lattice-based cryptography, hash-based cryptography, multivariate polynomials, error-correcting codes and / or supersingular elliptic curves. [7] Method according to any of the preceding claims, the digital token (110) further comprising a first cryptographic signature (1124) created by a first signature device using a first private key, wherein the supplementary cryptographic signature (1123) is stored on the digital token (110) in addition to the first cryptographic signature (1124). [8] Method according to claim 7, wherein the first private key was created using a cryptographic method based on RSA or ECC. [9] Method according to claim 7 or 8, further comprising, after reading out the readout data: - Reading the first cryptographic signature (1124) of the digital token (110); and - Verifying the readout data using the first cryptographic signature (1124). [10] Method according to any one of claims 7 to 9, wherein the data structure (1121), the first cryptographic signature (1124) and / or the supplementary cryptographic signature (1123) are stored in a protected storage area of ​​the digital token (110). [11] Method according to one of claims 7 to 10, the digital token (110) further comprising a security object which includes at least one hash value formed over at least one part of the data structure (1121) and the first cryptographic signature formed over the at least one hash value, wherein the supplementary cryptographic signature (1123) is stored in the security object. [12] Method according to one of the preceding claims, wherein receiving the readout data of the data structure (1121) comprises: reading the readout data from the digital token (110) by a read access of the terminal (120) to the digital token (110). [13] Method according to one of the preceding claims, further comprising, after receiving the readout data: generating, by the terminal (120), the hash value based on at least a part of the readout data. [14] Method according to any of the preceding claims, wherein the digital token (110) is a chip card and / or a digital chip of a security document. [15] Method according to any of the preceding claims, wherein the terminal (120) is an electronic device comprising a reader and enabling read and / or write access to the token (110). [16] Method for verifying the authenticity of a data structure (1121) stored on a digital token (110), the digital token (110) comprising a supplementary cryptographic signature (1123) which was supplemented by the method according to one of claims 1-14, the method for verifying the authenticity comprising the following steps: - Mutual authentication (S501) of the digital token (110) and a second terminal (140); - Determine, through the second terminal (140), the presence of the supplementary cryptographic signature on the digital token (110) and the storage location of the supplementary cryptographic signature on the digital token (110); - Reading at least a part of the data structure (1121) of the digital token (110) by means of a read access of the second terminal (140), the read part of the data structure (1121) comprising data to be verified; - Reading, by means of a read access of the second terminal (140), the supplementary cryptographic signature using the specified storage location; - Verify, by the second terminal (140), the authenticity of the data to be verified using the supplementary cryptographic signature (1123) and one of the public keys (1323) associated with the supplementary cryptographic signature (1123). [17] The method according to claim 16, further comprising: - Determine, via the terminal (140), the presence of the supplementary cryptographic signature by reading a flag indicating the presence of the supplementary cryptographic signature (1123); - Determining the storage location of the supplementary cryptographic signature using a digital pointer associated with the flag. [18] Electronic system (100, 101) for supplementing a supplementary cryptographic signature (1123) in a digital token (110), the electronic system (100, 101) comprising the digital token (110), a terminal (120) and a signature device (130), the digital token (110) comprising a data structure (1121), and configured to: - Authenticate to the terminal (120); - Establishing a read / write connection with the terminal (120); - Storing a supplementary cryptographic signature (1123) transmitted from the terminal (120); The terminal (120) is configured to: - Authenticate against the digital token (110); - Establishing a read / write connection with the digital token (110); - Receiving readout data of the digital token's data structure (110); - Transmitting a hash value of at least a part of the data structure (1121) to the signature device (130), wherein the hash value is either part of the read data or was generated on the basis of the read data; the signature device (130) comprising a secret key (1323) which differs from cryptographic keys previously used for the digital token, the signature device (130) configured to: - Creating the supplementary cryptographic signature (1123) for the hash value by the signature device (130) using the secret key (1323); - Transmitting the supplementary cryptographic signature (1123) to the token (110). [19] Electronic system (199, 101) according to claim 18, wherein the digital token (110) is further configured to - Adding, in the administrative data of the digital token (110), a flag indicating that the digital token (110) contains the supplementary cryptographic signature (1123), and a pointer to the supplementary cryptographic signature (1123). [20] Electronic system (100, 101) according to claim 18 or 19, wherein the signature device (130) is further configured to - Transmitting the supplementary cryptographic signature (1123) to the terminal (120); and the terminal (120) remains configured to - Receiving the supplementary cryptographic signature (1123) from the signature device (130) and - to transfer the supplementary cryptographic signature (1123) to the token (110). [21] Electronic system (100, 101) according to one of claims 16 to 18, the electronic system (100, 101) further configured to carry out the method steps according to claims 1 to 14. [22] Electronic system (200, 201) for verifying the authenticity of a supplementary cryptographic signature (1123) stored on a digital token (110) created with a first electronic system (100, 101) according to one of claims 15 to 19, the electronic system comprising the digital token (110) and a second terminal (140), the digital token (110) comprising a data structure (1121), and configured to - Authenticate to the second terminal (140); and The second terminal (140) is configured to: - Authenticate against the digital token (110), - Determining the presence of the supplementary cryptographic signature on the digital token (110) and the storage location of the supplementary cryptographic signature on the digital token (110); - Reading at least a part of the data structure of the digital token; the read part of the data structure includes data to be verified; - Reading the token's supplementary cryptographic signature (110) using the specified storage location; and - Verifying the authenticity of the data to be verified using the supplementary cryptographic signature (1123) and a public key (1423) associated with the supplementary cryptographic signature. [23] Electronic system according to claim 22, wherein the second terminal is further configured to: - Reading a flag indicating the presence of the supplementary cryptographic signature; and - Reading the supplementary cryptographic signature of the token (110) using a digital pointer associated with the flag.

Images