Figure 9.24: Interfaces for freshness value management

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Schnittstellen- und Komponentendiagramm (Architekturprofil der AUTOSAR Adaptive Platform).
• Technischer Zweck: Spezifikation der Kopplung zwischen dem Functional Cluster Communication Management (ara::com) und dem Freshness Value Management (FVM) zur Absicherung der Dienst- und PDU-Kommunikation gegen Replay-Angriffe (SecOC / Message Authentication) gemäß AUTOSAR Adaptive Platform R21-11.

2. Komponenten, Entitäten & Schnittstellen

• Communication Management («aapFunctionalCluster», daemon-based):
  • Repräsentiert das funktionale Cluster der Adaptive Platform für Inter-Process- und Inter-ECU-Kommunikation in seiner daemon-basierten Ausprägung (daemon-based).
  • Tritt im Diagramm als Konsument/Klient der FVM-Funktionalität auf.
• FVM («aapNativeInterface,aapPlatformExtension»):
  • Stereotyp «aapNativeInterface»: Definiert eine native C++-Schnittstelle auf Plattformebene.
  • Stereotyp «aapPlatformExtension»: Kennzeichnet die Schnittstelle als Plattform-Erweiterungspunkt (OEM- oder anbieterspezifische Implementierung, keine anwendungsseitige Standard-ara::-API).
  • Schnittstellenmethoden:
    • + Initialize(): Initialisiert den Zustand des FVM (z. B. Synchronisationsstatus, Trip-/Reset-Counter, Anbindung an Zeitbasen).
    • + GetTxFreshness(): Liefert den aktuellen Freshness-Wert (vollständig bzw. trunkiert) für den Sendevorgang zur kryptografischen MAC-Generierung.
    • + GetRxFreshness(): Rekonstruiert anhand des empfangenen (trunkierten) Freshness-Werts und des lokalen Zustands den vollständigen Freshness-Wert zur MAC-Verifikation.
• Beziehung:
  • Gerichtete Abhängigkeit (Dependency mit Stereotyp «use») vom Cluster Communication Management auf das Interface FVM. Zeigt lose Kopplung via Dependency Injection / Interface-Abstraktion.

3. Dynamisches Verhalten & Sequenzablauf

• Initialisierungsphase:
  • Beim Startup des Kommunikations-Stacks ruft Communication Management synchron Initialize() auf, um den internen Zustandsautomaten des FVM und etwaige Sync-Mechanismen scharfzuschalten.
• Sendepfad (TX-Sequenz):
  1. Eine Service-Instanz oder ein Socket-Binding initiiert den Versand einer authentifizierten Nachricht/PDU.
  2. Communication Management ruft synchron GetTxFreshness() auf.
  3. Der zurückgegebene Freshness-Wert wird an das Crypto-Modul übergeben, in den Datenstrom für die CMAC-/HMAC-Berechnung eingefügt und ggf. trunkiert im Header übertragen.
• Empfangspfad (RX-Sequenz):
  1. Eine eingehende authentifizierte Nachricht trifft im Binding ein.
  2. Communication Management extrahiert den trunkierten Freshness-Wert und ruft synchron GetRxFreshness() auf.
  3. FVM rekonstruiert den vollständigen Zähler-/Zeitstempelwert.
  4. Schlägt die Rekonstruktion fehl (z. B. Out-of-Sync oder Replay-Verdacht), bricht Communication Management die Verarbeitung ab und verwirft die PDU.

4. Normative Relevanz & Entwickler-Hinweise

• Architektur & Integration (Platform Extension):
  • Das FVM ist als «aapPlatformExtension» modular ausgelegt. Der Integrator muss eine konkrete FVM-Implementierung bereitstellen, die das OEM-spezifische Freshness-Protokoll (z. B. Time-Sync über gPTP/AUTOSAR Time Synchronization oder Trip-Counter-Verfahren nach SecOC) abbildet.
• Echtzeitanforderungen & Reentrancy:
  • GetTxFreshness() und GetRxFreshness() liegen direkt im synchronen Serialisierungs-/Deserialisierungspfad von ara::com. Die Implementierung muss zwingend reentrant, threadsicher und latenzarm (ohne blockierende I/O oder Mutex-Contention) sein.
• Kopplung an Krypto-Subsysteme:
  • Das Interface übergibt die Werte typischerweise an die PDU-Router- bzw. SOME/IP-Transformator-Schicht, welche diese Werte mit dem Crypto Stack (ara::crypto) zur Signatur-/MAC-Erzeugung zusammenführt.