System access using mobile devices

Abstract

Embodiments of the present disclosure relate to system access using a mobile device. The present invention discloses techniques related to electronic security, such as for authenticating a mobile electronic device to allow access to system functions (e.g., physical access to the system, starting the engine / motor, etc.). In some embodiments, the system and the mobile device exchange public keys of a public key pair during a pairing process. In some embodiments, an asymmetric transaction process includes using a key derivation function to generate a shared secret based on a key established using a secure key exchange (e.g., Elliptic Curve Diffie-Hellman) and verifying the signature of the system before transmitting any information identifying the mobile device. In various embodiments, the disclosed techniques can increase transaction security and the privacy of identification information.

Description

[0001] This application is a divisional application of the invention patent application with international application number PCT / US2018 / 020494, international application date March 1, 2018, date of entry into the Chinese national phase on August 9, 2019, and national application number 201880011318.6. Technical Field

[0002] The present disclosure relates generally to electronic security and, more particularly, to encryption techniques for using a mobile device to gain access to another system. Background Art

[0003] Traditional techniques for gaining access to system functionality (e.g., physical access or access to certain features of the system) may require the use of a physical key or electronic fob. Carrying such a traditional key can be inconvenient and, if lost or stolen, could allow a malicious entity to gain access. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] Figure 1A is a block diagram illustrating exemplary pairing communications between a mobile device and a control unit according to some embodiments.

[0005] Figure 1B is a block diagram illustrating exemplary request and authentication communications between a mobile device and a control unit according to some embodiments.

[0006] Figure 1C is a block diagram illustrating exemplary communications to authorize another mobile device to control a control unit according to some embodiments.

[0007] Figure 2 is a block diagram illustrating an exemplary mobile device according to some embodiments.

[0008] Figure 3 is a communication diagram illustrating an example technique for pairing according to some embodiments.

[0009] Figure 4 is a communication diagram illustrating example techniques for authorization operations according to some embodiments.

[0010] Figure 5 is a communication diagram illustrating an example technique for authorizing another device according to some embodiments.

[0011] Figures 6A to 6B A communication diagram illustrating exemplary techniques for server-based authorization of another device according to some embodiments is constituted.

[0012] 7A to 7Bis a flowchart illustrating an exemplary method for pairing a mobile device and a processing element of a system according to some embodiments.

[0013] Figures 8A to 8B is a flow chart illustrating an exemplary method for authenticating a mobile device to authorize one or more operations of a system according to some embodiments.

[0014] Figures 9A to 9C A communication diagram illustrating exemplary techniques for authorizing operations with multiple transaction types, according to some embodiments, is constructed.

[0015] Figure 10 is a communication diagram illustrating an example technique for authorizing operations with standard transaction types, according to some embodiments.

[0016] Figure 11 is a communication diagram illustrating an exemplary pairing technique according to some embodiments.

[0017] Figure 12 is a block diagram illustrating exemplary system elements according to some embodiments.

[0018] Figure 13 is a block diagram illustrating exemplary components of a mobile device and system according to some embodiments.

[0019] Figure 14 is a diagram illustrating an example mailbox structure according to some embodiments.

[0020] Figure 15 is a communication diagram illustrating exemplary offline sharing with another device according to some embodiments.

[0021] Figure 16 is a communication diagram illustrating exemplary online sharing with another device according to some embodiments.

[0022] Figure 17 is a diagram illustrating exemplary key revocation according to some embodiments.

[0023] Figure 18 is a diagram illustrating exemplary mailbox usage according to some embodiments.

[0024] Figures 19 to 24 is a block diagram illustrating an example certificate chain according to some embodiments.

[0025] Figure 25 is a block diagram illustrating an exemplary computer-readable medium storing design information according to some embodiments.

[0026] Figure 26is a flow chart illustrating an exemplary mobile-side method for authentication according to some embodiments.

[0027] Figure 27 is a flow chart illustrating an exemplary system-side method for authentication according to some embodiments.

[0028] Figure 28 is a block diagram illustrating an exemplary technique for digital key structure proof at pairing time, according to some embodiments.

[0029] This disclosure includes references to "one embodiment" or "an embodiment." The appearance of the phrase "in one embodiment" or "in an embodiment" does not necessarily refer to the same embodiment. The particular features, structures, or characteristics may be combined in any suitable manner consistent with this disclosure.

[0030] Within the present disclosure, different entities (which may be variously referred to as "units," "circuits," other components, etc.) may be described or claimed as being "configured to" perform one or more tasks or operations. This expression—"an entity configured to perform one or more tasks"—is used herein to refer to a structure (i.e., a physical thing, such as an electronic circuit). More specifically, this expression is used to indicate that this structure is arranged to perform one or more tasks during operation. A structure may be said to be "configured to" perform a task even if the structure is not currently being operated. "A secure circuit configured to perform authentication" is intended to encompass, for example, an integrated circuit having circuitry that performs that function during operation, even if the integrated circuit in question is not currently being used (e.g., power is not connected to it). Thus, an entity described or stated as "configured to" perform a task refers to a physical thing, such as a device, a circuit, a memory storing executable program instructions, etc., that is used to implement that task. The phrase is not used herein to refer to intangible things. Thus, a structure "configured to" is not used herein to refer to a software entity, such as an application programming interface (API).

[0031] The term “configured to” is not intended to mean “configurable to.” For example, an unprogrammed FPGA would not be considered “configured to” perform a particular function, although it may be “capable of being configured to” perform that function and may be “configured to” perform that function after being programmed.

[0032] The phrase "configured to" in the appended claims is expressly intended to define the claim elements. NoInvoking 35 U.S.C. § 112(f). Thus, no claim in this application, as filed, is intended to be construed as having means-plus-function elements. If the applicant wishes to invoke section 112(f) during the prosecution of the application, it will use the “means for “[performing the function]” construct to phrase the claim element.

[0033] As used herein, the terms "first," "second," and the like serve as labels for the nouns that follow them and do not imply any type of ordering (e.g., spatial, temporal, logical, etc.) unless explicitly stated. For example, a mobile device may have a first user and a second user. The term "first" is not limited to the initial user of the device. The term "first" may also be used when there is only one user of the mobile device.

[0034] As used herein, the term "based on" is used to describe one or more factors that influence a determination. The term does not exclude that there may be additional factors that may influence the determination. That is, a determination may be based solely on the specified factors or on the specified factors and other unspecified factors. Consider the phrase "A is determined based on B." This phrase specifies that B is a factor used to determine A or that B influences the determination of A. This phrase does not exclude that the determination of A may also be based on some other factor, such as C. This phrase is also intended to cover embodiments in which A is determined solely based on B. As used herein, the phrase "based on" is therefore synonymous with the phrase "based at least in part on." DETAILED DESCRIPTION

[0035] Overview of Exemplary Embodiments

[0036] The present disclosure describes an embodiment of a mobile device for obtaining access to system functions. In some embodiments, asymmetric encryption is used to establish a secure channel between the mobile device and the system. Using the secure channel, the system can authenticate the device by verifying a signature generated by a security circuit such as a secure element (SE) of the mobile device using a previously stored public key (e.g., a key stored as part of the pairing process). A processor such as a control unit (e.g., an ECU) of the system can be configured to store a long-term key pair, generate a short-lived asymmetric key pair, and verify the signature. The mobile device may include an SE configured to store a long-term asymmetric key pair.

[0037] In various embodiments, the mobile device initially performs a pairing process with the system. This process may include the mobile device exchanging a short-lived public key pair with the system, and the mobile device's processor generating a shared secret with the system based on the exchanged keys (e.g., using Elliptic Curve Diffie-Hellman (ECDH)). The mobile device's security circuitry may also generate a public key pair that allows the system to authenticate the mobile device. For example, the security circuitry may be a secure element. As used herein, the term "secure element" is to be interpreted according to its meaning as understood in the art, comprising circuitry (e.g., typically a single-chip microcontroller) configured to store information in a tamper-resistant manner that prevents unauthorized access to that information. Non-limiting examples of secure element form factors include UICC, embedded SE, and microSD. For example, in some embodiments, secure elements are also used for other types of transactions, such as payment transactions. For payment transactions, the secure element may encryptedly store data such as the payment instrument (e.g., credit card) and owner (e.g., cardholder), access to a physical location or building, and transmission access. In some embodiments, at least a portion of the secure element's functionality may be cloud-based. In these embodiments, the secure element on the device may store virtual information that can be used to retrieve the actual required information stored on a server. In some embodiments, other types of secure circuits or secure processors may perform the functions described as being performed by the secure element, including, for example, the secure enclave processor discussed below.

[0038] After the key exchange, the mobile device can then encrypt the key pair's certificate using the private key and send the encrypted certificate to the system. The mobile device can then display a value derived based on the public key pair and ask the user of the mobile device to confirm that the value is also displayed on the system's display, which can derive the value based on the public key in the certificate.

[0039] Once a mobile device has been paired with another system, the mobile device can perform an exchange with the other system to enable functionality of the other system, such as, in some embodiments, opening a door, starting the engine or activating the motor, making a call, playing media, traveling above a certain speed, and the like. In some embodiments, the exchange includes the mobile device's processor generating another encryption key shared with the system conducting the conversation, and the system issuing a challenge to the mobile device. In response to receiving the challenge, the mobile device's security element generates a response using the private key of the previously generated public key pair. In other embodiments, other security circuits that are not considered security elements can be used to perform similar functions. The mobile device then encrypts the response with another encryption key and sends the response to the system for verification. In response to successful verification, the system can enable the requested functionality.

[0040] In some cases, the owner of the system may wish to enable another user's mobile device to access the system. In some embodiments, the secure element of the other user's mobile device can generate a public key pair and a corresponding certificate signing request for the public key. The other user's device can then send the certificate signing request to the secure element of the owner's mobile device, which generates a certificate for the public key. The owner's mobile device can then send the generated certificate to the other user's mobile device, allowing the mobile device to enable system functionality.

[0041] The mobile device and system may include any suitable hardware for implementing the functions described herein. Thus, the hardware may include a processor subsystem coupled to system memory and I / O interfaces or devices via an interconnect (e.g., a system bus). Although described as a mobile device, the device may be any of various types of devices, including but not limited to a server system, a personal computer system, a desktop computer, a laptop or notebook computer, a mainframe computer system, a tablet computer, a handheld computer, a workstation, a network computer, a consumer device such as a mobile phone, a music player, or a personal data assistant (PDA). The mobile device and / or system may also implement various functions by executing program instructions embedded in a non-transitory computer readable medium. The following further details Figure 2 Additional non-limiting examples of hardware implementations are shown.

[0042] In some embodiments, the disclosed technology can advantageously provide privacy equivalent to that of a physical key, offline key sharing, interoperability across devices and systems, operation independent of the underlying radio protocol, scalable systems, etc. In some embodiments, the mobile device private key never leaves the secure circuitry (e.g., a secure element) included in the mobile device. In some embodiments, the disclosed technology can be used over untrusted channels and provide protection against active and / or passive eavesdroppers.

[0043] As used herein, the term "secure channel" refers to a dedicated path for transmitting data (i.e., a path shared only by the intended parties) or transmitting data encrypted or signed using a cryptographic key known only to the intended parties. As used herein, the term "secure circuit" refers to a class of circuits configured to perform one or more services and return an authenticated response to an external requestor. The results returned by a secure circuit are considered to have a higher trust mark than circuits that simply return results without any form of authentication. Therefore, a circuit that provides data without authenticating the source of the accessed data (e.g., from an untrusted storage area accessible to a third-party application) would not be considered a secure circuit within the meaning of this application. In the embodiments disclosed herein, secure elements and secure enclave processors are provided as examples of secure circuits. By authenticating the returned results, such as by signing them with a verifiable cryptographic signature, the secure circuit can provide anti-spoofing functionality. Similarly, by encrypting the results using a private or secret key, the secure circuit can authenticate the source of the encrypted data (in various embodiments, encryption can be used alone or in combination with signing). In addition, in some cases, the secure circuit may be referred to as "tamper-resistant," which is a term specifically referring to a mechanism that prevents the portion of the secure circuit that performs one or more services from being compromised. For example, a secure mailbox can be implemented so that only a portion of the secure circuit (e.g., a predefined memory area) is directly accessible to other circuits. Similarly, firmware executed by the secure circuit can be encrypted, signed, and / or stored in an area inaccessible to other processing elements.

[0044] Figure 1A 1 is a block diagram illustrating exemplary pairing communications 145 between circuitry, such as a control unit of a system, and a mobile device, according to some embodiments. Although a single control unit is discussed in various examples for illustrative purposes, similar techniques can be used with multiple different control units or processors (e.g., microcontrollers) and various types of control units or processors that control different vehicle functions. The term "ECU" is an example of a control unit and is a term of art intended to be interpreted according to its well-known meaning, which includes circuitry configured to control one or more operations of a vehicle.

[0045] In the illustrated embodiment, system 110 includes a control unit 137 and receives a pairing request 140 from a user. In some embodiments, system 110 is a vehicle or a component thereof, such as an ECU. Examples of vehicles include, but are not limited to, aircraft, ships, recreational vehicles (RVs), automobiles, buses, rail vehicles, spacecraft, robotic devices, and the like. Examples of systems that may not be vehicles also include physical locations such as buildings, transit access controls, and IoT or home automation devices or controllers. It should be noted that various actions described as being performed by system 110 may be performed by processors, components, or devices included in system 110. The pairing request may be initiated at system 110, for example, via input entered using a touchscreen within system 110, and may include information identifying the user and / or information for initial authentication of the user, such as a personal identification number (PIN), password, biometric authentication, and the like. In various embodiments, this information may be sent out-of-band relative to the wireless communications discussed herein. In some embodiments, the manufacturer or provider of the system provides the user with an initial PIN when selling system 110, which is then used in pairing request 140.

[0046] In the illustrated embodiment, the mobile device 130 includes an application processor (AP) 136 and a wireless interface 132 (e.g., an NFC interface, a Bluetooth interface, a Wi-Fi direct interface, etc.), which in turn includes a SE 134. In some embodiments, the SE 134 is configured to perform various cryptographic operations to facilitate secure communication between the mobile device 130 and the system 110. Note that while NFC communication is discussed herein, this is not intended to limit the scope of the present disclosure. In other embodiments, any of a variety of appropriate interfaces may be used with the disclosed technology, such as Wi-Fi Direct, Bluetooth, etc. In addition, in various embodiments, the various functions discussed herein with respect to specific types of elements (e.g., application processors, secure elements, ECUs, etc.) may be performed by other types of elements.

[0047] Pairing of the mobile device 130 and the system 110 may involve establishing a shared secret (which may also be referred to as a shared key) and storing a long-term public key from the SE 134 by the system 110. Figure 3 A detailed description of an exemplary pairing process is discussed in

[0026] Once paired, SE 134 may also facilitate transactions in which mobile device 130 instructs system 110 to perform various operations, for example, as described below with reference to Figure 4 discussed.

[0048] Figure 1Bis a block diagram illustrating exemplary communications between a system and a mobile device for performing operations according to some embodiments. Examples of operations include unlocking a door, starting an engine, enabling or disabling a feature, changing the media being played, connecting or disconnecting the system from a wide area network, authorizing or removing additional users, accessing keychain data, purchasing capabilities, etc. In the illustrated embodiment, SE 134 is configured to perform authentication communications 155 for a request 150 initiated by AP 136.

[0049] Figure 1C 1 is a block diagram illustrating exemplary communications for granting authorization to another mobile device 160 to control a control unit 137. This may allow a user of a paired device to grant access to one or more other devices (e.g., those of a friend or family member). In the illustrated embodiment, SE 134 sends an authorization grant 165 (which may include, for example, a signed certificate) to mobile device 160, which enables system 110 to confirm, based on authentication communication 170, that mobile device 160 received authorization from mobile device 130. In the illustrated embodiment, mobile device 160 sends an authorization request 162, which may include a key to be signed by SE 134.

[0050] Exemplary Mobile Device Implementations

[0051] Now turn Figure 2 , a block diagram of a mobile device 130 is shown according to some embodiments. The mobile device 130 may include a wireless interface 132, a SE 134, and a biosensor 138. In the illustrated embodiment, the mobile device 130 also includes a secure enclave processor (SEP) 210, a cellular interface 220, a CPU 230, a memory 240, and peripherals 260 coupled via a communication structure 250. As shown, the SEP 210 may include one or more processors P 212, a secure memory 214, and one or more secure peripherals 216. The SE 134 may include one or more processors P 222 and a memory 224. The CPU 320 may include one or more processors P 232. The memory 240 may store an interface application 242. In some embodiments, the mobile device 130 may be implemented differently than shown.

[0052] In some embodiments, SEP 210 is configured to maintain previously captured biometric template data 218 for one or more authorized users and compare it with newly received data captured by biometric sensor 138 to authenticate the user. (In another embodiment, biometric sensor 138 or SE 134 may perform the comparison.) In the illustrated embodiment, SEP 210 is configured to store biometric data collected from fingerprints, facial biometric data (e.g., iris data, voice data, facial or body features), etc. in biometric templates 218. In fingerprint embodiments, each template 218 may correspond to a specific registered user and may be assigned a unique index value. In some embodiments, if the biometric data received from biometric sensor 138 matches the biometric data stored in template 218, SEP 210 is configured to provide the unique index value associated with the matching template 218 to SE 134, which in turn uses the index value to look up corresponding identification information for the known user being authenticated. In some embodiments, SEP 210 may store multiple templates 218. In various embodiments, communications between the SEP 210, SE 134, and / or biosensor 138 are encrypted so that another entity, such as the CPU 230, cannot view the communications.

[0053] In various embodiments, the SEP 210 is configured to securely store biometric data. Therefore, in various embodiments, the SEP 210 is isolated from the rest of the mobile device 130 except for carefully controlled interfaces (thus forming a secure enclave for the SEP processor 212, secure memory 214, and secure peripherals 216). Because the interfaces to the SEP 210 are carefully controlled, direct access to the SEP processor 212, secure memory 214, and secure peripherals 216 is prevented. In one embodiment, a secure mailbox mechanism may be implemented. In this secure mailbox mechanism, external devices may transmit messages to an inbox. The SEP processor 212 may read and interpret the message to determine the action to take in response to the message. Response messages from the SEP processor 212 may be transmitted through an outbox, also part of the secure mailbox mechanism. Other circuitry may not be able to access the internal resources of the SEP 210 except via the mailbox mechanism. Other interfaces may be used that only allow commands / requests to be passed from external components and results to be passed to external components. No other access from external devices to SEP 210 is permitted, thus SEP 210 can be "protected from access." More specifically, software executing anywhere outside of SEP 210 can be prevented from directly accessing secure components of SEP 210. SEP processor 212 can determine whether to execute a command. In some cases, the determination of whether to execute a command may be influenced by the source of the command. That is, a command from one source may be permitted but not from another.

[0054] In various embodiments, SEP 210 may be configured to perform the functions described with reference to SE 134 and / or vice versa. In some embodiments, SE 134 is configured to authenticate the identity of device 130, while SEP 210 is configured to authenticate the identity of the current user of device 130 (which may also be required for system access in some embodiments).

[0055] In some embodiments, the SEP processor 212 can execute securely loaded software that facilitates the functionality described with respect to the SEP 210. For example, the secure memory 214 can include software executable by the SEP processor 212. One or more of the secure peripherals 216 can have an external interface that can connect to a software source (e.g., non-volatile memory such as flash memory). In another embodiment, the software source can be non-volatile memory coupled to another peripheral 216, and the software can be encrypted to prevent third-party observation. The software from the source can be authenticated or otherwise verified as secure and can be executed by the SEP processor 212. In some embodiments, the software can be loaded into a trusted zone within the memory 214 allocated to the SEP 210, and the SEP processor 212 can retrieve the software from the trusted zone for execution. The software can be stored in encrypted form in the memory 240 to prevent observation. Although steps are taken to ensure the security of the secure software, the secure software can still be prevented from directly accessing / retrieving the stored private key. In one embodiment, only the hardware can access the private key.

[0056] The secure peripheral 216 may be hardware configured to assist with security services performed by the SEP 210. Thus, the secure peripheral 216 may include authentication hardware that implements / accelerates various authentication algorithms, cryptographic hardware configured to perform / accelerate cryptography, a secure interface controller configured to communicate with external devices (with the mobile device 130) via a secure interface, and the like.

[0057] In some embodiments, SE 134 may implement functionality similar to SEP 210 to restrict access to confidential information stored in memory 224, such as public key information 228. For example, SE 134 may implement a mailbox to restrict access to processor 222 and memory 224. In various embodiments, SE processor 222 also executes securely loaded software to implement the functionality described herein, such as applet 226 stored in memory 224.

[0058] In one embodiment, applet 226 can be executed to perform registration of mobile device 130 and authentication to the reader. Regarding registration, applet 226 can be executed to generate a public key pair and obtain a corresponding certificate, which can be stored in memory 224 as public key information 228.

[0059] In some embodiments, an interface application 242 may be executed to facilitate interaction between the SEP 210, the SE 134, and the user of the mobile device 130 when performing enrollment and authentication. Thus, the application 242 may provide various prompts to the user during these processes, instructing the user to perform various actions. During these processes, the application 242 may also activate the biometric sensor 138, the SEP 210, and / or the SE 134, as appropriate. The various actions performed by the application 242 are described in more detail below.

[0060] In some embodiments, cellular interface 220 is a remote radio component that is configured to facilitate interaction between mobile device 130 and one or more external systems, such as systems 120 and 140. Cellular link 220 may include suitable circuitry for interacting with the remote network, such as a baseband processor, analog RF signal processing circuitry (e.g., including filters, mixers, oscillators, amplifiers, etc.), digital processing circuitry (e.g., for digital modulation and other digital processing), one or more antennas, etc. Cellular interface 220 may be configured to communicate using any of a variety of radio access technologies / wireless communication protocols, such as GSM, UMTS, CDMA2000, LTE, LTE-A, etc.

[0061] As described above, CPU 230 may include one or more processors 232. Generally speaking, a processor may include circuitry configured to execute instructions defined in an instruction set architecture implemented by the processor. Processor 232 may include (or correspond to) a processor core implemented on an integrated circuit with other components as a system on a chip (SOC) or at other levels of integration. Processor 232 may also include a discrete microprocessor, a processor core, and / or a microprocessor integrated into a multi-chip module implementation, a processor implemented as multiple integrated circuits, and the like.

[0062] Processor 232 can execute the system's main control software, such as an operating system. Typically, the software executed by CPU 230 during use can control other components of the system to achieve the desired functionality of the system. The processor can also execute other software. These applications can provide user functions and can rely on the operating system for lower-level device control, scheduling, memory management, etc. Therefore, processor 232 (or CPU 230) can also be referred to as an application processor. CPU 230 can also include other hardware, such as an L2 cache and / or interfaces to other components of the system (e.g., an interface to communication structure 260).

[0063] The memory 240 may generally include circuitry for storing data. For example, the memory 240 may be static random access memory (SRAM), dynamic RAM (DRAM) such as synchronous DRAM (SDRAM), including double data rate (DDR, DDR2, DDR3, DDR4, etc.) DRAM. Low power / mobile versions of DDR DRAM (e.g., LPDDR, mDDR, etc.) may be supported. The device 130 may include a memory controller (not shown) that may include a memory operation queue for sorting (and possibly reordering) these operations and providing them to the memory 240. The memory controller may also include a data buffer for storing write data waiting to be written to the memory and read data waiting to be returned to the source of the memory operation. In some embodiments, the memory controller may include a memory cache for storing recently accessed memory data. In some embodiments, the memory 330 may include program instructions that can be executed by one or more processors 232 to enable the device 130 to perform the various functions described herein with respect to the device 130, such as instructions of the application 242.

[0064] Peripherals 250 may be any collection of additional hardware functions included in device 130. For example, peripherals 340 may include video peripherals, such as an image signal processor configured to process image capture data from a camera or other image sensor, a display controller configured to display video data on one or more display devices, a graphics processing unit (GPU), a video encoder / decoder, a scaler, a rotator, a mixer, and the like. Peripherals 250 may include audio peripherals, such as a microphone, a speaker, an interface to a microphone and a speaker, an audio processor, a digital signal processor, a mixer, and the like. Peripherals 250 may include interface controllers for various interfaces, including interfaces such as a universal serial bus (USB), a peripheral component interconnect (PCI) (including PCI Express (PCIe)), a serial port, and a parallel port, and the like. Peripherals 250 may include networking peripherals, such as a media access controller (MAC). Any collection of hardware may be included.

[0065] The communication fabric 260 can be any communication interconnect and protocol for communicating between components of the device 130. The communication fabric 260 can be bus-based, including shared bus configurations, crossbar configurations, and hierarchical buses with bridges. The communication fabric 260 can also be packet-based and can be hierarchical with bridges, crossbar, point-to-point, or other interconnects.

[0066] Although Figure 2 Components within mobile device 130 are shown, but it should be noted that similar components may be present in a computer system for implementing other functionality described herein, such as that described with respect to system 110 or mobile device 160. Thus, these systems may also include a CPU, memory, various network interfaces, and peripherals, such as those described above.

[0067] Exemplary pairing techniques

[0068] Figure 3 is a communication diagram illustrating exemplary messages between user 310, system 110 (e.g., using control unit 137), application processor 136, and SE 134 for the pairing process. In some embodiments, the pairing process generates a long-term public key system.PK stored by mobile device 130 and a long-term public key se.PK stored by system 110. These keys can then be used for various transactions, for example, as described below with reference to Figure 4 As stated.

[0069] exist Figure 3 In the process, user 310 begins pairing with system 110 at 302, for example, using the system's console interface or some other input device. In the illustrated embodiment, system 110 then checks at 304 that the current state is unpaired (e.g., the system is not currently paired with another mobile device). In other embodiments, pairing may be allowed even if system 110 is already paired with another device. Allowing only one mobile device to be paired at a time may increase security but limit flexibility (although this may be mitigated by allowing a paired mobile device to authorize other mobile devices, as discussed in further detail below).

[0070] In the illustrated embodiment, user 310 submits authentication information to system 110. This may include a user PIN, password, the presence of a key fob or key to the system, biometrics, etc. In some embodiments, multiple types of authentication information may be required. This can prevent unauthorized individuals from initiating the pairing process. Generally, system 110 may need to enter a pairing state before adding the owner key to the system, and may require the user to prove ownership of the system before entering this state. The technology used to prove ownership may be defined by the manufacturer of system 110.

[0071] In the illustrated embodiment, at 306, the system 110 verifies the authentication information and, in response, generates a temporary key pair. In the illustrated embodiment, the system 110 then switches to the "pairing in progress state." Note that in other embodiments, other states may be used, and states may be entered or exited at different times than shown.

[0072] In the illustrated embodiment, the key pair includes a temporary public key system.ePK and a temporary secret key system.eSK. The keys can be "temporary" in the sense that they are of limited use, for example, valid only for a specific number of uses (including embodiments where they are valid only for a single use) or for a specific time interval. The temporary keys can be deleted at the end of each transaction. Because temporary keys are invalid after expiration, it is possible to prevent unauthorized individuals from reusing the keys if the keys are somehow intercepted.

[0073] In the illustrated embodiment, user 310 also initiates a pairing process with mobile device 130 at 308 via AP 136. This can be performed, for example, using an input device of mobile device 130, such as a touchscreen. For example, the user can initiate the pairing process by opening an application and selecting a pairing option. In some embodiments, mobile device 130 is configured to automatically prompt the user for input to confirm that a pairing operation is desired, for example in response to a communication from system 110, rather than requiring the user to navigate to a pairing application. In other embodiments, the user may be required to initiate the pairing process on both devices to avoid broadcasting an indication that pairing is occurring. Mobile device 130 may also prompt the user for authentication information, such as a password, biometric scan, PIN, etc.

[0074] In the illustrated embodiment, in response to initiating the pairing process, at 312, AP 136 also generates a temporary key pair, phone.ePK and phone.eSK. In the illustrated embodiment, system 110 and AP 135 then exchange their respective generated temporary public keys, system.ePK and phone.ePK, at 314 and 316. Each device then derives a shared secret based on the exchanged public keys and their respective secret keys at 318. As described above, ECDH can be used to derive the shared secret. At this point in the process, in the illustrated embodiment, an unauthenticated secure channel has been established between system 110 and mobile device 130 using the temporary key. In other embodiments, other techniques may be used to establish a shared secret or key. The disclosed techniques for obtaining a shared secret are disclosed for illustrative purposes and are not intended to limit the scope of the present disclosure.

[0075] In the illustrated embodiment, the system 110 then sends the certificate (system.Cert) encrypted using the shared secret at 322. In the specific illustrated embodiment, the shared secret includes an encryption key (KENC) and a message authorization code (KMAC). These can be shared symmetric keys derived from system.eSK / phone.ePK on the system side and phone.eSK / system.ePK on the mobile device side. These keys can be stored on the AP 136 and the ECU of the system 110 and can be deleted after each transaction. In the illustrated embodiment, the notation (KENC, KMAC)(data) represents an encryption operation using KENC and a hash operation using KMAC (where the hash output can be used to protect the integrity of the key exchange). In the illustrated embodiment, the AP 136 uses the shared secret at 324 to extract the system public key system.PK from the encrypted certificate system.Cert.

[0076] In the illustrated embodiment, AP 136 then requests generation of a new key pair from SE 134 at 326. In the illustrated embodiment, SE 134 generates a public / private key pair, se.SK and se.PK, and a corresponding certificate, se.Cert, at 328. In the illustrated embodiment, a certificate is a wrapper around a public key that describes the public key and indicates that SE 134 is authorized to issue such a public key. The certificate can be self-signed or based on a certificate from a certificate authority (e.g., if SE 134 is an intermediate authority). SE 135 sends certificate, se.Cert, to AP 136 at 332, which then encrypts the certificate using a shared secret (using KENC and KMAC techniques in the illustrated embodiment) and sends the encrypted certificate to system 110 over a secure channel at 334.

[0077] In the illustrated embodiment, the system 110 then verifies the MAC and decrypts the certificate se.Cert at 336. The system 110 then verifies se.Cert using a root certificate from an authorized entity associated with the mobile device (e.g., obtained from the manufacturer or OEM of the mobile device 130) and extracts the public key se.PK from se.Cert. In some embodiments, the manufacturer of the mobile device 130 may provide its root certificate to various system manufacturers to facilitate this process.

[0078] In the illustrated embodiment, text confirmation is then performed (this step may be omitted in other embodiments), and both the mobile device 130 and the system 110 generate text information based on the shared secret and display the text information to the user at 338. In the illustrated embodiment, the user then indicates to the system 110 that the text on both devices is the same. This can be used to detect and avoid tampering by unauthorized entities during the pairing process (e.g., causing the displayed text to not match).

[0079] In the illustrated embodiment, the system 110 then stores the se.PK with owner rights at 342 (e.g., information specifying what operations the mobile device 130 is authorized to perform). This long-term SE public key can be used to authenticate future requests from the mobile device 130. Examples of owner rights for the mobile device 130 may include, but are not limited to: opening doors, starting the engine, adding / removing keys from the system 110 (e.g., owner and friend keys), delegating key sharing to another party, changing rights, setting the system to an unpaired state, accessing keychain data (e.g., website usernames, passwords, WLAN network information, payment information, etc.), making purchases within the system 110, performing other cryptographic operations, and the like. In the illustrated embodiment, the system 110 also switches to a paired state, which prevents subsequent pairing (e.g., until the mobile device 130 is unpaired). In some embodiments, the owner rights may be granted to the new user by providing them with owner rights (e.g., using Figure 5 The process of then revoking the key of the previous owner without switching to the unpaired state to perform the ownership transfer. In other embodiments, it may be necessary to switch to the unpaired state to transfer ownership to another mobile device.

[0080] In some embodiments, a rotating PIN is used for pairing with the system 110. For example, the system 110 may display a new PIN to the user upon successful pairing, wherein the new PIN needs to be entered by the user before another pairing with another mobile device. This may prevent pairing initiated by unauthorized users.

[0081] Various operations performed by some of AP 136, SE 134, or SEP 210 are discussed herein. These embodiments are discussed for purposes of explanation and are not intended to limit the scope of the present disclosure. In other embodiments, actions described as being performed by one of these processors may be performed by other processors in these processors and / or other processing elements, or a combination thereof. As an example, if additional security is desired, SEP 210 may be used to require biometric authentication for various operations performed by SE 134. Additionally, the ordering and types of messages in the various communication diagrams disclosed herein are not intended to limit the scope of the present disclosure; in various embodiments, similar messages may be sent in a different order, disclosed messages may be omitted, and / or additional messages may be utilized.

[0082] In some embodiments, the user can also initiate an unpairing operation, which can transition system 110 to an unpaired state. This can be used to register a new device as the owner device of system 110, for example, to transfer ownership of the system or if the user purchases a new mobile device. For this process, mobile device 130 can send a specific command while authenticating with private key se.SK. In some embodiments, unpairing can also be performed via the interface of system 110, for example, by entering a new PIN from the last pairing operation.

[0083] In some embodiments, the system 110 is configured to Figure 3 The system 110 operates in the "Pairing" state during operation and rejects pairing requests in this state. In some embodiments, the system 110 is configured to transition to the Blocked state after a number of failed pairing attempts (the number may be configurable). In the Blocked state, the user may need to contact the manufacturer to obtain a recovery PIN, which can only be provided after showing proof of ownership.

[0084] In some embodiments, out-of-band communication can be used to establish a secure channel. For example, the system 110 can dynamically generate a password and transmit the password out-of-band to the mobile device 130, such as by scanning an image, text, or animation using the camera of the mobile device 130. For example, the image, text, or information can be displayed on the multimedia system of the system 110. The out-of-band shared secret can be used with a password authenticated key exchange (PAKE) technology such as secure remote password (SRP) to establish an unauthenticated secure channel. In these embodiments, text matching performed by the user between the text displayed by the system 110 and the text displayed by the mobile device 130 can be omitted, for example, because the out-of-band communication can prevent man-in-the-middle attacks.

[0085] In some embodiments, the se.Cert may be transferred from the mobile device 130 to the system 110 using a pre-existing pairing, such as a Bluetooth pairing.

[0086] Exemplary Operation Authorization Techniques

[0087] Figure 4 is a communication diagram illustrating exemplary messages between system 110 (e.g., via control unit 137), application processor 136, and SE 134 for authorizing operation of system 110. In the illustrated embodiment, the communications are used to authenticate a command from mobile device 130 that specifies an operation to be performed by system 110.

[0088] In the illustrated embodiment, at 402, system 110 begins communicating with AP 136. In some embodiments, this includes sending a polling message (e.g., an NFC anti-collision enhanced contactless poll (ECP) message). In other embodiments, other communication initiation techniques may be used. In response, at 404 of the illustrated embodiment, AP 136 generates a temporary key pair, phone.eSK and phone.ePK (although in other embodiments, other processing elements such as SE 134 may generate the temporary key pair). Examples of key pairs include elliptic curve cryptography (ECC) pairs, pairs generated using AES encryption, etc. In the illustrated embodiment, AP 136 sends the key pair and channel negotiation options to system 110 at 406. In some embodiments, in response to determining that it is within communication distance of system 110, mobile device 130 may automatically prompt the user to enter one or more commands for system 110.

[0089] In the illustrated embodiment, at 408, system 110 also generates a temporary key pair (system.eSK and system.ePK) and derives KENC and KMAC for secure communications with system 110. (In some embodiments, ECC may also be used for the key pair.) In the illustrated embodiment, system 110 also generates a system.eCert certificate, which contains the system.ePK and phone.ePK temporary public keys and is signed with system.SK.

[0090] In the illustrated embodiment, at 412, the system 110 also generates an operation dictionary (OD), which is a data structure that includes the following information: the requested operation, the reason, and the challenge. In this case, the operation can be a signature on the challenge (e.g., the system 110 is requesting that the challenge be signed by the SE 134 using the SE 134's cryptographic key). The reason can specify the operation to be performed by the system (e.g., allowing physical access or allowing the system to be driven). The system 110 then encrypts and MACs the OD using KENC and KMAC, and also sends the certificate system.eCert for the public key system.PK at 424. The AP 136 verifies the system.eCert using the public key system.PK (e.g., as stored during the pairing process) and extracts the temporary public key system.ePK from the system.eCert. The AP 136 also derives a shared secret (KENC and KMAC in this embodiment) using the system.ePK and phone.eSK. The AP 136 then verifies the MAC and decrypts the OD using KENC at 426. Note that Figure 4 A secure channel can be used for privacy purposes.

[0091] In the illustrated embodiment, AP 136 then requests a signature for the OD from SE 134 at 428. At 432, SE 134 computes the ODSignature by signing the OD with the secret key se.SK and returns the ODSignature to AP 136 at 434. In the illustrated embodiment, the signature may be part of the challenge in the OD. Encryption using the long-term secret key se.SK prevents privacy-sensitive data from being leaked in a man-in-the-middle attack and allows the phone to share a unique identifier or certificate with the system 110 without leaking it to an eavesdropper. In some embodiments, the mobile device 130 is further configured to require user authentication for the signing step, for example, biometric authentication of the signing using SEP 210. Generally speaking, in some embodiments, the mobile device 130 may be configured to require touch ID or other user verification at this step.

[0092] In the illustrated embodiment, AP 136 then sets a command at 436 (which indicates the desired operation to be performed by system 110 in some embodiments) and MACs and encrypts the response of system 110. In the illustrated embodiment, the response includes ODSignature at 438, a hash of the public key se.PK, and the command. This can utilize the established secure channel and can allow system 110 to authenticate mobile device 130. Note that while both encryption and MAC are discussed in various embodiments, encryption using a secret key without a MAC can be used in other embodiments.

[0093] In the illustrated embodiment, at 442, the system 110 verifies the MAC using the KMAC portion of the shared secret, decrypts the ODSignature using the KENC portion of the shared secret, and verifies the ODSignature using se.PK (as received and stored during the pairing process). In the illustrated embodiment, the system 110 applies the associated access policy (e.g., to determine whether the user is allowed to perform the requested operation) and executes the command if the user is authorized. For example, the system 110 may unlock the vehicle doors to allow access to the interior, allow the system to be driven, allow the alarm to be disabled, etc.

[0094] In some embodiments, the disclosed techniques prevent the mobile device 130 from releasing unique identifiers or data without the user's consent (e.g., potentially allowing the use of a LOGG radio component to track the mobile device). Specifically, public key certificates, public key hashes, or other types of keys / device unique identifiers can be used to track a user's device, but the disclosed techniques can prevent this information from being intercepted by establishing a secure channel before exchanging this information and / or by authenticating the system before transmitting this information.

[0095] In some embodiments, the disclosed technology has a forward secrecy property, which prevents an attacker who manages to obtain a long-term key from being able to decrypt past communications. In some embodiments, this property is achieved by using a temporary key on each side. In other embodiments, a more relaxed forward secrecy property can be achieved by using a long-term key on the system side and a temporary key on the mobile device side. This can simplify the specific implementation on the system side.

[0096] In some embodiments, operations described as being performed by AP 136 (eg, establishing a secure channel) may be performed by SE 134 , which may reduce flexibility in the control of system 110 but may improve overall security.

[0097] In various embodiments, user authentication may be performed in addition to authentication of device 130. Authentication may prevent unauthorized users from using mobile device 130 to authorize system 110. For example, authentication may be performed at least in part by SEP 210, which may prevent SE 134 from performing further communications for pairing or authorization sessions until authentication is complete. In some embodiments, a biometric template may be stored in secure circuitry included in the system and may be configured to perform at least a portion of biometric authentication. In other embodiments, biometric authentication may be handled entirely by the mobile device. In other embodiments, authentication of mobile device 160 may be performed without authenticating the user of mobile device 160, for example, to allow a user to physically lend their mobile device to another user for system access purposes.

[0098] Example authorization to another mobile device

[0099] Figure 5 is a communication diagram illustrating exemplary messages between the system 110, the application processor 136, and the SE 134 for authorizing another mobile device 160. Figure 15 Additional embodiments for authorizing a sharer device (the device with which authorization is being shared) are discussed.

[0100] In the example embodiment at 502, the AP 136 of the owner of the system 110 selects a set of rights to be granted to another mobile device. For example, the owner can limit the speed limits available to the other mobile device, the times of day the other mobile device can access the system 110, etc. Note that although the term "owner" is used herein for convenience, the AP 136 and SE 134 can be included in the mobile device of a user who does not actually own the system 110, as long as the mobile device has been previously paired with the system 110.

[0101] In the illustrated embodiment, the owner AP 136 sends a notification at 504 that key sharing is required, along with information specifying the rights, to the other AP 536 (where, in the illustrated embodiment, the other AP 536 and the other SE 534 are included in another mobile device 160). The AP 536 sends the rights information and a key pair generation request to the SE 534 at 506, which generates a public / private key pair (se_other.SK and se_other.PK) and a corresponding certificate, se_other.Cert, at 508. In the illustrated embodiment, the SE 534 also embeds the rights in the certificate (this prevents unauthorized changes to the rights). The SE 534 then sends the se_other.Cert back to the AP 536 at 512, which forwards it to the AP 136 at 514 along with the signature request.

[0102] In the exemplary embodiment at 516, AP 136 checks se_other.Cert using a root certificate (e.g., from the phone manufacturer of mobile device 160), checks the entitlements (e.g., to ensure they have not been altered), and authenticates the user. Authentication may include biometric authentication, a PIN, a username / password combination, and the like. AP 136 then sends a signing request and se_other.Cert to SE 134 at 518, which signs the certificate with se.SK at 522 and returns the signed certificate, se_other.CertSignature, to AP 136 at 524. Communications between mobile devices can be performed locally (e.g., via a direct wireless connection such as NFC or Bluetooth) or over a network. Generally speaking, for example, the various communications between devices discussed herein can be performed remotely or in close proximity via a local direct wireless connection.

[0103] In the illustrated embodiment, AP 136 sends the signature at 526 to AP 536, which then uses the signature at 528 as a key identifier in an access transaction with system 110. System 110 can check the rights in the signature to enforce the rights. For example, a transaction with mobile device 160 may be similar to Figure 4 In this way, the user of mobile device 130 can securely authorize mobile device 160 to perform a specified set of operations using system 110. This can be used to allow friends, family members, tenants, etc. to access system 110. In the context of ride-sharing, mobile device 160 can be the person or entity that rents or shares access to system 110.

[0104] In some embodiments, key sharing can be delegated to a third party, such as a management company of the sharing network. In this scenario, the server can generate the key pair (e.g., rather than the mobile device 160), so that the owner device can verify the source of the public key using the root certificate of the sharing network. The management company can have the following rights, such as: opening the car door, starting the engine, adding / removing friend public keys to / from the system 110, and expiration date.

[0105] In addition, in some embodiments, the mobile device 130 is configured to revoke specific keys from other mobile devices in response to user input. In these embodiments, the system 110 can remove the corresponding certificate or mark it as revoked (so that the certificate can be reactivated later if needed). Once revoked, if another mobile device attempts to command the system 110 to perform an operation, the transaction will not be accepted. In some embodiments, when the owner mobile device is unpaired from the system 110, the system 110 is also configured to revoke any friend keys that have been authorized.

[0106] In some embodiments, the rights for authorizing a friend may include, but are not limited to: opening car doors, starting the engine, removing the public key from the system, key expiration date, speed limit, location limit, time limit, etc.

[0107] In some embodiments, another party, such as the system manufacturer, may require input regarding what operations the system allows (e.g., adding a new key or a new owner pairing). This may enable the manufacturer to better track ownership changes for warranty purposes, for example. In these embodiments, in addition to the signatures for certain operations performed by the user's device, the system 110 may also request signatures from another party's server before performing certain operations.

[0108] In various disclosed embodiments, pairing and key sharing can be performed offline (e.g., when the system is not connected to a wide area network). Private keys may never leave the secure element or SEP embedded in the mobile device, which may prevent tampering. Furthermore, the disclosed technology can reduce the number of exchanges required to access a transaction relative to conventional technologies. The disclosed technology can even provide security over untrusted channels. In addition, the disclosed technology can provide protection against both active and passive eavesdroppers.

[0109] The following table provides non-limiting example encryption algorithms that may be used for various operations disclosed herein, according to some embodiments:

[0110]

[0111] Exemplary Online Operation

[0112] The various embodiments described above can be performed offline between devices that are close to each other (e.g., in the absence of a wide area network connection). In some embodiments, the system manufacturer may also allow communication over a wide area network (e.g., the Internet) to perform remote operations. In some embodiments, the manufacturer or some other entity may act as an agent to provide network access so that the system is not directly exposed to the network. The entity may require system authentication to the entity's server. Online techniques for adding friend keys to the system are discussed below (in this article, friend keys may also be referred to as sharer keys, and the term "friend" is used for convenience, but is not meant to imply any specific relationship between the sharer / friend and the owner). In other embodiments, similar online techniques can be used for any of the various other operations discussed herein, and so on.

[0113] In some embodiments, the public key stored in the control unit 137 is synchronized with the server, for example on a best-effort basis. For example, each time a new owner is paired and each time a new friend key is added, the system 110 may be configured to attempt to synchronize its stored public key with the server. In some embodiments, the system 110 is configured to provide a non-secret unique identifier and uniform resource identifier (URI) as a means of reaching the system 110 via the Internet. This allows the mobile device 130 to establish a secure session with the server (for example, using a protocol such as Transport Layer Security (TLS) to allow the device 130 to authenticate the server). Once the session is established, the device 130 can use the SE 134 to sign the challenge provided by the system 110 and / or the command executed by the system 110. Before transmitting the request to the system 110, the server can act as a proxy to check the packet formatting and signature. The server can also provide firewall-type protection to prevent denial of service attacks or malformed packets. In some embodiments, server authentication of the device 130 may include client authentication after the device 130 successfully signs the server challenge using a valid key.

[0114] In some embodiments, an entity such as a system manufacturer may wish to oversee various operations described herein, such as issuing new keys or owner pairing. In these embodiments, in addition to signatures provided by the owner device or a friend device, the system 110 may require a signature from the entity's server before performing certain operations. However, such oversight may prevent these operations from being performed offline.

[0115] For example, mobile device 130, device 160, and / or system 110 may notify the server that a new key has been issued, requiring at least one of the parties involved to be online (connected to the server) to retrieve the server signature. In these embodiments, if none of the devices involved can reach the server, system 110 may allow the use of the new key with limited functionality until the signature can be retrieved from the entity. For example, a new friend user may be allowed access to the system, but only if they drive at a threshold speed and within a threshold distance of a specified location until online authorization has been completed. In some embodiments, the server is configured to remotely disable the requirement for a server signature, for example, if the server becomes unavailable.

[0116] Figures 6A to 6B , illustrates exemplary communications involving server 610 according to some embodiments. Note that Figure 6B yes Figure 6A Continuation of communication.

[0117] In the illustrated embodiment, the communication is as described above with reference to Figure 5 This continues until AP 136 receives se_other.CertSignature at 620. At this point, in the illustrated embodiment, if a network connection to server 610 (e.g., via the Internet) is available at 622, AP 136 requests the server signature for se_other.Cert and se_other.CertSignature. If this is the case, server 610 checks se_other.CertSignature at 624 and signs se_other.Cert if it is valid. In the illustrated embodiment, server 610 also stores se_other.Cert until its expiration time. Server 610 then sends se_otherServer.CertSignature to AP 136 at 626.

[0118] In the illustrated embodiment, the AP 136 sends the se_other.CertSignature and se_otherServer.CertSignature to the other AP 536 at 628 (if the server signature is received; otherwise, the AP 136 sends the first signature without the server signature). If the se_otherServer.CertSignature is not provided, the AP 536 is configured to request a signature from the server 610 at 632 in the illustrated embodiment.

[0119] Now go to Figure 6B, server 610 may process the request from AP 536 at 634 similar to the request from AP 136. In the illustrated embodiment, AP 536 then initiates a transaction with system 110 at 638 and sends se_other.Cert, se_other.CertSignature, and se_otherServerCertSignature (if the server signature has been received, otherwise it may be omitted).

[0120] In the illustrated embodiment, if connectivity is available, if the system 110 has not yet received the server signature, it requests the server signature at 644 and receives a response from the server 610 at 648. The system 110 then checks the se_otherServer.CertSignature (if present) at 652 and also checks the se_otherCertSignature. If both signatures are verified, the system 110 is configured to apply the rights of se_other.Cert to the transaction. If the server signature is not obtained, the system 110 can be configured to allow a more restricted set of rights for the transaction (or can deny the transaction altogether).

[0121] Despite Figures 6A to 6B In the embodiment of FIG. 1 , each device involved in a transaction is configured to request a signature from server 610, but this may not be the case in other embodiments. Furthermore, other devices may use similar techniques to request a signature from the server. In various embodiments, the disclosed techniques may allow server 610 to oversee transactions with system 110 in a secure manner.

[0122] In some embodiments, mass pairing can allow an entity to manage a group of systems. For example, an owner key can be generated on the entity's server, and the public key can be stored separately in the system processor (e.g., ECU) during manufacturing. In some embodiments, the same public key can be pushed to all systems and then transferred using the ownership transfer techniques described herein.

[0123] System manufacturers can provision root certificates in system processors (e.g., ECUs) during production. Manufacturers can also push new certificates after production, for example, to support other phone manufacturers. These certificates can include root certificates from the secure element manufacturer, the phone manufacturer, and / or the system manufacturer.

[0124] Exemplary Methods

[0125] Figure 7A is a flow chart illustrating a method for pairing with a system via a mobile device according to some embodiments. Figure 7AThe methods shown can be used in conjunction with any of the computer circuit systems, systems, devices, elements, or components disclosed herein (as well as other devices). In various embodiments, some of the method elements shown can be performed concurrently in an order different from the order shown, or can be omitted. Additional method elements can also be performed as needed.

[0126] At 710, in the illustrated embodiment, in response to receiving a first request to perform a pairing operation with the system, the mobile device establishes a first shared encryption key with the system. This may include establishing a temporary key pair and deriving a shared secret based on the temporary key pair. The shared secret may be derived using ECDH or some other asymmetric encryption technology. The request to perform the pairing operation may be received from the system or from a user (e.g., via an input component). It should be noted that various embodiments are described herein with reference to vehicles and mobile phones. These devices are included for illustrative purposes and are not intended to limit the scope of the present disclosure. In various embodiments, the disclosed technology can be used for mutual authentication between two or more different types of devices. For example, similar technology can be used to authenticate devices with paired wearable devices, distributed sensors, IoT devices, etc.

[0127] At 720, in the illustrated embodiment, the security circuit (eg, SE 134 or SEP 210) generates a public key pair and a certificate (eg, se.Cert) corresponding to the public key pair that includes the public key of the public key pair. In some embodiments, this is performed by the security circuit.

[0128] At 730, in the illustrated embodiment, the mobile device encrypts the certificate using the first shared key.

[0129] At 740, in the illustrated embodiment, the mobile device sends the encrypted certificate to the system. This can end the pairing process from the mobile device side. In other embodiments, the mobile device can receive an indication indicating a successful pairing.

[0130] In some embodiments, the mobile device is configured to display a value generated based on the public key pair and request the user of the mobile device to confirm that the system also displays the value. In some embodiments, this can avoid unintentional or malicious pairing.

[0131] In some embodiments, in response to a second request to allow another mobile device to access the system, the mobile device uses the private key of the public key pair to sign a certificate of another public key pair generated by the security circuit of the other mobile device. In some embodiments, the mobile device requests a server signature of the certificate signed by the security circuit via the wide area network, and the server signature can be used by the system to determine whether to grant the operation requested by the other mobile device.

[0132] In some embodiments, the mobile device indicates whether the mobile device is allowed to use some of a set of rights specified by a user of the mobile device.

[0133] Figure 7B is a flowchart illustrating a method for pairing a system with a mobile device according to some embodiments. Figure 7B The methods shown can be used in conjunction with any of the computer circuit systems, systems, devices, elements, or components disclosed herein (as well as other devices). In various embodiments, some of the method elements shown can be performed concurrently in an order different from the order shown, or can be omitted. Additional method elements can also be performed as needed.

[0134] At 750, in the illustrated embodiment, the processing element of the system establishes a first shared encryption key (which may be, for example, Figure 7A key of element 710).

[0135] At 760, in the illustrated embodiment, the processing element of the system receives from the mobile device an encryption certificate corresponding to the first public key pair and including the public key of the pair. For example, the public key pair can be generated by security circuitry of the mobile device.

[0136] At 770 , in the illustrated embodiment, the processing element of the system decrypts the encrypted credential using the first shared encryption key and stores the decrypted credential.

[0137] Figure 8A is a flowchart illustrating a method of authentication by a mobile device according to some embodiments. Figure 8A The methods shown can be used in conjunction with any of the computer circuit systems, systems, devices, elements, or components disclosed herein (as well as other devices). In various embodiments, some of the method elements shown can be performed concurrently in an order different from the order shown, or can be omitted. Additional method elements can also be performed as needed.

[0138] At 810, in the illustrated embodiment, the mobile device establishes a second shared encryption key with the system (e.g., which may be different from the first shared encryption key used for pairing). This may be performed based on communications from the system, based on detecting proximity to the system, etc. For example, this may include using a temporary key pair and ECDH.

[0139] At 820, in the illustrated embodiment, the mobile device receives a challenge from the system and generates a response to the challenge received from the system using the private key (e.g., se.SK) of the public key pair established during the pairing session with the system. For example, the security circuit can use the secret key to sign the challenge.

[0140] At 830, in the illustrated embodiment, the mobile device encrypts the response using the second shared encryption key.

[0141] At 840, in the illustrated embodiment, the mobile device transmits the encrypted response to the system.

[0142] Figure 8B is a flowchart illustrating a method for authenticating a mobile device by a system according to some embodiments. Figure 8B The methods shown can be used in conjunction with any of the computer circuit systems, systems, devices, elements, or components disclosed herein (as well as other devices). In various embodiments, some of the method elements shown can be performed concurrently in an order different from the order shown, or can be omitted. Additional method elements can also be performed as needed.

[0143] At 850, in the illustrated embodiment, the processing element of the system establishes a second shared encryption key (e.g., Figure 8A key of element 810).

[0144] At 860, in the illustrated embodiment, the processing element issues a challenge to the mobile device in response to the requested operation. The operation can be automatically requested by the mobile device (e.g., based on proximity to the system), based on input to the mobile device, based on information received from the system, etc. For example, the challenge can be included in an operation dictionary. The challenge can be encrypted using a shared encryption key. In some embodiments, information indicating the requested operation is included in the challenge, which can enable the mobile device to confirm whether the requested operation is actually desired.

[0145] At 870, in the illustrated embodiment, the processing element receives a response to the challenge and decrypts the response using the second shared encryption key.

[0146] At 880, in the illustrated embodiment, the processing element uses the private key of the public key pair established during the pairing session to verify that the response is signed by the mobile device and then authorizes the requested operation. For example, the processing element may use se.PK to verify that the response is signed using se.SK. In some embodiments, if Figure 8B If one or more elements of the processing element fail (e.g., a shared encryption key is not successfully established, the response to the challenge is incorrect, the response to the challenge is not properly signed, etc.), the processing element rejects the requested operation.

[0147] Exemplary Multiple Transaction Type Implementation

[0148] In some embodiments, multiple types of authentication transactions are supported. Figures 9A to 9Cis a communication diagram illustrating an exemplary transaction flow with two types of transactions (which may be referred to herein as "standard" transactions and "fast" transactions). In some embodiments, standard transactions do not involve pre-established symmetric keys, but may be used to generate such keys that are stored and may be used in one or more subsequent fast symmetric transactions. Note that Figure 9B and Figure 9C yes Figure 9A Continuation of the communication initiated in .

[0149] exist Figure 9A , system 110 and mobile device 130 generate their own temporary key pairs and start communicating at elements 902-906. It should be noted that the temporary key pair can be generated before and / or after starting communication. Because this process takes time, in various embodiments, it may be desirable to generate keys before the transaction begins to reduce the transaction time visible to the user. Starting communication may include system 110 using, for example, NFC anti-collision with ECP to initiate communication. At 908, system 110 then generates a random (or pseudo-random) transaction.ID for the current transaction and sends message 910 (in the illustrated embodiment, this is a SELECT ACCESS message, but various types of messages may be used in other embodiments). In some embodiments, the message indicates the applet ID of the applet executable on the mobile device 130 (e.g., via SE 134) to perform the transaction.

[0150] This document uses the following terms and symbols:

[0151] In some embodiments, the AP is, for example, an application processor of a mobile device.

[0152] In some embodiments, CASD is a control authority security domain, and the certificates stored therein may be referred to as "SE certificates."

[0153] DoS means Denial of Service.

[0154] ECP stands for Enhanced Contactless Polling

[0155] HCI refers to the host communication interface

[0156] In some embodiments, IVe is the initialization vector used for symmetric encryption. This vector may change in each transaction, for example, due to a changing transaction.ID.

[0157] In some embodiments, KAEseed is a symmetric long-term key used to derive encryption and MAC session keys. It can be stored in NVM on both sides and can also be used as a root key for fast transactions. Its lifespan can be determined by the security policy implemented on the system side (e.g., a maximum of 10 transactions before renewal, always renewed at engine startup, etc.).

[0158] In some embodiments, KAEe is a derived symmetric key used to encrypt the phoneIdentifier and confidentiality payload.

[0159] In some embodiments, KAEm is the derived symmetric key used to compute phoneTag.

[0160] In some embodiments, the KDF is a key derivation function. In various embodiments, different derivation constants can be used for derivations from the same input secret.

[0161] In some embodiments, the KTS is a Key Tracking Server.

[0162] LPM refers to Low Power Mode.

[0163] PAKE stands for Password Authenticated Key Exchange.

[0164] In some embodiments, phone.Cryptogram is a MAC value calculated from the unique public transaction data. It can indicate that the device has the same symmetric key as the system. In some embodiments, it is only used in fast transactions.

[0165] In some implementations, system.Sig is used to indicate that the system owns system.SK. It can be signed with a temporary key, system Identifier, and transaction.ID.

[0166] In some embodiments, DH is the Diffie-Hellman key exchange function.

[0167] In some embodiments, transaction.ID is a unique identifier for the transaction that is used as a variable element by both parties for symmetric key derivation and MAC / signature generation.

[0168] In some embodiments, the systemIdentifier is a unique identifier for the system. For NFC transactions, it can be protected by the range of the RF field. For BT transactions, it can rely on the privacy protection of the BT channel. On the device side, it can be used to determine the system's long-term public key.

[0169] In some embodiments, phoneIdentifier is a unique identifier for the device. In some embodiments, the privacy of the device's unique identifier during the transaction is protected by sending it in a secure channel after the phone has authenticated the system. It can be used on the system side to select the device's public key to verify the signature of the transaction. Type is a reader-determined value that indicates which traffic flow should be used, fast or standard / full.

[0170] In some embodiments, transaction.Type is a reader-determined value that indicates which flow rate should be used, e.g., express or standard / full (among other possible types of transactions).

[0171] In some embodiments, phoneData is an encrypted phone identifier and optional mailbox data.

[0172] In some embodiments, the phoneTag is a MAC calculated from the transaction related data.

[0173] In some embodiments, the phoneAuthenticatedData includes a phone identifier and a phone signature.

[0174] The notation KAEe:KAEm:IVe=KDF(...) means that all three values ​​are derived from the same KDF using different derivation constants. The constants are not specified in this document.

[0175] The notation phoneData:phoneTag=EncMac(KAEe:KAEm)(IV=IVe, AD=…, AE=…) indicates that phoneData is data AE encrypted using KAEe, and phoneTag is a MAC value obtained through AD using KAEm.

[0176] At 912, in the illustrated embodiment, the mobile device 130 executes the indicated applet to send a SELECT response using the temporary phone public key phone.ePK. In some embodiments, the system 110 can use BUS-S1 transport to send phone.ePK to a processor configured to perform the disclosed operations. In various embodiments, the system 110 can include one or more NFC devices (e.g., in a door handle, near the ignition, etc.) that can operate as secure element readers and can communicate with one or more processors configured to perform cryptographic operations. In some embodiments, the buses used for these communications can be relatively slow, so the fast transaction techniques can reduce the amount of data transmitted on these buses compared to standard transaction techniques.

[0177] At 914, the system 110 then sends an AUTH0 command including the system public key system.ePK "system identifier" value (which may be unique to the system 110) and the transaction ID. The AUTH0 command may also indicate which transaction type should be performed, for example, standard or fast. In response, the mobile device 130 generates a random shared secret KAEseed or selects a previously negotiated KAEseed for the transaction. In some embodiments, the generation / selection is performed using a constant time interval to avoid transmitting information about the system identifier (for example, to avoid indicating whether the system identifier is already known to the device). In the illustrated embodiment, if the system identifier is known and a corresponding KAEseed exists, the existing KAEseed may be selected. This can be used for fast path transactions, as discussed in further detail below. Otherwise, a generated random KAEseed may be selected.

[0178] At 916, in the illustrated embodiment, the mobile device 130 then uses the same KDF to calculate KAEe and KAEm using the selected KAEseed, transaction.id, and the string "auth1" (note that this string is for illustrative purposes, but any of a variety of values ​​known to both parties may be implemented in various embodiments). (Note that the mobile device 130 may not generate a KAEe for the fast transaction type). The mobile device 130 further determines phone.Cryptogram as the MAC (KAEm) of ("AUTH0cmd" | phone.ePK | system.ePK | systemIdentifier | system.PK | transaction.ID | phoneIdentifier | phone.PK) and sends an AUTH0 response using phone.Cryptogram. phone.Cryptogram may involve another bus transmission BUS-S2 of system 110. In some embodiments, the mobile device does not calculate a KAE value or generate ciphertext for standard transactions.

[0179] At 920, based on the AUTH0 response, the system 110 may have different routes of proceeding for the standard technique and the fast technique. For the standard technique (e.g., if the policy or context requires standard authentication or if the phone.Cryptogram cannot be verified), the system 110 ignores the phone.Cryptogram (or simply receives a confirmation message without the ciphertext) and proceeds to Figure 9BFor the fast technique, the system 110 searches for known phones until a matching phone.Cryptogram is found. The system 110 then calculates KAEm (and KAEe for standard transactions) as the KDF of a pre-negotiated seed for the mobile device (e.g., KAEseed[i] from a previous standard transaction) and transaction.ID. For example, this technique of searching for known mobile devices can avoid publishing an identifier for the mobile device 130, which can increase privacy and prevent tracking of the mobile device 130. Generally speaking, the disclosed techniques can avoid releasing public key certificates, public key hashes, or other keys / device-unique identifiers that could be used to track the device.

[0180] The system 110 then attempts to verify the phone.Cryptogram MAC and may immediately authenticate and authorize the requested action in response to a successful verification (which may end the quick transaction). If verification of the phone.Cryptogram is unsuccessful, standard transaction techniques may continue.

[0181] Now go to Figure 9B At 930, system 110 discards phone.Cryptogram (because this is not a fast transaction) and generates a system.eCert containing system.ePK, phone.ePK, system Identifier, and transaction.ID signed with system.SK to generate system.Sig. In the illustrated embodiment, system 110 then sends an AUTH1 command 934 including system.Sig. This may involve another bus transfer of system.Sig BUS-S3 by system 110.

[0182] In the illustrated embodiment, the system 110 then uses the KDF of the DH key exchange of system.eSK and phone.ePK, system.ePK, phone.ePK, and system.PK to calculate KAEseed. In some embodiments, the KAEseed can be stored as a shared symmetric key and used for subsequent quick transactions. The shared secret can be used indefinitely or can be of limited use (e.g., it can expire after a specific time interval or number of uses). Generally speaking, KAEseed is an example of a shared secret calculated using elliptic curve cryptography on a temporary key and a KDF including the system public key (e.g., system.PK). The system 110 then uses the KAEseed and the KDF of transaction.ID to calculate KAEe, KAEm, and IVe.

[0183] In the example embodiment at 932, the mobile device 130 verifies the system.eCert using the public key system.PK and the received system.Sig. The mobile device 130 then stores the KAEseed in non-volatile memory for the systemIdentifier of the system 110. Then, if the verification is successful, the mobile device 130 generates phoneAuthenticatedData as the previously calculated phone data and phoneSig, and sends an AUTH1 response 940 using the phoneAuthenticatedData. In some embodiments, this may involve another bus transmission of the phoneAuthenticatedData by the system 110.

[0184] In the illustrated embodiment, the system 110 then generates phoneTag' at 942 by MACing the phoneAuthenticatedData using KAEm, decrypting the phoneIdentifier, looking up and verifying phone.PK using the phoneIdentifier, verifying phone.Sig using the public key phone.PK, decrypting any packet data, and storing KAEseed in non-volatile memory for the phoneIdentifier of the mobile device 130. Once verification is successful, the system 110 can authorize the requested action, such as starting a motor or engine.

[0185] In some embodiments, a standard transaction type is required for certain types of actions, such as starting the engine or shifting the system 110 from park. In some embodiments, a fast transaction type may be used for an NFC reader that has a slower bus relative to other readers in the system 110 (e.g., a reader located in a vehicle door rather than in the interior console).

[0186] Now go to Figure 9C , the system 110 and the mobile device 130 can calculate KS1, KS2, IV1, and IV2 using KAEseed, transaction.ID, phone.ePK, and a KDF of one or more known values ​​or strings, as shown at 944 and 946. In some embodiments, these values ​​can be used in a session to transfer additional information between the system 110 and the mobile device 130.

[0187] In some embodiments, the mobile device 130 includes one or more mailboxes for storing data from the system 110. Figure 18Discussing exemplary mailbox implementations. In some embodiments, a privacy-protected mailbox can be accessed by AP 136 without encryption, while a confidential mailbox can only be accessed by system 110 via secure NFC. Generally speaking, a mailbox can be used to store a variety of information, which can be in a format defined by the manufacturer or designer of system 110. In some embodiments, this information can include an anti-theft token. In some embodiments, this information can include settings indicating parameters for performing one or more actions (e.g., comfort settings related to seat and mirror positions, etc.). Thus, the disclosed techniques for mobile device 130 can enable communication with a variety of different types of systems.

[0188] In some embodiments, the system 110 uses a confidential mailbox to store fixed keys during pairing with the mobile device 130. Before performing certain actions (e.g., starting an engine), the system 110 can retrieve and verify one or more fixed keys from the confidential mailbox. Once a key is used to authorize the requested action, the system 110 can discard it.

[0189] In some embodiments, the private mailbox is used to store user settings, such as for third-party applications, diagnostics, commands, wireless pairing information, etc. In some embodiments, the private mailbox supports random access.

[0190] In some embodiments, KAEseed can also be used as a symmetric key for ultra-wideband (UWB) communications. These communications can use time-of-flight to verify the proximity of mobile device 130 and system 110. The shared secret techniques discussed herein can be used to authenticate that such communications are actually being performed with an authorized device.

[0191] In some embodiments, the validity of keys shared with other mobile devices is managed by a generation counter that is automatically incremented when the system 110 receives a complete access list (although the counter may remain unchanged when incremental additions to the list are performed, e.g., to allow existing entries to remain valid). The counter may be monotonic and its size is designed to avoid re-counting. In these embodiments, the system 110 may reject any previous or pending requests signed with a generation counter that is lower than the counter value. This may prevent a user from accidentally forgetting a friend's mobile device that has access to the system 110, intending to let the mobile device's access expire.

[0192] Example standard transaction using KDF

[0193] Figure 10 An asymmetric transaction according to some embodiments is shown. In some embodiments, a shared secret established during such a transaction (e.g., KAEseed discussed below) can be saved by the device for subsequent fast path (e.g., symmetric) techniques. In some embodiments, Figure 10 The technique shown in is similar to Figures 9A to 9C , but focuses only on standard techniques (and omits details related to fast path techniques). In some embodiments, asymmetric encryption provides relatively strong authentication and forward secrecy, while fast transactions can provide improved performance (e.g., when processing resources are limited). In some embodiments, standard transactions are always used for the first time by a friend device (also referred to herein as a "sharer") that first contacts system 110. Even when a fast transaction is requested, standard transactions can be forced by mobile device 130 (e.g., for a first contact or an unknown system) or by system 110 (e.g., when a symmetric key is not established).

[0194] Generally speaking, in the illustrated embodiment, a shared secret (KAEseed) is negotiated using a temporary key pair and a previously determined long-term key (from pairing). This shared secret is used by the mobile device to generate a signature (signed using the long-term secret key), and the signature is encrypted along with other phone data such as the phone ID. After verifying the signed certificate from the system, the mobile device sends the data to the system. The system verifies the phone data, decrypts it, uses the phone ID to look up phone.PK, and then verifies the signature using phone.PK. In the illustrated embodiment, the system and mobile device then use the values ​​established during the standard transaction to transmit mailbox data, which can be used for various communications and purposes.

[0195] Even more generally, Figure 10 This involves the system generating authentication material, sending the material to the mobile device 130, which authenticates the material, establishes a dedicated channel, and generates endpoint authentication material. The system 110 then authenticates the mobile device and may establish a secure channel. Authentication may be used to authorize one or more actions, and various types of information may be exchanged using dedicated and / or secure channels. The disclosed techniques may allow the system 110 to be authenticated before the mobile device 130 provides any identifying information, and may also provide encryption of information used to identify the mobile device 130 using a secure channel.

[0196] More specifically, at 1002, in the illustrated embodiment, the system 110 generates a system temporary key pair (e.g., system.eSK and system.ePK). At 1004, the system 110 performs NFC anti-collision using enhanced contactless polling (although other techniques may be used in other embodiments). At 1006, the mobile device 130 generates a phone temporary key pair (e.g., phone.eSK and phone.ePK) and wakes up at 1008 upon polling detection.

[0197] At 1010, in the illustrated embodiment, system 110 generates a random transaction ID and sends an application identifier message 1012 to mobile device 130. For example, the message can be a SELECT ACCESS AID message that indicates the application identifier to select the appropriate application on mobile device 130. At 1014, mobile device 130 responds with the phone temporary public key phone.ePK. In some embodiments, the transaction includes a SELECT command / response, an AUTH0 command / response, an AUTH1 command / response, and optionally one or more SET / GET commands / responses (AUTH and SET / GET messages are discussed in further detail below).

[0198] At 1016, in the illustrated embodiment, system 110 sends a command with transaction parameters. In some embodiments, this may be referred to as an AUTH0 command. In some embodiments, the command includes: system.ePK|systemIdentifier|transaction.ID|transaction.type=standard. In other examples, transaction.type may indicate a fast transaction or some other type of transaction. Thus, the AUTH0 command may provide the system public information required by the device (static identifier and random session information), and, if applicable, calculate the ciphertext based on the symmetric secret established for fast transactions. For the standard transaction shown, the response at 1018 may simply be an acknowledgment with no data.

[0199] At 1020, in the illustrated embodiment, system 110 generates a temporary certificate with the transaction ID and the system identifier, and signs the certificate to generate a signature. This may include, for example, generating a temporary certificate system.eCert containing system.ePK|phone.ePK|systemIdentifier|transaction.ID. This may be signed using a secret key from the pair (e.g., system.SK) to obtain a signature system.Sig.

[0200] At 1022, in the illustrated embodiment, the mobile device 130 generates a derived shared secret, generates a signature, and encrypts the signature based on the derived shared secret. In some embodiments, this includes generating KAEseed = KDF(DH(system.ePK, phone.eSK), system.ePK | phone.ePK | system.PK). In this example, the Diffie-Hellman function DH is an example of a key exchange function used to generate a shared secret, and the key derivation function KDF generates the derived shared secret based on the output of the key exchange function and the public keys system.ePK, phone.ePK, and system.PK. In some embodiments, the mobile device 130 also defines diversifier = transaction.identifier | phone.ePK | system.ePK | systemIdentifier | system.PK. In some embodiments, the mobile device 130 calculates KAEe1:KAEm1:IVe1=KDF(KAEseed,diversifier|"phone to system") and calculates KAEe2:KAEm2:IVe2=KDF(KAEseed,diversifier|"system to phone"). These derived symmetric keys can be used to encrypt information identifying the phone and / or confidential payload, which can enhance the security of such information.

[0201] In some embodiments, the mobile device 130 generates the signature phone.Sig=Sign(phone.SK, transaction.Identifier|phone.ePK|system.ePK). In some embodiments, the mobile device 130 calculates phone.Data:phone.Tag=EncryptMac(KAEe1:KAEm1:IVe1:counter=0)(phone.Identifier|phone.Sig|[mailbox data]).

[0202] At 1024, in the illustrated embodiment, the mobile device 130 recreates the temporary certificate from the system system.eCert using system.ePK|phone.ePK|systemIdentifier|transaction.Identifier. As described below, this can help verify the temporary certificate from the system.

[0203] At 1026, in the illustrated embodiment, the system 110 sends the temporary credentials and signature generated at 1020. This message may be referred to as an AUTH1 command. In some embodiments, the system 110 authenticates itself to the device in the message by sending the signature.

[0204] At 1028 , in the illustrated embodiment, the mobile device 130 verifies the temporary certificate system.eCert using the signature system.Sig and the system public key system.PK. When the device is able to verify the signature, it can associate a new symmetric shared secret KAEseed with the verified identifier of the system 110 .

[0205] In parallel, in the illustrated embodiment, system 110 computes the same symmetric shared secret. Specifically, in the illustrated embodiment, at 1030, system 110 computes the derived shared secret KAEseed = KDF(DH(system.eSK, phone.ePK), system.ePK | phone.ePK | system.PK). System 110 also computes KAEe1:KAEm1:IVe1 = KDF(KAEseed,diversifier|"phone to system").

[0206] At 1032, the mobile device 130 sends a response (which may be referred to as an AUTH1 response) using the encrypted signature and the mobile device identifier. More specifically, the mobile device 130 may send phone.Data and phone.Tag in the message, which may include various pre-computed encrypted and MAC data, as described above.

[0207] At 1034, system 110 decrypts the data from mobile device 130, uses the identifier to look up the phone's public key, and verifies the signature phone.Sig using that public key. Specifically, this may include verifying phone.Tag, decrypting phone.Data, using phone.Identifier to look up phone.PK, verifying phone.Sig using phone.PK, and storing the KAEseed associated with phone.Identifier. Thus, when system 110 is able to successfully verify the device signature (phone.Sig), it associates the symmetric secret with the device. Other mailbox data can be decrypted and used on the system side.

[0208] In various transactions, device 130 may request the contents of the private mailbox and / or confidential mailbox at the end of the transaction, for example, using the derived keys (KAEm, KAEe) to create a secure channel.

[0209] Therefore, in the illustrated embodiment, device 130 uses the DH on the temporary key and a KDF including the long-term system key system.PK to calculate a shared secret (KAEseed). It also uses phone.SK to calculate the device signature (phoneSig). Simultaneously, the system generates a temporary certificate signed by the long-term system key system.SK and sends its signature to the device. After recreating the same temporary certificate, the device verifies the signature and, if successful, stores the shared secret (KAEseed) associated with the system identifier. The KAEseed can then be used for the upcoming quick transaction and to secure the final payload transmission using the derived symmetric keys (KAEe, KAEm). Upon receiving the AUTH1 response, the system uses the decrypted phone identifier received as part of phoneAuthenticatedData to look up the device's public key to verify the phone signature. If successful, the system decrypts the optional payload (e.g., an anti-theft token) and stores the device's KAEseed in persistent storage. Optionally, the derived session key can then be used to transmit the payload (e.g., an anti-theft token) from the device to the system. In UWB systems, the Security Domain Master Key (SASK) can be derived from the KAEseed.

[0210] In some embodiments, the privacy concern addressed by this transaction is preventing the phone from releasing the phoneIdentifier to unauthorized readers. Releasing a public key certificate, public key hash, or any type of key / device unique identifier can be considered a potential method for tracking a device without user consent. The choice of KAEseed on the device side can be implemented in a constant-time design to not disclose any knowledge to an attacker about whether the device has known the systemIdentifier. In some embodiments, forward secrecy is provided in the various transactions discussed herein, for example, due to the use of ephemeral keys.

[0211] In some embodiments, Figure 10 Various modifications can be made to transactions to improve performance. For example, a compact or compressed form can be used for ECC points, e.g., to reduce the size of the public key. In some embodiments, the minimum amount of data required to rebuild the system.eCert can be transmitted (e.g., rather than padding the eCert). In some embodiments, data such as ephemeral keys, systemIdentifier, transaction.ID, etc. can be pre-fetched. Additionally, selecting an efficient EC curve can also improve performance.

[0212] Exemplary pairing implementation

[0213] Figure 11is a communication diagram illustrating a pairing transaction using PAKE to generate session keys according to some embodiments.

[0214] In some embodiments, before pairing, the system 110 stores the device manufacturer's root certificate to verify the source of the public key it receives. In some embodiments, the system uses a root certificate stored in the OEM backend (and in these embodiments, it should be online during pairing). In other embodiments, the certificate can be provided by the device. In this case, it should be signed by an authority that can be verified by the system. In some embodiments, before pairing, the system receives a secret (pairingPassword) from the system manufacturer's backend via telematics at 1102, and the user obtains the secret (pairingPassword) from the system manufacturer's portal / app / dealer / user manual at 1104 and uses it. In the illustrated embodiment, K is a symmetric session key generated on both sides by the PAKE algorithm.

[0215] In some embodiments, at 1116 and 1120, a secure channel is established using the PAKE protocol based on the session key K. In the illustrated embodiment, temporary keys are generated on both sides (at 1106 and 1108), and a pairing request 1110 and confirmation 1112 are exchanged before establishing the secure channel. In messages 1121 and 1124, the certificates system.Cert and phone.Cert are securely exchanged over the channel. After the certificate exchange and verification, the system can then perform the standard transactions described herein (e.g., Figure 10 in order to supply data.

[0216] In some embodiments, when entering pairing mode, the system contacts the backend and requests the pairingPassword value. The conditions for entering pairing mode may be defined by the system OEM. The backend then generates the pairingPassword, transmits it to the system, and provides it to the user in parallel through the OEM user account. The user retrieves the pairingPassword (e.g., in a web browser or through an installed OEM application). The user then initiates pairing mode in the OEM application or OS on the mobile device and enters the pairingPassword. Note that the pairingPassword may also be referred to herein as a PIN. The OEM application may transmit the paringPassword directly to the applet via an appropriate OS API. In some embodiments, when both the device and the system have generated a temporary key pair based on the pairing password, both UIs invite the user to tap the NFC console reader on their device. In some embodiments, the system 110 may implement one or more policies for the pairingPassword, including, for example, the number of failed pairing attempts allowed, the behavior after a successful pairing, the behavior after too many failed attempts, a recovery process after too many failed attempts, confidential delivery to the system, and / or confidential delivery to the owner.

[0217] In some embodiments, the vehicle sends configuration information during pairing that specifies how the digital key should be set up by the mobile device. This configuration information may include various fields, for example, indicating what types of transactions are allowed, system metadata, a start date, an expiration date, etc. The operating system of the mobile device may instruct one or more applets on the secure element to create the digital key according to the configuration. The SE may also generate a long-term public key pair phone.PK and phone.SK. In some embodiments, the SE generates a certificate with the configuration information (as proof that the digital key has been created according to the configuration) and signs it using phone.SK. In these embodiments, the system 110 can verify that the digital key was created correctly by verifying the certificate and confirming that the configuration information is correct. A more detailed example with proof is given in Figure 28 and will be discussed in detail below.

[0218] Overview of Exemplary Systems and Components

[0219] Figure 12 1 is a block diagram illustrating an exemplary distributed system according to some embodiments. In the illustrated embodiment, the system includes a mobile device manufacturer backend 1230, a key tracking server 1250, an OEM business backend 1270, and other backends 1210. In the illustrated embodiment, some of these backend systems communicate with the owner device 130, the system 110, the friend device 160, and the service device 1220.

[0220] In some embodiments, the system 110 is linked to the OEM business backend via a telematics link. This link can provide a secure communication channel and can be fully controlled by the system OEM. In some embodiments, the system is equipped with an NFC reader to communicate with the mobile device for actions such as owner pairing, system lock / unlock, engine start, etc. In the illustrated embodiment, the device can also communicate with the key tracking server 1250 to track, sign and revoke issued digital keys. In some embodiments, the owner device communicates with the OEM business backend (for example, which can host the owner account) through the OEM application. In some embodiments, friend devices and service devices do not need to be linked to the OEM business backend to obtain primary services. In some embodiments, these devices can use the OEM application to access optional accounts. The device can be manufactured by various manufacturers and can communicate with multiple corresponding mobile device manufacturer backends.

[0221] In some embodiments, the KTS 1250 may trust the business backend to provide checking and signing functionality while logging changes to the keys associated with the vehicle. In some embodiments, for key sharing, the KTS 1250 logs: the friend's public key, the friend's access rights, the friend's generation counter, start and expiration dates, the key identifier, the SE signature, the owner signature, and the KTS signature.

[0222] In some embodiments, the manufacturer backend 1230 is responsible for managing the lifecycle of system key applications (or applets) on the device and supplying the root Apple OEM certificate to the application. It may also provide services for suspending, resuming, and wiping the device. In some embodiments, the device OEM backend may not be tightly integrated with the system OEM business backend 1270. In some embodiments, some connections may be used to issue OEM-based revocation or device loss / theft notifications to the owner. In some embodiments, the backend 1230 is not connected to other backends in real time. In some embodiments, the exchange of device OEM SE root certificates is performed only once between all device OEMs in order to verify and sign all unowned root certificates and supply them to mobile devices. In some embodiments, all devices using the disclosed technology should include secure circuits (such as certified secure elements) and short-range wireless (e.g., NFC) capabilities that can communicate with the system. Whitelisting of devices can be performed by each system OEM.

[0223] Figure 13is a block diagram illustrating an exemplary short-range wireless (e.g., NFC) connection according to some embodiments. In the illustrated embodiment, the mobile device 130 includes an application processor 136 connected to an NFC controller 1332. In the illustrated embodiment, the NFC controller is connected to a secure element 134 and controls the routing from the NFC antenna to the secure element or application processor 136. In some embodiments, the application processor 136 does not need to be awakened for NFC transactions. In some embodiments, the system is equipped with at least two NFC readers, such as the door handle reader 1330 and the console reader 1335 shown. In some embodiments, one ECU 137C controls all readers and includes software that executes communication protocols via NFC, including the various encryption operations described herein. In the illustrated embodiment, another ECU 137B controls screen output and one or more user input devices 1325. Another ECU 137A can also establish a secure channel to the system OEM backend via a telematics link 1320. Note that in various embodiments, ECU deployment can be different for different OEMs.

[0224] In some embodiments, the NFC component uses card emulation mode and supported ECP (e.g., ECP 2.0) and field detection mode. In some embodiments, the SE 134 supports symmetric and asymmetric encryption, stores a local certificate authority (CA) for identification and public key signing, includes a system key application, and / or includes a card content application. In some embodiments, the system key application is configured to implement fast transactions and standard transactions, store and manage anti-theft tokens, and manage owner pairing, sharing, and revocation. In some embodiments, the application allows the operating system to query the number of available keys for sharing / anti-theft tokens, the number of keys that have been shared, information about keys that have been shared, and / or information about keys that have been received from another owner. The application can track shared keys and can verify the signatures of SEs from other manufacturers. The application can be configured to temporarily disable the use of specified keys. In some embodiments, the application can be verified before it is loaded onto the SE 134.

[0225] In some embodiments, the operating system natively implements key features such as owner pairing, transactions, key sharing, and revocation. In some embodiments, it is configured to: send and receive keys via proximity sharing (e.g., AirDrop), send and receive keys via remote sharing (e.g., iMessage), send and receive keys to / from other phone OEM devices, display a list of issued friend keys, display multiple keys available for sharing, display when a key has been used on the system, store manufacturer-signed root certificates of other manufacturer SEs to verify SE signatures of public keys used for key sharing, open a secure session with the system OEM server to communicate with the system remotely (without using OEM user account credentials). In some embodiments, the operating system provides an API to the system OEM application that allows: passing the owner PIN from the backend to the device SE during the pairing process, reading and writing the private mailbox slot of the digital key for each associated system separately, writing to the confidential mailbox slot of the digital key for each associated system separately, accessing the application to execute remote commands, sharing friend keys with a server instead of the device (e.g., for professional services), receiving friend or specific keys from a server instead of the device (e.g., for sharing or professional services), retrieving non-confidential information about shared keys on the device, and / or revoking keys.

[0226] In some embodiments, the operating system is configured to request authentication (or a certain authentication type, such as biometric authentication) for certain types of actions. These actions may include, for example, owner pairing, full key sharing, service key sharing, key revocation (including on the owner device at owner request, on a friend device at friend request, on a friend device at owner request, on the owner device with a request sent to a friend). In some embodiments, all requests also arrive at the system 110 via the backend. In some embodiments, examples of actions that do not require authentication (e.g., unless explicitly configured by the user on the device) may include door lock / unlock transactions, engine start transactions, first-time transactions for friends in certain circumstances, and receiving a key revocation request from the KTS 1250 or owner / friend device (e.g., for silent revocation).

[0227] It should be noted that the various functions described herein as being performed by specific processors, software components, or hardware components are discussed for illustrative purposes, but are not intended to limit the scope of the present disclosure. In other embodiments, various functions may be performed by other elements different from those described herein.

[0228] In some embodiments, mobile device 130 is a wearable device such as a watch, which can be paired with a cellular phone, for example. In some embodiments, the functions described herein with reference to device 130 can be divided between such devices.

[0229] In some embodiments, the system 110 is configured to provide owner pairing information, such as the owner public key and / or device information, to the KTS 1250. In some embodiments, the system 110 may support changing the owner device via a backup of the non-confidential key sharing information.

[0230] In some embodiments, the cloud service system may be configured to temporarily disable the digital key functionality on a lost or stolen device (if online), remotely erase the digital key on a lost or stolen device (if online), securely bind the user identity to the device identity, and / or back up digital key sharing information to facilitate recovery of the shared key on a new device.

[0231] In some embodiments, the key tracking server 1250 is configured to provide privacy protection for stored data. In some embodiments, the KTS 1250 is accessed for data queries only when the system is stolen and the owner has authorized access. In some embodiments, the KTS 1250 has privacy separation from the system OEM business backend, records and signs keys, and checks service validity and key policy before signing (for example, it may not sign and send an ab error code with a specific reason, such as service expired, no more digital keys, check service subscription, check the number of signed keys for the service, check the validity of the owner signature (for example, using the owner.PK received from the system 110 during pairing), and / or check the validity of the SE signature (for example, using access to the manufacturer OEM root certificate). The KTS 1250 can also revoke a key on the device when it is deleted in the system or the system OEM backend, revoke a key on the system through the system OEM backend when it is deleted on the device, and / or provide a notification to the friend device that the shared friend key information has been provisioned to the system before the first friend transaction.

[0232] In some embodiments, the proposed system uses asymmetric encryption to mutually authenticate the system and device. In some embodiments, the device only reveals its identity to known systems. For situations where faster transactions are required, subsequent transactions can use the shared key agreed upon in the asymmetric transaction to authenticate the device through symmetric encryption. No TSM is required to provision keys to the device. Public keys can be exchanged by pairing the owner's device with the system. The owner can then distribute the digital keys to friends and family members. The system is envisioned to work completely offline for all relevant features (i.e., no server connection is required). In some cases, when regulatory or business constraints require online connectivity, the system design will support its addition.

[0233] In some embodiments, multiple types of keys are implemented, and a given device may hold keys for multiple systems (and may have different rows for those systems). In some embodiments, the following key types are implemented: owner, friend, professional service provider, system shared, and service specific.

[0234] In some embodiments, the system accepts only one owner device. When in an unpaired state, a device associated with the system is considered the owner device. After an owner device associates with the system, the system switches from an unpaired state to a paired state. Owner device keys are tracked by the key tracking server through the owner pairing process. Appropriate rights are defined and assigned by the system OEM (see below). The system can accept several friend devices. Friend devices may have restricted rights on the system. These rights are assigned by the owner when the key is issued and are checked by the system against the system OEM's policy for friend keys. They may also need to be registered with the tracking server before they can be accepted by the system. The issuance of professional service provider keys is not managed locally but through an application. The application provides a way for owners to share keys with professional service providers (PSPs). A PSP, represented by a server, is similar to a friend, but does not require an anti-theft token. It issues keys to employees, which include an anti-theft token and are tracked by the KTS, as the PSP is assumed to be always online. Employee devices cannot share keys. In the system sharing model, the owner is a server at the system sharing company. It issues friend keys to system sharing users and has the system track the keys. System-shared users can issue specific service keys from their devices. For the first transaction with the system, the same rules as for friend keys apply, regardless of whether the system is online or offline. For certain implementations, the system accepts a single service device active at the same time. In some embodiments, service devices cannot issue further keys to other entities. They may have other restricted rights.

[0235] In some embodiments, a digital key is represented by a data structure that includes one or more of various fields (e.g., depending on its type), such as a key identifier, a key friendly name, a VIN, a system public key, a key anti-theft token, a backup anti-theft token, owner rights, a device public key, device and OS information, a key type, a recipient account identifier, a key tracking service URL, system metadata, a start date, an expiration date, recipient rights, an SE signature, a key tracking signature, etc. In some embodiments, a digital key is represented by an instance of a data structure. Different types of keys may also have different sets of fields.

[0236] In some embodiments, the rights are stored by the system along with the corresponding public key for each device associated with the system. Depending on the system OEM policy, the owner can change the rights over the network if connectivity is available. When changing rights is not allowed, the current key can be revoked and a new key must be issued to reflect the change in rights.

[0237] Example first use of a shared secret key

[0238] In some embodiments, when a key is shared with a friend or family member, system 110 should store the friend's new public key after verifying the required signatures (discussed in further detail below). In some embodiments, the standard transaction process is used in this scenario. In some embodiments, the following additional cryptographic elements are used relative to the owner's standard transaction process: SE.sig, owner.SK, owner.Sig, friend.ePK / friend.eSK, friend.PK / friend.SK, friend.Cert, and KTS.sig. In some embodiments, SE.Sig is the signature of the public key, proving that the key was generated by a genuine secure element. In some embodiments, owner.SK is a long-term private key on the owner's device, used to sign the friend's public key when sharing access to the owner's system. This key can be the same key used in the standard transaction process (named phone.SK). In some embodiments, owner.Sig is generated when the owner signs the friend's public key, once the owner has verified that their identity and entitlements are correct and that the key has been generated on the genuine secure element. In some embodiments, friend.ePK / friend.eSK is a temporary key pair generated for each transaction and can be deleted after each transaction. In some embodiments, friend.PK / friend.SK is a long-term key pair generated by the friend's phone during device pairing. Each associated system can generate a key pair. In some embodiments, friend.Cert is a certificate embedded in friend.PK. In some embodiments, it is signed by se_friend.SK, owner.SK, and (optionally) tracking.SK. In some embodiments, once friend.PK is successfully stored in the system, the certificate becomes obsolete. In some embodiments, KTS.Sig is an optional signature added by the key tracking server that notifies the system that a new key has been recorded.

[0239] In this transaction variant, it can be assumed that the friend's public key has not been pushed into the system by the backend before the friend first approaches the system. The payload can be transmitted on the device side as [mailbox-data] in the AUTH1 response or in one of the session messages. For example, mailbox_data can = friend.Cert containing the SE signature, owner signature, and key tracking signature. When sending data, device 130 can prepare the data based on the received system identifier. When the backend has managed to provision all data into the system before the first friend transaction, the device can be notified via the KTS link and avoid sending data. In some embodiments, the payload consists of data elements obtained by the friend during the key sharing process, which may include: the friend's public key, the secure element's signature on the friend's public key, the owner's signature on the friend's public key, an optional signature of the key tracking server on the friend's public key, rights that the owner has attached to the public key before signing it, a friend SE certificate allowing verification of the friend's SE signature, and / or an owner SE certificate allowing verification of the owner SE signature.

[0240] Exemplary Anti-Theft Token Technology

[0241] In some embodiments, an anti-theft token can be used for added security. In some embodiments, mobile device 130 may store and release a secret piece of data called an ImmobilizerToken with each engine start transaction with system 110. The ImmobilizerToken can be verified by various ECUs to allow the engine to be started but may not be permanently stored within the system, for example as an anti-theft countermeasure. Therefore, in some embodiments, the system cannot be started until the ImmobilizerToken has been distributed by a key fob or associated mobile device. In some embodiments, the anti-theft token should not be copied. In some embodiments, system 110 may embed a secure element capable of locally storing the ImmobilizerToken and releasing it to the ECU after verifying a signature calculated by mobile device 130. In this case, the device may not need to store and release this token, for example, because the system may rely solely on digital signature verification and the security of its secure element.

[0242] Note that while this document discusses anti-theft tokens for purposes of illustration, this discussion is not intended to limit the scope of the present disclosure. Rather, the anti-theft token is an example of a security token or second-level security token that can be processed using the disclosed technology.

[0243] Various techniques can be used to store anti-theft tokens in the secure element of a mobile device, and these techniques may vary between system manufacturers. In some embodiments, system 110 generates one (or a set of) anti-theft tokens during the owner pairing step and pushes them to device 130 via a secure channel opened with a standard transaction. In some embodiments, the system manufacturer's backend generates one (or a set of) anti-theft tokens during the owner pairing step and pushes them to the device over the network. In some embodiments, the anti-theft token is provided by the owner to the friend and encrypted with the friend's public key during key sharing. In some embodiments, when the friend creates a service key, he or she provides their anti-theft token to the service key owner. In the next transaction with the system or over the network, the friend receives a new anti-theft token, which is registered with their public key. When the owner revokes their mobile key or the friend deletes their mobile key, the anti-theft token is also deleted. In this case, the owner can obtain a new anti-theft token so that they can share the new friend key. Issuing a new anti-theft token to the owner can be linked to the owner generating a revocation receipt from the friend's device and / or the system confirming that the friend's public key and corresponding anti-theft token have been deleted. In some embodiments, the device stores the anti-theft token in a confidential mailbox. The mailbox can be organized into slots. This allows a slot containing an anti-theft token package (e.g., friend + specific) to be associated with a public key received from a verified friend device with a valid SE signature (e.g., via key sharing).

[0244] Figure 14 14. It is a block diagram showing an exemplary mailbox organization according to some embodiments. In the illustrated embodiment, there are four slots for the owner's confidential mailbox, wherein three slots are filled (although any number of slots can be realized in other embodiments). In the illustrated embodiment, each slot is configured to store up to two anti-theft tokens. In some embodiments, each slot can be assigned to a public key (e.g., friend PK 1430 or owner PK 1440). In the illustrated example, the first slot 1410 has not yet been supplied, and the fourth slot with owner PK 1440 is reserved for the owner. In the illustrated embodiment, the second slot 1420 has received unassigned anti-theft tokens 1422 and 1424 during the owner pairing period, for example. The third slot with friend PK 1430 includes a friend's public key and an anti-theft token hash as shared evidence. When a key is revoked on a friend's device of the system, the synchronization process can provide a revocation receipt to the owner. The receipt can be signed or otherwise authenticated by the secure element of the friend's device. In response to receiving the receipt, the owner device application may delete all contents of the mailbox slot corresponding to the public key in the receipt and the revoked public key itself.

[0245] In some embodiments, the private mailbox can facilitate low power mode (LPM) operation, e.g., by making data available to the system 110 without involving the main processor of the mobile device 130. In some embodiments, for example, a secure element can be capable of providing access to private mailbox data while the device is in LPM.

[0246] Additional key sharing and tracking implementations

[0247] In various embodiments, the owner wishes to share a key with another person or entity. The owner may be an individual or a company. In some embodiments, the owner signs the public key generated by the friend and associates it with some specific rights. Offline techniques (e.g., Figure 15 ), while online techniques may be used when system 110 is reachable (e.g., as Figure 16 shown).

[0248] In the illustrated embodiment, at 1502, the system initially stores a counter system.GenCount (associated with the number of shared keys), the owner public key owner.PK, the sharer certificate (if sharing has occurred), and the system certificate system.Cert. The owner device 130 stores a copy of the counter CopyGenCount, owner.PK, and any current sharer certificates. In some embodiments, key sharing maintains the current counter value, while revoking a shared key increments the counter value. At 1506, the owner device 130 selects a set of rights and then, at 1508, notifies the sharer device 160 of the key sharing attempt and the rights.

[0249] At 1510, in the illustrated embodiment, the friend's device generates a long-term public key pair (e.g., called newSharee.SK and newSharee.PK). In the illustrated embodiment, the sharer device 160 also generates a public and private key pair for encryption (e.g., newSharee.encSK and newSharee.encPK). The sharing device 160 also generates a certificate that embeds the indicated rights.

[0250] At 1512, sharer 160 sends the certificate newSharee.Cert in the signing request to owner device 130. When requesting that owner device 130 share a digital key with a friend, the friend's SE may create a certificate newSharee.Cert containing a public key signed by the local CA on the SE. The certificate may include data elements that allow the owner to verify the authenticity of the friend's public key. Detailed techniques for certificate chaining for signature verification are discussed below.

[0251] At 1514, the owner device 130 checks the newSharee.Cert with a root certificate (e.g., the root certificate of the phone manufacturer or phone OEM of the sharer device 160), checks whether the embedded rights match those selected by the owner, and authenticates the user (e.g., using biometric authentication, a password, etc.). If authentication fails, in some embodiments, the owner device 130 is configured not to continue sharing. For example, this can prevent a stolen owner device from sharing.

[0252] At 1516, the owner device 130 may add one or more data elements, such as the entitlement and generation counter, to the digital key structure, sign it with the owner's private key owner.SK, and send the complete data back to the friend as wrappedData. In some embodiments, this includes determining newSharee.GenCount = CopyGenCount; newSharee.Sig = sign(newSharee.Cert | newSharee.GenCount) with owner.SK; and wrapped data = encryptImmobilizerToken[+data] with newSharee.encPK. This may allow the system 110 to verify, for example, that the owner device 130 has confirmed the entitlement.

[0253] At 1518, the owner device 130 sends the signature, counter, and encrypted data to the sharer device 160. For example, this may include newSharee.GenCount, newSharee.Sig, and wrappedData.

[0254] At 1520, in the illustrated embodiment, sharer 160 sends the signature and counter to system 110. At 1522, the system verifies the signature and certificate, checks the counter, and adds the sharer to the authorization list. For example, this may include verifying newSharee.Sig, verifying newSharee.Cert, verifying newSharee.GenCount == system.GenCount, and if successful, adding the sharer to the authorization list.

[0255] In some embodiments, the disclosed offline techniques may allow for non-centralized key sharing in various situations, eg, without a wide area network connection or any connection to a server.

[0256] In some embodiments, a generation counter protects the reuse of revoked keys. In some embodiments, the owner or friend can contact a key tracking server to obtain a signature. In some embodiments, the key tracking server or the owner device contacts the system OEM business backend and provides the system with one or more relevant elements of the shared digital key structure, such as: the friend's public key, rights, generation counter, start and expiration dates, key identifier, key friendly name, SE signature, owner signature, and / or KTS signature.

[0257] Figure 16 is a detailed communication diagram showing an exemplary online communication. In the illustrated embodiment, several elements are similar to Figure 15 In the illustrated embodiment, the owner device also generates a new access list for a set of current sharer devices and sends a signed copy of the new access list to the system 110.

[0258] In some embodiments, the system manufacturer may optionally allow devices used to perform remote operations to reach system 110 via a wide area network, such as the internet. To avoid exposing the system directly to the internet and making it more vulnerable to attack, the system manufacturer's server may act as a proxy, providing access to the system when the device authenticates with the system manufacturer's server. In some embodiments, the public keys stored in the system ECU are synchronized on the system manufacturer's server on a best-effort basis. In some embodiments, the system attempts to synchronize its stored public keys and revocation list with the system manufacturer's server each time a new owner pairs and each time a new friend key is added. During device pairing, the system may provide the device with a non-secret unique identifier and URI to be used with the system manufacturer's server as a means of reaching the system over the internet. Using this URI and unique identifier, the device can establish a secure session with the system manufacturer's server. The secure session can use standard protocols such as TLS, enabling the device to authenticate the server. Once the session is established, the device can use a secure element to sign challenges provided by the system and commands executed by the system. The system manufacturer's server, acting as a proxy, can check that packets are formatted and signed correctly before transmitting requests to the system. Firewall-type protection against denial of service or malformed packets can also be provided by the system manufacturer's server. In some embodiments, TLS server authentication can be upgraded with client authentication after the device successfully signs the server challenge with a valid key, which can help filter DOS attacks at the cost of increased complexity.

[0259] In some embodiments, the following online remote operations are available within a secure session with the OEM server: door lock / unlock, trunk unlock, friend key revocation, owner device removal, owner device unpairing, and / or comfort operations such as air conditioning or heating.

[0260] The system manufacturer may wish to track and / or control some of the operations herein, such as issuing new keys or owner pairing. In this context, in addition to the signature performed by the friend / owner device, the system may require a signature generated by the system manufacturer's server to allow certain operations. However, such a requirement may prevent offline capabilities for these operations. The system manufacturer's server may be notified by the owner's device, the friend's device, or the system that a new key has been issued, so that at least one of the three parties involved should be online to retrieve the signature from the server. If no party is able to reach the server, the system may still allow temporary use of the key, for example, in a limited capacity until a signature can be retrieved from the system manufacturer's server. In some embodiments, the system manufacturer is able to remotely disable the need for additional server signatures, for example, in case its server becomes unavailable at some point.

[0261] In some embodiments, if the system is offline, the friend's device presents the data element to the system in the first transaction, as described above. The anti-theft token can be transferred as part of this transaction. In some embodiments, a mailbox can be used for this transfer. When the owner and the friend use devices from different manufacturers, the sender can provide a certificate, such as a Control Authority Security Domain (CASD) certificate, which is used by the SE to sign the recipient's public key.

[0262] In some embodiments, for key tracking, the SE provides a temporary secure element identity (local CA) that is stable until the SE is erased. This identity can be controlled by the device manufacturer and can be verified by the system OEM using the manufacturer's local CA root certificate. The manufacturer backend can link this identity to the SE-ID, and the SE-ID is not exposed to external identities. In some embodiments, the key tracking server 1250 is responsible for verifying device qualifications before signing digital keys. Verification can be performed using the device manufacturer's temporary root certificate that allows verification of the signature of the secure element. In addition, the device can deliver the following information: device manufacturer, device hardware, device OS version and / or JCOP platform identifier.

[0263] In some embodiments, KTS 1250 is physically and logically separated from the OEM business backend to provide privacy for stored data. In some embodiments, KTS 1250 can only be accessed for data queries if the system is stolen and the owner has authorized access, so it cannot be used for business purposes. In some embodiments, any device with a mobile key can contact KTS because the URL is delivered in the mobile key from the system to the owner's device and from the owner's device to friend and service devices. In some embodiments, KTS has the following communication interfaces: KTS-Device, KTS-OEM Business Backend / System, KTS-Device.

[0264] In some embodiments, the KTS-device interface allows both parties to begin communicating, but the first step should be taken by the device after receiving the mobile key. When a friend device provides a new mobile key to the server, this interface can be used to perform the following operations: check service validity, check the number of signing keys for the service, check the validity of the SE signature (e.g., accessing the phone OEM root certificate), check the validity of the owner signature (e.g., using a copy of the system PK), register the mobile key and device information, sign the mobile key data presented to the system on the first transaction, provide the mobile key data to the system OEM backend for provisioning into the system (if the system is online), send the signed mobile key back to the device or provide an error and reason code. Examples of reason codes may include: SE signature invalid / SE not whitelisted, owner signature invalid / unknown, service subscription invalid, and / or the maximum number of issued mobile keys reached. In some embodiments, this interface can be used when the friend deletes a key on the friend device to send a revocation request to the server. In some embodiments, this interface can be used when the KTS 1250 notifies the owner device of a successful revocation. For example, when the mobile key state changes, the KTS 1250 may contact the owner device to update the applet state (remove the friend public key and associated tracking data (e.g., a hash of the friend mobile key data, such as Figure 14 shown).

[0265] In some embodiments, the KTS-OEM business backend / system interface is used to notify revocation requests in the OEM business backend system and / or request revocation of keys on devices when deletion is initiated through the OEM owner or friend account or in the system.

[0266] Exemplary Key Revocation Techniques

[0267] Keys can be revoked at various locations, including the system 110 and the mobile device 130. In some embodiments, the validity of keys is managed using a generation counter that is incremented when the system receives a complete access list. To remove a key, a new access list does not contain the key to be revoked and includes a generation counter that is incremented by at least one relative to the current access list. In some embodiments, the system 110 is configured to reject any previous or pending requests signed with a generation counter that is lower than the new current value. In some embodiments, when incremental additions to the list are performed, the generation counter remains unchanged, allowing existing entries to remain valid. In some embodiments, the counter is monotonic and is configured to count to a sufficiently large value to avoid recounting from the beginning.

[0268] Figure 1717 is a communication diagram illustrating an exemplary key revocation performed by a mobile device 130. In the illustrated embodiment, the mobile device 130 receives a key revocation request at 1704 via the secure channel established at 1702. At 1706, the mobile device 130 then instructs the secure element (or some other secure circuit) to mark the key as revoked. In this state, the key cannot be used in transactions and can only be used to sign a revocation certificate. In some embodiments, the mobile device 130 is configured to request a revocation certificate for the revoked key from the SE, as shown in 1706, which may be signed by phone.SK. In the illustrated embodiment, the mobile device returns a revocation certificate 1708, and the server 146 uses phone.PK to verify the authenticity of the revocation certificate at 1710. In some embodiments, the mobile device 130 is configured to instruct the SE to delete the key in the revoked state, as shown in elements 1712-1716. In other embodiments, any of the various elements discussed herein may be configured to verify the revocation certificate. In some embodiments, the revocation process is initiated via a push notification to the device requesting to contact the OEM backend and synchronize the key status.

[0269] In various embodiments, the disclosed technology can allow system, owner device, and / or internet-based revocation to prove that the revoked key was actually removed or frozen on the sharer device. The revocation technology can also be used on the owner device, for example, before pairing with another owner device. In some embodiments, Figure 17 The disclosed revocation technology can be used directly between a friend mobile device and an owner mobile device, e.g., without involving a server. For example, the friend device can send a revocation receipt directly to the owner device 130.

[0270] Exemplary Mailbox Technology

[0271] Figure 18 is a block diagram illustrating exemplary mailbox technology according to some embodiments. In the illustrated embodiment, application processor 136 executes OS and application 1810, which has read and write access to private mailbox 1830 and write access to confidential mailbox 1840. In the illustrated embodiment, secure element 134 also includes storage 1820 for long-term system public key and phone secret key. In the illustrated embodiment, system 110 includes storage 1825 for system secret key and phone private key, and also includes storage 1835 for user settings and storage 1845 for anti-theft token.

[0272] In some embodiments, a mailbox mechanism allows the secure element to store small data buffers that can be accessed by the application processor 136 and the system 110. These data buffers can be stored in the secure element volatile or non-volatile memory and read / written during transactions or provisioning. In some embodiments, each key created on the device 130 is associated with two mailboxes with different security properties and for different purposes.

[0273] In some embodiments, the private mailbox 1830 is readable and writable by the application processor 136, for example, using an internal wired link within the device. In some embodiments, once the secure channel described above is established via the registered system.PK, the system 110 can also access it for readable and writable purposes, for example, using an RF interface. The established secure channel protects the data exchanged to prevent phone tracking. In some embodiments, the mailbox can be used to send user settings from the AP 136 to the system, to send diagnostic information from the system to the AP 136, to send specific commands to the system, and / or to send Bluetooth pairing information to the system. In some embodiments, the mailbox supports random access and its contents can be read / written using offset / length parameters.

[0274] In some embodiments, the confidential mailbox 1840 is read and write accessible by the system and is write accessible by the application processor 136. In some embodiments, the confidential mailbox is also writable by the application processor 136 (e.g., via an internal wired link) when data is encrypted with newSharee.encPK. In some embodiments, the contents of the confidential mailbox can be exported using the certificate / public key encryption of another trusted security element if the key object configuration allows and the user agrees. In some embodiments, any data exchanged over RF is protected by an established secure channel to prevent user tracking. In some embodiments, the mailbox can be used for: anti-theft token provisioning from an owner device to a friend's device, anti-theft token provisioning from the system to a device, and / or anti-theft token provisioning from an anti-theft token release device to the system. In some embodiments, the mailbox supports random access and its contents can be read / written using offset / length parameters. For example, as mentioned above with reference to Figure 14 As described, a set of anti-theft tokens can be written / read at different offsets in the confidential mailbox.

[0275] Example certificate chain

[0276] In some embodiments, a public key infrastructure (PKI) mechanism is used to build a trust chain up to a specific digital key. In some embodiments, these chains include a device certificate chain, a system certificate chain, an owner pairing key certificate, and a key sharing key certificate.

[0277] In some embodiments, the device manufacturer shall provide a secure service to handle certificate signing requests (CSRs) from other device manufacturers. A root certificate may need to be cross-signed for all device manufacturers whitelisted by a given system manufacturer. The signed certificate may be embedded in the device OS by the manufacturer that owns the device only, or by all other device manufacturers. The latter option may reduce data transfer of certificates during key sharing, but requires all other devices to store the device OEM's certificate. In some embodiments, the system manufacturer shall provide a secure service to accept CSRs from all whitelisted device manufacturers. In some embodiments, the signed certificate is stored in the device's OS and is provided for verification during owner pairing.

[0278] Figure 19 2 is a block diagram illustrating an exemplary device certificate chain according to some embodiments. In the illustrated embodiment, the manufacturer root certificate 2102 is self-signed using the root private key 2108 and is used for secure provisioning of the secure element 134 (the root private key is also used for production provisioning of the local CA certificate 1232 and the local CA private key 1234).

[0279] In the illustrated embodiment, the OEM 1 root certificate 2112 is self-signed using the OEM root private key 2118, which is also used to sign the CASD certificate 2114 that is provided to the SE 2110 during product provisioning. In the illustrated embodiment, the OEM 1 root certificate 2112 is also provided from the phone OEM backend 2172 to the phone manufacturer backend 1230 using a trusted exchange. The backend 1230 signs the root certificate 2112 with the signature 2106 and provides the signed certificate to the OS 2120.

[0280] Therefore, in some embodiments, each qualified security element includes a public key pair (e.g., CASD) of production supply, which allows SE to prove that a public key has been created on a real SE. In the illustrated embodiment, the CASD public key is embedded in a certificate signed by a root key securely stored in the OEM back end. The manufacturer can sign the local CA certificate stored in the applet instance based on the CASD signature, which proves the authenticity of the instance key pair. This allows static identifiers, such as SEID, to be eliminated from the certificate chain. In order to allow the device to verify the SE signature of the received key, in some embodiments, the root certificates of all qualified device OEMs are exchanged between their respective back ends and then signed with the receiving device OEM root private key 2118. The corresponding root certificate will be securely supplied to the SE of all OEM devices. The signed OEM root certificate is stored in all OEM devices. Since the authenticity of the certificate is verified before each use in the SE, there is no need for secure storage.

[0281] Among other things, the disclosed techniques may facilitate implementing the techniques disclosed herein using mobile devices from a variety of manufacturers.

[0282] Figure 20 is a block diagram illustrating an exemplary device certificate chain according to some embodiments. In the illustrated embodiment, the manufacturer root certificate 2102 is signed (OEM signature 2219) using the root private key 2218 of the system OEM backend 1270 (e.g., through a trusted exchange). In some embodiments, once the device OEM is whitelisted by the system manufacturer or the device manufacturer supports the system OEM, the device root certificate is signed by the system OEM root private key. In some embodiments, the OEM 1 root certificate 2212 is securely stored in each system 110. In the illustrated embodiment, the signed manufacturer root certificate 2102 is stored in the device operating system 2120.

[0283] In some embodiments, for example, when the system is configured to store device root certificates, the owner pairing exchange can be simplified. In this case, the device OEM may not need to store the root certificate 2102 signed by the system OEM in the device OS.

[0284] Figure 21 is a block diagram illustrating an exemplary technique for having a local CA signed by a system OEM, according to some embodiments. In some embodiments, when the local CA certificate is signed by the system OEM at setup, the system 110 can directly verify the owner public key certificate using its embedded system OEM root certificate. In the illustrated embodiment, the manufacturer local CA certificate 2132 is stored in the device OS 2120 and signed by both the device manufacturer backend 1230 and the system OEM backend 1270.

[0285] Figure 22 is a block diagram illustrating an exemplary owner pairing certificate chain according to some embodiments. In some embodiments, during an owner pairing session, the owner device 130 creates a long-term key pair. The public key is signed by the owner device SE to generate a device public key certificate 2432, which is transmitted to the system 110 along with the SE certificate 2132 and the device root certificate 2102 signed by the system OEM. The system can then verify the device OEM root certificate 2102 using the system OEM root certificate 2112, verify the SE certificate 2132 using the device OEM root certificate 2102, and verify the device public key using the SE certificate 2132. In some embodiments, when all verifications are successful, the device public key is stored in the system as the owner public key.

[0286] Figure 23is a block diagram illustrating an exemplary owner pairing using a local CA signed by the system OEM, according to some embodiments. In some embodiments where the system is configured to store the root certificate (signed by the system OEM) for each whitelisted device OEM, there may be no need to provide the device OEM root certificate as part of the owner pairing, and device OEM root certificate verification, provided that the device OEM root certificate is stored in secure storage. When the owner device provides a local CA certificate signed by the system OEM (as shown), the need to store all device OEM certificates in the system may be eliminated.

[0287] In the illustrated embodiment, the manufacturer local CA certificate 2132 is signed by the manufacturer (signature 2307 ) and the OEM (signature 2519 ), and is verified using the OEM 1 root certificate 2112 , which is then used to verify the device public key certificate 2442 .

[0288] Figure 24 is a block diagram illustrating an exemplary key sharing certificate chain according to some embodiments. In some embodiments, when a signed public key is sent from a friend device to an owner device during the key sharing process, the secure element of the owner device can identify the SE certificate through the CA identifier field and retrieve the corresponding OEM root certificate from the AP. In the illustrated embodiment, SE 134 uses the manufacturer root certificate to verify the OEM certificate 2112, and then uses the OEM certificate to verify the OEM CASD certificate (which may also be referred to as the SE certificate) received from the OEM SE 2110. It then uses the OEM CASD certificate to verify the friend's public key certificate. In some embodiments, when the verification is successful, the owner device signs the friend's public key using the private key associated with the owner's public key, which is also stored in the system (when the owner is paired).

[0289] In some embodiments, the OEM CASD certificate may be replaced by a local CA scheme that, for example, replaces the SE manufacturer signature with the device OEM signature.

[0290] Additional Implementation Plans

[0291] In some embodiments, a device comprises: a security circuit; and one or more processing elements, wherein the one or more processing elements are configured to establish a first shared encryption key with a system in response to receiving a first request to perform a pairing operation with the system; wherein the security circuit is configured to generate a public key pair and a certificate corresponding to the public key pair, wherein the certificate includes a public key of the public key pair; wherein the device is configured to: encrypt the certificate using the first shared key; and send the encrypted certificate to the system.

[0292] In some embodiments, the security circuit is a secure element further configured to store payment data for a payment transaction. In some embodiments, the device is further configured to: display a value generated based on the public key pair; and request confirmation from a user of the device that the system is also displaying the value. In some embodiments, the device is configured to, in response to receiving a second request for the system to perform an operation, establish a second shared encryption key; use the private key of the public key pair to generate a response to a challenge received from the system; encrypt the response using the second shared encryption key; and send the encrypted response to the system. In some embodiments, the operation includes opening a door of the system, enabling the system's navigation system, or starting the system's engine. In some embodiments, the device is configured to, in response to receiving a second request for another mobile device to access the system, use the private key of the public key pair to sign a certificate for another public key pair generated by the security circuit of the other mobile device. In some embodiments, the device is further configured to: request a server signature for the certificate signed by the security circuit via a wide area network; and the server signature can be used by the system to determine whether to grant the operation requested by the other mobile device. In some embodiments, the apparatus is further configured to indicate whether the other mobile device is allowed to perform some of a set of rights specified by a user of the mobile device.

[0293] In some embodiments, a non-transitory computer-readable medium stores instructions that can be executed by a computing device to result in operations including: receiving a first request to perform a pairing operation with a system; in response to the first request: establishing a first shared encryption key with the system; using a security circuit of the device to generate a public key pair and a certificate corresponding to the public key pair, wherein the certificate includes a public key of the public key pair; encrypting the certificate using the first shared key; and sending the encrypted certificate to the system.

[0294] In some embodiments, the operations further include: displaying a value generated based on the public key pair; and requesting a user of the computing device to confirm that the system is displaying the value. In some embodiments, the operations further include: receiving a second request for the system to perform an operation; in response to the second request: establishing a second shared encryption key; using the secure circuit and the private key of the public key pair to generate a response to a challenge received from the system; encrypting the response using the second shared encryption key; and sending the response to the system.

[0295] In some embodiments, the operations further include: receiving a second request to allow another mobile device to access the system; and in response to the second request, signing a certificate of another public key pair generated by the security circuit of the other mobile device using the security circuit and the private key of the public key pair.

[0296] In some embodiments, a device is included in or configured to be coupled to a system, the device comprising: one or more processing elements configured to: establish a first shared encryption key with a mobile device; receive an encrypted certificate from the mobile device, wherein the certificate corresponds to a first public key pair and includes a public key of the first public key pair, and wherein the certificate is encrypted using the first shared encryption key; and decrypt the encrypted certificate and store the decrypted certificate.

[0297] In some embodiments, the one or more processing elements are further configured to: generate a value based on the first public key pair and cause the value to be displayed on a display of the system for the user to compare with a corresponding value displayed on the mobile device. In some embodiments, the one or more processing elements are further configured to: store information indicating which of the one or more operations performed by the system the mobile device is authorized to access. In some embodiments, the one or more processing elements are further configured to: issue a challenge to the mobile device for a request to cause the system to perform an operation; negotiate a second shared encryption key with the mobile device; receive a response to the challenge and decrypt the response using the second shared encryption key; and before authorizing the operation, verify whether the response was signed by the mobile device using the private key of the first public key pair. In some embodiments, the one or more processing elements are further configured to: receive a certificate for the public key pair generated by another mobile device; in response to determining that the certificate was signed by the mobile device using the private key of the first public key pair, store the certificate for the other mobile device; and determine whether to authorize the operation of the other mobile device based on the certificate stored for the other mobile device.

[0298] In some embodiments, a non-transitory computer-readable medium stores instructions that can be executed by a computing device of the system to result in operations including: establishing a first shared encryption key with a mobile device; receiving an encrypted certificate from the mobile device, wherein the certificate corresponds to a first public key pair and includes a public key of the first public key pair, and wherein the certificate is encrypted using the first shared encryption key; and decrypting the encrypted certificate and storing the decrypted certificate.

[0299] In some embodiments, the operations further include: issuing a challenge to the mobile device in response to a request for the system to perform an operation; negotiating a second shared encryption key with the mobile device; receiving a response to the challenge and decrypting the response using the second shared encryption key; and verifying that the response was signed by the mobile device using the private key of the first public key pair before authorizing the operation. In some embodiments, the operations further include: receiving a certificate for the public key pair generated by another mobile device; in response to determining that the certificate was signed by the mobile device using the private key of the first public key pair, storing the certificate for the other mobile device; and determining whether to authorize the operation of the other mobile device based on the certificate stored for the other mobile device.

[0300] Exemplary computer-readable media

[0301] The present disclosure has described various exemplary circuits in detail above. It is intended that the present disclosure encompass not only embodiments including such circuit systems, but also computer-readable storage media including design information specifying such circuit systems. Accordingly, the present disclosure is intended to support claims that encompass not only apparatuses including the disclosed circuit systems, but also storage media that specify the circuit systems in a format recognizable by a manufacturing system configured to generate hardware (e.g., integrated circuits) including the disclosed circuit systems. Claims to such storage media are intended to encompass, for example, entities that generate circuit designs but do not themselves manufacture the designs.

[0302] Figure 25 27 is a block diagram illustrating an exemplary non-transitory computer-readable storage medium storing circuit design information according to some embodiments. In the illustrated embodiment, a semiconductor manufacturing system 2720 is configured to process design information 2715 stored on a non-transitory computer-readable medium 2710 and to manufacture an integrated circuit 2730 based on the design information 2715.

[0303] Non-transitory computer-readable medium 2710 may include any of various suitable types of memory devices or storage devices. Medium 2710 may be an installation medium, such as a CD-ROM, floppy disk, or tape device; computer system memory or random access memory such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc.; non-volatile memory such as flash memory, magnetic media, for example, a hard drive or optical storage device; registers, or other similar types of memory elements, etc. Medium 2710 may also include other types of non-transitory memory or a combination thereof. Medium 2710 may include two or more memory media that may reside in different locations, such as different computer systems connected via a network.

[0304] Design information 2715 can be specified using any of a variety of suitable computer languages, including hardware description languages ​​such as, but not limited to, VHDL, Verilog, SystemC, SystemVerilog, RHDL, M, MyHDL, and the like. Design information 2715 can be used by semiconductor manufacturing system 2720 to manufacture at least a portion of integrated circuit 2730. Design information 2715 is in a format recognizable by at least one semiconductor manufacturing system 2720. In some embodiments, design information 2715 can also include one or more cell libraries that specify synthesis and / or layout of integrated circuit 2730. In some embodiments, the design information is specified in whole or in part in the form of a netlist that specifies the cell library elements and their connectivity.

[0305] Semiconductor manufacturing system 2720 may include any of a variety of suitable components configured to manufacture integrated circuits. This may include, for example, components for depositing semiconductor material (e.g., on a wafer that may include a mask), removing material, changing the shape of deposited material, modifying material (e.g., by doping the material or modifying the dielectric constant using ultraviolet treatment), and the like. Semiconductor manufacturing system 2720 may also be configured to perform various tests on the manufactured circuits to ensure proper operation.

[0306] In various embodiments, integrated circuit 2730 is configured to operate according to the circuit design specified by design information 2715, which may include performing any of the functionality described herein. For example, integrated circuit 2730 may include Figures 1A to 1C or Figure 2 Any of the various elements shown in . In addition, integrated circuit 2730 can be configured to perform the various functions described herein in conjunction with other components. In addition, the functionality described herein can be performed by multiple connected integrated circuits.

[0307] As used herein, phrases of the form "design information specifying a design of a circuit configured to..." do not imply that the circuit in question must be manufactured in order to satisfy the element. Rather, the phrase indicates that the design information describes a circuit that, when manufactured, will be configured to perform the indicated actions or will include the specified components.

[0308] Figure 26 is a flow chart illustrating an exemplary method for authentication according to some embodiments, in which a device does not send identification information until after verifying a signed certificate from another device. Figure 26 The methods shown can be used in conjunction with any of the computer circuits, systems, devices, components, or parts disclosed herein. In various embodiments, some of the method elements shown can be performed concurrently in an order different from that shown, or can be omitted. Additional method elements can also be performed as needed.

[0309] At 2810, in the illustrated embodiment, a device (eg, a mobile device) generates a first temporary key pair including a first public key and a first private key. phone.ePK and phone.eSK are an example of a first temporary key pair.

[0310] At 2820, in the illustrated embodiment, the device determines a second public key generated by the system, wherein the second public key is included in the second temporary key pair. System.ePK is an example of the second public key.

[0311] At 2830, in the illustrated embodiment, the device generates a first shared secret using a key exchange function that uses the first private key and the second public key as inputs. For example, the key exchange function can be DH(car.ePK, phone.eSK), and its output can be the first shared secret.

[0312] At 2840, in the illustrated embodiment, the device generates a derived shared secret using a key derivation function that uses at least the following inputs: the first shared secret, the first public key, and the system's public key previously established during a pairing session between the device and the system. KAEseed is an example of a derived shared secret, and system.PK is an example of a system's public key.

[0313] At 2850, in the illustrated embodiment, the device generates a signature by signing the transaction information with the device private key established during the pairing session. Phone.Sig is an example of such a signature.

[0314] At 2860, in the illustrated embodiment, the device encrypts the signature and information identifying the device based on the derived shared secret. PhoneIdentifier is an example of information identifying the device.

[0315] At 2870, in the illustrated embodiment, the device uses the system's public key to verify a signed certificate received from the system, where the certificate was signed with the system's corresponding private key established during the pairing session. In various embodiments, the device does not transmit identifying information during the transaction until after the signed certificate is verified.

[0316] At 2880, in the illustrated embodiment, in response to verifying the signed certificate, the device transmits the encrypted signature and information to the system. In some embodiments, this transmission corresponds to an AUTH1 response.

[0317] Figure 27 is a flow chart illustrating an exemplary method for system-side authentication according to some embodiments. Figure 27The methods shown can be used in conjunction with any of the computer circuits, systems, devices, components, or parts disclosed herein. In various embodiments, some of the method elements shown can be performed concurrently in an order different from that shown, or can be omitted. Additional method elements can also be performed as needed.

[0318] At 2910 , in the illustrated embodiment, the system (eg, vehicle) generates a signature by signing the transaction information with the system private key established during the pairing session with the mobile device.

[0319] At 2920, in the illustrated embodiment, the system transmits the signature to the mobile device.

[0320] At 2930, in the illustrated embodiment, the system receives an encrypted signature from the mobile device responsive to the transmitted signature.

[0321] At 2940, in the illustrated embodiment, the system generates a first temporary key pair comprising a first public key and a first private key.

[0322] At 2950, ​​in the illustrated embodiment, the system determines a second public key generated by the mobile device, wherein the second public key is included in the second temporary key pair.

[0323] At 2960, in the illustrated embodiment, the system generates a first shared secret using a key exchange function that uses the first private key and the second public key as inputs.

[0324] At 2970, in the illustrated embodiment, the system generates a derived shared secret using a key derivation function that uses at least the following inputs: the first shared secret, the first public key, and the system's public key previously established during the pairing session.

[0325] At 2980, in the illustrated embodiment, the system decrypts the signature using the derived shared secret.

[0326] At 2990, in the illustrated embodiment, the system verifies the signature using the mobile device's public key established during the pairing session.

[0327] At 2995, in the illustrated embodiment, the system authorizes one or more actions based on the verification.

[0328] Exemplary Digital Key Proofing Techniques

[0329] Figure 2830 is a block diagram illustrating an exemplary digital key attestation during pairing according to some embodiments. In the illustrated embodiment, server 3010 is configured to generate a pairing password 3002 and send a system password and salt value 3004 to system 110. Note that for illustrative purposes, Secure Remote Password (SRP) (enhanced PAKE protocol) is used in the illustrated example, but the disclosed attestation techniques can be used with various security protocols. In the illustrated embodiment, the salt value is random data used as an additional input to a one-way hash function and can be used to protect the system password.

[0330] At 3006, the mobile device OS 2120 logs into the server 3010 and obtains the owner password. At 3008, the SRP is used to create a secure channel, and the system 110 provides digital key configuration data. This configuration information may include various fields, such as indicating what types of transactions are allowed, system metadata, a start date, an expiration date, a public key, a system identifier, etc. In some embodiments, the system 110 is configured to refuse pairing unless the mobile device correctly verifies that the digital key was created according to the configuration data.

[0331] At 3012, the mobile device OS 2120 sends a command to the SE applet 3030 to create a digital key based on the configuration information. The SE applet 3030 creates the digital key (which may include various information discussed herein, such as a long-term public key pair for pairing sessions) and sends the certificate and public key to the mobile device OS 2120 at 3014. The OS then sends the certificate 3016 to the system 110.

[0332] The system 110 then verifies the attestation data at 3018 and accepts or rejects the public key based on the verification. This may include comparing the configuration data embedded in the signed certificate from the OS with the configuration data sent at 3008 and verifying the signature of the certificate to confirm that the certificate is from the SE. In various embodiments, this may allow the system 110 to confirm that the digital key has been correctly created before allowing pairing with the mobile device 130.

[0333] Note that in other embodiments, the functionality described with respect to the OS 2120 and the applet 3030 may be performed by a single module executable on a single processor. Figure 28 The functional distribution disclosed in the foregoing is included for illustrative purposes and is not intended to limit the scope of the disclosure.

[0334] Although specific embodiments have been described above and illustrated in the following figures, these embodiments are not intended to limit the scope of the present disclosure, even when only a single embodiment is described with respect to a particular feature. The feature examples provided in this disclosure are intended to be illustrative, not limiting, unless otherwise stated. As an example, reference to the term "phone" may encompass any suitable mobile device. Therefore, the above and following descriptions are intended to encompass such alternatives, modifications, and equivalents as would be apparent to those skilled in the art having the benefit of this disclosure.

[0335] The scope of the present disclosure includes any feature or combination of features disclosed herein (explicitly or implicitly) or any generalization thereof, whether or not it mitigates any or all of the problems addressed herein. Accordingly, new claims may be made during the prosecution of this patent application (or a patent application claiming priority thereto) to any such combination of features. In particular, with reference to the appended claims, features of dependent claims may be combined with features of the independent claims, and features from corresponding independent claims may be combined in any appropriate manner and not just in the specific combinations listed in the appended claims.

Claims

1. A mobile device, comprising: One or more processing elements are configured to: determining an action associated with another system to which the sharer device is to be authorized; sending information indicative of the action to the sharer device; receiving a certificate from the sharer device, wherein the certificate is signed and embeds the action and a public key of the sharer device; verifying a first signature of the certificate, verifying the received certificate using a root certificate, and verifying that the action matches the determined action; signing the verified certificate using a private key of the mobile device, the private key established during a pairing session with the other system; as well as The signed certificate is sent to the sharer device, wherein the signed certificate is capable of being sent by the sharer device to the other system to identify the sharer device as an authorized device for the action based on verification of the second signature from signing the verified certificate and verification of the certificate. 2 . The mobile device of claim 1 , wherein the sharer device is another mobile device, the another system is a vehicle, and the action is turning on or starting the vehicle.

3. The mobile device of claim 1 , wherein the one or more processing elements are further configured to: The signed certificate is encrypted using the public key of the encryption key pair before transmission.

4. The mobile device of claim 1 , wherein the one or more processing elements are further configured to: A user of the mobile device is authenticated prior to transmission of the signed certificate.

5. The mobile device of claim 1 , wherein the one or more processing elements are further configured to: maintaining a counter value indicating a number of times the mobile device has authorized one or more sharer devices; updating the counter value based on communication with the sharer device; and The counter value is sent with the signed certificate to the sharer device, wherein the counter value is also available for transmission by the sharer device to the other system for verification of the counter value.

6. The mobile device of claim 1, wherein the transmission of the signed certificate to the sharer device is performed via a direct wireless connection between the mobile device and the sharer device. 7 . The mobile device of claim 1 , wherein the one or more processing elements comprises a secure element configured to sign the certificate.

8. A mobile device comprising: One or more processing elements are configured to: receiving information from a shared device indicating an action to be authorized for the mobile device, wherein the action is associated with another system; sending a certificate to the shared device, the certificate being signed and embedding the action and the public key of the mobile device; receiving a signed version of the certificate from the shared device based on verification of the public key and the certificate, the certificate being signed to produce an additional signature using a private key of the shared device, the private key being established during a pairing session between the shared device and the other system; sending the signed certificate to the other system to establish the mobile device as an authorized device for the action based on verification of the additional signature and verification of the certificate; as well as The action is requested from the other system.

9. The mobile device of claim 8, wherein the one or more processing elements are further configured to: An encryption key pair is generated for encrypting the signed certificate.

10. The mobile device of claim 8, wherein the signed version of the certificate is received via a direct wireless connection between the mobile device and the shared device. 11 . The mobile device of claim 8 , wherein the sharer device is another mobile device, the another system is a vehicle, and the action is turning on or starting the vehicle.

12. The mobile device of claim 8, wherein the certificate specifies one or more rights to be enforced by the other system.

13. The mobile device of claim 12, wherein the one or more rights include an expiration date, a speed limit, a location limit, or a time limit.

14. The mobile device of claim 8, wherein the one or more processing elements comprises a secure element configured to generate the credential.

15. An electronic system comprising: One or more processing elements are configured to: receiving a signed certificate from a sharer device, wherein the certificate is signed by the sharer device and embeds actions authorized by the sharing device for the sharer device, wherein the certificate is generated by the sharer device and signed by the sharing device in response to verification of the certificate using a private key of the sharing device and using a root certificate to produce an additional signature, the private key being established during a pairing session between the sharing device and the electronic system; verifying the additional signature of the shared device and verifying the certificate; storing information indicating that the sharer device is an authorized device for the action; as well as The action is initiated in response to a request from the sharer device to perform the action.

16. The electronic system of claim 15, wherein the one or more processing elements are configured to: maintaining a counter value indicating a number of times the sharing device has authorized one or more sharer devices; updating the counter value based on communication with the shared device; receiving a counter value together with the signed certificate from the sharer device; as well as The counter value is verified. 17 . The electronic system of claim 15 , wherein the sharer device is a mobile device, the electronic system is a vehicle, and the action is turning on the vehicle or starting the vehicle.

18. The electronic system of claim 15, wherein the one or more processing elements are further configured to: checking the entitlements embedded in the certificate; and Enforcing the rights associated with the sharer device.

19. The electronic system of claim 18, wherein the rights include an expiration date, a speed limit, a location limit, or a time limit.

20. The electronic system of claim 15, wherein the one or more processing elements are further configured to: In response to the sharing device revoking authorization of the action, an indication that the certificate has been revoked is stored.

Images