Figure 15.6: Sequence diagram of STS_CRYPTO_00008 Steps 1-20.

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm (sd STS_CRYPTO_00008 Steps 1-20).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Dokument AUTOSAR_AP_TR_SystemTests.
• Funktionale Einordnung: Verifikationsszenario zur Konformitätsprüfung des AUTOSAR Adaptive Crypto-Stacks (ara::crypto). Es validiert die fehlerfreie Ausführung asymmetrischer Schlüssel-Kapselungsmechanismen (Key Encapsulation Mechanism, KEM / Key Wrapping) durch eine Adaptive Application (CRYPTOApp01). Geprüft werden Dekapselung eines empfangenen symmetrischen Schlüssels mit dem privaten Schlüssel der Applikation (APvK), dessen Verifikation über eine symmetrische Testverschlüsselung sowie die anschließende Re-Kapselung mittels eines externen öffentlichen Schlüssels (TPbK).

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Lifelines:
  • CRYPTO Tester: Test-Harness / Test-Treiber (externes Testsystem oder koordinierender Test-Prozess), der Eingangsvektoren injiziert und Status-/Vergleichsergebnisse validiert.
  • CRYPTOApp01: System Under Test (SUT) – AUTOSAR Adaptive Application, die gegen die standardisierte ara::crypto-Schnittstelle gelinkt ist (insbesondere ara::crypto::cryp::EncrypterContext, DecrypterContext bzw. Key Management / Key Encapsulation Interfaces).
• Kryptografische Artefakte & Parameter:
  • <APvK> / <APbK>: Asymmetrisches Schlüsselpaar der Applikation (Application Private Key / Application Public Key).
  • <TPbK>: Öffentlicher Schlüssel des Testers (Tester Public Key).
  • <SK1>: Ephemerer symmetrischer Sitzungsschlüssel (Symmetric Key 1).
  • <ESK1_APbK>: Gekapselter/verschlüsselter symmetrischer Schlüssel (Encapsulated Symmetric Key 1 via <APbK>).
  • <Plaintext1>: Referenz-Klartext für den Funktionsnachweis der Dekapselung.
  • <Ciphertext1> / <Ciphertext1'>: Erwartetes Referenz-Chiffrat vs. durch SUT mit <SK1> generiertes Chiffrat.
  • <ESK1_TPbK> / <ESK1_TPbK'>: Erwarteter vs. durch SUT neu gekapselter Schlüssel unter Verwendung von <TPbK>.
• Schnittstellen & Interaktion:
  • Nachrichtenbasierte IPC/SOME/IP- oder Funktionsaufruf-Schnittstelle zwischen Test-Treiber und Test-Applikation zur Triggerung, Vektorübergabe und Statusrückmeldung.

3. Dynamisches Verhalten & Sequenzablauf

Der Ablauf unterteilt sich in drei konsekutive Phasen:

Phase A: Dekapselung von <SK1> (Schritte 1–4)

1. [Step 1] Request: CRYPTO Tester sendet <ESK1_APbK> an CRYPTOApp01, um die Schlüsseldekapselung zu triggern.
2. [Step 2] Execution: CRYPTOApp01 dekapselt intern <ESK1_APbK> unter Verwendung des privaten Schlüssels <APvK> und stellt den Klartext-Schlüssel <SK1> im flüchtigen Key-Slot / Context bereit.
3. [Step 3 & 4] Verification: Rückmeldung des Dekapselungs-Status an den Tester und lokale Verifikation (Check decapsulation status).

Phase B: Verifikation des dekapselten Schlüssels via Symmetrische Verschlüsselung (Schritte 5–12)

1. [Step 5] Injection: CRYPTO Tester überträgt Test-Nutzdaten <Plaintext1>.
2. [Step 6] Execution: CRYPTOApp01 verschlüsselt <Plaintext1> mit dem zuvor dekapselten symmetrischen Schlüssel <SK1> und erzeugt Chiffrat <Ciphertext1'>.
3. [Step 7 & 8] Status-Check: Rückgabe und Überprüfung des Verschlüsselungsstatus.
4. [Step 9] Reference Injection: Tester sendet Referenzchiffrat <Ciphertext1>.
5. [Step 10] Comparison: CRYPTOApp01 führt internen Byte-Vergleich zwischen generiertem <Ciphertext1'> und Referenz <Ciphertext1> aus.
6. [Step 11 & 12] Result Check: Rückgabe des Vergleichsergebnisses (matched/unmatched) an den Tester; Validierung der erfolgreichen Übereinstimmung.

Phase C: Kapselung von <SK1> mit externem Schlüssel (Schritte 13–20)

1. [Step 13] Trigger: Tester initiiert Kapselung von <SK1>.
2. [Step 14] Execution: CRYPTOApp01 kapselt den im Speicher gehaltenen <SK1> mit dem öffentlichen Schlüssel des Testers <TPbK>; Resultat ist <ESK1_TPbK'>.
3. [Step 15 & 16] Status-Check: Rückgabe und Validierung des Kapselungsstatus.
4. [Step 17] Reference Injection: Tester übermittelt Referenzdaten <ESK1_TPbK>.
5. [Step 18] Comparison: CRYPTOApp01 vergleicht <ESK1_TPbK'> mit Referenz <ESK1_TPbK>.
6. [Step 19 & 20] Evaluation: Rückgabe (matched/unmatched) und Abschlussprüfung durch den Tester.

4. Normative Relevanz & Entwickler-Hinweise

• API-Konformität (ara::crypto):
  • SUT-Implementierungen müssen asymmetrische KEM-Algorithmen (z. B. RSA-KEM, ECIES oder Post-Quantum-KEMs je nach Release-Profil) vollständig im Crypto-Treiber/Crypto-Provider abbilden.
  • Schlüsselhandhabung erfordert die korrekte Bindung flüchtiger symmetrischer Schlüssel (<SK1>) an Crypto-Kontexte (SymmetricBlockCipherCtx / StreamCipherCtx), ohne dass Schlüsselmaterial ungeschützt in den Userspace exponiert wird.
• Deterministisches vs. Probabilistisches KEM-Verhalten:
  • Der direkte Byte-Vergleich in Schritt 10 und Schritt 18 setzt entweder deterministische Algorithmen (z. B. deterministisches Padding/Encryption) voraus oder erfordert, dass für Testläufe feste Initialisierungsvektoren (IV) bzw. deterministische Pseudo-Zufallswerte (PRNG-Seeds) injiziert werden können.
• Fehler- und Status-Handling:
  • Bei Fehlschlagen einer Operation (z. B. Integritätsfehler beim Unwrapping) muss die Applikation standardisierte Fehlercodes (ara::core::ErrorCode bzw. Krypto-spezifische Exceptions) abfangen und als normierten Fehlerstatus an den Tester melden; ein Fortführen von Schritt 5 oder 13 bei fehlerhaftem Status (Schritt 4/8/16) führt zum Testabbruch.
• Berechtigungen & Key Storage (IAM / Manifest):
  • Das Ausführen von Schritt 2 und Schritt 14 setzt voraus, dass CRYPTOApp01 laut Execution- und Service-Instance-Manifest Zugriffsrechte auf den Key-Slot von <APvK> sowie Kapselungs-Berechtigungen besitzt.