CN107846395B

CN107846395B - Method, system, medium, and vehicle for securing communications on a vehicle bus

Info

Publication number: CN107846395B
Application number: CN201710858268.2A
Authority: CN
Inventors: 詹姆斯·罗伯特·阿尔弗雷德; 瑟吉·西多罗夫; 斯科特·李·林盖; 曾明驰
Original assignee: BlackBerry Ltd
Current assignee: BlackBerry Ltd
Priority date: 2016-09-20
Filing date: 2017-09-20
Publication date: 2021-10-08
Anticipated expiration: 2037-09-20
Also published as: EP3297247A1; CA2979653A1; US10285051B2; US20180084412A1; CN107846395A; US10965450B2; HK1252006A1; EP3297247B1; US20190268763A1

Abstract

A system and method for securing communications on a vehicle bus, comprising: establishing a connection between a gateway in a vehicle and a vehicle bus; generating a session key at a gateway within the vehicle; sending a public key certificate and a transient key to the gateway and an electronic control unit of the vehicle; generating a shared secret at the gateway and the electronic control unit, respectively; encrypting, at a gateway, a session key using the shared secret; receiving, at the electronic control unit, an encrypted session key over the onboard bus; and decrypting, at the electronic control unit, the encrypted session key based on the generated shared secret.

Description

Method, system, medium, and vehicle for securing communications on a vehicle bus

Technical Field

The present disclosure relates to networks, and more particularly to protocols for providing secure communications over a vehicle network.

Background

Vehicle networks are being developed by automotive manufacturers to reduce exhaust emissions, improve fuel economy and improve vehicle driveability. The point-to-point connections of the network transmit data between the vehicle components. But as components and functionality increase, the complexity and size of the network becomes larger, impractical and expensive.

To reduce complexity and cost, serial buses have been developed that facilitate communication with embedded vehicle systems. One such system, known as a Controller Area Network (CAN), is a low cost lightweight protocol (light protocol) system that allows microcontrollers to communicate openly with each other. The protocol includes built-in features, such as a Cyclic Redundancy Code (CRC) check, that allow the vehicle application to detect errors during transmission, storage, and retrieval.

Disclosure of Invention

There is a need for methods, systems, and devices that provide secure communications over an unsecure infrastructure.

According to an aspect, there is provided a method for securing communications on an onboard bus having an untrusted side on one side of a root of trust and a trusted side on the other side of the root of trust, the method comprising:

establishing a connection between a gateway in a vehicle and the onboard bus, the gateway on the untrusted side;

generating, at the gateway within the vehicle, a session key, the session key being a key that is used during a single ignition cycle or power cycle and then discarded;

receiving a public key certificate and a transient key at the gateway and an electronic control unit of the vehicle, the electronic control unit being on the trusted side;

generating a shared secret at the gateway and the electronic control unit, respectively, in response to the public key certificate and the ephemeral key;

encrypting, at the gateway, a session key using the shared secret;

receiving, at the electronic control unit, an encrypted session key over the onboard bus; and

decrypting, at the electronic control unit, the encrypted session key based on the generated shared secret.

According to another aspect, there is provided a system for securing communications on an in-vehicle network having an untrusted side on one side of a root of trust and a trusted side on the other side of the root of trust, the system comprising:

a gateway in the vehicle, the gateway generating a session key and sending and receiving an encrypted certificate and a temporary key from the in-vehicle network, the gateway being on the untrusted side;

an electronic control unit within the vehicle, the electronic control unit receiving the encrypted certificate and the ephemeral key sent by the gateway and sending the encrypted certificate and the ephemeral key received by the gateway, the electronic control unit being on the trusted side;

wherein the gateway and the electronic control unit generate a shared secret in response to the encrypted certificate and the ephemeral key received by the gateway and the electronic control unit, respectively;

wherein, in response to verification of the encryption certificate received from the electronic control unit, the gateway encrypts and transmits the session key using the shared secret; and

wherein the session key is a key that is used during a single ignition cycle or power cycle and then discarded.

According to another aspect, there is provided a computer readable medium storing a program for securing communications on an in-vehicle bus having an untrusted side on one side of a root of trust and a trusted side on the other side of the root of trust, the program comprising computer program code for:

encrypting, at the gateway, a session key using the shared secret;

According to another aspect, there is provided a vehicle comprising:

an in-vehicle network having an untrusted side located on one side of a root of trust and a trusted side located on the other side of the root of trust;

a gateway within the vehicle, the gateway generating a session key and sending and receiving encrypted credentials and a transient key over the on-board network, the gateway on the untrusted side;

In this way, secure communications can be provided over an unsecure infrastructure.

Drawings

The invention can be better understood with reference to the following drawings and description. The components in the figures are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the technology. Moreover, in the figures, like reference numerals designate corresponding parts throughout the different views.

Fig. 1 shows an electronic control unit communicating on a vehicle bus.

Fig. 2 illustrates a multi-level security platform.

Fig. 3 is a flow chart of key exchange.

Fig. 4 shows the key exchange of fig. 3 between the electronic control unit and the gateway.

Fig. 5 is a message flow diagram for updating keys.

Detailed Description

While designed to provide an efficient, cost-effective structure for on-board communications, both commercial and open-source implementations of CAN networks are inherently insecure because they rely on good behavior to deter attacks. No arbitrator is needed to resolve these disputes over the network because good behavior is guaranteed.

While good behavior may work well in an unconnected car, it does not provide protection for vehicles connected to the outside infrastructure (V-2-I), retailer (V-2-R) and individual (V-2-P) of the car through onboard and remote networks. Connected cars may be easily attacked by eavesdropping on the vehicle's network. In these attacks, attackers are difficult to detect because they do not affect the data flowing through the network despite their unauthorized access. The attacker is not necessarily a stranger; he or she may be a legitimate user without authority. Alternatively, an attacker may actively intervene in the vehicle network to change the data or gain malicious benefit.

One focus of the attack is the car itself and the ability to physically attach to the network at any time and begin monitoring and/or attack. This physically connected attack pattern may occur when an attacker aims the vehicle ensemble for learning and evaluation. From this advantage, an attacker can plan a remote attack. The mischief of connected vehicle attacks that are likely to occur recently is likely due to a series of physical connection attacks and the resulting exploit (exploit) as preconditions. The ability to preclude or destroy physical connection attacks and their exploits is then a problem in the need for a solution.

The disclosed systems and processes provide a secure communication protocol over an unsecure infrastructure. The security protocol allows secure communication over unsecured on-board networks, which may provide connectivity to networks outside of the vehicle while ensuring the integrity and source of data transmitted thereon. This means that the on-board systems can communicate with each other or with any remote or local destination outside the vehicle through the open infrastructure in the vehicle and can reasonably ensure that their communications will be received intact and protected in transit from unauthorized parties or destinations. A security protocol provides a series of steps that allow two or more parties to exchange information through cryptographic security. Using encryption parameters, the security protocol can interoperate with independent programs and libraries (e.g., collections of software and data files that perform different tasks). By allowing migration from one cryptographic primitive to the next, the security protocol is extensible, efficient, and updatable, allowing it to defend against new threats and keeping up with improvements in technical efficiency.

Fig. 1 shows a vehicle connected to a remote node or remote destination over a wireless network. The vehicle includes a plurality of Electronic Control Units (ECUs) and interfaces embedded in the vehicle to control one or more of the systems or subsystems of the vehicle from within the vehicle. Example ECUs and interfaces include, but are not limited to: an electronic/Engine Control Module (ECM), a Powertrain Control Module (PCM), a Transmission Control Module (TCM), a Brake Control Module (BCM), a Central Control Module (CCM), a Central Timing Module (CTM), a General Electronic Module (GEM), a Body Control Module (BCM), a Suspension Control Module (SCM), an Entertainment and Comfort Control Module (ECCM), a Passive Keyless Entry (PKE), a remote link application interface, a vehicle-to-vehicle (V-2-V), V-2-I, V-2-R and/or V-2-P Dedicated Short Range Communication Transceiver (DSRCT), engine and transmission units, airbag modules, lighting modules, vehicle access systems, on-board diagnostics interface (OBDI), universal serial bus interface, bluetooth interface, smartphone interface, etc., five of which are designated by reference numerals 1 to 5 in fig. 1.

In some systems, ECUs such as those shown in FIG. 1 are integrated into one or more domain controllers utilizing an advanced multiprocessor architecture. The multiple processors execute software customized for each electrical system or subsystem it controls. It can manage concurrent vehicle systems/subsystems that may be different from each other, execute one or more cipher suites (ciphersuites) using the gateway, and can provide access to the encryption key store. The use of one or more domain controllers exposes fewer attacking nodes.

In FIG. 1, in the present disclosure, ECUs 1-5 are connected to an onboard communication link, also referred to as an onboard network and an onboard bus. The CAN bus is an example of an on-board bus. ECUs are embedded electronic devices (e.g., dedicated digital computers or signal processors) that read signals sent from on-board sensors located at various portions of the vehicle to monitor vehicle conditions. The sensor detects or measures a condition by converting non-electrical energy into a discrete or analog signal. For example, ECUs such as Advanced Driver Assistance Systems (ADAS), powertrain controllers, brake systems and clusters capable of over-the-air (OTA) communication as shown in FIG. 2 communicate through a root of trust (RoT) that may be remote (as shown by the trust anchor in FIG. 2) or an integral part of the gateway. RoT acts as a separate compute engine consisting of inherently trusted hardware and software. RoT controls the cryptographic processor of a trusted computing platform (which may be embedded in a gateway within a vehicle), may securely store cryptographic keys, may securely store certificate chains, may provide application and data isolation, and/or may securely sign certificates that are associated or verified by security protocols. As shown, all vehicle content outside the gateway (e.g., body ECUs, brake ECUs, powertrain ECUs, cluster ECUs, ADAS ECUs, etc.) is located on the trusted side of the RoT (to the right of the trust anchor), although in other configurations and implementations, some controllers may not. For example, a body ECU with very low processing power may be connected to an on-board communication link on the untrusted side (to the left of the trust anchor) because of its limited functionality or its functionality as an endpoint for a higher level controller. In fig. 2, the body ECU is shown on the trusted side because its functions may include controlling headlights, power windows, and/or door locks, all of which may be integrated into the exploit (e.g., no headlights at night, opening windows in a thunderstorm, etc.).

In fig. 2, an OBD interface, a Telematics Control Unit (TCU), and an in-vehicle infotainment (IVI) ECU communicate with a gateway over an in-vehicle communication link. IVI manages and delivers audio content, provides navigation data, delivers back seat entertainment such as movies, games, social networking functions, etc., listens to incoming Short Message Service (SMS) text messages and sends outgoing Short Message Service (SMS) text messages, makes/receives phone calls, and/or may access internet-enabled or smart phone-enabled content that may include traffic reports, sports scores, and weather forecasts, for example. OBD provides access to vehicle self-diagnostic and reporting capabilities delivered over an onboard communication link.

The connection to the onboard communication link begins with a gateway that generates a symmetric session key and a transient key pair as power or ignition turns in the vehicle. In some implementations, the same key pair is used separately for each encrypted shared secret exchange with each network node. Once the certificate and ephemeral key are exchanged, the gateway accepts the node request for the session key. The session key is a key for one communication session, such as communications that occur during a single ignition cycle (e.g., starting and driving a car and then parking would be an ignition cycle) or power cycle (e.g., turning the device on and then off), and then the session key is discarded.

The first thing each node does when it is online is to retrieve the session key when an asymmetric handshake occurs. The session key is the same for all nodes on the on-board network. However, since the security protocol handles certificates, it establishes a shared secret that is specific and in some cases unique to each node (gateway pair or group for each power cycle/ignition cycle). A shared secret known only to the devices involved in the secure communication is used to encrypt the session key before it is sent to the node over the network.

Each node on the network immediately initiates a session key exchange when it comes online. At 302, when the vehicle starts (power up), the gateway generates a symmetric session key and sends HELLO (HELLO) messages from each node to the gateway and RoT (hereinafter referred to as part of the gateway) separately and separately as shown in fig. 3 and 4. A node includes any data processing device including ECUs, domain controllers, processing devices, etc., coupled by a communication medium or link. In the security protocol the hello message comprises two bytes of data comprising e.g. information about the sending node, e.g. its identification.

Hello (ID: 0X011)

In response, the gateway and the node provide the certificate and the temporary public key to each other (the receiving node and the gateway), respectively, at 304 and 306, as shown in fig. 3. The 304 and 306 sequences may be performed concurrently or out of order. The certificate is installed when the vehicle is manufactured (e.g., prior to assembly of the vehicle) or during service (e.g., during component repair and/or replacement). They provide authentication for each active node and gateway communicating across the onboard bus. Authentication is similar to the verification of Secure Sockets Layer (SSL) certificates. The certificate and the gateway's ephemeral key are formatted in an 8 byte format in two parts (data 1 and data 2). The first two bytes of the gateway's certificate and transient key (first packet) are an ID field containing a destination unique identifier so that the gateway can communicate with the correct node on the vehicle network. The third byte is a counter that keeps track of the number of packets sent, and the remaining five bytes are reserved for the payload.

Gateway certificate (ID: 0X12)

Here, a "packet" is a data block for transmitting information that may include a payload and a non-payload portion; "payload" is the data of interest; and "non-payload" is packet data that is not payload data, such as routing or configuration information. In some cases, the payload may include frames sent on the CAN bus, such as data frames, remote frames, error frames, and/or overload frames.

In a data frame (shown below), the first two bytes represent the total length of the gateway certificate and the ephemeral public key, the next two bytes represent the length of data 1 (e.g., gateway certificate, secret session key, etc.), and the remaining four bytes are reserved for the payload. The field following the second packet reserves the first two bytes of the packet of length D2 and the remaining bytes for the corresponding data D2. In this format, the security protocol sends as many packets as necessary.

Upon receipt of the gateway message at the node, the gateway message is disassembled, the certificate for the gateway is reassembled and validated, and the public key for the gateway is extracted from the certificate. The public key of the gateway and the ephemeral public key are then processed by the node to generate a shared secret at 308 by an encryption operation, such as by an elliptic curve Menezes-Qu-vanstone (ecmqv) cipher suite.

The node or unit certificate and its ephemeral key sent to the gateway at 306 have almost the same format as the gateway's certificate message, as the format of the gateway certificate. The essential difference is that the destination ID field enables the gateway to distinguish node packets on the CAN bus. The conventional CAN protocol does not use an addressing scheme and therefore the destination ID serves this function. In an alternative implementation, the ID field is not used, particularly when the location (e.g., address) is identified in the backup protocol. When a node message is received at the gateway, the node message is disassembled, the certificate of the node is reassembled and verified, and the public key of the node is extracted from the certificate. The public key of the node and the ephemeral public key are then processed by the gateway to generate a shared secret at 308 by the same cryptographic operation as performed at the node. In this example, an ECMQV cipher suite.

The shared secret is then used at 310 to encrypt the existing session key by a symmetric encryption operation. The session key message sent to the node in fig. 4 follows a similar format as the gateway certificate. The essential difference is that instead of two data fragments, the payload contains one data fragment: an encrypted session key.

In this implementation, the security protocol uses a single session key for each power/ignition cycle. In an alternative implementation, the security protocol may update the session key. Regardless of the version, once a successful session key extraction occurs at the node, the gateway is notified at 312. As shown in fig. 4, the secure connection is completed upon receipt of the acknowledgement.

The acknowledgement is transmitted in two bytes.

Affirmation (ID: 0X019)

With the negotiated security protocol, the ECU and the domain controller may communicate using a hash-based message authentication code (HMAC) that is verified at the receiving destination. In CAN or on-board bus applications, the first 8 bytes of the first packet (not shown) of the secure ECU/domain controller-gateway exchange contain data generated by the ECU/domain controller in the normal format that the ECU/domain controller sends over the on-board network. The HMAC code works by: first packet data padded with zeros of 8 bytes total length is interleaved with the session key and counter value by a hashing algorithm that converts the input into a small fixed length output (e.g., six or more bytes) that needs to have a counter and the same session key in order to read the ECU to authenticate the data. The counter is provided with a second packet.

In the second packet of the security ECU/domain controller-gateway exchange, the scheme appends a 3-bit zero as the second packet identifier, 29 bits of the source ID of the node output data and a counter. Under the security protocol, each authenticator message contains a count greater than the counter located directly in front on the on-board network. In some implementations, the counter may be random or variable, may be encrypted, but is not a timestamp. The counter effectively prevents replay of responses from previously executed and suppresses replay attacks. In one implementation, the counter is programmed to fall within a range that ensures that the counter does not return to zero during the session; as shown, the second packet is required to reserve four bytes or more for the counter. Here, the counter is a variable that keeps a count of messages transmitted on the on-board network.

Authenticator (second group)

In the third packet of the secure ECU/domain controller-gateway exchange, the signature allows the gateway to match the packet to the second packet, because after receiving the second packet, the reader can calculate the resulting HMAC value by using the counter, the session key and the data from the first packet. The third grouping is shown below.

Signature (ID: 0X01) (third packet)

Three-packet security ECU/domain controller-gateway switching has many advantages, including efficient routing of packets without transmitting a source ID in all three packets (see, e.g., third packet: signature). It also simplifies the authentication process at the gateway and node, so when a byte-by-byte comparison of a received packet with previously stored trusted packets/information reveals that the packet is corrupted or corrupted, the ECU waits for a second packet (with a counter and CAN ID, linking it to the data packet) and a third packet (which does not have the ID, but rather has an HMAC hash value containing the data, session key and counter). The first packet is ignored and discarded after a timeout or upon receiving another data packet with the same CAN ID.

Because a received packet, such as a certificate or session key, for example, may not always reach the intended destination, the security protocol includes a message for resending the missing packet. For example, at a node, if the order of the packets is corrupted or the expected number is less than expected, the node will send a message to the gateway over the vehicle bus to resend the lost packets.

Repeat Unit to gateway (ID: 0x15)

Here, the source ID is a reporting node ID, and the packet number is a counter value of a lost packet. In response TO a REPEAT Unit TO GATEWAY (REPEAT UNIT TO GATEWAY) message, the GATEWAY resends the packet.

Packets such as certificates or transient keys, for example, may not always arrive at the gateway, as may be the condition that causes a repeat unit to gateway message to be issued. At the gateway, if the order of the packets is disrupted or the expected number is less than expected, for example, the gateway will send a message to the node over the vehicle bus requesting the node to resend the lost packets. Here, the destination ID is a gateway ID, and the packet number is a counter value of a lost packet. In response TO repeating the gateway-TO-cell (REPEAT GATEWAY TO UNIT) message, the node resends the packet.

Repeating gateway to cell (ID: 0x16)

In some communication sessions, it is sometimes necessary to change the session key during the power/ignition cycle. Since the trusted ECU and the gateway share the same key during the communication cycle and both operate on the same one-way function, the gateway can encrypt or wrap the new session key (generated using a random number generator or key establishment procedure) with the old session key and the nodes decrypt the new key with the old session key by exchanging messages as shown in fig. 5. The UPDATE of the session KEY is initiated by an UPDATE KEY (UPDATE KEY) message from the gateway. Current implementations of security protocols use a key update function, such as the Advanced Encryption Standard (AES) 128-bit key algorithm. The update key message may include a packet formatted as follows.

Updating the Key (ID: 0x17)

The payload data may be formatted as:

when all packets are received and all REPEAT (REPEAT) messages are processed (if needed), the node informs the gateway that the procedure is successfully completed by sending an Acknowledgement (ACKNOWLEDGE) message. When all nodes acknowledge the extraction of the new session key, the gateway broadcasts a single message: the UPDATE KEY END (UPDATE KEY END).

Update Key end (ID: 0x18)

Byte 1
	0xFF

During this time, while the nodes are updating the session key, the nodes continue to sign their data with the old session key until they receive an update-key-end message. During which both the old and new session keys are used to perform secure message authentication, wherein the new session key is processed first, followed by the old session key in turn. Once the renew key end message is broadcast, all nodes switch to signing with the new session key.

Any node may report an error. For example, a failed certificate validation at a node may mark an error. When an error occurs, the ECU/domain controller may report the error to the gateway in the following format, for example.

Each of the methods and descriptions of the protocols described herein may be independent and, in alternative implementations, may be combined with other protocols, including an in-vehicle network that uses end-to-end encryption that preserves confidentiality. In one alternative, an encryption device (e.g., ECU, domain controller, gateway, etc.) encrypts secure non-payload data reassembled with unencrypted routing information, such as, for example, a source identification, a destination identification, and a padded source identifier (e.g., a truncated source ID prior to padding). In alternative implementations, the security protocol has a different range or more of bus Identifiers (IDs) and/or function messages. In this alternative, the security protocol also serves as a framework for developing and deploying other ID, message, password, and/or hash functions that allow migration to other on-board communication links/buses and/or to later-developed communication links/buses.

ID	Message
		0x11	You good
0x12	Gateway certificate
		0x13	Unit certificate
0x14	Session key
		0x15	Repeating unit to gateway
0x16	Repeating gateway to cell
		0x17	Updating a key
0x18	Rekeying over
		0x19	Acknowledgement of the fact
0x10	Error(s) in
		0x01	Signature

In the alternative, the ECU/domain controller joins the secure session when the presence of the ECU/domain controller is detected on the on-board bus in response to a state of health message (SOH) broadcast on the CAN bus. In this alternative, after a node broadcasts its presence on the bus via a SOH message, the node retrieves the session key via the secure protocol described above. The protocol performs a key update function when the node stops broadcasting SOH messages. Alternatively, the SOH message may supplement the security protocol. In this implementation, the SOH supplements the security protocol by establishing that the node is operating correctly. It is used as an integrity check. In another alternative, the encryption and decryption of the security protocol is done exclusively in hardware, without attaching the HMAC signature to the ECU/domain controller data through the AES accelerator module performing AES128 encryption and decryption. In this alternative, 304 and 306 of fig. 3 are replaced by AES accelerators, which perform encryption and decryption using 128-bit keys according to AES in hardware. Further, another alternative may include any combination of the structures and functions described herein (in this disclosure/application and patent) or shown in one or more or each of the figures. These systems or methods are formed by any combination of the described structures and functions.

The new security protocol can be applied to existing topologies and can also migrate to topologies under development. For example, while an example implementation of the security protocol has been described for a limited packet size of eight bytes used in the classic CAN, an alternative security protocol ensures flexible data rates (FD) and packet sizes provided by implementing the vehicle network protocol. This means that the security protocol protects networks with large or variable payload lengths (e.g., CAN 13 bytes, CAN FD 64 bytes, bulk download protocol, etc.), CAN use two or more different bit rates, and accommodates the higher bandwidths used in the technology being developed. In one example, the protocol ensures that CAN frames with two different bit rates make the network backward compatible with controllers with more limited packet lengths. One example security protocol has a large payload, e.g., a data frame with up to 64 bits, while protected by a CRC (e.g., CAN FD 64 bytes).

The elements, systems, engines, methods, modules, applications, and descriptions herein may also be programmed by computer program code in one or more controllers, signal processors, special purpose processors, and one or more processors and co-processors (e.g., a co-processor is a different processor than the main processor that performs additional functions that assist the main processor). The processors may be arranged in a parallel processing architecture and/or a multi-processing architecture. Parallel processing may be run on a computer that contains two or more processors running simultaneously. Parallel processing differs from multiprocessing in the way tasks can be distributed.

The RoT, encryption and decryption engines may comprise a part of a processor or program that performs or supports the encryption functions. The sequence of steps describing the safety protocol involves two or more entities designed to accomplish the task of ensuring the safety of the vehicle bus communication. By "a series of steps" is meant that the protocol has a sequence from beginning to end. Unless otherwise noted, each step is completed in turn, with no steps taken until the previous step is completed, some of which are optional, such as an acknowledgement message. "involving two or more entities" means that at least two or more entities are required to establish a protocol (e.g., a node and a gateway, one or more nodes and gateways, etc.). Finally, "designed to accomplish the task of securing the vehicle bus communications" means that the protocol must secure communications on the vehicle bus. What looks like a protocol but does not accomplish the task of securing the vehicle bus communications is not a secure protocol.

In some systems, the elements, systems, methods, engines, and descriptions described herein may be encoded in a non-transitory signal bearing storage medium, a computer readable medium, or may comprise logic stored in a memory accessible through an interface. Some signal-bearing storage media or computer-readable media include memory that is integral to or separate from (e.g., local or remote to) the vehicle. If the description is performed by software, the software may reside in memory that resides in or interfaces to one or more processors, ECUs, domain controllers, and/or gateways.

The disclosed memory or memories may retain an ordered listing of executable instructions for implementing the functions described herein. The machine-readable medium may alternatively be, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor medium. A non-exhaustive list of examples of machine-readable media includes: a portable magnetic or optical disk, volatile memory such as Random Access Memory (RAM), Read Only Memory (ROM), erasable programmable read only memory (EPROM or flash memory), or a database management system. When a message, ECU, domain controller, gateway and/or other device function or step is said to be "responsive" or occurs to be "responsive" to a function or message, the message, ECU, domain controller, gateway and/or other device function or step must occur as a result of the message or function. It is not sufficient that a function or an action merely follows or occurs after another.

The disclosed system and process provide a secure communication protocol that ensures communication over an unsecured infrastructure, such as for a vehicle, over a vehicle bus. Vehicles may include, but are not limited to, automobiles, buses, trucks, tractors, motorcycles, bicycles, tricycles, quadricycles or other wheeled vehicles, boats, submarines, boats or other watercraft, helicopters, drones, airplanes or other aircraft, trains, trams or other tracked vehicles, space ships or other spacecraft, and any other type of vehicle, whether currently existing or after the present disclosure. In other words, it includes equipment or structures for transporting people or things. The security protocol creates secure communications over an unsecured vehicle bus (e.g., CAN bus) that CAN communicate over a remote wireless and/or fixed telephone channel while ensuring the integrity and source of data sent over it. This means that on-board systems can communicate with each other over an open infrastructure to any remote or local destination and reasonably ensure that it will be received and protected in its entirety. The security protocol provides a series of steps that enable two or more parties to exchange information through cryptographic operations that are particularly effective in precluding or destroying physical connection attacks and their exploits, etc., because they are not private (privy) to cryptographic operations. By using encryption parameters, the security protocol can interoperate with stand-alone programs and libraries. By allowing migration from one cryptographic primitive to the next, the security protocol is extensible, efficient, and updatable, allowing it to defend against new threats and keep up with improvements brought about by technological changes.

Other systems, methods, features and advantages will be, or will become, apparent to one with skill in the art upon examination of the following figures and detailed description. It is intended that all such additional systems, methods, features and advantages be included within this description, be within the scope of the invention, and be protected by the following claims.

Claims

1. A method for securing communications on an in-vehicle bus having an untrusted side on one side of a root of trust and a trusted side on the other side of the root of trust, the method comprising:

encrypting, at the gateway, a session key using the shared secret;

2. The method of claim 1, wherein the on-board bus comprises a controller domain network that utilizes a packet size specified by an on-board bus protocol.

3. The method of claim 1, further comprising establishing a wireless connection between a node capable of communicating on the vehicle bus and a node remote from the vehicle.

4. The method of claim 1, wherein the electronic control unit comprises a plurality of electronic control units incorporated into a domain controller.

5. The method of claim 1, further comprising sending one of the public key certificate and the ephemeral key from the gateway to the electronic control unit.

6. The method of claim 1, further comprising sending one of the public key certificate and the ephemeral key from the electronic control unit to the gateway.

7. The method of claim 1, wherein the session key is valid only during one communication session occurring during an ignition cycle of the vehicle.

8. The method of claim 1, wherein the session key is valid only during one communication session occurring during a power cycle.

9. The method of claim 1, wherein the on-board bus comprises a controller area network bus utilizing more than one bit rate.

10. The method of claim 1, wherein the session key, the public key certificate, and the ephemeral key are transmitted on the onboard bus in 8 byte packets.

11. The method of claim 1, wherein the onboard bus is encrypted end-to-end.

12. The method of claim 1, further comprising: data is transmitted from the electronic control unit over the vehicle bus encrypted by the session key.

13. The method according to claim 1, wherein the electronic control unit communicates with the second vehicle through an encrypted session key.

14. The method of claim 1, wherein the gateway comprises the root of trust securely storing the public key certificate and the ephemeral key.

15. A system for securing communications on an in-vehicle network having an untrusted side on one side of a root of trust and a trusted side on another side of the root of trust, the system comprising:

16. The system of claim 15, wherein the gateway comprises an encryption processor.

17. The system of claim 15, wherein the vehicle network comprises a controller area network bus that uses a packet size and more than one bit rate specified by a vehicle bus protocol.

18. The system of claim 15, wherein the shared secret is generated in response to a hash-based method authentication code.

19. The system of claim 15, different encryption certificates being hard-wired into the gateway and the electronic control unit, respectively.

20. A computer readable medium storing a program for securing communications on an in-vehicle bus having an untrusted side on one side of a root of trust and a trusted side on another side of the root of trust, the program comprising computer program code for:

encrypting, at the gateway, a session key using the shared secret;

21. A vehicle, comprising: