Figure 7.2: Interaction of the IdsM with other stack modules

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: AUTOSAR-Schichtenmodell / Modul-Interaktionsdiagramm (Blockdiagramm mit BSW-Schichtenarchitektur nach AUTOSAR Classic Platform, Release R20-11 bis R25-11).
• Technischer Zweck: Darstellung der Einbettung des Intrusion Detection System Managers (IdsM) in die AUTOSAR-Basissoftware (BSW), Klassifikation von internen/externen Sensormodulen (BSW- und Applikations-Sensoren) sowie die Identifikation der Service-, Krypto-, Kommunikations- und Speicherpfade zur Erfassung, Filterung, Persistierung und Weiterleitung von Security Events (SEv) bzw. Qualified Security Events (QSEv).

2. Komponenten, Entitäten & Schnittstellen

Zentrale Service-Instanz

• IdsM (Crypto / System Services): Zentrale Instanz zur Aggregation, Ratenbegrenzung, Filterung und Qualifizierung von Security Events (SEv zu QSEv).

Sensor-Quellen (Security Event Sources / Sensoren)

Gekennzeichnet durch das Sensor-Piktogramm (Puls-/Signallogik):

• App (Application Layer / SW-C): Applikativer Sensor. Kommunikation über den RTE via Service-Port-Interface (standardisiertes Client-Server-Interface IdsM_SecurityEventReporting mit Operation SetSecurityEvent).
• Dcm (Communication Services): Diagnosesensor (Erkennung unautorisierter Diagnosesitzungen, Security-Access-Fehlschläge) und Diagnoseinterface für IdsM.
• SecOC (Communication Services): BSW-Sensor für Kommunikationsintegrität (Authentifizierungsfehler, Freshness-Value-Mismatch, Replay-Angriffe).
• KeyM (Crypto Services): BSW-Sensor für Schlüssel- und Zertifikatsmanagement (Zertifikatsabläufe, unberechtigte Schlüsselzugriffe).
• CanIf / EthIf (Communication Services): BSW-Sensoren auf Abstraktionsebene für Busüberwachung (Framedrops, unzulässige CAN-IDs, Ethernet-Flooding, MAC/IP-Spoofing).

Unterstützende BSW-Module & Schnittstellen

• StbM (Synchronized Time-Base Manager): Unidirektionaler Input zu IdsM. Bereitstellung hochpräziser globaler Zeitstempel (StbM_GetCurrentTime) zur zeitlichen Korrelation von QSEv.
• BswM (BSW Mode Manager): Modul- und Partitionszustandssteuerung (Modusüberwachung, Initialisierung IdsM_Init, Partitionsstart/-stopp).
• Dem / Sem (Diagnostic Event Manager / Security Event Manager): Unidirektionale Meldung von Sicherheitsvorfällen (Dem_SetEventStatus), wenn QSEv Diagnosefehler/DTCs auslösen.
• NvM (Memory Services): Bidirektionale Persistierung (NvM_ReadBlock, NvM_WriteBlock) von Filterparametern, Ereigniszählern, Non-Volatile-Schwellwerten und persistenten Pufferzuständen.
• PduR (Communication Services): Egress-Schnittstelle (PduR_Transmit). Übergabe qualifizierter Security-Event-PDUs zur On-Board-/Off-Board-Weiterleitung (z. B. an zentrales Telematik-Gateway oder SIEM/Backend).
• Dcm (Diagnostic Communication Manager): Bidirektionaler Zugriff via UDS (z. B. Service $22 ReadDataByIdentifier / $2E WriteDataByIdentifier) zur Konfiguration von Schwellwerten, Auslesen von Sensorstatus und Löschen von Ereignisspeichern.
• Kryptografische Kette (Csm ↔ CryIf ↔ Crypto (HSM) ↔ HSM):
  • Csm: Anforderung kryptografischer Primitiven (Signaturberechnung, MAC-Erzeugung, Payload-Verschlüsselung der QSEv-PDUs).
  • CryIf → Crypto Driver → HSM: Hardwarespezifische Abstraktion und Treiberausführung im Hardware Security Module (Microcontroller-Schicht).

3. Dynamisches Verhalten & Sequenzablauf

1. Ereigniserfassung (Synchroner Ingress):
   • BSW-Sensoren (CanIf, EthIf, SecOC, KeyM, Dcm) melden Sicherheitsvorfälle synchron über die direkte C-API IdsM_SetSecurityEvent(SecurityEventDefinitionId, ContextData, ContextDataLength).
   • Applikationskomponenten (App) triggern die Meldung asynchron/synchron über das RTE-Interface SecurityEventReporting.SetSecurityEvent(...).
2. Zeitstempelung & Qualifizierung:
   • IdsM ruft bei eintreffenden Events synchron die Zeitbasis von StbM ab (StbM_GetCurrentTime).
   • Interne Filterung (State-, Threshold-, Rate-Limiting- oder Sampling-Filter). Ein Event, das die Filterregeln passiert, wird zum QSEv (Qualified Security Event).
3. Pufferung, kryptografische Härtung & Egress:
   • IdsM puffert das QSEv im internen Ringspeicher.
   • Sofern konfiguriert, fordert IdsM asynchron kryptografische Operationen (z. B. MAC-Signatur) via Csm_MacGenerate an.
   • Übergabe an PduR via PduR_Transmit zur Aussendung als IdsM-PDU über Busprotokolle (CAN-FD, Ethernet/IP).
4. Fehlerspeicherung & Persistenz:
   • Triggern von DTCs im Dem via Dem_SetEventStatus, falls das Event Relevanz für das Fehlerspeichermanagement besitzt.
   • Periodisches oder Event-getriebenes Schreiben von State-Informationen in das NvM.

4. Normative Relevanz & Entwickler-Hinweise

• Puffer-Dimensionierung & Echtzeitverhalten: IdsM_SetSecurityEvent wird häufig aus hochfrequenten Interrupt- oder BSW-Task-Kontexten aufgerufen (z. B. EthIf_RxIndication, SecOC_VerifyStatusOverride). Die Ingress-API muss zwingend reentrant und nicht-blockierend ausgelegt sein. Ereignis-Drops bei Pufferüberlauf müssen deterministisch gehandhabt und als interne Security-Events (IdsM_InternalSEvs) erfasst werden.
• Filter-Konfiguration (ARXML): Schwellwerte (IdsMThresholdFilter), Ratenbegrenzungen (IdsMRateLimiter) und Zeitfenster müssen je SecurityEventDefinition in der BSW-Konfiguration penibel auf die Buslast und CPU-Ressourcen abgestimmt werden, um Denial-of-Service (DoS) auf dem PduR-Egress-Pfad zu verhindern.
• Abhängigkeiten zu StbM & Csm: Ist kein synchronisierter Zeitstempel verfügbar (z. B. Time-Base uninitialisiert / Time-Timeout), greifen Fallback-Regeln (Relative Systemticks oder ungültige Zeitstempel-Flags). Asynchrone Krypto-Jobs über den Csm erfordern Callback-Konfigurationen (IdsM_CsmNotification), um den IdsM-Main-Loop nicht zu blockieren.
• Speicherlayout & Non-Volatile Blocks: Für NvM-Blöcke des IdsM (z. B. persistente Filterzustände gegen Re-Boot-Angriffe) ist ein robuster Integritätsschutz (CRC32, Redundanz) zwingend erforderlich, um Manipulationen an Schwellwerten auszuschließen.