Authenticated Transmission of Traffic Signal Information for Autonomous Vehicles

By Yogesh Kumar Oza


With the current rate of advancements in self-driving capabilities of new age vehicles, the need for detecting traffic signal arises for these autonomous vehicles. The current approaches rely on image processing of the traffic lights but this may not be suitable in certain environments where visibility is limited due to weather conditions. Intersections with high number of connecting roads can also cause confusion and thus the vehicle not being able to detect the correct traffic signal information. An error in detecting this information correctly can have life threatening consequences. In this blog, I propose a method to securely transmit the traffic signal information to these autonomous vehicles wirelessly.


Without the security provisions that will be suggested here, any malicious user can send a wrong traffic signal information which the vehicle will use blindly which in turn can cause life threatening crashes. The transmission of traffic signal information does not need to be confidential as anyone within the range should be able to read that broadcast but the receivers should be able to verify the integrity of the message and they should be able to authenticate the sender of this information. To achieve this, we could simply use public key based digital signatures but the information being transmitted is time sensitive and any delay caused by the computational complexity may result in receiver getting the information which has already been changed. To overcome this, the autonomous vehicles can first authenticate the certificates of the available traffic nodes in a wider area using PKI infrastructure. Once the vehicle has identified the nodes it needs to communicate with, based on the route the vehicle is going to take it can authenticate the available nodes in its area it and establish a symmetric key with these nodes and send the same to the nodes securely by using their public key. The nodes can then use this key to generate the MAC of the message it is going to send to the vehicle. The receiving vehicle can calculate MAC again using the shared secret key and compare it with the received MAC to validate the integrity of the message. Note that the message itself does not have to be encrypted as confidentiality of the traffic signal information is not required.


First, we need to specify the data structure format in which the information will be transmitted. For this we need to mark all the roads on the intersection with unique IDs. Here each road direction as well will have a unique ID. A sample numbering of a four-way intersection can be seen in fig. 1 below:


Figure 1: Four-way intersection numbering


To represent the traffic signal information for the roads numbered above, an adjacency matrix can be used with a value “1” representing the path that has “green light” and value “0” representing the that path has “red light”.  For example, considering that only paths from road 2 to 3, 2 to 5 and 8 to 1 are open, it can be represented by an adjacency matrix as seen in fig. 2 below.

boolean red_green[8][8]; //index starts from 1 NOT 0 for simplicity.

If the value of red_green[i][j] is “1”, it means that the path from road “i” to “j” has green light but NOT vice-versa, which means that path “j” to “i” is not green.


Figure 2: Adjacency Matrix

The next step in the implementation is defining the contents of the public key certificate which will be sent to the vehicles. Apart from the standard fields like the Public Key, Serial number, Issuer, Subject, Algorithm used etc. we need to add a custom field “location” in the public key certificate. This field will hold the GPS location of the sender on that intersection. Once the client receives this certificate, it can extract the GPS coordinates from the certificate. Once the client has the GPS coordinates, it is the client’s responsibility to check if it wants to authenticate that sender. This is up to the client how they choose whether the sender should be authenticated to establish a secure channel with it. This decision can be based on a predetermined route the client is taking. The client will then calculate if the GPS coordinates of the sender fall within the list of the coordinates of the intersections the client will be passing through. Choosing the sender to authenticate this way may have issues if the client decides to change route last minute and it may not have sufficient time to authenticate the new intersection it is heading to. The other way of choosing the intersections to authenticate can be based on choosing an authentication radius. The clients will calculate the intersections’ distance from itself and if the distance falls within the specified radius it will authenticate the sender. This method works well for driving within the city limits where last minute changes to a route happen all the time so the client will always have all the intersections authenticated within the specified radius. Once the clients have selected the senders is wants to authenticate it will verify the signed public key certificate sent by them with RSA using the trusted certificate authority (CA) to verify the identity of those senders and their corresponding GPS coordinates.


Figure 3: Message exchanges for sending the signal information


Once the client has authenticated the identity of the sender, it will generate a 128-bit key to communicate that sender. The client will encrypt this key using the sender’s public key and transmit it to that sender. The sender will than decrypt this message using its private key to extract the 128-bit key from that message. This key (K) will be used as a symmetric key with AES-CBC block cipher to achieve the goal of integrity of the signal information that will be sent to the client. This will be achieved by using the CBC-MAC generated by the AES cipher. Usually the AES-CBC requires two 128-bit keys, one for encryption and one for MAC generation but here, the message being sent does not need to be encrypted as it is intended to be a broadcast for anyone listening to it. Only one key will be needed here to generate only the MAC of the message being sent. This MAC (MACs) will be sent to the client along with the plain-text message (M). Once the client receives this message, it will generate the MAC (MACr) of that message as well and compare it with the received MAC (MACs). If both the MAC match then the client can confidently say that the message was not modified during transmission as only the sender with the symmetric key (K) can generate that MAC. The client can now extract the adjacency matrix in the received message, calculate the road it is currently on based on the its GPS location and determine whether the intended path it needs to take has a green light. The fig. 3 above shows the exchanges needed between the client and the sender to establish an authenticated channel.


The use of asymmetric keys is very resource intensive task. It has a lot of overhead when used for our usage scenario of traffic signal information especially if every message being sent gets encrypted using asymmetric keys. To avoid these resource intensive asymmetric key operations, we use symmetric key based approach for message integrity but that itself does not provide any authentication so a hybrid system of asymmetric and symmetric keys was used. This provides a perfect balance between computation time and security by authenticating the senders well in advance with asymmetric keys before the data messages being sent with MAC computed from symmetric key based approach for data integrity. With this method, the autonomous vehicles will be able to successfully validate the integrity of the traffic signal information received and the authenticity of the sender of the same information.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s