Figure 9.47: ExtensionService and CryptoContext Interfaces (1 of 2)

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Hybrides Spezifikationsdiagramm bestehend aus einer tabellarischen Schnittstellen- und Methodenübersicht (oben) und einem UML-Klassendiagramm / Schnittstellen-Realisierungsdiagramm (unten).
• Funktionale Einordnung: AUTOSAR Adaptive Platform (Release R21-11), Functional Cluster Cryptography (ara::crypto).
• Technischer Zweck: Definition der nativen Programmierschnittstellen (C++ Native Interfaces) für kryptografische Kontexte (KEM, Key-Wrapping, RNG, MAC) sowie deren Verknüpfung mit dem gemeinsamen Metadaten- und Schlüsselanalyse-Dienst ExtensionService.

2. Komponenten, Entitäten & Schnittstellen

Akteure & Komponenten

• Adaptive Application: Konsumierende Anwendungsentität (Prozess im User-Space).
• Cryptography («aapFunctionalCluster», daemon-based): Bereitstellende Plattform-Instanz des Adaptive Core. Die Realisierung ist architektonisch als Hintergrunddienst (Daemon) ausgewiesen, typischerweise mit Prozessisolation und Hardware-Anbindung (z. B. HSM/SHE über Treiber).

Schnittstellen & Klassen («aapAPI, aapNativeInterface»)

• KeyEncapsulatorPublicCtx (Schnittstellen-Namespace CryptoContext): Asymmetrische Schlüsselkapselung (KEM - Key Encapsulation Mechanism, Sender-Rolle mit Public Key).
  • Operationen: AddKeyingData(), Encapsulate(), GetEncapsulatedSize(), GetExtensionService(), GetKekEntropy(), Reset(), SetKey().
• KeyDecapsulatorPrivateCtx (Schnittstellen-Namespace CryptoContext): Asymmetrische Schlüsselentkapselung (KEM, Empfänger-Rolle mit Private Key).
  • Operationen: DecapsulateKey(), DecapsulateSeed(), GetEncapsulatedSize(), GetExtensionService(), GetKekEntropy(), Reset(), SetKey().
• SymmetricKeyWrapperCtx (Schnittstellen-Namespace CryptoContext): Symmetrisches Schützen, Exportieren und Importieren von kryptografischem Schlüsselmaterial (Key Wrap Algorithms, z. B. AES-KW).
  • Operationen: CalculateWrappedKeySize(), GetExtensionService(), GetMaxTargetKeyLength(), GetTargetKeyGranularity(), Reset(), SetKey(), UnwrapConcreteKey(), UnwrapKey(), UnwrapSeed(), WrapKeyMaterial().
• RandomGeneratorCtx (Schnittstellen-Namespace CryptoContext): Kryptografischer Pseudozufalls- oder Hardware-Zufallsgenerator (CSPRNG/TRNG).
  • Operationen: AddEntropy(), Generate(), GetExtensionService(), Seed(), SetKey().
• ExtensionService: Begleitende Abfrage-Schnittstelle für den Zustand und die Attribute des im jeweiligen Kontext gebundenen Schlüssels.
  • Operationen: GetActualKeyBitLength(), GetActualKeyCOUID(), GetAllowedUsage(), GetMaxKeyBitLength(), GetMinKeyBitLength(), IsKeyAvailable(), IsKeyBitLengthSupported().
• Keyed MAC Context (tabellarisch definiert, z. B. MessageAuthnCodeCtx):
  • Operationen: Check(), Finish(), GetDigest(), GetDigestService(), Reset(), SetKey(), Start(), Update().

Beziehungen & Abhängigkeiten

• Abhängigkeit («use»): Adaptive Application nutzt alle fünf Interfaces direkt (KeyEncapsulatorPublicCtx, KeyDecapsulatorPrivateCtx, SymmetricKeyWrapperCtx, RandomGeneratorCtx, ExtensionService).
• Realisierung (--▷ gestrichelt mit geschlossener Hohlspitze): Der funktionale Cluster Cryptography implementiert alle genannten Interfaces.
• Assoziation / Delegation: Jeder kryptografische Kontext bietet eine Methode GetExtensionService() an, über die eine Instanz/Referenz von ExtensionService für kontextbezogene Schlüsselmetadaten erreichbar ist.

3. Dynamisches Verhalten & Sequenzablauf

Kontext-Lebenszyklus (Zustands- und Ablaufmuster)

1. Initialisierung & Schlüsselbindung:
   • Aufruf von SetKey() bindet ein persistentes oder flüchtiges Schlüsselobjekt (ara::crypto::keys::Key bzw. Key Slot) an den Kontext.
   • Über GetExtensionService() validiert die Applikation Schlüsselmetadaten (IsKeyAvailable(), GetAllowedUsage(), Bitlängen).
2. Datenstrom-Verarbeitung (Streaming am Beispiel MAC-Kontext):
   • Start() initialisiert den Puffer/IV für einen neuen Rechenlauf.
   • Update() verarbeitet Nachrichten-Chunks schrittweise (iterativ, synchron/asynchron gepuffert).
   • Finish() schließt die Berechnung ab und erzeugt das Digest-/Signaturobjekt; alternativ vergleicht Check() das Resultat direkt gegen eine erwartete Signatur.
3. Kapselung / Wrapping (Transaktional):
   • KEM: AddKeyingData() → Encapsulate() (Sender generiert Shared Secret + Ciphertext) bzw. DecapsulateKey() / DecapsulateSeed() (Empfänger rekonstruiert Schlüsselmaterial).
   • Key-Wrapping: CalculateWrappedKeySize() → WrapKeyMaterial() bzw. UnwrapKey() / UnwrapConcreteKey().
4. Bereinigung:
   • Reset() verwirft interne Puffer, Zwischenzustände und temporäres Schlüsselmaterial im Kontext für die Wiederverwendung.

4. Normative Relevanz & Entwickler-Hinweise

• Architekturmodell & Prozessgrenzen (daemon-based): Die Implementierung erfolgt über den Cryptography-Daemon. Methodenaufrufe können Interprozesskommunikation (IPC) zu einem privilegierten Sicherheitsdämon oder Hardware-Sicherheitsmodul (HSM) triggern. Zeitkritische Pfade müssen IPC-Latenzen berücksichtigen.
• Metadaten-Entkopplung via ExtensionService: Kontext-Interfaces führen keine redundanten Methoden zur Schlüsselabfrage. Prüfungen auf Schlüsselattribute (COUID, Crypto Object Unique Identifier, erlaubte Key-Usage-Flags nach AUTOSAR Key Management) müssen strikt über den abgerufenen ExtensionService erfolgen.
• Zustandssicherheit (State Machine): Alle Kontexte sind zustandsbehaftet. Vor einem erneuten Start() oder Schlüsselwechsel via SetKey() muss im Fehler- oder Abbruchfall zwingend Reset() ausgeführt werden, um Speicherlecks und undefinierte Zustände im Daemon/HSM zu verhindern.
• Polymorphie & Typgranularität: SymmetricKeyWrapperCtx unterscheidet explizit zwischen rohem Schlüsselmaterial (WrapKeyMaterial()), generischen Schlüsseln (UnwrapKey()), typisierten Schlüsseln (UnwrapConcreteKey()) und Seeds (UnwrapSeed()), was strikte Typisierungsprüfungen zur Compile- und Laufzeit erzwingt.