DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_SWS_Cryptography FIG-a704d4d80f20b0b0 733 × 393 px 1 Release(s)

Figure 5.1: Interfaces provided by Cryptography to other Functional Clusters

SHA-256 Inhalts-Fingerabdruck: a704d4d80f20b0b0931a96419d580ff6d9f3d6df74d00fb3bef0c95822375ab2

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: UML-Architektur- und Komponentendiagramm (Abhängigkeitsdiagramm der AUTOSAR Adaptive Platform).
  • Technischer Zweck: Statische Dokumentation der Schnittstellenbereitstellung des Functional Clusters (FC) Cryptography für andere Functional Clusters der Adaptive Platform Foundation und Services.
  • Funktionale Einordnung: Definiert Cryptography als zentrale Basiskomponente für hardwaregestützte sowie softwarebasierte kryptografische Dienste (Schlüsselverwaltung, Signaturprüfung, Verschlüsselung, Zertifikatshandling) im Gesamtsystem.

2. Komponenten, Entitäten & Schnittstellen

  • Schnittstellen-Entität:
    • «aapAPI, aapNativeInterface» CryptoStack: Platzhalter-Abstraktion für die nativen C++-APIs des Krypto-Stacks (ara::crypto::cryp, ara::crypto::keys, ara::crypto::x509). Schnittstelle wird als In-Process C++-Bibliotheks-API bereitgestellt.
  • Dienstanbieter (Provider):
    • «aapFunctionalCluster» Cryptography (Stereotyp/Eigenschaft: daemon-based): Realisiert (realization, gestrichelte Linie mit geschlossener Dreiecksspitze) das Interface CryptoStack. Kapselt Krypto-Treiber, HSM/SHE/TEE-Anbindungen und System-Daemons.
  • Konsumenten (Clients / Dependents): Verwenden die Schnittstelle über gerichtete Nutzungsbeziehungen («use», gestrichelte Pfeile auf CryptoStack):
    1. «aapFunctionalCluster» Persistency (library-based): Verschlüsselung und Integritätsschutz gespeicherter Key-Value-Datenbanken und Files (ara::per).
    2. «aapFunctionalCluster» Update and Configuration Management (daemon-based): Authentizitäts- und Signaturprüfung sowie Entschlüsselung von Software-Update-Paketen (ara::ucm).
    3. «aapFunctionalCluster» Vehicle Update and Configuration Management (daemon-based): Fahrzeugweite Kampagnen-Validierung, Zertifikats- und Backend-Authentifizierung (ara::vucm).
    4. «aapFunctionalCluster» Diagnostic Management (daemon-based): Authentifizierter Diagnosezugriff (UDS Service 0x27 SecurityAccess, Service 0x29 Authentication, TLS für DoIP).
    5. «aapFunctionalCluster» Communication Management (daemon-based): Sichere Service-Kommunikation (ara::com, SecOC, SOME/IP-Authentifizierung, TLS/DTLS, IPsec).
    6. «aapFunctionalCluster» Raw Data Stream (library-based): Stream- und Puffer-Chiffrierung sowie Hash-Berechnung für byteweise Rohdatenströme.
    7. «aapFunctionalCluster» Intrusion Detection System Manager (daemon-based): Integritätssicherung, Signierung und Hashing von Qualified Security Events (QSEv) vor Protokollierung und Backend-Übertragung.

3. Dynamisches Verhalten & Sequenzablauf

  • Interaktionsmodell: Statisches Diagramm ohne Sequenzpfade. Laufzeitinteraktionen erfolgen über synchrone und asynchrone API-Aufrufe.
  • Ausführungspfade:
    • In-Process Path: Aufrufer binden die native Client-Bibliothek (libara_crypto) direkt ein. Lokale Berechnungen (z. B. Software-Hashes) laufen im Kontext des aufrufenden Prozesses.
    • Daemon/IPC Path: Operationen auf geschützten Schlüsseln, RNG oder Hardware-Beschleunigern werden intern via IPC an den Cryptography daemon bzw. das HSM/Secure OS durchgereicht.
  • Synchronisation & Callbacks: Nicht-blockierende kryptografische Operationen nutzen ara::core::Future / ara::core::Promise. Fehlerfortpflanzung erfolgt deterministisch und exception-frei über ara::core::Result<T, CryptoErrc>.

4. Normative Relevanz & Entwickler-Hinweise

  • API-Mapping (CryptoStack als Abstraktion): Im Code existiert kein Interface CryptoStack. Implementierer müssen gezielt gegen die Sub-Namespaces linken:
    • ara::crypto::cryp: Algorithmen-Kontexte (Signer, Verifier, Encryptor, MessageAuthCodeCtx, HashCtx, RandomGeneratorCtx).
    • ara::crypto::keys: Key Storage Provider, Slot-Allokation, Import/Export von Schlüsseln.
    • ara::crypto::x509: X.509-Parser, Zertifikatsketten-Validierung, OCSP.
  • Manifest-Konfiguration & Zugriffsrechte:
    • Die bloße «use»-Beziehung erfordert im Execution Manifest und Crypto Key Manifest die exakte Deklaration von CryptoProvider- und KeySlot-Zugriffsrechten für jeden konsumierenden Prozess.
    • Schlüsselmaterial wird primär über opaque Handles (KeySlot, PrivateKey, SymmetricKey) referenziert und verlässt den sicheren Daemon/HSM-Speicherraum nicht.
  • Startreihenfolge & Lifecycle (Execution Management):
    • Da Cryptography als daemon-based gekennzeichnet ist, müssen konsumierende Daemons (UCM, CM, DM, IDSM) im Execution Manifest zwingend mit entsprechenden Startup-Dependencies versehen werden, um Zugriffe vor initialisierter Krypto-Infrastruktur auszuschließen.

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

R24-11 → R25-11 keine inhaltliche Änderung Vorgänger: FIG-80ae8ae5d71f1a16

Keine inhaltlichen Änderungen erkennbar.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

«aapAPI,aapNativeInterface» | CryptoStack | «aapFunctionalCluster» | Cryptography daemon-based | «aapFunctionalClust... | Persistency | «aapFunctionalCluster» | Communication | Management daemon-based | «aapFunctionalCluster» Update and Configuration | Management daemon-based | «aapFunctionalCluster» | Vehicle Update and Configuration Management daemon-based | «aapFunctionalClust... Diagnostic Management | daemon-based | «aapFunctionalCluster» | Raw Data Stream | «aapFunctionalClust... Intrusion Detection System | Manager daemon-based | «use» «use» «use» «use» «use» «use» «use»

Begleitender Spezifikationstext:

Specification of Cryptography AUTOSAR AP R25-11 5 Dependencies to other functional clusters This chapter provides an overview of the dependencies to other Functional Clusters in the AUTOSAR Adaptive Platform. Section 5.1 “Provided Interfaces” lists the interfaces provided by Cryptography to other Functional Clusters. Section 5.2 “Required Interfaces” lists the interfaces required by Cryptography. A detailed technical architecture documentation of the AUTOSAR Adaptive Platform is provided in [6]. 5.1 Provided Interfaces «aapAPI,aapNativeInterface» CryptoStack «aapFunctionalCluster» Cryptography daemon-based «aapFunctionalClust... Persistency «aapFunctionalCluster» Communication Management daemon-based «aapFunctionalCluster» Update and Configuration Management daemon-based «aapFunctionalCluster» Vehicle Update and Configuration Management daemon-based «aapFunctionalClust... Diagnostic Management daemon-based «aapFunctionalCluster» Raw Data Stream «aapFunctionalClust... Intrusion Detection System Manager daemon-based «use» «use» «use» «use» «use» «use» «use» Figure 5.1: Interfaces provided by Cryptography to other Functional Clusters Figure 5.1 shows interfaces assumed to be provided by Cryptography to other Functional Clusters within the AUTOSAR Adaptive Platform. Table 5.1 provides a list of interfaces assumed to be provided to other Functional Clusters within the AUTOSAR Adaptive Platform. Please note that for brevity only a placeholder interface CryptoStack is used instead o

Vorkommen in AUTOSAR-Releases (1)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R25-11 AUTOSAR_AP_SWS_Cryptography S. 30 5.1 Figure 5.1: Interfaces provided by Cryptography to other Functional Clusters