Securing the transmission of a data frame between an electronic device associated with a tire and a remote receiver unit

Abstract

Method for transmitting a frame (40) from a device (20) associated with a tire (11) to a remote receiver unit (30), comprising: the device (20) encrypting a segment (4002) of the frame; determining (S13) a symmetric key (K) associated with a key identifier (ID) determined (S12) from an identifier of the device (20); and applying (S15) the symmetric key to the segment (4002) in order to encrypt content, and associated reception method.

Description

DESCRIPTION Securing the transmission of a data frame between an electronic device associated with a pneumatic system and a remote receiving device TECHNICAL FIELD

[0001] This description relates to the transmission of measurement data between a device associated with a mounted assembly comprising a tire and a wheel, and a remote receiving device. It applies particularly to devices incorporating sensors, such as temperature and pressure sensors, that measure the condition of the tire.

[0002] It is already known that vehicles have sensors on their tires, such as TPMS (Tire Pressure Monitoring System) devices, which monitor tire pressure. These systems use sensors installed inside or outside the tires to measure pressure; these measurements are then transmitted wirelessly to an electronic component of the vehicle to warn the driver in case of a pressure problem.

[0003] More recently, more complex systems have emerged for tire management, the TMS (Tire Mounted System) systems which aim to multiply the sensors and provide advanced functionalities through the measured data.

[0004] Although the information transmitted by electronic devices is technical in nature, it can present a risk to the confidentiality and respect of personal data.

[0005] Indeed, by capturing the data transmitted by such an electronic device over time, for example using a mobile phone, its position can be tracked in time and space. By linking this data to the vehicle, the vehicle's and its driver's movements can be traced. Since this tracking is possible without the knowledge of the driver or owner of the vehicle, the situation presents a risk to them.

[0006] Therefore, there is a need to improve current state-of-the-art proposals. DESCRIPTION OF THE INVENTION

[0007] The invention aims to improve upon the state of the art. In particular, it proposes to implement encryption to secure, at least partially, the content of a frame. One of the goals is to prevent the device from being traced by a third party other than the intended remote receiving device.

[0008] To achieve this, a method is proposed for transmitting a frame by a device associated with a pneumatic tube to a remote receiving organ, comprising encrypting a segment of said frame by said device, determining a symmetric key associated with a key identifier determined from an identifier of said device, and applying said symmetric key to said segment to encrypt content.

[0009] According to another aspect, a method is also proposed for receiving a frame by a remote receiving organ emitted by a device associated with a pneumatic tube, comprising decrypting a segment of said frame including determining a key identifier from a first field of said frame, querying a remote server to retrieve a symmetric key associated with said key identifier, and applying said symmetric key to a segment of said frame to determine a content.

[0010] According to preferred embodiments, the invention comprises one or more of the following features which may be used separately or in partial combination with each other or in total combination with each other: said identifier is formed from a set of bits of a value determined from the first field, said set of bits being an ordered and predetermined selection of bits of said value; said identifier is determined by applying at least one second key to said first field in order to obtain said value; said at least one second key are at least two keys applied successively to at least two blocks of said first field; a portion of the at least two blocks of said first field, for example of Speck or AES type, partially overlap in pairs; said content includes at least one unique identifier of said device; said first field is an identifier of said device chosen from a set of identifiers made available by an identifier server.

[0011] Another object relates to a method of transmitting a frame between a device associated with a pneumatic and a remote receiving organ, comprising a transmission method as previously described implemented by the device and a reception method as previously described implemented by the remote receiving organ.

[0012] Yet another object relates to a device suitable for association with a pneumatic device, comprising circuits for transmitting a frame to a remote receiving organ, said circuits being adapted to perform encryption of a segment of said frame comprising determining a symmetric key associated with a key identifier determined from an identifier of said device, and applying said key to content to encrypt said segment.

[0013] Another object relates to a remote receiving organ comprising circuits for receiving a frame from a device associated with a pneumatic, said circuits being adapted to perform a decryption of a segment of said frame comprising a determination of a key identifier from a first field of said frame, a query of a remote server to retrieve a symmetric key associated with said key identifier and an application of said symmetric key to a segment of said frame to decrypt said content.

[0014] Another aspect concerns a system comprising at least one device associated with a pneumatic system as previously described and / or a remote receiving unit as previously described, as well as the remote server BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Other aspects, objectives, advantages, and features of the invention will become clearer upon reading the following detailed description of preferred embodiments thereof, given by way of non-limiting example, and made with reference to the accompanying drawings in which: Figure 1 represents a context for the implementation of the process and devices described; Figure 2 schematically represents the architecture of a device according to one embodiment; Figure 3 illustrates an example of a frame transmitted between a device and a remote receiving organ, according to embodiments; Figure 4 illustrates an example of the payload of a frame transmitted between a device and a remote receiving organ, according to embodiments; Figure 5 illustrates a method of emitting a frame by a device, according to one embodiment; Figure 6 illustrates the process of receiving a frame by a remote receiving organ, according to one embodiment; Figure 7 illustrates an example of implementing a step to determine an identifier according to one embodiment. DETAILED DESCRIPTION OF SPECIFIC METHODS OF IMPLEMENTATION

[0016] Figure 1 shows a mounted assembly, or wheel, 10 comprising a tire 11 and a rim 12. The wheel is intended to be mounted on a motor vehicle.

[0017] A device 20 is associated with the tire 11, that is, adapted to provide information on the condition of this tire by means of sensors. This device is an electronic device. For example, it could be a TPMS or TMS device, or any other device of the same type with similar functionalities.

[0018] The device 20 can be positioned directly on or within the tire 11. In particular, this device can be positioned and fixed to an inner surface of the tire. The device 20 can also be positioned on the rim 12, or on a valve associated with the tire. Generally, the device 20 is attached to the mounted assembly 10.

[0019] This device is suitable for communicating measurements acquired by the sensors to a remote receiving organ 30.

[0020] This remote receiver 30 can be located within the motor vehicle. For example, it could be one of the circuits that make up the vehicle's instrument panel. It can then be designed to display data from these measurements on an interface of this instrument panel, in the form of numerical values, indicator lights in case of alarms (triggered by exceeding thresholds, for example), etc.

[0021] The remote receiving unit 30 can also be located outside the vehicle. For example, it can be located in a station where the motor vehicle may be parked periodically. This could be a regular parking area for the vehicle, or a maintenance area, for example.

[0022] The measurements can be communicated by transmitting a data frame 40 to this remote receiving device. This frame 40 includes, in particular, representative values ​​of these measurements, adapted for processing by the remote receiving device 30.

[0023] Figure 2 schematically illustrates a possible architecture of such a device 20.

[0024] It includes different circuits allowing it to perform different treatments.

[0025] In this embodiment, sensors 21, 22, and 23 are integrated into the device's structure. Other embodiments may involve sensors located outside the device itself, capable of communicating with it via wired or wireless means, for example, using near-field communication (NFC). This example shows three sensors, but it is obviously possible to use fewer or more.

[0026] The device also includes processing means 24, or electronic circuits, typically comprising a microcontroller, or processor, and a memory 25.

[0027] The device 20 also includes a radio frequency interface 26 adapted for transmitting frames 40 to the remote receiving device 30. This radio interface 26 can conform to different radio communication mechanisms and protocols. It can in particular, be compliant with short-range radio communication protocols such as Wi-Fi or Wi-Fi Direct, Zigbee, Z-Wave, Bluetooth or BLE protocols.

[0028] In cases where the transmission itself needs to minimize the energy consumption of the transmitting device, the BLE protocol can be chosen.

[0029] The Bluetooth Low Energy (BLE) protocol is a version of the Bluetooth protocol designed to provide low-power wireless communications. BLE is standardized in the IEEE 802.15.1 standard and is part of the Bluetooth specifications adopted by the Bluetooth Special Interest Group (Bluetooth SIG).

[0030] The BLE protocol uses 2.4 GHz frequency bands and 40 channels distributed between 2402 and 2480 MHz and with a width of 2 MHz.

[0031] According to this protocol, three advertising channels are defined. These are specific channels used for broadcasting advertising messages or frames, primarily to establish a connection: devices listening on these channels can receive advertisements, allowing a device to initiate a connection. They can also be used to announce a device's presence (discovery mechanism) or for beacon-type signaling. Data is exchanged between participants after a connection is established, in frames transmitted over the other channels.

[0032] Advertisement frames, transmitted through advertising channels, are thus opposed to data frames transmitted through other channels.

[0033] The advertising channels are channels 37 (2402 MHz), 38 (2426 MHz) and 39 (2480 MHz). These three channels are strategically located within the frequency band to minimize interference with other technologies using the same band (such as Wi-Fi, which also operates in the 2.4 GHz band).

[0034] Establishing a connection between two parties in a BLE communication poses an energy consumption problem, particularly due to the synchronizations to be carried out between them and the multiple frequency hops to be made to transmit and listen in the correct channels.

[0035] Also, according to an embodiment based on this BLE protocol, it is chosen not to establish a connection between the device 20 and the remote receiving organ 30. In particular, the frames 40 are transmitted on an advertisement channel.

[0036] The 40 frames are structured according to a communication protocol shared between the device 20 and the remote receiving organ.

[0037] Figure 3 illustrates an example of a frame in the case of an implementation based on the use of the BLE protocol's advertising channels.

[0038] This frame 40 includes a preamble 41 of one byte, an address field 42 of four bytes, a header 43 of two bytes, and a payload 44 (or PDU for Protocol Data Unit). Finally, the frame includes an error correction code (CRC) 45 of three bytes.

[0039] Preamble 41 is a synchronization field used to indicate the start of the frame.

[0040] For advertisement frames, address field 42 is fixed and has the value 0x8E89BED6. For data frames, this address is unique to the current connection between two devices.

[0041] Header 43 indicates the frame type: for example, a "connectionless communication" type for an advertisement frame. For such a frame, it also indicates the length of the payload 44, which can be between 0 and 37 bytes.

[0042] Also, the transmission of the sequence of values ​​is constrained in this payload to a maximum of 37 bytes.

[0043] As illustrated in Figure 4, part of this payload 44 is also used for other information: a device identifier 441 20, an increment indicator 442 and a format indicator 444.

[0044] Also, a 443 field can contain a sequence of values ​​representative of sensor measurements.

[0045] According to one embodiment, the frame may include a second identifier 445 of device 20.

[0046] The order of the fields is illustrative. Other fields may also be included in frame 40.

[0047] The first identifier 441 is a unique identifier, meaning it allows the device 20 to be identified unambiguously. For example, it could be a unique MAC address (for "Media Access Control") assigned uniquely by the manufacturer of the device 20. This identifier could then consist of a first 24-bit part identifying the manufacturer (OUI for "Organizationally Unique Identifier") and a second 24-bit part identifying the device 20 among the manufacturer's various products.

[0048] This unique identifier 441 is generally fixed "hard-set" within the device 20 by the manufacturer itself, according to a process guaranteeing the uniqueness of the identifier 441.

[0049] The second identifier 445 is a device identifier that is chosen from a set of identifiers made available by an identifier server.

[0050] It can indeed be envisaged that a remote server will provide a list of identifiers (of the MAC type, for example), corresponding to the OUI of the device manufacturer 20 and differing only by the second part of the identifier, which is 3 bytes long. Each device can be assigned such an identifier upon its first startup, but since the list is limited, uniqueness is not necessarily guaranteed. If applicable, this identifier 445 would allow a receiving device 30 to track the different frames of the same device 20, given that the probability of this same receiving device being simultaneously in contact with several devices 20 bearing the same second identifier 445 is low.

[0051] However, for several applications, the unique identifier 441 is preferable. In particular, when data is shared on a centralized platform in contact with a large number of remote receiving organs, and therefore indirectly with devices 20, it can be important, even crucial, to uniquely identify these devices, and thus to rely on the unique identifier 441.

[0052] However, as previously mentioned, the presence of a unique identifier could allow a third party to trace the device's movements. This would simply require receiving the 40 frames and retrieving the unique identifier to, by aggregating the received data over time, reconstruct the device's route 20, or at least determine its presence at a specific location on a specific date.

[0053] If this third party is not approved by the owner and / or driver of the vehicle, problematic situations can clearly result.

[0054] In other words, it is necessary to ensure that only the remote receiving organ 30 is able to access certain parts of the content of the frame 40 and in particular to uniquely identify the transmitting device 20.

[0055] Also, the proposed process includes encryption of a segment of the frame by device 20 and decryption of this segment by the receiving organ 30. Thus, only device 20 and the receiving organ 30 will know the shared secret corresponding to this encrypted segment.

[0056] According to one embodiment, the encrypted segment includes the unique identifier 441 of device 20.

[0057] The encrypted segment may also include other fields from frame 40, such as the increment indicator 442, the format indicator 444 or the sequence of values ​​443 representing sensor measurements.

[0058] It may be desirable to encrypt certain fields for various reasons, but in particular because some, alone or in combination, could allow identification of device 20 (with possibly a margin of error).

[0059] Figure 5 illustrates a method of transmitting a frame 40 by a device 20 implementing encryption of a segment 4002 of the frame, according to one embodiment.

[0060] In the first SU step, a device identifier 20 is determined.

[0061] This identifier determines the first field, 4001. This field could, for example, be the second identifier, 445. Since this second identifier is chosen from a limited list of identifiers, it does not allow for the problematic identification of device 20. In particular, the non-uniqueness of the second identifier, 445, ensures the protection of personal data and the technical impossibility of tracking device 20 (and therefore the vehicle and its driver).

[0062] In an S12 step, a key ID is determined from this identifier (which is also inserted in field 4001). As will be seen later, this identifier is then used to encrypt a 4002 segment of the frame. The first 4001 field must therefore not belong to this 4002 segment.

[0063] One step S13 is to determine a symmetric key K from the key identifier ID, which is associated with a device identifier 20.

[0064] It is important to remember that a symmetric key is a unique key that allows both the encryption and decryption of data. It is therefore necessarily secret and shared only by the parties involved in the data exchange.

[0065] Device 20 can store such an association in its internal memory

[0066] There is a one-to-one association between the key identifier ID and the symmetric key K. This association can be directly encoded in the device 20, but it must be determinable by the remote receiving organ 30. In other words, it must be such that the latter can retrieve the key K from the key identifier ID. The mechanism on the receiver side will be explained later.

[0067] Figure 7 illustrates an example of implementing this step of determining the key identifier ID.

[0068] In this example implementation, at least one second key, KSI, KS2, is applied to the first field 4001, in order to obtain a value V. The key identifier ID is then obtained from a set of bits, ID1, ID2, ID3, of this value V.

[0069] In particular, block ciphers can be implemented whereby the keys are, for example, two speck keys applied successively to two partially overlapping blocks of the first 4001 field. Other mechanisms are also applicable, such as AES keys.

[0070] It is also possible to apply more than two keys successively to more than two blocks of the first 4001 field. In this case, according to one embodiment, it may be provided that a part of the at least two blocks of said first 4001 field partially overlap in pairs.

[0071] Thus, a first KSI key is applied (step BS1) to a first block of the first 4001 field. Part of the output of this BS1 application provides bits of the final value V. The complementary part of the output of step BS1, along with the complementary block of the first 4001 field, forms the input of a BS2 application step. of a second key KS2. The output of this step provides the bits that allow the final value V to be completed.

[0072] Speck keys can be used. Speck is a family of lightweight block ciphers designed by the NSA and made public in June 2013 in the article by Ray Beaulieu, Douglas Shors, Jason Smith, Stefan Treatman-Clark, Bryan Weeks and Louis Wingers, "The Simon and Speck Families of Lightweight Block Ciphers", on nsacyber.github.io.

[0073] In the case of a first field encoded on 46 bits, 64-bit Speck keys can be used, for example. The blocks can be 32 bits, which corresponds to an overlap of 18 bits.

[0074] Of course, other encryption mechanisms are entirely possible, with Speck block ciphers being given as an illustrative example of one implementation.

[0075] Treatments other than encryption (or cryptography) can also be used.

[0076] To add variability and make the attack more complex for a third party, different mechanisms can be defined based on certain information from frame 40. For example, different KSI and KS2 keys can be provided, and the ones used can be made dependent on the format indicator 444.

[0077] The key identifier ID can be formed from a set of bits of the value V determined from this first field.

[0078] In other words, a set of bits from the value V obtained by the processing allows the key identifier ID to be determined. The other bits of the value V may not be used in the described process.

[0079] According to one embodiment, no processing is applied to field 4001 so that the value V corresponds to field 4001.

[0080] In one embodiment, this set of bits is an ordered selection of the value, previously determined. This ordered selection is predetermined in order to be shared between the device 20 and the remote receiving organ 30 (for example, by construction, or during an initialization phase at the manufacturer).

[0081] For example, the key identifier ID is formed from 3 bits, ID1, ID2, ID3, which are, respectively, the 17 e bit, 38 e bit and 4 e bit of the value V.

[0082] It should therefore be noted that even if a third party manages to obtain the value V from the encrypted field, they would also need to know which bits to take into account, and in what order, in order to determine the key identifier ID.

[0083] Even if no processing is applied to field 4001 (Speck encryption or other), the key identifier ID is therefore not directly deducible by a third party.

[0084] In the example previously illustrated in Figure 7, the key identifier ID is encoded on 3 bits, allowing for the association of 8 different symmetric keys. It is clear that other embodiments are possible and that the remote server 80 can contain more symmetric keys, which are then associated with key identifiers ID encoded on more bits.

[0085] The symmetric key K determined in step S13 is applied, in step S15, to segment 4002 to encrypt (or determine the value of) a content. This term "content" refers to the data exchanged via a portion of the frame (or set of fields). This content therefore represents semantic data, as opposed to the frame fields, which can be encrypted and thus contain different physical data since they have undergone digital cryptographic processing.

[0086] As explained previously, this content can correspond to different fields of frame 40, typically including the unique identifier 441. This content is determined in an S14 step.

[0087] The symmetric key can, for example, be a 16-byte key.

[0088] The content encryption mechanism can conform to different encryption techniques, or encryption.

[0089] As an example, the AES algorithm is used.

[0090] AES (for "Advanced Encryption Standard") is a symmetric encryption algorithm widely used to secure data. It operates on 128-bit data blocks and uses 128-, 192-, or 256-bit keys, providing high security for a wide range of applications (such as file, disk, and network communication encryption). AES was published as an official standard by the NIST (National Institute of Standards and Technology) under the name FIPS PUB 197 in November 2001, and also by the ISO under the reference ISO / IEC 18033-3.

[0091] The frame 40 thus formed can then be transmitted to the distant receiving organ 30 as previously described.

[0092] Figure 6 illustrates the process of receiving a frame 40 by such a remote receiving organ 30, according to one embodiment.

[0093] Upon receiving a frame 40, the remote receiving organ implements a decryption phase of the encrypted segment 4002 of the frame (the other data of the frame being, by definition, unencrypted).

[0094] To do this, in an S21 step, a key identifier ID is determined from the first 4001 field of the received frame.

[0095] This step can be identical to that performed by device 20 in transmission. For example, the same mechanism illustrated in Figure 7 can be implemented.

[0096] Since the mechanism is the same on the transmitter and receiver sides, the remote receiving organ 30 determines the same key identifier ID value as that determined by the device 20 when transmitting the frame.

[0097] In an S22 step, the remote receiving organ 30 performs a query of a remote server 80. It can do this by sending a request message containing this key identifier ID.

[0098] This remote server 80 can be a server belonging to the manufacturer or manager of the device 20 and / or the remote receiving unit 30. It provides a list of symmetric keys associated with identifiers and can only be queried by providing an identifier. The identifier / symmetric key associations are, of course, the same as those stored on the device 20.

[0099] In step S23, the remote receiving device 30 applies the symmetric key K returned by the remote server 80 to the (encrypted) segment 4002 in order to decrypt it. The remote receiving device 30 may use an algorithm identical to or the inverse of the one used by device 20. For example, the AES algorithm may also be used by the remote receiving device 30.

[0100] Since the key K is symmetric, it can be used by the device to encrypt content to form the encrypted segment 4002, and by the remote receiving organ 30 to decrypt segment 4002 and retrieve the content.

[0101] In an S24 step, this content can be exploited by the remote receiving organ.

[0102] Thus, in the reception process described, it is necessary to query a remote server 80 to decrypt the frames 40. It is therefore impossible for a third party to decrypt a received frame without accessing such a remote server, since without querying it, it cannot determine which key K to apply.

[0103] The remote server manager can also control access and decide on security mechanisms (including authentication) to allow access to symmetric key / identity associations.

[0104] Of course, the present invention is not limited to the examples and embodiment described and illustrated. In particular, it is susceptible to numerous variations accessible to those skilled in the art.

Claims

DEMANDS 1. Method of transmitting a frame (40) by a device (20) associated with a pneumatic (11) to a remote receiving organ (30), comprising encrypting a segment (4002) of said frame by said device (20), determining (S13) a symmetric key (K) associated with a key identifier (ID) determined (S12) from an identifier of said device (20), and applying (S15) said symmetric key to said segment (4002) to encrypt a content.

2. Method of receiving a frame (40) by a remote receiving organ (30) emitted by a device associated with a pneumatic, comprising decrypting a segment of said frame including determining (S21) a key identifier (ID) from a first field (4001) of said frame, querying (S22) a remote server (80) to retrieve a symmetric key (K) associated with said key identifier (ID), and applying (S23) said symmetric key (K) to a segment (4002) of said frame to determine a content.

3. Method according to claim 2, wherein said identifier is formed from a set of bits of a value determined from the first field, said set of bits being an ordered and predetermined selection of bits of said value.

4. Method according to the preceding claim, wherein said identifier is determined (S21) by applying at least one second key (KSI, KS2) to said first field (4001) in order to obtain said value.

5. Method according to the preceding claim, wherein said at least one second key (KSI, KS2) are at least two keys applied successively to at least two blocks of said first field (4001).

6. Method according to the preceding claim, wherein a portion of the at least two blocks of said first field (4001), for example of Speck or AES type, partially overlap two by two.

7. A method according to any one of the preceding claims in which said content comprises at least one unique identifier of said device (20).

8. A method according to any one of claims 2 to 7 wherein said first field (4001) is an identifier of said device chosen from a set of identifiers made available by an identifier server.

9. Device (20) suitable for being associated with a pneumatic (11), comprising circuits for transmitting a frame (40) to a remote receiving organ (30), said circuits being adapted to perform encryption of a segment (4002) of said frame comprising a determination of a symmetric key (K) associated with a key identifier (ID) determined from an identifier of said device (20), and an application (S15) of said key to a content to encrypt said segment (4002).

10. Remote receiving organ (30) comprising circuits for receiving a frame (40) from a device (20) associated with a pneumatic (11), said circuits being adapted to perform a decryption of a segment of said frame comprising a determination (S21) of a key identifier (ID) from a first field (4001) of said frame, a query (S22) of a remote server (80) to retrieve a symmetric key (K) associated with said key identifier and an application (S23) of said symmetric key (K) to a segment (4002) of said frame to decrypt said content.

11. System comprising at least one device (20) associated with a pneumatic (11) according to claim 9 and / or a remote receiving element (30) according to claim 10, as well as said remote server.

Images