Figure 9.2: Store multiple key

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm (Interaktionsdiagramm).
• Technischer Zweck: Spezifikation des synchronen Interaktions- und Protokollablaufs zur sicheren Einbringung und Verifizierung mehrteiliger bzw. mehrerer kryptografischer Schlüssel (Store multiple key) im AUTOSAR Classic Platform Crypto-Stack.
• Architektonische Einordnung:
  • Liegt in der BSW-Serviceschicht (Service Layer).
  • Beschreibt die Vermittlerrolle des Key Managers (KeyM) zwischen Applikationsebene/Diagnose (z. B. Dcm, Security-SWC) und dem Crypto Service Manager (Csm), welcher die Hardware-Abstraktion (CryIf, Crypto Driver/HSM) anbindet.

2. Komponenten, Entitäten & Schnittstellen

• Beteiligte Instanzen (Lifelines):
  • Application: Aufrufende Applikations-SWC oder BSW-Komponente (z. B. Diagnose-/Update-Dienst zur Schlüsselbereitstellung).
  • «module» KeyM: AUTOSAR Key Manager BSW-Modul (Zustandsverwaltung, Format-Parsing, Orchestrierung).
  • KeyHandler: Interner/konfigurierter Callback- bzw. Sub-Handler für herstellerspezifische Schlüsselvorbereitung (KeyM_KH_*).
  • «module» Csm: AUTOSAR Crypto Service Manager (Kryptografische Basisfunktionen und Schlüsselverwaltung im HSM/Crypto-Treiber).
• Schnittstellen & Parameter-Signaturen:
  • Application → KeyM:
    • KeyM_Start(Std_ReturnType, KeyM_StartType, const uint8*, uint16, uint8**, uint16**): int: Initialisierung des Schlüssel-Update-Vorgangs; Übergabe von Betriebsmodus und Ein-/Ausgabepuffern.
    • KeyM_Prepare(Std_ReturnType, const uint8*, uint16, uint8**, uint16**): Vorbereitung des Zielspeichers und Kontextes.
    • KeyM_Update("1".."3", ...): Sequentielles Laden einzelner Schlüsselteile/Elemente.
    • KeyM_Finalize(Std_ReturnType, const uint8*, uint16, uint8**, uint16*): Abschluss der Übertragung und Hash-/Längen-Validierung.
    • KeyM_Verify(Std_ReturnType, const uint8*, uint16, const uint8*, uint16, uint8**, uint16**): int: Verifikation der eingebrachten Schlüsseldaten (z. B. per Signatur/MAC).
  • KeyM → KeyHandler:
    • KeyM_KH_Prepare(): Modulinterne Schnittstelle zur Formatanpassung/Vorvalidierung.
  • KeyM → Csm:
    • Csm_KeyElementSet(keyId, keyElementId, keyPtr, keyLength): Schreiben einzelner Schlüsselelemente in den persistenten oder transienten Schlüsselspeicher (HSM/SHE/Crypto-Treiber).
    • Csm_KeySetValid(keyId): Atomares Aktivieren/Gültigsetzen des Schlüssels nach vollständiger Übertragung.
    • Csm_XXXVerify(...): Dynamisch aufgelöste Verifikationsfunktion basierend auf dem Parameter KeyMCryptoCsmVerifyJobRef (im Diagramm typografisch als KeyMCryptpKeyCsmVerifyJobRef annotiert).

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierungsphase:
   • Application triggert KeyM_Start(...).
   • KeyM wechselt intern in den Zustand state = active (Session ist geöffnet, Exklusivität für Schlüsseloperationen etabliert) und quittiert synchron.
2. Vorbereitungsphase:
   • Application ruft synchron KeyM_Prepare(...) auf.
   • KeyM leitet den Aufruf an KeyHandler via KeyM_KH_Prepare() weiter, um Parsing-Strukturen und Puffer zu allozieren/vorzubereiten.
3. Iterative Übertragungsphase (Schlüsselkörper 1 bis 3):
   • Die Applikation transferiert die Schlüsseldaten blockweise oder elementspezifisch über wiederholte Aufrufe von KeyM_Update(...) ("1", "2", "3").
   • Jeder Aufruf resultiert in einer synchronen Weiterleitung von KeyM an Csm via Csm_KeyElementSet(...), wodurch die Schutzelemente direkt im Ziel-Treiber/HSM abgelegt werden.
4. Finalisierungsphase:
   • Nach vollständigem Datentransfer ruft die Applikation KeyM_Finalize(...) auf.
   • KeyM schließt das Setzen der Elemente ab und validiert den Schlüsselbestand im CSM über Csm_KeySetValid(...). Der Schlüsselstatus wechselt im CSM von in Bearbeitung/ungültig auf gültig.
5. Verifikationsphase:
   • Application initiiert KeyM_Verify(...) mit Zertifikats-/Signatur-Prüfdaten.
   • Gemäß Konfigurationsparameter KeyMCryptoCsmVerifyJobType bzw. KeyMCryptoCsmVerifyJobRef mappt KeyM den Funktionsnamen und stößt den Verifikationsjob synchron über Csm_XXXVerify(...) an (z. B. SignatureVerify oder MacVerify).
   • Nach erfolgreichem Rückgabewert meldet KeyM den Abschlussstatus an die Applikation zurück.

4. Normative Relevanz & Entwickler-Hinweise

• Zustandskonsistenz & Rollback:
  • Der Schlüssel verbleibt im CSM bis zum erfolgreichen Aufruf von Csm_KeySetValid im Zustand invalid. Schlägt ein Teilschritt (KeyM_Update, KeyM_Finalize oder KeyM_Verify) fehl, darf der Schlüssel nicht als gültig markiert werden bzw. muss invalidiert werden.
• Synchroner Aufrufkontext:
  • Alle dargestellten CSM-Schnittstellen (Csm_KeyElementSet, Csm_KeySetValid, Csm_XXXVerify) werden hier synchron bedient. Dies erfordert, dass die zugrundeliegenden CryIf-/Crypto-Treiber-Jobs für synchrone Verarbeitung (CRYPTO_PROCESSING_SYNC) konfiguriert sind, um Blockaden des aufrufenden Tasks zu vermeiden bzw. deterministische Laufzeiten zu garantieren.
• Konfigurationsabhängige API-Ableitung:
  • Die Verifikationsschnittstelle Csm_XXXVerify ist generisch. Der Entwickler/Integrator muss über den Konfigurationscontainer KeyMCryptoCsmVerifyJobRef den konkreten CSM-Job (z. B. RSA/ECC-Signaturprüfung oder CMAC) referenzieren; KeyM generiert bzw. bindet die entsprechende Service-API typsicher ein.
• Puffer- und Alignment-Anforderungen:
  • Doppelzeiger-Signaturen (uint8**, uint16**) in KeyM_Start, KeyM_Prepare, KeyM_Verify dienen dem dynamischen Handling von Response-Daten bzw. Restdatenpuffern. Entwickler müssen sicherstellen, dass die übergebenen Pufferbereiche gültig bleiben und den Cache-/Alignment-Vorgaben der Plattform entsprechen.