Figure 9.45: CryptoService and CryptoContext Interfaces

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Klassendiagramm / Schnittstellenspezifikation (AUTOSAR Adaptive Platform).
• Architektur-Kontext: Spezifikation der C++ Native API-Bindung für den Functional Cluster Cryptography (ara::crypto) gemäß AUTOSAR Adaptive Platform (R21-11, AUTOSAR_EXP_SWArchitecture).
• Technischer Zweck: Darstellung der Entkopplung zwischen der konsumierenden Adaptive Application und der Plattform-Realisierung im Modus daemon-based (getrennter Prozess/Daemon für Krypto-Primitive, Key-Storage und HSM-Anbindung). Es definiert die Schnittstellenteilung zwischen zustandsbehafteten Rechenkontexten (CryptoContext) und zustandslosen Algorithmen-Metadaten (ExtensionService).

2. Komponenten, Entitäten & Schnittstellen

• Komponenten / Akteure:
  • Adaptive Application: Anwendungsprozess im User Space, agiert als Service-Konsument.
  • «aapFunctionalCluster» Cryptography (Tag: daemon-based): Plattform-Dienst/Daemon, der die kryptografischen Treiber, Hardware-Security-Module (HSM) oder Software-Ciphers kapselt.
• Schnittstellen (Stereotypen: «aapAPI, aapNativeInterface»):
  • CryptoContext::EncryptorPrivateCtx: Asymmetrischer/privater Verschlüsselungskontext.
    • Methoden: + GetCryptoService(), + ProcessBlock(), + Reset(), + SetKey().
  • CryptoContext::DecryptorPrivateCtx: Asymmetrischer/privater Entschlüsselungskontext.
    • Methoden: + GetCryptoService(), + ProcessBlock(), + Reset(), + SetKey().
  • CryptoContext::SymmetricBlockCipherCtx: Symmetrischer Blockchiffrier-Kontext (z. B. AES-CBC, AES-GCM).
    • Methoden: + GetCryptoService(), + GetTransformation(), + ProcessBlock(), + ProcessBlocks(), + Reset(), + SetKey().
  • ExtensionService::CryptoService: Dienst zur Bereitstellung algorhythmusspezifischer Parameter und Puffergrenzen.
    • Methoden: + GetBlockSize(), + GetMaxInputSize(), + GetMaxOutputSize().
• Beziehungen & Vererbung:
  • Interface-Realization (gestrichelte Linie mit geschlossener, nicht ausgefüllter Pfeilspitze): Cryptography realisiert alle vier nativen Schnittstellen.
  • Nutzungsabhängigkeit («use», gestrichelte Pfeile): Adaptive Application bindet und konsumiert alle vier Interfaces direkt.
  • Assoziation / Navigation: Jeder CryptoContext referenziert über GetCryptoService() die zugehörige Instanz von ExtensionService::CryptoService.

3. Dynamisches Verhalten & Sequenzablauf

Obwohl als statisches Strukturdiagramm dargestellt, erzwingt das API-Design folgenden Ablauf:

1. Kontext-Allokation & Konfiguration:
   • Erzeugung/Bezug einer Kontextinstanz (EncryptorPrivateCtx, DecryptorPrivateCtx oder SymmetricBlockCipherCtx) über eine Factory/Provider-API.
   • Bindung des Schlüssels über SetKey().
2. Puffer- und Größenabfrage:
   • Aufruf von GetCryptoService() am Kontext liefert CryptoService.
   • Abfrage von Block- und Maximalgrößen (GetBlockSize(), GetMaxInputSize(), GetMaxOutputSize()) zur Vorallokation applikationsseitiger Ein-/Ausgabepuffer.
3. Kryptografische Transformation:
   • Synchroner Aufruf von ProcessBlock() für Einzelblöcke bzw. ProcessBlocks() für Blockströme.
   • Bei symmetrischen Chiffren: Identifikation des Transformationsmodus (Algorithmus, Chaining-Modus, Padding) via GetTransformation().
4. Zustandsverwaltung / Reset:
   • Reset() setzt interne Zustände (Initialisierungsvektoren IV, Zwischenpuffer) zurück, behält jedoch die Schlüsselbindung (SetKey()) bei.

4. Normative Relevanz & Entwickler-Hinweise

• IPC-Overhead bei daemon-based: Da das Cluster als Daemon instanziiert ist, involvieren Aufrufe Prozesswechsel (Context Switches) und Inter-Process Communication (IPC/Shared Memory). Entwickler müssen für Durchsatzoptimierung zwingend ProcessBlocks() (Streaming/Batching) statt sequenzieller ProcessBlock()-Aufrufe verwenden.
• Puffer-Vorvalidierung: Vor Aufruf von ProcessBlock(s) muss die Applikation die Puffergrößen strikt gegen GetMaxInputSize() und GetMaxOutputSize() validieren. Fehldimensionierungen führen zu Fehlern aus der CryptoErrorDomain (ara::core::Result<T>).
• Schlüsselisolierung: SetKey() verarbeitet Key-Slot-Handles/Referenzen (ara::crypto::keys). Reines Schlüsselmaterial verbleibt im geschützten Speicherbereich des Daemons oder im Secure Element/HSM und wird nicht in den Prozessraum der Adaptive Application kopiert.
• Thread-Sicherheit: Instanzen von CryptoContext sind zustandsbehaftet und in der Regel nicht reentrant/thread-safe. Nebenläufige Verschlüsselungsoperationen erfordern separate Kontext-Instanzen je Thread.