Figure 9.66: X.509 Certificate Handling Interfaces

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm / Schnittstellenspezifikation gemäß AUTOSAR Adaptive Platform UML-Profil (AUTOSAR_EXP_SWArchitecture, R21-11).
• Architektur-Kontext: Dargestellt ist das Subsystem für X.509-Zertifikatshandling innerhalb des Functional Clusters (FC) Cryptography (ara::crypto::x509).
• Funktionaler Zweck: Trennung zwischen den zentralen kryptografischen Verwaltungs- und Validierungsdiensten (Public Key Infrastructure, Certificate Life Cycle, CRL, OCSP) im daemon-basierten Krypto-Stack und der anwendungsspezifischen Dekodierung proprietärer X.509v3-Zertifikatserweiterungen über ein SAX-/Visitor-Callback-Muster.

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Stereotypen

• Adaptive Application («component»):
  • POSIX-Anwendungsprozess auf der Adaptive Platform.
  • Agiert als Client von Zertifikatsdiensten und als Implementierer anwendungsspezifischer Parser-Logik.
• Cryptography («aapFunctionalCluster», Ausprägung: daemon-based):
  • Plattform-Basisdienst der Adaptive Platform zur Bereitstellung kryptografischer Operationen, Schlüsselspeicher und Trust-Anchor-Verwaltung.
  • Läuft isoliert als System-Daemon mit IPC-Bindeglied.
• X509Provider («aapAPI, aapNativeInterface»):
  • C++ Interface (ara::crypto::x509::X509Provider) für die vollständige Lebenszyklusverwaltung und Validierung von X.509-Artefakten.
  • Methoden-Gruppierung:
    • Distinguished Name (DN): BuildDn(), CreateEmptyDn(), DecodeDn(), FindCertByDn()
    • Zertifikats-Lookup & -Lifecycle: FindCertByKeyIds(), FindCertBySn(), LoadCertificate(), Import(), Remove(), SetAsRootOfTrust(), SetPendingStatus(), CleanupVolatileStorage()
    • Parsing & Dekodierung: ParseCert(), ParseCertChain(), ParseCertSignRequest(), ParseCustomCertExtensions(), ParseOcspResponse(), CountCertsInChain()
    • Verifikation: VerifyCert(), VerifyCertChain()
    • Sperrprüfung (CRL / OCSP): CheckCertStatus(), CheckCertStatusOnline(), ImportCrl(), UpdateCrlOnline(), CreateOcspRequest(), SendRequest()
    • Erstellung: CreateCertSignRequest(), CreateEmptyExtensions()
• X509CustomExtensionsParser («aapAPI, aapNativeInterface»):
  • C++ Callback-Interface (ara::crypto::x509::X509CustomExtensionsParser) zur ereignisgesteuerten Verarbeitung von ASN.1-DER-kodierten Erweiterungen.
  • Primitive ASN.1-Handler: OnBitString(), OnBool(), OnGeneralizedTime(), OnIa5String(), OnInteger(), OnNull(), OnOctetString(), OnOid(), OnPrintableString(), OnUtcTime(), OnUtf8String()
  • Strukturierte ASN.1-Handler: OnSequenceStart(), OnSequenceEnd(), OnSetStart(), OnSetEnd()
  • Ablaufsteuerung: OnParsingEnd()

Beziehungen & Kardinalitäten

• Adaptive Application → X509Provider («use»): Gerichtete Verwendungsabhängigkeit. Die Applikation konsumiert Zertifikats- und PKI-Funktionen.
• Cryptography → X509Provider (Interface Realization): Der Krypto-Daemon implementiert das native Interface X509Provider (gestrichelte Linie mit geschlossener, nicht ausgefüllter Dreiecksspitze).
• Adaptive Application → X509CustomExtensionsParser (Interface Realization): Die Applikation implementiert das Callback-Interface zur Verarbeitung proprietärer OIDs (gestrichelte Linie mit geschlossener Dreiecksspitze).
• Cryptography → X509CustomExtensionsParser («use»): Inversion of Control (IoC). Der Daemon bzw. die Parsing-Engine ruft die Callbacks der Applikation auf, sobald eine benutzerdefinierte Extension geparst wird.

3. Dynamisches Verhalten & Sequenzablauf

1. Standard-Zertifikatsvalidierung & Verwaltung (Synchron / Asynchron)

1. Initialisierung/Import: Adaptive Application lädt Zertifikate (LoadCertificate(), Import()) oder CRLs (ImportCrl()).
2. Kettenprüfung: Aufruf von VerifyCert() oder VerifyCertChain().
3. Revocation-Check:
   • Lokal: CheckCertStatus() via gecachter CRLs.
   • Online: Asynchron über CheckCertStatusOnline() bzw. UpdateCrlOnline() / CreateOcspRequest() und SendRequest(). Rückgabe erfolgt in der Adaptive Platform über ara::core::Future/ara::core::Result.

2. Callback-basiertes Parsing benutzerdefinierter Erweiterungen (IoC)

1. Trigger: Adaptive Application instanziiert ein Objekt, das X509CustomExtensionsParser implementiert, und übergibt die Referenz an X509Provider::ParseCustomCertExtensions().
2. Traversierung: Die ASN.1-Engine der Krypto-Komponente traversiert den DER-Byte-Stream der X.509v3-Extension hierarchisch:
   • Start von Konstrukten: OnSequenceStart(), OnSetStart().
   • Blattknoten: Aufruf des typadäquaten Callbacks mit Payload und Längeninformation (z. B. OnOid(), OnOctetString(), OnInteger()).
   • Ende von Konstrukten: OnSequenceEnd(), OnSetEnd().
3. Abschluss: Aufruf von OnParsingEnd() nach Erreichen des Stream-Endes. Bei Parser- oder Syntaxfehlern bricht der Durchlauf mit einem entsprechenden ara::core::ErrorCode ab.

4. Normative Relevanz & Entwickler-Hinweise

• API-Standard: Gemäß AUTOSAR_SWS_Cryptography liegt die Implementierung im Namespace ara::crypto::x509.
• Inversion-of-Control & Thread-Safety:
  • Die Methoden von X509CustomExtensionsParser werden synchron im Ausführungskontext des Parsers aufgerufen.
  • Die Callbacks müssen strikt non-blocking implementiert werden und dürfen keine reentranten Aufrufe auf dieselbe X509Provider-Instanz durchführen (Deadlock-Gefahr bei Daemon-IPC).
• Speicher- und Ressourcenmanagement:
  • Das Parsing erfolgt streaming-basiert (SAX-Prinzip), wodurch Allokationen großer Zwischenbäume auf dem Heap vermieden werden (essentiell für ASIL-konforme Embedded-Systeme).
  • Nach Abschluss flüchtiger Operationen ist CleanupVolatileStorage() aufzurufen, um sensitive Schlüssel- und Zertifikatsfragmente im flüchtigen RAM sicher zu nullen/bereinigen.
• Prozessgrenzen & IPC:
  • Da Cryptography als daemon-based deklariert ist, kapselt der X509Provider Proxy/Skeleton-IPC-Aufrufe. Methoden wie SendRequest() und CheckCertStatusOnline() beanspruchen Netzwerk-Sockets und erfordern passende SE-Linux-/IAM-Berechtigungen (Identity and Access Management) im Deployment-Manifest der Adaptive Application.