Subject: [its] does MANET or ITS scope extend to EV charging stations with internet backend?

From: Alison Chaiken <[email-masked]>
Date: Mon, 22 Apr 2013 09:51:26 -0700

If so, this "Infosec Risks of Charging Electric Cars" presentation may
be relevant:

http://conference.hitb.org/hitbsecconf2013ams/materials/D2T2%20-%20Ofer%20Shezaf%20-%20The%20Infosec%20Risks%20of%20Charging%20Electric%20Cars.pdf
»

-- 
Alison Chaiken                           [email-masked]
650-279-5600                            http://{she-devel.com,
exerciseforthereader.org}
The intermediary between the head and the hands must be the heart.
-- Thea von Harbou

---

From: Rex Buddenberg <[email-masked]>
Date: Mon, 22 Apr 2013 11:06:27 -0700

Alison,

You have a (quite common) non-sequitor.  Foggy thinking vis security.

Almost all of the  briefing has to do with content security -- content
authentication and content confidentiality.  The scope of these security
needs is almost always end-to-end, meaning that they can only be
addressed at layer 6/7.

By contrast, MANET protocols are layer 3 protocols.  The security
measures being worked for the MANET (and LOADng) have to do with routing
table integrity.  Not content integrity.  

Figures 25 and 27 in the deck show the problem quite clearly: the pcb
board and the charging station are end systems.  Which puts them outside
the scope of the MANET security measures.  

The way to sort this out; map onto the ISO model:

Layer | object protected | scope        | example
------------------------------------------------
6/7   | content msg      | end-to-end   | S/MIME, ssh
- - - - - - - - - - - - - - - - - - - - - - - - -
4/5   | session          |socket-socket | SSL
- - - - - - - - - - - - - - - - - - - - - - - - -
3     | IP datagram      | enclave      | VPN
- - - - - - - - - - - - - - - - - - - - - - - - -
1/2   | frame            |single segment| WPI
- - - - - - - - - - - - - - - - - - - - - - - - -

We're agreeing that the content needs to be protected, to prevent theft,
for example.  The correct remedy for that is authenticity of the
content, map onto the layer 6/7 line in the chart.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 23 Apr 2013 09:43:54 +0200

Le 22/04/2013 18:51, Alison Chaiken a écrit :
> If so, this "Infosec Risks of Charging Electric Cars" presentation
> may be relevant:
>

Allison,

Thanks for forwarding the presentation.

I dont remember quite well, but I think there may exist efforts to make
IPv6 work over EV charging station specifics, similar to what IPv6 works
over PLC (power-line communications) at home.  This includes but is not
limited to IPv6 address auto-configuration between the vehicle and the
charging station, such that the EV gets access to Internet via that cable.

There are additional expectations about getting to Internet via such
charging stations or any other similar post for payment or for
authentication.  I have seen it with RFID auth and/or payment slots for
bicycles, combustion-engine parking space, etc.  The security of that
may be the existing WiFi security.

Are there end-to-end security risks about this - I guess yes.  Letting
aside the risks of initial innocent deployments assuming everyone is
kind, there may exist risks related to lack of security features in
protocols.  These could be identified.

Is the assumed security of the cable (as opposed to wireless) leading to
lack of IP protocol security on that cable?  Could I build a Y out of
that cable and do Man-in-the-Middle? Or will ND security protect this?

Alex

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Apr 2013 09:10:31 -0400

>>>>> "Alexandru" == Alexandru Petrescu <[email-masked]> writes:
    >> If so, this "Infosec Risks of Charging Electric Cars"
    >> presentation may be relevant:
    >> 

    Alexandru> Allison,

    Alexandru> Thanks for forwarding the presentation.

Thanks also from me.  

I think that the risks of physical attack require a rethink of the processes.

Some lessons may perhaps be learnt from Kerberos history and MIT's Project
Athena:  it was assumed that all workstations would be rooted trivially,
and thus students were expected to reboot them from the network on each
use, and the workstation did not have any priviledges that the student
didn't give to it through kerberos.

    Alexandru> Is the assumed security of the cable (as opposed to
    Alexandru> wireless) leading to lack of IP protocol security on that
    Alexandru> cable?  Could I build a Y out of that cable and do
    Alexandru> Man-in-the-Middle? Or will ND security protect this?

It's seems that it's not the cable that is the end points of the
required security, but rather, driver<->grid security.  The car and the
charging station need to have priviledge delegated to them, not vv.

(The car can not be trusted for a variety or reasons: car sharing being
the most obvious non-malicious case.  In Ottawa, the first Plug-in
Electric outlets in "public" places are for the car sharing company. The
driver is not trusted, as the billing relationship is between utility
and car sharing co-op, not driver.  I haven't driven one of them yet, 
but I did take the mandatory online training course)

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [