Figure 9.5: Add Root or intermediate Certificate

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm (AUTOSAR Classic Platform, SWS Key Manager, R22-11, Figure 9.5).
• Technischer Zweck: Spezifikation des standardisierten Verifikations-, Einbringungs- und Aktualisierungsablaufs von X.509-Root- bzw. Intermediate-Zertifikaten im BSW-Modul KeyM (Key Manager).
• Architektur-Einordnung: Vertikale Orchestrierung im AUTOSAR-Sicherheits-Stack: Die Application (SW-C) stößt administrative Zertifikatsoperationen über das Service-Interface des KeyM an. Der KeyM interagiert mit StbM (Synchronized Time-Base Manager für Gültigkeitsprüfungen), Csm (Crypto Service Manager für kryptografische Signaturprüfung und Key-Management) sowie optional NvM (Non-Volatile Memory Manager für persistente Zertifikatsspeicherung).

2. Komponenten, Entitäten & Schnittstellen

Beteiligte Instanzen (Lifelines)

• Application: Aufrufende Applikations-SW-C bzw. Diagnose-Session (z. B. Dcm-Proxy).
• «module» KeyM: Zentrales BSW-Modul zur Zertifikats- und Schlüsselverwaltung (Crypto Service Layer).
• «module» StbM: BSW-Modul zur synchronisierten Zeitbereitstellung (System Services).
• «module» NvM: BSW-Modul zur nichtflüchtigen Speicherverwaltung (Memory Services; gekennzeichnet mit Persistenz-Symbol).
• «module» Csm: BSW-Modul zur Abstraktion hardware-/softwarebasierter Kryptografietreiber (Crypto Services).

Schnittstellen & Funktionssignaturen

• KeyM_ServiceCertificate(Std_ReturnType, KeyM_ServiceCertificateType, const uint8*, uint16, const uint8*, uint16, uint8**, uint16): Service-Einsprungpunkt für Zertifikatsoperationen (service-Selektor: KEYM_SERVICE_CERT_SET_ROOT, KEYM_SERVICE_CERT_SET_INTERMEDIATE_CERT, KEYM_SERVICE_CERT_UPDATE_INTERMEDIATE).
• StbM_GetCurrentTime(Std_ReturnType, StbM_SynchronizedTimeBaseType, StbM_TimeStampType**, StbM_UserDataType**): Abfrage des aktuellen, verifizierten Zeitstempels.
• Csm_KeyElementSet(Std_ReturnType, uint32, uint32, const uint8*, uint32): Setzen von Schlüsselelementen im Worker-Key bzw. Ziel-Key.
• Csm_KeySetValid(Std_ReturnType, uint32): Gültig-Schalten eines konfigurierten CSM-Schlüssels.
• Csm_SignatureVerify(Std_ReturnType, uint32, Crypto_OperationModeType, const uint8*, uint32, const uint8*, uint32, Crypto_VerifyResultType**): Asymmetrische Signaturprüfung des Zertifikats.
• NvM_WriteBlock(Std_ReturnType, NvM_BlockIdType, const void*): Persistieren des Zertifikats in einem NVRAM-Block.

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger & Identifikation:
   • Aufruf von KeyM_ServiceCertificate() mit dem entsprechenden Service-Kommando.
   • Interner Suchschritt im KeyM: Search for KeyMCertificate über die Konfigurationsreferenz KeyMCertStorageCryptoKeyRef->KeyMCryptoKeyName.
2. Strukturelle & Semantische Vorprüfung:
   • Parsing: Vollständiges Parsen aller X.509-Subelemente (ASN.1/DER-Decodierung).
   • Verifying: Ausführung von KeyMCertificateElementVerification().
   • subject check: Validierung der Zertifikatskette; das Subject-Feld des übergeordneten Zertifikats muss exakt mit dem Issuer-Feld des untergeordneten Zertifikats übereinstimmen.
3. Gültigkeitszeitraum-Validierung (StbM):
   • Synchroner Abruf der aktuellen Systemzeit via StbM_GetCurrentTime().
   • time stamp check: Abgleich der StbM-Zeit gegen die Gültigkeitsgrenzen notBefore und notAfter des Zertifikats.
4. Kryptografische Signaturprüfung (Csm):
   • Belegen eines temporären Worker-Keys via Csm_KeyElementSet() mit dem öffentlichen Schlüssel der Ausstellerinstanz.
   • Statuswechsel auf gültig via Csm_KeySetValid().
   • Aufruf von Csm_SignatureVerify() mit dem Zertifikatsdatenstrom und der Signatur; Rückgabe des Verifikationsergebnisses (Crypto_VerifyResultType).
5. Konditionale Persistierung (opt [Verification successful]):
   • Nur bei erfolgreicher Verifikation greift das Combined Fragment alt:
     • Pfad 1 ([NvM used for Key storage]): Direktes Schreiben der Zertifikatsdaten in den NvM via NvM_WriteBlock().
     • Pfad 2 ([Csm used for Key storage]): Schlüsseldaten werden via Csm_KeyElementSet() in den persistenten CSM-Key überführt und mittels Csm_KeySetValid() validiert.
6. Bereinigung (Zeroization) & Rückkehr:
   • Unconditional Execution: Aufruf von Csm_KeyElementSet() zur Zerstörung/Ungültigmachung des ephemeren Worker-Keys (KeyElementSet to destroy the worker key).
   • Rücksprung zu Application mit Erfolgs- oder Fehlercode (Std_ReturnType).

4. Normative Relevanz & Entwickler-Hinweise

• Key-Lifecycle & Hygiene: Das Diagramm erzwingt eine strikte ephemere Handhabung des Verifikationsschlüssels. Nach Abschluss der Verifikation muss der Worker-Key im Krypto-Treiber (Crypto Driver Object) überschrieben bzw. gelöscht werden, um Key-Leakage im RAM zu verhindern.
• Konfigurationsabhängigkeit der Persistierung: In KeyM muss über Konfigurationsparameter (z. B. KeyMCertificateStorage) festgelegt werden, ob Zertifikate transparent im NvM (Dateisystem/Block) oder geschützt über den Krypto-Stack (Csm/Crypto-Hardware-Flash) hinterlegt werden.
• StbM-Zeitbasis-Restriktion: Schlägt StbM_GetCurrentTime() fehl oder liefert StbM keinen synchronisierten Zeitstatus (STBM_TIMEOUT_COUNTER überschritten oder Status unvalidiert), schlägt die Zertifikatsinstallation fehl. Entwickler müssen sicherstellen, dass die Synchronisationsquelle (z. B. via PTP/CAN-TSyn/GPS) vor Zertifikatsupdates verriegelt ist, sofern nicht via Konfiguration (KeyMValidCertTime) eine Lockerung definiert ist.
• Synchronität vs. Asynchronität: Obwohl das Sequenzdiagramm vereinfacht synchrone Returns darstellt, arbeiten Csm_SignatureVerify und NvM_WriteBlock im AUTOSAR-Standard primär asynchron (CRYPTO_PROCESSING_ASYNC / Job-Queue). Der KeyM-Zustandsautomat muss zyklisch in KeyM_MainFunction() bzw. über Modul-Callbacks (KeyM_CsmNotification, NvM_SingleBlockCallback) synchronisiert werden.