Figure 15.8: Sequence diagram of STS_CRYPTO_00009.

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm (sd STS_CRYPTO_00009).
• Spezifikation: AUTOSAR Adaptive Platform System Tests (AUTOSAR_AP_TR_SystemTests), gültig für R20-11 bis R25-11.
• Architektur-Kontext & Zweck: Formaler Systemtestfall zur Verifikation der Anforderung RS_CRYPTO_02104 („Restriction of Key and Seed Usage“). Das Diagramm spezifiziert das Soll-Verhalten des Adaptive Crypto Stacks (ara::crypto) bei der Durchsetzung konfigurierter Verwendungsbeschränkungen (AllowedUsageFlags) für kryptographische Schlüssel (Key) und Seeds (Seed) über einen Positiv- und Negativtestpfad.

2. Komponenten, Entitäten & Schnittstellen

• Lebenslinien / Akteure:
  • CRYPTO Tester: Test-Harness / Orchestrator zur Injektion von Konfigurationen, Testvektoren und Triggern sowie zur Verifikation von Zwischen- und Endergebnissen.
  • CRYPTOApp01: System Under Test (SUT) – Adaptive Application, welche die APIs des Crypto Stacks (ara::crypto::keys, ara::crypto::cryp) instanziiert und ausführt.
• Parameter & Datenentitäten:
  • <AllowedUsageFlags1>: Soll-Bitmaske der erlaubten Operationen (z. B. Encryption, Decryption, Signature, Verification, Derivation, Export).
  • <AllowedUsageFlags1'>: Tatsächlich vom Crypto Stack aus dem Key-Slot/Objekt-Header persistierte bzw. ausgelesene Verwendungsflags.
  • <Key1> / <Seed1>: Zielobjekt im Key Storage (ara::crypto::keys::KeySlot bzw. flüchtiges Krypto-Objekt).
  • <Usage1>: Erlaubte kryptographische Operation, die durch <AllowedUsageFlags1> explizit autorisiert ist.
  • <Usage2>: Nicht autorisierte Operation (Disallowed Usage), die durch <AllowedUsageFlags1> verboten ist.
  • <Result1>, <Result1'>: Soll- und Ist-Ergebnis der kryptographischen Berechnung (z. B. Ciphertext, MAC, Signatur).

3. Dynamisches Verhalten & Sequenzablauf

Der Ablauf gliedert sich in vier synchrone Testphasen:

1. Konfigurationsabgleich (Steps 1–4):
   • Step 1: CRYPTO Tester sendet <AllowedUsageFlags1> an CRYPTOApp01.
   • Step 2: CRYPTOApp01 liest <AllowedUsageFlags1'> aus dem Crypto Stack und vergleicht diese mit den Soll-Flags.
   • Step 3 & 4: Rückmeldung (matched/unmatched) an den Tester; Bestätigung der korrekten Attribut-Initialisierung.
2. Positivtest – Autorisierte Operation (Steps 5–8):
   • Step 5: Tester triggert erlaubte Operation <Usage1> auf <Key1> / <Seed1>.
   • Step 6: CRYPTOApp01 führt <Usage1> über den Crypto Stack aus.
   • Step 7 & 8: Rückgabe und Prüfung des Ausführungsstatus (success erwartet).
3. Ergebnisvalidierung (Steps 9–12):
   • Step 9: Tester übermittelt Referenzdaten <Result1>.
   • Step 10: CRYPTOApp01 führt byteweisen Abgleich mit dem lokal berechneten <Result1'> durch.
   • Step 11 & 12: Rückgabe des Vergleichsstatus (matched/unmatched) an den Tester.
4. Negativtest – Restriktionsdurchsetzung (Steps 13–16):
   • Step 13: Tester triggert unzulässige Operation <Usage2> auf <Key1> / <Seed1>.
   • Step 14: CRYPTOApp01 versucht die Ausführung über den Stack.
   • Step 15 & 16: Der Crypto Stack muss die Operation abweisen. Rückmeldung und Prüfung des Fehlerstatus (Erwartungswert: kontrollierter Abbruch/Fehlercode).

4. Normative Relevanz & Entwickler-Hinweise

• Crypto-Stack- / Provider-Implementierung (ara::crypto):
  • Vor jeder Krypto-Operation (z. B. in Kontexten wie EncryptorPublicCtx, SignerPrivateCtx, KeyDerivationFunctionCtx) muss der Provider die Flags des gebundenen Schlüssels (KeySlot::GetAllowedUsage()) gegen die angeforderte Operation prüfen.
  • Bei Nichtübereinstimmung (Usage2) ist die Ausführung zwingend zu verweigern und ein normativer Fehlercode zurückzugeben (in der Regel ara::crypto::SecurityErrc::kAccessViolation oder kIncompatibleObject). Ein Ausführen oder Fallback ist unzulässig.
• Applikations-Entwicklung & Manifest-Konfiguration:
  • Schlüssel- und Seed-Definitionen im Execution Manifest (CryptoKeySlot.allowedUsage) müssen minimal und auf den konkreten Einsatzzweck beschränkt projektiert werden (Principle of Least Privilege).
  • Applikationen müssen darauf ausgelegt sein, dass Krypto-Aufrufe bei verletzter Nutzungseinschränkung deterministisch fehlschlagen; eine Mehrfachnutzung desselben Schlüssels für inkompatible Primitive (z. B. Signieren und Verschlüsseln) wird durch den Stack aktiv unterbunden.