Service discovery over some IP is one of the most used protocols in automotive ethernet networks right now because it gives the flexibility of service-oriented communication instead of the normal fixed communication.
It also provides a way to communicate between different automotive stacks “e.g. classic AUTOSAR, adaptive AUTOSAR, GENIVI, etc …”
Service discovery protocol works in decentralized mode in communication mode:
(a) Publish/Subscribe to needed data “events”
(b) Request/Response “methods with return value”
(c) Fire and forget “methods without return value”
How it works
Server can offer the service and the client(s) will subscribe to service data then, the server will send the data to only clients subscribed to it.
In the end we can see multiple services offered by different ECUs and every service is consumed/subscribed-to by different ECUs as consumers for the service data.
In classic Autosar world this is done by the help of service discovery “SD” and socket adapter “SoAd” modules.
SD controls SoAd socket connections to open and close them as needed based on server or client state.
If service A is offered from the server and consumed from client A/B, SD on server side will open socket connection responsible for service data Tx path and SD on clients side will do the same for Rx path so the data can be forwarded to upper layers and application to use the data.
This efficient approach allows transmission and reception of only needed data to relevant clients reducing network bandwidth and ECUs Computational power.
Security Analysis:
However, the protocol is widely used and hugely efficient, but it lacks a very important aspect of automotive communication, which is security.
The protocol currently is working in plain text mode, and it lacks very important features like authenticity of the sender, integrity of the data and data confidentiality.
The protocol itself does not specify any security measures, but it also make it difficult to implement other security protocols because of its implementation.
SD is a decentralized protocol using mainly UDP protocol, multicast, and N:M communication, so protocols like TLS cannot be used effectively here since it needs 1:1 session setup over TCP.
Anyone who can have access to the ethernet network with proper tools can spy on the bus to understand SD services running in the car then starts to inject packets in same car or another one of the same model.
Available workaround which affects data throughput
For data transfer using TCP, the requesting client must establish a connection with the server. in this case TLS can be used, However the date throughput will be reduced as the server has to manually pull on all the clients to send the data.