Figure 7.1: High-level CryptoAPI architecture

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Komponenten-, Schichten- und Isolationsmodell (High-Level Deployment/Runtime-Architektur) mit definierten Prozess- und Sicherheitsdomänen (Trust Boundaries).
• Technischer Zweck & Einordnung:
  • Definiert die logische und physische Trennung der Adaptive Platform CryptoAPI (ara::crypto) gemäß AUTOSAR_AP_SWS_Cryptography (Kapitel 7, High-level CryptoAPI architecture).
  • Trennt den unprivilegierten Applikationskontext (Adaptive Applications) von sicherheitskritischen Ausführungsumgebungen (Isolated/Trusted Env, z. B. TEE, Hypervisor-Partition, dedizierter Daemon) und der Hardware-Abstraktion (HW (file-sys, HSM)).
  • Gewährleistet Key-Isolation (Schlüsselmaterial verlässt die sichere Domäne nicht als Plaintext), Mandantenfähigkeit, Zugriffskontrolle und herstellerunabhängige Hardware-Beschleunigung (HSM/SHE/TPM).

2. Komponenten, Entitäten & Schnittstellen

Das Schaubild gliedert sich entlang zweier vertikaler Vertrauensgrenzen in drei primäre Domänen sowie übergeordnete Funktionscluster:

Domäne 1: Adaptive Applications (User-Space / Unprivilegiert)

• Adaptive Application: Konsument kryptografischer Dienste.
• CryptoAPI library (ara::crypto): Client-Laufzeitbibliothek im Prozesskontext der Applikation, unterteilt in:
  • Local Crypto-Provider: Führt unkritische Operationen ohne IPC-Overhead im lokalen Speicher durch (+ Keyless & Session Ctx, + Public key, + Session).
  • IPC lib: Kommunikationsschicht zur Interprozesskommunikation mit dem Crypto-Daemon / TEE.

Domäne 2: Isolated/Trusted Env (Sicherheitsdomäne / TEE / Crypto-Server)

• IPC & Resource Management: Zentraler Dispatcher/Gatekeeper; verifiziert Applikationsidentitäten (IAM/Manifest-Rechte), verwaltet Ressourcen, Sitzungen und Opaque Handles.
• Key-Storage Provider (ara::crypto::keys): Abstrahiert Zugriff, Persistenz, Modifikation und Lebenszyklus von Schlüsseln und Key-Slots.
• Crypto Provider (ara::crypto::cryp): Mehrfach instanziierbar (gestapelte Boxen, 1..n), kapselt konkrete kryptografische Algorithmen, Primitive und Beschleuniger-Engines.
• X.509 Provider (ara::crypto::x509): Parsen, Validierung, Pfadprüfung und Zertifikatsmanagement für X.509-Objekte.
• Gelber Systembus (Treiber-/Hardware-Schnittstelle): Bidirektionale Verbindung zwischen den Providern und den HW/Storage-Ressourcen.

Domäne 3: HW (file-sys, HSM) (Persistenz- & Hardware-Ebene)

• Protected Key Storage: Manipulations- und auslesegeschützter nichtflüchtiger Speicher (NVM/Flash) für symmetrische/asymmetrische Schlüssel.
• HSM (Hardware Security Module): Kryptografischer Coprozessor (gestapelt: mehrere Kerne/Instanzen möglich) für Hardware-Root-of-Trust, kryptografische Primitive und hardwaregebundenes Key-Wrapping.
• Certificate Storage: Nichtflüchtiger Speicher zur Ablage öffentlicher Zertifikate, Trust-Anchors und Zertifikatssperrlisten (CRLs).

Übergreifende Funktionscluster (AP-FCs)

• AP-FCs: UCM (Update & Config Management), COM (ara::com), PER (Persistency), DIAG (Diagnostics).
• Stereotypen & Relationen:
  • AP-FCs $\xrightarrow{\ll\text{use}\gg}$ Protected Key Storage: Standardisierte Nutzung geschützter Schlüssel für Secure Boot, Authenticated Diagnostics, SecOC/TLS und verschlüsselte Persistenz.
  • Protected Key Storage $\xleftrightarrow{\ll\text{map}\gg}$ HSM: Abbildung logischer Key-Slots/Handles auf physische HSM-Key-Slots bzw. Key-Wrapping-Schlüssel.
  • HSM $\xleftrightarrow{\ll\text{link}\gg}$ Certificate Storage: Assoziation zwischen Hardware-geschützten privaten Schlüsseln und den zugehörigen X.509-Zertifikaten.
  • Certificate Storage ⟶ Protected Key Storage: Referenzverknüpfung für Zertifikats-/Schlüssel-Paare.

3. Dynamisches Verhalten & Sequenzablauf

Die Architektur realisiert ein Dual-Path-Ausführungsmodell:

1. Local Fast-Path (Synchron, prozesslokal):
   • Trigger: Aufruf von Operationen ohne schützenswerte private Geheimnisse (z. B. Hashing via SHA-2/3, CRC, Signaturprüfung mit Public Key, symmetrische Ver-/Entschlüsselung mit rein ephemeren Session-Keys).
   • Ablauf: Ausführung direkt in der CryptoAPI library via Local Crypto-Provider. Kein Kontextwechsel, keine Serialisierung, minimale Latenz.
2. Secure Isolated-Path (IPC-basiert, synchron/asynchron):
   • Trigger: Zugriff auf Protected Key Storage, Import/Generierung von Schlüsseln, Operationen mit privaten Schlüsseln (z. B. Signaturerstellung, Entschlüsselung) oder Auslagerung an das HSM.
   • Ablauf:
     1. Applikation ruft API auf → Weiterleitung an IPC lib.
     2. IPC-Transfer über Prozessgrenze an IPC & Resource Management.
     3. Validierung der Zugriffsberechtigung der Applikation anhand des Applikations-Manifests.
     4. Delegierung an den zuständigen Provider (Key-Storage, Crypto, X.509).
     5. Provider steuert über den Hardware-Bus das HSM oder den Protected Key Storage an.
     6. Rückgabe von Opaque Handles (CryptoHandle, KeySlot) oder Rechenergebnissen über IPC.
3. Fehlerbehandlung:
   • Fehler werden über ara::core::Result<T, ara::crypto::CryptoErrorDomain> synchron oder via ara::core::Future asynchron an die Applikation propagiert (keine Classic-AUTOSAR Det/Dem-Meldungen, sondern strukturierte C++-Error-Codes).

4. Normative Relevanz & Entwickler-Hinweise

• Opaque Handle-Prinzip & Zero Plaintext Leakage:
  • Applikationen erhalten niemals rohe Schlüsselbytes (std::vector<uint8_t>) privater/symmetrischer Schlüssel. Sämtliche Operationen laufen über typisierte Opaque Handles (PrivateKey, SymmetricKey, KeySlot).
  • Schlüssel können direkt im Protected Key Storage als „nicht-exportierbar“ konfiguriert werden.
• Latenz- und Deadline-Budgetierung:
  • Aufrufe, die das HSM oder die Isolated/Trusted Env involvieren, unterliegen IPC- und Treiberoffsets. Bei harten Echtzeitanforderungen (z. B. zyklische SecOC-Frames in ara::com) müssen Operationen vorab initialisiert oder dedizierte Session-Kontexte im Fast-Path verwendet werden.
• Multi-Provider-Konfiguration (Execution Manifest):
  • Da Crypto Provider mehrfach existieren können, müssen Algorithmen und Key-Slots im Manifest eindeutig über Crypto-Provider-UUIDs/Namen aufgelöst werden (z. B. Unterscheidung zwischen Default-Software-Fallback und hardwarebeschleunigtem HSM-Provider).
• Treiber- und Plattform-Integration:
  • Stack-Entwickler binden HSM-Firmware und Secure-Storage-Treiber unterhalb des gelben Busses an die Provider an; die Schnittstelle zu Adaptive Applications bleibt standardisiert und portabel gemäß ara::crypto.