Figure 15.1: Crypto Stack - Reference Architecture

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Technisches Architektur- und Schichten-/Bereitstellungsdiagramm (Component & Deployment/Trust Boundary Architecture) mit Domänentrennung und Schnittstellenbeziehungen.
• Funktionaler Kontext: Darstellung der Referenzarchitektur des AUTOSAR Adaptive Platform (AP) Crypto-Stacks (ara::crypto) gemäß AUTOSAR_AP_EXP_PlatformDesign (Kapitel 15). Das Diagramm definiert die funktionale Dekomposition zwischen Applikationsraum, vertrauenswürdiger Ausführungsumgebung (Isolated/Trusted Execution Environment, TEE/Daemon) und der zugrundeliegenden Hardware-/Speicherebene (HSM, Flash/Filesystem) sowie die Interaktion mit weiteren AP Functional Clusters (AP-FCs).

2. Komponenten, Entitäten & Schnittstellen

Das Diagramm gliedert sich in drei vertikale Sicherheits-/Isolationsdomänen sowie einen querschnittlichen Funktionscluster-Block:

A. Adaptive Applications (Unprivilegierter Applikationskontext)

• Adaptive Application: Endanwender- oder Plattformprozess im ungesicherten Userspace.
• CryptoAPI library (ara::crypto): Statisch oder dynamisch eingebundene Client-Bibliothek, unterteilt in:
  • Local Crypto-Provider: Führt hardwareunabhängige oder leistungskritische Operationen direkt im Prozesskontext aus:
    • Keyless & Session Ctx (z. B. ungeschützte Hashes wie SHA-256, HMAC mit transienten Sitzungsschlüsseln).
    • Public key (Verifikation asymmetrischer Signaturen, Parsing öffentlicher Schlüssel).
    • Session (Verwaltung lokaler, ephemerer Zustände).
  • IPC lib: Abstraktionsschicht für Interprozesskommunikation zur Weiterleitung priviligierter Krypto-Operationen an den Daemon.

B. Isolated/Trusted Env (Isolierter Daemon / TEE / Secure OS)

• IPC & Resource Management: Zentrale Vermittlungs- und Dispatcher-Instanz; übernimmt Authentifizierung, Zugriffsrechteprüfung (IAM / Access Control) und Ressourcen-Serialisierung.
• Key-Storage Provider (ara::crypto::keys::KeyStorageProvider): Managt logische Key-Slots, Import/Export, Generierung und Zugriffsrichtlinien persistenter Schlüssel.
• Crypto Provider (ara::crypto::cryp::CryptoProvider - mehrfach gestapelt): Modulare Treiber-/Backend-Instanzen für konkrete Krypto-Engines und Algorithmen (z. B. AES, ECC, RSA, ChaCha20).
• X.509 Provider (ara::crypto::x509::X509Provider): Verarbeitet Zertifikate, Zertifikatspfad-Validierung (Certificate Chains), OCSP/CRLs.

C. HW (file-sys, HSM) & Speicher-Entitäten

• Protected Key Storage: Persistenter, verschlüsselter und manipulationsgeschützter Schlüsselspeicher (Key Slots auf Dateisystem-/NVM-Ebene).
• HSM (Hardware Security Module): Kryptographischer Coprozessor / Secure Element für Schlüsselisolation und hardwarebeschleunigte Berechnungen.
• Certificate Storage: Speicherbereich für Trust-Anchors (Root-CAs), Zwischenzertifikate und Geräteidentitäten.
• Beziehungen & Stereotypen:
  • Protected Key Storage $\longleftrightarrow$ HSM (<<map>>): Schlüsselidentifikatoren bzw. Key-Slots im Storage mappen auf physikalische Hardware-Key-Handles im HSM.
  • Certificate Storage ⟶ Protected Key Storage (<<link>>): Zertifikate verweisen über Slot-IDs/UUIDs auf die zugehörigen privaten Schlüssel (Key Links).
  • Gelbe Bus-Pfeile: Standardisierte Treiberschnittstellen der Provider zu den jeweiligen Speicher- und HSM-Treibern.

D. AP-FCs (Adaptive Platform Functional Clusters)

• Enthält UCM (Update and Configuration Management), COM (Communication Management / SecOC / TLS), PER (Persistency / Encrypted Storage) und DIAG (Diagnostics / Authenticated Security Access).
• Beziehung AP-FCs ⟶ Protected Key Storage (<<use>>): Direkte funktionale Abhängigkeit der Plattform-Cluster von persistenten Schlüsseln und Zertifikatsstrukturen.

3. Dynamisches Verhalten & Sequenzablauf

1. Lokale Pfad-Entscheidung:
   • Ein Aufruf über die CryptoAPI library wird anhand des Schlüssel-Typs und Kontexts klassifiziert: Operationen ohne Sicherheitsanforderungen an den Key-Schutz (Keyless, Public Key) terminieren synchron im Local Crypto-Provider ohne Kontextwechsel.
2. IPC-Delegation an Trusted Env:
   • Operationen auf privaten, langlebigen oder Hardware-gebundenen Schlüsseln initiieren über die IPC lib einen synchronen/asynchronen IPC-Request an IPC & Resource Management.
3. Rechteprüfung & Dispatching:
   • IPC & Resource Management prüft die Prozessidentität und Berechtigung gegen hinterlegte Access Control Lists (ACL / IAM-Integration).
   • Der Request wird an den zuständigen Provider delegiert (Key-Storage Provider, Crypto Provider oder X.509 Provider).
4. Schlüssel-Auflösung & Hardware-Krypto:
   • Der Key-Storage Provider schlägt Metadaten und Handles im Protected Key Storage nach.
   • Der Crypto Provider führt die kryptographische Transformation unter Nutzung des HSM via <<map>> aus. Das Schlüsselmaterial selbst verlässt das HSM/die Trusted Boundary nicht (Zero-Leakage-Prinzip).
5. Rückmeldung:
   • Das Resultat (z. B. Signatur, Ciphertext oder ara::core::Result<T>) wird über IPC zurück in den Kontext der Adaptive Application transferiert.

4. Normative Relevanz & Entwickler-Hinweise

• Entkopplung & Portabilität: Applikationen dürfen zu keinem Zeitpunkt Rohschlüssel (Plaintext Keys) im Userspace verlangen. Es wird strikt mit opaken Schlüsselobjekten (ara::crypto::cryp::PrivateKey, KeySlot) gearbeitet.
• Konfigurationsverantwortung (Manifeste):
  • Für Key Slots müssen Zugriffsrechte (kAllowCryptoUsage, kAllowExport, etc.) in den Execution- und Service-Instance-Manifesten explizit definiert werden.
  • Das Mapping von logischen Key Slot IDs zu physischen Speicherpfaden bzw. HSM-Slots (<<map>>) erfolgt deklarativ in den Platform-Konfigurationsmodellen.
• Latenz- & Concurrency-Budgetierung:
  • Aufrufe über IPC in die Trusted Boundary und an das HSM erzeugen signifikanten CPU- und Kontextwechsel-Overhead. Zeitkritische Pfade (z. B. frame-basierte Signaturen in COM/SOME/IP) müssen asynchrone APIs nutzen (ara::core::Future).
  • Read-Only-Validierungen sollten durch Konfiguration des Local Crypto-Provider lokal gehalten werden, um Lock-Contention im Crypto-Daemon zu minimieren.
• Plattform-Integration (AP-FCs):
  • UCM: Erfordert zwingend den X.509 Provider zur Validierung der Software-Package-Signaturkette vor der Übergabe an Root-Key-Storage.
  • COM: Nutzt TLS/IPsec-Schlüssel über den Key-Storage Provider, wobei Session-Keys nach dem Handshake in flüchtige Kontexte überführt werden können.