WO2019136332A1

WO2019136332A1 - Multilane message counters to ensure order

Info

Publication number: WO2019136332A1
Application number: PCT/US2019/012463
Authority: WO
Inventors: Danny SUNG
Original assignee: Continental Intelligent Transportation Systems, LLC
Priority date: 2018-01-08
Filing date: 2019-01-07
Publication date: 2019-07-11

Abstract

A remote-cloud-key (RCK) system for granting access and start authorization to a locked vehicle, the system including: a cloud server; a plurality of mobile devices that is configured to receive RCK-vehicle-access commands and RCK-vehicle-start commands from the cloud server; an RCK device in the vehicle that is configured to receive a plurality of the RCK-vehicle-access commands and a plurality of the RCK-vehicle-start commands from the plurality of mobile devices and that is configured to use a single secure messaging layer (SML) counter to prevent the remote cloud key device from sending to the vehicle both: (1) RCK-vehicle-access commands out of order with respect to other RCK-vehicle-access commands sent to the vehicle; and (2) RCK-vehicle-start commands out of order with respect to other RCK-vehicle-start commands sent to the vehicle. The RCK-vehicle-access commands and RCK-vehicle-start commands may have been cached by the plurality of mobile devices.

Description

MULTILANE MESSAGE COUNTERS TO ENSURE ORDER

BACKGROUND

[0001] Embodiments of the invention relate generally to remote access control for motor vehicles. Typically, physical key fobs are created and sold with a particular vehicle to allow remote access into a vehicle.

[0002] U.S. Patent 9,483,886 to Bergerhoff, et al., entitled Method and system for remote access control, which is incorporated herein by reference, discloses a method to learn and then pair with a pre-installed access control system of a vehicle. Communication is exchanged between the access control system and a backend cloud-based system. Required data of the access control system including its particular authentication code is extracted by a learning device. A vehicle matching data is sent to the backend cloud-based system and the vehicle is registered with the backend cloud-based system. The learning device is registered to the access control system in accordance with learning procedures implemented in the vehicle as remote entry key. The learning device is coupled to a Radio Frequency signal transmitter that has Application- Specific Integrated Circuits to generate stable RF signals at multiple frequency wavelengths. Registration of learning device includes, receiving a first access control telegram message, transmitting the first access control telegram message to the access control system, pairing the learning device with the access control system.

[0003] Out of the roughly 1 billion light vehicles currently on the road, new key devices for vehicle access and start may be programmed by a consumer without any dealer involvement for up to about 30-50% of those vehicles. Vehicles built until 2006-2010 typically allow the owner to add additional keys, which the owner can“learn” to their vehicle. An owner would have to have a valid key that came with the car, and, perhaps go through a predefined sequence, such as turning on and off the ignition multiple times within a predefined period of time (e.g., 4 times within 30 seconds) or unlocking and locking the power door locks a

predetermined number of times within a predetermined period of time. The vehicle will then typically give an indication that it is in a mode to learn additional keys. For example, the vehicle may provide an audible indication, such a chime. A new unprogrammed key (also referred to as a virgin key) may then be recognized by the vehicle through a process in which the virgin key transmits a radio frequency (“RF”) telegram, and the vehicle accepts the credentials from the key and stores those credentials in an electronic control unit, such as the vehicle’s body controller. On newer models, a similar procedure may also be performed over a low frequency (“LF”) immobilizer interface by putting the new key into the ignition or near a pushbutton used for starting the vehicle or some other predefined location within the vehicle. In this way, the secrets and the rolling-code counter, which are required to synchronize a new key with the vehicle may be provided to, and stored in, the new key.

[0004] Generally, there are three types of access control systems for vehicles.

First, a mechanical blade to both unlock the door and start the engine. Second, came Remote Keyless Entry (RKE), which allows users to press a key on a fob to unlock the door. An anti-theft option also was introduced with RKE. Anti-theft is typically implemented with a coil around the ignition switch. The coil is connected to an immobilizer, which prevents unauthorized starting of the vehicle’s engine. The coil communicates an LF signal to a transponder in the head of the key, which changes or validates a secret code, which allows the engine to start. Third, passive systems work without actively operating the authorization device. The key can remain in the vehicle operator’s pocket, for example. When a door handle or a button on the door handle is touched, the vehicle sends a signal to the fob, which responds with a proper signal, and then the vehicle unlocks, which is essentially hands free operation with respect to the fob. Similarly, once inside the vehicle, upon pressing a start button, for example, antennas within the vehicle send a signal to the fob, which responds via RF thereby allowing the vehicle’s engine to be started. This replaces the need, in the RKE systems with anti-theft, to place the place the fob or a key close to the immobilizer coil in order to start the engine. Passive mode only works when the fob battery is charged. If the fob battery is flat (i.e., discharged), a mechanical key would have to be used to unlock the car. That is so-called limp-home mode for unlocking a car that has passive entry. Limp-home mode for starting the engine for a car with passive start is the same as the RKE system with anti-theft, which means that the fob will be placed near the immobilizer coil, which will provide energy to the microcontroller in the fob to respond with a secret code so that the vehicle can be started even when the fob battery is discharged.

[0005] Vehicle access (i.e., unlocking a vehicle’s door) involves a unidirectional communication. A button is pressed on a remote-control key fob, which causes the fob to send out a telegram to the vehicle. The vehicle and the key share a common secret. The algorithm that generates an

appropriate code is called a rolling code. The algorithm is known to both the key and the car. A command, such as lock or unlock, is transmitted along with the next valid rolling code. The most recently used rolling code gets stored. Then an algorithm is used to generate the next rolling code based on the most recently used rolling code. The vehicle then accepts only future rolling codes, relative to the most recently used rolling code, which prevents a so-called replay attack.

[0006] For start authorization, the communication scheme that is implemented on every car is a so-called challenge-response scheme. The car and the legitimate key, once it is programmed, share one secret, which is a bit pattern that is identical and which is referred to as a secret key. Both have the same secret key. The vehicle generates a random number, which is called a challenge, and sends the random number to the key. The vehicle then takes the random number that it just generated and runs it through a cryptology algorithm, e.g., HITAG 2, which uses the secret key to produce a result. The key does the same thing. The key also runs the random number received from the vehicle through the cryptology algorithm, which uses the secret key to produce a result, which is called a response. The key then sends this response back to the car, which checks whether the response matches the expected value calculated by the vehicle. If the response is correct, then the vehicle allows the key to start the vehicle.

[0007] Vehicle implementations for RKE, PASE (Passive Start and Entry), and

Immobilizer are highly fragmented between different vehicle models in their respective RF protocols, LF protocols, learning procedures, and the like. Conventional vehicle keys, therefore, will typically work with only one particular vehicle model. Such keys have a single

communications protocol, for example, adapted for use with a single vehicle model.

[0008] Conventionally, sequence-control has been maintained via roll-codes in

RF transmission for existing key fobs of existing RKE systems, and sequence numbers have been used in TCP packets.

[0009] Techniques for ensuring that RKE commands sent from a cloud server to mobile devices are received at an RCK device in an appropriate order would be an improvement.

BRIEF SUMMARY

[0010] Embodiments of the invention are directed to a remote-cloud-key (RCK) system for granting access and start authorization to a locked vehicle, the system including: a cloud server; a plurality of mobile devices that is configured to receive RCK-vehicle-access commands and RCK- vehicle-start commands from the cloud server; an RCK device in the vehicle that is configured to receive a plurality of the RCK-vehicle- access commands and a plurality of the RCK-vehicle-start commands from the plurality of mobile devices and that is configured to use a single secure messaging layer (SML) counter to prevent the remote cloud key device from sending to the vehicle both: (1) RCK- vehicle- access commands out of order with respect to other RCK-vehicle-access commands sent to the vehicle; and (2) RCK-vehicle-start commands out of order with respect to other RCK-vehicle-start commands sent to the vehicle. The RCK-vehicle-access commands and RCK-vehicle-start commands may have been cached by the plurality of mobile devices.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Fig. 1 depicts an operating environment for embodiments of the

invention.

[0012] Fig. 2 depicts a message format for messages (M) in a system, such as a

Remote Cloud Key (RCK) system, in which various commands may be sent between components within the system.

[0013] Fig. 3 depicts a typical format for a transport packet (T) in which single or multiple messages will typically be sent.

[0014] Fig. 4 depicts a first naive approach (to allowing some messages to

occur out of sequence from others while providing some guarantee of order for messages of the same category) in which a sequence number is embedded with all or specific commands in message M.

[0015] Fig. 5 depicts a second naive approach (to allowing some messages to occur out of sequence from others while providing some guarantee of order for messages of the same category) in which a counter (i.e., a sequence number) is added to the transport-level packet.

[0016] Fig. 6 depicts an improved approach (to allowing some messages to occur out of sequence from others while providing some guarantee of order for messages of the same category) in which a counter and a counterld are added to the transport header.

[0017] Fig. 7 depicts three lanes of ordered messages in accordance with

embodiments of the invention.

DETAILED DESCRIPTION [0018] In accordance with embodiments of the invention, a communications packet supports multiple counters, allowing for flexible determination of what types of packets should be ordered compared to previous packets. In addition it aids in preventing against replay attacks.

[0019] Fig. 1 depicts an operating environment for embodiments of the

invention. As depicted in Fig. 1, a Remote-Cloud-Key server (also referred to as a backend server) communicates wirelessly with a plurality of mobile devices (e.g., smartphones), which execute a

Connected Vehicle Access System (CVAS) mobile app. The mobile apps communicate wirelessly with a Remote-Cloud-Key (RCK) device (also referred to as a CVAS device) in a vehicle. From the point of view of the Remote Keyless Enty (RKE) module and the immobilizer in the vehicle, the RCK device appears to be simply an authorized key device that has been learned to the vehicle when the RCK device transmits commands, which it receives from the server via one of the mobile devices. Such commands may be cached by mobile devices, and there is limited range of valid rolling codes that the vehicle will accept at any particular time. As such, preventing the rolling codes sent by the RCK device to the vehicle from getting outside of the acceptable range by efficiently using rolling codes and minimizing wasted rolling codes improves operation of the system.

[0020] Fig. 2 depicts a message format for messages (M) in a system, such as a

[0021] Fig. 3 depicts a typical format for a transport packet (T) in which single or multiple messages will typically be sent.

[0022] In most situations, there is order dependence requiring that M_k occurs before M_{k+ i}. In this situation, the above transmission is sufficient as every message is guaranteed to be received and processed in order. [0023] There are cases, however, where some messages should be allowed to occur out of sequence from others, but messages of the same category still need some guarantee of order.

[0024] Fig. 4 depicts a first naive approach (to allowing some messages to

[0025] The advantage provided by the approach shown in Fig. 3 is great

granularity in controlling the sequence of commands. The disadvantage is that there are potentially numerous counters (one per command) and the inability to ensure order across multiple commands.

[0026] Fig. 5 depicts a second naive approach (to allowing some messages to occur out of sequence from others while providing some guarantee of order for messages of the same category) in which a counter (i.e., a sequence number) is added to the transport-level packet.

[0027] The approach depicted in Fig. 4 reduces the data transmitted for

numerous messages (M), the result is the same as the“typical” case where all messages M occur in sequence.

[0028] Fig. 6 depicts an improved approach (to allowing some messages to occur out of sequence from others while providing some guarantee of order for messages of the same category) in which a counter and a counterld are added to the transport header. The counterld serves as a category grouping for the individual counter value.

[0029] In accordance with embodiments of the invention, the Counter Id and

Counter values may be optional components of the Transport Header.

[0030] In this way, a small (controlled) number of sequence-able“lanes” of transport packets are provided such that messages within a lane can be guaranteed of order, but lanes are independent of each other.

[0031] Fig. 7 depicts three lanes of ordered messages in accordance with

embodiments of the invention. [0032] In this way, different“lanes” are provided for commands, where commands within any particular lane are guaranteed to be in order. As such, commands of different categories may be sent asynchronously (e.g. triggered by various user actions). When order is required for one category, it does not force a correlation with other categories. This is particularly advantageous when commands may be cached by an intermediary device (e.g. a mobile device).

[0033] As an example use case of the approach depicted in Figs. 5 and 6,

consider a remote cloud key (RCK) system in which a cloud server sends RCK commands (e.g., unlock vehicle, open trunk, enable vehicle start) to multiple mobile devices, which cache the commands before then sending them in an asynchronous manner (i.e., one mobile device may send several cached commands in row before any of the other mobile devices sends any of the cached commands) to an RCK device in a vehicle.

[0034] Such a scenario presents two separate problems to be solved. One

problem is to prevent a replay attack in StartAuth commands. The other problem is to prevent duplicate RKE lock/unlock commands from getting from the RCK device to the vehicle.

[0035] So, a naive approach would be to put a roll code in the StartAuth

command itself because that’s how the RK commands work. There is a roll code in the RKE command, so a roll code could be put in the

StartAuth command as well. This would involve putting a separate counter in the RKE command that the RCK device will check before it sends the actual command to the vehicle.

[0036] In accordance with embodiments of the invention, another layer, which may be referred to as a Secure Messaging Layer (SML), which is outside these commands, may be created and a counter may be placed in the SML layer. This SML layer may have multiple counters. So for the StartAuth commands and for the RKE commands different values of the counters are used. But the code is the same because it’s in a separate layer.

[0037] So, according to a naive approach, code would have to be written for checking StartAuth, and separate code would have to be written for checking RKE commands. By putting a counter in an upper layer, which enforces a check on sequencing even before any of the commands is executed, the counter value is different, but the same code decides whether to allow a next command to be executed or not. So the command itself will not be executed if the counter value is not within an appropriate range of values. In this way, one piece of code is used rather than using a separate piece of code for StartAuth and a separate piece of code for RKE commands and implementing the StartAuth and RKE commands differently with more complicated logic. So, in this way, the complication has been confined to one place, instead of two.

[0038] Stated somewhat differently, the RCK device has different layers of code that process these different commands. So there is RKE command processing, there is StartAuth command processing, these are different commands within the RCK device. So, for the StartAuth, it basically processes the command itself, and it prepares the RCK device to be ready to allow the car to get started, but it doesn’t send anything to the vehicle. For the RKE commands, for any lock/unlock command, RKE command processing prepares the RCK device to send a command, and then it actually sends a command to the vehicle. So, these separate types of command processing are implemented by two separate pieces of code.

[0039] To add roll-code functionality to StartAuth command in order to do the check to prevent replay of an old command, the StartAuth command implementation itself could be enhanced by puttin the roll code in the StartAuth command processing itself. And similarly to enhance the roll- code functionality for the RKE commands, that piece of code could be enhanced because it is a separate piece of code and a separate counter could be added in there. Then before the command is actually sent to the car, a check of the counter value could be performed to make sure that a command is not being duplicated (i.e., a command that has already been sent to the vehicle is not being sent again).

[0040] Instead of enhancing the separate pieces of code separately, an outer layer, a separate checking piece of code, was created. And the counter in this outer layer is used this counter and which will do this check to make sure that the SML counter of the outer layer is in an appropriate range before executing either type of commands. If the SML counter is valid, then either type of command may be executed. In this way, before the command is even accessed, the check of the SML counter is performed. And, in this way, that check serves a dual purpose: it prevents a replay of a StartAuth command; and it also prevents an old RKE command from being sent to the vehicle.

[0041] While the present invention has been illustrated by a description of various embodiments and while these embodiments have been described in considerable detail, it is not the intention of the applicants to restrict or in any way limit the scope of the appended claims to such detail. Additional advantages and modifications will readily appear to those skilled in the art. The invention in its broader aspects is therefore not limited to the specific details, representative apparatus and method, and illustrative example shown and described. Accordingly, departures may be made from such details without departing from the spirit or scope of applicant’s general inventive concept.

Claims

1. A remote-cloud-key (RCK) system for granting access and start authorization to a locked vehicle, the system comprising:

a cloud server;

a plurality of mobile devices that is configured to receive RCK-vehicle- access commands and RCK-vehicle-start commands from the cloud server;

an RCK device in the vehicle that is configured to receive a plurality of the RCK-vehicle-access commands and a plurality of the RCK-vehicle-start commands from the plurality of mobile devices and that is configured to use a single secure messaging layer (SML) counter to prevent the remote cloud key device from sending to the vehicle both: (1) RCK-vehicle-access commands out of order with respect to other RCK-vehicle-access commands sent to the vehicle; and (2) RCK-vehicle-start commands out of order with respect to other RCK- vehicle-start commands sent to the vehicle.

2. The RCK system of claim 1, wherein the RCK-vehicle-access commands and RCK-vehicle-start commands have been cached by the plurality of mobile devices.

3. The RCK system of claim 1, wherein the SML counter is

implemented by including a header, a counter ID, and a counter in a transport header.

4. The RCK system of claim 3, wherein the counter ID serves as a category grouping for the counter.