Securing a file system on a remote autonomous system

Abstract

Securing a file system of a remote autonomous system The invention relates to a device for securing a file system of a remote autonomous system (10) using an operating system (18) associated with said file system having a dual partition allowing A / B updates, said remote autonomous system being updated by atomic update, and further comprising a secure boot tool (22), said security device being configured to sign said file system using two-key asymmetric cryptography comprising a public key and a private key, the public key being integrated into the kernel of said operating system, the lifetime of said private key being limited, said two public and private keys being regenerated by said security device at each production of a new atomic update of said remote autonomous system.Figure for the abbreviation: Figure 1.

Description

Title of the invention: Securing a file system of a remote autonomous system

[0001] The present invention relates to a device for securing a file system of a remote autonomous system, said remote autonomous system using an operating system associated with said file system of said remote autonomous system, the remote autonomous system further using a double file system partition allowing A / B updates, said remote autonomous system being further capable of being updated by atomic update, the remote autonomous system further comprising a secure boot tool.

[0002] The present invention also relates to such a remote autonomous system, said remote autonomous system using an operating system associated with said file system of said remote autonomous system, the remote autonomous system further using a double file system partition allowing A / B updates, said remote autonomous system being further capable of being updated by atomic update, the remote autonomous system further comprising a secure boot tool.

[0003] The invention also relates to a method for securing a file system of such a remote autonomous system.

[0004] The invention also relates to a computer program associated with said method.

[0005] The invention lies in the field of autonomous systems using at least one operating system (OS), for example the Linux operating system, and which are administered remotely (Over The Air).

[0006] Such remote administration requires the ability to atomically manage updates to such a remote autonomous system whose file system, also called rootfs, is, in order to control updates, commonly of type A / B, i.e. comprising two file systems A and B, alternately active. More precisely, if file system A is active then the update will be done on file system B, and vice versa). Once the update is done, the system restarts and switches to file system B. If the update is defective, the system can return to the old version, namely file system A, still available. The active file system is read-only and no partial update is possible in order to guarantee proper operation after an update.Persistent data, for example configuration data, is stored on a partition, dedicated if necessary, of the media corresponding to the physical storage medium (eg hard disk, flash memory, eMMC (from the English Embedded . MultiMediaCard. The media is formatted with multiple partitions, each containing a file system.

[0007] Furthermore, such an atomic update consists of updating in one go both the kernel of the operating system, hereinafter called kernel, and jointly the file system, and this on the same partition of the media (i.e. the remote autonomous system). This pair, namely the kernel and the file system is therefore linked, and it is difficult, or even impossible, to update these two elements independently.

[0008] Verifying the integrity and authenticity of the files of such a remote autonomous system, in particular using a Linux operating system, is imperative for these systems, in which it is necessary to ensure that the binaries that are executed actually come from the original software supplier and have not been altered.

[0009] In general, such remote autonomous systems also include a secure boot hardware tool, however such a tool guarantees the integrity and authenticity only of the kernel and the bootloader suitable for launching the (or each) operating system, without allowing the verification of the integrity and authenticity of the elements of the file system.

[0010] Currently, the verification of the integrity and authenticity of the elements of the file system exploits the trust acquired in the kernel of the operating system, notably Linux, via the secure boot hardware tool in order to be able to use a complementary software mechanism which generally relies on two types of solutions.

[0011] The first solution is based on calculating hashes of the blocks of the media partition via a Merkle tree, also called a hash tree, capable of producing a unique hash (root hash) serving as a reference for integrity. More precisely, Merkle trees are binary trees used to perform data validation. To do this, each leaf of the tree will contain the cryptographic hash corresponding to a part of the data to be validated. Each node of the tree will also contain a hash. This hash is obtained by concatenating the hash of the two children and passing the result into a function to create a new hash. A general dependency is then constructed where the value of each node depends on the values ​​of its child nodes to ultimately obtain a unique hash (root hash).This unique fingerprint is then integrated into the kernel of the operating system, notably Linux, and is checked at startup and dynamically.

[0012] This first solution is however incompatible with the implementation of atomic updates because the addition of the fingerprint in the kernel inevitably modifies the fingerprint of the disk sector containing the kernel and therefore makes the unique fingerprint obsolete.

[0013] The second solution is based on a signature verification of the integrity and authenticity of the files, using for example for a Linux type operating system, a Linux IMA subsystem (from the English Integrity Measurement Architecture) with the EVM module (from the English Extended Verification Module).

[0014] This second solution based on signature verification requires the creation of a pair of private / public keys for asymmetric cryptography. The private key is used to sign the kernel and the bootloader, while the public key is stored on the hardware on which the OS is running, for example an iMX6 processor, by engraving its hash in the processor. This engraving of the public key is carried out in particular by relying on a physical mechanism based on OTP (One Time-Programmable) fuses. These fuses have the characteristic of being able to be written only once, while being able to be read as many times as necessary. They thus allow the secure storage of the public key in the hardware in an unalterable manner.

[0015] This second solution has the advantage of being compatible with the implementation of atomic updates because the public key can be added to the kernel without impact on the integrity calculation while allowing the management of atomic updates.

[0016] However, such key management generally proves to be complex to make it simple and industrially secure.

[0017] Indeed, in this context, there are currently different solutions for securing a private key but which all bring industrial, technical and financial constraints when we have to use this mechanism to sign a file system.

[0018] A first current solution for securing the private key requires an interconnection with a public key infrastructure for managing PKI keys (Public Key Infrastructure), but this is not very efficient, complex and expensive to implement because it requires, for example, modifying the signature software integrated into the kernel, in particular the open source Linux signature software called "evmctl", which is under a specific "GPLv2" license, which is not necessarily industrially acceptable. Indeed, such signature software is not designed to connect to this PKI, because it is only intended to work with a local private key.

[0019] A second current solution for securing the private key involves the use of a local hardware security module (HSM), but, like the first solution, also requires the development of a software layer to interface the signature software with the HSM component, which also involves high costs.

[0020] A third current solution for securing the private key is based on the use of a local Trusted Platform Module (TPM) to store the private key, but requires, like the previous solutions, the development of a software layer to interface the signature software with the TPM component, which also adds constraints on the machine used to produce the image of the file system, noting that the use of "asset hardware" complicates, or even prevents, automated software production on cloud computing.

[0021] A fourth current solution is based on the use of a locally self-signed private key, which is efficient and compatible with the implementation of atomic updates of a remote autonomous system, but requires complex organizational constraints to protect, trace, monitor the access(s) to the private key, such as encrypted disk storage, with rather relative security and difficulty in identifying a data leak or detecting a compromise (i.e. hacking) of the private key. Indeed, if the private key is intercepted, confidence in the file system is lost, because the interceptor will have the means to modify the contents while validating the verification with the public key)

[0022] The object of the invention is to remedy the drawbacks of the state of the art by proposing an alternative solution, simpler and more industrially secure, for the creation and management of private / public key pairs dedicated to signature verification.

[0023] For this purpose, the invention proposes a device for securing a file system of a remote autonomous system, said remote autonomous system using an operating system associated with said file system of said remote autonomous system, the remote autonomous system further using a double file system partition allowing A / B updates, said remote autonomous system being further capable of being updated by atomic update, the remote autonomous system further comprising a secure boot tool, said security device being configured to sign said file system based on asymmetric two-key cryptography comprising a public key and a private key, the public key being integrated into the kernel of said operating system, the lifetime of said private key being limited,said two public and private keys being regenerated by said security device each time a new atomic update of said remote autonomous system is produced.

[0024] Thus the present invention provides a solution to securing the private key in the case of a solution based on a self-signed key in order to maintain a simple mechanism to implement rather than going through an external authority to generate the keys.

[0025] More specifically, the solution according to the present invention uses a volatile private key in the sense that its lifetime is limited and where the two public and private keys are regenerated by the security device each time a new atomic update of the remote autonomous system is produced. Thus the complexity of securing this private key, the need for which is almost non-existent, because it is very limited in time, is reduced, and the update of the file system will go through a complete update of the remote autonomous system with a new public / private key pair associated with this production as such of this new update, the same update being able to subsequently be distributed to several separate remote autonomous systems.

[0026] The device for securing a file system of a remote autonomous system proposed according to the present invention may also have one or more of the characteristics below, taken independently or in all technically conceivable combinations:

[0027] - said private key is configured to sign said system only once files;

[0028] - the lifespan of said security device is also limited;

[0029] - said security device is a Docker container.

[0030] The invention also relates to an autonomous system using an operating system associated with a file system of said remote autonomous system,

[0031] the remote autonomous system further using a double file system partition allowing A / B updates, said remote autonomous system being further capable of being updated by atomic update, the remote autonomous system further comprising a secure boot tool, the remote autonomous system comprising the security device according to the present invention as mentioned above.

[0032] The remote autonomous system provided according to the present invention may also have the characteristic that said operating system is a Linux operating system using the signature mechanism provided by IMA / EVM Linux.

[0033] The invention also relates to a method for securing a file system of a remote autonomous system, said remote autonomous system using an operating system associated with said file system of said remote autonomous system, the remote autonomous system further using a double file system partition allowing A / B updates, said remote autonomous system being further capable of being updated by atomic update, the remote autonomous system further comprising a secure boot tool,

[0034] the method comprising a phase of signing the file system based on two-key cryptography comprising a public key and a private key, said phase of signing the file system comprising the following steps:

[0035] - generation and integration of the public key into the kernel of said system operating;

[0036] - generation of a private signature key for said file system, the lifetime of said private key being limited;

[0037] - signing and securing said file system using said private key to limited lifespan.

[0038] The method for securing a file system of a remote autonomous system proposed according to the present invention may also have one or more of the characteristics below, taken independently or in any technically conceivable combination:

[0039] - the method further comprises a step of secure destruction of said key private, said destruction step being implemented after said signature;

[0040] - said destruction is a multi-pass erasure;

[0041] - the method further comprises, after said signing step, a storage step of said private key in an encrypted container whose opening key is randomly generated without being saved.

[0042] The invention also relates to a computer program comprising software instructions which, when executed by a computer, implement a method for securing a file system of a remote autonomous system as defined above.

[0043] Other characteristics and advantages of the invention will emerge from the description given below, for information purposes only and in no way limiting, with reference to the appended figures, among which:

[0044] [Fig-1] [Fig.l] schematically represents a remote autonomous system and a device for securing a file system of such a remote autonomous system according to one embodiment of the invention;

[0045] [Fig.2] [Fig.2] is a flowchart of a method for securing a system of files of a remote autonomous system according to one embodiment of the invention;

[0046] [Fig.3] [Fig.3] illustrates the securing effects associated with each step of the process illustrated by [Fig.2].

[0047] As indicated previously, [Fig.l] schematically represents a remote autonomous system 10 and a device for securing a file system of such a remote autonomous system according to an embodiment of the invention.

[0048] More precisely, such a remote autonomous system 10 firstly comprises, and uses, a medium 12, having a double partition of type A 14, and B 16, allowing A / B updates. Each partition A 14 and B 16 has its own file system.

[0049] Furthermore, said remote autonomous system 10 is furthermore capable of being put to updated by atomic update as defined previously.

[0050] The remote autonomous system 10 further comprises, and uses, at least one operating system 18 whose kernel 20 is subsequently called kernel. This operating system 18 is associated with the file system of said remote autonomous system 10.

[0051] As an optional addition, said operating system 18 is a Linux operating system 18 using the signature mechanism provided by IMA / EVM Linux, to compile the public key with the kernel in accordance with this IMA system and the EVM module of Linux, to ensure verification.

[0052] The remote standalone system 10 also includes a secure boot tool 22.

[0053] According to the present invention, the remote autonomous system 10 also comprises a device 24 for securing the file system of the remote autonomous system 10.

[0054] Said security device 24 is configured to sign said file system based on two-key asymmetric cryptography comprising a public key and a private key, the public key subsequently being integrated into the kernel 20 of said operating system 18.

[0055] According to the present invention, the security device 24 is specifically configured to generate a private key whose lifetime is limited, the two public and private keys being regenerated by the security device 24 each time a new atomic update of said remote autonomous system 10 is produced (which amounts to a regeneration of the two public and private keys each time a version of a remote autonomous system 10 is produced, N remote autonomous systems according to this version being able to be installed on N separate machines for example).

[0056] As an advantageous optional addition, said private key is configured to sign said file system only once.

[0057] To sign said file system based on asymmetric two-key cryptography comprising a public key and a private key, the security device 24 comprises, according to the embodiment of [Fig.l], a first generation module 26 configured to generate the public key and then to integrate it into the kernel 20 of said operating system 18.

[0058] In addition, according to the embodiment of [Fig.l], the security device 24 further comprises a second generation module 28 configured to generate the private signature key of said file system, the lifetime of said private key being limited.

[0059] According to one variant, the first generation module 26 and the second generation module 28 are distinct. According to another variant, the first generation module 26 and the second generation module 28 share the same key generation tool configured to directly generate the private key / public key pair.

[0060] According to an additional optional aspect, the security device 24 further comprises an encrypted container 30, represented using dashes, said encrypted container 30 being configured to store said private key, the opening key of said encrypted container 30 being generated randomly without being saved.

[0061] According to the embodiment of [Fig.l], the security device 24 further comprises a signature module 32 configured to sign and secure said file system using said private key with limited lifetime.

[0062] According to an additional optional aspect, the electronic security device 24 further comprises a destruction module 34, represented using dashes, configured to securely destroy said private key, after its use to sign and secure said file system. It should be noted that the use of the encrypted container 30 indicated previously makes it possible to avoid the use of the destruction module 34, and vice versa.

[0063] According to an optional variant, such an optional destruction module 34 is capable of implementing multi-pass erasure.

[0064] The electronic security device 24 is thus configured to implement at least in part the method for securing a file system of a remote autonomous system as detailed below in relation to [Fig.2].

[0065] According to one aspect illustrated by [Fig.l], the electronic security device 24 comprises an information processing unit 36 ​​formed for example of a memory 38 and a processor 40 associated with the memory 38.

[0066] According to a particular example, the first generation module 26, and the second generation module 28, the signature module 32, and optionally the encrypted container 30 or the destruction module 34 are each produced in the form of software, or a software brick, executable by the processor 40 of the electronic security device 24 according to the present invention.The memory 38 of the electronic security device 24 is then able to store a first software for generating and integrating the public key into the kernel 20 of said operating system 22, a second software for generating a private key for signing said file system, the lifetime of said private key being limited, a software for signing and securing said file system using said private key with a limited lifetime, and optionally an encrypted container software whose opening key is randomly generated without being saved, or a software for securely destroying said private key after its use for signing. The processor 40 is then able to execute each of these software programs.

[0067] In a variant not shown, the first generation module 26, and the second generation module 28, signature module 32, and optionally encrypted container 30 or destruction module 34 are each produced in the form of a programmable logic component, such as an FPGA (Field Programmable Gate Array) or in the form of a dedicated integrated circuit, such as an ASIC (Application Specified Integrated Circuit).

[0068] When the electronic security device 24 is produced in the form of one or more software programs, that is to say in the form of a computer program, it is also capable of being recorded on a medium, not shown, that is readable by a computer. The computer-readable medium is, for example, a medium capable of storing electronic instructions and of being coupled to a bus of a computer system. By way of example, the readable medium is an optical disk, a magneto-optical disk, a ROM memory, a RAM memory, any type of non-volatile memory (for example EPROM, EEPROM, FLASH, MVRAM), a magnetic card or an optical card. A computer program comprising software instructions is then stored on the readable medium.

[0069] It should be noted that said security device 24 which is used to produce the new system and therefore uses the volatile private key according to the present invention, is itself conventionally secured to be itself correctly protected in order to ensure the protection of the private key, which amounts to prohibiting the use of a device without any protection, without updating, connected to the Internet, and consequently vulnerable.

[0070] According to an additional optional aspect, the lifetime of said security device 24 itself is also limited.

[0071] According to another additional optional aspect, said security device 24 is a Docker container.

[0072] An example of implementation of a method 50 for securing the file system of the remote autonomous system 10 according to the example of [Fig. 1] will now be described below, in particular in relation to the embodiment of [Fig. 2], the method 50 comprising a phase of signing the file system based on two-key cryptography comprising a public key and a private key, said phase of signing the file system comprising the following steps:

[0073] - generation and integration of the public key into the kernel of said system operating;

[0074] - generation of a private signature key for said file system, the lifetime of said private key being limited;

[0075] - signing and securing said file system using said private key to limited lifespan.

[0076] The embodiment of [Fig.2] corresponds to an implementation of said method 50 considering that the operating system 18 of [Fig.l] is a Linux operating system.

[0077] According to this implementation, a packet initialization, not shown, is first implemented. Then, the creation of the system as such is carried out and it is during this creation that the method 50 for securing the file system of the remote autonomous system 10 according to the present invention is implemented.

[0078] More precisely, in a conventional manner a step 52 of generating the file system is first implemented.

[0079] Then, according to the example of [Fig.2], the generation of the public key and the generation of the aforementioned private key are implemented simultaneously within step 54 of generation of a private key / public key pair, the private key being configured to have a limited lifetime (i.e. the private key being volatile).

[0080] During step 56, the compilation (i.e. integration) of the public key in the kernel 20 is implemented.

[0081] In parallel, during step 58 the creation of the files of the file system is implemented.

[0082] Then according to a step 60, the signing and securing of the files using the limited duration private key is carried out.

[0083] As an optional addition, the method 50 for securing a file system of a remote autonomous system further comprises a step 62, represented using dashes, of storing said private key in an encrypted container whose opening key is generated randomly without being saved.

[0084] As an alternative to the optional step 62, the aforementioned signature step 60 is followed by an equally optional step 64 of secure destruction of said private key.

[0085] According to an optional aspect, such destruction 64 is implemented by multi-pass erasure (i.e. by multiple passes).

[0086] At the end of steps 52 to 60, with optionally steps 62 and 64, according to a step 66 a signed and immutable file system is then obtained.

[0087] Thus, the method 50 according to the present invention is based on the innovative use of a volatile private key, that is to say that the key will have a limited lifetime, and according to an advantageous optional aspect, limited to the signature period of the file system.

[0088] A malicious actor who wishes to steal the private key will then have to either recover the key from the system after it has been shut down, which is subsequently referred to as a post-mortem attack, in particular by theft of a hard drive or installation / execution of malicious software (from the English malware) after the production of the file system, or intercept the key by having previously compromised the system containing the private key, which which is subsequently described as a dynamic attack, this time using malware during the execution of step 60 signature as such.

[0089] With regard to post-mortem attacks, as indicated previously, the present invention proposes, in order to protect against such post-mortem attacks, to implement a secure storage mechanism 62 and / or destruction mechanism 64 of the private key.

[0090] More precisely, as indicated previously, for the secure storage 62, the present invention proposes to use an encrypted container. In other words, for this security option 62, it is a question of generating and storing the key not “in clear” on the storage media but inside an encrypted container 30 as represented in [Fig.l], such as a “cryptsetup LUKS”, “truecrypt” container secured by AES-256 type encryption, for example.

[0091] According to an optional variant making it possible to reinforce the security of such storage 62, such an encrypted container 30 could be created and mounted directly in volatile RAM (Random Access Memory).

[0092] To create this encrypted container 30, the security password will be generated randomly and not saved, so that in post mortem analysis it is therefore impossible to find the opening key of the encrypted container 30, and this encrypted container cannot be decrypted with current means.

[0093] For the other secure destruction option 64, it is proposed according to this alternative to focus on securing the destruction of the data rather than securing its storage as described according to the option above.

[0094] Depending on the type of hardware used to temporarily store the private key, secure destruction 64 corresponds, according to a first variant, already mentioned previously, to multi-pass erasure, according to which dedicated software is used to carry out an erasure comprising successive writings of random or non-random data on the old data and then erasures, thus ensuring secure erasure of the data.

[0095] According to another variant, implemented when the hardware used to temporarily store the private key corresponds for example to one or more SSD disk(s) (from the English Solid State Drive, technology based on Flash memory), so that the first variant above does not work, the methods of the manufacturers, who offer software dedicated to their hardware of this type, are used to actually erase the flash memory areas.

[0096] With regard to the aforementioned dynamic attacks, in order to reduce the attack surface as much as possible, it is proposed, as indicated previously, that the lifetime of said security device 24 itself is also limited.

[0097] In other words, the security device 24 used to perform the signature and store the private key is also ephemeral. For this purpose, it is proposed to use virtualized devices without persistence, such as, for example, a Docker container corresponding to an open platform for deploying and executing applications and which makes it possible to embed and execute an application in a partitioned environment called a container. Unlike virtualization where the virtual machine contains a complete operating system, the associated tools and the hosted application, such a Docker container only contains the libraries and tools necessary for executing the application, and operates directly in the kernel of the host machine. Such a Docker container then amounts to implementing isolation of the computing means during the creation, use and destruction of the private key, which makes it possible to guarantee the security of the process..

[0098] [Fig.3] illustrates the securing effects associated with each step of the process illustrated by [Fig.2].

[0099] In [Fig. 3], view 67 corresponds to the software production of the file system. According to the embodiment illustrated by [Fig. 3], the public 68 and private 70 keys are for example generated using an encryption toolbox such as OpenSSL, and in particular the signature tool 72 provided by IMA / EVM Linux is used.

[0100] Once the signature operation is completed, a signed and immutable file system 74 is then obtained, and the private key 70 is, according to an option detailed previously, securely destroyed to limit the risks of exfiltration of this private key via forensic methods (i.e. based on a forensic analysis also called digital investigation).

[0101] For example, the lifetime of the private key 70 is limited to the duration of the software production of the file system, i.e. a few hours, for example two or three hours, and is used, as such, only a few seconds to sign the files in order to obtain after its use the signed file system 74.

[0102] View 75 of [Fig. 3] illustrates the execution of the remote autonomous system 10. During this execution, according to a prerequisite on which the present invention is based, the secure boot tool, illustrated by the reference 22 in [Fig. 3], implemented by the hardware of the remote autonomous system 10, will also conventionally check the integrity of the bootloader (or BIOS for Basic Input Output System, or UEFI for Unified Extensible Firmware Interface) 76 and the kernel 20 via, for example, a “ROM code” (Read Only Memory), or embedded software (Firmware), implementing the management of the secure boot tool 22 and using another pair of asymmetric keys, the public key 78 of which is represented in [Fig. 3], themselves suitably secured via a classic security by in PKI (Public Key Infrastructure) type public key management infrastructure or via an HSM (Hardware Security Module), etc.

[0103] During this execution of the remote autonomous system 10, in the example of [Fig.3], an attacker (i.e. malicious actor) could attempt to use an attack which would employ a new unrepresented malicious public / private key pair, and would attempt to re-sign the entire file system with the malicious private key by also replacing the public key 68 in the kernel 20 with its malicious public key.

[0104] Such an attacker would then be advantageously blocked according to the present invention, because firstly, as indicated previously, the kernel 20 is also controlled by the secure boot tool 22 which implements an additional cryptographic verification in particular via the key 78.

[0105] Furthermore, the public key 68, generated during the software production of the view 67 of [Fig. 3], associated with the file system, is included in the kernel 20 and the whole forms the coherent whole 80. However, according to the present invention, it is impossible to modify any file of the coherent whole 80 without having the private key 70, generated during the software production of the view 67 of [Fig. 3] and due to its limited lifetime, according to the present invention, (i.e. volatile key), which advantageously no longer exists during the execution of the remote autonomous system 10 corresponding to the view 75 of [Fig. 3].

[0106] Those skilled in the art will understand that the invention is not limited to the embodiments described, nor to the particular examples of the description, the embodiments and variants mentioned above being suitable for being combined with each other to generate new embodiments of the invention.

[0107] The present invention thus proposes a security solution for verifying the integrity of a file system, in particular of the Linux type. This solution based on a volatile private key no longer makes it possible to modify or alter the file system because the private key will no longer exist, which complicates the implementation of a persistent attack on this type of system for a malicious person.

[0108] As previously indicated, the public key, for its part, is compiled with the kernel to ensure verification in accordance with the IMA system and the EVM module of Linux, the integrity and authenticity of the kernel being themselves protected by the secure boot hardware tool.

[0109] Since updating the file system is atomic, adding / modifying / deleting a file requires regenerating the entire file system, which therefore implies generating a new public / private key pair. A new kernel is also compiled including the new public key.

[0110] Thus, the solution proposed according to the present invention is advantageous because it eliminates the need to take heavy technical or organizational measures to manage the protection of the private key. The association of an atomic update including the file system and the kernel as well as the generation of single signature keys (i.e. single use to sign the file system once), offers the benefit of a simple and ultra-secure solution for the private key to overcome the constraints linked to its management.

Claims

Claims

1. A device (24) for securing a file system of a remote autonomous system (10), said remote autonomous system using an operating system (18) associated with said file system of said remote autonomous system, the remote autonomous system (10) further using a double file system partition allowing A / B updates, said remote autonomous system (10) being further capable of being updated by atomic update, the remote autonomous system (10) further comprising a secure boot tool (22), said security device being configured to sign said file system based on asymmetric two-key cryptography comprising a public key and a private key, the public key being integrated into the kernel of said operating system, said security device being characterized in that the lifetime of said private key is limited,said two public and private keys being regenerated by said security device each time a new atomic update of said remote autonomous system is produced.,

2. The device of claim 1, wherein said private key is configured to sign said file system only once.

3. Device according to claim 1 or 2, characterized in that the lifetime of said securing device (24) is also limited.

4. Device according to any one of the preceding claims, wherein said securing device (24) is a Docker container.

5. Remote autonomous system (10) using an operating system (18) associated with a file system of said remote autonomous system, the remote autonomous system (10) further using a double file system partition allowing A / B updates, said remote autonomous system (10) being further capable of being updated by atomic update, the remote autonomous system (10) further comprising a secure boot tool, the remote autonomous system being characterized in that it comprises the security device according to any one of the preceding claims.

6. The system (10) of claim 5, wherein said operating system is a Linux operating system using the signing mechanism provided by IMA / EVM Linux.

7. Method (50) for securing a file system of a remote autonomous system, said remote autonomous system using an operating system associated with said file system of said remote autonomous system, the remote autonomous system further using a double file system partition allowing A / B updates, said remote autonomous system being further capable of being updated by atomic update, the remote autonomous system further comprising a secure boot tool, the method comprising a phase of signing the file system based on two-key cryptography comprising a public key and a private key, said phase of signing the file system comprising the following steps: - generation (54) and integration (56) of the public key in the kernel of said operating system;- generation (54) of a private key for signing said file system, the lifetime of said private key being limited; - signing and securing (60) said file system using said private key with limited lifetime.;

8. The method of claim 7 further comprising a step of securely destroying said private key, said step of destroying being implemented after said signature.

9. The method of claim 8, wherein said destruction is a multi-pass erase.

10. Method according to any one of claims 7 to 9, further comprising, after said signing step, a step (62) of storing said private key in an encrypted container whose opening key is randomly generated without being saved.

Images