Figure 7.3: Functional modules of the IdsM.

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: AUTOSAR BSW-Schichtenarchitektur- und Funktionsblockdiagramm mit vertikalen/horizontalen Interaktionspfaden (Data- & Control-Flow).
• Technischer Zweck: Spezifikation der internen funktionalen Pipeline des Intrusion Detection System Managers (IdsM) in der AUTOSAR Classic Platform (Service Layer) sowie seiner Systemintegration:
  • Entkopplung von Security-Sensoren (Applikation, BSW-Stacks, MCAL-Treiber) über einen Pufferungsmechanismus.
  • Transformation von Roh-Sicherheitsereignissen (Security Events, SEv) in qualifizierte Sicherheitsereignisse (Qualified Security Events, QSEv) anhand konfigurierbarer Filter-/Schwellwert-Algorithmen.
  • Anbindung an die Persistenzinfrastruktur (Dem/Sem, NvM) und den Kommunikations-/Kryptografiestack (Csm, CryIf, Crypto Driver, PduR) zur Weiterleitung an den IdsR (Ids Reporter / On-board Dispatcher).

2. Komponenten, Entitäten & Schnittstellen

Akteure & BSW-Module nach Schichten:

• Application Layer:
  • SW-C (Application Software Component als Security-Sensor): Meldet applikative Sicherheitsereignisse (Report SEv).
• Runtime Environment (RTE):
  • Vermittelt Service-Port-Aufrufe zwischen SW-C und BSW (SecurityEventReport-Interface).
• BSW – Services Layer:
  • IdsM (Crypto/System Services): Zentrales Kernmodul mit vier normativen Submodulen:
    • Buffer SEv (SWS_IdsM_00202): Thread-sichere FIFO-/Ringpufferung zur Entkopplung der Meldekontexte.
    • Qualify SEv (SWS_IdsM_00203): Regelbasierte Qualifizierungslogik (Thresholds, Time-Windows, Filterung).
    • Prepare QSEv for persistence (SWS_IdsM_00204): Serialisierung und Formatierung für Diagnosespeicher / NvM.
    • Prepare QSEv for transmission (SWS_IdsM_00204): Zusammenbau von IdsM-PDUs (Compact/Extended Format) zur Übertragung.
  • Dcm (Communication Services):
    • Schnittstelle Access QSEv records: Diagnosezugriff auf gepufferte/gespeicherte QSEv-Einträge via UDS (z. B. ReadDTCInformation 0x19 / RoutineControl 0x31).
    • Schnittstelle Reconfigurate specific parameters of SEv: Dynamische Schwellwert- und Filterrekonfiguration zur Laufzeit.
  • Dem inkl. Sem (System Services):
    • Sem (Security Event Memory): Spezialisierter Speicherbereich im Dem zur Ablage von QSEv-Records.
  • NvM (Memory Services):
    • Nichtflüchtige Speicherung von QSEv-Parametern, Zählern, Filterzuständen und Blockdaten.
  • Csm (Crypto Services):
    • Subfunktion Prepare signature: Asymmetrische Signatur- oder MAC-Generierung zur Integritäts- und Authentizitätssicherung der IdsM-PDUs vor der Übertragung.
  • SecOC (Communication Services als BSW-Sensor-Beispiel):
    • Erkennt MAC-Verifikationsfehler, Freshness-Value-Mismatches oder Replay-Angriffe und meldet diese via C-API direkt an den IdsM.
  • PduR (Communication Services):
    • Weiterleitung der serialisierten/signierten QSEv-PDUs (Propagate QSEv to IdsR) an nachgelagerte Bus-Schnittstellen (CanIf, SoAd, FrIf).
• BSW – Crypto Hardware Abstraction & Driver Layer:
  • CryIf & Crypto (HSM) (MCAL / Crypto Driver):
    • Abstraktion und hardwarenahe Ausführung der Signatur-/MAC-Operationen.
• BSW – Communication Drivers Layer:
  • EthDrv (MCAL-Sensor-Beispiel):
    • Erkennt Low-Level-Netzwerkanomalien (z. B. Frame-Size-Violations, Flooding, ungültige EtherTypes) und meldet sie per C-API schichtenübergreifend direkt an Buffer SEv.
• Microcontroller / Hardware:
  • HSM (Hardware Security Module): Physikalischer Secure-Execution-Bereich für Krypto-Operationen und Schlüsselverwaltung.

Schnittstellen & Beziehungen:

• Sensor-Input (1:n): C-API IdsM_SetSecurityEvent() / IdsM_SetSecurityEventWithContextData() bzw. RTE-Client/Server-Ports.
• Diagnose-Kopplung (1:1): Bivalente Interaktion zwischen Dcm und IdsM (Lesen vs. Parametrieren).
• Persistenz-Kopplung: IdsM → Dem/Sem → NvM (Ereignisspeicherung) und direkte Bindung IdsM → NvM (Filterschwellwerte/Monotonic Counters).
• Krypto-/Routing-Kopplung: Synchron/asynchrone Delegation IdsM → Csm → CryIf → Crypto Driver; anschließende PDU-Übergabe IdsM → PduR_Transmit().

3. Dynamisches Verhalten & Sequenzablauf

1. Ereigniserfassung (Synchron / Interrupt- oder Task-Kontext):
   • Ein Sensor (SW-C via RTE, SecOC im Bus-Task-Kontext, EthDrv im RX-Task/ISR-Kontext) detektiert eine Anomalie und setzt synchron IdsM_SetSecurityEvent(EventId, ...).
   • Das Submodul Buffer SEv nimmt das Event atomar entgegen und legt es in einen internen Puffer (Entkopplung zur Einhaltung harter Realzeit-Deadlines der Aufrufer).
2. Qualifizierung (Asynchron in IdsM_MainFunction):
   • Zyklischer Aufruf von IdsM_MainFunction().
   • Qualify SEv liest gepufferte SEvs aus, prüft Filterregeln (Rate-Limiting, Zeitfenster, Zählschwellen nach SWS_IdsM_00203).
   • Erreicht ein SEv die definierte Schwelle, wechselt sein Status in QSEv (Qualified Security Event).
3. Persistenzpfad (Bedingt / Parallel):
   • Ist die Persistierung konfiguriert (Prepare QSEv for persistence, SWS_IdsM_00204), übergibt der IdsM das Ereignis an das Dem/Sem (Dem_SetEventStatus / dedizierte Sem-API) zur Ablage im NVRAM via NvM_WriteBlock().
4. Signierung & Übertragungspfad (Bedingt / Asynchron):
   • Prepare QSEv for transmission (SWS_IdsM_00204) packt das Ereignis in ein IdsM-Protokoll-Frame.
   • Falls konfiguriert: Aufruf von Csm_MacGenerate() oder Csm_SignatureGenerate(). Die Krypto-Kette propagiert den Job über CryIf an Crypto (HSM).
   • Nach erfolgreichem Krypto-Callback (IdsM_CsmNotification) übergibt der IdsM die PDU via PduR_Transmit() an den PDU-Router zur Weiterleitung an den bordeigenen oder fahrzeugexternen IdsR.

4. Normative Relevanz & Entwickler-Hinweise

• Kontext- und Reentrancy-Anforderungen:
  • IdsM_SetSecurityEvent() muss reentrant und interrupt-sicher implementiert sein, da Aufrufe direkt aus MCAL-Treibern (EthDrv), OS-Tasks (SecOC) und Applikationstasks (SW-C) erfolgen können.
  • Das Submodul Buffer SEv erfordert Critical Sections (SchM_Enter_IdsM_...), um Dateninkonsistenzen bei parallelen Pufferzugriffen zu verhindern.
• Pufferüberlauf-Strategien (SWS_IdsM_00202):
  • Bei hoher Last (z. B. Denial-of-Service-Angriff auf den Bus) droht Puffererschöpfung. Der Stack muss deterministisch konfiguriert werden (IdsMBufferOverrunStrategy: Drop-Newest vs. Overwrite-Oldest); Überläufe müssen zwingend als internes Meta-Security-Event oder DET-Fehler (IDSM_E_BUFFER_OVERFLOW) registriert werden.
• Dcm-Rekonfigurationsrisiko:
  • Änderungen von Filterschwellen via Dcm wirken direkt auf Qualify SEv. Embedded-Entwickler müssen sicherstellen, dass geänderte Parameter gegen unbefugtes Überschreiben (UDS SecurityAccess) geschützt sind und konsistent in den NvM gespiegelt werden.
• Krypto-Latenzen & Blockierungsfreiheit:
  • Die Signierung via Csm darf die IdsM_MainFunction nicht blockieren. Es sind asynchrone CSM-Jobs zu verwenden; der Sendepfad via PduR darf erst nach Eintreffen des asynchronen CSM-Tx-Bestätigungs-Callbacks getriggert werden.
• Ressourcenallokation (RAM/ROM):
  • Da Sensor-Beispiele wie EthDrv extrem hohe Datenraten aufweisen, müssen Filterparameter (IdsMFilterThreshold, IdsMFilterDuration) restriktiv gewählt werden, um ein Fluten des Dem/Sem-Speichers und des Kommunikationsbusses zu verhindern.