Figure 9.65: 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: Standardisierte native C++-Schnittstelle (ara::crypto) der AUTOSAR Adaptive Platform. Stellt Krypto-Primitive, Schlüsselverwaltung (KeyStorageProvider, Keyslot) sowie X.509-Zertifikatsdienste bereit.
• Konsumenten (Clients / Dependents):
  • «aapFunctionalClust... Persistency (ara::per): Nutzt («use») den CryptoStack zur kryptografischen Absicherung gespeicherter Daten (Verschlüsselung sensibler Key-Value-Stores und Dateien, Integritätsprüfungen via MAC/Hash).
  • «aapFunctionalCluster» Update and Configuration Management daemon-based (ara::ucm): Update- und Konfigurationsmanager. Nutzt («use») den CryptoStack zur Signaturverifikation von Software-Paketen, Entschlüsselung von Software-Payloads sowie Manifest- und Integritätsvalidierung.
  • «aapFunctionalCluster» Vehicle Update and Configuration Management daemon-based (ara::vucm): Fahrzeugweiter Kampagnen- und Update-Manager. Nutzt («use») den CryptoStack zur Verifikation fahrzeugweiter Software-Updates, Kampagnen-Signaturen und OEM-Zertifikatsketten.
  • «aapFunctionalClust... Diagnostic Management daemon-based (ara::diag / ara::dm): Diagnose-Cluster. Nutzt («use») den CryptoStack zur Absicherung von Diagnose-Sessions (DoIP / UDS), Authenticated Diagnostic Services und kryptografischen Berechtigungsnachweisen (Security Access).
  • «aapFunctionalCluster» Communication Management daemon-based (ara::com): Dienst- und Netzwerkkommunikation. Nutzt («use») den CryptoStack für Transportsicherheit (TLS/DTLS-Handshakes, Zertifikatsvalidierung) sowie Session-Key-Ableitung und SecOC.
  • «aapFunctionalCluster» Raw Data Stream (ara::rds): Cluster für unstrukturierte Streaming-Daten. Nutzt («use») den CryptoStack zur kontinuierlichen Ver- und Entschlüsselung sowie Authentifizierung von Datenströmen mit hohem Durchsatz (z. B. Sensor-/Kameradaten).
  • «aapFunctionalClust... Intrusion Detection System Manager daemon-based (ara::idsm): Sicherheitsüberwachung. Nutzt («use») den CryptoStack zur Authentifizierung und kryptografischen Integritätssicherung von Security Events und Protokollen.
• Anbieter (Provider / Realization):
  • «aapFunctionalCluster» Cryptography daemon-based: Zentrale Implementierungseinheit; realisiert die Schnittstelle CryptoStack (Interface Realization, gestrichelte Linie mit geschlossener Dreiecksspitze).
• Beziehungssemantik:
  • Sieben gerichtete Abhängigkeiten («use»): Sämtliche Konsumenten greifen ausschließlich über die typsichere CryptoStack-API auf Kryptografie- und Schlüsseldienste zu. Fünf der sieben Konsumenten sowie der Provider sind explizit als daemon-based modelliert.

3. Dynamisches Verhalten & Sequenzablauf

• Prozessgrenzen & Interaktionsmuster:
  • Daemon-Architektur: Sowohl der Krypto-Anbieter (Cryptography) als auch fünf der sieben Konsumenten (Update and Configuration Management, Vehicle Update and Configuration Management, Diagnostic Management, Communication Management, Intrusion Detection System Manager) sind als eigenständige Daemons ausgeführt. Persistency und Raw Data Stream agieren primär als bibliotheksbasierte Cluster.
  • Client-Stub-Abstraktion: Die Konsumenten binden die CryptoStack-Bibliothek lokal in ihren Adressraum ein. API-Aufrufe werden transparent über Inter-Process Communication (IPC) bzw. Shared-Memory-Kanäle an den zentralen Cryptography-Daemon delegiert.
• Synchroner vs. Asynchroner Pfad:
  • Kontexterzeugung, Slot-Auflösung und Standard-Krypto-Primitive laufen typischerweise synchron ab.
  • Asynchrone Aufrufe (via ara::core::Future / ara::core::Promise) kommen bei rechenintensiven Operationen wie asymmetrischer Signaturverifikation (in UCM/Vehicle UCM) oder bei hohem Datendurchsatz (in Raw Data Stream und Communication Management) zum Einsatz, um ein Blockieren der Daemon-Ereignisschleifen zu verhindern.
• Fehlerbehandlung:
  • Kein C++-Exception-Pfad im POSIX-Kernel-Interface; standardisierte Fehlerbehandlung über ara::core::Result<T, CryptoErrorDomain>.

4. Normative Relevanz & Entwickler-Hinweise

• Zentraler Architekturvertrag: Die Spezifikation untersagt proprietäre Kryptografie-Lösungen innerhalb einzelner Funktionscluster. Alle Plattform-Komponenten müssen Kryptografie- und Zertifikatsoperationen zwingend über den CryptoStack abwickeln.
• Schlüsselschutz & Hardware-Kapselung: Private Schlüssel und symmetrische Master-Keys verbleiben strikt im geschützten Speicher des Krypto-Daemons bzw. in angebundenen Hardware-Sicherheitsmodulen (HSM/TEE/SHE). Konsumenten arbeiten ausschließlich mit abstrakten Handles (KeySlot, CryptoProvider).
• Performance & Streaming-Optimierung: Durch die Ausführung von Provider und Konsumenten als Daemons entstehen IPC-Latenzen. Für datenintensive Cluster wie Raw Data Stream und Communication Management müssen Zero-Copy- oder Shared-Memory-Puffer implementiert werden, um Kontextwechsel bei kontinuierlichen Krypto-Operationen zu minimieren.
• Granulares Rechtemanagement im Manifest: Für jeden angebundenen Cluster (insbesondere UCM, Vehicle UCM, Diag und IDSM) müssen im AUTOSAR-Deployment-Manifest Zugriffsrechte auf spezifische Key-Slots, Algorithmen und Zertifikate restriktiv und isoliert deklariert werden; der Cryptography-Daemon agiert als zentraler Enforcement Point.