Figure 15.12: Sequence diagram of STS_CRYPTO_00013.

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (sd STS_CRYPTO_00013) gemäß System-Test-Spezifikation (AUTOSAR_AP_TR_SystemTests).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Functional Cluster Cryptography (ara::crypto).
• Technischer Zweck: Spezifikation eines End-to-End-Systemtestfalls zur Verifikation des X.509-PKI- und Zertifikats-Lebenszyklus-Managements über die APIs ara::crypto::x509 und ara::crypto::keys. Der Ablauf validiert CSR-Erzeugung, Statusübergänge, Parsing, mehrstufige Zertifikatsketten-Validierung, persistente Ablage sowie das deterministische Löschverhalten.

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Lifelines:
  • CRYPTO Tester: Testumgebung / Test-Harness (simuliert Gegenstelle, CA und Testautomatisierungs-Logik).
  • CRYPTOApp01: System Under Test (SUT) – Adaptive Application mit Instanzierung des AP Crypto Stacks.
• Kryptografische Objekte & Parameter:
  • <DN1>: X.509 Distinguished Name (ara::crypto::x509::X509DN).
  • <APbK1> / <APvK1>: Asymmetrisches Schlüsselpaar (Public Key / Private Key, ara::crypto::cryp::PublicKey / PrivateKey).
  • <CSR1>: Certificate Signing Request (PKCS#10 / ara::crypto::x509::CertSignRequest).
  • <RCERT1>: Root-CA-Zertifikat (Trust Anchor im lokalen Speicher).
  • <IMCERT1>: Intermediate-CA-Zertifikat.
  • <EECERT1>: End-Entity-Zertifikat (Leaf-Zertifikat).
  • <TPbK1>: Target Public Key (aus <EECERT1> extrahierter öffentlicher Schlüssel).
  • (non-)volatile storage: Schlüssel- und Zertifikatsspeicher (ara::crypto::keys::KeyStorageProvider).
• Schnittstellen & Interaktionsmuster:
  • Synchrones Request-Response-Muster via Test-IPC/RPC zwischen CRYPTO Tester und CRYPTOApp01.
  • Methodenaufrufe an ara::crypto::x509::X509Provider, ara::crypto::x509::Certificate und ara::crypto::keys::KeyStorageProvider.

3. Dynamisches Verhalten & Sequenzablauf

Der Testfall läuft in 46 sequenziellen Einzelschritten über 6 funktionale Phasen ab:

1. CSR-Generierung & Export (Schritte 1–9):
   • Tester triggert CSR-Erstellung; CRYPTOApp01 signiert <CSR1> intern mit <APvK1> unter Verwendung von <DN1> und <APbK1>.
   • Tester fragt Status ab, triggert den Export und prüft das gelieferte CSR-Datenformat auf syntaktische Korrektheit.
2. Statusübergang CSR (Schritte 10–13):
   • Tester setzt den CSR-Status explizit auf "Pending" (Zertifikatsanforderung in Bearbeitung bei CA). Quittierung und Verifikation durch Tester.
3. Parsing & 2-stufige Kettenvalidierung (Schritte 14–22):
   • Tester injiziert <EECERT1>. CRYPTOApp01 parst das Zertifikat.
   • Verifikation der Zertifikatskette <RCERT1> -> <EECERT1> (Root direkt zu End-Entity). Rückgabe und Prüfung des Ketten- sowie Einzelzertifikatsstatus.
4. Persistierung des End-Entity-Zertifikats (Schritte 23–26):
   • Import von <EECERT1> in den (nicht-)flüchtigen Speicher via KeyStorageProvider. Statusprüfung.
5. Erweiterte 3-stufige Kettenvalidierung (Schritte 27–34):
   • Tester injiziert <IMCERT1>. CRYPTOApp01 parst dieses und validiert die 3-stufige Vertrauenskette <RCERT1> -> <IMCERT1> -> <EECERT1>. Tester verifiziert erfolgreichen Validierungsstatus.
6. Export, Integritätscheck & Deprovisionierung (Schritte 35–46):
   • Laden und Exportieren von <EECERT1> aus dem Speicher. Tester verifiziert das Zertifikat gegen den enthaltenen <TPbK1>.
   • Löschung (Remove) von <EECERT1> aus dem Speicher.
   • Negativtest / Dangling-Pointer-Prüfung: Erneuter Ladeversuch (Load) auf <EECERT1>; CRYPTOApp01 muss zwingend nullptr (bzw. einen Null-Handle/Fehlercode) zurückgeben; Tester validiert dieses Ergebnis in Schritt 46.

4. Normative Relevanz & Entwickler-Hinweise

• API-Konformität (ara::crypto):
  • Der Stack-Treiber muss RFC 5280-konforme Pfadvalidierung sowohl für direkte Vertrauensbeziehungen (Root -> Leaf) als auch für hierarchische Pfade mit Zwischenzertifikaten (Root -> Intermediate -> Leaf) beherrschen.
  • Das Setzen und Abfragen des transienten Zustands "Pending" an CertSignRequest-Objekten muss unterstützt werden.
• Speicher- und Key-Storage-Semantik:
  • Nach Ausführung von Remove() im KeyStorageProvider darf die Entität nicht mehr adressierbar sein. Aufrufe wie LoadCertificate() müssen deterministisch fehlschlagen bzw. nullptr / CryptoErrc::kDoesNotExist liefern.
  • Implementierer müssen sicherstellen, dass bei Entzug oder Löschung keine verwaisten Handles oder ungesperrten flüchtigen Kopien im RAM verbleiben.
• Test-Implementierung:
  • Die Sequenz dient als Konformitätskriterium für OEM-/Tier-1-Abnahmetests von Adaptive-Core-Stacks bezüglich Key-Management und X.509-Zertifikats-Handling.