Figure 7.1: Exemplary High-level FC Crypto architecture

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: High-Level-Systemarchitekturdiagramm / Schichten- und Komponentenmodell der AUTOSAR Adaptive Platform (AP).
• Technischer Zweck: Darstellung der internen Struktur und Systemintegration des Functional Cluster (FC) Cryptography (ara::crypto). Es visualisiert die Entkopplung von Applikationen und Functional Clusters von konkreten kryptografischen Backends (Software vs. Hardware Security Module) über eine standardisierte API, inklusive modellbasierter Zugriffskontrolle und persistenter Speicheranbindung.

2. Komponenten, Entitäten & Schnittstellen

• Consumer-Ebene (Client Space):
  • Application (Application Code): Standard-Adaptive-Applikation.
  • Functional Cluster X (FC Code): Anderer AP-Systemdienst (z. B. UCM, SecOC, IAM).
  • ara::crypto: Clientseitige C++-Standard-Bibliotheksschnittstelle (ara::crypto::cryp, ara::crypto::keys, ara::crypto::x509), über die Schlüssel-Handles (Key-Icons) angefordert und Krypto-Kontexte betrieben werden.
• Vermittlungs- & Abstraktionsebene (Crypto FC Core / Service):
  • Access Control: Autorisierungs- und Richtlinien-Instanz, validiert Prozessidentitäten und Zugriffsrechte auf angeforderte Schlüssel/Slots.
  • Static configuration: Konfigurationsdatenbank (generierte Tabellen/Manifest-Binaries), definiert Providers, Slot-IDs und Zugriffsmatrizen.
  • X509Provider: Schnittstellenimplementierung für Zertifikatsmanagement, Pfadvalidierung und Parsing (ara::crypto::x509::X509Provider).
  • SW CryptoProvider: Software-Fallback / CPU-basierte Krypto-Bibliothek für Krypto-Primitive und Software-Schlüsselverwaltung.
  • HSM CryptoProvider: Hardware-Abstraktionstreiber zur Anbindung dedizierter Krypto-Beschleuniger (HSM, TPM, SE).
• Modellierungs- & Build-Ebene:
  • Model (ARXML): Formales AUTOSAR-Manifest (Crypto Design, Crypto Deployment & Execution Manifest).
  • Mapping: Definition der Beziehungen zwischen Applikation/Prozess, logischen KeySlots (CryptoKeySlot) und physischem CryptoProvider.
  • Generation: Toolchain-Schritt zur Übersetzung des ARXML-Modells in die maschinenlesbare Static configuration.
• Plattform- & Hardware-Ebene:
  • Operating System: POSIX-OS-Schicht (IPC, VFS, Chardev-/Kernel-Treiber für HSM).
  • Filesystem: Persistente Speicherbereiche für Certificate Storage (X.509-Stores, CRLs) und softwarebasierte Key Storage (gesicherte Key-Dateien).
  • HSM: Physisch isolierte Hardware-Sicherheitsdomäne mit internem, nicht-flüchtigem Key Storage (Root-Keys, Secure Storage).

3. Dynamisches Verhalten & Sequenzablauf

1. Design- & Build-Phase: ARXML definiert Schlüsselbedarf, Slot-Restriktionen und Zuweisungen (Mapping). Der Codegenerator erzeugt die Static configuration für das Ziel-ECU.
2. Provider-Allokation: Client (Application oder FC X) initiiert Provider-Instanziierung über ara::crypto::LoadCryptoProvider() oder ara::crypto::LoadX509Provider().
3. Zugriffskontrolle & Slot-Bindung:
   • Anforderung wird an Access Control geleitet.
   • Access Control gleicht die aufrufende Prozess-ID (POSIX UID/GID oder Peer Credentials) gegen die Static configuration ab.
   • Bei erfolgreicher Prüfung wird das Handle auf den Ziel-Provider (SW CryptoProvider oder HSM CryptoProvider) bzw. KeySlot freigegeben.
4. Operationelle Krypto-Verarbeitung:
   • SW-Pfad: Krypto-Primitive laufen im CPU-Kontext; Schlüssel werden über das OS-Filesystem aus Key Storage geladen (ggf. verschlüsselt hinterlegt).
   • HSM-Pfad: API-Calls werden über OS-Treiberschnittstellen an die HSM-Firmware delegiert; Schlüsselmaterial verbleibt innerhalb der gesicherten HSM-Hardwaregrenze.
   • Zertifikats-Pfad: X509Provider nutzt das Filesystem (Certificate Storage) zum Laden von Zertifikaten und delegiert kryptografische Signaturprüfungen an den zuständigen CryptoProvider.

4. Normative Relevanz & Entwickler-Hinweise

• Transparenter API-Vertrag: Der Anwendungscode interagiert ausschließlich mit den abstrakten Interfaces von ara::crypto. Der Wechsel von SW-Crypto auf Hardware-HSM erfolgt rein deklarativ über das ARXML-Mapping ohne Code-Änderung in der Applikation.
• Opaque Key Handles: Applikations- und FC-Entwickler erhalten niemals direkten Zugriff auf raw Key-Bytes; kryptografische Operationen akzeptieren ausschließlich opake Instanzen (ara::crypto::keys::KeySlot, ara::crypto::cryp::Key).
• Manifest-Bindung: Ein unvollständiges oder fehlerhaftes ARXML-Mapping führt unweigerlich zu Laufzeitfehlern bei LoadCryptoProvider() oder LoadKeySlot() (z. B. SecurityError / Zugriffsverweigerung durch Access Control).
• Latenz- & Concurrency-Implikationen:
  • HSM-Operationen erfordern IPC- und Treiber-Roundtrips; zeitkritische Operationen (z. B. Stream-Ciphers, Fast-MAC) müssen gegen HSM-Bandbreiten und IPC-Overhead abgewogen werden.
  • Der HSM-CryptoProvider muss Reentrancy und Thread-Sicherheit über OS-Mutexes oder Hardware-Mailbox-Queues sicherstellen.
• Speicher-Integrität: Für Filesystem-basierte Key- und Zertifikats-Stores sind zwingend zusätzliche Integritätsmechanismen auf Betriebssystemebene erforderlich (z. B. dm-verity, verschlüsselte Dateisysteme/LUKS), da Software-Keys im Host-Speicherraum liegen.