Figure 7.11: SecOC embedded in the Adaptive Communication Management

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Schichtenmodell / Komponenten-Protokollstapel-Architektur (Blockdiagramm).
• Kontext & Zweck: Verortung des Subsystems SecOC (Secure Onboard Communication) innerhalb des AUTOSAR Adaptive Platform Functional Clusters Communication Management (ara::com) gemäß Release R20-11 bis R23-11. Das Diagramm definiert die vertikale Einbindung kryptografischer Schutzmechanismen (Authentizität, Integrität und Replay-Schutz nach RS_SEC_04001) in den externen Ethernet-Protokollstapel im Kontrast zum stack-internen Inter-Process-Communication-Pfad (IPC).

2. Komponenten, Entitäten & Schnittstellen

• Communication Management (ara::com): Umfassender funktionaler Cluster zur Bereitstellung serviceorientierter Kommunikation (SOA) für Adaptive Applications.
• Dispatching and Discovery: Zentrales Routing- und Service-Discovery-Modul (SOME/IP-SD, Skeleton-/Proxy-Dispatching, Event-/Method-Demultiplexing). Verbindet generische Applikationsendpunkte mit den transportabhängigen Bindings.
• SecOC (Secure Onboard Communication): Kryptografische Verifikations- und Authentifizierungsinstanz (farblich hervorgehoben). Kapselt MAC-Generierung/-Verifikation (Message Authentication Code) sowie Freshness-Value-Management (FVM).
• SOME/IP Transport: Protokoll-Binding-Schicht für Scalable service-Oriented MiddlewarE over IP (SOME/IP-Serialisierung, Header-Formatierung, PDU-Handling).
• TCP/IP & Ethernet Driver: Standardisierter POSIX-/OS-Netzwerk- und Interface-Stack (L2/L3/L4) für die Off-Board- bzw. Inter-ECU-Netzwerkkommunikation.
• IPC & IPC Transport: Separater, leichtgewichtiger Transportpfad für knoteninterne Kommunikation (Intra-Machine via Shared Memory, UDS/Domain Sockets oder Pipes).
• Beziehungen & Schichtung:
  • Asymmetrische Einbettung: SecOC liegt exklusiv im Netzwerk-Strang oberhalb des SOME/IP Transport und unterhalb von Dispatching and Discovery.
  • Bypass im IPC-Pfad: Der lokale IPC Transport operiert ohne SecOC-Schicht, da Intra-Machine-Kommunikation über OS-Sicherheitsgrenzen (z. B. DAC, MAC/SELinux, Memory Isolation) geschützt wird.

3. Dynamisches Verhalten & Sequenzablauf

Die Pfeile visualisieren den Ingress-Pfad (Empfang/Verifikation) von unten nach oben:

1. Rahmenempfang & Entkapselung: Der Ethernet Driver empfängt L2-Frames; der TCP/IP-Stack reicht TCP-Streams bzw. UDP-Datagramme an den SOME/IP Transport weiter.
2. SOME/IP-PDU-Extraktion: SOME/IP Transport parst den SOME/IP-Header und extrahiert die geschützte PDU bzw. Secured PDU (enthält Payload, Freshness Value (FV) und Authenticator/MAC).
3. Kryptografische Verifikation in SecOC:
   • Abfrage/Rekonstruktion des vollständigen Freshness Value über das FVM.
   • Asynchrone oder synchrone Übergabe an die Krypto-Engine/HSM (über ara::crypto).
   • Validierung: Stimmt der berechnete MAC mit dem empfangenen überein und liegt der Zähler im zulässigen Freshness-Fenster, gilt die Nachricht als authentisch.
   • Fehlerpfad (Abbruchbedingung): Bei MAC-Mismatch oder Replay-Verdacht wird die PDU verworfen (silent drop); optional erfolgt Security-Event-Reporting (z. B. an IDS/SEv).
4. Dispatching: Verifizierte Nutzdaten werden an Dispatching and Discovery übergeben und den Ziel-Instanzen (Service-Proxies/Skeletons) zugestellt.

Egress-Richtung (Senden, invers):

• Dispatching and Discovery übergibt serialisierte Daten an SecOC → Erzeugung des MAC mittels FVM/Crypto-Key → Assemblierung der Secured PDU → Übergabe an SOME/IP Transport → TCP/IP → Ethernet Driver.

4. Normative Relevanz & Entwickler-Hinweise

• Transparenz für Applikations-Entwickler: ara::com-Applikationen (Proxy/Skeleton-Implementierungen) bleiben vollständig kryptografie-agnostisch. Die Absicherung erfolgt deklarativ im AUTOSAR-Manifest (ARXML: SecureCommunicationProps, SecOcDeployment, Zuordnung zu SOME/IP-Events/-Methoden).
• Stack- & Integrator-Konfiguration:
  • Key- und Freshness-Synchronisation: Notwendigkeit einer robusten Kopplung an ein Freshness Value Management (FVM) und persistierte Krypto-Schlüssel im HSM/Key-Storage via ara::crypto.
  • Latenz- & Pufferbudgetierung: Die kryptografische Verifikation vor dem Dispatching führt zu messbaren Latenzen. Blockierende Krypto-Aufrufe im Kommunikations-Thread können den Event-Durchsatz degradieren; asynchrone non-blocking Treiberkopplung ist zwingend einzukalkulieren.
• Architektonische Randbedingung: Keine Ende-zu-Ende-Sicherheit für lokale Services: Sendet ein Service sowohl an lokale (IPC) als auch an externe (SOME/IP) Empfänger, entfällt der SecOC-Overhead für lokale Konsumenten automatisch am Branch-Punkt Dispatching and Discovery.