Figure 5.2: Interface required by Diagnostic Management from Adaptive Intrustion Detection System Manager

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Schnittstellen- und Komponentendiagramm (AUTOSAR Adaptive Platform Functional Cluster Interaction Diagram).
• Technischer Kontext: Spezifiziert die funktionalen Schnittstellenanforderungen (required interfaces) des Functional Clusters Diagnostic Management (DM) gegenüber Nachbar-Clustern im Rahmen der Systemarchitektur (AUTOSAR_AP_EXP_SWArchitecture, Kapitel 5).
• Architektonischer Zweck: Veranschaulichung der Sicherheits- und Überwachungsanbindung des DM zur Laufzeit: Erkennung und Meldung diagnosebezogener Sicherheitsanomalien an den Intrusion Detection System Manager (IdsM) sowie Nutzung kryptografischer Primitiven zur Authentifizierung und Datenintegrität.

2. Komponenten, Entitäten & Schnittstellen

Functional Clusters (Akteure / Services)

• Diagnostic Management («aapFunctionalCluster», Tag: daemon-based):
  • Konsumenten-Rolle (Consumer / Client).
  • Verwaltet UDS- (ISO 14229) und DoIP-Kommunikation (ISO 13400) auf Plattform- und Applikationsebene.
• Intrusion Detection System Manager («aapFunctionalCluster», Tag: daemon-based):
  • Provider des Sicherheitsüberwachungs-Interfaces.
  • Sammelt, filtert und aggregiert sicherheitsrelevante Ereignisse (Security Events – SEv).
• Cryptography («aapFunctionalCluster», Tag: daemon-based):
  • Provider von Krypto-Diensten, Zertifikatsprüfungen und sicherem Schlüsselmanagement (ara::crypto).

Schnittstellen & Beziehungen

• EventReporter («aapPortInterface, aapAPI»):
  • Operation: + ReportEvent()
  • Realisierung: Intrusion Detection System Manager implementiert das Interface (UML-Realisierungspfeil - - -▷).
  • Nutzung: Diagnostic Management greift via «use»-Abhängigkeit (- - ->) darauf zu.
  • Art: Service-orientiertes Port-Interface (über Service-Infrastruktur / ara::com bzw. plattforminternes IPC).
• CryptoStack («aapAPI, aapNativeInterface»):
  • Realisierung: Cryptography stellt diese Schnittstelle bereit (UML-Realisierungspfeil - - -▷).
  • Nutzung: Diagnostic Management greift via «use»-Abhängigkeit (- - ->) darauf zu.
  • Art: Native C++-Programmierschnittstelle (ara::crypto), die über Client-Bibliotheken direkt im Prozessraum des DM instanziiert wird und mit dem Krypto-Daemon interagiert.

3. Dynamisches Verhalten & Sequenzablauf

Pfad 1: Security Event Reporting (EventReporter::ReportEvent)

1. Trigger: Auftreten einer diagnosebezogenen Sicherheitsverletzung innerhalb des DM-Daemons:
   • Fehlschlag von SecurityAccess (UDS Service 0x27) durch ungültige Keys / Brute-Force-Versuche.
   • Ungültige Zertifikate, falsche Signaturen oder abgelaufene Tokens bei Authentication (UDS Service 0x29).
   • DoIP-Routing-Activation-Verletzungen, DoS-Muster oder PDU-Längenanomalien.
2. Ablauf: DM kapselt das Vorkommnis in einen Security Event (Event-ID, Kontextdaten wie Tester-Adresse, Zeitstempel, Payload-Auszug) und setzt einen Aufruf von ReportEvent() ab.
3. Senke: Der IdsM-Daemon verarbeitet den Event gemäß konfigurierter Filter- und Qualifizierungsregeln (Qualified Security Event, QSEv) zur Persistierung oder Weiterleitung an ein Vehicle Security Operations Center (VSOC).

Pfad 2: Kryptografische Verifikation (CryptoStack)

1. Trigger: Eingehende authentifizierte Diagnoseanforderung (z. B. UDS 0x29, Secure Flash Request, TLS-Handshake über DoIP).
2. Ablauf: Synchroner Aufruf nativer ara::crypto-APIs:
   • Prüfung von X.509-Zertifikatsketten gegen Trust-Anchor-Zertifikate.
   • Asymmetrische Signaturvalidierung (ECDSA/RSA) von Challenge-Response-Tokens.
   • Generierung kryptografisch sicherer Zufallszahlen (CSPRNG) für Diagnose-Challenges.

4. Normative Relevanz & Entwickler-Hinweise

• Prozess- und Deployment-Modell:
  • Alle drei beteiligten Cluster sind als daemon-based markiert. Sie laufen als eigenständige OS-Prozesse unter Aufsicht des Execution Management (EM).
  • Inter-Cluster-Aufrufe an den IdsM bedingen IPC-Kontextwechsel. Zur Vermeidung von Performance-Engpässen und DoS auf den IdsM-Kanal muss im DM eine lokale Vorfilterung bzw. Entprellung (Rate Limiting) von ReportEvent()-Aufrufen implementiert sein.
• Manifest- und Port-Konfiguration:
  • DM-Konfiguration: Benötigt einen RPortPrototype vom Typ EventReporter im Execution Manifest / Service Instance Manifest sowie Zuweisung der konkreten Krypto-Schlüssel-Slots (KeySlots) und Krypto-Provider im Cryptography-Manifest.
  • IdsM-Konfiguration: Bereitstellung eines korrespondierenden PPortPrototype für EventReporter mit Bindung an die definierten Security Event IDs der Diagnose.
• API-Vertrag (ara::crypto vs. EventReporter):
  • CryptoStack wird als aapNativeInterface über standardisierte C++14/C++17-Header eingebunden; Schlüsselmaterial verbleibt hardwaregekapselt (HSM/SE) im Adressraum des Krypto-Daemons.
  • EventReporter ist zustandslos und darf den diagnostischen Zustandsautomaten (NRC-Generierung, UDS-Session-Handling) im Fehlerfall nicht blockieren (bevorzugt asynchrone / non-blocking Übergabe).