Figure 2: Simplified View of Message Authentication and Freshness Verification flow

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Daten- und Kontrollflussdiagramm (funktionales Wirkungs- und PDU-Konstruktionsmodell) auf BSW-/RTE-/Applikationsebene.
• Technischer Zweck: Schematische Darstellung des symmetrischen kryptografischen Authentifizierungs- und Verifikationsprozesses in AUTOSAR SecOC (Secure Onboard Communication, SWS-ID-Bereich SWS_SecOC_*) zwischen Sender- und Empfänger-ECU zur Absicherung von I-PDUs gegen Replay-, Injection- und Masquerading-Angriffe.
• Architektur-Einordnung: Einbettung des BSW-Moduls SecOC zwischen PduR (PDU Router) und Cryptographic Service Manager (CSM) / Crypto Stack, mit Schnittstelle über die RTE zum Freshness Value Manager (FVM) in der Application Layer.

2. Komponenten, Entitäten & Schnittstellen

• Akteure & Module:
  • **Application Layer / FVM (Freshness Value Manager):** Software-Component (SW-C), zuständig für Generierung, Synchronisation und Bereitstellung monoton steigender Frischewerte (Zähler, Timestamps oder Trip-Counters).
  • **RTE (Runtime Environment):** Vermittelt standardisierte AUTOSAR-Client/Server- bzw. Sender/Receiver-Interfaces zwischen FVM (Applikationsebene) und SecOC-BSW.
  • SecOC BSW-Modul (Sender / Receiver): Führt I-PDU-Assembly, Truncation, Parsen und PDU-Verifikation aus; triggert kryptografische Primitive via CSM-APIs (Csm_MacGenerate, Csm_MacVerify).
  • Crypto Stack (CSM/CryIf/Crypto Driver): Verwaltet den symmetrischen Schlüssel K (Secret Key, z. B. AES-128 für CMAC) im HSM, vHsm oder Secure Memory.
• Datenstrukturen & PDU-Entitäten:
  • Authentic I-PDU: Originäre Nutzlast aus oberen Schichten (z. B. COM/PduR).
  • SecOC Data ID: Konfigurierte, eindeutige Identifikationsnummer (SecOCDataId) zur Bindung der PDU an den Kontext (Teil der zu signierenden Eingangsdaten, wird i. d. R. nicht über den Bus übertragen).
  • Data to Authenticate: Konkatenation aus SecOC Data ID + Authentic I-PDU + vollständigem Freshness Value (FV).
  • Secured I-PDU: Bus-Payload bestehend aus Authentic I-PDU + optionalen übertragenen FV-Bits (Truncated Freshness Value) + abgeschnittenem MAC (Truncated MAC).

3. Dynamisches Verhalten & Sequenzablauf

A. Sender-Ablauf (MAC Generation & PDU Assembly)

1. PDU-Trigger: PduR leitet eine sendebereite Authentic I-PDU via SecOC_Transmit() an das SecOC-Modul weiter.
2. Frische-Abfrage: SecOC ruft den aktuellen Frischewert synchron/asynchron über das FVM-Interface ab (Fcm_GetFreshnessValue() bzw. R-Port über RTE).
3. MAC-Berechnung: Übergabe der Data to Authenticate (Data ID + Payload + voller FV) an den CSM (Csm_MacGenerate()) unter Nutzung des symmetrischen Schlüssels K. Das Ergebnis ist der unbeschnittene MAC (z. B. 128 Bit CMAC).
4. Truncation & Serialisierung:
   • Kürzung des MACs auf die konfigurierte Bitbreite (SecOCAuthInfoTxLength).
   • Optional Kürzung des FVs auf die Bus-relevante Bitbreite (SecOCFreshnessValueTxLength).
   • Aggregation zur Secured I-PDU und Weiterleitung an den PduR / Interface-Treiber (CanIf/FrIf/EthIf).

B. Empfänger-Ablauf (Freshness Verification & MAC Verification)

1. Empfangs-Trigger: PduR übergibt die eingegangene Secured I-PDU via SecOC_RxIndication().
2. Deserialisierung: Trennung von empfangener Authentic I-PDU, übertragenem (abgeschnittenem) FV und übertragenem Truncated MAC.
3. Frische-Rekonstruktion: Übergabe der empfangenen FV-Fragmente an den FVM via RTE (Fcm_GetRxFreshnessAuthData() / GetFreshnessValue()), um den vollständigen Verifikations-Frischewert synchron/lokal abzuleiten.
4. MAC-Verifikation: Bereitstellung von Data ID, erhaltener Authentic I-PDU, rekonstruiertem vollem FV und empfangenem MAC an den CSM (Csm_MacVerify() bzw. Csm_MacGenerate() mit bitweisem Vergleich).
5. Entscheidung & Fehlerpfade:
   • OK (Verifikation erfolgreich): Authentic I-PDU wird via PduR_SecOCRxIndication() an den PduR weitergeleitet; FVM aktualisiert internen Frischestatus.
   • NOK (Verifikation fehlgeschlagen): Die PDU wird verworfen (nicht an PduR propagiert). Optionaler Aufruf von Dem_SetEventStatus (z. B. SECOC_E_VERIFICATION_FAILED) und Inkrementierung von Fehlerzählern; FVM-Synchronisationsversuch (z. B. Request Sync Message).

4. Normative Relevanz & Entwickler-Hinweise

• Buslast vs. Sicherheitsniveau (Truncation-Trade-off):
  • SecOCAuthInfoTxLength bestimmt die kryptografische Restfälschungswahrscheinlichkeit (1/2^n). Im Automotive-Bereich (CAN-FD) sind 24–64 Bit üblich.
  • SecOCFreshnessValueTxLength legt fest, wie viele LSBs des Frischezählers übertragen werden; zu kurze Werte führen bei Burst-Verlusten zum Verlust der FVM-Synchronisation.
• CSM-Ausführungsmodus (Synchron vs. Asynchron):
  • Bei synchroner CSM-Ausführung blockiert SecOC_Transmit() / SecOC_RxIndication() den aufrufenden Task-Kontext (Latenz- und Jitter-Risiko bei Software-Krypto ohne HSM).
  • Bei asynchroner Abwicklung sind PDU-Pufferung (SecOCUseTransmitEvent, SecOCPduBufferRef) und CSM-Callback-Handling zwingend abzustimmen.
• Data ID-Konfiguration:
  • Die SecOCDataId muss systemweit über ARXML/DEXT konsistent zwischen Sender und Empfänger konfiguriert sein, da Abweichungen zu deterministischen Verifikationsfehlern führen, ohne dass auf dem Bus ein Payload-Fehler sichtbar ist.
• FVM-Interface-Typ:
  • Festlegung, ob das FVM als C-Header-Interface (optimiertes BSW-Linkage) oder als klassische AUTOSAR-SW-C über RTE-Service-Ports angebunden wird (Auswirkung auf Kontextwechsel und Stack-Nutzung).