Enrollment of a device in a secure network

Abstract

A method for enrolling a device in a secure network to which an information system is connected, the method comprising the steps, implemented by a trusted device connected to the secure network, of: a) receiving from a user terminal, distinct from the device to be enrolled, an authorization to connect to the device to be enrolled, b) generating cryptographic keys intended for the device to be enrolled to access the secure network, and c) transmitting the cryptographic keys to the device to be enrolled.

Claims

1. A method for enrolling a first device in a secure network to which an information system is connected, the method comprising the steps, implemented by a trusted device connected to the secure network, of: a) receiving from a user terminal, distinct from the first device, an authorization to connect to the first device, said authorization notifying the trusted device that the first device is authorized to connect to the secure network, wherein the connection authorization issued in step a) is conditional on the user of the terminal supplying a hardware cryptographic token and validating the hardware cryptographic token, b) upon receiving the authorization to connect to the first device, generating cryptographic keys intended for the first device to access the secure network, and c) enrolling the first device in the secure network by transmitting the cryptographic keys to the first device, in order for the first device be able to communicate via the secure network without requiring the user terminal to further communicate with the trusted device, such cryptographic keys securing said communication of the first device with at least the trusted device.

2. The method of claim 1, comprising: after generation of the cryptographic keys, requesting a certification of said keys with the information system, and upon obtaining this certification, sending the cryptographic keys and an associated certificate to the first device.

3. The method of claim 2, wherein the request for certification of the keys is carried out according to at least one among the Certificate Management Protocol (CMP), the Simple Certificate Enrollment Protocol (SCEP), and the Cryptography Message Syntax (CMS) protocols.

4. The method of claim 1, wherein validating the hardware cryptographic token includes validating a personal identification code, entered by the user on a human-machine interface of the terminal.

5. The method of claim 4, wherein an invitation to enter the personal identification code is triggered on the terminal by collaboration of the terminal with the hardware cryptographic token.

6. The method of claim 5, wherein the hardware cryptographic token is a USB key with a processor, comprising a male connection member arranged to interconnect with a counterpart female connection member comprised in the user terminal, the interconnection of the members causing execution of a routine on the user terminal asking the user to enter his or her personal identification code.

7. A hardware cryptographic token comprising a processing circuit for implementing the method according to claim 5.

8. The method of claim 1, wherein the trusted device is a highly secure access control device of the network.

9. A user terminal comprising a processing circuit for implementing the method of claim 1.

10. A non-transitory computer-readable medium comprising a computer program stored thereon and including instructions for implementing the method of claim 1 when the instructions are executed by a processor.

11. A trusted device comprising a processing circuit for implementing the method of claim 1.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) Other features and advantages will be apparent from reading the exemplary embodiments presented in the detailed description below, and from examining the appended drawings in which:

(2) FIG. 1 schematically illustrates a system, in an exemplary embodiment,

(3) FIG. 2 illustrates the exchanges between the different entities of this system, in an exemplary embodiment,

(4) FIG. 3 illustrates the main steps implemented by a trusted device HSACD, in an exemplary embodiment,

(5) FIG. 4 schematically illustrates the structure of such a trusted device HSACD, in an exemplary embodiment,

(6) FIG. 5 schematically illustrates the structure of a cryptographic token J and that of a terminal TU available to a field agent AT and able to collaborate with the token J, in an exemplary embodiment.

DETAILED DESCRIPTION

(7) Thus, the method of the disclosure proposes applying a protocol enabling the integration of an IED into the trust domain of the Company by relying on the secure device HSACD.

(8) Advantageously, this solution allows: having the keys subsequently used by the IED to be generated by the HSACD, when the IED is unable to do so, physically checking the integrity of the IED and the link between the HSACD and the IED before enrollment, which increases the trust level in the link between the HSACD and the IED.

(9) In the embodiment presented below, this solution proposes implementing a system with four entities, as illustrated in FIG. 1: the IED itself, which initially is not in the trust domain of the Company and therefore cannot communicate with the HSACD or the IS of the Company; the HSACD, a device present in the trust domain of the Company, connected to the IED by an IP network; a field agent AT, who configures the HSACD and the IED and who ensures their proper “business-related” operation; a cryptographic token J of the agent, which allows the agent to prove that he or she is part of the trust domain of the Enterprise DE, this cryptographic token J working for example by the entry of a simple PIN (“personal identification number”) known only to the agent AT.

(10) With reference to FIG. 2, in one exemplary embodiment the protocol may proceed as follows.

(11) In step S21, the agent AT verifies the physical compliance of the HSACD-IED connection and of the IED itself.

(12) In step S22, the agent AT connects to the HSACD using his or her cryptographic token J and the associated PIN. For example, the agent AT may have at access to a user terminal (TU) such as a computer, connected (typically via the IP network) to the HSACD device and equipped with a female socket capable of accommodating a USB key. The cryptographic token J may then be in the form of a USB key or “dongle”, equipped with a processor capable of executing a predefined routine when the token connects to the terminal TU of the agent AT. In particular, this routine consists of: asking the agent AT to enter a PIN code via a human-machine interface of the TU, and if the PIN code entered is correct (by comparison with a specific PIN code reference stored in the dongle's memory), connecting the TU to the IP network in order to notify the HSACD router that an authorized IED device (since the entered PIN code is valid) wants to connect to the protected network of the IS (possibly with an IP address which the agent AT may optionally provide).

(13) Thus, at the end of this step S22 and due to the action of the cryptographic token, the HSACD agrees to go into “enrollment of an TED” mode in step S23. In the next step S24, the HSACD generates the encryption/decryption keys for the IED to access the secure network of the IS, and thus to communicate with the IS.

(14) Prior to the communication of these keys to the TED, the HSACD has these keys certified by the IS, via a conventional protocol that is known per se, in step S25.

(15) An example of a possible protocol for the implementation of step S25 may be CMS (for “Cryptography Message Syntax”), or CMP (for “Certificate Management Protocol”), or even SCEP (for “Simple Certificate Enrollment Protocol”), of the IEFT (“Internet Engineering Task Force”), or others.

(16) Finally, in step S26, the HSACD transmits the keys thus certified to the IED, in other words the cryptographic keys and the associated certificate, thus allowing its secure connection to the protected network of the IS. This communication in step S26 may be carried out via a conventional interface (webservice type), possibly standardized (as defined in the IEC-61850 standard for example).

(17) The steps implemented by the highly secure access control device HSACD are summarized in FIG. 3. For example, at the end of a first step S1, if the HSACD receives a request to enroll a new device IED, communicated by the cryptographic token J, via the terminal TU of the agent AT, the HSACD executes an enrollment computer routine in step S2. This computer routine begins, in step S3, with the generation of cryptographic keys K. In step S4, these keys are certified with the information system SI. Then, in step S5, the secure gateway HSACD sends these certified keys to the IED (and more generally the cryptographic components MAT necessary for the IED to connect to the secure network). Once these have been sent to the IED, the HSACD can end the enrollment procedure in step S6.

(18) Now with reference to FIG. 4, the HSACD device comprises for example a communication interface COM for communicating via the IP network, connected to a processor PROC for executing all or part of the instructions of the computer program according to an embodiment, these instructions being for example stored in a memory MEM with which the processor PROC can collaborate. These instructions typically make it possible to execute the enrollment protocol described above with reference to FIG. 3.

(19) With reference to FIG. 5, the cryptographic token J may be in the form of a USB dongle, comprising an interface INT1 connected to a male connection member ORG and to a processor PROC2, this processor being capable of executing part of the instructions of the computer program according to an embodiment. This part of the instructions may be stored for example in a memory MEM2 with which processor PROC2 can collaborate. These are typically instructions launching the human-machine interface on the user terminal TU in order to enter the user's PIN code, verify this code against the reference stored in the memory MEM2 of the token J, and send to the login terminal TU the command to connect to the HSACD in order to execute the IED enrollment procedure.

(20) The user's terminal TU (here, a terminal available to a field agent AT) itself may comprise an interface INT2 connected to: a female connection member arranged to receive the member ORG of the cryptographic token J, and a processor PROC3 comprised in the terminal TU, and capable of executing part of the instructions of the computer program according to an embodiment.

(21) This part of the instructions may be stored for example in a memory MEM3 with which processor PROC3 can collaborate. These are typically instructions allowing the terminal TU to collaborate with the token J for the launching of the human-machine interface and the entry of the PIN code, then to connect to the HSACD in order to execute the IED enrollment procedure.

(22) One will note, however, that in a possible alternative to the one illustrated in FIG. 5, the terminal TU may store in memory MEM3 a computer security module in the form of an application for example which, when executed, requests via a human-machine interface the entry of a PIN code, and if the code is valid, contacts the HSACD to initiate the IED enrollment protocol. In addition, as an alternative to entering a PIN code, it may be provided to enter a biometric print (fingerprint or iris) of the user, which is compared to a reference previously stored on the user terminal TU. Of course, yet other embodiments may alternatively also be provided. For example, the token J may be in the form of a near-field contactless chip card which can be read by the terminal TU.

(23) The disclosed embodiments offer numerous advantages over immediate solutions for the enrollment of an IED, for example by using the known protocols CMP, SCEP, or CMS, used in the field of tertiary sector computing. For the initial establishment of trust, these protocols can use several mechanisms: a certificate already established in the IED; or unique identifier and password for the IED, allowing it to authenticate itself with the IS.

(24) In the case of the pre-established certificate, the IED is already considered to be enrolled in the target trust domain, which assumes: that the supplier of the IED has elements enabling dialog with the target trust domain, which increases the risk of attack; or that the IED undergoes a preparatory step between its reception and its installation in the field, which is costly.

(25) The case of the unique identifier and password for the IED poses similar problems: the identifier and password are integrated at the factory by the IED supplier; or else the identifier and password are entered by the agent installing the IED in the field, but in this solution it is necessary to generate these passwords in a secure manner, transmit them to the agent, etc. Such management is complex and this solution is slow (the field agent finds out the password, copies it without any typing errors, etc.).

(26) The presented solution does without these two mechanisms due to the HSACD, a highly secure device which is already able to communicate with the trust domain, and makes it possible to minimize the impact on the supplier and on the field agent performing the installation of the IED.