Figure 3.66: CryptoInterfaces for modeling of the interaction of the Application with the Crypto software

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm / AUTOSAR M2-Metamodell-Ausschnitt (Manifest-Modellierung, Adaptive Platform).
• Technischer Zweck: Spezifikation von Software-Schnittstellen (PortInterface) für das Subsystem ara::crypto. Dient der deklarativen Modellierung des Zugriffs einer Adaptive Application über standardisierte Ports (RPortPrototype) auf kryptografische Ressourcen (Key Slots, Zertifikate, Crypto Provider, Trust Master) im Application/Execution Manifest (gemäß RS_MANI_00031, TPS_MANI_03253, Release R20-11).

2. Komponenten, Entitäten & Schnittstellen

Metamodell-Klassen & Schnittstellen

• PortInterface (Stereotypen: ARElement, AtpBlueprint, AtpBlueprintable, AtpType):
  • Generische Basisklasse aller AUTOSAR-Port-Schnittstellen.
  • Beziehung: Wird über die Assoziation +requiredInterface (0..1, «isOfType», redefiniert atpType) an AbstractRequiredPortPrototype bzw. RPortPrototype gebunden.
• CryptoInterface (abstrakt):
  • Spezialisiert PortInterface.
  • Wurzelklasse für sämtliche typspezifischen Crypto-Schnittstellen der Adaptive Platform.
• Spezialisierungen von CryptoInterface:
  • AbstractCryptoKeySlotInterface (abstrakt):
    • Spezialisiert CryptoInterface.
    • Abstrakte Basisklasse für Schlüssel-Slot-Schnittstellen.
    • Attribute:
      • allocateShadowCopy: Boolean [0..1]: Steuert, ob für Transaktionssicherheit ein Shadow-Puffer allokiert wird.
      • cryptoAlgId: String [0..1]: Spezifiziert den Krypto-Algorithmus (z. B. Algorithmen-Identifier / Crypto Primitives).
      • cryptoObjectType: CryptoObjectTypeEnum [0..1]: Art des gespeicherten Objekts.
      • slotCapacity: PositiveInteger [0..1]: Maximale Kapazität des Slots in Bytes.
      • slotType: CryptoKeySlotTypeEnum [0..1]: Gültigkeits- bzw. Isolationsbereich (machine vs. application).
  • CryptoKeySlotInterface:
    • Spezialisiert AbstractCryptoKeySlotInterface.
    • Modelliert die Schnittstelle für Schlüssel-Slots.
  • CryptoKeySlotClientInterface:
    • Spezialisiert AbstractCryptoKeySlotInterface.
    • Modelliert die Client-seitige Schnittstelle für den Zugriff auf Schlüssel-Slots.
  • CryptoCertificateInterface: Repräsentiert Schnittstellen für X.509-Zertifikate.
    • isPrivate: Boolean [0..1]: Kennzeichnung als privates/vertrauliches Zertifikat.
    • writeAccess: Boolean [0..1]: Erlaubt schreibenden/aktualisierenden Zugriff auf das Zertifikat.
  • CryptoProviderInterface: Repräsentiert die Fabrik- und Initialisierungsschnittstelle zu einem spezifischen Crypto Provider Driver/Plugin.
  • CryptoTrustMasterInterface: Modelliert administrative/Root-of-Trust-Schnittstellen (z. B. Trust Anchor Management, Key Management Privilege).

Kompositionen & Unterstrukturen von AbstractCryptoKeySlotInterface

• CryptoKeySlotAllowedModification (Komposition +keySlotAllowedModification, Kardinalität 0..1):
  • Definiert Schreib-, Update- und Exportrestriktionen des Schlüssel-Slots.
  • Attribute: allowContentTypeChange: Boolean [0..1], exportability: Boolean [0..1], maxNumberOfAllowedUpdates: PositiveInteger [0..1], restrictUpdate: Boolean [0..1].
• CryptoKeySlotContentAllowedUsage (Komposition +keySlotContentAllowedUsage, Kardinalität 0..*):
  • Regelt granulare Verwendungszwecke des Schlüssels.
  • Attribut: allowedKeyslotUsage: String [0..1].

Enumerationen

• CryptoObjectTypeEnum: Undefined, SymmetricKey, PrivateKey, PublicKey, Signature, SecretSeed.
• CryptoKeySlotTypeEnum: machine (maschinenweiter Shared Slot), application (applikationsisolierter Slot).
• CryptoKeySlotUsageEnum: verification, encryption.

3. Dynamisches Verhalten & Sequenzablauf

• Als statisches M2-Strukturdiagramm enthält das Schaubild keine direkten Laufzeit-Zustandsübergänge; es definiert jedoch das statische Berechtigungs- und Deployment-Gerüst für das Laufzeitverhalten:
  1. Manifest-Parsing & Slot-Mapping (Startup): Execution Management und der Crypto Daemon werten das Manifest der Adaptive Application aus. Ein RPortPrototype, der ein CryptoKeySlotInterface referenziert, wird gegen den physischen Key Storage gemappt.
  2. Zugriffsbeschränkung & Validierung: Bei Aufruf von ara::crypto::keys::OpenKeySlot() validiert der Crypto-Stack die Operationen gegen slotType, slotCapacity und CryptoKeySlotAllowedModification (z. B. Abbruch/Error bei Schreibversuch, wenn restrictUpdate == true oder Update-Limit maxNumberOfAllowedUpdates überschritten ist).
  3. Usage Enforcement: Krypto-Operationen (Signieren, Verschlüsseln) schlagen fehl, wenn der beabsichtigte Modus nicht durch keySlotContentAllowedUsage bzw. CryptoKeySlotUsageEnum abgedeckt ist.

4. Normative Relevanz & Entwickler-Hinweise

• Applikations-Entwickler (ara::crypto):
  • Schnittstellen stellen keine klassischen Client-Server- oder Service-Interfaces (wie ara::com) dar, sondern dienen als formale Typisierung von Ports zur Konfiguration von Zugriffsrechten, Speicherlimits und Berechtigungs-Tokens.
  • Im C++-Code wird kein Code-Generator für Skeleton/Proxy generiert; die ARXML-Ports dienen dem Security-Policy-Enforcement und der Verknüpfung mit dem Plattform-Schlüsselspeicher.
• Manifest- & Integrations-Konfiguration:
  • Bei slotType = machine ist auf systemweite Eindeutigkeit und geteilte Zugriffsrechte zwischen Prozessen zu achten.
  • Fehlen Attribute wie slotCapacity oder cryptoObjectType, greifen standardmäßig plattformspezifische Defaults des Crypto Providers oder der Typ bleibt Undefined.
  • allocateShadowCopy = true erhöht die Ausfallsicherheit bei Stromausfall während Key-Updates (A/B-Swapping), benötigt aber den doppelten physischen NVM-/HSM-Speicher.