System and Method for Authenticating a Connection Between a User Device and a Vehicle

Abstract

A method for authenticating a connection between a user device and a vehicle includes sending, by the vehicle, a first wireless signal through a connection channel, receiving, by the vehicle, a second wireless signal through the connection channel, and acquiring, by the vehicle, a second signal strength sequence from second N continuous signal strength characteristics (PF.sub.Veh) of the second wireless signal, receiving, by the user device from the vehicle, the first wireless signal, acquiring a first signal strength sequence from first N continuous signal strength characteristics (PF.sub.UDev) of the first wireless signal, and communicating, by the user device, the first signal strength sequence to the vehicle.

Claims

1. A user device comprising: a memory configured to store programming instructions; and a processor coupled to the memory, wherein the programming instructions cause the processor to be configured to: send, to a vehicle, a second wireless signal through a connection channel; receive, from the vehicle, a first wireless signal through the connection channel; acquire a first signal strength sequence from first N continuous signal strength characteristics (PF.sub.UDev) of the first wireless signal; and communicate the first signal strength sequence to the vehicle.

2. The user device of claim 1, wherein the first signal strength sequence comprises the PF.sub.UDev.

3. The user device of claim 2, wherein the first signal strength sequence further comprises a user string (S.sub.UDev) and a correction data C.

4. The user device of claim 3, wherein the programming instructions further cause the processor to be configured to: filter the PF.sub.UDev using a low-pass filter to obtain a filtered PF.sub.UDev; and generate the S.sub.UDev and the correction data C by inputting the filtered PF.sub.UDev to a generate (gen) function of a fuzzy extractor mechanism.

5. The user device of claim 1, wherein before acquiring the first signal strength sequence, the programming instructions further cause the processor to be configured to communicate, to the vehicle, an initiation instruction for authenticating the user device.

6. The user device of claim 5, wherein the initiation instruction comprises: an initiation message authentication code (MAC) (M.sub.Ini) instructing the vehicle to authenticate the initiation instruction based on a BLUETOOTH user device (BUD) key (K.sub.BTUDev) that is shared between the user device and the vehicle; or a sign (S) instructing the vehicle to authenticate the initiation instruction based on a public-key infrastructure (PKI)-private key associated with the user device (Key.sub.Priv_UDev) that is shared between the user device and the vehicle.

7. The user device of claim 6, wherein the initiation instruction is validated, and wherein before acquiring the first signal strength sequence, the programming instructions further cause the processor to be configured to: receive an acknowledgement instruction from the vehicle, wherein the acknowledgement instruction is based on an encrypted acknowledgement message and an acknowledgement MAC (M.sub.Ack), wherein the encrypted acknowledgement message comprises a nonce n, a random string r, and an acknowledgement command, wherein the encrypted acknowledgement message is encrypted using a corresponding BUD key (K.sub.BTUDev), and wherein the M.sub.Ack is based on the encrypted acknowledgement message and the K.sub.BTUDev; validate the acknowledgement instruction using the K.sub.BTUDev.

8. The user device of claim 6, wherein the programming instructions further cause the processor to be configured to: detect a BLUETOOTH Low Energy (BLE) beacon from the vehicle; and establish, in response to the detecting, a BLUETOOTH pairing between the user device and the vehicle using a BLUETOOTH connection key (Key.sub.BTcon), wherein the Key.sub.BTcon is shared between the user device and the vehicle.

9. A vehicle comprising: a memory configured to store programming instructions; and a processor coupled to the memory, wherein the programming instructions cause the processor to be configured to: send, to a user device, a first wireless signal through a connection channel; receive, from the user device, a second wireless signal through the connection channel; acquire a second signal strength sequence from second N continuous signal strength characteristics (PF.sub.Veh) of the second wireless signal; receive, from the user device in response to sending the first wireless signal, a first signal strength sequence from first N continuous signal strength characteristics (PF.sub.UDev) of the first wireless signal; and authenticate a connection between the user device and the vehicle based on the first signal strength sequence and the second signal strength sequence.

10. The vehicle of claim 9, wherein the first signal strength sequence comprises the PF.sub.UDev.

11. The vehicle of claim 10, wherein the first signal strength sequence further comprises a user string (S.sub.UDev) and a correction data C, wherein the S.sub.UDev and the correction data C are based on a filtered PF.sub.UDev.

12. The vehicle of claim 11, wherein the programming instructions further cause the processor to be configured to: extract the correction data C from the first signal strength sequence; filter the correction data C using a low pass filter to obtain a filtered correction data C; filter the P.sub.FVeh using the low pass filter to obtain a filtered P.sub.FVeh; generate a vehicle string (S.sub.Veh) by inputting the filtered P.sub.FVeh and the filtered correction data C to a reproduce (rep) function of a fuzzy extractor mechanism; and authenticate, based on the S.sub.UDev and the S.sub.Veh, the connection.

13. The vehicle of claim 12, wherein the programming instructions further cause the processor to be configured to identify that the connection is valid based on characters at M corresponding positions in the S.sub.UDev and the S.sub.Veh being the same, and wherein the M is a positive integer greater than or equal to a preset threshold.

14. The vehicle of claim 9, wherein before acquiring the second signal strength sequence, the programming instructions further cause the processor to be configured to: receive an initiation instruction from the user device; and authenticate the user device based on the initiation instruction.

15. The vehicle of claim 14, wherein the initiation instruction comprises: an initiation message authentication code (MAC) (M.sub.Ini) indicating an instruction for the vehicle to authenticate the initiation instruction based on a BLUETOOTH user device (BUD) key (K.sub.BTUDev) that is shared between the user device and the vehicle; or a sign (S) indicating an instruction for the vehicle to authenticate the initiation instruction based on a public-key infrastructure (PKI)-private key associated with the user device (Key.sub.Priv_UDeva) and the K.sub.BTUDev and a PKI-public key associated with the vehicle (Key.sub.Pub_Veh), wherein the Key.sub.Priv_UDev and the Key.sub.Pub_Veh are shared between the user device and the vehicle.

16. The vehicle of claim 9, wherein before receiving the second wireless signal, the programming instructions cause the processor to be configured to: emit a BLUETOOTH Low Energy (BLE) beacon; and establish a BLUETOOTH pairing between the user device and the vehicle using a BLUETOOTH connection key (Key.sub.BTcon) based on whether the BLE beacon is detected, wherein the Key.sub.BTcon is shared between the user device and the vehicle.

17. A system comprising: a vehicle configured to send a first wireless signal through a connection channel; and a user device coupled to the vehicle and configured to: receive, from the vehicle, the first wireless signal through the connection channel; send, to the vehicle, a second wireless signal through the connection channel; acquire a first signal strength sequence from first N continuous signal strength characteristics (PF.sub.UDev) of the first wireless signal; and communicate the first signal strength sequence to the vehicle, wherein the vehicle is further configured to: receive, from the user device, the second wireless signal through the connection channel; acquire a second signal strength sequence from second N continuous signal strength characteristics (PF.sub.Veh) of the second wireless signal; and receive, from the user device, the first signal strength sequence, wherein the first signal strength sequence and the second signal strength sequence are for authenticating a connection between the user device and the vehicle.

18. The system of claim 17, wherein the first signal strength sequence comprises the PF.sub.UDev.

19. The system of claim 18, wherein the first signal strength sequence further comprises a user string (S.sub.UDev) and a correction data C.

20. The system of claim 19, wherein the user device is further configured to: filter the PF.sub.UDev by a low pass filter to obtain a filtered PF.sub.UDev; and generate the S.sub.UDev and the correction data C by inputting the filtered PF.sub.UDev to a generate (gen) function of a fuzzy extractor mechanism.

21. The system of claim 17, wherein before acquiring the first signal strength sequence, the user device is further configured to communicate, to the vehicle, an initiation instruction instructing to authenticate the user device.

22. The system of claim 21, wherein the initiation instruction comprises: an initiation message authentication code (MAC) (M.sub.Ini) instructing the vehicle to authenticate the initiation instruction based on a BLUETOOTH user device (BUD) key (K.sub.BTUDev) that is shared between the user device and the vehicle; or a sign (S) instructing the vehicle to authenticate the initiation instruction based on a public-key infrastructure (PKI)-private key associated with the user device (Key.sub.Priv_UDev) that is shared between the user device and the vehicle.

23. The system of claim 21, wherein the vehicle is further configured to: identify that the initiation instruction is valid; and communicate, in response to the identifying, an acknowledgement instruction to the user device, wherein the acknowledgement instruction is based on an encrypted acknowledgement message and an acknowledgement MAC (M.sub.Ack), wherein the encrypted acknowledgement message comprises a nonce n, a random string r, and an acknowledgement command, wherein the encrypted acknowledgement message is encrypted using a corresponding BLUETOOTH user device (BUD) key (K.sub.BTUDev), and wherein the M.sub.Ack is based on the encrypted acknowledgement message and the K.sub.BTUDev, and wherein the user device is further configured to validate the acknowledgement instruction using the K.sub.BTUDev.

24. The system of claim 21, wherein the vehicle is further configured to emit a BLUETOOTH Low Energy (BLE) beacon, and wherein the user device is further configured to: detect the BLE beacon; and establish, in response to the detecting, a BLUETOOTH pairing between the user device and the vehicle using a BLUETOOTH connection key (Key.sub.BTcon), wherein the Key.sub.BTcon is shared between the user device and the vehicle.

Description

BRIEF DESCRIPTION OF DRAWINGS

[0101] The above advantages and features in accordance with this disclosure are described in the following detailed description and are shown in the following drawings.

[0102] FIG. 1 illustrates a block diagram representative of an existing keyless entry system for vehicles.

[0103] FIG. 2 illustrates a block diagram representative of a keyless entry system for vehicles in accordance with embodiments of the disclosure.

[0104] FIG. 3 illustrates a block diagram representative of components in an electronic device or module for implementing embodiments of the disclosure.

[0105] FIG. 4 illustrates a timing diagram for establishing a BLE connection between two devices and the recording of physical layer features of the BLE channel in accordance with embodiments of the disclosure.

[0106] FIG. 5 illustrates a received signal strength variation as recorded by a user's device, a vehicle module and an adversary device.

[0107] FIG. 6A and FIG. 6B illustrate block diagrams representative of cryptographically secure fuzzy extractor mechanism in accordance with embodiments of the disclosure.

[0108] FIG. 7 illustrates a timing diagram for mutually authenticating the user device and the vehicle module based on the recorded physical layer features of the BLE channel in accordance with embodiments of the disclosure.

[0109] FIG. 8 illustrates a timing diagram for establishing a BLE connection between two devices and the recording of physical layer features of the BLE channel utilizing PKI in accordance with embodiments of the disclosure.

[0110] FIG. 9 illustrates a timing diagram for mutually authenticating the user device and the vehicle module based on the recorded physical layer features of the BLE channel using PKI in accordance with embodiments of the disclosure.

DESCRIPTION OF EMBODIMENTS

[0111] This disclosure describes a system and method for authenticating a connection between a user's device and a vehicle. In particular, the disclosure utilizes the physical layer features of the connection channel between the user's device and the vehicle to mutually authenticate the connection between the user's device and the vehicle.

[0112] The system allows for the secure and automatic authentication of user's mobile/personal device with the car using wireless technology. This system detects and confirms the proximity of user's device to the car and vice versa. The solution does this by exploiting the unique physical layer features of the BLE channel between the user's device and the car. An example of a physical layer feature is the received signal strength (RSS) as detected by the user's device or by the car. The wireless channel's physical features cannot be spoofed by an attacker and is extremely hard to predict. The mutual authentication steps to subsequently authenticate the recorded RSS features are designed based on a cryptographically secure fuzzy extractor mechanism and this system may be applied to two types of schemes, one for symmetric key based scenarios, and the other for PKI based scenarios.

[0113] FIG. 2 illustrates a block diagram of keyless entry system 200 for vehicles in accordance with embodiments of the disclosure. System 200 comprises vehicle 205 and devices 210 and 220 that belong to user 215. Vehicle 205 is provided with vehicle module 206 that is configured to handle vehicle 205's external communications with other sources and vehicle module 206 and user devices 210 and 220 are all BLUETOOTH enabled. In accordance with embodiments of the disclosure, vehicle module 206 may comprise any electronic module, any computing device and/or any wireless transceiver with communication function, and the electronic module, the computing device and/or the wireless transceiver which is configured to receive, process, and transmit instructions relating to vehicle 205. One skilled in the art will recognize that vehicle module 206 may comprise any combinations or types of electronic devices that are able to perform the functions mentioned above without departing from this disclosure.

[0114] Prior to establishing a BLUETOOTH connection between devices 210, 220 and vehicle module 206, a Key.sub.BTcon, is shared between devices 210, 220 and vehicle module 206 by a trusted entity. Once installed within the respective devices or module, this Key.sub.BTcon, will be bound to the device or module and may not be transferred out to another device or module as this key, Key.sub.BTcon will be used to establish a BLUETOOTH connection and for encrypting BLE communications between devices 210, 220 and module 206.

[0115] A Key.sub.BTUDev is also shared between devices 210, 220 and vehicle module 206 by a trusted entity. Once installed within the respective devices or module, this Key.sub.BTUDev will be bound to the device or module and may not be transferred out to another device or module as this key Key.sub.BTUDev will be used for encrypting commands and data that are sent through the BLE communications between devices 210, 220 and module 206 thereby increasing the security of the transmitted data.

[0116] FIG. 3 illustrates a block diagram representative of components of an electronic device 300 that is provided within user devices 210, 220 and module 206 for implementing embodiments in accordance with embodiments of the disclosure. One skilled in the art will recognize that the exact configuration of each electronic device provided within the user devices or the vehicle module may be different and the exact configuration of electronic device 300 may vary and FIG. 3 is provided by way of example only.

[0117] In embodiments of the disclosure, device 300 comprises controller 301 and user interface 302. User interface 302 is arranged to enable manual interactions between a user and electronic device 300 and for this purpose includes the input/output components required for the user to enter instructions to control electronic device 300. A person skilled in the art will recognize that components of user interface 302 may vary from embodiment to embodiment but will typically include one or more of display 340 that may be touchscreen enabled, keyboard 335 and track-pad 336.

[0118] Controller 301 is in data communication with user interface 302 via bus 315 and includes memory 320, central processing unit (CPU) 305 mounted on a circuit board that processes instructions and data for performing the method of this embodiment, an operating system 306, an input/output (I/O) interface 330 for communicating with user interface 302 and a communications interface, in this embodiment in the form of a network card 350. Network card 350 may, for example, be utilized to send data from electronic device 300 via a wired or wireless network to other processing devices or to receive data via the wired or wireless network. Wireless networks that may be utilized by network card 350 include, but are not limited to, WI-FI, BLUETOOTH, Near-Field Communication (NFC), cellular networks, satellite networks, telecommunication networks, wide area networks (WANs) and etc.

[0119] Memory 320 and operating system 306 are in data communication with CPU 305 via bus 310. The memory components include both volatile and non-volatile memory and more than one of each type of memory, including random-access memory (RAM) 320, read-only memory (ROM) 325 and a mass storage device 345, the last comprising one or more solid-state drives (SSDs). Memory 320 also includes secure storage 346 for securely storing secret keys, or private keys. It should be noted that the contents within secure storage 346 are only accessible by a super-user or administrator of device 300 and may not be accessed by any user of device 300. One skilled in the art will recognize that the memory components described above comprise non-transitory computer-readable media and shall be taken to comprise all computer-readable media except for a transitory, propagating signal. Typically, the instructions are stored as program code in the memory components but can also be hardwired. Memory 320 may include a kernel and/or programming modules such as a software application that may be stored in either volatile or non-volatile memory.

[0120] Herein the term “CPU” is used to refer generically to any device or component that can process such instructions and may include a microprocessor, microcontroller, programmable logic device or other computational device. That is, CPU 305 may be provided by any suitable logic circuitry for receiving inputs, processing them in accordance with instructions stored in memory and generating outputs (for example to the memory components or on display 340). In this embodiment, CPU 305 may be a single core or multi-core processor with memory addressable space. In one example, CPU 305 may be multi-core, comprising—for example—an 8 core CPU.

[0121] In the subsequent sections, for brevity, reference is made only to the interactions between user device 210 and vehicle module 206. One skilled in the art will recognize that user device 210 may be replaced with device 220 or any other similar devices without departing from this disclosure.

[0122] In the subsequent sections, for brevity, reference is made only to the authenticating a BLUETOOTH connection between a user device and a vehicle using BLE technology. One skilled in the art will recognize that the BLUETOOTH connection may be replaced with WI-FI connection or any other wireless connection without departing from this disclosure. In other words, the following method for authenticating are involved can be used for authenticating wireless connection between a user device and a vehicle.

[0123] As illustrated in FIG. 4, vehicle module 206 is configured to periodically transmit BLE beacons that contain the unique credentials/Identity of the vehicle 205. This is illustrated at step 412. When user 215 starts walking towards vehicle 205 and when user 215 is within communication range of the vehicle's BLE beacons, the user's personal device(s) 210 will detect and receive the BLE beacon transmitted from vehicle module 206. The vehicle's ID/credentials as contained in the BLE beacon is then used to identify that the vehicle 205 belongs to user 215. In accordance with embodiments of the disclosure, at step 415, when device 210 has determined that vehicle 205 belongs to user 215, device 210 will establish a BLUETOOTH pairing between device 210 and vehicle module 206 using the Key.sub.BTCon, that was previously shared between device 210 and vehicle module 206 by a trusted entity.

[0124] The step 412 and step 415 are set up a BLUETOOTH pairing between the user device 210 and the vehicle module 206. The course of setting up a BLUETOOTH pairing is a process to be performed when the user device 210 and the vehicle module 206 first establish a BLUETOOTH connection.

[0125] After the BLUETOOTH pairing has been completed when the user device 210 closed to the vehicle module 206. The user device 210 can establish a BLUETOOTH connection directly with the vehicle module 206 and the user device 210 needn't re-entering the Key.sub.BTCon. Once the BLUETOOTH pairing has been completed, device 210 will then generate an initiation instruction defined as (ID.sub.UDev∥CMD_START_AUTH, MAC (Key.sub.BTUDev, ID.sub.UDev∥CMD_START_AUTH)) where initiation MAC M.sub.Ini is defined as MAC (Key.sub.BTUDev, ID.sub.UDev∥CMD_START_AUTH), ID.sub.UDev is defined as the identity of the user's device 210 and CMD_START_AUTH is an initiation command identifier for instructing vehicle module 206 to initiate communications. The notation MAC (k, m) is a message authentication code using SHA-256 hash algorithm for a message m using a key k. At step 420, the initiation instruction is then communicated to vehicle module 206.

[0126] The user device 210 can based on the distance between the user device 210 and the vehicle module 206 generate the initiation instruction, for example when the user device 210 close to the vehicle module 206 the user device 210 generate the initiation instruction.

[0127] The user device 210 can based on the user's instruction generate the initiation instruction, for example when the user click the start button the user device 210 generate the initiation instruction.

[0128] Upon receiving the initiation instruction, vehicle module 206 will extract the identity ID.sub.UDev of user device 210 is from the initiation instruction. The extracted identity ID.sub.UDev is then used to retrieve a corresponding Key.sub.BTUDev from a database linked to vehicle module 206. The corresponding BUD Key, Key.sub.BTUDev, is then used to validate the initiation instruction. Once validated, vehicle module 206 will then generate an acknowledgement instruction at step 425 whereby the acknowledgement instruction is defined as (E(Key.sub.BTUDev, n∥r∥CMD_ACK_AUTH), MAC(Key.sub.BTUDev, n∥r∥CMD_ACK_AUTH)), where acknowledgement MAC MAC.sub.Ack—is defined as MAC(Key.sub.BTUDev, n∥r∥CMD_ACK_AUTH), the E(k, m) is an encryption function to encrypt message m with key k, CMD_ACK_AUTH is an acknowledgement command identifier for acknowledging a device, n is a nonce, and r is a random string. The acknowledgement instruction is then communicated to user device 210.

[0129] Upon receiving the initiation instruction, the vehicle module 206 will extract the identity ID.sub.UDev of user device 210 is from the initiation instruction. Once validated, the vehicle module 206 cannot execute the step 425.

[0130] In embodiments of the disclosure, vehicle module 206 is then configured to record physical layer features (PF) of the BLE channel established between the user device 210 and vehicle module 205. In embodiments of the disclosure, the physical features of the BLE channel may comprise RSS measures that were measured using a timer function with a t milliseconds (ms) timeout for a particular time period, e.g. a few seconds (4-5 seconds (s)) during which the user is walking towards his/her car.

[0131] Alternatively, the physical features of the BLE channel may comprise RSS measures that were measured in a time window, e.g. the time window set to 50 s and the vehicle module 206 measured the RSS ten timers in the time window.

[0132] Alternatively, a challenge response protocol can be employed for a synchronized PF reading between two parties with nonce n being applied to all communications. Here, the response must be sent within channel coherence time which typically comprises a few milliseconds. The recording of the physical layer features of the BLE channel PF.sub.TBox or PF.sub.Veh by vehicle module 206 is illustrated as step 435. One skilled in the art will recognize that step 435 may take place prior to the communication of the acknowledgement instruction or after the communication of the acknowledgement instruction without departing from the disclosure. Upon receiving the acknowledgement instruction, user device 210 will then validate the received acknowledgement instruction using the BUD Key, Key.sub.BTUDev. Upon successfully validating the instruction, the acknowledgement message is then decrypted using the Key.sub.BTUDev. The acknowledgement command is then retrieved from the decrypted message and the acknowledgement command causes the user device 210 to then record a set of physical layer features PF.sub.UDev of the BLE beacon's channel at step 430.

[0133] After step 430, both the user device 210 and vehicle module 206 will each have a set of physical layer features of the BLE beacon's channel recorded, i.e. PF.sub.UDev for user device 210, and PF.sub.TBox or PF.sub.Veh for vehicle module 206. The recorded set of physical layer features PF.sub.UDev and the set of physical layer features PF.sub.TBox or PF.sub.Veh are then mutually validated by a fuzzy extractor mechanism.

[0134] When the devices are connected over BLE, the wireless BLE channel exhibits reciprocity property, i.e. the wireless channels physical features e.g. signal strength, measured by both the legitimate devices in quick succession (within few a milliseconds) will be nearly the same. When two devices record these features over a short period of time, the overall variation observed by the two devices will be highly correlated. It should be noted that, the values may not be exactly similar, however, the overall trend or pattern of the two datasets will be nearly similar. Further, due to reciprocity property of the wireless channel, the recorded sets of PF.sub.UDev and PF.sub.TBox or PF.sub.Veh will both show high correlation in their variation trends even though the individually recorded values may not be exactly same because of in-channel noise, hardware factors, etc.

[0135] At the same time, when an adversary or eavesdropper (third device/attacker) eavesdrops on the communication between the two legitimate devices (user's device and the vehicle module) and records the signal features, his/her channel features will be totally different compared to the recording done by legitimate devices. This is because, although the adversary is in the vicinity of the legitimate devices, the signal captured by him/her will be different due to the multi-path effects of the wireless channel, i.e., the signal takes different multiple paths to reach the adversary's device. Hence, the adversary cannot even guess the values obtained by car and user's device. Even if the adversary were to adopt the same scheme as the legitimate devices, he/she cannot be successful in authenticating the communications between the user device and the vehicle module. FIG. 5 illustrates the received signal strength variation as recorded by user device, vehicle module and adversary for the above scenario whereby plot 505 shows the recorded RSS for the user device, plot 510 shows the recorded RSS for the vehicle module and 515 shows the recorded RSS for the adversary.

[0136] Further, apply filtering to remove noise component in the recorded RSS on both the devices. A low pass filtering method is applied to original RSS (as shown in FIG. 5) to obtain filtered signals. the filtered receive signal strength variation as recorded by user device, vehicle module and adversary for the above scenario whereby plot 505 shows the filtered RSS for the user device, plot 510 shows the filtered RSS for the vehicle module and 515 shows the filtered RSS for the adversary.

[0137] And then, employ Binary quantization, i.e., m-ary quantization for processing the RSS samples (PF).

[0138] W—number of samples in window.

[0139] m—number of levels e.g., 2 or 4 or 8 etc.

[0140] A guard band (space) is inserted between two consecutive quantization levels. The samples in guard band are discarded.

[0141] Other samples are encoded as per their levels Q.sub.i.

[0142] The ratio of guard band to data is denoted as α.

[0143] The size of quantization interval and guard band are calculated as follows:

[00005]${\int }_{l_i-1}^{l_i-g_i}f\tilde{s}d\tilde{s}=\frac{1-\alpha }{m},{\int }_{l_i-g_i}^{l_i}f\tilde{s}d\tilde{s}=\frac{\alpha }{m-1}.$

[0144] Further, it should be noted that the disclosure allows both parties to detect active man-in-the-middle attacks as symmetric keys and signal variation patterns are employed to detect and authenticate the devices. Only the pair of connected wireless devices can have similar RSS values due to reciprocity property of wireless channel. This means that adversaries or other BLE devices in the vicinity of legitimate devices cannot predict the RSS values obtained by legitimate parties. The RSS trend can be used to confirm if the user is really approaching i.e., RSS value increases as the user approaches the vehicle. Hence, both the party's user's device and vehicle module can confirm this behavior. Therefore, the disclosure provides strong mutual authentication with the help of Physical layer features of wireless channel (BLE) that cannot be spoofed or guessed by an adversary/eavesdropper. The legitimate parties will get know by their physical layer features if there is any attack during authentication. Thus, relay and impersonation attacks are mitigated by the disclosure.

[0145] In order to authenticate the physical layer features of the BLE beacon's channel as recorded by the user device 210 and the vehicle module 206, a cryptographically secure fuzzy extractor based mechanism is employed. A fuzzy extractor mechanism consists of a pair of functions gen 605 and rep 610 whereby the properties of these two functions 605, 610 are shown in FIG. 6A. The Gen function takes an input, a set of values w and produces a string s and set H. The rep function takes two inputs, a set w′ which is nearly same as w, but has some errors with respect to w, and H produced by gen, to produce s which is exactly same as the s produced by gen. The exact workings of the fuzzy extractor mechanism are omitted for brevity.

[0146] Hence, as illustrated in FIG. 6B, when the gen function 605 is used on the physical layer features of the BLE beacon's channel as recorded by the user device, the gen function takes in as its input the set of PF.sub.UDev and produces two outputs s.sub.UDev and C. As for the rep function 610, this function is applied by vehicle module 206 by taking as its input the physical layer features of the BLE beacon's channel as recorded by the vehicle module, PF.sub.TBox or PF.sub.Veh and C to produce seen that will be similar as that of s.sub.UDev.

[0147] The mutual authentication of the physical layer features of the BLE beacon's channel as recorded by both the user device 210 and vehicle module 206 is illustrated in FIG. 7. At step 705, user device 210 first applies a low pass filter to PF.sub.UDev to remove any spikes that may occur due to noise in the channel. Subsequently at step 710, the Gen function is then applied to the set of recorded physical layer features of the BLE beacon's channel PF.sub.UDev to generate string s.sub.UDev and correction data C.

[0148] A verification instruction defined as (E(Key.sub.BTUDev, n∥c∥CMD_HLP), MAC(Key.sub.BTUDev, n∥c∥CMD_HLP)) is then generated at step 715, where verification MAC M.sub.Ver is defined as MAC(Key.sub.BTUDev, n H C CMD_HLP), and CMD_HLP is a verification command identifier for instructing the vehicle module initiate mutual authentication steps.

[0149] At step 725, an authentication check instruction defined as E(Key.sub.BTUDev, n∥(r XOR s.sub.UDev)∥CMD_AUTH_CHK), MAC(Key.sub.BTUDev, n∥(r XOR s.sub.UDev)∥CMD_AUTH_CHK)) is then generated, where authentication check MAC M.sub.Auth_chk is defined as MAC(Key.sub.BTUDev, n∥(r XOR s.sub.UDev)∥CMD_AUTH_CHK), and CMD_AUTH_CHK is an authentication check command identifier for instructing the vehicle module to compare the recorded physical layer features of the BLE beacon and XOR is a logic XOR operation.

[0150] Upon receiving the verification instruction and decrypting and validating the verification instruction, at step 720, C parameters are extracted from the verification instruction. Vehicle module 206 then applies filtering and at step 730, the Rep function is applied to the set of recorded physical layer features of the BLE beacon's channel PF.sub.TBox or PF.sub.Veh and C to produce s.sub.Veh.

[0151] Upon receiving the authentication check instruction and decrypting and validating the authentication check instruction, vehicle module 206 verifies whether ((r XOR s.sub.UDev) as extracted from the authentication check message is same as (.sub.r XOR s.sub.Veh) that was generated by vehicle module 206. This is done at step 732. If it is determined that both are the same, then the authentication is considered successful, and an approval instruction defined as (E(Key.sub.BTUDev, n∥CMD_AUTH_OK), MAC(Key.sub.BTUDev, n∥CMD_AUTH_OK)) is generated where approval MAC M.sub.Apprv is defined as MAC(Key.sub.BTUDev, n∥CMD_AUTH_OK), CMD_AUTH_OK is an approval command identifier and the approval instruction is sent to user device 210 at step 735.

[0152] Conversely, if the verification fails, an error instruction defined as (E(Key.sub.BTUDev, n∥CMD_AUTH_FAIL), MAC(Key.sub.BTUDev, n∥CMD_AUTH_FAIL)) is generated where error MAC M.sub.Error is defined as MAC(Key.sub.BTUDev, n∥CMD_AUTH_FAIL), CMD_AUTH_FAIL is an error command identifier and the error instruction is sent to user device 210 and the authentication is then rejected at step 740.

[0153] Upon receiving the instructions, the user device will validate either the received approval instruction or the error instruction using the Key.sub.BTUDev. Once validated, the user device then proceeds to decrypt either the approval or error instruction.

[0154] In embodiments of the disclosure, if the BLUETOOTH on a user's device is not turned on while he/she is approaching the vehicle, automatic detection and authentication with the vehicle may not occur. Hence, in such a scenario, when the notices the device's status indicates that the device is not connected to the vehicle, the user then turns on BLUETOOTH on his user device to enable the device to connect to the vehicle. Upon successfully pairing the device with the vehicle's module, the user device will detect that the user is already near the car using RSS information obtained during the pairing step. The user will then be notified via an application on their device to wave his/her device towards the vehicle, i.e. to move the device in random manner a few times. If the device is a smartphone, the user will just need to wave it towards the vehicle, and if the device is a smartwatch worn on wrist, the user just needs to wave the watch in the direction of the vehicle to authenticate as described above.

Second Embodiment: PKI Based Solution

[0155] In another embodiment of the disclosure, in addition to pre-sharing the Key.sub.BTCon, the Key.sub.BTUDev between devices 210, 220 and vehicle module 206 by a trusted entity, public-private key pairs are also provided by the trusted entity to devices 210, 220 and vehicle module 206.

[0156] As illustrated in FIG. 8, vehicle module 206 is configured to periodically transmit BLE beacons that contain the unique credentials/Identity of the vehicle 205. This is illustrated as step 810. When user 215 is within communication range of the vehicle's BLE beacons, the user's personal device(s) 210 will detect and receive the BLE beacon transmitted from vehicle module 206. The vehicle's ID/credentials as contained in the BLE beacon is then used to identify that the vehicle 205 belongs to user 215.

[0157] In accordance with embodiments of the disclosure, at step 815, when device 210 has determined that vehicle 205 belongs to user 215, device 210 will establish a BLUETOOTH pairing between device 210 and vehicle module 206 using the Key.sub.BTCon, that was previously shared between device 210 and vehicle module 206 by a trusted entity.

[0158] The step 810 and step 815 are set up a BLUETOOTH pairing between the user device 210 and the vehicle module 206. The course of setting up a BLUETOOTH pairing is a process to be performed when the user device 210 and the vehicle module 206 first establish a BLUETOOTH connection.

[0159] After the BLUETOOTH pairing has been completed when the user device 210 closed to the vehicle module 206. The user device 210 can establish a BLUETOOTH connection directly with the vehicle module 206 and the user device 210 needn't re-entering the Key.sub.BTCon.

[0160] Once the BLUETOOTH pairing has been completed, device 210 will then generate an initiation instruction defined as (E(Key.sub.Pub_Veh, m.sub.0), S(Key.sub.Priv_Udev, m.sub.1)), where initiation message m.sub.0 is defined as (ID.sub.UDev∥CMD_START_AUTH), ID.sub.UDev is the identity of the user's device, and CMD_START_AUTH is the initiation command identifier for instructing vehicle module 206 to initiate communications. The encryption function E(k, m) causes message m to be encrypted with key k, m.sub.1 is defined as H(Key.sub.BTUDev, E(Key.sub.Pub_Veh, m.sub.0)), and the signing function S(k, m) causes message m to be signed using key k. H comprises a hash function that performs the hash using SHA-256 hash algorithm. At step 820, the initiation instruction is then communicated to vehicle module 206. The user device 210 can based on the distance between the user device 210 and the vehicle module 206 generate the initiation instruction, for example when the user device 210 close to the vehicle module 206 the user device 210 generate the initiation instruction.

[0161] The user device 210 can based on the user's instruction generate the initiation instruction, for example when the user click the start button the user device 210 generate the initiation instruction.

[0162] Upon receiving the initiation instruction, the vehicle module 206 will verify the signed-hashed-encrypted initiation message in the initiation instruction using a Key.sub.Pub_UDev, and when it is verified, the vehicle module 206 then decrypts the encrypted initiation message using a Key.sub.Priv_Veh. Based on the decrypted initiation message, a corresponding K.sub.BTUDev, for ID.sub.UDev is then retrieved from a database.

[0163] Vehicle module 206 will then generate an acknowledgement instruction at step 825 whereby the acknowledgement instruction is defined as (E(Key.sub.BTUDev, m.sub.2), S(Key.sub.Priv_Veh, m.sub.3)), where, m.sub.2 is defined as (n∥r∥CMD_ACK_AUTH), where CMD_ACK_AUTH is an acknowledgement command identifier for acknowledging a device, n is a nonce, and r is a random string, and m.sub.3 is defined as H(Key.sub.BTUDev, E(Key.sub.BTUDev, m.sub.2)). The acknowledgement instruction is then communicated to user device 210. Upon receiving the initiation instruction, the vehicle module 206 will extract the identity ID.sub.UDev of user device 210 is from the initiation instruction. Once validated, the vehicle module 206 cannot execute the step 825.

[0164] In embodiments of the disclosure, vehicle module 206 is then configured to record physical layer features (PF) of the BLE channel established between the user device 210 and vehicle module 205. In embodiments of the disclosure, the physical features of the BLE channel may comprise RSS measures that were measured using a timer function with a t ms timeout for a particular time period, e.g. a few seconds (4-5 s) during which the user is walking towards his/her car.

[0165] Alternatively, the physical features of the BLE channel may comprise RSS measures that were measured in a time window, e.g. the time window set to 50 s and the vehicle module 206 measured the RSS ten timers in the time window.

[0166] Alternatively, a challenge response protocol can be employed for a synchronized PF reading between two parties with nonce n being applied to all communications. Here, the response must be sent within channel coherence time which typically comprises a few milliseconds. The recording of the physical layer features of the BLE channel PF.sub.TBox or PF.sub.Veh by vehicle module 206 is illustrated as step 835. One skilled in the art will recognize that step 835 may take place prior to the communication of the acknowledgement instruction or after the communication of the acknowledgement instruction without departing from the disclosure.

[0167] Upon receiving the acknowledgement instruction, user device 210 will then verify the signed-hashed-encrypted acknowledgement message in the acknowledgement instruction using a PKI-Public Key associated with the vehicle module, Key.sub.Pub_Veh. The encrypted acknowledgement message is then decrypted using the K.sub.BTUDev when the signed-hashed-encrypted acknowledgement message is verified. Once the message is decrypted, the user device 210 then proceeds to record a set of physical layer features PF.sub.UDev of the BLE beacon's channel at step 830.

[0168] After step 830, both the user device 210 and vehicle module 206 will each have a set of physical layer features of the BLE beacon's channel recorded, i.e. PF.sub.UDev for user device 210, and PF.sub.TBox or PF.sub.Veh for vehicle module 206. The recorded set of physical layer features PF.sub.UDev and the set of physical layer features PF.sub.Veh or PF.sub.Veh are then mutually validated by a fuzzy extractor mechanism which has been described in detail in the previous embodiment.

[0169] The mutual authentication of the physical layer features of the BLE beacon's channel as recorded by both the user device 210 and vehicle module 206 is illustrated in FIG. 9. At step 905, user device 210 first applies a low pass filter to PF.sub.UDev to remove any spikes that may occur due to noise in the channel. Subsequently at step 910, the Gen function is then applied to the set of recorded physical layer features of the BLE beacon's channel PF.sub.UDev to generate user string s.sub.UDev and correction data C.

[0170] A verification instruction defined as (E(Key.sub.BTUDev, S(Key.sub.Priv_Udev, m.sub.5)) is generated at step 915, where m.sub.4 is defined as (n∥c∥CMD_HLP), where CMD_HLP is a verification command identifier for instructing the vehicle module initiate mutual authentication steps, m.sub.5 is defined as H(Key.sub.BTUDev, E(Key.sub.BTUDev, m.sub.4)).

[0171] At step 925, an authentication check instruction defined as (E(Key.sub.BTUDev, m.sub.6), S((Key.sub.Priv_Udev, m.sub.7)) is then generated, where m.sub.6 is defined as (n∥(r XOR S.sub.UDev)∥CMD_AUTH_CHK), where CMD_AUTH_CHK is an authentication check command identifier for instructing the vehicle module to compare the recorded physical layer features of the BLE beacon and XOR is a logic XOR operation and m.sub.7 is defined as H(Key.sub.BTUDev, E(Key.sub.BTUDev, m.sub.6)).

[0172] Upon receiving the verification instruction, the signed-hashed-encrypted verification message in the verification instruction is verified using a Key.sub.Pub_UDev. The encrypted verification message is then decrypted using the corresponding K.sub.BTUDev, and the correction data C is extracted from the decrypted verification message. The vehicle module then filters the extracted correction data C and the set of physical layer features PF.sub.Box or PF.sub.Veh using a low pass filter when the verification instruction is validated at step 920. A vehicle string S.sub.Veh is then generated by providing the filtered set of physical layer features PF.sub.Veh and the filtered correction data C to a rep function of the fuzzy extractor mechanism at step 930.

[0173] Similarly, upon receiving the authentication check instruction, the signed-hashed-encrypted authentication check message in the authentication check instruction is verified using a Key.sub.Pub_UDev. The encrypted authentication check message is then decrypted using the corresponding K.sub.BTUDev, when the signed-hashed-encrypted authentication check message is verified.

[0174] Upon decrypting and validating the authentication check instruction, vehicle module 206 verifies whether ((r XOR s.sub.UDev) as extracted from the authentication check message is same as (.sub.r XOR s.sub.Veh) that was generated by vehicle module 206. This is done at step 932. If it is determined that both are the same, then the authentication is considered successful, and an approval instruction defined as (E(Key.sub.BTUDev, m.sub.8), S(Key.sub.Priv_Veh, m.sub.9)) is generated, where m.sub.8=(n CMD_AUTH_OK), m.sub.9=H(Key.sub.BTUDev, E(Key.sub.BTUDev, m.sub.8)), and CMD_AUTH_OK is an approval command identifier to approve the mutual authentication. The approval instruction is then sent to user device 210 at step 935.

[0175] Conversely, if the verification fails, an error instruction defined as (E(Key.sub.BTUDev, m.sub.10), S(Key.sub.Priv_Veh, m.sub.11)) is generated and mutual authentication is rejected, where m.sub.10 is defined as (n∥CMD_AUTH_FAIL), where mu is defined as H(Key.sub.BTUDev, E(Key.sub.BTUDev, m.sub.10)), and CMD_AUTH_FAIL is the error command to reject the mutual authentication process. The error instruction is then sent to user device 210 at step 940.

[0176] Upon receiving the approval instructions, the user device will verify the signed-hashed-encrypted approval message in the approval instruction using a Key.sub.Pub_Veh. The encrypted approval message is then decrypted using the K.sub.BTUDev, when the signed-hashed-encrypted approval message is verified. The authentication of the user device and the vehicle module is then completed based on the approval command in the decrypted approval message.

[0177] Conversely, upon receiving the error instructions, the user device will verify the signed-hashed-encrypted error message in the error instruction using a Key.sub.Pub_Veh. The encrypted error message is then decrypted using the K.sub.BTUDev, when the signed-hashed-encrypted error message is verified. The authentication of the vehicle module and the user device is then rejected based on the error command in the decrypted approval message.

[0178] In accordance with another embodiment of the disclosure, with reference to FIG. 2 and FIG. 3, either one of user devices 210 or 220 may be used to authenticate BLUETOOTH or wireless communications with vehicle module 206. In particular, user device 210 has a processor 305 and a non-transitory media 320 readable by the processor 305 whereby the non-transitory media 320 is configured to store instructions. When these instructions are executed by the processor 305, the instructions cause processor 305 to generate an initiation instruction based on an identity of the user device ID.sub.UDev, an initiation command, and an initiation MAC M.sub.Ini, wherein the MAC M.sub.Ini is generated based on the identity of the user device ID.sub.UDev, the initiation command and a K.sub.BTUDev that is shared between the user device 210 and the vehicle module 206, communicate the initiation instruction to the vehicle module 206 such that upon receiving the initiation instruction, the vehicle module 206 is configured to retrieve a corresponding K.sub.BTUDev, from a database, based on the received initiation instruction and validate the initiation instruction using the retrieved corresponding K.sub.BTUDev, generate an acknowledgement instruction based on an encrypted acknowledgement message and an acknowledgement MAC M.sub.Ack, when the initiation instruction is validated, wherein the acknowledgement message comprises a nonce n, a random string r, and an acknowledgement command and the acknowledgement message is encrypted using the corresponding K.sub.BTUDev, and the acknowledgement MAC M.sub.Ack is generated based on the acknowledgement message and the corresponding K.sub.BTUDev, communicate the acknowledgement instruction to the user device 210, record a set of physical layer features PF.sub.Veh of the BLE beacon's channel, the user device 210 further comprising instructions for directing the processor to validate the acknowledgement instruction using the K.sub.BTUDev, record a set of physical layer features PF.sub.UDev of the BLE beacon's channel when the acknowledgement instruction is validated, and authenticate the vehicle module 206 when the set of physical layer features PF.sub.UDev and the set of physical layer features PF.sub.Veh are validated by a fuzzy extractor mechanism.

[0179] In accordance with yet another embodiment of the disclosure, with reference to FIG. 2 and FIG. 3, either one of user devices 210 or 220 may be used to authenticate BLUETOOTH or wireless communications with vehicle module 206. In particular, user device 210 has a processor 305 and a non-transitory media 320 readable by the processor 305 whereby the non-transitory media 320 is configured to store instructions. When these instructions are executed by the processor 305, the instructions cause processor 305 to encrypt an initiation message, m.sub.o, comprising an identity of the user device ID.sub.UDev and an initiation command, using a Public Key Infrastructure (PKI)-Public Key associated with a vehicle module, Key.sub.Pub_Veh, hash the encrypted initiation message using a K.sub.BTUDev, and sign the hashed-encrypted initiation message using a Key.sub.Priv_UDev, generate an initiation instruction based on the encrypted initiation message and the signed-hashed-encrypted initiation message, communicate the initiation instruction to the vehicle module 206 such that upon receiving the initiation instruction, the vehicle module 206 is configured to verify the signed-hashed-encrypted initiation message in the initiation instruction using a Key.sub.Pub_UDev, decrypt the encrypted initiation message using a PKI-private key associated with the vehicle module 206, Key.sub.Priv_Veh and retrieve a corresponding K.sub.BTUDev, from a database, based on the decrypted initiation message when the signed-hashed-encrypted initiation message is verified, encrypt an acknowledgement message, m.sub.2, comprising a nonce n, a random string r, and an acknowledgement command, using the corresponding K.sub.BTUDev, hash the encrypted acknowledgement message using the corresponding K.sub.BTUDev, and sign the hashed-encrypted acknowledgement message using the Key.sub.Priv_Veh, generate an acknowledgement instruction based on the encrypted acknowledgement message and the signed-hashed-encrypted acknowledgement message, communicate the acknowledgement instruction to the user device 210, record a set of physical layer features PF.sub.Veh of the BLE beacon's channel, the user device 210 further comprising instructions for directing the processor to verify the signed-hashed-encrypted acknowledgement message in the acknowledgement instruction using a Key.sub.Pub_Veh, decrypt the encrypted acknowledgement message using the K.sub.BTUDev when the signed-hashed-encrypted acknowledgement message is verified, record a set of physical layer features PF.sub.UDev of the BLE beacon's channel, and authenticate the vehicle module 206 when the set of physical layer features PF.sub.UDev and the set of physical layer features PF.sub.Veh are validated by a fuzzy extractor mechanism.

[0180] In accordance with yet another embodiment of the disclosure, with reference to FIG. 2 and FIG. 3, vehicle module 206 may be used to authenticate BLUETOOTH or wireless communications with either one of user devices 210 or 220. In particular, user device 210 has a processor 305 and a non-transitory media 320 readable by the processor 305 whereby the non-transitory media 320 is configured to store instructions. When these instructions are executed by the processor 305, the instructions cause processor 305 to receive an initiation instruction from the user device, wherein the initiation instruction is generated based on an identity of the user device ID.sub.UDev, an initiation command, and an initiation MAC M.sub.Ini, whereby the MAC M.sub.Ini is generated based on the identity of the user device ID.sub.UDev, the initiation command and a K.sub.BTUDev that is shared between the user device 210 and the vehicle module 206, retrieve a corresponding K.sub.BTUDev, from a database, based on the received initiation instruction and validate the initiation instruction using the retrieved corresponding K.sub.BTUDev, generate an acknowledgement instruction based on an encrypted acknowledgement message and an acknowledgement MAC M.sub.Ack, when the initiation instruction is validated, wherein the acknowledgement message comprises a nonce n, a random string r, and an acknowledgement command and the acknowledgement message is encrypted using the corresponding K.sub.BTUDev, and the acknowledgement MAC M.sub.Ack is generated based on the acknowledgement message and the corresponding K.sub.BTUDev, record a set of physical layer features PF.sub.Veh of the BLE beacon's channel, communicate the acknowledgement instruction to the user device 210 such that upon receiving the acknowledgement instruction, the user device 210 is configured to validate the acknowledgement instruction using the K.sub.BTUDev, record a set of physical layer features PF.sub.UDev of the BLE beacon's channel when the acknowledgement instruction is validated, and authenticate the vehicle module when the set of physical layer features PF.sub.UDev and the set of physical layer features PF.sub.Veh are validated by a fuzzy extractor mechanism.

[0181] In accordance with yet another embodiment of the disclosure, with reference to FIG. 2 and FIG. 3, vehicle module 206 may be used to authenticate BLUETOOTH or wireless communications with either one of user devices 210 or 220. In particular, user device 210 has a processor 305 and a non-transitory media 320 readable by the processor 305 whereby the non-transitory media 320 is configured to store instructions. When these instructions are executed by the processor 305, the instructions cause processor 305 to receive an initiation instruction from the user device 210, wherein the initiation instruction is generated based on an encrypted initiation message and a signed-hashed-encrypted initiation message, the initiation message m.sub.o which comprises an identity of the user device ID.sub.UDev and an initiation command, is encrypted using a Key.sub.Pub_Veh, and the encrypted initiation message is hashed using a K.sub.BTUDev, and signed using a Key.sub.Priv_UDev, verify the signed-hashed-encrypted initiation message in the initiation instruction using a Key.sub.Pub_UDev, decrypt the encrypted initiation message using a Key.sub.Priv_UDev and retrieve a corresponding K.sub.BTUDev, from a database, based on the decrypted initiation message when the signed-hashed-encrypted initiation message is verified, encrypt an acknowledgement message, m.sub.2, comprising a nonce n, a random string r, and an acknowledgement command, using the corresponding K.sub.BTUDev, hash the encrypted acknowledgement message using the corresponding K.sub.BTUDev, and sign the hashed-encrypted acknowledgement message using the Key.sub.Priv_Veh, generate an acknowledgement instruction based on the encrypted acknowledgement message and the signed-hashed-encrypted acknowledgement message, record a set of physical layer features PF.sub.Veh of the BLE beacon's channel, communicate the acknowledgement instruction to the user device 210 such that upon receiving the acknowledgement instruction, the user device 210 is configured to verify the signed-hashed-encrypted acknowledgement message in the acknowledgement instruction using a Key.sub.Pub_Veh, decrypt the encrypted acknowledgement message using the K.sub.BTUDev when the signed-hashed-encrypted acknowledgement message is verified, record a set of physical layer features PF.sub.UDev of the BLE beacon's channel, and authenticate the vehicle module 206 when the set of physical layer features PF.sub.UDev and the set of physical layer features PF.sub.Veh are validated by a fuzzy extractor mechanism.

[0182] The above is a description of embodiments of a system and process in accordance with the present disclosure as set forth in the following claims. It is envisioned that others may and will design alternatives that fall within the scope of the following claims.