Method for operating an industrial control system

Abstract

A method for operating an industrial control system, wherein the industrial control system is, for example, an energy generation and transmission system and / or a manufacturing system, wherein each level of the control system is a security level, and each level forms a separate, closed security class, each security class having its own trust anchor for the corresponding level of the control system, such that the overall integrity of the system is not compromised in the event that a single or multiple levels of functionality are identified by an inspection agency, such as firmware, as impaired, because in this case only the impaired functionality and the trust anchor explicitly assigned to the functionality, in particular the level, are identified and / or severed.

Description

Technical Field

[0001] The present invention relates to a method for operating an industrial control system, wherein the industrial control system is, for example, an energy generation and transmission system and / or a manufacturing system. Background Technology

[0002] According to existing technologies, the implementation of multiple security layers / application scenarios is attributed to a trusted institution. These multiple security layers / application scenarios include, for example, secure loading of firmware during system startup (Secure Boot) and secure storage of device secrets or, in connection with, device identity (Secure Storage).

[0003] The integrity of a system—such as sandboxing, secure boot, secure communication, secure storage, and device identity—depends on the integrity of a single source of trust, the anchor of trust (“root of trust”).

[0004] If the integrity of the source of trust is compromised, it will have an impact on all levels / scenarios. An example of such a breach is reading / manipulating an AES key that is used for signing / encryption.

[0005] In the prior art, security vulnerabilities in a single security level or security feature can compromise the overall integrity of a system because multiple, often, or even all, security features are interconnected. This should be avoided in this application. Summary of the Invention

[0006] Therefore, the object of the present invention is to provide an industrial control system, such as an energy generation and transmission system and / or a manufacturing system, which, in the event of a security vulnerability in the control system, partially and preferably completely maintains the overall integrity of the system.

[0007] By employing separate, enclosed security layers for each individual use case (secure boot, secure storage, etc.), this risk is at least minimized, and preferably even completely eliminated. Thus, for the first time, partial device integrity is guaranteed in the event of partial integrity failure.

[0008] By widely employing various mechanisms to improve overall device integrity, the existence of security vulnerabilities and their exploitation only invalidates the corresponding security features / scenarios. Other security features / scenarios remain unaffected and retain their own integrity. Therefore, device integrity is always guaranteed.

[0009] Therefore, the method described herein is based in particular on providing at least one first hierarchical level and at least one second hierarchical level, wherein these hierarchical levels are in exchange with each other, especially in an exchange in a data technology manner, such that each individual hierarchical level is assigned at least one specific function for controlling and / or regulating the control system.

[0010] The “hierarchical structure of the control system” can be understood in particular as the layout of the computer architecture’s memory from the perspective of the main processor, where the hierarchy can be ordered by the size of the access speed, the reduction of cost and / or the increase of storage capacity and / or the increase of access units.

[0011] In the context of this invention, the term "hierarchy" can also be understood as at least one security module. A "security module" can be understood as a security certificate (however, this is not mandatory). These security modules can be arranged at a level (a hierarchy) or within a sorting hierarchy (i.e., a common hierarchical level). In other words, these security modules are not thus constructed in a hierarchical manner. In at least one embodiment, these security modules correspond to a security scenario constructed in parallel.

[0012] The memory hierarchy can be processor registers, processor cache, working memory, distributed memory, mass storage, and / or removable data carriers.

[0013] Different memory levels in the database of a control system can also be referred to as main memory, secondary memory, or tertiary memory, depending on their speed.

[0014] Each level is described or can be described by or within at least one electronic device of the control system, wherein each of these levels is a security level.

[0015] "Security level" is a level of security that is defined by conditions relating to the design (Konstruktion) of security mechanisms from the perspective of software technology and / or structural tactiles (through the design and implementation of microchips).

[0016] In at least one implementation, each hierarchical level forms a separate, closed security level, each security level having its own trust anchor for the corresponding hierarchical level of the control system.

[0017] Trust anchors can be, for example, certificates from the source certificate authority, or certificates generated through such an authority, such that the authority represents the trust anchors of the corresponding infrastructure at the corresponding level or hierarchy as source or root certificates.

[0018] This ensures, in particular, that the overall integrity of the system remains unaffected in the event that a single or multiple layers of functionality are identified as impaired by an inspection agency, such as the firmware, because in this case only the impaired function and the trust anchors explicitly assigned to that function, especially the layers, are identified and / or severed.

[0019] If the data may have been manipulated and if the owner (e.g., the administrator) of the system described herein no longer has oversight of how it is functioning correctly or the correct content, or if the attacker has achieved other objectives of manipulation, then the system described herein, and in particular its database and / or the various levels of the system described herein (and possibly even the various data groups related to the system), are considered compromised.

[0020] In other words, it is possible, through the invention mentioned above, that even if an unacceptable change, i.e. damage, is determined along the safety rope from an anchor element that is no longer trustworthy, the system can continue to operate, for example, without interference or in an emergency mode.

[0021] A “separat” closed security layer is especially a layer level that triggers a security mechanism, for example, upon determining that a breach has been made, but which has virtually no effect on the second, third, or fourth security layer, preferably none at all.

[0022] Therefore, the remaining undamaged safety layers can, as presented above, maintain the overall system's functionality independently or collectively. In other words, the overall system, i.e., the control system, continues to operate with substantially unchanged operating values ​​and / or with correspondingly adapted operating values. Thus, adjustments to the overall operation of the control system based on safety impairments determined within a single or multiple layers do not necessarily result in overall damage to the control system's entire control and hierarchical system.

[0023] According to at least one embodiment, a method for operating an industrial control system, such as an energy generation and transmission system and / or a manufacturing system, includes at least the steps of providing at least one hierarchical level and at least one second hierarchical level, wherein the two hierarchical levels are in exchange with each other in a data-technical manner, such that each individual hierarchical level is assigned at least one specific function for controlling and / or regulating the control system, and further wherein each hierarchical level is depicted by or within at least one electronic device of the control system, and further wherein each of these hierarchical levels is a security hierarchical level. However, it should be mentioned here that, in addition to this, it is also possible for hierarchical levels to exist that are different from security hierarchical levels and therefore have no trust anchor.

[0024] Each layer forms a separate, closed security level, each with its own trust anchor for the corresponding layer of the control system. This ensures that the overall integrity of the system remains unaffected even if an inspection agency, such as firmware, identifies a single or multiple layers as functionally compromised, because in this case only the compromised function and the trust anchor explicitly assigned to that function, particularly the layer, are identified and / or severed. Furthermore, in this application, "layer" and "layer level" are used synonymously.

[0025] According to at least one implementation, at least one security level is assigned to at least one, preferably each usage process, especially secure boot and / or secure storage, etc.

[0026] It is conceivable that the corresponding usage process takes place within one security level, preferably a single security level, or across two, three, or more security levels throughout the entire usage period.

[0027] According to at least one implementation, when a security vulnerability is identified, i.e., when a functional impairment is determined, the remaining functionalities based on trust anchors different from the impaired functionalities remain unaffected in terms of their own functionality and trustworthiness. This represents an implementation of a separate, closed security level.

[0028] Therefore, in the event of impairment, the remaining hierarchical levels or parts thereof remain unrestricted in terms of their own credibility, such that the system functionality generated by these trust anchors and / or the trust anchors associated with the corresponding hierarchical levels is at least partially, but preferably completely, preserved based on these trust anchors, which are still trusted without restriction.

[0029] According to at least one implementation, at least one trust anchor is assigned to each function of the control system, or a part of the control system, or a hierarchical level of the control system; however, preferably exactly one trust anchor is assigned.

[0030] According to at least one implementation, at least one function is defined across at least two different hierarchical levels, however, based on a trust anchor, preferably based on exactly one trust anchor.

[0031] In the context of this invention, "function" can refer to a function, such as storing data or using data to perform the operation of an industrial control system.

[0032] Alternatively or additionally, functions can be based on two or more trust anchors. It is conceivable to assign m trust anchors to n functions. The placeholders n and m are positive integers greater than zero.

[0033] According to at least one implementation, the function is secure startup, secure communication, secure storage and / or identification of the device in the control system, or a portion thereof.

[0034] According to at least one implementation, a root of trust or chain of trust within the control system is formed using at least one of the following functions: eFuses, a physicallyuncloneable function (PUF), a trusted platform module (TPM), and / or package assertions (operating system mechanisms). It is conceivable that the trust anchor, also known as the "root," is constructed from the chain of trust. Based on this, specific security features can be expressed.

[0035] Each security use case, such as each trusted path, can be implemented using its own root of trust, and different technologies are suitable for this. Example: 1. eFuses: One-time programmable for secure boot using public key authorization. 2. Physically Unclonable Function (PUF): One-to-one device identity 3. Trusted Platform Module (TPM): Secure Storage, Secure Communications, Device Identity 4. Package Assertions (Ubuntu Core operating system mechanism): Packages are signed on the server side. This mechanism implements (umsetzen) trusted sandboxed applications. Packages are signed outside of automated systems, for example, during development. When a device boots the package, the automated system checks the signature.

[0036] Therefore, a secure path includes not only trust anchors, but also the programs and data packets and / or hierarchical levels and / or all other functions used to implement functions along that path, so that compromise also undermines the trust foundation in the corresponding existing trust anchors. In other words, the trust anchor (root of trust) is directly connected to the compromised data and / or loaded packets along the secure path (chain of trust).

[0037] According to at least one implementation, after a functional impairment is determined, at least one new chain of trust is formed based on an existing security anchor by means of at least one of the following functions: E-Fuses, Physically Unclonable Function (PUF), Trusted Platform Module (TPM), and / or Packet Assertion (operating system mechanism).

[0038] In other words, the alternative implementation proposed here suggests that the compromised function takes a symbolic and data-technically conceived detour around the compromised area, such as a compromised data packet, so that the trust anchor can be assigned to new data packets along a secure path.

[0039] According to at least one embodiment, an industrial control system is a control device used in the manufacture of robots, machine tools, and / or vehicles.

[0040] The present invention also relates to an industrial control system, such as an energy generation and transmission system and / or a manufacturing system.

[0041] In particular, all features disclosed for the methods described herein are also disclosed for the control systems described herein, and vice versa.

[0042] Here, the industrial control system includes at least one hardware component that describes and / or defines at least one, preferably at least two, hierarchical levels, or the hardware component is at least a portion of said hierarchical levels, wherein each of these hierarchical levels is a security hierarchical level.

[0043] In particular, this industrial control system is characterized by each level forming a separate, closed security level, wherein each security level has its own trust anchor for the corresponding level of the control system. This ensures that the overall integrity of the system remains unaffected even if a single or multiple levels of functionality are identified by an inspection mechanism, such as firmware, because in this case only the compromised function and the trust anchor explicitly assigned to that function, especially the level, are identifiable and / or detachable. The control system described herein includes the same design scheme and optional features as the method described above, such that the control system described herein is specifically designed and configured to at least perform the method according to claim 1. Attached Figure Description

[0044] The invention described herein is further described below with reference to the accompanying drawings and embodiments.

[0045] Appendix Figures 1A to 1D Different implementations of the methods for operating industrial control systems described herein are shown, wherein hardware security chains (chains of trust) for possible trust scenarios are illustrated, wherein the chains consist of attached... Figures 1A to 1D The various trust scenarios shown can also be combined with each other.

[0046] In these figures, even if some components may be shown oversized, the same or equivalent components are given the same reference numerals. Detailed Implementation

[0047] exist Figure 1AThe diagram illustrates a first trust scenario, "Secure boot" (a trust scenario can be a hierarchical level or part of such a hierarchical level), which begins with a root trust technology, such as "eFuses," followed by public authorization, then initialization of the "First Stage Boot Loader," and then initialization of the "Second Stage Boot Loader," thus establishing it as a "Trusted Operating System."

[0048] In other words, Figure 1A The corresponding security path is shown, which begins with block 1A1 (eFuses) and is followed by blocks 1A2 (“public license”), 1A3 (“first-stage bootloader”), 1A4 (“second-stage bootloader”), and finally block 1A5 (“trusted operating system”).

[0049] exist Figure 1B The diagram illustrates a trust scenario called "Secure Storage," which begins in Block 1B1 (TPM) and then proceeds to store the first route key and / or boot key as per Block 1B2. Next, either Block 1B3 (Storage Container) and secure storage (Block 1B4) are executed, or private key handling (Block 1B5) is performed immediately following Block 1B2, and secure communication, "Secure Information Communication" (Block 1B6), is achieved through this key handling.

[0050] In the trust scenario "Identity", PUF is performed in block 1C1, then a key is generated or a key is derived from PUF (see block 1C2), and then the device identifier, i.e. the device identity, is determined in block 1C3.

[0051] exist Figure 1D The diagram illustrates a Generic Trust Szenario, where a security anchor is first defined in the hardware within Block 1D1 (Generic Trust Root Hardware). Next, a trust chain, specifically a generic form of trust chain, is generated based on Block 1D2, and then a new security feature is generated in Block 1D3.

[0052] Therefore, as shown above, different root trust hardware for each trust scenario can be arbitrarily combined. For example, device identity can be implemented not only using TPM but also using PUF.

[0053] In short, each security use case can be implemented using its own root of trust, and different technologies are suitable for this. Example: 1. eFuses: One-time programmable for secure boot using public key authorization. 2. Physically Unclonable Function (PUF): One-to-one device identity 3. Trusted Platform Module (TPM): Secure Storage, Secure Communications, Device Identity 4. Package Assertions (Ubuntu Core operating system mechanism): Packages are signed on the server side.

[0054] This mechanism enables trustworthy sandboxed applications. The software package is signed outside the automated system, for example, during development. When the device boots the package, the automated system checks this signature.

[0055] The present invention is not limited to the description based on the embodiments. Rather, the present invention includes every new feature and every combination of features, especially every combination of features included in the patent claims, even if the feature or combination itself is not explicitly described in the patent claims or embodiments.

[0056] The applicant reserves the right to claim protection for all features disclosed in the application documents as essential to the invention, provided that such features, individually or in combination, are novel with respect to the prior art. It is also noted that features described in the various figures can be advantageous in themselves. Those skilled in the art will readily recognize that specific features described in the figures can be advantageous even without employing other features in those figures. Those skilled in the art will also recognize that advantages can also be derived from combinations of multiple features shown in individual figures or in different figures.

Claims

1. A method for operating an industrial control system (1), the method comprising the following steps: At least one first level (11) and at least one second level (12) are provided, wherein the two levels (11, 12) are in exchange with each other in a data-technical manner, such that each individual level (11, 12) is assigned at least one specific function for controlling and / or regulating the control system, and further wherein Each of the aforementioned hierarchical levels (11, 12) is depicted by or within at least one electronic device of the control system (1), and further, wherein Each of the aforementioned hierarchical levels (11, 12) is a security level. Its features are, Each level (11, 12) corresponds to one of the constructed security scenarios and forms a separate, closed security level, each security level having its own trust anchor for the corresponding level (11, 12) of the control system (1), such that the overall integrity of the system is not compromised in the event that the function of a single or multiple levels is identified as impaired by the inspection agency, because in this case only the impaired function and the trust anchor explicitly assigned to the function are identified and / or severed.

2. The method according to claim 1, Its features are, Assign at least one security level (11, 12) to each process.

3. The method according to claim 1 or 2, Its features are, In the event that a security vulnerability is identified, i.e., a functional impairment is determined, the remaining functionalities based on trust anchors different from the impaired functionalities remain undamaged in terms of their own functionality and trustworthiness.

4. The method according to claim 1 or 2, Its features are, Each function is assigned to at least one trust anchor.

5. The method according to claim 1 or 2, Its features are, At least one function is defined across at least two different hierarchical levels (11, 12), yet based on trust anchors.

6. The method according to claim 1 or 2, Its features are, The functions are secure startup, secure communication, secure storage, and / or identification of the device or part thereof of the control system (1).

7. The method according to claim 6, Its features are, At least one root of trust or chain of trust is formed within the control system by means of at least one of the following functions: eFuses, Physically Unclonable Function (PUF), Trusted Platform Module (TPM), and / or Package Assertion.

8. The method according to claim 1 or 2, Its features are, After identifying a compromised function, at least one new chain of trust is formed based on an existing security anchor by means of at least one of the following functions: eFuses, Physically Unclonable Function (PUF), Trusted Platform Module (TPM), and / or Package Assertion.

9. The method according to claim 1 or 2, Its features are, The industrial control system (1) is a control device used in the manufacture of robots, machine tools and / or vehicles.

10. The method of claim 1, wherein, The industrial control system (1) is an energy generation and transmission system and / or a manufacturing system.

11. The method of claim 1, wherein, Each level (11, 12) corresponds to one of the constructed security scenarios and forms a separate, closed security level, each security level having its own trust anchor for the corresponding level (11, 12) of the control system (1), such that the overall integrity of the system is not compromised in the event that the firmware identifies a single or multiple levels of functionality as impaired, because in this case only the impaired functionality and the level to which the functionality is explicitly assigned are identified and / or disconnected.

12. The method of claim 2, wherein, Assign at least one security level (11, 12) to secure boot and / or secure storage.

13. The method of claim 4, wherein, Each function is assigned to exactly one trust anchor.

14. The method of claim 5, wherein, At least one function is defined across at least two different hierarchical levels (11, 12), yet based on exactly one trust anchor.

15. An industrial control system (1), the industrial control system comprising: At least one hardware component (3), said at least one hardware component describes and / or defines at least one hierarchical level (11, 12), wherein Each of the hierarchical levels (11, 12) is a security level. Its features are, Each level (11, 12) corresponds to one of the constructed security scenarios and forms a separate, closed security level, each security level having its own trust anchor for the corresponding level (11, 12) of the control system (1), such that the overall integrity of the system is not compromised in the event that the function of a single or multiple levels is identified as impaired by an inspection agency, because in this case only the impaired function and the trust anchor explicitly assigned to the function are identifiable and / or detachable.

16. The industrial control system (1) according to claim 15, characterized by The industrial control system is an energy generation and transmission system and / or a manufacturing system.

17. The industrial control system (1) according to claim 15, characterized by The at least one hardware component describes and / or defines at least two hierarchical levels (11, 12).

18. The industrial control system (1) according to claim 15, characterized by Each level (11, 12) corresponds to one of the constructed security scenarios and forms a separate, closed security level, each security level having its own trust anchor for the corresponding level (11, 12) of the control system (1), such that the overall integrity of the system is not compromised in the event that the firmware identifies a single or multiple levels of functionality as impaired, because in this case only the impaired functionality and the level to which the functionality is explicitly assigned are identifiable and / or disconnectable.

Images