Method, computer program product and field device for authorizing access to objects in a computerized system

Abstract

A method for authorizing an entity (9) in a computerized system to access an object (12) includes the following steps: providing (S1) an access control list (ACL) that specifies access permissions for each object (12) to the object (12) in the computerized system; assigning (S2) capability requirement information to at least one of the objects in the access control list (ACL); assigning the capability information to at least one entity (9) in the computerized system; requesting (S11) access to the object (12) by the entity (9); checking whether the requesting entity (9) has access permissions according to the ACL; and authorizing (S5) access to the requested object (12) by the requesting entity (9) only if the capability information assigned to the requesting entity (9) matches the capability requirement information assigned to the requested object (12). The combination of ACL-based access to files and capabilities enhances the security of the system.

Description

[0001] This disclosure relates to a method for authorizing access to objects (such as files or processes) in a computerized system (e.g., an automated system). This disclosure further relates to field devices in an automated system.

[0002] Authorizing access to objects in computerized systems (such as industrial automation or control systems) requires security and assurance. Authorizing or denying access to files, interfaces, or functions in equipment involved in an automation system is a key measure to improve the integrity of the corresponding automation system.

[0003] Automated systems typically run operating systems on the controllers involved. For example, conventional operating systems use access control methods for operating system resources (such as files) based on access control lists (ACLs). For instance, an access control list (ACL) specifies whether certain users are allowed to access a file. Conventional operating systems such as Linus, UNIX, BSD, Windows, or MacOS all use the ACL model.

[0004] Access control management is typically based on the Freedom Access Control (DAC) model, where users can define access permissions for the objects they own within the system. In a Mandatory Access Control (MAC) system, access permissions are defined system-wide and cannot be changed by the user. ACL, DAC, or MAC models may not be sufficient or flexible enough for industrial applications, such as computerized automation systems.

[0005] Therefore, the purpose of this disclosure is to provide an improved method for authorizing access to objects in a computerized system.

[0006] According to one aspect of this disclosure, a method for authorizing an entity in a computerized system to access an object includes the following steps:

[0007] Provide an access control list (ACL) that specifies access permissions to objects on the computerized system for each object;

[0008] Assign capability requirement information to at least one object in the access control list;

[0009] Assign capability information to at least one entity in a computerized system;

[0010] A request is made by an entity to access an object;

[0011] Check whether the requesting entity has the necessary access permissions based on the ACL; and

[0012] Access to the requested object is only granted to the requesting entity if the capability information assigned to the requesting entity matches the capability requirement information assigned to the requested object.

[0013] In computerized systems, the term "entity" is used as the name of a subject requesting access to a specific object in the system. Further understanding, "match" will be interpreted as agreement or conformity between entities. Therefore, capability requirement information specifies what capabilities a requesting entity must possess to access the requested object.

[0014] Computerized systems can be distributed systems including communication-coupled devices. The proposed method for authorized access combines conventional ACL-based access control with additional capability-based verification assigned to the subject (i.e., the requesting entity). Capability requirement information indicates that specific capabilities, which can be defined by capability information, are necessary to access the requested object. In particular, capability-based additional verification can be readily implemented in automated systems or industrial networks. Specifically, regarding security-related access, combining ACLs with capability checks can enhance security.

[0015] In embodiments of the method, the at least one object is a file, interface, component, service, and / or a registry entry of the operating system. For example, a file may be stored according to a file system as defined by the operating system. An interface may be a network interface or an input / output interface that can be connected to a sensor or actuator. A component of the computerized system may be a power management unit, a watchdog component, or an integrated real-time clock. In embodiments, access to the interface is achieved through file access in the file system. A service may be a software service that allows or implements certain actions in the computerized system.

[0016] In embodiments of this method, the at least one entity is a user or a process. In methods of operating a computerized system, processes, such as those performing read or write operations, are not only recorded according to ACLs but also have capabilities assigned to them based on capability information. The same applies to users or user IDs that indicate a specific identity, to which capability information is assigned.

[0017] In this embodiment, capability requirement information is a data flag in the ACL that indicates whether capability requirements should be checked before authorized access. Capability requirement information can be a Capability Requirement Data Entry (CRDE) and / or a pointer to a capability requirement data entry.

[0018] For example, a data flag indicates that, in addition to a successful ACL check, a capability check needs to be performed before authorized access to an object, ensuring that the requesting entity can access the object. Flags or CRDEs can be stored based on the file header, file attributes, filename, or file extension. Specifically, if the object is a file in a file system, the CRDE can be explicitly or implicitly included in the filename. For example, a file extension like self-check.execap could indicate that access to the file is only permitted if specific capabilities are demonstrated. It is also possible to include the CRDE directly in the file header, such as in the first eight or sixteen bytes of the file to be stored.

[0019] In this embodiment, the CRDE can be part of a file attribute, which can be metadata associated with a corresponding computer file. Conventional operating systems already provide file attributes, so additional capability attributes can be added. This also includes file system-specific fields, such as extended attributes, that can be used to store the CRDE.

[0020] In this embodiment, CRDE is stored in a database separate from ACL. Trusted hardware modules, security elements, and / or cryptographic protection elements within a computerized system are conceivable.

[0021] In embodiments of this method, capability information is an entry in a capability table, including the entity's identifier and the assigned capability data entry (CDE). The capability table can be stored in a capability configuration file. Alternatively, a hardware security module or a security dongle can be used to store the capability table.

[0022] In this embodiment, kernel-level components such as Linux security modules are used for the storage capability table. For example, if a user is considered an access request entity, the username or user ID can be used as the entity's identifier. Alternatively or additionally, the process ID can be used as the identifier when a process needs to access certain files managed by the corresponding operating system implementing the aspects of the proposed method.

[0023] It is worth considering storing the capability table as part of the user database.

[0024] In this embodiment, a CDE is assigned to each user or user group. A CDE can be included in the attributes of a binary file, such as a file containing program code or belonging to a program code library. Attributes can define the characteristics of the capability data entries required to access and execute the program code within the file.

[0025] In some embodiments, the process running under the operating system is the requesting entity. The process can then have an allocated capability data entry, which can be passed to the resulting process (the child process), allowing capabilities to be inherited from one process to another.

[0026] Checking or verifying whether capability information matches the capability requirements of a specific process may include requesting external credentials, such as retrieving additional capability or security data from a server or a dedicated hardware security module.

[0027] In an embodiment, the CRDE includes a verification data entry VDE for verifying the CDE, wherein the CDE specifically includes a cryptographic checksum calculated as a function of data indicating the identity of the entity.

[0028] In this embodiment, a separate security element is used to perform the verification CDE. It is conceivable that the operating system implementing the proposed method generates a dedicated capability memory segment for the user. Such a dedicated capability memory segment can serve as a capability whiteboard, in which the user can securely store their capability entries.

[0029] For example, a computerized system may include an industrial PC, field devices, and / or controller devices that operate according to an operating system. When the computerized system is started, capability information can be stored as a function of random variables. Therefore, each time the system starts, a dedicated capability memory segment changes its appearance, which improves security.

[0030] Verifying a CDE can include an identity check, whereby the CDE and CRDE match if the CDE's bit sequence is identical to the required bit sequence in the corresponding CRDE. For example, the bit sequence can be 32, 64, 128, 256, or 512 bits long. The bits can be randomly selected, making it virtually impossible to guess a valid CDE. This provides a high level of protection.

[0031] Effective access control can be achieved if the CDE includes a password checksum derived from the requesting entity's identity data (such as username or user ID). Authentication can be performed by kernel components or security elements such as TrustZone, TEE, HSM, or CryptoController. External authentication CDEs are particularly advantageous when the requesting entity includes processes for updating firmware of a computerized system or processes related to the firmware of a computerized system.

[0032] In an embodiment, the CDE may further require interaction with the user. For example, additional verification of an object-specific password or user identifier based on a hardware token could be considered.

[0033] In embodiments, the CDE has a limited validity period. For example, validity may be limited to a certain time period. It is also conceivable that the CDE can only be used to access an object a certain number of times. One-time validity of access control for accesses highly relevant to security is conceivable. It is also conceivable that the CDE can only be used under certain global conditions of the operating system or device, such as the presence of a USB device, or if an external tamper switch indicates that the device remains intact.

[0034] In embodiments, the CDE varies depending on its purpose. For example, the CDE may initially allow a specific reconfiguration process during the bootstrap phase. However, such reconfiguration is no longer permitted during the normal operation of the computerized system. This capability is removed after a one-time deployment.

[0035] According to another aspect of this disclosure, a field device for an automation system is disclosed, including a processing device and a memory device for storing objects. The processing device is configured to perform methods for accessing objects by an entity according to the aspects disclosed above or below. For example, the field device may include a memory device containing a file system, and the objects are archived in the file system.

[0036] Preferably, the field device includes a separate storage device or segment for storing and / or inspecting capability information.

[0037] Field devices may further include safety elements for performing specific safety functions. For example, specific hardware features of the field device may be authorized only if the requesting party or object can provide matching capability information.

[0038] The proposed method offers the following advantages: robust protection against attacks on hardware components can be easily achieved. This is because the combination of ACL access control and additional capability checks leads to improved hardware security and can be added to the access control mechanisms of regular operating systems.

[0039] For example, the corresponding entity of a processing device can be implemented in hardware and / or software. If the entity is implemented in hardware, it can be embodied as a device, such as a computer or a processor, or as part of a system (e.g., a computer system). If the entity is implemented in software, it can be embodied as a computer program product, function, routine, program code, or executable object. Virtualized devices can be considered.

[0040] According to another aspect, this disclosure relates to a computer program product including program code for executing the methods described above when run on at least one computer or processing device.

[0041] Computer program products, such as computer program components, can take the form of memory cards, USB sticks, CD-ROMs, DVDs, or files that can be downloaded from a server on a network. For example, such files can be provided by transmitting files containing computer program products from a wireless communication network.

[0042] The method of authorized access is adapted to the aspects and characteristics described in the field equipment description, with necessary modifications to the details.

[0043] Other possible implementations or alternative solutions to the access authorization method include combinations of features described above or below with reference to the embodiments, which are not explicitly mentioned herein. Those skilled in the art can also add individual or isolated aspects and features to the most basic form of the invention.

[0044] Further embodiments, features, and advantages of the invention will become clear from the following description and dependent claims, taken in conjunction with the accompanying drawings, wherein:

[0045] Figure 1 A process flow illustrating the method steps involved in an embodiment including a method for authorizing access to objects in a computerized system is shown;

[0046] Figure 2 A schematic diagram of an embodiment for field devices is shown;

[0047] Figure 3 A process flow illustrating method steps involved in another embodiment, including a method for authorizing access to objects in a computerized system, is shown; and

[0048] Figure 4 A schematic diagram of an embodiment for a file system is shown.

[0049] In the figures, unless otherwise indicated, the same reference numerals designate the same or functionally equivalent elements.

[0050] Figure 1 The process flow illustrated includes method steps involved in an embodiment of a method for authorizing access to objects in a computerized system. The computerized system includes objects, for example, in the form of files. These objects are accessed by entities such as users. If a user wants to access a file, the operating system, on the one hand, performs an ACL-based check to authorize or deny access to that file. Additionally, the user must provide certain capabilities to access the file. The ACL defines what capabilities must be provided. Only if both requirements are met—that is, ACL compliance is consistent with and matches the capabilities required to access the file—can the user access the file and the corresponding data.

[0051] Therefore, in the first step S1, an access control list is provided for the object, that is, for the files in the computerized system. For example, Figure 4 The file system 10, which includes directories and files, is shown. Figure 4 The directories bin, config, log, and dev are shown. File system 10 is organized by the operating system of the computerized system. Examples of ACL entries can be seen in the bin directory 11. For example, it specifies authorized access based on the DAC attribute dr-xr-xr-x.

[0052] In addition to ACLs, in step S2, capability requirement information is assigned to files in the file system. For example, capability requirement information is a flag added to certain files based on attributes, indicating that additional capability checks are necessary to access the file. (See again...) Figure 4 In the bin directory 11, the config file with the ACL entry -r-xr-x- carries the additional attribute "x-capability". "x-capability" can be interpreted as indicating the following capability information: in order to access the config file in the bin directory 11, the user needs to have matching capability information.

[0053] Therefore, capability information is assigned to each user. If a user requests access to the config file in the bin directory 11, step S3 needs to check whether the requesting user has access rights according to the ACL, and additionally, must have the capability information assigned to the user that matches the capability requirement information assigned to the requested file. If not, access is denied in step S4.

[0054] If the requesting user has the assigned matching or compatible capability information, he or she can access the file in step S5.

[0055] Figure 2 A schematic diagram of an embodiment of field device 1 is shown, which can be used and operated according to methods for authorizing or denying access to an object. Figure 3 A processing flow including method steps is shown, which are involved in another embodiment of a method for authorizing access to such objects, particularly files.

[0056] Figure 2The field device 1 shown includes a processing device 2, such as, for example, a central processing unit (CPU). Memory devices 3 and 4 are present, where 3 is, for example, random access memory (RAM) and 4 is flash memory. Field device 1 has a network interface 5 and input / output interfaces for coupling with, for example, sensors or actuators 7 in an automation system. Furthermore, field device 1 includes a security element (SE) implemented as a hardware security module (HSM), which can be a security element of a system-on-a-chip.

[0057] In another embodiment, field device 1 may include a trusted execution environment, a hardware cryptographic engine, a security protection extension SGX, or an integrated trusted platform module TPM.

[0058] Figure 2 User 9 is further illustrated as an example of an entity attempting to access, for example, files and / or initiate a process to control sensor 7.

[0059] Flash memory 4 may store an operating system, such as Linux, BSD, or Windows. RAM memory 4 may also include a file system, such as... Figure 4 As shown in the example. In this embodiment, when the system of field device 1 starts up, file system 10 is copied to RAM memory 3.

[0060] The operating system is implemented to enforce ACL-based access control for files. The corresponding ACLs define which specific files on the file system 10 user 9 of the operating system / field device 1 can access. For example, ACLs define specific user types, such as "web service," "control," "config," or "diagnostic" users. For instance, an ACL defines that only the control user can access I / O device 6. Access to I / O interface device 6 may be blocked for other users.

[0061] Reference again Figure 4 The file system 10 shown illustrates a tree structure with directories bin 11, config 12, log 13, and dev 14, which includes several additional subdirectories or files. For each file, an ACL is assigned according to known techniques. ACLs are written based on read (r), write (w), and execute (x) permissions for users or user groups. Files may have additional attributes, such as specifying the directory as "d". For example, based on the ACL entry drwxr-xr-x, the directory log 13 is available for access.

[0062] Figure 3The process flow for accessing files in file system 10 is now shown. The process begins at step S0. Next, in step S11, user 9 requests access to a specific file. For example, user 9 wants to access the file / bin / config in the bin directory 11.

[0063] In step S12, the user's access rights are first checked according to the corresponding ACL. If not, access is denied in step S13, causing the process to stop with access denied in steps S18 and S19 respectively.

[0064] The config file in the bin directory (11) also contains capability requirement information based on flags and / or capability requirement data. The capability requirement data entry in the config file is x-capability: service. Therefore, the config file can only be accessed if the requesting user has the service capability. Figure 3 In the processing flow, firstly, the operating system checks in step S14 whether the file attribute indicating capability is necessary exists. This is the case for the configuration file bin directory 11. Therefore, the capability is checked and verified in step S15.

[0065] If a user has the associated capability information based on the corresponding capability data entry CDE, he or she can manipulate the config file and authorize access in step S17.

[0066] If the access request points to a file that does not have capability attributes, such as a control file in the bin directory 11, then there is no need to perform capability attribute checks in step S14, and access is immediately authorized in step S17.

[0067] In a simulated manner, such as with other files in an executable, specific capability requirements can be specified. For example, a user may only be able to run or access the security self-test application sectest (Security Test) in the bin directory if he or she has the secrun capability. We note that the sectest ACL entry prohibits any changes to the sectest program.

[0068] In conjunction with denying or granting access to I / O module 6 of field device 1, dev directory 14 requires w-capability: iostartup. For example, "iostartup" implies that the ioconfig process can only be executed during the boot process of device 1. For example, the iostartup capability can only be used once and expires after the first system boot. This prevents manipulation of I / O module 6 during the operation of field device 1.

[0069] For example, security element 8 can perform verification of the capabilities assigned to the requesting user by calculating a password checksum. If security element 8 verifies that the checksum, for example, the user ID, is correct, then the configuration of I / O interface 6, and thus access to sensor and actuator devices 7, is permitted. This is especially true because the configuration file ioconf can only be read and written according to ACLs.

[0070] Capabilities assigned to users or processes can be hard-coded, for example, through a specific operating system kernel. Such hard-coded capabilities or capability data entries consequently have the advantage that they cannot be changed by the user. However, in other embodiments, the capability list based on a capability table including a user identifier and assigned capability data entries can be stored according to a configuration file. For example, this can be based on… Figure 4 This is achieved through the config directory 12.

[0071] Generally, for field devices in computerized systems, improved integrity and robustness against unauthorized access are achieved. This is due to the following advantages: conventional operating systems such as Linux, UNIX, BSD, or Windows can be extended by checking the capabilities of access control files or processes. In particular, hardware-specific functions can be protected through specific capability requirements. Therefore, the overall security of the computerized system is improved.

[0072] Although the invention has been described with reference to preferred embodiments, it will be apparent to those skilled in the art that modifications are possible in all embodiments.

[0073] Reference number:

[0074] 1. On-site equipment

[0075] 2 Processing equipment

[0076] 3 RAM memory devices

[0077] 4 Flash memory devices

[0078] 5 network interfaces

[0079] 6 Input / Output Interfaces

[0080] 7 Sensor / Actuator Devices

[0081] 8 safety elements

[0082] 9 users

[0083] 10 file system

[0084] Table of Contents 11-14

[0085] S0 Start

[0086] S1 provides ACL

[0087] S2 allocation capacity

[0088] S3 checks ACL consistency

[0089] S4 Access Denied

[0090] S5 authorizes access upon successful capability check.

[0091] S11 File Access Request

[0092] S12 checks the file ACL

[0093] S13 allows access

[0094] S14 File Capability Attributes

[0095] S15 Inspection Capability

[0096] S16 allows access

[0097] S17 Authorized Access

[0098] S18 Access Denied

[0099] S19 has ended.

Claims

1. A method for authorizing an entity (9) in a computerized system to access an object (12), comprising: Provide (S1) an access control list ACL that specifies access permissions for each object (12) of the computerized system; Assign (S2) capability requirement information to at least one of the objects in the Access Control List (ACL); Assign capability information to at least one entity in a computerized system (9). The request (S11) is for entity (9) to access object (12); Check whether the requesting entity (9) has access permissions according to the ACL; and Access to the requested object (12) by the requesting entity (9) is only granted (S5) if the capability information assigned to the requesting entity (9) matches the capability requirement information assigned to the requested object (12). Among them, the capability requirement information is a data flag in the ACL that indicates the capability requirement, the capability requirement data entry CRDE, and / or a pointer to the capability requirement data entry CRDE.

2. The method according to claim 1, wherein the at least one object (12) is a file, service, and / or registry entry.

3. The method according to claim 1 or 2, wherein the at least one entity (9) is a user or a process.

4. The method according to claim 1 or 2, wherein the object (12) is a file, and the CRDE is implemented as part of the file's header data, file attributes, file name and / or file extension.

5. The method of claim 1, wherein the CRDE is stored in a database separate from the ACL, particularly in a Trusted Hardware Module (TPM), a Security Element (SE), and / or a cryptographic protection element.

6. The method according to claim 1 or 2, wherein the capability information is an entry in a capability table, the capability table including an entity identifier and an assigned capability data entry CDE, wherein the capability table is stored in a capability configuration file, a Linux security module (LSM), a security element (SE), a hardware security module (HSM), and / or a security dongle.

7. The method according to claim 1, wherein, The CRDE includes a verification data entry VDE for verifying the CDE, wherein the CDE specifically includes a cryptographic checksum calculated as a function of data indicating the identity of the entity (9).

8. The method according to claim 7, wherein, Verification of the CDE is performed using a separate security element (8).

9. The method according to claim 6, wherein, CDE has a limited effective period.

10. The method according to claim 1 or 2, wherein the computerized system includes an industrial PC, field devices (1) and / or controller devices operating according to an operating system, and guiding the computerized system includes a function that stores capability information as random variables.

11. A computer program product including program code for performing, when run on an industrial PC, a method for an authorized entity to access an object as claimed in any one of claims 1-10.

12. A field device (1) for an automation system, comprising a processing device (2) and a memory device (3, 4) for storing an object (12), wherein the processing device (2) is configured to perform a method for accessing the object (12) by an entity (9) according to any one of claims 1-9.

13. The field device according to claim 12, wherein, The memory devices (3, 4) include a file system (10), the objects being files in the file system (10), and the field device (1) includes a separate memory device or segment for storing and / or checking capability information.

14. The field device according to claim 12 or 13, further comprising a safety element (8).

Images