Secure message filtering to vehicle electronic control units with secure provisioning of message filtering rules

A method according to one embodiment includes the operations of configuring a host processor to receive a message filtering rule, the host processor associated with a vehicle; configuring a bus controller to verify authenticity of the message filtering rule, wherein the bus controller is programmed through an interface, the interface inaccessible from the host processor; filtering messages from the host processor using the verified message filtering rule, wherein the filtering is performed by the bus controller; and transmitting the filtered messages from the bus controller over a bus to one or more electronic control units (ECUs), the ECUs communicatively coupled to the bus.

FIELD

The present disclosure relates to secure message filtering to vehicle electronic control units, and more particularly, to secure message filtering to vehicle electronic control units with secure provisioning of message filtering rules.

BACKGROUND

As vehicle control systems become increasingly complex, interconnected and accessible through wireless communication, these systems also become increasingly vulnerable to security attacks. Embedded controllers (for engines, brakes, etc.) are typically designed to withstand hostile physical environments, but often little attention is paid to the security environment. It has generally been assumed that software running on each controller, connected to a common bus, can be trusted (i.e., not infected with malware), although that philosophy is beginning to change.

The presumption of security safety is no longer justified as recent studies have shown that vehicles with internet connectivity and/or wireless interfaces such as Bluetooth and WiFi may permit a platform in the vehicle to become infected. Such a malicious platform can then reprogram other controllers on the bus and/or send messages to these controllers which are capable of causing catastrophic harm to the vehicle and its occupants. One approach to this problem is to implement specific and unique security enhancements to each individual embedded controller, but this may require significant involvement on the part of all Original Equipment Manufacturers (OEMs) and may result in duplication of efforts or adoption of incompatible approaches.

DETAILED DESCRIPTION

Generally, this disclosure provides methods and systems for implementing a rule-based message filter in the firmware of a bus controller for a bus, to which a vehicle's electronic control units are connected. The firmware may be protected from unauthorized manipulation and the message filter rules may be verified for authenticity and security. Additionally, methods are provided for generating secure message filter rules that may be authenticated prior to implementation.

FIG. 1illustrates a system block diagram100of one exemplary embodiment. System100of this embodiment generally includes a vehicle based host platform120. Host platform120may be an in-vehicle information and/or entertainment (IVI) system. Host platform120may include wireless connectivity to the internet, Bluetooth devices, WiFi networks, and/or any other communication networks. Host platform120may comprise host processor122, bus controller132, and message filter rule database128. Host processor122may receive message filtering rules114from a rule provisioning system112through a wireless interface and store those rules124in the message filter rule database128. Host processor122also generates unfiltered messages126to be sent to the bus controller132. Host processor122may communicate with bus controller132through a Peripheral Component Interconnect (PCI) bus, a Universal Serial Bus (USB) or other suitable interface.

Bus controller132may comprise firmware134implemented in a field programmable gate array (FPGA) or other suitable programmable logic circuitry. Bus controller firmware134may be programmed by a Joint Test Action Group (JTAG) programming unit140through a JTAG interface142or other suitable programming methods that are similarly inaccessible to the host processor122and any other processors or controllers associated with the vehicle. Limiting programmability access to the bus controller firmware134increases the security of that firmware134. Programming of the bus controller firmware134includes message filter logic and message filter rule verification logic. The message filter rule verification logic may include a trusted rule-signing key as will be explained in greater detail below.

Bus controller firmware134is responsible for receiving unfiltered messages126from the host processor122, filtering those messages and sending the filtered messages152to the bus150. Bus controller firmware134performs this filtering based on rules130obtained from the message filter rule database128. The filtering rules may be used to prevent unauthorized and/or potentially malicious messages from being sent over the bus150to various vehicle electronic control units (ECUs)154. The bus150may be a Controller Area Network (CAN) bus or other suitable bus. The vehicle ECUs (154) may be embedded controllers for the engine, brakes, transmission or other vehicle systems or sensors.

Most ECU messages are original equipment manufacturer (OEM) specific and proprietary, and therefore the OEM generally determines how message filter rules are constructed so that messages sent to the ECUs154will be safe and appropriate. An initial set of rules may be pre-loaded or provisioned in the message filter rule database128by the OEM, but it is useful for the rules to be updatable through the wireless connectivity of the host platform120, so that the OEM can evolve the rules over time to enable new features or close newly-discovered security vulnerabilities. New or updated message filter rules114obtained in this manner, however, generally cannot be trusted due to security vulnerabilities inherent in the internet and wireless networks as well as the fact that software running in the host processor122, which has full access to these message filter rules114, may be compromised.

In order to verify the authenticity and security of new message filtering rules114provided to the host platform120, a secure rule provisioning system is employed. A trusted rule authoring entity102, such as the OEM, is provided with rule authoring tools that enable the entity102to generate a digital signature to be associated with a newly authored set of rules. The rule authoring entity102sends the new set of rules and the digital signature104to a rule certification service106which can verify the identity of the rule authoring entity102based on the digital signature. The rule certification service106then generates a digital manifest to be associated with the new rule set to indicate that the rule set is trusted and sends this manifest110back to the rule authoring entity102. The rule authoring entity102sends this rule set and manifest108to a provisioning system112where it can be made available to host platform120by any suitable method of transmission. Host platform120stores the rule set and associated manifest124in the message filter rule database128.

Bus controller firmware134can verify the authenticity and security of message filter rules130obtained from the database128, based on the manifest associated with the rule set, in combination with a trusted rule-signing key that is provided to the firmware134as part of the firmware134secure programming142. The key may be an asymmetric key used in combination with the manifest to decrypt the rule set. If the bus controller firmware134cannot verify the authenticity of the message filter rules130, it may ignore the new rules and continue to use an existing rule or it may cease to transmit messages to the vehicle ECUs154and signal an error condition.

By providing message filtering capability, executed on secure firmware using trusted message filtering rules, any compromise in the integrity of the host processor or the IVI system will not lead to a compromise in the security of the rest of the vehicle including safety critical ECU functions.

FIG. 2illustrates a flowchart of operations200of one exemplary embodiment. At operation202, a host processor associated with a vehicle is configured to receive message filtering rules. The rules may be received through a wireless interface from a rule provisioning system external to the vehicle. At operation204, a bus controller is configured to verify the authenticity of the message filtering rules. At operation206, the bus controller filters messages from the host processor using the verified message filtering rules. The bus controller is configured to verify rules and perform filtering through a programming interface that is inaccessible to the host processor. The programming interface may be a JTAG interface and the bus controller may be implemented as an FPGA. At operation208, the bus controller transmits the filtered message over a bus to one or more vehicle ECUs. If the bus controller cannot verify the authenticity of the message filtering rules, it may ignore the new rules and continue to use existing rules or it may cease to transmit messages and signal an error condition.

FIG. 3illustrates a flowchart of operations300of another exemplary embodiment. At operation302, a rule certification service receives message filtering rules from a rule authoring entity. At operation304, the rule certification service receives a digital signature associated with the message filtering rules from the rule authoring entity. The rule authoring entity may generate the digital signature using rule authoring tools provided by the rule certification service. At operation306, the rule certification service verifies the identity of the rule authoring entity as a trusted source based on the digital signature. At operation308, the rule certification service generates a trusted manifest to be associated with the message filtering rules. At operation310, the rule certification service provides the trusted manifest to the rule authoring entity. The rule authoring entity may then transmit the message filtering rules and the associated trusted manifest to a vehicle based host platform.

Although the automobile industry and OEMs may, over time, take steps to develop more secure ECUs, the rule based message filtering system described herein may be cooperatively employed with and take advantage of any additional platform security measures that are implemented in the future. In the meantime, the rule based message filtering system described herein may be employed to mitigate the risks posed by IVI platforms which have the greatest exposure to malware infection.

Embodiments of the methods described herein may be implemented in a system that includes one or more storage mediums having stored thereon, individually or in combination, instructions that when executed by one or more processors perform the methods. Here, the processor may include, for example, a system CPU (e.g., core processor) and/or programmable circuitry. Thus, it is intended that operations according to the methods described herein may be distributed across a plurality of physical devices, such as processing structures at several different physical locations. Also, it is intended that the method operations may be performed individually or in a subcombination, as would be understood by one skilled in the art. Thus, not all of the operations of each of the flow charts need to be performed, and the present disclosure expressly intends that all subcombinations of such operations are enabled as would be understood by one of ordinary skill in the art.

The storage medium may include any type of tangible medium, for example, any type of disk including floppy disks, optical disks, compact disk read-only memories (CD-ROMs), compact disk rewritables (CD-RWs), digital versatile disks (DVDs) and magneto-optical disks, semiconductor devices such as read-only memories (ROMs), random access memories (RAMs) such as dynamic and static RAMs, erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), flash memories, magnetic or optical cards, or any type of media suitable for storing electronic instructions.

“Circuitry”, as used in any embodiment herein, may comprise, for example, singly or in any combination, hardwired circuitry, programmable circuitry, state machine circuitry, and/or firmware that stores instructions executed by programmable circuitry.