Figure 4.1: Communication with IPsec in AUTOSAR Adaptive Platform

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Technisches Architektur- und Schichtenmodell (Blockdiagramm) zur Darstellung der Integration von IPsec in die AUTOSAR Adaptive Platform (AP) über User-Space und Kernel-Space hinweg.
• Funktionaler Zweck: Veranschaulichung der transparenten Absicherung von Netzwerkkonversationen (Layer-3-Sicherheit via IPsec/IKE) unterhalb des AUTOSAR Adaptive Communication Managements (ara::com). Es definiert die Trennung von Steuer- und Konfigurationsebene (IKE/IPsec-Konfiguration, IKE-Daemon) und Datenebene (Kernel-IP-Stack, XFRM/IPsec-Transformationsengine, SP DB/SA DB).

2. Komponenten, Entitäten & Schnittstellen

User Space / AUTOSAR Runtime Environment

• Adaptive Application (Instanzen): POSIX-Prozesse der Anwendungsschicht. Nutzen servicespezifische Kommunikations-Endpunkte über High-Level-APIs; haben keine direkte Kenntnis über kryptografische Parameter oder IPsec-Tunnel.
• Communication Management (ara::com): AUTOSAR Adaptive Funktionscluster für Interprozess- und Netzwerkkombination (z. B. SOME/IP, DDS). Kommuniziert über Standard-POSIX-Sockets (TCP/UDP) bidirektional mit dem IP stack.
• IKE module: User-Space-Daemon zur dynamischen Schlüssel- und Authentisierungsaushandlung (IKEv2 gem. RFC 7296).
  • Nutzt Kontrollschnittstellen (z. B. Netlink XFRM/PF_KEY) zur Kernel-Interaktion.
  • Schreibt ausgehandelte Schlüsselmaterialien und Parameter in die SA DB.
• IKE config / IPsec config: Externe Konfigurationsdateien/Manifeste (AUTOSAR Execution/Machine Manifest bzw. Strongswan/Charon/IPsec-Tools Konfiguration):
  • IKE config: Parameter für IKE-Aushandlung (Preshared Keys, Zertifikate, Cipher Suites, Peer-Identitäten).
  • IPsec config: Statische Regelsätze für die Filterung und Klassifizierung (Traffic Selectors, Sicherheitsrichtlinien) sowie statische SAs.

Kernel Area (Betriebssystemkern)

• SP DB (Security Policy Database): Datenbank der Sicherheitsrichtlinien (RFC 4301). Definiert für jeden IP-Verkehr über Selektoren (IP-Adressen, Ports, Protokolle) die Aktion: PROTECT (IPsec anwenden), BYPASS (ungeschützt durchlassen) oder DISCARD (verwerfen).
• SA DB (Security Association Database): Datenbank der aktiven unidirektionalen Sicherheitsbeziehungen (SAs). Speichert kryptografische Schlüssel, SPIs (Security Parameter Index), Verschlüsselungs-/Integritätsalgorithmen und Sequence Numbers.
• IP stack: Netzwerkprotokoll-Stack des Betriebssystems. Enthält:
  • IPsec module: Ausführungseinheit für die Kapselung und Dekapselung (ESP/AH-Header, Enkryptierung/Dekryptierung, MAC-Verifikation).
  • XFRM module: Kernel-Transformationsframework (z. B. Linux Netkey/XFRM), das eingehende/ausgehende Pakete anhand der SP DB filtert und an die passende Transformation (IPsec module / SA DB) bindet.

Schnittstellen & Beziehungen

• Adaptive Application ↔ Communication Management: C++-API-Bindung (ara::com-Proxies/Skeletons).
• Communication Management ↔ IP stack: POSIX-Socket-Interface (AF_INET/AF_INET6), payload-transparent.
• IKE module ↔ IP stack / Kernel area:
  • Bidirektionaler Kanal für Policy-Events/ACQUIRE-Trigger (Kernel signalisiert Bedarf für neuen Tunnel).
  • Unidirektionaler Injektionspfad (IKE module → SA DB) zum Eintragen ausgehandelter Security Associations.
• IPsec config → SP DB: Initialer Download statischer Sicherheitsrichtlinien (z. B. beim Systemboot via setkey oder ip xfrm policy).
• SA DB / SP DB → IPsec module / XFRM module: Interne Kernel-Abfragen zur Paketverarbeitung im Sende- und Empfangspfad.

3. Dynamisches Verhalten & Sequenzablauf

A. Initialisierung & Policy Provisioning

1. Bootphase: Laden von IPsec config und IKE config durch das Basisbetriebssystem / Machine State Management.
2. Statische Initialisierung der SP DB mit Traffic Selectors für autorisierte AUTOSAR-Services (z. B. SOME/IP-Port-Ranges).
3. Start des IKE module (User-Space Daemon) zur Überwachung von Tunnel-Anforderungen.

B. Sendevorgang (Outbound Flow mit dynamischem IKE)

1. Trigger: Adaptive Application sendet Daten über ara::com; Socket schreibt Datagramm in den IP stack.
2. Policy Lookup: Der Paketfluss trifft auf das XFRM module. Abgleich mit SP DB.
3. Fall A (SA vorhanden): XFRM referenziert die passende SA in der SA DB. Das IPsec module verschlüsselt/authentifiziert das Paket (ESP/AH) und sendet es physisch über den MAC-Treiber.
4. Fall B (Keine SA aktiv - ACQUIRE):
   • Kernel verwirft oder puffert das Paket und sendet ein ACQUIRE-Signal via Netlink an das IKE module.
   • IKE module initiiert IKEv2-Handshake mit dem Remote-Peer.
   • Nach erfolgreichem Handshake pusht IKE module die generierten SAs in die SA DB.
   • Nachfolgender Traffic wird über den Pfad aus Fall A verarbeitet.

C. Empfangsvorgang (Inbound Flow)

1. IPsec-Paket trifft am Interface ein.
2. IPsec module extrahiert den SPI aus dem Header, sucht korrespondierende SA in SA DB, validiert die Sequenznummer (Anti-Replay) und entschlüsselt die Payload.
3. XFRM module prüft gegen die SP DB, ob das entschlüsselte Klartextpaket mit der hinterlegten Policy übereinstimmt (Verhinderung von Redirection/Injection).
4. Unverändertes Klartext-Paket wird über Standard-Socket-Puffer an Communication Management (ara::com) und die Zielanwendung zugestellt.

4. Normative Relevanz & Entwickler-Hinweise

• Vollständige Abstraktion für ara::com-Applikationen:
  • Applikationsentwickler implementieren keine kryptografischen Mechanismen im Code. Die Absicherung erfolgt deklarativ über das Bereitstellungsmanifest (Deployment Manifest / Execution Manifest).
• Konfigurationsanforderungen (Integrator & Stack-Entwickler):
  • Manifest-Mapping: Validierung, dass IPsec-Endpunkte exakt mit den in den Service-Deployment-Manifesten (ServiceInstanceToMachineMapping) definierten UDP/TCP-Ports übereinstimmen.
  • Latenz- und Pufferverhalten: Der IKE-Handshake erzeugt bei Kaltstart Latenzen (Initial Packet Drop oder Socket Timeout). Für harte Echtzeit-/Startup-Anforderungen im Fahrzeugnetzwerk sind Pre-Shared Keys, aggressive SA-Vorinitialisierungen oder statische SAs (ohne IKE-Laufzeitverzögerung) zwingend abzuwägen.
  • MTU/Fragmentation: Durch IPsec-Overhead (ESP-Header, IV, ICV/Tag, Padding) sinkt die effektive Path-MTU. SOME/IP-Serialisierer oder TCP-MSS müssen angepasst werden, um unerwünschte IP-Fragmentierung im Automotive-Ethernet-Netzwerk zu verhindern.
• Plattform-/OS-Bindung:
  • Setzt einen POSIX-Kernel mit nativer XFRM/IPsec-Unterstützung (oder äquivalentem BSD KAME/QNX io-pkt-Stack) voraus. Das IKE module muss die Automotive-Zertifikatsketten (PKI/CryptoStack via ara::crypto) bzw. Security-Management-Vorgaben einbinden können.