Method for managing a user secret in a security device

Abstract

The present invention describes a method for securely capturing a secret on a third-party device in order to perform authentication on a security device connected to the third-party device or to personalize an initial secret on that security device. Using a lookup table displayed on the security device allows a mask to be added to the value of the secret manipulated by the third-party device.

Description

Title of the invention: Method for managing a user secret in a security device

[0001] The present invention presents a method for securely managing a user secret (for example, the personal identification number also called PIN code, or any other secret) in a security device (which may, for example, be a FIDO key or a hardware cryptocurrency wallet) having a limited physical user interface and which may take advantage of the user interface functions of a third-party device (computer, phone or tablet) to secure and facilitate the user experience of managing a secret.

[0002] Some applications today use a virtual mixed keyboard to secure password entry. This is the case, for example, for some French banks which have been implementing this principle for several years.

[0003] This technique makes it possible in particular to protect against spying on the user's input devices (keyboard and mouse) since the virtual keyboard is shuffled each time the user enters their password.

[0004] This principle is not sufficient, however, if an attacker has the ability to capture both what is displayed to the user and also the user's input devices. The main vulnerability here lies in the fact that the entire process of collecting user credentials runs on a single machine. Since this machine can be compromised by an attacker, it is difficult to place complete trust in this authentication mechanism.

[0005] The present invention proposes to build upon and improve this solution to allow a user to initialize, update, or validate their secret on a security device in the event that: • The security device does not physically have a keyboard (or any other similar device) allowing the secret to be entered directly on the device itself. • The security device must have a screen large enough to display, for example, a virtual keyboard. • a third-party device (e.g., computer, phone, or tablet) is used to collect user input.

[0006] The third-party device, used to collect user input, which may not be trusted (for example, it may not belong to the user or it may be infected by a virus), must not be able to know the value of the secret of The user must ensure the integrity of the security device. Therefore, the user's secret must not, for example, be entered in plain text on the third-party device.

[0007] The security device is, by definition, considered to be trusted since it is a device dedicated to performing sensitive operations and has possibly undergone a high-level certification process. It is therefore considered highly improbable that the security device itself would be under the control of an attacker.

[0008] In the configuration described in paragraph

[0005] , and taking into account the prerequisites described in paragraphs

[0006] and

[0007] , the present invention therefore proposes to use the third-party device to provide a suitable interface for entering the secret and to use the screen of the security device to mask the true value of the secret from the third-party device. With this proposal, compromising the secret is rendered impossible even if the third-party device is under the control of an attacker, all while maintaining the smoothest possible user experience.

[0009] The following sequence is therefore proposed to securely collect the user's secret (see also the illustration provided in [Fig.1]): 1. The user connects their security device to a third-party device (the connection can be made via any type of protocol: USB, Bluetooth, etc.), and uses the appropriate application so that the two devices can communicate with each other. 2. The user performs an action that triggers the request to enter the secret, which causes the following two events: a. The security device displays a lookup table that allows for the random assignment of one character to another (see [Fig 2] for an example of a lookup table using only digits). Each time the user wants to send their secret, a new shuffle of the lookup table is performed. b. the third-party device presents the user with a text input field, 3. using the lookup table displayed on their security device, the user enters into the text field of the third-party device the dynamic code corresponding to their secret (for example, if the user's secret is '1234', the user's dynamic code would be '2731' using the lookup table given as an example in [Fig.2]), 4. The user then validates their entry, which triggers the transmission of the dynamic code to the security device. The latter, knowing the combination in the lookup table, is able to translate the dynamic code to obtain the actual value of the secret the user wants to transmit.

[0010] The third-party device, not knowing the shuffle of the lookup table, is unable to reconstruct the user's secret from the dynamic code entered by the user. Since the lookup table changes with each submission of the secret, the third-party device also cannot know in advance the correct value of the dynamic code to send. Because the security device is trusted, it is considered highly improbable that an attacker would succeed in controlling both the third-party device and the security device to recover the actual value of the secret.

[0011] The sequence described in paragraph

[0009] can be used both for initializing the user's secret during the initial personalization of the security device and also, for example, each time the user needs to authenticate using their secret.

[0012] Note that, although the third-party device cannot retrieve the user's actual secret, it can retrieve partial information about the actual secret using the dynamic code. Consider the following two examples (still using [Fig.2] as the lookup table): • If the secret is '0000', the user will use the dynamic code '8888' and therefore the third-party device can deduce that the user's secret consists of four identical digits, thus reducing the number of possible secrets. • Similarly, if the secret is '1234', the user will use the dynamic code '2731', and here too, the third-party device can deduce that there is no digit repetition in the user's code, which also has the effect of reducing the number of possible secrets.

[0013] However, this information leak can be countered by using one of the following proposals or by using a combination of these proposals: • Similar to a bank card, the presence of a test counter in the security device helps prevent brute-force attacks. The test counter must be small enough to be effective. • The larger the size of the secret, the more difficult it will be to exploit the information leak explained in paragraph

[0012] . • Using a secret with the least possible repetition of digits also helps to reduce the exploitation of a leak as described in paragraph

[0012] . • Using a unique lookup table for each alphanumeric character of the secret completely eliminates the risks detailed in paragraph

[0012] . However, this option requires the user to perform an action (e.g., press a button) to instructing the security device to move to the next lookup table may reduce the user experience.

[0014] We will take as an example the well-known and standardized FIDO2 application, which provides a secure way to authenticate users without a password, while preserving privacy. Online services (e.g., websites) can use this specification by implementing the server-side of the FIDO2 protocol. This protocol and these applications replace usernames and passwords using public-key cryptography in a convenient way that also preserves user privacy.

[0015] Let us consider, as an example, that: our security device is a FIDO2 device, with a screen and a button; our third-party device is a Windows 11 computer; both devices have the ability to establish a Bluetooth connection. The PIN code of the FIDO2 device has not yet been personalized. The following sequence can therefore be executed: 1. The user connects their FIDO2 device to their computer. 2. The user triggers the personalization of their PIN code by performing the two subsequent actions: a. Pressing the button on the FIDO2 device triggers the display of the lookup table (with a new mix). b. By using the configuration interface for a physical key available in Windows settings, the user obtains the input field allowing entry of their PIN code. 3. The user enters the dynamic code corresponding to the PIN code they have chosen. 4. Validating the user's input triggers the transmission of the dynamic code via the standard FIDO2 protocol. The FIDO2 device receives and translates the dynamic code into an actual PIN.

[0016] After this initial PIN code setup, the user can use their FIDO2 device with a website that implements the FIDO2 protocol to authenticate without a password: 1. The user connects their FIDO2 device to their computer. 2. The user navigates to the website using their internet browser. computer and accesses the authentication page. The FIDO2 protocol is triggered: a. The FIDO2 device displays the lookup table (with a new mix). b. The browser requests the user's PIN code so that the FIDO2 device can authenticate it. 3. The user enters the dynamic code corresponding to the PIN code that he has personalized (see paragraph

[0015] ). 4. Validating the user's entry triggers the transmission of the dynamic code via the standard FIDO2 protocol. The FIDO2 device receives and translates the dynamic code into a valid PIN. Finally, if the PIN is correct, the user's authentication on the website proceeds according to the standard FIDO2 protocol.

[0017] Let us consider, as another example, that: our security device is a Bitcoin hardware wallet, with a screen and two buttons; our third-party device is a Windows 11 computer; both devices have the ability to establish a Bluetooth connection. We consider the case where the user wants to import their private keys from another Bitcoin wallet. To do this, the user must enter an initial secret, which is represented by 24 words. The following sequence must therefore be executed: 1. The user connects their security device to their computer. 2. The user triggers the import of their private keys using the user interface of his Bitcoin wallet application that he installed on Windows, which triggers the following actions: a. The Bitcoin wallet application on Windows notifies the Bitcoin application on the security device of this action, and the latter displays an alphanumeric lookup table (with a new shuffle) on the security device's screen. If the security device's screen is too small to display the entire lookup table, only the first part of the table is displayed, and the user can advance to subsequent parts by pressing a button on the security device or go back with another button. b. The Bitcoin wallet application on Windows displays an input field to the user. 3. The user enters the dynamic code corresponding to each word they must enter. 4. For each word, validation of the user input field triggers the sending of the dynamic code via the Bluetooth protocol to the security device. 5. The security device receives and translates the dynamic code. The translated word is displayed on the security device's screen, and the user can verify its accuracy before confirming it and moving on to the next word using a button on the security device. 6. After validation of each word in the series of 24 words, the import is finalized and the security device generates the user's keys.

Claims

Demands

1. A method for managing user secrets by a security device equipped with a screen but without a keyboard, which is connected to another device that has a keyboard, or other means of input, according to the following steps: a. The security device displays on its screen a table of alphanumeric character correspondences in which each alphanumeric character is assigned to another alphanumeric character. b. The user enters the dynamic code on the other device that is connected to the security device using the lookup table displayed by the security device and choosing, for each alphanumeric character of the secret, the alphanumeric character that is assigned to the original alphanumeric character of his secret in place of the original alphanumeric character. c. The connected device sends the dynamic code thus entered by the user to the security device using their communication channel. d. The security device receives the dynamic code and replaces each alphanumeric character containing this code with the original alphanumeric character in the lookup table to recover the original secret. e. The security device uses the secret thus decrypted to initialize or update the security device's secret or to validate or reject it during an authentication procedure.

2. A method for authenticating the user by a security device according to the

1. which is used for entering a numeric PIN code using a numeric lookup table instead of an alphanumeric table.

3. A method for user authentication by a security device according to the [Claims 1 & 2] in which the lookup table changes randomly for each request for the user to enter the secret

4. A process according to the [Claims 1 & 2] which is used for the user secret initialization phase during the initial customization of the security device.

5. A process according to the [Claims 1 & 2] which allows the matching table to be displayed on several consecutive screens (if it is too large) and allowing the user to navigate between the different screens using navigation buttons on the security device or the auxiliary device.

6. A security device equipped with a screen but without a keyboard, which has one or more means of communication such as USB, Bluetooth, NFC or others, and which implements the process according to the [Claims 1 & 2] by communicating with an attached device such as a PC or telephone or other device which has input means.

7. A safety device according to the

6. that can reject user choices of a secret in the initial security device personalization procedure if that secret incorporates repetitions of alphanumeric characters that weaken the secret.

8. A security device according to the

6. which may be in the form of a smart card or a USB dongle.

Images