OCPP 1.6 Sécurité. TLS, certificats et les erreurs que tout le monde fait

OCPP 1.6 n'a pas été conçu avec la sécurité comme priorité. La spec originale supposait que les bornes seraient sur des réseaux privés derrière des pare-feux. Cette hypothèse était fausse dès 2018, et elle est dangereusement fausse maintenant. Les bornes sont sur l'internet public, traitent des paiements et sont connectées à l'infrastructure électrique. La sécurisation compte.

La base

Rendering diagram...

Si votre borne se connecte en ws:// en production, tout est en clair : identifiants RFID, données de transaction, commandes de configuration, URLs de firmware. N'importe qui sur le même segment réseau peut tout lire. Pire, ils peuvent injecter des messages. démarrer des sessions gratuites, changer des configurations, rediriger des téléchargements de firmware.

Les trois profils de sécurité

Le livre blanc sécurité OCPP 1.6 définit trois profils, chacun s'appuyant sur le précédent :

Rendering diagram...

Profil 1 met un mot de passe dans l'URL : wss://backend.example.com/ocpp/CP001?password=secret123. Le mot de passe est généralement codé en dur à la fabrication et rarement changé.

Profil 2 fait présenter un certificat TLS par le backend. La borne vérifie qu'elle parle au vrai serveur, pas à un imposteur. Ça bloque les attaques man-in-the-middle. Mais le backend ne vérifie pas la borne. n'importe quoi connaissant l'URL peut se connecter.

Profil 3 ajoute un certificat client côté borne. Les deux endpoints prouvent leur identité. Pas d'usurpation dans aucune direction. C'est ce qu'on veut vraiment, mais ça nécessite une PKI : provisionnement de certificats à la fabrication, une CA, et un workflow de renouvellement. La plupart des opérateurs se retrouvent sur le Profil 2 avec des mots de passe forts et uniques par borne, parce que le PKI du Profil 3 est difficile à faire correctement à grande échelle.

Les erreurs que je vois dans les vrais déploiements

WebSocket en clair en production. Plus fréquent qu'on ne le croit. Parfois le firmware de la borne ne supporte pas le TLS. Parfois le service IT a mal configuré le load balancer.

Validation de certificat désactivée. La borne est configurée en wss:// mais verify_peer = false. Ça annule tout l'intérêt. un MITM peut présenter n'importe quel certificat et la borne l'accepte joyeusement.

Mots de passe par défaut. admin, password, ocpp, le numéro de série de la borne. Jamais changés après le déploiement terrain.

URLs de firmware non protégées. L'URL d'UpdateFirmware pointe vers du HTTP en clair sans authentification. N'importe qui sur le réseau peut servir une image firmware modifiée.

Endpoints OCPP ouverts. L'endpoint WebSocket du backend est accessible publiquement sans filtrage IP, sans limitation de débit. Trivial à inonder avec de fausses connexions de bornes.

Checklist pratique

• Utilisez wss:// partout. Sans exception.
• Activez la validation de certificat côté borne. Si le fabricant dit "désactivez-le juste pour les tests" sans jamais mentionner de le réactiver, insistez.
• Mots de passe uniques par borne, changés régulièrement.
• HTTPS pour toutes les URLs de firmware et diagnostics.
• Limitez le débit et surveillez les connexions WebSocket vers votre CSMS.
• Loggez chaque identifiant de borne inconnu qui tente de se connecter. c'est soit une mauvaise configuration, soit quelque chose de pire.
• Si vous pouvez le gérer, visez le Profil 3 (mTLS). Sinon, le Profil 2 avec des mots de passe par borne est le plancher pragmatique.

La sécurité d'OCPP 1.6 n'est pas la partie où la spec brille. Le protocole lui-même n'impose rien de tout ça. c'est à vous de le configurer correctement. Mais la surface d'attaque d'une borne VE publique qui traite des données de paiement est réelle, et traiter la sécurité comme optionnelle est une décision que vous finirez par regretter.