Authentication hardware token to ensure control of user data

Abstract

A method of accessing secure data on a user device wherein authenticated access of the user device is unavailable, the method comprising: receiving a request from a requester to access secure data in the user device; receiving an authentication input from the user; authenticating a data input from the user using a control token; and providing access to the security data to the requester.

Description

Technical Field

[0001] The various exemplary embodiments disclosed herein relate to an authentication hardware token that ensures a data owner's control over user data. Background Art

[0002] An authentication hardware token can be used to ensure a data owner's control over user data. The data owner has their hardware token (e.g., key ring, key card, bracelet, health device, smart watch, etc.), which contains authenticated authentication data for verifying access rights to a service. For example, in order to obtain access to digital identity services provided by the European Union Digital Identity Wallet (EUDIW) running on the data owner's smartphone, the data owner will present their hardware token (something you have) and combine it with their authentication (something you know or your identity), which will allow transactions to be made through cryptographic components and record the transactions. This allows the user to maintain control over the shared data. Summary of the Invention

[0003] An overview of the various exemplary embodiments is presented below.

[0004] The various embodiments relate to a method of accessing secure data on a user device where authentication access to the user device is not available. The method includes: receiving a request to access secure data in the user device from a requester; receiving authentication input from the user; authenticating the data input from the user using a control token; and providing access to the secure data to the requester.

[0005] Describe various embodiments where the authentication input from the user includes biometric input.

[0006] Describe various embodiments where the authentication input from the user further includes a secret user input code.

[0007] Describe various embodiments where authenticating the data input from the user using a control token uses near field communication.

[0008] Describe various embodiments where authenticating the data input from the user using a control token uses one of ultra-wideband communication, Bluetooth communication, and near field magnetic induction communication.

[0009] Describe various embodiments where providing access to the secure data to the requester includes securely sending the requested secure data to the requester.

[0010] Describe various embodiments where the method further includes: receiving a request from the user to add the control token as an authentication device; and binding the control token to the user device.

[0011] Various other embodiments relate to a method of accessing secure data on a user device by a requesting device, where the user device is in a low power mode, the method comprising: sending a request to access secure data in the user device to the user device; receiving data from the user device, the data including biometric authentication data; receiving biometric input from an authenticator device, where the user provides biometric input to the authenticator device; comparing the biometric input from the authenticator device with the biometric authentication data; and accessing the user's secure data when the input from the authenticator device matches the biometric authentication data.

[0012] Describe various embodiments where the user also provides a secret user input code input to the authenticator device.

[0013] Describe various embodiments where sending the request to the user device uses near field communication.

[0014] Describe various embodiments where sending the request to the user device uses one of ultra-wideband communication, Bluetooth communication, and near field magnetic induction communication.

[0015] Describe various embodiments where receiving data from the user device and accessing the secure data includes: receiving data from the user device includes receiving encrypted secure data from the user device; and accessing the secure data includes decrypting the encrypted secure data when the input from the authenticator device matches the biometric authentication data.

[0016] Describe various embodiments, the method further comprising: sending a proof of performing biometric authentication on the user to the user device; and receiving encrypted secure data from the user device when the user device verifies the proof of performing biometric authentication on the user.

[0017] Various other embodiments relate to a method of accessing secure data on a user device by a requesting device, where the user device is in a low power mode, the method comprising: receiving a request to access secure data in the user device from the requesting device; sending data to the requesting device, the data including biometric authentication data; receiving a proof of biometric input from the authenticator device from the requesting device, where the user provides biometric input to the authenticator device; verifying the proof of biometric input; and sending the user's secure data to the requesting device when the proof of biometric input is verified.

[0018] Describe various embodiments where the proof of biometric input from the authenticator device includes a proof that the user inputs a secret user input code into the authenticator device.

[0019] Describe various embodiments where receiving the request from the requesting device uses near field communication.

[0020] Describes various embodiments in which a request is received from a requesting device using one of ultra-wideband communication, Bluetooth communication, and near-field magnetic induction communication.

[0021] Describes various embodiments, the method further comprising encrypting the security data before sending the security data to the requesting device.

[0022] The foregoing has outlined rather broadly the features and technical advantages of examples in accordance with the present disclosure so that the following detailed description may be better understood. Additional features and advantages will be described hereinafter. The disclosed concepts and specific examples may be readily utilized as a basis for modifying or designing other structures for carrying out the same purposes of the present disclosure. Such equivalent constructions do not depart from the scope of the appended claims. The features of the concepts disclosed herein, both as to their organization and method of operation, together with associated advantages will be better understood from the following description when considered in conjunction with the accompanying drawings. Each of the drawings is provided for the purpose of illustration and description, and is not provided as a definition of the limits of the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] To understand the above features of the present disclosure in detail, a more specific description briefly summarized above may be made by reference to the aspects, some of which are illustrated in the drawings. It should be noted, however, that the drawings only illustrate some typical aspects of the present disclosure and should not be considered as limiting the scope of the present disclosure, as the description may admit other equally effective aspects. The same reference numerals in different drawings may identify the same or similar elements.

[0024] Figure 1 Illustrates a registration process.

[0025] Figure 2 Illustrates a data flow during the use of an authentication system.

[0026] Figure 3 Illustrates the registration of biometric information used with a second device as an external biometric authenticator.

[0027] Figure 4 Illustrates a first scenario of an authentication system.

[0028] Figure 5 Illustrates a second scenario of an authentication system. DETAILED DESCRIPTION

[0029] Aspects of the present disclosure are described more fully hereinafter with reference to the accompanying drawings. However, the present disclosure may be embodied in many different forms and should not be construed as limited to any specific structure or function presented throughout this disclosure. Rather, these aspects are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art. Based on the teachings herein, those skilled in the art should appreciate that the scope of the present disclosure is intended to cover any aspect of the present disclosure disclosed herein, whether implemented independently of any other aspect of the present disclosure or in combination with any other aspect of the present disclosure. For example, an apparatus may be implemented or a method may be practiced using any number of the aspects set forth herein. Additionally, the scope of the present disclosure is intended to cover such apparatus or methods practiced using other structures, functionality, or a combination of structures and functionality in addition to or different from the various aspects of the present disclosure set forth herein. It should be understood that any aspect of the present disclosure disclosed herein may be embodied by one or more elements of a claim.

[0030] Certain aspects of a authentication system will now be presented with reference to various devices and techniques. These devices and techniques will be described in the following detailed description and illustrated in the accompanying drawings by various blocks, modules, components, circuits, steps, processes, algorithms, etc. (collectively referred to as "elements"). These elements may be implemented using hardware, software, or a combination thereof. Whether such elements are implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system.

[0031] An authentication hardware token can be used to ensure a data owner's control over user data. The data owner owns their hardware token (e.g., key fob, key card, wristband, health device, implant, smartwatch, etc.), which contains authenticated authentication data for verifying access to a service. For example, in order to obtain access to digital identity services provided by the European Union Digital Identity Wallet (EUDIW) running on the data owner's smartphone, the data owner will present their hardware token (something you own) and combine it with their authentication (something you know or your identity), which will allow transactions to occur via cryptographic components and record the transactions. This allows the user to maintain control over the shared data. In addition to requiring user input to allow use of the hardware token, presenting the hardware token may only require the hardware token to be in proximity to a reader.

[0032] In the context of a digital wallet such as EUDIW, access to a service may result in the exposure of some sensitive data owned by the user. This can occur, for example, when the user's device with sensitive data is offline or has a low battery. Since authentication typically may require some network connection, the user may not be able to perform authentication when a network connection is not available.

[0033] The embodiments disclosed herein bring additional trust to the ecosystem of digital identity services. Specifically, when the owner's smartphone is offline or has a low battery, a trust relationship is generated, and the user-owned device is unable to perform full-functional authentication required to establish trust when authenticating access rights to sensitive data. For example, if the device has a low battery, then the device can no longer perform facial or other biometric identification, or it is no longer able to drive the touch screen.

[0034] An authentication system will be described herein that allows for the protection of user-owned data and the secure use of digital identity services using a local hardware token or control token owned by the data owner. A control token is needed to facilitate the authentication of the user, which can be performed using ultra-wideband (UWB), near-field communication (NFC), magnetic transmission field (MTF), or other communication protocols. The token can always be mandatory, and when the user device is fully functional, the token serves as a second-factor authentication. The token can be mandatory only when the user device is not fully functional, otherwise it is optional: that is, the token serves as a substitute for other authentication components of the user device. The additional data stored on the hardware token supplements the trust in the system. When the user device is fully functional and the token is additionally used, the token can store additional information indicating the most recent authentication on the user device, which can be reused when the token serves as a substitute for some trust relationship establishment when the user device is not fully functional. It should be noted that the described embodiments systematically refer to EUDIW, but it can equally be used for any similar service (e.g., national digital identity service, access control system, Apple Wallet, Google Wallet, etc.). It should be noted that any given control token can be used to assist in the authentication of multiple devices. Additionally, the user can have multiple control tokens, and the authentication process may require the use of more than one control token to increase the security of the authentication system and process.

[0035] The trust system has four entities: the user; the local device; the control token; and the local requester. The user owns a local or user device that stores sensitive data. The local device belongs to the user. The data in the local device can be stored on a secure element. The user device can be battery-powered and can enter a low-battery state that restricts the functions of the user device. The user device can include radio connections (e.g., USB, NFC, Bluetooth (BT), etc.) that may not work when authentication is required. The control token stores authentication data and stores records used by the user to authenticate EUDIW. The local requester (e.g., police, administrator, transportation employee, etc.) requests access to the data stored by the data owner on the secure element of the device. The verifier can be online and can have access to the network.

[0036] Figure 1Illustrates the registration process of the authentication system. User 102 requests to add a control token as a second factor of authentication for their EUDIW. Subsequently, the user presents the control token 106 to the user device 104. The control token 106 can interact with the user device 104 using NFC, UWB, Bluetooth, NFMI, etc. The user device 104 personalizes the control token 106 and binds it between the user device 104 and the control token 106. The user device now needs to use the control token 106 for each authentication (defaulting to two-factor authentication). In other embodiments, more than one token can be registered for use, and the system can use one or more of the tokens for authentication purposes.

[0037] It should be noted that special classes of devices that can potentially be used by the authentication system embodiments described herein include medical implants on or within the body of user 102. Medical implants can include, for example, continuous glucose monitors, cardiac pacemakers, insulin pumps, hearing aids, cochlear implants, etc.

[0038] When the user device 104 is fully operational, the control token 106 is an optional second factor of authentication, but when the user device 104 is not fully operational, the control token 106 will be an authentication factor. In Figure 1 NFC is mentioned, but any communication technology can also be used between the user device 104 and the control token 106.

[0039] Figure 2 Illustrates the data flow during the use of the authentication system. First, the requester 108 wants to access the secure data 202 stored in the user device 104. Subsequently, the user device 104 receives a request for second factor authentication 204. Subsequently, the user 102 authenticates themselves to the user device 104 using, for example, biometric input 206. The user device 104 then requests the control token 106 as a second factor of authentication via a communication protocol (e.g., NFC, UWB, Bluetooth, NFMI, etc.) 208. When the authentication using the second factor has been verified, the requester 108 obtains access to the data / service 208.

[0040] In the above steps, the case where user 102 (also the data owner in this case) wants to perform a qualified signature of a document and wants to access the secure data instead of the requester 108 is relevant, for example. If the user device 102 is fully functional, then the control token can be regarded as a second factor authentication method, but if the user device 102 is not fully functional (e.g., low battery), then the use of the control token 106 is the authentication method.

[0041] There can be cases of this authentication system where step 208 is performed only by a proximity check: i.e., the token is close enough to the device to be considered a successful authentication.

[0042] Example scenarios where this method can be used include a situation where a person (user) wants to perform an electronic signature to sign a signature document requested by a validator. The user authenticates using their EUDIW to access the service. As an additional authentication trust, the user presents their controlled hardware token (ID document, smartwatch, keyring, key card, implantable device in the body, etc.). Authentication is completed and the user can perform their electronic signature.

[0043] The authentication system described above improves the security architecture of the EUDIW and maintains the protection of user data under the control of the user.

[0044] When the phone does not have a battery, it is difficult or impossible to obtain access to the secure data stored on a device that needs to be unlocked with a credential or biometric input. In other words, if there is a secure element with an NFC interface in the mobile phone, for example, it may still be possible to access the data in the secure element through the NFC interface of the secure element when the battery power is low or when the battery is empty. However, the key point is that for some data, this retrieval operation is adjusted by the explicit biometric approval of the owner of the data (i.e., the owner of the device containing the secure element), and if the battery power is insufficient, the mobile phone cannot perform biometric authentication.

[0045] This embodiment of the authentication system implements the idea that if the battery of the owner's device is low or empty (or equivalently, the battery power is insufficient, which may include the inability to perform biometric authentication), and if this device has an embedded secure element with NFC capabilities (this secure element contains the data to be unlocked), then the owner can trust another second device to be used as a biometric authenticator. The second device can interact with the first device via any radio and communication protocol available and for which there is still sufficient power available in the first device or via NFC. Biometric verification can be split between the second and first devices and the embedded secure element in the first device according to the power available in the first device. The owner's device relays the biometric authentication to a second device that the owner of the first device trusts for this operation.

[0046] Another element of this authentication system is that the biometric unlocking in the second device can depend on a previous biometric unlocking operation that has been successfully performed on the first device before the first device enters the low - battery state. In other words, the embedded secure element in the first device also contains the required data from the previous successful biometric authentication, which will be required for the relayed biometric authentication on the second device.

[0047] As an additional security measure, the relayed biometric authentication can be locked for a security element in the first device via an interface of the first device or the second device by a second authentication factor. As an additional security measure, the relayed biometric authentication can be placed under the control of another embedded security element located in the second device acting as a biometric repeater. In this case, the biometric operations can be split among the two devices and the two embedded security elements.

[0048] Figure 3 Illustrates the registration of biometric information used with a second device as an external biometric authenticator.

[0049] User 102 unlocks its user device 104 and proceeds to biometric registration on its security element 302. The user device 104 saves a biometric token (fingerprint, face, iris, vein, etc.) into the security element for external verification 304. This process can be done in the background under each strong authentication, but also during registration / feature enabling. In the case of registration or enabling of this mechanism, an additional security level (e.g., a specific pin code) can be added to achieve two-factor authentication.

[0050] Figure 4 Illustrates a first embodiment of an authentication system. First, a requester 108 wants to use NFC communication 402 to access security data stored in a user device 104 that does not have battery power or is in a low-power mode for verification. The user device 104 detects the NFC request and retrieves data from the security element 404 using the NFC circuitry. The user device 104 then sends a specific response 406 to the requester 108 using NFC. This token response can include encrypted data, biometric data to be verified, a timestamp, etc. The owner or user 102 of the user device uses the requester device 108 to check its biometric data (face, fingerprint, etc.) 408. The biometric data received from the user 102 is compared with the biometric data included in the token response 410. If the compared data is verified, then the requester 108 can access the secure encrypted data received in response from the user device. This can be done by decrypting the received encrypted secure data.

[0051] Optionally, in the case of two-factor authentication, the user 102 can be requested to use a pin code to access the data.

[0052] This process allows the user device 102 to use the requester device 108 as a biometric authentication peripheral via the NFC interface. Note that the second device and the authenticator device can be the same or different.

[0053] Figure 5Shows a second embodiment of the authentication system. First, the requester 108 wants to use NFC communication 502 to access secure data stored in the user device 104 that does not have battery power or is in a low-power mode for verification. The user device 104 detects the NFC request and retrieves data from the secure element 504 using the NFC circuit. The user device 104 then sends a specific response to the requester 506 using NFC. This token response may include biometric data, a timestamp, etc. to be verified. Next, the owner or user 102 of the user device uses the requester device 108 to check their biometric data (face, fingerprint, iris, etc.) 508. Optionally, in the case of two-factor authentication, the user 102 may be requested to use a pin code to access the data. The biometric data received from the user 102 is compared with the biometric data included in the token response 510. If the compared data is verified, then the requester can access the secure encrypted data received in response from the user device. The user device 104 receives a request to prove that the user has indeed performed biometric verification 512. The user device 104 proves that the requester is allowed to access the sensitive data stored in the secure element of the user device 514. Subsequently, the encrypted sensitive data is securely sent 516 to the requester 108. Note that the second device and the authenticator device may be the same or different.

[0054] Example scenarios where this method can be used include cases where the user 102 is controlled by an authorizing party or authenticator 108. The battery of the user's mobile phone is low, depleted, or in some other low-power mode, and sensitive data (i.e., ID) requested by the authorizing party requires a high level of authentication. The controlled user 102 has previously enabled a service in their device to use biometric data from an external device to access their ID stored in their secure element. When the external device touches the authorizing device, the authenticator 108 receives a response from the user's mobile device. This request requires strong authentication. The user performs biometric authentication on the authorizing device by using biometric authentication on the external device (eventually requiring two-factor authentication using a pin code). Finally, the authorizing party can access the requested ID document stored in the device of the user with a depleted battery.

[0055] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the aspects to the exact forms disclosed. Modifications and variations may be made in light of the above disclosure, or may be obtained from the practice of the aspects.

[0056] As used herein, the term "component" is intended to be broadly understood as hardware, firmware, and / or a combination of hardware and software. As used herein, a processor is implemented in hardware, firmware, and / or a combination of hardware and software.

[0057] As used herein, meeting a threshold may, depending on the context, refer to a value being greater than the threshold, greater than or equal to the threshold, less than the threshold, less than or equal to the threshold, equal to the threshold, not equal to the threshold, etc. It will be apparent that the systems and / or methods described herein can be implemented in various forms of hardware, firmware, and / or combinations of hardware and software. The actual specific control hardware or software code used to implement these systems and / or methods does not limit the aspects. Thus, the operations and behaviors of the systems and / or methods are described herein without reference to specific software code, and it should be understood that the software and control hardware can be designed to implement the systems and / or methods at least in part based on the description herein.

[0058] As used herein, the term "non-transitory machine-readable storage medium" should be understood to exclude transiently propagated signals but include all forms of volatile and non-volatile memory. When software is implemented on a processor, the combination of the software and the processor becomes a particular dedicated machine.

[0059] Since the data processing for implementing the embodiments described herein is mostly composed of electronic components and circuits known to those of ordinary skill in the art, in order to understand and appreciate the basic concepts of the aspects described herein and in order not to obscure or deviate from the teachings of the aspects described herein, the circuit details will not be explained to a greater extent than considered necessary as shown above.

[0060] Unless otherwise specified, terms such as "first" and "second" are used arbitrarily to distinguish the elements described by such terms. Thus, these terms are not necessarily intended to indicate a temporal or other precedence of these elements.

[0061] Those of ordinary skill in the art should understand that any block diagrams herein represent conceptual views of exemplary hardware embodying the principles of the aspects.

[0062] Although each of the embodiments has been described above in terms of its structural arrangement, it should be understood that the aspects also cover the associated methods using the embodiments described above.

[0063] Unless otherwise indicated, all numbers representing parameter values, etc. used in this specification and the claims should be understood to be modified in all cases by the term "about". Thus, unless otherwise indicated, the numerical parameters set forth in this specification and the appended claims are approximations, which may vary depending on the desired characteristics sought to be obtained by the embodiments of the present disclosure. As used herein, "about" can be understood by those of ordinary skill in the art and can vary to some extent depending on the context in which it is used. If there is an unclear usage of a term by those of ordinary skill in the art, then considering the context in which the term is used, "about" can mean up to ±10% of the particular term.

[0064] Even if a particular combination of features is recited in the claims and / or disclosed in the specification, such combinations are not intended to limit the disclosure of the various aspects. In fact, many of these features may be combined in ways not specifically recited in the claims and / or not specifically disclosed in the specification. Although each dependent claim listed below may directly depend on only one claim, the disclosure of the various aspects includes each dependent claim in combination with every other claim in the claim set. The phrase "at least one of" in reference to a list of items refers to any combination of those items, including a single member. For example, "at least one of the following: a, b, or c" is intended to cover a, b, c, a - b, a - c, b - c, and a - b - c, as well as any combination with multiple of the same element (e.g., a - a, a - a - a, a - a - b, a - a - c, a - b - b, a - c - c, b - b, b - b - b, b - b - c, c - c, and c - c - c, or any other ordering of a, b, and c).

[0065] Unless so explicitly described, elements, acts, or instructions used herein are not to be construed as critical or essential. Also, as used herein, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more". Further, as used herein, the terms "set" and "group" are intended to include one or more items (e.g., related items, unrelated items, combinations of related and unrelated items, etc.) and may be used interchangeably with "one or more". In cases where only one item is intended, the term "only one" or similar language is used. Also, as used herein, the terms "has", "have", "having", etc. are intended to be open - ended terms. Additionally, unless otherwise explicitly stated, the phrase "based on" is intended to mean "at least partially based on".

Claims

1. A method for accessing secure data on a user device, wherein authenticated access to the user device is unavailable, characterized in that: The method comprises: receiving a request from a requestor to access secure data in the user device; receiving authentication input from a user; authenticating data input from the user using a control token; and The requesting party is provided access to the secure data.

2. The method according to claim 1, characterized in that The authentication input from the user comprises biometric input.

3. The method according to claim 2, characterized in that The authentication input from the user also includes a secret user input code.

4. A method according to any of the preceding claims, characterised in that Authenticating the data input from the user using a control token uses near field communication.

5. A method according to any of the preceding claims, characterised in that Authenticating the data input from the user using a control token uses one of ultra-wideband communication, Bluetooth communication, and near-field magnetic induction communication.

6. A method according to any of the preceding claims, characterised in that Providing the requesting party with access to secure data includes securely sending the requested secure data to the requesting party.

7. A method according to any of the preceding claims, characterised in that Further including: receiving a request from the user to add the control token as an authentication device; as well as The control token is bound to the user device.

8. A method for accessing secure data on a user device by a requester device, wherein the user device is in a low power mode, characterized in that: The method comprises: sending a request to the user device to access secure data in the user device; receiving data from the user device, the data comprising biometric authentication data; receiving a biometric input from an authenticator device, wherein a user provides the biometric input to the authenticator device; comparing the biometric input from the authenticator device to the biometric authentication data; and When the input from the authenticator device matches the biometric authentication data, the security data of the user is accessed.

9. The method according to claim 8, characterized in that The user also provides a secret user input code input to the authenticator device.

10. The method according to claim 8 or 9, characterized in that: Sending the request to the user device utilizes near field communication.

Images