5
 min de lecture

La gestion des certificats OPC-UA

Article technique dans lequel vous trouverez des explications sur la gestion des certificats avec le protocole OPC-UA.

Qu’est ce que l’OPC-UA ?

OPC-UA – pour Open Platform Communications Unified Architecture – est un protocole de communication open source d’informatique industrielle. Le protocole est développé et maintenu par la Fondation OPC et a été élaboré essentiellement pour la sécurisation et la standardisation des flux de données entre machines et systèmes d’information.

La gestion des certificats

La notion de certificat peut paraitre abstraite, cependant vous y êtes confrontés quotidiennement lorsque vous naviguez sur internet.

Les certificats sont identifiables dans les navigateurs par ce joli cadenas dans la barre d’adresse web. Un certificat est en fait un cachet d’approbation numérique délivré par un tiers de confiance connu sous le nom d’autorité de certification (CA). Plus précisément, il s’agit d’un fichier numérique contenant des informations émises par une autorité tiers indiquant que le site Web est sécurisé par une connexion cryptée.

Ils permettent d’assurer que le site sur lequel vous naviguez est authentique et que personne ne pourra intercepter les données échangées.

Les abréviations liées aux certificats

  • SSL - couche de socket sécurisée
  • CSR - Demande de signature de certificat
  • TLS - Sécurité de la couche de transport
  • PEM - Messagerie améliorée de confidentialité
  • DER - Règles de codage distinguées
  • SHA - Algorithme de hachage sécurisé

Comment fonctionne un certificat SSL?

Vous utilisez ce type de certificat pour affirmer l'identité de votre organisation et pour authentifier mutuellement les clients et votre serveur Web afin d'établir une connexion sécurisée et cryptée, cela implique :

  • L'échange de suites de chiffrement et de paramètres pour déterminer les fonctions cryptographiques prises en charge par les deux parties,
  • L'authentification d'une ou des deux parties dans l'échange,
  • L'échange de clés et la génération de clés de session symétriques.  

C'est par le biais de cette connexion sécurisée que les utilisateurs peuvent transmettre leurs informations à votre site sans que des attaques de type "man-in-the-middle" (MitM) et autres puissent intercepter ou décrypter les données.

Les certificats d'une application OPC-UA

Les applications OPC UA ont besoin de certificats pour assurer la sécurité des échanges clients - serveurs. Ces certificats sont de type X.509 v3 et contiennent une liste d'éléments de données définis.

La cryptographie asymétrique utilise deux clés : une clé privée et une clé publique. 

Les certificats incluent une signature numérique. Cette signature numérique peut être auto-signée (la signature est générée par la clé privée associée au certificat X.509 v3) ou peut être signée par une autorité de certification (la signature est générée par la clé privée associée au certificat X.509 v3 de l'AC). Les deux types de certificats offrent le même niveau de sécurité. Les signatures peuvent être générées à l'aide de divers algorithmes, qui offrent différents niveaux de sécurité (128 bits, 256 bits, 512 bits, etc.). 

Une application OPC-UA dispose d'une liste de clés publiques de confiance qui représentent les applications auxquelles elle fait confiance. Cette liste est stockée dans un dossier ou dans le registre de certificats Windows.

Une application OPC-UA aura également une clé privée qui correspond à son certificat. L'application peut utiliser une clé publique de sa liste pour valider que la signature d'une demande de connexion reçue a été générée par la clé privée correspondante. Une application peut également utiliser la clé publique de l'application cible pour crypter des données, qui ne peuvent être décryptées qu'à l'aide de la clé privée de l'application cible.

Il y a différentes manières de gérer les certificats d’une infrastructure OPC-UA.

1. Pas de certificats

Vous n’utilisez pas de certificat et dans ce cas les échanges entre clients et serveurs OPC-UA ne sont pas protégés. Les échanges ne sont pas cryptés et peuvent être interceptés et donc votre système peut être la cible d'attaques de type "man-in-the-middle" (MitM).

Une gestion de la sécurité de votre infrastructure OPC-UA sans certificats n'est pas recommandée.

2. Certificats auto-signés (générés manuellement)

Dans ce cas, c'est vous même qui générez vos certificats.

Vous devez exporter, copier et installer manuellement les clés publiques associées au client vers le serveur avec lequel il va communiquer. Et vice versa sur chacun des éléments de l’infrastructure OPC-UA. Cela doit être répété pour autant de client et de serveurs 

Un certificat a une durée de vie et devra être remplacé par un certificat actualisé avant son expiration.

Exemple de génération d'un certificat auto-signé par commande bash avec openSSL :

openssl genrsa -out default_pk.pem 2048
openssl req -new -key default_pk.pem -out cert.csr -subj "/C=US/ST=NY/L=NY/O=Organization/OU=OrganizationUnit/CN={YOUR_IP}"
openssl x509 -req -days 3650 -extfile extensions.cnf -in cert.csr -signkey default_pk.pem -out public.pem
openssl x509 -in public.pem -inform PEM -out public.der -outform DER

3. Certificats générés par une autorité de certification (CA)

La principale différence entre un certificat signé par une autorité de certification et un certificat auto-signé est l'effort requis pour déployer et maintenir les certificats. 

Dans les systèmes comportant plusieurs serveurs et clients, le management de certificats auto-signés peut très vite devenir fastidieux. Dans ce cas, l'utilisation d'une autorité de certification propre à l'entreprise peut grandement simplifier le management des certificats. 

L'autorité de certification peut également fournir des avantages supplémentaires tels que la gestion de l'expiration des certificats et des listes de révocation de certificats (LCR).

Vous devrez générer un certificat signé par l'autorité de certification pour tous les clients et serveurs installés dans votre système. Lorsqu'un certificat expire, vous devrez uniquement remplacer le certificat expiré.

Exemple de génération d'un CA par commande bash avec openSSL :

openssl req -new -sha256 -nodes -newkey rsa:4096 -keyout CA.key -out CA.csr
openssl x509 -req -sha256 -extfile x509.ext -extensions ca -in CA.csr -signkey CA.key -days 1095 -out CA.pem

avec par exemple x509.ext :

[ ca ]
# X509 extensions for a ca
keyUsage                = critical, cRLSign, keyCertSign
basicConstraints        = CA:TRUE, pathlen:0
subjectKeyIdentifier    = hash
authorityKeyIdentifier  = keyid:always,issuer:always

Conclusion

Ces dernières années, le protocole OPC-UA tire clairement son épingle du jeu dans la course des protocoles de communication industriels, en effet il possède des arguments de poids :

  • Un standard ouvert
  • Plateforme agnostique
  • Comme décrit dans ce post, la sécurité est intégrée en standard, que ce soit au niveau de l’authentification ou lors des échanges de données
  • Déjà implémenté nativement dans de nombreux automates industriels
  • Flexible et évolutif grâce aux nombreuses implémentations que ce soit en C/C++ mais aussi en Java, .NET, NodeJS ou encore Python
  • Son concept de Publisher/subscriber qui permet une communication événementielle

Le module Connecter de SCorp-io utilise le protocole OPC-UA et embarque toutes les notions de sécurité intégrés au protocole standard. Notre prochain article explicitera pas à pas la sécurisation par certificat d'une communication OPC-UA entre un automate programmable et le module Connecter.

Jean-Romain BARDET
Jean-Romain BARDET

CEO et Co-Fondateur

Nos autres articles