Download to read offline
![Improved OCPP Transport Protocol
[
2, // MessageType: CALL (Client-to-Server)
"19223201", // RequestId
"BootNotification", // Action
{
"chargingStation": { ... },
"reason": "FirmwareUpdate"
}
]
[
2, // MessageType: CALL (Client-to-Server)
"CSMS", // Destination Node Id or
// Any-/Multicast Address
[ "CS01", "NN01" ], // Network Source Path
"19223201", // RequestId
"BootNotification", // Action
{
"chargingStation": { ... },
"reason": "FirmwareUpdate"
}
]
Additional routing
information within the
JSON transport array
⚠️
Network Source Path
- Record of the Route taken
- Implicit Hop Count
- Implicit Loop Detection
✅](https://image.slidesharecdn.com/fosdem20242024-02-03d-241028153737-f4fb62cf/85/Enhancing-OCPP-with-E2E-Security-and-Binary-Data-Streams-for-a-more-Secure-Energy-Ecosystem-9-320.jpg)
![New OCPP Overlay Networking
CS1
CS2
CSMS1
(CSMS)
⚠️Routing tables in every node
⚠️”AutoLearn” and Gossip based exchange of routing information
✅ Any-/Multicast: Instead of sending data to boxes, we address services
NN
/
LC
CS1: WebSocketServer 1 Connection 1 [Standard Mode]
CS2: WebSocketServer 1 Connection 2 [Standard Mode]
CSMS1: WebSocketClient 1 [Overlay Network
Mode]
CSMS: WebSocketClient 1 [Overlay Network
Mode]
➔ NotifyNetworkTopology(“CS1”, “CS2”)
WS](https://image.slidesharecdn.com/fosdem20242024-02-03d-241028153737-f4fb62cf/85/Enhancing-OCPP-with-E2E-Security-and-Binary-Data-Streams-for-a-more-Secure-Energy-Ecosystem-10-320.jpg)
![Signed Messages and Data
✅ Signatures are part of the OCPP
requests, responses or data structures
(In contrast to OCPP v2.0.1 transport layer signatures)
✅ 0…n signatures allowed
✅ Signatures over different data
representations
✅ Additional meta data within signatures
to be more user friendly
{
// BootNotificationRequest
[...]
"signatures“: [
{
"keyId": "...",
"value": "...",
“algorithm": "secp521r1"|...,
"signingMethod": "json"|"binary"|...,
"encoding": "base64"|"hex"|...,
"name": "...",
"description": "...",
“timestamp": “[ISO8601]",
}
]
}](https://image.slidesharecdn.com/fosdem20242024-02-03d-241028153737-f4fb62cf/85/Enhancing-OCPP-with-E2E-Security-and-Binary-Data-Streams-for-a-more-Secure-Energy-Ecosystem-12-320.jpg)
Uploaded byAchim Friedland
Enhancing OCPP with E2E-Security and Binary Data Streams for a more Secure Energy Ecosystem
The document discusses enhancements to the Open Charge Point Protocol (OCPP) to integrate end-to-end security and support for binary data streams within an energy ecosystem. It outlines proposed changes, including improvements to network communication efficiency, additional command structures, user role definitions, and security enhancements to manage the complexities and security demands of modern charging systems. The author emphasizes the need for robust and secure communication channels to address regulatory requirements and safeguard data integrity in the electric vehicle charging landscape.
More Related Content
Similar to Enhancing OCPP with E2E-Security and Binary Data Streams for a more Secure Energy Ecosystem
Enhancing OCPP with E2E-Security and Binary Data Streams for a more Secure Energy Ecosystem
- 1. Enhancing OCPP with E2E-Securityand Binary Data Streams Open Charing Cloud February 2024 achim.friedland@graphdefined.com …for a more secure energy ecosystem #SecurityByDesign #SichererAlsDasBSIErlaubt
- 2. /me • Studied ComputerScience (medical CS, network security) at TU Ilmenau, Germany • Developing the student campus network, e.g. WLAN Point-to-Point links • Worked for multiple startups (GraphDBs, Renewables, e-Health, PV, EV, …) • Started my own Open Source & Open Data company in 2014
- 3. Historical background CS1 CS2 A dedicatedHTTPS Web Socket connection between multiple Charging Stations (CS) and a single Charging Station Management System (CSMS) CSMS
- 4. Local Networking (Local Proxyin OCPP v2.0.1) CS1 CS2 CSMS ✅ Networking Node (NN) just shares the Internet uplink ✅ Improved network efficiency, lowers monthly costs ⚠️New OCPP commands for network management (optional) ⚠️Charging Stations also offer HTTP Web Socket Access (optional) NN
- 5. Local Controller CS1 CS2 CSMS ✅ LocalController (LC) might have own energy meter(s) for monitoring the Grid Connection Point (GCP) ✅ LC in charge of the Dynamic Load Management (DLM) ✅ LC connected to a Smart Meter Gateway (SMGW, Germany) LC SMGW GCP Energy Meter
- 6. Local Networking/Controllers CS1 CS2 CSMS ⚠️Duplication ofseparate HTTPS Web Socket connections caused by OCPP protocol limitations ❌ Security and privacy issues arise, as HTTPS/TLS is no longer sufficient for end-to-end security! NN / LC
- 7. CSMS Marketing-in-the-Middle CSMS ✅ Web Socketis one (Micro) Service, CSMS is another ✅ Might even be operated by different companies ✅ Spying for analytics while connecting to 1…n “black box” CSMSs ❌ More duplications, more security, privacy & H/A issues Web Sockets CS1 CS2 NN / LC
- 8. Shared Web SocketConnections CSMS ✅ A single shared HTTP Web Socket connection ✅ Improved network efficiency, less load in the backend ⚠️An improved OCPP Transport Protocol is required ⚠️Other protocols like MQTT or kafka are possible Web Sockets or Message Bus CS1 CS2 NN / LC
- 9. Improved OCPP TransportProtocol [ 2, // MessageType: CALL (Client-to-Server) "19223201", // RequestId "BootNotification", // Action { "chargingStation": { ... }, "reason": "FirmwareUpdate" } ] [ 2, // MessageType: CALL (Client-to-Server) "CSMS", // Destination Node Id or // Any-/Multicast Address [ "CS01", "NN01" ], // Network Source Path "19223201", // RequestId "BootNotification", // Action { "chargingStation": { ... }, "reason": "FirmwareUpdate" } ] Additional routing information within the JSON transport array ⚠️ Network Source Path - Record of the Route taken - Implicit Hop Count - Implicit Loop Detection ✅
- 10. New OCPP OverlayNetworking CS1 CS2 CSMS1 (CSMS) ⚠️Routing tables in every node ⚠️”AutoLearn” and Gossip based exchange of routing information ✅ Any-/Multicast: Instead of sending data to boxes, we address services NN / LC CS1: WebSocketServer 1 Connection 1 [Standard Mode] CS2: WebSocketServer 1 Connection 2 [Standard Mode] CSMS1: WebSocketClient 1 [Overlay Network Mode] CSMS: WebSocketClient 1 [Overlay Network Mode] ➔ NotifyNetworkTopology(“CS1”, “CS2”) WS
- 11. Analytics CDRs Realtime POI The new CSMSMicro Service Reality ⚠️Monoliths ➔ Multiple Micro Services of different operators ⚠️Each service might have its own Role Based Access Control (RBAC) ❌ Security and privacy issues arise everywhere! ❌ Traditional OCPP security model is no longer sufficient! Web Sockets or Message Bus CS1 CS2 NN / LC
- 12. Signed Messages andData ✅ Signatures are part of the OCPP requests, responses or data structures (In contrast to OCPP v2.0.1 transport layer signatures) ✅ 0…n signatures allowed ✅ Signatures over different data representations ✅ Additional meta data within signatures to be more user friendly { // BootNotificationRequest [...] "signatures“: [ { "keyId": "...", "value": "...", “algorithm": "secp521r1"|..., "signingMethod": "json"|"binary"|..., "encoding": "base64"|"hex"|..., "name": "...", "description": "...", “timestamp": “[ISO8601]", } ] }
- 13. Signature Policies OUT Whichsignatures must be generated for which request/response, using which data (representation) and private key? IN Which request/response is expected to be signed by which public key(s)? Which signatures, public key chains and rules must be verified?
- 14. User Roles forOCPP • A user role is a collection of OCPP requests having the same security level (admin, tech, operations, …) • A user role defines a collection of public keys allowed to invoke the specified OCPP Requests (Later maybe down to the values of request parameters) • The user role defines which public key can read, write, … variables of the OCPP Device Model (↔ Siemens proposal)
- 15. Binary Data Streams ✅Using HTTPS Web Socket binary frames ✅ Generic File Transfer commands: SendFile, GetFile, … ✅ Safer Firmware uploads, LogFile downloads, … as those use external HTTP(s) requests which expose network security risks ✅ Used for encrypted/tunneled OCPP commands ⚠️Large transfers need a proper message priority scheduling!
- 16. Nice, but why? Manynew End-to-End Communication Use Cases
- 17. German §14a GridLoad Management EMP ⚠️Distribution System Operator reduces the energy consumption ⚠️Regulatory operation based on §14a EnWG (Germany) ⚠️Very complex and “high” security demands (➔ SMGWs 🤡) ⚠️Mandatory secure & transparent information of the CPO/EV driver CSMS CS CS NN DSO Reduce to 6 KW in 1 hour, for 6 hours! Transparen cy SMGW
- 18. German §14a GridLoad Management (vNEXT) EMP ✅ Direct communication between DSO, transparency and CSMS ✅ Avoids infrastructure duplication, reduces complexity, safes costs ⚠️But for this we need significant security & robustness improvements CSMS CS CS NN DSO Future? Transparen cy
- 19. Secure & EfficientSensor Data Streams ⚠️Sending regular measurements for grid load management is a regulated service in Germany (SMGWs et.al) CSMS CS CS NN DSO Smart Meter SMGW Smart Meter Send me measurements every 5 seconds
- 20. Secure & EfficientSensor Data Streams EMP ✅ OCPP v2.1 already defines Periodic Event Streams ✅ We extent this to Binary Periodic Event Streams ✅ We also define a generic “Modbus Transport (Tunnel)” for secure remote access of e.g. Smart Meters via an OCPP Overlay Network CSMS CS CS NN DSO Smart Meter Smart Charging Smart Meter Future?
- 21. Charging Tariffs underAFIR • EV driver must be informed about prices before, during and after a charging session • Tariffs need to be digital, immutable and signed and available on transparency platforms ( This will solve some major German Eichrecht problems ) • OCPP v2.1 will support OCPI++ tariff data structures, but currently without end-to-end-semantics
- 22. Ad hoc chargingunder AFIR • Anonymous EV driver scans a dynamic QR code for payments… • Why not a signed QR code to access a remote display of the charging station? EV drivers want to control their charging sessions via smartphone anyway! • Some proprietary solutions already exist within the market, but all have regulatory, security and privacy issues!
- 23. • The CSMSis no longer the “single source of truth” • CPOs/vendors often do not really know what’s going on and neither AI, nor séances can not solve missing communication and consensus in distributed systems • As OCPP does not provide a generic way to share all information/state changes in a secure way ➔ Often vendor backdoors are used • Like a “remote display” for internals, diagnostics, … Digital Charging Station Twins
- 24. Timestamp MeterId UserId or SessionId MeterValue Public Key Charge Detail Record (CDR) Start-/Stop Time Start-/Stop Meter Value Location Information Tariff Information Session Information Charging Station Signed Meter Values Smart Meter Charging Station Operator Crypto Signature E-Mobility Provider Crypto Signature Transparency Software A Better German Calibration Law ✅ Transparency Software as legally binding “remote display” for the validation of older (public) charging sessions ⚠️Additional meta data should also be signed, e.g. tariffs, load reductions!
- 25. Analytics NCPs CDRs Realtime POI National Contact Points ✅Delivery of POI, statistical & real-time data for publicly funded CSs ✅ NCP as “just another” service within the Overlay Network ❌ No security, privacy or consistency requirements yet defined ✅ Anyway, it would be useful to send only authentic/signed data Web Sockets or Message Bus CS1 CS2 NN / LC
- 26. Analytics CDRs Realtime POI Web Sockets or Message Bus PhysicalAccess (In-)Security ❌ We can not trust anything coming from computers on the street! ⚠️Also content & contextual integrity of messages must be validated ✅ Small project how to secure against insider attacks by . No Physical Access Security Realistic Physical Access Security CS1 CS2 NN / LC
- 27. • All theseOCPP extensions are/will be available as “Open Source Vendor Extensions” on GitHub • OCA Technical Working Group has a very conservative approach on “backward compatibility” and dislikes “breaking” changes :-/ • As usual: Many leechers, very few real contributors ➔ Become an OCA member to improve the situation ;) How to get this into “the market”?
- 28.
Editor's Notes
- #4 The term „Local Proxy“ of OCPP v2.0.1 is unfortunately a bit misleading :-/
- #7 Really not a cleaver architecture, but when the CSMS is a black box, you must handle with those business analytics requirements. Also, companies like this solution to migrate from one CSMS to another CSMS more easily! Neither business analytics, nor marketing are known to care about IT security. Therefore, this must be seen as a major backdoor!
- #8 For this an internal OCA draft exists but shows many drawbacks, e.g. it relied on Source Routing, which is known to scale not very well.
- #9 Shamelessly stolen from the IPv4 Record Route Option of RFC 791 ;)
- #10 - „CSMS1“ is a networking node identification - „CSMS“ is the CSMS service provided by „CSMS1“
- #12 OCPP v2.0.1 also defines singed messages, but it is on the OCPP transport layer, is using JSON WebToken like data structures and duplicates all commands (actions)… which is NOT a scaling solution.
- #13 New OCPP CSMS requests to maintain security policies at charging stations, local controllers, ...
- #14 New OCPP CSMS requests to maintain user roles at charging stations, local controllers, ...
- #16 Overlay Networking End-to-End Signatures and Encryption User Roles Binary Data Streams
- #23 Also, most OCPP commands are not aware, that they might overwrite data already changed by a 3rd party. These kind of commands should be extended to be safe within distributed systems, e.g. like HTTP conditional requests.
- #24 See my FOSDEM 2023 talk
- #25 More or less all statistics for the National Contact Points already exist somewhere within the CPOs Micro Service zoo. The „just“ have to be copied to those remote services.
- #26 Smart City Jena has the same problem: How to validate citizen sensor data and how to control access on Smart City systems in a city full of nerds ;)
- #28 Please use the FOSDEM chat applications for your questions and suggestions, use the issue management on GitHub or send me an e-mail. You can also sponsor our work and the further development of this project on GitHub.