Figure 15.13: Sequence diagram of STS_CRYPTO_00014.

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML 2.x Sequenzdiagramm (sd STS_CRYPTO_00014), synchroner/asynchroner Testablauf.
• Spezifikations-Kontext: AUTOSAR Adaptive Platform (AP), Testspezifikation AUTOSAR_AP_TR_SystemTests (System Tests für Releases R21-11 bis R25-11), Testfallgruppe Kryptografie (STS_CRYPTO).
• Technischer Zweck: Spezifikation des End-to-End-Systemtestfalls STS_CRYPTO_00014 zur Verifikation des X.509-Zertifikatsmanagements (ara::crypto::x509). Er validiert:
  • Den Import und die Verarbeitung von Certificate Revocation Lists (CRL gem. RFC 5280).
  • Die Erstellung, den Export und die Auswertung von Online Certificate Status Protocol Requests und Responses (OCSP gem. RFC 6960).
  • Die hierarchische Zertifikatskettenprüfung (Root CA → Intermediate CA → End-Entity Certificate).
  • Die dynamische Aktualisierung und Persistierung eines neuen Vertrauensankers (Root of Trust / Trust Anchor) im nicht-flüchtigen Speicher (NVM) sowie dessen Auswirkung auf bestehende und nachfolgende Zertifikate.

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Lebenslinien:
  • CRYPTO Tester: Test-Harness / Test-Controller (Black-Box-/Grey-Box-Testtreiber). Injiziert Zertifikate, CRLs und OCSP-Meldungen, triggert kryptografische Operationen und assertiert Rückgabewerte.
  • CRYPTOApp01: Adaptive Application (SUT – System Under Test). Dient als Test-Adapter, der die C++-APIs des ara::crypto::x509-Subsystems konsumiert.
• Zertifikats- und Datenartefakte:
  • <RCERT1>, <RCERT2>: Root-CA-Zertifikate (Trust Anchors).
  • <IMCERT1>: Intermediate-CA-Zertifikat.
  • <EECERT1>, <EECERT2>: End-Entity-Zertifikate (Blattzertifikate / Leaf Certificates).
  • <CRL1>: Zertifikatswiderrufsliste mit Revocation-Eintrag für <RCERT1>.
  • <OCSPReq1>, <OCSPReq2>: Generierte OCSP-Anfragen für die jeweilige Zertifikatskette.
  • <OCSPResp1>, <OCSPResp2>: Simulierte OCSP-Antworten (Resp1 widerruft <RCERT1> und <EECERT1>; Resp2 widerruft <IMCERT1>).
• Schnittstellen & Methoden auf CRYPTOApp01 (Mapping auf ara::crypto::x509):
  • Import: Import von X.509-Strukturen (X509Provider::ImportX509Provider, Certificate::Import, volatile oder NVM-persistiert).
  • Verify ... chain: Validierung des Zertifikatspfads (Certificate::Verify bzw. Kettenvalidierungslogik).
  • Retrieve statuses: Abfrage des Zertifikatsstatus (Certificate::GetStatus).
  • Create / Export <OCSPReq>: Zusammenbau und Serialisierung einer OCSP-Anfrage (OCSPRequest::Create, OCSPRequest::ExportPublicly).
  • Set as root of trust: Explizite Kennzeichnung eines Zertifikats als autorisierter Trust Anchor (Certificate::SetAsRootOfTrust).

3. Dynamisches Verhalten & Sequenzablauf

Der Testfall gliedert sich in zwei sequentielle Hauptphasen über insgesamt 50 Interaktionsschritte:

Phase 1: Validierung und Revocation der Erst-Kette via CRL und OCSP (Schritte 1–21)

1. CRL-Widerruf einsteuern (Schritte 1–4):
   • CRYPTO Tester sendet <CRL1> (enthält Revocation für <RCERT1>).
   • CRYPTOApp01 importiert <CRL1> und meldet den Status zurück; Tester verifiziert den Import-Erfolg.
2. Kettenprüfung mit invalidiertem Root (Schritte 5–9):
   • Tester fordert Verifikation der Kette <RCERT1> -- <IMCERT1> -- <EECERT1> an.
   • CRYPTOApp01 prüft die Kette, fragt die Einzelstatus ab (Retrieve statuses) und liefert die Resultate zurück. Tester validiert den Fehler-/Widerrufsstatus.
3. OCSP-Request 1 erzeugen und exportieren (Schritte 10–17):
   • Trigger zur Erstellung von <OCSPReq1> auf Basis von <RCERT1>, <IMCERT1> und <EECERT1>.
   • Export des Requests aus CRYPTOApp01 an den Tester; Tester prüft die Konformität der generierten Anfrage.
4. OCSP-Response 1 verarbeiten (Schritte 18–21):
   • Tester sendet <OCSPResp1> (Widerruf von <RCERT1> und <EECERT1>).
   • CRYPTOApp01 parst die Response, aktualisiert die internen Status und meldet diese an Tester zur Verifikation.

Phase 2: Root-of-Trust-Migration auf RCERT2, Re-Validierung und Intermediate-Revocation (Schritte 22–50)

1. Neuen Vertrauensanker etablieren (Schritte 22–29):
   • Tester überträgt <RCERT2>, CRYPTOApp01 speichert dieses persistent in den nicht-flüchtigen Speicher (non-volatile storage).
   • Tester triggert Set as root of trust für <RCERT2>, CRYPTOApp01 setzt das Trust-Flag und bestätigt die Operation.
2. Zweites End-Entity-Zertifikat bereitstellen (Schritte 30–33):
   • Tester sendet <EECERT2>; CRYPTOApp01 importiert dieses in den Speicher (flüchtig/nicht-flüchtig) und bestätigt.
3. Validierung der migrierten Kette (Schritte 34–38):
   • Verifikation der Kette <RCERT2> -- <IMCERT1> -- <EECERT2>.
   • CRYPTOApp01 führt die Kettenprüfung erfolgreich gegen den neuen Trust Anchor durch und liefert die Statuswerte zurück.
4. OCSP-Request 2 generieren (Schritte 39–46):
   • Trigger zur Erstellung von <OCSPReq2> (<RCERT2>, <IMCERT1>, <EECERT2>).
   • (Hinweis Spezifikationsfehler im Originaldiagramm: Schritt 41 ist im Text fälschlich als [Step 31] beschriftet).
   • Export von <OCSPReq2> an Tester und Validierung der ASN.1/DER-Struktur.
5. Intermediate-Revocation via OCSP-Response 2 (Schritte 47–50):
   • Tester sendet <OCSPResp2> mit partiellem Widerruf nur für das Zwischenzertifikat <IMCERT1>.
   • CRYPTOApp01 extrahiert die Statusinformationen.
   • Tester prüft die Kaskadierung: Der Widerruf von <IMCERT1> invalidiert die Vertrauensstellung der gesamten Sub-Kette bis <EECERT2>.

4. Normative Relevanz & Entwickler-Hinweise

• X.509-Provider-Konformität: Implementierungen von ara::crypto::x509 müssen sicherstellen, dass sowohl Offline-Revocations (CRLs) als auch Online-Meldungen (OCSP-Responses) deterministisch in das Status-Caching von Zertifikatsobjekten einfließen.
• Kaskadierende Kettenungültigkeit: Der Widerruf einer Intermediate-CA (<IMCERT1>) muss bei nachfolgenden Prüfungen zwingend zum Abbruch der Kettenvalidierung (kInvalidChain / kCertRevoked) führen, selbst wenn das Blattzertifikat (<EECERT2>) selbst nicht als widerrufen markiert ist.
• Laufzeit-Aktualisierung des Trust-Stores: Der Stack muss APIs bereitstellen, um Root-Zertifikate zur Laufzeit atomar als vertrauenswürdig zu deklarieren (Set as root of trust) und im NVM zu sichern, ohne dass ein Neustart des Crypto-Daemons oder der Partition erforderlich ist.
• Testbarkeit & Schnittstellendesign: Für die Systemintegration ist sicherzustellen, dass Testadapter (CRYPTOApp01) OCSP-Requests serialisiert exportieren und synthetische OCSP-Responses direkt injizieren können, um Netzwerk- und Serverabhängigkeiten in hermetischen SIL/HIL-Testumgebungen zu eliminieren.