Figure 7.40: Input for for signal based SecOC configuration

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: AUTOSAR Meta-Modell-Ausschnitt / UML-Klassendiagramm der System- und Kommunikationsbeschreibung (FIBEX/ARXML-Modell).
• Technischer Zweck & Einordnung: Spezifikation der Konfigurationsparameter für signalbasierte Secure Onboard Communication (SecOC) im Kontext des AUTOSAR Adaptive Communication Management (ara::com). Es definiert die metamodellierten Schnittstellen und Datenstrukturen, über welche die Absicherung von I-PDUs (Authentizität, Integrität und Replay-Schutz via Freshness-Werten und Authenticator/MAC) für signalbasierte Kommunikationspfade (z. B. CAN, FlexRay, Ethernet) konfiguriert und an den Stack übergeben wird.

2. Komponenten, Entitäten & Schnittstellen

Meta-Klassen & Datenstrukturen

• SecureCommunicationPropsSet («FibexElement»):
  • Globales/systemweites Bündelungselement für wiederverwendbare Sicherheitsprofile.
  • Besitzt per Komposition:
    • 0..* SecureCommunicationFreshnessProps (Rolle: +freshnessProps).
    • 0..* SecureCommunicationAuthenticationProps (Rolle: +authenticationProps).
• SecuredIPdu (Spezialisierung/Typ: IPdu):
  • Repräsentiert die kryptografisch gesicherte PDU.
  • Attribute:
    • useAsCryptographicIPdu: Boolean [0..1]: Legt fest, ob die PDU als rein kryptografischer Container agiert.
    • useSecuredPduHeader: SecuredPduHeaderEnum [0..1]: Aktiviert/konfiguriert die Header-Länge zur PDU-Laufzeitidentifikation.
  • Assoziationen & Abhängigkeiten:
    • 1 Komposition zu SecureCommunicationProps (+secureCommunicationProps).
    • 0..1 Referenz auf SecureCommunicationFreshnessProps (+freshnessProps).
    • 0..1 Referenz auf SecureCommunicationAuthenticationProps (+authenticationProps).
    • 1 Referenz auf die Nutzdaten-PDU via PduTriggering (+payload).
• SecureCommunicationProps:
  • Instanzspezifische SecOC-Parameter der PDU:
    • dataId: PositiveInteger: Eindeutige Kennung für die PDU-Authentifizierungsbindung.
    • authenticationRetries: PositiveInteger: Maximale Wiederholungsversuche bei Authentifizierungsfehlern.
    • authenticationBuildAttempts: PositiveInteger [0..1]: Versuche zur Konstruktion des Authentication-Tags.
    • freshnessValueId: PositiveInteger [0..1] & secondaryFreshnessValueId: PositiveInteger [0..1]: Schlüssel für Freshness-Manager/FVM.
    • authDataFreshnessLength / authDataFreshnessStartPosition (PositiveInteger [0..1]): Extraktion von Freshness-Informationen aus den Nutzdaten.
    • securedAreaLength / securedAreaOffset (PositiveInteger [0..1]): Definiert das exakte Byte-Fenster der PDU, das in die MAC-Berechnung eingeht.
    • messageLinkLength / messageLinkPosition (PositiveInteger [0..1]): Parameter zur Verknüpfung getrennter Authenticators bei Split-PDU-Verfahren.
• SecureCommunicationFreshnessProps («Identifiable»):
  • Profil für Freshness-Value-Management (Replay-Schutz):
    • freshnessValueLength / freshnessValueTxLength: Vollständige vs. tatsächlich übertragene Bitlänge des Freshness-Werts.
    • freshnessCounterSyncAttempts: PositiveInteger [0..1]: Synchronisationsversuche bei Counter-Versatz.
    • useFreshnessTimestamp: Boolean [0..1] & freshnessTimestampTimePeriodFactor: PositiveInteger [0..1]: Parameter für zeitstempelbasierte Frischeprüfung.
• SecureCommunicationAuthenticationProps («Identifiable»):
  • authInfoTxLength: PositiveInteger [0..1]: Übertragene Bitlänge des Authentifizierungs-Tags (Trunkierung des MAC).
• PduTriggering («Identifiable»):
  • Bildet den Payload-Transport auf Netzwerkebene ab; referenziert * Ports via +iPduPort.
• IPduPort (Spezialisierung/Typ: CommConnectorPort):
  • Schnittstellenknoten am Kommunikations-Connector:
    • rxSecurityVerification: Boolean [0..1]: Schaltet die Verifikation auf Empfängerseite scharf.
    • timestampRxAcceptanceWindow: TimeValue [0..1]: Akzeptanzfenster (Toleranz) für Zeitstempelverifikation.
    • useAuthDataFreshness: Boolean [0..1]: Nutzt Freshness direkt aus Datenfeld.
    • iPduSignalProcessing: IPduSignalProcessingEnum [0..1]: Art der Weiterverarbeitung (IMMEDIATE vs. DEFERRED).
• SecuredPduHeaderEnum («enumeration»):
  • Werte: noHeader, securedPduHeader08Bit, securedPduHeader16Bit, securedPduHeader32Bit.

3. Dynamisches Verhalten & Sequenzablauf

Da es sich um ein statisches Metamodell handelt, ergibt sich die Dynamik zur Laufzeit aus der Konfigurationsauswertung (SWS_CM_90117, SWS_CM_90118):

1. Sende-Pfad (Tx / PDU Construction):
   • Trigger durch Signal-Assembly: payload (über PduTriggering) stellt Nutzdaten bereit.
   • PDU-Layout-Zusammenbau: Optionaler SecuredPduHeader + securedArea (Offset/Length).
   • Freshness-Abfrage: Abruf des aktuellen Freshness-Werts (FVM / Zeitstempel) via freshnessValueId. Kürzung auf freshnessValueTxLength.
   • MAC-Generierung: Crypto-Service berechnet MAC über DataID + SecuredArea + FreshnessValue.
   • Truncation & Serialisierung: Kürzung des MAC auf authInfoTxLength und Einbettung in SecuredIPdu.
2. Empfangs-Pfad (Rx / Verification):
   • Empfang der SecuredIPdu am IPduPort.
   • Prüfung rxSecurityVerification == TRUE: Falls FALSE, Weiterleitung ohne Verifikation.
   • Zeitstempelprüfung: Abgleich gegen timestampRxAcceptanceWindow.
   • Replay- & MAC-Verifikation: Rekonstruktion des vollständigen Freshness-Werts; Validierung des MAC.
   • Fehlerbehandlung: Bei Fehlschlag Wiederholung bis authenticationRetries; bei anhaltendem Fehler Verwerfen der PDU und Fehlereintrag (Security Event / Det / Dem).

4. Normative Relevanz & Entwickler-Hinweise

• Generator- & Tooling-Vertrag (SWS_CM_90117, SWS_CM_90118):
  • ARXML-Generatoren für ara::com müssen signalbasierte Endpunkte über diese Klassen parametrisieren, um standardkonforme SecOC-Binärlayouts (Payload, Truncated Freshness, Truncated MAC, optionaler Header) deterministisch zu erzeugen.
• Speicher- & Bus-Bandbreitenoptimierung:
  • authInfoTxLength und freshnessValueTxLength definieren den PDU-Overhead auf dem Bus. Unvollständige Freshness-Werte im Frame (freshnessValueTxLength < freshnessValueLength) erzwingen auf Empfängerseite ein zustandsbehaftetes Freshness Value Management (FVM) zur Rekonstruktion des Zählers.
• Port-Spezifische Verifikation:
  • rxSecurityVerification auf IPduPort-Ebene erlaubt asymmetrische Absicherung: Gateways oder Diagnoseknoten können dieselbe PDU unverifiziert weiterrouten oder monitorieren, während Ziel-ECUs die Verifikation erzwingen.
• Teilabsicherung via securedAreaOffset / securedAreaLength:
  • Erlaubt das Ausschließen dynamischer oder unkritischer Signale innerhalb derselben PDU von der MAC-Berechnung (z. B. Diagnose-Zähler oder ungesicherte Statusflags). Offset und Länge müssen strikt byte-aligned zur PDU-Serialisierung passen, andernfalls schlägt die Verifikation fehl.