Figure 9.124: 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 Plattform- und Sicherheitsdiensten der AUTOSAR Adaptive Platform (AP): dem Intrusion Detection System Manager (IdsM), dem FC Cryptography sowie dem FC Execution Management (EM).
• Systemkontext: Definiert die Sicherheits- und Prozessarchitektur für diagnosebezogene Operationen auf dem POSIX-System. DM agiert als Service-Konsument (Client) für Security Event Reporting (Angriffserkennung/Auditierung), kryptografische Primitive (Authentifizierung, Integritätsprüfungen, Signatur- und Zertifikatsvalidierung) sowie für die Meldung des eigenen Prozessausführungszustands an die Plattform-Laufzeitsteuerung.

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, CryptoStack und ExecutionClient.
• «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.
• «aapAPI, aapNativeInterface» ExecutionClient:
  • Standardisierte native C++ API (ara::exec::ExecutionClient) zur Prozesssteuerung und Lebenszyklusmeldung.
  • Operationen:
    • + Create(): Fabrikmethode zur Initialisierung und Instanziierung des Ausführungs-Clients.
    • + ReportExecutionState(ExecutionState): Übermittlung von Zustandswechseln (z. B. kRunning, kTerminating) an das Execution Management.
  • Wird durch den FC Execution Management via Interface-Realisierung (--▷) bereitgestellt.
• «aapFunctionalCluster» Execution Management (daemon-based):
  • Zentraler System-Daemon zur Initialisierung, Überwachung und Steuerung des Lebenszyklus aller Plattform- und Applikationsprozesse auf der Adaptive Machine.

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.
• Pfad 3: Prozesslebenszyklus- und Zustandsmeldung (ExecutionClient)
  • Auslöser: Start und Initialisierungssequenz des Diagnostic Management Daemons durch das Betriebssystem bzw. Execution Management.
  • Ablauf:
    1. Nach dem Prozessstart erzeugt DM über Create() eine Instanz des ExecutionClient.
    2. Nach erfolgreichem Aufbau der Diagnoseprotokoll-Sockets und interner Krypto-/IdsM-Initialisierung ruft DM ReportExecutionState(ExecutionState::kRunning) auf.
    3. Execution Management empfängt den Zustand und deklariert den DM-Dienst als betriebsbereit.
    4. Beim kontrollierten Herunterfahren (Shutdown/State Transition) meldet DM analog ExecutionState::kTerminating.

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.
  • Die Lebenszyklusverwaltung erfordert die Einbindung von ara::exec::ExecutionClient; der DM-Prozess darf den Zustand kRunning erst melden, wenn alle sicherheitskritischen Initialisierungen (Krypto-Provider geladen, IdsM-Port verbunden) abgeschlossen sind.
• 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.
  • Execution-Manifest: Für den Prozess Diagnostic Management muss reportingBehavior = reportsExecutionState konfiguriert sein, damit Execution Management den Startup-Watchdog auf die Rückmeldung via ReportExecutionState() synchronisiert.
  • 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/EM/Crypto bei Diagnose-Timeouts (z. B. P2/P2*-Timer nach ISO 14229-2) einkalkuliert werden; zeitkritische Operationen nutzen die lokalen Bibliotheksanteile der als «aapNativeInterface» ausgeprägten APIs (CryptoStack, ExecutionClient).