DEENESPTFRRUARHIKOZHNL
AUTOSAR_SWS_SecureOnboardCommunication FIG-c9353920c306bf20 903 × 656 px 1 Release(s)

Figure 7: Verification of MAC

SHA-256 Inhalts-Fingerabdruck: c9353920c306bf203c954fae72b7280dc6e98c764fb448ba0137071be9c5f0af
✦ KI-generierte Bildanalyse & technische Beschreibung Modell: gemini-3.8-flash (via agy) · Rezept figure-description@2 · erstellt am 2026-10-07

1. Diagrammtyp & Architektur-Kontext

  • Klassifikation: UML-Aktivitätsdiagramm (Activity Diagram) / Kontrollflussgraph mit Entscheidungsknoten (Decision Node) und Guard-Bedingungen.
  • Funktionale Einordnung: AUTOSAR Classic Platform (Release 4.2.2), BSW Communication Services Layer, Modul SecOC (Secure Onboard Communication).
  • Technischer Zweck: Spezifiziert den normativen Algorithmus zur Freshness-Wert-Synchronisation und Retry-Schleife während der Authentizitäts- und Integritätsprüfung einer empfangenen Secured I-PDU (Rx-Pfad) gemäß SWS_SecOC_00053. Werden zur Bandbreitenreduktion nur die Least Significant Bits (LSBs) des Freshness-Wertes über den Bus übertragen, ermöglicht diese Logik die Resynchronisation bei verpassten Botschaften/LSB-Überläufen durch schrittweises Inkrementieren der lokal rekonstruierten Most Significant Bits (MSBs).

2. Komponenten, Entitäten & Schnittstellen

  • Akteure & Module:
    • SecOC: Ausführende BSW-Entität.
    • Crypto Service Manager (CSM): Unterlagerte Krypto-Schnittstelle zur Ausführung der Signatur-/MAC-Prüfung (Csm_MacVerify bzw. Csm_SignatureVerify).
    • PduR (PDU Router): Überlagerte Empfangsschicht (PduR_SecOCRxIndication).
  • Zustands- & Konfigurationsvariablen:
    • Attempts: Lokale Laufzeitvariable (Schleifenzähler für Verifikationsiterationen, initial 0).
    • SecOCFreshnessValueSyncAttempts (ECUC-Parameter): Maximal zulässige Anzahl an Re-Synchronisationsversuchen zur Rekonstruktion des vollständigen Freshness-Wertes.
    • FreshnessVerifyValue: Zusammengesetzter Verifikations-Vektor bestehend aus lokal gehaltenen MSBs und den in der Secured I-PDU übertragenen LSBs.
  • Kontrollfluss-Knoten & Konnektoren:
    • Initial Node: Eintritt über eingehende gesicherte PDU.
    • Decision Node (Raute): Auswertung des Verifikationsergebnisses und der Guard-Bedingungen.
    • Exit-Konnektoren:
      • continue (grün): Erfolgreicher Abschluss, Übergang zur Nutzdaten-Auslieferung.
      • step back (gelb): Rücksprung zur Wiederholung der Krypto-Prüfung.
      • abort (rot): Terminaler Fehlerzustand, Verwerfen der PDU.

3. Dynamisches Verhalten & Sequenzablauf

  1. Trigger: Aufruf von SecOC_RxIndication() durch die unterlagerte Schnittstelle (z. B. CanIf, FrIf, SoAd). SecOC baut den ersten Prüfvektor FreshnessVerifyValue auf.
  2. MAC Verification:
    • Ausführung der MAC-Verifikation über Nutzdaten (Authentic I-PDU) und FreshnessVerifyValue via CSM (synchron oder asynchron).
  3. Verzweigung via Guard-Bedingungen:
    • Pfad 1 (passes):
      • MAC ist valide.
      • Fluss terminiert auf Konnektor continue.
      • SecOC aktualisiert den lokalen Freshness-Wert (persistente MSBs) und leitet die Authentic I-PDU via PduR_SecOCRxIndication() an den PduR weiter.
    • Pfad 2 (fails && [Attempts < SecOCFreshnessValueSyncAttempts]):
      • MAC ist ungültig, das Synchronisationsfenster ist noch nicht ausgeschöpft.
      • Aktion 1: Attempts++ (Inkrementierung des Versuchszählers).
      • Aktion 2: most significant bits of FreshnessVerifyValue ++1 (Annahme: LSB-Überlauf fand auf Senderseite bereits statt, Empfänger verpasste mindestens ein Sendeintervall).
      • Fluss terminiert auf Konnektor step back: Rücksprung zur erneuten Ausführung von MAC Verification mit dem modifizierten FreshnessVerifyValue.
    • Pfad 3 (fails && [Attempts >= SecOCFreshnessValueSyncAttempts]):
      • MAC ist ungültig und das Limit der Re-Synchronisationsversuche ist erreicht oder überschritten.
      • Aktion: Drop message (PDU wird verworfen, keine Weiterleitung an PduR).
      • Fluss geht auf abort: Fehlermeldung an Dem (z. B. SECOC_E_VERIFICATION_FAILURE) bzw. Sicherheits-Event-Logging via IdsM.

4. Normative Relevanz & Entwickler-Hinweise

  • WCET & Task-Scheduling-Einfluss:
    • Ist SecOCFreshnessValueSyncAttempts auf N konfiguriert, resultiert dies im Worst Case in (N + 1) sequentiellen CSM-Aufrufen für einen einzigen Rx-Frame.
    • Bei synchroner CSM-Verarbeitung im Kontext der Kommunikations-Task (SecOC_MainFunctionRx oder Rx-ISR) führt dies zu massiven CPU-Lastspitzen und potenziellen Task-Overruns. Bei hohen Datenraten oder CAN-Bursts muss die asynchrone CSM-Anbindung mit PDU-Queuing implementiert werden.
  • Denial-of-Service (DoS) & Buslast-Exposition:
    • Ein Angreifer kann durch bewusst manipulierte MACs die Empfänger-ECU dazu zwingen, für jede injizierte PDU das maximale Synchronisationsfenster vollständig abzuarbeiten. Der Parameter SecOCFreshnessValueSyncAttempts ist daher so klein wie möglich zu wählen (typisch 1 … 3).
  • Zustandskonsistenz der Freshness-Quelle:
    • Das Inkrementieren der MSBs (FreshnessVerifyValue ++1) darf während der Iterationen ausschließlich auf einer lokalen Arbeitskopie für die Verifikation erfolgen. Eine Übernahme in den persistenten lokalen Freshness-Zustand des Empfängers darf erst und ausschließlich bei Traversierung des continue-Pfades erfolgen.

Versionsvergleich KI-generiert · gemini-3.8-flash (via agy)

R4.2.2 → R4.3.1 keine inhaltliche Änderung Nachfolger: FIG-0d5a4627ecec958a

Keine inhaltlichen Änderungen erkennbar.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Erkannte Spezifikationsbelege & Anforderungen auf dieser Seite

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

Attempts++ | most significant bits of FreshnessVerifyValue ++1 | Drop message | abort continue step back | MAC Verification | fails && [Attempts < SecOCFreshnessValueSyncAttempts] | fails && [Attempts >= SecOCFreshnessValueSyncAttempts] | passes

Vorkommen in AUTOSAR-Releases (1)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R4.2.2 AUTOSAR_SWS_SecureOnboardCommunication S. 39 7 Figure 7: Verification of MAC