Digital key control system

Abstract

A digital key control system is provided. A control system for controlling a digital key system of a vehicle at a mobile device wherein the digital key system is implemented according to a predetermined vehicle digital key specification to enable one or more vehicle functions to be performed at the vehicle without using a physical key of the vehicle, and wherein the control system, when executed by the processor of the mobile device, is arranged to: communicate with the digital key system via the at least one short range communication protocol according to a predetermined vehicle digital key specification to cause execution of at least one of the one or more vehicle functions; and providing, at the mobile device, a secure software runtime environment for the control system to perform one or more secure operations including the control system acting as a software root of trust for execution of at least one of the one or more vehicle functions according to a predetermined vehicle digital key specification.

Description

Technical Field

[0001] The present invention relates to a control system for use at a mobile device to control a digital key system of a vehicle. Background Art

[0002] Keyless systems (also known as remote keyless systems or keyless vehicle systems) have been widely used in the automotive field for both consumer and commercial vehicles, such as for one or more of the following: (i) keyless entry / access to the vehicle; (ii) keyless ignition of the vehicle engine; (iii) keyless starting of an electric vehicle motor; etc. Such keyless systems replace the need to unlock a physical lock with a physical key, and instead use a keyless remote control (or passive fob) to authorize unlocking (or another function) of the vehicle based on the keyless remote's proximity to the vehicle itself (or presence inside the vehicle). Such keyless remote controls typically communicate with the vehicle via short-range radio transmissions, with the keyless remote control acting as a transponder.

[0003] Such systems provide improved convenience to the user, who can enter and often start the vehicle without having to interact with the keyless fob, which only needs to be with the user. They also provide reliability improvements over physical lock and key systems, where weather conditions (such as cold temperatures) may cause the physical lock to become inoperable, for example due to ice on the keyhole.

[0004] One drawback of remote keyless systems is that they traditionally require dedicated hardware, in the form of a keyless fob, for each specific vehicle. Additionally, to maintain the security of the system, an initial secure pairing of the keyless fob and vehicle is typically performed by the original equipment manufacturer (OEM) - however, this makes replacement or repair of the keyless fob difficult and expensive.

[0005] Recent developments in remote keyless systems have enabled common mobile devices (such as smartphones) to take on the role of keyless remote controls, typically using built-in communication systems or protocols such as near field communication (NFC) or Bluetooth. This is driven in part by the changing needs and attitudes of drivers, who expect to use smart devices as keys to allow them to lock, unlock, start the engine, and share access to the vehicle, etc. Such mobile devices can store and use digital keys, which are used to interact with a keyless vehicle system at the vehicle to provide such (physical) keyless functionality for the vehicle.

[0006] A digital key protocol is provided by the Car Connectivity Consortium (CCC). CCC is a cross-industry standards organization that aims to create a system that standardizes interface technology to provide a consistent and good user experience across vehicles and mobile devices. CCC members include companies such as smartphone manufacturers, vehicle manufacturers, automotive Tier 1 suppliers, silicon / chip manufacturers, security product suppliers, etc. CCC has released various specifications aimed at achieving the above goals. More details of CCC and CCC specifications can be found, for example, at https: / / carconnectivity.org / about / and https: / / carconnectivity.org / digital-key-release-3-0-specification-download / , the entire disclosure of which is incorporated herein by reference.

[0007] Various versions of the CCC specification already exist:

[0008] Digital Key 1.0 was released in June 2018: Version 1.0 of the specification provides a common deployment method that allows vehicle OEMs to securely migrate digital key implementations to mobile devices using existing Trusted Service Manager (TSM) infrastructure. It provides secure vehicle access by leveraging NFC distance limitations and a direct link to the secure element of the mobile device.

[0009] Digital Key 2.0 was released in May 2020: The 2.0 version of the specification is based on the use of NFC as the underlying radio technology to implement digital key services. In principle, this digital key management framework is designed to be independent of the radio technology, so that the framework can be extended to support other technologies.

[0010] Digital Key 3.0, released in July 2021: Version 3.0 expands on Version 2.0 by implementing location-aware features using (in addition to NFC) Bluetooth Low Energy (BLE) combined with Ultra-Wideband (UWB) wireless connectivity to provide digital key functionality and allow secure location with an accuracy equal to or better than existing passive key fobs.

[0011] In the attached figure Figure 1 The digital key system according to the CCC specification is schematically shown. The system is composed of various links (or connections or interfaces) - in particular, standardized links ( Figure 1 Solid lines in the ) and / or proprietary links ( Figure 1The CCC specification is composed of multiple participants / entities connected to each other (dashed connecting lines in the figure). The standardized links are fully specified in the CCC specification to enable implementation and interoperability. The entities, standardized links and proprietary links are described below to provide an overview of the high-level functionality of the system. Of course, further details can be found in the CCC specification if necessary, and it will certainly be appreciated that technicians in this field will be very familiar with such traditional CCC systems.

[0012] In this system, the vehicle is linked to the vehicle OEM server via the telematics link 1. This link provides a secure communication channel and is fully controlled by the vehicle OEM.

[0013] The vehicle is equipped with an NFC reader and optional Bluetooth (BLE) and / or UWB module to communicate with a mobile device via links 3, 4 in the case of an NFC connection or via links 11, 12 in the case of a BLE / UWB connection for owner pairing, vehicle lock / unlock, and engine start.

[0014] The owner device (or mobile device) communicates with the owner device OEM server using proprietary link / method 2. The owner device can also communicate directly with the vehicle OEM server using a proprietary vehicle OEM API via link 10. Similarly, a friend device (another mobile device) can communicate directly with the vehicle OEM server using a proprietary vehicle OEM API via link 9.

[0015] The owner / friend device OEM server is responsible for managing the lifecycle of the digital key applet of the owner / friend device, and updates the necessary digital certificates in the owner / friend device via link 2 / 7. It can provide services to suspend, resume and erase the digital key when the mobile device is lost or stolen.

[0016] The vehicle OEM server hosts user accounts and manages identification and authentication functions (e.g., for the vehicle and / or owner / friend device). It can also connect to an optional key tracking server via link 5 to register digital keys issued for the vehicle, e.g., to help preserve / ensure the privacy of stored information (digital keys).

[0017] · Owner device OEM servers do not directly connect to other device OEM servers.

[0018] The owner device can share a digital key with a friend device (via links 2, 6, 8, and 7), which defines appropriate access policies and can terminate the shared digital key when it is no longer needed / desired. The friend device can host the digital key shared by the owner, but cannot re-share such a shared digital key with any other mobile device.

[0019] Friend device and its friend device OEM server Link 7 supports necessary certificate services as in Link 2. Device OEM or vehicle OEM may facilitate device replacement, but this is outside the scope of the CCC specification.

[0020] The interface between the vehicle OEM server and the owner / friend device OEM server 6 / 8 is used to exchange server credentials, key sharing, key tracking, key expiration and notification.

[0021] In the attached figure Figure 2 Schematic diagram showing the participation Figure 1 functional elements of a mobile device of a system (e.g., Figure 1 In particular, the mobile device includes:

[0022] Safety element (or equivalent)

[0023] οJava Card and Global Platform support

[0024] ο Global Platform Card Specification Amendment C and Global Platform Contactless Extension

[0025] οStandard symmetric and asymmetric encryption support

[0026] ο Managed digital key applet

[0027] Digital Key Mini Program

[0028] οEscrow digital key

[0029] ο Implement relevant (express and standard) transactions

[0030] ο Implement instance CA (conditional access) to support offline use cases and privacy protection

[0031] oStore anti-theft tokens, offline proofs, access policies, and other data associated with the digital key when needed by the vehicle

[0032] οVerify the identity / authenticity of the vehicle

[0033] οVerify the certificate chain of the friend's public key

[0034] Digital key framework

[0035] ο Implement key features: owner pairing, digital key sharing, and management

[0036] o Provides universal digital key service functionality via a set of OS-specific APIs for vehicle OEM applications

[0037] Local Apps

[0038] o Mobile device native application that provides device native user interface such as digital key creation, digital key termination and deletion, digital key enable / disable, etc.

[0039] οDisplay a list of issued owner / friend digital keys

[0040] Vehicle OEM App

[0041] ο Vehicle OEM application is optional. The device itself supports the main features of the application

[0042] οCan support the same features as native apps plus features specific to vehicle OEMs

[0043] ο Provide identification and authentication to vehicle OEM servers

[0044] ο Retrieve the owner pairing code

[0045] οManage keys with non-standard access policies

[0046] CCC systems (e.g. Figure 1 and Figure 2 The system uses asymmetric cryptography to mutually authenticate the vehicle and the remote (mobile) device. Public keys are exchanged by pairing the remote device with the vehicle. The owner / user of the remote device can then authorize other users (such as friends and family members) to use the digital key by signing their public keys. The system supports a variety of features, including:

[0047] Equivalent or better security and privacy than physical keys

[0048] Pairing of owner device and vehicle

[0049] Key sharing between the owner and other users (e.g. friends)

[0050] Interoperability across device and vehicle OEMs

[0051] Support multiple digital keys from different vehicle OEMs on a single mobile device

[0052] Enable vehicle OEMs to control the issuance and policy of digital keys

[0053] Privacy protection against active / passive eavesdroppers

[0054] Another digital key protocol is provided by the Intelligent Connected Car Ecosystem Alliance (ICCE). Some of the major developments and releases of ICCE are:

[0055] September 2020: Release of "ICCE Digital Key System Part 1: General Requirements"

[0056] January 2021: Release of "ICCE Digital Key System Part 2: Bluetooth System Requirements"

[0057] July 2022: Release of "ICCE Digital Key System Part 3: NFC System Requirements"

[0058] More details of ICCE and ICCE system definitions can be found, for example, at https: / / www.icce.cn / web / index and https: / / www.icce.cn / web / technicalRules?urlData=0, the entire disclosures of which are incorporated herein by reference.

[0059] In the attached figure Figure 3 A digital key system according to the ICCE specification is schematically shown. The ICCE system (according to the ICCE specification) is similar to the CCC system (according to the CCC specification) in some aspects, but different in other aspects. For example:

[0060] Similarities:

[0061] CCC and ICCE share the same goal: to create a sustainable and flexible ecosystem that standardizes interface technologies to provide a consistent and good user experience across vehicles and mobile devices

[0062] There are similar actors in the system: vehicle, vehicle NFC reader, vehicle BLE module, vehicle UWB module, vehicle OEM server, device, and device OEM server

[0063] Their standardized interfaces focus on:

[0064] οDigital Key Framework API for Mobile Devices

[0065] οDevice OEM server and vehicle OEM server communication interface

[0066] οAPDU (Application Protocol Data Unit) messages for communication between mobile devices and vehicles via NFC / BLE / UWB

[0067] They offer similar features such as owner pairing, key sharing, passive entry / passive start, RKE (remote keyless entry)

[0068] Differences:

[0069] The CCC specification is a global standard with more members from equipment OEMs, vehicle OEMs, Tier 1, etc., while the ICCE specification is currently a localized standard

[0070] The CCC specification uses asymmetric encryption, while the ICCE specification uses symmetric encryption

[0071] The ICCE specification defines an independent BLE device key protocol, while the CCC specification does not

[0072] The CCC and ICCE specifications have different definitions regarding their standardized interfaces and protocols, and these are not intercompatible

[0073] Of course, it will be appreciated that those skilled in the art will be very familiar with such conventional ICCE systems.

[0074] One of the benefits of the CCC and ICCE specifications (protocols / systems) is that they provide a standard, with CCC / ICCE certification, respectively. In addition, for CCC, a single CCC integration at the vehicle supports any CCC-certified device OEM, and likewise, for ICCE, a single ICCE integration at the vehicle supports any ICCE-certified device OEM. However, there are several disadvantages. For example, (i) in order to utilize device OEM capabilities (mobile device framework, secure element (SE), and device OEM server), the device OEM will charge the vehicle OEM; (ii) digital key ownership and control does not entirely lie with the vehicle OEM, because key management at the mobile device depends on the device OEM; (iii) traditional mobile devices do not support CCC and / or ICCE specifications / protocols; (iv) not all device OEMs will choose to support CCC and / or ICCE specifications / protocols; (v) vehicle OEMs need to integrate and work with each device OEM one by one, which is a lot of technical labor and requires continuous support (e.g., bug fixes) from each device OEM; (vi) device OEMs may only enable / support a limited number of vehicle control features, while vehicle OEMs may want to provide a richer set of vehicle control features; (vii) sharing keys across different mobile device brands or across mobile devices running different operating systems may be difficult, restricted, or impossible. Therefore, it would be desirable to provide a digital key system for providing (physical) keyless vehicle functionality while addressing some or all of these shortcomings of existing systems and implementations. Summary of the invention

[0075] According to a first aspect of the present invention, a control system for controlling a digital key system of a vehicle at a mobile device is provided, wherein the digital key system is implemented according to a predetermined vehicle digital key specification so as to enable one or more vehicle functions to be performed at the vehicle without using a physical key of the vehicle, and wherein the control system, when executed by a processor of the mobile device, is arranged to: communicate with the digital key system via at least one short-range communication protocol according to the predetermined vehicle digital key specification to cause the execution of at least one of the one or more vehicle functions; and provide a secure software runtime environment for the control system at the mobile device to perform one or more security operations, the one or more security operations including the control system acting as a software trust root for the execution of at least one of the one or more vehicle functions according to the predetermined vehicle digital key specification.

[0076] In some embodiments, the control system is arranged to perform one or more security operations independently of any keyless vehicle control functionality provided by the manufacturer of the mobile device.

[0077] In some embodiments, the control system is arranged to perform one or more security operations independently of any keyless vehicle control functionality provided as part of the operating system of the mobile device.

[0078] In some embodiments, the control system is arranged to perform one or more security operations without using a security element of the mobile device to: (a) store data for controlling the digital key system; and (b) execute instructions for implementing control of the digital key system.

[0079] In some embodiments, a secure software runtime environment is provided based on one or more of the following:

[0080] (a) the control system is implemented at least in part using a white box cryptographic algorithm to (i) protect the storage of some or all of the data used to control the digital key system; and / or (ii) protect some or all of the instructions used to implement the control system;

[0081] (b) the control system is implemented at least in part using obfuscation of one or more of: (i) instructions for implementing the control system; (ii) a control flow of the control system; and (iii) runtime data of the control system;

[0082] (c) the control system includes one or more secure storage functions for performing secure storage of one or more cryptographic keys and / or sensitive data;

[0083] (d) the control system is arranged to perform node locking to lock execution of the control system to the mobile device;

[0084] (e) the control system is arranged to perform integrity verification of the control system and / or digital key system; and

[0085] (f) The control system is arranged to perform anti-debugging functions.

[0086] In some embodiments, the control system is arranged so that data received from the vehicle via at least one short-range communication protocol is routed to the control system rather than to a secure element of the mobile device. In some such embodiments, the control system is arranged to perform host card emulation to enable the data to be transmitted from a transceiver of the mobile device implementing the at least one short-range communication protocol to the control system.

[0087] In some embodiments, the predetermined vehicle digital key specification specifies one or more protocols and / or one or more functions and / or one or more requirements that enable one or more vehicle functions to be performed at the vehicle without using a physical key of the vehicle.

[0088] In some embodiments, the predetermined vehicle digital key specification is one of: (a) a Car Connectivity Consortium specification; and (b) a Smart Car Connectivity Industry Ecological Alliance specification.

[0089] In some embodiments, the one or more vehicle functions include one or more of the following:

[0090] (a) physical unlocking and / or physical locking of at least a portion of the vehicle;

[0091] (b) physical opening and / or physical closing of at least a portion of the vehicle;

[0092] (c) starting and / or stopping the engine or motor of the vehicle; and

[0093] (d) Operate the vehicle's auxiliary systems.

[0094] In some embodiments, the at least one short-range communication protocol includes at least one of: a near field communication (NFC) protocol; a Bluetooth Low Energy (BTLE) protocol; and an ultra-wideband (UWB) protocol.

[0095] In some embodiments, the control system acting as a software root of trust includes the control system: storing one or more cryptographic keys; and using the one or more cryptographic keys to authenticate one or more digital signatures and / or issue one or more digital certificates.

[0096] In some embodiments, the control system exposes an API configured to receive commands for controlling the system from an application that can be installed by a user on a mobile device to cause execution of at least one of the one or more vehicle functions. In some such embodiments, the command is based on input provided to the application by a user of the mobile device. Additionally or alternatively, in some such embodiments, the application is a native application of the mobile device. Additionally or alternatively, in some such embodiments, the application is provided at least in part by a vehicle manufacturer.

[0097] In some embodiments, the one or more security operations include one or more of the following:

[0098] (a) authenticating the identity of the vehicle and / or the identity of the digital key system according to predetermined vehicle digital key specifications;

[0099] (b) enabling the digital key system to authenticate the identity of the mobile device and / or the identity of the control system according to predetermined vehicle digital key specifications;

[0100] (c) sharing a digital key at least partially protected by the control system with another mobile device;

[0101] (d) digital key management of one or more encryption keys used in accordance with predetermined vehicle digital key specifications; and

[0102] (e) secure storage of data used for performance of at least one of one or more vehicle functions.

[0103] In some embodiments, the control system, when executed by a processor of the mobile device, is arranged to bind to the vehicle, the binding being controlled by a server in communication with the control system.

[0104] In some embodiments, the mobile device is a smartphone.

[0105] According to a second aspect of the present invention, there is provided an application program installable by a user on a mobile device, the application program comprising a control system according to the above-mentioned first aspect (or any embodiment thereof).

[0106] According to a third aspect of the present invention, an application that can be installed by a user on a mobile device is provided, which is configured to provide one or more commands for the control system to a control system according to the above-mentioned first aspect (or any embodiment thereof) to cause the execution of at least one of one or more vehicle functions.

[0107] According to a fourth aspect of the present invention, a mobile device is provided, which includes a control system according to the above-mentioned first aspect (or any embodiment thereof) and / or an application according to the above-mentioned second aspect or third aspect is installed thereon.

[0108] According to a fifth aspect of the present invention, there is provided a computer readable medium storing a set of instructions, which together implement a control system according to the above first aspect (or any embodiment thereof). BRIEF DESCRIPTION OF THE DRAWINGS

[0109] Embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

[0110] Figure 1 A digital key system according to the CCC specification is schematically shown;

[0111] Figure 2 Schematic diagram showing the participation Figure 1 Functional elements of a mobile device of a system;

[0112] Figure 3 Schematically illustrates a digital key system according to ICCE specifications;

[0113] Figure 4 A system according to an embodiment of the present invention is schematically shown;

[0114] Figure 5a An example hardware implementation of a computer system suitable for a server is schematically shown;

[0115] Figure 5b schematically illustrates an example hardware implementation of a mobile device; and

[0116] Figure 6 A specific example of an embodiment of the present invention is schematically shown, which is configured for use with an Android operating system of a mobile device associated with a CCC system. DETAILED DESCRIPTION

[0117] In the following description and in the accompanying drawings, certain embodiments of the present invention are described. However, it will be appreciated that the present invention is not limited to the described embodiments, and some embodiments may not include all of the features described below. However, it will be apparent that various modifications and changes may be made herein without departing from the broader spirit and scope of the present invention as set forth in the appended claims.

[0118] Figure 4 Schematically, a system 400 according to an embodiment of the present invention is shown. System 400 includes a mobile device 402 and a vehicle 404. Mobile device 402 may be, for example, a smartphone. Mobile device 402 is "mobile" in the sense that it is carried / worn / held by a (human) operator. Vehicle 404 may be any consumer or commercial vehicle, such as a car, van, truck, camper, motorcycle, etc.

[0119] The vehicle 404 includes a digital key system implemented according to a predetermined vehicle digital key specification ( Figure 4 404). The predetermined vehicle digital key specification will enable one or more vehicle functions to be performed at the vehicle 404 without using a physical key of the vehicle 404. For example, the predetermined vehicle digital key specification specifies one or more protocols and / or one or more functions and / or one or more requirements that enable one or more vehicle functions to be performed at the vehicle 404 without using a physical key of the vehicle 404 - for example, the predetermined vehicle digital key specification may be a CCC specification or an ICCE specification, as discussed above, although it will be appreciated that any other digital key standard or specification (currently known or developed in the future) may be used instead. Therefore, as discussed above, the vehicle's digital key system provides keyless functionality at the vehicle 404. Likewise, the one or more vehicle functions may include one or more of the following: (a) physical unlocking and / or physical locking of at least a portion of the vehicle 404 (e.g., one or more doors, luggage compartment / trunk, glove box / compartment, etc.); (b) physical opening and / or physical closing of at least a portion of the vehicle 404 (e.g., one or more doors, luggage compartment / trunk, glove box / compartment, etc.); (c) starting and / or stopping the engine or motor of the vehicle 404 (e.g., controlling the ignition of a gasoline / diesel engine or starting / stopping the electric drive motor of an electric vehicle); (d) operating an auxiliary system of the vehicle 404 (e.g., flashing lights or making noises to enable a user to locate the vehicle 404; controlling the air conditioning system of the vehicle 404; controlling the audio / video / entertainment system of the vehicle 404; etc.); (e) etc. Since the in-vehicle digital key system, the corresponding predetermined vehicle digital key specifications, and the keyless vehicle functions are well known (as described above), they will not be described in more detail herein.

[0120] Embodiments of the present invention are intended to enable vehicle OEMs to deploy their in-vehicle digital key systems without relying on mobile device OEMs, i.e., vehicle OEMs can manufacture / provide vehicles 404 with vehicle functions (such as lock / unlock, engine / motor start / stop, etc.) controlled by a control system 406 at a mobile device 402, wherein the control system 406 is independent of (or unaware of) the mobile device OEM (i.e., no specific functions need to be provided or exhibited by the mobile device OEM to provide digital key functions). As discussed above, this provides many technical advantages, such as: users are able to use any brand of mobile device 402 they wish in conjunction with the vehicle 404 (and users do not have to purchase different mobile devices 402 to ensure compatibility with newly purchased vehicles 404); users are able to use legacy mobile devices that do not support digital key functions by the mobile device OEM; easier integration, maintenance, and support at the vehicle OEM (vehicle OEMs do not need to integrate with and support multiple proprietary systems or requirements of multiple mobile device OEMs); and the like.

[0121] Thus, the mobile device 402 has a control system 406 for controlling the digital key system of the vehicle 404. In particular, the control system 406 may be implemented in software (i.e., as one or more instructions and / or one or more computer programs and / or one or more modules). When executed by the processor of the mobile device 402, the control system 406 is arranged to:

[0122] (a) communicating with a digital key system of a vehicle 404 via at least one short-range communication protocol to cause execution of at least one of the one or more vehicle functions in accordance with predetermined vehicle digital key specifications; and

[0123] (b) providing a secure software runtime environment for the control system 406 at the mobile device 402 to perform one or more security operations, the one or more security operations including the control system 406 acting as a software root of trust for execution of at least one of the one or more vehicle functions according to predetermined vehicle digital key specifications.

[0124] Details of such provision of such functionality by control system 406 will be described later.

[0125] The one or more security operations may be functions for implementing predetermined vehicle digital key specifications or any functions for keyless vehicle functions. For example, the one or more security operations may include one or more of the following:

[0126] (a) authenticating the identity of the vehicle 404 and / or the identity of the digital key system according to predetermined vehicle digital key specifications;

[0127] (b) enabling the digital key system to authenticate the identity of the mobile device 402 and / or the identity of the control system 406 according to predetermined vehicle digital key specifications;

[0128] (c) sharing a digital key at least partially protected by control system 406 with another mobile device;

[0129] (d) digital key management of one or more encryption keys used in accordance with predetermined vehicle digital key specifications; and

[0130] (e) secure storage of data used for performance of at least one of one or more vehicle functions.

[0131] In some embodiments, the control system 406 may optionally be arranged to communicate with one or more servers 410, 412 (or server systems) via one or more communication networks 408 (such as one or more of the Internet, a telecommunications network, a satellite communication network, a local area network, etc.). The purpose of the one or more servers 410, 412 will be described later.

[0132] As will be described in more detail later, in some embodiments the control system 406 is arranged to interact with, or present an interface to, another application 414 installed on the mobile device 402 .

[0133] Figure 5a An example hardware implementation of a computer system 500 suitable for each of one or more servers 410, 412 is schematically shown. The system 500 includes a computer 502. The computer 502 includes: a storage medium 504, a memory 506, a processor 508, a device interface 510, a user interface 512, and a network interface 516. Each of these components can be arranged to communicate with one or more of the other components via one or more communication buses 518 of the computer 502.

[0134] The storage medium 504 may be any form of non-volatile data storage device, such as one or more of a hard drive, a magnetic disk, a solid-state storage device, an optical disk, a ROM, etc. The storage medium 504 may store an operating system for the processor 508 to execute in order to operate the computer 502. The storage medium 504 may also store one or more computer programs (or software or instructions or codes).

[0135] The memory 506 may be any random access memory (storage unit or volatile storage medium) suitable for storing data and / or computer programs (or software or instructions or code).

[0136] The processor 508 may be any data processing unit suitable for executing one or more computer programs (such as those stored on the storage medium 504 and / or in the memory 506), some of which may be computer programs according to embodiments of the present invention, or computer programs that, when executed by the processor 508, cause the processor 508 to implement a method according to an embodiment of the present invention and configure the system 500 as a system according to an embodiment of the present invention. The processor 508 may include a single data processing unit, or multiple data processing units operating in parallel, individually, or in cooperation with each other. When implementing data processing operations of embodiments of the present invention, the processor 508 may store data to the storage medium 504 and / or the memory 506, and / or read data from the storage medium 504 and / or the memory 506.

[0137] The device interface 510 can be any unit for providing an interface to the device 522, which is external to or removable from the computer 502. The device 522 can be a data storage device, such as one or more of an optical disk, a magnetic disk, a solid-state storage device, etc. The device 522 can have processing capabilities - for example, the device 522 can be a smart card. Therefore, the device interface 510 can access data from the device 522, provide data to the device 522, or interface with the device 522 according to one or more commands it receives from the processor 508.

[0138] The user interface 512 is arranged to receive input from a user or operator of the system 500. The user provides the input via one or more input devices of the system 500, such as a mouse (or other pointing device) 526 and / or a keyboard 524, connected to or in communication with the user interface 512. However, it will be appreciated that the user may provide input to the computer 502 via one or more additional or alternative input devices, such as a touch screen. The computer 502 may store input received from the input devices via the user interface 512 in the memory 506 for subsequent access and processing by the processor 508, or may pass it directly to the processor 508 so that the processor 508 may respond accordingly to the user input.

[0139] The user interface 512 is also arranged to provide graphical / visual and / or auditory output to a user or operator of the system 500. As such, the processor 508 may be arranged to instruct the user interface 512 to form an image / video signal representing the desired graphical output and provide the signal to a monitor (or screen or display unit) 520 of the system 500 connected to the user interface 512. Additionally or alternatively, the processor 508 may be arranged to instruct the user interface 512 to form an audio signal representing the desired audio output and provide the signal to one or more speakers 521 of the system 500 connected to the user interface 512.

[0140] Finally, the network interface 516 provides functionality for enabling the computer 502 to download data from and / or upload data to one or more data communications networks. This may be via wired communications and / or wireless communications.

[0141] You will understand that in Figure 5a The architecture of the system 500 shown in FIG. 1 and described above is merely exemplary, and embodiments of the present invention may use systems with different architectures (e.g., systems with more Figure 5a Fewer components than shown in the Figure 5a 502) with additional components and / or alternative components compared to the components shown in FIG. 502. As an example, computer system 500 may include one or more of the following: a personal computer; a server computer; etc. Additionally, it is possible that some components of computer system 500 are not located in computer 502, and instead, are part of a computer network connected to computer 502 via network interface 516. Additionally or alternatively, computer system 500 may include multiple computers 502, such as in a network of computers such as a cloud system of computing resources.

[0142] Figure 5b Schematically illustrated is an example hardware implementation of a mobile device 402. The mobile device 402 includes a storage medium 554, a memory 556, a processor 558, a secure element 580, a telecommunications module 590, a user interface 562, and a short-range (radio) communication module 566. Each of these components may be arranged to communicate with one or more of the other components via one or more communication buses 568 of the mobile device 402.

[0143] The storage medium 554 may be any form of non-volatile data storage device, such as one or more of a solid-state storage device, ROM, etc. The storage medium 504 may store an operating system for execution by the processor 558 to operate the mobile device 402. The storage medium 554 may also store one or more computer programs (or software or instructions or codes).

[0144] The memory 556 may be any random access memory (storage unit or volatile storage medium) suitable for storing data and / or computer programs (or software or instructions or code).

[0145] The processor 558 may be any data processing unit suitable for executing one or more computer programs (such as computer programs stored on the storage medium 554 and / or in the memory 556), some of which may be computer programs according to embodiments of the present invention, or may be computer programs that, when executed by the processor 558, cause the processor 558 to implement a method according to an embodiment of the present invention and configure the mobile device 402 as a system according to an embodiment of the present invention. The processor 558 may include a single data processing unit, or multiple data processing units operating in parallel, independently, or in cooperation with each other. When implementing data processing operations of embodiments of the present invention, the processor 558 may store data to the storage medium 554 and / or the memory 556 and / or read data from the storage medium 554 and / or the memory 556.

[0146] The security element 580 is typically provided by the mobile device OEM in the mobile device it manufactures. The security element 580 provides tamper-resistant hardware and is used to provide / enable secure processing and data storage functions (e.g., secure storage of encryption keys, secure execution of encryption operations such as encryption, decryption, signature generation and verification) to the mobile device 402. Further details of the security element (SE) can be found at, for example, https: / / en.wikipedia.org / wiki / Secure_element, and its entire disclosure is incorporated herein by reference. The security element 580 is typically used by the device OEM to support encryption operations in the device OEM's proprietary solution to provide keyless vehicle functionality.

[0147] The telecommunications module 590 may be arranged to perform telecommunications communications in accordance with any well-known telecommunications protocols / standards, such as one or more standards provided by the International Telecommunication Union (ITU).

[0148] The user interface 562 is arranged to receive input from a user or operator of the mobile device 402. The user may provide the input via one or more mechanisms, such as a touch screen of the mobile device 402, a microphone of the mobile device 402 for receiving audio / voice input from the user, a keyboard forming part of the mobile device 402, etc. However, it will be appreciated that the user may provide input to the mobile device 402 via any other mechanism. The mobile device 402 may store the input received via the user interface 562 in the memory 556 for subsequent access and processing by the processor 558, or may pass it directly to the processor 558 so that the processor 558 may respond to the user input accordingly.

[0149] The user interface 562 is also arranged to provide graphical / visual and / or audio output to a user or operator of the mobile device 402. As such, the processor 558 may be arranged to instruct the user interface 562 to form an image / video signal representative of a desired graphical output and provide the signal to a screen of the mobile device 402. Additionally or alternatively, the processor 558 may be arranged to instruct the user interface 562 to form an audio signal representative of a desired audio output and provide the signal to one or more speakers of the mobile device 402.

[0150] Finally, the short-range (radio) communication module 566 includes one or more transceivers for performing short-range wireless communications via one or more corresponding protocols, such as one or more of the following: (a) near field communication (NFC) protocol; (b) Bluetooth low energy (BTLE) protocol; ultra-wideband (UWB) protocol; (d) and the like.

[0151] You will understand that in Figure 5b The architecture of the mobile device 402 shown in FIG. 1 and described above is exemplary only, and different architectures (e.g., having a Figure 5b Fewer components than shown in the Figure 5b Other mobile devices 402 (with additional components and / or replacement components compared to the components shown in FIG. 4 ) may be used in embodiments of the present invention. As an example, the mobile device 402 may include one or more of the following: a smart phone; a tablet computer; a personal digital assistant; a smart watch; etc.

[0152] As described above, using an embodiment of the present invention, the control system 406 of the mobile device 402 is arranged to communicate with the digital key system of the vehicle 404 via at least one short-range communication protocol according to a predetermined vehicle digital key specification to cause the execution of at least one of the one or more vehicle functions. To this end, the control system 406 utilizes the short-range (radio) communication module 566 so that data / commands can be transmitted between the control system 406 and the digital key system of the vehicle 404 via one or more transceivers of the short-range (radio) communication module 566 and one or more corresponding transceivers of the vehicle 404.

[0153] Some mobile device OEMs arrange to route data received at the transceiver of the short-range (radio) communication module 566 directly to the secure element 580 for subsequent processing, rather than being routed to the processor 558, storage medium 554, or memory 556. This may apply to some or all of the short-range communication protocols being used by the mobile device 402 - for example, under the Android framework, data received via NFC is routed to the secure element 480, while Android does not route data received via BLE and UWB in this manner, and allows third-party applications to access the interfaces to the BLE and UWB transceivers to obtain data therefrom. Routing data directly to the secure element 480 is typically a deliberate choice by the mobile device OEM to ensure the security of the data / communication / processing when the short-range (radio) communication module 566 is intended to be used to process sensitive information (e.g., payment transactions via NFC). Therefore, in view of the above-mentioned purpose of attempting to make the control system 406 independent of the implementation / method of the mobile device OEM, in some embodiments of the present invention, the control system 406 is arranged so that data received from the vehicle 404 via at least one short-range communication protocol is routed to the control system 406, rather than being routed to the secure element 580 of the mobile device 402. This can be achieved in various ways. For example, the control system 406 can be arranged to perform host card emulation to enable data to be transmitted from a transceiver of the mobile device 402 (e.g., an NFC or BLE or UWB transceiver of the short-range (radio) communication module 566) that implements at least one short-range communication protocol to the control system 406. Host card emulation is well known - see, for example, https: / / en.wikipedia.org / wiki / Host_card_emulation, the entire disclosure of which is incorporated herein by reference. Data transmission between the control system 406 and the digital key system of the vehicle 404 remains protected (e.g., protected by security / encryption mechanisms / protocols set forth in the predetermined vehicle digital key specifications) - it is just that such protected data received at the mobile device 402 can be routed to the control system 406 rather than the secure element 480, thereby eliminating dependence on the mobile device OEM's implementation, and the restricted exposure use of the secure element 480.

[0154] Of course, it is important to implement the control system 406 in a secure manner - after all, if an attacker (or malicious entity) is able to gain unauthorized access to or use of the control system 406, then the attacker may be able to gain unauthorized access to or use of the vehicle 404, share the digital key with other mobile devices in an unauthorized manner, prevent legitimate users of the mobile device 402 or vehicle 404 from being able to access or operate the vehicle 404, and so on.

[0155] The mobile device OEM may be able to provide their own security, such as by providing functionality via a proprietary operating system executing on the mobile device 402, or functionality installed by the mobile device OEM using the secure element 580 of the mobile device 402 (which is limited to mobile devices 402 manufactured by the OEM). However, in view of the above-mentioned purpose of attempting to make the control system 406 independent of the implementation / method of the mobile device OEM, the control system 406 according to embodiments of the present invention is preferably arranged to perform one or more security operations independently of any keyless vehicle control functionality provided by the manufacturer (OEM) of the mobile device 402. Likewise, the control system 406 according to embodiments of the present invention is preferably arranged to perform one or more security operations independently of any keyless vehicle control functionality provided as part of the operating system of the mobile device 402. Likewise, the control system 406 according to embodiments of the present invention is preferably arranged to perform one or more security operations without using the secure element 580 of the mobile device 402 for: (a) storing data for controlling the digital key system; and (b) executing instructions for implementing control of the digital key system. With this in mind, the control system 406 executes as a software application (on the processor 558 , ie, external to the secure element 580 ) and is separate from the keyless vehicle control functionality provided by the mobile device OEM or by the operating system of the mobile device 402 .

[0156] With this in mind, as described above, the control system 406 is arranged to provide a secure software runtime environment for the control system 406 at the mobile device 402 to perform one or more security operations, the one or more security operations including the control system 406 acting as a software root of trust according to a predetermined vehicle digital key specification to perform at least one of the one or more vehicle functions. The provision of the secure software runtime environment can be provided in a number of different ways, such as based on one or more of the following:

[0157] (a) the control system 406 is (or has been) implemented or protected at least in part using a white box cryptographic algorithm to (i) protect the storage of some or all of the data used to control the digital key system; and / or (ii) protect some or all of the instructions used to implement the control system 406;

[0158] (b) control system 406 is being (or has been) implemented at least in part using obfuscation of one or more of: (i) instructions for implementing control system 406; (ii) a control flow of control system 406; and (iii) runtime data of control system 406;

[0159] (c) the control system 406 includes one or more secure storage functions for performing secure storage of one or more encryption keys and / or sensitive data;

[0160] (d) the control system 406 is arranged to perform node locking to lock the execution of the control system 406 to the mobile device 402;

[0161] (e) the control system 406 is arranged to perform integrity verification on the control system 406 and / or digital key system of the vehicle 404; and

[0162] (f) The control system 406 is arranged to perform anti-debugging functions.

[0163] For example, the control system 406 can be considered to be executed in a so-called "white box" attack environment. The white box attack environment is an attack model for the execution of a software project (such as the control system 406), wherein the model identifies that the attacker has various capabilities, as described in more detail below (i.e., the attacker can perform certain actions / operations and has access to certain data). Therefore, if the attacker will have those capabilities when the software project is actually executed in a specific execution environment (e.g., using a specific computer / processor, etc.), then it can be said that the software project is being executed in a "white box" environment. In a white box attack environment, the attacker of the software project is assumed to have full access and visibility to the data being operated (including intermediate values), memory contents, and the execution / process / control flow of the software project. In addition, in a white box attack environment, the attacker is assumed to be able to modify the data being operated, memory contents, and the execution / process / control flow of the software project, such as by using a debugger-in this way, the attacker can experiment on the software project and attempt to manipulate the operation of the software project, with the purpose of bypassing the originally intended function and / or identifying secret information and / or for other purposes.

[0164] However, the software project may need to use or store or generate secret information (e.g., one or more cryptographic keys or identifiers), where the information needs to remain hidden from an attacker, or not be usable / accessible by an attacker (except as part of the correct / intended functionality of the software project); the software project may need to execute different parts of the code based on specific decision logic, where it is important to ensure that an attacker cannot violate the decision logic to force the software to execute one part of the code instead of another part of the code; etc. This is particularly true for the control system 406 as it performs the operation of the keyless vehicle function. The provider of the software project does not necessarily know (or does not fully know) and / or cannot control (or cannot fully control) the settings, configuration, and capabilities of the system on which such software project is to be executed, and therefore it can be assumed that the software project may eventually be executed in a white box attack environment. This is particularly relevant when a software project is written in a scripting language or interpreted language (such as JavaScript) due to the human-readable nature of such languages ​​(as opposed to, say, compiled binary executables) - attackers can easily view, monitor and modify the execution of such software projects (e.g., during interpretation or after just-in-time compilation), which makes it easy for attackers to copy and modify the software project and / or its data or control flow in an attempt to launch attacks against / using the software project. This is why many software protection techniques have been developed - such protection techniques can be applied to software projects in order to generate protected software projects, the purpose of which is to make it difficult for an attacker to carry out a successful attack on the protected software project, and / or the purpose of which is to reduce / mitigate the consequences of such an attack by an attacker - i.e., to protect the initial software project from attacks in a white-box environment.

[0165] With this in mind, the control system 406 is a software project to which one or more such software protection techniques have been applied, thereby ensuring that the control system 406 can provide a secure software runtime environment, i.e., it is a protected software project that is therefore executable by the processor 558 of the mobile device 402 and does not need to rely on the hardware security provided by the secure element 580. Many such software protection techniques (referred to herein as "protection") can be used to implement the control system 406 so that the control system 406 is arranged to provide a secure software runtime environment, such as one or more of camouflage techniques, homomorphic data transformation, control flow transformation, white box cryptographic algorithms, key hiding, program interlocking, and boundary mixing. For example:

[0166] There are many techniques, referred to herein as "white-box obfuscation techniques", for transforming an initial software project so that it is resistant to white-box attacks (i.e., attacks that may be launched or available in a white-box attack environment). Examples of such white-box obfuscation techniques can be found in "White-Box Cryptography and an AES Implementation", S. Chow et al, Selected Areas in Cryptography, 9. th Annual International Workshop, SAC 2002, Lecture Notes in Computer Science 2595 (2003), p250-270 and "A White-box DES Implementation for DRM Applications", S. Chow et al, Digital Rights Management, ACM CCS-9 Workshop, DRM 2002, Lecture Notes in Computer Science 2696 (2003), p1-15, the entire disclosure of which is incorporated herein by reference. Additional examples can be found in US61 / 055694, EP4024755, EP3998738, WO2021 / 032792 and WO2009 / 140774, the entire disclosure of which is incorporated herein by reference. Some white box obfuscation techniques (such as the white box obfuscation techniques described above and other white box obfuscation techniques described below) enable the storage and / or use and possible manipulation of secret / sensitive data (such as encryption keys) in a transformed / secure manner, from which it is difficult / impossible for an attacker to access or derive the underlying secret / sensitive data. Some white box obfuscation techniques implement data flow obfuscation, for example, see US7350085, US7397916, US6594761 and US6842862, the entire disclosures of which are incorporated herein by reference. Some white box obfuscation techniques implement control flow obfuscation, for example, see US6779114, US6594761 and US6842862, the entire disclosures of which are incorporated herein by reference. However, it will be appreciated that there are other white box obfuscation techniques, and embodiments of the present invention may use any white box obfuscation technique.

[0167] As another example, it is possible that the initial software project may be intended to be provided (or distributed) to and used by a specific computer system (or a group of specific computer systems), and it is therefore desirable to "lock" the initial software project to that (one or more) specific computer system, i.e., to prevent the initial software project (once protected) from being executed on another computer system. Therefore, there are many techniques, referred to herein as "node-locked" protection techniques, for converting the initial software project so that the protected software project can be executed on (or by) one or more predetermined / specific computer systems, but not on other computer systems. Examples of such node-locking techniques can be found in WO2012 / 126077, the entire disclosure of which is incorporated herein by reference. However, it will be appreciated that there are other node-locking techniques, and embodiments of the present invention may use any node-locking technique. Such node-locking techniques are useful to help ensure that the control system 406 will only be executed on the intended mobile device 402 (so that the control system 406 with an embedded digital key cannot be copied to another mobile device 402 with an eye to using that other mobile device 402 as a "cloned" key for the vehicle 404).

[0168] Various methods are known for checking the integrity / correctness of the instructions of a software project and / or the data operated on or generated by the software project. Some such checks may be performed at load time (i.e., static checks), while other such checks may be performed in a continuous manner during the runtime execution of the software project (i.e., dynamic checks). Such checks help to confirm that the software project and / or data being used has not been tampered with. Examples of such integrity verification techniques may be found, for example, in WO2015 / 149828, WO2018 / 108275, EP3649553, the entire disclosures of which are incorporated herein by reference.

[0169] Many examples of methods and systems for applying protection techniques to software projects can be found in, for example, WO 2015 / 150391 and WO 2015 / 150376, the entire disclosures of which are incorporated herein by reference.

[0170] • Further examples of protection techniques that may be applied may be found in WO2013 / 142981, WO2013 / 142979, WO2013 / 142983 and WO2013 / 142980, the entire disclosures of which are incorporated herein by reference.

[0171] As described above, the control system 406 is arranged to act as a software root of trust. This enables the use of a cryptographic key of the control system 406 (which, for example, may be stored or implemented in an obfuscated manner within the control system 406, such as using the white box protection described above) to perform operations in a secure / authenticated manner for functions that predetermine the vehicle digital key specification and for keyless vehicle functions. In particular, acting as a software root of trust may include storing one or more cryptographic keys; and using one or more cryptographic keys to authenticate one or more digital signatures and / or issue one or more digital certificates. For example, this can be used to authenticate data signed by a digital key system of the vehicle 404, or to generate a digital certificate for use by the vehicle 404 and / or for use by another mobile device in order to share the digital key of the vehicle 404 (for example, as described above with respect to Figure 1 Having the control system 406 act as a root of trust enables the digital key functionality to be performed even when the mobile device 402 does not have communication access to the network 408 - i.e., the control system 406 does not need to rely on having access to the servers 410, 412 (enabling, for example, the doors of the vehicle 404 to be opened even when the mobile device 402 does not have a network connection).

[0172] In some embodiments, control system 406 is used to operate as a keyless fob, such as to unlock the vehicle when mobile device 402 comes into proximity with vehicle 404 .

[0173] In some embodiments, the control system 406 exposes an API that is configured to receive commands for controlling the control system 406 from an application 414 that may be installed by a user on the mobile device 402 to cause execution of at least one of the one or more vehicle functions. Such an application 414 may allow a user to provide input, wherein the command is generated by the application 414 based on or in accordance with the user input - for example, a command to unlock or lock the doors of the vehicle 404, a command to start or stop the engine / motor of the vehicle 404, etc. Thus, the command may be based on input provided to the application 414 by a user of the mobile device 402. The application 414 may be a native application of the mobile device 402 (e.g., downloaded from an app store by a user of the mobile device 402). In some embodiments, the application 414 is provided at least in part by the manufacturer of the vehicle 404 - thus, the application 414 may be provided by the manufacturer of the vehicle 404 to allow an owner / user of the vehicle 404 to execute / control one or more vehicle functions (e.g., by providing a suitable user interface for the owner / user to provide commands / control via the application 414).

[0174] In some embodiments, the application 414 is separate from the control system 406. In other embodiments, the control system 406 forms a subsystem (eg, component / module, etc.) of the application 414, such that the control system 406 is installed on the mobile device 402 together with the application 414.

[0175] In some embodiments, server 410 is a server (or part of a system) operated by the manufacturer of vehicle 404. Thus, control system 406 and / or application 414 may be arranged to communicate with manufacturer server 410 (e.g., via network 408) - this may be, for example, to enable manufacturer-specific / manufacturer-provided functionality via application 414 (e.g., where application 414 is provided by the manufacturer of vehicle 404); additionally or alternatively, this may be, for example, to enable functionality in accordance with a predetermined vehicle digital key specification (e.g., to enable execution of one or more functions specified by a predetermined vehicle digital key specification). Additionally or alternatively, in some embodiments, server 412 is a server (or part of a system) operated by a third party (i.e., different from the manufacturer of vehicle 404). Thus, the control system 406 and / or the application 414 may be arranged to communicate with the third-party server 412 (e.g., via the network 408)—this may, for example, enable specific functionality via the application 414 (e.g., where the application 414 is provided by a third party); additionally or alternatively, this may, for example, enable functionality in accordance with a predetermined vehicle digital key specification (e.g., so as to be able to perform one or more functions specified by the predetermined vehicle digital key specification). As an example of functionality that may be provided via the server 410 and / or server 412, the control system 406 may be arranged to bind to the vehicle 404 (e.g., as part of an initial setup procedure in accordance with the short-range communication protocol used), wherein the binding is controlled by the server 410 and / or 412 in communication with the control system 406. Thus, the initial security setup / provisioning may be performed in a more remote / safer location to help prevent unauthorized binding of the mobile device 402 to the vehicle 404.

[0176] Figure 6 A specific example of an embodiment of the present invention is schematically shown, which is configured for use with an Android operating system of a mobile device 402 associated with a CCC system - of course, it will be appreciated that other operating systems and examples of predetermined vehicle digital key specifications may be used with embodiments of the present invention. Figure 6 As shown in the example system, the present invention eliminates the vehicle OEM's dependence on device OEMs in the implementation of digital key solutions by providing two components: "a mobile engine compliant with CCC specifications" and "a cloud engine compliant with CCC specifications", thereby solving the pain points of vehicle OEMs in the implementation of digital key projects.

[0177] It should be pointed out that the "mobile engine compliant with CCC specifications" in the present invention is a security SDK that complies with CCC specifications based on Irdeto Cloakware software security protection technology and Android OS framework open capabilities. By integrating this security SDK, vehicle OEMs can implement their own digital key applications.

[0178] The specific description of "Mobile terminal engine that complies with CCC specifications" is as follows:

[0179] Build (or provide) a secure software runtime environment using software security technologies (such as Irdeto Cloakware technology) such as white-box cryptographic algorithms, secure storage, code obfuscation, data transformation, anti-debugging, anti-hooking, static and dynamic integrity verification.

[0180] Use the HCE (Host Card Emulation) feature of the Android framework (supported starting from Android 4.4) to emulate a card and communicate directly with the NFC reader of the mobile device 402. When emulating an NFC card using host-based card emulation, data is routed directly to the host CPU instead of being routed to the host's secure element (mobile device 402).

[0181] Use the BLE features of the Android framework to manage BLE communications with the vehicle 404 .

[0182] If the Android framework provides UWB features, a mobile engine that complies with the CCC specification can also manage UWB ranging services with the vehicle 404.

[0183] Implement key vehicle digital key features such as: owner pairing, digital key sharing, and management.

[0184] · Implement relevant (express and standard) transactions.

[0185] • Store anti-theft tokens, offline proofs, access policies, and other data associated with the digital key when needed by the vehicle 404.

[0186] Verify the authenticity of the vehicle 404.

[0187] Implement advanced Digital Car Key (DCK) features for vehicle OEMs.

[0188] Provide secure communication with “CCC-compliant cloud engines” based on communication protection and data protection security mechanisms.

[0189] The specific description of the “cloud engine compliant with the CCC specification” deployed on the server 410 side is as follows:

[0190] Implements the device OEM cloud API defined by the CCC specification (such as Section 17: Server-to-Server Communications and APIs of the CCC Specification Version 3.0) to integrate with the vehicle OEM’s backend to support key sharing / key tracking / key termination / notification features. Or it can implement the vehicle OEM’s proprietary protocol to simplify key management and support the vehicle OEM’s advanced DCK features

[0191] ·Create a digital key and send it to a "CCC-compliant mobile engine". Cloud-based key creation is more secure than client-side key creation. However, it will be appreciated that the present invention also supports the creation of digital keys on the device side (i.e., a "CCC-compliant mobile engine").

[0192] Simplify the key sharing process and enhance the security of the key sharing process

[0193] It will be appreciated that embodiments of the present invention can be implemented using various information processing systems. In particular, although the accompanying drawings and discussions thereof provide exemplary computing systems and methods, these are presented only to provide useful references when discussing various aspects of the present invention. Embodiments of the present invention can be implemented on any suitable data processing device, such as a personal computer, notebook computer, personal digital assistant, mobile phone, set-top box, television, server computer, etc. Of course, for the purpose of discussion, the description of system and method has been simplified, and they are just one of the many different types of systems and methods that can be used for embodiments of the present invention. It will be appreciated that the boundaries between logic blocks are merely illustrative, and alternative embodiments can merge logic blocks or elements, or can impose alternative decompositions of functions under various logic blocks or elements.

[0194] It will be appreciated that the functions mentioned above can be implemented as one or more corresponding modules as hardware and / or software. For example, the functions mentioned above can be implemented as one or more software components for execution by the processor of the system. Alternatively, the functions mentioned above can be implemented as hardware, such as one or more field programmable gate arrays (FPGAs), and / or one or more application specific integrated circuits (ASICs), and / or one or more digital signal processors (DSPs), and / or one or more graphics processing units (GPUs) and / or other hardware arrangements. The method steps implemented in the flowcharts included in this article or as described above can all be implemented by corresponding corresponding modules; the multiple method steps implemented in the flowcharts included in this article or as described above can be implemented together by a single module.

[0195] It will be appreciated that, within the limits that embodiments of the present invention are implemented by computer programs, one or more storage media and / or one or more transmission media storing or carrying computer programs form aspects of the present invention. A computer program may have one or more program instructions or program codes, which, when executed by one or more processors (or one or more computers), implement embodiments of the present invention. The term "program" used herein may be an instruction sequence designed for execution on a computer system, and may include subroutines, functions, processes, modules, object methods, object implementations, executable applications, applets, servlets, source codes, object codes, byte codes, shared libraries, dynamic link libraries, and / or other instruction sequences designed for execution on a computer system. A storage medium may be a disk (such as a hard disk or floppy disk), an optical disk (such as a CD-ROM, DVD-ROM, or a blue optical disk), or a memory (such as a ROM, RAM, EEPROM, EPROM, flash memory, or a portable / removable memory device), etc. A transmission medium may be a communication signal, a data broadcast, a communication link between two or more computers, etc.

Claims

1. A control system for controlling a digital key system of a vehicle at a mobile device, wherein the digital key system is implemented according to a predetermined vehicle digital key specification to enable one or more vehicle functions to be performed at the vehicle without using a physical key of the vehicle, and wherein the control system, when executed by a processor of the mobile device, is arranged to: communicating with the digital key system via at least one short-range communication protocol to cause execution of at least one of the one or more vehicle functions in accordance with the predetermined vehicle digital key specifications; and A secure software runtime environment is provided for the control system at the mobile device to perform one or more security operations, wherein the one or more security operations include the control system acting as a software root of trust according to the predetermined vehicle digital key specifications for the execution of at least one of the one or more vehicle functions.

2. The control system according to claim 1, wherein: The control system is arranged to perform the one or more security operations independently of any keyless vehicle control functionality provided by a manufacturer of the mobile device.

3. A control system according to any one of the preceding claims, wherein: The control system is arranged to perform the one or more security operations independently of any keyless vehicle control functionality provided as part of an operating system of the mobile device.

4. A control system according to any one of the preceding claims, wherein: The control system is arranged to perform the one or more security operations without using a secure element of the mobile device for: (a) storing data for controlling the digital key system; and (b) executing instructions for implementing control of the digital key system.

5. A control system according to any one of the preceding claims, wherein: The secure software runtime environment is provided based on one or more of the following: (a) the control system is implemented at least in part using a white box cryptographic algorithm to (i) protect the storage of some or all of the data used to control the digital key system; and / or (ii) protect some or all of the instructions used to implement the control system; (b) the control system is implemented at least in part using obfuscation of one or more of: (i) instructions for implementing the control system; (ii) a control flow of the control system; and (iii) runtime data of the control system; (c) the control system includes one or more secure storage functions for performing secure storage of one or more encryption keys and / or sensitive data; (d) the control system is arranged to perform node locking to lock execution of the control system to the mobile device; (e) the control system is arranged to perform integrity verification on the control system and / or the digital key system; and (f) The control system is arranged to perform anti-debugging functions.

6. A control system according to any one of the preceding claims, wherein: The control system is arranged such that data received from the vehicle via at least one short range communication protocol is routed to the control system rather than to a secure element of the mobile device.

7. The control system according to claim 6, wherein: The control system is arranged to perform host card emulation to enable the data to be transferred from a transceiver of the mobile device implementing the at least one short range communication protocol to the control system.

8. A control system according to any one of the preceding claims, wherein: The predetermined vehicle digital key specification specifies one or more protocols and / or one or more functions and / or one or more requirements, and the one or more protocols and / or one or more functions and / or one or more requirements enable the one or more vehicle functions to be performed at the vehicle without using a physical key of the vehicle.

9. A control system according to any one of the preceding claims, wherein: The predetermined vehicle digital key specification is one of: (a) CCC specification; and (b) ICCE specification.

10. A control system according to any one of the preceding claims, wherein: The one or more vehicle functions include one or more of the following: (a) physical unlocking and / or physical locking of at least a portion of the vehicle; (b) physical opening and / or physical closing of at least a portion of the vehicle; (c) starting and / or stopping the engine or motor of the vehicle; and (d) operating auxiliary systems of the vehicle.

11. A control system according to any one of the preceding claims, wherein: The at least one short-range communication protocol includes at least one of: a near field communication (NFC) protocol; a Bluetooth low energy (BTLE) protocol; and an ultra-wideband (UWB) protocol.

12. A control system according to any one of the preceding claims, wherein: A control system that acts as a software root of trust includes the control system: storing one or more encryption keys; and The one or more cryptographic keys are used to authenticate one or more digital signatures and / or issue one or more digital certificates.

13. A control system according to any one of the preceding claims, wherein: The control system exposes an API configured to receive commands for the control system from an application installable by a user on the mobile device to cause execution of at least one of the one or more vehicle functions.

14. The control system according to claim 13, wherein: The commands are based on input provided to the application by a user of the mobile device.

15. The control system according to claim 13 or 14, wherein: The application is a native application of the mobile device.

16. A control system according to any one of claims 13 to 15, wherein: The application is provided at least in part by the vehicle manufacturer.

17. A control system according to any one of the preceding claims, wherein: The one or more security operations include one or more of the following: (a) authenticating the identity of the vehicle and / or the identity of the digital key system according to the predetermined vehicle digital key specification; (b) enabling the digital key system to authenticate the identity of the mobile device and / or the identity of the control system according to the predetermined vehicle digital key specification; (c) sharing a digital key at least partially protected by the control system with another mobile device; (d) digital key management of one or more encryption keys used in accordance with said predetermined vehicle digital key specification; and (e) secure storage of data used for performance of at least one of the one or more vehicle functions.

18. A control system according to any one of the preceding claims, wherein: The control system, when executed by a processor of the mobile device, is arranged to bind to the vehicle, the binding being controlled by a server in communication with the control system.

19. A control system according to any one of the preceding claims, wherein: The mobile device is a smartphone.

20. An application installable by a user on a mobile device, comprising a control system according to any one of claims 1 to 19.

21. An application installable by a user on a mobile device, configured to provide one or more commands to a control system according to any one of claims 1 to 19, so that the control system causes the execution of at least one of the one or more vehicle functions.

22. A mobile device comprising the control system according to any one of claims 1 to 19, and / or having the application according to claim 20 or 21 installed thereon.

23. A computer readable medium storing a set of instructions which together implement a control system according to any one of claims 1 to 19.

Images