Printer Friendly

A Balanced Approach for Securing the OBD-II Port.

1. INTRODUCTION

Motivation

There is a real and growing threat to automotive cyber security and, in turn, safety. In particular, the OBD-II port has become a greater risk [19]. The number of vehicles with brakes, steering and acceleration influenced by messages on the CAN bus is increasing due to self-parking, ADAS and the move toward autonomous driving. The OBD-II port has transitioned from a physical port only accessible from inside the cabin of the vehicle to one that is wirelessly accessible via cellular modems, Bluetooth and Wi-Fi dongles [9, 1]. There is evidence that interest in the cyber security of vehicles is migrating from white hat researchers to hackers with hostile intent. Taken together, these facts call for taking a fresh look at the OBD-II port and identifying an up-to-date approach for protecting vehicle security and safety.

Related Work

There has been a growing list of researchers who have demonstrated that gaining access to the CAN bus via the OBD-II port can allow a hacker to influence control of a vehicle [8]. Those researchers who have used wireless access via an OBD-II device to compromise a vehicle [12, 3] are of particular interest.

Prior Society of Automotive Engineers (SAE) standards work in the form of SAE J2186 - E/E Data Link Security [14] addressed access to ECUs via the Data Link Connector (DLC). (Throughout this document "OBD" is used as a shorthand for OBD-II and the DLC.)

In some sense, J2186 may have been ahead of its time because when it was revised in 2005 the threat environment and motivation to secure vehicles was very different from today. The OBD-related threat has recently gained the attention of Congress which in a Sep 12, 2016 letter to NHTSA [13] wrote "... stakeholders cited the ports and the direct connection they provide to the vehicle internal networks as one of the fundamental sources of cyber security risk in the modern vehicle ecosystem."

Within the broader cyber security community there has been a great deal of work done on cryptographic protocols [11], public key cryptography [16], public key infrastructure and role based access control [17, 10, and 2]. These techniques and lessons learned can accelerate efforts to protect vehicles from attacks through the OBD port.

The remainder of this paper is organized as follows:

2. Brief history of vehicle network technologies, providing background on how we got here.

3. Requirements, informally summarizes the cyber security challenges this paper is addressing. There are many other cyber security items to address beyond the limited scope of this paper.

4. Technical approach, provides one technical approach for meeting the needs of various stakeholders in a manner which is scalable, cost effective and secure.

5. Operation, outlines how the technical approach would impact device certification and use.

6. Design considerations, discusses certification, implementation cost and technology options.

7. Summary/Conclusions, touches upon standardization of the OBD security concept and application to the telematics control unit (TCU).

2. BRIEF HISTORY OF VEHICLE NETWORK TECHNOLOGIES

CAN Bus

What was the original environment for the CAN bus? Historically the CAN bus was an island. An air-gapped network contained within the sheet metal envelope of the vehicle. Everything on the network was integrated by the OEM and trusted to preserve the cyber security of the vehicle. Anyone attempting to send CAN bus messages on the bus was assumed to be inside the vehicle and therefore trusted.

This level of trust and openness on the CAN bus was reasonable back in the day when brakes, steering and transmission were controlled by physical linkages, not a network. Today the lack of source authentication on the CAN bus is a security and safety issue.

OBD

What was the original purpose of the data link connector and OBD? It was designed to allow repair shops to connect with engine controls to perform diagnostics and gather emissions related information. Few envisioned the OBD port as a means of remotely injecting commands which could affect brakes, steering or acceleration. When J1979 was first issued in 1991, who imagined an insecure cellular modem connected to the vehicle OBD port controlling vehicle operation?

This paper and SAE J2186 both address aspects of OBD security. However, SAE J2186 was focused on protecting the integrity of a single Electronic Control Unit (ECU). i.e. J2186 could be used to prevent a device from changing firmware or calibration parameters within a specific ECU unless the device at the OBD port could authenticate to the ECU as a device authorized to make changes to that ECU. While this proposal can also prevent an OBD connected device from making changes to an ECU it can also prevent the OBD connected device from injecting CAN messages which trigger ECU actions. e.g., a message injected via the OBD triggers an ECU to unlock the doors.

The CAN bus does not perform source authentication of messages placed on the CAN bus. Thus, an attacker who is able to inject messages into the OBD port can send messages which appear to come from one of the ECUs on the bus. Referring to Figure 1, if the OBD security module was not present, the OBD connected device would be able to place messages on the CAN bus which would normally be sent by ECU_1.x or ECU_2.x. Thus, anything these ECUs would normally do could be done by an attacker via the OBD. A few of the many things the attacker could do via the OBD port include:

* Flash the headlights

* Unlock the doors

* Turn the air conditioning on/off

* Activate anti-lock brake functions

* Turn the front wheels (on vehicle with automatic parking capability)

* Change the speed shown on the speedometer

Some of these actions may be categorized as nuisance aimed at distracting the driver. Other actions directly affect vehicle operation taking control away from the driver or interfering with driver actions. Either can result in a safety incident.

OBD Devices

The OBD-II port is a source of data that can be used and manipulated for insurance tracking, monitoring vehicle performance and other "diagnostic" functions. Low cost (less than $20) wireless OBD devices are commercially available [1]. These can provide access via cellular, Wi-Fi or Bluetooth. The security of these devices is questionable. The web description for one model makes the claim

Easy to Use: Plug the device in your car's OBD2 port, turn on your car, enable Bluetooth on your Android phone or tablet, search for "OBDII" and pair with it (pin 1234), run the download App with simple settings and wait until it connects your car's ECU successfully

The hackers now know the pairing code for all devices of this model. What other security flaws could be lurking in these devices?

Hacking Culture

The world of hacking has also changed over the last 20 years. We have witnessed a progression from hacking a PC via a virus on floppy disc to hacking a website to get bragging rights and more recently hacking of industrial control systems. The Stuxnet attack on an industrial control system [7] was a wake-up call: hacking could remotely damage or destroy physical systems. This, of course, has been followed by multiple demonstration hacks of vehicles as well as research addressing vehicle security [18]. What is more concerning is the change in who is doing the hacking and their motivation. Years ago, bored college students hacked to show their skills. Today organized crime hacks for money. Ransomware attacks on home PCs and even businesses are common. When will we see ransomware against vehicles?

3. REQUIREMENTS

The OBD environment has been examined to identify security requirements necessary to protect vehicle safety. It is obvious that a one-size-fits-all access control policy is not appropriate. The requirements to secure the OBD port and associated components are outlined below:

* Support diagnostics. The OEM is required by law to provide an OBD-II port to support diagnostics. Independent repair shops and vehicle owners have a right to repair which includes access to many vehicle functions via the OBD-II. Some "secured Functions" are unlocked per SAE J2186 but many functions are not locked.

* Provide third parties (e.g. insurance companies) read access to vehicle data such as Vehicle Identification Number (VIN), speed and braking via OBD.

* Enable OBD device providers the ability to offer vehicle-related services via the OBD port. The industry must balance access with vehicle security and safety concerns.

* Provide the vehicle owner the ability to use mobile apps (Torque, Dash, OBD Auto Doctor, etc.) to retrieve information from their vehicle.

* Deliver vehicles which are safe. The safety of modern automobiles requires that they have cyber security to protect them from malicious commands/data injected via the OBD port. This implies these derived requirements.

** Provide a means to test and certify the CAN messages injected by an OBD connected device (e.g., Insurance dongle, diagnostic tool).

** Provide a means to authenticate a device plugged into an OBD port. i.e., determine the manufacturer of the device and the model number.

** Determine and enforce the OEM approved access rights for the authenticated device relative to the OBD port. e.g., the device can read all data but only write to the body control modules.

4. TECHNICAL APPROACH

This section provides an introduction to the technologies which can be used to solve the OBD security issue. It introduces key technologies and outlines the system.

Defensive Technologies

Fortunately, there are defensive technologies which can be employed to enhance security. Public key cryptography and access control mechanisms could be combined to provide an authenticated access control function for the OBD port.

Public Key

Public key (aka asymmetric key) cryptography [16] technology in the form of RSA and elliptic curve makes it possible to provide digital signatures and create public key infrastructure tailored to the needs of protecting vehicles. This is a mature technology already in use in other industries.

Public key cryptography uses two keys which are mathematically-related. The private key must be protected from unauthorized access. It is typically stored in some form of protected hardware and only accessed by the cryptographic engine within the hardware. Thus, the private key is used by the cryptographic engine to sign and encrypt/decrypt data but the key cannot be extracted from the cryptographic engine. The corresponding public key may be freely distributed. It does not require any confidentiality protection. The approach described in this paper makes use of two cryptographic functions.

A digital signature is an operation in which the creator digitally signs a piece of data by using the private key. The signature is a string of bits which practically speaking, could only be created by the entity holding the private key. Anyone holding the corresponding public key is then able to use that public key to perform a cryptographic operation and confirm that the piece of data in question was indeed signed by the entity holding the private key. As an example, if an OEM wanted to sign a firmware file such that any vehicle could verify that the firmware came from the OEM, the OEM would:

1. Create the file containing the firmware.

2. Compute a hash function over the firmware

3. Use the OEM private key to encrypt the hash result, thus creating a digital signature.

4. Send the original firmware file and the encrypted hash result together to any device which is to use the firmware.

The receiving entity, which has obtained the OEM public key through a trusted channel (e.g. loaded into the vehicle at the time of manufacture) then performs the following:

1. Compute the hash function over the firmware

2. Use the OEM public key to decrypt the encrypted hash result distributed with the firmware file.

3. Compare the locally computed hash result to the result of the decrypted hash from step 2.

If the decrypted hash and locally computed hash match, then the vehicle knows the firmware came from the OEM. If the decrypted hash does not match the locally computed hash then the vehicle rejects the firmware file. In the context of the OBD security solution being described here the "firmware file" would be security policy data which the OBD security module will apply to messages from the device connected to the OBD port. More on this later.

The second function of the public key cryptography is to perform a key exchange between the OBD security module and the device connected to the OBD port. The purpose of the key exchange is to authenticate the OBD device to the OBD security module and establish a secure session for exchanging data between them. A similar type of key exchange is typically performed when your web browser connects to your bank website. The public and private keys contained within the OBD device are used as follows.

The OBD device (e.g. a diagnostic tool) passes its public key to the OBD security module. This exchange uses an X.509 certificate [5] structure. This structure provides fields which may be used to carry data identifying the OBD device type (e.g. Acme Tool Company, OBD scanner, model 100). The X.509 certificate, when combined with a successful key exchange;

* Proves to the vehicle that the vehicle is connected to a device certified by the OEM.

* Authenticates the identity of the OBD device

* Binds the OBD device to the access rights assigned by the OEM.

The key exchange (aka key agreement) is illustrated in Figure 2 and is performed as follows.

1. The OBD device sends the OBD security module within the vehicle the OBD device X.509 certificate and the X.509 certificate for the device manufacturer. This device manufacturer X.509 certificate has been signed by the OEM using the OEM private key. (Certification is addressed below in the subsection - Certification process.)

2. The OBD security module verifies the digital signature on the X.509 certificate confirming it was issued (perhaps indirectly) by the OEM. The OBD security module "walks the certificate chain" to establish trust. First, the OBD security module uses the OEM public key (embedded in the security module when the vehicle was manufactured) to verify the digital signature on the manufacturer X.509 certificate. The OBD security module then extracts the manufacturer public key from the freshly verified certificate. The OBD security module repeats the certificate verification process, this time using the device manufacture's public key to verify the certificate bound to the OBD device. The vehicle OBD security module then extracts the OBD device public key from the freshly verified OBD device X.509 certificate.

3. The OBD security module generates a random number which will be used as a key for a symmetric cryptographic algorithm (e.g. Advanced Encryption Standard (AES)). The OBD security module protects the confidentiality of this random number.

4. The OBD security module uses the public key of the OBD device to encrypt the random number. Public key cryptography ensures that only the OBD device holding the private key corresponding to the public key extracted from the X.509 certificate can decrypt the message and recover the original random number. The message containing the encrypted random number is then sent across the OBD port to the OBD device.

5. The OBD device uses its private key to decrypt the random number and recover the original plaintext version of the random number. Now the OBD security module and the OBD device both have the shared secret random number. No other entity has this number because only the OBD device with the right private key can perform the decryption.

6. The OBD security module and OBD device use the shared secret in a key derivation process to create the shared symmetric key which will be used to encrypt and authenticate messages sent across the OBD port.

Successful authentication of the OBD device allows the OBD security module to apply the access control specified by the OEM.

Role-Based Access Control

The OBD security module is responsible for enforcing an access control policy on traffic flowing through the OBD port. The policy may restrict the type of messages (if any) the OBD device is authorized to send into the vehicle. The policy could also restrict CAN messages which are allowed to flow from the vehicle to the OBD device.

A typical vehicle may have 50 - 100 ECUs capable of sending thousands of types of CAN messages. The OEM could create the access control policy for each OBD device by stepping through the entire list of messages and selecting the access rights for each message type individually.

* Null: The device is not able to read or write the message type.

* Read only: The device is able to read (listen for) the message type but not write the message type.

* Write: The device is allowed to write messages into the vehicle. Typically writes would be restricted to a white list specifying the list of arbitration IDs and associated message content e.g. In case of ISO 15765 diagnostic messages, the white list of allowed service identifiers (SIDs) and parameter identifiers (PIDs) needs to be specified in the access control list.

This specification of the access policy becomes a burdensome task when it is repeated for each make, model and year for each OBD device type manufactured by an OBD device vendor. Role based access control (RBAC) allows the OEM to create a structured model for assigning access rights. This technique has been applied to industrial control systems controlling plants with thousands of control points [2]. A similar model will be used to allow OEMs to efficiently assign access rights to an OBD device based upon the role associated with the device (e.g. insurance tracking vs. diagnostic tool).

System Level Entities

The entities within the proposed system include:

* OBD security module: This module sits between the OBD port and the vehicle CAN bus as shown in Figure 1 and enforces security. It could be embedded into the OBD port, it could be an inline module between the OBD and CAN bus or it could be implemented within a gateway device if the vehicle uses a gateway to bridge CAN busses. The OBD security module authenticates the OBD connected device then applies the corresponding security policy as specified by the OEM.

* OEMs: The OEMs are responsible for establishing policies to be enforced by the OBD security module. The OEM provides a process by which ODB device manufacturers may request security policies for their devices. The OEM also serves as the public key Certification Authority (CA) for the vehicles it manufacturers. The OEM holds the private key and loads the corresponding public key into each OBD security module. The OEM uses its private key to digitally sign certificates for OBD device manufacturers.

* OBD device manufacturers: The manufactures receive an X.509 certificate from the OEM and act as a certification authority for the devices they produce. They also produce a private/public key pair for each device manufactured. They use their private key to sign certificates which are bound to their product. These certificates contain the public key of the manufactured device as well as the security policy the OEM approved for the product.

* OBD device and certificate: The device which will plug into the OBD port contains a public/private key pair unique to that device. The public key is also contained in the device certificate signed by the device manufacturer. The device uses trusted storage (e.g. a secure microcontroller) to protect its private key.

* Policy change authorization token: The OEM creates a token and digitally signs it. This token flows from the OEM, to the OBD device manufacturer, into an OBD device and finally into the OBD security module. The OBD security module is able to verify the digital signature applied by the OEM.

These entities work together during the certification process and operation as described below.

Certification Process

The OEM controls the certification process for OBD devices which will interact with the OEM's vehicles. The method the OEM uses to certify a manufacturer and their devices is outside the scope of this paper. It is expected to include a statement by the manufacturer regarding the access rights their device needs in order to perform its intended function. The OEM would typically perform a risk assessment which takes into account the level of confidence placed in the OBD device and the potential for introducing a security or safety risk to the vehicle. At the end of the risk analysis the OEM and OBD device manufacturer agree upon the security policy the vehicle will apply to the device. The remainder of this subsection describes the process for binding the OEM specified security policy to the OBD device.

The public key material and a corresponding public key infrastructure to allow the vehicle to verify the OEM specified security policy to be applied to an OBD device is outlined below and shown in Figure 3.

1. The OEM creates a public/private key pair. The private key is protected in a hardware security module and backed up by the OEM.

2. The OBD device manufacturer creates a public/private key pair and sends the public key to the OEM along with the manufacturer identification data using a certificate signing request protocol (e.g., Certificate Management Protocol (CMP) [6]).

3. The OEM uses the OEM certification authority private key to digitally sign a certificate (e.g. X.509v3) containing the OBD device manufacturer identity and public key.

4. The OEM creates a policy change authorization token which includes the changes to the policy and the manufacturer, make and model of the set of devices associated with this authorization token. The authorization token is signed using the OEM private key and sent to the OBD device manufacturer.

5. A public/private key pair are created for the OBD device.

6. The OBD device manufacturer uses the OBD device manufacturer private key to sign a certificate for the OBD device containing the device identification data (manufacturer, make and model) and the device public key. The OBD device manufacturer also loads a copy of the OBD device manufacturer certificate into the OBD device.

At the end of the process above the OBD device contains

* Device manufacturer certificate - Signed by the OEM

* Device certificate - Signed by the device manufacturer

* Policy change authorization token specific to the OBD device type (manufacturer, model) - signed by the OEM

During the vehicle manufacturing process the OEM loads the OEM public key into the OBD security module.

Sample Policies

The sample policies below illustrate the application of security policy within the OBD security module to enhance vehicle security and safety.

* Safety: Assume that CAN message ID 5 with content 0000 0000 0000 1111 tells the brake system to vent pressure from the wheel cylinders. This is typically done to bleed air out of the hydraulic brake system. The OBD security module default safety policy would block message ID = 5, content 0000 0000 0000 1111 from being injected via the OBD port. (The policy would likely block a broad set of messages.) This would prevent a compromised OBD device (e.g. insurance dongle with a modem) from disabling the brakes on a vehicle [12]. A tool certified by the OEM to be used by a service technician to bleed the brakes would 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) was plugged into the OBD port after the technician serviced the vehicle, the safety policy would prevent the compromised dongle from issuing the bleed brakes command to the vehicle. The authorization token is only in effect while the device linked to the authorization token is plugged into the OBD port and using the randomly generated cryptographic key from the OBD security module.

* Security: The keyless entry system on a vehicle is able to send a CAN bus message to unlock the doors. However, a compromised OBD device could also send an unlock command, allowing a thief into the vehicle. Therefore, a security policy in the vehicle security module would be to block "unlock door" messages sent into the vehicle via the OBD port unless the OBD device has provided a policy change authorization token signed by the OEM.

One can imagine many more threats and policies which would block those threats. In general, the OBD security module policy should be to block messages from the OBD device unless the device has a policy change authorization token opening up the policy. A few of the many types of policy changes which could be requested for an OBD device include:

* Allow the device to limit the speed of a vehicle. This may be used in fleet management applications.

* Allow the device to load new firmware on an ECU.

* Allow the device to read the GPS coordinates of a vehicle so the OBD device can provide vehicle tracking

* Allow a device to remotely start the engine of a vehicle

* Allow the device to send a command to change the emissions control setting on a vehicle

The OEM is responsible for the policy specification in the OBD security module as well as the format used within the policy change authorization token. The authorization token could take many forms depending upon the structure used for specifying policy within the OBD security module. Data fields which would be typical in the authorization token include:

* Applicable vehicles: A device may be allowed to change the policy on vehicles produced since 2016 but not before. The device may only be licensed with the OEM to be used on certain models and therefore the authorization token would identify the set of licensed vehicles.

* Policy/rule identifier: Depending upon how the OEM manages policy/rules in the OBD security module, the token may specify the number of the rule which is to be modified or turned off, e.g. "turn off rule 3."

* Allowable message ID list: Most firewalls and OBD security modules operate using a "deny unless explicitly allowed" model. Thus, if the policy does not explicitly allow a message ID, that message ID would be blocked. An "allowable message ID" field could specify IDs which are allowed to pass across the OBD port.

* Specific message ID/value pairs: Frequently there are multiple parameters within a message. e.g. one byte could control the throttle position while another byte in the same message controls the amount of fuel delivered. The default policy could allow message ID x but only allow a specific set of parameters. e.g. only allow byte specifying the amount of fuel to be between 10 and 100. The policy could allow an authorized device to change these parameter limits.

5. OPERATION

The OBD security module would typically ship with a default security policy. This policy specifies the types of messages allowed to flow to and/or from the vehicle to a device plugged into the OBD port. The policy change authorization token specifies changes to be applied to the policy when the device associated with the authorization token is plugged in.

Up to this point the focus has been on creating the infrastructure and the process of creating policy. What actually happens in the field when a device is plugged into the OBD port of a vehicle equipped with an OBD security module? Two cases of interest are outlined below.

Non-Certified Devices. No Extra Privilege

When a device which has not been certified by the OEM (e.g. a legacy insurance dongle) is plugged into a vehicle, the OBD security module will attempt to authenticate the device and obtain the policy change authorization token. Obviously, a legacy OBD device will not complete the authentication. The OBD security module will simply enforce the default policy established by the OEM.

The default policy could allow the OBD device to observe all CAN traffic but not allow the device to inject any messages into the vehicle. A more practical and fair policy is to allow a set of diagnostic SIDs required for emissions compliance testing that are known to be benign. Allowing diagnostics SIDs does not put vehicle in danger since they only read information and do not modify anything. A recommended default policy would also allow reading Diagnostic Trouble Codes (DTCs) and clearing them. This semi-open default policy is still secure while preserving all legitimate legacy use cases.

Certified with Privilege

When a certified OBD device is plugged into a vehicle, the OBD security module and OBD device will perform the protocol exchange described above in subsection Public Key and Figure 2. This protocol exchange and cryptographic processing within the OBD security module accomplishes the following:

* Allows the OBD security module to confirm the identity of the device connected to the OBD port

* Allows the OBD security module to confirm that the policy change authorization token is bound to the device

* Allows the OBD security module to confirm that the policy change authorization token was authorized by the vehicle OEM.

* Allows the OBD security module and OBD device to establish a cryptographically protected communications channel.

The OBD device will be able to perform all of the functions it has been certified for. There is no need for additional manual operations by the vehicle owner or technician to enable the OEM approved security policy modification.

6. DESIGN CONSIDERATIONS

There are many possible variations to the approach described above. Some of the considerations to consider when designing this system are discussed below.

Implementation Cost

How much will it cost the OEMs and OBD device manufactures to implement such a system?

Certification Authority

It is not necessary for the policy change authorization token to interoperate with vehicles from other OEMs or any government entities. Thus each OEM is free to serve as the certification authority for their own vehicles. This eliminates the costs associated with a 3rd party certification authority.

Certification Cost

The certification cost are expected to roughly correspond to the level of risk associated with a device. Here, risk is driven by the range of authorized CAN messages (commands) and the type of access required to cause the OBD device to send data.

A device which only reads data viewable at the OBD port but never writes data into the port essentially has no privilege and thus would not require any certification of authentication. The policy implemented in the OBD security module would block the device from sending any unauthorized messages into the vehicle.

A device which only requests diagnostic trouble codes would require little or no certification. Typically the OEM default policy in the OBD security module would allow any device to make benign requests.

A device which performs only limited functions (e.g. limit the speed of the vehicle using a well-defined set of CAN messages) but does not have authorization to manipulate safety critical systems (steering, brakes) would require minimal review to certify.

A device which performed safety related diagnostics (manipulate ABS) or triggers events related to physical security (unlock doors) would require a more rigorous certification effort to ensure that the device could not be easily misused. If such a device had no external access (e.g. the device is only controlled by a technician pressing buttons) it would be low risk and require a minimal certification. In contrast a similar OBD device which is wirelessly connected to a repair shop network or cellular network would require a more stringent certification effort.

Key Storage

A concern in environments containing cryptography is the protection of keying material [15]. The approach being described here requires the OEM to protect their private key material in a hardware security module. The number of hardware security modules required by an OEM is small so cost is not a problem.

The OBD security module stores only public key material so the integrity of the public key must be protected. The OBD security module does not require hardware to store a private key. Thus, OEMs are free to use a range of microcontrollers available from multiple competitors.

The devices which connect to the OBD port will be required to store private key and thus must have trusted storage. Fortunately, new microcontrollers are available with trusted storage technology which can store cryptographic keying material in low cost hardware to prevent tampering and thus improve trust in the overall public key environment. Key material in this trusted store may be used by the local cryptographic engine but the keys cannot be extracted.

The bottom line is that the cost of protecting the cryptographic keys is not a significant issue.

OBD Security Module

Many OEMs already include some type of gateway module within their bus architecture to route traffic to/from the OBD port and CAN busses. The security function described here may be implemented within a gateway module with modest processing and storage reserves.

Potential Costs of not Adding Security

OEMs are forced to make a decision regarding the costs of adding security as outlined above versus the potential costs of not providing security. The following factors conspire to make the analysis difficult.

* Lack of historical data: The connected car is relatively new and to date most of the attacks have been carried out by researchers, not attackers with hostile intent. We will not know the frequency or severity of attacks for several years. Thus, OEMs are forced to look at other industries and extrapolate the risk to their market.

* Deterrent effect: Security features (both cyber and physical) tend to deter illegal activity. Thus, if OEMs do implement security and few attacks occur it raises questions about how many attacks would have occurred if security was not implemented.

* Financial impact: The financial impact of an event can depend upon public perception, the court system and the opinion of Government authorities. Will the OEM be viewed as negligent or will all responsibility be placed upon the attacker?

The following scenario is given as a framework for discussing the potential costs of not addressing OBD security. It is very speculative for the reasons listed above.

There are currently about 4M vehicles with OBD devices containing cellular modems (e.g. Insurance company provided devices for monitoring driving behavior). The majority of these contain security vulnerabilities. Assume that the targeted OEM has 100,000 vehicles using an insecure cellular dongle. Attackers have demonstrated the tendency to attack large targets. This allows them to develop the attack once and use it many times. Windows PCs represent an example of a large target. Thus, an OEM with a large fleet makes for a large target.

Assume that attackers are able to compromise 1% of the OEMs 100,000 vehicles with cellular devices. What could the attackers do?

* Hold the vehicles for ransom by preventing operation of the vehicle

* Attempt to involve the vehicle in an accident by interfering with acceleration, braking or steering.

What would be the costs of the compromise? OEMs could look at historical data involving a similar number of vehicles with a common defect as a calibration point. (Faulty ignition switches, SUVs with tire problems prone to rollover, unintended acceleration) They could then sum the costs of the following.

* Class action lawsuit

* Government fines

* Mandated recall

* Damage to brand image and perceived lower value of vehicles

What is the proper decision in the face of such uncertainty?

Technology Options

The system description above is intentionally generic to allow an OEM and their tool partners to select specific technologies and processes suitable for their business. Variations in the process described above that would produce a similar result include:

* Cryptographic algorithm: The public key algorithm could be RSA or elliptic curve.

* Cryptographic key length: The various public key pairs (OEM, OBD device, and manufacturer) could use different key lengths appropriate to the perceived threat.

* Certificate structure: The certificates could be X.509 v3 certificates, IEEE 1609.2 [4] or a proprietary format. However, there is a large base of mature software available for X.509 certificates.

* Public Key infrastructure (PKI): The PKI could be a simple structure in which the OEM serves as its own root of trust. (aka Root certificate authority). The system could use a larger and more complete PKI in which the root of trust is above the OEM. This type of structure could allow one OBD device to be recognized by OBD security modules associated with multiple OEMs.

* Key exchange protocol: Many different protocols exist to establish the secure communications between the OBD security module and the OBD device. The TLS protocol provides a worked example which has been thoroughly reviewed by the security community.

* Policy change authorization token distribution: The authorization token could be distributed by embedding it within the OBD device such that the OBD device is the transport mechanism. The authorization token could be embedded in the OBD security module firmware and activated when an authorized OBD device authenticates itself. The authorization token could be fetched in real time by either the vehicle or the OBD device.

* Authorization token structure: The structure of the policy override could be a complete replacement of the default OBD security module policy. Alternatively the structure could simply identify changes to the default policy.

7. SUMMARY/CONCLUSIONS

This paper has presented an approach which provides the industry with an alternative to the one-size-fits-all security policy for the OBD port.

The approach provides OEMs with the flexibility to change the security and/or safety policy of the OBD security module in the field using a cryptographically protected authorization token which is cryptographically bound to the OBD connected device.

This same policy change concept may be applied to devices or services accessing the vehicle via any of the TCU interfaces (Cellular, Wi-Fi, Bluetooth or even USB). The device or service attempting to access the vehicle would be required to perform a cryptographic handshake with an access control function within the vehicle. The device or service requesting access would pass its X.509 certificate containing identification data along with policy change authorization data to the access control function within the vehicle. The vehicle could then enforce access rights established by the OEM specifically for the device or service requesting access.

The industry should determine if there is a need to protect vehicle from unauthorized message injection via the OBD port. Assuming there is a need, SAE could serve as the leader in coordinating the development of a standard to move from concept to fielded solution.

REFERENCES

[1.] Bluetooth and Wi-Fi/cellular OBD-II devices https://www.amazon.com/Panlong-Bluetooth-Diagnostic-ScannerAndroid/dp/B00PJPHEBO?ie=UTF8&psc=1&redirect=true&ref_=oh_aui_detailpage_o02_s00&tag=androidcentralb-20, accessed Sep. 2016.

[2.] Department of Energy, Office of Scientific and Technical Information, "RBAC Driven Least Privilege Architecture for Control Systems," http://www.osti.gov/scitech/servlets/purl/1124080, Accessed Sep. 2016.

[3.] Ian, Foster, Prudhomme Andrew, Koscher Karl, and Savage Stefan. "Fast and vulnerable: a story of telematic failures." In 9th USENIX Workshop on Offensive Technologies (WOOT 15). 2015.

[4.] IEEE Standard for Wireless Access in Vehicular Environments "Security Services for Applications and Management Messages", 1609.2-2016.

[5.] Internet Engineering Task Force (IETF), "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile," IETF RFC 5280, May 2008.

[6.] Internet Engineering Task Force (IETF), "Internet X.509 Public Key Infrastructure--HTTP Transfer for the Certificate Management Protocol (CMP))," IETF RFC 6712, Sep 2012.

[7.] Karnouskos S., "Stuxnet worm impact on industrial cyber-physical system security," IECON 2011 - 37th Annual Conference on IEEE Industrial Electronics Society, Melbourne, VIC, 2011, pp. 4490-4494. doi: 10.1109/IECON.2011.6120048

[8.] Miller, C., and Valasek, C., "Advanced CAN Injection Techniques for Vehicle Networks," Presentation at BlackHat USA 2016

[9.] Nathanson, M., "Vehicle Intelligence and Remote Wireless OBD," SAE Technical Paper 2000-01-3506, 2000, doi: 10.4271/2000-01-3506.

[10.] NIST Computer Security Research Center, "HL7 Role-Based Access Control (RBAC) Role Engineering Process," http://csrc.nist.gov/groups/SNS/rbac/documents/hl7_role-based_access_control_(rbac).pdf accessed Sep. 2016.

[11.] Canetti, Ran, and Herzog Jonathan. "Universally composable symbolic analysis of mutual authentication and key-exchange protocols." In Theory of Cryptography Conference, pp. 380-403. Springer Berlin Heidelberg, 2006.

[12.] Cnet.com, Researchers hack a Corvette's brakes via insurance black box," http://www.cnet.com/roadshow/news/researchers-hack-a-corvettes-brakes-via-insurance-black-box/, Accessed Sep 2016

[13.] Rosekind, M. (NHTSA), Congress of the United States, Committee on Energy and Commerce, Sep 12, 2016.

[14.] SAE Vehicle E E System Diagnostic Standards Committee, "E/E Data Link Security," SAE Standard J2186 Rev. June 2005.

[15.] SAE Vehicle Electrical System Security Committee, "Requirements for Hardware-Protected Security for Ground Vehicle Applications", SAE Standard J3101, Jun. 2015.

[16.] Wikipedia, "Public-key cryptography," https://en.wikipedia.org/wiki/Public-keycryptography, accessed Sep 2016.

[17.] Wikipedia, "Role-based access control," https://en.wikipedia.org/wiki/Role-based_access_control, accessed Sep 2016.

[18.] Woo S., Jo H. J. and Lee D. H., "A Practical Wireless Attack on the Connected Car and Security Protocol for In-Vehicle CAN," in IEEE Transactions on Intelligent Transportation Systems, vol. 16, no. 2, pp. 993-1006, April 2015. doi:10.1109/TITS.2014.2351612

[19.] Yada1, A. et al, "Security, Vulnerability and Protection of Vehicular On-board Diagnostics" International Journal of Security and Its Applications Vol. 10, No. 4 (2016), pp.405-422 http://dx.doi.org/10.14257/ijsia.2016.10.4.36 ISSN: 1738-9976 IJSIA

CONTACT INFORMATION

Tom Markham, Engineering Fellow

Honeywell ACST,MN10-211A 1985 Douglas Dr. Golden Valley, MN 55422-3935 Office: 1 763 954-6840 tom.markham@honeywell.com

DEFINITIONS/ABBREVIATIONS

ABS - Anti-lock braking system

ADAS - Advanced driver assistance systems

AES - Advanced Encryption Standard. NIST FIPS 197

CA - Certification authority

CAN - Controller area network

CANFD - CAN with flexible data-rate

CMP - Certificate Management Protocol

DLC - Diagnostic link connector

ECU - Electronic control unit

FIPS - Federal information processing standards

GPS - Global positioning system

NHTSA - National Highway Traffic Safety Administration

NIST - National Institute of Standards and Technology

OBD, OBD-II - On-board diagnostics (~1988) and On-board diagnostics version 2 (~1997)

OEM - Original equipment manufacturer

PID - Parameter identifiers. See SAE J1939

PKI - Public key infrastructure

RBAC - Role based access control

RSA - Ron Rivest, Adi Shamir and Leonard Adleman public key cryptographic system

SCEP - Simple certificate enrollment protocol

SID - Service identifier. See SAE J1939

TCU - Telematics control unit

TLS - Transport layer security

X.509 - International Telegraph Union standard for public key certificates

Tom R. Markham and Alex Chernoguzov

Honeywell
COPYRIGHT 2017 SAE International
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2017 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Markham, Tom R.; Chernoguzov, Alex
Publication:SAE International Journal of Passenger Cars - Electronic and Electrical Systems
Article Type:Technical report
Date:Aug 1, 2017
Words:7024
Previous Article:Integration of Component Design Data for Automotive Turbocharger with Vehicle Fault Model Using JA6268 Methodology.
Next Article:Diagnostics of Individual Air Fuel Ratio Cylinder Imbalance.
Topics:

Terms of use | Privacy policy | Copyright © 2019 Farlex, Inc. | Feedback | For webmasters