Non-Repudiation and End-to-End Security for Electric-Vehicle - - PowerPoint PPT Presentation

non repudiation and end to end security for electric
SMART_READER_LITE
LIVE PREVIEW

Non-Repudiation and End-to-End Security for Electric-Vehicle - - PowerPoint PPT Presentation

Non-Repudiation and End-to-End Security for Electric-Vehicle Charging Innovative Smart Grid Technologies Europe 2019 September 30 th , 2019 1/40 Pol Van Aubel Authors Pol Van Aubel pol.vanaubel@cs.ru.nl Erik Poll erikpoll@cs.ru.nl This


slide-1
SLIDE 1

Non-Repudiation and End-to-End Security for Electric-Vehicle Charging

Innovative Smart Grid Technologies Europe 2019 September 30th, 2019

1/40 Pol Van Aubel

slide-2
SLIDE 2

Authors

Pol Van Aubel

pol.vanaubel@cs.ru.nl

Erik Poll

erikpoll@cs.ru.nl

Joost Rijneveld

joost@joostrijneveld.nl

This work is supported by the European Regional Development Fund (ERDF), Rijksoverheid, and Province of Gelderland, as part of the project Charge & Go.

2/40 Pol Van Aubel

slide-3
SLIDE 3

Overview

The EV-charging infrastructure The need for security End-to-end security Conclusions

slide-4
SLIDE 4

Where is the EV-charging infrastructure?

Source: openchargemap.io

3/40 Pol Van Aubel

slide-5
SLIDE 5

Where is the EV-charging infrastructure?

Source: openchargemap.io

4/40 Pol Van Aubel

slide-6
SLIDE 6

Where is the EV-charging infrastructure?

Source: openchargemap.io

5/40 Pol Van Aubel

slide-7
SLIDE 7

Where is the EV-charging infrastructure?

Source: openchargemap.io

6/40 Pol Van Aubel

slide-8
SLIDE 8

Where is the EV-charging infrastructure?

Source: openchargemap.io

7/40 Pol Van Aubel

slide-9
SLIDE 9

What is the EV-charging infrastructure?

Source: EV Related Protocol Study – ElaadNL

8/40 Pol Van Aubel

slide-10
SLIDE 10

Most important aspects

  • Many roles, fulfilled by many different parties.

9/40 Pol Van Aubel

slide-11
SLIDE 11

Most important aspects

  • Many roles, fulfilled by many different parties.
  • The only way for some of these to communicate is via other parties.

9/40 Pol Van Aubel

slide-12
SLIDE 12

Overview

The EV-charging infrastructure The need for security End-to-end security Conclusions

slide-13
SLIDE 13

What could go wrong?

  • Fraud

10/40 Pol Van Aubel

slide-14
SLIDE 14

What could go wrong?

  • Fraud
  • Vandalism

10/40 Pol Van Aubel

slide-15
SLIDE 15

What could go wrong?

  • Fraud
  • Vandalism
  • Activism

10/40 Pol Van Aubel

slide-16
SLIDE 16

What could go wrong?

  • Fraud
  • Vandalism
  • Activism

– “Chaos Computer Club hacks e-motor charging stations” https://www.ccc.de/en/updates/2017/e-motor

10/40 Pol Van Aubel

slide-17
SLIDE 17

What could go wrong?

  • Fraud
  • Vandalism
  • Activism

– “Chaos Computer Club hacks e-motor charging stations” https://www.ccc.de/en/updates/2017/e-motor

  • Grid destabilization

10/40 Pol Van Aubel

slide-18
SLIDE 18

What could go wrong?

  • Fraud
  • Vandalism
  • Activism

– “Chaos Computer Club hacks e-motor charging stations” https://www.ccc.de/en/updates/2017/e-motor

  • Grid destabilization

– Horus Scenario: hacking PV-installations https://horusscenario.com/

10/40 Pol Van Aubel

slide-19
SLIDE 19

What could go wrong?

  • Fraud
  • Vandalism
  • Activism

– “Chaos Computer Club hacks e-motor charging stations” https://www.ccc.de/en/updates/2017/e-motor

  • Grid destabilization

– Horus Scenario: hacking PV-installations https://horusscenario.com/ – “Public Plug-in Electric Vehicles + Grid Data: Is a New Cyberattack Vector Viable?” https://arxiv.org/abs/1907.08283

10/40 Pol Van Aubel

slide-20
SLIDE 20

What could go wrong?

  • Privacy breaches

11/40 Pol Van Aubel

slide-21
SLIDE 21

What could go wrong?

  • Privacy breaches

– Customer location is sensitive information!

11/40 Pol Van Aubel

slide-22
SLIDE 22

What could go wrong?

  • Privacy breaches

– Customer location is sensitive information! – What other information should be secret?

11/40 Pol Van Aubel

slide-23
SLIDE 23

What could go wrong?

  • Privacy breaches

– Customer location is sensitive information! – What other information should be secret? – GDPR compliance is not straightforward.

11/40 Pol Van Aubel

slide-24
SLIDE 24

Current state of security

  • Authentication / authorization with RFID cards

12/40 Pol Van Aubel

slide-25
SLIDE 25

Current state of security

  • Authentication / authorization with RFID cards
  • Some TLS, lacking clear instructions

12/40 Pol Van Aubel

slide-26
SLIDE 26

Envisioned state of security

  • Strong authentication using challenge-response

13/40 Pol Van Aubel

slide-27
SLIDE 27

Envisioned state of security

  • Strong authentication using challenge-response
  • TLS everywhere, standardized & specified well

13/40 Pol Van Aubel

slide-28
SLIDE 28

Envisioned state of security

  • Strong authentication using challenge-response
  • TLS everywhere, standardized & specified well
  • Better implementations and testing

13/40 Pol Van Aubel

slide-29
SLIDE 29

Are we done then? CPO

I S O 1 5 1 1 8

eMSP

O C P I O C P P

EV Charge Point

14/40 Pol Van Aubel

slide-30
SLIDE 30

Are we done then? CPO

I S O 1 5 1 1 8

eMSP

O C P I O C P P

EV Charge Point

TLS TLS TLS TLS TLS

15/40 Pol Van Aubel

slide-31
SLIDE 31

We’re not done

  • TLS protects the network traffic between individual parties.

16/40 Pol Van Aubel

slide-32
SLIDE 32

We’re not done

  • TLS protects the network traffic between individual parties.
  • Provides confidentiality and authenticity for the data
  • nly while being communicated between these parties.

16/40 Pol Van Aubel

slide-33
SLIDE 33

Trust

We have to trust that every party

  • doesn’t send what it shouldn’t,

17/40 Pol Van Aubel

slide-34
SLIDE 34

Trust

We have to trust that every party

  • doesn’t send what it shouldn’t,
  • doesn’t change what it relays,

17/40 Pol Van Aubel

slide-35
SLIDE 35

Trust

We have to trust that every party

  • doesn’t send what it shouldn’t,
  • doesn’t change what it relays,
  • doesn’t peek at what it shouldn’t see,

17/40 Pol Van Aubel

slide-36
SLIDE 36

Trust

We have to trust that every party

  • doesn’t send what it shouldn’t,
  • doesn’t change what it relays,
  • doesn’t peek at what it shouldn’t see,
  • doesn’t later dispute sending something,

17/40 Pol Van Aubel

slide-37
SLIDE 37

Trust

We have to trust that every party

  • doesn’t send what it shouldn’t,
  • doesn’t change what it relays,
  • doesn’t peek at what it shouldn’t see,
  • doesn’t later dispute sending something,

for whatever reason.

17/40 Pol Van Aubel

slide-38
SLIDE 38

Overview

The EV-charging infrastructure The need for security End-to-end security Conclusions

slide-39
SLIDE 39

What is end-to-end security?

Main aspects:

  • confidentiality.

18/40 Pol Van Aubel

slide-40
SLIDE 40

What is end-to-end security?

Main aspects:

  • confidentiality.
  • authenticity.

18/40 Pol Van Aubel

slide-41
SLIDE 41

What is end-to-end security?

Main aspects:

  • confidentiality.
  • authenticity.
  • non-repudiation.

18/40 Pol Van Aubel

slide-42
SLIDE 42

What is end-to-end security?

Main aspects:

  • confidentiality.
  • authenticity.
  • non-repudiation.
  • from end to end:

18/40 Pol Van Aubel

slide-43
SLIDE 43

What is end-to-end security?

Main aspects:

  • confidentiality.
  • authenticity.
  • non-repudiation.
  • from end to end:

– from the initial sending party on one side,

18/40 Pol Van Aubel

slide-44
SLIDE 44

What is end-to-end security?

Main aspects:

  • confidentiality.
  • authenticity.
  • non-repudiation.
  • from end to end:

– from the initial sending party on one side, – to the eventual receiving party on the other side,

18/40 Pol Van Aubel

slide-45
SLIDE 45

What is end-to-end security?

Main aspects:

  • confidentiality.
  • authenticity.
  • non-repudiation.
  • from end to end:

– from the initial sending party on one side, – to the eventual receiving party on the other side, – regardless of how many parties are in between.

18/40 Pol Van Aubel

slide-46
SLIDE 46

This is not end-to-end! CPO

I S O 1 5 1 1 8

eMSP

O C P I O C P P

EV Charge Point

TLS TLS TLS TLS TLS

19/40 Pol Van Aubel

slide-47
SLIDE 47

And it doesn’t provide non-repudiation!

  • Long-term guarantee of authenticity

20/40 Pol Van Aubel

slide-48
SLIDE 48

And it doesn’t provide non-repudiation!

  • Long-term guarantee of authenticity
  • Proof that a message was produced by that party

20/40 Pol Van Aubel

slide-49
SLIDE 49

And it doesn’t provide non-repudiation!

  • Long-term guarantee of authenticity
  • Proof that a message was produced by that party

– (very useful in disputes!)

20/40 Pol Van Aubel

slide-50
SLIDE 50

An example message

EV ID Time CP Location Contract ID €/kWh 101 2019-09-30 14:50 51°49'30.6"N 5°52'06.5"E 12501932 0.21 Charge Session Start sent from EV to CPO

21/40 Pol Van Aubel

slide-51
SLIDE 51

An example message

EV ID Time CP Location Contract ID €/kWh 101 2019-09-30 14:50 51°49'30.6"N 5°52'06.5"E 12501932 0.21 Charge Session Start sent from EV to CPO EV ID Time Contract ID €/kWh 101 2019-09-30 14:50 12501932 0.21 Charge Session Start sent from CPO to eMSP

21/40 Pol Van Aubel

slide-52
SLIDE 52

An example message

EV ID Time CP Location Contract ID €/kWh 101 2019-09-30 14:50 51°49'30.6"N 5°52'06.5"E 12501932 0.21 Charge Session Start sent from EV to CPO EV ID Time Contract ID €/kWh 101 2019-09-30 14:50 12501932 0.21 Charge Session Start sent from CPO to eMSP

CP Location is dropped because the eMSP doesn’t need it.

21/40 Pol Van Aubel

slide-53
SLIDE 53

Adding authenticity & non-repudiation – naïvely

EV ID Time CP Location Contract ID €/kWh 101 2019-09-30 14:50 51°49'30.6"N 5°52'06.5"E 12501932 0.21 Charge Session Start sent from EV to CPO

22/40 Pol Van Aubel

slide-54
SLIDE 54

Adding authenticity & non-repudiation – naïvely

EV ID Time CP Location Contract ID €/kWh 101 2019-09-30 14:50 51°49'30.6"N 5°52'06.5"E 12501932 0.21 Charge Session Start sent from EV to CPO EV ID Time Contract ID €/kWh 101 2019-09-30 14:50 12501932 0.21 Charge Session Start sent from CPO to eMSP

22/40 Pol Van Aubel

slide-55
SLIDE 55

Adding authenticity & non-repudiation – naïvely

EV ID Time CP Location Contract ID €/kWh 101 2019-09-30 14:50 51°49'30.6"N 5°52'06.5"E 12501932 0.21 Charge Session Start sent from EV to CPO EV ID Time Contract ID €/kWh 101 2019-09-30 14:50 12501932 0.21 Charge Session Start sent from CPO to eMSP

CP Location cannot be dropped because that invalidates the signature!

22/40 Pol Van Aubel

slide-56
SLIDE 56

Requirements:

  • Authenticity & non-repudiation (signatures)

23/40 Pol Van Aubel

slide-57
SLIDE 57

Requirements:

  • Authenticity & non-repudiation (signatures)
  • End-to-end secrecy (encryption)

23/40 Pol Van Aubel

slide-58
SLIDE 58

Requirements:

  • Authenticity & non-repudiation (signatures)
  • End-to-end secrecy (encryption)
  • Data minimization (omission)

23/40 Pol Van Aubel

slide-59
SLIDE 59

Requirements:

  • Authenticity & non-repudiation (signatures)
  • End-to-end secrecy (encryption)
  • Data minimization (omission)

– GDPR-compliance: data must be removed if no longer needed

23/40 Pol Van Aubel

slide-60
SLIDE 60

Requirements:

  • Authenticity & non-repudiation (signatures)
  • End-to-end secrecy (encryption)
  • Data minimization (omission)

– GDPR-compliance: data must be removed if no longer needed – Hard to achieve with normal signatures

23/40 Pol Van Aubel

slide-61
SLIDE 61

Requirements:

  • Authenticity & non-repudiation (signatures)
  • End-to-end secrecy (encryption)
  • Data minimization (omission)

– GDPR-compliance: data must be removed if no longer needed – Hard to achieve with normal signatures

  • Limited overhead (data billed per byte)

23/40 Pol Van Aubel

slide-62
SLIDE 62

Requirements:

  • Authenticity & non-repudiation (signatures)
  • End-to-end secrecy (encryption)
  • Data minimization (omission)

– GDPR-compliance: data must be removed if no longer needed – Hard to achieve with normal signatures

  • Limited overhead (data billed per byte)
  • Offline operation (some parties may be offline when a message is

sent)

23/40 Pol Van Aubel

slide-63
SLIDE 63

How do we solve this? Two signatures?

EV ID Time Contract ID €/kWh 101 2019-09-30 14:50 12501932 0.21 Charge Session Start sent from EV to CPO EV ID Time CP Location 101 2019-09-30 14:50 51°49'30.6"N 5°52'06.5"E

24/40 Pol Van Aubel

slide-64
SLIDE 64

How do we solve this? Two signatures?

EV ID Time Contract ID €/kWh 101 2019-09-30 14:50 12501932 0.21 Charge Session Start sent from EV to CPO EV ID Time CP Location 101 2019-09-30 14:50 51°49'30.6"N 5°52'06.5"E Contract ID €/kWh 12501932 0.21 Charge Session Start sent from EV to CPO EV ID Time CP Location 101 2019-09-30 14:50 51°49'30.6"N 5°52'06.5"E

24/40 Pol Van Aubel

slide-65
SLIDE 65

How do we solve this? Two signatures?

EV ID Time Contract ID €/kWh 101 2019-09-30 14:50 12501932 0.21 Charge Session Start sent from EV to CPO EV ID Time CP Location 101 2019-09-30 14:50 51°49'30.6"N 5°52'06.5"E Contract ID €/kWh 12501932 0.21 Charge Session Start sent from EV to CPO EV ID Time CP Location 101 2019-09-30 14:50 51°49'30.6"N 5°52'06.5"E Contract ID €/kWh 12501932 0.21 Charge Session Start sent from CPO to eMSP EV ID Time 101 2019-09-30 14:50

24/40 Pol Van Aubel

slide-66
SLIDE 66

This works, but. . .

  • That’s still a lot of overhead

25/40 Pol Van Aubel

slide-67
SLIDE 67

This works, but. . .

  • That’s still a lot of overhead
  • Doesn’t solve data minimization

25/40 Pol Van Aubel

slide-68
SLIDE 68

One signature using a hash tree

Contract ID €/kWh 12501932 0.21 Signed Charge Session Start EV ID Time CP Location 101 2019-09-30 14:50 51°49'30.6"N 5°52'06.5"E

26/40 Pol Van Aubel

slide-69
SLIDE 69

We take the hashes of individual data fields

Contract ID €/kWh 12501932 0.21 Signed Charge Session Start EV ID Time CP Location 101 2019-09-30 14:50 51°49'30.6"N 5°52'06.5"E a81f9da8

27/40 Pol Van Aubel

slide-70
SLIDE 70

Build the collection of hashes. . .

Contract ID €/kWh 12501932 0.21 Signed Charge Session Start EV ID Time CP Location 101 2019-09-30 14:50 51°49'30.6"N 5°52'06.5"E a81f9da8 d32dd76 1338492f

28/40 Pol Van Aubel

slide-71
SLIDE 71

For each party that needs a signature

Contract ID €/kWh 12501932 0.21 Signed Charge Session Start EV ID Time CP Location 101 2019-09-30 14:50 51°49'30.6"N 5°52'06.5"E a81f9da8 d32dd76 1338492f 31fa9918 13aabd8f 2aa81355 433fccd9

29/40 Pol Van Aubel

slide-72
SLIDE 72

Then we hash those collections again. . .

Contract ID €/kWh 12501932 0.21 Signed Charge Session Start EV ID Time CP Location 101 2019-09-30 14:50 51°49'30.6"N 5°52'06.5"E a81f9da8 d32dd76 1338492f 31fa9918 13aabd8f a6189fee 2aa81355 433fccd9

30/40 Pol Van Aubel

slide-73
SLIDE 73

Into a final couple of hashes

Contract ID €/kWh 12501932 0.21 Signed Charge Session Start EV ID Time CP Location 101 2019-09-30 14:50 51°49'30.6"N 5°52'06.5"E a81f9da8 d32dd76 1338492f 31fa9918 13aabd8f a6189fee 8aa19330 2aa81355 433fccd9

31/40 Pol Van Aubel

slide-74
SLIDE 74

And sign those hashes

Contract ID €/kWh 12501932 0.21 Signed Charge Session Start EV ID Time CP Location 101 2019-09-30 14:50 51°49'30.6"N 5°52'06.5"E a81f9da8 d32dd76 1338492f 31fa9918 13aabd8f a6189fee 8aa19330 2aa81355 433fccd9

32/40 Pol Van Aubel

slide-75
SLIDE 75

Overhead is minimized

Contract ID €/kWh Apf8da;w3 23gaw Signed Charge Session Start sent by EV to CPO EV ID Time 101 2019-09-30 14:50 CP Location 51°49'30.6"N 5°52'06.5"E 8aa19330 eMSP Hash

33/40 Pol Van Aubel

slide-76
SLIDE 76

CPO verification

Contract ID €/kWh Apf8da;w3 23gaw Signed Charge Session Start verified by CPO EV ID Time 101 2019-09-30 14:50 CP Location 51°49'30.6"N 5°52'06.5"E 8aa19330 eMSP Hash a81f9da8 d32dd76 1338492f

34/40 Pol Van Aubel

slide-77
SLIDE 77

CPO verification

Contract ID €/kWh Apf8da;w3 23gaw Signed Charge Session Start verified by CPO EV ID Time 101 2019-09-30 14:50 CP Location 51°49'30.6"N 5°52'06.5"E 8aa19330 eMSP Hash a81f9da8 d32dd76 1338492f a6189fee 8aa19330

35/40 Pol Van Aubel

slide-78
SLIDE 78

Dropping & encrypting data now works

Contract ID €/kWh Apf8da;w3 23gaw Signed Charge Session Start sent by CPO to eMSP EV ID Time 101 2019-09-30 14:50 a6189fee CPO Hash

36/40 Pol Van Aubel

slide-79
SLIDE 79

eMSP verification

Contract ID €/kWh 12501932 0.21 Signed Charge Session Start verified by eMSP EV ID Time 101 2019-09-30 14:50 31fa9918 13aabd8f 2aa81355 433fccd9 a6189fee CPO Hash

37/40 Pol Van Aubel

slide-80
SLIDE 80

eMSP verification

Contract ID €/kWh 12501932 0.21 Signed Charge Session Start verified by eMSP EV ID Time 101 2019-09-30 14:50 31fa9918 13aabd8f a6189fee 8aa19330 2aa81355 433fccd9 a6189fee CPO Hash

38/40 Pol Van Aubel

slide-81
SLIDE 81

Cryptographic details

  • We piggy-back on technologies that have to be present anyway:

– Cryptographic algorithms from TLS – Public key infrastructure – JSON message formatting

39/40 Pol Van Aubel

slide-82
SLIDE 82

Overview

The EV-charging infrastructure The need for security End-to-end security Conclusions

slide-83
SLIDE 83

Conclusions

  • EV-charging infrastructure is complex, with many actors.

40/40 Pol Van Aubel

slide-84
SLIDE 84

Conclusions

  • EV-charging infrastructure is complex, with many actors.
  • Current security practices are not sufficient.

40/40 Pol Van Aubel

slide-85
SLIDE 85

Conclusions

  • EV-charging infrastructure is complex, with many actors.
  • Current security practices are not sufficient.
  • Employing TLS everywhere is a necessary improvement, but

40/40 Pol Van Aubel

slide-86
SLIDE 86

Conclusions

  • EV-charging infrastructure is complex, with many actors.
  • Current security practices are not sufficient.
  • Employing TLS everywhere is a necessary improvement, but
  • TLS alone is not sufficient: We need true end-to-end security.

40/40 Pol Van Aubel

slide-87
SLIDE 87

Conclusions

  • EV-charging infrastructure is complex, with many actors.
  • Current security practices are not sufficient.
  • Employing TLS everywhere is a necessary improvement, but
  • TLS alone is not sufficient: We need true end-to-end security.
  • This can be achieved using hash trees and selective encryption.

40/40 Pol Van Aubel

slide-88
SLIDE 88

Conclusions

  • EV-charging infrastructure is complex, with many actors.
  • Current security practices are not sufficient.
  • Employing TLS everywhere is a necessary improvement, but
  • TLS alone is not sufficient: We need true end-to-end security.
  • This can be achieved using hash trees and selective encryption.
  • Protocols will need to be changed to deal with this.

40/40 Pol Van Aubel

slide-89
SLIDE 89

Conclusions

  • EV-charging infrastructure is complex, with many actors.
  • Current security practices are not sufficient.
  • Employing TLS everywhere is a necessary improvement, but
  • TLS alone is not sufficient: We need true end-to-end security.
  • This can be achieved using hash trees and selective encryption.
  • Protocols will need to be changed to deal with this.
  • The industry needs to agree on which party should see what data.

40/40 Pol Van Aubel

slide-90
SLIDE 90

Conclusions

  • EV-charging infrastructure is complex, with many actors.
  • Current security practices are not sufficient.
  • Employing TLS everywhere is a necessary improvement, but
  • TLS alone is not sufficient: We need true end-to-end security.
  • This can be achieved using hash trees and selective encryption.
  • Protocols will need to be changed to deal with this.
  • The industry needs to agree on which party should see what data.
  • This scheme works in other cases with similar requirements.

40/40 Pol Van Aubel