Protection of a communication

Abstract

The present description relates to a method (400) for wireless communication between a first device (TERM) and a second device (CARD), comprising the following successive steps: - the first device (TERM) sending a first request (S-Block (Ptime, NONCE_R)) to the second device (CARD); - the second device (CARD) responding to the first device (TERM) with a first response (S-Block (OK, NONCE_R, NONCE_R_C)); and - the first device (TERM) verifying the response time of the second device (CARD) using a reference time that is dependent on the first request (S-Block (Ptime, NONCE_R)).

Description

DESCRIPTION TITLE: Protecting a Communication

[0001] This description is based on European patent application no. 24315376.4 filed on August 2, 2024 and on French patent application no. 2410117 filed on September 23, 2024, entitled "protection of a communication", the contents of which are incorporated by reference within the limits authorized by law. technical field

[0002] This description generally concerns electronic systems and devices, and the means of communication between these 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 communications against malicious attacks. Previous technique

[0003] More and more transactions are being conducted via wireless communications, such as those using near-field communication (NFC) technology. These wireless communications can be vulnerable to various types of malicious attacks, allowing, for example, the retrieval of confidential data.

[0004] 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

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

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

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

[0008] There is a need for such secure communication methods against malicious attacks such as relay attacks.

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

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

[0011] 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.

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

[0013] 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.

[0014] One embodiment provides a method for establishing wireless communication via a first wireless communication device comprising the following steps: - send an initial request; - to receive an initial response; and - check the response time using a reference time that depends on the first request.

[0015] One embodiment provides a method for establishing wireless communication via a second wireless communication device, comprising the following steps: - receive an initial request; - send a first response, in which a response time depends on a reference time, itself dependent on characteristics of said second device.

[0016] One embodiment provides a device adapted to be the first device in a wireless communication process 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.

[0017] One embodiment provides a device adapted to be the second device in a communication process wireless connection 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.

[0018] One embodiment provides for a wireless communication device, adapted to constitute a first device, comprising a microcontroller configured to implement the following steps: send a first request; receive a first response; check the response time using a reference time that depends on the first request.

[0019] One embodiment provides for a wireless communication device, adapted to constitute a second device, comprising a microcontroller configured to implement the following steps: receive a first request; send a first response, in which a response time depends on a reference time, itself dependent on characteristics of said second device.

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

[0021] 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.

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

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

[0024] 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.

[0025] According to one embodiment, said third data can be used in the implementation of an authentication operation.

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

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

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

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

[0030] According to one embodiment, the first answer is a type 05 answer from ISO 14443.

[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 process described previously being said first device when said program runs on a computer.

[0032] 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 process described above, being said second device when said program is running on a computer. Brief description of the drawings

[0033] 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 attached figures, among which:

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

[0035] Figure 2 represents a practical example of a communication process;

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

[0037] Figure 4 represents methods of implementing secure communication processes. Description of the implementation methods

[0038] The same elements have been designated by the same reference numerals in the different figures. In particular, 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.

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

[0040] Unless otherwise specified, when referring to two connected elements, this means directly connected without any intermediate elements other than conductors, and when referring to two coupled elements, this means that these two elements can be connected or linked through one or more other elements.

[0041] In the description that follows, when referring to absolute positional qualifiers, such as the terms "front", "back", "top", "bottom", "left", "right", etc., or relative positional qualifiers, such as the terms "above", "below", "superior", "inferior", etc., or to orientational qualifiers, such as the terms "horizontal", "vertical", etc., unless otherwise specified, it refers to the orientation of the figures.

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

[0043] The embodiments described below relate to the protection of wireless communication between two electronic devices, called the terminal device and the card device, against a relay attack. Such an attack is described in detail below with reference to Figure 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.

[0044] The solution provided by the embodiments described below is as follows. The terminal device This 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 terminal device's particular request within the time allotted by the reference time, then the terminal device considers the card device unreliable. Conversely, if the card device responds on time, then it is considered reliable. If the card device does not respond to the terminal device's request, the terminal device will also consider the card device unreliable.

[0045] Furthermore, the embodiments described below are particularly well-suited for use in wireless communications such as Near Field Communication (NFC), and are even more specifically 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, and also defines the format of the data exchanged during such communication. Indeed, from the perspective of the integrity of the information exchanged in such communication, distance typically alters the wave; due to interference or excessive distance, a bit could be misinterpreted. Such communication is described in relation to Figures 2 and 4.

[0046] Furthermore, the embodiments described above are particularly well-suited for use in any type of industrial market where wireless communication is required. More specifically, such a method of Wireless communication can be used in: the automotive industry, for example in the field of automotive electrification or in the field of Advanced Driver Assistance Systems (ADAS); the industrial sector, 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.

[0047] Figure 1 is a block diagram schematically representing the architecture of an example of an electronic device 100 adapted to implement a wireless communication process. 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.

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

[0049] 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. For example, some of these memories are adapted to retain data or information even when the component is no longer powered.

[0050] The electronic device 100 further includes, for example, a secure element 103 (SE) adapted to handle 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.

[0051] 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.

[0052] According to one embodiment, the interface circuits 104 may include a specific circuit adapted to implement wireless communication. For example, a Such a specific circuit can be a controller or a microcontroller.

[0053] The electronic device 100 further comprises various circuits 105 (FCT1) and 106 (FCT2) adapted to perform different functions. For 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.

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

[0055] 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.

[0056] 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, including 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.

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

[0058] For example, device 202 could be a smart device such as a phone, tablet, watch, or ring. Another example is that device 202 could host one or more digital cards (payment card, transit card, or other contactless service card).

[0059] In one embodiment, the wireless and contactless communication described herein uses near-field communication (NFC) technology for its implementation. 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).

[0060] 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 this transaction, 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 covered by 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 include: These are all 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 digital authorization or authentication.

[0061] We will consider here the case of two electronic devices, for example, terminal 201 and remote module 202, but everything described here applies more generally to any system in which a transponder detects an electromagnetic field radiated by a reader, terminal, or other device. Terminal 201 and remote module 202 are, for example, electronic devices of the type described in Figure 1 (device 100). In this type of communication, electronic devices 201 and 202 are positioned within range of each other, that is, at a distance generally less than 10 cm. Alternatively, devices 201 and 202 may be in mechanical contact with each other.

[0062] Depending on the application, for NFC communication, one of the devices, the terminal 201, operates in reader mode while the other, the remote module 202, operates in card mode, or the two devices communicate in peer-to-peer (P2P) mode. Each device includes 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 radio frequency field generated by one of the devices, for example, the terminal 201, is picked up by the other device, for example, the remote module 202, which is within range and also has an antenna. When the terminal 201 emits an electromagnetic field to initiate communication with the remote module 202, this field is The field is captured by the remote module 202 as soon as it comes within range. This field is detected by the circuits 203 of the remote module 202, which are reactivated if they are in standby mode. 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 the remote module 202 on the field-generating resonant circuit of the terminal 201. In practice, the corresponding change in phase or amplitude of the emitted field is detected by the terminal 201, which then initiates a NEC communication protocol with the remote module 202.On the terminal 201 side, it is detected whether the voltage amplitude across the resonant circuit falls below a threshold or whether the voltage across the resonant circuit has 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 from terminal 201 and response transmissions from remote module 202. The request and response transmissions are described in more detail in relation to Figure 4.

[0063] Terminal 201 is an electronic device that can be, for example, fixed or mobile. It is Terminal 201 that initiates 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 (DoS) application, that is, an application enabling it to process a transaction. as a payment terminal. In another example, the 201 terminal could be a connected device, such as a smartwatch, adapted to implement near-field communication, and more specifically, NFC transactions. In yet 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 the door to be opened.

[0064] The remote module 202 is a device that is generally mobile. In one preferred embodiment, the remote module 202 is a microcircuit board (or smart card), for example, a bank card or a transit card. In another preferred example, the remote module 202 could be a mobile phone adapted 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.

[0065] In modern systems, a single 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, depending on the situation, whether to function in card mode or reader mode. For example, module 201 could be used as a reader or terminal to process a payment transaction, and, in another case, be used as a card, for example, to validate a transit pass.

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

[0067] Figure 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 Figure 2.

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

[0069] In Figure 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 mimic the behavior of a card device, i.e., implementing the same functionalities as a card device, and a TERM302 electronic device adapted to mimic 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 can be a single electronic device.

[0070] The CARD302 device is suitable for communicating with the TERM300 device using NEC communication. The TERM302 device is suitable for communicating with the CARD300 device using NEC communication. Finally, the CARD302 and TERM302 devices are suitable for communicating with each other using wireless communication, such as NEC 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.

[0071] When the TERM300 terminal device attempts to initiate NFC communication with the CARD300 card device, a malicious user exploits the CARD302 and TERM302 devices to retrieve or modify data exchanged during the communication. To do this, the CARD302 device impersonates a standard card reader, retrieves the data provided by the TERM300 terminal device, and then transfers it to the TERM302 device, which in turn transmits it to the CARD300 device. Thus, the CARD302 and TERM302 devices have retrieved the data sent by the TERM300 terminal device. Similarly, the CARD302 and TERM302 devices can subsequently (or concurrently) retrieve data sent by the CARD300 card device. In 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 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.

[0072] 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 Figure 4.

[0073] Figure 4 is a block diagram illustrating one implementation method of a 400 wireless communication process, and more specifically NEC communication, allowing... protect against a relay attack described in relation to Figure 3.

[0074] In a preferred embodiment, the NFC communication implemented here follows the communication protocol defined by ISO 14443. This standard specifies a number of parameters, which 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).

[0075] According to one embodiment, the NEC communication being implemented does not follow the communication protocol defined by ISO 14443, but rather other communication protocols. A person skilled in the art is capable of adapting the following explanations to other communication protocols.

[0076] At initial and optional steps 401 (ANTICOLL) and 402, implemented by the TERM terminal device and the CARD card device, NEC communication is initiated by an anti-collision procedure, or 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 these steps 401 and 402, the TERM and CARD devices can exchange data. In one example, the TERM device provides the CARD device with TERMInfo data indicating its characteristics. In another For example, the GARD device provides the TERM device with CARDInfo data indicating its characteristics.

[0077] Such a mechanism can eliminate devices that are unable to implement the subsequent NEC communication. For example, such a mechanism can prevent initiating a bank transaction using a transit card.

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

[0079] 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 GARD device.

[0080] In the case where the NEC communication implemented here follows the ISO 14443 standard, the formats of the requests and data exchanged by the TERM and GARD 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, defined as an application radio frequency frame with an information block carrying a block of information. The second format is called R-Block, defined as an application radio frequency frame with a Receive Ready block carrying an acknowledgment, or a non-acknowledgment, regarding the last application radio frequency frame received. The third format is called S-Block, defined as an application radio frequency frame with a supervisory block carrying control information for the exchange between the devices. Communication. S-Block format data and queries 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) according to 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.

[0081] Furthermore, assuming that the NEC 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.

[0082] In an optional 404 (C2) step, implemented by the CARD device, following step 403, the CARD device responds to the TERM device's S-Block (Ready) request 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 next stage of the NEC communication.

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

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

[0085] In one embodiment, at step 405, the TERM device starts a time calculation means, such as a counter, enabling it to check the response time of the GARD device to the S-Block request (PTime, NONCE_R). The GARD device's response time is checked in a subsequent step against a reference response time PTime. For example, the reference response time PTime could 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 NEC communication and the S-Block request (PTime, NONCE_R).In one particular embodiment, when an anti-collision procedure or mechanism is implemented—that is, when steps 401 and 402 are implemented—the reference time PTime can depend on the CARDInfo information communicated by the GARD device. In an optional embodiment, the TERM device can transmit the reference response time PTime of the GARD device considered by the TERM device in the S-Block request (PTime, NONCE_R).

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

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

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

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

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

[0091] In the case where the NEC 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.

[0092] According to one embodiment, the TERM device may not send the NONCE_R data and only the NONCE_C data may be used in the subsequent steps of the 400 communication.

[0093] At step 407 (VERIF), implemented by the terminal device TERM, following step 406, upon receiving the S-Block(OK, NONCE_C, NONCE_R_C) request, the TERM stops its time calculation means, for example, its counter, and then sets the response time of the GARD device. The TERM then verifies the GARD device's response time by comparing it to the reference response time PTime. In one embodiment, the GARD device's response time can be measured by the GARD device itself and sent to the TERM device during step 406.

[0094] If the GARD 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 GARD device is considered reliable, it means that it is not intercepted by malicious devices such as the TERM302 and CARD302 devices described in relation to Figure 3.

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

[0096] If the GARD device is deemed reliable, the NEC communication continues. The NONCE_R_C data can then be used in subsequent NEC communications.

[0097] As an 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 If the system uses its own cryptographic key system, the signature can take place at this level. Otherwise, cryptographic verification can take place in the so-called application layer of the ISO / OSI communication model.

[0098] 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 GARD device is not considered reliable, the TERM device can interrupt the NEC communication, or transmit this information to other software layers so that they can take it into account for the rest of the NEC communication.

[0099] According to one variation, the mechanism described here can be a way to test the reliability of the GARD device. Other methods can be implemented subsequently.

[0100] One advantage of implementing a card device response time verification mechanism after an anti-collision procedure is that it allows this response time verification to be performed as many times as necessary during the communication. Another advantage of verifying the card device response time after an anti-collision procedure is that it allows for repeated response time checks during subsequent communications.

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

[0102] Finally, the practical implementation of the described methods and variants is within the reach of the person in the trade, 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, after implementation of an anti-collision procedure, 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)); responding, 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_C)); and verify, by the first device (201; TERM300; TERM), the response time of the second device (202; CARD300; CARD) using a reference time (PTime).

2. Method of establishing wireless communication by a first wireless communication device comprising, after implementation of an anti-collision procedure, 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).

3. A method for establishing wireless communication by a second wireless communication device comprising, after implementation of an anti-collision procedure, the following steps: receiving a first request (S-Block (Ptime, NONCE_R)); sending a first response (S-Block (OK, NONCE_R, NONCE_R_C)). in which a response time depends on a reference time (PTime).

4. 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; GARD) comprising, after implementation of an anti-collision procedure, the following successive steps: sending, by the first device (201; TERM300; TERM), to the second device (202; CARD300; GARD) a first request (S-Block (Ptime, NONCE_R)); responding, by the second device (202; CARD300; GARD), to the first device (201; TERM300; TERM) with a first response (S-Block(OK, NONCE_R, NONCE_R_C)); and verify, by the first device (201; TERM300; TERM), the response time of the second device (202; CARD300; GARD) using a reference time (PTime).

5. Device adapted to be the second device (202; CARD300; GARD) in a wireless communication method between a first device (201; TERM300; TERM) and said second device (202; CARD300; GARD) comprising, after implementation of an anti-collision procedure, the following successive steps: sending, by the first device (201; TERM300; TERM), to the second device (202; CARD300; GARD) a first request (S-Block (Ptime, NONCE_R)); responding, by the second device (202; CARD300; GARD), to the first device (201; TERM300; TERM) with a first response (S-Block (OK, NONCE_R, NONCE_R_C)); and verify, by the first device (201; TERM300; TERM), the response time of the second device (202; CARD300; GARD) using a reference time (PTime).

6. Wireless communication device, adapted to constitute a first device comprising a microcontroller configured to implement, after implementation of an anti-collision procedure, 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).

7. Wireless communication device, adapted to constitute a second device comprising a microcontroller configured to implement, after implementation of an anti-collision procedure, 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 (PTime).

8. A method according to any one of claims 1 to 3, or a device according to any one of claims 4 to 7, wherein said reference time (PTime) depends on characteristics of said second device (202; CARD300 ; GARD) .

9. Method or device according to claim 8, wherein said second device (202; CARD300; GARD) sends its characteristics to said first device (201; TERM300; TERM) during the implementation of an anti-collision mechanism prior to the sending of said first request (S-Block (Ptime, NONCE_R) ).

10. Method according to any one of claims 1, 3, 8 or 9, or device according to any one of claims 4 to 9, wherein said first request (S-Block (Ptime, NONCE_R) ) comprises the value of a first data (NONCE_R).

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

12. Method or device according to claim 11, wherein said third data (NONCE_R_C) is used for the implementation of an authentication operation.

13. A method according to any one of claims 1 to 3, 8 to 12, or a device according to any one of claims 4 to 12, 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; GARD); the sending, by said second device (202; CARD300 ; GARD) , of a second response (S-Block (OK) ) said first device (201 ; TERM300 ; TERM) .

14. A method according to any one of claims 1 to 3, 8 to 13, or device according to any one of claims 4 to 13, wherein the communication is a near field communication (NFC).

15. A method or device according to claim 14, wherein the communication is field communication close (NFC) using the communication protocol set by the ISO 14443 standard.

16. 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 3, 8 to 15.

Images