# SOME/IP-Security-Tests: was prüfen und warum Wie du SOME/IP am Prüfstand testest: ein Service-Inventar aus Service Discovery bauen, mit der Matrix vergleichen, Erreichbarkeit prüfen, Ergebnisse lesen. Source: https://auto-st.com/de/insights/some-ip-security-tests · Updated: 2026-10-07 SOME/IP-Security-Tests beantworten eine Frage: welche Services bietet ein Steuergerät im Netzwerk an, und ist jeder nur für die Clients erreichbar, die ihn erreichen sollen? Das Protokoll hat keine eigene Authentifizierung, ein Service ist also nur dadurch geschützt, wo er im Netz liegt und welche zusätzliche Schicht das Projekt ergänzt hat. Der Test beginnt deshalb damit, ein Inventar aus Service Discovery zu bauen, es mit der Kommunikationsmatrix zu vergleichen und alles zu markieren, was dort oder für den angeboten wird, wo oder für den es nicht sein sollte. Robustheitstests kommen danach, am Prüfstand. ## Der Header, wie ein Leser ihn braucht Eine SOME/IP-Nachricht beginnt mit einem 16 Byte langen Header. Ihn zu lesen ermöglicht, ein Capture zu interpretieren und einen Service vom anderen zu unterscheiden. ``` 12 34 00 01 Message ID: Service 0x1234, Methode 0x0001 00 00 00 0A Length-Feld 00 01 00 01 Request ID: Client ID und Session ID 01 Protocol Version 01 Interface Version 00 Message Type (REQUEST, RESPONSE, NOTIFICATION, ...) 00 Return Code ``` Method-IDs mit gesetztem höchsten Bit (`0x8000` und höher) sind Events, keine Methoden. Responses tragen einen Return Code, der für einen Tester so nützlich ist wie ein UDS-NRC: `0x00` E_OK, `0x02` E_UNKNOWN_SERVICE, `0x03` E_UNKNOWN_METHOD, `0x07` E_WRONG_PROTOCOL_VERSION, `0x08` E_WRONG_INTERFACE_VERSION. Diese Codes sagen dir, ob ein Service existiert und adressierbar ist, bevor du etwas über seine Funktion weißt. ## Schritt 1: das Inventar bauen Service Discovery (SOME/IP-SD) ist die Quelle des Inventars. Steuergeräte kündigen ihre Services mit OfferService-Einträgen an, die Service ID, Instance ID, Major- und Minor-Version, eine Time-to-live und eine Endpoint-Option mit IP-Adresse, Transportprotokoll und Port tragen. Diesen Verkehr mitzuhören und optional mit einem FindService-Eintrag nach Services zu fragen, ergibt eine Liste dessen, was im Netz ist: | Feld | Was der Tester festhält | | --- | --- | | Service ID / Instance ID | Welcher Service, welche Instanz | | Major- / Minor-Version | Angebotene Interface-Version | | Endpoint (IP, Protokoll, Port) | Wo er erreichbar ist | | TTL | Wie lange das Angebot gilt | AutoST macht diesen Teil passiv und mit aktivem FindService und bildet die Methoden und Eventgroups, die es beobachten kann, auf jeden Service ab. ## Schritt 2: mit der Kommunikationsmatrix vergleichen Das Inventar allein ist nur eine Liste. Die Findings erscheinen, wenn du es neben die Kommunikationsmatrix legst (das ARXML oder das Service-Design des Projekts), die sagt, was jedes Steuergerät anbieten soll und für wen: - Ein angebotener Service, der nicht in der Matrix steht: ein undokumentierter oder übrig gebliebener Service, das SOME/IP-Gegenstück zu einem versteckten Diagnosedienst. - Ein Service auf dem falschen Netzsegment: erreichbar aus einer Domain oder einem VLAN, das das Design nie vorsah, etwa von einer nach außen gerichteten Head Unit. - Mehr Methoden oder Events, als die Matrix listet: ein Interface breiter als seine Spezifikation. - Ein Versionskonflikt: ein Steuergerät, das eine alte Interface-Version neben der aktuellen weiter anbietet. ## Schritt 3: Erreichbarkeit und Zugriff prüfen Für jeden Service, der eingeschränkt sein sollte, lautet die Frage, ob die Einschränkung wirklich hält. Bestätige am Prüfstand, aus welchen Segmenten der Service überhaupt antwortet, ob er einem Client antwortet, den das Design nicht als Konsumenten listet, und ob ein Event von einem Endpunkt abonniert werden kann, der es nicht empfangen sollte. Ein Service, der einem nie vorgesehenen Client mit `E_OK` antwortet, ist ein Zugriffsschutz-Finding, unabhängig davon, was die Methode tut. Wo das Projekt Authentifizierung oder TLS über SOME/IP gelegt hat, bestätige, dass sie tatsächlich erforderlich und nicht nur verfügbar ist. ## Schritt 4: Robustheit Zuletzt, und nur am Prüfstand, kommt die Robustheit: wie der Service-Stack mit fehlerhaften Headern, falschen Length-Feldern, unerwarteten Message-Types und abgeschnittenen Payloads umgeht. Dieselbe Crash- und Hang-Erkennung wie beim UDS- und CAN-Fuzzing gilt, denn eine Service-Implementierung, die bei einem schlechten Header umfällt, ist eine Denial-of-Service-Oberfläche. ## Die Ergebnisse lesen | Beobachtung | Was es bedeutet | | --- | --- | | Service nicht in der Matrix | Undokumentierter oder übrig gebliebener Service | | Service aus dem falschen Segment erreichbar | Lücke in der Netzsegmentierung | | Zusätzliche Methoden oder Events angeboten | Interface breiter als spezifiziert | | Antwortet einem Client, der ihn nicht erreichen sollte | Fehlender Zugriffsschutz | | Stack fällt bei einer fehlerhaften Nachricht um | Robustheits- und Denial-of-Service-Finding | Die meisten SOME/IP-Findings drehen sich um Erreichbarkeit und Konfiguration, nicht um einen gebrochenen Algorithmus, der Fix liegt also meist im Netzwerkdesign, in der Service-Konfiguration oder in den Gateway-Regeln. ## Wie AutoST SOME/IP testet AutoST entdeckt SOME/IP-Services passiv und mit aktivem FindService, bildet Services, Methoden und Eventgroups auf ihre Endpunkte ab und bewertet die Exposition, und es läuft über dieselbe Ethernet-Verbindung wie für DoIP, sodass Diagnose- und Service-Findings zusammen landen. Die Ergebnisse fließen in denselben Risiko-Score und Fix Plan wie alles andere. Die tiefere Arbeit an einzelnen Services, die Anwendungslogik hinter einer Methode und die Verbindung zu Sicherheitsfunktionen bleiben beim Penetrationstester. ## FAQ **Hat SOME/IP eingebaute Sicherheit?** Nein. Das SOME/IP-Protokoll selbst trägt keine Authentifizierung oder Verschlüsselung. Schutz kommt aus dem Netzwerkdesign, etwa VLANs und Firewalls im Switch oder Gateway, und aus zusätzlichen Schichten, wo das Projekt sie einsetzt. Deshalb konzentriert sich der Test auf Erreichbarkeit und Konfiguration. **Was ist das häufigste SOME/IP-Finding?** Services, die auf einem Netzsegment angeboten werden, das niemand erreichen sollte, und Services, die mehr Methoden oder Events offenlegen, als die Kommunikationsmatrix vorsah. Beides zeigt sich, sobald du das gefundene Inventar mit der Matrix vergleichst. **Ist SOME/IP-Testen an einem laufenden Fahrzeug sicher?** Passive Discovery ist in der Regel sicher. Alles, was mit einem Service interagiert, gehört an den Prüfstand, denn eine Methode auf einem Automotive-Steuergerät kann einen Fahrzeugzustand ändern, deshalb ist Interaktionstesten eine kontrollierte Prüfstandstätigkeit. ## Sources - [AUTOSAR SOME/IP Protocol Specification und SOME/IP Service Discovery Protocol Specification](https://www.autosar.org/standards) - [ISO 13400-2:2019 Straßenfahrzeuge, Diagnosekommunikation über Internet Protocol (DoIP), Teil 2](https://www.iso.org/standard/74785.html) - [ISO/SAE 21434:2021 Straßenfahrzeuge, Cybersecurity-Engineering](https://www.iso.org/standard/70918.html) ## Related - [SOME/IP (Scalable service-Oriented MiddlewarE over IP)](https://auto-st.com/de/glossar/some-ip) - [DoIP (Diagnostics over Internet Protocol)](https://auto-st.com/de/glossar/doip) - [DoIP-Testaufbau: vom Ethernet-Link zu UDS über IP](https://auto-st.com/de/insights/doip-testaufbau) - [Fuzzing vs. Schwachstellenscan am Steuergerät: Was welche Methode findet](https://auto-st.com/de/vergleich/fuzzing-vs-schwachstellenscan) - [Folge dem ECU ins Netzwerk.](https://auto-st.com/de/doip-someip-test) --- AutoST by Zyberum. Canonical page: https://auto-st.com/de/insights/some-ip-security-tests