A method for secure inter-process communication within a computer's operating system.

Abstract

A method for secure inter-process communication within a computer operating system. The process modules (10, 20) each comprise: a process executable (12, 22) previously signed by asymmetric signature with a public / private key pair; said public key (14, 24); and a module identifier (16, 26). A signature file (30) comprises: the process signatures (32) of all the process modules, a signature of the signature file (36), and a signature of a coordinator component (34). A secure coordinator component (40) controls the exchange of data between the process modules after creating a read / write pipe pair for each process module. The modules and the coordinator component authenticate each other using the signatures stored in the signature file (30).For the interconnection, a requesting module (RM) transmits to the coordinating component (40), via the respective pair of pipes previously created, a message and a module identifier (26) of a target process module (TM) receiving the message. The coordinating component (40) transmits the message to the target process module (TM) via the respective pair of pipes previously created for that target module (TM). (Figure to be published: Figure 1).

Description

Title of the invention: Secure inter-process communication method within the operating system of a computer

[0001] The invention relates to inter-process communication (IPC) within the operating system of the same computer, where the processes communicate locally with each other via pipes allocated by the operating system (hereinafter "OS").

[0002] Here, the term "pipe" should be understood in the sense it has in POSIX / Unix or Windows terminology (registered trademarks), namely communication channels enabling the exchange of data from one process to another. These pipes (or pipelines) can be categorized into anonymous pipes, created at the initiative of one of the processes and which disappear after the completion of the processes, and named pipes, which are linked to the OS and persist after the completion of the processes. Context of the invention

[0003] Computer programs are generally presented in the form of multiple modules, each comprising executable code for a specific process. The modules, which run at different privilege levels, are interdependent and must exchange data with each other within the OS in a perfectly secure manner, which cannot be intercepted or altered by third parties (so-called "man-in-the-middle" or MITM attacks) or unlawfully rerouted by address modification (so-called "spoofing" attacks), etc., or even by so-called "pipe squatting" attacks, which are denial-of-service (DoS) attacks that compromise the OS's inter-process synchronization mechanism when using named pipes, if the pipe identifier is known to the attacker.

[0004] To mitigate these risks, a number of security and authentication measures for exchanges between processes within the OS have been proposed.

[0005] The security of the IPC is ensured when (i) a pipe can only be established if there is only one process on each side of the pipe, (ii) only processes connected to the pipe can access the data flowing in the pipe, (iii) a process on one side of the pipe can identify the process that is on the other side of the pipe, and (iv) the executable that was used to create a process can be determined from its process identifier.

[0006] These security requirements are part of the features typically specified under POSIX or Windows.

[0007] To prevent MITM attacks, each process must identify the process with which it should communicate on the other side of the pipe. For example, for a Windows operating system, a certificate is integrated when the process module is created to allow its subsequent authentication by a WinVerifyTrust command.

[0008] However, these precautionary measures do not guarantee protection against all third-party attack attempts. For example, it would be possible for a third party to replace a recent version of an executable with an older, vulnerable version of the same executable having the same apparent properties, the same process identifier, and the same embedded certificate, thereby circumventing existing protections and rendering the intrusion into the OS undetectable.

[0009] To this end, the invention proposes a method of secure inter-process communication, in which processes communicate with each other within a computer operating system via pipes allocated by the operating system.

[0010] Each process is implemented by a respective process module comprising: - a process executable, previously signed by an asymmetric signing operation with a public / private key pair; - said public key; and - a module identifier,

[0011] The operating system also includes: - a signature file, including: • for each process module, the respective process signature resulting from said asymmetric signing operation of the process executable, • a signature file signature, resulting from a prior asymmetric signing operation of the signature file with said public / private key pair, and • a coordinating component signature; and - a secure coordinating component, capable of communicating with the signature file and with the process modules and of controlling the exchange of data between the process modules.

[0012] The process of the invention comprises the following steps: a) a preliminary initialization step, comprising: al) by the secure coordinator component, the creation of a read / write tube pair for each module; a3) for each module, the connection to the respective pair of tubes created in step a1) and the verification that the connection leads to the secure coordinator component, the secure coordinator component being authenticated from the coordinator component signature of the signature file and the public key embedded in the module; a4) by the secure coordinator component, verification that the connection from step a3) originates from a module authenticated by the respective process signature in the signature file and the public key stored in the secure coordinator component; and b) Upon request from a requesting module: b1) by the requesting module, the transmission to the secure coordinator component, via the respective pair of pipes created in step a1) for the requesting module, of a message and a module identifier of a target process module receiving the message; and b2) by the secure coordinator component, the transmission of the message to the target process module, via the respective pair of pipes created in step a1) for the target module.

[0013] In a preferred implementation, prior to the execution of step a), an initial step is also provided for creating a package comprising all the process modules of a given computer program, comprising successively: - the generation of the respective process executables for all process modules of the program; - the generation of a public / private key pair; - the incorporation of said public key into each of the executables of the process modules and into the secure coordinator component; - for each process module, the performance of an asymmetric signature operation, using said public key / private key pair, of the process module executable incorporating said public key, and of the secure coordinator component, so as to produce a process signature for each process module and a coordinator component signature; and - the creation of a signature file from the process signatures of each process module and the coordinating component signature; - the execution of an asymmetric signature operation, by said public key / private key pair, of the content of the signature file, so as to produce a signature of the signature file; - the storage, in the signature file, of the signature of the signature file; and - the grouping, in the same package, of all the process modules of the program with the corresponding signature file thus obtained.

[0014] The private key is preferably destroyed after execution of all asymmetric signature operations.

[0015] - In the case where the tubes are named tubes, with for each pair of tubes a identifying a pair of tubes that is unique to it, the process advantageously also includes: - at step a1), by the secure coordinator component, the random assignment to each pair of tubes of a respective tube pair identifier, - between steps a1 and a3) a step a2) of registration, by the secure coordinator component, in an operating system registry, of the assigned tube pair identifiers, and - at step a3), querying the registry by the requesting module and obtaining the random tube pair identifier corresponding to the interconnecting tube pair with the module.

[0016] In the case where the tubes are anonymous tubes, and the process advantageously further comprises: - between steps a1 and a3) a step a2) of assigning to the modules of the respective pairs of tubes created in step a1). Brief description of the drawings

[0017] We will now describe an example of implementation of the invention, with reference to the attached drawings where the same references designate identical or functionally similar elements from one figure to another.

[0018] [Fig-1] shows the main functional blocks involved in the implementation of the invention.

[0019] [Fig.2] presents the successive process steps of the preliminary phase of creating a package incorporating all the process modules, the secure coordinator component enabling their interconnection, and the associated signature file.

[0020] [Fig.3] presents the successive process steps of the initial phase of tube creation associated with the various respective process modules.

[0021] [Fig.4] presents the successive process steps leading to the interconnection of two process modules with each other, in accordance with the teachings of the invention.

[0022] Fig. 1 illustrates in the form of functional blocks the different elements interacting together to ensure secure communication between processes of a computer OS.

[0023] It should be noted that the functional elements 10, 20 ... 60 shown in [Fig. 1] are all integral parts of the same OS, so that the invention is implemented completely autonomously within this OS, without connection or exchange with the outside world, and therefore without risk of intrusion or interception by a third party during the implementation of the interconnection, nor dissemination of sensitive information outside the OS and the computer.

[0024] The OS comprises a multitude of different process modules, running at various privilege levels. In [Fig. 1] two of these modules 10, 20 are shown to illustrate the establishment of a connection between processes initiated by a requesting module MR 10, destined for a target module MC 20. But the OS actually comprises a very large number N of such modules Mi ... MN, which will be generally designated M;.

[0025] Each process module incorporates a process executable such as 12, 22 ..., a public key K such as 14, 24, ..., with the same key K for all modules, and a module identifier ID(M;) such as 16, 26, ..., specific to the process module.

[0026] Each process module Mi has been previously signed by an asymmetric signing operation with a public key(K) / private key pair, resulting in a SIG(M;) signature.

[0027] All process module signatures are stored in a signature file FS, referenced 30 on [Fig.1], in respective sections SIG(Mi) ... SIG(Mn), referenced 32.

[0028] To establish interconnections between process modules, it is planned to implement a secure CCS coordinator or orchestrator component, hereinafter "CCS component", referenced 40 on [Fig.1], enabling in particular the authentication and coordination of the system's process modules.

[0029] In concrete terms, the CCS 40 component can be implemented in the same form as a process module, with clean code executable by the OS.

[0030] The CCS component 40 also incorporates the public key K in position 42, and it has also undergone an asymmetric signing operation using the public key(K) / private key pair, resulting in a SIG(CCS) signature. The SIG(CCS) signature of the CCS component is stored in the signature file FS, in position 34.

[0031] Finally, the FS signature file is also signed by the asymmetric signature operation with the public key(K) / private key pair, resulting in a signature file signature SIG(FS), stored in the signature file, in 36.

[0032] The FS signature file is accessed by the CCS component 40. In the case where the interconnection between modules is done via named pipes (as opposed to anonymous pipes), the CCS component also has access to the Registry 50, this Registry being a conventional element of the OS, for example the Windows Registry of the Windows operating system, which contains the configuration data of the OS and which is accessible internally to the different modules of the OS.

[0033] Finally, the CCS component communicates with each of the modules M; by means of pairs of write / read pipes 60, specific to each process module, the modules not being able to communicate directly with each other, but only through the CCS component 40.

[0034] Figure 2 illustrates the successive steps of the process from a preliminary phase 100 of creating a package incorporating all the process modules M;, the CCS component, and the associated FS signature file.

[0035] This method first comprises (block 102), for each of the process modules Mi, the generation of a process executable by compiling the source code and linking. An identifier ID(M;) is then assigned to the module, specific to that module.

[0036] The next step (block 104) consists of creating the module corresponding to the CCS component, with specific code executable by the OS, prior to any interconnection between process modules.

[0037] The next step (block 106) consists of generating a public / private key pair intended to perform the signing operations described below.

[0038] The public key K is written in each of the process modules M; (in 14, 24, ... on the [Fig.l]) as well as in the CCS component (in 42 on the [Fig.l]).

[0039] The next step (block 108) consists of signing the executable of each process module M;, giving a signature SIG(M;), and storing this signature SIG(M;) in the signature file FS (in 32 on the [Fig.l]).

[0040] The next step (block 110) consists of signing the CCS component, resulting in a SIG(CCS) signature. This SIG(CCS) signature is similarly stored in the FS signature file (at position 34 in [Fig. 1]).

[0041] The next step (block 112) consists, once the previous operations have been carried out, of signing the FS signature file, giving a SIG(FS) signature, which is also stored in the signature file (in 36 on the [Fig.l]).

[0042] The next step (block 114), which is an optional but advantageous step from a security point of view, consists of destroying the private key used for the various previous signing operations; indeed, this key will no longer be needed for the rest of the process and can be deleted.

[0043] Finally (step 116) the FS signature file is incorporated into the package, which therefore brings together N modules of the process M;, the CCS module, and the FS signature file associated with all of these modules.

[0044] Figure 3 illustrates the successive process steps of the initial phase 200 of tube creation associated with the various respective process modules Mj.

[0045] This process first includes (block 202) the creation by the CCS component of N pairs of tubes leading to the CCS component, each pair of tubes being intended to connect the CCS component to a respective module M of the previously created package.

[0046] In the case where the tubes are named tubes (block 204), a random identifier is assigned to each of the N pairs of tubes, and this identifier is entered in the OS Register (referenced 50 on [Fig.1]).

[0047] In the case of anonymous tubes (block 206), the Register does not intervene (since the tubes are anonymous) and the pair of tubes created in the previous step 202 is assigned to the corresponding module Mi.

[0048] The following steps (blocks 208 and 210) are repeated for each process module M;.

[0049] In the case of named tubes (step 208) the module M; queries the Register to obtain the identifier of the pair of tubes which was assigned to it previously in step 204, so as to be able to establish a connection of this module M; with the CCS component.

[0050] Then, in all cases (named or anonymous pipes), the Mi module connects to its corresponding pipe pair, queries the FS signature file via the CCS component, and verifies the authenticity of the connection from the M module to the CCS component. This verification is performed using the SIG(CCS) signature read from the FS signature file (itself authenticated by verifying the SIG(FS) signature) and the public key K that had been previously incorporated into the M module.

[0051] In the reverse direction, from the CCS component to the process module M;, the authenticity of the connection is verified by the CCS component, which queries the FS signature file, obtains the SIG(M;) signature of the corresponding module, and verifies this signature from the key K which had been previously incorporated into the CCS component (in 42 on the [Fig.l]).

[0052] Once the pairs of tubes have thus been established and authenticated, the modules will be able to interconnect with each other.

[0053] Figure 4 illustrates the successive steps in the process of this interconnection. 300, established at the initiative of a requesting process module designated MR, which wishes to communicate with a target module, designated MC.

[0054] The first step (block 302) consists, by the requesting module MR, of querying the signature file FS and verifying the signature of the signature file, from SIG(FS) read in this FS file (in 36 on [Fig.l]) and the public key K which had been incorporated into the requesting module (in 14 on [Fig.l]).

[0055] In the case of named tubes (block 304), the requesting MR module queries Register 50 and retrieves the tube pair identifier that had been assigned to it to communicate with the CCS component.

[0056] In the next step (block 306), the requesting module MR opens the pair of tubes to access the CCS component, queries the FS signature file to verify the SIG(CCS) signature of the CCS component contained in this signature file (in 34 on [Fig.l]), from the key K which had been incorporated into the requesting module (in 14 on [Fig.l]).

[0057] The requesting module then transmits to the CCS the ID(MC) identifier of the target module MC with which it wishes to communicate, as well as a certain amount of data constituting a payload intended for this target module MC.

[0058] The next step (block 308) consists, by the CCS, of querying the signature file, verifying the SIG(FS) signature of the latter (in 36 on [Fig.l]) from the public key K which had been incorporated into the CCS component (in 42 on [Fig.l]), then verifying the SIG(MC) signature of the target module MC read in the signature file (in 32 on [Fig.l]), from this same key K which had been incorporated into the CCS component (in 42 on [Fig.l]).

[0059] In the case of named tubes, the CCS component queries Register 50 and retrieves the identifier of the tube pair assigned to the target module MC.

[0060] The CCS component can then open the pair of tubes to access the target module MC, and transmit to the latter the payload communicated by the requesting module, via the pair of tubes leading to the target module MC.

[0061] The two modules, the requesting module MR and the target module MC, can then continue to communicate securely with each other within the OS.

Claims

Demands

1. A secure inter-process communication method, wherein processes communicate with each other within a computer operating system (OS) via pipes (60) allocated by the operating system, wherein each process is implemented by a process module (10, 20,...) each comprising: - a process executable (12, 22), previously signed by an asymmetric signing operation with a public / private key pair; - said public key (14, 24); and - a module identifier (16, 26), in which the operating system (OS) also comprises: - a signature file (30), comprising: • for each process module, the respective process signature (32) resulting from said asymmetric signing operation of the process executable, • a signature file signature (36), resulting from a prior asymmetric signing operation of the signature file with said public / private key pair, and • a coordinator component signature (34); and - a secure coordinator component (40), capable of communicating with the signature file (30) and with the process modules (10, 20,...) and to control the exchange of data between the process modules, the method comprising the following steps: a) a preliminary initialization step, comprising: a1) by the secure coordinator component (40), the creation of a read / write pipe pair for each module (10, 20,...); a3) by each module (10, 20,...), the connection to the respective pipe pair created in step a1) and the verification that the connection leads to the secure coordinator component (40), the secure coordinator component (40) being authenticated from the coordinator component signature (34) of the signature file (30) and the public key (14) incorporated in the module; a4) by the secure coordinator component (40), the verification that the connection of step a3) comes from a module authenticated from. the respective process signature (32) of the signature file (30) and of the public key (14) stored in the secure coordinator component (40); and b) On request from a requesting module (MR): bl) by the requesting module (MR), the transmission to the secure coordinator component (40), via the respective pair of pipes created in step a1a) for the requesting module (MR), of a message and a module identifier (26) of a target process module (MC) recipient of the message; and b2) by the secure coordinator component (40), the transmission of the message to the target process module (MC), via the respective pair of pipes created in step a1a) for the target module (MC).

2. The method of claim 1, wherein it is further provided, prior to the execution of step a), for an initial step of creating a package comprising all the process modules (10, 20,...) of a given computer program, comprising successively: - the generation of the respective process executables of all the process modules (10, 20,...) of the program; - the generation of a public / private key pair; - the incorporation of said public key into each of the executables of the process modules (10, 20,...) and into the secure coordinator component (40); - for each process module (10, 20,...), the performance of an asymmetric signature operation, by said public key / private key pair, of the executable of the process module incorporating said public key, and of the secure coordinator component (40), so as to produce a process signature (32) for each process module and a coordinator component signature (34); and - the creation of a signature file (30) from the process signatures (32) of each process module and the coordinator component signature (34); - the performance of an asymmetric signature operation, by said public key / private key pair, of the contents of the signature file (30), so as to produce a signature of the signature file; - the storage, in the signature file (30), of the signature of the signature file (36); and.

3.

4.

5. - the grouping, in the same package, of all the process modules (10, 20,...) of the program with the corresponding signature file (30) thus obtained. The method of claim 2, wherein the private key is destroyed after execution of all asymmetric signing operations. The method of claim 1, wherein the tubes (60) are named tubes, with each pair of tubes having a unique tube pair identifier, and wherein the method further comprises: - at step a1), by the secure coordinator component (40), the random assignment to each pair of tubes of a respective tube pair identifier, - between steps a1a and a3) a step a2) of registration, by the secure coordinator component (40), in a registry (50) of the operating system (OS), of the assigned tube pair identifiers, and - at step a3), querying the register database (50) by the requesting module and obtaining the random tube pair identifier corresponding to the interconnecting tube pair with the module. The method of claim 1, wherein the tubes (60) are anonymous tubes, and wherein the method further comprises: - between steps a1 and a3) a step a2) of assigning to the modules of the respective pairs of tubes created in step a1).

Images