Protecting a communication

Abstract

Communication Protection This description relates to a method (400) for wireless communication between a first device (TERM) and a second device (CARD) comprising the following successive steps: - sending, by the first device (TERM), to the second device (CARD) a first request (S-Block(Ptime, NONCE_R)); - responding, by the second device (CARD), to the first device (TERM) with a first response (S-Block(OK, NONCE_R, NONCE_R_C)); and - verifying, by the first device (TERM), the response time of the second device (CARD) using a reference time that depends on the first request (S-Block(Ptime, NONCE_R)). Figure for the abstract: Fig. 4

Description

Title of the invention: Protection of a communication technical field

[0001] This description relates generally to electronic systems and devices, and to the means of communication between these electronic systems and devices. More specifically, this description relates to the protection of communications between electronic devices against malicious attacks, and more precisely to the protection of wireless communication against malicious attacks. Previous technique

[0002] Increasingly, transactions are being carried out via wireless communications, such as communications using near-field communication (NFC) technology. These wireless communications can be vulnerable to various types of malicious attacks that can, for example, allow the retrieval of confidential data.

[0003] It would be desirable to be able to improve, at least in part, certain aspects of the protection of wireless communications between electronic devices against malicious attacks. Summary of the invention

[0004] There is a need for secure wireless communication methods between two electronic devices.

[0005] There is a need for secure NFC communication methods between two electronic devices.

[0006] There is a need for NFC communication methods using the communication protocol set by the ISO-14443 standard, between two secure electronic devices.

[0007] There is a need for such secure communication methods against malicious attacks of the relay attack type.

[0008] One embodiment overcomes all or part of the disadvantages of known wireless communication methods.

[0009] One embodiment provides for wireless communication between a terminal device and a card device, in which the terminal device checks the response time of the card to a particular request sent at the beginning of the communication.

[0010] One embodiment provides that the terminal device checks the response time of the card based on a reference time which is dependent on characteristics of the card device.

[0011] One embodiment provides that the terminal device sends said reference time to said card device in said particular request.

[0012] One embodiment provides for a wireless communication method between a first device and a second device comprising the following successive steps: - send, via the first device, a first request to the second device; - to respond, using the second method, to the first method with an initial response; and - verify, by the first device, the response time of the second device using a reference time that depends on the first request.

[0013] One embodiment provides a method for establishing wireless communication by a first wireless communication device comprising the following steps: - send a first request (S-Block(Ptime, NONCE_R)); - receive an initial response (S-Block(OK, NONCE_R, NONCE_R_C)); and - check the response time using a reference time (PTime) which depends on the first request (S-Block(Ptime, NONCE_R)).

[0014] One embodiment provides a method for establishing wireless communication via a second wireless communication device comprising the following steps: - receive a first request (S-Block(Ptime, NONCE_R)); - send a first response (S-Block(OK, NONCE_R, NONCE_R_C)), in which a response time depends on a reference time, itself dependent on characteristics of said second device.

[0015] One embodiment provides a device adapted to be the first device in a wireless communication method between said first device and a second device comprising the following successive steps: - send, via the first device, a first request to the second device; - to respond, using the second method, to the first method with an initial response; and - verify, by the first device, the response time of the second device using a reference time that depends on the first request.

[0016] One embodiment provides a device adapted to be the second device in a wireless communication method between a first device and said second device comprising the following successive steps: - send, via the first device, a first request to the second device; - to respond, using the second method, to the first method with an initial response; and - verify, by the first device, the response time of the second device using a reference time that depends on the first request.

[0017] One embodiment provides a wireless communication device, adapted to constitute a first device, comprising a microcontroller configured to implement the following steps: send a first request (S-Block(Ptime, NONCE_R)); receive a first response (S-Block(OK, NONCE_R, NONCE_R_C)); check the response time using a reference time (PTime) which depends on the first request (S-Block(Ptime, NONCE_R)).

[0018] One embodiment provides a wireless communication device, adapted to constitute a second device, comprising a microcontroller configured to implement the following steps: receive a first request (S-Block(Ptime, NONCE_R)); send a first response (S-Block(OK, NONCE_R, NONCE_R_C)), in which a response time depends on a reference time, itself dependent on characteristics of said second device.

[0019] According to one embodiment, said reference time depends on characteristics of said second device.

[0020] According to one embodiment, said second device sends its characteristics to said first device during the implementation of an anti-collision mechanism preceding the sending of said first request.

[0021] According to one embodiment, said first request includes the value of said reference time.

[0022] According to one embodiment, said first query includes the value of a first data point.

[0023] According to one embodiment, said first response includes the value of a second data point, and the value of a third data point which is dependent on said first and second data points.

[0024] According to one embodiment, said third data can be used to implement an authentication operation.

[0025] According to one embodiment, the sending of the first request is preceded by: - ​​the sending, by said first device, of a second request to said second device; - the sending, by said second device, of a second response) to said first device.

[0026] According to one embodiment, the communication is a near-field communication.

[0027] According to one embodiment, the communication is a near field communication using the communication protocol defined by the ISO 14443 standard.

[0028] According to one embodiment, in which the first query is a C4 type query of ISO 14443.

[0029] According to one embodiment, the first response is a C5 type response of ISO 14443.

[0030] Yet another embodiment provides for a computer program product comprising program code instructions recorded on a medium usable in a computer, comprising computer-readable programming means for implementing said method described above, being said first device when said program is running on a computer.

[0031] Yet another embodiment provides for a computer program product comprising program code instructions recorded on a medium usable in a computer, comprising computer-readable programming means for implementing said method described above, being said second device when said program is running on a computer. Brief description of the drawings

[0032] These features and advantages, as well as others, will be described in detail in the following description of particular embodiments, given by way of non-limiting example, in relation to the accompanying figures, among which:

[0033] [Fig.1] represents an embodiment of an electronic device adapted to implement the implementation methods described in relation to [Fig.4];

[0034] [Fig.2] represents a practical example of a communication method;

[0035] Figure 3 illustrates an example of implementing a relay attack against a communication method; and

[0036] [Fig.4] represents methods of implementing secure communication processes. Description of the implementation methods

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

[0038] For the sake of clarity, only the steps and elements useful for understanding the described embodiments have been represented and are detailed.

[0039] Unless otherwise specified, when referring to two interconnected elements, this means directly connected without intermediate elements other than conductors, and when referring to two connected (in English "coupled") elements between them, this means that these two elements can be connected or linked via one or more other elements.

[0040] 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", "superior", "inferior", etc., or to orientation qualifiers, such as the terms "horizontal", "vertical", etc., reference is made, unless otherwise specified, to the orientation of the figures.

[0041] Unless otherwise specified, the expressions "approximately", "roughly", and "in the order of" mean within 10%, preferably within 5%.

[0042] The embodiments described below relate to the protection of wireless communication between two electronic devices, called a terminal device and a card device, against a relay attack. Such an attack is described in detail below with reference to [Fig. 3]. To counter such an attack, the terminal device must ensure that the card device with which it initiates communication is reliable by using a reliable communication method, i.e., one that has not been tampered with.

[0043] The solution provided by the embodiments described below is as follows. The terminal device includes a means for verifying the response time of the card device to a particular request. This verification means uses a reference response time, which depends on the characteristics of the card device. If the card device does not respond to the particular request of the terminal device within the time allotted by the reference time, then the terminal device considers the card device to be unreliable. Conversely, if the card device responds on time, then it is considered reliable. If the card device does not respond to the request of the terminal device, the card device will also be considered unreliable by the terminal device.

[0044] Furthermore, the embodiments described below are particularly well-suited for use in wireless communications of the Near Field Communication (NFC) type, and are even more particularly well-suited for use in NFC communications using the communication protocol defined by ISO 14443, or derivatives thereof, such as the standards at the NFC Forum. This standard defines, among other things, a set of requests and responses for initiating reliable NFC communication, but also defines the format of the data exchanged during such communication. Indeed, from the point of view of the integrity of the information exchanged in such communication, typically, distance alters the wave; due to interference or excessive distance, a bit could be misinterpreted. Such communication is described with reference to Figures 2 and 4.

[0045] Furthermore, the embodiments described above are particularly suitable for use in any type of industrial market where wireless communication may be used. More specifically, such a wireless communication method may be intended for: - the automotive industry, for example in the field of automotive electrification or in the field of advanced driver assistance systems (ADAS); - the industrial industry, for example in the field of green energy, in the field of infrastructure electrification, the Internet of Things (IoT) and Smart Homes, where electricity and energy consumption and data exchange are key elements; - the personal electronics industry, for example in the field of mobile telephony and the Internet of Things (IoT), as well as in the field of broadband interfaces; - the communications equipment, computer and peripherals industry, for example in the field of infrastructure and data centers, and in the field of low Earth orbit (LEO) satellites; and - the wireless transaction industry, typically in payment transactions between a terminal and a card, the transport industry, typically transactions with transport companies (metro, tram, bus ...), unlocking cars with a phone, and the access management industry, typically access management with the use of a badge that is read on a reader.

[0046] Figure 1 is a block diagram representing, very schematically, the architecture of an example of an electronic device 100 adapted to implement a wireless communication method. The electronic device 100 can be a terminal-type electronic device and / or a card-type electronic device. These two types of devices are described in relation to Figure 2.

[0047] The electronic device 100 includes a processor 101 (CPU) adapted to implement various processing of data stored in memories and / or provided by other circuits of the device 100. According to one embodiment, the processor 101 is adapted to implement a wireless communication method.

[0048] The electronic device 100 further comprises various types of memory 102 (MEM), including, for example, registers, non-volatile memory, volatile memory, and / or read-only memory. Each memory 102 is adapted to store different types of data or information. By way of example, some of these memories are adapted to retain data or information even when the component is no longer powered.

[0049] The electronic device 100 further comprises, for example, a secure element 103 (SE) adapted to process sensitive and / or confidential data. The secure element 103 may include its own processor(s), its own memory(ies), etc. In one embodiment, the secure element 101 may be adapted to implement a wireless communication method. Moreover, in one example, the electronic device 100 may itself be a secure element.

[0050] The electronic device 100 may further include interface circuits 104 (IN / OUT) adapted to send and / or receive data from outside the device 100. The interface circuits 104 may further be adapted to implement a data display, for example, a display screen.

[0051] According to one embodiment, the interface circuits 104 may include a specific circuit adapted to implement wireless communication. By example, such a specific circuit may be a controller or a microcontroller.

[0052] The electronic device 100 further comprises various circuits 105 (FCT1) and 106 (FCT2) adapted to perform different functions. By way of example, circuits 105 and 106 may include measurement circuits, data conversion circuits, etc. In one embodiment, circuits 105 and 106 may include a circuit adapted to implement a wireless communication method.

[0053] The electronic device 100 further includes one or more data buses 107 adapted to transfer data between its different components.

[0054] According to a particular example, the electronic device 100 is adapted to implement computer programs, and in particular a computer program enabling the implementation of a wireless communication process, for example a computer program enabling the implementation of a wireless communication process on the terminal side and / or on the card side.

[0055] More specifically, the electronic device 100 is adapted to implement at least one computer program product comprising program code instructions recorded on a medium usable in a computer, comprising computer-readable programming means for implementing the wireless communication process as a terminal device and / or as a card device when said program is running on a computer.

[0056] Fig. 2 illustrates, very schematically and in block form, a wireless 200 and contactless communication between an electronic device 201 (TERM) serving as a terminal which can be mobile, or mobile terminal 201, and an electronic device 202 (CARD) serving as a remote module, or remote module, also called card module 202.

[0057] For example, device 202 may be a smart device such as a phone, tablet, watch, or ring. For example, the device 202 hosts one or more digital cards (payment card, transport or other contactless service).

[0058] According to one embodiment, the wireless and contactless communication referred to herein uses, for its implementation, a near-field communication technology, hereinafter referred to as NFC communication. Near-field communication (NFC) technologies enable high-frequency, short-range communication. Such systems exploit a radio-frequency electromagnetic field emitted by a device (terminal or reader) to communicate with another device (remote module, transponder, or card).

[0059] Such wireless communication can enable the implementation of a wireless transaction, or NFC transaction. Here, a transaction is defined as a specific type of communication whose purpose is a commercial, monetary, loyalty, and / or authorization operation, in which one device, terminal 201, is the "payment" or "control" terminal that implements the transaction, and the other device, remote module 202, is the one that accepts or rejects the transaction. An example of a transaction relevant to the embodiments described below is a bank transaction. Another example is the purchase of a transportation ticket. Yet another example is the use of a card, or a smartphone emulating a card, to access a motor vehicle such as a car. Other types of transactions are conceivable, and the two examples mentioned above are not exhaustive.The NFC transaction in question here is specifically one in which the two devices exchange sensitive and / or secret data, or data enabling authorization or digital authentication.

[0060] We assume here the case of two electronic devices, for example the terminal 201 and the remote module 202, but everything described herein applies more generally to any system in which a transponder detects an electromagnetic field radiated by a reader, terminal, or device. The terminal 201 and the remote module 202 are, for example, electronic devices of the type of device 100 described in relation to [Fig. 1]. In this type of communication, the electronic devices 201 and 202 are positioned within range of each other, that is, at a distance generally less than 10 cm. According to another example, the devices 201 and 202 are in mechanical contact with each other.

[0061] Depending on the application, for NFC communication, one of the devices, the terminal 201, operates in so-called reader mode while the other, the remote module 202, operates in so-called card mode, or the two devices communicate in peer-to-peer (P2P) mode. Each device comprises various electronic circuits 203 (NFC) adapted to transmit, receive, and / or modulate a radio frequency (RF) signal transmitted using an antenna of an oscillating / resonant circuit. The field The radio frequency generated by one of the devices, for example, terminal 201, is received by the other device, for example, remote module 202, which is within range and also has an antenna. When terminal 201 emits an electromagnetic field to initiate communication with remote module 202, this field is received by remote module 202 as soon as it is within range. This field is detected by the circuits 203 of remote module 202, which, if in standby mode, are reactivated. In some cases, depending on the type of device, the remote device captures the energy from the field (along with the communication data) and uses it to power itself. In this case, a startup of the remote device (202) is necessary. This results in a change in the load exerted by the circuits 203 of remote module 202 on the field-generating resonant circuit of terminal 201.In practice, the corresponding variation in phase or amplitude of the emitted field is detected by terminal 201, which then initiates an NFC communication protocol with the remote module 202. On the terminal 201 side, it detects whether the voltage amplitude across the resonant circuit falls below a threshold or whether the voltage across the resonant circuit exhibits a phase shift greater than a threshold. Once terminal 201 has detected the presence of the remote module 202 within its field, it initiates a communication establishment procedure, implementing request transmissions by terminal 201 and response transmissions by the remote module 202. The request and response transmissions are described in more detail in relation to [Fig. 4].

[0062] Terminal 201 is an electronic device that can be, for example, fixed or mobile. Terminal 201 is responsible for initiating communication. For example, Terminal 201 is an electronic device adapted to implement a transaction application as a transaction terminal, such as a fixed or mobile payment terminal. In another example, Terminal 201 is a mobile phone, for example, a smartphone implementing a point-of-sale (POS) application, that is, an application enabling it to implement a transaction as a payment terminal. In yet another example, Terminal 201 could be a connected device, such as a smartwatch, adapted to implement near-field communication, and more specifically, an NFC transaction.In another example, the terminal can be integrated into a larger object, such as a car, where the antenna is located, for example, near the driver's door handle, allowing it to be opened.

[0063] The remote module 202 is a generally mobile device. According to a preferred embodiment, the remote module 202 is a microcircuit board (or smart card), for example, a bank card or a transit card. According to another preferred example, the remote module 202 could be a mobile phone adapted to to implement an application enabling it to reproduce, simulate, or emulate the behavior of one or more microcircuit boards. The remote module 202 includes various electronic circuits adapted to implement various requests sent by the terminal 201, such as authentication circuits, cryptography circuits, etc.

[0064] In recent systems, the same NFC device can operate in card mode or reader mode (for example, in the case of near-field communication between two mobile phones), and can choose, as appropriate, whether to operate in card mode or reader mode. For example, module 201 could be used as a reader or terminal to implement a payment transaction, and, in another case, be used as a card, for example, to validate a travel ticket.

[0065] According to a particular embodiment, the 200 wireless communication is an NFC communication following the communication protocol defined by the ISO 14443 standard. The key elements of this communication protocol are described in relation to [Fig.4].

[0066] Fig. 3 represents, very schematically, the implementation of a 300 relay attack as a wireless communication of the type of the 200 wireless communication described in relation to Fig. 2.

[0067] During a relay attack, a malicious user aims to retrieve and / or modify data from a wireless communication.

[0068] In [Fig. 3], a wireless communication between a TERM300 terminal device and a remote CARD300 device or CARD300 card device is targeted by a relay attack. To carry out such an attack, a malicious user needs a CARD302 electronic device adapted to replicate the behavior of a card device, i.e., implementing the same functionalities as a card device, and a TERM302 electronic device adapted to replicate the behavior of a terminal device, i.e., implementing the same functionalities as a terminal device. In one embodiment, the CARD302 and TERM302 electronic devices may be a single electronic device.

[0069] The CARD302 device is adapted to communicate with the TERM300 device by implementing NFC communication. The TERM302 device is adapted to communicate with the CARD300 device by implementing NFC communication. Finally, the CARD302 and TERM302 devices are adapted to communicate with each other by implementing wireless communication, for example NFC communication, or any other type of wireless communication, such as wireless communication using a communication protocol defined by the Bluetooth telecommunications standard, a Wi-Fi, 3G, 4G, 5G or later internet protocol.

[0070] When the TERM300 terminal device wishes to initiate NFC communication with the CARD300 card device, the malicious user uses the CARD302 and TERM302 devices to retrieve or modify data exchanged during the communication. To do this, the CARD302 device impersonates a conventional card device, retrieves the data provided by the TERM300 terminal device, and then transfers it to the TERM302 device, which then transmits it to the CARD300 device. The CARD302 and TERM302 devices have thus retrieved the data sent by the TERM300 terminal device. Similarly, the CARD302 and TERM302 devices can subsequently (or in parallel) retrieve the data sent by the CARD300 card device. According to one variant, the CARD302 and TERM302 devices can also modify the data exchanged by the TERM300 and CARD300 devices.As an example, the two devices can adapt a low-level communication software layer to enable virtually transparent communication between the TERM300 terminal device and the CARD300 card device. The objective of this attack is to trick the TERM300 terminal device into believing that it is interacting with the CARD300 card device. The authorization that is implemented is indeed an authorization that only concerns the TERM300 and CARD300 devices, without the owner of the CARD300 card device having given their consent.

[0071] A weakness of such a relay attack is that the overall communication time is greatly increased. This weakness is exploited by the embodiment described in relation to [Fig. 4].

[0072] Fig. 4 is a block diagram illustrating an implementation method of a 400 wireless communication method, and more particularly an NFC communication, allowing protection against a relay-type attack described in relation to Fig. 3.

[0073] According to a preferred embodiment, the NFC communication implemented here follows the communication protocol defined by ISO 14443. This standard specifies a number of parameters. These parameters are explained in detail below. The terminal device TERM can be called a Proximity Coupling Device (PCD). The card device CARD can be called a Proximity Card Object (PICC).

[0074] According to one embodiment, the NFC communication implemented does not follow the communication protocol defined by ISO 14443, but follows other communication protocols. A person skilled in the art can adapt the following explanations to other communication protocols.

[0075] At initial and optional steps 401 (ANTICOLL) and 402, implemented by the terminal device TERM and by the card device CARD, NFC communication is initiated by an anti-collision mechanism. An anti-collision mechanism allows the terminal device to know precisely how many card devices are within its range and to learn to differentiate them, for example, by requesting information characterizing some of their features, such as their identifiers. Similarly, such a mechanism can allow a card device to know how many terminal devices are nearby. Thus, during steps 401 and 402, the TERM and CARD devices can exchange data. For example, the TERM device provides the CARD device with TERMInfo data indicating its characteristics. For example, the CARD device provides the TERM device with CARDInfo data indicating its characteristics.

[0076] Such a mechanism can eliminate devices that are not capable of implementing the subsequent NFC communication. For example, such a mechanism can prevent a bank transaction from being initiated with a transit card.

[0077] In the case where the NFC communication implemented here follows the ISO 14443 standard, the anti-collision mechanism can be a protocol enabling communication by application, such as that detailed by the ISO 14443-3 standard.

[0078] In an optional step 403 (Cl), implemented by the terminal device TERM, following steps 401 and 402, the TERM device sends an S-Block(Ready) request to the CARD device. This first request allows the TERM device to request the attention of the CARD device.

[0079] In the case where the NFC communication implemented here follows the ISO 14443 standard, the formats of the requests and data exchanged by the TERM and CARD devices are defined by the ISO 14443-4 standard. At least three types of data and request formats are defined by this standard. The first format is called I-Block; it is defined as an application radio frequency frame having an information block carrying a block of information. The second format is called R-Block; it is defined as an application radio frequency frame having a Receive Ready block carrying an acknowledgment, or a non-acknowledgment, concerning the last application radio frequency frame received.A third format is called S-Block. It is defined as an application radio frequency frame containing a supervisory block carrying control information for the exchange between communicating devices. S-Block data and requests may include a field called S(PARAMETERS) containing additional information. The content of this S(PARAMETERS) field conforms to the coding rules known as BER-TLV (Basic Encoding Rules - Tag Length Value). in accordance with ISO / IEC 7816-4:2013, Annex E. The tag field indicates a context-specific class. The data word length field must be encoded in short form.

[0080] Furthermore, still assuming that the NFC communication implemented here follows the ISO 14443 standard, the S-Block(Ready) request is an S-Block format request of type Cl as defined by the ISO 14443 standard.

[0081] In an optional step 404 (C2), implemented by the CARD device, following step 403, the CARD device responds to the S-Block(Ready) request from the TERM device with an S-Block(OK) request. This request allows the CARD device to indicate to the TERM device that it is ready to proceed with the rest of the NFC communication.

[0082] In the case where the NFC communication implemented here follows the ISO 14443 standard, the S-Block(OK) request is an S-Block format request of type C2 defined by the ISO 14443 standard.

[0083] At a step 405 (C4), implemented by the terminal device TERM, following step 404, the TERM device sends an S-Block(PTime, NONCE_R) request to the CARD device. In one embodiment, this S-Block(PTime, NONCE_R) request includes a NONCE_R data point generated by the TERM device. In one example, the NONCE_R data point is random data.

[0084] In one embodiment, in step 405, the TERM device starts a time calculation means, such as a counter, enabling it to check the response time of the CARD device to the S-Block(PTime, NONCE_R) request. The CARD device's response time is checked in a subsequent step against a reference response time PTime. For example, the reference response time PTime can be a minimum response time, a maximum response time, or a range of response times bounded by a minimum and a maximum response time. In one embodiment, the reference response time PTime is dependent on the ongoing NFC communication and the S-Block(PTime, NONCE_R) request.According to a particular embodiment, when an anti-collision mechanism is implemented, i.e., when steps 401 and 402 are implemented, the reference time PTime can depend on the CARDInfo information communicated by the CARD device. According to an optional embodiment, the TERM device can transmit in the S-Block(PTime, NONCE_R) request the reference response time PTime envisaged by the TERM device.

[0085] In the case where the NFC communication implemented here follows the ISO 14443 standard, the S-Block(PTime, NONCE_R) request is an S-Block format request of type C4 defined by the ISO 14443 standard.

[0086] According to one embodiment, when steps 403 and 404 have taken place before step 405, step 405 directly follows step 405, without any further exchange of data between the TERM and CARD devices.

[0087] At step 406 (C5), implemented by the CARD device, following step 405, the CARD device responds to the S-Block(PTime, NONCE_R) request from the TERM device with an S-Block(OK, NONCE_C, NONCE_R_C) request. According to one embodiment, this S-Block(OK, NONCE_C, NONCE_R_C) request comprises: - a confirmation OK data point; - a NONCE_C data generated by the CARD device, which is, for example, a random data like the NONCE_R data from step 403; - a NONCE_R_C data generated by the CARD device, which is, for example, a combination of the NONCE_R and NONCE_C data.

[0088] According to one example, the NONCE_R_C data can be obtained by applying an XOR (exclusive OR) logical function to the NONCE_R and NONCE_C data. According to another variant, the NONCE_C data can represent the time the card device used to process the command and respond to the terminal device. In this alternative, the NONCE_C data can subsequently be signed using a response data from the card device. This allows the application to verify the processing time used and reported by the card.

[0089] For example, the NONCE_R_C data can subsequently be considered as trusted data for implementing cryptographic processes, such as authentication or encryption processes. For example, this NONCE_R_C data will no longer need to be transferred in commands during authentication or authorization, but the TERM and CARD devices will need to use the data generated during this step.

[0090] In the case where the NFC communication implemented here follows the ISO 14443 standard, the S-Block(OK) request is an S-Block format request of type C5 defined by the ISO 14443 standard.

[0091] At step 407 (VERIF), implemented by the terminal device TERM, following step 406, upon receipt of the S-Block(OK, NONCE_C, NONCE_R_C) request, the TERM device stops its time calculation means, for example its counter, and then sets the response time of the CARD device. The TERM device then verifies the response time of the CARD device by comparing it to the reference response time PTime.

[0092] If the CARD device meets the reference response time PTime, then it is considered reliable by the TERM device; otherwise, it is not. In other words, if the CARD device is considered reliable, this means that it is not intercepted. by malicious devices such as the TERM302 and CARD302 devices described in relation to [Fig.3].

[0093] According to an example, the mechanism described above is integrated via commands (s-Block) at the protocol level of the ISO / OSI model.

[0094] If the CARD device is deemed reliable, NFC communication continues. The NONCE_R_C data can be used in subsequent NFC communications.

[0095] By way of example, the NONCE_R_C data can also be used during cryptographic authentication or authorization. If the protocol layer (as defined in the ISO / OSI communication model) has its own cryptographic key system, the signing can take place at that level. Otherwise, the cryptographic verification can take place in the so-called application layer of the ISO / OSI communication model.

[0096] According to another example, it may be recommended to use the NONCE_R_C data in a calculation for authorization or authentication using the values ​​transmitted by the two devices during steps 405 and 406. If the CARD device is not considered reliable, the TERM device may interrupt the NFC communication, or transmit this information to other software layers so that they take it into account for the continuation of the NFC communication.

[0097] According to one variant, the mechanism described herein can be a means of testing the reliability of the CARD device. Other means can be implemented subsequently.

[0098] Various embodiments and variations have been described. A person skilled in the art will understand that certain features of these various embodiments and variations could be combined, and other variations will become apparent to a person skilled in the art.

[0099] Finally, the practical implementation of the embodiments and variants described is within the reach of a person skilled in the art, based on the functional indications given above.

Claims

Demands

1. Method (400) of wireless communication between a first device (201; TERM300; TERM) and a second device (202; CARD300; CARD) comprising the following successive steps: - sending, by the first device (201; TERM300; TERM), to the second device (202; CARD300; CARD) a first request (S-Block(Ptime, NONCE_R)); - respond, by the second device (202 ; CARD300 ; CARD), to the first device (201 ; TERM300 ; TERM) with a first response (S-Block(OK, NONCE_R, NONCE_R_Q) ; and - check, by the first device (201 ; TERM300 ; TERM), the response time of the second device (202 ; CARD300 ; CARD) using a reference time (PTime) which depends on the first request (S-Block(Ptime, NONCE_R)).

2. Method according to claim 1, wherein said reference time (PTime) depends on characteristics of said second device (202; CARD300; CARD).

3. A method according to claim 2, wherein said second device (202; CARD300; CARD) sends its characteristics to said first device (201; TERM300; TERM) during the implementation of an anti-collision mechanism prior to sending said first request (S-Block(Ptime, NONCE_R)).

4. A method according to any one of claims 1 to 3, wherein said first query (S-Block(Ptime, NONCE_R)) includes the value of said reference time (PTime).

5. A method according to any one of claims 1 to 4, wherein said first query (S-Block(Ptime, NONCE_R)) includes the value of a first data (NONCE_R).

6. Method according to claim 5, wherein said first response (S-Block(OK, NONCE_R, NONCE_R_C)) comprises the value of a second data point (NONCE_C), and the value of a third data point (NONCE_R_C) which is dependent on said first and second data points (NONCE_R, NONCE_C).

7. Method according to claim 6, wherein said third data (NONCE_R_C) can be used to implement an authentication operation.

8. A method according to any one of claims 1 to 7, wherein the sending of the first request (S-Block(Ptime, NONCE_R)) is preceded by: - ​​the sending, by said first device (201; TERM300; TERM), of a second request (S-Block(Ready)) to said second device (202; CARD300; CARD); - the sending, by said second device (202; CARD300; CARD), of a second response (S-Block(OK)) to said first device (201; TERM300; TERM).

9. A method according to any one of claims 1 to 8, wherein the communication is near field communication (NFC).

10. A method according to claim 9, wherein the communication is a near field communication (NFC) using the communication protocol defined by ISO 14443.

11. A method according to claim 10, wherein the first query (S-Block(Ptime, NONCE_R)) is a C4 type query from ISO 14443.

12. Method according to claim 10 or 11, wherein the first response (S-Block(OK, NONCE_R, NONCE_R_C)) is a C5 type response from ISO 14443.

13. Product computer program comprising program code instructions recorded on a medium usable in a computer, comprising computer-readable programming means for implementing said method according to any one of claims 1 to 12.

14. Method of establishing wireless communication by a first wireless communication device comprising the following steps: - send a first request (S-Block(Pthne, NONCE_R)); - receive a first response (S-Block(OK, NONCE_R, NONCE_R_C)); - check the response time using a reference time (PTime) which depends on the first request (S-Block(Pthne, NONCE-R)).

15. Method of establishing wireless communication by a second wireless communication device comprising the following steps: - receive a first request (S-Block(Ptime, NONCE_R)); - send a first response (S-Block(OK, NONCE_R, NONCE_R_Q), - in which a response time depends on a reference time, itself dependent on characteristics of said second device.

16. Device adapted to be the first device (201; TERM300; TERM) in a wireless communication method between said first device (201; TERM300; TERM) and a second device (202; CARD300; CARD) comprising the following successive steps: - sending, by the first device (201; TERM300; TERM), to the second device (202; CARD300; CARD) a first request (S-Block(Ptime, N0NCE_R)); - respond, by the second device (202 ; CARD300 ; CARD), to the first device (201 ; TERM300 ; TERM) with a first response (S-Block(OK, N0NCE_R, N0NCE_R_Q); and - check, by the first device (201 ; TERM300 ; TERM), the response time of the second device (202 ; CARD300 ; CARD) using a reference time (PTime) which depends on the first request (S-Block(Ptime, N0NCE_R)).

17. Device adapted to be the second device (202; CARD300; CARD) in a wireless communication method between a first device (201; TERM300; TERM) and said second device (202; CARD300; CARD) comprising the following successive steps: - sending, by the first device (201; TERM300; TERM), to the second device (202; CARD300; CARD) a first request (S-Block(Ptime, N0NCE_R)); - respond, by the second device (202 ; CARD300 ; CARD), to the first device (201 ; TERM300 ; TERM) with a first response (S-Block(OK, N0NCE_R, N0NCE_R_Q); and - check, by the first device (201 ; TERM300 ; TERM), the response time of the second device (202 ; CARD300 ; CARD) using a reference time (PTime) which depends on the first request (S-Block(Ptime, N0NCE_R)).

18. Wireless communication device, adapted to constitute a first device comprising a microcontroller configured to implement the following steps: - send a first request (S-Block(Ptime, N0NCE_R)); - receive a first response (S-Block(OK, NONCE_R, NONCE_R_Q); - check the response time using a reference time (PTime) which depends on the first request (S-Block(Ptime, NONCE-R)).

19. Wireless communication device, adapted to constitute a second device comprising a microcontroller configured to implement the following steps: - receive a first request (S-Block(Ptime, NONCE_R)); - send a first response (S-Block(OK, NONCE_R, NONCE_R_C)), - wherein a response time depends on a reference time, itself dependent on characteristics of said second device.

Images