Article technique dans lequel vous trouverez des explications sur la gestion des certificats avec le protocole 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 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.
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 :
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 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.
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.
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
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
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 :
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.
CEO et Co-Fondateur