Figure 9.1: Store single key

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm).
• Technischer Zweck: Darstellung des Ablaufs zur Speicherung eines einzelnen kryptografischen Schlüssels (Store single key) im AUTOSAR Classic Crypto-Stack.
• Architektur-Einordnung: Das Diagramm zeigt die Interaktion zwischen der Applikationsschicht (SWC), dem standardisierten BSW-Modul KeyM (Crypto Key Manager, Service Layer), modul-internen Format-Handlern (KeyHandler, hier exemplarisch SHE-spezifisch) sowie dem Csm (Crypto Service Manager, Service Layer).

2. Komponenten, Entitäten & Schnittstellen

• Akteure & Lifelines:
  • Application: Applikationskomponente (SWC) oder Diagnose-/Bootloader-Stack, die das Key-Material bereitstellt.
  • «module» KeyM: AUTOSAR Key Manager; verwaltet Zertifikate und symmetrische/asymmetrische Schlüssel, steuert Parsen, Entschlüsseln und Verifikation.
  • KeyHandler: Modulinterne bzw. protokollspezifische Handler-Einheit des KeyM (z. B. zuständig für das Parsen und Unpacken proprietärer/standardisierter Key-Container wie SHE M1–M3).
  • «module» Csm: AUTOSAR Crypto Service Manager; kapselt Hardware-/Software-Kryptotreiber und verwaltet CSM-Key-Container.
• Schnittstellen & Funktionssignaturen:
  • KeyM_Prepare(Std_ReturnType, const uint8*, uint16, uint8**, uint16**): Initialisiert die Key-Aktualisierung; übergibt Quell- und Zielpuffer/Metadaten.
  • KeyM_KH_Prepare(): Interner Treiber-/Handler-Aufruf zur Vorbereitung der zustandsbehafteten Key-Parsing-Routine.
  • KeyM_Update("SHE", ...): Übergabe des eigentlichen Key-Blobs unter Angabe des Key-Typs/Schemas (hier: SHE – Secure Hardware Extension).
  • Csm_KeyElementSet(Std_ReturnType, uint32 keyId, uint32 keyElementId, const uint8* keyPtr, uint32 keyLength): Synchroner/asynchroner Schreibzugriff auf ein bestimmtes Schlüssel-Element im CSM/CryIf.
  • Csm_KeySetValid(Std_ReturnType, uint32 keyId): Schließt den Schreibvorgang ab und deklariert das Schlüsseltarget im CSM als betriebsbereit und gültig.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung/Vorbereitung (Prepare-Phase):
   • Die Application ruft synchron KeyM_Prepare(...) auf, um die Schlüsselaktualisierung anzumelden und Arbeits-/Pufferadressen auszutauschen.
   • KeyM delegiert intern an KeyM_KH_Prepare() der spezifischen KeyHandler-Instanz, um interne Puffer und Dekodierzustände vorzubereiten.
   • Die Aufrufe kehren mit Statusquittierung (Std_ReturnType) an die Application zurück.
2. Key-Aktualisierung (Update-Phase):
   • Die Application triggert KeyM_Update("SHE", ...) mit dem verschlüsselten bzw. verpackten Key-Material.
   • KeyM verarbeitet/extrahiert das Schlüsselmaterial und ruft Csm_KeyElementSet(...) am Csm auf, um den aufbereiteten Schlüssel in das konfigurierte Ziel-Element der CSM-Schlüsselstruktur zu schreiben.
   • Nach erfolgreichem Schreiben des Key-Elements ruft KeyM Csm_KeySetValid(...) auf, um den Zustand des CSM-Keys von INVALID auf VALID zu setzen.
   • KeyM signalisiert den erfolgreichen Abschluss an die Application zurück.

4. Normative Relevanz & Entwickler-Hinweise

• Zustandssicherheit (State Consistency): Ein Schlüssel ist im CSM erst nach dem expliziten Csm_KeySetValid() verwendbar. Bricht der Ablauf zwischen Csm_KeyElementSet und Csm_KeySetValid ab (z. B. Reset, fehlerhafte Checksumme, MAC-Mismatch im SHE-Update), bleibt der Schlüssel ungültig und schützt vor Verwendung partieller/korrupter Schlüsseldaten.
• Konfigurationsabhängigkeit: Die Zuordnung des "SHE"-Formats erfordert die entsprechende Konfiguration des KeyMKeyHandler sowie konsistente IDs (keyId, keyElementId) im CSM/CryIf/Crypto-Treiber (z. B. HSM- oder SHE-Emulation).
• Synchronität vs. Blockierungszeit: Sowohl Csm_KeyElementSet als auch Csm_KeySetValid können bei HSM-Anbindung signifikante Latenzen erzeugen. Der Aufrufkontext der Applikation darf bei synchroner Abwicklung nicht in zeitkritischen Tasks/Interrupts liegen.