Figure 2.3: SA creation with IKE for network traffic protection

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Komponenten-, Schichten- und Kommunikationsarchitektur (Standard-IPsec-Architektur nach RFC 4301 und RFC 7296).
• Technischer Zweck: Etablierung und Verwaltung kryptografischer Sicherheitsassoziationen (Security Associations, SAs) über IKEv2 (Internet Key Exchange Protocol Version 2) zur transparenten Absicherung des IP-basierten Netzwerkverkehrs zwischen zwei AUTOSAR Adaptive Platform (AP) Knoten (Node A, Node B) über ein unvertrauenswürdiges Übertragungsmedium (Untrusted network).
• Funktionale Einordnung: AUTOSAR AP Communication Management & Security Framework. Verdeutlicht die strikte funktionale Trennung zwischen Control Plane (IKEv2-Signalisierung, Authentifizierung, Diffie-Hellman-Schlüsselaustausch) und Data Plane (Paketkapselung, Verschlüsselung, Integritätssicherung via AH/ESP).

2. Komponenten, Entitäten & Schnittstellen

• Knoten / Endpunkte:
  • Node A & Node B: Kommunikationsinstanzen (z. B. HPC, Telematik-Steuergerät oder Zone Controller unter AUTOSAR Adaptive OS / POSIX).
• Komponenten pro Knoten:
  • SP DB (Security Policy Database, SPD): Statische/konfigurierte Richtliniendatenbank. Definiert anhand von Selektoren (Quell-/Ziel-IP, Ports, Protokoll), welcher Datenverkehr geschützt (PROTECT), unverschlüsselt transportiert (BYPASS) oder verworfen (DISCARD) wird.
  • IKE (v2): Control-Plane-Komponente (IKE-Daemon im Userspace, z. B. strongSwan). Handhabt Authentifizierung (PSK oder X.509 via Crypto-Stack) und die dynamische Aushandlung von Schlüsselmaterial.
  • SA DB (Security Association Database, SAD): Dynamische Laufzeitdatenbank im Betriebssystem-Kernel/IP-Stack. Hält aktive SA-Einträge mit Parametern wie Security Parameter Index (SPI), Verschlüsselungs-/Authentifizierungs-Schlüsseln, Algorithmen, Replay-Window-Zählern und Timeouts.
  • IPsec: Data-Plane-Engine (Kernel-Space / Host-Stack, z. B. Linux XFRM). Führt die Transformation (ESP/AH) auf Netzwerkebene (OSI-Schicht 3) durch.
• Schnittstellen & Assoziationen:
  • SP DB → IKE (v2): Richtlinienabgleich und Trigger-Signal (ACQUIRE), wenn für zu schützenden Traffic noch keine SA existiert.
  • SP DB → IPsec: Paketfilter- und Zuordnungsschnittstelle zur Bestimmung der anwendbaren Security Policy pro IP-Paket.
  • IKE (v2) → SA DB: Programmierschnittstelle (z. B. via Netlink/XFRM oder PF_KEYv2) zur Injektion der ausgehandelten SA-Parameter.
  • SA DB → IPsec: Lookup-Schnittstelle zur Bereitstellung kryptografischer Schlüssel und Parameter anhand des SPI.
  • Key exchange (IKE v2 ↔ IKE v2): Peer-to-Peer Control-Kanal über UDP (Port 500 / 4500).
  • IKE SA: Bidirektionaler, geschützter Kontrollkanal für IKEv2-Managementnachrichten.
  • IPsec SA pair: Logisches Paar zweier unidirektionaler SAs (Inbound und Outbound) in den jeweiligen SA DBs.
  • AH/ESP protects data: Nutzdatenkanal via ESP (IP-Protokoll 50) oder AH (IP-Protokoll 51).

3. Dynamisches Verhalten & Sequenzablauf

1. Policy Trigger & State Check:
   • Eine Applikation auf Node A sendet IP-Traffic Richtung Node B.
   • Der IPsec-Stack gleicht die Header mit der SP DB ab. Trifft eine PROTECT-Regel zu, wird die SA DB nach einer passenden Outbound-SA abgefragt.
   • Liegt keine SA vor, sendet der Kernel ein Triggersignal (ACQUIRE) an den IKE (v2)-Daemon.
2. Phase 1 – IKE SA Etablierung (IKE_SA_INIT & IKE_AUTH):
   • Austausch von Diffie-Hellman-Parametern und Nonces via UDP 500 (Key exchange).
   • Gegenseitige Knoten-Authentifizierung (mittels X.509-Zertifikaten aus dem AUTOSAR Crypto Stack / Key Storage oder Pre-Shared Keys).
   • Etablierung der bidirektionalen IKE SA.
3. Phase 2 – Child SA / IPsec SA Aushandlung:
   • Innerhalb der geschützten IKE SA werden die Traffic-Selektoren, Verschlüsselungs-/Integritäts-Suiten und SPIs für die Data Plane ausgehandelt.
   • Der IKE (v2)-Daemon generiert das symmetrische Schlüsselmaterial und schreibt das gerichtete IPsec SA pair in die lokale SA DB beider Nodes.
4. Data Plane Execution:
   • Ausgehende Datenpakete werden von der IPsec-Engine gemäß Outbound-SA gekapselt (ESP/AH), signiert/verschlüsselt und über das ungesicherte Netzwerk transportiert.
   • Node B identifiziert die passende Inbound-SA anhand des SPI im ESP/AH-Header, verifiziert/entschlüsselt die Daten und prüft die Übereinstimmung mit seiner SP DB.

4. Normative Relevanz & Entwickler-Hinweise

• Architektonische Schichtentrennung: IPsec operiert auf Layer 3 transparent unterhalb der AUTOSAR Adaptive Middleware (ara::com, SOME/IP, DoIP). Applikationen benötigen keine IPsec-spezifische API-Implementierung; die Absicherung erfolgt deklarativ über das Deployment.
• Konfigurationsanforderungen (Manifeste):
  • Die Einträge der SP DB (Traffic-Selektoren, Sicherheitsanforderungen wie ESP-Encryption/Authentication) müssen im AUTOSAR Execution/Machine Deployment Manifest konsistent und symmetrisch für beide Endpunkte definiert sein.
  • IKEv2-Profile (Cipher-Suites: AES-GCM, SHA-256/384, Diffie-Hellman-Gruppen) müssen den automobilen Sicherheitsstandards (z. B. ISO/SAE 21434, FIPS) genügen.
• Crypto-Stack Integration:
  • Der IKE-Daemon muss für die Zertifikatsprüfung, Signaturgenerierung und Secret-Speicherung an das AUTOSAR Adaptive Crypto API (ara::crypto) bzw. das zugrundeliegende HSM / Secure Element angebunden sein.
• Latenz- & Echtzeitimplikationen:
  • First-Packet-Delay: Der dynamische IKEv2-Handshake erzeugt bei Kaltstart signifikante Latenzen (mehrere Roundtrips über UDP). Bei zeitkritischen Signalen ist eine Vorab-Etablierung der SAs beim Systemhochlauf (Pre-established / Early SAs) zwingend vorzusehen.
  • Re-Keying & Anti-Replay: Konfiguration von Extended Sequence Numbers (ESN, 64-Bit) verhindert SA-Überläufe bei High-Throughput-Verbindungen (Multi-Gigabit-Ethernet). Re-Keying-Schwellwerte müssen so dimensioniert sein, dass keine Kommunikationsabrisse entstehen.
• Hardware-Offloading:
  • Da die Software-Kryptotransformation (ESP) im POSIX-Kernel bei hohen Datenraten erhebliche CPU-Ressourcen bindet, sollten Entwickler IPsec-Offloading über entsprechende Hardwarebeschleuniger (SoC-Crypto-Engines oder Ethernet-MACs) in Betracht ziehen.