Figure 15.17: Sequence diagram of STS_CRYPTO_00018.

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (sd STS_CRYPTO_00018) gemäß AUTOSAR Adaptive Platform System Tests (AUTOSAR_AP_TR_SystemTests), Kapitel 15.
• Technischer Zweck: Spezifikation eines Integrations- und Konformitätstestfalls für den Adaptive-Crypto-Stack (ara::crypto).
• Funktionale Einordnung: Validierung des vollständigen Lebenszyklus kryptografischer Transformationskontexte (Erzeugung, Schlüsselbindung via SetKey(), Modus-Parametrierung und Metadaten-Introspektion) über die standardisierten Schnittstellen ara::crypto::cryp und ara::crypto::keys.

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Lifelines:
  • CRYPTO Tester: Test-Harness / Test-Orchestrator zur Stimulation, Parameterübergabe und Ergebnisvalidierung.
  • CRYPTOApp01: Testanwendung (System Under Test, SUT) auf der Adaptive Platform, die als Adapter auf die nativen C++-APIs des Crypto Providers zugreift.
• Kryptografische Entitäten & Typen:
  • <KeySlot1IS>: ara::core::InstanceSpecifier zur Adressierung eines persistenten oder flüchtigen KeySlots im Manifest.
  • <SK1>: Symmetrischer Schlüssel (ara::crypto::cryp::SymmetricKey).
  • <Alg1>, <Alg2>: Krypto-Algorithmus-Identifikatoren (CryptoAlgId / Algorithmenbezeichner).
  • <SymBCCtx1>: Symmetrischer Blockchiffre-Kontext (ara::crypto::cryp::SymmetricBlockCipherCtx).
  • <AuthSCCtx1>: Authentisierter Chiffre-Kontext (ara::crypto::cryp::AuthCipherCtx bzw. AuthStreamCipherCtx).
  • <StrCCtx1>: Stromchiffre-Kontext (ara::crypto::cryp::StreamCipherCtx).
  • <KeyDecPvCtx1>: Asymmetrischer Schlüsseldekapsulierungs-Kontext (ara::crypto::cryp::KeyDecapsulatorPrivateCtx).
• Inspizierte Kontextparameter & Eigenschaften:
  • Blockchiffre: BlkSize, Transform (Richtung), MaxIOnly, MaxOOnly, MaxISize, MaxOSize.
  • Auth-Chiffre: MaxDataSize, IVSize, BlkSize, ValidIVSize, ActIvLen.
  • Stromchiffre: Transform, ByteMode, SeekableMode.
  • Key-Decapsulator: KekEnt (Key Encryption Key Entropy), EncSize (Kapselungs-/Ciphertext-Größe).

3. Dynamisches Verhalten & Sequenzablauf

Der Testablauf erfolgt streng synchron in vier aufeinanderfolgenden Testphasen (40 Einzelschritte im Request-Response-Schema):

Phase 1: Symmetric Block Cipher Context (Schritte 1–15)

1. [Schritt 1–4]: Tester sendet <KeySlot1IS>. CRYPTOApp01 lädt <SK1> via Key-Management-Schnittstelle (LoadKeySlot), liefert Status zurück; Tester verifiziert Ladevorgang.
2. [Schritt 5–8]: Tester triggert Erzeugung von <SymBCCtx1> über <Alg1> aus <SK1> (CreateSymmetricBlockCipherCtx); Verifikation des Status.
3. [Schritt 9–12]: Tester triggert Zuweisung von <SK1> zu <SymBCCtx1> mit gesetztem Verschlüsselungsmodus (CryptoTransform::kEncrypt); Statusquittierung und -prüfung.
4. [Schritt 13–15]: Tester triggert Abfrage der Blockchiffre-Attribute (BlkSize, Transform, Ein-/Ausgabegrenzen); CRYPTOApp01 liest Eigenschaften aus und antwortet; Tester führt Soll-Ist-Vergleich durch.

Phase 2: Authenticated Cipher Context (Schritte 16–22)

1. [Schritt 16–19]: Tester übergibt <Alg1>. CRYPTOApp01 instanziiert <AuthSCCtx1> (CreateAuthCipherCtx); Rückgabe und Prüfung des Instanziierungsstatus.
2. [Schritt 20–22]: Abfrage und Rückgabe der Kontextparameter (MaxDataSize, IVSize, BlkSize, ValidIVSize, ActIvLen); Verifikation durch den Tester.

Phase 3: Stream Cipher Context (Schritte 23–33)

1. [Schritt 23–26]: Instanziierung von <StrCCtx1> mit <Alg1> aus <SK1> (CreateStreamCipherCtx); Statusprüfung.
2. [Schritt 27–30]: Bindung von <SK1> an <StrCCtx1> im Entschlüsselungsmodus (CryptoTransform::kDecrypt); Statusquittierung und -prüfung.
3. [Schritt 31–33]: Abfrage und Prüfung der Stromchiffre-Eigenschaften (Transform, ByteMode, SeekableMode).

Phase 4: Key Decapsulator Private Context (Schritte 34–40)

1. [Schritt 34–37]: Tester übergibt <Alg2>. Erzeugung von <KeyDecPvCtx1> (CreateKeyDecapsulatorPrivateCtx); Statusverifikation.
2. [Schritt 38–40]: Abfrage der KEM-Metadaten (KekEnt, EncSize); Rückgabe an Tester und finale Validierung.

4. Normative Relevanz & Entwickler-Hinweise

• Crypto-Stack- / Treiber-Implementierung (Crypto Provider):
  • Alle Introspektionsmethoden (GetBlockSize(), GetIvSize(), IsByteMode(), IsSeekable(), etc.) müssen auch vor Ausführung aktiver Transformationen (vor Aufruf von Start()) konsistente, normierte Werte liefern.
  • Das Setzen des Schlüssels (SetKey) muss strikt gegen die zulässigen Verwendungszwecke (KeyUsage) und die angeforderte Betriebsart (CryptoTransform::kEncrypt vs. kDecrypt) validiert werden. Bei Inkompatibilität ist der Fehler SecurityErrc::kIncompatibleObject zu werfen.
  • Hardware-gestützte Provider (HSM/SHE/Crypto-Beschleuniger) müssen Puffergrenzen (MaxISize, MaxOSize) transparent nach oben melden, um Überläufe im Schnittstellentreiber zu verhindern.
• Applikations-Entwickler:
  • Metadaten-Abfragen sind obligatorischer Bestandteil der Initialisierung, um dynamische Pufferallokationen für Ciphertexte, IVs und Tags vorab passgenau dimensionieren zu können (SecurityErrc::kInsufficientCapacity vermeiden).
  • Zugriff auf <KeySlot1IS> erfordert ein korrekt konfiguriertes Execution- und Machine-Manifest mit definierten Zugriffsrechten (CryptoKeySlot / CryptoProviderInterfaceGrant).