implementing wpt according to iso 15118 · 2018-10-02 · bitfield, indicating support for ac, dc,...

V1.0 | 2018-04-11

An overview over the challenges of implementing WPT with PnC compared to AC/DC with EIM only

Implementing Inductive Charging according to ISO 15118 ED2 DIS

2 © 2018. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector. V1.0 | 2018-04-11

u What’s New?

Wireless Communication

Introducing Plug n’ Charge

Wireless Power Transfer

Conclusion

Agenda


u Supported energy transfer modes

u AC Charging> Single phase

> Three phase

u DC Charging> DC extended

> DC core

u Supported identification modes

u External Identification Means (EIM)> RFID cards, smartphone apps, credit cards, etc.

u Plug n’ Charge> X509.v3 certificates

u Supported security profiles

u No security

u TLS secured

Retrospect of ISO 15118 ED1

What’s New?


u New energy transfer modes

u Bidirectional Power Transfer (BPT)

u Automatic Charging Device (ACD)

u Wireless Power Transfer (WPT)

u New physical layer

u IEEE 802.11n

u Changed service negotiation

u All parameters that possible lead to incompatibility are negotiated at the beginning

u Changed Renegotiation & Metering Receipt

u Renegotiation and Metering Receipt are now multiplexed with the charging loop

u Changed security profiles

u TLS mandatory, all the time

Innovations of ISO 15118 ED2

What’s New?


u Changes compared to currently used conductive charging

u Different message set> Wireless Power Transfer for inductive charging

u Different physical layer> IEEE 802.11n for Wireless Communication

u “New” security profile> Transport Layer Security (TLS)

u “New” identification method> Plug n’ Charge (PnC)

Challenges of Implementing Inductive Charging

What’s New?


What’s New?

u Wireless Communication



Conclusion

Agenda


u ANSI/IEEE 802.11n-2009

u Also known as Wi-Fi

u Broadly used in the consumer industry

u Supported by almost every laptop, smartphone, etc.

u Many Wi-Fi chips available from different semiconductor manufacturers that support 802.11n

u Consumer Wi-Fi router may be used as access point for SECC

u Open Source Firmware available, for example OpenWrt or DD-WRT

IEEE 802.11n



u Wi-Fi chips usually have an SDIO interface

Automotive microcontrollers usually have only an SPI interface> SDIO interfaces can potentially be operated in an

SPI mode, might not always be supported

u SDIO interface would support high data rate of Wi-Fi, SPI only has a very limited data rate

u Wi-Fi is a shared medium

u PLC only had two nodes per medium (PLC), Wi-Fi potentially has hundreds

u High packet drop possible

u Many attack vectors for denial of service (DOS) attacks

u ISO 15118-8 defines requirements for Wi-Fi

u Vendor Specific Element (VSE)> Contains information about the types of EVSEs

that are available at this location

Stock Wi-Fi drivers are usually not able to set or get the VSE

u No MAC layer encryption is used> No access control on Wi-Fi level

> Firewall will be necessary to control traffic

> Rules are defined in ISO 15118-2 ED2

> Value Added Services (VAS) will be difficult to authorize for SECC, as open port shall only be used by authorized EVCCs

> Process described in ISO 15118-2 ED2

Requirements



Field Description

Element ID Fixed value, defined by IEEE 802.11

Length Size of the following fields

Organization ID

A unique identifier for the ISO 15118 series assigned by the IEEE

Element Type Version information of the ISO 15118-8

Energy Transfer Type

Bitfield, indicating support for AC, DC, WPT and ACD

Country Code Two byte country code according to ISO 3166-1

Operator IDOperator ID, defined by ISO 15118-2, issued by national authority

Charging Site ID

Can be freely defined by the Operator

Additional Information

UTF-8 encoded, provides the possibility to add detailed information

Vendor Specific Element of ISO 15118


EID

0xDD

Length

0x11

Organizational ID

0x0123456789

Type

0x01

ETT

0x03

Country Code

0x4445

Operator ID

0x58595A

Charging Site ID

0x0123456789

u Basic Layout of VSE (see left table)

u Additional information

u Different parameters for AC, DC, WPT & ACD> AC & DC: Type of connector, number of phases

> WPT: Gap class, power class

u Example> AC:C=1|WPT:Z=2:P=1,2


Situation Wi-Fi

u Wi-Fi is natively supported by laptops

u Wi-Fi to USB adapters are broadly available

u Communication over a shared medium, everyone is able to trace the communication

u Mandatory TLS encryption will lead to new challenges

u Tools are able to decrypt TLS communication, in case secret can be provided

Production EVs and SEs will not offer a method to extract the secret

How to decrypt TLS communication?

How to differentiate charge loop messages from parallel renegotiation, metering, etc.?

Tracing Wi-Fi communication will not be any easier

Situation PLC

u Adapters for PLC to ETH not broadly available

Special equipment needed to be developed “just” for tracing CCS communication

u “Man in the middle” setups tend to alter the behavior

Tracing only possible to a certain extent

u Special configurations for EVCC or SECC that mirror the PLC data

u Improves tracing

u Usually not available for production

Tracing the PLC communication between a real EV and SE was/is not easily possible

Tracing



What’s New?


u Introducing Plug n’ Charge


Conclusion

Agenda


u Introducing certificates into the EVCC

u Private key of the Provisioning Certificate needs to be securely installed into the EVCC> Possibly also private key of Contract Certificate

u Will Provisioning Certificate be installed at Tier1 or OEM?

u How will the private key be securely transmitted to the EVCC?

u Securely storing certificate data

u How to protect crypto material?> Private key from read access and modification

> Certificates from modification

u Public Key Infrastructure (PKI)

u V2G PKI used by> Charge Point Operators

> Issue SECC certificates

> Certificate Provisioning Service

> Issue certificates used for Certificate Installation

u MO PKI used by> Mobility Operator

> Issues Contract Certificates

u OEM PKI used by> Vehicle Manufacturer

> Issues OEM Provisioning Certificates

u Running a PKI is not an easy task

u Will all PKIs be run independently?

u How many PKIs will there be?> One per continent/country/consortium?

u Who will run them?

Requirements



u Requirements

u Semiconductor manufacturer> Provides a list containing all UIDs of the HSMs

u OEM> For all UIDs, the OEM creates the artifacts

> Master ECU Key

> Certificate

> Public/Private Key Pair

> For development, those artifacts will be the same for all ECUs

> For production, for each UID a specific set of artifacts needs to be created

u Assumptions

u Local creation of public/private key pair is not possible, as no online connection is available

u Provisioning Certificates and private keys shall be created and controlled by OEM

u Tier1 shall have no access to private keys in an unencrypted format

u Goals

u Protect private key from creation until installation in EVCC

End-to-end encryption required

Secure Installation of Private Keys


u Process

u Install Master ECU Key via SHE v1.1 Key (Memory) Update Protocol

u Transmit encrypted Public/Private Key Pair container to ECU> ECU decrypts the container using the Master ECU Key

u ECU stores decrypted Private Key in the crypto stack


u HSM present

HSM is able to store sensitive data and calculate cryptographic algorithms

Memory protected by HSM> RAM as well as NVRAM are protected from

unauthorized access

HSM calculates with its own core, host-controller is free to process other tasks

Acceleration of asymmetric cryptography possible

u Neither SHE nor HSM present

Everything will be stored and calculated on the host-controller

Sensitive data (e.g. private keys) cannot be protected

Slow calculation of symmetric and asymmetric algorithms, blocking host-controller

u SHE present

Everything will be stored on host-controller, symmetric operations accelerated by SHE

Sensitive data can be protected by encrypting the data before storing it in the NVRAM

Sensitive data is still unprotected in RAM

Most common, symmetric cryptography accelerated by SHE

Asymmetric cryptography still on host-controller in software

Secure Storage of Crypto Material



What’s New?



u Wireless Power Transfer

Conclusion

Agenda


u Messages with parameter definition

u FinePositioningSetupReq/Res

u FinePositioningReq/Res

u Messages still in “generic” stage

u PairingReq/Res

u AlignmentCheckReq/Res

u Long parameter list during service negotiation

u Power Class, Ground Clearance, Operating Frequency, Geometry, Circuit Topology, Manufacturer-specific data, etc.

Compatibility between systems from different manufacturers?

ISO 15118 “too soon” for IEC 61980 and ISO 19363?

Status of Message Set


PairingResType

PairingRes

ResponseCode

EVSEStatus

EVSEProcessing

PairingParameters

PairingReqType

PairingReq

EVProcessing

PairingParameters


Fine Positioning



What’s New?




u Conclusion

Agenda


u Upcoming challenges for …

u EVs supporting PnC> Secure storage of sensitive data required

> Public Key Infrastructure necessary

u EVs supporting Wireless Power Transfer> Important mechanisms such as Fine Positioning

are not finalized yet

> Wi-Fi communication

> Selection of Wi-Fi chips

> Interface to host controller?

> How to create traces?

> Especially when TLS encryption is being used

u Current Situation

u DIN SPEC 70121 is still the most commonly used CCS standard> No encryption

> No certificates

u Difficulties with PLC have been “mastered”

u Tracing tools available for PLC

Current Situation & Outlook

Conclusion


Author:Eisele, FabianVector Germany

Your questions are welcome!

http://www.vector.com/

implementing wpt according to iso 15118 · 2018-10-02 · bitfield, indicating support for ac, dc,...

Documents