FR2866169A1 - Systeme de communication securise. - Google Patents

Abstract

L'invention concerne un système de communication sécurisé d'un équipement d'automatisme serveur 40 communiquant avec au moins un équipement d'automatisme client 20 par l'échange de requêtes/réponses non-sécurisées conformes à un protocole de communication application. Le système comporte un module de détection 43 d'un en-tête de sécurité client contenu dans une requête 11 sécurisée ou non-sécurisée conforme audit protocole de communication a pplication, un module de gestion sécurité 42 susceptible d'autoriser l'exécution d'une requête non-sécurisée contenue dans une requête sécurisée 11, un module de génération 48 susceptible d'ajouter un en-tête de sécurité serveur dans une réponse non-sécurisée, pour créer une réponse sécurisée 12 conforme audit protocole de communication application et envoyée à l'équipement client 20.

Description

La présente invention se rapporte à un système de communication basé sur

un procédé de communication sécurisé entre des équipements d'automatisme capables d'échanger des informations à l'aide de trames de communication non-sécurisées conformes à un protocole de communication application. Un tel système de

communication peut être mis en oeuvre pour sécuriser et contrôler l'accès à des équipements d'automatisme dans une installation appartenant notamment au domaine des automatismes industriels, des automatismes du bâtiment ou du contrôle/commande des réseaux électriques de distribution.

Sous le terme "équipement d'automatisme", on désignera ci-après tout équipement possédant au moins une unité de traitement, capable de communiquer avec d'autres équipements ou appareils via un protocole de communication application et susceptible d'offrir des fonctions servant en particulier au contrôle, à la commande, à la surveillance, à la conduite, à la configuration d'installations d'automatisme. Ce terme englobe donc par exemple un automate programmable, une commande numérique, une station de contrôle/commande ou un équipement informatique (serveur d'entreprise de type MES ou ERP, superviseur de type SCADA, ordinateur de type PC,...). On inclura aussi dans cette définition des équipements tels que un module métier, un module d'entrées/sorties déportées, un terminal de dialogue, un variateur de vitesse, un appareil de commande, un appareil de protection, un appareil de détection, etc....

Les réseaux locaux de communication entre équipements utilisent habituellement un modèle d'architecture de référence, tel que le modèle OSI bien connu (Open Systems Interconnexion) à sept couches successives, proposé par l'ISO (International Standard Organization). Chaque couche du modèle OSI remplit un certain nombre de tâches bien identifiées pour gérer la communication entre équipements divers.

Ainsi la première couche au niveau le plus bas, appelée couche physique, est notamment chargée de définir la nature du médium de communication ainsi que les caractéristiques des signaux véhiculés sur ce médium. La seconde couche, appelée couche liaison, gère en particulier les règles de partage d'accès au médium et la détection d'erreurs et de collisions lors d'accès simultanés au médium par différents équipements. La septième couche de niveau supérieur, appelée couche application, contient toutes les fonctions qui permettent de rendre compréhensibles pour un programme application les messages échangés entre équipements expéditeurs et destinataires. Il existe de nombreux protocoles de communication application qui permettent de remplir les fonctions de cette couche application.

MODBUS (www.modbus.orq) est un exemple de protocole de communication pour la couche application du modèle OSI. Ce protocole est très largement diffusé et permet des échanges de trames de communication de type clientserveur (c'est-à-dire principalement par l'intermédiaire de requêtesréponses) entre équipements d'automatisme. L'intérêt du modèle OSI à sept couches est de clairement séparer chaque couche pour les rendre indépendantes les unes des autres. Ainsi, le protocole application MODBUS est indépendant des couches basses du modèle OSI et il peut donc être utilisé avec des couches liaison et couches physiques différentes (par exemple avec des moyens de communication simples de type liaison série, avec des réseaux locaux de type Ethernet IEEE802.3, avec des réseaux globaux utilisant TCP/IP, ...). Les services offerts par MODBUS sont identifiés par des codes fonction application, codés sur un octet, présents dans chaque trame et qui permettent de définir l'action demandée (par le client) et effectuée (par le serveur). Ces codes fonctions peuvent être suivis de données associées à ces codes fonctions Désormais, grâce au protocole TCP/IP, l'ouverture et la transparence des communications entre équipements d'automatisme conduit de plus en plus à se soucier de la sécurité des accès à ces équipements d'automatisme, en particulier pour éviter toute intrusion extérieure non autorisée ou non authentifiée dans une architecture d'automatisme, par exemple lorsque les équipements d'automatisme sont connectés à un réseau LAN ou WAN. Toute opération non autorisée pourrait en effet avoir des conséquences plus ou moins graves sur le fonctionnement du process piloté par un équipement d'automatisme, la confidentialité de certaines données, etc...

Il existe déjà d e n ombreux protocoles d e communication sécurisés, tel que par exemple le protocole HTTPS. Cependant, l'adoption de tels protocoles sécurisés dans les architectures d'automatisme ne peut pas être envisagée, principalement à cause de leur non adéquation aux contraintes de certains équipements industriels simples (besoin de communications temps réel, ressources limitées des équipements: CPU, mémoire RAM et FLASH). De plus, cela nécessiterait la mise à jour de l'ensemble des équipements et applications concernées pour qu'ils soient compatibles avec ces nouvelles exigences de sécurité.

Or la très large diffusion des installations comprenant des équipements d'automatisme qui communiquent grâce à un protocole application de type MODBUS par exemple, rend difficile la mise à jour des équipements ou modules déjà connectés à un réseau de communication.

De plus, tous les équipements d'automatisme connectés à un réseau de communication ne nécessitent pas forcément la mise en oeuvre de la sécurité. En effet, il faut pouvoir faire cohabiter sur un même réseau de communication des équipements communiquant selon un protocole application sécurisé et d'autres communiquant selon un protocole application non sécurisé, notamment quand ces équipements sont déjà mis en place. De même, au sein d'un même réseau de communication, un équipement d'automatisme donné doit pouvoir échanger soit de façon sécurisée avec certains équipements, soit de façon non sécurisée avec d'autres équipements. De même, un équipement d'automatisme donné doit pouvoir échanger avec un autre équipement soit de façon sécurisée pour certaines requêtes de communication, soit de façon non- sécurisée pour d'autres requêtes ne mettant pas en jeu des données sensibles.

II existe donc un besoin d'apporter une solution de sécurité simple et facile à mettre en oeuvre, qui permettent d'instaurer des mécanismes de contrôle pour l'accès à des ressources sensibles, qui permettent de sécuriser la transmission d'informations grâce à des mécanismes d'authentification sécurisée ou non (transmission d'un code d'authentification en clair ou bien en chiffré), ainsi qu'à des mécanismes de vérification de l'intégrité des données échangées entre équipements d'automatisme clients/serveurs. Ces mécanismes doivent rester compatibles avec des équipements d'automatisme existants connectés au même réseau de communication via le même protocole de communication application. En particulier, des équipements d'automatisme existants ne nécessitant pas d'accès sécurisé doivent pourvoir continuer à communiquer selon ce protocole de communication, sans nécessiter une quelconque modification dans ces équipements.

C'est pourquoi, l'invention décrit un système de communication sécurisé d'un équipement d'automatisme client capable de communiquer avec au moins un équipement d'automatisme serveur par l'échange de requêtes et de réponses de communication non-sécurisées conformes à un protocole de communication application. Le système comporte un module de génération susceptible d'ajouter un en-tête de sécurité client dans une requête nonsécurisée, pour créer une requête sécurisée conforme au protocole de communication application et envoyée à l'équipement d'automatisme serveur. Le système comporte aussi un module de détection d'un en-tête de sécurité serveur contenu dans une réponse sécurisée ou non-sécurisée conforme au protocole de communication application et provenant de l'équipement d'automatisme serveur et un module de gestion sécurité analysant ladite réponse en fonction dudit en-tête de sécurité serveur.

L'en-tête de sécurité client comprend un code fonction sécurité et un code d'authentification de l'équipement d'automatisme client. Selon une caractéristique, l'en-tête de sécurité client comprend également un code de niveau de sécurité d'échange requis par l'équipement d'automatisme serveur ainsi qu'un code d'intégrité permettant de garantir l'intégrité des données échangées.

L'invention décrit également un système de communication sécurisé d'un équipement d'automatisme serveur capable de communiquer avec au moins un équipement d'automatisme client par l'échange de requêtes et de réponses de communication non-sécurisées conformes à un protocole de communication application. Le système comporte un module de détection d'un en-tête de sécurité client contenu dans une requête sécurisée ou non-sécurisée conforme au protocole de communication application et reçue de l'équipement d'automatisme client, un module de gestion sécurité susceptible d'autoriser l'exécution d'une requête non-sécurisée contenue dans une requête sécurisée, en fonction de l'en-tête de sécurité client, en fonction d'informations contenues dans la requête non-sécurisée et en fonction d'une liste de contrôle d'accès accessible à l'équipement d'automatisme serveur. Le système comporte aussi un module de génération susceptible d'ajouter un en-tête de sécurité serveur dans une réponse nonsécurisée, pour créer une réponse sécurisée conforme au protocole de communication application et envoyée à l'équipement d'automatisme client.

Selon une caractéristique, les informations contenues dans la requête nonsécurisée comprennent un code fonction application et éventuellement des données associées à ce code fonction application.

Selon une autre caractéristique, les requêtes et réponses sécurisées sont acheminées au moyen d'un réseau Ethernet ou au moyen d'une liaison série.

D'autres caractéristiques et avantages vont apparaître dans la description détaillée qui suit en se référant à un mode de réalisation donné à titre d'exemple et représenté par la figure 1 qui schématise un système de communication sécurisé entre deux équipements d'automatisme client et serveur selon l'invention.

La figure 1 m outre u n p remier é quipement d'automatisme 20 e t un s econd équipement d'automatisme 40 connectés sur un réseau de communication 10 de façon à pouvoir échanger entre eux des trames de communication 11,12. Au niveau de la couche OSI application, le premier et le second équipement 20,40 communiquent entre eux via un protocole de communication application de type "client-serveur", tel que le protocole MODBUS. Dans ce type de protocole de communication bien connu, les équipements "client" émettent des requêtes de communication (appelées requêtes) à destination d'équipements "serveur" qui traitent ces requêtes et renvoient des réponses de communication (appelées réponses) aux équipements "client".

II est évident que d'autres équipements non-représentés peuvent également être connectés au même réseau de communication 10 et échanger avec le premier et/ou le second équipement. De même, il est évident qu'un même équipement d'automatisme peut se comporter à la fois comme "client" vis-àvis de certains équipements et comme "serveur" vis-à-vis d'autres équipements.

Il est connu que tout équipement d'automatisme "client" 20 conforme à un protocole de communication application de type "client-serveur" est capable d'envoyer une requête de communication 11 à un équipement d'automatisme "serveur" 40, lequel est capable de traiter la requête et d'y répondre en renvoyant une réponse de communication 12 à l'équipement d'automatisme "client" 20. Lorsque ces trames de communication ne comportent pas de sécurité, elles seront appelées: requête non- sécurisée et réponse non-sécurisée.

Une requête non-sécurisée est habituellement composée d'un code fonction application client, qui indique à l'équipement serveur la fonction demandée par l'équipement client, suivie d'éventuelles données associées. De même, une réponse est habituellement composée d'un code fonction serveur suivie d'éventuelles données.

Le code fonction serveur renseigne l'équipement client sur l'éventuelle action effectuée par l'équipement serveur (sous forme de réponse, compterendu, code d'erreur,...). Ces informations constituent la trame utile ou PDU (Protocol Data Unit). Certains protocoles de communication application imposent une longueur utile maximale autorisée de la trame PDU.

En fonction des couches OSI inférieures traversées pour communiquer via le réseau de communication utilisé, cette trame PDU peut être ensuite encapsulée avec d'autres informations (de type adresse, checksum,...) pour former la trame circulant réellement sur le réseau de communication. La longueur utile maximale de la trame PDU peut alors dépendre des différentes couches OSI inférieures utilisées.

En référence à la figure 1, l'équipement client 20 comporte des moyens d'émission 29 de trames 11 sur le réseau 10 et des moyens de réception 24 de trames 12 provenant du réseau 10. De même, l'équipement serveur 40 comporte des moyens d'émission 49 de trames 12 sur le réseau 10 et des moyens de réception 44 de trames 11 provenant du réseau 10. Ces moyens d'émission 29,49 et de réception 24,44 gèrent notamment les couches OSI inférieures du réseau de communication 10. Le réseau 10 peut être indépendamment un réseau de type Ethernet, Ethernet TCP/IP, un réseau de type liaison série de type point-à-point ou multipoints, ou autres.

L'équipement client 20 comporte un module de génération 28 capable de générer une requête non-sécurisée conforme au protocole de communication application, à partir d'informations fournies par une unité de traitement 21 de l'équipement client 20. Selon l'invention, ce module de génération 28 est susceptible d'ajouter un en-tête de sécurité client dans une requête non-sécurisée, pour créer une requête sécurisée conforme au protocole de communication application et envoyée à l'équipement serveur 40 à l'aide des moyens d'émission 29.

De même, l'équipement serveur 40 comporte un module de génération 48 d'une réponse non-sécurisée conforme au protocole de communication application, à partir d'informations fournies par une unité de traitement 41 de l'équipement serveur 40. Ce module de génération 48 est susceptible d'ajouter un en-tête de sécurité serveur dans une réponse non-sécurisée, pour créer une réponse sécurisée conforme au protocole de communication application et envoyée à l'équipement client 20 à l'aide des moyens d'émission 49.

L'équipement client 20 comporte un module de détection 23 capable de reconnaître la présence d'un en-tête de sécurité serveur dans toute réponse 12 sécurisée ou non-sécurisée conforme au protocole de communication application, reçue par 1 es m oyens de réception 24 et provenant de l'équipement d'automatisme serveur 40. En fonction du résultat de cette détection, un module de gestion sécurité 22 analyse la réponse 12 en vue d'effectuer le traitement correspondant.

De même, l'équipement serveur 40 comporte un module de détection 43 d'un en-tête de sécurité client dans toute requête 11 sécurisée ou nonsécurisée conforme au protocole de communication application, reçue par les moyens de réception 44 et provenant de l'équipement client 20. En fonction du résultat de cette détection, un module de gestion sécurité 42 autorise ou non la requête 11 permettant à l'unité de traitement 41 de faire le traitement et de fournir les informations pour générer une réponse 12.

Puisque selon l'invention les requêtes et les réponses sécurisées restent conformes au protocole de communication application, elles peuvent être traitées par tout équipement capable de communiquer selon ce protocole application, y compris des équipements existants ne possédant pas le système de communication sécurisé décrit dans l'invention. Lorsqu'un équipement existant client émet une requête non-sécurisée pour accéder à des informations sécurisées d'un équipement serveur, il reçoit une réponse conforme au protocole application, lui indiquant un code d'erreur. De même, si un équipement client muni du système de communication sécurisé émet une requête sécurisée pour accéder à des informations non- sécurisées d'un équipement serveur existant, celui-ci renvoie un code d'erreur conforme au protocole application, compréhensible par l'équipement client qui pourra alors ré-émettre une requête non-sécurisée. Ceci présente l'avantage d'une compatibilité ascendante entre tous les équipements. Ainsi, des communications sécurisées et non-sécurisées peuvent circuler sur un même réseau.

Les trames non-sécurisées (respectivement requêtes ou réponses) sont encapsulées par les en-têtes de sécurité (respectivement client ou serveur). Dans le mode de réalisation présenté, ces en-têtes sont placés devant le code fonction application contenu dans les trames nonsécurisées, pour former les trames de communication sécurisées (respectivement requêtes ou réponses). Si, à cause de l'adjonction d'un en-tête de sécurité (respectivement client ou serveur), une requête ou une réponse sécurisée dépasse la longueur maximale autorisée par le protocole de communication application, alors les modules de génération (respectivement 28 ou 48) sont capables de modifier la longueur totale de la trame en supprimant des données contenues dans la trame non-sécurisée, de façon à ce que la trame sécurisée correspondante reste conforme au protocole de communication application. Dans ce cas, ceci entraîne un découpage des données à émettre et donc la génération par les modules 28 ou 48 d'une trame complémentaire de façon à envoyer les données qui ont été supprimées pour respecter la longueur maximale des trames. Cette modification de la longueur de trame est gérée par les modules de génération 28 ou 48 de façon transparente.

L'en-tête de sécurité client comporte un code fonction sécurité, par exemple codé sur un octet numérique, et un code d'authentification de l'équipement client 20, qui est soit propre à cet équipement client, soit propre à un utilisateur à l'origine de la requête émies par l'équipement client. Selon un mode de réalisation préféré, le code d'authentification client est composé de plusieurs octets numériques, par exemple quatre octets, ce code pouvant résulter de l'application d'un algorithme de type HASH sur une information de type nom d'utilisateur/mot de passe.

Selon une variante de l'invention, l'en-tête de sécurité client comporte également un code de niveau de sécurité d'échange (codé sur un octet numérique) qui permet de préciser le niveau de sécurité utilisé lors de la constitution de l'en-tête de sécurité. En effet, l'équipement serveur a la possibilité d'implémenter plusieurs niveaux de sécurité et de requérir pour chaque équipement client l'utilisation d'un niveau de sécurité spécifique, ce niveau pouvant être différent suivant l'équipement client. A chaque niveau de sécurité requis par l'équipement serveur, correspondent différents algorithmes de codage de l'en-tête. Lorsqu'un équipement client envoie une requête, il inclut dans l'en-tête de sécurité client un code du niveau de sécurité d'échange qui doit être celui requis par l'équipement serveur pour que l'exécution de la requête soit autorisée. Si le niveau de sécurité émis par l'équipement client n'est celui requis par l'équipement serveur, celui-ci renvoie une réponse d'erreur avec un code d'exception contenant le code du niveau de sécurité d'échange requis et d'éventuelles informations complémentaires qui devront être prises en compte par l'équipement client lors de la constitution de sa prochaine requête sécurisée.

Pour pouvoir s'adapter à de petits équipements d'automatisme ayant une faible puissance CPU, l'algorithme choisi pour le niveau de sécurité d'échange le plus bas doit être simple, par exemple de type CRC32. D'autres algorithmes plus complexes peuvent évidemment être choisis lorsqu'un niveau de sécurité d'échange plus élevé est requis. Optionnellement, en fonction du niveau de sécurité d'échange requis, l'entête de sécurité client comporte un code d'intégrité chiffré ou non permettant de vérifier l'intégrité des données contenues dans la requête, par exemple au moyen d'un algorithme de chiffrage de type MD5.

Le code d'authentification client peut être mémorisé dans un emplacement mémoire 25 de l'équipement client 20, relié au module de génération 28. Alternativement, le code d'authentification client peut être stocké à l'extérieur de l'équipement client 20, mais accessible à l'équipement client 20, par exemple via un réseau local ou global de type Intranet, Extranet ou Internet. Alternativement, pour améliorer la sécurité des échanges, le code d'authentification client n'est pas mémorisé mais est directement calculé, en utilisant l'algorithme adéquat, par le module de génération 28 à partir d'une information d'identification, par exemple un mot de passe, fournie par un utilisateur via des moyens de dialogue, de type é cran/clavier, connectés à l'équipement client 20.

Pour autoriser l'exécution d'une fonction contenue dans une requête reçue par l'équipement serveur 40, le module de gestion sécurité 42 vérifie l'intégrité du code d'authentification client, après l'avoir au préalable déchiffré si le niveau de sécurité requis impliquait un chiffrement du code d'authentification par l'équipement client, puis vérifie sa présence dans une liste de contrôle d'accès. Cette liste de contrôle d'accès peut être mémorisée dans un emplacement mémoire 45 de l'équipement serveur 40, relié au module de gestion sécurité 42. Alternativement, la liste d e contrôle d'accès peut être stockée à l'extérieur de l'équipement serveur 40, mais accessible à l'équipement serveur 40, par exemple via un réseau local ou global de type Intranet, Extranet ou Internet. La liste de contrôle d'accès peut comporter indifféremment: É des authentifications clients seules, permettant d'autoriser ou non l'accès complet de l'équipement serveur à certains clients, et/ou É des authentifications clients en combinaison avec des codes fonctions application, par exemple pour n'autoriser l'accès de l'équipement serveur qu'à certaines fonctions pour certains clients, et/ou É des authentifications clients en combinaison avec des codes fonctions application et des données associées contenues dans la requête, pour restreindre l'exécution de certaines fonctions en fonction de ces données associées, par exemple pour n'autoriser une fonction application de type lecture ou écriture que sur certaines variables de l'équipement serveur. 30

L'en-tête de sécurité serveur comporte un code fonction sécurité, pouvant être défini comme étant identique à celui contenu dans l'en-tête de sécurité client. Suivant le niveau de sécurité correspondant au code fonction sécurité requis, l'en-tête de sécurité serveur peut aussi comporter des données de sécurité complémentaires identifiées sous la dénomination "challenge" et utilisées par le client lors de la constitution et du chiffrement de l'entête de sécurité client, tel qu'un code aléatoire dans le cas de l'utilisation d'un algorithme de chiffrage de type MD5.

Le fonctionnement de divers cas de figures sont décrits ci-après avec 10 l'utilisation du protocole de communication MODBUS: Scénario 1: Un équipement client 20 demande à un équipement serveur 40 d'exécuter une fonction. Si l'équipement client 20 ne dispose pas du système de communication sécurisé décrit dans l'invention ou si l'équipement client 20 sait que le traitement demandé ne nécessite pas d'accès sécurisé d ans l'équipement serveur 4 0, a lors 1 e module de génération 28 émet une requête non-sécurisée classique conforme au protocole de communication application incluant un code fonction application qui correspond à la fonction demandée.

la) Si l'équipement serveur destinataire de cette requête Il nonsécurisée n'est pas un équipement serveur disposant du système de communication sécurisé 20 décrit dans l'invention, alors la requête nonsécurisée est traitée de façon habituelle et une réponse 12 est renvoyée, conformément au protocole de communication application.

lb) Si l'équipement serveur destinataire est un équipement serveur 40 possédant le système de communication sécurisé décrit dans l'invention, alors le module de détection 43 de l'équipement serveur 40 détecte que la requête reçue est non-sécurisée, car ne comportant pas d'en-tête de sécurité client. Le module de gestion sécurité 42 analyse ensuite le code fonction application, ainsi qu'éventuellement les données associées, contenues dans la requête non-sécurisée.

i. Si l'exécution du traitement correspondant au code fonction application (et éventuellement aux données associées) contenu dans la requête n'est pas protégée et n'exige pas l'utilisation d'une requête sécurisée, alors l'équipement serveur exécute le traitement. Le module de génération 48 de l'équipement serveur 40 renvoie ensuite une réponse 12 non- sécurisée conforme au protocole de communication application, sans intégrer un en-tête de sécurité serveur. Cette réponse classique sera comprise par tout équipement client 20.

ii. Si l'exécution du traitement correspondant au code fonction application (et éventuellement aux données associées) contenu dans la requête est protégée et implique l'emploi d'une requête sécurisée, alors la demande de traitement est refusée par le module de gestion sécurité 42, puisque aucun en-tête de sécurité client n'est présent dans la requête 11. En réponse à cette requête non-sécurisée, le module de génération 48 renvoie à l'équipement client une réponse 12 non-sécurisée contenant un code d'erreur conformément au protocole de communication application et donc compréhensible par tout équipement client 20.

Dans le cas d u protocole MODBUS, u n code d'erreur est formé par le code fonction application ajouté de la valeur "128". Ce code d'erreur peut être suivi d'une information complémentaire appelée code d'exception détaillant la raison de l'erreur. Par exemple, il existe déjà un code exception "Acces_illegal", signifiant que la requête n'a pas pu être exécutée. Dans le cas présent, ce code d'exception peut être utilisé car l'équipement client ne dispose pas des droits requis. Le code exception peut également intégrer un code de niveau de sécurité requis par l'équipement serveur.

1c) L'équipement client reçoit la réponse contenant un code d'erreur suivi d'un code exception "Acces_illegal". Comme cette réponse est conforme au protocole MODBUS, elle est compréhensible par tout équipement client.

i. Si l'équipement client ne dispose pas du système de communication sécurisé ou s'il ne dispose pas des mécanismes nécessaires au niveau de sécurité requis, il en conclut que l'accès à l'équipement serveur est impossible et la transaction s'achève sans que la requête soit exécutée par l'équipement serveur.

ii. Si l'équipement client est un équipement disposant du système de communication sécurisée et s'il dispose des mécanismes nécessaires au niveau de sécurité requis, il sait qu'il lui faut générer une requête sécurisée compatible avec le niveau de sécurité requis par l'équipementserveur. Suivant le niveau de sécurité requis, cette génération pourra 10 20 nécessiter des informations complémentaires fournies par l'équipement serveur, le "challenge", qui seront alors utilisées par les mécanismes de chiffrement de l'entête de sécurité de la requête sécurisée.

Scénario 2: Un équipement client 20, disposant du système de communication sécurisé décrit dans l'invention, requiert une fonction à un équipement serveur. Il prépare alors une requête non-sécurisée classique conforme au protocole de communication application en incluant un code fonction application correspondant à la fonction demandée.

Le module de génération 28 de l'équipement client 20 y ajoute ensuite un en-tête de sécurité client pour créer une requête 11 sécurisée compatible avec le niveau requis, envoyée à l'équipement serveur. Cet en-tête de sécurité client comprend le code fonction sécurité et le code d'authentification de l'équipement client ou de l'utilisateur travaillant sur l'équipement client.

L'en-tête de sécurité client peut aussi comporter un code indiquant le niveau de sécurité associé. Suivant le niveau de sécurité requis, il peut être nécessaire de disposer d'informations complémentaires fournies par l'équipement serveur, principalement pour effectuer les opérations de chiffrement de l'entête de sécurité client.

2a) Si l'équipement serveur destinataire de cette requête 11 sécurisée ne dispose pas du système de communication sécurisé décrit dans l'invention, il ne peut pas comprendre le code fonction sécurité placé en tête de la requête, puisque ce code fonction sécurité fixe ne correspond à aucune des fonctions application disponibles dans le protocole de communication application. II renvoie alors une réponse contenant un code erreur (code fonction sécurité + "128") suivi d'un code exception indiquant un code fonction illégal. Ainsi, l'équipement client 20 expéditeur sait que l'équipement serveur n'est pas capable de traiter les requêtes sécurisées. Il pourra néanmoins accéder à cet équipement serveur en émettant des requêtes classiques non-sécurisées (voir scénario la).

2b) Si l'équipement serveur destinataire est un équipement serveur 40 possédant le système de communication sécurisé décrit dans l'invention, alors le module de détection 43 de l'équipement serveur 40 détecte que la requête 12 reçue est une requête sécurisée grâce au code fonction sécurité. Il lit alors le code d'authentification client (éventuellement chiffré si le niveau de sécurité d'échange le requiert), ainsi que les informations application reçues dans la requête non-sécurisée (code fonction application et données associées).

i. Si le code fonction application reçu ne correspond pas à une fonction exigeant un accès sécurisé dans l'équipement serveur 40, le module de gestion sécurité 42 autorise l'exécution de la fonction demandée. Le module de génération 48 de l'équipement serveur 40 renvoie ensuite une réponse 12 sécurisée conforme au protocole de communication application, en intégrant un en-tête de sécurité serveur.

ii. Si le code fonction application reçu correspond à une fonction exigeant un accès sécurisé dans l'équipement serveur 4 0, 1 e module d e g estion sécurité 42 vérifie alors les informations reçues par rapport à celles contenues dans sa liste de contrôle d'accès, comme indiqué précédemment. Il vérifie également que le niveau de sécurité d'échange reçu est bien le niveau requis par l'équipement serveur 40.

É Si les vérifications sont bonnes, le module de gestion sécurité 42 autorise l'unité de traitement 41 à exécuter la requête reçue. Le module de génération 48 ajoute ensuite un en-tête de sécurité serveur pour créer une réponse sécurisée 12 à destination de l'équipement client 20.

É Si l'une des vérifications n'est pas bonne, le module de gestion sécurité 42 interdit l'exécution de la requête. Le module de génération 48 renvoie alors une réponse sécurisée 12 vers l'équipement client 20 contenant un code d'erreur (= code fonction sécurité + "128") suivi d'un code d'exception associé à un éventuel "challenge". Le code d'exception contient le code du niveau de sécurité d'échange qui est requis par l'équipement serveur 40. Ce code d'exception sera analysé par le module de gestion sécurité 22, de façon à permettre à l'équipement client 20 d'utiliser le bon niveau de sécurité d'échange lors d'une prochaine requête.

Bien que ces codes d'exception soient s pécifiques à l'invention, s i une telle réponse est reçue par un équipement client existant ne disposant pas du système décrit dans l'invention, cet équipement existant est néanmoins capable de détecter le code d'erreur contenu 30 dans la réponse et donc d e comprendre q ue l'accès à la fonction demandée dans l'équipement serveur ne lui est pas possible, ce qui permet de conserver avantageusement une compatibilité des échanges avec tout équipement existant conforme au protocole application.

II est bien entendu que l'on peut, sans sortir du cadre de l'invention, imaginer d'autres variantes et perfectionnements d e d étail et de m ême e nvisager l'emploi d e moyens équivalents.

Claims (19)

REVENDICATIONS

1. Système de communication sécurisé dans un équipement d'automatisme client 20 capable de communiquer avec au moins un équipement d'automatisme serveur 40 par l'échange de requêtes et de réponses de communication non-sécurisées conformes à u n p rotocole d e communication application, caractérisé en ce que le système comporte: un module de génération 28 susceptible d'ajouter un en-tête de sécurité client dans une requête non-sécurisée, pour créer une requête sécurisée 11 conforme audit protocole de communication application et envoyée à l'équipement d'automatisme serveur 40, l'en-tête de sécurité client comprenant un code fonction sécurité et un code d'authentification de l'équipement client 20, un module de détection 23 d'un en-tête de sécurité serveur contenu dans une réponse sécurisée ou non-sécurisée 12 conforme audit protocole de communication application et provenant de l'équipement serveur 40, un module de gestion sécurité 22 analysant ladite réponse sécurisée 12 en fonction dudit en-tête de sécurité serveur.

2. Système de communication selon la revendication 1, caractérisé en ce que le code d'authentification est mémorisé dans l'équipement client 20.

3. Système de communication selon la revendication 1, caractérisé en ce que le code d'authentification est mémorisé à l'extérieur de l'équipement client 20 et est accessible par l'équipement client 20.

4. Système de communication selon la revendication 1, caractérisé en ce que le code d'authentification est composé de plusieurs octets numériques calculés par le module de génération 28 à partir d'une information d'identification renseignée par un utilisateur.

5. Système de communication selon la revendication 1, caractérisé en ce que l'en-tête de sécurité client comprend également un code de niveau de sécurité d'échange soumis à l'équipement serveur 40.

6. Système de communication selon l'une des revendications 1 à 5, caractérisé en ce que le module de génération 28 est capable de modifier la longueur de la requête non-sécurisée, en cas de dépassement de la longueur de la requête sécurisée 11 par rapport à une longueur maximale autorisée par ledit protocole de communication application.

7. Système de communication selon l'une des revendications 1 à 6, caractérisé en ce que la requête sécurisée 11 est acheminée vers l'équipement serveur 40 au moyen d'un réseau Ethernet.

8. Système de communication selon l'une des revendications 1 à 6, caractérisé en ce que la requête sécurisée 11 est acheminée vers l'équipement serveur 40 au moyen d'une liaison série.

9. Système de communication selon l'une des revendications 1 à 6, caractérisé en ce que ledit protocole de communication application est le protocole MODBUS.

10. Système de communication sécurisé dans un équipement d'automatisme serveur 40 capable de communiquer avec au moins un équipement d'automatisme client 20 par l'échange de requêtes et de réponses de communication non-sécurisées conformes à un protocole de communication application, caractérisé en ce que le système comporte: un module de détection 43 d'un en-tête de sécurité client contenu dans une requête sécurisée ou non-sécurisée 11 conforme audit protocole de communication application et reçue de l'équipement client 20, l'en-tête de sécurité client comprenant un code fonction sécurité et un code d'authentification de l'équipement client 20, un module de gestion sécurité 42 susceptible d'autoriser l'exécution d'une requête non-sécurisée contenue dans une requête sécurisée 11, en fonction dudit en-tête de sécurité client, en fonction d'un code fonction application contenu dans ladite requête nonsécurisée et en fonction d'une liste de contrôle d'accès accessible à l'équipement serveur 40, un module de génération 48 susceptible d'ajouter un en-tête de sécurité serveur dans une réponse non-sécurisée, pour créer une réponse sécurisée 12 conforme audit protocole de communication application et envoyée à l'équipement client 20.

11. Système de communication selon la revendication 10, caractérisé en ce que la réponse sécurisée 12 comporte un code de niveau de sécurité d'échange requis par l'équipement serveur 40.

12. Système de communication selon la revendication 11, caractérisé en ce que l'en-tête de sécurité client comporte un code de niveau de sécurité d'échange soumis à l'équipement serveur 40.

13. Système de communication selon la revendication 10, caractérisé en ce que le module de génération 48 est capable de modifier la longueur de la réponse non-sécurisée, en cas de dépassement de la longueur de la réponse sécurisée 12 par rapport à une longueur maximale autorisée par ledit protocole de communication application.

14. Système de communication selon l'une des revendications 10 à 13, caractérisé en ce que la réponse sécurisée 12 est acheminée vers l'équipement client 20 au moyen d'un réseau Ethernet.

15. Système de communication selon l'une des revendications 10 à 13, caractérisé en ce que la réponse sécurisée 12 est acheminée vers l'équipement client 20 au moyen d'une liaison série.

16. Système de communication selon l'une des revendications 10 à 15, caractérisé en ce que ledit protocole de communication application est le protocole MODBUS.

17. Procédé de communication sécurisé entre un équipement d'automatisme client 20 et un équipement d'automatisme serveur 40 capables de communiquer entre eux par l'échange de requêtes et de réponses de communication non-sécurisées conformes à u n p rotocole de communication application, caractérisé en ce que le procédé comporte: une étape d'adjonction, par l'équipement client 20, d'un en-tête de sécurité client dans une requête non-sécurisée, pour créer une requête sécurisée 11 conforme audit protocole de communication application, l'en-tête de sécurité client comprenant un code fonction sécurité et un code d'authentification de l'équipement client 20, une étape d'envoi de ladite requête sécurisée 11 vers l'équipement serveur 40, une étape de détection par l'équipement serveur 40 dudit l'en-tête de sécurité client contenu dans ladite requête sécurisée 11, une étape de gestion sécurité permettant d'autoriser ou non l'exécution de la requête non-sécurisée en fonction dudit en-tête de sécurité client, e n fonction d'un code fonction application contenu dans ladite requête non-sécurisée et en fonction d'une liste de contrôle d'accès accessible à l'équipement d'automatisme serveur 40.

18. Procédé de communication selon la revendication 1 7, caractérisé en ce que l'étape d'adjonction comporte une étape de modification de la longueur de la requête non-sécurisée, en cas de dépassement de la longueur de la requête sécurisée par rapport à une longueur maximale autorisée par ledit protocole de communication application.

19. Système de communication selon la revendication 18, caractérisé en ce que ledit protocole de communication application est le protocole MODBUS.