Figure 15.2: CKI Key Management Interactions

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Architektur- und Interaktionsdiagramm mit Darstellung von Sicherheits-/Vertrauensdomänen (Trust Boundaries), Software-Schichten und Kontroll-/Datenflüssen.
• Technischer Zweck: Spezifikation der Schlüsselverwaltungs- und Zugriffskontroll-Architektur (Cryptographic Key Interface, CKI / ara::crypto) in der AUTOSAR Adaptive Platform (AP).
• Funktionale Einordnung: Trennung zwischen unprivilegiertem Anwendungsraum (Adaptive Applications), isolierter Kontroll- und Ausführungsebene (Isolated & Trusted Environment) sowie persistenter/hardwaregestützter Schlüsselspeicherebene (File System or HSM) zur Durchsetzung von Least-Privilege- und Zero-Plaintext-Exposure-Prinzipien.

2. Komponenten, Entitäten & Schnittstellen

Das Diagramm unterteilt das System über vertikale Vertrauensgrenzen in drei Domänen:

• Domäne 1: Adaptive Applications (Unprivilegierter User Space)
  • Adaptive Application (unter Kontrolle des Execution Manager als Exec App.): Nutzt Krypto-Dienste.
  • Application Manifest: Modellierungsartefakt, definiert Identität und Ressourcenrechte der Applikation.
  • CryptoAPI Library: Applikationsseitige API-Bibliothek (ara::crypto::keys, ara::crypto::cryp).
  • Security services (IKE / UCM / PER): Plattformdienste (Internet Key Exchange, Update and Configuration Management, Persistency) mit Bedarf an Krypto-Provider-Funktionalität.
• Domäne 2: Isolated & Trusted Environment (Privilegierter Daemon- / TEE-Kontext)
  • Execution Manager: Verifiziert beim Prozessstart das Application Manifest und stellt die Application ID bereit.
  • Identity and Access Management (IAM): Sicherheitsgrenze, enthält:
    • Key Storage Provider (ara::crypto::keys::KeyStorageProvider): Zentrale Instanz zur Verwaltung von Key-Slots.
    • Rights table: Autorisierungsmatrix, dynamisch oder statisch aus der Capabilities DB gespeist.
  • Crypto Provider Backend: Führt die tatsächlichen kryptographischen Operationen in einer geschützten Umgebung aus.
• Domäne 3: File System or HSM (Persistenz- und Hardware-Ebene)
  • Key Storage Manifest: Beschreibt Speicherorte, Slot-Konfigurationen und Zugriffspolicies der Schlüssel.
  • Protected Key Storage: Verschlüsselter/integritätsgeschützter Dateispeicher für persistente Schlüssel.
  • HSM (Hardware Security Module / Secure Element): Kryptographischer Hardware-Vertrauensanker.
• Schnittstellen & Kanäle:
  • openEmpty(slotID), openExisting(slotID), clean(slotID): IPC-Aufrufe von CryptoAPI Library an Key Storage Provider.
  • Opaque "container" hnd.: Opakes Handle (ara::crypto::keys::KeySlot), das der Applikation als Schlüsselreferenz zurückgegeben wird.
  • loadKey("container" hnd.), saveKey("container" hnd.): IPC-Schnittstelle von CryptoAPI Library zum Crypto Provider Backend.
  • Trusted channel (Container access API): Dedizierter Kanal zwischen Key Storage Provider und Crypto Provider Backend zur Auflösung der Container-Referenzen.
  • Encrypted channel: Abgesicherter Transportkanal zwischen Key Storage Provider und Protected Key Storage.
  • Control channel: Direkte Anbindung des Crypto Provider Backend an das HSM.

3. Dynamisches Verhalten & Sequenzablauf

1. Authentifizierung & Autorisierungsabgleich (IAM-Pfad):
   • Der Execution Manager startet die Applikation, liest das Application Manifest aus und übergibt die validierte Application ID an den Key Storage Provider.
   • Die Capabilities DB initialisiert bzw. aktualisiert die Rights table innerhalb des IAM-Bereichs.
2. Slot-Allokation / Öffnen eines Schlüssels (Synchroner IPC-Pfad):
   • Die Applikation fordert über die CryptoAPI Library einen Schlüssel an (openExisting(slotID)) oder alloziert einen leeren Slot (openEmpty(slotID)).
   • Der Key Storage Provider gleicht die Application ID gegen die Rights table ab.
   • Bei erfolgreicher Autorisierung ruft der Key Storage Provider die verschlüsselten Schlüsseldaten über den Encrypted channel aus dem Protected Key Storage (konfiguriert via Key Storage Manifest) ab.
   • Der Key Storage Provider liefert ausschließlich ein opakes Handle (Opaque "container" hnd.) an die CryptoAPI Library zurück. Das Klartext-Schlüsselmaterial gelangt zu keinem Zeitpunkt in den Adressraum der Applikation.
3. Kryptographische Verarbeitung (Backend-/HSM-Pfad):
   • Die Applikation übergibt das Handle via loadKey("container" hnd.) an das Crypto Provider Backend.
   • Das Crypto Provider Backend validiert und referenziert den Container über den Trusted channel beim Key Storage Provider.
   • Berechnungen (z. B. Signaturerzeugung, Ver-/Entschlüsselung) werden im Backend oder hardwarebeschleunigt über den Control channel direkt im HSM ausgeführt.
4. Persistierung & Bereinigung:
   • Modifizierte Schlüssel werden mittels saveKey("container" hnd.) über das Backend und den Storage Provider zurück in den Protected Key Storage geschrieben.
   • clean(slotID) löscht den Inhalt des Ziel-Slots und synchronisiert den Zustand mit dem Speicher/HSM.

4. Normative Relevanz & Entwickler-Hinweise

• Zero-Plaintext-Exposure: Anwendungs- und Middleware-Entwickler dürfen weder symmetrisches Schlüsselmaterial noch private asymmetrische Schlüssel im Applikationsspeicher halten. Alle Interaktionen basieren strikt auf ara::crypto::CryptoObject bzw. KeySlot-Handles.
• Manifest-Abhängigkeit: Jeder Zugriff auf einen slotID schlägt zur Laufzeit fehl (ara::crypto::SecurityError), wenn die Bindung zwischen Application Manifest (Process / IAM-Grant), Capabilities DB und Key Storage Manifest inkonsistent ist.
• Transparente HSM-Integration: Die Trennung von Key Storage Provider und Crypto Provider Backend ermöglicht Architekturen, bei denen der Schlüssel rein hardwarekapselt im HSM verbleibt, während die Applikation identische API-Aufrufe nutzt.
• IPC-Overhead berücksichtigen: Aufrufe wie openExisting und loadKey passieren Prozess-/Domänengrenzen und binden IAM-Checks ein. Schlüssel-Handles müssen daher im Lebenszyklus der Applikation gecacht und dürfen nicht in latenzkritischen Regelschleifen zyklisch neu geöffnet werden.