Figure 7.5: Authenticated state transitions without persistent states

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Zustandsdiagramm (State Machine Diagram) zur Modellierung des nicht-persistenten Authentifizierungs-Zustandsautomaten im Diagnostic Communication Manager (Dcm).
• Technischer Zweck: Abbildung des dynamischen Lebenszyklus des UDS-Dienstes 0x29 (Authentication, ISO 14229-1:2020) im Dcm (Classic Platform BSW, Submodul DSP/DSL). Das Diagramm spezifiziert die Zustandsübergänge für Steuergeräte, bei denen der Authentifizierungsstatus flüchtig im RAM gehalten wird (DcmAuthenticationStatePersistent == FALSE) und nach Reset oder Kommunikationsabriss deterministisch in den sicheren Grundzustand zurückfällt.

2. Komponenten, Entitäten & Schnittstellen

• Zustände (States):
  • Startup: Initialer Pseudozustand vor Ausführung des DCM-Initialisierungscodes.
  • deauthenticated: Sicherer Default-Betriebszustand; Diagnose-Client verfügt über keine verifizierten Zugriffsrechte (Rolle: Unauthenticated).
  • authenticated: Autorisierter Zustand nach erfolgreicher kryptografischer Verifikation (Rolle: zugeordnete Client-Rolle mit erweiterten DID-/Routine-Lese-/Schreibberechtigungen).
• Schnittstellen & Trigger:
  • Dcm_Init(): BSW-Initialisierungs-API (vom BswM/EcuM aufgerufen).
  • UDS Service 0x29 Subfunktionen:
    • 0x00: deAuthenticate
    • 0x01: verifyCertificateUnidirectional
    • 0x02: verifyCertificateBidirectional
    • 0x03: proofOfOwnership
  • Timer-Ereignisse:
    • S3server timeout: Ablauf des DSL-Sitzungstimers bei fehlender Kommunikation in einer Nicht-Standard-Diagnosesitzung.
    • No diagnostic communication for 20 seconds in default session: Spezifischer Fallback-Wächter im DCM für die Default Diagnostic Session (0x01).
• Assoziierte BSW-Module:
  • Csm / CryIf / Crypto: Asynchrone Schnittstelle zur Signatur- und Hash-Prüfung.
  • KeyM: Zertifikats- und Trust-Anchor-Verwaltung.
  • BswM / EcuM: Lifecycle-Trigger für den Stack.

3. Dynamisches Verhalten & Sequenzablauf

• Initialisierungspfad:
  • Transition Startup → deauthenticated zwingend über den synchronen Aufruf Dcm_Init().
• Authentifizierungspfad (State Escalation):
  • Transition deauthenticated → authenticated erfordert die zweistufige Sequenz:
    1. Zertifikatsprüfung via Subfunktion 0x01 (verifyCertificateUnidirectional) oder 0x02 (verifyCertificateBidirectional).
    2. Nachweis des privaten Schlüssels via Subfunktion 0x03 (proofOfOwnership, Challenge-Response-Verfahren).
  • Erst nach vollständiger, positiver Auswertung beider Schritte (29 01|2 + 29 03) wird der Zustand authenticated eingenommen.
• Aktualisierungs-/Refresh-Pfad:
  • Self-Transition authenticated → authenticated über erneute Ausführung von 29 03 (Proof of Ownership), z. B. zur Verlängerung oder Re-Validierung des Status ohne vorheriges Deauthentifizieren.
• De-Authentifizierungspfade (State Revocation):
  • Expliziter Abbau: Empfang des Dienstes 29 00 (deAuthenticate) führt unmittelbar von authenticated → deauthenticated.
  • Idempotenter Aufruf: 29 00 im Zustand deauthenticated verbleibt via Self-Loop in deauthenticated.
  • Sitzungsverlust (Non-Default Session): Ablauf des Timers S3server löst den Rückfall in die Default Session aus und forciert zeitgleich den Übergang nach deauthenticated.
  • Inaktivitäts-Timeout (Default Session): Bleibt in der Default Session die Diagnosekommunikation für 20 Sekunden aus, verfällt der Authentifizierungsstatus automatisch (authenticated → deauthenticated).

4. Normative Relevanz & Entwickler-Hinweise

• Anforderungskonformität:
  • RS_Diag_04230: Gewährleistung standardisierter Authentifizierungsmechanismen nach ISO 14229-1.
  • SWS_Dcm_01480: Reset auf deauthenticated bei Kaltstart/Warmstart (Dcm_Init()) ohne NvM-Rücksicherung.
  • SWS_Dcm_01481: Durchsetzung der strikten Sequenzkontrolle; der Aufruf von 29 03 ohne vorangegangenes valides 29 01 bzw. 29 02 muss mit NRC 0x24 (Request Sequence Error) abgewiesen werden.
  • SWS_Dcm_01482: Deterministischer Entzug von Berechtigungen bei Session- und Inaktivitäts-Timeouts.
• Konfigurationsaspekte (Dcm.epc):
  • Parameter DcmAuthenticationStatePersistent muss auf FALSE stehen.
  • Überwachung des 20-Sekunden-Timers in der Default Session erfordert korrekte Zykluszeiten in Dcm_MainFunction() bzw. dedizierte Timer-Tasks im DSL.
• Integration & Tooling:
  • Diagnose-Tester müssen zur Erhaltung des Authentifizierungsstatus in der Default Session zyklisch TesterPresent (0x3E 80) oder Statusabfragen innerhalb des 20-Sekunden-Fensters senden.
  • Da asymmetrische Krypto-Operationen (CSM) typischerweise asynchron auf HSM/She ausgeführt werden, muss der DSP während der Zustandsübergänge NRC 0x78 (Response Pending) unterstützen, ohne den Zustandsautomaten inkonsistent zu blockieren.