Automotive Ethernet Security Using MACsec

By Comcores

Automotive Architecture

The traditional automotive architecture, which assigns a dedicated Electronic Control Unit (ECU) to each vehicle function and connects them through protocols like CAN, LIN, and FlexRay, can no longer support modern vehicles’ needs. Not only has the number of needed ECUs exploded to support the growing functionality expected by today’s vehicles, but the wiring harness to facilitate communication has also reached an unsustainable size and complexity. Modern vehicles equipped with ADAS features—such as adaptive cruise control, lane assist, and automatic parking—rely on sensors like lidar, radar, and cameras that demand higher bandwidth than CAN, LIN, and FlexRay are able to support. For future self-driving (autonomous) vehicles, it is essential to support the high bandwidth communication and powerful processing required for their operation.

Figure 1: Next generation automotive architecture

To help address the bandwidth challenge, the next-generation automotive architecture is adopting an Ethernet packet-based network for all in-vehicle communication. Indeed, Ethernet has sufficient bandwidth, but it doesn’t natively provide the reliable and low-latency communication needed by the many real-time applications in a vehicle. The solution is to introduce Time Sensitive Networking (TSN). TSN is a collection of IEEE standards, that ensures precise timing and guaranteed delivery of critical data by implementing features such as time synchronization, traffic prioritization, and bounded low latency. It’s an addition to the existing IEEE 802.3 standard for Ethernet and Ethernet with TSN capabilities is often referred to as TSN Ethernet.

TSN Ethernet combined with the introduction of high-performance central processing units enables larger vertical integration of the many ECUs and supports the notion of the software-defined vehicle.

In general, the next-generation automotive architecture can contain the following different types of Ethernet-enabled devices:

End Station	Gateway	Bridged End Station/Gateway	Bridge
Connects various vehicle sensors and actuators, such as radars, cameras, motors, and lights, to the in-vehicle TSN Ethernet network	A network device that enables non-Ethernet enabled devices, like legacy ECUs, to connect to a TSN Ethernet network infrastructure	This enables the implementation of a daisy-chain network topology, along with traditional CAN and LIN networks used for connecting to different legacy sensors and actuators to TSN Ethernet network infrastructure	A network device that forwards data between different segments of an in-vehicle TSN Ethernet network

TSN Ethernet is superior to the legacy automotive communication protocols on bandwidth and security. Not only can it support bandwidths larger than 100Gbps, but it also protects against potential cyber security threats. In addition, Ethernet is the most deployed communication protocol in the world, and it has successfully been utilized across several different industries. It has a large ecosystem of standard specifications, components, devices, solutions and know-how.

Communication Protocol	Bandwidth	Security	Topology	Cabling	Messaging	Unique Features
Controller Area Network (CAN)	125Kbps – 20Mbps	Limited Optional CANsec in CAN XL	Star, Ring, Bus	Unshielded Twisted Pair (UTP)	Multi-Master	Multi-Master capabilities Robust error detection
Local Interconnect Network (LIN)	Up to 20Kbps	–	Bus	Single wire	Master-Slave	Low cost Simplicity
FlexRay	Up to 10Mbps	–	Star, Bus, Hybrid	UTP	Multi-Master	Basic redundancy Time-Triggered & Event-Triggered transmission
TSN Ethernet	10Mbps to +100Gbps	MACsec	Star, Bus, Hybrid	1x UTP xBASE-T1x 4x UTP xBASE-T	Based on IP	Time synchronization Reliability QoS IT/OT integration

The messaging scheme of Ethernet is based on the exchange of Ethernet frames and the Internet Protocol (IP) protocol messages. At the physical layer, the next-generation automotive architecture is adopting Single-Pair Ethernet (SPE), like 100BASE-T1 and 1000BASE-T1, to reduce the number of wires needed in the cable harness. In some lower bandwidth scenarios, the Multidrop functionality supported by the 10BASE-T1S IEEE specification allows End Stations to share the network media to further reduce the number of required Bridges devices.

The most valuable property of TSN is that real-time critical traffic from Advanced Driver Assistance Systems (ADASs) and less critical best-effort traffic, like in-vehicle infotainment, can coexist on the same network infrastructure. To support this, the following three important TSN features are utilized in the in-vehicle network.

Timing and Synchronization: It is a key component of the TSN suite and is based on the Precision Time Protocol (PTP) as defined in IEEE 1588. The standard ensures that all devices in a network share a common sense of time with nanosecond-level precision, enabling deterministic communication is essential for automotive applications.

Traffic Shaping: Credit-Based Shapers (CBS) and Time-Aware Shapers (TAS) are two mechanisms designed to manage traffic flow and ensure deterministic communication. CBS regulates bandwidth usage by assigning credits to traffic streams, ensuring fairness and prioritizing time-sensitive traffic over lower-priority traffic. TAS provides deterministic scheduling by dividing time into repeating cycles with predefined time slots for each traffic class. This allows time-critical traffic to be transmitted without interference from other traffic, guaranteeing ultra-low latency and precise timing.

Reliability: Frame Replication and Elimination for Reliability is a TSN standard designed to enhance network reliability by ensuring data delivery despite potential failures or disruptions. This is achieved by replicating frames at the sender and transmitting them over multiple disjoint network paths. At the receiver, duplicate frames are identified and eliminated, ensuring that only one copy of each frame is processed. This redundancy ensures high availability and fault tolerance, making it particularly valuable for critical automotive applications.

Security Threats and Attacks to In-Vehicle Networks

Several security attacks target the Data Link Layer and thus compromise any data transported over a specific link in the in-vehicle network. The attacks can be instigated by a malicious actor, who has gained access to an Ethernet or CAN link in the network, either by physical access or by exploiting an existing vulnerability.

Attacks are categorized as active and passive attack. Active attacks are based on intercepting legitimate messages and performing an action with them on the respective channel. On the other hand, passive attacks are based on eavesdropping the legitimate information and not interfering the communication channel.

Figure 2 illustrates the threat scenario and attacks from a malicious actor with Layer 2 access to devices in the in-vehicle network. In this example, an attacker has gained access to the communication channel between a Control SoC and Radar, LIDAR, and Actuator ECUs.

Figure 2: In-vehicle network threat scenario

Eavesdrop and Steal

As all traffic is being broadcasted and sent in clear text an attacker can easily read all the information being exchanged. This allows an attacker to get insight into the types of traffic, nodes/devices, and even content being exchanged, such as proprietary or private data, that can be captured for postprocessing and used later for malicious purposes.

Spoof and Impersonation

Due to the lack of authentication between devices in the in-vehicle network, an attacker could pretend to be a legitimate node/device and inject fake messages into the network. This can allow an attacker to send wrong information that can lead to a wrong processing operation, and even gain control of a device by escalating higher privileges. For example, an attacker can falsify frame data coming from sensors, radars, or cameras, to activate or deactivate the break control.

An attacker could also perform attacks on the TSN operation in the in-vehicle network by injecting illegitimate high-priority packets. This impacts the scheduling mechanism by queuing and delaying legitimate high-priority traffic, and also disrupting low-priority traffic, weakening the deterministic nature of the network.

Drop and Modify

Access to the communication channel permits and attacker to masquerade as a gateway device and drop or modify messages that pass through it. ECUs, without the ability to verify the authenticity of a message, will rely on its contents which may result in performing unauthorized and abnormal actions. For example, an attacker can perform calibrated attacks by disrupting or denying service to specific sensitive frames. This allows an attacker to balance his disruption with low chances of being detected, making the vehicle fully unreliable.

Replay and Flood

An attacker can identify and store specific messages and then replay them later to the network. This can cause disruption and confusion in a device as data is now received out of order or multiple copies of the same frames are received. Furthermore, by replaying messages at a high rate, an attacker can launch a flooding attack and cause a communication link to stop functioning due to a high amount of generated traffic. For example, in a stationary car, an attacker can replay messages that can open the door, start the engine, turn on the lights, and even drive the car away.

Access to physical Ethernet links and ports can be sufficient for a malicious actor to perform the aforementioned attacks. They can result in a Denial-of-Service attack which is a serious vulnerability in in-vehicle networks. Furthermore, access to private information of the car network and systems becomes available, which violates the privacy of the car users. Therefore, there is a strong need for security mechanisms at the Ethernet level that ensure the protection of sensitive data and a reliable operation of the in-vehicle network.

MACsec Features for Automotive Ethernet

Media Access Control Security (MACsec), specified in the IEEE 802.1AE standard, is designed to provide authentication, confidentiality and integrity for data transported on point-to-point links in Local Area Network (LAN) using the Advanced Encryption Standard with Galois/Counter Mode (AES-GCM) data cryptography algorithm.

MACsec provides authentication by ensuring that only known nodes / devices are allowed to communicate on the LAN. It provides confidentiality through encryption of the data so only end-points with the correct encryption key can see the contents. Integrity is provided through a cryptographic mechanism ensuring that data has not been tampered with while in motion.

How MACsec works

MACsec operates at the Data Link Layer acting as a client of the Ethernet Media Access Control (MAC) layer. It encapsulates packets with a 16-byte MACsec SecTAG header and 16-byte Integrity Check Value (ICV) tail and uses the EtherType (0x88E5) as shown in Figure 3. In the MAC layer, the preamble and Frame Check Sequence (FCS) are added to the Ethernet frame before transmission.

The SecTAG includes a TAG Control Information/Association Number (TCI/AN) field that provides information on whether encryption is used or not, if the optional Secure Channel Identifier (SCI) is used and the SA that is in use.

The SCI specifies the Secure Channel (SC) and is a concatenation of the 48-bit source MAC address and 16-bit port identifier. The Short Length (SL) field is only used for short frames, while the Packet Number (PN) can be used to keep track of packet order and detect if packets are missing or delayed.

Figure 3: MACsec frame format

• The TAG Control Information/ Association Number (TCI/AN) specifies if encryption is used.
• The Short Length (SL) field specifies the length of the encrypted data if it is a short frame.
• The Packet Number (PN) is typically 32 bits long, but can be up to 64 bits long when eXtended Packet Number (XPN) versions are used for higher speed interfaces.
• The Secure Channel Identifier (SCI) specifies the Secure Channel (SC) and is a concatenation of the 48 bit source MAC address and a 16-bit port ID.

MACsec Authentication

In order for Ethernet-enabled devices to send MACsec frames over the in-vehicle network, they must be authenticated. Authenticated MACsec peers, such as end stations, gateways, or bridges, belong to a Connectivity Association (CA). This basically means that these MACsec peers are connected and are allowed to communicate with each other. Members of the CA identify themselves using a long-lived Connectivity Association Key (CAK) with a corresponding Connectivity Association Key Name (CKN).

Peer discovery and key negotiation

Whenever a new device is added to the in-vehicle network, which is known as the “supplicant”, the “authenticator” requests the identity of the supplicant. This process is based on the IEEE 802.1X Extensible Authentication Protocol (EAP). The EAP-over-LAN (EAPoL) protocol uses special Ethernet-based messaging with a specific EtherType (0x888E). A typical supplicant request process is shown in Figure 4.

Figure 4: MACsec key agreement process

Once the supplicant has been authenticated, a Master Session Key (MSK) is generated for the remaining communication between the supplicant and the authenticator. During the MACsec Key Agreement (MKA) process, a Key Server is elected based on the lowest pre-set key server priority value assigned to that node or with the lowest SCI value in the case of a tie. The key server is responsible for generating and distributing encryption parameters and secure key information to members of a MACsec CA.

The MSK can be used to derive the long-lived CAK, which in turn is used to generate short-live SAKs. This process above is often referred to as a dynamic key exchange. However, it is also possible to manually configure the CAK based on a pre-shared key. This can then be used to derive the Secure Association Key (SAK). This is referred to as a static key exchange.

The disadvantage of static key exchange is that keys need to be managed and configured manually, which can be burdensome for many nodes. However, for compact device implementations such as in automotive networks, it can reduce the processing burden slightly by avoiding the initial authentication process based on RADIUS.

Confidentiality

The MACsec frames are transported over virtual, unidirectional, point-to-multipoint Secure Channels (SCs), which are supported by Secure Associations (SAs). As defined by the 802.1AE standard, a “SecY “is the entity that operates the MACsec protocol on a network port. There can be one or more SecY instances on any physical port, but the SecY instance is associated with a specific virtual port. Each SecY and virtual port will have one transmit-SC and can have multiple receive-SCs. Each receive-SC corresponds to each peer associated with the SecY. Each transmit-SC and receive-SC can have up to four SA. Each SA uses a separate SAK to encrypt and authenticate frames.

The long-lived CAK is used to generate short-lived SAKs for protecting data transferred between peers. The SAKs are regularly updated based on the number of packets transmitted to make communication more secure.

MACsec is based on the AES-GCM cryptography algorithm, which provides options for 128-bit, 192-bit and 256-bit cipher suites. For MACsec, the 128-bit AES-GCM-128 cipher suite is used by default. However, there is an option to use the stronger 256-bit AES-GCM-256 cipher suite.

Integrity

MACsec not only encrypts data, but also provides integrity through an Integrity Check Value (ICV) which is a cryptographic digest function dependent on the data and the SAK. Because of this, an attacker cannot tamper with the data without the encryption key.

While MACsec encryption is optional, integrity is an integral part of MACsec. The ICV is used to authenticate all of the Ethernet frames before the FCS fields, as shown in Figure 3. This ensures that any tampering with the frame will be detected.

The Packet Number (PN) can be used by the receiver to see if a packet has been dropped, replayed or delayed. Typically, the PN is 32 bits long and is unique to the specific SA and SAK. MACsec transmits each frame in an SA with a PN that increases with each frame transmitted. Typically, the receiver will expect a packet number one higher than the last frame received, but it is possible to configure MACsec to take account of expected packet re-ordering.

MACsec in Action

Figure 5 illustrates the threat scenario discussed in “Security Threats and Attacks to In-Vehicle Networks” with MACsec enabled in each device. With MACsec, each device of the in-vehicle network is part of a MACsec Connectivity Association (CA) and authenticated using a Connectivity Association Key (CAK). Only nodes that are part of the same CA are allowed to transmit or receive Ethernet frames. In addition, each Ethernet port will have at least one Secure Association (SA) for transmit and one SA for reception of traffic from each connected device. The SA is protected by a short-lived Secure Association Key (SAK), which is derived from the long-lived CAK.

MACsec can thus authenticate the in-vehicle network devices, and ensure that only trusted nodes, e.g. Control SoC, Radar, LIDAR, and Actuator ECUs, with valid CAKs and SAKs can exchange information, preventing the addition of external malicious devices, or the impersonation of legitimate ones.

The SAKs are used as input to the AES-GCM cipher algorithms for encrypting Ethernet frames ensuring that attackers cannot see any payload contents. They are also used for integrity generating a unique ICV that ensures that any manipulation of the frames is detected immediately. As a result, all data between legitimate nodes remains confidential. In addition, using MACsec Packet Numbers (PN), all Ethernet frames that are exchanged between nodes are tracked. This ensures that re-ordering, replaying or delaying of Ethernet frames is detected.

Therefore, MACsec is a suitable security protocol to protect the TSN Ethernet-based communication between nodes in in-vehicle networks. Its security features of authentication, confidentiality, integrity, and replay protection make it robust against threats and attacks at the Data Link Layer.

Figure 5: MACsec protection in in-vehicle network

MACsec Integration in Automotive Ethernet Devices

A few different options exist for how to integrate the MACsec functionality into an automotive Ethernet device. First, the MACsec function is operating at the Data Link Layer (Layer-2) in the OSI model, along with the Media Access Control (MAC) function defined in IEEE 802.3. Hence, the MACsec function should be placed together with the MAC. Second, according to the IEEE 802.1AE specification, MACsec uses the insecure MAC Service provided by the LAN to offer the secure MAC Service to its client. In other words, from a functional perspective, the MACsec function is placed above the standard unsecured MAC service. Last, the MACsec function can be dedicated to a physical network port, or it can be a shared resource with a finite capacity, which can be used by one or more physical network ports.

Although the IEEE standard states the MACsec should be placed above the standard MAC function, many of the actual MACsec implementations have opted to place it below the standard MAC. One obvious reason for this placement is, that companies building IEEE 802.3 standalone physical layer chips (PHYs) can offer MACsec as part of their solution. This makes their PHY offering more attractive, as it enables customers to add MACsec to existing products by just upgrading the PHY chip.

Another reason is the accurate timestamping of frames used for time synchronization protocols, like IEEE 1588 PTP and IEEE 802.1AS. To ensure maximum precision, these protocols depend on accurate transmission and reception times of the various synchronization messages exchanged across the network. In general, timestamping frames as close as possible to the physical network should lead to higher precision. In addition, the one-step operation, used by the timing synchronization protocols, where the transmission time of the synchronization message is embedded directly into the actual message is another challenge. Insertion of a transmission timestamp into an already MACsec encrypted frame isn’t possible without compromising the frame integrity. Hence, to support one-step operation, frames should be timestamped prior to the MACsec and the timestamping should be performed as close as feasible to the physical network.

Figure 6: Different MACsec placements

Of course, placing the MACsec functionality below the MAC doesn’t come without a few implications.

To assess the implications of placing the MACsec functionality below the MAC, the transformation of an Ethernet frame as it is processed by the MACsec and MAC functionality will be studied. The assessment will cover both placements; MACsec placed above MAC and MACsec placed below MAC. Furthermore, the assessment will assume a Switch core or DMA engine (Switch/DMA) as the source or destination of the unprotected traffic.

Switch/DMA: In addition to user payload, the frame will also include MAC source & destination address, EtherType information and an optional VLAN TAG.

MACsec placed above MAC

The transformation of an unprotected Ethernet frame as it is being processed by MACsec and MAC functions is illustrated in Figure 7.

^{Click to enlarge}

Figure 7: Frame format – MACsec

TX direction (From Switch/DMA to physical network)

MACsec: The user payload, the EtherType field and the optional VLAN TAG will be encrypted to provide confidentiality. A Secure TAG (SecTAG) with MACsec frame-specific information and an Integrity Check Value (ICV) to ensure frame integrity are added.

MAC: If the length of the frame from the MACsec function is less than 64bytes padding bytes will be added. A Frame Check Sequence (FCS) is calculated and inserted. The Preamble and Start of Frame (SFD) are added. The MAC must ensure the minimum Interframe Gap (distance between frames) is not violated prior to forwarding the frame to the PCS/PMA layer.

RX direction (From physical network to Switch/DMA)

MAC: The Preamble and SFD are stripped. The FCS is verified and frames with an invalid FCS are marked as bad so subsequent functions know the payload can’t be trusted and should be ignored. Possible padding bytes added by the transmitting MAC will be removed.

MACsec: The integrity of the frame is validated and frames where the integrity check fails are marked as bad so appropriate actions can be taken by the subsequent functions. The MACsec SecTAG and ICV field is removed. The encrypted part of the frame is decrypted.

MACsec placed below MAC

When the MACsec function is placed below the individual transformation steps of an unprotected Ethernet frame will be different, but the result is identical to the previous case. See the Figure 8.

^{Click to enlarge}

Figure 8: Frame formats – MACsec function placed below MAC

TX direction (From Switch/DMA to physical network)

MAC: The MAC behaviour will be exactly as in the previous case, but instead of operating on the frame from the MACsec function it will now operate on the frame from the Switch/DMA controller.

MACsec: Only the user payload, the EtherType field, and the optional VLAN TAG should be encrypted to provide confidentiality. Possible padding inserted by the MAC shouldn’t be encrypted nor included in the integrity check. The Secure TAG and ICV are added. The FCS value from the MAC is no longer valid, due to the additional fields added and the encrypted payload, so a new FCS must be calculated. The minimum Interframe Gap must be fulfilled before the frame is transferred to the PCS/PMA layer.

RX direction (From physical network to Switch/DMA)

MACsec: Ignore Preamble and SFD. Validate FCS and mark the frame as bad if FCS is invalid. Perform integrity check and mark frame as bad when integrity check fails. Decrypt data and strip SecTAG and ICV. Replace the received FCS with a recalculated FCS based on the decrypted frame payload to ensure the frame isn’t declared invalid by MAC.

MAC: Standard MAC receive operation; Remove preamble and SFD, validate FCS and mark frame as bad if FCS validation fails, and strip possible padding bytes.

Implications of MACsec placement

Based on the assessment of MACsec placement several problematic areas related to additional frame overhead, duplicated MAC functions and error handling can be identified.

Additional frame overhead

The MACsec functionality will add a SecTAG and ICV field to a MACsec-protected frame and as a result, the frame overhead will increase with 32bytes. To manage this additional expansion, two options exist:

First option: The MACsec function must be able to indicate backpressure to the source of the unprotected frame.
Second option: The source of the unprotected frame must reserve sufficient space to accommodate for the additional frame overhead.

The second option can have performance implications. The MACsec function will include both a protected and an unprotected path. Only frames in the protected path will be MACsec protected and therefore require additional frame overhead. Whereas frames in the unprotected path will pass through the MACsec function unchanged. The selection of what frames to protect is done by the MACsec function. Hence, unless the source of the unprotected frames knows what frames will be protected by the MACsec function, it must reserve space to accommodate for the possible additional frame overhead for all frames. In the case of unprotected frames, this will be wasted bandwidth.

So, what are the implications of the additional frame overhead when the MACsec function is placed above the MAC? In this case, option 1 is very easy to implement. The interface between the MACsec function and the source of the unprotected frame is an internal chip interface like AXI-Stream. These types of interfaces have built-in backpressure capabilities i.e. tready signal. This enables the MACsec function to perform backpressure when needed due to the additional frame overhead.

In fact, Comcores MACsec solution utilizes backpressures to allocate MACsec overhead at the end of each frame, regardless of whether the frame is being protected or not. Hence, for both options and for both traffic types, there is a fixed overhead impact on performance, which is wasted BW for unprotected frames.

When the MACsec is placed below the MAC the story is different. The interface between the MAC and PCS/PMA is often a standard Media Independent Interface (MII). The MII comes in a variety of types depending on the supported network bandwidths and the desired number of signals. One common characteristic is that they don’t provide any kind of backpressure capabilities. In case the MAC and MACsec functions reside in the same physical chip, a proprietary backpressure signal can of course be added to allow the MACsec function to perform backpressure.

If the MAC and MACsec functions are located in two different chips a proprietary backpressure signal is no longer a viable option. In this case, the only option is to transmit an IEEE802.1 Pause Frame in the receive direction of the MAC. The reaction time from the time the MACsec function realizes that backpressure is needed, and until the MAC placed above will stop transmitting unprotected frames is extremely long, due to the nature of how IEEE802.1 Pause Frame-based flow control is designed.

To accommodate for the slow reaction time, an undesirable amount of frame buffering in the MACsec function will be required. Not only will the frame buffer increase the cost, but it will also introduce a large variable delay in the transmission path.

What about the second option when the MACsec is placed below the MAC? In this specific case, the MAC must ensure the interframe gap is large enough to accommodate the additional frame overhead from the MACsec protection, while the minimum required spacing between frames is still satisfied.

^{Click to enlarge}

Figure 9: Backpressure options as a function of MACsec

Duplicated MAC functions

The assessment of MACsec placement clearly shows how several MAC functions must be duplicated by MACsec when the MACsec function is placed below the MAC.

The main reason behind these duplicated MAC functions is the fact that the MACsec function is intended to rely on the service functions provided by the MAC. When the MACsec function is placed below the MAC, these service functions are no longer available. The only way to circumvent this is to reintroduce them in the MACsec itself or in a separate thin MAC placed above and below the MACsec function, as illustrated in Figure 10.

Figure 10: MACsec with Thin MAC placements

MACsec with MAC functions

In the transmit direction, at a minimum, the FCS must be recalculated by the MACsec function after the unprotected frame has been protected by MACsec. If the MAC and MACsec functions are connected via an external interface or the MAC function can forward unprotected frames with an invalid FCS, the FCS should also be validated by the MACsec function prior to any further processing. Without this step, the MACsec function could make an FCS errored unprotected frame valid by recalculating a new FCS. In general, if the unprotected frame has traversed an external interface, the MACsec function shouldn’t only validate the FCS, but also the overall structure of the frame, like preamble, SFD, and undersized/oversized should be validated. In addition, the MACsec function must also guarantee the minimum interframe gap is not violated when the protected frames are forwarded to the PCS/PMA.

In the receive direction, the FCS must be validated by the MACsec function before the protected frame can be processed. After the MACsec decryption and integrity check processes, a new FCS must be calculated and added to the MACsec processed frame. Furthermore, the MACsec function must ensure the interframe gap, SFD, and size of the received protected frame is correct. If needed, MACsec should ensure sufficient padding is present to avoid the frame being discarded by the MAC as an undersized frame.

MACsec with Tiny MAC

In the transmit direction, the first Thin MAC will validate the frame received from the above MAC and strip the Preamble/SFD/FCS before the frame is forwarded to the MACsec function for MACsec protection. The second Thin MAC will calculate and add an FCS, add a Preamble/SFD to the MACsec-protected frame and ensure the minimum interframe gab isn’t violated before the frame is forwarded to the PCS/PMA layer.

In the receive direction, the received MACsec-protected frame from the PCS/PMA will be validated by the first Thin MAC. The Preamble/SFD/FCS is removed before the frame is forwarded to the MACsec function. After frame decryption and integrity check, the second Thin MAC will calculate and add a new FCS as well as include a Preamble/SFD prior to forwarding the frame to the Switch/DMA.

Error handling

Due to the cut-through operation of the MACsec and MAC function, errors can be classified into two groups.

The first group covers errors which can be identified by the processing function before any frame data has been forwarded to the subsequent function. In this case, the errored frame can be discarded by the processing function without involving the subsequent function. Examples of these types of errors for the MACsec function could be: Common Port disabled, Controlled Port SecY disabled and Wrong SecTAG.

The second group includes errors that are identified by the processing function after the transfer of frame data has started to the subsequent function. In this case, the subsequent function must be made aware that the frame should be aborted. Invalid FCS, underrun scenarios and MACsec integrity check failure are examples of some of these error types.

For the second group of errors, the error indication can be implemented differently depending on the capabilities of the interconnect between the processing function and the subsequent function.

When the MACsec is placed above the MAC, the interconnect is often an AXI-Stream or similar interface, where an error can easily be indicated using a sideband error flag along with the last data transfer of the frame.

For the other case, where the MACsec function is placed below the MAC, an xMII interface, as described previously, is the typical interconnect. The MII also supports error signalling. However, the error signalling depends on the specific type of MII. Some have dedicated error signals, and some utilize special control code words to indicate an error.

Instead of using the xMII error indication, another option is to forward the frame without any error indication, while enforcing an invalid FSC in the frame. This will ensure the frame is discarded or marked as bad at the next FCS validation point.

Frame pre-emption

Frame Preemption, defined in IEEE 802.3br and IEEE 802.1Qbu, permits the interruption or preemption of lower priority frames (Preemptable traffic) transmission so that higher priority frames (Express traffic) can be dispatched. As a result, a Preemptive frame can be transmitted as a sequence of fragments if one or more Express frames become eligible for transmission while the transmission of the Preemptive frame is still ongoing.

A single MACsec Secure Entity (SecY) can’t simultaneously protect Express and Preemptable traffic in an interleaved manner. This is because the AES-GCM cryptography used in MACsec encryption is a stateful operation and interleaving is not inherently supported. This problem is addressed by using a dedicated MACsec SecY for Express and Preemptive traffic.

Again, the MACsec function can be placed before or after the preemptive MAC as shown in Figure 11.

Figure 11: Frame preemption add different MACsec

Frame Preemption, defined in IEEE 802.3br and IEEE 802.1Qbu, permits the To help understand the implications of frame preemption and the placement of the MACsec function, the frame formats of a MACsec protected Express frame and a Preemptable frame will be assessed.

As shown in Figure 12 the overall format of a MACsec-protected Express frame is identical to the formats described in the previous section.

For the preemptible frame case, the MACsec-protected frame can be split into several fragments by the preemptive MAC function. In addition to splitting the frame, the preemptive MAC must also add different preambles, Start of Frame Delimiters (SFDs), and Fragment Counts depending on the fragment type (First, Middle, or Last). Finally, a Cyclic Redundancy Check (CRC) for the First and Middle fragments and FCS for the Last fragment must be calculated and added.

One important thing to note is, that the Preemptive frame will be MACsec protected before it is potentially fragmented by the preemptive MAC and transmitted as fragments. On the receiving end, the MACsec decryption and integrity check can’t be completed before the last fragment has been received. This doesn’t pose a challenge, as the fragments from the Preemptive frame have their own MACsec SecY. Hence, any received interleaved Express frames will not interfere with the MACsec verification process.

^{Click to enlarge}

Figure 12: Frame preemption formats – MACsec function placed above MAC

When the MACsec function is placed below the Preemptive MAC, each fragment of a preemptive frame will be MACsec protected. See Figure 13 for details.

^{Click to enlarge}

Figure 13: Frame preemption formats – MACsec function placed below MAC

As a result, each received fragment can be processed by the MACsec function and forwarded to the preemptive MAC as they are received. This could have a possible advantage on latency, but the preemptive MAC can’t finalize the processing and handover of the non-fragmented preemptive frame before the last fragment has been received from the MACsec function. A possible drawback is that each MACsec-protected fragment will contain a SecTAG and an ICV and this could be considered inefficient use of the network bandwidth. Again, as described earlier, the MACsec must repeat or perform many of the MAC functionality already conducted by the MAC functions above.

Conclusion

The integration of Media Access Control Security (MACsec) into automotive Ethernet networks is a crucial step towards enhancing the security and reliability of modern vehicles. As the automotive industry transitions from traditional communication protocols to Ethernet-based networks, the need for robust security measures becomes paramount. MACsec provides authentication, confidentiality, and integrity for data transmitted over Ethernet links, protecting against various cyber threats such as eavesdropping, spoofing, and replay attacks.

The adoption of Time Sensitive Networking (TSN) Ethernet combined with MACsec offers a comprehensive solution for secure and reliable communication in automotive networks. This integration supports the industry’s move towards software-defined vehicles and the realization of fully autonomous driving capabilities.

By ensuring that only authenticated and authorized nodes/devices can communicate, MACsec maintains the integrity and confidentiality of in-vehicle communications. The placement of MACsec functionality, whether above or below the MAC layer, has implications for frame overhead, duplicated MAC functions, and error handling.

In conclusion, while the combination of TSN Ethernet and MACsec provides a robust framework for the secure and efficient operation of modern automotive networks, paving the way for the future of autonomous driving, a key consideration is also the need for a good understanding of the system requirements and the available architectural options for appropriate MACsec integration. To bridge this gap Comcores offers advanced IP solutions that seamlessly integrate both MACsec and TSN capabilities to address the security and reliability requirements outlined in this document.

By providing state-of-the-art Ethernet solutions, Comcores provides the building blocks to ensure automotive networks are safeguarded against threats while maintaining the precision and timing essential for autonomous driving applications. The comprehensive approach to automotive Ethernet solutions from Comcores not only enhances data integrity and confidentiality but also optimizes network efficiency, making Comcores an ideal partner for the industry.

To get more technical details and insights into Comcores MACsec write to sales@comcores.com or visit www.comcores.com

If you wish to download a copy of this white paper, click here