Secure session communication between a mobile device and a base station

A vehicle includes: (i) a main telematics module, (ii) a connectivity module including antenna(s) and processor(s). The connectivity module is configured to: (a) authenticate a mobile device via a vehicle-access-key (VAK); (b), if (a), issue an ephemeral-session-key (DSK) to the mobile device; (c), if (b), establish an active session with the mobile device; (d) encrypt all messages to the mobile device with the VAK during (a) and with the DSK during (c). The connectivity module is configured to automatically revoke the DSK upon expiration of a predetermined time interval.

TECHNICAL FIELD

This application relates to secure communication between a mobile device, such as a smartphone, and a base station, such as a vehicle, a server, or a second mobile device.

BACKGROUND

Mobile devices (e.g., smartphones) have become pervasive and are used for more than voice conversation and text messaging. The increasing availability of high-speed Internet, coupled with new technologies such as Bluetooth and NFC have enabled new uses such as mobile payments, health monitoring and more. These technologies however are not perfectly secure, and on their own cannot be trusted to communicate sensitive or potentially safety-critical information between two devices.

Additional use cases for a mobile device include interacting with a vehicle (or other base station such as a house, a server, a second mobile device, etc) to cause the vehicle (or other base station) to perform entry, start, lock/unlock, and other functions. Some prior art references disclose these use-cases. These references, however, fail to provide efficient and effective security for communication between the mobile device and the vehicle. Standardized communication technologies such as Bluetooth and WiFi fail to sufficiently secure communication.

New and improved techniques for secure communication between a mobile device and a vehicle (or other base station) are therefore needed.

SUMMARY

Disclosed is an efficient method to secure command and control communications between the mobile device and vehicle without relying on any security offered by the wireless delivery mechanism (e.g., Bluetooth or WiFi).

The method may rely on knowledge of a pre-shared cryptographic key called the VAK. This key is shared to both the mobile device and the vehicle in an out-of-band, secure manner from a backend system. The key is unique per mobile device and/or user of the mobile device (e.g., user A of the mobile device is associated with a first VAK and user B of the mobile device is associated with a second VAK). Furthermore, each user of the mobile device may be associated a different VAK for each of a plurality of vehicles. The users may log in to the mobile device (e.g., an app on the mobile device). The mobile device may recognize which VAKs are associated with a user based on the log-in information. The mobile device may prevent the user from applying VAKs associated with other users. Thus, the VAK can be used to confirm a device's identity. The vehicle can store multiple keys representing multiple different mobile devices and/or users.

The solution also implements an ephemeral session key called the DSK, which is used for protecting messages following authentication of the mobile device. A temporal and ephemeral key both prevents replay of entire sessions and ensures secrecy of messages across sessions—knowledge of one session key does not allow one to decrypt messages from any other session.

An optional counter is also provided. The counter is useful to prevent message replay attacks. The counter may optionally be used as a nonce during authentication.

A vehicle consistent with the present disclosure thus includes: (i) a main telematics module, (ii) a connectivity module including antenna(s) and processor(s). The connectivity module is configured to: (a) authenticate a mobile device via a vehicle-access-key (VAK); (b), if (a), issue an ephemeral-session-key (DSK) to the mobile device; (c), if (b), establish an active session with the mobile device; (d) encrypt some or all messages to the mobile device with the VAK during (a) and with the DSK during (c). The connectivity module is configured to automatically revoke the DSK upon expiration of a predetermined time interval.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

In this application, the use of the disjunctive is intended to include the conjunctive. The use of definite or indefinite articles is not intended to indicate cardinality. In particular, a reference to “the” object or “a” and “an” object is intended to denote also one of a possible plurality of such objects. Further, the conjunction “or” may be used to convey features that are simultaneously present, as one option, and mutually exclusive alternatives as another option. In other words, the conjunction “or” should be understood to include “and/or” as one option and “either/or” as another option.

FIG. 1shows a computing system100of a base station, such as a host vehicle200. Although the base station is discussed as being host vehicle200, the base station may be any suitable equipped device such as a mobile phone, a tablet, a server, etc. Host vehicle200is connected, meaning that host vehicle200is configured to (a) receive wireless data from external entities (e.g., infrastructure, servers, other connected vehicles) and (b) transmit wireless data to external entities. Host vehicle200may be autonomous, semi-autonomous, or manual. Host vehicle200includes a motor, a battery, at least one wheel driven by the motor, and a steering system configured to turn the at least one wheel about an axis. Host vehicle200may be fossil fuel powered (e.g., diesel, gasoline, natural gas), hybrid-electric, fully electric, fuel cell powered, etc.

Vehicles are described, for example, in U.S. patent application Ser. No. 15/076,210 to Miller, U.S. Pat. No. 8,180,547 to Prasad, U.S. patent application Ser. No. 15/186,850 to Lavoie, U.S. Patent Publication No. 2016/0117921 to D'Amato, and U.S. patent application Ser. No. 14/972,761 to Hu, all of which are hereby incorporated by reference in their entireties. Host vehicle200may include any of the features described in Miller, Prasad, Lavoie, D'Amato, and Hu.

Computing system100resides in host vehicle200. Computing system100, among other things, enables automatic control of mechanical systems within host vehicle200and facilitates communication between host vehicle200and external entities (e.g., connected infrastructure, the Internet, other connected vehicles). Computing system100includes a data bus101, one or more processors108, volatile memory107, non-volatile memory106, user interfaces105, a telematics unit104, actuators and motors103, and local sensors102.

Data bus101traffics electronic signals or data between the electronic components. Processor108performs operations on electronic signals or data to produce modified electronic signals or data. Volatile memory107stores data for near-immediate recall by processor108. Non-volatile memory106stores data for recall to the volatile memory107and/or the processor108. Non-volatile memory106includes a range of non-volatile memories including hard drives, SSDs, DVDs, Blu-Rays, etc. User interface105includes displays, touch-screen displays, keyboards, buttons, and other devices that enable user interaction with the computing system. Telematics unit104enables both wired and wireless communication with external entities via Bluetooth, cellular data (e.g., 3G, LTE), USB, etc.

Actuators/motors103produce tangible results. Examples of actuators/motors103include fuel injectors, windshield wipers, brake light circuits, transmissions, airbags, motors mounted to sensors (e.g., a motor configured to swivel a local sensor102), engines, power train motors, steering, blind spot warning lights, etc.

Local sensors102transmit digital readings or measurements to processors108. Examples of local sensors102include temperature sensors, rotation sensors, seatbelt sensors, speed sensors, cameras, lidar sensors, radar sensors, infrared sensors, ultrasonic sensors, clocks, moisture sensors, rain sensors, light sensors, etc. It should be appreciated that any of the various electronic components ofFIG. 1may include separate or dedicated processors and memory. Further detail of the structure and operations of computing system100is described, for example, in Miller, Prasad, Lavoie, and Hu.

FIG. 2generally shows and illustrates host vehicle200, which includes computing system100. Some of the local sensors102are mounted on an exterior of host vehicle200(others are located inside the vehicle200). Local sensor102ais configured to detect objects leading the vehicle200. Local sensor102bis configured to detect objects trailing the vehicle200as indicated by trailing sensing range109b. Left sensor102cand right sensor102dare configured to perform similar functions for the left and right sides of the vehicle200.

As previously discussed, local sensors102ato102dmay be ultrasonic sensors, lidar sensors, radar sensors, infrared sensors, cameras, microphones, and any combination thereof, etc. Host vehicle200includes a plurality of other local sensors102located in the vehicle interior or on the vehicle exterior. Local sensors102may include any or all of the sensors disclosed in Miller, Prasad, Lavoie, D'Amato, and Hu. The general arrangement of components shown inFIGS. 1 and 2is prior art.

It should be appreciated that host vehicle200, and more specifically, processors108of host vehicle200, is/are configured to perform the methods and operations described herein. In some cases, host vehicle200is configured to perform these functions via computer programs stored on volatile107and/or non-volatile106memories of computing system100.

One or more processors are “configured to” perform a disclosed method step, block, or operation, at least when at least one of the one or more processors is in communication with memory storing a software program with code or instructions embodying the disclosed method step or block. Further description of how processors, memory, and software cooperate appears in Prasad. According to some embodiments, a mobile phone or external server(s) in communication with host vehicle200perform some or all of the methods and operations discussed below.

Host vehicle200may include some or all of the features of vehicle of Prasad. Computing system100may include some or all of the features of the VCCS of Prasad. Host vehicle200may be in communication with some or all of the devices shown in FIG. 1 of Prasad, including the nomadic or mobile device, the communication tower, the telecom network, the Internet, and the data processing center (i.e., one or more servers). Each of the entities described in this application may share any or all of the features described with reference toFIG. 1andFIG. 3.

The term “loaded vehicle,” when used in the claims, is hereby defined to mean: “a vehicle including: a motor, a plurality of wheels, a power source, and a steering system; wherein the motor transmits torque to at least one of the plurality of wheels, thereby driving the at least one of the plurality of wheels; wherein the power source supplies energy to the motor; and wherein the steering system is configured to steer at least one of the plurality of wheels.” Host vehicle200may be a loaded vehicle.

The term “equipped electric vehicle,” when used in the claims, is hereby defined to mean “a vehicle including: a battery, a plurality of wheels, a motor, a steering system; wherein the motor transmits torque to at least one of the plurality of wheels, thereby driving the at least one of the plurality of wheels; wherein the battery is rechargeable and is configured to supply electric energy to the motor, thereby driving the motor; and wherein the steering system is configured to steer at least one of the plurality of wheels.” Host vehicle200may be an equipped electric vehicle

FIG. 3shows a more specific implementation of computing system100. As illustrated, computing system100includes a connectivity module300, a main telematics module320, and a plurality of other modules340.

Connectivity module300includes one or more processors301, volatile memory302, non volatile memory303, one or more antennas304, and a data bus305. Main telematics module320includes one or more processors322, volatile memory323, non volatile memory324, one or more antennas321, and a data bus325.

The other modules340include a plurality of modules, such as actuator/motor modules341, user interface modules342, and local sensor modules343. Each of the other modules340includes one or more processors, volatile memory, and non volatile memory. At least some of the actuator/motor modules are connected to motors/actuators103such as motors, engines, etc.

The other modules340control the substantive driving and safety functions of host vehicle200, such as providing power to the wheels, performing safety functions (e.g., deploying airbags), controlling the radio, mapping the vehicle's route, etc.

Main telematics module320is the primary communication bridge between host vehicle200and external entities (e.g., servers, other vehicles, the Internet, mobile devices, etc.). Connectivity module300is (a) the primary communication bridge between host vehicle200and specific mobile devices and (b) an authenticator of at least some external entities in communication with host vehicle200. As described below, connectivity module300directly communicates, via antennas304, with specific mobile devices and authorizes the specific mobile devices to control main telematics module320and/or some or all of the other modules340. Thus, antennas321of main telematics module320may be equipped for long-range communication over the Internet (e.g., cellular communication) while antennas304of connectivity module300may be only equipped for short-range communication (e.g., Bluetooth low energy communication). Connectivity module300may be configured to only accept and broadcast messages prepared at connectivity module processors301, while main telematics module320may be configured to accept and broadcast messages prepared at any module.

FIG. 4shows operations associated with negotiating a session between mobile device380and host vehicle200. Upon negotiating the session, an active session occurs on both mobile device380and host vehicle200. During the active session, connectivity module300forwards commands issued by mobile device380to the other modules340. For example, upon pairing, host vehicle200may enable mobile device380to issue: an unlock command causing host vehicle200to unlock its doors, a lock command causing host vehicle200to lock its doors, a motor start command, an engine start command, a window adjust command, a panic command, etc. Before connectivity module300begins the active session, connectivity module300may reject any messages including commands for the other modules340.

Communications inFIG. 4may be exclusively conducted between mobile device380and connectivity module300, except for authentication request402, which may be sent from mobile device380to main telematics module320and then forwarded by main telematics module320to connectivity module300. Alternatively, as disclosed below, all communications may routed through main telematics module320.

Authentication request402is a request for connectivity module300to authenticate mobile device380. Authentication request402includes (a) a vehicle access key (VAK) ID (“VAK_id”) and (b) a tag of the VAK ID (“tag_VAK”).

Although not shown, one, more, or all of the messages originated at mobile device380and one, more, or all of the messages originated at connectivity module300of host vehicle200may include unencrypted routing metadata. The routing metadata may (i) instruct the receiving entity (mobile device380or host vehicle200) to route the message to a specific location within the receiving entity (e.g., a specific program or a specific piece of hardware). The routing metadata may (ii) instruct the transmitting entity to route the message to a specific receiving entity.

For example, and with reference toFIG. 3, connectivity module300may lack antennas. As such, when transmitting messages, connectivity module may include first routing metadata in the messages instructing main telematics320to route the message to a specific mobile device. Connectivity module may include second routing metadata in the messages instructing telematics of the mobile device to route the message to specific hardware or software within the mobile device380. As such, connectivity module300may lack antennas304and communicate with mobile device380via main telematics320.

The vehicle access key is a cryptographic key used to facilitate the negotiating session ofFIG. 4. For the purposes ofFIG. 4, both mobile device380and connectivity module300already store (i.e., know) the VAK. The VAK ID is a unique identifier (i.e., name) of the specific VAK stored in mobile device380and connectivity module300. Generation and distribution of the VAK and VAK ID to the mobile device380and host vehicle200is discussed below with reference toFIG. 7.

The tag of the VAK ID is a hash of the VAK ID performed with a hashing function prestored on the mobile device380. When the present application states that a hash on something has been performed (e.g., the hash on the VAK ID has been performed), at least two things may be possible: first, the listed inputs are the only inputs to the hashing function; second, the hashing function uses the listed inputs, and possibly other inputs, when generating the hash.

It should be appreciated that for the hashing to be effective, the hashing function and inputs thereto on the mobile phone must be equivalent to the hashing function and the inputs thereto on the host vehicle. Thus, to the extent that the mobile device includes other inputs in the hash (e.g., the date), the host vehicle must include the same inputs when calculating the reciprocal hash (discussed below).

In general, hashing functions apply arbitrary mathematical operations to inputs. For example, one hashing function may generate an output by multiplying every input together and then subtracting seven from the multiplication result. Thus, if the inputs to the hashing function are 127, 434, and 22 the output of the hashing function would be (127*434*22−7)=1212589. As another example, one hashing function may sum the first value of every input. Thus, if the inputs to the hashing function are 127, 434, and 22 the output of the hashing function would be (1+4+2)=7. Many other possibilities exist.

The point of hashing functions is to confirm that inputs to one operation (e.g., an operation performed on mobile device380) are equal to the inputs on another operation (e.g., an operation performed on host vehicle200), without ever disclosing the exact values of the inputs. Thus, if host vehicle200receives a hash of 1212589 from mobile device380, performs a reciprocal hash on values stored on host vehicle200, and outputs a reciprocal hash of 1212589, host vehicle200knows that the inputs on the mobile device380(here,127,434, and22) are the same as the inputs on host vehicle200(again 127, 434, and 22). Someone who intercepts the hash of 1212589 (e.g., a hacker), would not be able to reverse engineer the inputs of 127, 434, and 22 because the hash of 1212589 could be the result of any series of inputs (e.g., 4, 7, 43307; or 2, 14, 44307; etc) or could be the result of any hashing function.

At block404, host vehicle200performs the reciprocal hash (i.e., applies the same hash function) on the VAK ID and compares the hash received at402with the reciprocal hash generated at404. If the hashes match, then host vehicle200responds with a challenge406. The challenge406includes (a) a counter (which is similar to a rolling code) (“ctr”) and a randomly generated nonce (“N”), which are individually encrypted according to the VAK (“enc_VAK”) and (b) a hash of the VAK (“tag_VAK”). The counter may be used as the nonce. The counter may be randomly generated at block404.

At block408, mobile device380decrypts the counter and the nonce, performs a reciprocal hash on the decrypted counter and nonce, and compares the reciprocal hash to the hash included in challenge406. If the hashes match, then mobile device380calculates a mobile response (“r_ph”), which is a function of the nonce and the VAK and sends a challenge response410. The challenge response410includes (a) the incremented counter (“ctr+1”) and the calculated mobile response (“r_ph”), which are individually encrypted according the VAK (“enc_VAK”) and (b) a hash of the VAK (“tag_VAK”).

According to preferred embodiments, the hash (i.e., “tag_” of encryption keys) may be replaced with a message authentication code (MAC). This optionally applies to every use of the term “hash” or “tag_” in the application.

The MAC may include some or all of the following: (1) An unencrypted ID of the encryption key. As discussed elsewhere, each encryption key (e.g., the VAK and DSK) may be paired with a unique ID when generated. (2) An unencrypted first hash of all data in the message that was encrypted according to the encryption key. The first hash may further include the unencrypted ID. (3) A second unencrypted hash of the unencrypted encryption key. (4) A third unencrypted hash with (2) and (3) as inputs to the hash function. According to an especially preferred embodiment, the MAC only includes (1), (2), and (4), but not (3). When the present application discusses reciprocal hashes, such reciprocal hashes apply to the MAC. Put differently, upon receiving a message with a MAC, the mobile device300or host vehicle200may perform the following reciprocal hashing steps: (a) ensuring the unencrypted ID is correct, (b) based on the ID, ensuring that (3), the second unencrypted hash of the unencrypted encryption key is correct, (c) decrypting the message if (a) and (b) are confirmed, and (d) confirming that (4), the third unencrypted hash is correct after (c).

At block412, host vehicle200decrypts the incremented counter and the calculated response, performs or references a reciprocal hash of the VAK, and compares the reciprocal hash of the VAK to the hash of the VAK in challenge response410. If the hashes match and the incremented counter exceeds the original counter sent via challenge406, then host vehicle200calculates a vehicle response (“r_veh”), which is a function of the nonce and the VAK.

The function applied to calculate the vehicle response, r_veh, is the same as the function applied to calculate the mobile device response, r_ph. Host vehicle200compares the vehicle response, r_veh, with the mobile device response r_ph. If the responses match, then host vehicle200generates a random, ephemeral session key (“DSK”). The session key has a limited lifetime to limit exposure in the event a hacker computes the DSK. Put differently, host vehicle200will only recognize the DSK and thus only recognize messages encrypted according to the DSK for a predetermined amount of time (e.g., 6 hours).

After generating the DSK, host vehicle200transmits an acknowledgement414. The acknowledgement414includes the DSK encrypted according to the VAK (“enc_VAK”) and a hash of the VAK (“tag_VAK”). At block416, mobile device380confirms that the hash of the VAK is valid (as described above, by comparing the hash of the VAK in the acknowledgement414with a reciprocal hash performed by mobile device380). If the hash is valid, mobile device380decrypts the DSK with the VAK, stores the DSK, and transmits a session request418.

The session request418includes the twice incremented counter (“ctr+2”), encrypted according to the DSK and a hash of the DSK. At block420, host vehicle200confirms that the hash of the DSK is valid by generating a reciprocal hash with the DSK, and confirms that the twice incremented counter exceeds the once incremented counter (“ctr+1”). If so, host vehicle200recognizes that the session has started and host vehicle200transmits a start session message422.

The start session message422includes (a) a thrice incremented counter (“ctr+3”), an initialization vector (“IV”), which are individually encrypted according to the DSK and (b) a hash of the DSK. At block424, the mobile device380decrypts the initialization vector and the thrice incremented counter. The mobile device380confirms that the hash of the DSK is valid and the thrice incremented counter exceeds the twice incremented counter. If so, then mobile device380recognizes that the session has started.

It should be appreciated that in addition to the above encryption techniques, each message may include encrypted substantive data (discussed below) stating the purpose of the message. Alternatively, each message may not include any substantive data and each receiving entity may recognize the message's purpose by virtue of its order in the negotiating process. To enhance this effect, and as shown inFIGS. 4 and 5, no two messages are identical. Thus, the purpose of a message can be identified by the message's structure.

Various signed messages (such as heartbeat challenges, heartbeat responds, vehicle commands, and receipts) are transmitted during the active session. A signed message may include (a) substantive data, which encrypted according to the DSK, and (b) a hash of the DSK (which may be replaced with the previously discussed authentication code). Alternatively or in addition, the signed message may include: (a) a hash of the initialization vector, (b) the substantive data first encrypted with one of the DSK and the initialization vector and then re-encrypted with the other of the DSK and the initialization vector, and (c) the re-incremented counter encrypted according to any of the above techniques (e.g., DSK alone, DSK then IV, or IV then DSK).

In response to receiving a signed message, the receiving entity (mobile device380or host vehicle200) (a) verifies the signed message (by validating any hashes with reciprocal hashes and confirming that the re-incremented counter exceeds the last counter known to the mobile device380) and (b) performs some substantive function (e.g., control a motor, unlock a door, start a motor, roll down a window, prepare and issue a message) according to the substantive data.

As shown inFIG. 4, heartbeat events436occur during the active session. Heartbeat events436enable host vehicle200and mobile device380to confirm that the wireless connection between the two is still present. At block426, host vehicle200determines that a heartbeat condition has occurred. A heartbeat condition may be set to occur at a predetermined time. The count of the time is reset to zero when any signed message is received from mobile device380(e.g., according to the above example of sixty seconds, if a new heartbeat condition was set to occur in 30 seconds, but connectivity module300received a signed heartbeat response or a signed vehicle command, then the counter may be reset to zero such that the new heartbeat condition occurs in 60 seconds).

Connectivity module300counts a heartbeat timeout, which exceeds the time associated with the heartbeat condition (e.g., the heartbeat timeout may occur after three minutes while the heartbeat condition may occur after one minute). The heartbeat timeout resets to zero every time a signed message is received from mobile device380.

Connectivity module300may transmit heartbeat challenges428once a heartbeat condition has occurred, but before a heartbeat timeout has occurred at a high frequency. For instance, according to the above example, connectivity module300waits sixty seconds after the last signed message to issue a first heartbeat challenge428. After sixty seconds, however, connectivity module300may issue heartbeat challenges428frequently (e.g., once per five seconds) until the heartbeat timeout occurs. As discussed below, once a heartbeat time occurs, connectivity module300returns to standby602and revokes the DSK.

Host vehicle200transmits a signed heartbeat challenge428in response to block426. At block430, mobile device380validates the signed heartbeat challenge428and issues a signed heartbeat response432. At block434, host vehicle200validates the signed heartbeat response432. Host vehicle200may generate mobile devices commands (not shown) according to the heartbeat command process436by including different substantive data.

Vehicle controls450occur during the active session. Host vehicle200will only process vehicle controls450during an active session (i.e., only after block420has occurred). At block438, mobile device380(a) generates substantive data (e.g., unlock the doors, start the engine, blink a certain light, roll down a certain window) and (b) transmits a signed vehicle command based on the substantive data. The signing process is described above. Mobile device380may perform block438in response to a user input (e.g., a tap of a virtual button).

At block442, host vehicle200validates the vehicle command and performs some substantive function based on the decrypted substantive data. Host vehicle200may transmit a signed receipt444. Mobile device380may validate the receipt and perform some substantive function (e.g., display a message) in response to the substantive data included in the receipt.

According to some embodiments, a different hash function may be applied for each communication during the negotiating session402,406,410,414,418, and422. Because both mobile device380and host vehicle200know the kind of communication received (authentication request vs. challenge vs. mobile response vs. acknowledgement vs. session request vs. start session command), both mobile device380and host vehicle200know which hash function to apply to generate the reciprocal hash for validating purposes.

According to some embodiments, only a single hash function is used by host vehicle200and mobile device380during the active session. Alternatively, a first hash function is used for all heartbeat challenges, a second hash function is used for all heartbeat responses, a third hash function is used for all vehicle commands, a fourth hash function is used for all receipts thereto, a fifth hash function is used for all mobile commands, and a sixth hash function is used for all receipts thereto. All hash functions used during the active session may be different than all hash functions used during the negotiating session.

FIG. 5shows operations associated with pairing mobile device380host vehicle200.FIG. 5includes the same features asFIG. 4, except where noted otherwise in the specification or Figures. The operations ofFIG. 5assume that the DSK is too large to be transmitted in a single message and thus break the DSK into two blocks: a first block (“DSK1”) and a second block (“DSK2”).

Upon receiving both the first and second blocks, DSK1and DSK2, mobile device380assembles the DSK. As one example, mobile device may append DSK2after DSK1(e.g., if DSK1was 45 and DSK2was 875, then the DSK would be 45875). As other examples, mobile device may multiply DSK1by DSK2, raise DSK1to the power of DSK2, etc.

Host vehicle200may be configured to implement bothFIGS. 4 and 5and choose between based on an identity of the wireless connection established between connectivity module300and mobile device380(e.g., if connectivity module300determines that the wireless connection is via NFC or an old Bluetooth version, then connectivity module300implementsFIG. 4; if connectivity module300determines that the wireless connection is via WiFi or a later Bluetooth version, then connectivity module300implementsFIG. 5).

At block404host vehicle200computes the DSK and then separates the DSK into two portions: DSK1and DSK2. Challenge406thus includes DSK1encrypted according to the VAK, but not DSK2. At block408, mobile device380decrypts and DSK1. At block412, host vehicle200includes DSK2, encrypted according to the VAK, and the twice incremented counter in acknowledgement414. At block416, mobile device380decrypts DSK2and assembles the DSK based on DSK1and DSK2. Due to the twice incremented counter in acknowledgement414, the counter in session request418is thrice incremented and the counter in start session command422is quad incremented.

Although not shown, acknowledgement414may include, in addition to DSK2, an assembly instruction encrypted according to the VAK. The assembly instruction, when received and opened at block416, instructs mobile device380how to combine DSK1with DSK2. The processors may be configured to determine whether DSK1or DSK2is smaller and transmit the DSK assembly instructions with the smaller of DSK1and DSK2.

FIG. 6is a flow diagram of the method ofFIG. 4. At block602, connectivity module300is in standby mode. Connectivity module300will only respond to an authentication request402while in standby mode (i.e., connectivity module will ignore anything other than an authentication request402while in standby mode602).

Standby mode602is specific to a unique mobile device such that connectivity module300may be in standby mode with respect to mobile device A, but not in standby mode with respect to mobile device B. As later discussed, each mobile device may be associated with a unique VAK and therefore, a unique VAK ID. As such, connectivity module300may identify a specific mobile device via the VAK ID issued by the specific mobile device at authentication request402. Whenever connectivity module300returns to standby mode602, any active DSK is revoked, meaning that host vehicle200will not verify messages encrypted and/or tagged according to the previously active DSK and a new DSK must be issued.

After receiving authentication request402, connectivity module300proceeds to block604where mobile device380is authenticated. If any message received from mobile device380is unverified (bad hash or bad counter), then an authentication error609occurs and connectivity module300returns to standby. If a timeout occurs (i.e., no message from mobile device380is received within a predetermined time), then an authentication error609occurs. Otherwise, authentication is successful610, and connectivity module proceeds to block606.

If any message received from mobile device380is unverified (bad hash or bad counter), then a key establishment error611occurs and connectivity module300returns to standby. If a timeout occurs (i.e., no message from mobile device380is received within a predetermined time), then a key establishment error611occurs. Otherwise, key establishment is successful612, and connectivity module proceeds to block608where an active session is established.

If, during the active session, (a) any signature is unverified or (b) any heartbeat timeout occurs (as previously discussed), then a session error613occurs and connectivity module300returns to standby mode602. As stated above, the DSK is ephemeral and expires after a predetermined time (e.g., one hour) after being issued at block412. Upon expiration, session termination614occurs and connectivity module300rejects messages with validation predicated on the DSK (e.g., being encrypted with the DSK, including tag of the DSK). Upon session termination614, host vehicle200may transmit a message to mobile device380instructing mobile device380to automatically issue an authentication request402to generate a new DSK. The message may be encrypted according to the VAK or may be encrypted according to the old DSK.

FIG. 7is a flow diagram of preloading the VAK onto mobile device380and host vehicle200. Backend390(one or more servers), intermediates between mobile device380and host vehicle200. Prior to block701, mobile device200knows: (a) a public key of backend390, (b) vehicle metadata (an identity of host vehicle200), (c) backend metadata, (e) mobile device metadata, (h) a mobile device private key, and (i) a mobile device/backend keypair [which is a private password].

Prior to block701, backend390knows (b) the vehicle metadata, (c) the backend metadata (d) a vehicle security symmetric key, (e) the mobile device metadata, (f) the private key of backend390, (g) a map of mobile device keypair (i) to (b) and/or (d), and (i) the private mobile device keypair. Prior to block701, host vehicle200knows (c) the backend metadata and (d) vehicle security symmetric key [set at time of manufacturing].

The following table is provided for the reader's convenience:

A process of generating and applying a new VAK will now be described in order. Mobile device380sends a new key request701to backend390, which is a request for connectivity module300of host vehicle200to store a new VAK for mobile device380. The new key request includes (b) and (i) individually encrypted according to (a). The new key request includes (e), which is unecrypted and thus enables routing of new key request701to backend390. The new key request includes an unencrypted mobile device public key, which is based on (h).

Upon receiving new key request701, backend390decrypts the message and confirms that (i) and (b) match via (g) the map (e.g, a table or spreadsheet). If the match is present, then backend390generates a VAK, the function (corresponding to r_ph and r_veh), and any hashing functions (previously discussed). Backend390individually encrypts the VAK and the functions according to (d) the vehicle security symmetric key associated with (b).

Key provision702includes the encrypted VAK, the encrypted functions, and unencrypted metadata. The unencrypted metadata enables main telematics module320to route key provision to connectivity module300at internal message703(which at least includes the VAK and the function individually encrypted according to (d)). Connectivity module300decrypts internal message703with (d), stores the VAK and stores one of the function as r_veh, stores the other functions as the hashing functions, and sends a response704. The response704includes unencrypted metadata routing the message according to (c) and substantive data encrypted according to the VAK.

At705, main telematics module320passes response704to backend390based on (c) the unencrypted metadata of backend390. Upon receiving response705, backend390transmits the VAK and the functions to mobile device390at706. Upon receiving response705, backend390may save the VAK and the functions and associate the same with the vehicle metadata. Alternatively, backend390may permanently delete the VAK and the functions.

In provision key message706, the VAK and the functions are encrypted according to a mobile device public key, provided in as unencrypted data in new key request701. Message706includes unencrypted mobile device metadata (e). Mobile device380decrypts message706with (h). Mobile device380stores the VAK, stores one of the functions as r_ph, and stores the other functions as the hashing functions. Mobile device380and host vehicle200may now execute steps402through450as discussed inFIGS. 5 and 6.

A process of revoking a VAK will now be described in order. Mobile device380issues a revoke key request721, which is similar to new key request701(i.e., encrypted and transmitted according to the same techniques), but includes a revoke key command, instead of a new key command. Revoke key request721may include the encrypted VAK ID or the encrypted VAK.

Backend390receives the revoke key request721, decrypts the VAK ID or VAK, and issues a revoke key command722(as above, if (i) maps to (b), which is similar to provision key message702(but includes a revoke key command and the encrypted VAK ID or the encrypted VAK). Main telematics320generates a revoke key internal message723based on722. Connectivity module300decrypts the revoke key internal message, revokes the VAK, the function (r_veh), the hashing functions, and generates a response724(which is similar to response724, but includes the encrypted VAK or VAK ID).

Main telematics module320forwards response704with response705to backend390. Backend930decrypts response705, marks the VAK and the function as revoked, and transmits a revoke key confirmation726to mobile device380. Revoke key confirmation726is similar to the provision key message706. Mobile device380decrypts revoke key confirmation726and revokes the VAK, the function (r_ph), and the hashing functions based on the decrypted VAK or VAK ID.

It should thus be appreciated that the following message pairs are similar (encrypted and routed according to the same techniques), but include different underlying substantive data either corresponding to a provision key command or a revoke key command: (i) messages701and721, (ii) messages702and722, (iii) messages703and723, (iv) messages704and724, (v) messages705and725, (vi) messages706and726. It should be appreciated that the following message pairs include at least the same encrypted data: (i) messages702and703, (ii) messages704and705, (iii) messages722and723, (iv) messages724and725.

Various items in this disclosure may be trademarked, including Bluetooth and Blu-Ray.