Secure Near Field Communication

Abstract

Secure near-field communication The present description relates to a method comprising:- generating, by a first device, a first and a second element;- providing the first element to a second device;- generating, by the second device, a first public key;- providing the first public key to the first device;- generating, by the first device, a session key;- generating, by the first device, a first code, and its encryption by the session key;- generating, by the first device, a second public key; - providing the first encrypted code and the second public key to the second device;- generating, by the second device, the session key and decrypting the first encrypted code;- controlling an actuator on the basis of the first public key. Figure for abstract: Fig. 1

Description

Title of the invention: Secure near-field communication Technical field

[0001] The present description relates generally to near-field communication methods between two devices, more particularly to methods of exchanging keys by near-field communication. Prior art

[0002] Certain services, such as for example locker rental, nightly accommodation rental, the provision of secure parking for a vehicle such as a bicycle, etc., require authentication between the user of the service and the equipment.

[0003] Authentication may be performed through the execution of a client application, for example installed on a user's smartphone. However, in certain use cases, it may be desirable for the execution of the application and / or the communication between the user's smartphone and the hardware device to be able to take place in a white zone, i.e. without connection to any network.

[0004] Additionally, it may be desirable for the user to be able to authenticate to multiple hardware devices.

[0005] However, authentication through an insecure application is generally prone to cyber attacks such as, for example, replay attacks, spoofing attacks, relay attacks, or man-in-the-middle attacks.

[0006] There is a need to improve authentication processes between two devices. In particular, there is a need to make authentication processes, which are carried out via an unsecured application, more robust against cyberattacks. Summary of the Invention

[0007] An embodiment provides an authentication method between a first device and a second device, the method comprising: - generating, by the first device, a first element and a second element, and storing them in a memory of the first device; - providing the first element, by a user of the first device, to the second device; - generating, by the second device, based on the first element and by applying the Diffie-Hellman protocol, a first public key; - providing the first public key to the first device and storing the first public key, in association with the first and second elements, in a memory of the first device; - the generation, by the first device, of a session key, on the basis of the second element and the first public key, by application of a Diffie-Hellman protocol on an elliptic curve; - the generation, by the first device, of a first code, on the basis of the second element, and its encryption by the session key; - the generation, by the first device, of a second public key; - the provision, by near field communication, of the first encrypted code and the second public key to the second device; - the generation, by the second device, of the session key, on the basis of the first element and the second public key, and the decryption of the first encrypted code, using the session key; - storing, in a memory of the second device, the first decrypted code; - the control, by the second device, of a first actuator following authentication of the second device, or of a third device, by the first device and on the basis of the first public key.

[0008] According to one embodiment, the above method further comprises: - the generation, by the first device, of a second code, on the basis of the second element, and its encryption by the session key and the provision, by near field communication, of the second encrypted code to the second, or to the third, device; - decryption, by the second, or third, device, of the second encrypted code and comparison of the second decrypted code with the first decrypted code; - based on the comparison between the first and second decrypted codes, the control, by the second device, of the first or a second actuator.

[0009] According to one embodiment, the first action is a locking or unlocking action of the second device and the second action is an unlocking or locking action of the second or third device.

[0010] According to one embodiment, the first public key is provided, by the second device, to the first device via an unsecured near-field communication.

[0011] According to one embodiment, the first element is a digital code and wherein the provision of the first element to the second device, via the user, consists of the user entering the digital code on a keyboard of the second device.

[0012] According to one embodiment, the first element is a quick response code and wherein providing the first element to the second device, via the user, consists of presenting the quick response code to a code reader at quick response from the second device.

[0013] According to one embodiment, the second element is a random value comprising a number N of words included in a standard dictionary of words encoding entropy, for example the BitCoin improvement proposal 39, N being an integer between 3 and 24.

[0014] According to one embodiment, the session key is erased from the first and second devices following the performance of the first action, and in which the session key is generated again, by the first device, then by the second, or the third, device, following the authentication of the second, or the third, device, by the first device.

[0015] According to one embodiment, the above method further comprises, before the generation, by the first device, of the session key, the authentication of the second device, by the first device and on the basis of the first public key and on the basis of a master key.

[0016] According to one embodiment, the above method further comprises, before carrying out the first action: - the encryption, by the second device, of the first element, and the provision of the encrypted first element to the first device; - decryption, by the first device, of the first encrypted element and comparison between the first decrypted element and the first element; and - if the first decrypted element and the first element do not match, the process is stopped.

[0017] According to one embodiment, the above method further comprises following the generation of the first code, providing a message authentication code to the second device.

[0018] According to one embodiment, the message authentication code is one of the coordinates, on the elliptic curve, of the session key.

[0019] According to one embodiment, the above method further comprises, following the provision of the first encrypted code and / or the second encrypted code: - the estimation, by the second, or the third, device, of the time elapsed between the sending, by the first device, of the encrypted code and the reception, by the second device, of the encrypted code; - the comparison, by the second, or the third, device, of the estimated elapsed time and a threshold value; and - if the estimated elapsed time is greater than or equal to the threshold value, the process is stopped.

[0020] According to one embodiment, the first code is a concatenation of a first part of a value generated on the basis of the second element with a second part of the value and in which the second code is a concatenation of the first part of the value with a third part of the value.

[0021] One embodiment provides a system comprising first and second devices configured to perform the above method.

[0022] According to one embodiment, the first device is a smartphone. Brief description of the drawings

[0023] These characteristics and advantages, as well as others, will be explained in detail in the following description of particular embodiments given without limitation in relation to the attached figures among which:

[0024] [Fig.l] illustrates an example of authentication between at least one user and a bicycle terminal according to an embodiment of the present description;

[0025] [Fig.2] illustrates near-field communication between two devices;

[0026] [Fig.3A] illustrates the emulation of near-field communication by a device comprising a secure element;

[0027] [Fig.3B] illustrates the emulation of a near field communication by a device comprising an emulation card, according to an embodiment of the present description;

[0028] [Fig.4] illustrates an example of a cyber attack on wireless communication between two devices;

[0029] [Fig.5] is a block diagram illustrating a system configured to implement an authentication method, according to an embodiment of the present description;

[0030] [Fig.6A] is a flowchart illustrating steps of an authentication method, according to an embodiment of the present description; and

[0031] [Fig.6B] is a flowchart illustrating steps of an authentication method, according to an embodiment of the present description. Description of the embodiments

[0032] The same elements have been designated by the same references in the different figures. In particular, the structural and / or functional elements common to the different embodiments may have the same references and may have identical structural, dimensional and material properties.

[0033] For the sake of clarity, only the steps and elements useful for understanding the described embodiments have been shown and are detailed. In particular, the key exchange protocols are not described in detail. In particular, the Diffie-Hellman key exchange protocols, based on cryptography on elliptic curves, are known to the person skilled in the art and are not detailed.

[0034] Unless otherwise specified, when referring to two elements connected to each other, this means directly connected without intermediate elements other than conductors, and when we refer to two elements connected (in English "coupled") to each other, this means that these two elements can be connected or be connected by means of one or more other elements.

[0035] In the following description, when reference is made to absolute position qualifiers, such as the terms "front", "back", "top", "bottom", "left", "right", etc., or relative position qualifiers, such as the terms "above", "below", "upper", "lower", etc., or to orientation qualifiers, such as the terms "horizontal", "vertical", etc., reference is made unless otherwise specified to the orientation of the figures.

[0036] Unless otherwise specified, the expressions "about", "approximately", "substantially", and "of the order of" mean to within 10%, preferably to within 5%.

[0037] [Fig.l] illustrates an example of an authentication between at least one user 100 and a bicycle parking terminal 102 according to an embodiment of the present description.

[0038] For example, user 100 wishes to park his bicycle temporarily on terminal 102. Authentication between user 100 and terminal 102 makes it possible, for example, to lock the bicycle in the terminal in order to protect it. Terminal 102 is, for example, configured to unlock the bicycle when user 100 wishes to retrieve it.

[0039] In particular, the authentication is performed via the use of a smartphone 104. By way of example, the smartphone 104 comprises a client application allowing the user 100 to authenticate himself with the terminal 102. The terminal 102 comprises for example an electronic card configured to perform cryptographic operations according to an embodiment of the present description.

[0040] According to one embodiment, the communication between the smartphone 104 and the terminal 102 is a wireless communication that does not require the smartphone to be connected to a network. For example, the communication between the smartphone 104 and the terminal 102 is a near field communication (NFC). For example, the terminal 102 comprises an NFC radio signal reader, configured to receive radio signals transmitted by the smartphone 104.

[0041] According to one embodiment, once the bicycle is locked in the terminal 102, the user 100 has the possibility of allowing another user 106 to recover the bicycle, and consequently to order the unlocking of the bicycle. For example, the unlocking of the bicycle by the other user 106 is carried out via a smartphone 108, on which the client application is installed.

[0042] According to one embodiment, each authentication between the user 100 and the terminal 102 is unique. That is to say that when the user 100 has, for example, recovered his bicycle, the authentication carried out is forgotten, by the terminal 102 and by the smartphone 104. Thus, each new re-authentication between the user 100 and the terminal 102 is performed as if no authentication had ever taken place.

[0043] According to one embodiment, the user 100 has the possibility of authenticating himself, for example simultaneously, with several terminals similar to the terminal 102. Similarly, users other than the user 100 have the possibility of authenticating himself with the terminal 102, when the latter is free.

[0044] Although the example illustrated by [Fig. 1] shows a bike rack, other devices are of course conceivable. For example, in the same locking-unlocking context, the device with which the user authenticates is, for example, a locker for storing items in a public place such as a swimming pool, a museum, a supermarket, etc.

[0045] In another example, authentication is carried out at a parking terminal, for example for self-service vehicles such as bikes, scooters or cars. In this example, authentication allows, for example, to unlock a parked vehicle and then lock it, for example at a parking terminal different from the one used for unlocking.

[0046] In yet another example, authentication is performed, for example, between two smartphones. In this example, authentication is performed, for example, at the entrance to a museum or a tourist site. For example, the user authenticates upon entry, then upon exit. For example, authentication upon entry, then upon exit makes it possible to establish billing based on time spent.

[0047] [Fig.2] illustrates a near-field communication protocol between two devices 200 and 202. In particular, [Fig.2] illustrates the verification, by a reader device 200, of the authenticity of an NFC tag transmitted by an electronic chip 202.

[0048] For example, the reader 200 is powered and emits a radio signal. When the electronic chip 202 is within range of the radio signal emitted by the reader 200, the chip 202 is for example powered by the radio signal.

[0049] The electronic chip 202 is configured to provide a message to the reader 200. For example, the message comprises an identifier (TAGID), a count value (TAGCOUNT) and an encrypted code (UCODE). For example, the encrypted code depends on the value of the identifier and the count value. For example, the encrypted code has been encrypted using a secret key (SECRETKEY) known by the chip 202. The reader 200 is then configured to verify the authenticity of the chip 200 on the basis of the secret key, before performing, or not, the required action. For example, the secret key is stored remotely, on a server, and the chip 202 is configured to query the server upon receipt of the message, for example by providing the server with the identifier, so that the latter provides it with the secret key.

[0050] However, this communication protocol is vulnerable to cyberattacks, such as relay attacks or man-in-the-middle attacks. In addition, this protocol requires complex secret key management. In particular, so that the secret key is not transmitted during NFC communication to the reader 200, the management of the secret keys is based for example on a public key infrastructure (PKI). The secret keys are then stored in a remote and secure server, for example in association with the chip identifier. The communication protocol requires a connection between the reader and the server in which the secret keys are stored. The reader 202 transmits the encrypted message, the identifier and the counting value to the remote server. The server, knowing the secret key of the chip 200, is able to verify that the encrypted message has indeed been generated from the secret key of the indicated identifier, taking into account the counting value.Incrementing the count value with each new use of the 200 chip prevents replay attacks on the encrypted message.

[0051] [Fig. 3A] illustrates the emulation of a near-field communication by a device 300 comprising a secure element 302 (SECURE ELEMENT). For example, the device 300 is a smartphone. For example, the secure element 302 comprises an emulation of a chip similar to the chip 202. The device 300 further comprises a control circuit 304 (NFC CTRL) configured to provide the data transmitted by a reader device 306 to the secure circuit 302. The secure element 302 is configured to communicate directly with the reader 306, without the intervention of a generic processor 310 (HOST CPU) of the device 300. In particular, the near-field communication between the secure element 302 and the reader 306 is carried out without the intermediary of the execution of an application installed on the device 300.For example, once the transaction between the secure element 302 and the reader 306 is completed, the processor 310 has access to the status of the transaction.

[0052] In the example described in relation to [Fig.3A], an application, such as the client application described in relation to [Fig.1], of the device 300 does not have the possibility of initiating an NFC communication via the secure element 302. Indeed, access to the secure element 302 is generally not open to applications. The client application cannot therefore benefit from the advantages provided by the secure element 302. In particular, the client application cannot benefit from the robustness of the secure element 302 against cyberattacks during NFC communications.

[0053] [Fig.3B] illustrates the emulation of a near-field communication by a device 312 comprising an NFC emulation software brick.

[0054] For example, software enabling the emulation of an NFC chip is installed in a memory (not shown) of the device 312. For example, the emulation software comes from HCE (Host Card Emulation) technology. For example, the software is executed by a generic processor 314 (HOST CPU). of the device 312 during an NFC transaction with a reader device 316 (NFC READER). By way of example, the device 312 further comprises a control circuit 318 (NFC CTRL) configured to provide the data transmitted from the reader device 316 to the processor 314, and / or to transmit data from the processor 314 to the control circuit 318.

[0055] HCE-type emulation software is easily implementable on a device such as a smartphone and allows the use of applications using NFC communication protocols. However, the use of emulation software makes the device vulnerable to cyberattacks.

[0056] [Fig.4] illustrates an example of a cyber attack on a wireless communication between two devices 400 (CB) and 402 (TERMINAL). In particular, [Fig.4] illustrates a relay attack on the device 400. The device 400 comprises, for example, an NFC chip. For example, the device 400 is a means of payment, such as a bank card or a smartphone comprising a payment application. For example, the device 402 is an electronic payment terminal (EPT) configured to carry out financial transactions.

[0057] A relay attack on the device 400 is for example carried out via two attackers and via a pirate device 404 (MOLE) and an accomplice device 406 (PROXY). The reader device 404 is placed near the device 400, for example at a distance of less than 50 cm from the device 400. The NFC chip of the device 400 is then powered by the sending of a request by the device 404. When the device 400 responds to the request, the message sent by the device 400 is transmitted, by the reader device 404, to the accomplice device 406. For example, the accomplice device 406 is within range of the device 402. For example, the attacker holding the accomplice device 406 pretends to pay with the device 406 to the device 402. The device 406 then transmits the message, from the device 400, to the device 402.Thus, the device 402 believes that the transaction is carried out by the device 406 when it is, in reality, carried out by the device 400 and, for example, without the knowledge of the holder of the device 400.

[0058] [Fig. 5] is a block diagram illustrating a system 500 configured to implement an authentication method, according to an embodiment of the present description. The system 500 comprises, for example, a device 502, such as for example a parking terminal, a locker, or a smartphone, comprising an electronic chip 504 configured to carry out NFC type communications. By way of example, the chip 504 comprises, or is, a secure element.

[0059] The system 500 further comprises a device 506, such as for example a smartphone, the device 506 comprising an electronic chip 508 configured to carry out NFC type communications. For example, the chip 508 comprises an NFC emulation software brick as described in relation to [Fig.3B].

[0060] The system 500 is configured to interact with a user 509 (USER). For example, the user is the owner of the device 506.

[0061] The chip 504, included in the device 502, comprises for example a processor 510 (CPU) connected to a non-volatile memory 512 (NVMEM) via a bus 514. According to one embodiment, the processor 510 is configured to perform cryptographic operations, such as for example cryptographic operations on elliptic curves. For example, the memory 512 is included in a hardware security component, such as a secure element, a trusted platform module (in English "Trusted Platform Module"), a secure storage element, etc.

[0062] According to one embodiment, the memory 512 stores the value of at least one secret key, such as for example a secret key linked to the provider of the service implemented by the device 502. The memory 512 stores, for example, in addition, at least one private key associated with the device 502 as well as a secret value. The memory 512 stores, for example, in addition at least one public key, such as for example a public key associated with the device 502. By way of example, the public key is stored in an encrypted manner, for example by being signed by the private key. By way of example, the memory 512 and the processor 510 are included in a secure element of the device 502.

[0063] The device 502 further comprises, for example, an interface 516 connected to the bus 514. For example, the interface 516 is a keyboard, a touch screen, a QR code scanner, etc.

[0064] The chip 508 comprises for example a processor 518 (CPU) connected to a non-volatile memory 520 (NVMEM) via a bus 522. According to one embodiment, the processor 518 is configured to perform cryptographic operations, such as for example cryptographic operations on elliptic curves.

[0065] The chip 508 further comprises an application 524 (APP.). For example, the application 524 is a software application installed in a non-volatile memory of the device 506 connected to the bus 522. The application 524 is configured to, when executed by the processor 518, generate elements, such as for example numerical values ​​and recovery phrases (in English “mnemonic phrases” or “seed phrases”). For example, the recovery phrases are sequences of words, for example sequences of between 3 and 24 words. Each word of a recovery phrase is for example randomly chosen from a standard list of words, for example from a list of 2048 words determined by the BIP39 standard (from the English “Bitcoin Improvement Proposal 39”). In another example, the application 524 is configured to generate quick response codes (QR codes).

[0066] The device 506 further comprises an interface 526 (INTERFACE) allowing the user 509 to interact with the device 526. For example, the interface 526 is a touch screen, a keyboard, etc.

[0067] [Fig.6A] is a flowchart illustrating steps of an authentication method. In particular, the flowchart of [Fig.6A] illustrates steps for performing a first action by the device 502. For example, the first action is locking a bicycle in a parking terminal, locking a locker or more generally a door. In another example, the first action is unlocking a bicycle, or a vehicle, made available to the user 509. In another example, the first action is a validation or an authorization, for example to enter a tourist site.

[0068] In a step 600 (SECRET GENERATION), the user 509 launches, for example, the execution of the application 524 on the device 506. For example, a PIN numerical value, such as a personal identification number (PIN) value, is generated by the device 506 when performing step 600. In another example, a quick response code is generated when performing step 600. For example, the generated numerical value, or code, is directly accessible by the user 509. For example, the PIN value, or code, is displayed on a screen of the device 506. According to one embodiment, the PIN value, or code, is further stored in the memory 520.

[0069] When performing step 600, another mnemonic element is generated when executing the application 524. For example, the other mnemonic element is a recovery phrase comprising, for example, between 3 and 24 words, for example 12 words. The generated mnemonic recovery phrase is, for example, directly stored in the memory 520. For example, the recovery phrase is not provided to the user 509.

[0070] When performing step 600, the user 509 transmits the value, or code, previously generated by the application 524, directly to the device 502. For example, the user 509 enters, for example manually, the PIN value via the interface. In another example, the user 509 scans, via the device 502, the quick response code, for example by presenting the device 506 to a reader of the device 502.

[0071] The fact that it is the user 509 who directly provides the value or code to the device 502 protects the system 500 against man-in-the-middle attacks.

[0072] In a step 601 (KEY DERIVATION), the device 502 uses a private key skbome as well as a secret value cJmincodehorne, in combination with the value, or the code, PIN provided by the user 509, in order to generate a private key sklKer[bome. For example, the private key skuserjbome is generated, by the device 502, by applying a key derivation function on the private key kkborne, the secret value chaincodebonie and the value, or the code, PIN. For example, the generation of the private key skuse!.[borne is carried out by the processor 510 in a secure manner.

[0073] The private key skborne and the secret value chaincodeborne are values ​​stored in the memory 512, for example during manufacture, or when the device 502 is put into service. These values ​​are, for example, values ​​specific to the device 502. In the example where the device 502 is a parking terminal, a locker, etc. Each terminal and / or locker includes a private key and a secret value different from those stored in other similar devices.

[0074] The device 502 further comprises, for example, a public key pkborne, as well as a private key skmastet. associated with the holder of the device 502. The keys pkh()rne and skmaster are for example stored securely in the memory 512. In another example, the public key pkborne takes the form of an electronic certificate.

[0075] A public key pkinas!er, associated with the secret key sktnaster, is, for example, further stored in the memory 520 of the device 506. For example, the public key pkmastei. is stored in the memory 520 during the installation of the application 524.

[0076] During step 601, the device 506 further generates, for example securely, a public key pkuseriiwrne. For example, the public key Penserjbome is the result of multiplying a point of an elliptic curve by the value of the private key skuser]borne. For example, the point of the elliptic curve used is the generating point of said elliptic curve. The elliptic curve on which the calculation is performed is, for example, defined upstream and is an elliptic curve suitable for implementing key exchange according to a Diffie-Hellman protocol.

[0077] Step 601 further comprises the electronic signature of the public key pkborne, for example by the private key skmaster. Step 601 further comprises the electronic signature of the public key pkuser[bome, for example by the private key $kborne.

[0078] Step 601 further comprises, for example, the transmission of the signed keys pkbome and P^userjbonte to the device 506. By way of example, the transmission of the signed keys is carried out by NFC communication between the devices 502 and 506.

[0079] In a step 602 (AUTHENTICITY VERIFICATION), the device 506, through the execution of the application 524, verifies the authenticity of the device 502. Verifying the authenticity of the device 502 comprises, for example, verifying the signature of the public key pkborne. The verification is carried out by example, based on the pkmaster key, stored, for example, in the memory 520. In the event that this verification fails, the method ends in failure and the communication between the devices 502 and 506 is broken. For example, when the method ends in failure, the PIN value is deleted from the device 502 and the signed pkbome and pkuserlbome keys are deleted from the device 506. For example, the elements generated during steps 600 and 601, such as the mnemonic recovery phrase, and the sk^gihome and pkuseribome keys, are deleted from the memories of the devices 502 and 506.

[0080] When the verification of the digital signature of the public key pki,Ome succeeds, step 602 continues with the verification of the signature of the key pkuser^ome- For example, following the verification of the digital signature of the key pkhorne, the value of the key pkbm.ne is known by the device 506. The verification of the key pkuserfborne is carried out, for example, via the execution of the application 524 and on the basis of the key pkborne. In the case where the verification of the signature of the key pkuseriborne fails, the method ends in failure. When the verification of the key pkuser]borne succeeds, the public key pkbo!.ne, the mnemonic recovery phrase and the value, or the code, PIN are, for example, stored in the memory 520. For example, the mnemonic recovery phrase and the value, or the code, PINs are stored in the memory 520 in association, and / or for example indexed by the public key pkh(ime.

[0081] For example, the NFC communication between the devices 502 and 506, in particular the transmission of the signed pkborne and pk^ef^fng keys, is carried out in a metal niche, for example made of aluminum in order to thwart a relay attack. For example, the metal niche is attached to, or is part of, the device 502. For example, the signed pkbonie and pk^eribome keys are displayed, for example in the form of quick response codes, on the interface 516 and are scanned by the user 509.

[0082] In a step 603 (SECURE CHANNEL), a secret ephemeralkey is generated by the device 506 in order to create a secure channel with the device 502.

[0083] According to one embodiment, through the execution of the application 524, the mnemonic recovery phrase is used to generate a masterkey value. For example, the masterkey value is a 64-byte value. According to one embodiment, the bytes, for example the 64 bytes, of the masterkey value are divided into at least 5 parts. For example, a first part of 32 bytes constitutes a private key skp]wne]borne and the other 32 bytes are used to define four authenticator values ​​authNk authN'l, authN3 and authNA, each of, for example, 8 bytes. Thus, the masterkey value, generated from the recovery phrase, is a concatenation of the private key skpiimepwrfie and the authentication values ​​authN 1 to authN4. Although the example of a 64-bit value, split into a 32-byte key and four 8-byte identifiers, is given, other sizes and other splits can of course be considered. For example, bytes 0 to 31 of the masterkey value define the private key; bytes 32 to 39 define the authentication value authN 1; bytes 40 to 47 define the authentication value authNZ; bytes 48 to 55 define the authentication value authN3; and bytes 56 to 63 define the authentication value authN4.

[0084] According to one embodiment, the secret key ephemeralkey is generated by the device 506, during the execution of the application 524, on the basis of the private key skphone / borne and the public key pkuser[bone. For example, the secret key ephemeralkey is obtained by multiplication on the elliptic curve of the point defined by the public key pk^r / borne by the scalar determined by the value of the private key ^userlhm-ne- For example, the multiplication of the key pkliseriborne by the key skusei[phone results in a point on the elliptic curve. The point obtained is therefore defined by two coordinates (ephemeralkey(x), ephemeralkey^y)). For example, the secret key ephemeralkey is equal to the coordinate ephemeralkeypx).It is of course entirely possible that the secret key ephemeralkey is equal to the coordinate ephemeralkey(y) ■ The secret key ephemeralkey is then used to encrypt communications transmitted by the device 506 to the device 502. .

[0085] A public key pkpimneibon.te is further generated during the execution of the application 524. For example, the public key pkphone / borne is a point on the elliptic curve comprising two coordinates, the point being derived from the result of the multiplication of point G, generator of the elliptic curve considered, by the scalar defined by the private key skphiweiborne.

[0086] In a step 604 (CIPHER CODE), a secret code is determined. For example, the user 509 does not have control over the choice of the secret code. For example, the secret code is determined as being a part of the generated masterkey value. For example, the secret code is equal to the authentication value authN 1. Other possibilities are of course conceivable. Indeed, the secret code can also be equal to one of the values ​​authNZ, authN3 or authN 4.

[0087] For example, through the execution of the application 524, the secret code is concatenated with one of the other authentication values. For example, the authentication value authN 1 is concatenated with the identification value authNZ. The concatenation of the secret code with the identification value, for example authN2, is then encrypted by the secret key ephemeralkey resulting in a cipher value _codelock.

[0088] A message comprising the value cipher_codelock and the two coordinates of the public key pkpjwneiiy(mie is then transmitted, by NFC communication, to the device 506.

[0089] For example, the transmitted message further comprises a message authentication code (MAC - "Message Authentication Code"), or a hash-based message authentication code (HMAC - "Hash-based Message Authentication Code"), encrypted with the unused coordinate of the point calculated for the generation of the secret key. For example, the MAC, or the HMAC, is generated on the basis of the coordinate ephemeralkeyCy). For example, the MAC or the HMAC is a cryptographic hash and its generation comprises the calculation of a checksum.

[0090] In a step 605 (VERIFICATION), the device 502 generates the secret key ephemeralkey on its side. The generation of the secret key ephemeralkey is carried out, for example, from the public key pkphonelhonw received during the performance of step 604. The secret key ephemeralkey is for example a coordinate of the point ( ephemeralkey ( x ), ephemeralkey ( y ) ), for example the coordinate ephemeralkey ( x ), obtained by multiplication on the elliptic curve of the point defined by the public key pk^^i^f.^ by the scalar defined by the value of the private key

[0091] As an example, the MAC code, or HMAC, generated and received during the performance of step 604, is for example verified using the other coordinate, for example the ephemeralkeylÿ} coordinate generated by the device 502.

[0092] For example, if the verification of the MAC code, or the HMAC code, fails, then the method ends in failure.

[0093] When the verification of the MAC code, or the HMAC code, succeeds, the encrypted value cipher _codelock is stored in the memory 512 of the device 502.

[0094] In a step 606 (ACKNOWLEDGMENT), the device 506 encrypts a value, for example the value P IN, or a value from the quick response code. For example, the encryption is carried out on the basis of the secret key ephemeralkey.

[0095] For example, the encryption is performed on the value P IN, or on a value from the quick response code, concatenated with another value. For example, this other value corresponds to the 8 most significant bytes of the private key skltëi,riiwme. More generally, the other value is a value known by the devices 502 and 506.

[0096] The value encrypted during the performance of step 606 is then transmitted, by NFC communication, to the device 506. The device 506 is then configured, by through the execution of the application 524, to decrypt the received encrypted value. For example, the decryption is carried out on the basis of the application of a symmetric encryption algorithm using the secret key ephemeralkey. The device 506 is then configured to compare the decrypted value with the PIN value, or with the quick response code. For example, the verification is carried out by comparing the first bytes, for example the bytes preceding the last 8 bytes of the decrypted value, with the PIN value, or the quick response code.

[0097] In one example, the device 506 is further configured to communicate to the user 509 the value, or the first bytes of the decrypted value. For example, the communication to the user is performed by display on the interface 526. The user 509 then checks whether the communicated value corresponds, for example, to his PIN code, generated when performing step 600. If the values ​​do not correspond, the user 509 indicates, for example via the interface 526, that the values ​​do not correspond, and the method ends in failure. If the values ​​correspond, the user 509 indicates, for example via the interface 526, that the values ​​correspond, thus validating the authentication between the two devices 502 and 506.

[0098] The device 506 is then configured, via the execution of the application 524 and when the values ​​match, to transmit an ACK validation value, encrypted by the secret key ephemeralkey. For example, the ACK validation value is concatenated with one of the authentication values, for example with the authNS value, before being encrypted by the secret key ephemeralkey.

[0099] The validation value, for example concatenated, encrypted is then transmitted, by NFC communication, to the device 502.

[0100] The device 502 is then configured to decrypt, by means of the secret key ephemeralkey, the value received during the performance of step 606 and to compare it, or to compare the first bytes corresponding to the number of bytes forming the validation value ACK, of the decrypted value with the validation value ACK. For example, the validation value ACK has been stored in the memory 512 upstream, for example during the manufacture, or during the commissioning, of the device 502.

[0101] For example, in the case where the decrypted ACK value does not match the stored value, the method ends in failure. When the decrypted ACK value does match the stored value, the method continues in a step 607 (ACTION 1). Step 607 includes performing an action, such as locking or unlocking the bicycle or vehicle of the user 509, locking the locker door, validating the entry of the user 509 into a tourist site, etc., by the device 502.

[0102] For example, following the performance of step 607, the secret key ephemeralkey is not kept in any memory of the devices 502 and 506.

[0103] Following the performance of step 607, the device 506 stores the value or code, PIN, the mnemonic recovery phrase and the public key pkuser[bome- The device 502 stores the encrypted value cipher _codelock. For example, the device 502 stores the encrypted value cipher_codelock decrypted via the secret key ephemeralkey. For example, the other values, transmitted and / or generated by one and the other of the devices 502 and 506, are deleted from the memories 512 and 520.

[0104] [Fig.6B] is a flowchart illustrating steps of an authentication method, according to an embodiment of the present description.

[0105] By way of example, the steps described in relation to [Fig.6B] are carried out when the user comes to collect his bicycle or vehicle from the parking terminal, or comes to put down the vehicle that was made available to him, or comes to collect belongings placed in the locker, or when the user 509 leaves the tourist site that he was visiting, etc.

[0106] A step 608 (AUTHENTICATION) is for example carried out by the initiative of the user 509. For example, the user 509 presents himself, with the device 506, to the device 502. For example, by means of the execution of the application 524, the device 506 transmits a request by NFC communication to the device 502.

[0107] As an example, the device 502 is configured to expose the public key pkbome signed by the private key skmasTer to the device 506. As an example, the device 502 exposes a digital certificate comprising the value of the public key pk-horne signed by the value of the key skmas{er. As an example, the signed public key pkborne, or the certificate, is transmitted via NFC communication. In another example, the value is for example displayed on the interface 516, for example in the form of a quick response code and the user 509 presents the device 506 in order to scan the code.

[0108] The device 506, through the execution of the application 524, is then configured to verify the authenticity of the device 502 using the public key pkmaster, stored in the memory 520, for example, during the installation of the application 524.

[0109] In the event that the verification of the authenticity of the device 506 fails, the method ends in failure.

[0110] When the authenticity verification is successful, a request for the performance of the second action is transmitted by the device 506 to the device 502.

[0111] For example, the request includes the transmission of the PIN value, or code. to the device 502. For example, the value is transmitted in clear text by NFC communication.

[0112] In a step 609 (KEY DERIVATION), the device 502 regenerates the private key skuser[i3orne based on the value, or code, PIN received when performing step 608, the private key skhorne and the secret value chaincodebm.ne. For example, the private key skuseribome is obtained by applying a key derivation function to the value, or code, PIN, the private key skbome and the secret value chaincodeborne.

[0113] The deterministically regenerated private key skuserjborne is then, for example, signed by the private key skh(trne. The signed private key skuser^orne is then transmitted, by NFC communication, to the device 506.

[0114] In a step 610 (SECURE CHANNEL RE-ESTABLISHMENT), the device 506, through the execution of the application 524, regenerates the masterkey value from the mnemonic recovery phrase, stored in memory. The device 506 further regenerates the secret key ephemeralkey as well as the public key pkphoneiborne. Carrying out step 610 is identical to carrying out step 603. For example, a MAC code, or an HMAC code, is further generated from the coordinate ephemeralkey(y), or epehemeralkey(x) if applicable.

[0115] In a step 611 (CIPHER CODE), the device 506 generates a new secret code codeunlock. The new secret code is equal to the secret code codelock, generated when performing step 604. In other words, the new secret code codeunlock is equal to the authentication value authNI, regenerated when performing step 610. The new secret code codeunlock, is then concatenated with a value different from that concatenated with the value of the codelock code when performing step 604. For example, the new code code _unlock is concatenated with the authentication value authNA. The concatenation of the two values ​​is then encrypted via the secret key ephemeralkey, resulting in an encrypted value cipher _codeunlock. So, although the two secret codes codelock and codeunlock are identical, the encrypted values ​​cipher _codelock and cipher _codeunlock differ.

[0116] A message comprising the encrypted code cipher codeunlock, the public key pkphimdborne, regenerated during the performance of step 610, as well as the MAC code, or HMAC, generated, for example on the basis of the ephemeralkey coordinate (y), is provided to the device 502.

[0117] In a step 612 (VERIFICATION), the device 502 estimates, for example, the time elapsed between the transmission of the message and its reception. The device 502 is then configured to compare the estimated time with a reference time period. For example, the reference time period is a duration less than 1 second, for example of the order of several milliseconds. If the estimated time is greater than the reference time period, the method ends in failure. In the case where the estimated time is much less than the reference time period, the device 502 regenerates the secret key ephemeralkey. The generation of the secret key ephemeralkey is carried out in an identical manner to the generation carried out in step 605. The device 502 then verifies, for example, the integrity of the MAC or HMAC code received by decrypting it using the coordinate ephemeralkey(y\ or ephemeralkey^ if applicable, also regenerated during the calculation of the secret key ephemeralkey. If the integrity of the MAC or HMAC code is not verified, the method ends in failure. If the MAC or HMAC code is indeed intact, the device 502 decrypts the encrypted code cipher_codeunlock.The device 502 further decrypts the encrypted code cipher _codelock, stored in memory following the performance of step 607.

[0118] The device 502 is then configured to compare the first bytes, for example the number of bytes corresponding to the size of the authentication values, for example the first 8 bytes of the decrypted cipher_codeunlock and cipher_codelock codes. If the two compared elements, normally equal to the authentication value authN 1, do not match, the method ends in failure. If the two compared elements match, and therefore are both equal to the value authN 1, the device 502 compares the remaining bytes, for example the last 8 bytes, of the decrypted cipher_codeunlock and cipher_codelock codes. If the remaining bytes of the decrypted cipher_codeunlock and cipher_codelock codes are equal, the method ends in failure.

[0119] If the remaining bytes of the decrypted cipher _codeunlock and cipher _codelock codes differ, the method continues in a step 613 (ACTION 2). Indeed, for the method not to end in failure, the last bytes of the decrypted cipher_codeunlock and cipher_codelock codes must differ, some being for example equal to the value authN2 and the others to the value authNA. Indeed, if the last bytes of the decrypted cipher _codeunlock and cipher _codelock codes are equal, this indicates that a replay attack is possibly taking place.

[0120] Carrying out step 613 consists, for example, of carrying out the second action.

[0121] For example, following the performance of step 614, the value, or code, PIN, the recovery phrase mnemonic and the public key pkuseribonie, as well as all other values ​​and elements generated during the performance of steps 608 to 613, are deleted from memory 520. Similarly, the encrypted code cipher _codelock, stored in memory 512 following the performance of step 607, is deleted from memory 512, as well as all other values ​​generated and received during the performance of steps 608 to 613. In other words, following the completion of step 614, the keys skmaster, skborne and the value chaincodeb()rne are stored in memory 512 and the key pkmaster is stored in memory 520.

[0122] For example, all operations performed by the device 502 are performed securely, for example in a secure hardware element of the device 502.

[0123] The steps described in relation to Figures 6A and 6B can be carried out in parallel between the device 506 and several devices similar to the device 502. In this case, the values, or codes, as well as the recovery phrases generated by the device 506, differ for each device similar to the device 502. Thus, all the other values ​​and keys generated when carrying out the steps described in relation to Figures 6A and 6B differ between each device similar to the device 502.

[0124] As an example, for example when the first action consists of unlocking a vehicle from a parking terminal and the second action consists of locking the vehicle in a parking terminal, the device 502 with which the first action is performed may differ from the device 502 with which the second action is performed. In this case, the use of the skbon,e key is replaced by the use of the skmaster key and only a self-signed certificate is exposed when performing step 601. In this case, the public key pkborne does not differ from one device 502 to another.

[0125] In some cases, it is another user of a device 506 remote from the device 502 who communicates the public key pkbome, the value, or the code, PIN and mnemonic to another user having a device similar to the device 506 within range of the device 502. For example, the steps described in relation to [Fig.6A] are carried out with a user different from the one present for carrying out the steps described in relation to [Fig.6B]. This example takes place for example when the user 509 wishes to lend his vehicle that he has parked in a parking terminal to a third party.

[0126] An advantage of the described embodiments is that they allow robust communication in the face of most known cyber attacks.

[0127] Another advantage of the described embodiments is that their implementation is carried out without connection to any network. Thus, the implementation of the described embodiments is also possible in a white zone. In particular, NFC communication does not use a PKI (Public Key Infrastructure).

[0128] An advantage of the described embodiments is that the number of elements kept in memory of the devices 502 and 506 is restricted.

[0129] Various embodiments and variations have been described. Those skilled in the art will understand that certain features of these various embodiments and variants could be combined, and other variants will occur to those skilled in the art. The values ​​used for the concatenations are given as examples and are not limiting.

[0130] Finally, the practical implementation of the embodiments and variants described is within the reach of the person skilled in the art from the functional indications given above. In particular, with regard to the presence and use of a hardware security component, such as a secure element, in the device 506. It is of course conceivable that the calculations carried out by the device 506 are made in a secure environment.

Claims

Claims

1. A method of authentication between a first device (506) and a second device (502), the method comprising: - generating, by the first device, a first element (PIN) and a second element (mnemonic), and storing them in a memory of the first device; - providing the first element, via a user of the first device, to the second device; - generating, by the second device, on the basis of the first element and by applying a Diffie-Hellman protocol, a first public key (pk^^^); - providing the first public key to the first device and storing the first public key, in association with the first and second elements, in a memory (520) of the first device;- the generation, by the first device, of a session key (ephemeralkeÿ), on the basis of the second element and the first public key, by applying a Diffie-Hellman protocol on an elliptic curve; - the generation, by the first device, of a first code (codelock), on the basis of the second element, and its encryption by the session key; - the generation, by the first device, of a second public key (pk phonelhome)? - the provision, by a near field communication, of the first encrypted code (cipher_codelock) and the second public key to the second device; - the generation, by the second device, of the session key, on the basis of the first element and the second public key, and the decryption of the first encrypted code, using the session key; - the storage, in a memory (512) of the second device, of the first decrypted code;- the control, by the second device, of a first actuator following authentication of the second device, or of a third device, by the first device and on the basis of the first public key.;

2. The authentication method of claim 1, further comprising: - the generation, by the first device, of a second code (codeunlock\ on the basis of the second element, and its encryption by the session key and the provision, by near field communication, of the second encrypted code (ciphœr _codeunlock) to the second, or to the third, device; - the decryption, by the second, or the third, device, of the second encrypted code and the comparison of the second decrypted code with the first decrypted code; - on the basis of the comparison between the first and second decrypted codes, the control, by the second device, of the first or of a second actuator.

3. The method of claim 1 or 2, wherein the first action is a locking or unlocking action of the second device (502) and the second action is an unlocking or locking action of the second or third device.

4. The method of any one of claims 1 to 3, wherein the first public key (pkllser\borne) is provided, by the second device (502), to the first device (506) via an unsecured near-field communication.

5. A method according to any one of claims 1 to 4, wherein the first element (PIN) is a digital code and wherein providing the first element to the second device (502), via the user, consists of the user entering the digital code on a keyboard of the second device.

6. A method according to any one of claims 1 to 4, wherein the first element is a quick response code and wherein providing the first element to the second device (502), via the user, comprises presenting the quick response code to a quick response code reader of the second device.

7. A method according to any one of claims 1 to 6, wherein the second element is a random value comprising a number N of words included in a standard dictionary of words encoding entropy, for example BitCoin Improvement Proposal 39, N being an integer between 3 and 24.

8. A method according to any one of claims 1 to 7, wherein the session key (ephemeralkey) is erased from the first and second devices (502, 506) following the performance of the first action, and wherein the session key is regenerated, by the first device, then by the second, or third, device, following authentication of the second, or third, device by the first device.

9. Method according to any one of claims 1 to 8, further comprising, before the generation, by the first device (506), of the session key (ephemercdkey), the authentication of the second device (502), by the first device and on the basis of the first public key (pk^rj^^g) and on the basis of a master key (pknmster).

10. A method according to any one of claims 1 to 9, further comprising, before performing the first action: - encrypting, by the second device, the first element (PIN) and providing the encrypted first element to the first device; - decrypting, by the first device, the encrypted first element and comparing the decrypted first element with the first element; and - if the decrypted first element and the first element do not match, stopping the method.

11. A method according to any one of claims 1 to 10, further comprising following generation of the first code (codelock), providing a message authentication code to the second device.

12. The method of claim 11, wherein the message authentication code is one of the coordinates, on the elliptic curve, of the session key (ephemeralkey).

13. A method according to claim 2, or any one of claims 3 to 12, as dependent on claim 2, further comprising, following the provision of the first encrypted code (cipher_codelock) and / or the second encrypted code (cipher_codeunlock): - estimating, by the second, or the third, device (502), the time elapsed between the sending, by the first device (506) of the encrypted code and the reception, by the second device, of the encrypted code; - comparing, by the second, or the third, device, the estimated elapsed time and a threshold value; and - if the estimated elapsed time is greater than or equal to the threshold value, stopping the method.

14. A method according to claim 2, or any one of claims 3 to 13 as dependent on claim 2, wherein the first code (codelock) is a concatenation of a first part of a value (masterkey) generated based on the second element with a second part of the value and in which the second code is a concatenation of the first part of the value with a third part of the value.

15. A system comprising first and second devices (506, 502) configured to perform the method of any one of claims 1 to 14.

16. The system of claim 15, wherein the first device (506) is a smartphone.

Images