Position Paper for the IoT Semantic Interoperability Workshop Vehicle-to-Vehicle and Vehicle-to-Infrastructure Communications Russ Housley 1. Introduction Vehicle-to-vehicle (V2V) communications are an interesting part of the Internet of Things (IoT). V2V communications can improve safety by giving the driver information about things that are happening in neighboring vehicles. Warnings about rapid deceleration or hard braking can give a driver additional time to react, and in some instances the vehicle may apply the brakes automatically. Vehicle-to-infrastructure (V2I) communications also improve safety. Information about traffic signal timing, warnings of speed limit changes, and warnings about upcoming weather conditions like fog can give the driver an opportunity to avoid an unsafe situation. I have made contributions to the security and privacy of V2V and V2I communications over the last 13 years. V2V and V2I communications standards are being developed in many different Standards-developing organizations (SDOs). The list of SDOs includes ASTM, ETSI, ISO, IEEE, and perhaps the IETF. The IETF will hold the Intelligent Transportation Systems (ITS) BoF at IETF 95 to decide wether the IETF is the right place to work on some of these standards. The protocols developed in IEEE and ETSI are not interoperable. However, the work being suggested by the ITS BoF could provide a bridge between these environments. Application layer interoperability must be achieved in order to realize all of the safety benefits envisioned by V2V and V2I communications. I would like to see these goals realized without too big a sacrifice to privacy or security. Designers of information models for connected vehicles need to remember that people own these vehicles and the data that they gather. As Stephen Farrell and Alissa Cooper have pointed out [1], these vehicle owners expect the vehicle to work for them, not against them. 2. Privacy To achieve the safety goals, vehicles will be transmitting information that could be used against its owner. For instance, if vehicles [Page 1] transmit their location, speed, and identity, it would be possible for others to collect information about their movements. Enabling straightforward tracking would be a privacy disaster. For this reason, some anonymity capabilities are included in the protocols and infrastructure, basically hiding the identity of the radio device in each vehicle. Even so, the safety goals cannot be achieved in a completely anonymous environment. Some applications must be able to determine that messages have a common origin. This can be done in a manner that enables the linking of messages within short time windows, but avoid excessive linking over long periods. While the information in the transmitted messages is inherently public, the identity of the radio device within the vehicle that needs to be kept private to avoid tracking. 3. Plan for Some Compromise or Failure Designers should assumed that the radio devices within some vehicles will be compromised in some manner. An attacker might cause a compromised device to transmit incorrect messages, or an attacker may recover the cryptographic keying from the device. Recovering from such compromises requires that legitimate devices are able to determine which devices have been compromised and ignore future messages from them. Please note the direct contradiction with the privacy goals discussed in Section 2 of this paper. The compromise recovery mechanisms might necessarily thwart the privacy protections until the compromised device can be repaired. 4. Failures Will Occur Sometimes a radio device in a vehicle will doubt the correctness of a received message. Perhaps the device is getting contradictory information from more than one other source. This might be a reason to suspect compromise, but it could just as well be a malfunction in the sending device. It is not entirely clear how to handle suspect messages. Some mechanism for sharing suspicions could facilitate a reputation system to identify failed devices. Once again, please note the direct contradiction with the privacy goals discussed in Section 2 of this paper. An identity is needed to have an effective reputation system. Reputation mechanisms might necessarily thwart the privacy protections until the failed device can be repaired. 5. Denial of Service Radio devices within vehicles should be able to withstand denial of service (DoS) attacks. For example, an attacker might jam all the [Page 2] radios in a particular geographic location or send many, many messages to individual radio devices to prevent them from sending or receiving legitimate messages. It is extremely difficult to defend against DoS attacks. Even so, designers should keep them in mind to avoid making them any easier for the attacker. 6. Summary Vehicles are part of the IoT, as is the infrastructure being deployed to support connected vehicles. V2V and V2I communications offer some significant privacy challenges, and some mechanisms to thwart privacy may be needed to manage compromise and failure in the system. Reference [1] Farrell, S., and A. Cooper, "It's Often True: Security's Ignored (IOTSI) - and Privacy too", work in progress, February 2016. [Page 3]