Updates

1/10/2020: added BLAKE/BLAKE2 to the HMAC section

Introduction

The CAN bus is a multi-master serial bus standard for connecting Electronic Control Units (ECUs) also known as nodes. The complexity of the node can range from a simple I/O device such as a low powered embedded/industrial microcontroller up to a computer with a CAN interface and sophisticated software and significant computational resources. Two or more nodes are required on the CAN network to communicate. CAN busses can be found in industrial settings, automobiles, aircraft, and many other industries.

There are two standards for the CAN bus. The first is high speed CAN as defined in ISO 11989-2. High speed CAN allows for bitrates of up to 1Mbit/s, or up to 5Mbit/s on CAN-FD (a newer CAN protocol in development). High speed CAN is limited to a maximum cable length of 40 meters which makes it unsuitable for many industrial applications.

The second standard is low speed/fault tolerant CAN, defined in ISO 11898-3. Low speed can allows for bitrates of up 125 kbps, with the maximum bitrate dropping with an increase in cable length. For the rest of this paper, we will assume low speed/fault tolerant CAN, though most of the considerations are the same.

The purpose of this article is to discuss the potential impacts of adding various cryptographic elements to CAN bus messages. Its purpose is NOT to propose a specific cryptographic solution, but to outline some of the potential cryptographic elements you might want to add including their benefits and drawbacks. Care was taken to propose only state of the art cryptographic elements.

The Problem

Communications security on the CAN bus is a fundamentally hard problem. The first reason why is that the bandwidth available limits the bits available to dedicate to cryptographic data. The second problem is that CAN is a linear bus with no built in authentication or authorization mechanisms. This means that only a single node can transmit at any time, and the transmitting node is controlled by the priority of the message it is sending. It also means that there is nothing stopping a node from creating fraudulent messages appearing to be from a different node address. As such the CAN protocol allows for an attacker to:

• Selectively preempt messages it does not want to be delivered
  • By listening for a specific message it wants to preempt and interrupting with a higher priority message
• Create a denial of service condition on the bus
  • By creating a stream of ‘junk’ highest priority messages
• Create (or re-play) arbitrary messages pretending to be another node on the network

These attacks, if they can be mitigated, must be mitigated at a layer above the CAN bus protocol, in the data fields of the CAN packets. However, the bandwidth limitations discussed above combined with the real time nature of CAN bus systems severely limit the options available.

Solutions

Each of the potential mitigations below have benefits and drawbacks. To understand them we must first define some key properties of communications security systems. Once we have defined the key properties, you must determine what you want to protect, how much protection it needs, and then, using that information, select the best possible protection scheme.

Properties

Confidentiality

Confidentiality, or secrecy, is the property of being able to keep a message from being read by an adversary. That is, if an attacker is listening on the CAN bus, they would not be able to read messages in their original form. This is most often achieved through the use of encryption algorithms, such as AES.

Integrity

Integrity is the property of being able to ensure or detect that a message has not been modified by unauthorized parties. This can be achieved through many different mechanisms such as a Message Authentication Code (MAC), Hash Based Message Authentication Code (HMAC), cryptographic signature, or by using an authenticated encryption mode (AEAD) of a cipher.

Authentication

Authentication is the process or action of verifying the identity of a user or process. That is, if you receive a message from a node on a CAN bus you can positively verify that that message came from someone who possess some secret. If secrets are shared, such as in symmetric cryptographic systems (e.g. AES) you cannot verify that a particular node is who they say it is, rather just that it came from a node who possess the secret. This is because the secret is shared and not unique to each node. However, in asymmetric/public key cryptographic systems, you can verify that a node is who it says it is because the private key should only be held by a particular node, and not shared. This property is called non-repudiation.

Information Gathering

We would ideally like the encrypt and validate every message on the CAN bus, but we most likely cannot due to bandwidth and computational constraints. So we must define what it is that we are trying to protect. The most realistic scenario is that there is a subset of CAN messages which are the most important to secure. These are usually commands which will alter the behavior of the system communicating via the CAN bus. However, if you are constrained further, you may need to only select a subset of commands which alter the behavior of the system and that relate to safety of people and/or equipment.

Once you have defined your set or subset of messages, you must determine which of the three properties defined above you need to implement. For instance: if you are transmitting some kind of sensitive piece of data over the CAN bus, confidentiality may be the prime concern. However, if it’s simply that the command is genuine, from a trusted source, you may only need Integrity and Authentication and not Confidentiality.

Confidentiality Solutions

A confidentiality only solution would comprise of only one element: encryption. That is, taking the existing data and passing it through an encryption algorithm. Both symmetric systems and asymmetric cryptographic systems allow you to encrypt data, but due to the relative slowness of asymmetric systems vs symmetric systems, symmetric systems should be preferred in most cases. Note, asymmetric systems may be used to provide non-repudiation and secure a key exchange to establish a symmetric key.

The only symmetric algorithm that should be selected without a very careful analysis by a security professional is AES. However, just selecting AES does not guarantee security. Block ciphers, such as AES also have ‘modes of operation’ and those modes each have their own benefits and drawbacks. Regardless of which mode is selected, in the context of security on a CAN bus, the primary drawback to using AES on the CAN is the message size expansion. AES works on 128, 192 or 256 bit ‘blocks’ of data, with the increase in block size also increasing the level of security. If you have 1 byte of data that you want to encrypt, you must pad that data to 16 bytes for AES 128, 24 bytes for AES 192 and 32 bytes for AES 256. What may have been a single CAN packet with 1 byte is now, at a minimum, 2 packets and 16 bytes, a 160% increase.

It is important to note that selecting a ‘Confidentiality only solution’ may still leave you open to several different types of attacks such as (but not limited to):

• Replay attacks
• Block combination attacks
• Padding oracle attacks
• Bit flipping attacks

And may require additional messaging to be defined in your communications scheme to support key exchange, IV transmission, or nonce transmission. Each of these also adds to either the message size or adds a new message type to your communications protocol.

Another important thing to consider is the impact of using encryption on low power devices. The CAN bus is often used for real time systems and the delay caused by encrypting or decrypting data transmitted on the bus may be a significant problem for your application. Your hardware may or may not have AES acceleration or be able to support the memory footprint of the extra instructions.

Integrity Solutions

There are several options for providing integrity verification to messages. They each have their benefits and drawbacks, much like the confidentiality options. One option for providing integrity is an asymmetric cryptographic signature such as DSA or ECDSA. However, these signatures may be large and expensive to compute compared to a message authentication code (MAC) based on a symmetric key. A MAC is a piece of data added to a packet that is based on a shared secret and provides integrity and authenticity. An individual MAC created for a message is called a tag.

You should note that using an integrity only solution on its own does not prevent replay attacks and will not protect the confidentiality of the data. Anyone on the bus can read the contents of the message. To prevent replay attacks you could, for instance, add a counter to the message, but must still be cautious as this isn’t a foolproof solution.

There are several different types of MACs that can be considered.

Universal Hashing Based MACs

There is really only one universal hashing based MAC that should be considered: UMAC. UMAC is defined in RFC 4418 . It produces 32, 64, 96, or 128 bit length tags (with security increasing with the length of the tag). The following section from the RFC should be read to understand the selection of the MAC length:

UMAC with truly random keys and pads then the probability that an attacker (even a computationally unbounded one) produces a correct tag for any message of its choosing is no more than 1/2^30, 1/2^60, 1/2^90, or 1/2^120 if the tags output by UMAC are of length 32, 64, 96, or 128 bits, respectively (here the symbol ^ represents exponentiation). When an attacker makes N forgery attempts, the probability of getting one or more tags right increases linearly to at most N/2^30, N/2^60, N/2^90, or N/2^120. In a real implementation of UMAC, using AES to produce keys and pads, the forgery probabilities listed above increase by a small amount related to the security of AES. As long as AES is secure, this small additive term is insignificant for any practical attack.

UMAC requires two elements to be synchronized between the two nodes who are communicating. The first is a shared secret, distribution and security of which is not covered in this paper, and the second is a nonce. A nonce is an arbitrary number that can be used only once in a particular cryptographic communication. A nonce can be sent as part of the message in plaintext but MUST NOT BE REPEATED in conjunction with a particular key.

Thus choosing to use UMAC for integrity would require 32-128 additional bits per message and either:

• A sufficiently sized random nonce such that it can be randomly generated without reuse
• A nonce scheme such as a counter + key rotation scheme

There are other universal hashing based MACs such as Poly1305, but that adds even more data than UMAC (128 bit minimum), and VMAC, which is designed for 64 bit CPUs which are unlikely to be used on a CAN bus.

If used in conjunction with a confidentiality solution (like AES), UMAC must use a different secret than that used with AES

Block Cipher based MACs

There is only one block cipher based MAC that should be considered: AES-CMAC. CBC-MAC is another block cipher based MAC that is NIST approved, but should be avoided. AES-CMAC is a NIST approved MAC specified by RFC 4493 and also called OMAC1. Its tag size is 128, 192, or 256 bits in length and is based on the AES block cipher. This means that on boards that have AES acceleration, you may get some acceleration in the calculation of this MAC.

If used in conjunction with a with a confidentiality solution (like AES), you must use a different key for the MAC and for AES.

HMAC

Hash based message authentication codes (HMAC) are another option that should be considered. HMACs are based on cryptographic hash functions such as the SHA family of hashes and a secret key. The first cryptographic hash function that should be considered is the SHA family of hashes. Due to limited bandwidth you should probably only consider SHA-1. A SHA-1 based HMAC will add 160 bits to your message. Note that the cryptogrphic attacks against SHA-1 which result in collisions do not effect the security of SHA-1 when used as an HMAC.

You may also consider BLAKE and BLAKE2. BLAKE3 was recently released as well, but at the time of writing is Rust only, which won't be suitable for many embedded devices (yet). The BLAKE family of cryptographic hash functions tends to be slightly faster than SHA-1 (see: https://blake2.net/). It also has 'Keyed Hashing' built in, which makes creating MACs very easy (and fast). BLAKE/BLAKE2 also has support for configurable digest sizes, which means it can create tags of the same size as SHA-1.

If used in conjunction with a with a confidentiality solution (like AES), you may use the same key for the MAC and for AES.

Combined Confidentiality and Integrity Modes

There are ciphers/cipher modes of operation that combine confidentiality and integrity. Ciphers that do so are called either ‘Authenticated Encryption’ (AE) or ‘Authenticated encryption with associated data’ (AEAD).

Authenticated Encryption

Authenticated encryption schemes that should be considered follow the ‘Encrypt-then-MAC’ paradigm. Use a cipher like AES in an appropriate mode of operation to produce cipher text, then put the cipher text through a MAC function. These functions should use separate keys unless an HMAC is used (such as HMAC-SHA1). The message then consists of (CipherText + MAC)

On the receiving side, the MAC tag is verified, then the data is decrypted if the tag is valid. An AES-128 cipher combined with AES-CMAC would result in a data packet with a minimum size of 256 bits (32 bytes) which is 4 CAN packets without adding any additional data (such as a counter) to prevent replay attacks.

Authenticated Encryption with associated data

There are several different AES modes that provide encryption and message integrity in one pass. There is one clear option that’s above all of the others: AES in Galois Counter Mode (AES-GCM). This mode is license free and extremely fast when compared to other AEAD modes of operation. In one pass, you can generate an AES encrypted cipher text and a MAC tag. The MAC tag produced is the same size as the block size being used with AES: 128, 192, or 256 bits. This mode will most often be preferred over encrypt-then-mac because of its speed.

If you’re curious about the other modes, I will defer to Matthew Green: Other AEAD modes

Authentication

The modes above provide authentication only in the sense that you know by virtue of being able to decrypt the message or validate a MAC (or both) that the other person has a copy of the correct key or keys. However, if you want to validate that a device is a particular device, and cannot be another device, you need non-repudiation provided by an asymmetric cryptographic system. While encrypting data (providing confidentiality) is possible with PKI, it is much slower than its symmetric counterparts (like AES), so we won’t consider if for the CAN bus. We will consider the effect of using cryptographic signing. There are two types of PKI that can be used, RSA and Elliptic Curve Cryptography (ECC). Cryptographic signatures for RSA are defined by public key cryptography standards (PKCS) and cryptographic signatures for ECC are defined by elliptic curve digital signature algorithm (ECDSA).

For ECDSA, the minimum signature size is 64 bytes (8 CAN packets).

For RSA (PKCS#1) the minimum signature size is 256 bytes (32 CAN packets).

It goes without saying that these signature sizes are quite large for a CAN bus and, while they may be required, should be used sparingly. Furthermore, they are also expensive to compute and/or verify compared to their symmetric peers.

The signature size does not include the transmission of a certificate chain, which may be required to authenticate a device, and would require a significant amount MORE data to be sent. Transmission of the certificate chain can be avoided or reduced in scope, but it requires careful design of the system, and reduces flexibility in your public key infrastructure.

Conclusions

Cryptography is hard. Cryptographic systems are even harder. The devil is in the details with each of these systems and the cost benefit analysis is non-trivial. It is extremely important to note that the primary focus of this document is NOT to provide guidance on what cryptographic elements you should choose for your cryptographic system and it does NOT provide guidance on how to build a complete cryptographic system that is immune to all attacks or even the attacks that you care most about preventing. What attacks you defend against is part of the compromises you will have to make when designing a system operating on a CAN bus. Instead, the focus of this paper was to provide information on the impact of various cryptographic elements on size of messages on the CAN bus and also discuss some of the impacts of adding these cryptographic elements on the performance of devices that will be required to perform them.

Links

1) https://github.com/CANToolz/CANToolz
2) http://illmatics.com/carhacking.html?_sm_nck=1
3) https://tools.ietf.org/html/rfc4418
4) https://blog.cryptographyengineering.com/2012/05/19/how-to-choose-authenticated-encryption/