Method for authenticating an entity

Abstract

The present disclosure relates to a method for authenticating an entity, comprising detecting a first authentication factor which comprises a first authentication feature; validating the first authentication feature; creating an identifier on the basis of a feature of the authentication factor, which identifier is designed to identify the first authentication feature. Furthermore, the identifier is validated, which comprises ascertaining whether an identifier corresponding to the first authentication feature is present and determining whether the identifier matches a stored or transferred identifier, if an identifier is present, in order to validate the identifier. Furthermore, the identifier is stored in relation to the first authentication feature if no identifier corresponding to the first authentication feature is present, in order to validate the identifier and to register the authentication factor for authentication.

Description

[0001] Methods for authenticating an entity

[0002] The present invention relates to the authentication of an entity, in particular a method for integrating a payment card-based authenticator, so that device-bound verification of authentication factors can be realized.

[0003] TECHNICAL BACKGROUND

[0004] Authentication technology has evolved considerably in recent years to improve security and user-friendliness. Various platforms exist for authentication. For example, FIDO UAF (Fast Identity Online Universal Authentication Framework) authentication can be implemented, enabling two-factor authentication, particularly without passwords.

[0005] A FIDO key can be derived from authenticated card data and a user secret, for example, stored on a server. This concept enabled the integration of an existing EMV card as a FIDO UAF authenticator in conjunction with a secure server. The card can be a standard payment card, in particular a card conforming to the Europay, Visa, and Mastercard (EMV) chip card specifications. Furthermore, the card can conform to a derived regional variant of a payment card standard (such as Girocard, RuPay, or China UnionPay).

[0006] While server-based validation of an EMV signature can offer a high level of system security, it also presents a number of challenges. In particular, integration can be complex for users. Furthermore, it may be necessary to establish server-to-server communication to exchange card data via a secure channel.

[0007] If a specific map is required, it may be necessary to perform external validation of the map data on the user side and return the result to the server. This may require additional integration with a user backend. Server-side key derivation may be performed in a hardware security module (HSM) for security reasons. This can complicate server installation in a cloud environment, incur additional costs, and / or require connecting a cloud server to a local HSM instance.

[0008] The method according to the invention aims to implement FIDO UAF authentication entirely on the terminal device. Accordingly, the authenticator for generating keys and validating cards can reside on the terminal device. This further improves the user-friendliness of authentication, as a server is no longer required and full control over the authentication process can be given to the terminal device. In particular, the present invention can implement the functionality of a FIDO authenticator and enable simple integration into a FIDO backend.

[0009] According to a first aspect, the present disclosure relates to a method for authenticating an entity. The method comprises capturing, in particular by means of an end device, a first authentication factor, which includes a first, in particular unique, authentication feature. Furthermore, the method comprises the step of validating the first authentication feature, for example, the validation of a card signature, and furthermore, the creation of an identifier based on a feature of the authentication factor, which is configured to identify the first authentication feature.

[0010] The procedure includes identifier validation. Identifier validation comprises determining whether an identifier exists corresponding to the first authentication feature, and furthermore, verifying whether the determined identifier matches a stored identifier, if one exists, in order to validate the identifier. Furthermore, validation includes the step of creating and storing the identifier in relation to the first authentication feature if no identifier corresponding to the first authentication feature exists, in order to validate the identifier, particularly during subsequent authentications, and to register the authentication factor for authentication.

[0011] This allows the advantage of combining the full security of a FIDO authenticator, in particular including cryptographic signatures, challenge-response protocol, attestation and / or transaction signing, with the hardware security of an EMV card.

[0012] Authentication can be tied to a predefined entity and / or a device associated with that entity. The entity can be a natural person, in particular a user. The entity can be linked to the first authentication factor and / or a second authentication factor. Specifically, the relevant authentication factor can be within the entity's sphere of influence. Thus, capturing the corresponding authentication factor allows the entity's identity to be inferred or confirmed. Advantageously, the entity can be confirmed by providing two authentication factors.

[0013] An authentication factor can be a unique security element associated with an entity. For example, the authentication factor can include a card, where the entity's possession of the card is suitable for authentication, at least partial authentication, of the entity. For example, the procedure can include recording the entity's possession of the authentication factor. An authentication factor can be characterized by a unique authentication feature and / or the ability to provide and / or generate a unique authentication feature.

[0014] Accordingly, authentication factors can ensure the security of registrations, authentications, and / or transactions. The card can be a physical or virtual card. Furthermore, an authentication factor can be a biometric factor. This biometric factor can, for example, include a digitized representation of a fingerprint, an iris scan, a voice signature, a physical characteristic (especially a facial feature), a predefined movement of a body part, or other biometric aspects. An authentication factor can also be a PIN and / or a cryptographic key. Each authentication factor has at least one specific authentication characteristic that serves to verify the cardholder's identity.The authentication feature can be defined as a unique, preferably immutable, data element. The authentication feature can be provided by the entity or generated in identical form by the entity, or by the authentication factor. The authentication feature can be a signature, in particular a card signature. The signature can be a unique digital signature generated on the card. Furthermore, the authentication factor can include a memory configured to store data immutably. The authentication factor can also include a processor configured to perform cryptographic operations to provide the authentication feature.

[0015] The authentication factor can include possessing, knowing, or generating a personal identification number (PIN). The PIN can be an alphanumeric or numeric code. The PIN can be static or dynamic. Furthermore, an authentication factor can have a limited validity period. The authentication factor can also include a cryptographic key.

[0016] Each authentication factor can contribute to verifying the cardholder's identity. The combination of these factors and features increases transaction security and protects against unauthorized access. For example, an authentication threshold can be defined, which can be reached through a combination of authentication factors. Several different authentication factors can be used for verification.

[0017] The authentication token can be a unique identifier, on which, in particular, the generation of the key pair can be based. A valid authentication token can be used to authenticate the key pair. Furthermore, authentication tasks can be signed. An initial key pair generation can occur during a first authentication process, which can correspond to a registration. Once a key pair has been generated in relation to the authentication token, further authentication processes are only possible based on the first authentication token. Upon registration, the public key of the key pair can be sent to a server.

[0018] The acquisition of the authentication factor can be achieved, in particular, between an end device and a data carrier, such as a card, through a contactless and / or contact-based connection between the end device and the data carrier. Preferably, an NFC connection can be established between the data carrier and the end device. Upon acquisition of the authentication factor, the authentication factor can be provided to an authenticator of the end device. For example, by acquiring a card, the card signature can be provided to an application of the end device, especially a secure environment, such as an authenticator. The card signature can be generated by the card in relation to communication with the end device and transmitted to it. The authentication factor can be provided exclusively to the authenticator.

[0019] Validating an authentication feature can be defined as establishing the origin, authenticity, and / or trustworthiness of the authentication feature. Furthermore, it can be determined that the authentication feature is unaltered. For example, a card signature can be verified up to the card system's public root key. The card can generate a digital signature created with a private key. This signature can serve as proof that the card is genuine and originates from a trusted source. Using a public root key, which may be part of a hierarchical key structure maintained by a trusted Certificate Authority (CA), the authenticity of the digital signature can be verified.

[0020] Verifying the card's digital signature can be done using the card's public key. This verification process involves tracing a certificate chain back to the public root key. Each stage of the chain can be checked to ensure all intermediate certificates are valid. Finally, the signature can be verified using the public root key. If this verification is successful, the card's authenticity can be confirmed, and the authentication feature validated.

[0021] When an authentication factor is first captured, a unique identifier can be generated and advantageously stored. This initial capture can initiate a registration process for the authentication factor. To validate the authentication factor for subsequent authentications, the associated identifier can be generated and linked to the authentication factor. Future authentications can be bound to the authentication factor and require the presence of the identifier.

[0022] With regard to determining whether an identifier corresponding to the first authentication attribute has been captured, particularly in the terminal device, it can be established whether the identifier has been passed to the terminal device. For example, the identifier can be passed from the storage device to the authenticator. Alternatively, the identifier can be passed to the terminal device from a third party, such as an authentication factor instance. It can be determined that the identifier has been captured if the identifier is present in the authenticator and / or accessible to the authenticator. The procedure may involve passing the identifier, particularly to the authenticator.

[0023] According to one embodiment, the method may include determining whether the identifier matches a stored or transmitted identifier, if the identifier is present or has been transmitted.

[0024] By storing the identifier in relation to the first authentication factor, if no identifier corresponding to the first authentication factor exists, the identifier can be validated during subsequent authentications. This validation can include comparing a previously stored identifier with a newly captured one. Similarly, when an authentication factor is initially captured, an identifier can be generated and stored for subsequent authentications.

[0025] In particular, the identifier can be securely stored in a memory, such as a keystore. The identifier can be derived from card data. For example, the identifier can contain a hash value based on an authentication feature or property of the authentication factor, such as a card number, a card sequence number, and / or an expiration date. During subsequent authentications, the identifier can be derived from the authenticated card data and verified by the authenticator. Accordingly, authentication can be successful if the authentication factor, such as the card, has been correctly authenticated., the card signature has been verified up to the public root key of the card scheme, and the derived identifier is identical to the identifier stored in memory during registration, i.e., during the initial capture of the authentication factor.

[0026] This ensures, for example, that a user presents a correct, valid card and that it is the same card that was used during registration.

[0027] Furthermore, the process can include defining a predetermined authentication factor suitable for registration. This can be implemented, for example, based on FIDO UAF extensions. Registration can then be successful if the authenticated card data is identical to the specified data (or the identifier derived therefrom). In an advantageous embodiment, the key pair can be generated once the identifier has been validated. Key pair generation can occur independently of the first authentication feature. This offers the advantage that no keys need to be derived from the authentication factor or authentication feature. In particular, the keys are not derived from card data. Accordingly, the key pair can be linked to a specific authentication factor via the identifier.However, no authentication factors, such as card data, are used to generate the key pair. The key pair is independent and is generated for the first time during registration, i.e., the initial capture of the authentication factor.

[0028] According to a further embodiment, the method includes authorizing the terminal device to generate the key pair once the first authentication factor has been captured. The key pair can be permanently stored on the terminal device. Upon registration of the authentication factor, the key pair can be generated once and made available for subsequent authentications. Permanent storage can involve storage in non-volatile memory. Furthermore, permanent storage can be defined as storage that is immutable with respect to the corresponding authentication factor. By storing the key pair only once, its regeneration can be prevented. The generated key pair can be bound to the authentication factor. Accordingly, the key pair generated only once can be required for subsequent authentications based on the corresponding authentication factor.This allows possession of the key pair to constitute an additional authentication factor alongside possession of the first authentication factor.

[0029] According to one embodiment, the method may include generating a random initial value, for example, a seed value. The key pair can be generated from the random initial value and the authentication feature. Advantageously, the random initial value can be stored to repeatedly generate the key pair; in particular, the key pair can be generated during each authentication.

[0030] The key pair can be derived from the card data, particularly the authentication factor. Using the seed value in conjunction with the card data, the key pair can be derived. Therefore, it may be sufficient to permanently store the seed value rather than the key itself. The first authentication factor can be immutable. When generating the key pair, the same private key and the same public key can be created using the first authentication factor. This offers the advantage that the key pair is only temporarily available but can be made available for authentication by generating it again identically. This allows for increased security against unauthorized access. Key generation can be implemented without a server, i.e., without key derivation by a server-side HSM.This can simplify cloud integration, for example.

[0031] The procedure can further include capturing, advantageously via the terminal device, a second authentication factor, which comprises a second authentication feature. The key pair can be generated once the first and second authentication factors have been captured. An authentication factor category of the first authentication factor can be identical to an authentication factor category of the second authentication factor.

[0032] Accordingly, two-factor authentication can be provided, which can be based, in particular, on possession of the EMV card and possession of a terminal device. The corresponding key pair, for example, FIDO keys, can be stored on the terminal device. This allows for a complete security environment equivalent to an authenticator, especially a FIDO-compliant authenticator. Cryptographic signatures, challenge-response protocols, attestations, and / or transaction signing can be implemented with the authenticator. The authenticator can advantageously be combined with the hardware security of an EMV card. The terminal device with the authenticator can communicate with a FIDO UAF server platform, particularly using a plug-and-play principle without an additional server component.The authenticator can be bundled with other authentication factors, for example, together with biometric authentication factors in an environment such as a Convego® Auth-U SDK. The authenticator can be selected as an authentication factor according to the corresponding server policies of an authentication server, such as an Auth-U server. Furthermore, integration into an external FIDO UAF system is possible. The process can include receiving an authentication task from an authentication server to authenticate the entity. It can also include generating an authentication response based on an authentication task using the private key.

[0033] To authenticate a process for an entity, a server can receive an authentication task. The authentication task can contain randomly generated data. Generating the authentication response can involve signing the authentication task with the private key. This signing can be implemented using an authenticator. The signed authentication task can then be transmitted as an authentication response back to the sender of the authentication task. The process can also include verifying the authentication response. With a correctly recognized authentication response, the entity can be authenticated for the process. The public key can also be transmitted with the authentication response. Advantageously, this eliminates the need for the sender of the authentication task or the recipient of the authentication response to retain the public key.

[0034] The authentication task can be bound to an authentication action of the entity. Furthermore, the authentication response can be used to validate the authentication action. In response to the authentication task, the first authentication factor and / or the second authentication factor can be captured. Advantageously, in response to receiving the authentication task and capturing the first authentication factor and / or the second authentication factor, the key pair can be generated. Alternatively, capturing the authentication task and the first authentication factor and / or the second authentication factor can at least read the private key from memory. The first authentication factor can be validated in response to the authentication task by checking the identifier.Advantageously, the authentication task can only be signed with an identifier identical to that used in the registration process. The authentication task can be bound to the first authentication factor and / or the second authentication factor. Accordingly, only authentication factors present at the time of registration can be used for subsequent authentication of the entity for a given operation. The procedure can include verifying the public key using an attestation key that authenticates the authenticator, in order to generate a verified public key. Furthermore, the procedure can include transmitting the public key to the authentication server. The transmission of the public key can occur with the initial generation of the key pair.Accordingly, registration of the entity using the first authentication factor and / or the second authentication factor can be indicated by receiving the public key. The authentication key can be bound to the authenticator and indicate the authenticator's authenticity. The transmission of the public key can be signed with the authentication key. An authentication instance can retain the public key for subsequent authentications of the entity. By transmitting the authentication response to the authentication server, the entity can be authenticated to the authentication server.

[0035] The key pair can be regenerated in response to receiving the authentication task. Similarly, the key pair can be regenerated each time the corresponding authentication factor is acquired. The key pair can be stored in memory until authentication and / or registration is complete. Specifically, the key pair and the identifier can be stored in memory. Access to the memory can be tied to acquiring the first authentication factor and / or the second authentication factor. Creating the key pair always results in identical keys.

[0036] The stored identifier can be immutably stored for the first authentication factor. Furthermore, the key pair can be generated if a generated identifier matches the stored identifier. In particular, the identifier can be generated in response to the acquisition, especially repeated acquisition, of the first authentication factor.

[0037] The identifier can be stored, particularly in relation to the registration of the authentication factor, if the identifier represents a predetermined property of the authentication factor. Immutable storage can be achieved using a suitably configured memory. Alternatively, immutable storage can be achieved through access restrictions, ensuring that the identifier, once stored, is read-only for subsequent authentications. The predetermined property can be a characteristic that identifies the authentication factor as valid for authentication or registration. For example, a serial number can be defined for the authentication or registration of an entity. Accordingly, only an authentication factor possessing this characteristic can successfully complete the authentication or registration process.The property can be predetermined by an issuing authority of the authentication factor and / or linked to the entity. Generating the identifier can signal the presence of the corresponding property. In particular, the receipt of an authentication response and / or the public key can indicate the presence of the property. For example, a card issuing authority can define a predetermined serial number (property of the authentication factor) for the authentication and / or registration of a predetermined entity. Only an authentication factor with this property can successfully complete authentication or registration by a device of the entity.

[0038] According to another aspect, the present disclosure relates to an end device for authenticating an entity. The end device may include an interface configured to capture a first authentication factor, which comprises a first authentication feature. Furthermore, the end device may include an authenticator configured to generate an identifier based on the first authentication feature and advantageously to compare the generated identifier with a stored identifier. The authenticator may also be configured to generate a key pair in response to the capture of the first authentication factor and to assign the key pair to the identifier.

[0039] Furthermore, the terminal device can include a memory, in particular a security memory, configured to store the identifier, preferably in an immutable manner. The memory can also be configured to store the key pair.

[0040] The interface can be, for example, a card reader interface configured to read data from a smart card. Advantageously, the data can be read wirelessly. The terminal device can be configured to assign the read card data to an authentication and / or registration process. In particular, the read card data can be recognized as an authentication factor. Furthermore, the interface can be configured to communicate with the authentication factor. For example, the authentication factor can generate and / or provide the authentication attribute in response to a corresponding request from the interface.

[0041] The terminal device can be configured to generate the key pair upon initial detection of the authentication factor, or upon initial detection of the corresponding authentication feature of the authentication factor.

[0042] According to one embodiment, the terminal device can include a further interface, which can be configured to capture a second authentication factor comprising a first authentication feature. The interface can be configured to capture an authentication factor from a first authentication factor category. The further interface can be configured to capture an authentication factor from a second authentication factor category, wherein the first authentication factor category can differ from the second authentication factor category.

[0043] The first authentication factor can advantageously be a possession factor, realized through possession of a card. The card can be configured to provide and / or generate the first authentication feature, for example, a card signature. A second authentication factor can also be a possession factor, realized through possession of the key pair, particularly on the end device. Accordingly, the first authentication factor, in conjunction with the key pair, can implement two-factor authentication.

[0044] In addition to the first authentication factor, a second authentication factor can be requested. Advantageously, the second authentication factor is not a possession factor. It is advantageously a knowledge factor, such as a PIN, or a property factor, such as the capture of a biometric characteristic. Accordingly, three-factor authentication can be implemented using the second authentication factor. A signature can be generated with the key, which can be validated by an external entity, such as a recipient, in the form of a signed authentication response.

[0045] The authenticator can be trained to authenticate the public key using a authentication key. Similarly, the authenticator can be trained to generate an authenticated public key. The end device can be trained to send the authenticated public key to an authentication server.

[0046] According to one embodiment, the terminal device can be configured to export an authentication factor, in particular a previously acquired authentication factor. The authentication factor can then be transmitted to a receiving device. The terminal device can be configured to export an authentication feature of an authentication factor. Exporting can be defined as providing and / or transmitting to a receiver.

[0047] The authentication key can be bound to a predefined instance of the authenticator on the end device. Accordingly, the authentication key can confirm the authenticity of the authenticator and / or the validity of the authentication performed by the authenticator.

[0048] According to another aspect, the present disclosure relates to a computer program product comprising a computer-readable medium containing instructions that can be executed by an end device configured to authenticate an entity. When executed by the end device, the instructions can cause the end device to perform steps of the procedure according to the described embodiments.

[0049] According to a further aspect, the present disclosure relates to a computer-readable data carrier, comprising a non-transitory computer-readable medium. A computer program according to the preceding aspect can be stored on the medium. When executed by an end device, the computer program can cause the end device to carry out the method according to the described embodiments.

[0050] Further aspects, features and advantages of the present disclosure will become clear to the person skilled in the art upon review of the following detailed description of preferred embodiments and variants of the present disclosure in conjunction with the accompanying figures.

[0051] BRIEF DESCRIPTION OF THE FIGURES

[0052] Reference is made to the attached illustrations, in which

[0053] FIG. 1 shows a schematic representation of the method according to one embodiment of the present invention; and

[0054] FIG. 2 shows a schematic representation of the method according to an embodiment of the present invention.

[0055] Fig. 1 shows the method 100 for authenticating an entity, wherein a first acquisition of the authentication factor can lead to the entity being registered for authentication. The registration can be an embodiment of the authentication. In particular, an identifier for the authentication factor can be generated for the first time during the registration. The method 100 can include initiating 101 the registration. With the initiation 101 of the registration, an end device can be configured for registration. In particular, an acquisition 102 of the authentication factor can be initiated. The acquisition 102 of the authentication factor can include reading a card. For example, a user can bring the card within communication range of the end device; in particular, physical contact can be made between a card and the end device in order to acquire the authentication factor, or the card, using a wireless interface.

[0056] A validation of an authentication characteristic of the authentication factor can then be performed (103). For example, the authentication characteristic could be a signature, especially a card signature. If the authentication characteristic cannot be validated, the registration process is aborted (104). Validation can fail if an incorrect authentication characteristic is captured. For example, the captured authentication characteristic might differ from an expected authentication characteristic. The expected authentication characteristic can be predefined via an authenticator.

[0057] Creating an identifier (105) can always occur. This means the identifier can always be created during registration as well as during subsequent authentications. Alternatively, creating an identifier (105) can depend on determining whether an identifier is already known (107). For example, the identifier can be generated exclusively during registration.

[0058] The creation process (105) can be followed by the validation (106) of the identifier. Validation (106) can include determining (107) whether an identifier for the authentication factor has already been specified. For example, it can be determined whether the identifier for the captured authentication factor is already present in the terminal device, or is known to or has been provided to the terminal device and / or the authenticator.

[0059] If an identifier is already known or stored for the authentication factor, a comparison (108) of the generated identifier with the already known identifier can follow. Alternatively, instead of comparing the identifier (108), the authentication feature can be used as a comparison criterion. For example, a representation of the authentication feature can be securely stored in the terminal and compared with the captured authentication feature. This comparison can determine (108-1) whether the captured identifier matches the stored identifier. If no identity is found, the registration can be aborted (104).

[0060] If no identifier is known, the identifier can be saved (109). If no identifier has been created yet, one can be created at this point. Saving (109) can be done only once. In particular, a check can be performed to ensure that the authentication factor has not previously been used for registration. After generating and saving the identifier, a key pair, comprising at least a private key and a public key, can then be created (110).

[0061] The authentication token can then be signed and / or the public key can be signed. Accordingly, authentication of the public key can follow. With authentication, or signing, using an authentication key, the registration can be successfully completed. Unlike registration, subsequent authentications can only involve a comparison with the stored identifier, since the identifier was initially stored and thus fixed during registration. However, with each subsequent authentication, the identifier can always be generated to enable a comparison with the stored identifier.

[0062] FIG. 2 shows a schematic representation of an embodiment of the method for authenticating an entity, wherein authentication of the entity for a process can be realized by first acquiring the first authentication factor and advantageously also the second authentication factor. The method 100 can include starting 201 the authentication.

[0063] Just like registration, the procedure can include capturing 102 the first authentication factor. Validating 103 the authentication feature, for example, validating the card signature, also occurs in accordance with the embodiment shown in FIG. 1. If the authentication feature cannot be validated, the authentication process can be aborted 204.

[0064] Furthermore, the creation of an identifier also occurs during authentication following registration. The system executing the procedure, for example, the end device, may already know that the current process is authentication and not registration. Accordingly, determining whether an identifier corresponding to the first authentication attribute exists, particularly in the end device, can be omitted. Alternatively, determining whether an identifier is present, especially in the end device, can always be performed if it is not known at the beginning of the procedure whether it is a registration or authentication. Advantageously, the procedure can be designed such that both an initial registration and subsequent authentications can be implemented using the same decision logic.

[0065] Authentication can always include verifying whether the newly generated identifier is identical to an identifier generated during registration. Since an identifier is always already stored during authentication, storing the identifier is unnecessary. The identifier is validated if an identity between the newly generated identifier and the stored identifier can be established. This comparison can determine whether the captured identifier matches the stored identifier. If no identity exists, authentication can be aborted. Confirming the identifier can trigger the generation of an authentication response. This response can be generated in response to an authentication task. Generating the authentication response can include processing the authentication task.The authentication task can include process instructions, which are to be executed by an authenticator in particular to generate the authentication response. Alternatively, the authentication response can correspond to a signed authentication task. The data it contains can therefore be identical except for the signing.

[0066] By sending the signed authentication response, the authentication of the entity can be successfully completed. 203.

Claims

Claims 1. Method (100) for authenticating an entity, comprising Capture (102), a first authentication factor, which includes a first authentication feature; Validating (103) the first authentication feature Creating (105) an identifier based on a feature of the authentication factor that is trained to identify the first authentication feature; Validating (106) the identifier, wherein validating the identifier includes: Determine (107) whether an identifier has been recorded corresponding to the first authentication feature; Determine (108) whether the identifier matches a captured identifier, if an identifier has been captured, in order to validate the identifier; Store (109) the identifier in relation to the first authentication feature if no identifier corresponding to the first authentication feature exists, in order to validate the identifier and register the authentication factor for authentication.

2. The method according to claim 1, comprising Creating (110) a key pair, using an end-device authenticator, comprising a private key and a public key, when the identifier is validated, wherein the creation of the key pair is independent of the first authentication feature.

3. Method according to any one of the preceding claims, comprising Authorizing the terminal to create the key pair when the first The authentication characteristic is captured, with the key pair being permanently stored on the end device.

4. Method according to claim 2, comprising Generating a random initial value, where the key pair is generated from the random initial value and the authentication feature, and Storing the random initial value to repeatedly generate the key pair, where the random initial value is immutable and the same private key and public key are generated using the first authentication feature when creating the key pair.

5. Method according to any one of the preceding claims, comprising Capturing a second authentication factor, which includes a second authentication feature; wherein the creation of the key pair occurs when the first authentication factor and the second authentication factor are captured, and wherein an authentication factor category of the first authentication factor is identical to an authentication factor category of the second authentication factor.

6. A method according to any one of the preceding claims, comprising Receiving an authentication task to authenticate the entity from an authentication server; Generating (202) an authentication response based on an authentication task using the private key, and Transmitting the authentication response to the authentication server to authenticate the entity to the authentication server.

7. Method according to one of the preceding claims, wherein the authentication task is bound to an authentication action of the entity, and the authentication action is validated with the authentication response.

8. Method according to any one of the preceding claims, comprising Authenticating (111) the public key using an authentication key that authenticates the authenticator to issue an authenticated public key produce; and Transmitting the public key to the authentication server.

9. Method according to one of the preceding claims, wherein the key pair is regenerated in response to receiving the authentication task / 10. Method according to one of the preceding claims, wherein the stored identifier for the first authentication feature is stored immutably.

11. Method according to one of the preceding claims, wherein the identifier is stored with respect to a registration of the authentication factor if the identifier represents a predetermined property of the authentication factor.

12. Terminal for authenticating an entity, comprising an interface configured to capture a first authentication factor, which includes a first authentication feature; an authenticator configured to: generate an identifier based on the first authentication feature; compare the generated identifier with a stored identifier; a key pair comprising a private key and a public key. to generate keys in response to the detection of the first authentication factor and to associate the key pair with the identifier; a memory configured to store the identifier and to store the key pair.

13. Terminal device according to claim 12, wherein the authenticator is configured to authenticate the public key by means of an authentication key in order to generate an authenticated public key; and wherein the terminal device is configured to send the authenticated public key to an authentication server.

14. A computer program product comprising: a computer-readable medium containing instructions executable by an end device configured to authenticate an entity, wherein the instructions, when executed by the end device, cause the end device to perform steps of the method according to any one of claims 1 to 11.

15. Computer-readable data carrier comprising a non-transitory computer-readable medium, wherein a computer program according to claim 14 is stored on the medium, wherein the computer program, when executed by an end device, causes the end device to perform the method according to any one of claims 1 to 11.

Images