GB2548371A - Firewall for securing access to vehicle networks - Google Patents

Abstract

A configurable vehicle firewall device filters traffic or data packets sent between the main vehicle bus of the vehicle 4 (the inside bus) and a potentially insecure bus 2 (the outside bus). The device may have a hardware interlock to control the filtering of messages based on the vehicles physical state (such as a physical key being turned in a lock to a particular position). The device may be embedded in an electronic control units (ECUs) 5 cable harness. The device may be configured by uploading rules into a firewall table which are stored in stable memory. The rules may determine the filtering of messages based on a message identifier, a message payload, or the real-time arrival pattern of a message. The device and rules can be authenticated using encryption and decryption. The firewall allows legitimate access to the internet 1 but aims to prevent any attack on the ECUs which may cause the vehicle to malfunction.

Description

FIREWALL FOR SECURING ACCESS TO VEHICLE NETWORKS 1. This invention reiates to the security probiem arising when vehicies with networked ECUs (Eiectronic Controi Units) are connected to the internet as shown in figure 1. A vehicie today commoniy consists of one or more embedded networks 1 such as CAN (controiier Area Network) to which many ECUs 3 are attached. These ECUs communicate to provide vehicie controi functions (inciuding anti-iock braking, assisted steering, engine management, door iocks, airbags, etc.). A common trend is to connect an ECU 2 to the internet 5 to provide functions such as navigation, entertainment, fieet management, and vehicie iocking. An emerging trend is for vehicie owners to convert an automobiie into an ‘Internet of Things’ vehicie by piugging a third-party internet-connected device, smartphone or iaptop 8 into a diagnostic connector 7 (sometimes this is an internet-connected smartphone iinked to the diagnostics socket via a Biuetooth adapter). Aiong with iegitimate access via the internet comes the possibiiity that maiefactors 4 may gain access to the embedded vehicie network and so to other ECUs that perform vitai functions. 2. By sending carefuiiy crafted messages masquerading as vaiid messages on the embedded network from a compromised infotainment unit or other internet-connected device a maiefactor couid cause the ECUs to maifunction and consequentiy the vehicie to maifunction. The maiefactor could induce malfunctions ranging from inducing reduced functionality (‘limp home mode’) to causing brake failure and spontaneous airbag detonation. A malefactor can multiply the effect of malfunctions by arranging a simultaneous attack on many vehicles. This could even form a military attack on a country as thousands of stopped vehicles across a road network would effectively jam the transport infrastructure of the country. A malefactor may also listen to traffic broadcast on the bus and exfiltrate over the internet connection sensitive information about the owner or driver of the vehicle (such as vehicle position). 3. One approach to mitigating the security risks described above is to improve the security of the internet-connected ECU using well-known techniques (such as cryptographically secure authorisation). This may be a necessary activity but it will not be sufficient: all complex computer systems have contained serious vulnerabilities and more continue to emerge.

Modern infotainment systems in vehicles are so complex that there is no realistic possibility of making them completely secure against all possible attacks by a sufficiently well resourced malefactor. 4. The approach of the invention described herein is to place between an internet-connected unit and the network a small and simple firewall device to filter the flow of messages such that invalid messages are discarded. The firewall device can be engineered to not contain vulnerabilities so that when the internet-connected device is compromised the extent of the breach is confined to the internet-connected device itself and no disruption of the vehicle control network can occur. 5. The invention will be described by referring to the accompanying drawings. The components of the invention are shown in figure 2. 6. In figure 2 the unit connected to the internet 1 is connected not to the main vehicle bus 4 called the ‘inside bus’ but to a bus assumed to be insecure 2 called the ‘outside bus’. The outside and inside buses can run at different baud rates and use different protocols (for example, the outside bus might be a CAN bus and the inside network might be the more advanced CAN FD bus). The firewall 3 forms the bridge between the outside bus and the inside bus. The firewall is preconfigured as to which traffic on one bus is intended to be seen by units on another bus. 7. This is shown in figure 3. The firewall consists of a bus controller 4 to send and receive messages in accordance with the protocol of the outside bus 6, a second bus controller 3 to send and receive messages In accordance with the protocol of the inside bus 7. The rules processor 1 is a logic state machine that listens to messages seen on the inside and outside buses and uses the filtering rules in the traffic configuration table 2 applied to attributes of a message to decide whether to take that message from one bus controller and place it into the other bus controller for sending. 8. A physical interlock input 5 can be used to ensure that some operations can only take place if certain physical actions have taken place (for example by the driver turning a physical key in a lock to a particular switch position). 9. Before transferring the message to the corresponding bus controller the rules processor rewrites attributes of the message according to optional rewrite rules included in the traffic configuration table. 10. One aspect of the invention is the physical packaging where the firewall device comprises a small number of discrete components embedded inside the connector at the end of the cable harness connecting an ECU to the vehicle. This allows an existing CAN bus ECU to be interfaced to the inside bus of a vehicle without requiring any hardware or software changes to the ECU. 11. The rules processor may be implemented by any logic hardware but the preferred embodiment of the invention is to use a general purpose microcontroller (MCU) programmed with firmware but including specific hardware logic to speed up certain CPU-intensive processing in order to minimise the production cost of the unit. 12. The process of configuring a firewall device is shown in figure 4. 13. The system designer 6 produces a table data file 5 that describes the messaging pattern on the bus. In a typical embodiment of the invention this process is done with a combination of automation tools such as a data dictionary importer and a configurator that takes human-readable definitions and produces binary table data. 14. A firewall programming tool 4 communicates with the firewall over the inside bus 2 and carries out a file transfer protocol to upload the table data into the firewall traffic configuration table 1 inside the firewall 7. In the preferred embodiment of the invention the programming tool is a general purpose computer with connectivity to the inside bus and runs application software to perform the file transfer. 15. The programming tool is typically connected to the inside bus via a connecting cable 3 to the vehicle in the factory when performing programming during manufacturing and in a maintenance workshop when performing general updates to the vehicle design. 16. The programming tool is also used to perform initial programming of an empty firewall. This sets key parameters for the inside bus. These parameters include the baud rate and the message identifiers that are used to communicate with the programming tool. 17. The parameters may also include symmetric or asymmetric encryption keys. These are used by the firewall to prevent tampering with the traffic configuration table by verifying the authenticity of a given programming tool when used to program the traffic configuration table and other parameters. 18. The key parameters are stored in non-volatile memory using a stable file protocol such that if there is a failure during programming then either the old or a completely written new file contents are retrieved. 19. The firewall operates a confirmation step before attempting to write new settings to its file: after the programming tool instructs the firewall to write the settings the firewall waits for some time, applies the settings and then waits for a confirmation message from the configuration tool. If the confirmation message is not received within a timeout period for reasons that include the inside bus not being able to operate at the baud rate or the programming tool crashing and losing track of the encryption keys then the firewall reverts to the original settings. The programming tool can resume communicating with the firewall and retry applying new settings. 20. If the designer configures the firewall to use encryption keys stored in its non-volatile memory then a programming tool connecting to an arbitrary vehicle network will only be able to communicate with the firewall if it uses the same keys. To aid using unique keys for each firewall an arbitrary programming tool can issue a ‘get serial number’ command without needing unique encryption keys and the firewall will respond with the serial number. This can be used to query a key database to obtain the encryption keys necessary for further access to the firewall. 21. The firewall processes a received message from either bus according to the flow shown in figure 5. In the step 1 the message is received from the bus controller. Then the message is identified 2 to determine which rules will be applied to it 3. If a rule indicates the message must be dropped then it is discarded 4. If all the rules have accepted the message and there are rewrite rules for the message then it is rewritten 5. 22. In the preferred embodiment where the bus protocol is CAN bus or CAN FD bus a message is identified by taking its CAN identifier (an 11 bit or 29 bit value) and matching against a list must-match/don’t-care masks from the traffic configuration table. 23. Once a message has been identified then a specific set of rules for that message produced by the design process and stored in the traffic configuration table are applied to determine if the message should be dropped. The categories of rules supported by the invention are now discussed. 24. One category of rule stored in the traffic configuration table extracts a subfield of the message identifier and checks to see if it falls inside or outside a defined range. It is a common use of the CAN and CAN FD buses to use a subfield of the CAN identifier to indicate a device destination or source address and this rule is used to ensure the source address of a message is valid and it can only address specific devices. It is also common for system designers to use a part of the identifier to reflect the urgency of the message. This category of rules allows the designer to restrict messages from the outside bus so that they can only reach ECUs that the internet-connected unit was designed to reach and cannot be sent with a priority that is outside a pre-defined range. 25. Another category of rules stored in the traffic configuration table extracts a part of the payload part of a message and checks to see if it falls inside or outside a defined range. It is a common use of CAN and CAN FD buses to encode source, destination and application signal definition data inside the payload. This category of rules allows the designer to restrict the messages from the outside bus to only reaching certain ECUs and only with certain application data values. 26. Another category of rules stored in the traffic configuration table defines the valid real-time properties of a message. It is common for the real-time properties of the traffic on the inside bus to be determined and controlled at design time and for an assumption to be made about the loading on the bus. In order for these assumptions to remain valid and thus for the bus to operate within design parameters there must be no overloading of the bus. This category of rules allows the designer to specify a constraint on the rate at which messages can be sent such that the inside bus remains able to handle all traffic within time constraints. The designer can employ this category of rules to detail for each message a budget for the number of times a particular message can be received in a time window and allowing for bounded variation in the periodicity or minimum resending time of a message (such variation is commonly known as the ‘jitter’). This category of rules allows the designer to configure the firewall to prevent a malefactor from flooding the inside bus with otherwise-valid messages to conduct a denial-of-service attack on the vehicle. 27. The firewall can be configured to receive special messages from ECUs on the inside bus that are not to be fonvarded to the outside bus but rather interpreted directly by the firewall itself as control commands. These control messages may instruct the firewall to enable and disable groups of messages. Another category of rules stored in the traffic configuration table determines if a given message from one bus is enabled or disabled and to drop the message If it is disabled. The traffic configuration table can be set such that certain groups can only be enabled by a control message if the interlock input is set. 28. It is common for a vehicle to operate in a number of modes, with different messages being valid in different modes. For example a remote programming function would need the bus to be flooded with messages containing new firmware data. These messages can be configured to be disabled until the vehicle is in a safe state for programming (a state verified by the interlock input) to ensure no malefactor can flood the bus with valid remote programming messages while the vehicle is not ready to be remotely programmed. 29. It is common for devices to be put into low power consumption sleep mode when the vehicle is parked and for the devices to be woken by a message being sent on the bus. The firewall supports this by accepting a control message to indicate the inside bus is being placed into sleep mode. This control message includes a time delay parameter. The rules processing will drop any messages from the outside bus that arrive before this delay expires. The time limit can be used to prevent a malefactor conducting a wake up attack (where the vehicle electronics is kept awake by repeated messages forwarded to the inside network) the control message includes a delay parameter. This allows the system to impose a dynamic rate limit on how often devices on the inside bus can be woken and so cap the electrical energy that a malefactor can drain from the vehicle’s battery. 30. After the rules processor decides to forward a message it applies optional message rewrite rules as specified in the traffic configuration table. The system designer can specify subfields of the identifier and the payload to be set to fixed values or left in place and so determine which signals from the inside bus are accessible to an internet-connected device and which are censored. 31. Another aspect of the invention is the handling of encrypted messages on the inside bus. The designer of the network may specify that some or all of the messages sent on the inside bus are encrypted. Some of those messages may be passed through to a device on the outside bus or come from a device on the outside bus. It may be that end-to-end encryption to this device is not possible or otherwise not desirable and accordingly the firewall can be configured in the traffic configuration table to decrypt and authenticate outgoing messages destined for the device and encrypt incoming messages using the encryption and authentication keys specified in the table. 32. The cryptographic protocol employed in the invention uses a symmetric encryption algorithm where the payload of a plaintext CAN bus message is concatenated with a message authentication code (MAC) and optionally a payload length code and encrypted into a 128 bit biock. In the preferred embodiment the symmetric encryption algorithm is the AES standard and the MAC code is the most significant 60 bits of a 128 bit MAC computed using the AES CBC-MAC aigorithm. 33. The ciphertext biock is transmitted as two CAN messages on the corresponding CAN bus with the iatter message having a iower priority to ensure ordered transmission. The MAC is obtained by using a MAC aigorithm appiied to piaintext comprising the originai message payioad, the CAN bus identifier of the encrypted message, and an optionai timestamp. The message is authenticated by a receiver by 1. decrypting the biock formed by concatenating the payioads of the pair of received CAN frames then 2. repeating the same MAC caicuiation as the sender and 3. comparing the received MAC with the computed MAC. If the computed and received MAC vaiues match then the message is authenticated. 34. If the optional timestamp feature is configured for the message then the timestamp is obtained by sender and receiver via a synchronised clock or other authenticated source of timestamp sequence. The timestamp updates with a periodicity significantly slower than the time taken for an encrypted message to be sent on the bus. The receiver resolves a race condition where the timestamp values used by the sender and receiver disagree because the timestamp value was updated in the time between the sender composing the MAC and the receiver receiving the MAC. To resolve this race the receiver performs a MAC calculation with the latest timestamp value and repeats the calculation with the previous timestamp value. If either calculation results in a match with the received MAC then the message is deemed to be authenticated.

Claims (16)

1. A configurable firewall device filtering traffic to an inside bus and from and inside bus as described by paragraphs 5 - 7.

2. A firewall device according to claim 1 where there is a hardware interlock to ensure that certain sets of messages are only forwarded when the vehicle is in a certain physical state as described in paragraph 8.

3. A firewall device according to claim 1 where the firewall device is embedded in an ECU cable harness as described by paragraph 10.

4. A firewall device according to claim 1 that is configurable by means of uploading rules into the firewall table as described in paragraphs 7-17.

5. A firewall device according to claim 4 where the programming tool uses stable storage to store the settings atomically as described in paragraph 18.

6. A firewall device according to claim 4 where the device and programming tool operate a confirmation protocol to ensure changes in communications settings are valid before being written to non-volatile storage as described in paragraph 19.

7. A firewall device according to claim 4 where the device sends its serial number to the programming tool without requiring the programming tool to use unique encryption keys to provide authentication as described in paragraph 20.

8. A firewall device according to claim 4 where the device identifies a message and applies a number of rules on that message before forwarding the message as described in paragraphs 21 - 23.

9. A firewall device according to claim 8 where the device may apply a rule on the range of values of subfields of the message identifier as described in paragraph 24.

10. A firewall device according to claim 8 where the device may apply a rule on the range of values of subfields of the message payload as described in paragraph 25.

11. A firewall device according to claim 8 where the device may apply a rule on the real-time arrival pattern of a message as described in paragraph 26.

12. A firewall device according to claim 8 where the device may apply a rule on the validity of groups of messages as described in paragraphs 27 - 28.

13. A firewall device according to claim 8 where the device may apply a rule on time limits for forwarding messages to an inside bus where the ECUs are in sleep mode as described by paragraph 29.

14. A firewall device according to claim 8 where the device may apply a rule to rewrite the identifier or contents of the payload or both according to paragraph 30.

15. A firewall device according to claim 8 where the device may perform encryption and decryption and authentication according to paragraph 31.

16. A firewall device according to claim 15 with an cryptographic protocol according to paragraphs 32 - 34.