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, numberOfRestartAttempts, preMapping.
• 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 (1): Zielprozess.
  • Referenz +keySlot (1): Zugeordneter CryptoKeySlot.
  • Instanz-Referenz +portPrototype («instanceRef», 1): Verknüpfter RPortPrototype im Anwendungsmodell.
• CryptoProviderToPortPrototypeMapping («UploadablePackageElement»): Bindeglied für Treiber-Instanzen.
  • Referenz +process (1): Zielprozess.
  • Referenz +cryptoProvider (1): Zugeordneter CryptoProvider.
  • Instanz-Referenz +portPrototype («instanceRef», 1): Verknüpfter RPortPrototype.

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

• Architektur-Entkopplung: Applikations-Entwickler dürfen keine fest codierten Key-Slot-IDs oder Pfade verwenden. Der Zugriff erfolgt normativ ausschließlich abstrahiert über Ports, typisiert durch CryptoKeySlotInterface (SWS_CRYPT_10000, RS_CRYPTO_02004, RS_CRYPTO_02305).
• Integrations- & Konfigurationspflicht: Für jeden Prozess, der kryptografische Operationen ausführt, müssen zwingend valide Manifest-Instanzen von CryptoKeySlotToPortPrototypeMapping bzw. CryptoProviderToPortPrototypeMapping erzeugt werden. Ein Fehlen dieser Mappings führt beim Start zur Verweigerung der Slot-Handle-Rückgabe (kAccessViolation / kUnreservedResource).
• Design-vs.-Deployment-Validierung: Konfigurations- und Generator-Toolchains müssen die Kompatibilität zwischen CryptoKeySlotInterface (Anforderungsebene) und CryptoKeySlot (Deployment-Ebene) verifizieren (z. B. ob die im Deployment zugewiesene slotCapacity mindestens der im Design geforderten Kapazität entspricht und ob cryptoAlgId sowie slotType übereinstimmen).
• Modularisierung via «atpSplitable»: Durch die Aufteilbarkeit der Komposition CryptoProvider → CryptoKeySlot können OEM und Tier-1 Schlüssel-Slots in getrennten Manifest-Dateien konfigurieren, ohne das Metamodell des Gesamttreibers aufzubrechen.