Figure 7.2: NvBlock configuration for key persistence

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Metamodell- / BSW-Konfigurations-Klassendiagramm (ECUC-Strukturmodell).
• Technischer Zweck & Einordnung: Spezifikation des Persistierungsmodells kryptografischer Schlüssel (Key Persistence) im AUTOSAR Classic Platform Crypto Driver (Crypto, MCAL/BSW-Treiberschicht) in Relation zum Non-Volatile RAM Manager (NvM, BSW-System-/Serviceschicht) gemäß SRS_CryptoStack_00061 und SWS_Crypto_00242.
• Funktionale Einordnung: Definiert die statische Verknüpfung zwischen logischen Schlüsselinstanzen des Crypto-Stacks und persistenten Speicherblöcken des NvM zur Erhaltung des Schlüsselmaterials über Power-Cycles hinweg.

2. Komponenten, Entitäten & Schnittstellen

• NVM::NvBlock (NvMBlockDescriptor):
  • Konfigurationscontainer des NvM-Moduls.
  • Repräsentiert die logische Abstraktion eines nicht-flüchtigen Speicherblocks (EEPROM/Flash) inklusive RAM-Spiegel (RAM Block) und Management-Headern.
• Key (CryptoKey):
  • Konfigurationscontainer einer logischen Schlüsselinstanz im Crypto Driver, adressiert über eine systemweit eindeutige CryptoKeyId.
  • Hält Laufzeitstatus, Gültigkeitsflags (valid/invalid) und die Instanzdaten.
• KeyType (CryptoKeyType):
  • Struktureller Typ- und Metadatencontainer, der das logische Layout eines Schlüssels definiert.
• KeyElement (CryptoKeyElement):
  • Atomare Dateneinheit innerhalb eines Schlüssels (z. B. eigentlicher Schlüsselwert, IV, Salt, Exponent, Zähler).
  • Definiert Attribute wie CryptoKeyElementId, CryptoKeyElementSize, Format und Lese-/Schreibberechtigungen.

Beziehungen & Kardinalitäten

• Key $\xrightarrow{\text{<<reference>>}}$ NvBlock (1..* zu 0..1):
  • Gerichtete Konfigurationsreferenz (CryptoKeyNvBlockRef).
  • 0..1 an NvBlock: Ein Schlüssel ist entweder flüchtig (Kardinalität 0, rein transientes Key-Handling im RAM) oder persistent (Kardinalität 1, an einen persistenten NV-Block gekoppelt).
  • 1..* an Key: Ein NvBlock kann von einem oder mehreren Schlüsseln referenziert werden (Shared-Block-Ansatz bei aggregierten Key-Containern).
• Key ⟶ KeyType (Kardinalität 1):
  • Typisierungsbeziehung: Jede Schlüsselinstanz instanziiert exakt einen definierten KeyType.
• KeyType — KeyElement (Kardinalität 1..*):
  • Aggregation/Komposition: Ein KeyType setzt sich aus mindestens einem oder beliebig vielen atomaren KeyElement-Definitionen zusammen.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierungsphase (Crypto_Init / Startup):
   • Das Laden persistenter Schlüsseldaten erfolgt typischerweise im Zuge von NvM_ReadAll() oder über eine explizite Ladeoperation (NvM_ReadBlock()) in den konfigurierten RAM-Spiegel des Treibers.
   • Der Crypto Driver synchronisiert den Zustand (VALID/INVALID) anhand der im NvM abgelegten Metadaten.
2. Schlüsselmodifikation (Crypto_KeyElementSet):
   • Aktualisierungen einzelner KeyElements schreiben Daten zunächst synchron in den RAM-Arbeitspuffer des Crypto Drivers.
3. Persistierungs-Trigger (Crypto_KeySetValid):
   • Durch das Validieren des Schlüssels via Crypto_KeySetValid() wird der Persistierungsvorgang ausgelöst (SWS_Crypto_00242).
   • Ist CryptoKeyNvBlockRef gesetzt, initiiert der Treiber das Schreiben des Schlüsselmaterials in den NvM (asynchroner Aufruf von NvM_WriteBlock() bzw. Vormerkung für NvM_WriteAll()).
4. Fehlerbehandlung & Synchronisation:
   • Fehler beim Lese-/Schreibzugriff auf den NvM führen zu Dem-Events bzw. Fehlerrückmeldungen (E_NOT_OK) und setzen den Status des CryptoKey auf ungültig.
   • Während eines laufenden NvM-Schreibvorgangs verriegelt der Treiber Zugriffe auf den Schlüssel gegen Dateninkonsistenz (CRYPTO_E_BUSY).

4. Normative Relevanz & Entwickler-Hinweise

• Blockgrößen-Kalkulation:
  • Der in NvM konfigurierte NvBlock muss exakt dimensioniert sein: Summe der Maximalgrößen aller im KeyType enthaltenen KeyElemente, für die CryptoKeyElementPersist == TRUE gesetzt ist, zuzüglich treiberspezifischer Header (z. B. Validitäts-Flag, Längenfelder).
• Sicherheitsvorgaben (Hardware Trust Anchor / HSM / SHE):
  • Plaintext-Ablage im Standard-Flash/EEPROM verletzt Security-Anforderungen. Bei Verwendung von Standard-NvM-Blöcken muss der Treiber das Schlüsselmaterial vor der Übergabe an den NvM verschlüsseln (Key Wrap) oder signieren.
  • Bei reiner Hardware-Persistenz (z. B. dedizierter Secure NVRAM im HSM) entfällt die NvBlock-Referenz (0), da die Persistierung treiberintern über die HSM-Firmware gesteuert wird.
• API- und Scheduling-Restriktionen:
  • Da NvM_WriteBlock() asynchron operiert, darf der Crypto Driver in synchronen CSM/Crypto-Aufrufen nicht blockierend auf den Abschluss des NvM-Zyklus warten. Der API-Vertrag verlangt geeignete Zustandspolling- oder Callback-Mechanismen (Csm_CallbackNotification).