Closing the CCS2 EV Charger Attack Surface: SSH Keys and mTLS-Only Backend Connections with TROPIC01

‍

The wake-up call

A few weeks ago, the team at Saiflow published a piece of research that every EV charging vendor should read twice - https://www.saiflow.com/blog/the-hidden-ccs2-attack-surface-on-ev-chargers.
They plugged into an XCharge C6 charger and found SSH and Telnet listening on every network interface, including the powerline link that talks to the car. The login was root:root. No rate limiting, no lockout, nothing. Plug in a $130 rig built from a Raspberry Pi and a HomePlug modem, and you're root on the charger in minutes.

We want to be clear about something first: this is good security research, done the right way. Saiflow disclosed responsibly, XCharge shipped a fix, and the blog itself says the pattern - services bound to all interfaces, default creds, no separation between management and operational networks - shows up across the whole industry, not just one vendor. That's the point of this post. Not to point fingers, but to talk through how a charger should be built so this class of bug simply can't happen, using a secure element like TROPIC01 to anchor SSH and backend authentication in hardware instead of passwords.

Credit is due all around here: to the researchers for doing the legwork and publishing it openly, and to the vendor for treating it as an engineering problem to fix rather than a PR problem to bury.

‍

Why "just add a password policy" isn't the fix

The instinct after reading a report like this is "okay, let's enforce strong unique passwords." That helps, but it's treating the symptom. The real issue is that SSH access to a charger's DCB (the compute board behind the CCS2 plug) was ever meant to depend on a secret that a human or a script types in. Secrets like that get reused, hardcoded, leaked in firmware images, or brute-forced. What you actually want is for the charger to only talk SSH to something that can prove it holds a specific private key - and for that private key to live somewhere no attacker can ever extract it, even with full root on the Linux side.

That's exactly the gap a secure element like TROPIC01 is built to close.

‍

Hardening SSH: keys in TROPIC01, not on disk

Here's the core idea. Instead of a password, or even a normal SSH key sitting in a file on someone's laptop, the private key used to authenticate lives inside TROPIC01's protected memory and never leaves it. TROPIC01 does the signing internally - the host only ever sees the result.

‍

On the client / operator side

Whoever needs to SSH into a charger for maintenance - a field technician's laptop, a fleet management jump box, a CI pipeline - holds their private key inside a TROPIC01 chip (or a TROPIC01-backed hardware token), not in ~/.ssh/id_rsa. This is wired into OpenSSH through PKCS#11: ssh-keygen -D reads out the public key from the module, and ssh-add -s registers the token with ssh-agent so that every signing operation during authentication is delegated straight to TROPIC01. The private key is never loaded into RAM, never touches the filesystem, and can't be copied off the laptop even if the laptop itself is compromised.

Practically, this means:

• A stolen laptop or a malware infection can't exfiltrate the SSH credential - there's nothing to steal, only a chip to physically hold.
• Losing the device revokes the credential instantly; there's no key file floating around in backups or old disk images.
• Credential reuse across techs or fleets goes away, because each TROPIC01 has its own unique key pair generated inside the chip.

‍

On the charger side: immutable public keys, not shared secrets

Now flip to the charger. The charger doesn't need to trust a list of passwords or even a growing pile of individual public keys pasted into authorized_keys. Instead, the SSH daemon verifies incoming certificates against the User CA public key via the standard TrustedUserCAKeys directive. Rather than relying on a mutable configuration file on disk that a local attacker might modify, the CA public key and sshd_config reside on a read-only root partition cryptographically locked with dm-verity . The integrity of this entire operating system image and kernel chain is anchored directly in TROPIC01 through hardware-enforced Secure Boot (e.g., using wolfBoot or mcuBoot integration) . Because the charger’s bootloader cryptographically validates the entire software chain against the immutable public keys in TROPIC01 before execution, an attacker with physical access or runtime root privileges cannot tamper with the CA trust anchors or downgrade the authentication policy

‍

The charger talks outward too: authenticating to billing and backend systems

SSH is about someone getting into the charger. But the charger itself is constantly reaching out - to a Charging Station Management System (CSMS) for OCPP session control, and through the CPO's backend to billing and roaming platforms (OCPI/OICP hubs like Hubject) that settle payments across networks. That outbound link matters just as much, because it's how a stolen or spoofed charger identity would turn into fraudulent billing, fake charging sessions, or a pivot point into the operator's back office.

The good news is that the OCPP standard already has a well-defined answer for this: Security Profile 3, which requires mutual TLS - both the charger and the CSMS present X.509 certificates, and the connection is authenticated cryptographically with no password involved at all. This is explicitly called out as the recommended security level for public charging infrastructure, ahead of the weaker profiles that rely on basic auth over TLS.

This is where TROPIC01 fits naturally as the identity vault on the charger's side of that outbound connection:

• The charger's unique client certificate and private key are generated and stored inside TROPIC01 during manufacturing, and never leave it.
• When the charger opens a connection to the CSMS, the TLS handshake data is signed inside TROPIC01, so the private key backing the charger's identity is never exposed to the Linux application stack - even if that stack is compromised through some other bug.
• TROPIC01 also holds the immutable root CA certificate used to verify the CSMS's own server certificate, so the charger isn't just proving who it is - it's also confirming it's actually talking to the real backend, not something impersonating it.
• Because each charger has its own key pair rooted in its own TROPIC01, a compromise of one unit's Linux OS doesn't hand an attacker a credential that works against the billing platform for other chargers in the fleet.

Put simply: the same reason you don't want SSH access guarded by a password is the same reason you don't want a charger's connection to billing and session-management backends guarded by a password either. Security Profile 3's mutual TLS gives you the protocol-level requirement; TROPIC01 gives you the hardware guarantee that the certificate and key backing the charger's side of that handshake can't be lifted off the device.

‍

Why this holds up even if the OS is compromised

The scenario that should worry every charger vendor isn't "what if someone guesses my password" - it's "what if someone gets root on my Linux userspace through some other bug." The XCharge case is one path to that; a future vulnerability in a completely unrelated service could be another. The whole point of anchoring SSH and backend mTLS trust in TROPIC01 is that this scenario stops being catastrophic. An attacker with root on the host OS still can't extract the SSH host key, still can't forge the client certificate used against the CSMS or billing backend, and still can't rewrite the trusted CA keys, because none of that material ever lived in a place root access can reach. The worst they can do is disrupt the device they're already on - not silently mint new trusted credentials or pivot cleanly into the backend as a "trusted" node.

‍

The bigger picture

None of this requires ripping out CCS2, V2G, or PLC. It requires treating every administrative and backend-facing surface - SSH, and the charger's own connection to the CSMS and billing systems - as something that should never trust a password, and building the trust anchor for certificates into hardware that's physically resistant to extraction. That's a design choice, not a compliance checkbox, and it's squarely the kind of "hardware-rooted security control" that frameworks like the EU Cyber Resilience Act are pushing the industry toward.

The Saiflow research did the EV charging industry a favor by showing exactly how bad the naive approach can get. The fix isn't scarier engineering - it's more boring, well-understood engineering: certificate-based SSH, mutual TLS on every backend connection, and private keys that live in a chip instead of a config file.

‍