Smart solutions for security and privacy issues in ITS


Data is the driving force behind intelligent transport systems. But using data also means taking risks: information can be leaked, unauthorized parties can surreptitiously gain access to it, and information can be altered by unauthorized parties – the familiar data security and privacy issues. This is why the partners participating in the Spookfiles A58 (‘Phantom Jams A58’) project are not only working on innovative ITS, but also on solutions for the corresponding data problems.

Article from NM Magazine, May 2016 – also available in PDF (Dutch only)

Spookfiles A58 is one of the projects being carried out under the Ministry for Infrastructure and the Environment’s Beter Benutten program. Businesses, the government, and knowledge institutions are working together in this project to introduce a cooperative system (wifi-p infrastructure), using the A58 between Tilburg and Eindhoven as trial trajectory. The first service to run on the system is the phantom jam service: this uses detailed information about traffic jams and waves of congestion on the trial trajectory to send participants personalized in-car speed recommendations from the roadside. In order to permit the cooperative system to generate these recommendations, it is necessary to collect, store, process and transmit a lot of information. This information includes both ‘public’ data, such as traffic information and the recommendations that the system eventually generates, as well as ‘personal’ data about the cooperative vehicles, such as their exact location, speed and direction. Working with this data inevitably means encountering two types of risk: possible problems in the field of (data) security, and issues related to privacy. The Spookfiles A58 partners have come up with interesting solutions for both categories that reduce the risks to an acceptable level.*

(Data) security


(Data) security has to deal first and foremost with availability problems. Will the service actually work when the client wants to use it? Or is there a problem somewhere along the chain with collecting or sharing information, which causes the service to fail? Secondly, there is the issue of data authenticity. Can clients who use an in-car service rely on it that the information on the screen of his device actually comes from the service provider? And then there are integrity issues. Is the recommendation that appears on the screen correct? Or has some of the data been altered, either on purpose or unconsciously? Security risks for the Spookfiles A58 project as such are not very grave: the phantom jam service on offer is an advisory service. The worst that could happen is that a particular recommendation is received temporarily or that an incorrect recommendation appears on the screen of the in-car device (the advice to reduce speed when this is not necessary). In both cases, there is still always the driver who will take his or her own decisions. But because Spookfiles A58 is a development and trial project, the partners decided to take stringent (data) security measures anyway. They regarded it as an excellent opportunity to practice for future services where risks may be higher.


So how are we dealing with the availability risks? It’s mainly a case of using quality components, executing systems and connections in a redundant way, and negotiating the right (commercial) service level agreements. The Spookfiles A58 system for instance runs on servers with guaranteed high availability, supplied by specialized market players. Specifically guaranteeing integrity and authenticity is slightly more difficult. To solve this, the project team developed a Public Key Infrastructure (PKI) solution. 

In short, PKI works like this: each system in Spookfiles A58 that wirelessly sends messages – i.e. the roadside stations and the on-board units in the cooperative vehicles – is fitted with two types of digital ‘key’: secret keys that only they can access, and a public key that is accessible to everyone via a database. The issuing and registration of the key sets is closely guarded. To give an example: say that a service provider wants to send a speed recommendation. Before sending this message, the service provider ‘signs’ it using his secret key: the key generates a digital signature on the basis of the message’s content. As soon as a cooperative vehicle picks up the speed advice, it will look for the transmitting stations’ public key. This public key can then be used to verify the signature linked to the message: was the right secret key used to generate this signature (= is the sender who he says he is) and does it match the content of the message? If this process results in an ‘Ok’, then the vehicle knows that both the authenticity and the integrity are reliable. If it results in ‘false’, then either the sender isn’t who he says he is, or the message has been altered.



Then there is the issue of privacy. A first risk is that detailed data is collected and stored for individual vehicles (that can be traced back to individual persons). In addition, some of this information is shared with third parties. This raises questions: are unauthorized persons able to access the stored data? And can we be sure that the shared data does not contain privacy-sensitive information?

A different kind of privacy risk is the intercepting of data transmitted by cooperative vehicles. Although a loose ‘message’ does not pose any danger – a certain vehicle A was at location x at time t – there would be a problem if all notifications transmitted by a vehicle were to be intercepted. If someone were to plot these onto a map, this would produce a route. That in turn would provide insight into the travel behaviour of individual vehicles (and of their users/drivers).


What are the solutions that are being developed or prepared for this problem? All source data collected for the Spookfiles A58 project is stored on the servers just mentioned. These are not only well-protected against failure, but are also strictly secured both physically and digitally. The source data itself, containing information that can be traced back to individual vehicles, is not surrendered to third parties. Any information that is shared – cooperative data is very valuable from a traffic scientific point of view – is aggregated data. This means that the third party receiving the information will not be able to zoom in to see details of specific vehicles. An extra measure taken in this regard is ‘in preparation’ and will be added at a later stage: removing the beginning and the end of each journey. This is because the start and end points are more difficult to aggregate – to prevent information about individual journeys from being shared, the last few hundred meters of each journey can be deleted.**

Finally there is the difficulty that all messages can in theory be intercepted and read. Should the messages that cooperative vehicles transmit perhaps be encrypted? No, because cooperation is obviously the essence of the cooperative system, as is the free sharing of details between the different components (the vehicles among each other, and vehicle and roadside).
One approach that has been developed is to give cooperative vehicles several digital signatures to sign their messages. This would make it much more difficult for eavesdroppers to follow a transmitter on the basis of the messages received. An extra precaution will be that the on-board units in the cooperative vehicles will change their MAC address every five minutes, so that they don’t transmit the same ID for longer than a few minutes.*** Even the cooperative system won’t ‘know’ which ID belongs to which vehicle.

And finally…

Spookfiles A58 has made a good contribution to data security and privacy protection for ITS systems. The solutions are intended first and foremost for the cooperative system on the A58 itself: they have already been implemented, or the architecture has been constructed to take implementation into account. But these solutions are also very suitable for use in other systems, whether cooperative or not. This is so because in developing these measures, the Spookfiles A58 partners have made sure to comply with the European standards set by ETSI, the European Telecommunications Standards Institute. In this sense, these solutions are not new. What is new, however, is that techniques such as PKI have been applied to the practice of cooperation on such a large scale. In doing so, the project has laid a robust foundation for (data) security and privacy in the future. 

* There is no such thing as 100% (data) security or privacy, just as no home is ever 100% burglar-proof. The aim of these measures is therefore to reduce risks to an acceptable level. What level is deemed to be acceptable will differ from application to application.
** This also means that origin or destination matrices cannot be extracted from the cooperative data, but this is the price that must be paid for privacy.
*** Many devices have a fixed MAC address, but the on-board units don’t. This is a consequence of the communication technology used, wifi-p, which is based on ‘connectionless communication’. By contrast with GSM, no connection is made (this takes too much time): all that happens is that messages are transmitted. This makes it easier to change ID.


Peter Goossens is chief technology officer at Vialis.
Willem de Boer is security domain architect at Technolution.
Oene Kerstjens is project manager Spookfiles A58.


Related items

Smart app FlowPatrol improves flow A58

Read more


BloqBase: your product development off to a good start

Read more

Building block

Speed Lock: permanently within the speed limit

Read more


'Waiting' in Amsterdam easier for inland shipping

Read more