CAN Newsletter magazine
This is the third part of an article series about CAN security. It summarizes some of the discussions at CiA’s security workshop and the inaugural meeting of CiA’s Interest Group (IG) “CAN cyber security”.
This article originally appeared in the September issue of the CAN Newsletter magazine 2018. This is just an excerpt.
Did you use security on Classical CAN in the past? No? If you’re like the authors, your arguments for not using security on CAN could have been along the following lines:
We did our best to refute the first argument in the first two articles of our series about CAN security [1]. This day and age, with more and more devices getting connected to the Internet either directly or indirectly, nobody should feel entirely safe anymore. Even if you still do, upcoming government regulations may force you to think otherwise.
The CiA recently established the IG “CAN cyber security” in order to harmonize definitions and propose solutions. Because generic standards and solutions for end-to-end security beyond CAN (FD) readily exist (like TLS, security for transport layer) and can easily be tunneled through segmented CAN communications, the group excluded these from their scope of work and will instead focus on lowerlevel, CAN-specific solutions that are not standardized yet. As a member of this group, we are able to present our generic, higher-layer-independent solution for a security layer – just above the CAN FD data link layer – that we also want to share with you.
While in the past CAN with its 8-byte maximum payload per frame severely limited options to include security in each frame, with CAN FD this is no longer the case. With up to 64 data bytes in a frame, it should always be possible to make room for security data like signatures. In CAN, there are basically two use cases: “small data” and “large data”. Small data, like process data in the form of sensor readings or actuator commands, is usually measured in bits and takes up a few bytes at the most. Even grouping multiple such values, you can always reserve some space in the – now much longer – CAN FD frame. Secure grouping of multiple nodes that transmit such small data is the primary concern in the interest group. Large data on the other hand, like configuration tables, logging data or firmware updates, will always need segmentation. In most cases, large data is better secured with some end-to-end method that we won’t cover here or in the interest group.
But if security is introduced to lower-level segmentation protocols regardless, the additional overhead for security should be easy to accept, even if it means not being able to use full frames for the payload. As a reminder, even in CANopen over Classical CAN and without security, segmentation would not start at nine bytes – one byte over the maximum eight bytes in a frame – but five, to leave room for the protocol overhead. As for the micro-controller performance, there are no indications that semiconductor companies are going to include CAN FD controllers in very low-end micro-controllers.
After all, they have to be able to handle not only eight times the data per frame, but also the faster data rate that the “FD” in CAN FD stands for. Typically, 32-bit cores with a core clock beyond 40 MHz are used with CAN FD – providing enough power to also run security algorithms. In addition, new micro-controllers in the roadmaps are planned to often have built-in hardware support for security algorithms like AES and others. We should take advantage of them whenever possible.
Looking at possible CAN (FD) security solutions for individual layers, we can split these into four groups as illustrated in Photo 2.
For the reminder of this article, we will focus on number 2, securing individual frames. We will have a closer look at the other solutions in future articles.
Each secure message has a security record embedded at the end of the CAN FD data field. Photo 3 shows the CAN FD frame with the location of the security record. The default security record consists of four 16-bit values:
As popular secure hash digests like SHA-256 are quite big, CANcrypt FD uses a truncated encrypted checksum as digital signature to authenticate the message. Photo 4 illustrates (download the full PDF) how it is generated (here, with a 16-bit signature and 64-bit block cipher). First, a buffer the size of the key is initialized. Instead of an all-zero initialization, it can also be based on another shared secret. For example, if the shared secret key is larger than required (e.g. 128-bit key, but using 64-bit encryption method), then the key could be split, one half used as main key, the other half as checksum initializer.
If you want to continue reading this article, you can download the PDF of Olaf Pfeiffer and Christian Keydel. Or you download the full magazine.
Sponsored links
News and reports
Emsa