DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_SWS_Cryptography FIG-1645707e16e96c7a 932 × 270 px 5 Release(s)

Figure 7.5: Key Slot types and usages

SHA-256 Inhalts-Fingerabdruck: 1645707e16e96c7a56097ca04a863d4f9426592426ce166c508a49dda9c7819f

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-description@2 · erstellt am 2026-10-07

1. Diagrammtyp & Architektur-Kontext

  • Klassifikation: Informelles Architektur- und Berechtigungsdiagramm (Logical Access & Trust Model) der AUTOSAR Adaptive Platform (AP).
  • Technischer Zweck: Spezifikation des Exclusive-Access-Modells für persistierte kryptografische Schlüssel im Functional Cluster (FC) Cryptography (ara::crypto). Es definiert die Zugriffs- und Kapselungsgrenzen zwischen Adaptive Applications (AA), Plattformdiensten (Functional Clusters) und zentralen Schlüsselverwaltungsinstanzen anhand der Differenzierung von slotType=application und slotType=machine.

2. Komponenten, Entitäten & Schnittstellen

  • Akteure / Anwendungsinstanzen:
    • Functional adaptive application: Reguläre Adaptive Application (AA) im Benutzerraum; besitzt exklusiven Zugriff auf ihren privaten Schlüsselbereich.
    • Key manager application: Privilegierte AA (z. B. OEM Key Management Daemon / Flotten-Provisionierung), autorisiert zur Verwaltung von Machine-Schlüsselmaterial.
  • AUTOSAR Functional Clusters (FC):
    • Persistency (ara::per): Konsumiert Machine-Keys zur kryptografischen Absicherung (z. B. Verschlüsselung von File-Objekten im Secure Storage).
    • Communication Management (ara::com): Konsumiert Machine-Keys zur Absicherung von Bus- und Netzwerkkommunikation (z. B. MAC-/Signaturgenerierung für SecOC message oder TLS).
  • Datenstrukturen & Krypto-Ressourcen:
    • Key-Slot (ara::crypto::keys::KeySlot): Persistenter Container für kryptografische Objekte, strukturiert in:
      • Meta-data: Attribute wie Schlüsseltyp, Algorithmusbeschränkung (AllowedUsages), Exportierbarkeit und Lebenszyklusdaten.
      • Key-material: Rohdaten des symmetrischen/asymmetrischen Schlüssels oder Zertifikats.
  • Klassifikation der Slot-Typen & Beziehungen:
    • slotType=application:
      • Kardinalität: Exklusiv genau einer Functional adaptive application zugeordnet (1:1).
      • Berechtigungsmatrix: Vollständiger Lebenszyklus (Import, Export, Update, Krypto-Nutzung). Zugriff durch jegliche Functional Clusters (außer dem verwaltenden FC Crypto) ist normativ ausgeschlossen.
    • slotType=machine:
      • Kardinalität: Gebunden an die Adaptive Machine; zugeordnet zu genau einem konsumierenden Functional Cluster (ara::per, ara::com etc.) sowie maximal einer verwaltenden Key manager application (1:1:1).
      • Berechtigungsmatrix: Rollentrennung in Management (Schlüssel-Update/Rollout via Key Manager) und Consumption (reine Krypto-Nutzung durch den jeweiligen FC).

3. Dynamisches Verhalten & Sequenzablauf (falls zutreffend)

Das Diagramm modelliert kein Zeitschrittverhalten, sondern zwei orthogonale Zugriffspfade zur Laufzeit:

  1. Provisionierungs- & Lifecycle-Pfad (Management-Ebene):
    • Die Key manager application öffnet Machine-Slots über den KeyStorageProvider mit Schreibrechten (kAllowUpdate).
    • Neues Key-material wird importiert oder aktualisiert (z. B. via Secured Diagnostics oder Remote-OTA-Protokoll).
    • Die Functional adaptive application provisioniert analog ihren eigenen application-Slot.
  2. Kryptografischer Konsumpfad (Service-Ebene):
    • Der FC Persistency greift lesend/ausführend auf den ihm zugewiesenen Machine-Slot zu, um Payloads auf dem Dateisystem transparent zu ver- bzw. entschlüsseln.
    • Der FC Communication Management greift auf den separaten Machine-Slot zu, um Authentifizierungs-Tags für eingehende/ausgehende SecOC-Nachrichten zu prüfen bzw. zu berechnen.
    • Isolationsdurchsetzung: Anfragen eines FCs auf slotType=application oder nicht-autorisierter Anwendungen auf slotType=machine werden vom FC Crypto via Identity and Access Management (IAM) mit Zugriffsfehlern (kAccessViolation / SecurityError) blockiert.

4. Normative Relevanz & Entwickler-Hinweise

  • Manifest-Modellierung (ARXML):
    • Instanziierung von CryptoKeySlot erfordert die exakte Festlegung von slotType: Entweder kApplication (Binding an das Process-Modell der spezifischen AA) oder kMachine (Binding an das Machine-Package).
    • Zugriffslisten müssen über IAM-Policies (CryptoKeySlotAccessList) explizit abgebildet werden. Die Zuordnung eines Machine-Slots zur Key manager application muss designiert modelliert sein.
  • API-Implementierung (ara::crypto::keys):
    • Zugriff erfolgt typischerweise über KeyStorageProvider::OpenKeySlot(). Entwickler müssen die Berechtigungsflags (kAllowUsage, kAllowUpdate, kAllowExport) passend zu ihrer Applikationsrolle anfordern.
    • Ein Machine-Slot erlaubt dem Functional Cluster in der Regel nur den instanziierten Krypto-Kontext (EncryptorContext, SignerContext), nicht jedoch Modifikations-APIs wie SaveCopy() oder BeginTransaction().
  • Integrations- & Sicherheitsbeschränkungen:
    • Applikationsentwickler dürfen keine systemweiten Shared-Keys in application-Slots ablegen, da andere Dienste (wie SecOC oder Diagnostics) keinen Zugriff darauf erhalten können.
    • Plattform- und Stack-Entwickler müssen sicherstellen, dass vor Inbetriebnahme von ara::per oder ara::com die korrespondierenden Machine-Key-Slots durch den Bereitstellungsprozess (Key Manager) initialisiert und persistent hinterlegt sind.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Begleitender Spezifikationstext:

Specification of Cryptography AUTOSAR AP R24-11 tions 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. The access model for the application key slot will protect the application own resources from being accessed by any Functional Clusters other than FC Crypto. On the other hand some Functional Clusters specify their own keyslots, 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 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. Additionally, the Key Slot may be assigned to a single Adaptive Application that is then able to manage the contained key-material. Figure 7.5 gives an example for the use of machine and application Key Slots. Figure 7.5: Key Slot types and usages 7.2.3 Application level The FC Crypto has been primarily designed to enable Adaptive Applications to acces

Vorkommen in AUTOSAR-Releases (8)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R20-11 AUTOSAR_SWS_Cryptography S. 45 7.5 Figure 7.5: Key Slot types and usages
R20-11 AUTOSAR_SWS_Cryptography S. 45 7.5 Figure 7.5: Key Slot types and usages
R21-11 AUTOSAR_SWS_Cryptography S. 48 7.5 Figure 7.5: Key Slot types and usages
R21-11 AUTOSAR_SWS_Cryptography S. 48 7.5 Figure 7.5: Key Slot types and usages
R22-11 AUTOSAR_SWS_Cryptography S. 48 7.5 Figure 7.5: Key Slot types and usages
R23-11 AUTOSAR_AP_SWS_Cryptography S. 36 7.5 Figure 7.5: Key Slot types and usages
R23-11 AUTOSAR_AP_SWS_Cryptography S. 36 7.5 Figure 7.5: Key Slot types and usages
R24-11 AUTOSAR_AP_SWS_Cryptography S. 38 7.5 Figure 7.5: Key Slot types and usages