Figure 7.7: Key deployment

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: AUTOSAR M2-Metamodell (UML-Klassendiagramm) zur Spezifikation von Software-Architektur und Zielkonfiguration (ARXML).
• Technischer Zweck & Einordnung: Spezifikation des Bereitstellungsmechanismus (Key Deployment) innerhalb des Functional Clusters Cryptography der AUTOSAR Adaptive Platform (AP, Release R24-11). Es definiert die strukturelle Entkopplung zwischen prozessunabhängigem Schnittstellenentwurf (Application Design) und zielsystemspezifischer Konfiguration (Target-Configuration). Über typisierte und nun generalisierte Mapping-Klassen wird festgelegt, wie kryptografische Schlüssel-Slots (CryptoKeySlot) und Treiber-Instanzen (CryptoProvider) auf Betriebssystem-Prozesse (Process) und Anwendungs-Ports (RPortPrototype) abgebildet werden.

2. Komponenten, Entitäten & Schnittstellen

Paket Application Design (Prozess- und plattformunabhängige Entwurfsebene)

• PortInterface («ARElement», «AtpBlueprint», «AtpBlueprintable», «AtpType»): Abstrakte Basisklasse aller Schnittstellen.
• CryptoInterface: Spezialisiert PortInterface; abstrakter Anker für kryptografische Schnittstellen.
• AbstractCryptoKeySlotInterface: Abstrakte Basisklasse für Schlüsselspeicher-Schnittstellen; spezialisiert CryptoInterface. Definiert die allgemeinen Konfigurationsattribute:
  • allocateShadowCopy: Boolean [0..1]: Flag zur Allokation eines Schattenpuffers (ermöglicht atomare Updates / Rollbacks).
  • cryptoAlgId: String [0..1]: Algorithmen-Identifikator, an den der Slot gebunden ist.
  • cryptoObjectType: CryptoObjectTypeEnum [0..1]: Typ des Objekts (z. B. symmetrischer/asymmetrischer Schlüssel, Zertifikat).
  • slotCapacity: PositiveInteger [0..1]: Maximale Nutzlastkapazität in Bytes.
  • slotType: CryptoKeySlotTypeEnum [0..1]: Persistenzcharakteristik (z. B. flüchtig/RAM, nicht-flüchtig/NVM).
• CryptoKeySlotInterface: Konkrete Schnittstelle für Schlüssel-Slots; spezialisiert AbstractCryptoKeySlotInterface und erbt dessen Attribute.
• CryptoProviderInterface: Spezialisiert CryptoInterface. Schnittstelle für allgemeine kryptografische Operationen eines Providers.
• RPortPrototype («AbstractRequiredPortPrototype»): Client-Port der Applikation.
  • Assoziation +requiredInterface (0..1, Stereotyp «isOfType», Constraint {redefines atpType}) referenziert PortInterface.

Paket Target-Configuration (Instanziierungs- und Ausführungskontext, Execution/Service-Manifest)

• Process («AbstractExecutionContext»): Repräsentiert den OS-Prozesskontext mit Attributen functionClusterAffiliation: String [0..1], numberOfRestartAttempts: PositiveInteger [0..1], preMapping: Boolean [0..1].
• CryptoProvider («Identifiable»): Repräsentiert die konkrete Implementierung/Instanz des Krypto-Stacks (z. B. HSM-Treiber, Software-Krypto-Engine).
  • Assoziation +cryptoProviderDocumentation (0..1) zu Documentation («ARElement», «UploadableDesignElement»).
• CryptoKeySlot («Identifiable»): Konkrete physische/logische Speicherressource auf dem Zielsystem mit Attributen allocateShadowCopy, cryptoAlgId, cryptoObjectType, slotCapacity, slotType.
  • Komposition: CryptoProvider besitzt 0..* CryptoKeySlot (+keySlot, Stereotyp «atpSplitable» für die dateiübergreifende ARXML-Definition).
• AbstractCryptoKeySlotToPortPrototypeMapping («UploadableDeploymentElement»): Abstrakte Basisklasse für Port-Mappings von Krypto-Slots.
  • Referenz +process (0..1): Zielprozess.
  • Referenz +keySlot (0..1): Zugeordneter CryptoKeySlot.
  • Instanz-Referenz +portPrototype («instanceRef», 0..1): Verknüpfter RPortPrototype im Anwendungsmodell.
• CryptoKeySlotToPortPrototypeMapping: Konkretes Mapping-Element; spezialisiert AbstractCryptoKeySlotToPortPrototypeMapping und erbt dessen Assoziationen.
• CryptoProviderToPortPrototypeMapping («UploadableDeploymentElement»): Bindeglied für Krypto-Treiber.
  • Referenz +process (0..1): Zielprozess.
  • Referenz +cryptoProvider (0..1): Zugeordneter CryptoProvider.
  • Instanz-Referenz +portPrototype («instanceRef», 0..1): Verknüpfter RPortPrototype im Anwendungsmodell.

3. Dynamisches Verhalten & Sequenzablauf

Das Diagramm modelliert primär statische Manifest-Strukturen. Das resultierende dynamische Auflösungsverhalten zur Systemlaufzeit gestaltet sich wie folgt:

1. Manifest-Resolution beim Prozess-Start: Der Execution Management / Crypto Daemon parst das Execution- und Service-Instance-Manifest. Anhand von CryptoKeySlotToPortPrototypeMapping wird ermittelt, welcher physische CryptoKeySlot für den jeweiligen OS-Prozesskontext reserviert ist.
2. Port-to-Slot-Binding (SWS_CRYPT_10000): Wenn eine Applikation (AdaptiveApplicationSwComponentType) über ihren RPortPrototype (typisiert durch CryptoKeySlotInterface) auf Krypto-Funktionen zugreift, wird dieser Port transparent auf die gemappte CryptoKeySlot-Instanz im Host-System bzw. HSM aufgelöst.
3. Provider-Lookup über Key-Slot (SWS_CRYPT_10003): Ruft die Applikation die API-Funktion zur Ermittlung des zugehörigen Providers auf (MyProvider), traversiert der Crypto-Stack die Kompositionsbeziehung vom CryptoKeySlot zu dessen aggregierendem CryptoProvider. Die Zuordnung des Providers erfolgt implizit über den Key-Slot, ohne dass die Applikation hardwarenahe Provider-Instanznamen kennen muss.

4. Normative Relevanz & Entwickler-Hinweise

• Refaktorisierung der Metamodell-Struktur (R24-11): Die Einführung von AbstractCryptoKeySlotInterface und AbstractCryptoKeySlotToPortPrototypeMapping modularisiert das Metamodell. Die Attribute des Krypto-Slots und die Mapping-Assoziationen sind nun in den abstrakten Basisklassen verankert, wodurch zukünftige spezialisierte Schnittstellen und Mappings von einer einheitlichen Basis ableiten können.
• Paketumbenennung zu Target-Configuration: Das vormals als Deployment bezeichnete Paket heißt nun Target-Configuration. Dies schärft den semantischen Kontext im Manifest von allgemeinen Deployment-Artefakten hin zu zielplattformspezifischen Konfigurationsmodellen.
• Vererbung und Abwärtskompatibilität: Für Anwendungsmodelle bleibt die Verwendung von CryptoKeySlotInterface und CryptoKeySlotToPortPrototypeMapping nach außen hin kompatibel, da diese Klassen transparent von den neu eingezogenen Abstraktionen erben.