Figure 15.16: Sequence diagram of STS_CRYPTO_00017.

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (sd STS_CRYPTO_00017) gemäß AUTOSAR Adaptive Platform Test-Spezifikation (AUTOSAR_AP_TR_SystemTests).
• Technischer Zweck: Blackbox-/System-Testfall-Spezifikation zur Verifikation der AUTOSAR Adaptive Crypto API (ara::crypto). Geprüft werden das Laden eines asymmetrischen privaten Schlüssels aus einem Key-Slot, die Instanziierung und Parametrierung eines Signatur-Kontexts (ara::crypto::cryp::SignerPrivateCtx), die Assoziation des Schlüssels mit dem Kontext sowie der vollständige Lifecycle eines Hash-Kontexts (ara::crypto::cryp::HashFunctionCtx: Initialisierung, Start, Update, Finish und Zustandskontrollen).

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Lifelines:
  • CRYPTO Tester: Test-Harness / Test-Orchestrator (treibt die Testschritte, validiert Rückgabewerte und Kontextzustände via ODD-/Test-Schnittstelle).
  • CRYPTOApp01: AUTOSAR Adaptive Application (SUT – System Under Test), welche die ara::crypto-Plattform-APIs nativ konsumiert.
• Krypto-Objekte & Datenstrukturen:
  • <KeySlot1IS>: Key-Slot Instance Specifier (ara::crypto::keys::KeySlot).
  • <APvK1>: Asymmetric Private Key (ara::crypto::cryp::PrivateKey).
    • Attribute: Payload (<APvK1Payload>), Algorithmen-ID (<APvK1AlgId>).
  • <SigPvCtx1>: Signer Private Context (ara::crypto::cryp::SignerPrivateCtx).
    • Attribute/Properties: <SigPvCtx1ReqHashSize>, <SigPvCtx1ReqHashAlgId>, <SigPvCtx1SigSize>, <SigPvCtx1Init>, <SigPvCtx1ActKeyLen>, <SigPvCtx1KeyUID>, <SigPvCtx1KeyAvailable>, <SigPvCtx1MinKeyLen>, <SigPvCtx1MaxKeyLen>, <SigPvCtx1KeyLenSupport>.
  • <HFCtx1>: Hash Function Context (ara::crypto::cryp::HashFunctionCtx).
    • Attribute: Digest-Größe (<HFCtx1DigestSize>), Zustands-Flags (<HFCtx1Started>, <HFCtx1Finished>).
  • <AlgId2>: Crypto Algorithm Identifier (spezifiziert den Hash-Algorithmus, z. B. SHA-256 / SHA-3).

3. Dynamisches Verhalten & Sequenzablauf

Der Ablauf gliedert sich in 5 synchrone Testphasen über 45 Einzelschritte:

1. Phase 1: Laden und Verifizieren des asymmetrischen Schlüssels (Schritte 1–7)
   • CRYPTO Tester sendet <KeySlot1IS> an CRYPTOApp01 ([Step 1]).
   • CRYPTOApp01 lädt den privaten Schlüssel <APvK1> via Key-Storage-Provider ([Step 2]) und meldet den Lade-Status zurück ([Step 3]).
   • Statusprüfung durch Tester ([Step 4]).
   • Abfrage und Rückgabe von Payload und Algorithmen-ID des Schlüssels ([Step 5–6]) gefolgt von Inhaltsvalidierung ([Step 7]).
2. Phase 2: Erzeugung und Validierung des Signer-Kontexts (Schritte 8–17)
   • Trigger zur Erzeugung von <SigPvCtx1> ([Step 8]).
   • CRYPTOApp01 instanziiert den Kontext ([Step 9]) und gibt Status zurück ([Step 10]); Tester prüft Status ([Step 11]).
   • Abfrage statischer Metadaten: Erforderliche Hash-Größe, Hash-Algorithmus-ID und Signaturgröße ([Step 12–13]) mit anschließender Prüfung ([Step 14]).
   • Abfrage der Schlüssel-Restriktionen und des Initialisierungsstatus vor Schlüsselzuweisung (Init=false, Key-Limits, UID) ([Step 15–16]) und Validierung ([Step 17]).
3. Phase 3: Binden des Schlüssels an den Signer-Kontext (Schritte 18–24)
   • Tester initiiert das Setzen des Schlüssels <APvK1> in <SigPvCtx1> via SetKey() ([Step 18]).
   • CRYPTOApp01 bindet den Schlüssel an den Kontext ([Step 19]) und quittiert ([Step 20–21]).
   • Erneutes Abfragen der Kontextparameter ([Step 22–23]): Verifikation, dass <SigPvCtx1Init> nun aktiv, die tatsächliche Schlüssellänge gesetzt und <SigPvCtx1KeyAvailable> wahr ist ([Step 24]).
4. Phase 4: Erzeugen und Initial-Prüfung des Hash-Kontexts (Schritte 25–31)
   • Tester übergibt <AlgId2> ([Step 25]).
   • CRYPTOApp01 instanziiert <HFCtx1> über die Crypto-Factory ([Step 26]) und meldet Status ([Step 27–28]).
   • Abfrage von Digest-Größe sowie Initialzustand der Kontrollflags (Started=false, Finished=false) ([Step 29–30]) und Validierung ([Step 31]).
5. Phase 5: Ausführung des Hash-Lebenszyklus (Start – Update – Finish) (Schritte 32–45)
   • Start: Aufruf der Start()-Methode von <HFCtx1> ([Step 32–34]); Prüfung des Call-Status ([Step 35]). Abfrage der Flags: <HFCtx1Started> muss true, <HFCtx1Finished> muss false sein ([Step 36–38]).
   • Update & Finish: Aufruf der Datenverarbeitung (Update()) und Finalisierung (Finish()) ([Step 39–41]); Prüfung der Call-Status ([Step 42]).
   • Abschlussprüfung: Abfrage der finalen Flags ([Step 43–44]): <HFCtx1Started> und <HFCtx1Finished> müssen den Zustand nach vollständiger Digest-Generierung widerspiegeln ([Step 45]).

4. Normative Relevanz & Entwickler-Hinweise

• API-Zustandsmaschine: Entwickler von ara::crypto::cryp::SignerPrivateCtx und HashFunctionCtx müssen strikte Vorbedingungen für Methodenaufrufe implementieren:
  • Vor Aufruf kryptographischer Operationen muss SetKey() erfolgreich ausgeführt werden; interne Properties (KeyAvailable, Init) müssen synchron aktualisiert werden.
  • Der HashFunctionCtx erzwingt die Reihenfolge Start() → Update() → Finish(). Aufrufe außerhalb dieser Sequenz müssen gemäß SWS mit CryptoErrc::kProcessingNotStarted bzw. CryptoErrc::kProcessingCompleted fehlschlagen.
• Konfigurations- und Slot-Bindung: Schlüssel-Metadaten (Algorithmus-Familie, Key-Length-Limits, Hash-Kompatibilität) im Key-Slot müssen exakt zu den Anforderungen des SignerPrivateCtx passen. Eine Inkompatibilität muss während SetKey() zur Laufzeit abgewiesen werden (CryptoErrc::kIncompatibleObject).
• Test-Instrumentation: Für automatisierte Systemtests (STS) muss die Applikation Schnittstellen bereitstellen, um interne Kontext-Zustände (wie Digest-Größen, Initialisierungs- und Processing-Flags) nach jedem Transformationsschritt deterministisch an den Tester zu exportieren.