This post builds on the previous post on functional safety. That one was about how EthTrcv detects faults and contains failures. This one flips the perspective: instead of random faults, we’re now dealing with an attacker who deliberately reads, alters, or injects frames.

If you’ve ever configured a transceiver’s MDIO wiring via EthTrcvMiiInterface and EthTrcvMiiIdx, you know EthTrcv mainly as PHY housekeeping. MACsec shifts that picture slightly: on modern PHY and switch silicon, an encryption engine sits directly between the MAC and the wire — and that engine needs configuring, keying, and monitoring. A chunk of that job inevitably lands close to EthTrcv and EthSwt.

What Is MACsec?

MACsec (Media Access Control Security, IEEE 802.1AE) encrypts and authenticates Ethernet frames at Layer 2 — frame by frame, right before they leave the wire on transmit, and right after reception, before they get handed up to the higher layers.

The key difference from TLS or IPsec: MACsec sits below IP. An attacker with physical access to an Ethernet segment (a tapped cable, a compromised ECU on the same segment, a tampered connector during service) sees the full plaintext frame without MACsec — IP header, ports, payload, all of it. With MACsec, all they see is encrypted noise.

Without MACsec:
┌──────────┬─────────┬──────────────────────────┬─────┐
│ Dst MAC  │ Src MAC │  EtherType + Payload      │ FCS │
│          │         │  (IP, UDP, SOME/IP, ...)  │     │
└──────────┴─────────┴──────────────────────────┴─────┘
             ↑ fully readable by anyone on the segment

With MACsec:
┌──────────┬─────────┬────────┬───────────────────────┬─────┬─────┐
│ Dst MAC  │ Src MAC │ SecTAG │  encrypted             │ ICV │ FCS │
│          │         │        │  payload (original     │     │     │
│          │         │        │  frame + EtherType)    │     │     │
└──────────┴─────────┴────────┴───────────────────────┴─────┴─────┘
             ↑ MAC addresses stay visible          ↑ Integrity Check Value

The SecTAG (Security Tag) is an extra header inserted right after the MAC addresses. It carries, among other things, the Association Number (AN) and the Packet Number (PN) counter — the latter being the main defense against replay attacks.

The Two Security Services of MACsec

MACsec offers two separately configurable services:

ServiceEffect

Integrity (always on)

Every frame gets an ICV (Integrity Check Value, similar to a MAC/HMAC). If an attacker changes even a single bit, verification fails at the receiver and the frame gets dropped.

Confidentiality (optional)

The payload is additionally encrypted (AES-GCM). Without this mode, frames are tamper-evident but still readable in plaintext — "integrity-only" is a deliberate trade-off for networks with diagnostic or debugging requirements.

MACsec uses AES-GCM (Galois/Counter Mode) with 128 or 256-bit keys. GCM delivers encryption and authentication in a single pass (AEAD — Authenticated Encryption with Associated Data), which is significantly more efficient than separate encrypt-then-MAC schemes.

Why MACsec in the Vehicle?

A few years ago, MACsec in a car would have been an academic discussion. Two regulatory developments changed that.

UN-R155 and ISO/SAE 21434

UN-R155 requires vehicle manufacturers to run a certified Cybersecurity Management System (CSMS) as a condition of type approval in many markets. ISO/SAE 21434 supplies the technical process framework for that: a Threat Analysis and Risk Assessment (TARA) across the entire vehicle lifecycle.

The practical effect: every interface in the vehicle — including an internal Ethernet backbone between zonal controllers — has to go through a TARA. If that TARA identifies an attack vector with relevant risk, a documented countermeasure is required. Unencrypted in-vehicle Ethernet is exactly that kind of finding in a lot of TARAs.

Attack Vectors on In-Vehicle Ethernet

Attack VectorDescription

Physical access during service

Workshop access, an OBD port, or an exposed backbone connector lets someone tap an Ethernet segment with cheap off-the-shelf hardware.

Compromised ECU

An ECU taken over through an unrelated weakness (infotainment, OTA update path) can become a launchpad for reading or injecting frames on the shared segment.

Man-in-the-middle at a switch

In zonal architectures with multiple switches, a tampered or additionally spliced-in switch port is a realistic attack scenario.

Frame injection / spoofing

Without integrity protection, an attacker can inject forged frames that the receiving ECU treats as legitimate — forged SOME/IP messages or manipulated diagnostic frames, for example.

MACsec only protects the segment between two MACsec endpoints (hop-by-hop, "point-to-point" or "point-to-multipoint" depending on topology). It is not end-to-end protection across multiple switches unless those switches pass the frame through transparently rather than terminating it themselves. Network topology largely determines where MACsec endpoints need to sit.

PHY-Integrated MACsec vs. Software MACsec

MACsec can be implemented at different points in the stack. For automotive systems with hard latency and jitter requirements (gPTP, TSN), this decision is not a footnote.

CriterionPHY-/Switch-Integrated MACsecSoftware MACsec (Host CPU)

Latency

Very low (typically < 1 µs added), since encrypt/decrypt runs in the chip’s own data path

Significantly higher, depends on CPU load and interrupt latency; can reach several µs to ms

Throughput

Wire speed (100 Mbit/s to 1 Gbit/s) with no CPU load

Limited by CPU performance; often can’t sustain line rate at 1 Gbit/s

Jitter behavior

Deterministic, relevant for TSN/gPTP coexistence

Non-deterministic, depends on host CPU scheduling

Key management

Keys are written into the chip’s secure storage over SPI/MDIO registers

Keys live in host main memory or an HSM, exchanged via driver API

Integration complexity

Needs vendor-specific register access / driver extension for the chip-internal MACsec entity, controlled through the standardized Mka module

Often reuses existing crypto libraries; Mka itself is standardized, but as of R25-11 still mostly draft status

For gPTP-critical networks (see the hardware deep dive’s section on PHY latency), PHY- or switch-integrated MACsec is nearly always the only practical choice. Software MACsec on the host CPU eats exactly the timing margin that sub-microsecond synchronization needs.

Typical Chips with a MACsec Engine

A look at real silicon options found in current automotive Ethernet designs:

NXP SJA1110 — Switch with Integrated MACsec

The SJA1110 is an automotive Ethernet switch with up to 11 ports that has MACsec engines integrated directly on several ports. Typical use case: a zonal gateway where multiple domains converge and need cross-segment protection.

Zonal Controller
┌─────────────────────────────────────────┐
│              SJA1110 Switch              │
│  ┌────┐   ┌────┐   ┌────┐   ┌────┐       │
│  │Port│   │Port│   │Port│   │Port│       │
│  │ 1  │   │ 2  │   │ 3  │   │ 4  │       │
│  │MAC-│   │MAC-│   │    │   │MAC-│       │
│  │sec │   │sec │   │ -- │   │sec │       │
│  └────┘   └────┘   └────┘   └────┘       │
└─────────────────────────────────────────┘
   ↑           ↑                  ↑
 Backbone    Camera ECU     Domain Controller
 (critical)  (critical)         (critical)
                  Port 3: diagnostics, no MACsec requirement

Characteristic feature: MACsec can be enabled per port — not every link needs encryption, which keeps key management correspondingly scoped.

Switch-integrated MACsec is closely tied to the question of whether an ECU needs a switch driver at all or can get by with a plain EthTrcv. The basics of that decision — when EthSwt is used instead of EthTrcv — are covered in the EthSwt post. That matters for MACsec because a switch-based approach terminates encryption at individual ports, whereas a plain EthTrcv link always secures a single point-to-point connection.

Marvell 88Q2221 — PHY with a MACsec Option

The 88Q2221 is a 100BASE-T1/1000BASE-T1 PHY from Marvell’s automotive portfolio with an optional MACsec engine built directly into the PHY. Unlike the switch-based approach, encryption here sits right at the edge of the network — on a single point-to-point link.

ECU A                                          ECU B
┌──────────────┐                        ┌──────────────┐
│  SoC / MAC   │                        │  SoC / MAC   │
└──────┬───────┘                        └──────┬───────┘
       │ RGMII                                 │ RGMII
┌──────▼───────┐   100BASE-T1 / 1000BASE-T1     │
│  88Q2221 PHY │◄──────── encrypted ───────────►│  88Q2221 PHY
│  + MACsec    │        (SecTAG + ICV)          │  + MACsec
└──────────────┘                                └──────────────┘

Both chip examples stand in for a whole category of silicon solutions. Other vendors — Microchip’s LAN937x family with a MACsec option, Broadcom — pursue similar integration approaches. The exact register map differs, but the underlying pattern — load keys via a management interface, run the engine in the data path — is comparable across vendors.

Key Agreement — MKA (MACsec Key Agreement)

MACsec itself only defines the frame format and the crypto operations. How the keys get established between two endpoints is handled by a separate protocol: MKA (MACsec Key Agreement), specified in IEEE 802.1X-2010.

The Flow at a Glance

ECU A (MKA)                              ECU B (MKA)
    │                                         │
    │──── EAPOL-MKA: Hello / Discovery ─────►│
    │◄─── EAPOL-MKA: Hello / Discovery ───────│
    │                                         │
    │           Key Server Election           │
    │        (highest priority wins)          │
    │                                         │
    │◄─── SAK (Secure Association Key) ───────│   encrypted with CAK
    │      distributed by the key server      │   (Connectivity Association Key)
    │                                         │
    │═══ MACsec-protected communication ════►│
    │      now runs with the SAK

Key terms:

TermMeaning

CAK (Connectivity Association Key)

A pre-shared or 802.1X-derived long-term key that secures the MKA exchange itself.

CKN (CAK Name)

Identifies the CAK so both sides know which long-term key they’re using.

Key Server

One of the endpoints is elected key server based on priority and generates the actual session key.

SAK (Secure Association Key)

The session key actually used to encrypt/decrypt frames. Rotated periodically (key rotation).

The AUTOSAR Module Mka

Contrary to how it’s often presented in older sources and forum threads: there is a standalone MKA module in AUTOSAR Classic Platform — the SWS MACsec Key Agreement (Document ID 1066, module name Mka), part of the standard for a few releases now. It defines a complete functional, API, and configuration specification with its own namespace (Mka_*, ECUC_Mka_*).

As of R25-11, essentially the entire Mka SWS is tagged Status: DRAFT. The standard exists and is specified in detail, but its maturity is clearly different from established modules like EthTrcv or EthIf — tooling support and production readiness among BSW vendors typically lag behind a draft specification. Anyone starting a MACsec project today should confirm this explicitly with their BSW supplier rather than assume it.

Per the spec, Mka has three central dependencies:

ModuleRole in relation to Mka

EthIf

Configures, controls, and monitors the MACsec entity (software or hardware). EthIf reports link changes to Mka (Mka_LinkStateChange) and, after ETH_MODE_ACTIVE, delegates establishing at least one Secure Channel to the responsible Mka instance.

CSM

Protects outgoing and validates incoming MKPDUs (the MKA protocol messages themselves) and handles generation, encryption, and decryption of the SAKs.

LSduR (Link-Layer Sdu Router)

Transports MKPDUs between Mka and EthIf — the frames carrying the MKA protocol itself run over the regular AUTOSAR PDU routing path, not around EthTrcv.

Mka itself brings a broad API — among others Mka_Init, Mka_MainFunction, Mka_LinkStateChange, Mka_GetPaeStatus, Mka_GetMacSecStatistics, Mka_SetEnable/Mka_GetEnable, and the notification functions toward the actual MACsec entity (Mka_MacSecAddTxSaNotification, Mka_MacSecAddRxSaNotification, Mka_MacSecUpdateSecYNotification).

AUTOSAR & MACsec

What the Standard Currently Covers

With the Mka module, AUTOSAR Classic now covers the MKA protocol (IEEE 802.1X-2010) as a standalone, standardized BSW module — including a functional, API, and ECUC configuration specification. Also present:

  • The Crypto Service Manager (CSM) supplies the cryptographic primitives that Mka references for MKPDU protection and SAK generation (MkaCryptoIcvGenerateJobRef, MkaCryptoKeyWrapJobRef, and other job references inside MkaKayParticipant).

  • EthTrcv and EthSwt bring their own standardized MACsec parameters — EthTrcvMacSecEnabled as a capability flag ("can this hardware do MACsec at all?") plus bypass lists (EthTrcvMacSecBypassDestinationMacAddress, ..EtherType, ..Vlan) for traffic that’s meant to stay unencrypted on purpose.

  • The Secure Onboard Communication (SecOC) specification addresses payload authentication at a higher layer (for CAN or SOME/IP messages, for example) — conceptually related, but operating on a different layer than MACsec and not a substitute for it.

The division of labor is clearer than it looks at first glance: EthTrcv/EthSwt only state whether the hardware can do MACsec at all. Negotiation, key management, and status monitoring belong to Mka — with EthIf as the broker to the actual hardware.

Where Vendor-Specific Work Still Happens

Even with a standardized Mka module, gaps remain that production integrations currently close on a project- or vendor-specific basis:

AreaCurrent State

Spec maturity

Essentially the entire Mka SWS is Status: DRAFT — tool chains and BSW stacks support the standard to varying degrees, and some vendors still ship their own interim solutions

Key provisioning in the production process

MkaCryptoCknCakKeyRef points to a CsmKey — how that key first gets into secure storage on the production line isn’t part of the Mka SWS and remains a manufacturing-process concern

Chip firmware vs. host software split

For PHY-/switch-integrated MACsec, the silicon vendor decides which part of the MACsec entity runs inside the chip itself and which part is controlled from the host via EthIf/Mka — this varies substantially between vendors

Interplay with SecOC

No documented standard interplay between layer-2 protection (MACsec/Mka) and payload protection (SecOC) for redundancy or performance optimization

Anyone integrating MACsec into an existing AUTOSAR project should clarify early, with both the BSW and silicon vendor, how mature the concrete Mka implementation actually is and which part of the MACsec logic runs in the chip. A draft status in the standard doesn’t automatically mean draft status in the concrete implementation — but it doesn’t automatically mean production-ready either.

Integration: Mka, EthIf, and EthTrcv

Adding MACsec touches three modules at once — with clearly separated responsibilities. The real ARXML structure looks like this:

Mka (standalone module)
 ├── MkaGeneral                       -- module-wide configuration
 ├── MkaCipherSuites
 │    └── MkaMacSecCipherSuitePrio    -- cipher suite priority (1..4) when acting as key server
 ├── MkaCryptoAlgoConfig              -- which CSM job for which crypto operation
 └── MkaPaeInstance (1..255)          -- one instance per protected port
      ├── MkaEthIfControllerRef       -- OR: port hangs off an EthIfController
      ├── MkaSwitchPortRef            -- OR: port hangs off an EthSwtPort
      ├── MkaOnFailPermissiveMode     -- behavior when negotiation fails
      └── MkaKay (1x)
           └── MkaKayParticipant (1..255)
                ├── MkaCryptoCknCakKeyRef   -- reference to the CAK/CKN, target: CsmKey
                ├── MkaCryptoAlgoRef        -- reference to MkaCryptoAlgoConfig
                └── MkaCryptoSakKeyRef      -- reference to the SAK slot

EthTrcvConfig / EthSwtPort (unchanged, capability flags only)
 ├── EthTrcvMacSecEnabled                    -- hardware supports & enables MACsec
 ├── EthTrcvMacSecBypassDestinationMacAddress
 ├── EthTrcvMacSecBypassEtherType
 └── EthTrcvMacSecBypassVlan                 -- traffic that stays unencrypted on purpose

MkaPaeInstance references an EthIfController or EthSwtPort directly — not EthTrcvConfig. The link to EthTrcv comes in indirectly through the EthIfController → EthIfTransceiver → EthTrcvConfig chain already covered in Part 3.

MkaCryptoCknCakKeyRef does point at a CsmKey element per the spec — so the community’s hunch that the CAK ends up "somewhere" in the Crypto Service Manager was essentially right. Only the configuration location differs: the reference sits in MkaKayParticipant (inside the Mka module), not in an EthTrcv vendor extension.

Status Monitoring

Here too there’s now a standard path instead of vendor events. Mka returns connection status via Mka_GetPaeStatus as a Mka_PaeStatusType structure, which includes Mka_MkaStatusType with these real states:

EthTrcv/EthSwt level                  Mka level (Mka_MkaStatusType)
─────────────────────                 ──────────────────────────────
ETHTRCV_LINK_STATE_DOWN               MKA_STATUS_WAITING_PEER_LINK
       │                                     │
       ▼                                     ▼
ETH_MODE_ACTIVE  ──── Mka_LinkStateChange ──► MKA_STATUS_WAITING_PEER
       │              (EthIf → Mka)                 │
       │                                             ▼
       │                                      MKA_STATUS_IN_PROGRESS
       │                                             │
       │                                             ▼
       │                                      MKA_STATUS_MACSEC_RUNNING
       │                                      (SAK established, frames protected)
       ▼                                             │
ETHTRCV_LINK_STATE_DOWN   ◄──────────────────────────┘

EthIf reports every link change of the transceiver or switch port to the responsible Mka instance via Mka_LinkStateChange(MkaPaeIdx, TransceiverLinkState) — TransceiverLinkState uses the same type, EthTrcv_LinkStateType, that EthTrcv_GetLinkState also returns. Only after EthIf has been signaled a physical link-up does it delegate establishing the Secure Channel to Mka.

Relevant for application software: as long as MKA_STATUS_MACSEC_RUNNING has not been reached, security-relevant frames may not be allowed onto that link. Enforcing that policy is governed by MkaOnFailPermissiveMode — with the real literals MKA_PERMISSIVE_MODE_NEVER (port stays blocked until negotiation succeeds) and MKA_PERMISSIVE_MODE_TIMEOUT (port is released without MACsec after a configured wait time).

MKA_PERMISSIVE_MODE_TIMEOUT (MACsec is attempted, but a plaintext fallback is allowed after timeout) undermines the protection goal the moment an attacker can deliberately delay or disrupt MKA negotiation. For security-relevant paths, MKA_PERMISSIVE_MODE_NEVER with hard fail-closed behavior is the only sensible policy.

Limits and Open Questions

Latency Overhead

Even PHY-integrated MACsec is not free. The SecTAG (at least 8 bytes, up to 16 bytes in extended configurations) and the ICV (16 bytes) enlarge every frame. For small, frequent frames — typical for time-critical control communication — the relative overhead can become noticeable:

Frame without MACsec:   64 bytes (minimum size incl. FCS)
Frame with MACsec:       64 bytes payload + 8-16 bytes SecTAG + 16 bytes ICV
                        = 88-96 bytes effective transmission size
                        → roughly 35-50% overhead on small frames

For larger frames (camera streaming data close to the MTU, for example), the percentage overhead becomes much less significant.

Key Rotation in Real-Time Systems

MKA provides for periodic SAK changes (re-keying), among other reasons to limit how long a compromised key stays useful to an attacker. In a real-time system, that is not trivial:

  • During the transition between old and new SAK, both keys must briefly be accepted (a grace period) to avoid frame loss from out-of-sync states.

  • A re-keying event must not cause any noticeable disruption to gPTP synchronization or time-critical control frames.

  • The re-keying interval is a trade-off: shorter intervals raise security but also increase the frequency of potentially disruptive transition phases.

What Remains Open Despite the Mka Module

A standardized module doesn’t automatically solve every practical problem. What still stays project-specific today:

PointConsequence

Draft status of the entire Mka SWS

Uneven implementation completeness across BSW vendors, some still shipping interim/vendor solutions alongside the standard

No defined interplay with SecOC

Layer 2 protection (MACsec/Mka) and payload protection (SecOC) are configured independently, with no documented interplay for redundancy or performance optimization

Key provisioning in the production process

MkaCryptoCknCakKeyRef assumes an existing CsmKey — how the CAK first gets securely provisioned on the production line isn’t part of the Mka SWS

Chip-internal vs. host-side split

For PHY-/switch-integrated MACsec, it remains vendor-specific which part of the MACsec entity runs inside the chip and which part is controlled from the host via EthIf/Mka

Anyone starting a MACsec project today should, despite the existing Mka standard, clarify early with the BSW supplier how completely their concrete implementation already covers the draft spec — and still use the chosen PHY/switch chip’s vendor documentation as an additional source for the chip-internal MACsec entity.

Summary

TopicKey takeaway for software developers

MACsec basics

Encryption and authentication at Layer 2, frame by frame — SecTAG and ICV wrap around the original payload

Regulatory driver

UN-R155 and ISO/SAE 21434 turn in-vehicle Ethernet encryption into a TARA finding, not an optional extra

PHY-/switch- vs. software MACsec

For gPTP-/TSN-critical networks, chip-integrated MACsec is practically the only option due to latency and determinism

Real chips

NXP SJA1110 (switch-integrated), Marvell 88Q2221 (PHY-integrated) exemplify two integration philosophies

MKA in AUTOSAR

Mka is a standalone, standardized BSW module (SWS MACsec Key Agreement) — as of R25-11 still essentially in draft status

Integration: Mka, EthIf, EthTrcv

MkaPaeInstance references EthIfController/EthSwtPort directly; EthTrcv/EthSwt only supply capability flags (EthTrcvMacSecEnabled) and bypass lists, no key logic

Limits

Frame overhead on small packets, re-keying complexity in real-time systems, plus the maturity and provisioning questions around the still-young Mka standard

Next in the EthTrcv series: Migrating from 100BASE-TX to 100BASE-T1 — What Changes in the AUTOSAR Stack