Figure 7.6: Application interface

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Formelles UML-Klassendiagramm der AUTOSAR Adaptive Platform (M2-Metamodell-Ebene).
• Technischer Zweck: Modellierung der Service- und Port-Schnittstellen (PortInterface) für das Subsystem ara::crypto. Es definiert die typisierte Port-basierte Interaktion zwischen einer Adaptive Application (RPortPrototype) und den kryptografischen Diensten/Ressourcen der Plattform (Key-Slots, Zertifikate, Trust-Master, Crypto-Provider) im Manifest (ARXML-Design-Phase).

2. Komponenten, Entitäten & Schnittstellen

Metamodell-Klassen & Stereotypen

• PortInterface (Stereotypen: «ARElement», «AtpBlueprint», «AtpBlueprintable», «AtpType»):
  • Generische Basisklasse aller AUTOSAR-Schnittstellenbeschreibungen.
• AbstractRequiredPortPrototype / RPortPrototype:
  • Client-Port einer Adaptive Application. Typisiert über die Assoziation «isOfType» (+requiredInterface, Multiplizität 0..1, redefiniert atpType) auf PortInterface.
• CryptoInterface:
  • Abstrakte Spezialisierung (Generalization) von PortInterface; fungiert als Basis-Klasse für alle kryptografischen Port-Schnittstellen.

Konkrete Schnittstellen (CryptoInterface-Spezialisierungen)

1. CryptoKeySlotInterface:
   • Schnittstelle zur Allokation, Definition und Restriktion persistenter oder flüchtiger Schlüsselspeicher (Key Slots).
   • Attribute:
     • allocateShadowCopy: Boolean [0..1] – Steuert die Allokation einer Schattenkopie für atomare Updates/Rollbacks.
     • cryptoAlgId: String [0..1] – Krypto-Algorithmus-Identifikator (z. B. standardisierter Crypto-Primitive-String).
     • cryptoObjectType: CryptoObjectTypeEnum [0..1] – Typ des Krypto-Objekts.
     • slotCapacity: PositiveInteger [0..1] – Maximale Kapazität des Slots in Bytes.
     • slotType: CryptoKeySlotTypeEnum [0..1] – Scope/Lebensdauer des Slots (machine vs. application).
2. CryptoCertificateInterface:
   • Schnittstelle zur Verwaltung von X.509- bzw. Krypto-Zertifikaten.
   • Attribute:
     • isPrivate: Boolean [0..1] – Zugriffsbeschränkung auf den Kontext der besitzenden Applikation.
     • writeAccess: Boolean [0..1] – Erlaubt Schreib-/Aktualisierungsoperationen auf dem Zertifikatsspeicher.
3. CryptoTrustMasterInterface:
   • Spezialisierte Schnittstelle für administrative Trust-Anchor- und Root-Zertifikatsoperationen.
4. CryptoProviderInterface:
   • Einstiegspunkt zur Instanziierung spezifischer Krypto-Treiber-/Bibliotheks-Backends (CryptoProvider).

Aggregationen von CryptoKeySlotInterface

• CryptoKeySlotAllowedModification (Komposition +keySlotAllowedModification, Kardinalität 0..1):
  • Definiert Restriktionen für Runtime-Modifikationen des Schlüsselslots.
  • Attribute: allowContentTypeChange: Boolean [0..1], exportability: Boolean [0..1], maxNumberOfAllowedUpdates: PositiveInteger [0..1], restrictUpdate: Boolean [0..1].
• CryptoKeySlotContentAllowedUsage (Komposition +keySlotContentAllowedUsage, Kardinalität 0..*):
  • Feingranulare Beschränkung der erlaubten Operationen für Schlüssel im Slot.
  • Attribute: allowedKeyslotUsage: String [0..1].

Enumerationen

• CryptoObjectTypeEnum: Undefined, SymmetricKey, PrivateKey, PublicKey, Signature, SecretSeed.
• CryptoKeySlotTypeEnum: machine (maschinenweiter Key-Slot, z. B. ECU-Identität), application (applikationsspezifischer Key-Slot).
• CryptoKeySlotUsageEnum: verification, encryption.

3. Dynamisches Verhalten & Sequenzablauf

• Da es sich um ein statisches Struktur-/Metamodell-Diagramm handelt, ist kein zeitlicher Kontrollfluss abgebildet.
• Laufzeit-Bindung:
  1. Die Applikation deklariert einen RPortPrototype, der ein CryptoKeySlotInterface referenziert.
  2. Zur Initialisierungszeit löst der Plattform-Stack (ara::crypto::keys::EntryAccessor / ara::crypto) über das Execution Management / Service Discovery den Port auf die physisch im Manifest konfigurierte Krypto-Storage-Instanz auf.
  3. Bei Schreibversuchen validiert der Stack statisch und dynamisch die Richtlinien (restrictUpdate, maxNumberOfAllowedUpdates, writeAccess). Bei Verletzung der Constraints schlägt die Operation synchron fehl (ara::core::ErrorCode / CryptoErrc::kAccessViolation).

4. Normative Relevanz & Entwickler-Hinweise

• Manifest-Design (ARXML):
  • Entwickler müssen über diese Metaklassen festlegen, welche Krypto-Objekte eine Adaptive Application konsumieren darf. Fehlt ein entsprechendes Interface am RPortPrototype, verweigert die ara::crypto-Plattformarchitektur den Zugriff auf Key-Slots und Zertifikate.
• Sicherheits- & Rechte-Restriktionen:
  • exportability = false verhindert das Auslesen von Rohschlüsseln über die ara::crypto-API (Export als Klartext-Objekt unzulässig).
  • slotType = machine erfordert privilegierte Plattformrechte; reguläre Adaptive Applications sind i. d. R. auf slotType = application beschränkt.
  • allocateShadowCopy = true muss bei Update-Fähigkeit (z. B. OTA-Schlüsseltausch) gesetzt sein, um Ausfallsicherheit bei Spannungsabfall während des Schreibvorgangs im NVM zu garantieren.
• API-Mapping:
  • Instanzen von CryptoKeySlotInterface mappen in C++ direkt auf Instanzen von ara::crypto::keys::KeySlot und steuern das Verhalten von ara::crypto::keys::KeySlotPrototypeProps.