Detecting Manipulated Clients in a Control System

Abstract

A client-server architecture for a control system of a technical installation, wherein the client-server architecture includes at least one first device formed as a client and at least one second device that formed as a server assigned to the client, where the client is configured to establish contact with the server, and is configured to execute a code received from the server, communication from the client to the control system exists via the server which is configured to detect whether the code, which the client executes, corresponds to the code that the client received from the server, and where the server, in the event of the code not corresponding, is further configured to interrupt the execution of the code by the client and lock the client out of communication with the control system.

Claims

1.-8. (canceled)

9. A method for checking integrity of a code to be executed by a client for a match with another code stored on a server in a client server architecture of a control system of a technical plant, the client server architecture comprising at least a first device comprising a client, which is configured to communicate with the control system, and at least one second device comprising the server, the method comprising: a) registering the client with the server and downloading the code to be executed by the client from the server; b) generating a secret key, encrypting the secret key aided by a public key of the client and creating a signature for the encrypted secret key aided by a public key of the server via the server; c) transmitting the previously encrypted and signed secret key from the server to the client; d) checking the created signature of the encrypted and signed secret key aided by the public key of the server; e) decrypting the encrypted secret key aided by a private key of the client via the client, if the previously checked signature is valid; f) determining a hash value of the code aided by a hash function via the client; g) encrypting the hash value aided by the secret key and signing the encrypted hash value aided by the private key of the client via the client; h) transmitting the encrypted and signed hash value from the client to the server; i) checking the signature of the encrypted and signed hash value aided by the public key of the client via the server; j) decrypting the encrypted hash value with the aid of the secret key via the server, if the previously checked signature is valid; k) determining an additional hash value of a copy of the code stored on the server and not transmitted to the client via the server; and l) allowing, by the server, the client to communicate with the control system of the technical plant in an event the hash value and the additional hash value match.

10. The method as claimed in claim 9, wherein the client is excluded from communicating with the control system upon failure of the hash value and the additional hash value to match.

11. The method as claimed in claim 10, wherein in an event the client, after exclusion from communicating with the control system, registers again with the server and an integrity check produces a match of the hash values, the server permits the client to communicate again with the control system.

12. The method as claimed in claim 10, wherein in an event the client, after exclusion from communication with the control system, registers again with the server, and the integrity check fails to produce a match with the hash values, the server permanently excludes the client from communicating with the control system and stores the client as a device to be rejected in the control system.

13. A client server architecture for a control system of a technical plant, the client server architecture comprising: at least one first device comprising a client; and at least one second device comprising a server; wherein the client server architecture is configured to: a) register the at least one client with the at least one server and download the code to be executed by the at least one client from the at least one server; b) generate a secret key, encrypt the secret key aided by a public key of the at least one client and create a signature for the encrypted secret key aided by a public key of the server via the at least one at least one server; c) transmit the previously encrypted and signed secret key from the at least one at least one server to the at least one client; d) check the created signature of the encrypted and signed secret key aided by the public key of the at least one at least one server; e) decrypt the encrypted secret key aided by a private key of the at least one client via the at least one client, if the previously checked signature is valid; f) determine a hash value of the code aided by a hash function via the at least one client; g) encrypt the hash value aided by the secret key and sign the encrypted hash value aided by the private key of the at least one client via the at least one client; h) transmit the encrypted and signed hash value from the at least one client to the at least one at least one server; i) check the signature of the encrypted and signed hash value aided by the public key of the at least one client via the at least one at least one server; j) decrypt the encrypted hash value aided by the secret key via the at least one at least one server, if the previously checked signature is valid; k) determine an additional hash value of a copy of the code stored on the at least one at least one server and not transmitted to the at least one client via the at least one server; and l) allow, by the at least one server, the at least one client to communicate with the control system of the technical plant in an event the hash value and the additional hash value match.

14. The client server architecture for a control system of the technical plant as claimed in claim 9, wherein the at least one client is configured to make contact with the at least one server to receive a code from the at least one server and to execute the received code, wherein communication exists between the client and the control system via the at least one server; wherein the at least one server is configured to detect whether the code, which the client executes, matches the code transmitted to the at least one client and stored on the at least one server; and wherein the at least one server is configured to interrupt execution of the code via the at least one client, in an event the code fails to match, and is configured to exclude the at least one client from communicating with the control system.

15. The client-server architecture as claimed in claim 14, wherein in an event the at least one client, after exclusion from communicating with the control system, again makes contact with the at least one server, and on account of execution of a code which fails to match, has been excluded a second time from communicating with the control system, the at least one server is further configured to store the at least one client as a device to be rejected in the control system.

16. The control system of a technical plant including the client server architecture as claimed in claim 13.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0042] The afore-described properties, features and advantages of this invention and the manner in which these are achieved will become clearer and more clearly intelligible in conjunction with the following description of the exemplary embodiment, which is explained in more detail in conjunction with the drawings, in which:

[0043] FIG. 1 is a schematic illustration of a part of an inventive control system 1 of a technical plant formed as a process engineering plant, in accordance with the invention; and

[0044] FIG. 2 is flowchart of the method in accordance with the invention.

DETAILED DESCRIPTION OF THE EXEMPLARY EMBODIMENTS

[0045] FIG. 1 shows a part of an inventive control system 1 of a technical plant formed as a process engineering plant. The control system 1 comprises a first server of an operator control system or a first operator station server 2 and a second operation station server 3. Moreover, the control system 1 comprises an operator station client 4. The first operator station server 2, the second operator station server 3 and the operator station client 4 are interconnected via a terminal bus 5 and are connected to further components of the control system 1 (not shown) such as an engineering system server or a process data archive.

[0046] In the context of operator control and monitoring, a user or operator can have access to the first operator station server 2 and/or the second operator station server 3 via the operator station client 4 via the terminal bus 5. The terminal bus 5 can be formed, for instance, as an industrial Ethernet, without being restricted thereto.

[0047] The operator station client 4 has a component 6 referred to as “local client observer”. The first operator station server 2 has a component 7 referred to as “client observer”. The second operator station server 3 likewise has a component 8 referred to as “client observer”.

[0048] The components “local client observer” 6 and “client observer” 7, 8 have asymmetric (public key) key pairs, where “X” refers to the respective asymmetric private key and “Y” refers to the respective asymmetric public key. For security reasons, the associated private keys should at best be securely stored in a hardware-bound manner (i.e., in what is known as a hardware secure element, e.g., TPM or HSM, integrated in the underlying hardware), or alternatively (with lower security requirements), such as in the Windows key store or in another key store.

[0049] The client 4 registers with the first operator station server 2 and downloads a code to be executed herefrom. The component “client observer” 7 of the first operator station server 6 initiates the code checking method, by generating a secret key (for security reasons, if possible, using pseudo random values), then encrypting these with the public key of the component “local client observer” 6 and signing the result (Enc) with its public key. The component “client observer” 7 then transfers the result to the component “local client observer” 6.

[0050] Here, the decryption and signature functions used are conventional prior art functions. The corresponding functions relating to “Enc” or “Sig” are referred to below as “Dec” or “Ver”. It should be noted that a decryption or signature check function is produced for each encryption or signature function. The symmetrical secret key is regenerated by the component “client observer” 7 for each test cycle.

[0051] The component “local client observer” 6 receives a value, which consists of the value Enc and the associated signature Sig from the component “client observer” 7 of the first operator station server 2. First, by using the public key of the operator station server 2, it checks whether the signature Sig(Enc) is valid: Ver(Sig(Enc)=True?

[0052] In the event that the signature is valid, it decrypts the shared symmetrical secret key by using its private key. It then forms a hash value for the code (hash=h(Code)) received by the first operator station server 2, where a hash function h is used. The client 4 then encrypts the hash value with the shared symmetrical secret key and signs the result with its private key. It then transfers the overall result comprising encryption and signature to the component “client observer” 7 of the first operator station server 2. It is important to note that the transmitted value appears to be random to an outsider or attacker. As already mentioned, the attacker (even if he records a number of values) cannot draw any useful conclusions that could help him when attempting to transfer a correct value to the first operator station server 2 in spite of executing the manipulated code.

[0053] The component “client observer” 7 of the first operator station server 2 receives the encrypted and signed hash value of the code to be executed from the component “local client observer” 6. The component “client observer” 7 first checks whether the signature is valid by using the public key of the client 4. If this is the case, then the component “client observer” 6 decrypts the hash value by using the shared symmetrical secret key. The component “client observer” then checks whether the result of the encryption matches with the hash value 6 formed (and thus correct) with respect to the code stored on the first operator station server 2.

[0054] If yes, then the test method is concluded successfully, i.e., it was confirmed that the code loaded into the client 4 by the first operator station server 2 was not manipulated. On the other hand (if a manipulation was detected), the cycle described below is executed for sanctioning and rehabilitation.

[0055] If the first operator station server 2 detects a manipulation, it immediately interrupts the currently executed command (e.g., change in control value, and/or alarm acknowledgement . . . ). Furthermore, it terminates the current client session, i.e., it excludes the client 4 at least temporarily from communicating with the control system 1. The first operator station server 2 cancels a corresponding event or a corresponding security message, which informs the rest of the control system 1 of a possibly manipulated client 4. Furthermore, in a component 9 (referred to as “user profile service”), a “client blacklist” 10 is extended by the affected client 4. This is initially a remark and not an actual block.

[0056] Further operator station servers 3 are moved into the same knowledge state via a component 11, of the first operator station server 2, referred to as “mirroring”. Irrespective of the operator station server 2, 3 with which the client 4 registers, it is known to the control system 1 that because of a manipulation, it is firstly “rehabilitated”, i.e., is on probation, and not yet entirely excluded from the operator control and monitoring.

[0057] When the client 4 is reconnected with an operator station server 2, 3, the potentially manipulated code in the client 4 is reloaded from the respective operator station server 2, 3. In further tests, an evaluation is now implemented by the respective component “client observer” to determine whether the client 4 is rehabilitated. If this applies, then this can be rejected from the blacklist. If this does not apply, then the client 4 remains blocked accordingly.

[0058] With a component “event manager” 11, 12 integrated in the first or second operator station server 2, 3 (all events detected within the scope of the described cycles are basically archived), a historical or forensic analysis (Audit Trail) can be performed independently hereof, with respect to which clients 4 were potentially manipulated in the past, although they were rehabilitated in the meantime. The events or security messages are accessible via a respective process image 13, 14 of the first or second operator station server 2, 3 of a message sequence display 15 of the client 4.

[0059] On account of the security messages of the runtime environments stored in the process images, all operators of the operator control and monitoring of the process engineering plant have knowledge of problematic clients 4, which represents information that is important for the operation of the plant. By continuously monitoring the code check, the generation of the corresponding events (if a manipulation was detected) and by initiating the immediate reaction thereto (in the form of a sanctioning), this will contribute to the conformity with the corresponding International Electrotechnical Commission (IEC) 62443 requirements as the leading Industrial Security Standards regarding the continuous security monitoring “continuous monitoring” and the timely response to reported events and alarms (“timely response to events”).

[0060] The availability and integrity represent the most important requirements of the IEC 62443. As a result, the disclosed embodiments of the invention generally contributes to the conformity with IEC 62443 and with the requirements based thereupon within the scope of the corresponding (increasingly obligatory) certifications and audits.

[0061] FIG. 2 is a flowchart of the method for checking integrity of a code to be executed by a client 4 for a match with another code stored on a server 2, 3 in a client server architecture of a control system (1) of a technical plant, where the client server architecture comprises at least a first device comprising a client (4), which is configured to communicate with the control system (1), and at least one second device comprising the server 2, 3.

[0062] The method comprises a) registering the client 4 with the server 2, 3 and downloading the code to be executed by the client 4 from the server 2, 3, as indicated in step 210. Next, b) a secret key is generated and encrypted aided by a public key of the client 4 and a signature for the encrypted secret key is created aided by a public key of the server via the server 2, 2, as indicated in step 215.

[0063] Next, c) the previously encrypted and signed secret key is transmitted from the server 2, 3 to the client 4, as indicated in step 220. Next, d) the created signature of the encrypted and signed secret key is checked aided by the public key of the server 2, 3, as indicated in step 225. Next, e) the encrypted secret key aided is decrypted by a private key of the client 4 via the client 4, if the previously checked signature is valid, as indicted in step 230.

[0064] A hash value of the code aided by a hash function via the client 4 is now determined, as indicated in step 235. Next, g) the hash value is encrypted aided by the secret key and the encrypted hash value signed aided by the private key of the client 4 via the client 4, a indicated in step 240.

[0065] Next, h) the encrypted and signed hash value is transmitted from the client 4 to the server 2, 3, as indicated in step 245. Next, i) the signature of the encrypted and signed hash value is checked aided by the public key of the client 4 via the server 2, 3, as indicated in step 250. Next, j) the encrypted hash value is decrypted with the aid of the secret key via the server 2, 3, if the previously checked signature is valid, as indicated in step 255.

[0066] Next, k) an additional hash value of a copy of the code stored on the server 2, 3 and not transmitted to the client 4 via the server 2, 3 is determined, as indicated in step 260. Next, l) the server 2, 3 allows the client 4 to communicate with the control system of the technical plant in an event the hash value and the additional hash value match, as indicated in step 265.

[0067] Although the invention was illustrated and described more closely in detail by the preferred exemplary embodiment, the invention is not restricted by the disclosed examples and other variations can be derived herefrom by the person skilled in the art without departing from the scope of the invention.

[0068] Thus, while there have been shown, described and pointed out fundamental novel features of the invention as applied to a preferred embodiment thereof, it will be understood that various omissions and substitutions and changes in the form and details of the methods described and the devices illustrated, and in their operation, may be made by those skilled in the art without departing from the spirit of the invention. For example, it is expressly intended that all combinations of those elements and/or method steps which perform substantially the same function in substantially the same way to achieve the same results are within the scope of the invention. Moreover, it should be recognized that structures and/or elements and/or method steps shown and/or described in connection with any disclosed form or embodiment of the invention may be incorporated in any other disclosed or described or suggested form or embodiment as a general matter of design choice. It is the intention, therefore, to be limited only as indicated by the scope of the claims appended hereto.