Figure 7.16: 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:
    • dynamicRuntimeLengthHandling: Boolean [0..1]: Steuert die dynamische Längenbehandlung der gesicherten PDU zur Laufzeit.
    • 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:
    • 0..1 Komposition zu SecureCommunicationProps (+secureCommunicationProps).
    • 0..1 Referenz auf SecureCommunicationFreshnessProps (+freshnessProps).
    • 0..1 Referenz auf SecureCommunicationAuthenticationProps (+authenticationProps).
    • 0..1 Referenz auf die Nutzdaten-PDU via PduTriggering (+payload).
• SecureCommunicationProps:
  • Instanzspezifische SecOC-Parameter der PDU:
    • dataId: PositiveInteger [0..1]: Kennung für die PDU-Authentifizierungsbindung (optional).
    • authenticationRetries: PositiveInteger [0..1]: Maximale Wiederholungsversuche bei Authentifizierungsfehlern (optional).
    • 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 Authentication-Tags (MAC/Signatur) in der PDU.
• PduTriggering («Identifiable»):
  • Verknüpft die Nutzdaten-PDU mit den Kommunikationsports (+iPduPort *).
• IPduPort (Spezialisierung/Typ: CommConnectorPort):
  • Port-spezifische Konfiguration für das Senden und Empfangen von I-PDUs:
    • iPduSignalProcessing: IPduSignalProcessingEnum [0..1]: Signalverarbeitungsmodus.
    • rxSecurityVerification: Boolean [0..1]: Steuert, ob auf Empfangsseite eine kryptografische Verifikation durchgeführt wird.
    • timestampRxAcceptanceWindow: TimeValue [0..1]: Akzeptanzzeitfenster für empfangene Zeitstempel.
    • useAuthDataFreshness: Boolean [0..1]: Gibt an, ob Freshness-Werte direkt aus den Nutzdaten bezogen werden.
• SecuredPduHeaderEnum («enumeration»):
  • Header-Konfiguration der gesicherten PDU: noHeader, securedPduHeader08Bit, securedPduHeader16Bit, securedPduHeader32Bit.

3. Dynamisches Verhalten & Sequenzablauf

• Konfigurations- und Bereitstellungsablauf:
  1. Das Systembündel SecureCommunicationPropsSet stellt wiederverwendbare Profile für Authentifizierung (SecureCommunicationAuthenticationProps) und Frischewerte (SecureCommunicationFreshnessProps) bereit.
  2. Eine SecuredIPdu kann optional eine Nutzlast über PduTriggering (+payload 0..1) und instanzspezifische SecureCommunicationProps (0..1) einbinden.
  3. Bei Sendeinitiierung wird über dataId, freshnessValueId und das Nutzdatenfenster (securedAreaOffset, securedAreaLength) das Authentifizierungs-Token (MAC) berechnet, auf authInfoTxLength gekürzt und zusammen mit dem gekürzten Freshness-Wert (freshnessValueTxLength) und optionalem Header (useSecuredPduHeader) assembliert.
  4. Auf Empfängerseite (IPduPort) steuert rxSecurityVerification die Verifikation; bei Zeitstempelnutzung dient timestampRxAcceptanceWindow zur Plausibilisierung, bevor die Nutzdaten zur Signalverarbeitung (iPduSignalProcessing) freigegeben werden.

4. Normative Relevanz & Entwickler-Hinweise

• Normative Verbindlichkeit:
  • Die Attribute dataId und authenticationRetries in SecureCommunicationProps sind nun optional ([0..1]).
  • Die Komposition +secureCommunicationProps und die Payload-Assoziation +payload an SecuredIPdu wurden von obligatorisch (1) auf optional (0..1) gelockert.
• Hinweise für Implementierung & Modellierung:
  • Die Lockerung auf 0..1 ermöglicht die Modellierung von kryptografischen Containern ohne direkte Payload-Verknüpfung im Modell (useAsCryptographicIPdu).
  • Mit dynamicRuntimeLengthHandling kann festgelegt werden, ob die SecOC-Verarbeitung variable PDU-Längen zur Laufzeit unterstützt.
  • Fehlen optionale Freshness- oder Authentication-Referenzen (0..1), greifen plattformspezifische Defaults oder PDU-interne Vorgaben.
  • Für fehlertolerante Kommunikation bei Counter-Drift ist freshnessCounterSyncAttempts zu parametrieren.