Figure 9.47: DigestService and CryptoContext Interfaces

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm / Schnittstellendiagramm (Strukturdiagramm der AUTOSAR Adaptive Platform).
• Technischer Zweck: Spezifikation der standardisierten C++-Schnittstellen («aapAPI,aapNativeInterface») für kryptografische Primitiven und Streaming-Kontexte innerhalb des funktionalen Clusters Cryptography (ara::crypto).
• Architektur-Einordnung: Veranschaulichung der Client-Server- bzw. API-Beziehung zwischen einer Adaptive Application (Nutzer) und dem daemon-basierten Plattform-Service Cryptography («aapFunctionalCluster»). Die Interfaces kapseln Zustandsautomaten für block- und streambasierte Krypto-Operationen (AEAD/Authenticated Ciphers, Message Authentication Codes, kryptografische Hashfunktionen) sowie den gemeinsamen Abfragedienst für Digest-Zustände (DigestService).

2. Komponenten, Entitäten & Schnittstellen

Akteure & Komponenten

• Adaptive Application: Konsument der kryptografischen Dienste im Benutzer-Kontext (User Space Process).
• «aapFunctionalCluster» Cryptography (daemon-based): Bereitstellende Plattform-Instanz des Adaptive Core. Realisiert die hardware- oder softwaregestützten Krypto-Treiber/Engines (z. B. HSM, Crypto-Daemon, vHSM/PKCS#11).

Schnittstellen («aapAPI,aapNativeInterface»)

1. AuthCipherCtx (Scope: CryptoContext / ara::crypto::cryp::AuthCipherCtx):
   • Authenticated Encryption with Associated Data (AEAD) Kontext.
   • Methoden: Check(), GetDigest(), GetDigestService(), GetMaxAssociatedDataSize(), GetTransformation(), ProcessConfidentialData(), Reset(), SetKey(), Start(), UpdateAssociatedData().
2. HashFunctionCtx (Scope: CryptoContext / ara::crypto::cryp::HashFunctionCtx):
   • Streaming-Interface für unkeyed Hashverfahren (z. B. SHA-2, SHA-3).
   • Methoden: Finish(), GetDigest(), GetDigestService(), Start(), Update().
3. MessageAuthnCodeCtx (Scope: CryptoContext / ara::crypto::cryp::MessageAuthnCodeCtx):
   • Streaming-Interface für symmetrische Authentisierungscodes (z. B. HMAC, CMAC).
   • Methoden: Check(), Finish(), GetDigest(), GetDigestService(), Reset(), SetKey(), Start(), Update().
4. DigestService (Scope: BlockService / ara::crypto::cryp::DigestService):
   • Status- und Verifikationsschnittstelle für Digest-erzeugende Kontexte; zugänglich u. a. via GetDigestService() der Krypto-Kontexte.
   • Methoden: Compare(), GetDigestSize(), IsFinished(), IsStarted().

Beziehungen & Kardinalitäten

• Nutzung («use» / Dependency): Adaptive Application greift über direkte Abhängigkeitspfeile auf alle vier Schnittstellen zu.
• Schnittstellen-Realisierung (Interface Realization): Der Cluster Cryptography implementiert (implements / gestrichelte Linie mit geschlossener Dreiecksspitze) AuthCipherCtx, HashFunctionCtx, MessageAuthnCodeCtx sowie DigestService.
• Strukturelle Kopplung: AuthCipherCtx, HashFunctionCtx und MessageAuthnCodeCtx aggregieren/referenzieren DigestService typischerweise über ihre Methode GetDigestService(), um Verifikations- und Statusabfragen (Compare, IsFinished) thread-sicher und modular auszulagern.

3. Dynamisches Verhalten & Sequenzablauf

Die Kontexte erzwingen ein definiertes Zustandsmodell für Streaming-Operationen:

1. Initialisierung & Parametrierung:
   • Schlüsselgebundene Kontexte (AuthCipherCtx, MessageAuthnCodeCtx) fordern zunächst SetKey().
   • Start des Operationszyklus via Start() (Initialvektor/Nonce-Übergabe je nach Algorithmus).
   • DigestService::IsStarted() wechselt auf true, IsFinished() auf false.
2. Datenverarbeitung (Streaming / Chunking):
   • HashFunctionCtx / MessageAuthnCodeCtx: Iterative Aufrufe von Update() mit Nutzdaten-Chunks.
   • AuthCipherCtx: Getrennte Verarbeitung von Zusatzdaten via UpdateAssociatedData() und Nutzlast via ProcessConfidentialData().
3. Abschluss & Verifikation:
   • Hash / MAC Erzeugung: Finish() schließt die Berechnung ab (IsFinished() == true), GetDigest() extrahiert das Ergebnis.
   • MAC / AEAD Verifikation (In-Place Check): Statt Klartext-Extraktion wird Check() oder DigestService::Compare() genutzt (verhindert Timing-Side-Channel-Angriffe über konstante Laufzeitvergleiche).
4. Zurücksetzen:
   • Reset() versetzt den Kontext in den uninitialisierten Zustand zur Wiederverwendung des Objekts ohne Neuzuweisung des Heap-Speichers.

4. Normative Relevanz & Entwickler-Hinweise

• Timing-Side-Channels & Constant-Time Verification: Applikationsentwickler müssen zur MAC- oder Tag-Verifikation zwingend Check() bzw. DigestService::Compare() verwenden, anstatt den Digest über GetDigest() abzurufen und mittels memcmp() bzw. std::equal manuell zu vergleichen.
• IPC- & Daemon-Overhead: Da der funktionale Cluster als daemon-based gekennzeichnet ist, können Kontextoperationen je nach Stack-Implementierung IPC-Übergänge (z. B. Unix Domain Sockets, Shared Memory) zum Krypto-Daemon erfordern. Für Hochdurchsatzdaten (z. B. Videostreams, große Flash-Images) ist Chunk-Streaming (Update()) mit optimierten Puffergrößen erforderlich, um IPC-Latenzen zu minimieren.
• Key-Slots & Handle-Sicherheit: SetKey() akzeptiert ara::crypto::keys::KeySlot bzw. symmetrische Schlüsselobjekte. Schlüsselmaterial verbleibt im sicheren Speicher des Daemons bzw. HSMs und wird nicht in den Adressraum der Adaptive Application kopiert.
• Zustandssicherheit (State Machine Contract): Der Aufruf von Update() nach Finish() ohne vorheriges Start() oder Reset() führt zu Fehlern (ara::crypto::SecurityErrc::kProcessingNotStarted bzw. ungültigem Kontextzustand gemäß AUTOSAR SWS Cryptography). Vor Auswertung von Digest-Ergebnissen muss über DigestService::IsFinished() validiert werden.