Figure 9.49: ExtensionService and CryptoContext Interfaces (2 of 2)

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Hybrides Spezifikationsdiagramm, bestehend aus einer tabellarischen Schnittstellenspezifikation (oben) und einem UML-Klassendiagramm / Schnittstellen-Realisierungsdiagramm (unten).
• Architektur-Kontext: AUTOSAR Adaptive Platform (ARA), Functional Cluster Cryptography (ara::crypto).
• Funktionale Einordnung: Spezifikation spezialisierter kryptographischer Kontext-Schnittstellen (CryptoContext) sowie der Hilfsschnittstelle ExtensionService. Die funktionale Implementierung ist als separater Hintergrunddienst (daemon-based) ausgelegt, der kryptographische Primitive und geschützte Schlüsseloperationen kapselt und via IPC typsichere C++ Native APIs für Applikationen im User Space bereitstellt.

2. Komponenten, Entitäten & Schnittstellen

Komponenten

• Adaptive Application (UML Component): Konsument der kryptographischen Schnittstellen; besitzt gerichtete «use»-Abhängigkeiten zu den Kontexten und dem Erweiterungsdienst.
• «aapFunctionalCluster» Cryptography (daemon-based) (UML Component): Realisierende Server-Komponente / Daemon, implementiert alle dargestellten Schnittstellen über Interface Realization (gestrichelte Linien mit geschlossener, nicht gefüllter Pfeilspitze).

Schnittstellen (Stereotypen: «aapAPI, aapNativeInterface»)

• RandomGeneratorCtx (im Tabellenteil oben detailliert, spezialisiert CryptoContext):
  • Dient der Erzeugung kryptographisch sicherer Zufallszahlen (CSPRNG).
  • Methoden: AddEntropy(), Generate(), GetExtensionService(), Seed(), SetKey().
• KeyDerivationFunctionCtx (spezialisiert CryptoContext):
  • Kontext für Schlüsselableitungsfunktionen (KDF, z. B. HKDF, PBKDF2).
  • Methoden: Init(), SetSourceKeyMaterial(), AddSalt(), AddSecretSalt(), ConfigIterations(), DeriveKey(), DeriveSeed(), Reset(), GetExtensionService().
  • Ziel-Metadatenabfragen: GetKeyIdSize(), GetTargetAlgId(), GetTargetAllowedUsage(), GetTargetKeyBitLength().
• KeyAgreementPrivateCtx (spezialisiert CryptoContext):
  • Asymmetrische Schlüsselvereinbarung (z. B. Diffie-Hellman, ECDH) unter Nutzung eines privaten Schlüssels.
  • Methoden: SetKey(), AgreeKey(), AgreeSeed(), Reset(), GetExtensionService().
• MsgRecoveryPublicCtx (spezialisiert CryptoContext):
  • Signaturprüfung mit Nachrichtenwiederherstellung (Message Recovery, z. B. RSA-ISO9796) über einen öffentlichen Schlüssel.
  • Methoden: SetKey(), DecodeAndVerify(), GetMaxInputSize(), GetMaxOutputSize(), Reset(), GetExtensionService().
• SigEncodePrivateCtx (spezialisiert CryptoContext):
  • Signierung und Nachrichten-Codierung mit privatem Schlüssel.
  • Methoden: SetKey(), SignAndEncode(), GetMaxInputSize(), GetMaxOutputSize(), Reset(), GetExtensionService().
• ExtensionService:
  • Schnittstelle zur Entkopplung und standardisierten Abfrage von Schlüsselzustand und Metadaten des an einen Kontext gebundenen Schlüssels.
  • Methoden: IsKeyAvailable(), IsKeyBitLengthSupported(), GetActualKeyBitLength(), GetMinKeyBitLength(), GetMaxKeyBitLength(), GetAllowedUsage(), GetActualKeyCOUID().

Beziehungen & Vererbung

• Spezialisierung / Vererbung: Alle Kontext-Schnittstellen (RandomGeneratorCtx, KeyDerivationFunctionCtx, KeyAgreementPrivateCtx, MsgRecoveryPublicCtx, SigEncodePrivateCtx) erweitern das Basis-Interface CryptoContext.
• Navigation zu ExtensionService: Jeder CryptoContext bietet GetExtensionService() und hält damit eine direkte 1:1-Beziehung zu einer zugehörigen Instanz von ExtensionService.

3. Dynamisches Verhalten & Sequenzablauf

1. Kontext-Allokation: Die Adaptive Application erzeugt/bezieht den spezifischen Kontext (z. B. KeyDerivationFunctionCtx oder KeyAgreementPrivateCtx) über die Factory-Methoden des CryptoProviders (Daemon-Proxy).
2. Schlüssel-Bindung & Konfiguration:
   • Aufruf von SetKey() bzw. SetSourceKeyMaterial() am Kontext.
   • Initialisierung spezifischer Parameter (z. B. AddSalt(), ConfigIterations(), Seed()).
3. Validierung über ExtensionService:
   • Die Applikation ruft GetExtensionService() ab.
   • Vor der Algorithmenausführung erfolgt die Validierung: IsKeyAvailable() == true, Abgleich von GetAllowedUsage() mit der beabsichtigten Operation und Prüfung von GetActualKeyBitLength().
4. Operation & Pufferdimensionierung:
   • Bei codierenden/dekodierenden Kontexten: Vorabfrage der maximalen Puffergrößen via GetMaxInputSize() / GetMaxOutputSize().
   • Ausführung der kryptographischen Transformation (DeriveKey(), AgreeKey(), SignAndEncode(), DecodeAndVerify(), Generate()).
5. Kontext-Bereinigung:
   • Synchroner Aufruf von Reset(), um flüchtige kryptographische Zwischenzustände (State Zeroization) im Kontext sicher zu löschen, bevor dieser freigegeben oder neu gebunden wird.

4. Normative Relevanz & Entwickler-Hinweise

• Key-Isolation via COUID: Über ExtensionService::GetActualKeyCOUID() wird die Crypto Object Unique ID des gebundenen Schlüssels ermittelt. Applikationen arbeiten rein auf Handles/COUIDs; sensitives Schlüsselmaterial verbleibt isoliert im Daemon/HSM-Speicher.
• Usage-Policy Enforcement: Der ExtensionService dient als Policy-Gatekeeper (GetAllowedUsage()). Versucht eine Applikation einen Kontext für eine Operation zu nutzen, für die der Schlüssel im Manifest/Key-Storage nicht autorisiert ist (z. B. Signieren mit einem KDF-Schlüssel), schlägt die Operation mit einem ara::core::ErrorCode fehl.
• Kontext-Zustandsbehaftung: Kontexte sind nicht thread-sicher und streng zustandsbehaftet. Vor einer Wiederverwendung mit neuem Schlüsselmaterial oder Salt ist zwingend Reset() aufzurufen, um State-Leakage und ungültige Zwischenzustände zu verhindern.
• IPC- und Allokations-Overhead: Da der Functional Cluster daemon-basiert ist, lösen Operationen IPC-Transaktionen aus. Puffer sollten vorab mittels GetMaxOutputSize() statisch bzw. deterministisch vorallokiert werden, um Laufzeitreallokationen im sicherheitskritischen Pfad zu eliminieren.