Figure 10.9: KeyMCryptoKey Definition

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: AUTOSAR BSW Parameter Configuration Metamodel (UML-Klassendiagramm / ECUC Parameter Definition nach AUTOSAR BSW Architecture).
• Funktionale Einordnung: AUTOSAR Classic Platform (Release R22-11), Spezifikation des Key Managers (AUTOSAR_SWS_KeyManager). Das Modell definiert die Konfigurationsstruktur KeyMCryptoKey innerhalb des BSW-Moduls KeyM (Crypto Key Manager) zur Abbildung, Verwaltung, Derivierung und Persistierung kryptografischer Schlüssel sowie deren Bindung an die Crypto Service Manager (CSM) Infrastruktur und den Non-Volatile RAM Manager (NvM).

2. Komponenten, Entitäten & Schnittstellen

Zentraler Container

• KeyMCryptoKey (EcucParamConfContainerDef, Multiplizität: 0..65535): Repräsentiert die logische Konfigurationseinheit eines kryptografischen Schlüssels im KeyM.

Konfigurationsparameter (Aggregate via +parameter)

• KeyMCryptoKeyId (EcucIntegerParamDef): Eindeutiger Identifikator (min = 0, max = 65535, symbolicNameValue = true). Dient als Handle für KeyM-APIs.
• KeyMCryptoKeyMaxLength (EcucIntegerParamDef): Maximale Schlüssellänge in Byte (min = 1, max = 4294967295 / 2^32-1).
• KeyMCryptoKeyName (EcucStringParamDef): Textuelle Bezeichnung des Schlüssels.
• KeyMCryptoKeyGenerationType (EcucEnumerationParamDef):
  • KEYM_STORED_KEY: Statisch hinterlegter / direkt injizierter Schlüssel.
  • KEYM_DERIVED_KEY: Zur Laufzeit abgeleiteter Schlüssel.
• KeyMCryptoKeyStorage (EcucEnumerationParamDef):
  • KEYM_STORAGE_IN_CSM: Persistierung/Verwaltung direkt im CSM bzw. Crypto Driver (Crypto Key Elements).
  • KEYM_STORAGE_IN_NVM: Persistierung im NvM über KeyM-Verwaltung.
  • KEYM_STORAGE_IN_RAM: Volatile Haltung im RAM.
• KeyMCryptoCsmVerifyJobType (EcucEnumerationParamDef, Multiplizität: 0..1): Kryptografische Verifikationsoperation zur Integritäts-/Authentizitätsprüfung des Schlüssels:
  • KEYM_VERIFY_MACGENERATE
  • KEYM_VERIFY_MACVERIFY
  • KEYM_VERIFY_ENCRYPT
  • KEYM_VERIFY_DECRYPT
  • KEYM_VERIFY_AEADENCRYPT
  • KEYM_VERIFY_AEADDECRYPT
• KeyMCryptoKeyGenerationInfo (EcucStringParamDef, Multiplizität: 0..1): Zusatzparameter/Kontext für Schlüsselableitung.
• KeyMCryptoKeyCryptoProps (EcucStringParamDef, Multiplizität: 0..1): Kryptografische Eigenschaften/Restriktionen des Schlüssels.

Referenzen (Aggregate via +reference → +destination)

• KeyMCryptoKeyCsmKeyTargetRef (EcucReferenceDef, Multiplizität: 1..1, requiresSymbolicNameValue = true):
  • Ziel: CsmKey (from Csm, Multiplizität: 0..*).
  • Verpflichtende Verknüpfung auf den Ziel-CSM-Schlüssel, in den das Schlüsselmaterial geladen/aktualisiert wird.
• KeyMCryptoKeyCsmKeySourceDeriveRef (EcucReferenceDef, Multiplizität: 0..1, requiresSymbolicNameValue = true):
  • Ziel: CsmKey (from Csm, Multiplizität: 0..*).
  • Basisschlüssel (Master/Base Key) im CSM für Ableitungsoperationen bei KEYM_DERIVED_KEY.
• KeyMCryptoKeyCsmVerifyJobRef (EcucReferenceDef, Multiplizität: 0..1, requiresSymbolicNameValue = true):
  • Ziel: CsmJob (from Csm, Multiplizität: 1..*).
  • CSM-Job für kryptografische Verifikation des Schlüsselmaterials vor Aktivierung/Nutzung.
• KeyMCryptoKeyNvmBlockRef (EcucReferenceDef, Multiplizität: 0..1):
  • Ziel: KeyMNvmBlock (EcucParamConfContainerDef, Multiplizität: 0..65535).
  • Verknüpfung zur NvM-Blockkonfiguration, obligatorisch bei KEYM_STORAGE_IN_NVM.

3. Dynamisches Verhalten & Sequenzablauf

Aus dem statischen Konfigurationsmodell resultieren folgende Laufzeitpfade:

1. Initialisierung & Ladevorgang:
   • Bei Start/Request prüft KeyM KeyMCryptoKeyStorage:
     • KEYM_STORAGE_IN_NVM: Anforderung des Datensatzes über KeyMNvmBlockRef aus dem NvM; Übertragung des Schlüsselmaterials in das RAM bzw. Weiterleitung an CSM.
     • KEYM_STORAGE_IN_CSM: Schlüssel verbleibt im Crypto Driver Stack; KeyM hält nur ID-Zuordnungen.
     • KEYM_STORAGE_IN_RAM: Temporäres Caching; kein Non-Volatile Restore.
2. Schlüsselableitung (KEYM_DERIVED_KEY):
   • Trigger via KeyM-API (KeyM_DeriveKey o. ä.).
   • Auslesen des Quellschlüssels über KeyMCryptoKeyCsmKeySourceDeriveRef.
   • Ableitungsoperation unter Nutzung von KeyMCryptoKeyGenerationInfo.
   • Schreiben des abgeleiteten Schlüssels in den Ziel-CSM-Key (KeyMCryptoKeyCsmKeyTargetRef).
3. Schlüssel-Verifikation (Pre-/Post-Activation Gate):
   • Falls KeyMCryptoKeyCsmVerifyJobRef und KeyMCryptoCsmVerifyJobType konfiguriert sind:
   • Ausführung des referenzierten CsmJob (z. B. MAC/AEAD Verify).
   • Bei Fehlschlag: Abbruch der Schlüsselaktivierung, Fehler-Rückgabe (E_NOT_OK) und optional Det/Dem-Meldung.

4. Normative Relevanz & Entwickler-Hinweise

• Kardinalitäts- und Validierungsregeln:
  • KeyMCryptoKeyCsmKeyTargetRef ist zwingend (1..1). Jeder KeyM-Schlüssel muss auf genau einen CSM-Schlüssel mappen.
  • Wenn KeyMCryptoKeyGenerationType == KEYM_DERIVED_KEY, muss KeyMCryptoKeyCsmKeySourceDeriveRef konfiguriert sein; andernfalls ist die Konfiguration inkonsistent.
  • Wenn KeyMCryptoKeyStorage == KEYM_STORAGE_IN_NVM, muss KeyMCryptoKeyNvmBlockRef zwingend auflösbar sein.
  • KeyMCryptoKeyCsmVerifyJobRef und KeyMCryptoCsmVerifyJobType müssen paarweise konsistent konfiguriert werden; der CSM-Job-Algorithmus muss dem gewählten VerifyJobType entsprechen.
• Symbolic Name Generation:
  • Da KeyMCryptoKeyId, KeyMCryptoKeyCsmKeyTargetRef und KeyMCryptoKeyCsmVerifyJobRef symbolicNameValue = true setzen, generiert der Generator Header-Defines (z. B. KeyMConf_KeyMCryptoKey_<ShortName>), die typischerweise als uint16-Handles in BSW- und SWC-Aufrufen verwendet werden.
• Pufferallokation & Dimensionierung:
  • KeyMCryptoKeyMaxLength steuert statische Puffergrößen im KeyM-RAM und Serialisierungs-Payloads bei NvM-Transaktionen. Falsch konfigurierte Werte führen entweder zu Buffer-Overflows (durch Security-Checks abgefangen) oder zu RAM-Verschwendung.