Figure 9.65: Cryptographic Key Handling Interfaces

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Schnittstellen- und Komponentendiagramm (AUTOSAR Adaptive Platform Architecture Model) unter Verwendung platformspezifischer Stereotypen («aapFunctionalCluster», «aapAPI», «aapNativeInterface», «aapPortInterface», «aapRequiredPort», «aapCallbackMethod»).
• Technischer Zweck: Spezifikation der Architektur zur Verwaltung, Speicherung und Überwachung kryptografischer Schlüssel und Objekte (Key Handling) im Functional Cluster Cryptography (ara::crypto::keys) der AUTOSAR Adaptive Platform (Release R21-11).
• Funktionale Einordnung: Definiert die Entkopplung zwischen der konsumierenden Applikationsebene (Adaptive Application) und der plattformseitigen, zustandsbehafteten Schlüsselverwaltung (Cryptography daemon-based) über definierte C++-Laufzeitschnittstellen und modellierte AUTOSAR-Ports.

2. Komponenten, Entitäten & Schnittstellen

Komponenten / Akteure

• Adaptive Application: Applikationsprozess im User-Space, der kryptografische Operationen anfordert, Schlüssel verarbeitet und als Observer für Schlüsseländerungen agiert.
• «aapFunctionalCluster» Cryptography (daemon-based): Plattform-Dienst/Daemon, der die physische Persistenz, Hardware-Sicherheitsmodule (HSM/SHE/TPM-Anbindung), Zugriffsschutz und Transaktionsverwaltung für kryptografische Speicher kapselt.

Schnittstellen & Beziehungen

• KeyStorageProvider («aapAPI, aapNativeInterface»):
  • Rolle: Zentrale Factory- und Transaktions-Schnittstelle zur Schlüsselverwaltung.
  • Methoden: BeginTransaction(), CommitTransaction(), RollbackTransaction(), LoadKeySlot(), RegisterObserver(), UnsubscribeObserver(), GetRegisteredObserver().
  • Beziehungen: Wird von Adaptive Application verwendet («use»); wird vom Cryptography-Daemon realisiert (Interface Realization, gestrichelte Dreieck-Kante).
• KeySlot («aapAPI, aapPortInterface»):
  • Rolle: Repräsentiert einen logischen Schlüssel-Speicherplatz (Container für symmetrische/asymmetrische Schlüssel, Zertifikate oder Krypto-Parameter).
  • Methoden: Open(), Clear(), SaveCopy(), IsEmpty(), GetContentProps(), GetPrototypedProps(), MyProvider().
  • Beziehungen: Wird vom Cryptography-Daemon bereitgestellt/realisiert; wird von der Adaptive Application über einen modellierten AUTOSAR-Port gebunden («use» via «aapRequiredPort»).
• UpdatesObserver («aapAPI, aapNativeInterface»):
  • Rolle: Asynchrone Callback-Schnittstelle für Benachrichtigungen über Slot-Aktualisierungen.
  • Methoden: «aapCallbackMethod» + OnUpdate().
  • Beziehungen: Wird von der Adaptive Application implementiert/realisiert (Realization-Pfeil von Application auf Observer); wird vom Cryptography-Daemon aufgerufen («use»).

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung & Slot-Bindung:
   • Die Adaptive Application bindet einen statisch im Execution Manifest modellierten KeySlot über ihren «aapRequiredPort» oder lädt ihn dynamisch über KeyStorageProvider::LoadKeySlot().
   • KeySlot::Open() instanziiert das kryptografische Objekt im Speicher zur weiteren Verwendung in Krypto-Kontexten.
   • Status und Metadaten werden synchron via IsEmpty(), GetPrototypedProps() (Soll-Konfiguration aus dem Manifest) und GetContentProps() (Ist-Zustand des geladenen Schlüssels) abgefragt.
2. Transaktionales Schreiben / Löschen:
   • Modifikationen an Schlüsseln (z. B. Key Injection, Key Exchange, Provisionierung) erfordern Transaktionssicherheit:
     • Aufruf von KeyStorageProvider::BeginTransaction().
     • Manipulation am Speicherplatz über KeySlot::SaveCopy() (Einbringen eines neuen/modifizierten Schlüssels) oder KeySlot::Clear().
     • Abschluss via KeyStorageProvider::CommitTransaction() (atomare Persistierung im Daemon/NVRAM/HSM) oder RollbackTransaction() bei Validierungsfehlern.
3. Asynchrone Aktualisierung (Observer-Mechanismus):
   • Die Applikation instanziiert eine konkrete Klasse, die UpdatesObserver implementiert.
   • Registrierung beim Plattform-Daemon via KeyStorageProvider::RegisterObserver().
   • Ändert sich der Inhalt eines Slots extern (z. B. via Diagnose, Over-the-Air Update oder ein paralleles Security-Management), feuert der Cryptography-Daemon asynchron das Callback UpdatesObserver::OnUpdate().
   • Beendigung der Überwachung erfolgt über KeyStorageProvider::UnsubscribeObserver().

4. Normative Relevanz & Entwickler-Hinweise

• Manifest-Modellierung vs. Native C++-API:
  • KeySlot ist als «aapPortInterface» ausgelegt. Dies erfordert im AUTOSAR-Modell (ARXML) die Definition von CryptoKeySlotInterface, PortPrototype (RPortPrototype) und entsprechenden Instanziierungen im Execution/Service Instance Manifest.
  • KeyStorageProvider und UpdatesObserver sind «aapNativeInterface» und werden direkt im C++-Code gegen den Standard-Header (ara/crypto/keys/...) implementiert bzw. gelinkt.
• Transaktionskapselung & Thread-Safety:
  • Transaktionen (BeginTransaction/CommitTransaction) müssen zwingend atomar gegen Stromausfall (Power-Loss Safe) im Daemon implementiert sein. Applikationsentwickler müssen parallele Schreibzugriffe durch entsprechende Rollback-Behandlung absichern.
• Callback-Restriktionen (OnUpdate):
  • Der Aufruf von OnUpdate() erfolgt im Kontext eines IPC/Daemon-Worker-Threads. Die Implementierung in der Applikation muss non-blocking und thread-sicher sein; langlaufende Krypto-Berechnungen dürfen nicht direkt im Callback ausgeführt werden.
• Zugriffskontrolle (IAM):
  • Jeder Zugriff auf Methoden wie KeySlot::Open(), SaveCopy() oder Clear() wird vom Daemon gegen die im Deployment-Manifest hinterlegten IAM-Richtlinien (Identity and Access Management) validiert. Unberechtigte Prozesse erhalten Zugriffsfehler (SecurityError).