Vehicle-to-Vehicle and Vehicle-to-Infrastructure Communications
slides-iotsiws-vehicle-to-vehicle-and-vehicle-to-infrastructure-communications-00

     Position Paper for the IoT Semantic Interoperability Workshop

    Vehicle-to-Vehicle and Vehicle-to-Infrastructure Communications

                              Russ Housley
                         <housley@vigilsec.com>


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.
     <draft-farrell-iotsi-00.txt>

































                                                                [Page 3]