Figure 15.10: Sequence diagram of STS_CRYPTO_00011.

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (sd STS_CRYPTO_00011) mit alternativen Ausführungspfaden (alt-Kombinationsfragmente).
• Architektur-Kontext: AUTOSAR Adaptive Platform System Tests (AUTOSAR_AP_TR_SystemTests), Subsystem ara::crypto.
• Technischer Zweck: Spezifikation des Systemtestfalls STS_CRYPTO_00011 zur Validierung des Key-Managements. Getestet werden Import-, Export-, Integritätsverifikations- und Sicherheits-Beschränkungsmechanismen (Enforcement von Export-Restriktionen) für geschütztes (SecureKM1) und ungeschütztes (UnsecureKey1) Schlüsselmaterial.

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Lifelines:
  • CRYPTO Tester: Test-Harness / Test-Orchestrator zur Ablaufsteuerung, Stimuli-Generierung und Validierung der Testergebnisse.
  • CRYPTOApp01: System under Test (SUT) bzw. Adaptive Application, welche die ara::crypto-APIs (Key Storage Provider, Crypto Provider, Keyslots) bedient.
• Entitäten & Schlüsselobjekte:
  • <SecureKM1Exported1> / <SecureKM1Exported2>: Exportierte, kryptografisch verpackte Schlüssel-Blobs (z. B. via Key Wrapping geschützt).
  • <SK1>, <SK2>: Transport-/Verschlüsselungsschlüssel (Key Wrapping Keys).
  • <SecureKM1Exportable>: Importiertes Schlüsselobjekt mit erlaubter Export-Berechtigung.
  • <SecureKM1NotExportable>: Importiertes Schlüsselobjekt mit strikter Export-Sperre (Attribut non-exportable).
  • <UnsecureKey1Exported>: Ungeschützte/rohe Schlüsseldaten.
  • <UnsecureKey1Exportable>: Importierter, ungeschützter Schlüssel mit Export-Berechtigung.
  • <SecureKM1Exported2'>, <UnsecureKey1Exported'>: Im Testlauf re-exportierte Schlüsselmaterial-Instanzen zur Konsistenzprüfung.
• Schnittstellen: Test-Nachrichtenkanal (IPC / SOME/IP / Steuerprotokoll) zwischen Tester und Applikation sowie interne ara::crypto-C++-APIs (ImportKey, ExportKey, Compare).

3. Dynamisches Verhalten & Sequenzablauf

Der Ablauf gliedert sich in vier chronologische Phasen, jeweils differenziert über alt-Blöcke ([Testing <SecureKM1>] vs. [Testing <UnsecureKey1>]):

1. Schlüsselimport & Statusüberprüfung:
   • [Step 1]: Tester sendet Schlüsselmaterial (<SecureKM1Exported1> bzw. <UnsecureKey1Exported>) an CRYPTOApp01.
   • [Step 2]: CRYPTOApp01 importiert das Material:
     • Pfad <SecureKM1>: Entpacken via <SK1>; Erzeugung zweier Schlüsselobjekte (<SecureKM1Exportable> und <SecureKM1NotExportable>).
     • Pfad <UnsecureKey1>: Direkter Import zu <UnsecureKey1Exportable>.
   • [Step 3]: CRYPTOApp01 meldet den Import-Status an den Tester zurück.
   • [Step 4]: Tester verifiziert den Status lokal (Erfolg erwartet).
2. Schlüsselextraktion (Export) der erlaubten Schlüssel:
   • [Step 5]: Tester initiiert den Export des exportierbaren Schlüsselmaterials.
   • [Step 6]: CRYPTOApp01 exportiert:
     • Pfad <SecureKM1>: Verschlüsselter Export mittels <SK2> zu <SecureKM1Exported2'>.
     • Pfad <UnsecureKey1>: Direkter Export zu <UnsecureKey1Exported'>.
   • [Step 7]: CRYPTOApp01 sendet den Export-Status zurück.
   • [Step 8]: Tester verifiziert den Export-Status (Erfolg erwartet).
3. Vergleich und Verifikation (Round-Trip-Konsistenz):
   • [Step 9]: Tester übermittelt die Referenzdaten (<SecureKM1Exported2> bzw. <UnsecureKey1Exported>).
   • [Step 10]: CRYPTOApp01 führt einen Inhaltsvergleich zwischen Re-Export und Referenz durch.
   • [Step 11]: CRYPTOApp01 meldet das Vergleichsergebnis an den Tester zurück.
   • [Step 12]: Tester prüft das Ergebnis auf Übereinstimmung.
4. Negativtest: Durchsetzung von Exportbeschränkungen (Access Control):
   • Nur aktiv unter [Testing <SecureKM1>] (im Pfad <UnsecureKey1> entfällt dieser Schritt).
   • [Step 13]: Tester triggert den Export von <SecureKM1NotExportable>.
   • [Step 14]: CRYPTOApp01 versucht den Export mit <SK2>.
   • [Step 15]: Rückgabe des Fehlerstatus an den Tester.
   • [Step 16]: Tester verifiziert, dass die Operation zwingend fehlgeschlagen ist (failure expected).

4. Normative Relevanz & Entwickler-Hinweise

• Security Attribute Enforcement: Der Stack (ara::crypto Provider / Hardware Security Module / Keyslot Manager) muss sicherstellen, dass Berechtigungsflags (Export-Restriktionen) untrennbar an das importierte Schlüsselobjekt gebunden bleiben. Ein Aufruf von ExportKeySlot oder ExportKeyMaterial auf non-exportable Objekte muss zwingend mit einem definierten Fehlercode (z. B. SecurityError / Permission Denied) terminieren.
• Key Wrapping & Trust Boundaries: Beim Import/Export von geschütztem Schlüsselmaterial dürfen private/geheime Schlüssel zu keinem Zeitpunkt im Klartext außerhalb der gesicherten Umgebung (Crypto Stack / HSM / TrustZone) vorliegen. Die Bindung an die Transport-Schlüssel <SK1> und <SK2> erfordert konsistente Algorithmen-Konfigurationen (z. B. AES-Key-Wrap nach RFC 3394 oder AEAD-Envelopes).
• Deterministischer Vergleich: Bei symmetrischem Key-Wrapping muss das Serialisierungsformat deterministisch sein, damit der Vergleich in Step 10 byte-identisch evaluieren kann; bei asymmetrischem oder IV-basiertem probabilistischem Wrapping muss stattdessen die funktionale Entschlüsselbarkeit oder ein definierter MAC-Abgleich greifen.
• Test-Framework-Implementierung: CRYPTOApp01 muss als Test-Stub so implementiert sein, dass Rückgabewerte und Fehlermeldungen der AUTOSAR-Basis-APIs transparent und unverfälscht an den Test-Harness propagiert werden.