DNP3 a une norme de sécurité. Elle ne chiffre rien.
Secure Authentication v5 est de la vraie cryptographie, normalisée dans l'IEEE 1815, et elle prouve qui a envoyé une commande. Elle ne dit rien sur qui peut la lire. Ce guide explique ce que SAv5 protège vraiment, pourquoi si peu d'exploitants l'activent, et quoi faire du trafic qu'elle laisse en clair.
Dernière mise à jour:
Qu'est-ce que la sécurité DNP3, et qu'apporte réellement SAv5 ?
La sécurité DNP3 recouvre deux choses distinctes qu'il est facile de confondre. Secure Authentication v5, définie dans l'IEEE 1815, ajoute une authentification par défi-réponse : un équipement distant peut vérifier qu'une commande critique vient bien du maître qui prétend l'avoir envoyée. C'est de l'authentification et de l'intégrité. Ce n'est pas de la confidentialité : avec SAv5 actif, le trafic reste lisible sur le réseau. Le chiffrement est une décision distincte, et il vient de DNP3 sur TLS.
DNP3 est arrivé dans les années 1990 pour les réseaux d'électricité et d'eau, et il fait plus que Modbus : données horodatées, journalisation d'événements, réponses non sollicitées, fonctionnement sur des liaisons longues et bruitées. Cette richesse explique sa présence dans la télésurveillance, et elle donne aussi plus de matière à un attaquant quand rien n'authentifie le trafic.
Pourquoi SAv5 est-elle si rarement activée ?
La norme est disponible depuis 2012. Son adoption sur le terrain reste faible, et ce n'est pas parce que les exploitants la contestent. Quatre obstacles pratiques expliquent l'essentiel.
Les clés doivent atteindre des sites dispersés
SAv5 repose sur des clés de mise à jour et des clés de session qui doivent atteindre chaque équipement distant. Chez un exploitant, ces équipements sont des stations de pompage, des postes électriques et des unités de télégestion répartis sur un territoire, souvent joignables par une liaison lente ou intermittente. Distribuer et renouveler ce matériel cryptographique sur un tel parc, c'est là qu'est le travail, et c'est pourquoi la fonction reste inutilisée.
Les deux extrémités doivent la gérer
SAv5 est une capacité négociée. Un équipement distant qui la gère ne gagne rien si le maître ne la gère pas, et un parc constitué sur deux décennies l'a rarement aux deux bouts de chaque liaison. L'équipement le plus ancien fixe le plafond.
Elle protège les fonctions critiques, pas tout
La norme authentifie les codes de fonction critiques : commande, commande directe, redémarrages, changements de configuration. L'interrogation cyclique et la télémétrie ne sont pas couvertes par défaut, ce qui est un choix d'ingénierie correct, mais cela signifie qu'activer SAv5 n'authentifie pas toute la conversation.
On la prend souvent pour du chiffrement
C'est celui-là qui fait de vrais dégâts. Les équipes activent SAv5, cochent la mesure comme couverte, et supposent que la liaison est désormais privée. Elle ne l'est pas. Les valeurs de procédé, les noms de points et la forme de l'opération restent lisibles par tout ce qui se trouve sur le chemin.
Que peut faire un attaquant face à un équipement non authentifié ?
DNP3 organise les données en objets et en points, et gère les réponses non sollicitées. Cette structure fait son utilité pour les exploitants, et elle constitue aussi une carte bien documentée pour qui atteint le port.
Commandes de contrôle non autorisées
Une commande ou une commande directe visant un bloc de sortie de relais, émise par un maître qui n'en a jamais envoyé ou vers un point qui n'en a jamais reçu. C'est le précurseur classique d'un actionnement non autorisé, et sans SAv5 rien dans le protocole ne la distingue d'une commande légitime.
Reconnaissance de la cartographie des données
Des requêtes sur des objets, des variations ou des plages de points hors du profil habituel de l'équipement. Comme DNP3 est auto-descriptif, un attaquant peut apprendre la cartographie des données sans rien envoyer qui paraisse malveillant.
Rejeu de trafic capturé
Retransmettre des paquets autrefois valides pour déclencher une action ou masquer un changement. SAv5 l'empêche par défi-réponse et nonces de session ; sans elle, l'analyse des horodatages et des séquences est la seule défense, et c'est de la détection, pas de la prévention.
Abus de redémarrage et de configuration
Redémarrage à froid, redémarrage à chaud et codes de fonction de configuration apparaissant hors d'une fenêtre de maintenance planifiée. Ce sont exactement les fonctions critiques que SAv5 a été écrite pour protéger, et c'est pourquoi un parc non authentifié y est exposé.
Que couvre Secure Authentication v5 ?
SAv5 est un mécanisme de défi-réponse transporté dans DNP3 lui-même. Quand un maître émet une requête critique, l'équipement distant le met au défi, et le maître répond par un code d'authentification de message calculé sur la requête avec une clé de session partagée. L'équipement n'agit que si cette preuve est valide.
| Propriété | Avec SAv5 | Ce que cela change en pratique |
|---|---|---|
| Authentification | Oui, sur les codes de fonction critiques | L'équipement peut prouver qu'une commande vient du détenteur de la clé de session, et non de tout ce qui a pu atteindre le port. |
| Intégrité | Oui | Une commande modifiée en transit échoue à son code d'authentification et se voit rejetée. |
| Protection contre le rejeu | Oui | Le défi-réponse avec nonces de session fait qu'un paquet capturé ne peut pas être simplement renvoyé. |
| Confidentialité | Non | Rien n'est chiffré. Les valeurs de procédé, les noms de points et la structure de l'opération restent lisibles sur le réseau. |
| Couverture | Fonctions critiques | L'interrogation cyclique et la télémétrie ne sont pas authentifiées par défaut : activer SAv5 n'authentifie donc pas toute la session. |
L'authentification sécurisée DNP3 chiffre-t-elle le trafic ?
Non, et c'est le malentendu le plus lourd de conséquences sur la sécurité DNP3. SAv5 prouve qui a envoyé une commande et qu'elle n'a pas été modifiée. Elle ne cache pas ce que dit la commande, et elle ne cache pas la télémétrie qui remonte. Si vous avez besoin de confidentialité, vous faites passer DNP3 sur TLS, un contrôle distinct avec ses propres certificats et sa propre gestion de clés. Une checklist qui enregistre SAv5 comme satisfaisant une exigence de chiffrement en transit enregistre quelque chose de faux.
Comment chiffrer réellement DNP3 ?
Le chiffrement de DNP3 vient de son encapsulation dans TLS, pas du protocole lui-même. C'est une option réelle avec des coûts réels, et c'est sur ces coûts que la plupart des parcs calent.
TLS sur la liaison
DNP3 sur TLS apporte la confidentialité et une seconde authentification des extrémités, au niveau transport. Il faut des certificats aux deux bouts, donc une autorité de certification, un chemin de distribution et un processus de renouvellement qui atteignent chaque équipement distant.
Le problème des certificats est celui des clés
C'est le même obstacle qui laisse SAv5 inutilisée, sous un autre habit. Si des clés de mise à jour ne peuvent pas atteindre en pratique une station de pompage isolée, des certificats qui expirent ne le peuvent pas non plus.
Les liaisons série changent la question
Une part importante de DNP3 tourne encore sur du série ou sur des convertisseurs série vers IP. TLS suppose un chemin IP : sur ces liaisons, la question de la confidentialité se déplace vers ce qui transporte le série, et non vers DNP3.
Ou déplacer le problème hors des équipements
Là où un travail de certificats par équipement n'est pas réaliste, terminer la session sur un proxy qui comprend le protocole permet à un seul composant de détenir les clés et les certificats, au lieu que chaque équipement distant en détienne une part.
Quel maître, ou quel technicien ?
SAv5 répond à une question plus étroite qu'on ne le croit. Une clé de session est une identité d'équipement : elle prouve que la requête vient de quelque chose qui détient cette clé. Elle ne dit pas qui était au clavier, et sur un poste d'ingénierie partagé ce sont deux faits très différents.
Ce que SAv5 établit
Que la requête vient d'une partie détenant la clé de session de cette liaison, et qu'elle n'a été ni modifiée ni rejouée. Pour une interrogation de machine à machine entre un maître et un équipement distant, c'est exactement la bonne garantie, et elle suffit.
Ce qu'elle ne peut pas établir
Quelle personne a émis la commande. Une clé partagée entre une salle de conduite, un portable de maintenance et la session distante d'un intégrateur authentifie les trois de la même façon. Si la clé est copiée, la copie est indiscernable de l'originale.
Cela compte surtout là où DNP3 rencontre des personnes : fenêtres de maintenance, accès des intégrateurs, tout ce qui passe par la télé-assistance. NERC CIP-004 et CIP-005 demandent qui a eu accès et quand, et une identité d'équipement partagée par une équipe ne peut pas y répondre. L'identité nommée doit venir de la couche qui arbitre la session, pas du protocole.
Où la sécurité DNP3 casse-t-elle en pratique ?
Comme pour la plupart des protocoles OT, les échecs relèvent du déploiement, pas de la cryptographie.
SAv5 enregistrée comme du chiffrement
La ligne de conformité dit chiffré, le réseau dit le contraire. Vérifiez ce que la mesure demandait réellement.
Activée d'un seul côté
Un équipement capable en face d'un maître qui ne sait pas négocier SAv5 n'obtient aucune protection, et l'inventaire du parc l'enregistre souvent comme activée.
Clés de mise à jour jamais renouvelées
Des clés installées à la mise en service et jamais retouchées. Rien ne tombe en panne, donc rien ne déclenche de revue, et la portée d'une clé compromise reste permanente.
Port par défaut laissé joignable
DNP3 écoute par convention sur le port TCP 20000. Un équipement joignable sur ce port depuis un réseau à plat est joignable par tout ce qui s'y trouve, authentifié ou non.
Convertisseurs série vers IP jugés neutres
Mettre une liaison série sur IP l'expose à tout ce qu'IP expose. Le convertisseur reçoit rarement l'attention que recevrait l'équipement.
Checklist de durcissement DNP3 : quoi vérifier
L'essentiel relève de la vérification plutôt que de la construction, et une bonne part se répond à partir d'une capture et d'un inventaire.
- 01
Confirmer quelles liaisons négocient réellement SAv5, aux deux extrémités, plutôt que quels équipements l'annoncent comme capacité.
- 02
Vérifier que les codes de fonction critiques, commande, commande directe, redémarrage et changement de configuration, sont bien ceux qui sont authentifiés.
- 03
Consigner explicitement, dans le registre des risques et dans toute preuve de conformité, que SAv5 est de l'authentification et non du chiffrement.
- 04
Décider où la confidentialité est réellement requise et y appliquer TLS, plutôt que de supposer que le protocole l'apporte.
- 05
Donner aux clés de mise à jour un calendrier de renouvellement et un responsable, et consigner les dates d'émission et d'expiration avec le reste de l'état du réseau.
- 06
Établir une référence des objets, variations et codes de fonction que chaque équipement voit normalement, pour rendre visible tout ce qui sort de ce profil.
- 07
Confirmer que le port TCP 20000 n'est pas joignable depuis un endroit qui n'en a pas besoin, quel que soit l'état de l'authentification.
Ces mesures correspondent à NERC CIP-005 pour le périmètre de sécurité électronique et CIP-007 pour la sécurité des systèmes, à l'identification et l'authentification (FR1) et au contrôle d'usage (FR2) de l'IEC 62443, et au NIST SP 800-82r3 pour les systèmes OT.
Comment sécuriser du DNP3 qu'on ne peut pas reconfigurer ?
Tout ce qui précède suppose qu'on peut modifier l'équipement et lui acheminer des clés. Sur un parc réparti, cette hypothèse tombe souvent : l'équipement est antérieur à SAv5, le fournisseur refuse de valider la modification, ou le site est à deux heures de route de la personne qui pourrait intervenir. L'alternative est de placer la protection devant l'équipement.
Un seul endroit détient les clés
Access Gate exploite sa propre PKI et termine la session : certificats et matériel de clés vivent sur l'appliance et non sur chaque équipement distant. Celui qui n'aurait jamais pu porter une clé renouvelée n'a plus à le faire.
La confidentialité sans toucher au protocole
Le canal vers la Gate est en TLS 1.3 avec échange de clés post-quantique (ML-KEM-768), vérifié contre cette PKI, devant un équipement qui n'en parle pas un mot.
Refus par défaut, par identité et par protocole
Donner à un technicien l'accès DNP3 à un équipement ne lui donne rien d'autre. Chaque protocole sur chaque actif est une autorisation explicite, c'est-à-dire l'application qu'un équipement non authentifié ne peut pas assurer lui-même.
Preuves pour CIP-005 et CIP-007
Le proxy qui filtre la session l'enregistre aussi : quelle identité, quel équipement, quel protocole, à quel moment. C'est la preuve de contrôle d'accès que demande NERC CIP, produite par l'exploitation et non par un projet séparé.
Reprendre la main sur un parc DNP3 sans visiter chaque site
Si vos équipements distants ne peuvent pas faire tourner SAv5, ou si le renouvellement des clés sur le territoire n'est pas réaliste, nous pouvons regarder ensemble ce que donne le filtrage du canal sur votre réseau.
Réseaux électriques et postes
Comment la même architecture s'applique aux SCADA, aux unités de télégestion et aux relais du réseau électrique.
Le voir sur votre propre parc
Une revue sur votre topologie : quels équipements sont exposés, à quoi ressemble l'application des règles, et ce que demande le déploiement.
Questions sur la sécurité DNP3
Le port TCP DNP3 par défaut. Un équipement joignable ici sans authentification exécutera toute commande bien formée qu'il reçoit.
Non. SAv5 apporte authentification, intégrité et protection contre le rejeu pour les codes de fonction critiques. Elle n'apporte pas de confidentialité : la charge utile reste lisible sur le réseau. Le chiffrement de DNP3 vient de son passage sur TLS, un contrôle distinct avec ses propres certificats et sa propre gestion de clés. Enregistrer SAv5 au titre d'une exigence de chiffrement en transit revient à enregistrer quelque chose de faux.
C'est le mécanisme de sécurité défini dans l'IEEE 1815, la norme qui spécifie DNP3. Quand un maître envoie une requête critique, comme une commande ou un redémarrage, l'équipement distant émet un défi et le maître doit répondre par un code d'authentification de message calculé avec une clé de session partagée. L'équipement n'agit que si cette preuve est valide, ce qui bloque à la fois les commandes forgées et les commandes rejouées.
La gestion des clés. SAv5 exige que des clés de mise à jour et de session atteignent chaque équipement distant, et chez un exploitant ces équipements sont répartis sur un territoire, sur des liaisons lentes, intermittentes ou les deux. Elle doit aussi être gérée aux deux bouts d'une liaison, ce qu'un parc constitué sur vingt ans est rarement. L'obstacle n'est pas la cryptographie, c'est la distribution et le renouvellement du matériel de clés.
Non. Elle authentifie les codes de fonction critiques, ceux qui changent l'état : commande, commande directe, redémarrage à froid et à chaud, changements de configuration. L'interrogation cyclique et la télémétrie ne sont pas authentifiées par défaut. C'est un arbitrage d'ingénierie assumé, car authentifier chaque interrogation coûterait de la bande passante sur des liaisons qui n'en ont pas, mais cela veut dire qu'activer SAv5 laisse l'essentiel de la conversation non authentifié.
En plaçant la protection devant eux. On fait entrer l'équipement dans une enclave segmentée pour qu'il ne soit plus joignable directement, et on termine la session sur un proxy qui comprend le protocole et applique identité et politique avant de rétablir la connexion. Les clés et les certificats vivent sur le proxy, et non sur un équipement distant qui n'aurait jamais pu les porter ; l'équipement garde sa configuration, son firmware et son adresse IP.
