Figure 7.7: Key deployment

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: AUTOSAR M2-Metamodell (UML-Klassendiagramm) zur Spezifikation von Software-Architektur und Deployment-Artefakten (ARXML).
• Technischer Zweck & Einordnung: Spezifikation des Bereitstellungsmechanismus (Key Deployment) innerhalb des Functional Clusters Cryptography der AUTOSAR Adaptive Platform (AP, Release R20-11). Es definiert die strukturelle Entkopplung zwischen prozessunabhängigem Schnittstellenentwurf (Application Design) und prozessgebundener Zielsystemkonfiguration (Deployment). Über typisierte 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.
• CryptoKeySlotInterface: Spezialisiert CryptoInterface. Definiert die logischen Mindestanforderungen einer Applikation an einen Schlüsselspeicher. Attribute:
  • 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).
• 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 Deployment (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»).
• CryptoKeySlot («Identifiable»): Konkrete physische/logische Speicherressource auf dem Zielsystem. Führt dieselben Konfigurationsattribute wie das Interface (allocateShadowCopy, cryptoAlgId, cryptoObjectType, slotCapacity, slotType).
  • Komposition: CryptoProvider besitzt 0..* CryptoKeySlot (+keySlot, Stereotyp «atpSplitable» für die dateiübergreifende ARXML-Definition).
• CryptoKeySlotToPortPrototypeMapping («UploadablePackageElement»): Bindeglied für Schlüsselspeicher.
  • Referenz +process (0..1): Zielprozess.
  • Referenz +keySlot (0..1): Zugeordneter CryptoKeySlot.
  • Instanz-Referenz +portPrototype («instanceRef», 0..1): Verknüpfter RPortPrototype im Anwendungsmodell.
• CryptoProviderToPortPrototypeMapping («UploadablePackageElement»): 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

• Gelockerte Kardinalitäten (R22-11): Die Multiplizitäten der Referenzen an CryptoKeySlotToPortPrototypeMapping (+process, +keySlot, +portPrototype) und CryptoProviderToPortPrototypeMapping (+process, +cryptoProvider, +portPrototype) wurden von 1 auf 0..1 gelockert.
• Modellierungsflexibilität: Die Lockerung ermöglicht eine inkrementelle ARXML-Erstellung und modulare Manifest-Verwaltung; Referenzen auf Prozess, Port oder Ressource können während früherer Entwicklungsschritte oder in Vorlagen zunächst ungebunden bleiben.
• Attribut-Konsistenz: Die Konfigurationsparameter (cryptoAlgId, cryptoObjectType, slotCapacity, slotType, allocateShadowCopy) des logischen CryptoKeySlotInterface müssen mit den Merkmalen des im Deployment gebundenen CryptoKeySlot übereinstimmen.
• Prozess-Isolation: Die optionale Prozessbindung (process [0..1]) gestattet bei gesetzter Referenz weiterhin die prozessspezifische Isolation und Rechteprüfung auf Betriebssystemebene.