Sécurisez DNP3 sans toucher aux équipements distants. SAv5 authentifie les commandes, mais ne les chiffre pas.
Secure Authentication v5 (SAv5), normalisé dans l'IEEE 1815, prouve qui a envoyé une commande. Il ne cache pas son contenu. Ce guide couvre ce que protège SAv5, pourquoi peu d'exploitants l'activent, et comment traiter le trafic qu'il laisse lisible.
Dernière mise à jour:
Qu'est-ce que la sécurité DNP3, et qu'apporte SAv5 ?
La sécurité DNP3 recouvre deux choses distinctes, faciles à confondre. Secure Authentication v5 (SAv5), défini dans l'IEEE 1815, ajoute une authentification par défi-réponse. Elle permet à une station distante de vérifier qu'une commande critique vient bien de son maître. Cela couvre l'authentification et l'intégrité. Cela ne couvre pas la confidentialité : avec SAv5 actif, le trafic reste lisible sur le réseau. Le chiffrement est une décision distincte, qui passe par DNP3 sur TLS.
DNP3 est apparu dans les années 1990 pour les réseaux électriques et d'eau, et il fait plus que Modbus : données horodatées, journalisation d'événements, réponses non sollicitées et fonctionnement sur des liaisons longues et bruitées. Cette richesse explique sa présence partout en télésurveillance. Elle donne aussi plus de prise à 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 intégré à DNP3. Quand un maître émet une requête critique, la station distante le met au défi. Le maître répond avec un code d'authentification de message, calculé sur la requête avec une clé de session partagée. La station 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 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.
Les certificats ramènent le problème 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.
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.
SAv5 identifie-t-il le technicien ou seulement le maître ?
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 cède-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.
La checklist de durcissement DNP3.
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 de pouvoir modifier l'équipement et lui faire parvenir des clés. Sur un réseau de distribution étendu, cette hypothèse tombe souvent. L'équipement est antérieur à SAv5, le fournisseur ne prend pas en charge le changement, ou le site est à deux heures de la personne qui pourrait le faire. L'alternative est de placer la protection devant la station distante.
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.
Le chiffrement sans modifier le 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é.
Sécurisez DNP3 sans vous déplacer sur chaque site.
Certaines stations ne peuvent pas exécuter SAv5, et la rotation des clés sur tout un territoire est souvent irréaliste. Nous pouvons vous montrer à quoi ressemble le contrôle 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 fréquentes 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 l'authentification, l'intégrité et la protection contre le rejeu pour les codes de fonction critiques. Il n'apporte pas de confidentialité : la charge utile reste lisible sur le réseau. Le chiffrement de DNP3 passe par TLS, un contrôle distinct avec ses propres certificats et sa propre gestion des clés. N'inscrivez pas SAv5 face à une exigence de chiffrement en transit, car il n'y répond pas.
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, la station distante émet un défi. Le maître doit répondre avec un code d'authentification de message calculé avec une clé de session partagée. La station n'agit que si cette preuve est valide. Cela bloque les commandes falsifiées comme les commandes rejouées.
La gestion des clés. SAv5 exige que des clés de mise à jour et de session parviennent à chaque station distante. Chez un exploitant, ces stations sont réparties sur un territoire, sur des liaisons lentes, intermittentes, ou les deux. Les deux extrémités d'une liaison doivent aussi le prendre en charge, ce qui est rare dans un parc acheté sur vingt ans. La difficulté tient à la distribution et à la rotation des clés, plus qu'à la cryptographie.
Non. Il authentifie les codes de fonction critiques, ceux qui changent un état : operate, direct-operate, redémarrage à froid et à chaud, changements de configuration. L'interrogation courante et la télémesure ne sont pas authentifiées par défaut. C'est un compromis délibéré, car authentifier chaque interrogation coûterait une bande passante que ces liaisons n'ont pas. Mais activer SAv5 laisse donc l'essentiel des échanges non authentifié.
Placez la protection devant elles. Mettez la station dans une enclave segmentée pour qu'elle ne soit pas directement joignable. Terminez la session sur un proxy qui comprend le protocole et applique identité et politique avant de rétablir la connexion. Les clés et certificats résident sur le proxy, pas sur un équipement distant qui n'aurait jamais pu les porter. L'équipement garde sa configuration, son firmware et son adresse IP.
