Figure 9.108: Security-related Interfaces required by Diagnostic Management

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Schnittstellen- und Komponentendiagramm (AUTOSAR Adaptive Platform Architecture Meta-Model, Stereotypen-Profil «aap*»).
• Technischer Zweck: Spezifikation der normativen Abhängigkeiten des Functional Clusters (FC) Diagnostic Management (DM) zu den zentralen Sicherheitsdiensten der AUTOSAR Adaptive Platform (AP): dem Intrusion Detection System Manager (IdsM) und dem FC Cryptography.
• Systemkontext: Definiert die Sicherheitsarchitektur für diagnosebezogene Operationen auf dem POSIX-System. DM agiert als Service-Konsument (Client) für Security Event Reporting (Angriffserkennung/Auditierung) und kryptografische Primitive (Authentifizierung, Integritätsprüfungen, Signatur- und Zertifikatsvalidierung).

2. Komponenten, Entitäten & Schnittstellen

• «aapFunctionalCluster» Diagnostic Management (daemon-based):
  • Repräsentiert den Plattform-Dienst zur Handhabung von Diagnoseprotokollen (UDS ISO 14229-1 via DoIP ISO 13400-2).
  • Realisiert als eigenständiger POSIX-Daemon-Prozess.
  • Hält ausgehende Nutzungsbeziehungen («use») zu den Schnittstellen EventReporter und CryptoStack.
• «aapPortInterface, aapAPI» EventReporter:
  • Service- und Schnittstellendefinition zur Ereignismeldung.
  • Kombiniert ein dienstorientiertes Port-Interface («aapPortInterface») mit einer standardisierten C++ API («aapAPI»).
  • Operation: + ReportEvent() zur Weitergabe erkannter Sicherheitsanomalien.
  • Wird durch den FC Intrusion Detection System Manager via Interface-Realisierung (--▷) bereitgestellt.
• «aapFunctionalCluster» Intrusion Detection System Manager (daemon-based):
  • Sicherheits-Daemon zur systemweiten Erfassung, Filterung, Ratenbegrenzung und Aggregation von Security Events (SEv) zu qualifizierten Security Events (QSEv).
• «aapAPI, aapNativeInterface» CryptoStack:
  • Abstrakte Schnittstellendefinition der kryptografischen Plattformtreiber und -bibliotheken (ara::crypto).
  • Ausprägung als «aapNativeInterface» impliziert direkte native Sprachbindungen (C++ Dynamic Link / Shared Library) zur Vermeidung von IPC-Overhead bei datenintensiven Krypto-Operationen, kombiniert mit Standard-API-Definitionen («aapAPI»).
  • Wird durch den FC Cryptography via Interface-Realisierung (--▷) implementiert.
• «aapFunctionalCluster» Cryptography (daemon-based):
  • Plattform-Dienst für Schlüsselverwaltung, Isolation privater Schlüssel (Key Storage Manager, HSM/TPM-Anbindung) und Ausführung kryptografischer Algorithmen.

3. Dynamisches Verhalten & Sequenzablauf

• Pfad 1: Kryptografische Verifikation (CryptoStack)
  • Auslöser: Eintreffen einer gesicherten Diagnose-Anforderung (z. B. UDS Service 0x29 Authentication, Service 0x27 SecurityAccess via Challenge-Response oder TLS-Verbindungsaufbau im DoIP).
  • Ablauf:
    1. DM ruft synchron oder via ara::core::Future asynchron die Methoden des CryptoStack (ara::crypto::cryp, ara::crypto::keys) auf.
    2. Der Krypto-Dienst führt Zertifikatsprüfung (X.509-Validierung gegen hinterlegte Trust Anchors) oder Signatur-/MAC-Verifikation durch.
    3. Rückmeldung an DM via ara::core::Result<T>. Bei Erfolg erfolgt der Übergang in den autorisierten Diagnose-Sicherheitszustand.
• Pfad 2: Sicherheitsvorfall-Meldung (EventReporter)
  • Auslöser: Fehlerzustände mit Security-Relevanz im DM (z. B. wiederholt ungültige SecurityAccess-Keys, Zertifikats-Widerrufe, PDU-Spoofing, DoIP-Routing-Activation-Anomalien).
  • Ablauf:
    1. DM verpackt Event-ID, Kontext-Informationen (Sender-IP, Zeitstempel, Target Address) und Schweregrad.
    2. Nicht-blockierender Aufruf von ReportEvent() über den EventReporter-Port an den IdsM-Daemon.
    3. IdsM verarbeitet das Event asynchron, filtert nach Plattform-Regelwerk und persistiert/überträgt es an das Backend/SOC.

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag & Kapselung:
  • DM darf keine proprietären oder direkt integrierten Drittanbieter-Krypto-Bibliotheken nutzen. Alle Operationen müssen über die normierten Schnittstellen des CryptoStack laufen, um Hardware-Sicherheitsanker (HSM, SHE, TPM) konsistent einzubinden.
  • Das Security-Monitoring ist zwingend über EventReporter::ReportEvent() zu bedienen; direkte Syslog- oder Dem-Einträge für Security-Vorfälle verletzen die AUTOSAR-Security-Architektur.
• Deployment & Manifest-Konfiguration:
  • Port-Mapping: Im AUTOSAR-Modell (ARXML) muss das DM-Design einen Required Port (R-Port) vom Typ EventReporter definieren und diesen via Service-Instance-Manifest an den Provided Port (P-Port) des IdsM binden.
  • KeySlot-Allokation: Im Machine- und Execution-Manifest müssen dem Prozess Diagnostic Management explizite Zugriffsrechte (Access Rules) auf die benötigten CryptoKeySlots und CryptoProvider zugeordnet sein.
• Laufzeit-Performance:
  • Durch den Vermerk daemon-based für alle beteiligten Cluster muss die IPC-Latenz zwischen DM und IdsM/Crypto bei Diagnose-Timeouts (z. B. P2/P2*-Timer nach ISO 14229-2) einkalkuliert werden; zeitkritische Operationen nutzen die lokalen Bibliotheksanteile des «aapNativeInterface».