1. Introduction

In previous discussions, we introduced several aspects of network security technologies in in-vehicle communication, such as E2E and SecOC, but these technologies mostly focus on data validation, with the data itself still being transmitted in plaintext. As network security levels increase and Ethernet is more widely used in vehicles, we urgently need encryption methods to prevent data from being intercepted. Due to the latency requirements and deployment characteristics of in-vehicle communication, MACsec may become a more feasible solution.

---

2. What is MACsec?

MACsec, short for Media Access Control Security, is based on the 802.1AE and 802.1X protocols. Its main function is data encryption, and it also supports authentication and validat

ion. The data protected by MACsec includes Layer 2 and above in Ethernet, meaning that data such as ARP is encrypted and cannot be intercepted by network monitoring.

Compared to other encryption methods like TLS, MACsec can be implemented in hardware, resulting in lower latency and higher performance. Additionally, since MACsec encrypts data at Layer 2, it is transparent to upper-layer applications, meaning encryption can be deployed without any changes to the upper layers. This offers significant advantages when transitioning from non-encrypted to encrypted systems.

---

3. MACsec Workflow

MACsec uses symmetric encryption, and its key generation and distribution process follows the EAPOL-MKA (EAP stands for Extensible Authentication Protocol, and EAPOL is EAP over LANs; MKA is MACsec Key Agreement protocol, see IEEE Std 802.1X). The standard EAPOL-MKA process involves selecting a key server, but in the in-vehicle network, the key server is more likely to be pre-defined. Therefore, this article will not elaborate on the key server selection process (refer to IEEE 802.1X for more information) and will focus directly on how the key server generates and distributes keys.

All MACsec devices are pre-configured with a key called the CAK (Secure Connectivity Association Key), which is also known as the Pre-Shared Key. Note that the CAK itself is not used for data encryption; the actual key for data encryption is the SAK (Secure Association Key), which is derived from the CAK. The process for generating the SAK is as follows:

1) Pre-configured Key: In addition to pre-configuring the CAK, a key identifier called CKN (Connectivity Association Key Name) also needs to be configured. The CKN is an additional data parameter, and the CAK + CKN are used together in the Key Derivation Function (KDF).

2) Key Derivation: The CAK, using different derivation functions (refer to AUTOSAR SWS MACsec Key Agreement, IEEE 802.1X, NIST 800-108 for derivation functions), generates three keys: ICK (Integrity Check Value Key, used for validation), KEK (Key Encryption Key, used to encrypt the SAK), and SAK (Secure Association Key, used for actual data encryption). The ICK and KEK are fixed keys generated from CAK + CKN, and can be considered pre-known by all MACsec devices. ICK is used for process validation, KEK for SAK encryption, and SAK is generated from CAK + RNG (Random Number Generator) and is used for actual data encryption.

3) SAK Encryption: The SAK is encrypted using the KEK (refer to the AES Key Wrap algorithm in RFC 3394 for encryption) and transmitted across the Ethernet bus.

4) SAK Decryption: The peer node uses the same KEK to decrypt the SAK, which is then used for actual data encryption and decryption.

Once the SAK has been successfully distributed to MACsec nodes, Layer 2 Ethernet frames can be exchanged with encrypted data.

---

4. MACsec Frame Format

The MACsec frame format is shown in the diagram below:

The DMAC (Destination MAC), SMAC (Source MAC), and CRC (Cyclic Redundancy Check) are parts of the original Ethernet frame. The 802.1Q + payload represents the data carried by the original Ethernet frame (including the frame type), and this data is encrypted using the GCM-AES-128 (Galois/Counter Mode AES-128) algorithm (GCM-AES-256 is also supported). The ICV (Integrity Check Value) is the checksum, and SecTAG is the encryption header, which contains MACsec-related information. Its structure is as follows:

- MACsec EtherType: A fixed value of 0x88E5, indicating a MACsec frame.

- TCI (Tag Control Information): Control information.

- AN (Association Number): The association number.

- SL (Short Length): The short data length (used when the data is less than 48 bytes, see IEEE 802.1AE).

- PN (Packet Number): The packet number, used to prevent replay attacks.

- SCI (Secure Channel Identifier): Includes the PI (Port Identifier), which identifies the channel and port, typically a fixed value in simple networks.

The parsing of SecTAG is shown in the example below:

For the GCM-AES algorithm, three parameters are used: nonce (encryption vector IV), add (additional data), and tag (message authentication code), which correspond to specific fields in MACsec. The nonce corresponds to SCI + PN, add corresponds to DMAC + SMAC + SecTAG, and tag corresponds to the ICV (refer to IEEE 802.1AE).

---

5. CANoe MACsec Example

In CANoe, we establish multiple nodes: ChatClient1 and ChatClient2 establish a session with ChatServer via TCP, and their communication is independent of MACsec. The actual data on the bus is transmitted and received by Port1 of Switch_1 and Port2 of Switch_2 using Ethernet, as shown in the topology below:

Once the environment starts, Port1 and Port2 begin the SAK distribution process, and once completed, Port1 and Port2 can communicate with MACsec encryption, as shown below:

When ChatClient1 sends session data “Polelink” and ChatClient2 responds with “YES,” the data exchanged between ChatClient1 and ChatClient2 remains plaintext, as shown below:

However, the actual Ethernet data transmitted between Port1 and Port2 is fully encrypted, as shown below:

6. Conclusion

Polelink specializes in automotive electronics testing and has accumulated extensive experience in bus network diagnostic testing in collaboration with many OEMs. This article provides a brief introduction to MACsec, but there are still many details to discuss. In the future, we will share more content related to network security testing and development, and we welcome everyone to engage in further discussions.

References:

1. AUTOSAR_RS_MACsec 

2. AUTOSAR_SWS_MACsecKeyAgreement 

3. IEEE 802.1X 

4. IEEE 802.1AE 

5. [Huawei MACsec Info Finder](https://info.support.huawei.com/info-finder/encyclopedia/en/MACsec.html) 

6. [Cisco MACsec Key Agreement](https://community.cisco.com/t5/networking-knowledge-base/mka-macsec-key-agreement-exchange-on-the-wire/ta-p/4436083)