Vehicle security module system

Abstract

A vehicle security system having controller area network buses, electronic control units connected to the controller area network buses, a vehicle security module connected to the controller area network buses, and an on board diagnostics connector connected to the vehicle security module. The vehicle security module may according to a policy discriminate between authorized and unauthorized signals that are input to the on board diagnostics connector. Authorized signals may be forwarded by the vehicle security module to the controller area network busses. Authorized signals may affect operation of one or more of the components of the vehicle via the electronic control units. Authorized signals may change the policy used by the vehicle security module. Unauthorized signals may be refused entry to the controller area network busses. The on board diagnostics connector may receive the signals from diagnostic instrumentation, control instrumentation, tracking instrumentation, a dongle, and so forth.

Description

BACKGROUND

The present disclosure pertains to vehicle electronics and particularly to on board diagnostics systems.

SUMMARY

The disclosure reveals a vehicle security system having controller area network buses, electronic control units connected to the controller area network buses, a vehicle security module connected to the controller area network buses, and an on board diagnostics connector connected to the vehicle security module. The vehicle security module may according to a policy discriminate between authorized and unauthorized signals that are input to the on board diagnostics connector. Authorized signals may be forwarded by the vehicle security module to the controller area network busses. Authorized signals may affect operation of one or more of the components of the vehicle via the electronic control units. Authorized signals may change the policy used by the vehicle security module. Unauthorized signals may be refused entry to the controller area network busses. The on board diagnostics connector may receive the signals from diagnostic instrumentation, control instrumentation, tracking instrumentation, a dongle, and so forth.

BRIEF DESCRIPTION OF THE DRAWING

FIG. 1 is a diagram of an on board diagnostics computer arrangement for a vehicle;

FIG. 2 is a diagram of an interaction of a vehicle original equipment manufacturer, policy change requestor, vehicle security module and instrumentation such as a dongle;

FIG. 3 is a diagram of tables illustrating a default vehicle security module and authorization token change of the policy;

FIG. 4 is a diagram of a table illustrating a policy selection, an authorization token selection and a resulting policy of various selections;

FIG. 5 is a diagram showing an example implementation of an authorization token;

FIG. 6 is a diagram of a vehicle security module circuit board;

FIG. 7 is a diagram of interfaces to the vehicle security module;

FIG. 8 is a diagram of an example architecture modified for a vehicle security module;

FIG. 9 as a diagram of an example of circuitry for a vehicle security module; and

FIGS. 10a through 10j are diagrams of enlarged portions of the circuitry in FIG. 9.

DESCRIPTION

The present system and approach may incorporate one or more processors, computers, controllers, user interfaces, wireless and/or wire connections, and/or the like, in an implementation described and/or shown herein.

This description may provide one or more illustrative and specific examples or ways of implementing the present system and approach. There may be numerous other examples or ways of implementing the system and approach.

Reference may be made to symbols in the drawing. Symbols may have virtually any shape (e.g., a block) and may designate hardware, objects, activities, steps, procedures, and other items.

The idea pertains to vehicle security modules, and how to keep unauthorized intruders out of them while letting in legitimate individuals (e.g., authorized mechanics). At a high level, the present system and approach may propose an electronic key system that gives a vehicle manufacturer an ability to dictate who can get into a vehicle security module (VSM), and once in, which portions or bits of it they can change. The vehicle manufacture may be regarded as an original equipment manufacturer (OEM). The terms may be used herein interchangeably.

The system and approach use unique authorization “tokens” that dictate exactly what level of access is granted to the VSM and/or what changes can be made to the VSM policy, and may have, for example, a public/private key pairing that is used to ensure only an authorized entity is using the token. There may be several ways to ensure that the authorization token is securely passed to and accepted by the VSM.

On-board diagnostics (OBD) is an automotive term referring to a vehicle's self-diagnostic and reporting capability. OBD systems may appear in many cars and light trucks on the road today. Present OBD's may provide almost complete engine control and also monitor parts of the chassis, body and accessory devices, as well as a diagnostic control network of the car. Modern OBD implementations may use a standardized digital communications port or connector to provide real-time data in addition to a standardized series of diagnostic trouble codes (DTCs), which may allow one to rapidly identify and remedy malfunctions within the vehicle.

The present system may use an authorization token in its device. The system does not necessarily need an internet connection. The internet connection may be appropriate for a vehicle in a repair shop but it may not necessarily be appropriate for a vehicle operating on the open road with an insurance or tuning dongle.

The system does not necessarily only allow the diagnostic tool to select from pre-existing roles which have been programmed into an electronic control unit (ECU) or vehicle security module. The system may allow a flexible modification of a base security policy such that new features or access profiles not anticipated at the time of ECU manufacture can be supported by the present approach. In addition, if a security flaw is discovered in the base security policy, the present approach may be used to modify the policy to reduce the risk of compromise.

The present approach does not necessarily require a set of role-based policies in each ECU. The present approach may enforce a policy at the VSM. Thus, the present approach may prevent a device at the OBD II port from injecting traffic on the controller area network CAN bus. Thus, non-diagnostic commands, like turning the steering wheel, unlocking doors, and so forth, may not necessarily be sent to a vehicle via the OBD II within the present scheme. The present system may filter messages which may be destined to be injected into a CAN bus.

FIG. 1 is a diagram of an on board diagnostics (OBD) computer arrangement for a vehicle. An interface or connector 11 may provide an input for diagnostic or control instrumentation, such as a dongle. Instrumentation 12 may be provide an input for control or programming of electronic control units (ECUs) 13, 14 and 15 on a high speed CAN bus 21, and ECUs 16, 17 and 18 on a medium speed CAN bus 22. Between the ECUs and interface 11 may be a VSM 19 that can restrict access to the ECUs' inputs and outputs. VSM 19 may incorporate a gateway that is integrated in the VSM electronics. What is permitted in terms of inputs and outputs to buses 21 and 22, and the respective ECUs 13-18, may be based on policy.

Vehicle manufacturers may need the ability to manage issues such as liability by limiting how a device or software application can modify the operation of a vehicle while at the same time meeting laws and owner expectations related to the right to repair and modify of the vehicle. The present system and approach may allow the vehicle manufacturer to manage vehicle safety/security policy and associated liability by controlling when and which portions of the policy are enforced. Thus, the vehicle manufacturer may be allowed to selectively modify the policy in the vehicle.

There may be many variations for securely distributing a policy change authorization token to the vehicle security module. One approach may incorporate a dongle pair. An example is given in the following. Key creation and loading of authorization token into dongle may occur. Public key material and a corresponding public key infrastructure may be created as shown in view of a diagram 60 in FIG. 2, the following items: 1) An original equipment manufacturer (OEM) 61 may create a public/private key pair at corner 62 of diagram 60; 2) A vehicle security module 63 may also create its own public/private key pair; OEM 61 may embed along line 64 the OEM public key into vehicle security module 63; 3) A policy change requestor (PCR) 65 may create a public/private key pair at a corner 66 at an end of a line 69 from corner 62 of diagram 60; 4) OEM 61 may use the OEM private key to digitally sign a certificate (e.g., X.509v3) containing a PCR 65 identity and a PCR public key; 5) Vehicle OEM 61 may create a policy change authorization token which includes the changes to the policy and a dongle ID of a set of dongles associated with this authorization token; the authorization token may be signed using the OEM private key; 6) A public/private key pair may be created for a dongle 67 at corner 68 of a line 70 from corner 66 of diagram 60; and 7) PCR 65 may use the PCR private key to sign a certificate for dongle 67 containing the dongle ID, and PCR 65 may also load a copy of the PCR certificate into dongle 67.

An authorization token use may be noted. When dongle 67 is plugged into a vehicle, there may be a protocol exchange along a line 71 between corners 68 and 72, which allows the vehicle security module 63 to confirm the identity of dongle 67, allows the vehicle security module 63 to confirm that the authorization token is bound to dongle 67, and allows the vehicle security module 63 to confirm that the authorization token was authorized by vehicle OEM 61.

There may be multiple ways that the above-noted three confirmations may be achieved. One approach may be primarily described in the following paragraphs.

1) A dongle and a vehicle may perform a Diffie Hellman key exchange using the dongle certificate to establish a shared secret between the dongle and a vehicle security module. This may be a cryptographic handshake protocol. Other variations of the key exchange, besides the Diffie Hellman exchange noted herein, may be used.

2) The dongle may send the vehicle security module an authorization token and an integrity check value. Both of these items may be cryptographically protected using a key derived from the Diffie Hellman exchange.

3) The vehicle security module may use the key derived from, for instance, the Diffie Hellman exchange to validate an integrity check value. If the check is valid, then the vehicle security module may know that the dongle has the same key derived from the Diffie Hellman exchange.

4) The vehicle security module may then “walk the chain” of public key certificates from the dongle to a common root of trust (i.e., an OEM private key in this example). Assuming that the checks produce an expected result, the vehicle security module may know that this dongle is the dongle it claims to be.

5) The vehicle security module may the use an OEM public key to validate a digital signature on an authorization token. Assuming the digital signature to be valid, the vehicle security module may know that the authorization token is authorized by the vehicle OEM.

6) At this point, the vehicle security module may know that the dongle ID from the dongle certificate, it may know the dongle is authentic because of a successful Diffie Hellman key exchange and it may know that the policy changes contained in the authorization token are valid and apply to the specified dongle ID. Thus, the vehicle security module may make changes in its policy.

Variations in the above-described process, which produce a similar, result may incorporate:

1) A cryptographic algorithm—the public key algorithm may be an RSA (a Rivest Shamir Adelman public key cryptography algorithm) or an elliptic curve.

2) A cryptographic key length—various public key pairs (OEM, dongle vendor, dongle, and so forth) may use different key lengths.

3) A certificate structure—the certificates may be X.509 v3 certificates or a proprietary format.

4) A PKI—the PKI (private key infrastructure) may be a simple structure in which the OEM serves as its own root of trust (also known as a root certificate authority). The system may use a larger and more complete PKI in which the root of trust is above the OEM. This type of structure may allow one dongle to be recognized by vehicle security modules associated with multiple OEMs.

5) A key establishment protocol—many different protocols may exist to establish secure communications between the dongle and the VSM.

6) An authorization token distribution—the authorization token may be distributed via the dongle such that the dongle is the transport mechanism. The authorization token may be embedded in the VSM firmware and activated when an authorized dongle authenticates itself to the VSM. The authorization token may be fetched in real time by either the VSM or the dongle.

7) An authorization token structure—the structure of the policy override may be virtually a complete replacement of the default VSM policy. Alternatively, the structure may simply identify changes to a default policy. A set of changes may be bundled as a single package containing one or more changes. Alternatively, the changes may be packaged as one change per token such that a dongle could have multiple tokens associated with it.

A feature of the present system and approach may be that the security and/or safety policy in the vehicle security module could be changed in the field using a cryptographically protected authorization token which is directly or indirectly associated with a dongle.

The vehicle security module may be shipped with a default security policy. The policy may specify the types of messages allowed to flow to and/or from the vehicle to a device plugged into an on board diagnostics II (OBD) port. An authorization token may specify changes to be applied to the policy when the device associated with the authorization token is plugged in.

There may be many ways of specifying a policy. One example of a policy, along with an authorization token changing the policy, may be provided in the following:

1) A default vehicle security module policy—block messages with a CAN bus ID=1, 2, 3, 4, 5;

2) An authorization token—allow messages with a CAN bus ID=3; and

3) A resulting policy—block messages with the CAN bus ID=1, 2, 4, 5.

Another example may be given where the incoming message ID should match allowed rules in order to pass. A set mask may be used to determine which bits of the message ID are compared to the filter. A “0” in the mask may mean that the corresponding bits of the message ID are not tested. The filter value may be matched against the incoming message ID and if the non-masked bits match, the message is allowed to pass.

Default vehicle security module policy may be schematically shown in table 81 in FIG. 3. An authorization token may be a rule 3, with a new mask 1FFFFF00. A resulting policy may be shown in table 82.

There may be many types of policies. Many vehicle manufacturers may use proprietary messages on the CAN bus so the policy is likely to be different for each vehicle manufacturer. Examples may incorporate safety and security.

For safety, one may assume that a message ID 5 with content 0000 0000 0000 1111 tells the brake system to vent pressure from the wheel cylinders. This may be done to bleed air out of the hydraulic brake system. A safety policy may block message ID=5, content 0000 0000 0000 1111 from being injected via the OBD port. This may prevent a compromised dongle from disabling the brakes on a vehicle. A tool certified by the OEM to be used by a service technician to bleed the brakes may have an authorization token which turns off this policy, thus allowing the service technician to bleed the brakes. If another device (e.g., a compromised insurance dongle) is plugged into the OBD port after the technician has serviced the vehicle, the safety policy may prevent the compromised dongle from issuing the bleed brakes command to the vehicle. The authorization token should be only in effect while the device linked to the authorization token is plugged into the OBD port.

For security, a keyless entry system on a vehicle may be able to send a CAN bus message to unlock the doors. However, a compromised dongle may also send an unlock command, allowing a thief into the vehicle. Therefore, a security policy in the vehicle security module may be to block “unlock door” messages sent into the vehicle via the OBD port.

The CAN bus does not necessarily perform source authentication of messages placed on the CAN bus. Thus, an attacker who is able to inject messages into the OBD port could send messages which appear to come from one of the electronic control units (ECUs) on the bus. Referring to the FIG. 1, if the vehicle security module is not present, the dongle may be able to place messages on the CAN bus which could be sent by ECU 13-15 or ECU 16-18. Thus, anything that the ECUs may do could be done by an attacker via the OBD. A few of the many things the attacker could do via the OBD port may be to flash headlights, unlock doors, turn air conditioning on/off, activate anti-lock brake functions, turn the front wheels (on a vehicle with automatic parking capability), change the speed shown on the speedometer, and so on.

Some types of policy changes that could be requested for a dongle or other OBD device may incorporate allowing a dongle to limit the speed of a vehicle, which might be used in fleet management applications, allowing the device to load new firmware on an ECU, allowing the dongle to read GPS coordinates of a vehicle so that the dongle can provide vehicle tracking, allowing a dongle to remotely start the engine of a vehicle, and allowing the device to send a command to change the emissions control setting on a vehicle.

An authorization token may take many forms depending upon the structure used for specifying policy within the vehicle security module. Data fields that may be typical in the authorization token could incorporate the following items.

1) Applicable vehicles—a device/dongle may be allowed to change the policy on vehicles produced, for example, since 2015. The device/dongle should only be licensed with the OEM to be used on certain models and therefore the authorization token may identify a set of licensed vehicles.

2) A policy/rule identifier—depending upon how the OEM manages policy/rules in the vehicle security module, the token may specify a number identifying the rule which is to be modified or turned off (e.g., turn off rule 3).

3) An allowable message ID list—many firewalls and vehicle security modules may operate using a “deny unless explicitly allowed” model. Thus, if the policy does not explicitly allow a message ID, then that message ID may be blocked. The allowable message ID field may specify additional IDs which are allowed to pass.

4) Specific message ID/value pairs—frequently there may be multiple parameters within a message. For example, one byte may control the throttle position while another byte in the same message may control the amount of fuel delivered. The default policy may allow a message “ID x” but only allow a specific set of parameters. For instance, it may only allow a byte specifying the amount of fuel to be between, for example, 10 and 100. However, the policy may allow an authorized device to change these parameter limits.

The present system and approach may allow the vehicle manufacturer to manage vehicle safety/security policy by controlling when and which portions of the policy are enforced. The system may consist of the following entities. The vehicle manufacturer may set the default safety and security policies for the vehicle. The vehicle manufacturer may also be able to selectively authorize “policy change requestors” (PRCs) to override a policy under specific circumstances. A vehicle may be any motorized cyber-physical system used for transportation. The term “vehicle” may incorporate automobiles, military vehicles, autonomous (self-driving) vehicles, water craft, and aircraft having manned and unmanned (e.g., drones) capabilities. A policy change requestor may be an entity requesting a change to the vehicle safety and/or security policy. The requestor could be the owner of a vehicle or a service technician requesting a change to one vehicle. For instance, the owner may be a “tuner” who wants to modify how the vehicle performs. The tuner may be a manufacturer of diagnostic equipment, a dongle provider, or a developer of a software application. An authorization token may directly or indirectly identify the changes which the policy change requestor is authorized to make to a specific vehicle or a class of vehicles. For example, a dongle provider may receive a token to make changes to particular model pick-up trucks model produced during certain years. A structure of the authorization token may depend on how the vehicle manufacturer has implemented the authorization and the structure of associated policies.

The present system and approach may allow a vehicle manufacturer to grant a policy change requestor an ability to make selective changes to the safety/security policy of one or more vehicles.

A diagram of FIG. 4 may illustrate selections of the system. The system may include a policy selection function 35 on the vehicle which incorporates a drive function or mode 38 and diagnostic function or mode 39. An authorization token 36 may be selected as with a token or without a token for drive function 38 and for diagnostic function 39 of the vehicle. Resulting policies 31, 32, 33 and 34 may be from selections of a drive or diagnostic mode and an authorization token. Policy 31 may involve a drive mode with changes contained in the authorization token. Policy 32 may involve the drive mode with no changes in view of being without the authorization token. Policy 33 may involve a diagnostic mode with changes contained in the authorization token. Policy 34 may involve the diagnostic mode with no changes in view of being without the authorization token.

The policy select function 35 on a vehicle may be implemented via a physical switch or another mechanism which is resistant to hacking or jamming. In one implementation, the vehicle may contain a physical vehicle security module (VSM) which enforces the security policy. The VSM may contain a physical switch which the driver or technician can place in either drive mode 38 or diagnostics mode 39. When in diagnostics mode 39, the VSM may emit a signal (e.g., beeping or flashing light) to warn a vehicle operator that the safety and/or security policy normally enforced when the vehicle is in drive mode has been bypassed.

The authorization token may be implemented in multiple ways. One implementation may make use of public key cryptography to create an authorization token which could be bound to a device or application (e.g., an insurance dongle) and which may be cryptographically verified by the vehicle. One such implementation may be illustrated in a diagram of FIG. 5. A vehicle manufacturer 41 may create a public/private key pair 45 using the techniques of asymmetric cryptography. Vehicle manufacturer 41 may place a public key 42 in each vehicle as indicated by an arrow 44. Vehicle manufacturer 41 may maintain control of the private key and protect it from compromise.

A developer of the policy change requestor 46 (could be hardware or software) and vehicle manufacturer 41 may agree on a set of authorized policy changes to be granted to policy change requestor 46 for specified vehicles as indicated by an arrow 47. An agreement may involve testing, legal agreements or other activities outside the scope of the present system. Vehicle manufacturer 41 may then use its private key to cryptographically sign an authorization token 51 bound along arrow 47 to policy change requestor 46. When policy change requestor 46 wants to modify the default policy on the vehicle, policy change requestor 46 and vehicle 43 may perform a cryptographic handshake to pass the authorization token 48 to vehicle 43 along arrow 49. Vehicle 43 may use public key 42 provided by vehicle manufacturer 41 to validate the authorization token. Once validated, the changes contained in the authorization token may be applied to the default policy to produce the resulting policy 52 to be enforced by vehicle 43.

There may be multiple ways to securely pass an authorization token to the vehicle. Some of the ways may be noted herein. One way is that the vehicle manufacturer may act as a certificate authority and sign a certificate (e.g., X.509 v3) for a developer of the policy change requester. This approach may allow the policy change requester to use a local private key to generate and sign authorization tokens. The vehicle may then use the vehicle manufacturer public key to “walk the certificate chain” to validate the authorization token.

Another way is that the vehicle manufacturer may create authorization tokens which combine an identity of the policy change requestor with the authorization token as an approach of binding the token to the requestor.

Still another way is that the vehicle manufacturer may distribute a new policy directly to the vehicle with a mechanism to identify policy change requestors which are authorized to invoke the policy.

Yet another way is that the automotive industry may adopt a full public key infrastructure (PKI) which would allow vehicles from many manufacturers to validate policy change requestor entities from multiple developers.

There may be additional ways in which a policy associated with a specific policy change requestor could be loaded into a vehicle security module. A feature of the present system is that the vehicle manufacturer may have a way to alter the vehicle safety/security policy based upon the knowledge of a policy change requestor being associated with the vehicle.

A vehicle manufacturer may require a manufacturer of a policy change requestor (e.g., a dongle or diagnostic test tool) to use a key storage mechanism to protect the integrity and/or confidentiality of the cryptographic material used within the system.

A policy change requester (e.g., a dongle device plugged into a vehicle's OBD port) should perform a cryptographic handshake with the vehicle to ensure that it is a genuine (authorized) requester and not an imposter. An example of an imposter may be a look alike dongle from an unauthorized source. This look alike device may not necessarily meet the safety or security requirements set by the vehicle manufacturer.

This would allow OEMs to control what devices get added to their vehicles in order to preserve safety and security. This is a feature of the present system that would differentiate the present system from the competition.

FIG. 6 is a diagram of a vehicle security module circuit board 85. The present vehicle security module hardware may be based upon a MicroZed™ Zynq module. A security policy may run on an ARM Cortex™ A9 MPCore. This chip may have two CPU cores so that security can run on either of these two CPU cores. A security policy file, which can be updated via the authorization token, may be stored in, for example, a 256 Kbyte on-chip memory. The present system and approach may use other CPUs or microcontrollers. In general, the security policy may be stored in a memory on or connected to a microcontroller. The policy may be enforced by software or firmware on the CPU which can read the policy from the memory and apply the policy.

As to some details, board 85 may contain a dual core Cortex-A9 800 MHZ processing system (PS) 86 and a programmable logic card (PL) 87. PS 86 may incorporate a double data rate (DDR) controller 91 connected to a 1 GB DDR RAM 92, a quad serial peripheral interface (QSPI) 93 connected to a 128 MB QSPI flash 94, a processing system (PS) controller area network (CAN) controller (#1) 95 connected to a CAN #1 physical (PHY) 96. A 10/100 Ethernet controller 97 connected to a 10/100 Ethernet PHY 98, a PS CAN controller, (#2) 99 connected to a CAN #2 PHY 100, and a secured digital (SD) 101 connected to a micro SD card 102.

PL card 87 may incorporate a PL CAN controller (#1) 103 connected to a CAN (#3) 104, a PL CAN controller (#4) 105 connected to a CAN #6 PHY 106, a PL CAN controller (#2) 107 connected to a CAN #4 PHY 108, a PL CAN controller (#5) connected to a CAN #7 PHY 110, a PL CAN controller (#3) connected to a CAN #5 PHY, and PL CAN controller (#6) 113 connected to a CAN #8 PHY 114.

FIG. 7 is a diagram of the interfaces to the vehicle security module. The diagram may reveal an interface to a VSM 115 having an enclosure 116 with a printed circuit board (PCB) stack 117. PCB stack 117 may incorporate an Ethernet (ETH) transceiver (Xcvr) 121 connected to an ETH RJ45 connector 122, a CAN Xcvr 123 connected to a high speed 1 (HS1) CAN 124, a CAN Xcvr 125 connected to an HS2 CAN 126, a CAN Xcvr 127 connected to an HS3 CAN 128, and a CAN Xcvr 129 connected to a medium speed 1 (MS1) CAN 130, a CAN Xcvr 131 connected to a diagnostic link connector (DLC) (aka OBD II), 132, a CAN Xcvr 133 connected to DLC 132 and to a high speed 1 auxiliary (HS1A) CAN 134, a CAN Xcvr 134 connected to a HS2A CAN 135, and a CAN Xcvr 136 connected to a medium speed 1 auxiliary (MS1A) CAN 137. HS1A CAN 134, HS2A CAN 135, and MS1A CAN 137 may be connected to an accessory protocol interface module (APIM) 138. A 12 VDC power source 139 may be connected and used to power components of the PCB stack 117.

FIG. 8 is a diagram of an example an OBD architecture 145 such as for a Lincoln MKZ vehicle by Ford Motor Co., modified to incorporate a vehicle security module. The following description is an example of CAN busses and ECUs. There may be various other architecture designs. An HS2A 147, HS1A 148, MS1A 150 and HS3A 151 may be connected to a VSM and a gateway module (GWM) 146. A DLC 152 may be connected to HS2A 147 and HS1A 148. An APIM 153 may be connected to HS1A 148, MS1A 150 and HS3A 151. VSM and GWM 146 may be connected to HS1155, MS1156, HS3157, and HS2158. HS1, HS2, HS3, MS1, HS1A, HS2A, HS3A and MS1A refer to CAN busses.

Various modules may be connected to the busses. Some of the modules connected to HS1155 may be a PCM (powertrain control module) 161, BCM (battery control module-accessories) 162, PAM (parking aid module) 163 and HCM (headlamp control module) 164.

Some of the modules connected to MS1 may be a TRM (transmission range module) 165, RTM 166, SOD-L (side object detection-left module) 167, SOD-R (side object detection-right module) 168, DDM (driver's door module) 169, DSM (driver's seat module) 170, GPSM (global positioning system module) 171, FCIM (front controls interface module) 172, PDM 173, RGTM 174, HSWM (heated steering wheel module) 175 and SCME 176.

Some of the modules connected to HS3 may be TCU (transmission control unit) 177, ACM (audio control module) 178, ANC (auxiliary heater control) 179, DSP (digital signal processing module) 180, and IPC (instruments panel control) 181.

Some of the modules connected to HS2 may be RCM (restraint control module) 182, ABS (anti-lock brake system) 183, VDM (vehicle dynamics module) 184, HUD (heads up display) 185, PSCM (power steering control module) 186, GSM 187, IPM-A (instrument panel module-accessories) 188, TRCM 189, and SCCM (steering column control module) 190.

The ECUs of architecture 145 may be other than indicated. Some of the acronyms may designate other items than those mentioned, depending on, for instance, the model and year of the vehicle.

FIG. 9 is a diagram of an example of VSM circuitry 200 that may be incorporated in the present system. The diagram is divided into portions 201-209 that are enlarged in FIGS. 10a-10i, respectively. FIG. 10a is a diagram of portion 201 that has an MCU board 211 which may be, for example, a MicroZed™ SCM. An SCM of another source may utilized as the MCU board 211. Connections of portion 201 with portion 202 in FIG. 10b may be indicated by lines 215, 216, 217, 218, 219 and 220. Portions 203-205 may incorporate CAN transceivers connected to MCU board 211 and to output circuitry, respectively. Connections of portion 201 with portion 203 in FIG. 10c may be indicated by lines 221, 222, 223, 224, 225, 226, 227, 228, 229, 230, 231, 232, 233, 234, 235, 236 and 237. Connections of portion 203 of FIG. 10c with portion 204 in FIG. 10d may be indicated by lines 228, 229, 230, 231, 232, 233, 234, 235, 236, 237, 238, 239 and 240. Connections of portion 204 of FIG. 10d with portion 205 in FIG. 10e may be indicated by lines 234, 235, 236, 237, 238, 239 and 240.

Connections of portion 203 in FIG. 10c with portion 206 in FIG. 10f may be indicated by lines 241, 242, 243, 244, 245 and 246. Connections of portion 204 in FIG. 10d with portion 207 in FIG. 10g may be indicated by lines 247, 248, 249250, 251 and 252. Connections of portion 205 in FIG. 10e with portion 208 in FIG. 10h may be indicated by lines 253, 254, 255 and 256.

FIG. 10i is a diagram of a filter circuit 209 for power to VSM circuitry 200. FIG. 10j is a diagram of an example of a cable for each of the outputs of the circuits in portions 205-208.

To recap, a vehicle security system may incorporate one or more controller area network (CAN) buses, one or more electronic control units (ECUs) connected to the one or more CAN buses, a vehicle security module (VSM) connected to the one or more CAN buses, and an on board diagnostics (OBD) connector connected to the vehicle security module. The vehicle security module may discriminate between authorized and unauthorized signals that are input to the on board diagnostics connector. Authorized signals may be forwarded by the vehicle security module to the one or more CAN busses. The unauthorized signals may be refused entry to the one or more CAN busses.

The on board diagnostics connector may be connected to one or more devices selected from a group comprising diagnostic instrumentation, control instrumentation, and tracking instrumentation.

An OEM of the vehicle security module may create a public and private key pair. The vehicle security module may create a public and private key pair. The OEM may embed the OEM public key into the vehicle security module. A policy change requestor (PRC) may create a public and private key pair. The OEM may uses its private key to digitally sign a certificate containing an identity of the policy change requestor and the public key of the policy change requestor. The OEM may create a policy change authorization token to include changes to a security policy and an identification (ID) of one or more dongles associated with the authorization token. The authorization may be signed with the private key of the OEM. A public key and a private key may be created for the one or more dongles having the ID. The policy change requestor may use its private key to sign a certificate for the one or more dongles having the ID. The policy change requestor may load a copy of the certificate into the one or more dongles.

When a dongle of the one or more dongles is connected to the on board diagnostics connector, the vehicle security module may achieve a confirmation of the ID of the dongle, a confirmation that the authorization token is bound to the dongle, and a confirmation that the authorization token was authorized by the OEM.

A security or safety policy in the vehicle security module may be changed in a field using a cryptographically protected authorization token that is directly or indirectly associated with the dongle.

The vehicle security module may have a security policy. The security policy may specify the messages allowed to flow to or from the vehicle security module to a device connected to the on board diagnostics connector.

The authorization token may specify one or more changes to be applied to the security policy when the one or more dongles associated with the authorization token are connected to the on board diagnostics connector.

A security policy may block or allow one or more messages based upon virtually any characteristic of a message. A change of security policy may change any characteristic of a message used to block or allow the message.

An approach for authorizing a policy change in a vehicle security module, may incorporate plugging a device selected from a group comprising diagnostic instrumentation, control instrumentation, tracking instrumentation, and dongles, into an on board diagnostics connector connected to a vehicle security module that is in turn connected to one or more controller area network (CAN) buses. The one or more CAN buses may be connected to one or more electronic control units (ECUs). The vehicle security module may block unauthorized signals and allow authorized signals to the CAN buses. Allowing authorized signals to the CAN buses may result in a policy change in the vehicle security module.

The vehicle security module may have a policy for determining which signals are authorized and which signals are unauthorized. The one or more ECUs may be connected to components of a vehicle. Authorized signals may affect operation of one or more of the components of the vehicle. Authorized signals may change the policy of the vehicle security module. A manufacturer of the vehicle may be permitted to manage the policy of the vehicle security module.

The manufacturer may set a default version of the policy of the vehicle security module. The manufacturer may selectively authorize policy change requestors to override one or more aspects of the policy of the vehicle security module.

The manufacturer may provide an authorization token that identifies changes that a policy change requestor is permitted to make to a vehicle having the vehicle security module.

A policy select function may be implemented by a switch to select a drive mode or a diagnostics mode for the vehicle security module. A resulting policy of a drive mode with the authorization token may be the drive mode with changes of the policy contained in the authorization token. The resulting policy of a drive mode without the authorization token may be the drive mode absent changes. The resulting policy of a diagnostic mode with the authorization token may be the diagnostic mode with changes of the policy contained in the authorization token. The resulting policy of a diagnostic mode without the authorization token may be the diagnostic mode absent changes.

The authorization token may be implemented in a cryptographic manner.

When the vehicle security module is in the diagnostics mode, the vehicle security module may emit a signal of an audible or visible nature to inform anyone in a vicinity of the vehicle that the policy of the vehicle security module, which is enforced while the vehicle is in the drive mode, is bypassed.

A policy change requestor may perform a cryptographic handshake with the vehicle to ensure that the policy change request is authorized.

A mechanism for providing authorized changes of policy to the vehicle security module, may incorporate a vehicle security module, an on board diagnostics port connected to the vehicle security module, one or more controller area network (CAN) buses connected to the vehicle security module, and one or more electronic control units (ECUs) connected to the one or more CAN buses. The one or more ECUs may be associated with one or more components, respectively, of a vehicle.

An association with the one or more components may incorporate one or more items of a group consisting of functions, settings, control and diagnostics of the one or more components.

The mechanism may further incorporate a dongle plugged into the on board diagnostics port. The dongle may incorporate a loaded authorization token. The authorization token may authorize a change of policy of the vehicle security module.

The authorization token may allow the vehicle security module to confirm one or more items of a group incorporating an identity of the dongle, the authorization token being bound to the dongle, and the authorization token being validated by a manufacturer of the vehicle. The policy in the vehicle security module may be changed in the field by using the authorization token that is cryptographically protected.

Any publication or patent document noted herein is hereby incorporated by reference to the same extent as if each publication or patent document was specifically and individually indicated to be incorporated by reference.

In the present specification, some of the matter may be of a hypothetical or prophetic nature although stated in another manner or tense.

Although the present system and/or approach has been described with respect to at least one illustrative example, many variations and modifications will become apparent to those skilled in the art upon reading the specification. It is therefore the intention that the appended claims be interpreted as broadly as possible in view of the related art to include all such variations and modifications.

Claims

1. A vehicle security system for a vehicle, the system comprising: one or more controller area network (CAN) buses;one or more electronic control units (ECUs) connected to the one or more CAN buses;a vehicle security module (VSM) connected to the one or more CAN buses; andan on board diagnostics (OBD) connector connected to the vehicle security module; andwherein:the vehicle security module discriminates between authorized and unauthorized signals that are input to the on board diagnostics connector; andthe VSM has a security policy;the security policy specifies the types of messages that are allowed to flow to and/or from the vehicle to a device plugged into the OBD connector;the VSM is configured to verify a token in the device plugged into the OBD connector and modify the security policy according to a change specified in the verified token to allow the VSM to classify a signal as an authorized signal when the VSM would otherwise classify the signal as an unauthorized signal and facilitate performing a service on the vehicle that would not otherwise be permitted by the security policy;authorized signals are forwarded by the vehicle security module to the one or more CAN busses; andthe unauthorized signals are refused entry to the one or more CAN busses.

2. The system of claim 1, wherein the device to which the on board diagnostics connector is configured to receive is one or more devices selected from a group comprising diagnostic instrumentation, control instrumentation, and tracking instrumentation.

3. The system of claim 1, wherein: an original equipment manufacturer (OEM) of the vehicle security module creates a public and private key pair;the vehicle security module creates a public and private key pair;the OEM embeds the OEM public key into the vehicle security module;a policy change requestor (PRC) creates a public and private key pair;the OEM uses its private key to digitally sign a certificate containing an identity of the policy change requestor and the public key of the policy change requestor;the OEM creates a policy change authorization token to include changes to a security policy and an identification (ID) of one or more dongles associated with the authorization token;the authorization is signed with the private key of the OEM; anda public key and a private key are created for the one or more dongles having the ID;the policy change requestor uses its private key to sign a certificate for the one or more dongles having the ID; andthe policy change requestor loads a copy of the certificate into the one or more dongles.

4. The system of claim 3, wherein when a dongle of the one or more dongles is plugged into to the on board diagnostics connector, the vehicle security module can achieve a confirmation of the ID of the dongle, a confirmation that the authorization token is bound to the dongle, and a confirmation that the authorization token was authorized by the OEM.

5. The system of claim 4, wherein the security policy in the vehicle security module can be changed in a field using a cryptographically protected authorization token that is directly or indirectly associated with the dongle.

6. The system of claim 3, wherein the authorization token specifies one or more changes to be applied to the security policy when the one or more dongles associated with the authorization token are plugged into to the on board diagnostics connector.

7. The system of claim 6, wherein: the security policy can block or allow one or more messages based upon virtually any characteristic of a message; anda change of security policy can change any characteristic of a message used to block or allow the message.

8. A method for authorizing a policy change in a vehicle security module, comprising: plugging a device selected from a group comprising diagnostic instrumentation, control instrumentation, tracking instrumentation, and dongles, into an on board diagnostics connector connected to a vehicle security module that is in turn connected to one or more controller area network (CAN) buses, the vehicle security module having a default security policy that specifies the types of messages that are allowed to flow to and/or from the vehicle to the device plugged into the onboard diagnostics connector;verifying an authentication token in the device plugged into the on board diagnostics connector;modifying the default security policy of the vehicle security module according to a change specified in the verified authentication token; andclassifying a signal as authorized under the modified security policy that would otherwise be classified as unauthorized under the default security policy to facilitate performing a service on the vehicle that would not otherwise be permitted by the default security policy; andwherein:the one or more CAN buses are connected to one or more electronic control units (ECUs);the vehicle security module blocks unauthorized signals and allows authorized signals to the CAN buses.

9. The method of claim 8, wherein: the one or more ECUs are connected to components of a vehicle;authorized signals can affect operation of one or more of the components of the vehicle;authorized signals can change the policy of the vehicle security module; anda manufacturer of the vehicle is permitted to manage the policy of the vehicle security module.

10. The method of claim 9, wherein: the manufacturer sets a default version of the policy of the vehicle security module; andthe manufacturer can selectively authorize policy change requestors to override one or more aspects of the policy of the vehicle security module.

11. The method of claim 9, wherein the manufacturer provides the authorization token that identifies changes that a policy change requestor is permitted to make to a vehicle having the vehicle security module.

12. The method of claim 11, wherein: a policy select function is implemented by a switch to select a drive mode or a diagnostics mode for the vehicle security module;a resulting policy of a drive mode with the authorization token is the drive mode with changes of the policy contained in the authorization token;the resulting policy of a drive mode without the authorization token is the drive mode absent changes;the resulting policy of a diagnostic mode with the authorization token is the diagnostic mode with changes of the policy contained in the authorization token; andthe resulting policy of a diagnostic mode without the authorization token is the diagnostic mode absent changes.

13. The method of claim 12, wherein the authorization token is implemented in a cryptographic manner.

14. The method of claim 12, wherein when the vehicle security module is in the diagnostics mode, the vehicle security module emits a signal of an audible or visible nature to inform anyone in a vicinity of the vehicle that the policy of the vehicle security module, which is enforced while the vehicle is in the drive mode, is bypassed.

15. The method of claim 10, wherein a policy change requestor performs a cryptographic handshake with the vehicle to ensure that the policy change request is authorized.

16. A mechanism for providing authorized changes of policy to the vehicle security module, comprising: a vehicle security module having a security policy;an on board diagnostics port connected to the vehicle security module;one or more controller area network (CAN) buses connected to the vehicle security module; andone or more electronic control units (ECUs) connected to the one or more CAN buses; andwherein: the one or more ECUs are associated with one or more components, respectively, of a vehicle;the security policy specifies the types of messages that are allowed to flow to and/or from a vehicle to a device plugged into the on board diagnostics port;the vehicle security module verifies an authorization token in the device plugged into the on board diagnostics port and modifies the security policy according to a change specified in the verified authorization token to allow the vehicle security module to classify a signal as an authorized signal when the vehicle security module would otherwise classify the signal as an unauthorized signal and facilitate performing a service on the vehicle that would not otherwise be permitted by the security policy;the vehicle security module is configured to forward authorized signals to the one or more CAN buses and refuse entry to the one or more CAN buses to the unauthorized signals.

17. The mechanism of claim 16, wherein an association with the one or more components comprises one or more items of a group consisting of functions, settings, control and diagnostics of the one or more components.

18. The mechanism of claim 17, further comprising: a dongle plugged into the on board diagnostics port; andwherein:the dongle comprises a loaded authorization token; andthe authorization token authorizes a change of policy of the vehicle security module.

19. The mechanism of claim 18, wherein: the authorization token allows the vehicle security module to confirm one or more items of a group comprising an identity of the dongle, the authorization token being bound to the dongle, and the authorization token being validated by a manufacturer of the vehicle; andthe policy in the vehicle security module can be changed in the field by using the authorization token that is cryptographically protected.