EP3314498A1 - Systeme de securite pour systeme de controle industriel - Google Patents

Systeme de securite pour systeme de controle industriel

Info

Publication number
EP3314498A1
EP3314498A1 EP16730712.3A EP16730712A EP3314498A1 EP 3314498 A1 EP3314498 A1 EP 3314498A1 EP 16730712 A EP16730712 A EP 16730712A EP 3314498 A1 EP3314498 A1 EP 3314498A1
Authority
EP
European Patent Office
Prior art keywords
security
entity
hardware
software
user
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP16730712.3A
Other languages
German (de)
English (en)
Inventor
Zakarya DRIAS
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Schneider Electric Industries SAS
Original Assignee
Schneider Electric Industries SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Schneider Electric Industries SAS filed Critical Schneider Electric Industries SAS
Publication of EP3314498A1 publication Critical patent/EP3314498A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/41—User authentication where a single sign-on provides access to a plurality of computers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/418—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM]

Definitions

  • the present invention relates to a security system for an industrial control system.
  • An industrial control system refers generally to a control system used in the industrial field and including SCADA-type supervision solutions, distributed control systems (DCS) ) or any other solution that includes one or more Programmable Logic Controllers (PLC).
  • an industrial control system is designed to configure, supervise and manage critical infrastructures such as those related to an electricity generating station, a nuclear power plant, a water treatment plant, mining or quarrying solutions. gas, a pharmaceutical or chemical manufacturing process.
  • the system thus comprises one or more hardware entities and / or software entities installed and accessible through one or more security portals.
  • a hardware entity may be a programmable logic controller (PLC), a sensor, an actuator, etc.
  • PLC programmable logic controller
  • a software entity is software implemented to configure, manage, control or supervise the system and one or more of its hardware entities. defined above.
  • WO2006 / 059195A1 discloses a secure power management architecture comprising a plurality of intelligent electronic devices connected to each other.
  • the object of the invention is to propose a security system for an industrial control system making it possible to prevent a user from logging in whenever he wishes to access a hardware entity and / or a software entity of the control system. industrial.
  • the solution of the invention makes it possible to manage the identity data of each user or material entity of the system originating from action in the system, as well as the access control to the resources of the various entities of the system.
  • a security system for an industrial control system that comprises one or more hardware entities and / or one or more software entities accessible by at least one user through at least one security portal, the security system comprising :
  • a security database arranged to memorize:
  • security tokens generated for each user and each hardware entity each security token comprising the data signed by a security server and relating to the identity of the user or of the material entity and the rights data; access granted to the user or the physical entity,
  • a security server comprising:
  • a verification module in the security database of the identity data of a user or of a material entity
  • Each hardware entity or software entity comprises a software agent comprising:
  • a security token receiving module arranged to receive and memorize each received token and to sign the security token received from a security portal or a first hardware entity and to transfer this signed token to a second hardware entity or software to which the security portal or the first hardware entity wishes to access.
  • each software agent comprises a cryptographic key management module arranged for the generation, exchange, storage, use and replacement of cryptographic keys necessary to sign a security token or to decrypt it.
  • each software agent comprises one or more cryptographic libraries.
  • the software agent of a hardware entity includes an authentication module arranged to send the identity of the hardware entity to the security server to receive a security token from him.
  • FIG. 1 schematically represents the architecture of the security system of the invention used to secure an industrial control system
  • FIG. 2 illustrates the procedure for registering a user and adding a hardware entity to the security system of the invention
  • FIG. 3 illustrates the procedure for enrolling a hardware entity and authentication. of this entity
  • FIG. 4 illustrates the procedure for authentication of a user and access to a software entity by a user
  • FIG. 5 illustrates the procedure of access of a user to a hardware entity via a software entity
  • FIG. 6 illustrates the procedure for accessing a physical entity to another physical entity
  • Figure 7 illustrates the procedure for updating a security token
  • Figures 8A and 8B show two separate architectures of a security token.
  • an industrial control system is for example intended to manage a critical infrastructure and comprises one or more hardware entities and / or one or more software entities.
  • a hardware entity is for example a programmable logic controller, a sensor, an actuator, etc.
  • a software entity is intended to manage the configuration and / or operation of one or more hardware entities of the system.
  • the user 1 can be brought to connect to a hardware entity 5 or a software entity 5 of the system via a security gateway 10,
  • a hardware entity 5a or a software entity 6a may be made to connect to another hardware entity 5b or to another software entity 6b.
  • the security system of the invention mainly comprises the following elements:
  • the security database 4 is intended to store different types of security data:
  • authentication data 40 authorization data 41,
  • a file in a suitable format for example XACML (for Extensible Access Control Markup Language), to summarize the authorizations associated with each user 1 or hardware entity 5 of the system and a copy of the associated security token.
  • XACML Extensible Access Control Markup Language
  • the security token corresponds to the XACML file described above, timestamped and signed by the security server 3.
  • the security server 3 is intended in particular to manage the authentication of each user 1 and each hardware entity 5 of the system. It includes:
  • Each hardware entity 5 comprises a software agent 50 whose responsibility is to manage all the security operations related to the physical entity with which it is associated.
  • such software agent 50 comprises:
  • a security token receiving module 502 arranged to receive and memorize each received token and to sign the security token received from a security gateway 10 or a first entity and to transfer this signed token to a second entity to which the security gateway 10 or the first entity wishes to access,
  • a cryptographic key management module 503 arranged for the generation, exchange, storage, use and replacement of cryptographic keys, one or more cryptographic libraries 504 such as, for example, OpenSSL,
  • an authentication module 505 arranged to send the identity (certificate) of the hardware entity to the security server 3 to receive from it a security token.
  • Each software entity 6 also comprises a software agent 60 whose responsibility is to manage all the security operations related to the software entity 6 with which it is associated.
  • This agent comprises:
  • a security token receiving module 602 arranged to receive, memorize each received token and to sign the security token received from a security gate or a first entity and to transfer this signed token to a second entity to which the security portal or the first entity wishes to access,
  • cryptographic libraries 603 such as for example OpenSSL.
  • the access rights analysis module 501, 601 analyzes the architecture of the XACML file which includes a point of application of the decision (PEP for "Policy Enforcement Point”). and a Policy Decision Point (PDP).
  • PEP Policy Enforcement Point
  • FIG. 8A shows the architecture of a security token, respectively when it comes from the security server and when it is transmitted by a software agent.
  • the security token transmitted by the security server is a file that includes the following data:
  • This file is signed (signature 85) by the security server 3 with the aid of a private key in order to generate the security token.
  • the security token transmitted by a software agent 50, 60 of a hardware entity 5 or of a software entity 6 consists of the security token described above which is additionally signed (signature 86). by the software agent 50, 60 in order to be authenticated by the receiver.
  • the security system may comprise a certification authority 7 intended in particular to provide the certificates for each hardware and software entity of the system.
  • the certification authority interacts with the security server to provide, upon request from the security server, each certificate associated with a hardware and software entity of the system.
  • the certificates are stored in a database managed by the CA.
  • the certification authority 7 also has the means to generate new certificates and to check whether the certificates of each hardware and software entity are up to date.
  • the security system of the invention uses a conventional encryption system based on a public key mechanism and private key, for example TLS / SSL.
  • FIG. 2 illustrates the principle of registering a user 1 and a hardware entity 5 of a system by an administrator 2 connected to the security server through the administration software tool 20 executed on a computer station.
  • the administrator 2 For all administration task, the administrator 2 must first identify (A1) to the security server 3 via the administration software tool 20.
  • A1 the procedure follows the steps following:
  • A2 the administrator 2 sends to the security server 3 a request to add a user 1, along with the identification data of the user 1,
  • A3 the security server 3 issues a command to write the identification data relating to the user 1 in the security database 4,
  • A4 The security database 4 confirms to the security server 3 the addition of the user 1,
  • A5 The security server 3 confirms the addition of the user in the security database 4.
  • the procedure comprises the following steps:
  • the security server 3 sends a request to the certification authority 7 in order to obtain the certificate of the hardware entity 5 to be registered
  • the security server 3 sends a command to write identification data, including the obtained certificate, related to the hardware entity 5 in the security database 4,
  • security database 4 confirms the registration of the physical entity
  • the security server confirms the addition of the hardware entity to the administrator.
  • FIG. 3 illustrates the procedure for enrolling a hardware entity 5 and its authentication: C1: via the administrator interface of the security server 3, the administrator 1 issues a "Discover" command of the security server in order to determine the hardware entities of the system,
  • the security server 3 sends a request for a certificate request to the software agent 50 of a hardware entity 5 of the system,
  • the security server 3 sends a request for enrollment to the authentication module of the software agent 50 of the hardware entity with the address of the certification authority 7 in order to obtain a certificate from the certification authority 7,
  • the software agent 50 of the hardware entity 5 sends a request to the certification authority 7, for example in the form of a request based on the SCEP protocol ("Simple Certificate Enrollment Protocol"), to obtain a valid certificate,
  • SCEP protocol Simple Certificate Enrollment Protocol
  • the certification authority 7 generates a certificate for the hardware entity 5 and responds to the request by sending the certificate to the software agent 50 of the hardware entity 5,
  • C1 1 the security server 3 validates the authentication of the hardware entity 5 with the administrator 2.
  • C12 the administrator 2, from the administrative software tool 20, enters the configuration data of the hardware entity 5, including the data related to the access rights of this hardware entity
  • C13 the administrator 2 sends a request to save the configuration data of the hardware entity to the security server 3 for the creation of the XACML file for the hardware entity 5
  • C17 the receiving module of the hardware entity stores the received token.
  • Figure 4 illustrates the procedure of access of a user to a software entity. This procedure consists of the following steps:
  • the software entity 6 requests its software agent 60 to authenticate this user 1 and to check its access rights
  • D5 the software agent sends a request to the security portal to obtain the current security token associated with the user
  • the security gateway sends the security token to the software agent of the software entity
  • D8 the software entity agent verification module checks the received security token for authentication
  • D8 the software agent's software agent analysis module checks the user's access rights
  • the security portal asks the user to enter his identity data (username, password),
  • the security portal issues a request to the security server to obtain a security token by issuing the user's identity data
  • the security server checks the identity data received from the security database:
  • the security server sends a request to the security database to obtain the data related to the access rights of the user, that is to say the XACML file associated with this user,
  • Security database 4 returns data related to the user's access rights as the XACML file
  • D21 the security server sends the generated security token to the security gateway
  • D22 the security portal transfers the security token to the software agent of the software entity
  • D23 the software entity agent verification module verifies the received security token for authentication of the user and verification of his access rights
  • FIG. 5 illustrates the procedure implemented for the access of a user to a hardware entity 5 through a software entity 6.
  • the procedure comprises the following steps:
  • E1 the user 1 sends a request to the software entity 6 to perform an operation on a hardware entity 5
  • E2 the software entity 6 requests the hardware entity 5 to establish a secure communication channel (for example under the TLS protocol for Transport Layer Security),
  • the hardware agent verification module 50 of the hardware entity 5 checks the received security token.
  • E7 the software agent of the hardware entity sends a response to the hardware agent's hardware agent to indicate that it is invalid
  • E8 the software agent of the software entity requests an update of the security token to the security portal of the user
  • E9 the security portal asks the user to enter his identity data (username, password)
  • E1 1 the security gate sends a request to the security server for obtaining a security token, along with the identity data of the user,
  • Hardware entity's software agent verification module checks the received security token for authentication, the hardware agent's software agent's scanning module checks the user's access rights ,
  • Figure 6 illustrates the procedure implemented to allow a first hardware entity 5a to access a second hardware entity 5b. It comprises the following steps:
  • the first hardware entity 5a requests the second hardware entity 5b to establish a secure communication channel (for example under the Transport Layer Security TLS protocol),
  • F3 the software agent of the second hardware entity 5b sends a request to the software agent of the first hardware entity 5a to obtain its security token
  • F4 the software agent of the first hardware entity 5a sends its security token to the software agent of the second hardware entity 5b
  • F6 the software agent of the second hardware entity analyzes the access rights of the first hardware entity
  • F1 1 the software agent of the first hardware entity sends a request to the security server to obtain an update of its security token
  • F12 the security server generates a new security token from the XACML file, the security server time stamping and signing said file,
  • F15 the software agent's verification module of the second hardware entity checks the new security token
  • F6 If the new security token is valid, the software agent of the second hardware entity analyzes the access rights of the first hardware entity
  • Figure 7 illustrates the procedure for updating a security token belonging to a hardware entity.
  • a software agent of a hardware or software entity that has received a valid security token can ask if the security token in its possession is up to date.
  • the verification procedure that an up-to-date security token is performed on data representative of a compressed signature of the security token. Thus, only this data is sent by one entity to another.
  • This procedure consists of the following steps:
  • G1 the agent of a first entity (hardware in FIG. 7) requests a verification of the received security token to the software agent of a second (software) entity present in the chain,
  • G3 the software agent of the first entity requests the agent of the second entity the updated security token
  • the software agent of the second entity sends a request to the security portal to find out if the security token is up to date
  • the security portal after verification, if the security token is not up to date, the security portal sends a response to the software agent of the second entity indicating that the security token is not up to date,
  • the security gateway sends a request to the security server to know if the security token is up to date
  • G8 After verification, if the security token is not up to date, the security server sends a response to the security portal indicating that the security token is not up to date
  • G9 the security portal asks the user to enter their identity data
  • G10 the user enters his identity data
  • G1 1 the security gateway sends a request to the security server to obtain a new security token
  • G12 The security server responds to the security portal by sending a new security token to the security portal.
  • a user authenticates one time with the security server, and then any authentication of the user by the different entities is to authenticate the security token that has been associated with it.
  • a user or a hardware entity with a security token has the ability to securely access one or more software hardware entities of the system directly or indirectly on multiple levels.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Databases & Information Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Storage Device Security (AREA)
  • Computer And Data Communications (AREA)

Abstract

Système de sécurité pour un système de contrôle industriel qui comporte une ou plusieurs entités matérielles et/ou une ou plusieurs entités logicielles accessibles par au moins un utilisateur à travers au moins un portail de sécurité, le système de sécurité comportant : - une base de données de sécurité (4), - un serveur de sécurité (3), - Chaque entité matérielle ou logicielle comporte un agent logiciel comprenant : - un module (500) de vérification de chaque jeton de sécurité reçu en provenance d'un portail de sécurité (10) ou d'une entité matérielle ou logicielle (6), - un module (501) d'analyse des droits d'accès de l'utilisateur (1), d'une autre entité logicielle (6) ou matérielle (5), - un module (502) de réception de jeton de sécurité agencé notamment pour transférer un jeton vers une deuxième entité matérielle ou logicielle à laquelle un portail de sécurité (10) ou une autre entité souhaite accéder.

Description

Système de sécurité pour système de contrôle industriel
Domaine technique de l'invention
La présente invention se rapporte à un système de sécurité pour un système de contrôle industriel.
Etat de la technique
Un système de contrôle industriel (ICS pour « Industrial Control System ») désigne de manière générale un système de contrôle employé dans le domaine industriel et incluant des solutions de supervision de type SCADA, des solutions de contrôle distribués (DCS pour « Distributed control Systems ») ou toute autre solution incluant notamment un ou plusieurs contrôleurs logiques programmables (PLC pour « Programmable Logic Controller »). Un système de contrôle industriel est notamment destiné à configurer, superviser et gérer des infrastructures critiques telles que par exemple celles liées à une centrale de production électrique, une centrale nucléaire, une usine de traitement d'eau, des solutions d'extraction minière ou de gaz, un process de fabrication pharmaceutique ou chimique. Le système comporte ainsi une ou plusieurs entités matérielles et/ou entités logicielles installées et accessibles à travers un ou plusieurs portails de sécurité. Une entité matérielle peut être un contrôleur logique programmable (PLC), un capteur, un actionneur... Une entité logicielle est par exemple un logiciel mis en œuvre pour configurer, gérer, commander ou superviser le système et une ou plusieurs de ses entités matérielles définies ci-dessus.
Compte tenu de l'aspect critique des infrastructures décrites ci-dessus, la sécurité informatique est devenue un enjeu majeur pour protéger le système de toute intrusion malveillante.
Aujourd'hui, la sécurité de chaque entité matérielle ou entité logicielle du système est gérée de manière indépendante de sorte qu'un utilisateur doit se connecter à chaque fois, en fournissant des données d'identité (par exemple Login et mot de passe) et en justifiant de droits d'accès spécifiques, qu'il souhaite accéder à une entité matérielle ou une entité logicielle distincte du système de contrôle industriel.
Le document WO2006/059195A1 décrit une architecture de gestion d'énergie sécurisée comportant plusieurs dispositifs électroniques intelligents connectés entre eux. Le but de l'invention est de proposer un système de sécurité pour système de contrôle industriel permettant d'éviter à un utilisateur de se connecter à chaque fois qu'il souhaite accéder à une entité matérielle et/ou une entité logicielle du système de contrôle industriel. La solution de l'invention permet de gérer les données d'identité de chaque utilisateur ou entité matérielle du système, originaire d'action dans le système, ainsi que le contrôle d'accès aux ressources des différentes entités du système.
Ce but est atteint par un système de sécurité pour un système de contrôle industriel qui comporte une ou plusieurs entités matérielles et/ou une ou plusieurs entités logicielles accessibles par au moins un utilisateur à travers au moins un portail de sécurité, le système de sécurité comportant :
- une base de données de sécurité agencée pour mémoriser :
- des données d'identité associés à chaque utilisateur et entité matérielle,
- des données de droits d'accès à chaque entité matérielle ou entité logicielle du système,
- des jetons de sécurité générés pour chaque utilisateur et chaque entité matérielle, chaque jeton de sécurité comprenant les données signées par un serveur de sécurité et relatives à l'identité de l'utilisateur ou de l'entité matérielle et les données de droits d'accès attribués à l'utilisateur ou à l'entité matérielle,
- un serveur de sécurité comprenant :
- un module de vérification dans la base de données de sécurité des données d'identité d'un utilisateur ou d'une entité matérielle,
- un module de génération de jetons de sécurité pour chaque utilisateur ou entité matérielle identifié dans la base de données de sécurité,
- un module de gestion des données d'identité de chaque utilisateur, entité matérielle stockée dans la base de données de sécurité,
- un module de gestion des données de droits d'accès stockées dans la base de données de sécurité,
- Chaque entité matérielle ou entité logicielle comporte un agent logiciel comprenant :
- un module de vérification de chaque jeton de sécurité reçu en provenance d'un portail de sécurité, d'une entité logicielle ou d'une autre entité matérielle, - un module d'analyse des droits d'accès de l'utilisateur, d'une autre entité logicielle ou d'une autre entité matérielle,
- un module de réception de jeton de sécurité agencé pour recevoir et mémoriser chaque jeton reçu et pour signer le jeton de sécurité reçu d'un portail de sécurité ou d'une première entité matérielle et pour transférer ce jeton signé vers une deuxième entité matérielle ou logicielle à laquelle le portail de sécurité ou la première entité matérielle souhaite accéder.
Selon une particularité, chaque agent logiciel comporte un module de gestion de clés cryptographiques agencé pour la génération, l'échange, le stockage, l'utilisation et le remplacement de clés cryptographiques nécessaires pour signer un jeton de sécurité ou pour le décrypter.
Selon une autre particularité, chaque agent logiciel comporte une ou plusieurs librairies cryptographiques.
Selon une autre particularité, l'agent logiciel d'une entité matérielle comporte un module d'authentification agencé pour envoyer l'identité de l'entité matérielle vers le serveur de sécurité pour recevoir de sa part un jeton de sécurité.
Brève description des figures
D'autres caractéristiques et avantages vont apparaître dans la description détaillée qui suit faite en regard des dessins annexés dans lesquels :
la figure 1 représente de manière schématique, l'architecture du système de sécurité de l'invention employé pour sécuriser un système de contrôle industriel,
la figure 2 illustre la procédure d'enregistrement d'un utilisateur et d'ajout d'une entité matérielle dans le système de sécurité de l'invention, la figure 3 illustre la procédure d'enrôlement d'une entité matérielle et d'authentification de cette entité,
la figure 4 illustre la procédure d'authentification d'un utilisateur et d'accès à une entité logicielle par un utilisateur,
la figure 5 illustre la procédure d'accès d'un utilisateur à une entité matérielle via une entité logicielle,
la figure 6 illustre la procédure d'accès d'une entité matérielle à une autre entité matérielle, la figure 7 illustre la procédure de mise à jour d'un jeton de sécurité, les figures 8A et 8B représentent deux architectures distinctes d'un jeton de sécurité.
Description détaillée d'au moins un mode de réalisation
Comme décrit ci-dessus, un système de contrôle industriel est par exemple destiné à gérer une infrastructure critique et comporte une ou plusieurs entités matérielles et/ou une ou plusieurs entités logicielles. Une entité matérielle est par exemple un contrôleur logique programmable, un capteur, un actionneur... Une entité logicielle est par exemple destinée à gérer la configuration et/ou le fonctionnement d'une ou plusieurs entités matérielles du système.
Selon la configuration du système, plusieurs cas d'interaction entre utilisateur, entité matérielle 5 et entité logicielle 6 peuvent se présenter :
- l'utilisateur 1 peut être amené à se connecter à une entité matérielle 5 ou une entité logicielle 5 du système via un portail de sécurité 10,
- une entité matérielle 5a ou une entité logicielle 6a peut être amenée à se connecter à une autre entité matérielle 5b ou à une autre entité logicielle 6b.
Chacun de ces cas de fonctionnement sera décrit ci-dessous, en liaison avec le système de sécurité de l'invention.
Le système de sécurité de l'invention comporte principalement les éléments suivants :
- une base de données de sécurité 4,
- un serveur de sécurité 3,
- des agents logiciels 50, 60 associés chacun à une entité matérielle 5 ou à une entité logicielle 6 distincte.
La base de données de sécurité 4 est destinée à stocker différents types de données de sécurité :
- des données d'authentification 40, - des données d'autorisation 41 ,
- des données 42 liées à la politique de sécurité mise en œuvre pour le système.
Dans les données d'authentification 40, on retrouve :
- pour chaque utilisateur, un identifiant, un mot de passe et un jeton de sécurité,
- pour chaque entité matérielle, un identifiant, un certificat et un jeton de sécurité.
Dans les données d'autorisation 41 , on retrouve :
- pour chaque entité matérielle et entité logicielle du système, des données liées à leurs droits d'accès vers chaque entité matérielle et vers chaque entité logicielle du système,
Dans les données 42 liées à la politique de sécurité, on retrouve :
- pour chaque utilisateur 1 et entité matérielle 5 du système, un fichier sous un format adapté, par exemple XACML (pour extensible Access Control Markup Language), pour résumer les autorisations associées à chaque utilisateur 1 ou entité matérielle 5 du système ainsi qu'une copie du jeton de sécurité associé.
Pour chaque utilisateur 1 et entité matérielle 5 du système, le jeton de sécurité correspond au fichier XACML décrit ci-dessus, horodaté et signé par le serveur de sécurité 3.
Le serveur de sécurité 3 est destiné notamment à gérer l'authentification de chaque utilisateur 1 et chaque entité matérielle 5 du système. Il comporte ainsi :
- un module 30 de gestion des données d'authentification de chaque utilisateur 1 , stockées dans la base de données de sécurité 4, destiné à vérifier les données d'authentification de chaque utilisateur, un module 31 de gestion des données d'authentification de chaque entité matérielle 5 du système, stockées dans la base de données de sécurité 4, destiné à vérifier le certificat de chaque entité matérielle,
un module 32 de gestion des données liées aux droits d'accès de chaque utilisateur 1 et chaque entité matérielle 5 du système, stockées dans la base de données de sécurité 4,
un module 33 de gestion des jetons de sécurité attribués à chaque utilisateur et chaque entité matérielle du système, notamment pour réaliser la signature et l'horodatage à la génération de chaque jeton de sécurité, une interface administrateur 34 permettant notamment à un administrateur, à l'aide d'un outil logiciel d'administration, d'enregistrer des nouveaux utilisateurs et de nouvelles entités matérielles, de saisir les droits d'accès aux différentes entités matérielles et entités logicielles du système ainsi que la configuration et l'attribution des droits d'accès à chaque utilisateur et chaque entité matérielle.
Chaque entité matérielle 5 comporte un agent logiciel 50 dont la responsabilité est de gérer toutes les opérations de sécurité liées à l'entité matérielle à laquelle il est associé. Pour une entité matérielle 5, un tel agent logiciel 50 comporte :
- un module 500 de vérification de chaque jeton de sécurité reçu en provenance d'un portail de sécurité 10, d'une entité logicielle 6 ou d'une autre entité matérielle 5,
- un module 501 d'analyse des droits d'accès de l'utilisateur 1 , d'une entité logicielle 6 ou d'une autre entité matérielle 5 après décryptage et lecture d'un jeton de sécurité reçu,
- un module 502 de réception de jeton de sécurité agencé pour recevoir et mémoriser chaque jeton reçu et pour signer le jeton de sécurité reçu d'un portail de sécurité 10 ou d'une première entité et pour transférer ce jeton signé vers une deuxième entité à laquelle le portail de sécurité 10 ou la première entité souhaite accéder,
- un module 503 de gestion de clés cryptographiques agencé pour la génération, l'échange, le stockage, l'utilisation et le remplacement de clés cryptographiques, - une ou plusieurs librairies cryptographiques 504 telles que par exemple OpenSSL,
- un module 505 d'authentification agencé pour envoyer l'identité (certificat) de l'entité matérielle vers le serveur de sécurité 3 pour recevoir de sa part un jeton de sécurité.
Chaque entité logicielle 6 comporte également un agent logiciel 60 dont la responsabilité est de gérer toutes les opérations de sécurité liées à l'entité logicielle 6 à laquelle il est associé. Cet agent comporte :
- un module 600 de vérification de chaque jeton de sécurité reçu en provenance d'un portail de sécurité, d'une entité matérielle ou d'une autre entité logicielle,
- un module 601 d'analyse des droits d'accès de l'utilisateur, d'une entité matérielle ou d'une autre entité logicielle après décryptage et lecture d'un jeton de sécurité reçu,
- un module 602 de réception de jeton de sécurité agencé pour recevoir, mémoriser chaque jeton reçu et pour signer le jeton de sécurité reçu d'un portail de sécurtié ou d'une première entité et pour transférer ce jeton signé vers une deuxième entité à laquelle le portail de sécurité ou la première entité souhaite accéder,
- une ou plusieurs librairies cryptographiques 603 telles que par exemple OpenSSL.
Dans chaque entité matérielle 5 ou logicielle 6 du système, le module 501 , 601 d'analyse des droits d'accès analyse l'architecture du fichier XACML qui comporte un point d'application de la décision (PEP pour « Policy Enforcement Point ») et un point de décision de la politique (PDP pour « Policy Décision Point »).
Les figures 8A et 8B montrent l'architecture d'un jeton de sécurité, respectivement lorsque celui-ci est issu du serveur de sécurité et lorsque celui-ci est transmis par un agent logiciel. Sur la figure 8A, le jeton de sécurité transmis par le serveur de sécurité est un fichier qui comporte les données suivantes :
- des données 80 d'horodatage spécifiant la date de création du fichier,
- la duré de validité 81 du jeton de sécurité,
- des données 82 d'identité de l'utilisateur 1 ou de l'entité matérielle 5 associé au jeton de sécurité,
- des données 83 d'identification de l'organisme ayant généré le fichier,
- les données 84 liées aux droits d'accès de l'utilisateur 1 ou de l'entité matérielle 5 concerné,
Ce fichier est signé (signature 85) par le serveur de sécurité 3 à l'aide d'une clé privée afin de générer le jeton de sécurité.
Sur la figure 8B, le jeton de sécurité transmis par un agent logiciel 50, 60 d'une entité matérielle 5 ou d'une entité logicielle 6, consiste dans le jeton de sécurité décrit ci-dessus qui est en plus signé (signature 86) par l'agent logiciel 50, 60 afin de pouvoir être authentifié par le récepteur.
Le système de sécurité peut comporter une autorité de certification 7 destinée notamment à fournir les certificats pour chaque entité matérielle et logicielle du système. L'autorité de certification est en interaction avec le serveur de sécurité pour fournir, sur demande du serveur de sécurité, chaque certificat associé à une entité matérielle et logicielle du système. Les certificats sont stockés dans une base de données gérée par l'autorité de certification. L'autorité de certification 7 dispose également de moyens pour générer de nouveaux certificats et pour vérifier si les certificats de chaque entité matérielle et logicielle sont à jour.
Pour crypter les données échangées, le système de sécurité de l'invention utilise un système classique de cryptage basé sur un mécanisme de clé publique et de clé privée, par exemple TLS/SSL.
La figure 2 illustre le principe d'enregistrement d'un utilisateur 1 et d'une entité matérielle 5 d'un système par un administrateur 2 connecté au serveur de sécurité à travers l'outil logiciel d'administration 20 exécuté sur un poste informatique. Pour toute tâche d'administration, l'administrateur 2 doit d'abord s'identifier (A1 ) auprès du serveur de sécurité 3 via l'outil logiciel d'administration 20. Pour l'ajout d'un utilisateur 1 , la procédure suit les étapes suivantes :
- A2 : l'administrateur 2 envoie au serveur de sécurité 3 une requête d'ajout d'un utilisateur 1 , accompagnée des données d'identification de l'utilisateur 1 ,
A3 : le serveur de sécurité 3 émet une commande d'écriture des données d'identification relatives à l'utilisateur 1 dans la base de données de sécurité 4,
- A4 : La base de données de sécurité 4 confirme au serveur de sécurité 3 l'ajout de l'utilisateur 1 ,
- A5 : Le serveur de sécurité 3 confirme l'ajout de l'utilisateur dans la base de données de sécurité 4.
Pour l'ajout d'une entité matérielle 5, la procédure comporte les étapes suivantes :
B1 : via, l'outil logiciel d'administration 20, l'administrateur 2 envoie au serveur de sécurité 3 une requête d'ajout d'une entité matérielle 5,
B2 : le serveur de sécurité 3 envoie une requête à l'autorité de certification 7 en vue d'obtenir le certificat de l'entité matérielle 5 à enregistrer,
B3 : l'autorité de certification 7 renvoie le certificat requis,
B4 : le serveur de sécurité 3 envoie une commande d'écriture des données d'identification, notamment le certificat obtenu, liées à l'entité matérielle 5 dans la base de données de sécurité 4,
B5 : la base de données de sécurité 4 confirme l'enregistrement de l'entité matérielle,
B6 : le serveur de sécurité confirme l'ajout de l'entité matérielle à l'administrateur.
La figure 3 illustre la procédure d'enrôlement d'une entité matérielle 5 et son authentification : C1 : via l'interface administrateur du serveur de sécurité 3, l'administrateur 1 lance une commande de type « Discover » du serveur de sécurité en vue de déterminer les entités matérielles du système,
C2 : le serveur de sécurité 3 envoie une requête de demande de certificat à l'agent logiciel 50 d'une entité matérielle 5 du système,
C3 : le module d'authentification 505 de l'agent logiciel 50 de l'entité matérielle 5 répond à la requête par l'envoi de son certificat,
C4 : le serveur de sécurité 3 vérifie le certificat de l'entité matérielle 5, si le certificat est valide :
- C5 : l'entité matérielle 5 est authentifiée,
si le certificat n'est pas valide :
- C6 : l'administrateur 2 émet une requête d'ajout de l'entité matérielle 5 à destination du serveur de sécurité 3,
- C7 : le serveur de sécurité 3 envoie une requête d'enrôlement au module d'authentification de l'agent logiciel 50 de l'entité matérielle avec l'adresse de l'autorité de certification 7 en vue d'obtenir un certificat auprès de l'autorité de certification 7,
- C8 : l'agent logiciel 50 de l'entité matérielle 5 émet une requête à destination de l'autorité de certification 7, par exemple sous la forme d'une requête basée sur le protocole SCEP (« Simple Certificate Enrollment Protocol »), en vue d'obtenir un certificat valide,
- C9 : l'autorité de certification 7 génère un certificat pour l'entité matérielle 5 et répond à la requête par envoi du certificat à destination de l'agent logiciel 50 de l'entité matérielle 5,
- C10 : le module d'authentification de l'agent logiciel 50 de l'entité matérielle 5 renvoie le certificat obtenu au serveur de sécurité 3,
- C1 1 : le serveur de sécurité 3 valide l'authentification de l'entité matérielle 5 auprès de l'administrateur 2.
C12 : l'administrateur 2, à partir de l'outil logiciel d'administration 20, saisit les données de configuration de l'entité matérielle 5, notamment les données liées aux droits d'accès de cette entité matérielle, C13 : l'administrateur 2 émet une requête d'enregistrement des données de configuration de l'entité matérielle à destination du serveur de sécurité 3 en vue de la création du fichier XACML pour l'entité matérielle 5,
C14 : l'administrateur émet ensuite une requête à destination du serveur de sécurité pour la génération du jeton de sécurité,
C15 : le serveur de sécurité 3 génère le jeton de sécurité grâce à son module de gestion,
C16 : le serveur de sécurité 3 distribue le jeton de sécurité à destination de l'entité matérielle,
C17 : le module de réception de l'entité matérielle mémorise le jeton reçu.
La figure 4 illustre la procédure d'accès d'un utilisateur à une entité logicielle. Cette procédure comporte les étapes suivantes :
D1 : l'utilisateur 1 lance une entité logicielle 6 du système,
D2 : l'entité logicielle 6 demande à son agent logiciel 60 d'authentifier cet utilisateur 1 et de vérifier ses droits d'accès,
D3 : l'agent logiciel 60, par l'intermédiaire de son module de vérification, vérifie le jeton de sécurité de l'utilisateur 1 ,
- si le jeton de sécurité est valide :
D4 : l'entité logicielle s'exécute.
- si le jeton de sécurité n'est pas valide :
D5 : l'agent logiciel envoie une requête à destination du portail de sécurité en vue d'obtenir le jeton de sécurité actuel associé à l'utilisateur,
D6 : si le portail de sécurité détient un jeton de sécurité pour cet utilisateur :
D7 : le portail de sécurité envoie le jeton de sécurité à destination de l'agent logiciel de l'entité logicielle,
D8 : le module de vérification de l'agent de l'entité logicielle vérifie le jeton de sécurité reçu pour authentification, D8 : le module d'analyse de l'agent logiciel de l'entité logicielle vérifie les droits d'accès de l'utilisateur,
D9 : si l'utilisateur est authentifié et ses droits d'accès validés, l'entité logicielle s'exécute,
le portail de sécurité ne détient pas de jeton :
D10 : le portail de sécurité demande à l'utilisateur de renseigner ses données d'identité (identifiant, mot de passe),
D1 1 : L'utilisateur renseigne ses données d'identité,
D12 : le portail de sécurité émet une requête à destination du serveur de sécurité en vue d'obtenir un jeton de sécurité en émettant les données d'identité de l'utilisateur,
D13 : le serveur de sécurité vérifie les données d'identité reçues auprès de la base de données de sécurité :
D14 : si les données d'identité ne sont pas inscrites dans la base de données de sécurité :
D15 : le serveur de sécurité émet une réponse négative à destination du portail de sécurité,
D16 : la procédure d'authentification a échoué.
D17 : si les données d'identité sont inscrites dans la base de données de sécurité :
D18 : le serveur de sécurité envoie une requête à la base de données de sécurité en vue d'obtenir les données liées aux droits d'accès de l'utilisateur, c'est- à-dire le fichier XACML associé à cet utilisateur,
D19 : La base de données de sécurité 4 renvoie les données liées aux droits d'accès de l'utilisateur sous la forme du fichier XACML,
D20 : sur la base du fichier XACML reçu, le serveur de sécurité génère le jeton de sécurité,
D21 : le serveur de sécurité envoie le jeton de sécurité généré à destination du portail de sécurité, D22 : le portail de sécurité transfère le jeton de sécurité à l'agent logiciel de l'entité logicielle,
D23 : le module de vérification de l'agent de l'entité logicielle vérifie le jeton de sécurité reçu pour authentification de l'utilisateur et vérification de ses droits d'accès,
D24 : si l'utilisateur 1 est authentifié et ses droits d'accès validés, l'entité logicielle 6 s'exécute.
La figure 5 illustre la procédure mise en œuvre pour l'accès d'un utilisateur à une entité matérielle 5 à travers une entité logicielle 6. La procédure comporte les étapes suivantes :
E1 : l'utilisateur 1 émet une requête à destination de l'entité logicielle 6 en vue de réaliser une opération sur une entité matérielle 5,
E2 : l'entité logicielle 6 demande à l'entité matérielle 5 l'établissement d'un canal de communication sécurisé (Par exemple sous le protocole TLS pour Transport Layer Security),
E3 : l'entité matérielle 5 établit un canal de communication sécurisé avec l'entité logicielle 6,
E4 : l'agent logiciel 60 de l'entité logicielle 6 signe le jeton de sécurité de l'utilisateur 1 et l'envoie à destination de l'agent logiciel 50 de l'entité matérielle 5,
E5 : Le module de vérification de l'agent logiciel 50 de l'entité matérielle 5 vérifie le jeton de sécurité reçu.
E6 : si le jeton de sécurité est valide, l'opération peut être réalisée sur l'entité matérielle 5.
- si le jeton de sécurité est invalide :
E7 : l'agent logiciel de l'entité matérielle émet une réponse à l'agent logiciel de l'entité matérielle pour lui signaler la non- validité,
E8 : l'agent logiciel de l'entité logicielle demande une mise à jour du jeton de sécurité au portail de sécurité de l'utilisateur, E9 : le portail de sécurité demande à l'utilisateur de renseigner ses données d'identité (identifiant, mot de passe),
E10 : l'utilisateur renseigne ses données d'identité,
E1 1 : le portail de sécurité émet une requête à destination du serveur de sécurité en vue d'obtenir un jeton de sécurité, accompagnée des données d'identité de l'utilisateur,
E12 : après lecture de la base de données de sécurité 4, le serveur de sécurité 3 envoie le jeton de sécurité généré à destination du portail de sécurité,
E13 : le portail de sécurité transfère le jeton de sécurité à l'agent logiciel de l'entité logicielle qui le transfère à l'agent logiciel de l'entité matérielle,
E14 : le module de vérification de l'agent logiciel de l'entité matérielle vérifie le jeton de sécurité reçu pour authentification, le module d'analyse de l'agent logiciel de l'entité matérielle vérifie les droits d'accès de l'utilisateur,
E6 : si le nouveau jeton de sécurité est valide, l'opération peut être réalisée sur l'entité matérielle.
La figure 6 illustre la procédure mise en place pour permettre à une première entité matérielle 5a d'accéder à une deuxième entité matérielle 5b. Elle comporte les étapes suivantes :
F1 : la première entité matérielle 5a demande à la deuxième entité matérielle 5b l'établissement d'un canal de communication sécurisé (Par exemple sous le protocole TLS pour Transport Layer Security),
F2 : la deuxième entité matérielle 5b établit un canal de communication sécurisé avec la première entité matérielle 5a,
F3 : l'agent logiciel de la deuxième entité matérielle 5b émet une requête à destination de l'agent logiciel de la première entité matérielle 5a en vue d'obtenir son jeton de sécurité, F4 : l'agent logiciel de la première entité matérielle 5a envoie son jeton de sécurité à destination de l'agent logiciel de la deuxième entité matérielle 5b,
F5 : le module de vérification de l'agent logiciel de la deuxième entité matérielle 5b vérifie le jeton de sécurité reçu,
- si le jeton de sécurité est valide :
F6 : l'agent logiciel de la deuxième entité matérielle analyse les droits d'accès de la première entité matérielle,
F7 : si ses droits d'accès sont validés, la première entité matérielle 5a peut émettre des commandes à destination de la deuxième entité matérielle 5b,
F8 : la deuxième entité matérielle 5a autorise l'accès de la première entité matérielle 5a selon ses droits d'accès,
F9 : si le jeton de sécurité est invalide :
F10 : l'agent logiciel de la deuxième entité matérielle demande un nouveau jeton de sécurité à la première entité matérielle,
F1 1 : l'agent logiciel de la première entité matérielle envoie une requête à destination du serveur de sécurité en vue d'obtenir une mise à jour de son jeton de sécurité,
F12 : le serveur de sécurité génère un nouveau jeton de sécurité à partir du fichier XACML, le serveur de sécurité horodatant et signant ledit fichier,
F13 : le serveur de sécurité envoie le nouveau jeton de sécurité à destination de l'agent logiciel de la première entité matérielle 5a,
F14 : l'agent logiciel de la première entité matérielle transfère le jeton de sécurité à destination de l'agent logiciel de la deuxième entité matérielle,
F15 : le module de vérification de l'agent logiciel de la deuxième entité matérielle vérifie le nouveau jeton de sécurité, F6 : si le nouveau jeton de sécurité est valide, l'agent logiciel de la deuxième entité matérielle analyse les droits d'accès de la première entité matérielle,
F7 : si ses droits d'accès sont validés, la première entité matérielle 5a peut émettre des commandes à destination de la deuxième entité matérielle 5b,
F8 : la deuxième entité matérielle 5a autorise l'accès de la première entité matérielle 5a selon ses droits d'accès,
La figure 7 illustre la procédure de mise à jour d'un jeton de sécurité appartenant à une entité matérielle. Un agent logiciel d'une entité matérielle ou logicielle qui a reçu un jeton de sécurité valide peut demander si le jeton de sécurité en sa possession est bien à jour. La procédure de vérification qu'un jeton de sécurité est à jour est réalisée sur des données représentatives d'une signature compressée du jeton de sécurité. Ainsi, seules ces données sont envoyées par une entité vers une autre. Cette procédure comporte les étapes suivantes :
- G1 : l'agent d'une première entité (matérielle sur la figure 7) demande une vérification du jeton de sécurité reçu à l'agent logiciel d'une deuxième entité (logicielle) présente dans la chaîne,
- G2 : si l'agent logiciel de la deuxième entité conclut à une différence, il renvoie une réponse à l'agent de la première entité,
- G3 : l'agent logiciel de la première entité demande à l'agent de la deuxième entité le jeton de sécurité à jour,
- G4 : l'agent logiciel de la deuxième entité envoie une demande au portail de sécurité pour savoir si le jeton de sécurité est à jour,
- G5 : après vérification, si le jeton de sécurité n'est pas à jour, le portail de sécurité envoie une réponse à l'agent logiciel de la deuxième entité indiquant que le jeton de sécurité n'est pas à jour,
- G6 : l'agent logiciel de la deuxième entité demande au portail de sécurité le jeton de sécurité à jour,
- G7 : le portail de sécurité envoie une demande au serveur de sécurité pour savoir si le jeton de sécurité est à jour, G8 : après vérification, si le jeton de sécurité n'est pas à jour, le serveur de sécurité envoie une réponse au portail de sécurité indiquant que le jeton de sécurité n'est pas à jour,
G9 : le portail de sécurité demande à l'utilisateur de saisir ses données d'identité,
G10 : l'utilisateur saisit ses données d'identité,
G1 1 : le portail de sécurité envoie une requête à destination du serveur de sécurité en vue d'obtenir un nouveau jeton de sécurité,
G12 : le serveur de sécurité répond au portail de sécurité par l'envoi d'un nouveau jeton de sécurité à destination du portail de sécurité.
La solution de l'invention présente ainsi de nombreux avantages, parmi lesquels :
Permettre la gestion des données d'identité de chaque utilisateur ou entité matérielle dans le système de contrôle industriel, d'une manière centralisée avec un impact limité sur les architectures des produits existants,
Permettre la gestion des autorisations et des droits d'accès de chaque utilisateur ou entité matérielle vers chaque entité matérielle ou logicielle du système,
- Sécuriser la communication entre les différentes entités du système, par l'échange direct des jetons de sécurité entre ces entités, sans passer par un serveur central, en utilisant notamment des techniques de cryptographie asymétrique,
- Couvrir tous les niveaux d'un système de contrôle industriel,
- Accéder à des ressources multiples à partir d'une authentification unique (« Single Sign On »).
Ainsi, grâce au système de sécurité de l'invention, un utilisateur s'authentifie une seule fois auprès du serveur de sécurité, puis toute authentification de l'utilisateur par les différentes entités revient à authentifier le jeton de sécurité qui lui a été associé. De même, un utilisateur ou une entité matérielle, muni d'un jeton de sécurité, a la capacité de faire des accès sécurisés à une ou plusieurs entités matérielles logicielles du système de manière directe ou indirecte sur plusieurs niveaux.

Claims

REVENDICATIONS
1 . Système de sécurité pour un système de contrôle industriel qui comporte une ou plusieurs entités matérielles et/ou une ou plusieurs entités logicielles accessibles par au moins un utilisateur à travers au moins un portail de sécurité, caractérisé en ce que le système de sécurité comporte :
- une base de données de sécurité (4) agencée pour mémoriser :
- des données d'identité associés à chaque utilisateur (1 ) et entité matérielle (5),
- des données de droits d'accès à chaque entité matérielle (5) ou entité logicielle (6) du système,
- des jetons de sécurité générés pour chaque utilisateur et chaque entité matérielle, chaque jeton de sécurité comprenant les données signées par un serveur de sécurité (3) et relatives à l'identité de l'utilisateur ou de l'entité matérielle et les données de droits d'accès attribués à l'utilisateur ou à l'entité matérielle,
- un serveur de sécurité comprenant :
- un module de vérification dans la base de données de sécurité (4) des données d'identité d'un utilisateur (1 ) ou d'une entité matérielle (5),
- un module de génération de jetons de sécurité pour chaque utilisateur (1 ) ou entité matérielle (5) identifié dans la base de données de sécurité (4),
- un module de gestion des données d'identité de chaque utilisateur (1 ) et entité matérielle (5) stockées dans la base de données de sécurité,
- un module de gestion des données de droits d'accès stockées dans la base de données de sécurité (4),
- Chaque entité matérielle ou entité logicielle comportant un agent logiciel comprenant :
- un module (500) de vérification de chaque jeton de sécurité reçu en provenance d'un portail de sécurité (10), d'une entité logicielle (6) ou d'une autre entité matérielle (5),
- un module (501 ) d'analyse des droits d'accès de l'utilisateur (1 ), d'une autre entité logicielle (6) ou d'une autre entité matérielle (5), - un module (502) de réception de jeton de sécurité agencé pour recevoir et mémoriser chaque jeton reçu et pour signer le jeton de sécurité reçu d'un portail de sécurité (10) ou d'une première entité matérielle (5) et pour transférer ce jeton signé vers une deuxième entité matérielle ou logicielle à laquelle le portail de sécurité (10) ou la première entité matérielle (5) souhaite accéder.
2. Système selon la revendication 1 , caractérisé en ce que chaque agent logiciel (50, 60) comporte un module (503) de gestion de clés cryptographiques agencé pour la génération, l'échange, le stockage, l'utilisation et le remplacement de clés cryptographiques nécessaires pour signer un jeton de sécurité ou pour le décrypter.
3. Système selon la revendication 1 ou 2, caractérisé en ce que chaque agent logiciel (50, 60) comporte une ou plusieurs librairies cryptographiques (504).
4. Système selon l'une des revendications 1 à 3, caractérisé en ce que l'agent logiciel (50) d'une entité matérielle (5) comporte un module (505) d'authentification agencé pour envoyer l'identité de l'entité matérielle vers le serveur de sécurité (3) pour recevoir de sa part un jeton de sécurité.
EP16730712.3A 2015-06-26 2016-06-03 Systeme de securite pour systeme de controle industriel Withdrawn EP3314498A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1555952A FR3038097B1 (fr) 2015-06-26 2015-06-26 Systeme de securite pour systeme de controle industriel
PCT/EP2016/062618 WO2016206947A1 (fr) 2015-06-26 2016-06-03 Systeme de securite pour systeme de controle industriel

Publications (1)

Publication Number Publication Date
EP3314498A1 true EP3314498A1 (fr) 2018-05-02

Family

ID=54783701

Family Applications (1)

Application Number Title Priority Date Filing Date
EP16730712.3A Withdrawn EP3314498A1 (fr) 2015-06-26 2016-06-03 Systeme de securite pour systeme de controle industriel

Country Status (5)

Country Link
US (1) US20180137297A1 (fr)
EP (1) EP3314498A1 (fr)
CN (1) CN107787576A (fr)
FR (1) FR3038097B1 (fr)
WO (1) WO2016206947A1 (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11636220B2 (en) * 2019-02-01 2023-04-25 Intertrust Technologies Corporation Data management systems and methods
US11245699B2 (en) 2019-10-17 2022-02-08 Schweitzer Engineering Laboratories, Inc. Token-based device access restriction systems
CN111880779B (zh) * 2020-07-17 2023-12-26 盛视科技股份有限公司 一种系统应用源代码生成方法及装置
US11552941B2 (en) * 2020-10-30 2023-01-10 Saudi Arabian Oil Company Method and system for managing workstation authentication

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7761910B2 (en) * 1994-12-30 2010-07-20 Power Measurement Ltd. System and method for assigning an identity to an intelligent electronic device
CN101202753B (zh) * 2007-11-29 2010-11-17 中国电信股份有限公司 一种客户端访问插件应用系统的方法和装置
US8271536B2 (en) * 2008-11-14 2012-09-18 Microsoft Corporation Multi-tenancy using suite of authorization manager components
US20120297461A1 (en) * 2010-12-02 2012-11-22 Stephen Pineau System and method for reducing cyber crime in industrial control systems
CN103188248A (zh) * 2011-12-31 2013-07-03 卓望数码技术（深圳）有限公司 基于单点登录的身份认证系统及方法
WO2014042638A1 (fr) * 2012-09-13 2014-03-20 Siemens Aktiengesellschaft Système industriel de commandes à génération interne pour communications de réseau sécurisées
CN103078932B (zh) * 2012-12-31 2016-01-27 中国移动通信集团江苏有限公司 一种实现通用单点登录的方法、装置和系统

Also Published As

Publication number Publication date
CN107787576A (zh) 2018-03-09
FR3038097A1 (fr) 2016-12-30
US20180137297A1 (en) 2018-05-17
FR3038097B1 (fr) 2017-06-23
WO2016206947A1 (fr) 2016-12-29

Similar Documents

Publication Publication Date Title
EP3619888B1 (fr) Inscription de certificat automatisée pour des dispositifs dans des systèmes de commande industriels ou d'autres systèmes
US10484359B2 (en) Device-level authentication with unique device identifiers
EP3675415B1 (fr) Procédé de commande d'utilisation de données et dispositif cryptographique
CN107528692B (zh) 用于向认证机构注册智能电子装置的方法和系统
EP3590223A1 (fr) Procede et dispositif pour memoriser et partager des donnees integres
KR100529550B1 (ko) 공개키 기반 구조 인증시스템에서 생체정보를 이용한인증서 권한 변경 방법
US20200059470A1 (en) Industrial internet encryption system
KR20060096979A (ko) 컴퓨터 그리드에 대한 싱글-사인-온 액세스를 위한 방법 및시스템
JP2008507203A (ja) ディストリビューションｃｄを使用した、署名されたグループにおけるダイレクトプルーフの秘密鍵を装置に伝達する方法
WO2016206947A1 (fr) Systeme de securite pour systeme de controle industriel
CN111082941B (zh) 基于区块链技术的物联网数据共享方法和系统
CN112422287B (zh) 基于密码学的多层级角色权限控制方法和装置
CN112385198B (zh) 用于为第一设备设立授权证明的方法
CN113647080A (zh) 以密码保护的方式提供数字证书
CN109863492A (zh) 在车辆计算机中安装证书的方法及相关计算机和系统
CN112235276B (zh) 主从设备交互方法、装置、系统、电子设备和计算机介质
Das et al. Design of a trust-based authentication scheme for blockchain-enabled iov system
CN111586125A (zh) 一种物联网系统
CN113169953B (zh) 用于验证设备或用户的方法和装置
Falk et al. Using managed certificate whitelisting as a basis for internet of things security in industrial automation applications
JP2024513521A (ja) 組み込みデバイスの安全な信頼の起点登録及び識別管理
KR20200062098A (ko) 블록체인 기반의 통합 로그인 방법, 단말 및 이를 이용한 서버
Meier et al. Secure Provisioning of OPC UA Applications Using the Asset Administration Shell
KR20210063177A (ko) 모바일 인증 장치 및 방법, 그리고 이에 적용되는 기록매체
KR20200057660A (ko) 계정 키 페어 기반 계정 인증 서비스를 운영하는 방법과 시스템 및 이 방법을 기록한 컴퓨터로 읽을 수 있는 기록 매체

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20171109

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20200103

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20200603