Le standard de communication OPC UA permet de s’assurer de la confidentialité et de l’intégrité des échanges en s’appuyant sur les certificats X.509. Cependant, leur mise œuvre peut s’avérer laborieuse dans un environnement OT comprenant des mécanismes de mise à jour limités, de fortes contraintes de disponibilité sur un parc machines hétérogène et des compétences en cybersécurité peu présentes.

C’est pour répondre à cet obstacle majeur au renforcement de la cybersécurité de l’environnement industriel que Systerel travaille sur la gestion de ces certificats et a développé le GDS Push Server.

Le GDS PUSH Server est un outil d’administration permettant de communiquer avec l’infrastructure à clé publique (PKI) pour réaliser les différentes opérations nécessaires au maintien en conditions de sécurité comme renouvellement automatique de certificats ou le renouvellement de la liste de confiance du serveur. Cet outil s’appuie sur une interface standardisée sur les serveurs OPC UA.

Comment ça marche¶

La sécurité en OPC UA repose donc en partie sur les certificats X.509. Chaque application possède un certificat associé à une clé privée, ainsi qu’une liste de confiance qui confiance contient des certificats et des listes de révocation (CRL) sur lesquels l’application s’appuie pour déterminer si un certificat externe doit être accepté (voir chaîne de validation des certificats OPC UA). Ce processus de validation est primordial, car il détermine les entités autorisées à communiquer avec l’application.

Contexte¶

Deux points importants doivent être considérés : d’une part, les certificats et CRL ont des dates d’expiration, et d’autre part, le contenu des CRL évolue dynamiquement par essence (pour rappel les CRL contiennent les certificats révoqués et qui ne sont donc plus dignes de confiance).

Mise à jour des certificats et CRL ¶

Il est donc essentiel de maintenir les listes de confiance des applications à jour. Ce maintien à jour est laborieux, car il nécessite souvent une intervention (physique ou non) sur la machine, ce qui peut entraîner du retard dans sa mise en œuvre et impacter la sécurité des systèmes.

L’OPC UA prévoit des méthodes côté serveur permettant la modification (partielle ou totale) de la liste de confiance du serveur ainsi que la possibilité de renouveler son certificat avec ou sans génération d’une nouvelle clé privée. Cela simplifie la maintenance, car nous n’avons plus besoin de multiplier les canaux de communications et les protocoles utilisés, et nous bénéficions de la sécurité intrinsèque à l’OPC UA pour réaliser ces opérations.

Certificate Manager¶

La liste de confiance « originelle », maintenue à jour, et le service capable d’émettre un certificat serveur se trouvent regroupés au sein d’une même entité : le Certificate Manager. C’est lui qu’il faudra mettre en relation avec les serveurs OPC UA, et c’est à ce niveau que le logiciel GDS Push Server intervient.

GDS Push Server¶

Le GDS Push Server est un outil qui permet de synchroniser automatiquement ou manuellement, périodiquement ou non la liste de confiance des serveurs avec celle du Certificate Manager, ainsi que le renouvellement automatique ou manuel du certificat serveur par un certificat émis par le Certificate Manager.

Dans la suite de l’article et dans un souci de simplification, nous supposerons qu’il n’y a qu’un seul serveur OPC UA.

Nous présentons dans ce qui suit, les fonctionnalités du GDS Push Server et ses cas d’utilisation, puis les aspects techniques de l’outil, et enfin, nous nous intéresserons aux évolutions futures du produit.

GDS Push Server — fonctionnalités et cas d’usage¶

Le GDS Push Server a trois commandes :

Renew : renouvelle le certificat du serveur, avec ou sans regénération de la clé privée.
CRL : met à jour les CRL de la liste de confiance du serveur.
TL : met à jour l’entièreté de la liste de confiance (certificats + CRL) du serveur.

Il est possible de programmer des appels périodiques aux commandes CRL et TL.

Par ailleurs, les commandes se jouent automatiquement avant les dates d’expiration des certificats ou de la CRL. Par exemple, si le certificat serveur approche de sa date d’expiration alors la commande Renew sera jouée automatiquement par l’outil.

Voici quelques cas d’usage simples :

La clé privée d’un client a été compromise, son certificat a donc été révoqué pour ne plus autoriser les communications avec ce client. Les CRL doivent être mises à jour. On utilise la commande CRL manuelle.
On souhaite s’affranchir de la maintenance de la liste de confiance du serveur OPC UA (CRL) et de la maintenance de validité du certificat du serveur. Il suffit de laisser tourner le GDS Push Server s’exécuter en tâche de fond et il s’acquittera automatiquement de ces tâches en respectant les différentes échéances.
On souhaite autoriser un nouveau client à se connecter au serveur, et pour ça rajouter des certificats autorités de confiance dans la liste de confiance du serveur. Il suffit d’utiliser le GDS Push Server avec la commande TL manuelle.

GDS Push Server — conception du logiciel¶

L’outil GDS Push Server comprend deux interfaces :

Client OPC UA : il s’agit de l’interface de communication avec les serveurs OPC UA. Le client OPC UA se connecte et fait appel à différentes méthodes sur les serveurs. Le détail des méthodes OPC UA et des informations relatives aux protocoles utilisés est donné plus bas.
PKI : il s’agit de l’interface de communication avec le Certificate Manager. Dans un premier temps, le GDS Push Server est mis en œuvre avec la solution EJBCA de l’entreprise KeyFactor. L’interface PKI supporte plusieurs protocoles : CMP, EJBCA REST API, HTTPS.

Aperçu des utilisations du *GDS Push Server*

Généralités¶

Le GDS Push Server est écrit en C avec un code source s’intégrant à S2OPC, l’implémentation sûre et sécurisée du standard OPC UA conçue par Systerel. Le binaire Le GDS Push Server embarque les bibliothèques statiques suivantes : s2opc_clientserver, curl, openssl_cypto, openssl_ssl, json-c, expat. Nous verrons dans la suite pourquoi ces bibliothèques sont nécessaires au fonctionnement du produit.

Les fichiers de configuration sont au nombre de deux : configuration OPC UA Client-Serveur et configuration du GDS Push Server. Ils sont au format XML et chargés au démarrage de l’outil. Dans la configuration du GDS Push Server, on trouve notamment l’adresse du Certificate Manager (le serveur EJBCA) ou encore les informations relatives à la sécurité des protocoles utilisés (certificats / clé utilisés…).

Nous allons maintenant entrer dans le détail du comportement du GDS Push Server et de la composition de ses interfaces.

PKI¶

L’API EJBCA REST ¶

Cette API est utilisée pour la mise à jour de la liste de confiance (commandes TL et CRL).

Authentification du protocole

L’API EJBCA REST nécessite une authentification par certificat client ou OAuth. Cette paire de certificat/clé privée est fournie lors de la création du serveur EJBCA.

Le GDS Push Server obtient la liste des CA de EJBCA à l’aide d’une requête https. La réponse du serveur EJBCA est sous format json, la liste des subject DN (Distinguished Name) des certificats en est extraite. Pour rappel, le subject DN d’un certificat identifie l’entité associée à la clé publique du certificat.

La CRL de chacun des subject DN est alors téléchargée depuis EJBCA via une nouvelle requête https, et après un traitement du json et un décodage du base64, elle est ajoutée à la nouvelle liste de confiance.

Dans le cas où la commande était TL, les CA sont également téléchargées et ajoutées à la nouvelle liste de confiance.

Un mécanisme de « TrustedCertificates » utilisant une liste de subject DN chargée depuis la configuration XML a été implémenté pour dissocier les CA de EJBCA reconnus comme certificats de confiance (trusted) des certificats signataires (issuer).

Note

Pour le moment, seuls les CA de EJBCA peuvent être récupérés avec cette API.

Le protocole CMP (Certificate Management Protocol)¶

Ce protocole est utilisé pour mettre à jour le certificat serveur.

Authentification du protocole

L’authentification auprès du serveur CMP EJBCA se fait par mot de passe choisi lors de la création du point d’entrée CMP. Ce dernier est demandé lors du lancement de l’outil GDS Push Server.

Le client OPC UA GDS Push Server appelle la méthode OPC UA CreateSigningRequest exposée par le serveur, et ce dernier lui retourne un PKCS#10 Certificate Request DER encoded.

En utilisant la bibliothèque Openssl, le GDS Push Server réalise alors une requête p10cr en CMP au serveur CMP EJBCA avec pour argument la CSR (Certificate Signing Request) préalablement créée. Ce dernier retourne au GDS Push Server, si tout s’est bien passé, un certificat serveur.

OPC UA¶

Authentification du protocole

Le client s’authentifie par certificat / clé privée auprès des serveurs OPC UA (voir Application Authentication in OPC UA), et l’utilisateur par username / password. (voir User Authentication in OPC UA).

L’interface OPC UA du GDS Push Server s’appuie sur le principe du « Push Management » standardisé dans la part 12 du standard OPC UA (voir https://reference.opcfoundation.org/GDS/v105/docs/7.4).

Méthodes de la liste de confiance (Open / Write / CloseAndUpdate) ¶

Une fois une nouvelle liste de confiance construite, après avoir utilisé l’API EJCA REST par exemple, le client OPC UA GDS Push Server appelle les méthodes Open / Write / CloseAndUpdate des serveurs OPC UA pour remplacer l’ancienne liste de confiance du serveur par la nouvelle.

Méthode UpdateCertificate ¶

Le client OPC UA GDS Push Server appelle la méthode OPC UA UpdateCertificate exposée par le serveur, avec en argument le nouveau certificat. Ce nouveau certificat a été, par exemple, obtenu à l’aide du protocole CMP comme vu ci-dessus.

Avantages et perspectives d’évolution¶

GDS Push Server a plusieurs avantages :

Centraliser la gestion de plusieurs listes de confiance (dans le cas où nous avons plusieurs serveurs OPC UA), automatiser ces mises à jour.
Sécuriser ce processus de mise à jour.

Parmi les perspectives d’évolution possibles, nous pouvons lister :

L’interfaçage avec de nouveaux protocoles de communication avec les PKI, par exemple EST (Enrollment over Secure Transport, standard défini par le RFC7030) ou encore ACME (Automatic Certificate Management Environment, standard défini par le RFC8555). Cela permettrait de mettre au challenge l’abstraction protocolaire, et d’ouvrir le produit à des clients utilisant une solution Certificate Manager différente de EJBCA.
Permettre une modification dynamique (c’est-à-dire quand l’outil est en marche) de la liste de TrustedCertificates, des périodes de mise à jour, etc. Cela permettrait d’éviter des redémarrages qui sont pour le moment inévitables et qui apportent leur lot de limitations (il faudra par exemple rentrer à nouveau les mots de passes des différentes clés privées, protocoles de communications, etc.).
Compléter la solution afin de gérer entièrement la problématique du onboarding.