Automotive Layer 2 Security
In today's In Vehicle Networks (IVN) many sensors, actuators, and control units are connected which are producing a large amount of data every second. In addition, all those sensors need to communicate with each other with strict minimum latency. Different components in the vehicles require different bandwidths and latency; they also continue to increase in complexity along with the increase in the number of ECUs used in automotive vehicles. Today’s vehicles have easily 45 but sometimes even more than 120 embedded ECUs. Therefore, different network technologies are used for cost efficiency and flexibility to fit technical and economical best. But they have one thing in common, which is weakness in security, the network technology transmits what it gets from the upper layer regardless of the content. Security usually comes on top of the communication protocols.
Security can be added at different locations in the Open Systems Interconnect (OSI) model in the system. Today’s security is mainly used at four of them to protect communication. The most relevant for in-vehicle communication are adapted between Layer 2 to 4. TLS and SecOC are used for the Transport Layer, IPsec is used at the Network Layer and MACsec and CANsec are used at the Data Link layer. In general, going up in the communication hierarchy lets signal latency go up, which could be challenging for mission-critical applications as mentioned.
The classical automotive protocols like LIN or CAN are using quite a short payload for the frames; this makes it difficult to include additional security information. Ethernet and CAN-XL can handle frames with bigger payloads which qualifies them for secured communication. In this blog, we will focus on Layer 2 security, we will not consider higher security layers like SecOC or IPsec.
Layer 2 security offers strong security and requires only a small amount of additional overhead, which makes the protocol suitable for hardware implementation. Which can then ensure the integrity, confidentiality, and authenticity of communication frames. And, when implemented in hardware, it can offload the CPU.
MACsec
The MACsec architecture comprises two components. The MACsec key agreement (MKA) protocol defined in IEEE 802.1X, which is not part of this blog, specifies the exchange of authenticated keys and the establishment of a secure channel. The second component is the IEEE 802.1AE standard which provides a Layer 2 based encryption for data confidentiality and integrity for media access independent protocols. MACsec was originally developed for LAN (Local Area Network) security. However, nowadays by using VLAN tags, MACsec can be adopted for wider networks such as WAN (Wide Area Network). So that it can support pure point-to-point (P2P) security as well end-to-end (E2E) security. In P2P mode all traffic on a network link is secured, but inside switches there is no secured communication, also the network needs to be defined carefully to prevent unsecured links on the communication path. In E2E mode the complete path between the Edge nodes is secured independently from the configuration of the network between. Figure 2 depicts a Network topology illustrating the different security links P2P and E2E.
Figure 2. Network topology
A MACsec packet is formed with an Ethernet frame by adding a Security TAG (SecTAG) and an Integrity Check Value (ICV) as shown in Figure 3.
Figure 3. MACsec frame format
ETYPE – The MACsec Ethertype is 2 bytes long, like the normal Ethertype field. But it has a fixed value of 0x88e5 to indicate that this frame is a MACsec frame
TCI – Is a 1 byte field of TAG Control Information (TCI) that contains several pieces of information. Version number (V), End Station (ES), SCI present (SC), Single Copy Broadcast (SCB), Encrypted payload (E), Changed Text (C), and Association Number (AN)
SL – Is indicating a short length frame; the field is 6 bits long and indicates the bytes between the last byte of the SecTAG and the first byte of the ICV, if that number is less than 48. Otherwise, SL is set to zero. The bit 7 and 8 of this byte is always zero.
PN – The Packet Number (4byte) is mainly used to protect against replay attacks. In each MACsec frame the PN is unique, usually an increasing number. The PN is also used as Initial Value (IV) for the Cipher Suite.
SCI – The 8 byte secure channel identifier can be used to identify to which security association the traffic belongs.
ICV – The integrity check value is attached to each MACsec frame and ensures the integrity of data. The length of ICV depends on Cipher Suite and is between 8 to 16 bytes.
As shown in Figure 3 the IEEE 802.1Q VLAN is part of the encrypted payload. To support end-to-end applications the VLAN must remain unencrypted, hence the VLAN could be optionally located outside of the encryption header. Enabling this option allows customers to configure a VLAN (802.1Q) tag to bypass the MACsec encryption; but note in this case the VLAN tag is also not part of the authentication.
Figure 4. VLAN aware MACsec frame format
MACsec generates a secure Connectivity Association (CA) between two or more trusted Hosts. Figure 6 depicts four stations attached to a shared media LAN (e.g. 10BASE-T1S). The secure CA between the three hosts, A, B, and C is created by the MACsec key agreement protocol (MKA). Each CA is supported by unidirectional Secure Channels (SCs), each SC supporting secure transmission of frames using symmetric key cryptography. Each SC is supported by an overlapped sequence of Security Associations (SAs). And, each SA uses a fresh Secure Association Key (SAK) to provide the MACsec service. As shown in Figure 5, Host D is excluded from this CA it can communicate with the other hosts, but is insecure. It does not have Secure Association Keys (SAK) that would allow it to participate in any of the Secure Association (SA) that currently support SCA, SCB, or SCC; therefore, D cannot compromise the integrity, confidentiality, or origin of any of the frames being exchanged by A, B, and C. Hosts can also use multiple SCs, for instance, each application on the host gets a different SC. Then, it also secures the applications among themselves on the same host. Each SC is identified by a Secure Channel Identifier (SCI) comprising a 48-bit MAC address concatenated with a 16-bit Port Identifier.
Figure 6. MACsec Connectivity Association
Figure 5. MACsec Secure Channel
MACsec used as default Cipher Suite the Galois/Counter Mode of Operation with the AES-128 symmetric block. Further, it supports the GCM-AES with 256-bit and the GCM-AES-XPN for 128-bit and 256-bit.
CANsec
CANsec is a new standard CiA613-2 being developed by CAN in Automation (CiA) as an extension of the newly developed CAN XL protocol, supporting higher bandwidth and longer payload of the CAN Physical layer. It specifies a Layer 2 CAN security protocol that aims to protect the integrity, freshness, authenticity of origin, and confidentiality of data in CAN-based networks. The focus of this standard is on the data link layer. The specification excludes the key agreement, the same as MACsec does. CANsec focuses on a CAN XL network, but the working group is considering optionally expanding it to CAN FD networks as well. The CANsec frame format is like the MACsec frame format: A CANsec Header is added before the payload and at the end of the payload an Integrity Check Value (ICV) is inserted. Figure 7 shows the abstract frame format.
Figure 7. CANsec frame format
- CCI – Cipher Control Information, this 11-bit are comprises the following subfields
- VN – CANsec Version Number
- CM – Cipher Mode, it specified one of the two available security operations
- 0 Authentication mode
- 1 Authenticated Encryption with Associated Data (AEAD)
- res – Reserved bits
- CSCI – CAN Secure Channel Identifier
- SCI – Secure Channel Identifier 16 bits
- AN – Association Number 1-bit
- FV – Freshness Value, truncated value of the 64-bit freshness counter
CANsec has so-called Secure Zone (SZ) which is a group of nodes that can communicate together securely. The SZ is logically comparable to the CA for MACsec. It is a logical overlay over a physical network of nodes and can cover two or more physical CAN links. The SZ is defined by a higher layer protocol. Figure 9 shows an SZ example with four nodes. The nodes A to D can communicate together, they are all connected to the same physical CAN network. Nodes A, B, and C are configured to belong to the same SZ, they can communicate securely. Node D does not belong to the same SZ. Node D cannot verify any received secured frames and cannot decrypt any received secured frame if it is encrypted.
For communication between the nodes CANsec in using Secure Channels (SC), this does not distinguish between unicast, multicast or broadcast data transfer. A connection combines different unique SC. Figure 8 shows a SZ with the SCA that is used to transmit a secured frame from node A to nodes B and C in a multicast data transfer. Node B uses SCB and Node C used respectively SCC to transmit a secured frame. A SC is identified by a Secure channel identifier (SCI). The SCI is unique through all SZ.
Figure 9. CANsec Secure Zone
Figure 8. CANsec Secure Channel
CANsec supports in addition to the Galois/Counter Mode Cipher Suite AES-GCM-128 and AES-GCM-256 also the Cipher-based Message Authentication Code (CMAC) AES-CMAC-128 and AES-CMAC-256.
Comparison and Conclusion
Layer 2 security can secure all communication on a network, this is not possible for other security concepts like IPsec. IPsec can only secure IP traffic, but not other traffic like ARP or gPTP. Layer 2 security is not limited to point-to-point security as originally defined; it supports nowadays limited end-to-end security. This is not explicitly defined for CANsec (as of today the standardization work is still ongoing) but depending on the CANsec implementation it should be possible to bypass the traffic to the next layer, for simple bridging function without decryption and encryption of the frame. Layer 2 security cannot protect against malicious Layer 3 traffic coming from a higher layer. But in this case, the ECU is already overtaken by a hacker. Nevertheless, Layer 2 security requires only a small software overhead and has very small latencies (security at line speed). For optimal performance Layer 2 security requires hardware support, which adds extra cost. Therefore, in the past, it was not mainstream, but the security hurdle becomes higher and higher. And higher layer security protocols like IPsec or SecOC are stealing the application performance of the system. That’s why Layer 2 security is becoming interesting in the automotive area these days. Today the first products with MACsec are already available. Therefore, Layer 2 security (CANsec and MACsec) can help the automotive industry to solve the performance problem of networking technology. Renesas is preparing a CANsec demonstrator and in one of the next blogs, we will then report some of our performance measurements.
The network example of CANsec and MACsec shows a lot of similarities, even the terminology is partially the same. They used slightly different parameters but the concept behind CANsec and MACsec is identical. The battle between 10BASE-T1S Ethernet and CAN-XL is still ongoing refer to CAN XL and 10BASE-T1S, but it will not be decided on the security level. Perhaps time to market could be decisive, but the market acceptance depends on customer acceptance.
Table 1. Comparison MACsec vs CANsec
References
[1]: IEEE Std 802.1AE-2006
[2] CiA 613-2 CAN XL add-on services – Part 2: Security