With the rapid expansion of EV infrastructure, a massive technical debt has emerged: millions of legacy charging stations are operating on early Open Charge Point Protocol (OCPP 1.5 or 1.6J) versions. They primarily run on Security Profile 0 or 1, meaning all critical data (RFID tags, billing meters, remote commands) is transmitted over standard WebSocket (ws://) in plain text.
Recent regulations, such as the UK’s Smart Charge Points Regulations and the EU’s RED (EN18031), now strictly mandate encrypted communications (mTLS, or OCPP Security Profile 3). The obvious software engineering answer would be an Over-The-Air (OTA) firmware update. But out in the field, we hit a hard physical wall.
The Hardware Wall: Why OTA Fails on Cortex-M3/M4
Early EV chargers were built with highly resource-constrained embedded microcontrollers (MCUs) to control costs. Upgrading from plain text to Profile 3 (mTLS) isn't just a configuration flip; it triggers a severe "Crypto-Agility" crisis.
The RAM Bottleneck: Traditional non-secure mode requires < 10 KB of RAM for the TCP/IP stack. However, modern TLS 1.2/1.3 protocol stacks (even optimized ones like mbedTLS or WolfSSL) require 50-100 KB of heap memory to cache the certificate chain and encryption context during the handshake. On an MCU with only a few hundred KB of RAM, enabling TLS starves the core charging logic, leading to memory overflows and watchdog resets.
CPU Overhead: The TLS handshake involves computationally intensive asymmetric encryption (RSA or ECC). On these low-power MCUs, a handshake can take several seconds. If the network drops (common in 4G IoT), frequent reconnections peg the CPU, delaying real-time charging control tasks and triggering watchdog timeouts.
Flash limitations: Profile 3 requires mTLS, meaning the device needs a secure enclave to store private keys and enough Flash space to dynamically update Root CA lists. Legacy file systems simply do not have this capacity.
The Architectural Fix: Transparent Edge Proxy
Faced with the "rip and replace" economics (which costs up to $210,000+ for a DC Fast Charger site including civil works and power upgrades), we explored alternative architectures. A "Cloud-to-Cloud" proxy doesn't solve the first-mile interception risk on the local LAN or ISP.
The solution we engineered is a hardware-based transparent edge proxy gateway. It acts as a "security coprocessor" deployed inside the charger's cabinet.
Bi-directional Protocol Conversion: The gateway runs a high-performance embedded Linux environment. Southbound, it simulates a local CSMS, accepting the legacy Profile 1 (ws://) connection over the internal LAN. Northbound, it acts as the true OCPP client, initiating a Profile 3 (wss://) mTLS tunnel to the cloud. The dumb terminal thinks it's talking to an insecure server, while the cloud sees a fully compliant mTLS client.
Decoupling Certificate Management: Legacy chargers don't support the ACME protocol for certificate rotation. The gateway intercepts SignCertificate.req and InstallCertificate.req commands from the cloud. It generates the CSR, manages private keys, and updates Root CAs on behalf of the legacy charger, making the entire certificate lifecycle transparent to the old hardware.
Beyond TLS: Logic Injection for Legacy Gear
By placing compute at the edge, we unlocked unexpected capabilities. Older OCPP 1.6J chargers cannot handle complex Smart Charging profiles. By acting as a Local Controller, the gateway can ingest complex Time-of-Use (TOU) or OCPP 2.0.1 load-balancing policies from the cloud, parse them, and inject simple rate-limiting commands (SetChargingProfile) that the legacy 1.6J MCU can understand.
Additionally, because the edge proxy implements EN18031 standards, it can run a local Intrusion Detection System (IDS) to block LAN-based DoS attacks, preventing malicious traffic from exhausting the fragile legacy MCU.
By offloading cryptography and complex logic to an edge proxy, we can bridge the gap between insufficient embedded hardware and modern security regulations, preventing millions of functional chargers from becoming premature e-waste.
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (0)