Figure 7.28: Payload covered by SecOC and SOME/IP transport

1. Diagrammtyp & Architektur-Kontext

Strukturdiagramm zur Paketformat- und Protokoll-Schichtung im AUTOSAR-Adaptive-Kommunikationsmanagement (ara::com / Communication Management). Es zeigt die schrittweise Kapselung und den Abdeckungsbereich von Sicherheits- (SecOC) und Transport-Headern (SOME/IP) bei der Übertragung serialisierter Nutzdaten.

2. Komponenten, Entitäten & Schnittstellen

Das Diagramm gliedert ein Datenpaket in drei aufeinander aufbauende Stufen:

• SOME/IP Serialized Payload: Nutzdatenbereich, unterteilt in die Segmente oder Parameter x, y und z.
• SOME/IP Msg Header Part II: Zweiter Teil des SOME/IP-Nachrichten-Headers (enthält Request-ID / Client-ID & Session-ID, Protocol Version, Interface Version, Message Type, Return Code), der der Serialized Payload direkt vorangestellt ist.
• SecOC (truncated) Freshness: An das Payload-Segment angehängter, gekürzter Frischewert zur Absicherung gegen Replay-Angriffe.
• SecOC (truncated) Authenticator: Angehängter, gekürzter Message Authentication Code (MAC) zur Integritäts- und Authentizitätsprüfung.
• SOME/IP Msg Header Part I: Erster Teil des SOME/IP-Nachrichten-Headers (Message ID bestehend aus Service ID und Method/Event ID sowie das SOME/IP-Längenfeld).
• Abdeckungsbereiche / Scopes:
  • Payload covered by SecOC (violett markiert): Umfasst SOME/IP Msg Header Part II und SOME/IP Serialized Payload.
  • Payload covered by SOME/IP Length (blau markiert): Umfasst alle Bytes ab Beginn von SOME/IP Msg Header Part II über die serialisierte Payload bis einschließlich der beiden SecOC-Felder (Freshness und Authenticator).

3. Dynamisches Verhalten & Sequenzablauf

Das Diagramm illustriert den Kapselungsablauf von oben nach unten:

1. Bereitstellung der serialisierten SOME/IP-Payload (x, y, z) zusammen mit dem nachgelagerten Header-Teil SOME/IP Msg Header Part II.
2. Berechnung des SecOC-Schutzes über genau diese Bytes (SOME/IP Msg Header Part II + SOME/IP Serialized Payload) und anschließendes Anhängen von SecOC (truncated) Freshness sowie SecOC (truncated) Authenticator.
3. Hinzufügen von SOME/IP Msg Header Part I am Paketanfang; das darin enthaltene SOME/IP-Längenfeld deckt alle nachfolgenden Bytes ab (SOME/IP Msg Header Part II + Payload + SecOC Freshness + SecOC Authenticator).

4. Normative Relevanz & Entwickler-Hinweise

Normative Vorgabe für das Protokoll-Layout und die Längenberechnung bei der Absicherung von SOME/IP-Nachrichten mittels SecOC:

• Der kryptografische Authentifizierungsumfang von SecOC schließt SOME/IP Msg Header Part II sowie die serialisierte Payload ein, schließt jedoch SOME/IP Msg Header Part I und die SecOC-Erweiterungen selbst aus.
• Das SOME/IP-Längenfeld in SOME/IP Msg Header Part I muss zwingend die Länge von SOME/IP Msg Header Part II (8 Bytes), der Nutzlast sowie der angehängten SecOC-Zusatzdaten (Freshness Value und MAC) summieren.