Shared wildcard certificate in EV chargers

[Hanno Böck]

Hello,

I wanted to share an incident with shared certificates and keys on EV
charger devices. I discovered this while investigating another security
issue. (The devices were shipped with default credentials for HTTP
authentication, see [1].)

Devices of the Hypercharger brand (company Alpitronic) provide an HTTPS
web interface with a shared certificate issued for *.hypercharger.it
(expired in May 2022):
https://crt.sh/?id=11281533746

The same private key is used in other certificates (all expired):
https://crt.sh/?spkisha256=c8d3f7b83fdd94b804d0fea58818ce8c5c8f375a88c1e5c178ea0845d83200f4

All devices shared the same certificate. With access to the device
itself (or possibly the firmware), it is possible to get access to the
private key. While the devices provide firmware update functionality,
the firmware files are not publicly available.

Given that this is a wildcard certificate, it could've been used to
attack connections to any subdomain of hypercharger.it.

I informed Alpitronic about this. They told me that they would use
individual certificates for future devices. That the same key was used
for other hosts was, according to Alpitronic, an internal mistake.

As all the affected certificates had already expired, there was nothing
to do in terms of revocation and no need to report it to the
certificate authority.

However, there is an interesting hypothetical question: If this had
been discovered while the certificates were still valid, would a CA be
obliged to revoke the certificates? What kind of evidence would be
sufficient to show a key compromise?


[1]
https://industrydecarbonization.com/news/insecure-password-allowed-administrative-access-to-electric-vehicle-chargers.html
--
Hanno Böck
https://hboeck.de/

[Xiaohui Lam]

This is a funny challenge that WebPKI (actually iotPKI) could face. When IPv6 becomes available and cheaper, every matters, things connected to internet, will have urgent needs to secure authentication and identification protocols.

If the device manufacturer can prove that the private key is stored in the security chip and cannot be exported, and the security chip has a relevant white paper published, the CA and society should accept it.

On the contrary, if it is stored in a general NAND or SD card, we need to continue the discussion below.

Of course, it'll increases the cost of the equipment. But for WebPKI, which has requirements for higher trust, this is reasonable cost to take.

[Tobias S. Josefowitz]

On Wed, Jan 17, 2024 at 3:51 PM Xiaohui Lam <inao...@gmail.com> wrote:
>
> This is a funny challenge that WebPKI (actually iotPKI) could face. When IPv6 becomes available and cheaper, every matters, things connected to internet, will have urgent needs to secure authentication and identification protocols.
>
> If the device manufacturer can prove that the private key is stored in the security chip and cannot be exported, and the security chip has a relevant white paper published, the CA and society should accept it.
>
> On the contrary, if it is stored in a general NAND or SD card, we need to continue the discussion below.

The use of such a security chip would however not fundamentally change
the threat model. Even if we presume that it would not be able to
extract the private key from the security chip under any
circumstances, you could still have the security chip perform the
cryptographic operations necessary to accept valid connections
protected by the certificate/private key. The process of doing so
would be slightly more involved than just copying the key file and
using it from elsewhere, but fundamentally the threat is the same.