CN106537463B - Method and device for improving vehicle safety - Google Patents

Abstract

Apparatus, systems, and methods are disclosed that utilize inputs of a vehicle user to provide logical circuit context for legitimate vehicle use through a remote access device to protect a vehicle from theft. Thus, additional levels of security are employed and may be used in addition to other security and anti-theft techniques for the vehicle. In one example, a legitimate vehicle operator signals the context of the vehicle state to a hardware security module in the vehicle. The status includes, for example, not allowing all diagnostic system access or allowing diagnostic access for servicing.

Description

Method and device for improving vehicle safety

RELATED APPLICATIONS

The present application claims priority from U.S. provisional application sequence No.62/023388 entitled "METHOD AND APPARATUS FOR PROVIDING VEHICLES SECURITY" filed on 11.7.2014 FOR Jason Aurelle Soroko AND U.S. non-provisional application sequence No.14/795072 entitled "METHOD AND APPARATUS FOR PROVIDING VEHICLES SECURITY" filed on 9.7.2015 FOR Jason Aurelle Soroko AND incorporated herein by reference.

Technical Field

The present application relates generally to vehicle security systems, and more particularly to vehicle security systems that may be activated with remote access devices, such as key fobs, smart phones, internet appliances, and any other suitable remote access device.

Background

Modern motor vehicles (automobile) contain electronic control units and sensors connected to a network. Controller Area Network (CAN) systems were first implemented in 1986 and have become the standard implementation for automotive electronics. The door lock actuator, the engine starter and the anti-theft sensor are electrically connected to the same computer network as the vehicle diagnostic system. Thus, the door lock, engine starter and anti-theft sensor may be commanded from electronic inputs issued into the physical diagnostic port (OBD-II). In some vehicles, this capability may also be obtained remotely through a wireless connection by a device such as an electronic key fob or smart phone. There are many legitimate uses for remotely starting a vehicle engine and locking or unlocking a door. There are also many legitimate uses for physically accessing an automotive diagnostic OBD-II port in order to obtain diagnostic information.

Fig. 1 shows an example of a known vehicle configuration. It will be appreciated that other components may also be used. As shown, a Controller Area Network (CAN)100 is a network that allows a plurality of electronic control units located throughout an engine and a vehicle to communicate with each other through various links. Furthermore, the CAN includes a hardware security module that is designed to be tamper-resistant and therefore difficult for an attacker to access, modify, or bypass. As is known in the art, a hardware security module includes one or more processors, such as a central processing unit, and associated memory, where the memory stores executable instructions that, when executed, cause the processors to perform security operations. Examples of safety operations currently performed by the vehicle HSM may include work done by the EVITA project. The EVITA targets are: all encryption operations are internal to the HSM: all keys are stored inside the HSM. The key has a usage flag (encryption, decryption, signing, verification). An example of a use case may be a valet parking privacy application. There is secure access and storage of personal usage data related to vehicle usage, such as information from infotainment services or usage of a driving activity recording system. Another example may be that an activity such as braking in one car may result in the activation of brakes in another car. Communications are protected by the HSM.

In another use case, the data is sent to the display and signed by a key stored in the HSM. The vehicle 102 may be, for example, an automobile, a truck, or any other suitable vehicle. The vehicle system also includes one or more Local Interconnect Networks (LIN)104 in communication with the CAN via one or more communication links. LIN may allow access to door lock actuator 106 as well as other actuators and devices. The vehicle also includes various sensors 108, anti-theft sensors 110, actuators 112 (such as anti-lock brake system actuators), an entertainment system 114, an electronic engine controller 116 that may also be interconnected with other sensors (such as emission control sensors, speed sensors, and other sensors 118 known in the art), and a vehicle diagnostic system 120 (such as an OBD II system with a diagnostic port 122 (such as an OBD-II port)). As is known in the art, the OBD-II port may be accessed to obtain diagnostic information and other information from a vehicle diagnostic system. A user of the vehicle may be assigned a remote access device 124, such as a key fob with a wireless transceiver, to communicate with the CAN of the vehicle to unlock doors, open the trunk, start the vehicle, and perform other operations.

Defense systems, such as checks for the presence of a physical key, have been defeated by the theft's ability to duplicate the physical key. Defense systems that check for electronic signals or digital signatures embedded on physical keys or remote key fobs have also been defeated. The weak implementation of physical and electronic key security results in malicious physical access to the vehicle.

If car thieves are able to gain physical or remote wireless access to the vehicle diagnostic electronics, they will be able to issue electronic commands to unlock the doors to allow physical access and start the engine. Furthermore, in any complex electronic system, there is the possibility of implementing a defect, which will enable a malicious actor to take control. Thus, more than one layer of defensive security is required.

The vehicle diagnostic system will accept the command without authentication. In the future, if the vehicle diagnostic system performs authentication, the vehicle still cannot know whether the act of authentication is performed by a legitimate vehicle operator or a malicious thief. Authentication implementation flaws and the fundamental weakness of authentication secrets highlight the need for additional layers of defense security.

Fig. 2 shows an example of a gateway ECU 200 that may be employed as part of CAN 100. The hardware security module 202 may be employed as part of the gateway ECU or will be connected to the gateway ECU in a secure manner. The hardware security module includes one or more processors and associated memory that allow software to be executed by the processors to cause the processors to perform operations. Gateway ECU 200 also includes one or more processors 204 and associated memory 206. The gateway ECU 200 may also include a wireless transceiver 201 or communicate with a wireless transceiver in the vehicle to allow communication with a remote access device, shown in this example as a key fob 208, an OEM remote access system 210 (such as OnStar), or a smartphone 212.

It has been proposed to provide symmetric encryption between the remote access device and a hardware security module in the gateway ECU, for example to store a vehicle certificate with a unique vehicle ID. In addition, the remote access device is also manufactured with corresponding symmetric certificates so that the key fob and HSM can perform authentication operations so that the HSM and gateway ECU can authenticate, for example, the key fob or other device using a symmetric key authentication process to identify the key fob as appropriately corresponding to a particular vehicle so that it can be trusted.

However, with such systems, problems arise because a hacker can obtain such a symmetric key-based certificate from a key fob and program it into another key fob, thereby allowing the hacker to access and steal the vehicle. This is because once the symmetric key based certificate has been authenticated, the vehicle allows access to the diagnostic system. For example, a parked vehicle will still allow access to its diagnostic system, for example, through an OBD port. The vehicle may have a number of access points, such as bluetooth, WiFi or OBD ports.

It has also been proposed to use an asymmetric public key infrastructure system where the OEM may, for example, act as a root certificate authority (e.g., a server controlled by the OEM) and the HSM authenticates the key fob as being a genuine manufacturer part, since the manufacturer will issue public and private key pairs for the HSM and key fob. However, the proposed system still allows OBD access to parked vehicles or vehicles that have been locked with a remote access device.

Also, while the vehicle is driving, the electronic systems coordinate with each other to accomplish preprogrammed tasks. ABS braking enables an operator to maintain control over steering while carefully balancing brake disc application if the operator has difficulty applying the braking system in a particular situation. In coordination with the camera sensor, adaptive cruise control makes the driving experience more intelligent by helping the operator to automatically control the throttle and brake. The auxiliary parallel parking logic assists the operator by automating a series of steering motions. These electronic advances have resulted in increased safety and convenience for operators.

If ABS brakes are applied at high speeds or to assist parallel parking, the results can be catastrophic to the occupants of the vehicle. Unfortunately, this is possible due to the electronic connection of the vehicle's computer network and the trusted nature of the electronic control unit. Electronic security mechanisms can be bypassed and defeated. Most feared is that, unlike a normal personal computer, the amount of time an attacker may need to apply an electronic denial of service attack or timing attack only needs to be a few seconds before the vehicle may collide with another vehicle or roadside fixtures when the vehicle is traveling at high speed.

Drawings

Embodiments will become more readily understood from the following description when taken in conjunction with the following drawings, wherein like reference numerals designate like elements, and in which:

FIG. 1 is a block diagram of a prior art vehicle system;

FIG. 2 is a block diagram of a prior art gateway electronic control unit in a vehicle;

FIG. 3 is a block diagram illustrating one example of a hardware security module having a user-provided security context according to one embodiment of the present disclosure;

FIG. 4 is a block diagram of one example of an in-vehicle hardware security module with user-provided security context control, according to one example set forth in this disclosure;

FIG. 5 is a block diagram illustrating one example of a vehicle remote access device according to one embodiment set forth in the disclosure;

FIG. 6 is a flow diagram illustrating one example of a method of operation of the hardware security module shown in FIGS. 3 and 4;

FIG. 7 is a flow chart illustrating one example of operation of a vehicle remote access device and a security module according to one aspect of the present disclosure;

FIG. 8 illustrates one example of a key fob according to one aspect of the disclosure;

FIG. 9 is an illustration of a smartphone employing a graphical user interface, according to one example set forth in this disclosure;

FIG. 10 is a flow chart illustrating one example of operation of a vehicle remote access device and security module according to one aspect of the present disclosure;

FIG. 11 is an illustration of a smartphone employing a graphical user interface, according to one example set forth in the disclosure; and

fig. 12 illustrates one example of a key fob according to one aspect of the disclosure.

Detailed Description

Briefly, an apparatus, system, and method are disclosed for providing a logical circuit context for legitimate vehicle use through a remote access device using input from a vehicle user to prevent vehicle theft. As such, additional levels of security are employed and may be employed in addition to other security and anti-theft techniques for the vehicle. In one example, a legitimate vehicle operator signals the context of the vehicle state to a hardware security module in the vehicle. The status includes, for example, not allowing all diagnostic system access or allowing diagnostic access for servicing.

When diagnostic service is not enabled, the electronic controller in the vehicle does not respond to the command. This may include an electronic control unit known as a gateway ECU and any other electronic devices communicating with the LIN bus (local interconnect network). The LIN bus is typically an electronic network that issues commands to the door lock actuator. When the motor vehicle is in a mode where no diagnostic service is allowed, diagnostic commands that result in unlocking of the doors and starting the engine are not allowed to move on the CAN, LIN, FlexRay or any other vehicle network. If thieves gain malicious physical access to the parked vehicle, they cannot issue electronic commands to the automotive computer network through a physical diagnostic port or through a remote wireless connection.

An apparatus for providing vehicle security for a vehicle includes a security module including an asymmetric key based cryptographic engine to authenticate a vehicle remote access device based on a public key associated with the vehicle remote access device. The security module is further operable to establish a secure link with the vehicle remote access device. The security module includes logic to selectively prevent access to a diagnostic system of the vehicle in response to vehicle security context information received from the vehicle remote access device via the established secure link. In one example, the secure module is a hardware secure module having a tamper-resistant hardware structure.

The logic circuit may selectively prevent access to a diagnostic system of the vehicle. For example, when the diagnostic system receives a command, it will only run when signed by a cryptographic key stored in the HSM. If the security status is "on", such signing up does not occur, which means that the user of the car has signaled the intention that the car will not be used and that the car is not intended for repair.

In another embodiment, a vehicle remote access device includes a wireless transceiver and logic coupled to the wireless transceiver operable to facilitate public key based authentication with a vehicle electronic control unit. The vehicle remote access device also includes a user interface, such as a button or a graphical user interface or both, that provides vehicle security context information to the vehicle electronic control unit to prevent access to the vehicle's diagnostic system.

In another embodiment, a method performed by a device in a vehicle includes authenticating a vehicle remote access device based on a public key associated with the vehicle remote access device, establishing a secure link with the vehicle remote access device, and selectively preventing access to a diagnostic system of the vehicle in response to vehicle security context information received from the vehicle remote access device via the established secure link.

In one embodiment, a vehicle system includes a vehicle remote access device including a wireless transceiver, a first logic circuit operatively coupled to the wireless transceiver operable to facilitate public key based authentication with a vehicle electronic control unit. A remote access device, such as a key fob, smartphone, or other device, includes a user interface, such as a button, graphical user interface, or any suitable selection mechanism operatively coupled to logic circuitry. The remote access device provides vehicle security context information to the vehicle electronic control unit to prevent access to the vehicle's diagnostic system. The system includes a security module, such as a hardware security module, that includes an asymmetric key-based cryptographic engine operable to authenticate the vehicle remote access device based on a public key associated with the vehicle remote access device and operable to establish a secure link with the vehicle remote access device. The system includes a second logic circuit operative to selectively block access to a diagnostic system of the vehicle in response to vehicle security context information received from the vehicle remote access device via the established secure link.

In one embodiment, the logic is stored in a dedicated Hardware Security Module (HSM). HSMs are designed to be tamper-resistant and therefore an attacker cannot access, modify or bypass the secure logic. If desired, the logic circuit operation utilizes a Trusted Execution Environment (TEE) in the CPU of the hardware security module. TEE is a security standard for Global Platform that isolates critical logic functions into a secure and isolated space, further protecting the secure logic.

The context that the diagnostic service is allowed or not allowed is commanded via a remote access device of the normal car owner, such as an electronic key fob issued by the vehicle manufacturer or a smart phone application issued by the vehicle manufacturer. The connection and communication protocol may utilize existing technologies such as bluetooth, WiFi or another wireless technology chosen by the automotive manufacturer.

To protect the communications so that the thief cannot hear the commands in order to replay them at a later time (known as a replay attack), the communications are protected. This may be accomplished by implementing an SSL/TLS encrypted communication tunnel (link) between the key fob or smartphone application and the automotive connectivity technology (e.g., HSM) that is receiving the command. For example, the federal information processing standard FIPS 140-2 may be applied to communications between a key fob or smart phone application and an HSM device to create a highly secure communication channel.

As noted above, authentication of vehicle systems by existing key fobs or smartphones utilizes symmetric key technology that has been defeated. The thief can find out the shared secret between the key fob and the authentication system by investigating the motor vehicle computer system memory via the diagnostic port (OBD-II).

It is therefore important to employ powerful asymmetric cryptography, such as Public Key Infrastructure (PKI), in which private keys are securely stored in the vehicle hardware security module, as well as in the security elements within the electronic key fob. For smart phones it is feasible to store the private key within the smart phone. Similar to this is the Entrust Mobile Smart credit application. A more secure smartphone implementation would utilize secure elements on the phone and a Trusted Execution Environment (TEE) built into many smartphones. In fact, an electronic key fob or smart phone becomes equivalent to a smart card, which authenticates the ECU of the motor vehicle. The two halves of the private key of the PKI system are stored in secure tamper-resistant hardware. The PKI certificate authority and the root of trust may be managed by the vehicle manufacturer or other suitable third party. This would include certificate management, including device provisioning (provisioning), user provisioning, and certificate revocation. If the car changes ownership, the management of the change of ownership identity will be managed by the vehicle manufacturer.

The disclosed safety implementation allows for variations in use cases where the driver loses the ability to start the vehicle. This is accomplished by enabling the vehicle to change modes by utilizing remote services provided by the vehicle manufacturer. Systems such as OnStar and ConnectedDrive of BMW for general purpose automobiles are examples. These remote service commands will include a protected PKI authentication mechanism. They also protect communications by encrypting the communication tunnel using SSL/TLS. In this way, a malicious actor cannot pretend to be a legitimate remote service.

Among other advantages, motor vehicles in particular no longer trust malicious commands that may allow theft. The encryption key material does not have to be shared with the service center in order to authenticate access to the diagnostic system. This is a weakness of diagnostic authentication systems when the diagnostic context logic is not present.

The disclosed security implementation does not require shifting of other layers of security defense and can work in parallel with existing vehicle technology.

In one example, logic is placed in the hardware security module to enable and disable the context that allows diagnostic access. A secure connection to the logic circuit state is achieved. Logic circuits are also placed in electronic key fob or smartphone applications. These devices will all be part of the normal automotive deployment by the automotive manufacturer. If these are lost, the connections and logic from the vehicle manufacturer's remote control system need to be able to control the vehicle.

As described, operator authentication of a vehicle ECU controlling a security logic circuit is achieved by implementing a public key infrastructure in which a private key is stored in a hardware security module.

Another layer of security may also be provided by disabling the issuance of commands from the diagnostic system if desired, and an alarm system may be employed when the vehicle logic (such as the HSM) detects a malicious condition to any subsystem (such as the brake system or any other system). Such logic may be employed in addition to all other security, security and anti-theft techniques.

In connection with this additional layer of security, a common method of attack is to repeatedly attempt to send messages into the vehicle network, effectively causing a known "race condition" that is based on increasing the probability that a malicious command will override a legitimate command or security check.

The malicious command may come from physical access to an OBD-II diagnostic port, an entertainment system connection, or through a remote wireless connection. This highlights the need for an internal electronic control unit logic circuit comprising:

commands from the diagnostic system for applying the brake system should not be allowed while driving. Any command that is repeated multiple times in a short time (under 10ms, or based on an expected rate depending on normal driving conditions) should be identified as potentially malicious.

Any "information flood" event that causes the service within the vehicle electronics to be denied while driving will result in the vehicle attempting to alert the operator.

In one example, the disclosed logic circuit does not allow all diagnostic access except for outbound information when the vehicle is driving. Based on the vehicle design specifications, the logic circuit does not allow any attempt to issue an invalid command from the diagnostic system to CAN, LIN, FlexRay or any other vehicle network. The list of legal commands may be provided by the vehicle manufacturer for monitoring and storage in the security module.

If any of these logic circuit conditions are detected by the logic circuit, the vehicle operator may be notified to safely stop the vehicle. Such an alert may be sent through a separate and isolated notification system. This may be a haptic system connected to the seat, steering wheel, brake, throttle and gear change controller. This may also include dashboard alerts and notifications via the entertainment system.

Automotive hardware security modules are tamper-resistant electronic devices that can store data and logic circuitry in isolation from other electronic systems. They contain a secure element from which such logic circuits can be read. Applications of logic circuits may be executed within a known Trusted Execution Environment (TEE), which is a further isolation of the computer execution space from other electronic environments.

Some benefits of context logic include that the vehicle no longer trusts malicious commands that could lead to catastrophic consequences. Moreover, the threat surface of the motor vehicle is reduced.

In one example, logic circuitry (such as a programmed processor) is located in the hardware security module to disable issuing commands from the diagnostic system. When a malicious command condition is detected by the vehicle logic, an alarm system is employed.

Fig. 3 shows an example of a hardware security module with a user-provided security context 300, shown in this example as part of a gateway ECU. However, it will be appreciated that the hardware security module 300 may be located at any suitable point in the network, as desired. In this example, the gateway ECU 301 includes a wireless transceiver 201 and communicates with a remote access device 302, which remote access device 302 may be, for example, a key fob, a smart phone, or an OEM remote access system with user context security logic. The user context security logic allows a legitimate vehicle operator to notify the hardware security module 300 of vehicle security context information 405 sent by the vehicle remote access device (e.g., over the secure wireless link 306). The vehicle safety context information 405 may be, for example, an indication that the diagnostic system should be turned off.

Fig. 4 shows an example of a security module 300 with user-provided security context control in more detail. In this example, the security module 300 is a hardware security module, which is a tamper resistant electronic device that stores data and contains logic circuitry isolated from other electronic systems in the vehicle. In one example, the security module 300 includes logic 402, which may be, for example, a state machine, discrete logic, one or more processors executing programmable instructions stored in a memory that, when executed, cause the processors to operate as described herein, or any other suitable combination of hardware and software. The security module 300 also includes an asymmetric cryptographic engine 402, which may be a state machine, discrete logic circuitry, or one or more processors executing stored instructions that, when executed, cause the processor to operate as an asymmetric cryptographic engine, or any other suitable logic circuitry. If desired, the same processor may provide both the logic circuit 400 and the asymmetric cryptographic engine 402 by executing different executable code (if desired). The processor may be any suitable processor, such as a CPU, digital signal processor, or any other suitable programmable processor. Furthermore, the methods claimed herein are performed electronically.

When the logic circuit 400 and the asymmetric cryptographic engine 402 are implemented by one or more processors executing stored instructions, the non-transitory memory 404 may store executable instructions. The memory 404 may be any suitable memory made of any suitable technology, including memristor technology or any other suitable technology known in the art, such as RAM, ROM, or other storage media. In addition, the memory 404 also stores a private key 410 of the gateway ECU 404, a public key 412 of the HSM 300, a public key 414 of a remote access device (such as a key fob, a smart phone, or any other suitable device). The asymmetric cryptographic engine 402 may be a PKI engine that utilizes a public key and private key pair to perform mutual authentication. In addition, other keys may be employed to provide a secure channel between the remote access device and the HSM, such as according to the FIPS-140-2 standard or any other suitable secure channel protocol. The asymmetric key based cryptographic engine 402 is operable to authenticate the vehicle remote access device based on a public key associated with the vehicle remote access device and also establish a secure link with the vehicle remote access device. The logic circuit 400 selectively prevents access to a diagnostic system of the vehicle in response to vehicle security context information 405 received from a vehicle remote access device via an established secure link or channel. As mentioned previously, the hardware security module 300 may be a tamper-resistant hardware structure.

In operation, in one example, the asymmetric cryptographic engine 402 authenticates a vehicle remote access device based on a public key 414 associated with the vehicle remote access device (see fig. 5). The public key crypto engine also establishes a secure link or channel with the vehicle remote access device. The logic circuit 400 selectively prevents access to a diagnostic system of the vehicle in response to the vehicle security context information 304 received from the vehicle remote access device via the established secure link. For example, if the operator of the key fob selects vehicle shutdown via a graphical user interface or a button on the key fob such that the operator wishes to have the vehicle diagnostic system effectively shutdown on the logic circuit, then such vehicle safety context information 405, which may be one or more bits sent to the HSM via a secure channel, is then evaluated by the logic circuit 400, and if the information indicates that the diagnostic system should be shutdown on the logic circuit, the logic circuit 400 will indicate the ECU. For example, the logic circuit 400 may issue a CAN network monitor command 420 requesting the CAN network to monitor an on-board diagnostic system bus or other data to determine if access is being made to the vehicle diagnostic system. The ECU, via the processor 204, may then perform monitoring of the CAN network for access to the OBD. This may be done, for example, by an action that allows or prevents certificate signing commands sent to the diagnostic system. The diagnostic system will only respond to commands signed by certificates stored in the HSM. The act of signing the command occurs only when the security context is set to an enabled mode ("security context off"). If unsigned, falsely signed commands reach the diagnostic system, the diagnostic system will not work on those commands. This may also include tapping (tapping) the traffic of the CAN network with a dedicated network controller that records and classifies individual packets, similar to how intrusion prevention systems work in traditional IT systems, e.g., if the ECU detects that an OBD is being accessed, IT may send a security condition notification 422 to the logic circuit 400. The logic circuit 400 may then request an alarm to be issued via an alarm issue command 424, and the ECU may then issue an alarm notification, which may be sent back to the user's key fob in the form of an audio and/or visual alarm, and/or may also activate another alarm on the vehicle, and if desired, send an alarm message to a security infrastructure that may contact the police.

As shown in fig. 5, the remote access device may be a key fob 502, a smart phone, or any other suitable device and, as is known in the art, may include a wireless transceiver 500, such as a bluetooth, near field transmitter, cellular transmitter, WiFi transceiver, or any other suitable wireless transceiver 500, which may include one or more processors 504 or other suitable logic that constitutes user context security logic. The user context security logic may include an authenticator and secure channel generator 506 and may be operable to provide the selected user security context information 405 to the HSM 300 via the secure channel. In this example, a suitably programmed processor is employed that is programmed to complement the asymmetric cryptographic engine of the HSM's cryptographic engine. In one example, this can be accomplished by storing code executed by the one or more processors 504 in the memory 508. However, it will be appreciated that discrete logic circuitry, state machines, or any suitable combination of hardware and software may be employed. Further, a user interface 510, such as one or more buttons, a graphical user interface, a microphone, a speaker, or any other suitable user interface, is electronically coupled to the cryptographic engine to provide a vehicle security context input information provision to allow a user to select an additional layer of security desired by the user or vehicle operator so that, not only is the vehicle locked, for example, but in addition to that, the vehicle operator also desires to indicate that the context of the vehicle should be such that the diagnostic system should also be effectively turned off and inaccessible. The vehicle safety context information 405 may then be transmitted via the wireless transceiver 500 via a safe channel, as previously indicated.

It will be appreciated that the user interface 510 may be an existing button, for example on a key fob, that may be pressed and held down for an extended period of time to select the security context input information to be "on" so that the diagnostic system in the vehicle is prevented from being accessed. Alternatively, separate buttons either mechanically or through a graphical user interface may be employed. Further, audible commands may be utilized, biometric input may be utilized, or any other suitable activation mechanism as desired.

FIG. 6 is a flow chart illustrating one example of a method performed by a device in a vehicle beginning at block 600. The process may be initiated, for example, by a user activating a button or other selection mechanism on the vehicle remote access device to initiate the vehicle security context mode. It may also be automatically activated when the key fob or smartphone is within a certain range of the vehicle, if desired. As shown in block 602, the method includes authenticating a vehicle remote access device (such as a key fob or smartphone) based on a public key associated with the vehicle remote access device. As shown in block 604, the method includes establishing a secure link, such as a TSL secure tunnel, with the vehicle remote access device. Shown in block 606, the method includes selectively preventing access to a diagnostic system of the vehicle in response to vehicle security context information received from the vehicle remote access device via the established secure link. The method may be performed, for example, by logic circuitry in the vehicle and (in one example) a security module such as an HSM. The method may end as indicated in block 608.

Fig. 7 illustrates one example of a method of operation between a remote access device and an HSM, according to one embodiment. The user establishes a connection to the vehicle via bluetooth, WiFi, or other wireless technology, for example, by activating a button on a key fob or through a graphical user interface (block 700), and requests the HSM to perform mutual authentication 702 with the HSM's encryption engine. There are standard asymmetric authentication methods and protocols available to vehicle OEMs. An example for a remote wireless cross-challenge response would be a remote authentication scheme based on Elliptic Curve Cryptography (ECC) ID. The encryption step has been standardized. From the target perspective, the protocol steps are: mutual authentication of the server and the user, establishment of a secret authentication key to protect data used in the mutual authentication, non-repudiation of origin by the user and the server for related data sent from the user to the server and vice versa establishment of a negotiation for a secret session key, which will be used to encrypt data communications.

If the fob is authenticated by the HSM, the HSM establishes a secure channel 704, such as a TLS, for example, and the HSM will send a successful connection indication to the fob over the secure channel. The key fob then activates a light or other indication 706 on the key fob indicating that a secure connection is in place, for example, if desired. The HSM then indicates 708 the current computer security context of the vehicle to the handheld device. This may indicate, for example, a symbol of a computer component covered by a symbol of a red lock to highlight a condition where the vehicle does not allow diagnostic control and is protected. Another example is that the same computer component is not covered by a locked symbol, next to a yellow exclamation point, which would highlight a condition that diagnoses the computer system as being commanded and thus alert the user not to have their car parked in such a condition. The handheld device may then display 710 the current computer security context on the GUI or through another suitable button or indication. The HSM then waits for further instructions 712. If the user decides to provide additional vehicle security context 714 by, for example, selecting an on or off button when the car engine is off or parked, the vehicle security context information is transmitted to the HSM over a secure channel, and if the security context is not set 716, the HSM may send a command to the ECU to stop monitoring illegal commands to the diagnostic system 718. However, if the vehicle safety context is set, the HSM instructs the ECU to perform monitoring and listen to the monitoring results of the diagnostic system 720. If the ECU indicates an illegal activity 722, such as the detection of an OBD-2 diagnostic command, the HSM will notify the ECU to issue an alarm. If the ECU receives an alarm command from the HSM logic, the ECU will connect to the OEM remote access service and alert 724 of a potentially dangerous condition. Furthermore, if a connection is established with the handheld device, an alert may be sent to the remote access device over the normal connection without using a secure channel. If desired, a problem alert may also be displayed on the dashboard display of the vehicle via the ECU.

Fig. 8 and 9 are schematic diagrams of a key fob and a smartphone, respectively, as defined using the vehicle security context information described above. In these examples, the remote access device includes secure connection indicators 800 and 900 showing the user that a secure channel has been established between the remote access device and the HSM. In addition, the safe vehicle computer selectors 802 and 902 are used to allow a user to activate a vehicle safety context mode to indicate that the vehicle diagnostic system should not be accessible. If the activation of the vehicle safety context information has been properly performed, the user is notified of the safety vehicle computer indicators 804 and 904. Further, during the time that the safety vehicle computer indicator is activated, a visual, audible, or both alarm or warning alert as shown at 806 and 906 is activated in the event that the HSM has detected access to the diagnostic system.

Fig. 10 is a flow diagram illustrating another embodiment of a system in which location information of a smartphone or key fob and/or biometric information of a user may be employed. As shown, when used, the smartphone may issue a secure challenge against the user's biometric fingerprint or PIN code, as shown in block 1000. If the mutual authentication has been approved, the HSM can set up a TLS-based secure channel, with the biometric fingerprint information being an additional level of security. If desired, the smartphone or fob may register the GPS coordinates and send the GPS coordinates to the HSM over the secure TLS channel, as shown in block 1002. The received GPS coordinates are compared to the car coordinates (such as from the vehicle GPS) and if the location is too far, an alert is sent to the OEM remote access service, as shown in block 1004. The OEM remote access service will contact the user of the vehicle to ensure that this is the intended operation. If the legitimate user does not intend to do so, the vehicle will be fixed or tracked by the OEM remote access service, depending on the OEM-specific policy. Then, as shown in block 1006, a successful connection indication to the handheld device is sent over the secure channel, which is then indicated on the key fob or smartphone, as shown in block 1008. An indication of the current computer security context may be sent to the handheld device, as shown in block 1010, which may then be displayed on a GUI or otherwise indicated to the user, as shown in block 1012. If the remote access device or OEM remote access service sends vehicle security context information, this may be done based on the number of conditions. These are shown in blocks 1014, 1016, 1018, and 1020. These activities may be recorded in the memory of the remote access device, as shown in block 1022. For example, when the user has stopped the engine, the vehicle security context notification may be indicated as "on" and sent to the HSM in a secure channel. When the user has stopped the engine and the user wishes to have the diagnostic system access to the third party server, the user may select that condition and a notification indicating that the vehicle security context information is "off" is securely sent to the HSM. As shown in block 1018, in another example, the OEM remote access service has the capability to overwrite the security context in the HSM upon user request (e.g., if there is a lost key fob or a secure connection cannot be established with the smartphone). As shown in block 1020, if desired, security context charging activity is recorded at the OEM remote access service and local memory location.

As shown in fig. 11 and 12, automatic service selectors 1100 and 1200 are shown to allow, for example, user selection of a diagnostic service to occur. A GPS and/or biometric interface may also be provided as shown in 1102 and 1202. Accordingly, these devices may be used with the operations shown in fig. 10, for example.

In general, automotive electronic systems partially trust the commands issued to them. Automotive vehicles often cannot distinguish whether a command is issued from their legitimate operator or from a malicious thief. This problem is solved when the legitimate operator of the vehicle can signal the intent to the vehicle. Indeed, the context of whether the vehicle driver wants to drive or park the vehicle is part of defensive safety.

If a legitimate operator of a vehicle wants to park for a period of time, it can be assumed that the intention of the operator is that the vehicle doors will be locked and the engine will be stopped, and furthermore, the vehicle will not accept commands from the diagnostic system until the driver issues a command to unlock the doors and start the engine.

The exception to this is if the vehicle operator wants the vehicle to be serviced. The diagnostic port will be legitimately accessed. The vehicle owner or driver is allowed to issue a command to the vehicle to place it in a mode that allows diagnostic service.

In another embodiment, blocking of non-legitimate commands during legitimate operator operations may also be provided in combination, so that, for example, the hardware security module may disable commands issued from the diagnostic system. Other advantages will be recognized by those of ordinary skill in the art.

Among other advantages, an additional vehicle security layer is provided that includes an asymmetric key based mutual authentication operation between a remote access device and a vehicle security system. An additional secure channel, such as an SSL or TLS channel, is established between the HSM and the remote access device to issue additional commands by the vehicle operator or to provide vehicle security context information indicating, for example, that the vehicle diagnostic system should be shut down on the logic circuit. This may be information other than, for example, information indicating that the vehicle is parked and/or locked. As such, performing a physical lock of the vehicle is performed and a logical lock of the diagnostic system is performed.

The foregoing detailed description of the invention and the examples described therein have been presented for the purposes of illustration and description only and not by limitation. It is therefore contemplated to cover by the present invention any and all modifications, variations or equivalents that fall within the spirit and scope of the underlying principles disclosed above and claimed herein.

Claims (10)

1. An apparatus for providing vehicle safety for a vehicle, comprising:

a security module comprising:

an asymmetric key based encryption engine operable to authenticate the vehicle remote access device based on a public key associated with the vehicle remote access device and operable to establish a secure link with the vehicle remote access device; and

logic circuitry operable to responsively selectively prevent access to a diagnostic system of the vehicle responsive to vehicle security context information received from the vehicle remote access device via the established secure link.

2. The apparatus of claim 1, wherein the secure module comprises a hardware secure module having a tamper-resistant hardware structure.

3. The apparatus of claim 1, wherein the logic circuit selectively prevents access to a diagnostic system of a vehicle by at least the act of allowing or preventing a certificate signing command sent to the diagnostic system.

4. The apparatus of claim 1, wherein the security module, asymmetric key based encryption engine, and logic circuitry are in the vehicle.

5. A vehicle remote access device, comprising:

a wireless transceiver;

logic circuitry operably coupled to the wireless transceiver operable to facilitate public key based authentication with the vehicle electronic control unit;

a user interface operably coupled to the logic circuit and operable to provide vehicle safety context information to a vehicle electronic control unit to prevent access to a diagnostic system of a vehicle.

6. The vehicle remote access device of claim 5, wherein the vehicle remote access device comprises a handheld vehicle remote access device.

7. The vehicle remote access device of claim 6, wherein the handheld vehicle remote access device comprises a key fob.

8. A method performed by a device in a vehicle, comprising:

authenticating, by a device in the vehicle, the vehicle remote access device based on a public key associated with the vehicle remote access device;

establishing, by a device in a vehicle, a secure link with a vehicle remote access device; and

selectively preventing, by a device in the vehicle, access to a diagnostic system of the vehicle in response to vehicle security context information received from a vehicle remote access device via the established secure link.

9. A vehicle system, comprising:

a vehicle remote access device comprising:

a wireless transceiver;

a first logic circuit operably coupled to the wireless transceiver operable to facilitate public key based authentication with the vehicle electronic control unit;

a user interface operably coupled to the logic circuit and operable to provide vehicle safety context information to the vehicle electronic control unit to prevent access to a diagnostic system of the vehicle; and

a security module comprising:

an asymmetric key based encryption engine operable to authenticate the vehicle remote access device based on a public key associated with the vehicle remote access device and operable to establish a secure link with the vehicle remote access device; and

a second logic circuit operable to responsively selectively block access to a diagnostic system of the vehicle responsive to vehicle security context information received from the vehicle remote access device via the established secure link.

10. The vehicle system of claim 9, wherein the vehicle remote access device comprises a handheld vehicle remote access device, and wherein the security module is a security module in a vehicle.

Images