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

Abstract

The present specification relates to a method of securing data processing in a computer arranged according to a hybrid software architecture. The auxiliary hybrid architecture relies on a dual operating system including a trusted operating system "TOS" running critical functions and a general operating system "GPOS". The execution of the current application by the GPOS inevitably includes the access of at least one primitive to the TOS. The method includes implementing, by the GPOS, an authentication process that requires authentication confirmation granted by the TOS, and authorizing the at least one primitive to access the TOS at least upon authentication confirmation by the TOS.

Description

Technical Field

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

[0002] An example of data exchange between processors can be observed in a multicore microprocessor unit (MPU). A modern MPU provides several execution cores, each reading and executing program instructions as if the computer had multiple processors. Cores may or may not share caches, and they can implement message passing or shared memory inter-core communication methods. Typically, each core has an L1 cache, but they share an L2 cache. Heterogeneous multicore systems include only identical cores; heterogeneous multicore systems have different cores.

[0003] Requires a specific interrupt controller (in) The processor uses a global interrupt controller (called the global interrupt controller) to provide interrupt routing between cores and inter-processor interrupts.

[0004] RAM (Random Access Memory) and peripheral devices (such as UART (Universal Asynchronous Receiver Transmitter) and / or network interfaces) are shared among different cores of the Central Processing Unit (CPU). Therefore, memory or device bottlenecks may occur when several cores access the same resources simultaneously.

[0005] The following describes the hardware security mechanisms available in ARM and x86 processors and their uses in implementing Trusted Execution Environments (TEEs).

[0006] ARM processors with a TrustZone implement an architectural security extension that provides two virtual cores per physical processor core:

[0007] - A virtual core is considered insecure and has been called "unsettling the whole world," and

[0008] - Another virtual core is considered secure and is referred to as the "Secure World".

[0009] The mechanism for switching contexts between the two is known as "monitoring mode".

[0010] The world the processor is currently running in can be determined by the insecure bits available in the hardware security configuration register. The physical processor can enter monitor mode from the insecure world by executing a special instruction called a "Secure Monitor Call" (SMC), and this can be considered an exception to monitor mode software. Furthermore, main memory is also marked with insecure bits, allowing memory isolation between the secure and insecure worlds.

[0011] Security models implemented using trust zone technology provide additional partitions by separating the secure world from the ordinary world, thereby allowing solutions such as DRM (“Digital Rights Management”) to be protected from hostile environments, such as infected systems on both the user land and the kernel land.

[0012] Intel Software Protection Extensions (Intel SGX) provides hardware-based memory encryption that isolates specific application code and data within 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.

[0013] ARM Trust Zones and Intel SGX are intensively used to implement Trusted Execution Environments (TEEs), particularly in embedded devices such as smartphones. A Trusted Execution Environment (TEE) is an isolated execution environment that provides security features such as isolated execution, the integrity of applications running within the TEE, and the confidentiality of their assets. Generally, a TEE provides an execution space that runs in parallel with a normal operating system and offers 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. Trusted applications running in a TEE have full access to the device's main processor and memory, while hardware isolation protects these components from user-installed applications running on the main operating system. Software and cryptographic isolation within the TEE protects the different trusted applications contained within from each other. This architecture... Figure 1 As shown in the image.

[0014] On REEs such as Linux, the TEE kernel driver handles the details required for communication with the TEE. On ARM trust zones, the lowest-level communication with OP-TEE (“Open Portable TEE”) is based on the ARM SMC Calling Convention (SMCCC), which is the basis for the SMC interface of the TEE used internally by the driver (the SMC for “Security Monitoring Calls”).

[0015] Kernel TEE subsystem processing:

[0016] • TEE driver registration

[0017] • Manage shared storage between Linux and TEE

[0018] • Provide a common API (Application Programming Interface) to the TEE.

[0019] TEE applications and components rely on an internal API known as the TEE Internal Core API, while the TEE Client API describes how client applications running in the REE communicate with the TEE. The API uses a generic TEE API, which relies on file descriptors and ioctl (“input-output control”) access to the kernel driver using standard POSIX communication methods (IEEE 1003), such as... Figure 2 As shown.

[0020] In hybrid software architectures, as disclosed, for example, in document EP3872634, attempts are made to address the coexistence of services and applications with heterogeneous network QoS (Quality of Service) requirements, security constraints, and implementation complexity on a single processor. In practice, within a single system, some applications may have strong real-time constraints as described in the preceding sections, meaning they cannot support latency greater than a few microseconds when network events occur (e.g., message reception). Such applications are not very complex and are typically implemented on a trusted operating system (hereinafter referred to as "TOS") that typically operates in real-time to guarantee very low latency. However, the system should also support much more complex applications that do not have real-time requirements or have soft real-time capabilities. These applications may require frequent updates, can be extended by software plugins, and include many user functions. They are typically implemented on general-purpose OSes. The following application requirements cannot be met by the exclusive use of some common general-purpose OSes (such as Linux, VxWorks). For example, the operating system of a modern industrial communication platform must support different capabilities:

[0021] • Control network latency

[0022] • Various security measures to prevent attacks

[0023] • Support for complex applications / multi-protocol stacks

[0024] • Considering the flexibility and reduced costs of the development process (software running on a general-purpose OS).

[0025] • Integration and control of hardware Ethernet interfaces with heterogeneous capabilities.

[0026] The hybrid software architecture relies on a dual OS monitor (playing the same role as the super monitor in software virtualization) designed to run both TOS or BareMetal (BM) applications and GPOS (General Purpose Operating System) on the same core. The hybrid software architecture leverages ARM's Trust Zone security extension to run each OS under different security states.

[0027] The main characteristics of hybrid software are:

[0028] • Allows TOS and GPOS to run simultaneously on the same processor.

[0029] • Protects TOS memory and devices from unauthorized access by GPOS. This is supported by configuring the resources used by TOS to be accessible only based on trust status. Remaining resources are configured to be accessible based on trust and non-trust status.

[0030] • TOS real-time requirements are guaranteed. Time isolation of TOS activities is supported by carefully allocating two types of interrupts (i.e., FIQ (Fast Interrupt Request) and IRQ (Interrupt Request with Relative Normal Priority)) to each trust zone state.

[0031] The security outage was forwarded to the TOS.

[0032] • The insecure interruption was forwarded to GPOS.

[0033] When the kernel is running both TOS and GPOS, the following rules are applied to interrupt management:

[0034] • In safe mode (TOS running), unsafe interrupts are disabled, preventing GPOS from interrupting the execution of TOS.

[0035] Therefore, GPOS only executes upon explicit request from the TOS. This is achieved through the Secure Monitor Call (SMC) instruction.

[0036] • In an insecure state (GPOS operation), both secure and insecure interrupts are enabled, allowing the TOS to regain control of the processor. The trust zone is configured to prevent the insecure side from disabling secure interrupts. Due to this policy, the real-time constraints of the TOS are guaranteed, and malicious code cannot modify the platform's security configuration.

[0037] When all cores are dedicated to TOS, this strategy is no longer needed and can be applied without any impact. On this core, TOS will never relinquish control to GPOS.

[0038] On multi-core systems, the monitor code is shared across all cores, but except during initialization, the monitor's execution is independent of the core. System calls and notifiers always execute on the same core where they are triggered.

[0039] In this architecture, memory regions and peripheral devices have access permissions, allowing the definition of dedicated regions and peripheral devices managed specifically by each OS.

[0040] Use access permissions to define private memory for each operating system, which other operating systems cannot access. For example... Figure 4 As shown, an OS running in the insecure part of the system (GPOS) cannot access memory used by an OS running in the secure part. Shared memory is available for communication between different OSes, which can host FIFOs and data structures used to implement some communication mechanisms. Hardware mechanisms such as interrupts can also be used to notify one OS of an event from another.

[0041] This specification seeks a secure method for communication between a first OS running in an untrusted / insecure part (such as a rich execution environment or a general-purpose OS) and a second OS running in a trusted execution environment (TEE) (such as a TOS).

[0042] In practice, the OS running in the trusted part can provide some critical and secure services to the OS running in the insecure part through the original definition of the communication path opened between the untrusted OS and the trusted OS (hereinafter referred to as "inter-OS communication" or "IOC"). For example, when applied to industrial automation (IA) communication systems, the trusted OS can provide primitives and services responsible for controlling the state (start / stop / pause) of the running automation.

[0043] Therefore, there is a need to protect applications running on untrusted OSs from accessing those critical primitives.

[0044] Because platforms running on such a software architecture may be located in open environments, untrusted operating systems can be compromised, and an attacker could attempt to execute malicious requests using key primitives (see [link to relevant documentation]). Figure 5 Some applications of this technology. For example, an attacker can impersonate a certified application, such as a Guide User Interface (GUI) application responsible for stopping / starting automata, and send requests with malicious parameters, forcing the trusted OS to execute malicious requests, such as... Figure 5As shown. On the GPOS side, applications can send requests to the TOS service using a specific file descriptor associated with the IOC device driver. The GPOS kernel transmits such requests using the IOC device driver, which is responsible for managing the IOC (software) interface.

[0045] Therefore, in an open environment, it is necessary to protect access to critical requests so that only a set of authorized applications can execute such requests.

[0046] The solution to this problem may primarily lie in adding mechanisms to GPOS to support access control security policies, including mandatory access control at both the kernel and user space levels. For example, SELinux is a set of kernel modifications and user space tools already added to various Linux distributions.

[0047] The Linux kernel with integrated SELinux implements a strict access control policy that restricts user programs and system services, as well as access to files and network resources. Limiting privileges to the minimum necessary for operation reduces or eliminates the ability of these programs and daemons to cause damage in the event of failure or corruption (e.g., via buffer overflows or misconfigurations). This restriction mechanism operates independently of traditional Linux (arbitrary) access control mechanisms. It does not have the concept of a "root" superuser and does not share the well-known drawbacks of traditional Linux security mechanisms, such as reliance on setuid / setgid binaries (for setting the owner user ID / setting the group ID).

[0048] Therefore, SELinux can potentially control the system by allowing each user, process, and daemon to have very precisely defined activities. It is used to restrict daemons, such as those in database engines or web servers with well-defined data access and activity permissions. This limits potential harm from a compromised, restricted daemon.

[0049] However, when the system is highly compromised, SELinux does not protect access to certain resources. This means that an attacker has gained higher privileges and can access any file descriptor defined in GPOS, especially those used to send requests to the trusted OS.

[0050] Therefore, a highly secure method is needed to authenticate applications running on untrusted OS and filter requests, enabling only authorized applications to send requests to a trusted OS, allowing the trusted OS to trust the source of the request and execute it securely.

[0051] This instruction manual is intended to improve this situation. Summary of the Invention

[0052] To this end, it proposes a method for secure data processing in computers deployed according to a hybrid software architecture that relies on a dual operating system comprising a trusted operating system "TOS" running critical functions and a general-purpose operating system "GPOS".

[0053] The execution of the current application by GPOS necessarily involves at least one primitive access to TOS.

[0054] The method includes:

[0055] - The authentication process, which requires authentication confirmation granted by the TOS, is implemented by the GPOS, and

[0056] - At least when the TOS confirms the authentication, the at least one primitive is authorized to access the TOS.

[0057] Therefore, GPOS is typically programmed to initiate the authentication process when the execution of instructions of the computer program currently being used causes a primitive to request access to TOS, and TOS is programmed to check the authentication parameters provided by GPOS when GPOS implements the authentication process.

[0058] Therefore, in one embodiment, the computer program of the current application may include at least one instruction, the execution of which by GPOS initiates at least one primitive request for access to the TOS. This may be a specific feature of the computer program of the current application, thus having instructions that enable the authentication process, for example, when such instructions are executed at the start of the execution of the computer program of the current application. In this case, only the authenticated application can be executed by a computer having such a hybrid architecture protected according to this specification.

[0059] In one implementation, when the at least one primitive requests access to the TOS, a system call initiates a specific authentication primitive (hereinafter referred to as the "IOC" primitive) to enable GPOS to perform the authentication process.

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

[0061] In this implementation, the activation of the aforementioned specific authentication primitive generates a request to access the TOS from the GPOS, the request having authentication parameters that will be confirmed by the TOS.

[0062] More generally, when GPOS requests the authentication confirmation from TOS, GPOS provides TOS with authentication parameters including at least a first set of certificate data, and the authentication process includes TOS performing verification of the first set of certificate data provided by GPOS against a second set of certificate data previously stored by TOS.

[0063] For example, the first set of certificate data may include customer certificate data, and the second set of certificate data may include root certification authority certificate data stored in a secure storage accessible only by the TOS as a trusted certificate. This storage can be performed during the initialization steps of configuring the TOS.

[0064] This initialization step can typically correspond to the installation of the TOS, or to updating a pre-existing TOS with authentication data.

[0065] In one implementation, during the preamble step of installing the current application, GPOS calculates an application digest and uses the application digest and a private key associated with the public key to generate a digital signature of the binary code of the current application, the data of which is in the first set of certificate data.

[0066] The application digest (e.g., hash) and digital signature are computed to ensure that the primitives requesting access are initiated from the correct application execution for the TOS. Furthermore, this data is signed with the correct key; otherwise, the TOS will reject the access request.

[0067] In one implementation, the specific authentication primitive (hereinafter labeled "IOC_CtrlReq_AppAuth") initiates a request to access the TOS using the generated signature and the first set of certificate data before executing each current instance of the current application. The GPOS kernel module then processes the request as follows:

[0068] - Obtain the process identifier "PID" of the current application instance.

[0069] - Obtain the binary executable file appended to the PID.

[0070] - Calculate the application digest on the binary file of the type of application digest generated in the preparatory step, and

[0071] - Send a message to TOS containing the application digest, the generated signature, and the first set of certificate data (hereinafter labeled "IOC_IOCTL_CMD_AUTH").

[0072] The aforementioned kernel module can be viewed as a program loaded into the GPOS kernel, acting as a driver for communication with TOS.

[0073] In this implementation, upon receiving a message, the TOS performs authentication as follows:

[0074] - Compare the provided first set of certificate data with the second set of certificate data securely stored in the TOS.

[0075] - Using an asymmetric encryption algorithm, the provided application signature is checked using the application digest and the public key embedded in the first set of certificate data.

[0076] - Based on the results of the inspection, a signal is sent to GPOS indicating a successful or incorrect authentication status.

[0077] In a first implementation, the GPOS kernel module stores the authentication status 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 authentication status.

[0078] In the second embodiment, GPOS and TOS are interconnected via an inter-OS communication "IOC" interface. Each primitive requesting access to TOS is filtered by TOS at one of the IOC interfaces using the PID of each current application instance in order to avoid potential attacks from the GPOS kernel module.

[0079] Typically, as a result of the authentication request, TOS can return a single token for each current application instance, the token having a value defined by the authentication status, in order to prevent the token from being fraudulently reused for other current application instances.

[0080] This specification also aims at a computer program comprising instructions that, when executed by a processing unit, cause the implementation of the method according to any one of the preceding claims.

[0081] Typically, a computer program may include instructions that can be shared among the following:

[0082] - The GPOS used to identify the primitives requesting access to the TOS and to initiate the authentication process, and

[0083] - Check the TOS of the authentication parameters provided by GPOS.

[0084] This specification also aims at a computer program currently in use, which includes at least one instruction that executes when the computer program currently in use is run, and whose execution by GPOS initiates at least one primitive request to access the TOS, thereby enabling the authentication process of the above-described method.

[0085] Typically, the instruction can be executed once the current application is launched (i.e., once its program begins running). In this case, as described above, the aforementioned current application may correspond to an authorized application that is therefore authorized to be executed by a computer with a hybrid architecture protected according to this specification.

[0086] Furthermore, this specification also aims at a computer device including a processing unit to implement the methods as defined above (therefore corresponding to the aforementioned computer having a hybrid architecture protected according to this specification).

[0087] See the accompanying drawings for further details in the following instructions. Attached Figure Description

[0088] [ Figure 1 ]

[0089] Figure 1 The hardware separation between the Trusted Execution Environment (TEE) and the Rich Operating Environment (REE) is illustrated schematically.

[0090] [ Figure 2 ]

[0091] Figure 2 This schematically illustrates a generic TEE API for accessing kernel drivers that rely on ioctl.

[0092] [ Figure 3 ]

[0093] Figure 3 This schematically illustrates a hybrid software architecture that relies on a dual-OS monitor to concurrently execute TOS or BareMetal (BM) applications and GPOS (General Operating System) on the same core.

[0094] [ Figure 4 ]

[0095] Figure 4 The illustration schematically shows an operating system running in the secure portion and the insecure portion (GPOS) respectively, and not having access to the same memory used by the OS.

[0096] [ Figure 5 ]

[0097] Figure 5 The diagram illustrates the mechanisms of potential attacks on a platform running a hybrid software architecture.

[0098] [ Figure 6 ]

[0099] Figure 6 The encryption and decryption of shared messages are illustrated schematically.

[0100] [ Figure 7 ]

[0101] Figure 7 The illustration schematically depicts a typical public-key infrastructure (PKI).

[0102] [ Figure 8 ]

[0103] Figure 8 The principle of the authentication process is illustrated schematically for a specific TOS task in the trusted part that relies on the IOC primitive of the normal group and needs to be responsible for confirming the authentication.

[0104] [ Figure 9 ]

[0105] Figure 9 The main steps #1 to #5 of the method according to the first embodiment of this specification are schematically shown.

[0106] [ Figure 10 ]

[0107] Figure 10 The main steps #1 to #6 according to the second embodiment are schematically shown.

[0108] [ Figure 11 ]

[0109] Figure 11 The structure of an apparatus for performing the method according to an exemplary embodiment is illustrated schematically. Detailed Implementation

[0110] Within the context of a system environment with a trusted OS, a security method is subsequently proposed to filter access to some key primitives provided by the trusted OS services. These primitives can be divided into two groups (normal and secure). This method authenticates applications that can make requests to the trusted OS and filters access based on the calling application, request type, and authentication result.

[0111] Two implementations of this method are presented below 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 implementation can be considered an extension of the first implementation, allowing for stronger security because it specifically relies on mechanisms operating within the perimeter of a trusted OS.

[0112] The authentication process employs cryptographic mechanisms: digital signatures using asymmetric cryptography, public-key certificate chains, and a public-key infrastructure for key distribution / revocation. These principles are applied here to a computer system running on a hybrid software architecture. Unlike existing solutions, this approach requires no modifications to the GPOS file system. Only the application must be specifically designed to support the proposed authentication mechanism, and certain specific steps will be implemented when the application is deployed in the runtime environment.

[0113] Before detailing the two implementation methods described above, the principle of using digital signatures will be reiterated below. A digital signature is a mathematical scheme used to verify the authenticity of a digital message or document. Under certain preconditions, a valid digital signature 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 during transmission (integrity).

[0114] exist Figure 6 In the example, the message is digitally signed with Alice's private key, but the message itself is not encrypted. Alice signs the message with her private key. Using Alice's public key, Bob can verify that Alice sent the message and that the message has not been modified.

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

[0116] A 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 hash and encryption algorithm is usually indicated within the certificate.

[0117] exist Figure 7 In the typical Public Key Infrastructure (PKI) scheme illustrated, the certificate issuer is a Certificate Authority (CA), typically a trusted third-party company that charges clients for issuing certificates for them. In contrast, a self-signed certificate is a certificate with a subject matching its issuer and a signature that can be verified using its own public key. Therefore, the signature of a self-signed certificate is generated using the private key corresponding to the public key embedded in the certificate.

[0118] In the context of this specification, the primitives provided to user-space applications by the IOC interface are divided into two categories:

[0119] - Normal, and

[0120] -Safe.

[0121] Normal primitives can be invoked without any valid application authentication, while security primitives require valid authentication. This means that an application must initiate an authentication process immediately after starting up and opening an IOC session.

[0122] This authentication process relies on the IOC primitives of the normal group. It needs to be responsible for specific TOS tasks (in the trusted part) of the authentication process, such as... Figure 8 As shown.

[0123] In the two implementations below, the application executable binary is signed, as described in detail below. Instead of signing the entire binary executable, the authentication process involves signing only a pre-computed application digest on the complete application binary code. This process allows for a reduction in the amount of data exchanged through the IOC interface, thus improving efficiency. This method requires a certificate from a user, hereinafter referred to as a "client certificate" (a certificate of a natural person or client application), which can be generated by the client itself or by a trusted third party called a Certificate Authority (CA) when using PKI. For security purposes, the validity check of this client certificate must be performed by a Trusted OS (TOS). This operation uses trusted certificates, which can be self-generated certificates, CA root certificates, or intermediate certificates, securely stored in memory accessible only to the Trusted OS to prevent corruption (typically within a trusted zone). Figure 1 (The memory is presented in the right-hand portion).

[0124] In the following text, it is assumed that the proposed method is applied to a control API implemented as POSIX ioctl. This API uses user-space file descriptors and generates system calls (“syscalls”) to the kernel (such as the Linux kernel, which is similar to POSIX ioctl). The API defines IOC primitives to support request execution and also authenticates the applications using the API.

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

[0126] Assuming the GPOS kernel cannot be compromised by an attacker. Due to high-privilege access, only the filesystem is fully accessible, thus allowing an attacker to access user-space resources associated with the IOC interface (e.g., file descriptors). Therefore, it can be assumed that the kernel-level IOC driver is secure and cannot be compromised (or at least an attack can be detected). Consequently, an attacker cannot inject data / modify code within the code.

[0127] refer to Figure 9 According to this first embodiment, when the intention is to execute the current application in a hybrid architecture, the method includes the following steps:

[0128] Step #0: First, store the root certification authority certificate (RAC) data in the secure storage of the Trusted Area (TOS) (e.g., from a secure chip card or dongle or a secure connection to a remote server). This RAC data allows verification of the client certificate issued by the certification authority that initiated the client certificate. For computers with a hybrid architecture, perform step #0 once.

[0129] Step #1: First, an application digest (e.g., a hash, such as SHA256) is calculated on the file, and then a digital application signature is calculated using the application digest and the client's private key. This step is typically performed by the client's remote computer before deploying the current application and preparing the file system image. The client certificate (including the public key associated with the client's private key) is also installed and stored in GPOS (GrossPOS). Figure 1 The left-hand portion of the "untrusted zone" is accessible in memory containing the current application's binary code and the generated application signature. Therefore, the GPOS kernel can provide the client's certificate whenever access to the TOS is requested during the implementation of the current step #2, detailed below. Conversely, step #1 is performed only once when the current application is deployed / installed.

[0130] Step #2: To execute the current application (when at least one security primitive is deemed to be requesting access to the TOS), a system call initiates the specific IOC primitive IOC_CtrlReq_AppAuth, which is defined to participate in the authentication of the current application. It's important to note that a "primitive" function (here simply called a "primitive") refers to basic functionality provided by the first-level software layer, i.e., solely above the computer's hardware architecture (primitives are typically provided by programming interfaces). This specific IOC primitive is initiated by a system call handled by the GPOS kernel itself, based on system instructions rather than specific instructions of the current application (although application instructions can trigger system instructions).

[0131] Step #2 is executed each time the current application begins a session (actually, when the current application starts). This specific authentication primitive (ICO) generates a request with the current application's signature and the client's certificate as parameters. The IOC kernel module handles the system call and performs the following operations:

[0132] • Obtain the process identifier (PID) that identifies the current instance of the application.

[0133] • Obtain the binary executable file appended to that PID (e.g., using the Linux kernel's procfs and filp_open).

[0134] • Calculate the application digest on this binary file using the same method as in step #1.

[0135] • Send an IOC_IOCTL_CMD_AUTH message containing the application digest, application signature, and client certificate to the TOS IOC driver through the IOC interface.

[0136] Step #3: Upon receiving this message, the TOS IOC authentication task will:

[0137] • Examine the provided application certificate using the root certification authority certificate (RAC) previously stored in the secure storage.

[0138] • Use the client's public key embedded in the verified certificate and the application digest to verify the provided application signature.

[0139] Depending on the result of the previous operation, a success or error will be returned to GPOS.

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

[0141] Step #4: The current application instance executes one or more primitives classified as secure. Before forwarding the requested content from the secure primitive to the TOS in Step #5, the GPOS kernel filters the request by checking the authentication status associated with the current instance's PID.

[0142] Step #5: The GPOS kernel forwards the security request (if unfiltered) to the TOS to continue executing the current application.

[0143] This solution is secure because it can be reasonably assumed that an attacker cannot modify the value of the authentication status returned to the kernel (and can be stored in kernel memory). However, this assumption may be weak if an attacker can exploit read / write access to map kernel memory into user space. Then, by modifying the value of that variable, an attacker might be able to execute requests that require application authentication.

[0144] Except that once the Trusted OS (TOS) determines the authentication status for the current instance of the application (after steps #2 and #3), the GPOS kernel module is no longer responsible for filtering incoming requests from the application, the method according to the second implementation is still similar to the first implementation presented above. In this solution, the Trusted OS (TOS) is entirely responsible for directly filtering requests from primitives to access the TOS. If the authentication status is "successful," the message IOC_IOCTL_CMD_AUTH and the primitive IOC_CtrlReq_AppAuth now return the authentication token directly to the current instance of the application. If the authentication status is "failed," an "empty" token (which is an invalid token) is returned. For this purpose, the token value associated with the PID of the current application instance is stored in the TOS memory.

[0145] Then, in step #4, the application uses the token value as an additional parameter for each further request of the security primitive (named IOC_Ctrl_Req_SecXXX).

[0146] In step #5, the kernel module passes the authentication token and the PID of the current application instance as parameters for any IOC_IOCTL_CMD_SECXXX messages via the IOC interface. Then, for each request from the security primitive, TOS executes... Figure 10 The request carried in step #6, as shown, checks the validity of the token beforehand. The TOS can compare the token value stored in its secure memory with the token value presented in the message. Therefore, the TOS can typically discard requests from security primitives presented in messages with invalid tokens in their parameters. An invalid token can be an "empty" token as described above (due to authentication failure) or any other invalid token, such as a previously used token value (e.g., for a previous instance), to prevent replay attacks. These additional steps require minimal computational and memory resources on the TOS side but fully ensure the filtering process. The PID is passed to the TOS by the kernel module, making it resistant to PID hijacking attacks. In such attacks, a malicious application steals a valid token from an application that has successfully completed the authentication steps. The PID is determined by the kernel code, so it is important that the kernel binary is not modified, or at least that the TOS can detect any changes by performing periodic code checks.

[0147] Compared to the first embodiment described above, the kernel module in this second embodiment does not store any critical data in a private context associated with the file descriptor passed in the driver call function. Therefore, an attacker cannot modify the values ​​of variables by mapping kernel memory into user space, thereby allowing requests requiring application authentication to be executed.

[0148] Currently, regarding the signing of binary code, signature generation / verification can rely on the use of asymmetric cryptography (private / public key). Two schemes can be proposed:

[0149] - The first option can be fully managed by the customer, but may require a security TOS to be set up by the customer before deployment.

[0150] - The second approach can rely on the use of root certificates and can be deployed without any TOS settings (factory configuration can be sufficient).

[0151] Under the first scheme (without PKI), the customer can generate their own private / public key pair. The private key must be securely stored (typically off-platform) and used to sign the application runtime binary. 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 verify the signature.

[0152] Under the second scheme (with PKI), the client can generate a private / public key pair, but the private key is securely stored by the client and used to sign the application runtime binary. The root certificate authority (CA) certificate is securely stored in a trusted domain (TOS). The aforementioned certificate authority can be the manufacturer (i.e., the provider of the authentication means) or any trusted third-party company.

[0153] The client can send its public key to the issuer (CA) that will generate the client certificate, which includes:

[0154] -Certificate information (customer information, issuer information, certification expiration date, etc.)

[0155] -Client public key, and

[0156] - The certificate signature is generated using the root CA's private key, as described above.

[0157] In another implementation, some intermediate certificates can be generated by the CA. A signature for the client certificate can be generated using the private key associated with one of the intermediate certificates. The intermediate certificate should be uploaded to the TOS using a specific ICC IOTCL command. After upload, the TOS checks the validity of the provided certificate compared to the stored root CA certificate. The main benefit of this method is that the CA avoids frequent use of the root CA, thereby limiting its exposure to potential attackers. It is also more flexible, especially when some certificates must be revoked.

[0158] 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 a CA before their scheduled expiry date and should no longer be trusted. CRLs can be stored by the TOS and should be updated using specific ICC IOTCL commands. To prevent attackers from sending CRL lists and triggering denial-of-service attacks due to fake certificates, primitives related to certificate management must be categorized into security groups.

[0159] A computer program having an algorithm that follows the steps of the method presented above as a possible implementation can be deployed in any type of product using an embedded platform running a host operating system with a trusted execution environment for performing secure operations and requests issued by applications running on the host OS. A hybrid software architecture consisting of a general-purpose OS running as the host OS and a trusted operating system (TOS) is a specific case of this overall architecture.

[0160] Therefore, this method can be implemented by next-generation devices such as industrial controllers (PLCs, programmable logic controllers) or any IC communication device. They should be connected on a single physical bus, interspersed with other telecommunications devices that could be compromised and controlled by attackers. Thus, this method is highly useful because it provides a security solution to protect access to the critical functions of the IC device.

[0161] Figure 11 A computer device DEV according to an embodiment of this specification is schematically illustrated, including a processing unit for implementing the methods described above. The processing unit may include a processor PROC and a memory MEM storing at least the instructions of a computer program according to this specification. This computer program may correspond to a low-level program based on a secure hybrid architecture GPOS and TOS. When the computer device DEV starts the current application, the processor PROC may cooperate with the memory MEM to read the instructions and thus implement the methods described above.

Claims

1. A method for protecting data processing in a computer deployed according to a hybrid software architecture, the hybrid architecture relying on dual operating systems, the dual operating systems comprising a trusted operating system "TOS" running critical functions and a general-purpose operating system "GPOS". The execution of the current application by the GPOS necessarily involves at least one primitive access to the TOS. in, The method includes the following steps: - The authentication process, which requires authentication confirmation granted by the TOS, is implemented by the GPOS, and - At least after the TOS confirms the authentication, the at least one primitive is authorized to access the TOS.

2. The method according to claim 1, wherein, The computer program of the current application includes at least one instruction, which is executed by the GPOS to initiate at least one primitive request to access the TOS.

3. The method according to claim 1 or 2, wherein, When at least one primitive requests access to the TOS, a system call initiates a specific authentication primitive, enabling the GPOS to perform the authentication process.

4. The method according to claim 3, wherein, The activation of the specific authentication primitive generates a request from the GPOS to access the TOS using authentication parameters.

5. The method according to any one of the preceding claims, wherein, The GPOS requests the authentication confirmation from the TOS based on authentication parameters that include at least a first set of certificate data, and the authentication process includes the TOS performing verification of the first set of certificate data provided by the GPOS against a second set of certificate data previously stored by the TOS.

6. The method according to claim 5, wherein, The first set of certificate data includes customer certificate data, and the second set of certificate data includes root certification authority certificate data, which is stored as a trusted certificate in a secure storage that can only be accessed by the TOS during the initialization step of configuring the TOS.

7. The method according to claim 5 or 6, wherein, In the preparatory steps of installing the current application, the GPOS calculates an application digest and uses the application digest and a private key associated with the public key to generate a digital signature of the binary code of the current application, wherein the data of the public key is in the first set of certificate data.

8. The method according to claim 7 combined with claim 3 or 4, wherein, Before executing each current instance of the current application, the specific authentication primitive initiates a request to access the TOS using the generated signature and the first set of certificate data, wherein the GPOS kernel module processes the request as follows: - Obtain the process identifier "PID" of the current application instance. - Obtain the binary executable file appended to the PID. - Calculate an application digest for the binary file, wherein the application digest is of the same type as the application digest generated in the preparatory step, and - Send a message to the TOS containing the application digest, the generated signature, and the first set of certificate data.

9. The method according to claim 8, wherein, Upon receiving the message, the TOS authenticates itself by: - Compare the provided first set of certificate data with the second set of certificate data securely stored in the TOS. - Using an asymmetric encryption algorithm, the provided application signature is checked using the application digest and the public key embedded in the first set of certificate data. - Based on the results of the inspection, a signal is sent to the GPOS indicating a successful or incorrect authentication status.

10. The method according to claim 9, wherein, The GPOS kernel module stores the authentication status 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 authentication status.

11. The method according to claim 9, wherein, The GPOS and TOS are interconnected via an inter-OS communication "IOC" interface, wherein each primitive requesting access to the TOS is filtered by the TOS at one of the IOC interfaces using the PID of each current application instance, thereby avoiding potential attacks from the GPOS kernel module.

12. The method according to claim 11, wherein, The TOS returns a single token as a result of the authentication request for each current application instance. The token has a value defined by the authentication status to prevent other current application instances from fraudulently reusing the token.

13. A computer program comprising instructions that, when executed by a processing unit, cause the implementation of the method according to any one of the preceding claims.

14. A currently applied computer program, the computer program comprising at least one instruction executed during the execution of the currently applied computer program, and the GPOS executing the at least one instruction to initiate at least one primitive request to access the TOS, thereby enabling the authentication process of the method according to any one of claims 1 to 12 to be implemented.

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

Images