Signature generation through a security token

Abstract

Method for generating a signature (214) for a message (M) by a processor (116) of a security token (102), wherein the method comprises: - Sequential provision (302) of parts (T1-T7) of the message (M) by the processor (116); - during sequential provisioning, applying (304) an intermediate value function (ZWF) or a completion function (AF) of a hash function (110) to each of the parts of the message immediately after the provision of said part to stepwise compute a first hash value (#H1), wherein the first hash value (#H1) is identical to a value that would have been obtained by applying the hash function (110) to the entire message (M) by the processor; - Provision (306) of one or more data values ​​(D1-D4) by the processor; - after calculating the first hash value (#H1), the processor generates (308) a concatenated value (K) by concatenating the one or more data values ​​(D1-D4) and the calculated first hash value (#H1), excluding the message from the concatenation; - Applying (310) the hash function (110) or another hash function to the concatenated value (K) to calculate a second hash value (#H2) by the processor; - Output (312) of the second hash value (#H2) by the processor for use of the second hash value as the signature (214) of the message or as a part of that signature; furthermore with: - Output of each of the provided parts of the message (M) before the calculation and / or output of the first hash value (#H1) and / or the second hash value (#H2) via an interface (119.1) of the security token; and - Release of the memory of the security token occupied by the output parts of the message immediately after output of the message part.

Description

[0001] The invention relates to a method for generating a signature by means of a security token, a security token, and a method and data processing system for verifying said signature.

[0002] Various methods for signature generation are known from the state of the art.

[0003] Smartcards often store data or generate it through various operations, which then need to be read. Typically, data, which may be stored statically on the card, is read sequentially from the smartcard and transmitted to a receiver, such as a terminal reader. The smartcard's processor generates a signature for all the data read and transmitted.

[0004] US 2002 / 0191783 A1 describes a one-way hashing algorithm that creates a message from an input message. During one iteration of the hashing algorithm, two or more "rounds" are performed, where a "round" is a computation performed on one word from a sequence of input words derived from the message, with each successive round processing the next word in the sequence.

[0005] US Patent 4,995,082 describes a data exchange system that includes processor chip cards. A chip card encodes identification data based on a random, discrete logarithm r, an exponential value x = 2r (mod p), to the participant, who in turn generates a random bit sequence e and transmits it to the chip card. For an electronic signature, a hash value e is first calculated, and then a y-value is calculated from the information r, S, j, and e. The numbers x and y then constitute the electronic signature of the message m.

[0006] The BSI document, “Advanced Security Mechanisms for Machine Readable Travel Documents and el-DAS Token”, Part 3 - Common Specifications Version 2.20, (20150203), URL: https: / / www.bsi.bund.de / SharedDocs / Downloads / EN / BSI / Publications / TechGuidelines / TR03110 / BSITR-03110_Part-3-V2_2.pdf?_blob=publicationFile&v=1, (20160314), XP055258090 and the document BSI “Advanced Security Mechanisms for Machine Readable Travel Documents and eIDAS Token - Part 2”, (20141216), URL: https: / / www.bsi.bund.de / EN / Publications / Technical-Guidelines / TR03110 / BSITR0311 0.html, (20160310), XP055257174 describes procedures and protocols for the use of machine-readable travel documents. This involves signing the data stored on the machine-readable travel documents.

[0007] Patent application DE 10 2013 110 552 A1 describes a method for providing pseudonymous keys for a hybrid encryption method.

[0008] The document "Fundamentals of electronic signatures, law, technology, application, BSI Federal Office for Information Security, 2006, 175 pages" describes procedures for generating electronic signatures.

[0009] One problem that arises with smartcard signature generation is that it often consumes too much time and / or storage space. The microprocessor in smartcards has very limited processing power, and the card's own memory resources are also very limited. In time-critical applications and / or when using low-performance smartcards, generating a signature via the smartcard is therefore sometimes impossible or impractical, which can reduce security.

[0010] In contrast, the invention is based on the objective of creating an improved method for generating a signature using a security token, as well as a corresponding security token, method and system for signature verification procedures.

[0011] The problems underlying the invention are each solved by the features of the independent claims. Embodiments of the invention are specified in the dependent claims. The embodiments listed below can be freely combined with one another, provided they are not mutually exclusive.

[0012] In the following, the term "security token" refers to any data carrier that has a processor, e.g., a microchip with a microprocessor, and an interface connected to it, and can exchange data with a suitable reading device. The security token can be an electronic document of value or security, such as an ID document.

[0013] An ID document can be, for example, an identification document such as a national identity card, passport, driver's license, vehicle registration document, or company ID card. The security document can be, for example, a means of payment such as a banknote or a credit card. The document can also be other authorization, such as an admission ticket, a travel ticket (especially an electronic ticket), a waybill, a visa, or the like. The document body can be book-like, as is the case with a passport. The interface can be contact-based or contactless. Depending on the design, the document can be, for example, plastic-based and / or paper-based. The security token can be, for example, a chip card, a USB stick, or a portable Bluetooth device.

[0014] In the following, a "reader" is understood to be a data processing device that can exchange data with the security token to enable authentication of the security token to the reader and / or authentication of the reader to the security token. Depending on the embodiment, the "reader" may include a cryptographic function for signing and / or signature verification. Optionally, the reader may have a display device and thus function as a terminal. The reader may also be connected to an external terminal or to a user computer system. In particular, the reader may implement functionalities that are known per se for readers of machine-readable travel documents (MRTDs), especially cryptographic protocols such as a Basic Access Control (BAC) and / or an Extended Access Control (EAC) protocol.In some embodiments, the reader can be configured to read data from the security token. In some application scenarios, it is necessary to ensure that only an authorized reader can access the data stored in the security token, so the reader must authenticate itself to the security token before reading this data. Preferably, the authentication includes proof that the owner of the security token has intentionally made the security token available to the reader for data retrieval. This can be achieved, for example, by the reader transmitting data visible on the surface of the security token and optically captured by the reader to the security token as proof that the user intentionally showed the security token (and the optically captureable data contained therein) to the reader. Alternatively, for example,A secret entered by the user into the reader can also be used to authenticate the reader to the security token.

[0015] A terminal is a device that can exchange data using a security token and optionally has a user interface, such as a keyboard and / or a display. A terminal can include or be connected to a reader with a data exchange interface. The data exchange interface can be, for example, a contact-based interface, an NFC (Near Field Communication) interface, or a Bluetooth interface.

[0016] In the following, a "service computer system" is understood to be a computer system that provides a service. The service can encompass a wide variety of hardware- and / or software-based functions, such as granting access to protected buildings or objects, or to software functions or data. The service can be an online service, particularly a cloud service. However, the service computer system only makes its service available to individuals who have authenticated themselves to the service computer system, i.e., who have provided the service computer system with sufficiently credible proof of their own digital identity.

[0017] In the following, an "identity (ID) provider computer system" is understood to be a computer system that confirms a user's digital identity to a third party and / or provides this digital identity to a third party. This third party can be another computer system connected to the ID provider computer system via a network, e.g., a service computer system.

[0018] An "attribute value" is a data value for an attribute and can be assigned to a user.

[0019] In the following, a "user computer system" is understood to be a data processing system, e.g. a desktop PC, a notebook or a smartphone, which allows the user to request a service provided by a service computer system via a network, e.g. the Internet.

[0020] A "revocation server" is a data processing system that manages a revocation list and makes it publicly accessible via a network. A revocation list is a list of identifiers for all security tokens that are considered insecure or no longer valid, for example, due to expiration, a loss report by the owner, or deactivation by the issuer. These identifiers can be public cryptographic keys specifically assigned to the respective security tokens, or other data values, such as numbers, that uniquely identify a security token. In some implementations, the revocation server manages multiple revocation lists, each specifically assigned to a sector, and the identifiers in the revocation lists are sector-specific identifiers, also known as "pseudonyms."

[0021] A revocation terminal is a terminal that is (at least in part) designed to check, based on a received security token identifier, whether that security token is still valid. If not, it can, for example, revoke a public cryptographic key associated with that security token, withdraw its availability, and / or inform requesting systems that this public key is not considered secure. This may be necessary, for example, if such a key has been compromised or if there is suspicion that the key is no longer secure. The revoked key is added by a certification authority to the revocation list, also known as the certificate revocation list (CRL), which is accessible to the revocation terminal for validity verification.

[0022] A "hash function" is a method for compressing data using a one-way function, making it impossible to reverse engineer the original data. For an input value of any length, the hash function yields an output value, preferably of a fixed length, and is designed such that any change to the input data is highly likely to affect the calculated hash value (i.e., the output value). Typical examples of hash algorithms are SHA-1, SHA-256, and SHA-512. The result of a hash function is the hash value, often referred to as the digital fingerprint of the input value. Mathematically, this function is not injective (left-unique) and not necessarily surjective (right-total).

[0023] An "intermediate value function" of a hash function is a compression function that, when iteratively applied to a sequence of previously unprocessed parts of a message, ultimately returns a value in the final step—that is, when processing the last unprocessed part of the message—that is identical to the value the hash function would have yielded if applied directly to the entire message. The intermediate value function uses the result of the last execution and the next unprocessed part in the sequence as input for each execution and returns a result value, called a "chaining value," as output.The very last application of the intermediate value function, which is performed on the last unprocessed part of the message and the intermediate result obtained from the previous application of the intermediate value function, and which yields the aforementioned hash value as the result for the entire message, is referred to below as the closing function. Here, a "message" is understood to be a data value consisting, for example, of one or more attribute values, especially user-specific attribute values, or other data.

[0024] A "finalization function" is a one-time intermediate value function performed on the last remaining, unprocessed part of the message. In some implementations, the finalization function is mathematically identical to the intermediate value function. In other implementations, however, the finalization function includes additional calculations, which can also be called "finalization operations." These additional calculations of the finalization function can serve various purposes. For example, the result of the iterative application of the intermediate value function can be further compressed, or the length of the finally returned hash value can be truncated to a fixed length or extended.

[0025] Here, "concatenation" refers to the concatenation of data values, e.g., the concatenation of data values ​​to create a bit sequence.

[0026] A "pseudonymized signature," "pseudonymous signature," or "blind signature" does not allow a signature verification unit to associate the signature with a specific security token and thus with a specific person. At most, it is possible to associate the signature with a group of security tokens or persons, for example, with a group of security tokens from the same issuer of the security token. This group of persons could be the employees of a specific company or the employees of a specific department within that company. Pseudonymous signatures allow a signature verification unit to check the validity of the signed data value, but not to identify the security token that generated the signature. In some implementations, checking the validity of a signed data value includes checking its authenticity (i.e., verifying that the data was not created by the company).The key factors are the affiliation with a person, a security token, or a group of security tokens, and the integrity (i.e., the authenticity) of the verified data value. It's important to note that a sector-specific "pseudonym" can indeed be unique for a particular security token or person, but only for a single terminal within the sector for which the pseudonym was generated. In contrast, a "pseudonymous signature" allows signature verification without identifying the token that generated the signature.

[0027] A "sector" is an application context for generating and verifying a signature, where the application context corresponds, for example, to a specific service provider or terminal type. Terminal types such as "airport terminal," "company premises access control terminal," or "revocation terminal" can represent such an application context. It is possible for a terminal to belong to multiple sectors.

[0028] A "static key" is an encryption key that exists before the processing APDUs and persists during and after the processing of the APDUs. Therefore, a static key still exists even after the security token's power supply is interrupted ("power-off").

[0029] In one aspect, the invention relates to a method for generating a signature for a message using a security token processor. The method comprises: - sequential delivery of parts of the message by the processor; - during sequential provisioning, applying an intermediate value function or a completion function of a hash function to each of the parts of the message immediately after the provision of said part to stepwise compute a first hash value, the first hash value being identical to a value that would have been obtained by applying the hash function to the entire message by the processor; - Providing one or more data values ​​by the processor; - after calculating the first hash value, the processor generates a concatenated value by concatenating the one or more data values ​​and the calculated first hash value, excluding the message from the concatenation; - Applying the hash function or another hash function to the concatenated value to calculate a second hash value by the processor; - Output of the second hash value by the processor for use as the signature of the message or as part of that signature.

[0030] This can be advantageous because it eliminates the need to generate the message twice (once for transmission to a recipient and once for signing the entire message that has already been issued). The message is provided only once – sequentially in parts – and an intermediate value is calculated in parallel for each of these parts. This reduces the load on the security token's microprocessor.

[0031] Furthermore, caching the entire message is unnecessary; it suffices to temporarily store the intermediate value calculated for the last provided part until the next intermediate value has been calculated. This reduces the memory consumption on the chip card, meaning that even a small amount of memory (e.g., read / write memory, especially RAM) is sufficient to sign large messages. For example, the first hash value and each intermediate value calculated for the individual parts, e.g., when using a hash function like SHA-256, comprise only 32 bytes. This can be significantly less than the memory consumption of a message, which can often be several kilobytes or more.

[0032] It is therefore no longer necessary for the message to be compiled or created for an initial transmission and then compiled or created a second time for the calculation of the signature, or for the already provided message to be temporarily stored in its entirety for the purpose of signature generation.

[0033] This also avoids the problem that the size of the storage required for the message depends on the size of the entire message to be signed and is often difficult to estimate in advance, so that in previously used signature methods more storage was often reserved than was actually needed, which had further increased the problem of storage scarcity.

[0034] In some embodiments, the security token's processor reserves a memory area in main memory for calculating the first hash value. This area is sufficiently large to store at least one part of the message and at least one intermediate value, but smaller than the size of the entire message. This can be advantageous because it reduces the amount of main memory used.

[0035] According to some embodiments, the hash function that generates the first and / or second hash value is a cryptographic hash function. A cryptographic hash function is a special type of hash function that is collision-resistant, one-way, or both. This ensures that a specific hash value is the result of one, and only one, original plaintext.

[0036] In preferred embodiments, the hash function used follows the Merkle-Damgård construction. A hash function that follows the Merkle-Damgård construction first divides each individual part (into Fig. The intermediate function (labeled T1-T7) first divides a message into blocks of fixed length, e.g., 64 bytes. If the last block of a part is shorter than this length, it is padded with additional bits, e.g., zero bits, so that the total length of each part of the message is an integer multiple of the block length. The intermediate function, also called the "compression function," takes a message part as its input and outputs the value calculated for the previous message part in a previous iteration. The hash value of the entire message is the intermediate value calculated for the last message part.

[0037] In some embodiments, the data values ​​are transmitted to the same recipient who receives the message and the signature. For example, the data values ​​can be output as part of the signature, together with the signature, or together with the message. In alternative embodiments, the recipient and the security token have already agreed on the data values ​​before the signature is created, so that these values ​​no longer need to be transmitted. However, during signature verification, it can be checked whether the data values ​​of the security token and the recipient match. For example, the data values ​​could be domain parameters that are used as input for cryptographic functions, especially key agreement functions, by the security token and the message recipient to agree on keys. This could, for example,this occurs during the Diffie-Hellman key exchange process or during the generation of a pseudonymous signature.

[0038] According to embodiments, applying the intermediate value function or the termination function of the hash function to calculate the first hash value includes: - Applying the intermediate value function to a first of the provided parts of the message, as soon as it has been provided, to calculate an intermediate value into which this first of the parts of the message is incorporated; - For each further of the sequentially provided parts of the message, the intermediate value function is reapplied to the further provided part of the message as soon as it has been provided, in order to compute a new intermediate value, taking into account the intermediate value of the previous step and the further provided part of the message, with the completion function being applied to the last provided part of the message instead of the intermediate function; - where applying the closing function to the last provided part of the message and to the last calculated intermediate value yields the first hash value.

[0039] In some embodiments, each intermediate value overwrites the intermediate value calculated in the previous step in the memory. This significantly reduces the memory required for signature generation.

[0040] For example, the intermediate value function can output a reusable intermediate value Zi with i = 1 to n-1, where n represents the number of parts of the message. The intermediate value function uses the previous intermediate value and a part i of the message to do this. A predefined intermediate value is used for the first provided part of the message. The intermediate value function of the first hash function is first applied to the predefined intermediate value and the first provided part of the message to output a second intermediate value. In the next step, the intermediate value function of the first hash function is applied to the second intermediate value and the second provided part of the message to output a third intermediate value. In the next step, the intermediate value function of the first hash function is applied to the third intermediate value and the third provided part of the message to output a fourth intermediate value.And so on. In the final step, the closing function of the first hash function is applied to the previously calculated intermediate value and the last provided part of the message to output the first hash value. This first hash value is identical to the hash value that would result if the first hash function were applied directly to the entire message (which, however, does not happen here). The intermediate value function and the closing function of the hash function are designed such that the way the message is divided into parts can influence the intermediate values, but not the calculated final result. Further information on the mathematical background of this type of function can be found, for example, in the literature on the Merkle-Damgård construction.

[0041] For example, the method for embodiments of the invention can be mathematically described as follows: M=T1‖…‖Tn with n>=2; Z1=H'(Z0,T1); Zi=H'(Zi−1,Ti)with i=2;…;n; H(M)=H''(Zn);

[0042] Or, expressed in one line: H(M) = H"(H'(...H'(H'(H'(--,T1)T2),T3)..., Tn);

[0043] Here, M represents the message, T1, ..., Tn represents a number n of submessages T. Z is an intermediate value, i is an integer from 2 to n-1, Z0 is a fixed value used to calculate the first intermediate value Z1, H is the first hash function, H' is the intermediate value function of the first hash function, and H'' is the final function of the first hash function. The resulting hash value is exactly the same as if the hash were calculated directly on the entire message M in one step using the first hash function H.

[0044] The first hash function can be any hash function. Preferably, it should be a cryptographic hash function. These offer better collision protection and are cryptographically more secure. For example, the hash function could be one of the following: Brent hash, division-remainder method, double hash, FNV, cuckoo hash, multiplicative method, midsquare method, decomposition method, digit analysis; lattice-based hash functions such as Ajtai, Micciancio, Peikert-Rosen, Fast Fourier Transform, LASH; checksum-based hash functions such as Fletcher-32, Adler-32, CRC (Cyclical Redundancy Check), parity, digit sum; and in particular cryptographic hash functions such as MD2, MD4, MD5, SHA-1, SHA-256, SHA-512, RIPEMD-160, Tiger, HAVAL, Whirlpool, LM-Hash and NTLM.

[0045] According to embodiments, the method includes releasing the memory of the security token occupied by each part of the message immediately after applying the intermediate value function or the termination function to that part of the message. Alternatively, the memory of the security token occupied by each part of the message can be released after applying the intermediate value function or the termination function to that part of the message and immediately after that part of the message has been output via an interface of the security token.

[0046] This can be advantageous because, compared to previously known signature methods, less storage space is required and the saved storage space is immediately available for other applications.

[0047] In some embodiments, the released memory is used to store intermediate values, or at least the most recently calculated intermediate value. In particular, the previously calculated intermediate value can be overwritten with an intermediate value calculated during the immediately following call to the intermediate value function, or with the first hash value calculated by the closing function.

[0048] According to some embodiments, the method further includes outputting each of the provided message parts via an interface of the security token before the calculation and / or output of the second hash value. In particular, according to some embodiments, each of the provided message parts can also be output via the security token interface before the calculation and / or output of the first hash value. Furthermore, the security token releases the memory allocated by the output message part immediately after outputting that part. This can accelerate the signature process because the message is returned not only when the second hash function is applied to the first hash value and the data values, but also as soon as the first hash value has been calculated.

[0049] According to some embodiments, the signature is a Schnorr signature. The generation of the Schnorr signature includes: - Agreement of domain parameters to define a group G of order q=|G| between the security token and a terminal; q is a prime number; The domain parameters represent a set of parameters that defines a group; the hash function used to calculate the second hash value is a cryptographic hash function H with a range of values ​​[0, q-1]; - Generation of a random number x for use as a private key, where the random number is greater than zero and less than the prime number q; - Calculation of a public key y using scalar multiplication as a group element corresponding to the private key x of the group according to y=g x; where g is a generator of the group; a generator is a subset of parameters associated with a mathematical group, from which all elements of the mathematical group can be generated by applying a group operation, - Calculation of a random number k, where the random number is greater than zero and less than the order q of the group G; - Calculation of a Schnorr signature intermediate value r by means of scalar multiplication using the generator g and the random number k, where r=g k, where this notation represents the k-fold application of the group operation; the "signature intermediate value" r is not one of the intermediate values ​​calculated by the intermediate value function of the first hash function; the signature intermediate value r is one of the data values ​​and is included in the generation of the concatenated value (K); for example, the second hash value #H2 can be calculated using the formula #H2=HF2(D1|D2|D3|r||#H1), where D1, D2, and D3 are each one of the data values, HF2 is the second hash function, which can also be identical to the first hash function, and #H1 is the first hash value; depending on the implementation, the type and number of data values ​​D1-D3 can vary. - Calculation of a result value s as the sum of the random number k and the product of the private key x and the second hash value (#H2) modulo q; expressed as a formula: s=(k + x*#H2) mod q; - Using the second hash value #H2 and the resulting value s as components of the signature of message M. Therefore: Signature S = {s, #H2}. The intermediate signature value r was incorporated into the second hash value #H2 and thus into the signature S; the resulting value s is part of the signature S and is used for signature verification.

[0050] Using a Schnorr signature is advantageous because the Schnorr signature offers a particularly high level of security.

[0051] Depending on the embodiment, the data values ​​are one or more of the following: - an intermediate value of a key exchange procedure, e.g., an intermediate value calculated during a Diffie-Hellman key exchange; the intermediate value of the key exchange procedure can be, for example, an ephemeral Diffie-Hellman key; alternatively, the intermediate value can also be a part of such an ephemeral Diffie-Hellman key or a data value derived from the ephemeral Diffie-Hellman key in some other way. For example, the intermediate value can be an identifier of the security token transmitted to a terminal. - a public key that allows a recipient to decrypt the message; the key can be specific to the security token or to a "sector"; for example, it could be the public key of a sector "PK". SECTOR“According to TR-03110 Part 2 Version 2.20; a “sector” here refers to a specific terminal type and / or a specific application scenario for the generation and verification of a signature, e.g. airport terminals for checking passports or identity documents, terminals at the entrance to company premises for checking employee ID cards, etc. - a token ID, in particular a sector-specific token ID, which can be used, for example, as a pseudonym; - a sector-specific pseudonym of a multitude of ID tokens registered with the sector (a "sector-specific pseudonym" selectively allows only terminals of a particular sector to perform an identification of the security token based on its signature). - an ID of the signature method or signature verification method to be used. This can additionally or alternatively already be stored in the terminal receiving the message.

[0052] The data values ​​concatenated with the first hash value can be, in particular, technical control data that allows the terminal receiving the concatenated value to perform further operations by evaluating the control data. These further operations can include, for example, identifying the hash algorithm to be used for signature verification, identifying a group of security tokens to which the security token belongs, and / or verifying the signature's validity in interaction with a revocation server.

[0053] The data values ​​concatenated with the first hash value can include data that is only available after all parts of the message have been output, data that is statically stored on the security token, and / or data that is dynamically calculated by a processor of the security token or received from an external source, e.g., an attribute server.

[0054] As can be seen from the aforementioned examples of data values ​​concatenated with the first hash value, integrating these data values ​​can generate additional technical benefits. The automatic transmission of this information to a terminal can enable the terminal to automatically recognize which signature verification method it should apply. Furthermore, the data values ​​can contain information that allows the terminal of a specific sector to uniquely identify the identity token, for example, to compare it against a revocation list and, if necessary, block it. In other implementations, the signature is a pseudonymous signature that prevents unauthorized tracking of the security token holder.

[0055] According to various embodiments, the parts of the message contain one or more of the following values: - an attribute value read from a memory of the security token; the attribute value can be stored, for example, in the RAM, ROM, or EPROM of the security token; the attribute value can be a user-specific attribute value and, for example, contain information about age, place of residence, or bank account details; - an attribute value received by the processor from an attribute server over a network; this can also be a user-specific attribute value; - an attribute value dynamically calculated by the security token's processor; for example, the calculated attribute value may contain metadata for other attribute values ​​stored in the security token and indicate their reliability or trustworthiness; or the calculated attribute value may be a cryptographically encrypted value obtained by encrypting an attribute value stored on the security token; - Name or other attribute values ​​of a user to whom the security token is assigned; - Authorization data of a user to whom the security token is assigned. This authorization data can be, for example, a password, a PIN, or biometric data such as a fingerprint, iris scan, facial image, or similar, which can be evaluated as a reference during an authentication process.

[0056] Reading attribute values ​​from a security token can be implemented, for example, as described in patent application WO201 1006864 A2.

[0057] According to some embodiments, the signature is a pseudonymous signature.

[0058] This can be advantageous because pseudonymous signatures in business transactions provide a high degree of security for both the user (no tracking possible) and the service provider. A terminal that reads attribute values ​​from a smart card to make them available to a service "knows," for example, after performing smart card authentication, that the attribute values ​​originate from a trusted chip. To demonstrate trustworthiness to a third party (the service), the smart card must not only deliver the data (referred to here as a "message") itself to the terminal, but also a signature that proves the authenticity and integrity of the data to be forwarded from the terminal to the service. Unlike in the prior art, the chip does not need to keep the message in memory to use it for signature generation after output to the terminal, and / or does not need to generate the data twice.Rather, the output of the data and its signing can be performed in a single step with very low memory requirements. This is particularly advantageous in the context of pseudonymous signatures, since generating pseudonymous signatures is usually computationally more intensive than generating "conventional" signatures. Thus, a particularly efficient method for generating pseudonymous signatures can be provided. This makes the use of pseudonymous signatures possible even in particularly time-critical applications, such as situations where queues at terminals must be avoided.

[0059] Another advantageous aspect is that the step-by-step calculation of the first hash value that goes into the pseudonymous signature does not reduce the cryptographic security of the pseudonymous signature, provided that the hash function is chosen to be cryptographically sufficiently secure.

[0060] In some embodiments, the security token is one of a group of security tokens. Each of the security tokens contains a public key (PK). SECTOR “) of a terminal or service provider. For example, the public key (“PK”) can be stored. SECTOR The security document is transmitted along with a request to receive the message from the terminal. Preferably, the terminal or service belongs to a specific sector, and the public key is a sector-specific public key that is identical for all terminals or services within that sector. Each security token also contains a secret static key (SK). ICC_1Each security token has a different value. Optionally, another secret static key can also be stored in the security token. Each security token is configured to generate a sector-specific token ID ("pseudonym") from the secret static keys stored in the security token and the public key ("PK"). SECTOR “) to derive, wherein the signature (214) is a pseudonymous signature referring only to the identity of the group of security tokens, the procedure comprising: - Authentication of the terminal against the security token; - In the event of successful authentication of the terminal against the security token, the security token processor calculates the sector-specific token ID and generates the message and signature; - Transmission of the generated message, the calculated sector-specific token ID and the generated signature to the terminal; - Receipt of the message, the sector-specific token ID, and the signature by the terminal; - Identification of the security token using the received sector-specific token ID. For example, this can be done by the terminal comparing the received sector-specific token ID with a list of reference token IDs and determining whether the received token ID is known to that sector. The fact that the token ID is sector-specific means that a unique identification of a specific security token and / or its associated user can only be performed by terminals within a particular sector. The sector-specific token ID prevents terminals in other sectors from identifying the token or its user. - Optionally, the terminal performs a check to see if the identified security token is listed in a revocation list. Identification of the security token by terminals that use the private key ("SK") SECTOR “) not included, is therefore excluded, which ensures data protection; In addition to or as an alternative to identifying the security token, the terminal can perform a signature check of the message to verify its integrity. For this purpose, the terminal calculates, for example, the first and second hash values ​​based on the received message and any additional data values ​​received along with the message or that may already be stored on the terminal, using the same signature generation method employed by the security token. The calculated signature is then compared with the received signature. Alternatively or additionally, the terminal can forward the message and the signature to a service computer system to allow the service computer system to verify the authenticity and integrity of the message using the forwarded signature. The sector-specific token ID is preferably not forwarded in this process.Since the signature is a pseudonymous signature, the service computer system can determine the integrity of the message using the signature, but not the identity of the security token that created the signature.

[0061] According to various embodiments, the public key (“PK”) SECTOR “) Component of an authorization certificate of the terminal or the service computer system. This authorization certificate can, for example, be stored on each security token when issued by a sector-specific issuer. The public key (“PK”) is used in the calculation of the sector-specific token ID by the security token processor. SECTOR The ID card chip contains the following data values: the "Sector Public Key" (SPC), and other data values. These other data values ​​include, for example, domain parameters of the terminal or service provider and a unique public key from the ID card chip.

[0062] For example, the calculation of the sector-specific token ID (e.g., in the form of a sector-specific pseudonym) by a security token, after successful execution of the PACE protocol and successful mutual authentication of the terminal and security token, can enable access to a data field (e.g., the "SecurityInfos" field on the new German identity card) in which the private static keys of the security token are stored. The sector-specific token ID can, for example, be a "restricted identifier" and be calculated according to the Restricted Identification Protocol (RI) of the German Federal Office for Information Security (BSI).

[0063] In some implementations, the sector-specific token ID is included in the calculation of the pseudonymous signature.

[0064] According to some implementations, the terminal first checks the validity of the pseudonymous signature and the validity of the sector-specific public key (“PK”). SECTORIf both are valid, the terminal also considers the sector-specific token ID valid and uses it – together with the private key (“SK”). SECTOR “) which is assigned to the sector.

[0065] For example, according to embodiments of the invention, the message can be a certificate. The signature can, for example, be a pseudonymous signature for certificates according to the technical guideline TR-03110 Part 2 v. 2.20, wherein the attribute values ​​of the certificate serve as individual parts of the message and the first hash value is calculated step by step as described for these attribute values ​​(validity period, issuer, public key of the certificate, etc.).

[0066] Alternatively, according to embodiments of the invention, the signature can also be a pseudonymous signature of a message. The message can, for example, consist of several attribute values ​​that the security token's processor reads from a memory of the security token and / or other sources, with the intermediate value function and the closing function being applied to the attribute values ​​as parts of the message. It is also possible for the processor to read a longer data value from said memory and, during the reading process (i.e., before the entire message content has been loaded into the security token's main memory), to use the data stream, for example, after reaching a predefined maximum size, e.g., 10 kB, as part of the message and apply the intermediate value function and the closing function of the hash function to it.In this case, the "parts of the message" are not semantically defined, but rather solely by the size of the data already provided by the processor. The parts of the message here are therefore not individual attribute values ​​(with defined semantic content) but rather sequentially provided message packets of a predefined size (e.g., 10 kB message parts) by the processor.

[0067] All pseudonymous signatures created for a specific sector can be verified using the sector-specific public key (PK). SECTOR ) be verified.

[0068] In some implementations, the sector-specific token ID is calculated by the security token and forwarded to the terminal only if the terminal has previously proven to the security token that it is authorized to receive the sector-specific token ID (this corresponds to proof of being a "revocation terminal"). This security measure can be useful because the sector-specific token ID, in combination with other data values ​​such as the public sector-specific key (PK), SECTORThis enables identification of the token. Verification can be carried out, for example, using an authorization certificate. The terminal then compares the received sector-specific token ID, or a value derived from it, with the contents of a revocation list on a revocation server to check whether the security token has been revoked and whether all messages and signatures received from it must therefore be treated as no longer valid or trusted.

[0069] Thus, a very efficient method for generating a pseudonymous signature can be provided, which nevertheless allows individual identification of the security token, at least by authorized terminals, so that revocation of the security token becomes possible.

[0070] In some embodiments, the message comprises or consists of multiple attribute values. Each attribute value can function as one of the parts of the message. Providing at least one of the attribute values ​​involves reading the first attribute value from a protected memory of the security token. Additionally or alternatively, providing at least one of the attribute values ​​involves dynamically calculating the second attribute value by the security token's processor. Additionally or alternatively, providing at least one of the attribute values ​​involves receiving the third attribute value from an attribute server over a network by the security token's processor and making the received third attribute value available via the processor.Combining different attribute sources can be advantageous because the security token can act as a central access point for a multitude of attribute values, including those obtained from an external attribute server. Particularly with a large number of attribute values, this results in a significant reduction in the storage or data processing overhead required for signature generation for the attribute-based message.

[0071] In some embodiments, the security token is an identity document assigned to a user. The process includes authentication of the user against the security token and authentication of an ID provider computer system against the security token. After successful authentication of the user and the ID provider computer system against the security token, one or more attribute values ​​provided by the security document's processor are transmitted as part of the message to the ID provider computer system, and these attribute values ​​are then transmitted from the ID provider computer system to a service computer system.The provision of the attribute values ​​as part of the message to the ID provider computer system is carried out as described for previous implementations, whereby the attribute values, one or more of which represent a part of the message, are provided immediately after availability and after an intermediate value for that part has been calculated. The message signature calculated from the intermediate values ​​is also subsequently transmitted to the service computer system. The service computer system can then perform a corresponding signature verification procedure.

[0072] According to embodiments, the method further comprises authentication of the user to the security token and authentication of an ID provider computer system to the security token; after successful authentication of the user and the ID provider computer system to the security token, the ID provider computer system determines that at least one of the attribute values ​​requested by the ID provider computer system is not stored in the security token and cannot be calculated.Upon detection, the ID provider computer system instructs an attribute server to authenticate against the security token. The attribute server authenticates against the security token. After successful authentication, the attribute server transmits the third attribute value to the security token for storage by the security token's processor in a protected memory within the security token and / or for the processor to deliver the transmitted third attribute value as part of a message to the service computer system. This can be advantageous because it allows the security token to obtain additional attribute values ​​from an external source, which can then be made available immediately or at a later time as part of a message to a terminal or service computer system.

[0073] According to embodiments, the method further comprises: - Sending a request from a user computer system to the service computer system; the request can be sent, for example, as an HTTP request from a browser application program of the user computer system to the service computer system; - Generation of an attribute specification including a specification of one or more attributes by the service computer system; for example, the attribute specification could include that attribute values ​​for a first, second and / or third attribute are required by the service computer system, e.g., information regarding place of residence, age, authorization to drive a vehicle, etc.; and - Sending the attribute specification from the service computer system to the ID provider computer system. The security token transmits the attribute values ​​of the one or more attributes specified in the attribute specification to the ID provider computer system as part of the message, preferably immediately after the intermediate value function or the closing function has been applied to a portion of the message corresponding to that attribute value. The transmission is performed such that, before the transmission of each portion or attribute value of the message, an intermediate signature value is calculated as described for embodiments of the method. A portion of the message can correspond to a single attribute value or to multiple attribute values. The message signature is also transmitted to the ID provider computer system.The message, consisting of the sequentially provided attribute values, the signature, and optionally the data values ​​(which may be concatenated with the first hash value), are forwarded from the ID provider computer system to the service computer system. The service computer system checks the transmitted attribute values ​​and the validity of the signature as prerequisites for executing a transaction based on the request. For example, a car rental company will only provide a user with a vehicle if they are over 18 years old and possess a driver's license.

[0074] In another aspect, the invention relates to a security token comprising a processor. The security token is configured to execute a method according to one of the embodiments described above. As can be seen from the respective embodiments described, the individual method steps can be executed by the security token alone or in interaction with a user, a terminal, an ID provider computer system, and / or an attribute server.

[0075] In another aspect, the invention relates to a method for verifying the signature of a message. The signature can be provided, for example, by a security token processor, as described above. The method can be implemented on and executed by a data processing system, such as a terminal, a reader, or a service computer system. The method comprises: - Receiving a message and a signature on that message; for example, the message and its signature can be received together, e.g., if a reader first bundles the message and the signature into a larger message unit and forwards it directly or indirectly to a recipient, e.g., a service computer system. The message can also be received sequentially in parts directly from the security token, and the signature can be obtained from the security token by the recipient after the message has been completely transmitted to the direct recipient. Depending on the implementation, data values ​​that are concatenated in a later step can be received by the data processing system before, together with, or after the message is received. However, it is also possible that the data values ​​are wholly or partially data values ​​that were agreed upon in advance between the security token and the data processing system. This can, for example,This might be the case for domain parameters used in certain cryptographic functions, such as a Diffie-Hellman key exchange. The data value(s) in question can also be part of the signature or be received along with it. - Applying a hash function to the received message to calculate an initial hash value; the hash function used here must be identical to a hash function used by the security token to generate the initial hash value; - Generation of a concatenated value by concatenating the one or more data values ​​and the calculated first hash value, excluding the message from the concatenation; - Applying the hash function or another hash function to the concatenated value to calculate a second hash value; the hash function used in this step must be identical to the hash function used by the security token to generate the second hash value. As already described for signature generation, according to embodiments, the hash functions used to generate the first and second hash values ​​can be identical; - Check whether the calculated second hash value is identical to a hash value contained in the received signature; the hash value contained in the received signature corresponds to the second hash value calculated during signature generation, as previously described for various implementations of the signature generation procedure. The message signature is considered invalid if this check reveals no identity. If the calculated first hash value or any of the data values ​​concatenated by the data processing system differs from the first hash value and the data values ​​concatenated by the security token, the resulting second hash values ​​will also differ.

[0076] The aforementioned signature verification method can be advantageous because it allows for the verification of a signature generated according to the previously described efficient and resource-saving signature generation process. The concatenation method used in the signature verification process is identical to the concatenation method used by the security token.

[0077] In another aspect, the invention relates to a data processing system, e.g., a terminal, a reader, or a service computer system, with an interface for receiving a message and a signature on that message. According to some embodiments, the interface can also be configured to receive one or more data values, or these data values ​​can be pre-stored on the data processing system. The one or more data values ​​can also be part of the signature or be transmitted together with it. The interface can be configured as a contactless or contact-based interface for direct data exchange with a security token, e.g., a smart card, or as an interface for receiving the message and the signature via a network, e.g., from a user computer system or from an ID provider computer system. The data processing system includes a processor configured to: - Receipt of the message and the signature; In some embodiments, the interface is also designed to receive one or more data values; However, the data values ​​can also be stored in the data processing system before receiving the message, e.g., after the security token and the data processing system have dynamically agreed on the data values ​​(cryptographic keys in a key exchange procedure or pre-stored domain parameters, etc.); - Applying a hash function to the received message to calculate an initial hash value; this hash function is identical to the hash function of the security token, which calculates the initial hash value there; - Generation of a concatenated value by concatenating the one or more data values ​​and the calculated first hash value, excluding the message from the concatenation; - Applying the hash function or another hash function to the concatenated value to calculate a second hash value; this hash function is identical to the hash function of the security token that calculates the second hash value there; the hash functions for calculating the first and second hash values ​​can be identical. - Checking whether the calculated second hash value is identical to a hash value contained in the received signature (which corresponds to the second hash value calculated by the security token), whereby the signature of the message is considered invalid if this check shows that there is no identity.

[0078] Embodiments of the invention will now be explained in more detail with reference to the drawings. These show: Fig. 1 a block diagram of a system with a security token and a service computer system according to embodiments of the invention; Fig. 2 a scheme for generating a signature using a security token; Fig. 3. A flowchart of a procedure for generating a signature; Fig. 4. Multiple security tokens that are assigned to different users and can generate pseudonymous signatures.

[0079] The Fig. Figure 1 shows a security token 102, which is designed, for example, as a chip card. The security token is assigned to a user 101. The token has non-volatile memory 104, on which one or more attribute values ​​106 and one or more data values ​​108 are stored. Alternatively or additionally to the stored attribute values ​​106, the security token has program logic 111 for the dynamic calculation of one or more attribute values. Furthermore, the memory 104 contains program logic for executing a hash function 101 to calculate an initial hash value (see Figure 10). Fig. 2 #H1), a program logic for executing a hash function 180 to calculate a second hash value (see Fig. 2 #H2), program logic for executing a concatenation function 112, as well as program logic 114 for generating a message signature that can control the concerted execution of the aforementioned program logics, are stored. These functions and program logics are executed by a processor 116 of the security token 102. For example, the processor could be a chip card microcontroller. The chip card microcontroller is a microcontroller specifically optimized for the requirements of chip cards. The improvements primarily concern aspects of chip security, chip size, and special functional units for chip card-specific requirements.

[0080] Furthermore, the chip card has a memory 118 for storing data. This memory 118 can be a volatile data storage medium, such as RAM. The security token can exchange data with a reader 120 via an interface 119.1, 119.2. This interface can be contact-based or contactless.

[0081] The reader 120 can be connected to a user computer 122, which is assigned to user 101. The user computer system includes a processor 126 and a data storage device 124, on which, for example, a program for managing the attribute values ​​106 and data values ​​108 stored in the security token can be installed.

[0082] The user computer system 122 is connected to a service computer system 144 and optionally also to an ID provider computer system 128 and / or an attribute server 136 via a network, for example, the Internet 134. The ID provider computer system 128 has a processor 132 and a data storage device 130, in which program logic for confirming the user's identity to, for example, the service computer system 144 is installed. The attribute server 136 has a processor 142 and a non-volatile storage medium 138, in which further attribute values ​​140, assigned to the user 101, are stored. The storage device 138 can contain the attribute values ​​of a large number of users.

[0083] User 101 can, for example, use their user computer system 122 to access a service provided via the internet by the service computer system 144. This service could be, for example, a car rental service. To reserve a vehicle from the service, the user securely transmits their identity, specifically their name and address, and possibly also account information. The user also transmits further attribute values ​​to the service, such as their age and whether they possess a driver's license. For this purpose, the user can insert a security token, such as their electronic identity card, into the reader 120. This token stores the relevant data and attribute values.

[0084] After the user has authenticated themselves to the security token, for example by entering a PIN, and after an application installed on the user's computer system, in interaction with an ID provider computer system 128, has caused the ID provider computer system 128 to successfully authenticate itself to the security token, the attribute values ​​106 and possibly other dynamically calculated attribute values ​​are sequentially provided by the security token's processor, while in parallel a first hash value is calculated by the processor 116 (see Fig. 2) The first hash value is concatenated with one or more other data values ​​to calculate a second hash value, which is incorporated into a signature. The attribute values, which represent components of a message, and the signature are transmitted to the ID provider computer system. For example, the service computer system may have previously transmitted a list of all required attributes, e.g., in the form of an attribute specification, to the ID provider computer system, and the ID provider computer system may request only the attributes specified in the attribute specification from the security token. The receipt of the attribute values ​​from the security token by the ID provider computer system 128 may require mutual authentication between the security token 102 and the ID provider computer system. The ID provider computer system then forwards the attribute values ​​and their signature to a service computer system. The message, i.e., the (possibly...The attribute values ​​(specified in an attribute specification) are then transferred from the ID provider computer system to the service computer system. The service computer system can then perform a corresponding signature verification procedure.

[0085] In some embodiments, the security token may also obtain one or more of the attribute values ​​it outputs from an external source, for example, an attribute server 136, via the network 134. After successful authentication of the user to the security token and successful authentication of the ID provider computer system to the security token, the ID provider computer system determines that at least one of the attribute values ​​requested by the ID provider computer system is not stored in the security token and cannot be calculated. Upon this determination, the ID provider computer system 128 instructs the attribute server 136 to authenticate itself to the security token 102. After successful authentication of the attribute server to the security token, the attribute server transmits one or more attribute values ​​to the security token.The transmitted attribute values ​​can be stored in memory 104 of the security token, for example in encrypted form, and output in response to an attribute request from the service computer system and / or at a later time. Since the signature generation method used requires little memory and does not necessitate providing all attribute values ​​twice—once for transmission to the service computer system and once for signature generation—the described signature generation method is particularly suitable for quickly and efficiently generating signatures, even for long messages with a large number of attribute values.

[0086] Fig. Figure 2 shows an embodiment of the inventive method for generating a signature 214 for a message M by a processor 116 of the security token 102. First, several parts T1-T7 of a message M are sequentially provided by the processor 116. This provision can include reading the parts from a data memory 104 of the security token, dynamically calculating 111 of the parts by the processor 116, and / or receiving the parts from an external data source 136A via a network 134.During the provisioning process, i.e., at a point in time when the security token has fully loaded one or more of its parts into memory and is therefore available, but not all parts of the message have yet been loaded into memory 118 and are therefore available, the processor 116 applies an intermediate value function ZWF or, in the final computation step, a completion function AF of a hash function 110 to the currently provided part of the message, immediately after the provisioning of the respective part. Thus, a first hash value #H1 is calculated step by step, which is identical to the value that would have been obtained by applying the hash function 110 to the entire message M (provided that the order of the parts of the message in the entire message corresponds to the chronological sequence of the provisioning of the parts).This is ensured by the program logic 114 implemented on the security token for generating the signature 214. The chronological sequence of providing the message parts is such that at time t1, part T1 is provided first, then part T2 at time t2, then part T3 at time t3, and so on. Parts T1, T2, T4, and T7 can, for example, be previously stored attribute values ​​106. Part T3 can, for example, be an attribute value dynamically calculated using module 111. Parts T5 and T6 can be attribute values ​​140 received from an attribute server 136 via a network.

[0087] The application of the intermediate value function ZWF or the completion function AF of the hash function 110 is carried out as follows: the intermediate value function ZWF is applied to a first part T1 of the message as soon as it has been provided, in order to compute a first intermediate value 202. This first intermediate value 202 incorporates the first part T1 and a predefined value VDW of the hash function 110. The first intermediate value 202 occupies a specific memory area in memory 118. Once the first intermediate value 202 has been computed, part T1 is output as part of the message M (for example, to the reader 120 for forwarding to the ID provider computer system and / or service computer system 144). In a subsequent step, the intermediate value function ZWF is applied again, this time to the first intermediate value 202 and the second part T2 of the message, so that a second intermediate value 204 is returned.The second intermediate value 204 overwrites the first intermediate value 202 in memory 118. The overwriting process is described in . Fig. The second step is indicated by "DEL 202!". This is repeated for each of the provided parts of the message up to part T6, so that an intermediate value 212 is returned. A closing function AF is applied to this and to the last part T7 of the message, which returns the first hash value #H1. The first hash value is identical to the value that would have been obtained if the hash function 110 had been applied directly to the entire message M consisting of parts T1-T7.

[0088] Finally, processor 116 provides one or more data values ​​D1 to D4. These data values ​​can be, for example, technical control data that allows the recipient to select a suitable signature verification method to verify the signature 214 and / or to uniquely determine the identity of the security token 102, for example, to search for it in a revocation list to check whether the security token is still valid. Typically, but not necessarily, the parts of the message are user-related data, while the data values ​​D1-D4 can be technical or cryptographic parameters and data values, key or token IDs.

[0089] In a further step, the data values ​​D1-D4 and the first hash value #H1 are concatenated by applying the concatenation function 112, resulting in a concatenated value K. The hash function 110 or another, "second" hash function 180 is applied to the concatenated value K, returning a second hash value #H2. Because the second hash value is derived from a concatenated value that contains only the hash #H1 of message M, but not the entire message M, it is not necessary to wait to output message M until the second hash value #H2 and / or the signature 214 have been calculated. Instead, message M can be output sequentially, such that each part of the message is output immediately after the intermediate value function ZWF or the closing function AW has been applied to that part.

[0090] The second hash value #H2 becomes part of the signature 214 generated for the message.

[0091] Additional data values ​​can be included in the signature 214. For example, some or all of the data values ​​D1-D4 can be used in the generation of the signature 214 and optionally output along with it or at a later time. Alternatively, some or all of the data values ​​D1-D4 may already be present on the recipient's side, for example, in a data processing system that is to perform signature verification, such as in a service computer system, a revocation terminal, another terminal, or the like. In this case, the identity of the data values ​​used by the security token and the data values ​​used by the recipient can be verified by calculating the second hash value #H2' from the received message M and the other data values ​​D1-D4 stored on the recipient's side.For example, the data values ​​D1-D4 could be domain parameters agreed upon between the security token and a terminal, and the second hash value #H2 could be used to confirm the identity of the agreed-upon domain parameters without having to exchange the domain parameters between the token and the terminal.

[0092] Fig. Figure 3 shows a flowchart of an embodiment of a method for generating a signature 214 for a message M by a processor 116 of a security token 102. In the method, in a first step, 302 parts T1-T7 of the message M are sequentially provided by the processor 116. These parts can be, for example, attribute values ​​assigned to a user 101 who possesses the security token and to whom it is assigned. During the sequential provisioning, 304 an intermediate value function ZWF or a completion function AF of a hash function 110 is applied to each part of the message immediately after the provision of said part. This stepwise computes a first hash value #H1. This is identical to a value that would have been obtained by applying the hash function 110 to the entire message M.In a further step 306, the processor 116 provides one or more data values ​​D1-D4. After calculating the first hash value for (i.e., not on) the fully provided message, the processor generates a concatenated value K in step 308 by concatenating the one or more data values ​​D1-D4 and the calculated first hash value #H1. The message M is excluded from the concatenation; that is, it is not one of the data values ​​and only contributes to the second hash value via the first hash value calculated for it. In step 310, the processor applies the hash function 110 or another hash function to the concatenated value K to calculate the second hash value #H2. In step 312, the processor outputs the second hash value #H2 for use as the signature 214 of the message or as a component of that signature 214.For example, the signature can be transmitted to a reader 120, and from there to an ID server computer system and / or a service computer system 144 and / or another recipient, e.g. a terminal.

[0093] Fig. Figure 4 shows several security tokens 420, 422, 424, 426, e.g., chip cards, configured to generate a sector-specific, pseudonymous signature, according to one embodiment of the invention. Each security token is assigned to a user 101, 404, 406, 408. The security tokens 420, 422, 424, 426 form a group of security tokens belonging to the same sector and configured to generate a pseudonymous signature. The pseudonymous signature 214 thus generated allows identification of the group of tokens, but not of the individual tokens.

[0094] A Terminal 428, which might be located at an airport or at the entrance to a company premises, for example, can be one of several terminals (not shown) in the same sector. All of these terminals in the sector can be configured to verify the pseudonymous signature of a message received by a security token.

[0095] Before the security tokens 101, 404-408 are issued, an asymmetric cryptographic key pair is generated by a program logic operated by the issuer (“group manager”) over a set of domain parameters Q, where the key pair contains a private key SK. M and a public key PK M Includes an extended set of domain parameters Q^, which also includes the public key PK. MThe information contained in each of the sector's security tokens is stored by the token issuer. Each terminal of a given sector contains a public key (PK). SECTOR , which together with a private sector-specific key SK SECTOR forms an asymmetric cryptographic key pair.

[0096] The security token has a specifically assigned public key, which is referred to below as PK. ICC is referred to as a private key, which is called SK ICC is designated, assigned, PK ICC and SK ICC They form an asymmetric cryptographic key pair. The private key SK ICC is not stored in the security token. The public key (PK) is not stored in the security token. ICC can be transferred to the security token, for example, during the PACE mapping phase or during a Diffie-Hellman key exchange procedure.

[0097] The "group manager" generates a random SK value for each token to be issued. ICC_2 and calculates another value SK from this random value using linear decomposition ICC_1 e.g. such that the following equation is satisfied: SK M =SK ICC_1 + SK M * SK ICC_2 Other forms of linear decomposition are also possible. The values ​​SK determined in this way 1CC _1 and SK ICC_2 are unique to each of the security tokens. The SK value ICC_1 is stored on the token as the first private static key, to which an identifier ID-SK is assigned. ICC_1 is assigned. The assignment can be static, for example, and can be made by the processor of the ID token (e.g., at the instigation of the group manager) using a key derivation function and a public sector-specific key (PK). SEKTORThe sector to which the group manager belongs calculates the identifier for later use. The identifier ID-SK ICC_1 The identifier can be dynamically calculated during the calculation of the pseudonymous signature and is therefore not stored in the ID token. Alternatively, the identifier generated for a sector can be pre-calculated and stored in the ID token if the corresponding sector-specific public sector key has been provided to the ID token beforehand. If the ID token is to authenticate with terminals in multiple sectors, several sector-specific identifiers can be pre-calculated from the token's private key and a public sector key of the respective sector.

[0098] The pre-calculation and storage of permanent or at least reusable static keys and identifiers can, for example, enable revocation using these identifiers by a terminal of an authorized revocation sector. In this case, the identifier does not serve as a pseudonym.

[0099] The static keys SK ICC_1 or SK ICC_2 and their identifiers ID-SK ICC_1 or ID-SK ICC_2 (and values ​​derived from these) are used to calculate a signature that is the same for all tokens in a sector ("pseudonymous signature"). The identifiers ID-SK ICC_1 or ID-SK ICC_2These are "pseudonyms," meaning data values ​​that selectively allow terminals within a specific sector to identify an ID token. A "pseudonym" (not to be confused with a "pseudonymous signature") is a data value that serves as an identifier for an ID token only for the terminals within a specific sector, thus preventing tracking across different sectors using this data value ("pseudonym").

[0100] The data value ID-SK ICC_1 is therefore a system defined by the ID token based on the sector specified by the terminal (e.g., PK). REVOCATION ) calculated “pseudonym”. All terminals in a sector have the same public sector key. Only terminals in the sector whose public sector key formed the basis for the derivation of the static keys, and which possess the corresponding public sector key, can use the ID token based on the data value ID-SK. ICC_1 (or ID-SK) ICC_2) uniquely identify.

[0101] Alternatively or additionally, the value SK is also used ICC_2 Stored on the token as a second private static key, to which an identifier ID-SK is assigned. ICC_2 is assigned. Instead of the private cryptographic key SK ICC Therefore, a first and a second static private key SK will be used. ICC_1 , SK ICC_2 Stored in the security token. Depending on the implementation, the group manager stores an assignment of the identifiers ID-SK. ICC_1 and / or ID-SK ICC_2 to the security token, on which the corresponding first and second secret static keys, identified by ID-SK, are located. ICC_1 and ID-SK ICC_2 They can be identified and stored. Preferably, the two identifiers are ID-SK. ICC_1 and ID-SK ICC_2Each assignment is sector-specific. This assignment can be transferred to terminals or stored in such a way that the assignment can be read by some terminals after authentication.

[0102] Furthermore, the terminals of a specific sector (e.g., entry control terminals of a particular company or airport control terminals) receive the public, sector-specific key PK. SECTOR , the extended domain parameters D^ and the private key SK SECTOR , which uses the public key PK SECTOR forms an asymmetric cryptographic key pair.

[0103] If one or more of the terminals are configured as a 428 revocation terminal, i.e., a terminal that is allowed to request the token ID of the security token in order to determine the identity of the security token based on this token ID and compare it with a revocation list, it also receives a public revocation key PK. REVOCATION The revocation list can be provided, for example, by a revocation server 418 over a network. Using the revocation key PK REVOCATION The private key SK, which is transmitted to the security token via command, allows the terminal to authenticate itself to the security token as authorized to receive the token ID. REVOCATION , which is stored in the terminal, forms a combination with the public key PK REVOCATION an asymmetric cryptographic key pair.

[0104] On all terminals of the sector, the extended set of domain parameters Q" and the public sector-specific key PK are used. SECTOR stored. Also with the public key (PK). REVOCATION It could be a form of sector-specific public key (PK). SECTOR trade, which is issued specifically for terminals that are trained to revoke a particular group of security tokens.

[0105] The calculation of the pseudonymous signature 214 is now performed by the processors of each of the security tokens, for example according to the following procedure: First, the token calculates the first hash value #H1 of the message M, as already described for embodiments of the invention. Each part of the message that has already been processed can be immediately output, e.g., to a terminal that has identified itself to the token as authorized to receive the message M.

[0106] The token uses a cryptographic group GR with base point b and an order q of the domain parameters G. The pseudonymous signature PS for a message M is now generated as follows: PS=PSign(Q^, ID-SK ICC_1 , and ID-SK ICC_2 , SK ICC_1 , SK ICC_2 , ID-DSI, M), where ID-DSI identifies the signature generation procedure to be performed and, accordingly, the signature verification procedure to be applied by the terminal. The values ​​ID-SK ICC_1 , and ID-SK ICC_2 The data can be pre-stored in the token or dynamically transferred from the terminal to the ID token to enable the generation of a pseudonymous signature. The PSign function involves the following steps: 1. Choose the random numbers Z1, Z2 from the set of natural numbers greater than zero. 2. Calculate a value ZQ1 using a key agreement function KA according to ZQ1=KA(Z1, b)*KA(Z2, PK M ), where PKM a public key of the issuer of the security token and is specific to a sector, with this public key being stored on each of the security tokens of the sector; 3. Calculate a value ZA1=KA(Z1, PK SECTOR ) provided ID-SK ICC_1 was passed as an argument to the PSign function, where KA is a key agreement function; 4. Calculate a value ZA2=KA(Z2, PK) SECTOR ) provided ID-SK ICC_2 was passed as an argument to the PSign function; 5. If ZQ1=0 or ZA1=0 or ZA2=0, repeat steps 1-5; 6. Calculate a concatenated value K according to K = Concatenation function (ZQll ID-SK) ICC_1 |ZA1|ID-SK ICC_2 |ZA2|PK SECTOR |ID-DSI|#H1); 7. Calculate a second hash value #H2 according to #H2=H(K), where H represents the second hash function, which can be identical to the first hash function; 8. Calculate the value s1 according to s1=Z1-#H2*SK ICC_1 mod q; 9. Calculate the value s2 according to s2=Z2-#H2*SK ICC_2 mod q; 10. If s1 or s2 is equal to zero, repeat steps 1-10; 11th edition of #H2, s1, and s2 as part of the pseudonymous signature 124.

[0107] The pseudonymous signature can, for example, be output after the already output message M and transmitted to the recipient of message M. Furthermore, the values ​​ZQ1, the pseudonym (e.g., ID-SK) can be used. ICC_1 and / or ID-SK ICC_2 or derived values ​​that serve as pseudonyms, e.g. ZA1 and / or ZA2), PK SECTOR The ID-DSI values ​​are transmitted to the recipient. These values ​​correspond to data values ​​D1-D4 of the Fig. 2.

[0108] Regarding the values ​​ID-SK ICC_1 and ID-SK ICC_2Each of these can be a pseudonym calculated by the processor of an ID token using a public sector key provided by the terminals of a sector for all ID tokens belonging to that sector. For example, the value ID-SK could be... ICC_1 using a key derivation function KA (e.g. Diffie-Hellman method) and the public sector key PK SECTOR of the respective sector are calculated according to: ID-SK ICC_1 = KA(SK ICC_1 , PK SECTOR The function "KA" can, for example, be a "key agreement function" according to Diffie-Hellman. Similarly, ID-SK can be... ICC_2 Calculated according to: ID-SK ICC_2 = KA(SK ICC_2 , PK SECTORThe intermediate values ​​ZA1 and ZA2 can also be considered further sector-specific pseudonyms, which allow a terminal of a sector, for which the linear decomposition of the private sector-specific key into the two static keys has been performed, to identify the security token. ID-SK ICC_1 and ID-SK ICC_2 They can be calculated, for example, as pseudonyms resulting from a "half Diffie-Hellman" step, as described, for example, in TR-03110 Part 2, p. 30. Fig. Figure 5 illustrates this. To enable this identification, according to certain embodiments, the intermediate values ​​ZA1 and / or ZA2 are transferred from the token to the terminal as additional data values. The intermediate values ​​ZA1 and ZA2 can be considered further sector-specific pseudonyms when they are additionally transmitted to the terminal. Depending on the embodiment, an identifier (ID-SK) can therefore be used. ICC_1 and / or ID-SK ICC_2) of the first and / or second static key (SK ICC_1 and / or SK ICC_2 ) or a value derived from it can serve as a pseudonym. For example, the first and / or second static keys and the corresponding identifiers can be dynamically generated by the ID token processor during each signature process (tracking is therefore not possible; the identifiers or their derived values ​​are thus "pseudonymous").

[0109] If the terminal has proven its authorization to identify the token to the token, a sector-specific pseudonym, which uniquely identifies the security token within a sector, can be transmitted to the terminal as an additional data value. For example, the sector could be a "revocation sector" and the terminal a revocation terminal. The public sector-specific key (PK) SECTORIn this case, the public revocation key PK can be used. REVOCATION consist.

[0110] For example, the first ID (the first identifier) ​​could be “ID-SK”. ICC_1 “the first static key SK” ICC_1 and a second ID (second identifier) ​​“ID-SK ICC_2 “the second static key SK” ICC_2 of the security token according to TR-03110 Part 2 Version 2.20. According to embodiments, a security token can use its first and / or second static, token-specific private key to derive a pseudonymous signature that does not allow any inference about the identity of the security token, since both components of the linear decomposition that generated the first and second static keys are included in the signature.

[0111] The verification of the pseudonymous signature can now be performed by the receiving terminal as follows: First, the terminal calculates a first hash value #H1' of the received message M using the same hash function that was used by the token to calculate the first hash value.

[0112] By executing the PVerify function, the terminal verifies the integrity of the message. The function call includes the following arguments: PVerify (Q^, PK SECTOR , PKicc, ID-SK ICC_1 , ID-SK ICC_2 , ID-DSI, #H2, s1, s2);

[0113] The execution of the PVrify function involves the following steps: 1. Calculation of a value ZQ1' using a key agreement function KA according to ZQ1=KA(#H2, PK PICC )*KA(s1, b)*KA(s2, PK M ), where PK PICC the static public key of the security token; 2. If the terminal is authorized to individually identify the token, e.g., to check the revocation status, calculate a value ZA1'=KA(#H2, ID-SK).ICC_1 ) * KA(s1, PK SECTOR ); 3. If the terminal is authorized to revoke the security token and / or to individually identify the token, and if, in addition to or as an alternative to identifying the token using the first static private key SK ICC_1 identification using the second static private key SK ICC_2 The calculation of a value ZA2'=KA(#H2, ID-SK) is to take place. ICC_2 ) * KA(s2, PK SECTOR ); 4. Calculation of a concatenated value K' according to K'=concatenation function(ZQ1| ID-SK) ICC_1 |ZA1'|ID-SK ICC_2 |ZA2'|PK SECTOR |ID-DSI|#H1'); 5. Calculation of a second hash value #H2' according to #H2'=H(K'), where H represents the second hash function used by the token to calculate the second hash value #H2 and which may be identical to the first hash function; 6. If the hash value #H2 contained in signature 124 and the hash value #H2' calculated by the terminal are identical, the pseudonymous signature is considered valid.

[0114] The signature 214 generated in this way, containing the values ​​s1, s2 and #H2, does not allow identification of the security token, since the values ​​s1 and s2 are derived from random numbers, and #H2 depends on the content of the message M, thus preventing unauthorized tracking by the operator of the terminals.

[0115] If the terminal is a revocation terminal that has successfully authenticated itself to the security token as authorized to identify the token, the identifier ("ID-SK") will be displayed. ICC_1 / 2The first and / or second static key, as defined in the embodiments of the security token, is transmitted to the revocation terminal. The terminal has access to the mapping of the transmitted identifiers to the individual tokens and is operationally connected to a revocation server. Based on the transmitted identifier(s), the revocation terminal identifies the first and / or second private static key SK associated with the security token. ICC_1 , SK ICC_2 and checks whether a public key associated with this security token, or the security token itself, is listed on a revocation list. In this case, according to some implementations, the security token can be completely invalidated or retained by the terminal and / or the pseudonymous signature is considered invalid and is not forwarded to the service computer system. Reference symbol list 101 users 102 security tokens 104 data storage devices 106 stored attribute values 108 data values ​​D1-D4 110 Hash function 111 Logic for dynamic attribute value calculation 112 Concatenation function 114 Function for generating a signature 116 processor 118 MB RAM 119 Interface 120 reader 122 user computer systems 124 data storage devices 126 processor 128 ID Provider Computer System 130 data storage devices 132 processor 134 Network 136 attribute servers 138 data storage devices 140 stored attribute values 142 processor 144 Service Computer System 146 data storage devices 148 processor 150 service T1-T7 parts of the message t1-t7 Times of parts availability M message ZWF Intermediate value function AF closing function VDW pre-stored data value for hash function 110 202-212 Intermediate values #H1 first hash value #H2 second hash value D1-D4 data values K concatenate value 214 Signatur 302-312 steps 404-408 users 410-414 Security Tokens 418 Revocation Server 420-426 first static private cryptographic key 428 Terminal

Claims

Method for generating a signature (214) for a message (M) by a processor (116) of a security token (102), the method comprising: - sequential provision (302) of parts (T1-T7) of the message (M) by the processor (116); - during the sequential provision, applying (304) an intermediate value function (ZWF) or a completion function (AF) of a hash function (110) to each of the parts of the message immediately after the provision of said part to stepwise compute a first hash value (#H1), wherein the first hash value (#H1) is identical to a value that would have been obtained by applying the hash function (110) to the entire message (M) by the processor; - provision (306) of one or more data values ​​(D1-D4) by the processor;- after calculating the first hash value (#H1), the processor generates (308) a concatenated value (K) by concatenating the one or more data values ​​(D1-D4) and the calculated first hash value (#H1), excluding the message from the concatenation; - the processor applies (310) the hash function (110) or another hash function to the concatenated value (K) to calculate a second hash value (#H2); - the processor outputs (312) the second hash value (#H2) for use as the signature (214) of the message or as a part of that signature; furthermore, with: - outputting each of the provided parts of the message (M) before the calculation and / or output of the first hash value (#H1) and / or the second hash value (#H2) via an interface (119.1) of the security token;and release of the security token's memory occupied by the output parts of the message immediately after output of that part of the message. The method of claim 1, wherein applying the intermediate value function (ZWF) of the hash function (110) or the termination function (AF) of the hash function (110) to calculate the first hash value comprises: - applying the intermediate value function (ZWF) to a first (T1) of the provided parts of the message, as soon as it has been provided, to calculate an intermediate value (202) into which this first (T1) of the message is incorporated;- For each further (T2-T6) of the sequentially provided parts of the message, the intermediate value function (ZWF) is reapplied to the further provided part of the message as soon as it has been provided, in order to compute a new intermediate value, wherein the intermediate value of the previous step (202-210) and the further provided part (T2-T6) of the message (M) are taken into the computation of the new intermediate value (204-212), wherein the completion function is applied to the last provided part (T7) of the message instead of the intermediate function; wherein applying the completion function (AF) to the last provided part (T7) of the message and to the last computed intermediate value (212) yields the first hash value (#H1). A method according to any of the preceding claims, wherein the signature (214) is a Schnorr signature, and wherein the generation of the Schnorr signature comprises: - agreement of domain parameters to define a group G of order q=|G| between the security token and a terminal, wherein q is a prime number, wherein the domain parameters represent a set of parameters that defines a group; wherein the hash function (180) used for calculating the second hash value (#H2) is a cryptographic hash function with a range of values ​​[0, q-1]; - generation of a random number x for use as a private key, wherein the random number is greater than zero and less than the prime number q;- Calculation of a public key y by scalar multiplication as a group element of the group corresponding to the private key x according to y=gx, where g is a generator of the group and where the private and public keys x, y form an asymmetric cryptographic key pair; - Calculation of a random number k, where the random number is greater than zero and less than the order q of the group G; - Calculation of a Schnorr signature intermediate value r by scalar multiplication using the generator g and the random number k according to the formula r=gk, where the Schnorr signature intermediate value is one of the data values ​​(D1-D4) and is used in the generation of the concatenated value (K); - Calculation of a result value (s) as the sum of the random number k and the product of the private key x and the second hash value (#H2) modulo q;- Using the second hash value (#H2) and the result value (s) each as part of the signature (214) of the message (M).; A method according to any of the preceding claims, wherein the data values ​​(D1-D4) include one or more of the following values: - intermediate values ​​of a key exchange procedure; and / or - a public key (416) enabling a recipient (120) to decrypt the message (M); and / or - a token ID, in particular a sector-specific token ID; - a sector-specific pseudonym of a plurality of ID tokens registered with the sector; and / or - ID of the signature procedure or signature verification procedure to be applied. A method according to any of the preceding claims, wherein the parts of the message (T1-T7) include one or more of the following values: - an attribute value (T1, T2, T4, T7) read from a memory (104) of the security token; - an attribute value (T5, T6) received by the processor from an attribute server (136) via a network (134); - an attribute value (T3) dynamically calculated by the processor (116); - the name of a user (101) to whom the security token is assigned; - authorization data of a user (101) to whom the security token is assigned. Method according to one of the preceding claims, wherein the signature is a pseudonymous signature. The method of claim 6, wherein the security token is one of a group of security tokens, wherein each of the security tokens contains a public key (PKSECTOR) of a terminal (428) or a service provider, wherein each of the security tokens contains a secret static key (SKICC_1) which has a different value for each of the security tokens, wherein each of the security tokens is configured to derive a sector-specific token ID from the secret static keys and the public key (PKSECTOR) stored in the security token, wherein the signature (214) is a pseudonymous signature referring only to the identity of the group of security tokens, wherein the method comprises: - authentication of the terminal (428) against the security token;- In the event of successful authentication of the terminal against the security token, the security token processor calculates the sector-specific token ID and generates the message and signature; - The generated message (M), the calculated sector-specific token ID, and the generated signature (214) are transmitted to the terminal; - The terminal receives the message (M), the sector-specific token ID, and the signature (214); - The terminal identifies the security token using the received sector-specific token ID and a private key (SKSECTOR) that forms an asymmetric cryptographic key pair with the public key (PKSECTOR), and checks whether the identified security token is listed in a revocation list;and / or verification of the message signature by the terminal and / or forwarding of the message and the signature from the terminal to a service computer system to enable the service computer system to verify the integrity of the message based on the forwarded signature. A method according to any one of the preceding claims, wherein the message (M) comprises several attribute values, each of the attribute values ​​functioning as one of the parts (T1-T3) of the message (M), wherein the provision of at least one first (T1) of the attribute values ​​includes reading the first attribute value from a protected memory (104) of the security token; and / or, wherein the provision of at least one second (T2) of the attribute values ​​includes a dynamic calculation (111) of the second attribute value by the processor (116) of the security token; and / or, wherein the provision of at least one third (T3) of the attribute values ​​includes receiving the third attribute value (140) from an attribute server (136) via a network (134) by the processor of the security token and making the received third attribute value available via the processor (116). The method of claim 8, wherein the security token is an identity document assigned to a user (101), further comprising: - authentication of the user to the security token; - authentication of an ID provider computer system (128) to the security token; - after successful authentication of the user and the ID provider computer system to the security token, transmission of one or more of the attribute values ​​(106, 140, 111, T1-T7) provided by the processor of the security token as part of the message (M) by the processor (116) to the ID provider computer system for forwarding the message to a service computer system (144). The method of claim 8 or 9, further comprising: - authentication of the user (101) to the security token; - authentication of an ID provider computer system to the security token; - after successful authentication of the user and the ID provider computer system to the security token, determination by the ID provider computer system that at least one (T3) of the attribute values ​​requested by the ID provider computer system is not stored in the security token and cannot be calculated; - in the event of such a determination, inducing an attribute server (136) by the ID provider computer system to authenticate itself to the security token (102); - authentication of the attribute server to the security token;- after successful authentication of the attribute server to the security token, transfer of the third attribute value (T3) from the attribute server to the security token for storage of the third attribute value by the processor (116) of the security token in a protected memory (104) of the security token and / or for provision of the transferred third attribute value as part of the message (M) by the processor (116) to the service computer system.; Security token (102) comprising a processor (116), wherein the security token is configured to execute a method according to any of the preceding claims alone or in interoperation with a user (101), a terminal (428), an ID provider computer system (128) and / or an attribute server (136).

Images