Figure 9.57: Users of the Cryptography interfaces

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponentendiagramm mit Schnittstellen- und Abhängigkeitsbeziehungen (Stereotypen des AUTOSAR Adaptive Platform Profils: «aapFunctionalCluster», «aapAPI», «aapNativeInterface»).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP, Release R21-11), Spezifikation der Software-Architektur (AUTOSAR_EXP_SWArchitecture).
• Technischer Zweck: Darstellung der internen Plattform-Konsumenten (Functional Clusters) der nativen C++-Kryptografie-Schnittstelle (ara::crypto) sowie der Entkopplung zwischen API-Abstraktion (CryptoStack) und der darunterliegenden daemon-basierten Implementierung des Functional Clusters Cryptography.

2. Komponenten, Entitäten & Schnittstellen

• Schnittstelle:
  • «aapAPI, aapNativeInterface» CryptoStack: Die standardisierte C++-Programmierschnittstelle (ara::crypto). Definiert Datentypen, Algorithmus-Kontexte (Symmetric/Asymmetric Ciphers, Message Authentication Codes, Hashing, Key Derivation), Schlüsselverwaltungsstrukturen (KeyStorageProvider, Keyslot) sowie X.509-Zertifikats-Handling.
• Konsumenten (Clients / Dependents):
  • «aapFunctionalCluster» Persistency (ara::per): Nutzt («use») den CryptoStack zur kryptografischen Absicherung persistenter Daten (Verschlüsselung sensibler Schlüssel-Wert-Speicher/Dateien via AES-CBC/GCM, Authentizitätsprüfung per HMAC/CMAC).
  • UCM Subordinate (ara::ucm): Update and Configuration Management Subordinate. Nutzt («use») den CryptoStack für die Validierung von Software-Paketen (Signaturprüfung via RSA/ECDSA, Entschlüsselung von Software-Payloads, Integritäts- und Manifest-Verifikation).
  • «aapFunctionalCluster» Communication Management (ara::com): Nutzt («use») den CryptoStack zur Absicherung von Dienst- und Netzwerkkommunikation (Handshake-/Session-Key-Ableitung für SecOC, TLS/DTLS-Zertifikats- und Schlüsselaustausch, Authentisierung von Endpunkten).
• Anbieter (Provider / Realization):
  • «aapFunctionalCluster» Cryptography (daemon-based): Reale Implementierungseinheit. Realisiert die CryptoStack-Schnittstelle (Interface Realization, gestrichelte Linie mit geschlossener Dreiecksspitze).
• Beziehungssemantik:
  • Gerichtete Abhängigkeiten («use»): Plattform-Cluster hängen ausschließlich vom standardisierten API-Vertrag (CryptoStack) ab, nicht von der konkreten Implementierung oder Prozessgrenze des Daemons.

3. Dynamisches Verhalten & Sequenzablauf

• Prozessgrenzen & Interaktionsmuster:
  • Daemon-basierte Ausführung: Der Functional Cluster Cryptography läuft als eigenständiger System-Prozess/Dienst (Daemon).
  • Client-Stub-Abstraktion: Die API (CryptoStack) wird im Adressraum der Konsumenten (Persistency, UCM, Communication Management) als Bibliothek eingebunden und leitet Aufrufe über typsichere IPC (Inter-Process Communication) oder Shared-Memory-Puffer an den Krypto-Daemon weiter.
• Synchroner vs. Asynchroner Pfad:
  • Standard-Initialisierungen, Kontext-Erzeugungen und Slot-Suchen laufen synchron.
  • Rechenintensive kryptografische Operationen (z. B. Paket-Signaturverifikation in UCM oder Massendatenverschlüsselung in Persistency) nutzen die in Adaptive AUTOSAR üblichen asynchronen Muster (ara::core::Future / ara::core::Promise) oder blockierende synchrone Calls je nach Schnittstellenprofil.
• Fehlerbehandlung:
  • Kein C++-Exception-Pfad im POSIX-Kernel-Interface; Rückgabe erfolgt normativ über ara::core::Result<T, CryptoErrorDomain>.

4. Normative Relevanz & Entwickler-Hinweise

• Hardware-Isolation & Key Protection: Durch die Kapselung im Krypto-Daemon verbleiben sensitive Schlüsselmaterialien (PrivateKey, symmetrische Master-Keys) isoliert im geschützten Speicherbereich des Daemons bzw. werden direkt an ein Hardware Security Module (HSM), eine Trusted Execution Environment (TEE) oder einen Secure Hardware Extension (SHE) Treiber delegiert. Konsumenten erhalten lediglich ephemere Handles (KeySlot, CryptoProvider).
• IPC-Overhead & Latenzen: Stack- und Treiber-Entwickler müssen den Kontextwechsel und IPC-Overhead bei Kommunikationspfaden (insb. in Communication Management für hochfrequente Stream-Verschlüsselung) einkalkulieren. Zero-Copy-Mechanismen oder dedizierte Shared-Memory-Pages für Nutzdaten-Puffer zwischen Konsument und Daemon sind für Echtzeitanforderungen zwingend erforderlich.
• Deployment & Zugriffsrechte: Für jeden Konsumenten (Persistency, UCM, Applikationen) müssen im AUTOSAR-Manifest (CryptoServiceCertificate, CryptoServiceKey) die kryptografischen Berechtigungen (z. B. Zugriff auf spezifische Key-Slots, Algorithmen-Suites) granular konfiguriert werden; der Daemon fungiert als Enforcement Point.