Figure 7.15: Payload covered by SecOC and Signal2Service transport

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: PDU- / Wire-Format-Layoutdiagramm (Protokollrahmen-Struktur).
• Technischer Zweck & Einordnung:
  • Das Diagramm definiert das Serialisierungs- und Kapselungslayout für die Signal-to-Service-Translation (Signal2Service / S2S) im Adaptive Platform Communication Management (ara::com), wenn ein signalbasiertes PDU-Layout über SOME/IP transportiert und kryptografisch via SecOC (Secure Onboard Communication) abgesichert wird.
  • Funktionale Brücke zwischen klassischer, signalbasierter Kommunikation (ISignalIPdu aus dem CP-Umfeld bzw. System Description) und serviceorientierter Kommunikation (SOME/IP Events). Es visualisiert die exakte Abgrenzung zwischen SOME/IP-Header, Nutzdaten (Signals) und den SecOC-Sicherheitsfeldern im Ethernet-Frame.

2. Komponenten, Entitäten & Schnittstellen

• Protokoll-Entitäten & Datenstrukturen im Wire-Format:
  • SOME/IP Msg Header Part I (Dark Grey): Erste 8 Bytes des SOME/IP-Headers. Enthält:
    • Message ID (32 Bit: Service-ID [16 Bit] + Method-/Event-ID [16 Bit]).
    • Length (32 Bit): Definiert die Anzahl der nachfolgenden Bytes.
    • Hinweis: Der reguläre SOME/IP Header Part II (Request ID, Protocol Version, Interface Version, Message Type, Return Code – weitere 8 Bytes) entfällt in diesem Transportmodus vollständig.
  • Payload covered by SOME/IP Length (Cyan Marker): Die durch das SOME/IP-Längenfeld abgedeckte Gesamtspanne. Sie umfasst unmittelbar die serialisierte Nutzlast plus die SecOC-Trailer.
  • Signal based Serialized Payload (Light Grey): Authentic I-PDU bestehend aus den diskreten Signalen x, y, z (Layout gemäß Signal-to-PDU-Mapping, Bit-Positionen, Endianness).
  • SecOC (truncated) Freshness (Purple): Gekürzter Frischewert (Truncated Freshness Value, z. B. Counter oder Trip-Reset-Sync), konfiguriert zur Abwehr von Replay-Angriffen.
  • SecOC (truncated) Authenticator (Purple): Gekürzter Message Authentication Code (MAC, z. B. CMAC/HMAC), berechnet über die Authentic Payload, den vollständigen Frischewert und die Data ID.
• Metamodell-Entitäten (ARXML) & Beziehungen:
  • SomeipEventDeployment: Konfiguriert mit Attribut serializer = signalBased.
  • ISignalIPdu: Kapselt über ISignalToIPduMapping die Signale x, y, z (ISignal).
  • PduTriggering: Referenziert die ISignalIPdu und wird verknüpft mit einer SecuredIPdu.
  • SecuredIPdu: Verknüpft die Security-Eigenschaften über:
    • SecureCommunicationProps (grundlegende SecOC-Parameter),
    • SecureCommunicationFreshnessProps (Länge und Position des gekürzten Frischewerts),
    • SecureCommunicationAuthenticationProps (Algorithmus, Authenticator-Länge, Kürzungsregeln).

3. Dynamisches Verhalten & Sequenzablauf

Sende-Pfad (Tx / Serialisierung & Absicherung)

1. Trigger: Event-Transmission durch Adaptive-Applikation (Event::Send()) oder zyklischer PDU-Trigger.
2. Payload-Serialisierung: Communication Management (CM) serialisiert die Einzelsignale x, y, z gemäß PDU-Matrix in die Authentic Payload.
3. Freshness-Ermittlung: SecOC-Instanz fragt den aktuellen vollständigen Frischewert beim Freshness Value Manager (FVM / CSM) an.
4. MAC-Berechnung: Krypto-Modul berechnet den Authenticator über [Authentic Payload || Complete Freshness Value || DataID].
5. Frame-Zusammenbau:
   • Kürzung von Frischewert und Authenticator gemäß Konfiguration (SecureCommunication*Props).
   • Anhängen der gekürzten Felder direkt an die serialisierte Nutzlast.
   • Berechnung der SOME/IP-Länge: $\text{Length} = \text{len}(\text{Payload}) + \text{len}(\text{Truncated Freshness}) + \text{len}(\text{Truncated Authenticator})$.
   • Voranstellen des 8-Byte SOME/IP Msg Header Part I.
6. Transmission: Übergabe des zusammengesetzten Datenstroms an den Transport-Layer (UDP/TCP-Socket).

Empfangs-Pfad (Rx / Verifikation & Deserialisierung)

1. Header-Parsing: Auswertung von Message ID und Length aus Header Part I; Validierung gegen Deployment-Konfiguration.
2. Extraktion: Aufteilung der Payload in Authentic Payload (x, y, z), Truncated Freshness und Truncated Authenticator anhand der statisch konfigurierten Bitlängen.
3. Frische-Rekonstruktion: FVM rekonstruiert den vollständigen Frischewert aus dem empfangenen gekürzten Wert und dem internen Status.
4. Kryptografische Verifikation: Berechnung des Soll-MAC über [Authentic Payload || Reconstructed Full Freshness || DataID] und Vergleich mit dem Truncated Authenticator.
5. Verzweigung / Fehlerbehandlung:
   • Erfolg: Entpacken der Signale x, y, z und Bereitstellung an die Subskribenten via ara::com-API.
   • Fehlschlag (MAC-/Freshness-Mismatch): Verwerfen der PDU; Fehlermeldung an das Intrusion Detection Security Management (IdsM) / Security Event Reporting gemäß RS_SEC_04001.

4. Normative Relevanz & Entwickler-Hinweise

• Normative Anforderungen:
  • SWS_CM_11346: Wird ISignalTriggering in einer Signal-Service-Translation eingesetzt (SomeipEventDeployment.serializer == signalBased), muss das Communication Management prüfen, ob das PduTriggering der zugehörigen ISignalIPdu von einer SecuredIPdu referenziert wird. Falls ja, müssen SecureCommunicationAuthenticationProps, SecureCommunicationFreshnessProps und SecureCommunicationProps zwingend für die SecOC-Konfiguration herangezogen werden.
  • RS_SEC_04001: Gewährleistung von Datenauthentizität, Integrität und Replay-Schutz über sichere Kommunikationskanäle.
• Konsequenzen für Stack- & System-Entwickler:
  • Header-Abweichung beachten: Standard-SOME/IP-Parser erwarten 16 Bytes Header (inkl. Session-ID, Request-ID, Interface Version etc.). Bei signalBased Transport dürfen nur Part I (8 Bytes) verarbeitet werden. Standard-Wireshark-Dissektoren oder generische SOME/IP-Stacks ohne Signal2Service-Erweiterung schlagen bei diesem Wire-Format fehl.
  • Konfigurations-Konsistenz: Die Längen für Truncated Freshness und Truncated Authenticator müssen auf Sender- und Empfängerseite byte-exakt in den ARXML-Modellen (SecuredIPdu) übereinstimmen; dynamisches Parsing existiert im Wire-Format nicht (keine TLV-Codierung, rein statischer Offset).
  • Performance & Latenz-Budget: Die Berechnung des MACs vor dem Senden sowie die Verifikation vor der Signal-Extraktion erfordern CSM/Crypto-Aufrufe. Bei hochfrequenten Signalen (x, y, z) muss die Krypto-Hardwarebeschleunigung (z. B. HSM/SHE) für synchrone/asynchrone Aufrufe im CM-Thread-Pool dimensioniert sein.