Figure 4.3: MACsec Key Agreement sequence with pre-shared key.

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Protokoll-Ablaufdiagramm / UML-Sequenzdiagramm für das IEEE 802.1X-2010 MKA-Protokoll (MACsec Key Agreement).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Dokument AUTOSAR_AP_EXP_MACsec (Releases R23-11 bis R25-11).
• Funktionaler Zweck: Darstellung des Signalisierungs- und Schlüsselaushandlungsablaufs im Pre-Shared Key (PSK)-Modus zur Etablierung einer gesicherten Punkt-zu-Punkt-Verbindung auf Data-Link-Ebene (Layer 2, IEEE 802.1AE). Es beschreibt den Übergang von der initialen Schlüsselvereinbarung zur gesicherten Nutzdatenübertragung über die MACsec-Entity (SecY).

2. Komponenten, Entitäten & Schnittstellen

• Rollen & Akteure:
  • (Supplicant) Peer: Kommunikationsendpunkt/ECU, der als Teilnehmer agiert, seine MACsec-Fähigkeit signalisiert und den verteilten Sitzungsschlüssel empfängt und installiert.
  • (Authenticator) Key Server: Autorisierter Endpunkt/Switch/ECU, der die Kontrolle über die Schlüsselgenerierung hält und die Verteilung des Sitzungsschlüssels steuert.
• Schlüssel- und Datenstrukturen:
  • Pre-shared key (CAK) (Connectivity Association Key): Statisch vorkonfigurierter, symmetrischer Masterschlüssel (nebst zugehörigem CKN – CAK Name), der vorab auf beiden Knoten hinterlegt ist. Dient zur gegenseitigen Authentifizierung sowie zur Ableitung von KEK (Key Encrypting Key) und ICK (Integrity Check Key).
  • Distributed SAK (Security Association Key): Ephemerer, symmetrischer Sitzungsschlüssel für die Ver-/Entschlüsselung sowie Integritätssicherung des Nutzdatenverkehrs (z. B. via AES-GCM-128 oder AES-GCM-256 in der Hardware-SecY).
• Protokoll-Frames & Schnittstellen:
  • EAPoL/MKA-PDUs (EtherType 0x888E): Unverschlüsselte Kontrollnachrichten, die am MACsec-Filter vorbeigeschleust werden (Bypass).
  • MACsec protected traffic: Geschützte Ethernet-Frames (EtherType 0x88E5) mit SecTAG (Security Tag) und ICV (Integrity Check Value).

3. Dynamisches Verhalten & Sequenzablauf

1. Initialer Sicherheitszustand: Beide Instanzen verfügen über den identischen, provisionierten Pre-shared Key (CAK).
2. Key Server Ankündigung (Key Server): Der Authenticator/Key Server sendet eine MKA-PDU, deklariert seine Präsenz und beansprucht die Key-Server-Rolle (z. B. über höchste Key-Server-Priorität und SCI).
3. Fähigkeits- und Peer-Registrierung (MACsec Capable/Potential Peer): Der Supplicant/Peer empfängt die PDU, validiert diese mit dem aus dem CAK abgeleiteten ICK und antwortet mit einer MKA-PDU. Er signalisiert seine MACsec-Fähigkeit und meldet sich als potentieller Peer an (Eintrag in die Live Peer List).
4. Schlüsselgenerierung & -verteilung (Distributed SAK): Der Key Server generiert einen neuen SAK, wrappt diesen mit dem KEK (Key Wrap gemäß NIST SP 800-38F / RFC 3394) und sendet ihn innerhalb eines Distributed SAK Parameter Sets in einer MKA-PDU an den Peer.
5. Schlüsselaktivierung & Quittierung (SAK installed): Der Peer empfängt das Key-Set, un-wrappt den SAK, programmiert ihn in die lokale MACsec-Hardware (SecY Rx/Tx SAs) und quittiert die Einsatzbereitschaft via MKA an den Key Server.
6. Geschützter Datenaustausch (MACsec protected traffic): Beide Parteien schalten den Datenpfad auf den neu installierten SAK um. Der Ethernet-Verkehr wird ab diesem Zeitpunkt hardwarebeschleunigt auf Layer 2 verschlüsselt und integritätsgeschützt.

4. Normative Relevanz & Entwickler-Hinweise

• Treiber- & Hardware-Ebene (SecY / Ethernet PHY/MAC):
  • Der Ethernet-Treiber / Switch-Treiber muss Hardware-Offloading für SecY (SAK-Register, Ingress/Egress Packet Classification, SecTAG-Handling) unterstützen.
  • Es muss ein harter Layer-2-Bypass für den EAPoL-EtherType 0x888E konfiguriert sein, damit MKA-Pakete auch bei noch geschlossenem/ungesichertem MACsec-Port zur Applikation bzw. zum MKA-Daemon gelangen.
• Crypto-Stack & Key Management (ara::crypto):
  • Der CAK muss in einem manipulationssicheren Speicher liegen (HSM / Secure Storage Provider).
  • Der Crypto-Stack muss AES-CMAC (für die ICK-Prüfsummenableitung) und AES-Key-Wrap (KW/KWP nach RFC 3394 für die SAK-Kapselung) bereitstellen.
• Laufzeit- und Rekeying-Verhalten:
  • Der SAK-Wechsel (Rekeying vor Überlauf der Packet Number PN / XPN) erfordert unterbrechungsfreie Umschaltung (Hitless Rekeying). Dazu müssen Treiber und Hardware mindestens zwei parallele Security Associations (Ping-Pong-Prinzip für Ingress/Egress SA) vorhalten.
  • Scheitert der Handshake oder treten ICK-Validierungsfehler auf, muss der Port blockiert bleiben (Fail-Secure).