## 5 Results  
The Angoka security software is adaptable to a variety of packet-based communications protocols. It was adapted to integrate into the University's V2I system. Planning and software development took place over a period of several weeks. This was followed up with onsite integration testing and trial runs prior to the final tests and demonstrations to project partners. During the integration and debugging phase, the messages circulating in the V2I system can be monitored and logged; see Listing 1 for a CPM message received in the system. Logged data are time-stamped with the internal system data and time (seen in the square brackets). Figure 6: In this image, (**A**) is the Angoka V2I ZAP security system and it is installed alongside (**B**), which is the University of Warwick’s V2I systems controller. The image was taken by AirQKD’s project partner, Angoka. The planned route for the test vehicle is shown by the green line in Figure 7. Further, the route plan shows the location of the compromised RSU, indicated by the mask icon, and the attacker's desire to influence the driver's route, indicated by the red line. Figure 7: The vehicle’s intended route out of the campus is shown by the green line on this map. However, fake V2I messages cause the vehicle to divert, following the red line back around the campus’s one-way system. The fake V2I messages are transmitted by a compromised RSU or OBU controlled by the attacker, located in the car park indicated by the face mask. Table 2 summarises the tests performed as planned, namely testing the system during unsecured and QKD-secured operations, when operating normally and when being attacked with fake CPMs. The results show that the Angoka security protocol can function with the testbed's V2I system:  
During the normal operation of the system with the Angoka system turned off and the attacker not transmitting, the driver followed the planned green route (see Figure 7). When the attacker transmitted its faked CPM messages, the desired route is shown as blocked, see Figure 8.  
When the route is indicated as not being passable, the driver has no alternative and has to return to the campus's one-way system; see Figure 9.  
To prevent spoofing attacks against the campus's V2I system, the Angoka QKD-secured system is turned on. The RSUs and OBUs within the V2I system are then authenticated and provisioned using the Angoka ZAP protocol to enrol them within a DPN. An unknown vehicle entering the V2I area needs to be similarly authenticated and pro \begin{table}
\begin{tabular}{c c c c} \hline \hline
**Test** & **ZAP Security** & **Faked CPM** & **Outcome** \\ \hline
1 & Off & No & Unsecured normal V2I operation \\
2 & Off & Yes & Driver influenced by faked CPMs \\
3 & On & No & Secured normal V2I operation \\
4 & On & Yes & Secure V2I no faked CPMs seen \\ \hline \hline \end{tabular}
\end{table} 
Table 2: QKD-protected V2I system verification. Figure 8: The CPM map overlay shows (**A**) the research vehicle approaching a campus exit roundabout, and (**B**) faked CPM messages, indicating a blocked exit ahead. visioned. Listing 2 provides a small section of the system log showing a vehicle OBU, initiating the authentication and provisioning process. The testing of the QKD-protected V2I system was presented to the other AirQKD project partners, see Figure 10. This enabled the partners responsible for the FSO-QKD system's development to see the practical use of QKD-derived keys. **Listing 2. ** A vehicle enters the V2I zone and begins the request to join the V2I Device Private Network. 1. 2. 3. 4[1689170271.252408617] ReceiveBTPMessage: Received a BTP message with type 56 5 [1689170271.252923307] HandleReceive: Entered HandleReceive for ITSAdapter. Type is: 56 [1689170271.253247322] HandleReceive: Entered HandleReceive for ZapXTransferAdapterRSU. Type is: 56 [1689170271.253709677] HandleReceive: Entered HandleReceive for ProvisioningZapX adapterRSU.