DEENESPTFRRUARHIKOZHNL
AUTOSAR_SWS_Cryptography FIG-955f3b173d1e9b97 932 × 465 px 1 Release(s)

Figure 7.4: Integration into AUTOSAR

SHA-256 Inhalts-Fingerabdruck: 955f3b173d1e9b977b0d6ecc2367a4c00fa7297f97772e7bb7e254afc07594dc

Im Versions-Explorer öffnen

Kanonischer Bildausschnitt (144 DPI WebP, gerendert aus Original-Vektorgrafik) · nicht öffentlich, nur mit Anmeldung und Freigabe
✦ KI-generierte Bildanalyse & technische Beschreibung Modell: gemini-3.8-flash (via agy) · Rezept figure-series@1 · erstellt am 2026-10-08

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::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.

Versionsvergleich KI-generiert · gemini-3.8-flash (via agy)

R20-11 → R21-11 normative Änderung Vorgänger: FIG-6c4e4cbe6399426c
  • ara::rest (REST): Functional Cluster aus den Platform Foundation FCs entfernt.
  • ara::idsm (Intrusion Detection System Manager): Neuer Functional Cluster als Platform Foundation FC (C++ In-Process API) anstelle von ara::rest aufgenommen.
  • ara::com: Typografische Bereinigung der Blockbezeichnung von „Communication Management.“ zu „Communication Management“ (abschließender Punkt entfernt).
R21-11 → R22-11 normative Änderung Nachfolger: FIG-1811e3d3ca36f657
  • ara::fw (Firewall): Neuer Functional Cluster als Platform Foundation FC (C++ In-Process API) unterhalb von ara::nm service auf Ebene des Betriebssystem-Interfaces hinzugefügt.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Begleitender Spezifikationstext:

Specification of Cryptography AUTOSAR AP R21-11 treated equally. The integraton of FC Crypto into AUTOSAR is described in Figure 7.4. Figure 7.4: Integration into AUTOSAR Their differential treatment is due to the underlying trust-model: system services (Functional Clusters) are the trusted foundation while Adaptive Applications are untrusted additions. To ensure secure access from application side the trust-model, in the form of IAM, is designed for and applied only to Adaptive Applications. Similarly, the exclusive-access-model aims at protecting an application’s own resources against access by other applications, but additionally also against access by functional clusters other than FC Crypto. On the other hand some functional clusters specify their own key-slots, which contain key-material to be used when implementing certain system services (e.g. secure data storage, secure diagnostics or secure communication such as SecOC). Because key-management of Key Slots used by functional clusters should be possible from an Adaptive Application (e.g. OEM key manager), the exclusive-access-model defines two types of Key Slots: • application: the application has exclusive access to this key slot. It is able to import/export, update/delete and use the contained key-material. No other application or functional cluster may access this Key Slot. • machine: this type of Key Slot is defined by the adaptive machine and may be used by the functional cluster for which it is configured. Addit

Vorkommen in AUTOSAR-Releases (2)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R21-11 AUTOSAR_SWS_Cryptography S. 47 7.4 Figure 7.4: Integration into AUTOSAR
R21-11 AUTOSAR_SWS_Cryptography S. 47 7.4 Figure 7.4: Integration into AUTOSAR