Re: [its] Fwd: comments on vehicular communication drafts

[Alexandre Petrescu <[e-mail]>]

Hi, and thanks for reading through the documents.

Let me reply to some aspects.

> -------- Message transféré -------- Sujet : 	comments on vehicular
> communication drafts Date : 	Sun, 1 Nov 2015 13:08:47 +0000 De :
> George, Wes <[e-mail]> Pour :
> [e-mail] <[e-mail]>,
> [e-mail]
> <[e-mail]>,
> [e-mail]
> <[e-mail]>,
> [e-mail]
> <[e-mail]>
>

> Either way (text quoted from the eCall draft) this gave me pause: O
> The ability to handle text o  The ability for the PSAP to access
> vehicle components (e.g., an onboard camera (such as rear facing or
> blind-spot cameras) for a visual assessment of the crash site
> situation) o  The ability for the PSAP to request the vehicle to take
> actions (e.g., sound the horn, disable the ignition, lock/unlock
> doors)

[PSAP: Public Safety Answering Point, might be an emergency center]

> The security considerations sections need bolstering in light of
> recent revelations around the vulnerability of many CANBUS vehicles
> for attacks via their existing cellular/data connections.

I agree.

> The ability to handle text brings with it the ability to trigger
> buffer overruns and other exploits, and so there should be specific
> discussion about input validation and protection against this attack
>  vector. Accessing and manipulating vehicle components especially
> critical systems is enough of a privacy and safety concern that there
> should be more specific text about how to prevent unauthorized
> access. I think this starts with removing this (IMO) faulty
> assertion: "emergency call placed over a cellular network, there is a
> higher degree of trust that the source is indeed a PSAP" and
> replacing it with something that reinforces the "trust but verify"
> model, since the cellular network, while marginally more secure, is
> subject to call interception and manipulation from a suitably
> motivated and equipped actor, just like any other network. (google
> Stingray, for example) This section should also discuss, in detail,
> what is an acceptable level of security for the certificate to
> validate that the PSAP is authorized to send these sorts of commands,
> whether in call-back or in initial call, whether the payload data
> MUST/SHOULD be encrypted on the path to prevent
> interception/manipulation, and usual certificate based best practices
> such as mandatory to implement (or mandatory to avoid due to proven
> insecurity) algorithms, best practices for keyrolls, cert revocation,
> etc. as well as probably some text about general security best
> practices (remote software updates, third-party pentesting, airgaps,
> signed software, etc). There's no reason to reinvent this, but you
> need to reference existing IETF standards defining this for e.g. TLS,
> PKI, etc. and adapt where appropriate.

Yes, the tools available at IETF should be referenced, such as the basic
IPsec, TLS tools, and PKI concepts.


> Automakers have demonstrated on multiple occasions that they either
> don't understand these aspects of security in the connected car or
> don't understand why it's important, (e.g BMW not using HTTPS) so
> erring on the side of too much info is IMO the right model, because
> we have no reason to believe that the other SDOs involved in this
> effort will possess the standards and expertise, nor motivation to
> document it properly.

Work was performed recently to adapt TLS to vehicular-specific
certificates such as defined by IEEE and ETSI ITS:
draft-lonc-tls-certieee1609-01.txt
This was presented in a TLS session in Prague.

Is there any other vehicular security specific work at IETF?

Other vehicular related SDOs such as ISO TC204 start as we speak to
consider the use of such tools, refraining from defining new ones.

> In the case of the Petrescu drafts, explicit language identifying
> the system as read-only would probably limit the exposure to some of
> the concerns I raised above specific to manipulating important
> systems as described in the eCall drafts,

Sorry, what do you mean by identifying the system as read-only?

In the V2V use-cases such as CACC/Platooning we have an effort ongoing
to understand the relationship with V2I.  Namely, how should the IP path
establishment tools of V2V be involved when communicating with the
immediate infrastructure, how should the downwards path from the
Internet be considered.

In some prototype demonstrators the V2V protocol paths are commpletely
independent of the V2Internet paths (e.g. two different disconnected
boxes in the car, one in charge of V2V other for V2I).  The V2I boxes do
run TLS with certificates.  And, specific vehicular industry activities
consider seriously the establishment of a "vehicular PKI" which is
independent of the typical Internet PKI, with some prototype
demonstrators in Europe.

This raises several questions:

1. Can two boxes in a car be disconnected from each other?

2. How should the V2V tools be used to communicate with the immediate
    fixed infrastructure?

3. Can an independent PKI be used specifically for vehicles?


> but ultimately due to the interconnectedness of these systems within
> the vehicle and these drafts, it might make more sense to assume that
> this opens a new attack vector to pivot through systems via V2V
> communications, and discuss ways to harden the overall system
> accordingly.

I agree.  Given one hacked car, if it is V2V-connected to other cars it
leads to an amplified risk.

> I am by no means a security expert, so I'm sure that there's more
> I'm missing. It may be useful to ask for an early security
> directorate review for this set of drafts, or even to ask the
> Security ADs to suggest one or more security folks that you can ask
> to assist in fleshing out the security considerations.

I will ask this around.

> You're also missing an opportunity to suggest that if this uses IP
> networking, that it MUST support IPv6, given the number of devices
> expected to be present, the timeline for deployment, etc.

For the ITS problem statement we do assume IPv6 whenever we write IP.
In the Charter proposal I think we mean the current generation of
Internet Protocols is IPv6.

But, one must know that in the current advanced IP-connected cars and
prototypes IPv4 is considered first.  In vehicles where IP has not yet
arrived, IPv4 is already very advanced.  Some car manufacturers depend
on large fixed infrastructure (datacenters) which is IPv4 only.

The immediate infra near the car - the intelligent road - may be more
IPv6 though.

There is a significant amount of work to do to talk IPv6 concepts (as
opposed of IPv4) to car manufacturers.  Some times it may be easier to
propose just IP, regardless of the version.  The word "IPv6" has so much
of other aspects attached to it that are irrelevant to some vehicle
manufacturers.

> While that is not necessarily critical to the function of the
> protocol itself, it definitely bears mentioning as acknowledging the
> reality of applications that want to add hundreds of thousands of IP
> nodes to the mobile data network in the era of exhausted IPv4.

I fully agree, this is a good point.

In some countries IPv6 is largely available through the cellular 
operators, which is an essential link for cars.  In other countries this 
is far from happening.  And cars target markets on a per-country basis, 
as opposed to smartphones for example which are much more able to cross 
borders.

For example, I am wondering whether onstar and ecall migration to IPv6 
is being considered somewhere.  This will be a large effort I think.

Alex

>
>
> Thanks,
>
>
>
> Wes George
>
> Anything below this line has been added by my company’s mail server,
>  I have no control over it. -----------
>
>
>
>
> ________________________________
>
> This E-mail and any of its attachments may contain Time Warner Cable
>  proprietary information, which is privileged, confidential, or
> subject to copyright belonging to Time Warner Cable. This E-mail is
> intended solely for the use of the individual or entity to which it
> is addressed. If you are not the intended recipient of this E-mail,
> you are hereby notified that any dissemination, distribution,
> copying, or action taken in relation to the contents of and
> attachments to this E-mail is strictly prohibited and may be
> unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any
> copy of this E-mail and any printout.
>
>
>
>
>
> _______________________________________________ its mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/its
>