Patent Description:
Currently, vehicles access (e.g., car door opening, immobilizer/engine ignition) relies on physical keys or physical fobs. While having been in use for many years, physical keys/fobs become inconvenient for vehicle sharing which is a common phenomenon for family use and for car rental services. An example of vehicle sharing is that several family members may drive a family car at different times. Another example is that a car of a rental company is rented by different users over a time period. Vehicle sharing requires the sharing of the key for vehicle access, but physical keys are cumbersome to share, as pre-planning may be needed in order to pass the physical key from one person to another. A usual requirement in vehicle sharing is delegation of access rights for a short period of time. For example, a tourist touring foreign country only needs to rent a car for a certain period. Physical keys are especially inconvenient or unsafe for granting temporary vehicle access rights. In particular, once a physical key is passed to a delegated user, it is nearly impossible to prevent the delegated user from physically copying the key.

The landscape of the consumer electronics has changed drastically in recent years and portable devices, e.g., smart phones, smart watches, and smart pads, have become our daily necessity. This makes it possible for portable device-carried electronic keys to replace physical keys, so as to do away with the hassle of physical keys. In this regard, there have been a number of demonstrations and commercial products of electronic access key systems available, but without technical details revealed. Also, there is a plethora of research that is related to electronic access keys, and some of the typical examples are as follows.

In the publications "<NPL>" and "<CIT>", both publications also focus on car sharing and delegation of access rights. Particularly, it assumes a trusted server issue keys for vehicle access to car owners and in addition, to avoid directly registering a car owner's authentication key to the car owner's vehicle, a token containing the key (i.e. the token can be understood to be a sealed e-envelope) is also issued and the token can only be decrypted by the vehicle. In the vehicle access protocol, authentication data generated by using the authentication key together with the token is sent to the vehicle, which then decrypts the token to get the authentication key, and in turn uses the key to check against the authentication data.

In the systems disclosed in both publications, the authentication keys (for vehicle access) of all the car owners, delegated users and the vehicles are issued by or known to a trusted third party server. This creates vulnerability where a rouge insider of the trusted third party server can expose all the keys in the server due to the implementation of a centralised third party server for storing all the keys.

Further, the system disclosed in both publications adopts a token-based authentication method, where a car owner gets the authentication key and delegation key from the server, along with a sealed e-envelope containing these keys, which can only be opened by the car owner. When accessing the car by the car owner or a delegated user, the content in the sealed e-envelope must be communicated to the car, together with the actual authentication data. The sealed envelope adds to the communication overhead.

Hence, those skilled in the art are striving to provide a method of vehicle sharing without the hassle of passing physical keys or physical fobs to a car renter.

Document <CIT> discloses a method for loading a virtual key in a user terminal, comprising the following steps: - receiving, by the user terminal, of a piece of matching data from another user terminal; - transmitting a piece of data dependent on the matching data to an electronic unit of a vehicle; - receiving, by the user terminal, from the electronic unit, of a virtual key for controlling at least one function of the vehicle. Such a user terminal is also proposed.

The above and other problems are solved and an advance in the state of art is made by systems and methods provided by embodiments in accordance with the disclosure and as defined in the attached claims. A first advantage of embodiments of systems and methods in accordance with the disclosure is that physical keys for vehicle access are replaced with portable device such as a mobile device. In view of the prevalent use of portable device in our daily life, this removes the need to carry a physical key around. A second advantage of embodiments of systems and methods in accordance with the disclosure is that it allows car owners to flexibly and securely delegate their access rights to other users, under fine-grained access policies. This overcomes the hindrance physical keys face in the scenario of car sharing. A third advantage of embodiments of systems and methods in accordance with the disclosure is that car owners and delegated users are able to use their portable devices for secured vehicle access. A fourth advantage of embodiments of systems and methods in accordance with the disclosure is that the cars independently generate their own secret keys and in turn the corresponding car owners' authentication keys. As a car belongs to the car owner, doing so basically means that the car owner controls all secret keys associated with his/her car. In addition, even if a car is compromised and the secret key it contains is exposed, no other cars will be affected, so there is no a single point of vulnerability of the entire system. In brief, this is a decentralised key generation and distribution system and method.

The above advantages and features in accordance with this invention are described in the following detailed description and are shown in the following drawings:.

This disclosure relates to a vehicle access authentication framework. Particularly, this disclosure relates to a method and system for generating and distributing keys among various entities for vehicle access.

This invention relates to a vehicle access system using a portable device-based electronic key system. In the system, users do not obtain physical keys, but use their portable devices such as smart phones to securely access vehicles with the help of electronic access credentials stored on the portable devices. Further, the vehicle owners' access rights can be delegated to other users at the owners' discretion, either temporarily or for long term, or bound to certain access policy.

The targeted applications for this invention are vehicle sharing for family use or fleet management, and the proposed system is especially applicable in scenarios where a highly dynamic or large set of users exist such as in car rental services. The system allows for multiple owners sharing a car, and allows a car owner to flexibly delegate the access right to other people, governed by an access policy stipulated by the car owner.

<FIG> illustrates the architecture of the system <NUM>. The system <NUM> includes a mobile device of a car owner <NUM>, processing unit residing in a car <NUM>, mobile device of a delegated user <NUM>, and a remote server <NUM>. One skilled in the art will recognise that the processing unit in the car <NUM> may also be a mobile device without departing from the system.

The mobile devices and processing unit are communicatively connected via short distance communication such as Bluetooth. The mobile devices and processing unit are communicatively connected to the remote server <NUM> via a connected network, in particular Internet. For purposes of this disclosure, we will use car owner <NUM>, car <NUM> and delegated user <NUM> to describe the processes and interactions executed by the system <NUM>.

It should be noted that the system <NUM> is designed to allow for multiple car owners, but without loss of generality, we assume a master car owner who takes charge of administrating the car, e.g., manages a blacklist stored on the processing unit residing in the car.

The system <NUM> consists of the following processes, where the car owner access protocol and the Delegated User access protocol are online processes shown in solid lines in <FIG> while the others are offline processes shown in dotted lines in <FIG>.

The car <NUM> executes a process to generate car key <NUM>. This process is initiated by the car owner in which a secret key (K) will be generated. This is the only secret key (K) securely kept by the car, and all other authentication keys are derivable from this secret key. In particular, the car would generate keys for an owner and the owner may use its key to further generate keys for delegated users.

This process <NUM> is executed between a car owner and the car. As a result, the car issues an authentication key KidO to the car owner, based on the owner's identity (idO) and optionally an access policy (PO). The authentication key is securely managed on the car owner's portable device <NUM> such as a mobile device or a secure hardware such as a token. The access policy PO may, for example, stipulate the validity period of the authentication key.

This process <NUM> is essentially an authentication protocol between a car owner <NUM> and the car <NUM>, where the car owner <NUM> uses its authentication key KidO and the car <NUM> uses its secret key (K). If the car <NUM> successfully verifies the authenticity of the car owner <NUM>, then the car <NUM> grants access to the car owner <NUM>. For purposes of this disclosure, granting access may refers to opening the car door and/or powering up the car engine. Otherwise, the car <NUM> refuses granting access to the car owner <NUM>.

This process <NUM> or <NUM> is executed between a car owner <NUM> and a delegated user <NUM>. As a result, the car owner <NUM> generates a delegated authentication KidU based on the car owner's ID (idO), the delegated user's ID (idU), and an access policy (PU). The access policy (PU) can be fine-grained, e.g., stipulating the validity period of the delegation, the limit of driving speed, the range within which the car can be drove, and so on. Two ways are distinguished on how the car owner transmits KidU to the delegated user, namely, (<NUM>) direct delegation <NUM> and remote delegation <NUM>. In direct delegation <NUM>, the car owner directly sends KidU to the delegate user. This occurs where both car owner and delegated user meet in person and both of them may use their mobile devices to communication directly through short distance communication means such as Near Field Communication (NFC) or bluetooth. In remote delegation <NUM>, the car owner first sends KidU to the remote server <NUM>, and the delegated user retrieves the key (KidU) from the remote server <NUM>.

This process <NUM> is essentially an authentication protocol between a mobile device of the delegated user and the processing unit in the car, where the delegated user uses its delegated authentication key KidU and the car uses its secret key K. If the car successfully verifies the authenticity of the delegated user, then the car grants access to the delegated user according to the policy. Otherwise, the car refuses granting access to the non-authorised user.

This process <NUM> enables the master car owner to administrate a blacklist maintained at the processing unit <NUM> in the car by adding an item on the revoked user, through the remote server <NUM>. Both car owners and delegated users can be revoked.

<FIG> illustrates an example of a processing system <NUM> in the processing unit <NUM> residing in the car or the mobile devices <NUM> and <NUM> of the car owner or delegated user. Processing system <NUM> represents the processing systems in the processing unit <NUM> residing in the car or the mobile devices <NUM> and <NUM> of the car owner or delegated user that execute instructions to perform the processes described below in accordance with embodiments of this invention. One skilled in the art will recognize that the instructions may be stored and/or performed as hardware, firmware, or software without departing from this invention. Further, one skilled in the art will recognize that the exact configuration of each processing system may be different and the exact configuration of the processing system executing processes in accordance with this invention may vary and processing system <NUM> shown in <FIG> is provided by way of example only.

Processing system <NUM> includes a processor <NUM>, a radio transceiver <NUM>, an image capturing device <NUM>, a display <NUM>, a keypad <NUM>, a memory <NUM>, a Bluetooth module <NUM>, a Near Field Communication (NFC) module <NUM>, and an I/O device <NUM>.

The radio transceiver <NUM>, image capturing device <NUM>, display <NUM>, keypad <NUM>, memory <NUM>, Bluetooth module <NUM>, NFC module <NUM>, I/O device <NUM> and any number of other peripheral devices connect to processor <NUM> to exchange data with processor <NUM> for use in applications being executed by processor <NUM>.

The radio transceiver <NUM> is connected to an antenna which is configured to transmit outgoing voice and data signals and receive incoming voice and data signals over a radio communication channel. The radio communication channel can be a digital radio communication channel such as a CDMA, GSM or LTE channels that employs both voice and data messages in a conventional techniques.

The image capturing device <NUM> is any device capable of capturing still and/or moving images such as complementary metal-oxide semiconductor (CMOS) or charge-coupled sensor (CCD) type cameras. The display <NUM> receives display data from processor <NUM> and display images on a screen for a user to see. The display <NUM> may be a liquid crystal display (LCD) or organic light-emitting diode (OLED) display. The keypad <NUM> receives user input and transmits the input to processor <NUM>. In some embodiments, the display <NUM> may be a touch sensitive surface that functions as a keypad to receive user input.

The memory <NUM> is a device that transmits and receives data to and from processor <NUM> for storing data to a memory. The Bluetooth module <NUM> is a module that allows processing unit <NUM> to establish communication with another similar device based on Bluetooth technology standard. The NFC module <NUM> is a module that allows processing unit <NUM> to establish radio communication with another similar device by touching them together or by bringing the devices within a close proximity.

Other peripheral devices that may be connected to processor <NUM> include a Wi-Fi transceiver, a Global Positioning System (GPS), a RFID transceiver, an ultra wideband transceiver and other positioning transceivers.

The processor <NUM> is a processor, microprocessor, or any combination of processors and microprocessors that execute instructions to perform the processes in accordance with the present disclosure. The processor has the capability to execute various application programs that are stored in the memory <NUM>. These application programs can receive inputs from the user via the display <NUM> having a touch sensitive surface or directly from a keypad <NUM>. Some application programs stored in the memory <NUM> that can be performed by the processor <NUM> are application programs developed for Android, IOS, Windows Mobile, Blackberry or other mobile platforms.

The remote server <NUM> is essentially a computing system or a virtual machine running on the computing system that is communicatively connected to the processing unit <NUM> residing in the car or the mobile devices <NUM> and <NUM> of the car owner or delegated user. The remote server <NUM> is able to receive and transmit information such that the processing unit <NUM> residing in the car or the mobile devices <NUM> and <NUM> of the car owner or delegated user are able to communicate with each other. The remote server is similar to the processing system <NUM> in that the remote server also includes a processor <NUM>, a display <NUM>, a keypad <NUM>, a memory <NUM>, and an I/O device <NUM>. The remote server should also include a network device that connects the remote server to a network for transmission of data to and from other processing systems such as the processing unit <NUM> residing in the car or the mobile devices <NUM> and <NUM> of the car owner or delegated user.

<FIG> illustrates a program <NUM> stored in memory in processing unit residing in the car for performing the processes in accordance with the present disclosure. Program <NUM> includes a Key Generation Module <NUM>, a Secure Storage module <NUM>, an Owner Key Generation module <NUM>, a Car Access Protocol module <NUM> and a Blacklist module <NUM>. Briefly, the processes executed by <NUM> modules are as follows:.

<FIG> illustrates a program <NUM> stored in a memory in the mobile device of a car owner for performing the processes in accordance with the present disclosure. Program <NUM> includes an Owner Key Generation module <NUM>, a Secure Storage module <NUM>, a Delegated User Key Generation module <NUM>, a Car Access Protocol module <NUM> and a Blacklist administration module <NUM>. Briefly, the processes executed by <NUM> modules are as follows:.

<FIG> illustrates a program <NUM> stored in memory in the mobile device of a delegated user for performing the processes in accordance with the present disclosure. Program <NUM> includes a Delegated user Key Generation module <NUM>, a Secure Storage module <NUM>, and a Car Access Protocol module <NUM>. Briefly, the processes executed by <NUM> modules are as follows:.

<FIG> illustrates a program <NUM> stored in memory in the remote server for performing the processes in accordance with the present disclosure. Program <NUM> includes a Delegated user Key Generation module <NUM>, and a Blacklist administration module <NUM>. Briefly, the processes executed by <NUM> modules are as follows:.

The following first embodiment presents a symmetric key based instantiation of the above processes, based on the idea of hierarchical identity-based key generation.

<FIG> illustrates a timing diagram <NUM> to illustrate the information flow between the car, car owner, delegated user and remote server.

A key generation Application is installed on the car and only the master car owner can initiate the key generation Application, which is governed by password such as a superuser password. The superuser password can be delivered to the master car owner in a sealed physical envelope, together with other documents related to the car. The master car owner should be allowed to change the password. When the car is resold, the new master car owner can run the key generation Application again to generate a new secret key, which will overwrite the old one. The process of generating the new secret key is as follows.

Timing diagram <NUM> begins with step <NUM> where the car owner runs an application on his mobile device to initiate the car to run the key generation module <NUM> to generate a new secret key. Particularly, the owner key generation module <NUM> would generate and transmit a request to generate new secret key to the key generation module <NUM> in step <NUM>. In response to receiving the request, the car would perform an authentication with the car owner in step <NUM>. In particular, the key generation module <NUM> would request the owner key generation module <NUM> for the superuser password. If authentication is successful, the key generation module <NUM> would generate a secret key (K) in step <NUM>. Otherwise, the car would not generate a secret key. The car manages the secret key securely in the secure storage module <NUM>, e.g., in a secure hardware.

After the secret key is generated, the car owner would request for an authentication key in order to access the car. The authentication key for the car owner is generated in the following manner. In step <NUM>, the owner key generation module <NUM> sends a request to the owner key generation module <NUM> for authentication key. The request includes the car owner's ID (idO). In response to receiving the request from the car owner, the owner key generation module <NUM> generates an authentication key KidO = h(K, idCar, idO) in step <NUM>, where h(. ) is a cryptographic hash function, idCar is the ID of the car. The authentication key is transmitted to the owner key generation module <NUM> in step <NUM>. The car owner's mobile device manages the authentication key securely in the secure storage module <NUM>, e.g., in a secure hardware. For added security, a key rotation strategy can be implemented where after each car access or a fixed number of car accesses, the car generates a new authentication key for the car owner. Under the key rotation strategy, KidO would be computed as = h(K, idCar, idO, Seq), where Seq is an integer value, initially set to be <NUM>.

After the car owner received the authentication key, he/she is able to access the car with the authentication key. The process of accessing the car is as follows. The car access protocol module <NUM> would trigger the NFC to broadcasts its ID idCar and a random number r in a fixed frequency. Based on the idCar and random number r, the car access protocol module <NUM> computes vd = MAC(KidO, r), and then sends a request to access the car in step <NUM>. The request includes [<NUM>, idO, vd] where <NUM> denotes "owner access". In step <NUM>, the car verifies the blacklist and vd. In particular, the car access protocol module <NUM> checks the blacklist to determine whether idO is revoked, and aborts if it is. If the idO is not in the blacklist, the car access protocol module <NUM> continues to check whether vd = MAC(h(K, idCar, idO), r). If the check passes, then the car access protocol module <NUM> grants the access, e.g., open the car door. Otherwise, the car access protocol module <NUM> rejects granting access. If the key rotation strategy is implemented, a new key is going to be generated for the car owner after each access. Alternatively, the new key can be generated after a certain number of accesses. Further details on the car owner access would be described below.

In another embodiment where the communication channel between the car owner and the car is not that short, i.e. over Bluetooth, steps <NUM>-<NUM> may be modified as follows. The car access protocol module <NUM> would broadcasts its ID idCar and a random number r in a fixed frequency, e.g., once every <NUM> seconds. Upon receiving the broadcast message, the car access protocol module <NUM> chooses a random number r<NUM>, and then sends a message containing [<NUM>, idO, r<NUM>] to the car, where <NUM> denotes "owner access". In response to receiving the message, the car access protocol module <NUM> first checks the blacklist to determine whether idO is revoked, and aborts if it is. Otherwise, the car access protocol module <NUM> computes K'idO = h(K, idCar, idO) and vd<NUM> = MAC(K'idO, r<NUM>, r) and transmits vd<NUM> to the car owner. In response to receiving the message, the car access protocol module <NUM> checks whether vd<NUM> is equal to MAC(KidO, r<NUM>, r), and aborts if the check fails. Otherwise, the car access protocol module <NUM> computes vd<NUM> = MAC(KidO, r) and transmits a message containing vd<NUM> to the car access protocol module <NUM>. In response to receiving the message, the car access protocol module <NUM> checks whether vd<NUM> is equal to MAC(K'idO, r), and if the check passes, the car access protocol module <NUM> grants the access to the car, e.g., open the car door. Otherwise, the car access protocol module <NUM> rejects granting access to the car.

After the car owner received the authentication key, he/she is able to delegate access to the car with the authentication key. The process of delegation of access rights is as follows. The delegated user key generation module <NUM> transmits his/her ID idU to the delegated user key generation module <NUM> in step <NUM>. In response to receiving the ID, the delegated user key generation module <NUM> determines an access policy PU, and generates a delegated authentication key KidU = h(KidO, idU, PU) in step <NUM>. Thereafter, the delegated user key generation module <NUM> transmits the delegated authentication key to the delegated user key generation module <NUM> via either direct delivery or remote delivery in step <NUM>.

After the delegated user received the delegated authentication key, he/she is able to access the car with the delegated authentication key. The process of accessing the car is as follows. The car access protocol module <NUM> would trigger the NFC to broadcasts its ID idCar and a random number r in a fixed frequency. Based on the idCar and random number r, the car access protocol module <NUM> computes vd = MAC(KidU, r), and then sends a request to access the car in step <NUM>. The request includes [<NUM>, idU, idO, PU, vd] where <NUM> denotes "delegated user access". In step <NUM>, the car access protocol module <NUM> verifies the PU, blacklist and vd. In particular, upon receipt of the message, the car access protocol module <NUM> first checks whether PU is still valid, and aborts if PU does not hold any more. Otherwise, the car access protocol module <NUM> checks the blacklist in the blacklist module <NUM> to determine whether idO or idU is revoked, and aborts if it is. Otherwise, the car access protocol module <NUM> continues to check whether vd is equal to MAC(h(h(K, idCar, idO), idU, PU), r). If the check passes, then the car access protocol module <NUM> grants the access, e.g., open the car door. Otherwise, the car access protocol module <NUM> rejects granting access.

The master car owner can revoke a car owner or a delegated user from accessing the car by adding the ID of the car owner and delegated user in the blacklist. For revoking a car owner, the blacklist module <NUM> transmits a revoke request containing ID of the car owner to the remote server or directly to the car. For revoking a delegated user, the blacklist module <NUM> transmits a revoke request containing ID of the delegated user, ID of the car owner who delegated the ID, and the associated access policy P to the blacklist module <NUM> of the remote server or directly to the blacklist module <NUM> of the car. The master car owner can directly administer the blacklist in the blacklist module <NUM> if an operational interface is provided within the car and the master car owner physically has access to the car. Under such scenario, the master car owner can transmit the revoke request directly to the blacklist module <NUM> of the car in step <NUM>. In an alternate scenario, the master car owner manages the blacklist via the remote server. In such a scenario, the master car owner transmits the revoke request to the blacklist module <NUM> of the remote server in step <NUM>. In response to receiving the revoke request, the blacklist module <NUM> of the remote server updates the blacklist associated to the ID of the master car owner. The car would synchronize its blacklist with the remote server soonest possible. When the car request to synchronise its blacklist with the remote server, the remote server sends the updated blacklist to the car in step <NUM>. In this scenario, it is assumed that the master car owner registers to the remote server and thus has an account with the remote server. In addition, the car also registers to the remote server and communicates with the server. Timing diagram ends after step <NUM>.

The processes performed by the mobile devices and processing unit of the car owner, delegated user, car and remote server would now be described below.

<FIG> illustrates a process <NUM> performed by the mobile device of the master car owner in accordance with this disclosure. Process <NUM> begins with step <NUM> by requesting for the car owner to select an option. The options available are (<NUM>) access car, (<NUM>) add car owner, (<NUM>) new delegated user, (<NUM>) revoke key, and (<NUM>) new setup. If the option selected is option (<NUM>), process <NUM> proceeds to step <NUM> which is executed by the car access protocol <NUM>; if the option selected is option (<NUM>), process <NUM> proceeds to step <NUM> which is executed for the owner key generation module <NUM>; if the option selected is option (<NUM>), process <NUM> proceeds to step <NUM> which is executed for the delegated user key generation module <NUM>; if the option selected is option (<NUM>), process <NUM> proceeds to step <NUM> which is executed for the blacklist module <NUM>; and if the option selected is option (<NUM>), process <NUM> proceeds to step <NUM> which is executed for the owner key generation module <NUM>.

In step <NUM>, process <NUM> receives idCar and a random number r in a predetermined frequency via NFC. Based on the idCar and random number r, process <NUM> retrieves its authentication key KidO and computes vd = MAC(KidO' r) in step <NUM>. vd is computed via a Message Authentication Code (MAC) using a MAC generation function with KidO and r as the input. After vd is computed, process <NUM> generates and transmits a request to access the car in step <NUM>. The request includes [<NUM>, idO, vd] where <NUM> denotes "owner access". With the correct information in the request, the car should grant access. Optionally, for added security, a key rotation strategy can be implemented where after each car access or a fixed number of car accesses, the car generates a new authentication key for the car owner. Under the key rotation strategy, process <NUM> would continue after step <NUM> by receiving KO from the processing unit residing in the car. KO is essentially authenticated encryption of new key K'idO using the previous key KidO, i.e. KO =AEnc(KidO, K'idO). Process <NUM> would decrypt KO to get and verify the new key K'idO. If the new K'idO is authentic, process <NUM> updates its new authentication key, i.e. KidO = K'idO. If K'idO is not authentic, process <NUM> generates and transmits a response res = MAC(KidO, FALSE, r) to the car. res is computed via a Message Authentication Code (MAC) using a MAC generation function with KidO, FALSE and r as the input.

In step <NUM>, process <NUM> generates and transmits a request for authentication key. The request includes the car owner's ID (idO). In step <NUM>, process <NUM> receives an authentication key KidO = h(K, idCar, idO), where h(. ) is a cryptographic hash function, idCar is the ID of the car. Process <NUM> then stores the authentication key in a secured memory in step <NUM>. Optionally, for added security, a key rotation strategy can be implemented where after each car access or a fixed number of car accesses, the car generates a new authentication key for the car owner. Under the key rotation strategy, the authentication key would be KidO = h(K, idCar, idO, Seq), where Seq is an integer value initially set to be <NUM>.

In step <NUM>, process <NUM> receives an ID of a delegated user idU. In response to receiving the ID, process <NUM> requests for input on the access policy PU in step <NUM>. The access policy may include validity period of the delegated authentication key. Other access policy that may be added comprises speed limit, mileage, etc. In step <NUM>, process <NUM> generates a delegated authentication key KidU = h(KidO, idU, PU) after receiving the access policy. Thereafter, process <NUM> transmits the delegated authentication key to the delegated user via either direct delivery or remote delivery in step <NUM>.

In step <NUM>, process <NUM> request ID of the car owner or delegated user to be revoked. If the user wishes to revoke a car owner, process <NUM> generates a revoke request containing ID of the car owner in step <NUM>. If the master car owner wishes to revoke a delegated user, process <NUM> generates a revoke request containing ID of the delegated user, ID of the car owner who delegated the ID, and the associated access policy P in step <NUM> instead. Depending on the connectivity, process <NUM> transmits the revoke request directly to the processing unit residing in the car if the mobile device of the master car owner is communicatively connected to the processing unit residing in the car via Bluetooth or NFC in step <NUM>. Alternatively, process <NUM> transmits the revoke request to the remote server in step <NUM> instead.

In step <NUM>, process <NUM> generates and transmits a request to the processing unit residing in the car to generate new secret key. In step <NUM>, process <NUM> receives a request from the processing unit residing in the car owner for the superuser password. In response to receiving the request, process <NUM> prompts the user to enter the superuser password in step <NUM>. In step <NUM>, process <NUM> receives the input from the user. In step <NUM>, process <NUM> generates and transmits the superuser password to the processing unit residing in the car. In step <NUM>, process <NUM> receives a confirmation message from the processing unit residing in the car. The confirmation message contains information on whether the secret key has been successfully created.

Process <NUM> ends after steps <NUM>, <NUM>, <NUM>, <NUM> and <NUM>. Process <NUM> is also applicable for the mobile device of a car owner except that in option <NUM>, it would only be able to revoke a delegated user.

<FIG> illustrates a process <NUM> performed by the processing unit residing in the car in accordance with this disclosure. Before beginning with process <NUM>, the processing unit residing in the car has to boot up and retrieve a blacklist associated to the ID of the car from the remote server. Process <NUM> begins with step <NUM> to receive a request. If the request is for generating a new secret key, process <NUM> proceeds to step <NUM> which is executed by the key generation module <NUM>; if the request is for generating an authentication key, process <NUM> proceeds to step <NUM> which is executed by the owner key generation module <NUM>; if the request is for accessing the car, process <NUM> proceeds to step <NUM> which is executed by the car access protocol <NUM>; and if the request for updating the blacklist, process <NUM> proceeds to step <NUM> which is executed by the blacklist module <NUM>.

In step <NUM>, process <NUM> transmits a request for the superuser password. In step <NUM>, process <NUM> receives the superuser password from the mobile device of the master car owner. In step <NUM>, process <NUM> verifies the superuser password with the password stored on its memory. If the superuser password is correct, the car would generate a secret key (K) in step <NUM>. Otherwise, the car would not generate a secret key. In step <NUM>, process <NUM> stores the new secret key securely in a secured hardware. In step <NUM>, process <NUM> transmits a confirmation message to the mobile device of the master car owner. The confirmation message contains information on whether the secret key has been successfully created. The communication channel between the mobile device and the processing unit residing in the car is secured. This assumption is justified because this process is expected to be executed by the mobile device of the master car owner in a private environment, e.g., in the car owner's garage, and the distance between the mobile device and the processing unit is quite near via either NFC or Bluetooth.

In step <NUM>, process <NUM> generates an authentication key KidO = h(K, idCar, idO) with the car owner's ID (idO), the new secret key and its ID (idCar), where h(. ) is a cryptographic hash function. In step <NUM>, the authentication key is transmitted to the mobile device of the car owner. For added security, a key rotation strategy can be implemented where after each car access or a fixed number of car accesses, the car generates a new authentication key for the car owner. Under the key rotation strategy, KidO would be computed as = h(K, idCar, idO, Seq), where Seq is an integer value, initially set to be <NUM>. In step <NUM>, process <NUM> would be broadcasting its ID idCar and a random number r in a fixed frequency via either NFC or Bluetooth. One skilled in the art will recognise that process <NUM> may first be broadcasting its ID idCar and a random number r in a fixed frequency via either NFC or Bluetooth any time after step <NUM> and before step <NUM> without departing from the disclosure.

In step <NUM>, process <NUM> identifies whether this is an "owner access" or "delegated user access" based on the first integer in the request. If the first integer in the request is <NUM>, process <NUM> determines that this is an "owner access" proceeds to step <NUM>. If the first integer in the request is <NUM>, process <NUM> determines that this is a "delegated user access" and proceeds to step <NUM>.

In step <NUM>, process <NUM> checks whether PU is still valid, and aborts if PU does not hold any more. If PU is still valid, process <NUM> proceeds to step <NUM>. PU contains the validity period.

In step <NUM>, process <NUM> verifies the blacklist to determine whether idO or idU is revoked. If the idO or idU is revoked, process <NUM> ends. If the idO or idU is not in the blacklist, the car continues to verify vd in step <NUM>. For "owner access", process <NUM> check whether vd = MAC(h(K, idCar, idO), r). For "delegated user access", process <NUM> checks whether vd = MAC(h(h(K, idCar, idO), idU, PU), r). If the check passes, process <NUM> grants access to the car, e.g., open the car door. If the check fails, process <NUM> rejects granting access.

If the key rotation strategy is implemented, a new authentication key is going to be generated and transmitted to mobile device of the car owner in step <NUM>. The new authentication key is generated in the following manner. The process updates Seq = Seq +<NUM> and computes a new key K'idO = h(K, idCar, idO, Seq) and encrypts the new key K'idO with the car owner's old key KidO under an authenticated encryption scheme KO =AEnc(KidO, K'idO) and sends KO to the mobile device of the car owner. If a response is subsequently received by the processing unit, the processing unit verifies res. The response comprises MAC(K'idO, FALSE, r). To verify the res, the processing unit generates a MAC using the same MAC generation function with K'idO, FALSE and r as the input, and see whether MAC is equal to res. If verification is successful, the processing unit computes Seq = Seq -<NUM>.

One skilled in the art will recognise that steps <NUM>-<NUM> may be rearranged such that vd is verified first prior to verifying the blacklist. Further, other permutation may be implemented without departing from the disclosure. Still further, steps <NUM>-<NUM> may be implemented in a single step without departing from the disclosure.

Steps <NUM>-<NUM> are based on NFC communication channel between the car owner or delegated user and the car. In another embodiment where the communication channel between the car owner and the car is not that short, i.e. over Bluetooth, steps <NUM>-<NUM> may be performed in the following manner instead. Process <NUM> receives a message containing [<NUM>, idO, r<NUM>] from the car owner, where <NUM> denotes "owner access". Upon receipt of the message, process <NUM> checks the blacklist to determine whether idO is revoked, and aborts if it is. Otherwise, process <NUM> computes K'idO = h(K, idCar, idO) and vd<NUM> = MAC(K'idO, r<NUM>, r) and transmits vd<NUM> to the car owner. Process <NUM> then receives a message containing vd<NUM> from the car owner where vd<NUM> = MAC(KidO, r). Upon receiving the message, process <NUM> checks whether vd<NUM> is equal to MAC(K'idO, r), and if the check passes, process <NUM> grants access to the car, e.g., open the car door. Otherwise process <NUM> rejects granting access.

In step <NUM>, process <NUM> updates the blacklist accordingly. In particular, process <NUM> updates the blacklist by appending the ID of the car owner or ID of the delegated user, ID of the car owner who delegated access to the delegated user, and the associated access policy PU.

<FIG> illustrates a process <NUM> performed by the mobile device of the delegated user in accordance with this disclosure. Process <NUM> begins with step <NUM> by requesting for a delegated authentication key. The request includes his/her ID idU. As mentioned above, the request for delegated authentication key may be via direct delivery or remote delivery. Hence, under direct delivery the request would be transmitted to the mobile device of the car owner via Bluetooth or NFC and no authentication is required. Under the remote delivery, the request for delegated authentication key is transmitted to the remote server in step <NUM>. In the remote delivery scheme, prior to step <NUM>, the mobile device of the delegated user has to first register with the remote server and setup an authentication password for subsequent login to request for delegated authentication key from a car owner. After the delegated user registers with the remote server, he/she can establish a connection with the remote server through a password authentication and transmits the request to the remote server. In the remote delivery, the request would also include the car ID or the car owner ID in order for the remote server to direct the request to the right user.

In step <NUM>, process <NUM> receives a delegated authentication key KidU = (KidO, idU, Pu). Under direct delivery, the delegated authentication key would be received from the mobile device of the car owner via Bluetooth or NFC. Under the remote delivery, the request for delegated authentication key would be received from the remote server. Steps <NUM>-<NUM> are executable by the delegated user key generation module <NUM>.

After the delegated user received the delegated authentication key, he/she is able to access the car with the delegated authentication key. To access the car, process <NUM> receives the car ID idCar and a random number r in a fixed frequency via either NFC or Bluetooth in step <NUM>. Based on the idCar and random number r, the delegated user computes vd = MAC(KidU, r), and then transmits a request to access the car in step <NUM>. vd is computed via a Message Authentication Code (MAC) using a MAC generation function with KidU and r as the input. The request includes [<NUM>, idU, idO, PU, vd] where <NUM> denotes "delegated user access". With the correct request, the car should grant access to the car by opening the car door. Otherwise, the car would reject granting access. Process <NUM> ends after step <NUM>. Steps <NUM>-<NUM> are executable by the car access protocol module <NUM>.

<FIG> illustrates a process <NUM> performed by the remote server in accordance with this disclosure. Process <NUM> begins with step <NUM> by receiving a request from either the processing unit residing in the car or mobile devices of either car owners or delegated users. If the request is from the processing unit residing in the car to update blacklist, process <NUM> proceeds to step <NUM> which is executed by the blacklist module <NUM>. If the request is from the mobile device of the car owners and delegated user for remote delivery of delegated authentication key, process <NUM> proceeds to step <NUM> which is executed by the delegated user key generation module <NUM>. If the request is from the mobile device of the car owner to revoke a user, process <NUM> proceeds to step <NUM> which is executed by the blacklist module <NUM>.

In step <NUM>, process <NUM> retrieves the blacklist associated to the car ID upon receiving a request for blacklist from the processing unit residing in the car. The request includes the car ID and/or the ID of the car owner. In step <NUM>, process <NUM> transmits the blacklist to the processing unit residing in the car.

Step <NUM> involves handling the remote delivery of delegated authentication key between the delegated user and the car owner. In the remote delivery scheme, prior to step <NUM>, the mobile devices of the delegated user and car owner have to be registered with the remote server and subsequently login with their respective password in order to transmit data to and receive data from the remote server. In step <NUM>, process <NUM> receives a request from the delegated user comprising its ID together with the car ID or the car owner ID. In response to receiving the request, the remote server transmits a notification to the car owner in step <NUM>. Upon receiving the notification from the remote server, the car owner would login to the remote server and request for information. Hence, in step <NUM>, process <NUM> receives a request of information from the car owner. In response to receiving the request for information, process <NUM> generates and transmits information pertaining to the delegated user in step <NUM>. The information may include, name of the delegated user and ID of the delegated user. In step <NUM>, process <NUM> receives the delegated authentication key from the car owner. In step <NUM>, process <NUM> transmits the delegated authentication key from the delegated user.

Step <NUM> involves a request to revoke a user from is the mobile device of the car owner. In step <NUM>, receives a revoke request from the mobile device of the car owner. If a master car owner wishes to revoke a car owner, the revoke request contains ID of the car owner in step <NUM>. If the car owner wishes to revoke a delegated user, the revoke request contains ID of the delegated user, ID of the car owner who delegated the ID, and the associated access policy PU in step <NUM> instead. In response to receiving the revoke request from the car owner, process <NUM> retrieves the blacklist associated to the ID of the requestor and appends the blacklist accordingly in step <NUM>. Particularly, if the revoke request contains ID of the car owner, process <NUM> appends the blacklist to include the ID of the car owner, i.e. [idO]. If the revoke request contains ID of the delegated user, ID of the car owner who delegated the ID, and the associated access policy PU, process <NUM> append the blacklist to include ID of the delegated user, ID of the car owner who delegated the ID, and the associated access policy PU, i.e. [idU, idO, PU].

Process <NUM> ends after step <NUM>, <NUM> or <NUM>.

The following second embodiment presents another instantiation based on hierarchical Identity Based Signature (IBS). In an IBS system, a user's identity acts as the user's public key, without the reliance on Public Key Infrastructure (PKI) and in turn public-key certificates. The user's private key corresponding to the user's identity is issued by a Key Generation Center (KGC) which has a global public key/private key pair.

In hierarchical IBS, the KGC can be seen at level <NUM>, and it issues level-<NUM> private keys corresponding to user identities while a level-<NUM> private key issues level-<NUM> private keys, and so on. In particular, a hierarchical IBS scheme consists of the following algorithms:.

Based on a hierarchical IBS scheme, the instantiation can be described using <FIG>. All the assumptions in the first embodiment remain, unless otherwise specified.

Step <NUM> is modified such that the car would generate a secret key (GSK) by executing HSetUp(<NUM>k) to generate (GPK, GSK). The car then stores the GSK securely in the secure storage module while leaving GPK public. The car is at level <NUM>.

Step <NUM> is modified such that in response to receiving the request from the car owner, the car executes the key generation algorithm HKeyGen(GSK, idO,<NUM>, NULL), taking as input the GSK, the ID of the first device to generate a level <NUM> authentication key skidO,<NUM>. It should be noted that the car owner is at level <NUM>. The level <NUM> authentication key and the GPK are transmitted to the car owner in step <NUM>.

In step <NUM>, instead of computing vd, the car owner generates σ instead. Particularly, the car owner taps his/her mobile device to the car and receives the broadcast message containing ID idCar and a random number r. Based on the idCar and random number r, the car owner executes the signing algorithm, HSign(skidO,<NUM>, r), taking as input the first level authentication key of the car owner and the random number r, to generate σ, and then sends [<NUM>, idO, σ] to the car, where <NUM> denotes "owner access". In step <NUM>, the car verifies the blacklist and σ. In particular, the car checks the blacklist to determine whether idO is revoked, and aborts if it is. If the idO is not in the blacklist, the car continues to execute the signature verification algorithm, HVerify(σ, r, idO,<NUM>, NULL, GPK), taking as input the signature σ, the random number r, the ID of the first device, and GPK and grant the access if the output is <NUM>. Otherwise, the car rejects granting access.

In step <NUM>, in response to receiving the ID of the delegated user, the car owner determines an access policy PidU,<NUM>, and executes the key generation algorithm, HKeyGen(skidO,<NUM>, idU,<NUM>, PidU, <NUM>) taking as input the first level authentication key, the ID of the second device and the access policy PidU,<NUM> for idU,<NUM> to generate a level <NUM> authentication key skidU,<NUM>. Thereafter, the car owner transmits the level <NUM> authentication key and the GPK to the delegated user via either direct delivery or remote delivery in step <NUM>.

In step <NUM>, instead of computing vd, the delegated user generates σ instead. Particularly, the delegated user taps his/her mobile device to the car and receives the broadcast message containing ID idCar and a random number r. Based on the idCar and random number r, the delegated user computes σ = HSign(skidU,<NUM>, r), and then sends a request containing [<NUM>, idU,<NUM>, idO,<NUM>, PidU,<NUM>, σ] to the car, where <NUM> denotes "delegated user access". Particularly, the delegated user execute the signing algorithm HSign(skidU,<NUM>, r), taking as input the second level authentication key and the random number r, to generate the signature σ. In step <NUM>, the car verifies the PidU,<NUM>, blacklist and σ. In particular, upon receipt of the message, the car first checks whether PidU,<NUM> is still valid, and aborts if PidU,<NUM> does not hold any more. Otherwise, the car checks the blacklist to determine whether idO,<NUM> or idU,<NUM> is revoked, and aborts if it is. Otherwise, the car continues to compute b = HVerify(σ, r, idU,<NUM>, PidU,<NUM>, idO,<NUM>, NULL, GPK). Particular, the car executes the signature verification algorithm, HVerify(σ, r, idU,<NUM>, PidU,<NUM>, idO,<NUM>, NULL, GPK), taking as input the signature σ, the random number r, the ID of the second device, the PidU,<NUM>, the ID of the first device, and GPK. If b = <NUM>, the car grants the access, e.g., open the car door. Otherwise, the car rejects granting access.

The user revocation remains the same as the first embodiment.

The following third embodiment presents another instantiation based on digital signature. The digital signature scheme consists of the following algorithms:.

Based on the digital signature scheme, the instantiation can be described using <FIG>. All the assumptions in the first embodiment remain, unless otherwise specified.

Step <NUM> is modified such that the car would generate a secret key (SKC) by executing KeyGen(<NUM>k) to generate a pair of keys (PKC, SKC). The car then stores the SKC securely in the secure storage module while leaving PKC public.

Step <NUM> is modified such that car owner executes KeyGen(<NUM>k) to generate a pair of keys (PKO, SKO) for the car owner; transmits the public key of the car owner, PKO, to car; and stores the private key, SKO, securely in secure storage module. Step <NUM> is modified such that in response to receiving the public key of the car owner PKO from the car owner, the car executes the signing algorithm, Sign(SKC, PKO) taking as input the SKC, and the public key of the car owner to generate σC,O where σC,O serves as a digital certificate for the PKO. The digital certificate is transmitted to the car owner in step <NUM>. In an alternative embodiment, the car owner digital certificate σC,O and the pair of keys for the car (PKC, SKC) are not required when a whitelist containing the public key of the car owner PKO is maintained in the car.

In step <NUM>, instead of computing vd, the car owner generates σ instead. Particularly, the car owner taps his/her mobile device to the car and receives the broadcast message containing ID idCar and a random number r. Based on the idCar and random number r, the car owner executes the signing algorithm, Sign(SKO, r) taking as input the private key of the car owner, SKO and the random number r to generate σ, and then sends [<NUM>, PKO, σC,O, σ] to the car, where <NUM> denotes "owner access". In step <NUM>, the car verifies the blacklist and σ. In particular, the car checks the blacklist to determine whether PKO is revoked, and aborts if it is. If the PKO is not in the blacklist, the car continues to execute both a first verification algorithm, Verify(σC,O, PKO, PKC) taking as input the signature σC,O, the public key of the car owner and the public key of the car and a second verification algorithm, Verify(σ, r, PKO) taking as input the signature σ, the random number r, the public key of the car owner, and grant the access if both output <NUM>. Otherwise, the car rejects granting access. In the alternative embodiment, steps <NUM>-<NUM> would be modified such that the car owner sends [<NUM>, PKO, σ] to the car, where σ = Sign(SKO, r). In response, the car would check whether PKO is in the whitelist. If PKO is in the whitelist, the car continues to verify σ by executing the second verification algorithm, Verify(σ, r, PKO) taking as input the signature σ, the random number r, the public key of the car owner, and grant the access result from the second verification algorithm is <NUM>. Otherwise, the car rejects granting access.

Step <NUM> is modified such that the delegated user executes KeyGen(<NUM>k) to generate a pair of keys (PKU, SKU); transmits public key PKU to car owner; and stores the private key SKU securely in secure storage module. Step <NUM> is modified such that in response to receiving PKU from the delegated user, the car owner determines an access policy PU and executes the signing algorithm Sign(SKO, PKU∥PU) taking as input the SKO, and the public key of the delegated user and the access policy PKU∥PU to generate σO,U where σO,U serves as a digital certificate for the PKU. The digital certificate σO,U together with the PKO and σC,O are transmitted to the delegated user via either direct delivery or remote delivery in step <NUM>. In the alternative embodiment, step <NUM> would be modified such that the digital signature of the car owner σC,O is not transmitted to the delegated user.

In step <NUM>, instead of computing vd, the delegated user generates σ instead. Particularly, the delegated user taps his/her mobile device to the car and receives the broadcast message containing ID idCar and a random number r. Based on the idCar and random number r, the delegated user executes the signing algorithm, Sign(SKU, r) taking as input the private key of the delegated user, SKU and the random number r, to generate σ and then sends a request containing [<NUM>, PKU, PU, σO,U, PKO, σC,O, σ] to the car, where <NUM> denotes "delegated user access". In step <NUM>, the car verifies the PKO, PU, blacklist and σ. In particular, upon receipt of the message, the car first checks whether PU is still valid, and aborts if PU does not hold any more. Otherwise, the car checks the blacklist to determine whether PKO or PKU is revoked, and aborts if it is. Otherwise, the car continues to execute a third signature verification algorithm Verify(σC,O, PKO, PKC) taking as input the signature σC,O, the public key of the car owner, and the public key of the car, a fourth signature verification algorithm Verify(σO,U, PKU∥PU, PKO) taking as input the signature σO,U, the public key of the delegated user and the policy PKU∥PU, and the public key of the car owner, and a fifth signature verification algorithm Verify(σ, r, PKU) taking as input the signature σ, the random number r, the public key of the delegated user. If all return <NUM>, the car grants the access, e.g., open the car door. Otherwise, the car rejects granting access. In the alternative embodiment, step <NUM> would be modified such that the delegated user sends a request containing [<NUM>, PKU, PU, σO,U, PKO, σ]. In step <NUM>, the car will first check: <NUM>) whether PKO is in the whitelist; <NUM>) whether PU is still valid; <NUM>) whether PKO or PKU is in the blacklist. If the PKO is in the whitelist, PU is still valid and PKO or PKU is not in the blacklist, the car continues to verify σO,U by executing a signature verification algorithm, Verify(σO,U, PKU, PKO) taking as input the digital signature of the delegated user σO,U, the public key of the delegated user PKU, the public key of the car owner PKO. and verify σ, by executing another signature verification algorithm, Verify(σ, r, PKU) taking as input the signature σ, the random number r, the public key of the user PKU. If all return <NUM>, the car grants the access, e.g., open the car door. Otherwise, the car rejects granting access.

Claim 1:
A key generating method for a vehicle access authentication framework having a first device (<NUM>, <NUM>) operated by a vehicle owner, a second device (<NUM>) operated by a delegated user, and a third device (<NUM>) residing in a vehicle, wherein the first device (<NUM>, <NUM>) and the second device (<NUM>) are mobile devices; characterised in that the method is performed by the first device (<NUM>, <NUM>), and comprises:
running (<NUM>) an application to initiate the third device (<NUM>);
transmit (<NUM>) a first request to generate a new secret key K to the third device (<NUM>);
sending (<NUM>) a second request for an authentication key to the third device (<NUM>), the second request for the authentication key comprising an ID of the first device (<NUM>, <NUM>), idO;
receiving (<NUM>) an authentication key KidO from the third device (<NUM>) and store the authentication key KidO in a secured memory (<NUM>); wherein the authentication key KidO is used for the first device accessing the vehicle, and KidO = h(K, idCar, idO), where h(.) is a cryptographic hash function, idCar is an ID of the third device, K is the new secret key;
generating (<NUM>) a delegated authentication key KidU , where KidU = h(KidO, idU, PU), in response to receiving a request for delegated authentication key from the second device (<NUM>), the request for delegated authentication key comprising an ID of the second device (<NUM>); wherein idU is the ID of the second device (<NUM>), and PU is an access policy determined by the first device; and
transmitting (<NUM>) the delegated authentication key to the second device (<NUM>) for the second device (<NUM>) to access the vehicle.