Method, computer program and computer device for securing data processing in a computer

Abstract

This specification relates to a method for securing data processing in a computer arranged according to a hybrid software architecture. The hybrid architecture relies on a dual operating system including a general-purpose operating system (GPOS) and a trusted operating system (TOS) that performs critical functions. Execution of a current application by the GPOS implies access of at least one primitive to the TOS. The method includes the GPOS performing an authentication procedure requiring authentication validation granted by the TOS. Upon authentication validation by at least the TOS, the method includes authorizing said at least one primitive to access the TOS.

Description

[Technical Field]

[0001] This specification relates to secure interaction between processors in computer technology. [Background technology]

[0002] An example of data exchange between processors can be observed in a multicore microprocessor unit ("MPU"). Modern MPUs provide several execution cores, each of which retrieves and executes program instructions as if the computer had several processors. The cores may or may not share caches and may implement message-passing or shared-memory inter-core communication methods. Typically, each core has a level L1 cache, but the cores share a level L2 cache. Homogeneous multicore systems contain only identical cores, while heterogeneous multicore systems have non-identical cores.

[0003] A specific interrupt controller (called a global interrupt controller in ARM® processors) is required to provide inter-processor interrupts in addition to inter-core interrupt routing.

[0004] RAM (Random Access Memory) and device peripherals (such as "UART" (which stands for "Universal Asynchronous Receiver Transmitter") and / or network interfaces) are shared between different cores of a Central Processing Unit (CPU). Therefore, if several cores are accessing the same resources simultaneously, some memory or device bottlenecks may occur.

[0005] The hardware security mechanisms available in ARM and x86 processors and their use to implement a Trusted Execution Environment (TEE) are described below.

[0006] ARM processors with TrustZone support two virtual cores, each of which is a physical processor core. - one virtual core considered non-secure, called the "non-secure world", and - The other virtual core is considered secure and is called the "secure world"; and a mechanism for context switching between these two cores known as "monitor mode", and implements security extensions to the architecture that provide.

[0007] The world in which the processor is currently running can be determined by a non-secure bit available in a hardware secure configuration register. The mechanism that allows the physical processor to enter monitor mode from the non-secure world can be triggered by executing a dedicated instruction named "Secure Monitor Call" (SMC), which can be seen as an exception to the monitor mode software. Furthermore, main memory is also flagged with a non-secure bit, which allows memory isolation between the secure and non-secure worlds.

[0008] The security model implemented using TrustZone technology provides additional segmentation by separating the secure world from the normal world, allowing, for example, DRM solutions ("Digital Rights Management") to protect against hostile environments such as infected systems in both userland and kernelland.

[0009] Intel® Software Guard Extensions (Intel SGX) provides hardware-based memory encryption that isolates specific application code and data in memory. SGX allows user-level code to allocate private regions of memory called enclaves that are designed to be protected from processes running at higher privilege levels.

[0010] ARM TrustZone and Intel SGX are particularly used to implement trusted execution environments (TEEs) in embedded devices such as smartphones. A trusted execution environment (TEE) is an isolated execution environment that provides security features such as isolated execution and integrity for applications running within the TEE, along with confidentiality of their assets. Generally speaking, a TEE provides a parallel execution space for a normal operating system and a higher level of security for trusted applications running on the device. The aforementioned "normal" operating system can correspond to a rich operating environment (hereinafter referred to as "REE") or a general-purpose operating system. While trusted applications running in the TEE have full access to the device's main processor and main memory, hardware isolation protects these components from user-installed applications running in the main operating system. Software and cryptographic isolation within the TEE protect the various trusted applications contained within from each other. This architecture is shown in Figure 1.

[0011] In a REE such as Linux, the TEE kernel driver handles the details needed to communicate with the TEE. In ARM Trustzone, the lowest level communication with the OP-TEE ("Open Portable TEE") is based on the ARM SMC Calling Convention (SMCCC), which is the basis for the TEE's SMC interface used internally by the driver (SMC stands for "Secure Monitor Call"). The kernel TEE subsystem handles: ● TEE driver registration ● Managing shared memory between Linux and TEE ● Providing a generic API (Application Programming Interface) to the TEE.

[0012] TEE applications and components rely on an internal API called the TEE Internal Core API, while the TEE Client API describes how to communicate with the TEE from client applications running in the REE. This API makes use of a generic TEE API that accesses kernel drivers using standard POSIX communication methods (IEEE1003) that rely on file descriptors and ioctls ("input-output control"), as shown in Figure 2.

[0013] Hybrid software architectures, such as those disclosed in Patent Document 1, attempt to address the coexistence of services and applications with heterogeneous network QoS (Quality of Service) requirements, security constraints, and implementation complexities on a single processor. In fact, in a single system, some applications may have strong real-time constraints, as introduced in the above section, which means that they cannot support latencies greater than a few microseconds when a network event (e.g., message reception) occurs. Applications of this kind are not very complex and are usually implemented on a trusted operating system (TOS), which typically operates in real time and guarantees very low latency. However, systems are also intended to support much more complex applications that do not have real-time requirements or have soft real-time requirements. These applications may require frequent updates, may be extended by software plug-ins, and may include many user functions. These applications are usually implemented on a general-purpose operating system. The following application requirements cannot be met by exclusively using a typical general-purpose operating system (such as Linux or VxWorks®): For example, the operating system of a modern industrial communications platform must support a variety of capabilities. ● Controlling network latency ● Security compliance to prevent attacks ● Support for complex applications / multi-protocol stacks ● Flexibility to reduce costs by considering the development process (software that runs on a general-purpose OS) ● Integration and control of hardware Ethernet interfaces with different functions.

[0014] The hybrid software architecture relies on a dual OS monitor (same role as a hypervisor in software virtualization) designed to run TOS or BareMetal (BM) applications and GPOS (General-Purpose Operating System) simultaneously on the same core. The hybrid software architecture utilizes ARM TrustZone security extensions to run each OS in a different security state. The main features of hybrid software are as follows: ● Allows simultaneous execution of TOS and GPOS on the same processor. TOS memory and TOS devices are protected from unauthorized access by GPOS. This is supported by configuring resources used by the TOS to be accessible only from the trusted state. The remaining resources are configured to be accessible from both the trusted and untrusted states. ● TOS real-time requirements are guaranteed. Time isolation of TOS activity is supported by carefully allocating two types of interrupts to each TrustZone state: FIQ (Fast Interrupt reQuest) and IRQ (Interrupt ReQuest of relatively normal priority). ● Secure interrupts are forwarded to the TOS. ● Non-secure interrupts are forwarded to GPOS.

[0015] When a core runs both TOS and GPOS, the following rules apply to interrupt management: In the secure state (TOS running), non-secure interrupts are disabled so that GPOS cannot interrupt the execution of TOS. For this reason, GPOS only operates upon explicit request by TOS. This is achieved through the Secure Monitor Call (SMC) instruction. ● In the non-secure state (GPOS running), secure and non-secure interrupts are enabled so that the TOS can regain control of the processor. TrustZone is configured to prevent the non-secure side from disabling secure interrupts. Thanks to this policy, the real-time constraints of the TOS are guaranteed and malicious code cannot change the security configuration of the platform.

[0016] When dedicating an entire core to TOS, this policy is no longer needed, but can be applied without any impact - TOS just never helps GPOS on that core.

[0017] In a multi-core system, the monitor code is shared by all cores, but except during initialization, the monitor execution is core independent: system calls and system notifications are always executed on the same core on which they are triggered.

[0018] In this architecture, memory areas and peripherals have access rights that make it possible to define several private areas and peripherals that are managed exclusively by each OS.

[0019] Using access rights, a private memory is defined for each OS, and other OSes cannot access this memory. As shown in Figure 4, the OS (GPOS) running in the non-secure part cannot access the memory used by the OS running in the secure part. If communication between different OSes is required, a shared memory is available that can host FIFOs, which are data structures used to implement several communication mechanisms. Several hardware mechanisms, such as interrupts, can also be used to notify events from one OS to another.

[0020] In this specification, a secure method of communication between a first OS running in an untrusted / unsecure portion, such as a rich execution environment or general-purpose OS, and a second OS running in a trusted execution environment (TEE), such as a TOS, is explored.

[0021] In fact, the OS running in the trusted part can provide some important and secure services to the OS running in the non-secure part through primitives defined over a communication path opened between the non-trusted OS and the trusted OS, hereafter referred to as "Inter-OS Communication" (or "IOC"). For example, when applied to an industrial automation (IA) communication system, the trusted OS can provide primitives and services in charge of controlling the state (start / stop / pause) of the running automata.

[0022] Therefore, there is a desire to protect access to these critical primitives from applications running on untrusted operating systems.

[0023] Since a platform running on such a software architecture can be deployed in an open environment, an untrusted OS may be tampered with and an attacker may execute some applications that attempt to execute malicious requests using critical primitives (see Figure 5). For example, an attacker may imitate a proven application, such as a Guide User Interface (GUI) application responsible for stopping / starting an automaton, and send a request with bad parameters to cause the trusted OS to execute the bad request, as shown in Figure 5. On the GPOS side, an application can send a request to the TOS service by using a specific file descriptor associated with an IOC device driver. The GPOS kernel forwards such requests by using this IOC device driver, which is responsible for managing the IOC (software) interface.

[0024] Therefore, in an open environment, there is a need to protect access to critical requests so that only a set of authorized applications can perform such requests.

[0025] A solution to this problem can be to add some mechanisms to GPOS that support access control security policies, including mandatory access controls at the kernel and user space levels. For example, SELinux is a collection of kernel modifications and user space tools that have been added to various Linux distributions.

[0026] A Linux kernel with integrated SELinux enforces mandatory access control policies that restrict access to user programs and system services, as well as file and network resources. By limiting privileges to the minimum required for operation, the potential for these programs and daemons to cause harm if impaired or compromised (e.g., via buffer overflows or misconfiguration) is reduced or eliminated. This restriction mechanism operates independently of traditional Linux (discretionary) access control mechanisms. It has no concept of a "root" superuser and does not share well-known shortcomings of traditional Linux security mechanisms, such as reliance on setuid / setgid ("Set owner user ID" / "Set Group ID") binaries.

[0027] As a result, SELinux allows the system to potentially control what activities each user, process, and daemon is allowed to do with very precise specifications. SELinux is used to confine daemons such as database engines or web servers to have clearly defined data access and activity rights. This limits the potential harm from a confined daemon that becomes compromised.

[0028] However, SELinux does not protect access to some specific resources when the system is highly compromised, meaning that an attacker has gained a higher level of privileges and can access any file descriptor defined in GPOS, especially the file descriptors used to send requests to the trusted OS. [Prior art documents] [Patent documents]

[0029] [Patent Document 1] European Patent Application Publication No. 3872634 Summary of the Invention [Problem to be solved by the invention]

[0030] Therefore, there is a need for a highly secure way to authenticate applications and filter requests running on an untrusted OS so that only authorized applications can send requests to the trusted OS, so that the trusted OS can trust the origin of the request and execute the request securely. This specification aims to improve this situation. [Means for solving the problem]

[0031] To that end, the present specification provides a method for securing data processing in a computer arranged according to a hybrid software architecture, said hybrid architecture relying on a dual operating system including a general purpose operating system "GPOS" and a trusted operating system "TOS" performing critical functions; Execution of the current application with GPOS implies access to at least one primitive of TOS, The method comprises: - the GPOS performs an authentication procedure requiring authentication validation provided by the TOS; - authorizing said at least one primitive to access the TOS upon authentication validation by at least the TOS; The present invention proposes a method including:

[0032] Thus, the GPOS is programmed to initiate an authentication procedure when a primitive requests access to the TOS, typically by execution of computer program instructions of the current application, and the TOS is programmed to check authentication parameters provided by the GPOS when the GPOS performs the authentication procedure.

[0033] Thus, in one embodiment, the computer program of the current application may include at least one instruction, the execution of which by the GPOS initiates the at least one primitive that requests access to the TOS. This may be a particular feature of the computer program of the current application having such an instruction, for example, when the instruction that causes the implementation of an authentication procedure is executed at the start of operation of the computer program of the current application. In this case, only authenticated applications may be executed by a computer having such a hybrid architecture secured in accordance with this specification.

[0034] In one embodiment, upon a request by at least one of the above primitives to access a TOS, a system call initiates a specific authentication primitive (an "IOC" primitive, described in detail below) that causes the GPOS to perform an authentication procedure.

[0035] Typically, a GPOS can be programmed to generate such a system call to initiate an authentication primitive when any primitive requests access to a TOS during the execution of the current application.

[0036] In this embodiment, the initiation of the particular authentication primitive described above generates a request from the GPOS to access the TOS, along with authentication parameters that are validated by the TOS.

[0037] More generally, when the GPOS requests the TOS for the authentication validation, the GPOS provides the TOS with authentication parameters including at least a first set of certificate data, and the authentication procedure includes verification by the TOS of the first set of certificate data provided by the GPOS against a second set of certificate data previously stored by the TOS.

[0038] For example, the first set of certificate data may include data of a customer certificate, and the second set of certificate data may include data of a root certificate authority certificate as a trusted certificate stored in secure memory accessible only by the TOS, which may occur during an initialization step of configuring the TOS.

[0039] This initialization step may typically correspond to installing a TOS or updating an existing TOS with authentication data.

[0040] In one embodiment, an application digest is calculated by the GPOS in the preamble step of installing the current application, and a digital signature of the binary code of the current application is generated using the application digest and a private key associated with the public key whose data is in the first set of certificate data.

[0041] This application digest (e.g., hash) and digital signature are calculated to allow the TOS to verify that the primitive requesting access originates from the correct application execution. Furthermore, these data will be signed with the correct key; if not, the TOS will deny the access request.

[0042] In one embodiment, the specific authentication primitive (hereinafter referred to as "IOC_CtrlReq_AppAuth") initiates a request to access the TOS using the generated signature and the first set of certificate data before execution of each current instance of the current application. Thereafter, the GPOS kernel module: - getting the process identifier "PID" of the current application instance; - Obtaining the binary executable associated with said PID; - calculating an application digest of the type generated in the preamble step over the entire binary file; - sending a message (hereinafter referred to as "IOC_IOCTL_CMD_AUTH") to TOS that includes an application digest, the generated signature, and the first set of certificate data; Process the request by

[0043] The aforementioned kernel module can be seen as a program loaded into the GPOS kernel that acts as a driver that communicates with the TOS.

[0044] In this embodiment, when the TOS receives a message, - comparing the provided first set of certificate data with said second set of certificate data securely stored in the TOS; - checking the provided application signature using an application digest and a public key embedded in said first set of certificate data using an asymmetric cryptographic algorithm; - signaling by sending to the GPOS an authentication status of success or error depending on the result of said check; Certification is then carried out.

[0045] In a first embodiment, the GPOS kernel module stores the authorization state in association with the PID of the current application instance in order to filter requests initiated by one or more primitives of the current application based on the authorization state.

[0046] In a second embodiment, GPOS and TOS are interconnected through an Inter-OS Communication "IOC" interface, and each primitive requesting access to TOS is filtered by TOS in one of the IOC interfaces using the PID of each current application instance to avoid possible attacks from the GPOS kernel module.

[0047] Typically, the TOS may return a single token per current application instance as a result of an authentication request to prevent unauthorized reuse of the token for other current application instances, the token having a value defined by the authentication state.

[0048] The invention also covers a computer program comprising instructions which, when executed by a processing unit, cause the implementation of a method according to any one of the preceding claims.

[0049] Typically, a computer program - GPOS that identifies the primitive requesting access to the TOS and initiates the authentication procedure; - TOS checking the authentication parameters provided by GPOS, The instructions may include instructions that can be shared between the

[0050] The present specification also covers a computer program of a current application, the computer program of the current application including at least one instruction that is executed when the computer program of the current application is executed, and the execution of the at least one instruction by the GPOS initiates at least one primitive that requests access to the TOS, thereby causing the implementation of the authentication procedure of the method set forth above.

[0051] Typically, this instruction may be executed when the current application is started (i.e., as soon as the program begins its operation), where, as indicated above, said current application may correspond to an application that has been authenticated and, therefore, authorized to be executed by a computer having a hybrid architecture secured in accordance with this specification.

[0052] Furthermore, the present specification also covers a computer device comprising a processing unit for implementing the method defined above (and thereby corresponding to said computer having a hybrid architecture secured according to the present specification).

[0053] Further details are provided in the following description with reference to the accompanying drawings. [Brief explanation of the drawings]

[0054] [Figure 1] FIG. 1 is a diagram illustrating a hardware separation between a trusted execution environment (TEE) and a rich operating environment (REE). [Figure 2] FIG. 1 illustrates a schematic diagram of a typical TEE API that relies on ioctls to access kernel drivers. [Figure 3]1 is a diagram illustrating a hybrid software architecture that relies on dual OS monitors to run TOS or BareMetal (BM) applications and GPOS (General Purpose Operating System) simultaneously on the same core. [Figure 4] FIG. 1 shows a schematic diagram of operating systems running in a secure and non-secure part (GPOS) respectively, and being prevented from accessing the same memory used by the running OS. [Figure 5] FIG. 1 illustrates a schematic diagram of possible attack mechanisms on a platform running a hybrid software architecture. [Figure 6] FIG. 2 shows a schematic diagram of encryption and decryption of a shared message. [Figure 7] FIG. 1 is a schematic diagram of a typical public-key infrastructure (PKI). [Figure 8] 1 shows a schematic diagram of the principle of an authentication procedure that relies on IOC primitives of the normal group and requires a specific TOS task in the trusted part that is responsible for validating the authentication. [Figure 9] FIG. 2 is a diagram schematically illustrating main steps #1 to #5 of the method according to the first embodiment of the present specification. [Figure 10] FIG. 10 is a diagram schematically illustrating main steps #1 to #6 according to the second embodiment. [Figure 11] 1 shows a schematic diagram of the structure of a device for performing a method according to an exemplary embodiment; DETAILED DESCRIPTION OF THE INVENTION

[0055] For a system environment with a trusted OS, we propose in the following to define a secure method for filtering access to some important primitives provided by trusted OS services. These primitives can be classified into two groups: normal and secure. The method authenticates applications that can issue requests to the trusted OS and filters access depending on the calling application, the type of request, and the result of the authentication.

[0056] In the following, two embodiments of the method are proposed to prevent attacks when the main GPOS is compromised and the attacker has the ability to run applications with a higher privilege level. The second embodiment can be considered an extension of the first embodiment and allows for stronger security since it relies exclusively on mechanisms operating within the trusted OS boundary.

[0057] The authentication process utilizes cryptographic mechanisms, namely digital signage using asymmetric cryptography, public key certificate chains, and public key infrastructure for key distribution / revocation. These principles are applied here to computer systems running on a hybrid software architecture. Contrary to existing solutions, the method does not require any modifications to the GPOS file system. Only the application needs to be specifically designed to support the proposed authentication mechanism, and some specific steps will be implemented when this application is deployed across the execution environment.

[0058] Before describing the above two embodiments in detail, the principle of using digital signatures will be explained again below. A digital signature is a mathematical method for verifying the authenticity of a digital message or digital document. A valid digital signature, when necessary conditions are met, gives the recipient a very high degree of confidence that the message was created by a known sender (authenticity) and that the message has not been altered in transit (integrity).

[0059] In the example of Figure 6, the message is digitally signed using Alice's private key, but the message itself is not encrypted. Alice signs the message with her private key. Bob can use Alice's public key to verify that Alice sent the message and that the message has not been altered.

[0060] A public key certificate, also known as a digital certificate or identity certificate, is an electronic document used to verify the validity of a public key. The certificate contains information about the key, information about the identity of its owner (called the "subject"), and the digital signature of the entity (called the "issuer") that verified the certificate's contents. If the signature is valid and software examining the certificate trusts the issuer, the software can use the key to communicate securely with the certificate's subject.

[0061] The signature is generated by hashing the contents of the certificate, and then the hash is encrypted using the issuer's private key. The type of hashing and encryption algorithm is usually indicated in the certificate.

[0062] In a typical public key infrastructure (PKI) scheme, shown in Figure 7, the certificate issuer is a certificate authority (CA), typically a trusted third-party company that charges customers for issuing their certificates. In contrast, a self-signed certificate is a certificate with a subject that matches its issuer and a signature that can be verified with its own public key. Thus, the signature of a self-signed certificate is generated using the private key that corresponds to the public key embedded in the certificate.

[0063] For the purposes of this specification, the primitives provided by the IOC interface to user space applications fall into two categories: - Normal, and - Secure, It is divided into

[0064] Normal primitives can be invoked without valid application authentication, while secure primitives require valid authentication, which means that the application must initiate the authentication procedure immediately after opening the IOC session after startup.

[0065] This authentication procedure relies on IOC primitives from the normal group. This authentication procedure requires a specific TOS task (in the trusted part) that is responsible for validating the authentication process as shown in Figure 8.

[0066] In both of the following embodiments, the application executable binary is signed as described in detail below. Instead of signing the full binary executable, the authentication procedure involves signing only an application digest that is pre-computed over the full application binary code. This process allows for a reduction in the amount of data exchanged over the IOC interface, thereby improving efficiency. This method requires a user certificate, which can be generated either by the customer themselves or a trusted third party called a Certificate Authority (CA) when a PKI is used. This certificate is referred to below as the "customer certificate" (of a natural person or client application). To obtain security, the Trusted OS (TOS) must check the authenticity of this customer certificate. This operation uses a trusted certificate. This trusted certificate can be either a self-generated certificate, a CA root, or an intermediate certificate that is securely stored in memory accessible only to the Trusted OS (typically the memory shown in the trusted area in the right part of Figure 1) to prevent tampering.

[0067] In the following, we assume that the proposed method is applied to a control API implemented as a POSIX ioctl, which uses file descriptors at the user space level to generate system calls ("syscalls") to the kernel (such as the Linux kernel, which is an analogue of the POSIX ioctl). The API defines IOC primitives that support request execution and also authenticate the application using the API.

[0068] The first embodiment is described in detail below.

[0069] We assume that the GPOS kernel cannot be tampered with by an attacker. Only the file system is fully accessible with high-privilege access, so that an attacker can access user-space resources associated with the IOC interface (e.g., file descriptors). Therefore, we can assume that the kernel-level IOC driver is secure and cannot be tampered with (or at least can detect attacks). This way, an attacker cannot inject data / modify code within the code section.

[0070] Referring to FIG. 9, according to this first embodiment, when the current application is intended to be executed in a hybrid architecture, the method includes the following steps: Step #0: First, Root Authority Certificate (RAC) data is stored in the secure memory of the trusted area TOS (e.g., from a secure chip card or dongle or a secure connection to a remote server). These RAC data allow checking the customer certificate provided by the certificate authority that issued it. This step #0 is performed once for a computer with a hybrid architecture.

[0071] Step #1: An application digest (e.g., a hash such as a SHA256 hash) is first calculated over the entire file, and a digital application signature is calculated using the application digest and a customer private key. This step is performed, for example, by the customer's remote computer prior to deployment of the current application and preparation of a file system image. A customer certificate (including a public key associated with the customer private key) is also installed and stored in memory accessible by GPOS (the "untrusted area" in the left portion of Figure 1) along with the current application binary code and the generated application signature. The customer certificate can therefore be provided by the GPOS kernel each time it requests access to the TOS during the next current step #2, detailed below. This step #1, in contrast, is performed only once when the current application is deployed / installed.

[0072] Step #2: (When at least one secure primitive is deemed to require access to the TOS) a system call is initiated to authenticate the current application (IOC_CtrlReq_AppAuth), a specific IOC primitive defined to authenticate the current application. To reiterate, the term "primitive" functionality (here simply referred to as "primitive") refers to the basic functionality (usually provided by a programming interface) provided by the first level software layer, i.e., the software layer directly above the computer's hardware architecture. This specific IOC primitive is initiated by a system call handled by the GPOS kernel itself, according to a system instruction, and not according to the specific instructions of the current application (even if, of course, the application's instructions can trigger this system instruction).

[0073] This step #2 is executed every time the current application starts a session (actually, when the current application is launched). This particular authentication primitive (ICO) generates a request that takes the current application signature and the customer certificate as parameters. The IOC kernel module is responsible for handling the system call and performs the following actions: ● Obtaining the Process Identifier (PID) that identifies the current instance of the current application; ● Obtaining the binary executable associated with this PID (for example, using the Linux kernel's procfs and filp_open), ● Calculate the application digest over this binary file using the same method as in step #1, ● Sending an IOC_IOCTL_CMD_AUTH message with the application digest, application signature, and customer certificate to the TOS IOC driver via the IOC interface.

[0074] Step #3: Upon receiving this message, the TOS IOC authentication task: ● Checks the provided application certificate with a Root Certificate Authority Certificate (RAC) pre-stored in secure memory, ● Checking the provided application signature using the application digest and the customer public key embedded in the validated certificate; ● Depending on the result of the above operation, it returns success or error to GPOS.

[0075] The IOC kernel module stores this returned authentication status in the kernel context associated with the PID of the current application instance, and then notifies this instance of the success or failure of the authentication request.

[0076] Step #4: The current application instance executes one or more primitives classified as secure. The GPOS kernel filters the request from the secure primitive by checking the authorization state associated with the current instance's PID before forwarding the request content to the TOS in step #5.

[0077] Step #5: The GPOS kernel forwards the secure request to the TOS (if not filtered) and continues executing the current application.

[0078] This solution is secure because we can reasonably assume that an attacker cannot change the authentication state value returned to the kernel (and which can be stored in kernel memory). However, this assumption can be weak if an attacker can map kernel memory into user space with read / write access. By subsequently changing the value of this variable, an attacker could perform requests that require application authentication.

[0079] The method according to the second embodiment remains similar to the first embodiment shown above, except that once the authentication status has been determined by the TOS for the current instance of the application (after steps #2 and #3), the GPOS kernel module is no longer responsible for filtering incoming requests issued by the application. In this solution, the Trusted OS (TOS) is entirely responsible for directly filtering requests from primitives to access the TOS. The message IOC_IOCTL_CMD_AUTH and the primitive IOC_CtrlReq_AppAuth then return an authentication token directly to the current instance of the application if the authentication status is "successful." If the authentication status is "failed," a "null" token (invalid token) is returned. To this end, the token value associated with the PID of the current application instance is stored in the TOS memory.

[0080] This token value is then used in step #4 as an additional parameter to any further requests for secure primitives (named IOC_Ctrl_Req_SecXXX) by the application.

[0081] In step #5, the kernel module passes this authentication token and the PID of the current application instance as arguments to any IOC_IOCTL_CMD_SECXXX messages via the IOC interface. Then, for each request from a secure primitive, the TOS checks the validity of the token before executing the carried request in step #6 shown in FIG. 10. The TOS can compare the token value stored in its secure memory with the token value indicated in the message. As a result, the TOS can normally discard requests from secure primitives indicated in messages that have an invalid token as their argument. The invalid token can be a "null" token as described above (because authentication has failed) or any other invalid token, such as a token value previously used (e.g., for a previous instance) to prevent replay attacks. These additional steps make the filtering step completely secure, while requiring only small computational and memory resources on the TOS side. The PID is passed by the kernel module to the TOS so that the TOS prevents PID hijacking attacks. In such an attack, a malicious application steals legitimate tokens from applications that have successfully passed the authentication step. The PID is determined by the kernel code, so it is important that the kernel binary code does not change, or that the TOS can at least detect any changes by performing periodic code checks.

[0082] Compared with the first embodiment described above, the kernel module in this second embodiment does not store important data in the private context associated with the file descriptor passed in the driver call function, so that an attacker cannot change the value of variables by mapping kernel memory to user space, thereby enabling the execution of requests that require application authentication.

[0083] Currently, for signing application binary code, signature generation / checking can rely on the use of asymmetric cryptography (private key / public key). The following two schemes can be proposed: The first method allows full customer control but may require a secure TOS setup by the customer prior to deployment. - The second scheme can rely on the use of root certificates and can be deployed without TOS setup (factory configuration may be sufficient).

[0084] The first approach (without PKI) allows the customer to independently generate a private / public key pair. The private key must be stored securely (usually off-platform) and is used to sign the application runtime binaries. The public key is embedded in a self-signed certificate. This certificate is stored in a trusted domain (TOS), and the embedded public key is used to check signatures.

[0085] The second approach (with PKI) allows the customer to generate a private / public key pair, where the private key is securely stored by the customer and used to sign the application runtime binaries. A root Certificate Authority (CA) certificate is securely stored in a Trusted Domain (TOS). This Certificate Authority can be the manufacturer (i.e., the provider of the authentication means) or any trusted third-party company.

[0086] The customer can send the public key to the issuer (CA), who will then, as explained above, - Certificate information (customer information, issuer information, certificate expiration date, etc.) - a customer public key; - a certificate signature generated using the root CA private key; and Generate a customer certificate containing

[0087] In another embodiment, several intermediate certificates can be generated by the CA. The signature of the customer certificate can be generated using a private key associated with one of the intermediate certificates. The intermediate certificates are to be uploaded to the TOS using a specific ICC IOTCL command. After uploading, the TOS checks the validity of the provided certificate by comparing it with a stored root CA certificate. The main advantage of this method is that the CA can avoid frequent use of the root CA, thereby limiting its exposure to potential attackers. This method is also more flexible, especially when several certificates need to be revoked.

[0088] For example, a certificate revocation list (CRL) can be associated with each stored certificate. A CRL can be stored as a list of digital certificates that have been revoked by the issuing CA before their scheduled expiration date and should no longer be trusted. The CRL can be stored by the TOS and is to be updated using specific ICC IOTCL commands. To prevent an attacker from sending a list CRL and inducing a denial of service due to a fake certificate, primitives related to certificate management must be classified into secure groups.

[0089] A computer program having an algorithm following the steps of the method presented as a possible embodiment above can be deployed in any type of product that uses an embedded platform running a main operating system together with a trusted execution environment that securely executes and executes requests issued by applications running on said main OS. A hybrid software architecture consisting of a general-purpose OS running as the main OS and a TOS running as the trusted OS is a special case of this overall architecture.

[0090] The method can therefore be implemented by next generation devices of industrial controllers, such as PLCs (programmable logic controllers) or any IC communication devices, which will be connected on a single physical bus in conjunction with other telecommunication devices that may be tampered with and controlled by an attacker. In such cases, the implementation of the method is very useful, as it provides a security solution to protect access to critical functions of the IC devices.

[0091] 11 shows a schematic diagram of a computer device DEV according to an embodiment of the present disclosure, comprising a processing unit for implementing the above-described method. The processing unit may comprise a processor PROC and a memory MEM for storing at least instructions of a computer program according to the present disclosure. The computer program may correspond to a low-level layer program of GPOS and TOS according to the secure hybrid architecture. The processor PROC cooperates with the memory MEM to retrieve instructions when a current application is started by the computer device DEV, thereby implementing the above-described method.

Claims

1. 1. A method of securing data processing in a computer arranged according to a hybrid software architecture, said hybrid architecture relying on dual operating systems including a general purpose operating system (GPOS) and a trusted operating system (TOS) performing critical functions; said execution of a current application by said GPOS means accessing at least one primitive to said TOS; The method comprises: the GPOS performing an authentication procedure requiring authentication validation provided by the TOS; authorizing said at least one primitive to access said TOS upon validation of said authentication by at least said TOS; A method comprising:

2. 2. The method of claim 1, wherein the computer program of the current application includes at least one instruction, and wherein the execution of the at least one instruction by the GPOS initiates the at least one primitive that requests access to the TOS.

3. 3. The method of claim 1, wherein upon a request by said at least one primitive to access said TOS, a system call initiates a specific authentication primitive that causes said GPOS to perform said authentication procedure.

4. The method of claim 3 , wherein the initiation of the particular authentication primitive generates a request from the GPOS to access the TOS along with authentication parameters.

5. the GPOS requests the authentication validation from the TOS based on authentication parameters including at least a first set of certificate data; 5. The method of claim 1, wherein the authentication procedure includes a verification by the TOS of the first set of certificate data provided by the GPOS against a second set of certificate data previously stored by the TOS.

6. 6. The method of claim 5, wherein the first set of certificate data includes data of a customer certificate, and the second set of certificate data includes data of a root certificate authority certificate as a trusted certificate stored in a secure memory accessible only by the TOS during an initialization step of configuring the TOS.

7. 7. The method of claim 5 or 6, wherein an application digest is calculated by the GPOS in a preamble step of installing the current application, and a digital signature of the binary code of the current application is generated using the application digest and a private key associated with a public key in the first set of certificate data.

8. the particular authentication primitive initiates, prior to the execution of each current instance of the current application, a request to access the TOS using the generated signature and the first set of certificate data; The GPOS kernel module Obtaining a process identifier "PID" of the current application instance; Obtaining a binary executable file associated with the PID; calculating an application digest of the type generated in the preamble step over the entire binary file; sending a message to the TOS that includes the application digest, the generated signature, and the first set of certificate data; The method of claim 7 when combined with claim 3 or 4, wherein the request is processed by

9. Upon receiving the message, the TOS: verifying the provided first set of certificate data with the second set of certificate data securely stored in the TOS; checking the provided application signature using the application digest and a public key embedded in the first set of certificate data using an asymmetric cryptographic algorithm; signaling by sending to the GPOS an authentication status of success or error depending on the result of the check; The method of claim 8, wherein authentication proceeds by

10. 10. The method of claim 9, wherein the GPOS kernel module stores the authentication state in association with the PID of the current application instance to filter requests initiated by one or more primitives of the current application based on the authentication state.

11. 10. The method of claim 9, wherein the GPOS and the TOS are interconnected through Inter-OS Communication "IOC" mutual interfaces, and each primitive requesting access to the TOS is filtered by the TOS in one of the IOC interfaces using the PID of each current application instance to avoid possible attacks from the GPOS kernel module.

12. 12. The method of claim 11, wherein the TOS returns a single token per current application instance as the result of the authentication request to prevent unauthorized reuse of the token for other current application instances, the token having a value defined by the authentication state.

13. A computer program comprising instructions which, when executed by a processing unit, cause the implementation of the method of any one of claims 1 to 12.

14. A computer program of a current application, the computer program of the current application comprising at least one instruction that is executed when the computer program of the current application is executed, wherein the execution of the at least one instruction by the GPOS initiates at least one primitive that requests access to the TOS, thereby causing the implementation of the authentication procedure of the method of any one of claims 1 to 12.

15. A computer device comprising a processing unit for performing the method according to any one of claims 1 to 12.

Images