Dieser Post baut auf dem vorherigen Post zu Functional Safety auf. Dort ging es darum, wie EthTrcv Fehler erkennt und Ausfälle beherrscht. Dieser Post dreht die Perspektive: Es geht nicht mehr um zufällige Fehler, sondern um einen Angreifer, der absichtlich Frames mitliest, verändert oder einspielt.

Wer schon einmal die MDIO-Anbindung eines Transceivers über EthTrcvMiiInterface und EthTrcvMiiIdx konfiguriert hat, kennt EthTrcv als reine PHY-Verwaltung. MACsec verschiebt das Bild leicht: Auf modernen PHY- und Switch-Chips sitzt eine Verschlüsselungs-Engine direkt zwischen MAC und Leitung — und diese Engine will konfiguriert, mit Schlüsseln versorgt und überwacht werden. Ein Teil dieser Aufgabe landet unweigerlich in der Nähe von EthTrcv und EthSwt.

Was ist MACsec?

MACsec (Media Access Control Security, IEEE 802.1AE) verschlüsselt und authentisiert Ethernet-Frames auf Layer 2 — Frame für Frame, bevor sie das Kabel verlassen, und direkt nach dem Empfang, bevor sie an die höheren Schichten weitergereicht werden.

Der entscheidende Unterschied zu TLS oder IPsec: MACsec sitzt unterhalb von IP. Ein Angreifer, der physischen Zugriff auf ein Ethernet-Segment hat (abgegriffenes Kabel, kompromittiertes Steuergerät im selben Segment, manipulierter Konnektor im Service-Fall), sieht ohne MACsec den kompletten Klartext-Frame inklusive IP-Header, Ports und Payload. Mit MACsec sieht er nur verschlüsseltes Rauschen.

Ohne MACsec:
┌──────────┬─────────┬──────────────────────────┬─────┐
│ Dst MAC  │ Src MAC │  EtherType + Payload      │ FCS │
│          │         │  (IP, UDP, SOME/IP, ...)  │     │
└──────────┴─────────┴──────────────────────────┴─────┘
             ↑ für jeden am Segment vollständig lesbar

Mit MACsec:
┌──────────┬─────────┬────────┬───────────────────────┬─────┬─────┐
│ Dst MAC  │ Src MAC │ SecTAG │  verschlüsselte        │ ICV │ FCS │
│          │         │        │  Payload (Original-    │     │     │
│          │         │        │  Frame + EtherType)    │     │     │
└──────────┴─────────┴────────┴───────────────────────┴─────┴─────┘
             ↑ MAC-Adressen bleiben sichtbar      ↑ Integrity Check Value

Der SecTAG (Security Tag) ist ein zusätzlicher Header direkt nach den MAC-Adressen. Er trägt unter anderem die Association Number (AN) und den Packet Number (PN) Zähler — letzterer ist der Schlüssel gegen Replay-Angriffe.

Die zwei Sicherheitsdienste von MACsec

MACsec bietet zwei getrennt konfigurierbare Dienste:

DienstWirkung

Integrity (immer aktiv)

Jeder Frame erhält einen ICV (Integrity Check Value, ähnlich einem MAC/HMAC). Verändert ein Angreifer auch nur ein Bit, schlägt die Prüfung beim Empfänger fehl und der Frame wird verworfen.

Confidentiality (optional)

Die Payload wird zusätzlich verschlüsselt (AES-GCM). Ohne diesen Modus sind Frames zwar fälschungssicher, aber weiterhin im Klartext lesbar — "Integrity-only" ist ein bewusst gewählter Kompromiss für Netze mit Diagnose- oder Debugging-Anforderungen.

MACsec verwendet AES-GCM (Galois/Counter Mode) mit 128 oder 256 Bit Schlüssellänge. GCM liefert Verschlüsselung und Authentisierung in einem Durchgang (AEAD — Authenticated Encryption with Associated Data) und ist damit deutlich effizienter als getrennte Encrypt-then-MAC-Verfahren.

Warum MACsec im Fahrzeug?

Vor einigen Jahren wäre MACsec im Auto eine akademische Diskussion gewesen. Zwei regulatorische Entwicklungen haben das geändert.

UN-R155 und ISO/SAE 21434

UN-R155 verpflichtet Fahrzeughersteller zu einem zertifizierten Cybersecurity Management System (CSMS) für die Typgenehmigung in vielen Märkten. ISO/SAE 21434 liefert dazu den technischen Prozessrahmen: Threat Analysis and Risk Assessment (TARA) über den gesamten Fahrzeug-Lebenszyklus.

Der praktische Effekt: Für jede Schnittstelle im Fahrzeug — auch für ein internes Ethernet-Backbone zwischen Zonal Controllern — muss eine TARA durchgeführt werden. Wird dabei ein Angriffsvektor mit relevantem Risiko identifiziert, braucht es eine dokumentierte Gegenmaßnahme. Unverschlüsseltes In-Vehicle Ethernet ist in vielen TARAs genau so ein Befund.

Angriffsvektoren auf In-Vehicle Ethernet

AngriffsvektorBeschreibung

Physischer Zugriff im Service-Fall

Werkstattzugang, OBD-Port oder ein offen liegender Backbone-Stecker erlauben das Anzapfen eines Ethernet-Segments mit einfacher Hardware.

Kompromittiertes Steuergerät

Ein über eine andere Schwachstelle (z. B. Infotainment, OTA-Update-Pfad) übernommenes Steuergerät kann als Ausgangspunkt dienen, um Frames auf dem geteilten Segment mitzulesen oder einzuspielen.

Man-in-the-Middle am Switch

Bei Zonal-Architekturen mit mehreren Switches ist ein manipulierter oder zusätzlich eingeschleifter Switch-Port ein realistisches Angriffsszenario.

Frame Injection / Spoofing

Ohne Integritätsschutz kann ein Angreifer gefälschte Frames einspielen, die von der Empfangs-ECU als legitim behandelt werden — etwa gefälschte SOME/IP-Nachrichten oder manipulierte Diagnose-Frames.

MACsec schützt nur das Segment zwischen zwei MACsec-Endpunkten (Hop-by-Hop, "Point-to-Point" bzw. "Point-to-Multipoint" je nach Topologie). Es ist kein Ende-zu-Ende-Schutz über mehrere Switches hinweg, sofern die Switches den Frame nicht transparent durchreichen, sondern selbst terminieren. Die Netzwerktopologie entscheidet maßgeblich, wo MACsec-Endpunkte sitzen müssen.

PHY-integriertes MACsec vs. Software-MACsec

MACsec kann an unterschiedlichen Stellen im Stack implementiert werden. Für Automotive-Systeme mit harten Latenz- und Jitter-Anforderungen (gPTP, TSN) ist diese Entscheidung keine Nebensache.

KriteriumPHY-/Switch-integriertes MACsecSoftware-MACsec (Host-CPU)

Latenz

Sehr gering (typisch < 1 µs zusätzlich), da Ver-/Entschlüsselung im Datenpfad des Chips läuft

Signifikant höher, abhängig von CPU-Last und Interrupt-Latenz; kann mehrere µs bis ms betragen

Durchsatz

Linegeschwindigkeit (100 Mbit/s bis 1 Gbit/s) ohne CPU-Last

Begrenzt durch CPU-Performance, bei 1 Gbit/s oft nicht mehr line-rate-fähig

Jitter-Verhalten

Deterministisch, relevant für TSN/gPTP-Koexistenz

Nicht-deterministisch, abhängig von Scheduling der Host-CPU

Schlüsselverwaltung

Schlüssel werden über SPI/MDIO-Register ins Chip-interne Secure-Storage geschrieben

Schlüssel liegen im Hauptspeicher bzw. HSM des Hosts, Austausch über Treiber-API

Komplexität der Integration

Vendor-spezifische Register/Treiber-Erweiterung für die Chip-interne MACsec-Entität nötig, angesteuert über das standardisierte Mka-Modul

Nutzt oft vorhandene Krypto-Bibliotheken; Mka selbst ist zwar standardisiert, aber Stand R25-11 noch im Draft-Status

Für gPTP-kritische Netze (siehe Hardware Deep Dive, Latenz durch den PHY) ist PHY- oder Switch-integriertes MACsec fast immer die einzig praktikable Wahl. Software-MACsec auf der Host-CPU frisst genau die Zeitreserven auf, die für Sub-Mikrosekunden-Synchronisation gebraucht werden.

Typische Chips mit MACsec-Engine

Ein Blick auf reale Silizium-Optionen, wie sie in aktuellen Automotive-Ethernet-Designs zu finden sind:

NXP SJA1110 — Switch mit integriertem MACsec

Der SJA1110 ist ein automotive Ethernet-Switch mit bis zu 11 Ports, der MACsec-Engines direkt an mehreren Ports integriert hat. Typischer Einsatz: Zonal Gateway, an dem mehrere Domains zusammenlaufen und segmentübergreifend geschützt werden müssen.

Zonal Controller
┌─────────────────────────────────────────┐
│              SJA1110 Switch              │
│  ┌────┐   ┌────┐   ┌────┐   ┌────┐       │
│  │Port│   │Port│   │Port│   │Port│       │
│  │ 1  │   │ 2  │   │ 3  │   │ 4  │       │
│  │MAC-│   │MAC-│   │    │   │MAC-│       │
│  │sec │   │sec │   │ -- │   │sec │       │
│  └────┘   └────┘   └────┘   └────┘       │
└─────────────────────────────────────────┘
   ↑           ↑                  ↑
 Backbone   Kamera-ECU      Domain-Controller
 (kritisch) (kritisch)      (kritisch)
                  Port 3: Diagnose, keine MACsec-Anforderung

Charakteristisch: MACsec ist port-selektiv aktivierbar — nicht jeder Link muss verschlüsselt sein, was die Schlüsselverwaltung entsprechend gezielt hält.

Switch-integriertes MACsec ist eng mit der Frage verknüpft, ob ein Steuergerät überhaupt einen Switch-Treiber braucht oder mit einem einfachen EthTrcv auskommt. Die Grundlagen dazu — wann EthSwt statt EthTrcv zum Einsatz kommt — behandelt der EthSwt-Post. Für MACsec-Betrachtungen ist das relevant, weil bei einem Switch-Ansatz die Verschlüsselung an einzelnen Ports terminiert wird, während ein reiner EthTrcv-Link immer eine Punkt-zu-Punkt-Verbindung absichert.

Marvell 88Q2221 — PHY mit MACsec-Option

Der 88Q2221 ist ein 100BASE-T1/1000BASE-T1 PHY aus Marvells Automotive-Portfolio mit optionaler MACsec-Engine direkt im PHY-Baustein. Anders als beim Switch-Ansatz sitzt die Verschlüsselung hier ganz am Rand des Netzwerks — direkt an der einzelnen Punkt-zu-Punkt-Verbindung.

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

Beide Chip-Beispiele stehen stellvertretend für eine ganze Kategorie an Silizium-Lösungen. Weitere Anbieter wie Microchip (LAN937x-Familie mit MACsec-Option) und Broadcom verfolgen ähnliche Integrationsansätze. Die konkrete Registerlandschaft unterscheidet sich, das grundlegende Muster — Schlüssel per Management-Interface einspielen, Engine im Datenpfad — ist vergleichbar.

Key Agreement — MKA (MACsec Key Agreement)

MACsec selbst definiert nur das Frame-Format und die Krypto-Operationen. Wie die Schlüssel zwischen zwei Endpunkten zustande kommen, regelt ein separates Protokoll: MKA (MACsec Key Agreement), spezifiziert in IEEE 802.1X-2010.

Der Ablauf im Überblick

ECU A (MKA)                              ECU B (MKA)
    │                                         │
    │──── EAPOL-MKA: Hello / Discovery ─────►│
    │◄─── EAPOL-MKA: Hello / Discovery ───────│
    │                                         │
    │        Key Server Election             │
    │     (höchste Priorität gewinnt)         │
    │                                         │
    │◄─── SAK (Secure Association Key) ───────│   verschlüsselt mit CAK
    │      verteilt vom Key Server            │   (Connectivity Association Key)
    │                                         │
    │═══ MACsec-geschützte Kommunikation ═══►│
    │      läuft jetzt mit SAK

Zentrale Begriffe:

BegriffBedeutung

CAK (Connectivity Association Key)

Vorab bereitgestellter (pre-shared) oder aus 802.1X abgeleiteter Langzeit-Schlüssel, der die MKA-Kommunikation selbst absichert.

CKN (CAK Name)

Identifiziert den CAK, damit beide Seiten wissen, welchen Langzeit-Schlüssel sie verwenden.

Key Server

Einer der beiden (oder mehreren) Endpunkte wird per Priorität als Key Server bestimmt und generiert den eigentlichen Sitzungsschlüssel.

SAK (Secure Association Key)

Der tatsächlich für Ver-/Entschlüsselung der Frames verwendete Sitzungsschlüssel. Wird periodisch gewechselt (Key Rotation).

Das AUTOSAR-Modul Mka

Anders als es in älteren Quellen und Foren-Threads oft dargestellt wird: Es gibt ein eigenständiges MKA-Modul in AUTOSAR Classic Platform — die SWS MACsec Key Agreement (Document ID 1066, Modulname Mka), seit einigen Releases Teil des Standards. Es definiert eine vollständige Funktions-, API- und Konfigurationsspezifikation mit eigenem Namensraum (Mka_*, ECUC_Mka_*).

Zum Zeitpunkt R25-11 steht praktisch die gesamte Mka-SWS unter Status: DRAFT. Das bedeutet: Der Standard existiert und ist detailliert spezifiziert, aber die Reife unterscheidet sich deutlich von etablierten Modulen wie EthTrcv oder EthIf — Werkzeugunterstützung und Serienreife bei den BSW-Anbietern hinken einer Draft-Spezifikation typischerweise hinterher. Wer heute ein MACsec-Projekt aufsetzt, sollte das explizit mit dem BSW-Lieferanten klären, nicht stillschweigend voraussetzen.

Laut Spezifikation hat Mka drei zentrale Abhängigkeiten:

ModulRolle im Zusammenspiel mit Mka

EthIf

Konfiguriert, steuert und überwacht die MACsec-Entität (Software oder Hardware). EthIf meldet Link-Änderungen an Mka (Mka_LinkStateChange) und delegiert nach ETH_MODE_ACTIVE die Etablierung mindestens eines Secure Channel an die zuständige Mka-Instanz.

CSM

Schützt ausgehende und validiert eingehende MKPDUs (die MKA-Protokollnachrichten selbst) und übernimmt Erzeugung, Ver- und Entschlüsselung der SAKs.

LSduR (Link-Layer Sdu Router)

Transportiert MKPDUs zwischen Mka und EthIf — die Frames, über die das MKA-Protokoll selbst läuft, laufen also über den ganz normalen AUTOSAR-PDU-Routing-Pfad, nicht an EthTrcv vorbei.

Mka selbst bringt eine breite API mit — u. a. Mka_Init, Mka_MainFunction, Mka_LinkStateChange, Mka_GetPaeStatus, Mka_GetMacSecStatistics, Mka_SetEnable/Mka_GetEnable und die Vermittlungsfunktionen zur eigentlichen MACsec-Entität (Mka_MacSecAddTxSaNotification, Mka_MacSecAddRxSaNotification, Mka_MacSecUpdateSecYNotification).

AUTOSAR & MACsec

Was der Standard aktuell abdeckt

Mit dem Mka-Modul deckt AUTOSAR Classic das MKA-Protokoll (IEEE 802.1X-2010) inzwischen als eigenständiges, standardisiertes BSW-Modul ab — inklusive Funktions-, API- und ECUC-Konfigurationsspezifikation. Zusätzlich vorhanden:

  • Der Crypto Service Manager (CSM) liefert die kryptografischen Primitiven, die Mka für MKPDU-Schutz und SAK-Erzeugung referenziert (MkaCryptoIcvGenerateJobRef, MkaCryptoKeyWrapJobRef und weitere Job-Referenzen in MkaKayParticipant).

  • EthTrcv und EthSwt bringen eigene, standardisierte MACsec-Parameter mit — EthTrcvMacSecEnabled als Fähigkeits-Flag ("kann diese Hardware MACsec?") sowie Bypass-Listen (EthTrcvMacSecBypassDestinationMacAddress, ..EtherType, ..Vlan) für Verkehr, der bewusst unverschlüsselt bleiben soll.

  • Die Secure Onboard Communication (SecOC)-Spezifikation adressiert Payload-Authentisierung auf höherer Schicht (z. B. für CAN- oder SOME/IP-Botschaften) — das ist konzeptionell verwandt, aber auf einer anderen Schicht als MACsec und kein Ersatz dafür.

Die Aufgabenteilung ist damit klarer als sie auf den ersten Blick wirkt: EthTrcv/EthSwt erklären nur, ob die Hardware MACsec kann. Aushandlung, Schlüsselverwaltung und Statusüberwachung übernimmt Mka — über EthIf als Vermittler zur konkreten Hardware.

Wo trotzdem Vendor-spezifisch gearbeitet wird

Auch mit einem standardisierten Mka-Modul bleiben Lücken, die Serienintegrationen heute projekt- oder herstellerspezifisch schließen:

BereichAktueller Stand

Reifegrad der Spezifikation

Praktisch die gesamte Mka-SWS ist Status: DRAFT — Werkzeugketten und BSW-Stacks unterstützen den Standard unterschiedlich vollständig, manche Anbieter liefern noch eigene Zwischenlösungen

Schlüssel-Provisionierung im Produktionsprozess

MkaCryptoCknCakKeyRef verweist auf einen CsmKey — wie dieser Schlüssel in der Fertigung erstmalig ins sichere Speicherelement gelangt, ist kein Teil der Mka-SWS und bleibt Sache des Produktionsprozesses

Aufteilung Chip-Firmware vs. Host-Software

Bei PHY-/Switch-integriertem MACsec entscheidet der Halbleiterhersteller, welcher Teil der MACsec-Entität selbst im Chip abläuft und welcher Teil über EthIf/Mka vom Host gesteuert wird — das unterscheidet sich zwischen Herstellern erheblich

Zusammenspiel mit SecOC

Kein dokumentiertes Standard-Zusammenspiel zwischen Layer-2-Schutz (MACsec/Mka) und Payload-Schutz (SecOC) für Redundanz- oder Performance-Optimierung

Wer MACsec in ein bestehendes AUTOSAR-Projekt integriert, sollte früh mit dem BSW- und Halbleiterhersteller klären, welchen Reifegrad die jeweilige Mka-Implementierung hat und welcher Teil der MACsec-Logik im Chip läuft. Ein Draft-Status im Standard heißt nicht automatisch Draft-Status in der konkreten Implementierung — aber eben auch nicht automatisch Serienreife.

Integration: Mka, EthIf und EthTrcv

Die Einführung von MACsec berührt drei Module gleichzeitig — mit klar getrennten Zuständigkeiten. Die reale ARXML-Struktur sieht so aus:

Mka (eigenständiges Modul)
 ├── MkaGeneral                       -- modulweite Konfiguration
 ├── MkaCipherSuites
 │    └── MkaMacSecCipherSuitePrio    -- Cipher-Suite-Priorität (1..4) bei Key-Server-Rolle
 ├── MkaCryptoAlgoConfig              -- welche CSM-Jobs für welche Krypto-Operation
 └── MkaPaeInstance (1..255)          -- eine Instanz pro geschütztem Port
      ├── MkaEthIfControllerRef       -- ODER: Port hängt an einem EthIfController
      ├── MkaSwitchPortRef            -- ODER: Port hängt an einem EthSwtPort
      ├── MkaOnFailPermissiveMode     -- Verhalten bei gescheiterter Aushandlung
      └── MkaKay (1x)
           └── MkaKayParticipant (1..255)
                ├── MkaCryptoCknCakKeyRef   -- Referenz auf CAK/CKN, Ziel: CsmKey
                ├── MkaCryptoAlgoRef        -- Referenz auf MkaCryptoAlgoConfig
                └── MkaCryptoSakKeyRef      -- Referenz auf den SAK-Slot

EthTrcvConfig / EthSwtPort (unverändert, nur Fähigkeits-Flags)
 ├── EthTrcvMacSecEnabled                    -- Hardware unterstützt & aktiviert MACsec
 ├── EthTrcvMacSecBypassDestinationMacAddress
 ├── EthTrcvMacSecBypassEtherType
 └── EthTrcvMacSecBypassVlan                 -- Verkehr, der bewusst unverschlüsselt bleibt

MkaPaeInstance referenziert also direkt einen EthIfController oder EthSwtPort — nicht EthTrcvConfig. Der Bezug zu EthTrcv entsteht indirekt über die schon aus Teil 3 bekannte Kette EthIfController → EthIfTransceiver → EthTrcvConfig.

MkaCryptoCknCakKeyRef zeigt laut Spezifikation auf ein CsmKey-Element — die Vermutung aus der Community, der CAK lande "irgendwie" im Crypto Service Manager, war also im Kern richtig. Nur die Konfigurationsstelle ist eine andere: Die Referenz sitzt in MkaKayParticipant (im Mka-Modul), nicht in einer EthTrcv-Vendor-Extension.

Statusüberwachung

Auch hier gibt es jetzt einen Standardweg statt Vendor-Events. Mka liefert den Verbindungsstatus über Mka_GetPaeStatus als Mka_PaeStatusType-Struktur zurück; darin enthalten ist unter anderem Mka_MkaStatusType mit den realen Zuständen:

EthTrcv/EthSwt-Ebene                 Mka-Ebene (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 etabliert, Frames geschützt)
       ▼                                             │
ETHTRCV_LINK_STATE_DOWN   ◄──────────────────────────┘

EthIf meldet jede Link-Änderung des Transceivers oder Switch-Ports über Mka_LinkStateChange(MkaPaeIdx, TransceiverLinkState) an die zuständige Mka-Instanz — TransceiverLinkState ist dabei vom selben Typ EthTrcv_LinkStateType, den auch EthTrcv_GetLinkState liefert. Erst nachdem EthIf den physischen Link-Up signalisiert bekommen hat, delegiert es die Etablierung des Secure Channel an Mka.

Für die Applikationssoftware relevant: Solange MKA_STATUS_MACSEC_RUNNING nicht erreicht ist, dürfen unter Umständen keine sicherheitsrelevanten Frames über diesen Link gesendet werden. Die Durchsetzung dieser Policy regelt MkaOnFailPermissiveMode — real mit den Literalen MKA_PERMISSIVE_MODE_NEVER (Port bleibt bis zur erfolgreichen Aushandlung gesperrt) und MKA_PERMISSIVE_MODE_TIMEOUT (Port wird nach konfigurierter Wartezeit auch ohne MACsec freigegeben).

MKA_PERMISSIVE_MODE_TIMEOUT (MACsec wird versucht, nach Timeout aber ein Klartext-Fallback erlaubt) untergräbt den Schutzzweck, sobald ein Angreifer die MKA-Aushandlung gezielt verzögern oder stören kann. Für sicherheitsrelevante Pfade ist MKA_PERMISSIVE_MODE_NEVER mit hartem Fail-Closed-Verhalten die einzig sinnvolle Policy.

Grenzen und offene Fragen

Latenz-Overhead

Auch PHY-integriertes MACsec ist nicht kostenlos. Der SecTAG (mindestens 8, bei erweiterten Konfigurationen bis zu 16 Byte) und der ICV (16 Byte) vergrößern jeden Frame. Bei kleinen, häufigen Frames — typisch für zeitkritische Steuerungskommunikation — kann der relative Overhead spürbar werden:

Frame ohne MACsec:     64 Byte (Minimalgröße inkl. FCS)
Frame mit MACsec:       64 Byte Payload + 8-16 Byte SecTAG + 16 Byte ICV
                       = 88-96 Byte effektive Übertragungsgröße
                       → ca. 35-50 % Overhead bei kleinen Frames

Bei größeren Frames (z. B. Kamera-Streaming-Daten nahe der MTU) relativiert sich der prozentuale Overhead deutlich.

Key Rotation in Echtzeitsystemen

MKA sieht periodische SAK-Wechsel vor (Re-Keying), unter anderem um die Angriffsfläche eines kompromittierten Schlüssels zeitlich zu begrenzen. In einem Echtzeitsystem ist das nicht trivial:

  • Während des Übergangs zwischen altem und neuem SAK müssen kurzzeitig beide Schlüssel akzeptiert werden (Grace Period), um Frame-Verluste durch Out-of-Sync-Zustände zu vermeiden.

  • Ein Re-Keying-Vorgang darf keine spürbare Unterbrechung für gPTP-Synchronisation oder zeitkritische Steuerungsframes verursachen.

  • Die Re-Keying-Periode ist ein Trade-off: kurze Intervalle erhöhen die Sicherheit, aber auch die Häufigkeit potenziell störender Übergangsphasen.

Was trotz Mka-Modul offen bleibt

Ein standardisiertes Modul löst nicht automatisch jedes praktische Problem. Was aktuell noch projektspezifisch bleibt:

PunktKonsequenz

Draft-Status der gesamten Mka-SWS

Unterschiedlich vollständige Umsetzung zwischen BSW-Anbietern, teils noch Interims-/Vendor-Lösungen parallel zum Standard

Kein definiertes Zusammenspiel mit SecOC

Layer-2-Schutz (MACsec/Mka) und Payload-Schutz (SecOC) werden unabhängig konfiguriert, ohne dokumentiertes Zusammenspiel für Redundanz- oder Performance-Optimierung

Schlüssel-Provisionierung im Produktionsprozess

MkaCryptoCknCakKeyRef setzt einen bereits vorhandenen CsmKey voraus — wie der CAK erstmalig sicher in der Fertigung eingebracht wird, ist kein Teil der Mka-SWS

Chip-interne vs. host-seitige Aufteilung

Bei PHY-/Switch-integriertem MACsec bleibt herstellerspezifisch, welcher Teil der MACsec-Entität im Chip selbst und welcher über EthIf/Mka vom Host gesteuert wird

Wer heute ein MACsec-Projekt startet, sollte trotz vorhandenem Mka-Standard früh mit dem BSW-Lieferanten klären, wie weit dessen konkrete Implementierung den Draft-Stand bereits abbildet — und die Vendor-Dokumentation des gewählten PHY-/Switch-Chips für die Chip-interne MACsec-Entität als zusätzliche Quelle heranziehen.

Zusammenfassung

ThemaKernaussage für Software-Entwickler

MACsec-Grundlagen

Verschlüsselung und Authentisierung auf Layer 2, Frame für Frame — SecTAG und ICV umschließen die Original-Payload

Regulatorischer Treiber

UN-R155 und ISO/SAE 21434 machen In-Vehicle-Ethernet-Verschlüsselung zu einem TARA-Ergebnis, nicht zur Kür

PHY-/Switch- vs. Software-MACsec

Für gPTP-/TSN-kritische Netze ist Chip-integriertes MACsec praktisch alternativlos wegen Latenz und Determinismus

Reale Chips

NXP SJA1110 (Switch-integriert), Marvell 88Q2221 (PHY-integriert) stehen exemplarisch für zwei Integrationsphilosophien

MKA in AUTOSAR

Mka ist ein eigenständiges, standardisiertes BSW-Modul (SWS MACsec Key Agreement) — Stand R25-11 allerdings praktisch vollständig im Draft-Status

Integration: Mka, EthIf, EthTrcv

MkaPaeInstance referenziert EthIfController/EthSwtPort direkt; EthTrcv/EthSwt liefern nur Fähigkeits-Flags (EthTrcvMacSecEnabled) und Bypass-Listen, keine Schlüssellogik

Grenzen

Frame-Overhead bei kleinen Paketen, Re-Keying-Komplexität in Echtzeitsystemen, plus die Reifegrad- und Provisionierungsfragen rund um den noch jungen Mka-Standard

Weiter in der EthTrcv-Serie: Migration von 100BASE-TX zu 100BASE-T1 — Was sich im AUTOSAR-Stack ändert