DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_SWS_Cryptography FIG-7672b8a2221a5645 932 × 846 px 1 Release(s)

Figure 7.3: Concurrent access to a single Key Slot

SHA-256 Inhalts-Fingerabdruck: 7672b8a2221a56453974ca29eb163689df55468df07eec5a3432ff3ae13da243

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-Komponentendiagramm / Architektur-Interaktionsmodell mit funktionalen Stereotypen (<<use>>, <<update>>, <<add>>, <<notify>>).
  • Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Spezifikation ara::crypto, Sub-Package ara::crypto::keys (Key Storage & Lifecycle Management).
  • Technischer Zweck: Spezifikation der Nebenläufigkeit (Concurrency) und Entkopplung beim gleichzeitigen Zugriff auf denselben persistenten KeySlot durch getrennte funktionale Domänen (produktive Krypto-Dienste vs. Schlüsselverwaltung/Key-Lifecycle-Management) innerhalb einer Adaptive Application.

2. Komponenten, Entitäten & Schnittstellen

  • Adaptive Application:
    • Business logic / Service-consumer: Anwendungsdomäne, die kryptografische Dienste über standardisierte oder gekapselte Schnittstellen konsumiert.
    • 3rd party library: Funktionsbibliothek für operative Sicherheitsdienste und Krypto-Jobs (z. B. TLS-/SecOC-Stack, Signaturprüfung, Ver-/Entschlüsselung).
    • OEM library: Privilegierte OEM-spezifische Bibliothek für das Schlüsselmanagement (z. B. Backend-Provisioning, OTA-Key-Rollover, Zertifikatsaktualisierung).
  • Key-Storage-Provider (ara::crypto::keys::KeyStorageProvider):
    • Plattformseitiger Verwalter persistenter kryptografischer Speicherbereiche.
    • Key-slot (ara::crypto::keys::KeySlot): Persistenter Container zur Haltung eines versionierten kryptografischen Objekts / Schlüssels.
    • +UpdatesObserver (ara::crypto::keys::UpdatesObserver): Callback- und Signalisierungsschnittstelle zur Registrierung von Konsumenten bei Slot-Zustandsänderungen (Observer-Pattern).
  • Stereotypen & Relationen:
    • Business logic ↔ 3rd party library: Bidirektionaler Aufrufkontext für Krypto-Anforderungen und -Ergebnisse.
    • 3rd party library –<<use>>→ Key-slot: Lesender / instanziierender Zugriff auf den Schlüssel zur Ausführung von Krypto-Operationen.
    • 3rd party library –<<add>>→ +UpdatesObserver: Registrierung eines Observers zur Überwachung von Inhaltsänderungen am Ziel-Key-Slot.
    • +UpdatesObserver –<<notify>>→ 3rd party library: Asynchrone Signalisierung über einen durchgeführten Schreib-/Update-Vorgang.
    • OEM library –<<update>>→ Key-slot: Schreibender/modifizierender Zugriff (Key Injection, Rollover, Invalidation).

3. Dynamisches Verhalten & Sequenzablauf

  1. Observer-Registrierung (<<add>>): Vor Beginn operativer Krypto-Jobs registriert die 3rd party library über KeyStorageProvider::RegisterObserver() bzw. am KeySlot einen UpdatesObserver.
  2. Schlüsselverwendung (<<use>>): Die Bibliothek öffnet den Slot (OpenKeySlot()) und lädt das CryptoObject in den flüchtigen Kontext (Instanziierung eines kurzlebigen Schlüssels oder Kontexts im CryptoProvider).
  3. Schlüsselaktualisierung (<<update>>): Parallel stößt die OEM library eine Schlüsselaktualisierung an (z. B. Empfang eines neuen Schlüssels via Diagnose/OTA) und persistiert diesen atomar im Key-slot via KeySlot::SaveCopy() / KeyStorageProvider.
  4. Benachrichtigung (<<notify>>): Der Key-Storage-Provider feuert über UpdatesObserver::OnUpdate() ein Benachrichtigungs-Event an die registrierte 3rd party library.
  5. Konsistenz & Umschaltung: Bereits aus dem Slot geladene, aktive CryptoObject-Handles bleiben im Arbeitsspeicher für laufende Transaktionen bis zu deren Freigabe (Release()) deterministisch gültig. Die 3rd party library initialisiert nach Empfang des <<notify>> nachfolgende Krypto-Jobs mit dem neu geladenen Slot-Inhalt.

4. Normative Relevanz & Entwickler-Hinweise

  • Thread-Safety & Race Conditions: Entwickler von Krypto-Konsumenten dürfen geöffnete KeySlot-Referenzen nicht statisch über unbegrenzte Zeiträume cachen, ohne den UpdatesObserver zu implementieren, da andernfalls veraltete Schlüsselmaterialien (Stale Keys) verwendet werden.
  • Transaktionale Konsistenz: Die KeyStorageProvider-Implementierung des Stacks muss Updates auf Slots atomar ausführen. Teilschreibzugriffe dürfen für lesende Konsumenten zu keinem Zeitpunkt sichtbar sein.
  • Berechtigungsisolation (Execution Management & Manifest): OEM- und Drittanbieter-Bibliotheken benötigen differenzierte Zugriffsrechte im Crypto-Manifest. Schreibrechte (kKeySlotUpdateAllowed) sind strikt auf den Key-Management-Pfad (OEM) zu beschränken, während operative Bibliotheken ausschließlich Leserechte (kKeySlotReadOnly) besitzen dürfen.

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

R23-11 → R24-11 keine inhaltliche Änderung Vorgänger: FIG-29c1d438b89bc459

Keine inhaltlichen Änderungen erkennbar.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Begleitender Spezifikationstext:

Specification of Cryptography AUTOSAR AP R24-11 IAM enables access control to modeled entities or resources. Currently, FC Crypto considers access control only for two types of resources: Key Slot (read/write) and Certificate Slot (write). Clarification: key-slots and certificate-slots are non-volatile in nature, i.e. there is no use case for allocating volatile key-slot or certificate-slot instances. Note: Functional Cluster access to a Key Slot assigned under exlusive-access to an Adaptive Application is not ruled out by this model (see sub-chapter 7.2.2)! To enable and synchronize concurrent update and usage of the same key-slot, the Key Storage Provider specifies dedicated interfaces and mechanisms, which are subject to access control based on the addressed Key Slot. Figure 7.3 showcases this scenario: the Adaptive Application has exclusive-access to a Key Slot, which is used by a library providing cryptographic services to a higher layer (business logic). At the same time another library independently manages Key Slot content (e.g. crypto-keys). Figure 7.3: Concurrent access to a single Key Slot 36 of 441 Document ID 883: AUTOSAR_AP_SWS_Cryptography

Vorkommen in AUTOSAR-Releases (1)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R24-11 AUTOSAR_AP_SWS_Cryptography S. 36 7.3 Figure 7.3: Concurrent access to a single Key Slot