Figure 15.3: Sequence diagram of STS_CRYPTO_00004.

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML 2.x Sequenzdiagramm (sd STS_CRYPTO_00004).
• Architektur-Kontext: System-Integrationstestfall aus der Spezifikation AUTOSAR_AP_TR_SystemTests für die AUTOSAR Adaptive Platform (Release R25-11).
• Funktionaler Zweck: End-to-End-Verifikation des Functional Clusters Crypto (ara::crypto). Validiert wird das asymmetrische Signieren und Verifizieren digitaler Signaturen unter Nutzung getrennter privater (<APvK>) und öffentlicher (<APbK>) Schlüssel über standardisierte Krypto-Kontexte (HashFunctionCtx, VerifierPublicCtx).

2. Komponenten, Entitäten & Schnittstellen

• Lifelines / Akteure:
  • CRYPTO Tester: Externe Testumgebung / Test-Harness (Injektion von Stimuli, Bereitstellung von Referenzdaten und Verifikation von Statusrückmeldungen).
  • CRYPTOApp01: AUTOSAR Adaptive Application (SUT – System Under Test) im User Space, welche die APIs des Krypto-Stacks konsumiert.
• Kryptografische Entitäten & Testvektoren:
  • <Data1>, <Data2>: Test-Nutzdaten / Payloads.
  • <APvK>: Asymmetrischer privater Schlüssel (Asymmetric Private Key) von CRYPTOApp01 (Signaturschlüssel).
  • <APbK>: Asymmetrischer öffentlicher Schlüssel (Asymmetric Public Key) von CRYPTOApp01 (Verifikationsschlüssel).
  • <DS1>: Referenz-Signatur für <Data1>, vom Tester bereitgestellt.
  • <DS1'>: Zur Laufzeit durch CRYPTOApp01 aus <Data1> generierte Signatur.
  • <DS2>: Gültige digitale Signatur für <Data2>, durch Tester vorgegeben.
• Verwendete Schnittstellen & Kontext-Klassen (ara::crypto::cryp):
  • ara::crypto::cryp::HashFunctionCtx: Schnittstelle zur Digest-Berechnung mit den Lebenszyklus-Methoden Start(), Update(), Finish().
  • ara::crypto::cryp::VerifierPublicCtx: Kontext zur Signaturprüfung via Verify().
  • Implizit: ara::crypto::cryp::SignerPrivateCtx zur Erzeugung von <DS1'> in Step 2.
  • Inter-Process- / Test-Kommunikation: Dienstbasierte Schnittstellen (z. B. via ara::com oder Test-RPC) zur Übertragung von Testvektoren und Statuswerten.

3. Dynamisches Verhalten & Sequenzablauf

Der Testfall gliedert sich in zwei sequentielle Prüfphasen:

Phase 1: Signaturerzeugung und Ergebnisprüfung (Steps 1–8)

1. [Step 1] Request: CRYPTO Tester sendet Rohdaten <Data1> an CRYPTOApp01.
2. [Step 2] Execution: CRYPTOApp01 generiert intern die digitale Signatur <DS1'> aus <Data1> unter Verwendung des privaten Schlüssels <APvK>.
3. [Step 3 & 4] Response & Evaluation: CRYPTOApp01 meldet den Status der Signaturerzeugung zurück (synchron/asynchron). CRYPTO Tester prüft den Status auf Fehlerfreiheit.
4. [Step 5] Request: CRYPTO Tester übergibt die Solldaten/Referenzsignatur <DS1> an CRYPTOApp01.
5. [Step 6] Execution: CRYPTOApp01 vergleicht die lokal generierte Signatur <DS1'> direkt mit der Soll-Signatur <DS1>.
6. [Step 7 & 8] Response & Evaluation: CRYPTOApp01 liefert das Vergleichsergebnis zurück. CRYPTO Tester evaluiert die Identität der Signaturen.

Phase 2: Signaturverifikation via Public Key (Steps 9–12)

1. [Step 9] Request: CRYPTO Tester injiziert <Data2> zusammen mit der existierenden Signatur <DS2> in CRYPTOApp01.
2. [Step 10] Execution: CRYPTOApp01 führt die Verifikation durch:
   • Aufruf von HashFunctionCtx::Start() zur Initialisierung des Hash-Puffers.
   • Aufruf von HashFunctionCtx::Update() zum Hashing von <Data2>.
   • Aufruf von HashFunctionCtx::Finish() zur Finalisierung des Message-Digests.
   • Aufruf von VerifierPublicCtx::Verify() mit <DS2> unter Bindung an den öffentlichen Schlüssel <APbK>.
3. [Step 11 & 12] Response & Evaluation: CRYPTOApp01 meldet den Verifikationsstatus an den Tester zurück. CRYPTO Tester validiert die Rückgabe auf Erfolg (success, keine Fehler/Exceptions).

4. Normative Relevanz & Entwickler-Hinweise

• Zweistufiger Signatur-/Verifikationsprozess: Die Spezifikation fordert die explizite Entkopplung von Hashing (HashFunctionCtx) und kryptografischer Verifikation (VerifierPublicCtx). Entwickler müssen sicherstellen, dass Digest-Algorithmus und Signaturalgorithmus (z. B. SHA-256 mit RSA-PSS oder ECDSA) kompatibel über den Crypto Provider konfiguriert sind.
• Deterministisches vs. probabilistisches Signieren: Der Byte-für-Byte-Vergleich in Step 6 (<DS1'> vs. <DS1>) erfordert entweder ein deterministisches Signaturverfahren (z. B. ECDSA nach RFC 6979 oder deterministisches RSASSA-PKCS1-v1_5) oder ein Test-Setup mit fixiertem Nonce/Salt. Bei probabilistischen Verfahren (wie Standard-RSA-PSS) schlägt ein direkter Signaturvergleich fehl; dort ist zwingend eine Verifikation über den Verifier-Kontext erforderlich.
• Fehlerbehandlung: Alle Methodenaufrufe in Step 10 unterliegen dem ara::core::Result<T>-Pattern. Fehler (z. B. SecurityErrorDomain::kProcessingNotFinished, kInvalidInputSize oder kIncompatibleArguments) müssen deterministisch abgefangen und im Statusreport an den Tester propagiert werden.
• Key Slot & Usage Flags: Der Private Key <APvK> muss im Manifest/Key-Storage mit KeyUsage::kAllowSignature konfiguriert sein, der Public Key <APbK> zwingend mit KeyUsage::kAllowVerification. Ein Vertauschen oder Fehlen der Flags führt normativ zum Abbruch mit Sicherheitsfehler.