Figure 15.9: Sequence diagram of STS_CRYPTO_00010.

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (sd STS_CRYPTO_00010) aus der AUTOSAR Adaptive Platform Test-Spezifikation (AUTOSAR_AP_TR_SystemTests).
• Architektur-Kontext: System-Integrationstestfall (STS) zur funktionalen Konformitätsprüfung des Adaptive Crypto-Stacks (ara::crypto).
• Technischer Zweck: Verifikation der asymmetrischen Schlüsselvereinbarung (Diffie-Hellman / ECDH) via AgreeKey() sowie der anschließenden operativen Verwendbarkeit des resultierenden symmetrischen Schlüssels (<SK1>) gemäß konfigurierter Nutzungsbeschränkungen (<Usage1>) durch Bit-genauen Ergebnisabgleich mit einem Referenzwert.

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Lifelines:
  • CRYPTO Tester: Test-Harness / Testmaster; steuert die Testsequenz, hält Referenzvektoren und prüft Status- und Vergleichsergebnisse.
  • CRYPTOApp01: Adaptive Application (System under Test, SUT); konsumiert die standardisierte ara::crypto-C++-Schnittstelle.
• Schnittstellen & APIs:
  • ara::crypto::cryp::KeyAgreementPrivateCtx::AgreeKey(): API-Aufruf zur Ableitung/Berechnung des gemeinsamen Geheimnisses bzw. symmetrischen Schlüssels <SK1> unter Verwendung des öffentlichen Schlüssels der Gegenstelle (<TDHPbK1>).
  • Inter-Process / Test Interface: Nachrichtenbasierte Trigger-, Status- und Datenübergaben (Step 1, 3, 5, 7, 9, 11) zwischen Tester und Applikation (z. B. via ara::com / SOME/IP oder dedizierten Test-IPC).
• Datenstrukturen & Entitäten:
  • <TDHPbK1>: Target/Test Diffie-Hellman Public Key (ara::crypto::cryp::PublicKey).
  • <SK1>: Vereinbarter symmetrischer Schlüssel (ara::crypto::cryp::SymmetricKey).
  • <Usage1>: Autorisierte kryptographische Operation (definiert über AllowedKeyUsageFlags, z. B. AES-Verschlüsselung oder MAC-Generierung).
  • <Result1>: Vom Tester unabhängig berechneter Referenzwert (Sollwert).
  • <Result1'>: Von CRYPTOApp01 via <SK1> berechneter Istwert.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung & Key Agreement (Schritte 1–4):
   • Step 1: CRYPTO Tester sendet Trigger zur Durchführung des DH/ECDH Key Agreements an CRYPTOApp01.
   • Step 2: CRYPTOApp01 ruft lokal synchron AgreeKey() mit <TDHPbK1> auf; ara::crypto generiert das Schlüsselobjekt <SK1>.
   • Step 3 & 4: CRYPTOApp01 gibt den Status (success/failure) an den Tester zurück; Tester evaluiert die erfolgreiche Ausführung.
2. Kryptographische Nutzungsphase (Schritte 5–8):
   • Step 5: Tester triggert eine spezifikationsgemäße Operation <Usage1> unter Verwendung von <SK1>.
   • Step 6: CRYPTOApp01 führt <Usage1> über den entsprechenden Krypto-Kontext (z. B. EncryptorPublicCtx oder MessageAuthnCodeCtx) aus und erhält <Result1'>.
   • Step 7 & 8: CRYPTOApp01 meldet den Ausführungsstatus zurück; Tester validiert diesen.
3. Verifikation & Testabschluss (Schritte 9–12):
   • Step 9: Tester übermittelt seinen Referenzwert <Result1> an CRYPTOApp01.
   • Step 10: CRYPTOApp01 führt einen In-Memory-Vergleich zwischen <Result1'> und <Result1> durch.
   • Step 11 & 12: CRYPTOApp01 meldet das Vergleichsergebnis (matched/unmatched) an den Tester; Tester prüft auf matched als Pass-Kriterium für den Testfall STS_CRYPTO_00010.

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag (ara::crypto):
  • Die Implementierung von AgreeKey() muss die Vorgaben von RS_CRYPTO_02007 und RS_CRYPTO_02102 erfüllen. Das Schlüsselmaterial darf zu keinem Zeitpunkt im Klartext in den Userspace exponiert werden, sondern muss gekapselt als CryptoObject bzw. im HSM/CryptoProvider verbleiben.
  • Das aus AgreeKey() resultierende Objekt muss strikt die im Kontext definierten Nutzungsflags (AllowedKeyUsageFlags gem. RS_CRYPTO_02105) erben, sodass der Schlüssel ausschließlich für <Usage1> freigegeben ist.
• Fehler- und Ausnahmenbehandlung:
  • Methoden müssen ara::core::Result zurückgeben. Inkompatible Kurven-Parameter oder ungültige Schlüsselformate in <TDHPbK1> müssen deterministisch zu Krypto-Fehlercodes führen (z. B. SecurityErrorDomain::kIncompatibleObject, kBadObjectSize).
• Black-Box-Teststrategie für Entwickler:
  • Da sichere Krypto-Stacks den direkten Export von Schlüsseln verweigern (kAllowExport = false), weist dieser Testfall die Korrektheit des DH/ECDH-Ablaufs indirekt über den funktionellen Folgeaufruf (<Usage1>) und den anschließenden Nutzdaten-Abgleich nach.