Figure 9.46: BlockService and CryptoContext Interfaces

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Klassendiagramm / Schnittstellen- und Komponentenarchitektur (Interface Realization & Usage).
• Architektur-Kontext: AUTOSAR Adaptive Platform (ARA), Functional Cluster Cryptography (ara::crypto), Spezifikation AUTOSAR_EXP_SWArchitecture (Release R21-11).
• Technischer Zweck: Spezifikation der objektorientierten C++-Schnittstellen für symmetrische Strom- und Blockchiffren-Operationen. Das Diagramm illustriert das Extension-Service-Pattern: Entkopplung der primären Stream-Transformations-Pipeline (StreamCipherCtx) von algorithmusspezifischen Block- und Initialisierungsvektor-Metadaten (BlockService) in einer daemon-basierten Implementierungsarchitektur.

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Komponenten

• Adaptive Application (UML-Component): Konsumenten-Prozess im User Space (POSIX OS), der kryptografische Operationen über die standardisierte C++-API anfordert.
• «aapFunctionalCluster» Cryptography (daemon-based): Dienstleistender Functional Cluster. Läuft als eigenständiger Daemon-Prozess (ARA Crypto Daemon) mit Anbindung an Plattform-Sicherheitsmodule (z. B. HSM, Crypto-Treiber, Secure Elements via IPC/Shared Memory).

Schnittstellen (Interfaces)

• StreamCipherCtx («aapAPI, aapNativeInterface», Rolle: CryptoContext): Zustandsbehafteter Krypto-Kontext (ara::crypto::cryp::StreamCipherCtx) zur symmetrischen Ver- und Entschlüsselung.
  • Lebenszyklus & Transformation: SetKey(), Start(), Reset(), GetTransformation().
  • Datentransfer & Verarbeitung: ProcessBytes(), ProcessBlocks(), FinishBytes().
  • Streaming- & Modus-Prüfung: IsBytewiseMode(), IsSeekableMode(), Seek() (z. B. für Counter-Modi wie AES-CTR).
  • Puffermanagement & Prädiktion: CountBytesInCache(), EstimateMaxInputSize(), EstimateRequiredCapacity().
  • Service-Kopplung: GetBlockService() (Liefert Referenz/Pointer auf assoziierten Blockdienst).
• BlockService («aapAPI, aapNativeInterface», Rolle: ExtensionService): Zusatzschnittstelle (ara::crypto::cryp::BlockService) für kryptografische Primitive, die auf Blockchiffren basieren.
  • Methoden: GetBlockSize(), GetIvSize(), GetActualIvBitLength(), IsValidIvSize().

Beziehungen & Abhängigkeiten

• Realization (--▷ gestrichelt): Der Cluster Cryptography implementiert die nativen Schnittstellen StreamCipherCtx und BlockService.
• Usage (..> «use»): Die Adaptive Application nutzt beide Schnittstellen direkt über typisierte C++-Smart-Pointer (CryptoContext::Uptr bzw. über Rückgabe von GetBlockService()).
• Assoziation via Factory-Methode: StreamCipherCtx::GetBlockService() realisiert eine lose Kopplung; Chiffren ohne Blockcharakteristik (z. B. ChaCha20) geben hierbei nullptr zurück.

3. Dynamisches Verhalten & Sequenzablauf

Typischer Ausführungs- und Zustandsübergangspfad für eine Adaptive Application:

1. Kontext-Instanziierung & Schlüsselbindung:
   • Erzeugen des StreamCipherCtx über den zuständigen CryptoProvider.
   • Bindung des Schlüssels über SetKey(cryptoKey).
2. IV-/Parameter-Validierung via ExtensionService:
   • Aufruf von GetBlockService() am Kontext.
   • Validierung der Vektor- und Blockgrenzen (GetBlockSize(), IsValidIvSize(ivSize)).
   • Initialisierung des Chiffrierzustands über Start(iv).
3. Payload-Verarbeitung (Streaming / Blockweise):
   • Abfrage der Pufferanforderungen via EstimateRequiredCapacity() zur Allokation von Zielspeicher.
   • Transformation mittels ProcessBlocks() (ausgerichtete Blöcke, performant) oder ProcessBytes() (Byte-Stream, Puffercaching).
   • Optional: Direktes Springen im Stream via Seek(offset) (nur wenn IsSeekableMode() == true).
4. Finalisierung & Bereinigung:
   • FinishBytes() verarbeitet verbleibende Cache-Inhalte und schreibt Padding.
   • Reset() versetzt den Kontext ohne Re-Allokation in den Ausgangszustand zurück.

4. Normative Relevanz & Entwickler-Hinweise

• Extension Service Pattern (ara::crypto): Entwickler dürfen nicht davon ausgehen, dass jeder StreamCipherCtx zwingend einen BlockService bereitstellt. Vor Aufruf von GetBlockSize() muss der Rückgabewert von GetBlockService() zwingend auf nullptr geprüft werden.
• Deterministisches Speichermanagement: Dynamische Reallokationen im Verarbeitungszyklus sind strikt zu vermeiden. Entwickler müssen EstimateRequiredCapacity() vor Aufruf von ProcessBytes() / FinishBytes() auswerten, um Zielpuffer (ReadOnlyMemRegion / ReadWriteMemRegion) statisch bzw. deterministisch vorzuhalten.
• IPC- & Daemon-Overhead: Da Cryptography als daemon-based gekennzeichnet ist, erzeugen Kontextwechsel über Prozessgrenzen hinweg signifikante Latenzen. Zur Minimierung des IPC-Overheads ist blockweises Verarbeiten (ProcessBlocks()) mit maximaler Chunk-Größe gegenüber byteweisem Streaming (ProcessBytes()) in echtzeitkritischen Pfaden zwingend zu bevorzugen.
• Thread-Safety & Reentrancy: Instanzen von StreamCipherCtx sind zustandsbehaftet und standardmäßig nicht thread-sicher. Pro nebenläufigem Thread muss ein separater Kontext über den CryptoProvider instanziiert werden.