Figure 15.7: Sequence diagram of STS_CRYPTO_00008 Steps 21-40.

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-2.0-Sequenzdiagramm (sd STS_CRYPTO_00008 Steps 21-40).
• Architektur-Kontext: AUTOSAR Adaptive Platform System Tests (AUTOSAR_AP_TR_SystemTests), Kapitel Crypto Stack Verification.
• Technischer Zweck: Spezifikation eines Teilszenarios des Abnahmetests STS_CRYPTO_00008 zur normativen Verifikation von Key Wrapping und Key Unwrapping gemäß RS_CRYPTO_02008. Der Test validiert, ob ein zuvor via Key Encapsulation Mechanism (KEM, Schritt 2) gewonnener symmetrischer Schlüssel <SK1> erfolgreich in der ara::crypto-Laufzeit als Wrapping-Key genutzt werden kann, um einen transportierten gewrappten Schlüssel <WSK2> (Wrapped Symmetric Key 2) zu entpacken (<SK2>), diesen für symmetrische Verschlüsselungsoperationen zu instanziieren und anschließend <SK2> deterministisch wieder zu wrappen.

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Lifelines:
  • CRYPTO Tester: Test-Harness / Test-Orchestrator zur Stimulierung, Dateninjektion und Statusevaluation.
  • CRYPTOApp01: Adaptive Application (AUTOSAR System-Under-Test / SUT), die gegen das funktionale Cluster ara::crypto (ara::crypto::cryp / ara::crypto::keys) linkt.
• Kryptografische Entitäten & Datenobjekte:
  • <SK1>: Symmetrischer Basisschlüssel (aus Schritt 2 via Decapsulation ermittelt), fungiert als Key-Encrypting Key (KEK) für Wrapping/Unwrapping.
  • <WSK2>: Wrapped Symmetric Key 2 (Ciphertext des Nutzschlüssels).
  • <SK2>: Entpackter symmetrischer Zielschlüssel (Plaintext Key Object innerhalb der Crypto-Hardware/des Key-Storage).
  • <Plaintext2> / <Ciphertext2> / <Ciphertext2'>: Nutzdaten zur operativen Verifikation der kryptografischen Funktionsfähigkeit von <SK2>.
  • <WSK2'>: Durch das SUT neu gewrappter Schlüssel zur Re-Wrapping-Prüfung gegen <WSK2>.
• Schnittstellen & Interaktionsmodi:
  • Inter-Process- / Test-Kommunikation zwischen Tester und SUT (synchroner Request/Response-Zyklus via IPC/SOME/IP bzw. Test-RPC-Interface).
  • Interne Kapselung: Aufruf von ara::crypto::cryp::KeyWrapperCtx / ara::crypto::cryp::SymmetricBlockCipherCtx innerhalb von CRYPTOApp01.

3. Dynamisches Verhalten & Sequenzablauf

Der Ablauf gliedert sich in drei synchrone Phasen (Schritte 21 bis 40):

Phase A: Key Unwrapping & Statusprüfung (Schritte 21–24)

1. Step 21: CRYPTO Tester sendet <WSK2> an CRYPTOApp01 zur Triggerung des Unwrappings.
2. Step 22: CRYPTOApp01 führt das Unwrapping von <WSK2> unter Verwendung von <SK1> aus und instanziiert das In-Memory/Hardware-Schlüsselobjekt <SK2>.
3. Step 23 & 24: CRYPTOApp01 meldet den Ausführungsstatus (ara::core::Result<void>) an den Tester zurück; der Tester verifiziert den Status auf Fehlerfreiheit.

Phase B: Funktionale Validierung des entpackten Schlüssels <SK2> (Schritte 25–32)

1. Step 25: CRYPTO Tester übermittelt den Testvektor <Plaintext2> an CRYPTOApp01.
2. Step 26: CRYPTOApp01 verschlüsselt <Plaintext2> unter Verwendung von <SK2> zu <Ciphertext2'>.
3. Step 27 & 28: Rückmeldung und Verifikation des Verschlüsselungsstatus beim Tester.
4. Step 29: Tester sendet die Referenzchiffre <Ciphertext2> zur Verifikation an CRYPTOApp01.
5. Step 30: CRYPTOApp01 vergleicht <Ciphertext2'> bitgenau mit dem Sollwert <Ciphertext2>.
6. Step 31 & 32: CRYPTOApp01 liefert das Vergleichsergebnis (matched/unmatched) an den Tester, welcher dieses assertiert.

Phase C: Key Wrapping & Validierung (Schritte 33–40)

1. Step 33: CRYPTO Tester triggert das Wrapping von <SK2> an CRYPTOApp01.
2. Step 34: CRYPTOApp01 wrappt <SK2> mittels <SK1> und erzeugt den gewrappten Chiffretext <WSK2'>.
3. Step 35 & 36: Statusübermittlung und -überprüfung des Wrapping-Vorgangs.
4. Step 37: Tester triggert den Vergleich von Re-Wrapping zu Original.
5. Step 38: CRYPTOApp01 vergleicht <WSK2'> mit <WSK2>.
6. Step 39 & 40: Übertragung des Vergleichsergebnisses an den Tester und finale Assertion.

4. Normative Relevanz & Entwickler-Hinweise

• API- und Kontext-Verträge (ara::crypto):
  • Entwickler müssen sicherstellen, dass die verwendeten Key-Slots (CryptoProvider) für <SK1> und <SK2> die erforderlichen KeyUsageFlags besitzen:
    • <SK1> benötigt Flags für kAllowKeyWrapping und kAllowKeyUnwrapping.
    • <SK2> benötigt Berechtigungen für Transformationen (kAllowDataEncryption) sowie Exportfähigkeit (kAllowKeyExport / kAllowSecuredKeyExport).
• Determinisierung des Algorithmus:
  • Der Test setzt für Phase C ein deterministisches Wrapping-Verfahren (z. B. AES Key Wrap gemäß RFC 3394 / NIST SP 800-38F ohne zufällige Nonce bzw. mit fest definiertem Initial Vector) voraus, da der direkte Bit-Vergleich Compare <WSK2'> with <WSK2> in Step 38 andernfalls fehlschlägt.
• Isolierung & Sicherheitsdomänen:
  • Schlüssel-Export/Import im Adaptive Stack muss sicherstellen, dass der Klartextschlüssel <SK2> zu keinem Zeitpunkt ungesichert im User-Space-Speicher exponiert wird (Nutzung von Crypto-Hardware/HSM/SE-Backed CryptoProvider).
  • Fehler in den Einzelschritten (z. B. Ungültiger MAC/Integrity-Check beim Unwrapping) müssen zwingend auf standardisierte ara::crypto::SecurityErrc-Fehlercodes mappen.