Figure 9.10: Freshness Handling

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm mit kombinierten Fragmenten / Loops).
• Technischer Zweck: Spezifikation des asynchronen Verifikations- und Entschlüsselungs-/Freshness-Handling-Workflows auf Empfängerseite (Rx-Pfad) innerhalb des AUTOSAR Classic BSW-Moduls SecOC (Secure Onboard Communication, R4.3.1).
• Funktionale Einordnung: Dargestellt wird die Entkopplung zwischen dem PDU-Empfang via Interrupt/Callback-Kontext und der kryptografischen Verifikation im Task-Kontext (SchM), einschließlich mehrstufiger Wiederholmechanismen (Freshness-Synchronisation bei Fehlversuchen sowie Busy-Handling bei Ressourcenengpässen im CSM/Crypto-Stack).

2. Komponenten, Entitäten & Schnittstellen

Akteure / Instanzen (Lifelines)

• «module» PduR (PDU Router): Transportiert die eingehende gesicherte I-PDU (Secured I-PDU) von den unteren Kommunikationsschichten (CanIf, LinIf, FrIf, SoAd) an das SecOC-Modul.
• «module» SecOC: Zentrales BSW-Modul zur Verifikation von Authentizität, Integrität und Replay-Schutz der I-PDUs.
• «module» SchM (Schedule Manager / BSW-Scheduler): Triggert zyklisch die Hauptfunktion des SecOC im OS-Task-Kontext.
• FreshnessManager (auch FVM – Freshness Value Manager): SW-C oder CDD (Complex Device Driver), verantwortlich für Erzeugung, Synchronisation und Rekonstruktion vollständiger Freshness Values (Trip-Counter, Reset-Counter, Message-Counter).
• «module» Csm (Crypto Service Manager): Abstraktionsschicht für kryptografische Operationen (MAC-Prüfung via Software- oder Hardware-Krypto/HSM).

Schnittstellen & Interaktionsbeziehungen

• SecOC_RxIndication(): Standardisiertes AUTOSAR-Rx-Callback gem. PDU-Router-Interface.
• SecOC_MainFunctionRx(): Zyklischer SchM-Entry-Point für die asynchrone Rx-Verarbeitung.
• GetRxFreshness(): C-API-Callout oder RTE-Client-Server-Operation zur Rekonstruktion des vollständigen Freshness-Werts aus dem im PDU enthaltenen Truncated Freshness Value.
• Csm_MacVerify(): Standardisierte CSM-API zur asynchronen oder synchronen Verifikation des berechneten MAC gegen den empfangenen Authentication Tag.
• VerificationStatus(): Callback/Callout an den FreshnessManager zur Rückmeldung über Erfolg, MAC-Fehlschlag oder Replay-Verdacht.

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger & PDU-Pufferung:
   • PduR signalisiert das Eintreffen einer gesicherten PDU via SecOC_RxIndication().
   • SecOC puffert Metadaten sowie PDU-Payload im Puffer; zu diesem Zeitpunkt findet im Interrupt-/High-Priority-Kontext noch keine Krypto-Berechnung statt.
2. Task-Aktivierung:
   • Der SchM ruft im konfigurierten Raster die periodische Funktion SecOC_MainFunctionRx() auf.
3. Äußere Schleife – loop Authentication verify attempts (Bedingung: [MAC verification failed]):
   • Steuert die Freshness-Synchronisationsversuche (konfiguriert über SecOCAuthenticationVerifyAttempts). Schlägt eine MAC-Verifikation fehl, darf SecOC den FreshnessManager mehrfach nach alternativen Freshness-Werten (z. B. Counter-Window-Suche / Sync-Off-Window) anfragen.
4. Innere Schleife – loop authentication build attempts (Bedingung: [GetRxFreshness()==SECOC_E_BUSY || CsmMacVerify()==CRYPTO_E_BUSY]):
   • Guard-Handling bei Ressourcenkonflikten: Gibt GetRxFreshness() den Status SECOC_E_BUSY oder Csm_MacVerify() den Status CRYPTO_E_BUSY zurück, verharrt der Zustand bis zum Ablauf von SecOCAuthenticationBuildAttempts.
   • Freshness-Abfrage: Aufruf von GetRxFreshness(), um aus dem gekürzten Authentifizierungs-Header und dem internen FVM-Zustand den vollständigen Freshness-Vektor bereitzustellen.
   • Krypto-Verifikation: Aufruf von Csm_MacVerify() zur Prüfung des MAC über PDU-Daten + rekonstruierten Freshness-Wert.
5. Statusrückmeldung:
   • Nach Abschluss der Verifikationsschritte (Erfolg oder finale Erschöpfung der Versuche) übermittelt SecOC mittels VerificationStatus() das Verifikationsergebnis an den FreshnessManager, damit dieser seine internen Zustandszähler synchronisieren oder Fehlversuchs-Zähler dekrementieren/inkrementieren kann.

4. Normative Relevanz & Entwickler-Hinweise

• Nicht-blockierendes Design: GetRxFreshness() und Csm_MacVerify() dürfen die SecOC_MainFunctionRx() nicht unzulässig lange blockieren. Bei hardwarebeschleunigter Krypto (HSM/SHE) ist Csm_MacVerify() asynchron auszuführen; die Guard-Kriterien SECOC_E_BUSY und CRYPTO_E_BUSY fangen Wartezyklen ab.
• Puffer- und Latenzdimensionierung: Die PDU verbleibt für die Dauer beider Schleifen (verify attempts × build attempts) im Empfangspuffer von SecOC. Die Pufferkapazität (SecOCRxPduBufferRef) sowie die Zykluszeit der SecOC_MainFunctionRx() müssen so gewählt werden, dass Folge-PDUs desselben I-PDU-Handles keinen Pufferüberlauf erzeugen.
• FVM-Schnittstellenvertrag: Entwickler eines proprietären Freshness Managers müssen sicherstellen, dass GetRxFreshness() bei aufeinanderfolgenden Aufrufen innerhalb derselben Outer-Loop (Authentication verify attempts) abweichende Synchronisationshypothesen liefert (z. B. Erhöhung/Erniedrigung des Schätzers im Suchfenster).
• Rückmeldung bei Verifikationsfehlschlag: Erst nach Verlassen der äußeren Schleife (VerificationStatus()) entscheidet SecOC, ob die Authentic I-PDU an die oberen Schichten (z. B. via PduR_SecOCTxConfirmation / Rx-Weiterleitung) freigegeben oder verworfen wird. Ein finaler Fehlschlag muss optional Security-Events via IdsM (IdsM_SetSecurityEvent) oder Dem/Det melden.