Focus sur : Secure Modbus

David Bigot, consultant sécurité chez Orange Cyberdefense, offre ici un décryptage de ce protocole : de son évolution à ses failles.

Avant de présenter Secure Modbus, il est important de revenir sur l’histoire du protocole. Créé en 1979 par la société Modicon, racheté par Schneider Electric en 1996, le protocole Modbus RTU est en mode « point à point » sur des câbles « série » (par l’intermédiaire de connectiques RS-232, RS-422, ou RS-485). Il permet de faire échanger des données et des ordres entre des équipements industriels ou avec un logiciel de supervision et d’ingénierie.

Le succès de Modbus est lié à sa simplicité et son ouverture. En effet, il s’agit d’un des rares protocoles dont les spécifications sont publiques. Il demeure encore très utilisé à l’heure actuelle pour faire dialoguer deux équipements de constructeurs différents.

Schneider Electric a également publié une variante, appelé Modbus Plus, permettant une communication entre plusieurs équipements connectés sur le même bus. Ce protocole se base sur un principe de jetons. N’ayant pas rencontré l’adhésion escomptée, il reste assez peu répandu.

Avec l’informatisation des systèmes industriels et l’arrivée de l’Ethernet dans les milieux industriels, le protocole Modbus TCP/IP a été publié pour faciliter les interconnexions entre automates et les équipements informatiques notamment dans le cas de sites distants. Ce protocole reprend le principe du Modbus mais également ses défauts à savoir l’absence d’authentification et du contrôle de l’authenticité du message.

Le protocole Modbus TCP/IP a réutilisé la structure des messages du protocole Modbus RTU, à savoir l’utilisation des « fonctions code », qui spécifie s’il s’agit d’une lecture ou d’une écriture de données dans les registres de l’automate (ou cartes E/S…).

Schéma créé à partir des données de ce site : https://tools.ietf.org/html/draft-dube-modbus-applproto-00

Pour sécuriser le protocole Modbus, Schneider Electric a déjà proposé l’utilisation du protocole IPSec qui assure l’authentification et le chiffrement des communications réseau via un mot de passe. C’est d’ailleurs ce mécanisme de sécurité utilisé dans la gamme M580, qui a bénéficié d’une certification CSPN*.

En 2018, la Modbus organization a publié les spécifications du protocole Secure Modbus**, utilisant le port TCP/802, successeur dans la continuité du protocole Modbus. En effet, ce protocole reprend exactement la même structure de message que le protocole Modbus/TCP mais il ajoute une encapsulation dans une couche TLS pour sécuriser les communications.

Les spécifications présentent les soixante-deux règles avec le traditionnel may/shoud/must. Cinquante-quatre règles sont obligatoires. En les analysant, nous pouvons observer des concepts intéressants, notamment : l’authentification mutuelle par certificat, le contrôle d’intégrité ou le chiffrement. En résumé, les principaux éléments manquants à Modbus TCP.

Selon la règle R-14, le protocole Secure Modbus doit s’appuyer a minima sur la version 1.2 de TLS et supporter l’algorithme RSA mais aussi les courbes Elliptiques. Les spécifications excluent un certain nombre de suites cryptographiques jugées obsolètes (MD5, SHA1…) et imposent le support a minima d’AES 128 et SHA256. Il est surprenant de voir que des algorithmes sont mentionnés explicitement au vue de l’évolution des suites cryptographiques ; il sera nécessaire de maintenir à jour les spécifications du protocole.

Un autre point important : la possibilité de ne pas chiffrer les messages. La confidentialité des données n’est pas une priorité dans le milieu industriel. L’authentification est gérée par des certificats, il n’y a donc pas de chiffrement ou de hachage des mots de passe à réaliser.

Enfin, concentrons-nous sur l’utilisation exclusive d’algorithmes connus et référencés par l’IANA (Internet Assigned Numbers Authority). Elle implique une interdiction d’algorithmes propriétaires créés par les industriels. Il reste à voir comment seront implémentés les algorithmes standardisés. On peut également s’interroger sur l’utilisation de bibliothèques existantes (comme GNUTLS ou OpenSSL), qui reste cependant peu probable du fait de l’utilisation de systèmes d’exploitations propriétaires et temps-réel comme VxWorks. L’implémentation des suites cryptographiques sera-t-elle réussie et sans vulnérabilité ?

Comme évoqué précédemment, l’une des nouveautés est l’authentification par certificat. Ce mécanisme va en demander l’ajout sur les automates, mais également sur les stations d’ingénierie, serveurs de supervision ou sur les machines interrogeant un autre équipement.

La mise en place de ce mode d’authentification introduit l’ajout d’une infrastructure à clef publique (PKI en anglais) et notamment la vérification de l’état du certificat : est-il révoqué ou non ? Cette autorité peut devenir un élément critique. Que faire si un automate ne peut pas vérifier l’état du certificat ? Doit-il interrompre la communication ou l’autoriser malgré tout ?

Dans chaque certificat fourni, un champ Role (OID : 1.3.6.1.4.1.50316.802.1) spécifiera l’autorisation associée. Le protocole ne définit pas les différents types de rôles à implémenter et laisse ainsi la liberté à chaque constructeur sur ce point. La gestion des droits sera-t-elle réalisée au niveau de l’automate ou simplement au niveau du certificat ? La question se pose si un automaticien a le droit de configurer uniquement les automates d’un certain périmètre et non de l’ensemble des équipements. Les constructeurs devront donc mettre en œuvre un mode de fonctionnement permettant de définir de façon fine les droits.

Lors de la conférence S4 de 2017, Schneider Electric avait présenté les travaux sur le protocole Secure Modbus***. Avec ce nouveau protocole, la PKI devient un élément clef, notamment pour le provisionnement des certificats sur les équipements ainsi que leur remplacement lors de leur expiration. De nombreuses questions vont ainsi se poser, comme par exemple :

• Quel est le mécanisme pour la mise en place d’un équipement ?
• Le protocole d’enrôlement du nouvel automate sera t’il simple et sécurisé ?
• Comment remplacer facilement un équipement en cas de panne ?

Par ailleurs, de nombreux opérateurs disposent d’équipements de « spare » pour un remplacement sans nécessité de configuration, ni de compétences informatiques… Les équipementiers vont devoir proposer une architecture et de nouvelles briques de sécurité comme la gestion des certificats ou des droits par exemple. Toutefois, la question va devenir plus complexe si on utilise plusieurs constructeurs, voire même plusieurs produits ou gammes d’un même constructeur (variateurs de vitesse, automates, cartes E/S…). Comment vont dialoguer deux automates de constructeurs différents ? Les automaticiens devront t’ils intégrer manuellement le certificat sur l’automate tiers ?

Ce protocole fera t’il l’unanimité parmi les équipementiers industriels ? Sera-t-il activé par défaut en remplacement du bon « vieux » Modbus/TCP-IP ? L’interopérabilité sera-t-elle au rendez-vous ? Ces nombreuses questions restent sans réponse : seul l’avenir nous dira s’il sera réellement utilisé.

Notes :

*https://www.ssi.gouv.fr/uploads/2017/10/anssi-cible-cspn-2017_25en.pdf

**http://modbus.org/docs/MB-TCP-Security-v21_2018-07-24.pdf

***https://www.youtube.com/watch?v=kgvFWYv7Wwk