Patent Description:
More and more automobile manufacturers offer electronic car locks that are mainly used for opening and starting a car. An electronic car lock is generally associated with one or several physical keys embedding basic electronic components in order to offer connectivity to the lock and securing the key secrets.

The most secure version of these physical keys contain an embedded secure element (eSE) holding secret material. These physical keys are lifelong keys and provide full access to the car, which restricts who they can be lent to.

Another trend for car manufacturers is to try and put car keys inside an owner's mobile phone, for convenience reasons (see for instance <CIT>). These are so called virtual car keys. But to secure the keys at the same level as the physical keys, they often use hardware security on the phone, for example a trusted execution environment (TEEs), a smartcard with a subscriber identity module (SIM) application, an embedded secure element (eSE), or a combination thereof. This drastically limits which kind of device they can deploy on or add complex dependencies to secure element issuers.

Additional features and advantages of the invention will be more clearly understandable after reading a detailed description of one preferred embodiment of the invention, given as an indicative and non-limitative example, in conjunction with the following drawings:.

In this description, a physical key refers to at least a vehicle remote that is capable of communicating with a vehicle lock for providing access to at least some of the vehicle's resources. It is called physical as it can be held in the hand.

A vehicle is a mobile machine configured to transport goods or people including but not limited to a car, a truck, a boat or a wagon. A vehicle resource refers to a part or a function provided to the owner of the car or an authorized person, such as a trunk, a vehicle cabin accessible by opening a door or the starting of an engine.

The expression vehicle lock refers for example to an electro-mechanical device implemented into one or several of the vehicle's doors and controlled by the vehicle remote with the function of locking or unlocking it. The vehicle lock can also refer to the system used to start the vehicle. For a given vehicle, one can have one or several installed vehicle locks. A vehicle lock system refers to a set of one or several lock installed on a given vehicle.

A physical key therefore refers to a vehicle remote allowing the access to at least a vehicle resource. The physical key can also refer to a combination of a vehicle remote associated with a traditional key. A traditional key refers to a device configured to operate a mechanical lock. A physical key can also be implemented into a single device comprising the vehicle remote and a traditional key or alternately in two separate devices.

In this description, the expressions "master key" and "derived key" are referring to cryptographic keys used for cryptographic functions. A cryptographic key is a piece of information that can be memorized into the memory of an electrical device such as a vehicle remote, a smartphone or a vehicle lock.

<FIG> illustrates schematically a technique for an owner to delegate access to its car. For that purpose, the owner uses a physical key <NUM> comprising for example a vehicle remote <NUM> associated with a traditional key <NUM>.

The physical key <NUM> can be used by the owner to access or to start his car <NUM> and is generally provided with the car at the time of purchase. The physical key as well as the vehicle locks installed on the car are provisioned with a master key during a personalization phase performed in a production facility.

The vehicle remote <NUM> can be used for establishing a communication link <NUM> with a vehicle lock <NUM> for example using infra-red technologies. Techniques that are belonging to the state of the art can be used for that purpose.

In addition, the owner of the car <NUM> can configure a communication device for accessing its car taking into account a set of at least one access rule. According to this example, the communication device is a smartphone <NUM>. However, the invention is applicable to other types of communication devices, for example a smart watch or any electronic device comprising means to establish a communication link with the physical key <NUM> and a vehicle lock.

Using a communication device that is distinct from the physical key <NUM> presents several advantages. If the smartphone <NUM> belongs to the user, it allows him to leaves its physical key <NUM> at home. In another use case, the smartphone phone <NUM> may belong to a third party, for example a member of the owner's family or a friend. In that case, the owner is able to delegate a partial access to the car <NUM> by defining one or several access rules.

According to this example, a communication link is established between the physical key <NUM> and the smartphone <NUM> using a short-range communication protocol. Short-range communication protocols include but are not limited to Bluetooth, Bluetooth Low Energy (BLE) or Near-Field Communications (NFC) protocols. This communication link is preferably secured using state-of-the-art techniques as the data to be exchanged is sensitive.

Once the communication link <NUM> is established, the physical key sends a key that is derived from the master key. According to the invention, the master key is stored securely in a secure enclave implemented into the physical key <NUM>. In one embodiment, the secure enclave is a secure element embedded into the vehicle remote <NUM>.

Secure elements are small devices comprising a memory, a microprocessor and an operating system for computing treatments. Such secure elements may comprise a plurality of memories of different types. They are called "secure" because they are able to control the access to the data they contain and to authorize or not the use of data by other machines. The secure elements may also provide computation services based on cryptographic components. In general, secure elements have limited computing resources and are intended to be connected to a host machine. Secure elements may be removable or fixed to a host device.

The secure elements may embed an object-oriented virtual machine in order to be able to run applications written in an object-oriented language. Usually, these object-oriented applications manage applicative data which are stored into the secure element.

Other types of secure enclaves can also be used to memorize the master key, for example a trusted execution environment (TEE).

The smartphone <NUM> can use an application to manage the provisioning of the derived keys and to display information such as the access rules associated to a given derived key when required by the user of the application. The application can be made available on some application stores such as the App Store (trademark) or Google Play (trademark). Once configured and provisioned with the derived key and its associated access rules, the user can use the application to access some of the car resources.

As underlined, a derived key is associated to one or several access rules. An access rule is designed to limit the access to a vehicle lock system, for example the car trunk can be accessible but not the car doors. If the access rules allow the access to various resources of the car, the application can propose to the user different choices, for example "open the trunk", "open the right front door" or "start the car". If the user selects "open the right front door", a challenge can be sent by the smartphone <NUM> to the vehicle lock <NUM> and if it is successfully answered, the right front door finally opens. In this description, it is considered that a single derived key is calculated for a car. However, the invention is also applicable in the case where several derived keys are allocated to the car. For example, a different derived key can be allocated to each of the vehicle locks.

<FIG> provides an example of a sequence diagram where a mobile application is provisioned by a derived key for accessing to the resources of a car.

According to this example, the owner of the car <NUM> uses a mobile application <NUM> installed on a smartphone and selects <NUM> in a menu that a new derived key is required for this communication device. The owner <NUM> is then asked by the mobile application <NUM> to confirm the need for generating the new derived key. Once this is confirmed <NUM>, the mobile application <NUM> and the physical key <NUM> establish <NUM> a secure channel via the smartphone (not represented). This secure channel is established for example using Bluetooth Low Energy (BLE).

Then, a request <NUM> to generate a new derived key is sent by the mobile application <NUM> via the smartphone to the physical key <NUM>. This request <NUM> can be sent together with a set of at least one validity parameter defining the access rules, that is to say the conditions in which the derived key can be used for accessing the car resources. For example, the validity parameters include an expiration date after which the derived key will not be usable anymore, one or several time periods during which the access is allowed and an identifier of the resources for which the access is authorized. This identifier can be used to designate one of the car's door, the trunk or the starter.

According to one embodiment <NUM>, a confirmation can then be requested <NUM> by the mobile application <NUM> to the owner <NUM>. For example, a message is displayed on the smartphone's screen answering him to push a specific button located on its physical key <NUM>. The owner then pushes <NUM> the button and the computation <NUM> of the derived key by the physical key <NUM> is triggered.

The master key MK is securely stored in a secure enclave embedded into the physical key <NUM>. The derived key is designated as DK in the sequel and can be obtained by applying well-known derivation functions such as HMAC Key Derivation Function (HKDF), KDF1 or KDF2 as defined in ISO/IEC <NUM> specification.

According to one aspect of the invention, one or several validity parameters are used as inputs for the derivation algorithm. In that case, the DK is derived from the master key MK and a set of at least one validity parameters, which can be expressed as follow: <MAT> where:.

Once the newly generated derived key is available, it can be sent <NUM> by the physical key <NUM> to the mobile application <NUM>. The validity parameters and the mobile key DK are then stored <NUM> in the smartphone. As an example, those can be memorized into an embedded secure element (eSE), a SIM card, a trusted execution environment (TEE) or protected using white box cryptography (WBC) technique.

<FIG> provides an example of a sequence diagram in which a mobile application is used to open a vehicle lock.

The owner of the smartphone <NUM> requests an access to the car. The so-called owner of the smartphone can be the owner of the car or a third party to which an access to some of the car resources is delegated. For sending the request, he can push <NUM> a button displayed on the screen of the smartphone by the mobile application <NUM>. As an example, the owner <NUM> can choose among several actions associated to a given resource of the car. Example of choices that can be made available to the owner of the smartphone are: opening one or all of the car's doors, opening the trunk or starting the car. Those different actions can be materialized by different buttons displayed on the smartphone's screen.

Alternatively, the smartphone's owner can push <NUM> a button on or inside the car, for example a button that is located next to the starter if he want to start the car.

Once this is done, a connection link is established <NUM> between the mobile application <NUM> and the car lock <NUM>. For example, the car lock <NUM> can act like a beacon supporting Bluetooth Low Energy (BLE). Once it is detected by the smartphone, a communication link is established. Other technologies such as NFC can also be used. In that case, the communication link can be established by tapping an NFC-enabled smartphone to the vehicle lock <NUM>.

Once the communication link is established, a request for challenge is sent <NUM> by the mobile application <NUM> to the vehicle lock <NUM> together with the validity parameters VP that have been stored in the smartphone at the time of generating the derived key. It can also be sent with an action ACT identifying what the user wants to do, for example opening the car's trunk.

The vehicle lock checks <NUM> the validity parameters. In other words, it verifies the access rules defined by the validity parameters. For example, if the validity parameters are chosen such that the smartphone's owner is allowed to start the car between <NUM> and <NUM> p. , and that the time maintained by the car lock corresponds to <NUM> p. , the access is denied. On the contrary, if the validity parameters are positively verified, a challenge-response authentication is carried out. For that purpose, a challenge message <NUM> comprising a random number RND is transmitted by the vehicle lock <NUM> to the mobile application <NUM>. Then, an intermediate key AK is determined <NUM> by the mobile application <NUM>. AK is for example derived from the mobile key DK and the action ACT: <MAT> Where.

Then, the response to the challenge is calculated using a Keyed-Hash Message Authentication Code (HMAC) function: <MAT> Where:.

The answer ANS is then transmitted <NUM> by the mobile application <NUM> to the vehicle lock <NUM> together with a return message <NUM>. Once this message is received by the car lock <NUM>, it calculates <NUM> a version DK' of the derived key based on what it knows and what is received. An intermediate key AK' is also calculated: <MAT> <MAT>.

Then, the answer is re-calculated as follow: <MAT>.

If the received answer ANS is equal to the re-calculated one ANS', the action ACT can be carried out <NUM>, for example "opening the car's trunk" or "starting the car".

In an alternative embodiment, steps <NUM> and <NUM> can be replaced as follow. The answer is calculated using the following expression: <MAT>.

Where RND|ACT represents the concatenation of RND with ACT.

In that case, no intermediate key AK is required and the verification is done by the vehicle lock by recalculating the derived key and the received answer as follow: <MAT> <MAT>.

One advantage of the invention is that the master key MK is never transmitted once provisioned on the physical key and is kept securely in a secure enclave. When delegating the rights to access to a car resource, it is a derived key that is generated and transmitted to communication device. The interest of associating the derived key with a set of validity parameters is to limit the possibility of using this key compared to what can be done when using the physical key directly. For example, the physical key allows a complete access to the vehicle resources while the communication device that is using the derived key is only able to access to a subset of the available resources for a limited period of time. The derived key is less secure than the master key as it is transmitted over the air, but this drawback is advantageously mitigated by limiting its use using the access rules materialized by the validity parameters.

Claim 1:
A system comprising a physical key (<NUM>), a communication device (<NUM>) and a vehicle lock (<NUM>) installed on a vehicle memorizing a first cryptographic key called master key in a secure enclave, the vehicle lock (<NUM>) being configured to communicate remotely with the communication device (<NUM>),
wherein the physical key (<NUM>) is configured to provision the communication device (<NUM>) with data allowing said communication device (<NUM>) to access a vehicle resource by operating remotely the vehicle lock (<NUM>), the physical key (<NUM>) comprising a secure enclave also storing the master key, the secure enclave being an embedded secure element or a trusted execution environment, the physical key (<NUM>) being further configured to:
- establish a communication link (<NUM>) with the communication device (<NUM>);
- derive by the secure enclave a second cryptographic key called derived key from the master key; and
- transmit to the communication device (<NUM>) via the secure communication link (<NUM>) the derived key,
wherein the communication device (<NUM>) is configured to store the derived key received from the physical key (<NUM>) and
wherein the vehicle lock (<NUM>) is further configured to:
- establish a communication link (<NUM>) with the communication device (<NUM>),
- on request (<NUM>) from the communication device (<NUM>) send to the communication device a challenge message (<NUM>) comprising a random number;
- receive from the communication device (<NUM>) a security challenge answer (<NUM>) determined by the communication device (<NUM>) using the stored derived key and the random number;
- generate locally the derived key using the stored master key, compute locally a version of the security challenge answer and verify that it is identical to the one received from the communication device (<NUM>); and
- in case of a positive verification, grant the access to the vehicle resource (<NUM>).