Figure 7.4: Integration into AUTOSAR

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Statisches Schichtenmodell / Architektur-Blockdiagramm der AUTOSAR Adaptive Platform (AP).
• Technischer Zweck: Darstellung der strukturellen Verortung des Functional Clusters (FC) ara::crypto innerhalb der AUTOSAR Runtime for Adaptive Applications (ARA) sowie Abgrenzung zwischen Platform Foundation FCs, Platform Service FCs, Non-Platform Services, User Applications und dem darunterliegenden OS-Interface (POSIX PSE51).

2. Komponenten, Entitäten & Schnittstellen

• User Applications (Applikationsebene):
  • Adaptive Application: Unprivilegierte, isolierte Applikationsprozesse (untrusted).
  • ASW::XYZ Non-PF Service / ASW::ABC Non-PF Service: Benutzerdefinierte Services (Nicht-Plattform-Services), die serviceorientiert über ara::com bereitgestellt werden.
• AUTOSAR Runtime for Adaptive Applications (ARA):
  • Platform Foundation FCs (C++ In-Process API):
    • ara::crypto (Cryptography): Stellt kryptografische Basisfunktionen (Random, Symmetric/Asymmetric Ciphers, Hashes, Key Storage, X.509) bereit.
    • ara::iam (Identity and Access Management): Autorisierungsinstanz für Applikationszugriffe auf Plattform-Ressourcen und Krypto-Schlüssel.
    • ara::idsm (Intrusion Detection System Manager): Erfassung und Weiterleitung von Sicherheitsereignissen (Security Events).
    • ara::fw (Firewall): Schnittstellennahe Netzwerkpaket-Filterung und Firewall-Funktionalität.
    • ara::core, ara::exec, ara::com (inkl. Protokoll-Bindings IPC, Signal PDU, SOME/IP, DDS), ara::tsync, ara::diag, ara::per, ara::phm, ara::log.
  • Platform Service FCs (Service-basiert via IPC/ara::com):
    • ara::sm service (State Management), ara::ucm service (Update and Config Management), ara::nm service (Network Management).
• Betriebssystem- & Hardware-Ebene:
  • POSIX PSE51 / C++ STL: Standardisiertes OS-Interface (Single-Process, Multi-Threaded Profil gemäß IEEE 1003.13) für alle FCs.
  • (Virtual) Machine / Container / Hardware: Laufzeitumgebung, Hypervisor oder physisches SoC inklusive Hardware-Sicherheitsmodul (HSM / SHE / TPM).
• Strukturbeziehungen & Vertrauensgrenzen:
  • Trust-Boundary: Functional Clusters bilden das vertrauenswürdige Fundament (trusted foundation); Adaptive Applications gelten als unvertrauenswürdig (untrusted additions).
  • Schlüsselslot-Abstraktion (Exclusive-Access-Model):
    • Application Key Slots: Exklusiv an eine spezifische Applikation gebunden; abgeschottet gegen andere Applikationen und fremde FCs.
    • Machine Key Slots: An die Maschine/Plattform gebunden, reserviert für System-FCs (z. B. ara::com für SecOC/TLS, ara::per für verschlüsselte Persistenz, ara::diag für authentifizierte Diagnose).

3. Dynamisches Verhalten & Sequenzablauf

Das Diagramm stellt eine statische Schichtenarchitektur dar; das zugrundeliegende Interaktionsmuster gliedert sich wie folgt:

• API-Aufrufpfad (Synchron / In-Process):
  • Adaptive Applications binden ara::crypto direkt über Header und Laufzeitbibliotheken (In-Process C++ API) im lokalen virtuellen Adressraum ein.
• Zugriffskontrolle via ara::iam:
  • Beim Öffnen eines Key Slots oder dem Instanziieren kryptografischer Kontexte prüft die ara::crypto-Implementierung die Zugriffsrechte des aufrufenden Prozesses (UID/GID, Process Execution Context) synchron gegen ara::iam.
• Systemservice-Nutzung:
  • Plattform-Services (ara::diag, ara::per, ara::com) interagieren direkt mit ara::crypto, um Machine Key Slots zu konsumieren, ohne die IAM-Einschränkungen der Anwendungsebene zu durchlaufen. Key-Management-Applikationen (z. B. OEM Key Manager) verwalten diese Slots über dedizierte administrative Schnittstellen.

4. Normative Relevanz & Entwickler-Hinweise

• API-Klassifikation & Linking:
  • ara::crypto ist als Foundation FC spezifiziert. Entwickler instanziieren Krypto-Objekte nicht über Service Discovery (ara::com::FindService), sondern direkt über C++-Fabriken (ara::crypto::keys::OpenKeySlot(), ara::crypto::cryp::...).
• Manifest-Konfiguration:
  • Im Execution Manifest und Service Instance Manifest müssen die Zugriffsrechte für Schlüssel (CryptoKeySlot) und Algorithmen-Suites via IAM-Regeln explizit für den Applikationsprozess konfiguriert werden; unkonfigurierte Zugriffe terminieren mit SecurityErrorDomain-Fehlercodes.
• Portabilität & Treiber-Kapselung:
  • Stack-Entwickler müssen Hardware-Krypto-Beschleuniger (HSM/SE/Crypto-Engine) über das POSIX-Interface bzw. proprietäre Kernel-Treiber unterhalb der ara::crypto-Plattformbibliothek anbinden. Die Schnittstelle nach oben zur Applikation bleibt streng konform zu SWS Cryptography R20-11.