SECURE CLOUD COMPUTING ARCHITECTURE AND SECURITY PROCEDURES

Description

FIELD OF INVENTION

[0001] The present invention relates to a secure cloud computing architecture comprising a first data management and / or program execution space in which data management or program execution is controlled by a user, and a second data management and / or program execution space in which data management or program execution is controlled by a third-party operator. It further relates to a method for securing data and / or program execution in such a cloud computing architecture. EARLIER ART

[0002] Individuals, businesses, and government organizations are increasingly turning to cloud computing, and this trend is set to grow in the coming years. However, the issue of security and trust is becoming increasingly pressing. Governments, in particular, are concerned about their sovereignty. For example, the French government has helped two French companies, Orange Business Services and OVH, to compete with American giants such as Amazon AWS and Microsoft Azure in the cloud computing sector. Furthermore, businesses are hesitant to entrust critical data and processing to cloud providers. Indeed, current solutions do not offer the necessary guarantees, even when these solutions are considered "sovereign," meaning dependent on the countries where the companies are based (Orange Business Services and OVH in France).It is not enough to have a domestic cloud computing service provider to solve the trust problem, because they themselves have to use foreign hardware and software and, above all, can make mistakes or be attacked.

[0003] US 2014 / 137179 A1 and US 2007 / 271618 A1 constitute the relevant prior art. SUMMARY OF THE INVENTION

[0004] The scope of the invention is defined by the independent claims.

[0005] In light of the above, one problem that this invention aims to solve is to provide a method for securing a cloud computing architecture. More specifically, the problem addressed by the invention is a problem of trust: how to create a cloud computing architecture in which a user, in particular, can have full trust, or at least as much trust as if the architecture were completely under their control?

[0006] The solution proposed within the framework of the invention primarily aims at a secure cloud computing architecture comprising: a first data management and / or computer program execution space in which data management and / or program execution is controlled by a user; a second data management and / or computer program execution space in which data management and / or program execution is controlled by a third-party operator; characterized in that it further comprises: first security policies applied to data or program execution in the first execution space; second security policies applied to data or program execution in the second execution space; a security property expected by the user, compliance with said first and second security policies ensuring data management and / or computer program execution conforming to this property;and a trust base guaranteeing, in the absence of a breach, the application of the second security policies in data management and / or program execution in the second execution space, said trust base comprising, on the one hand, a hardware component with indicators of unauthorized access and, on the other hand, a software component, said software component being made available to the user and / or a trusted third party. These indicators are visible to the user and may potentially trigger the system's security measures.

[0007] Thus, when the user runs a program at least partially in the second execution space, and the access indicator signs remain blank, then that user can be certain that the execution of that program satisfies the property.

[0008] Advantageously: - the trust base includes a hardware security module, said hardware security module allowing the user to choose a certificate authority to represent them (at least from a list of possibilities), and the software part of the trust base is made available to the user or their representative; - the software part of the trust base and the means to rebuild it are provided or made available to the user and / or trusted third parties; - the trust base is part of a hardware security module whose core software, namely its most complex part, is formally proven; - the user is provided with the means to be convinced that all execution paths of the software part of the trust base guarantee compliance with the second set of security policies, under normal operating conditions;- the architecture includes a subset which comprises one or more physical servers forming the space (B), a hardware part and / or software part of the trust base forming hardware security modules being associated with said servers; - furthermore includes a hardware part of the trust base forming an additional box, this additional box being placed at the entrance of the subset and having means to filter data packets entering the subset, this filtering including a verification that said data packets comply with a security policy, i.e. that of the execution environment (B).;

[0009] The invention also relates to a method for securing a cloud computing architecture, comprising the steps according to which: We provide a first data management and / or computer program execution space in which data management and / or program execution is controlled by a user; we provide a second computer program execution space in which data management and / or program execution is controlled by a third-party operator; first security policies are applied to data and / or program execution in the first execution space; second security policies are applied to data and / or program execution in the second execution space; we define a security property expected by the user, compliance with said first and second security policies guaranteeing data management and / or computer program execution in accordance with this property;a trust base is provided guaranteeing, in the absence of a breach, the application of the second security policies in the management of data and / or the execution of programs in the second execution space, said trust base comprising, on the one hand, a hardware component with indicators of unauthorized access and, on the other hand, a software component, said software component being made available to the user and / or a trusted third party; and in that the management of data and / or the execution of programs carried out by the user at least in part in the second execution space is considered to satisfy the ownership expected by the user, if the access indicators remain blank.

[0010] Advantageously: - the software part of the trust base and the way to rebuild it is provided or made available in its entirety to the user and / or the trusted third party. BRIEF DESCRIPTION OF THE FIGURES

[0011] The invention will be better understood upon reading the following non-limiting description, drawn up with reference to the accompanying drawings, in which: [ Fig. 1 ] there figure 1 is a diagram illustrating an architecture according to the invention; [ Fig. 2A ] there figure 2A is a schematic representation of a first example of a hardware package comprising a formally proven core of the ProvenCore™ type, capable of being implemented in an architecture according to the invention, said package being equipped with filtering means and capable of forming a VPN; Fig. 2B ] there figure 2B is a schematic representation of a second example of a hardware package comprising a formally proven core of the ProvenCore™ type, capable of being implemented in an architecture according to the invention, said package being equipped with filtering; [ Fig. 3A ] there figure 3Ais a schematic representation of a specific room according to the invention, comprising a server, and a hardware security module of the type of hardware security modules shown in Figures 2A Or 2B , contributing to the trust base and enabling various partitions, both internal and external; [ Fig. 3B ] there figure 3B is a schematic representation of a specific room according to the invention, comprising a plurality of servers, and a set of enclosures of the type shown in the Figures 2A Or 2B , contributing to the trust base and enabling various partitions, both internal and external; and [ Fig. 3C ] there figure 3C is a schematic representation of a specific room according to the invention, comprising a plurality of servers, and a set of enclosures of the type shown in the Figures 2A Or 2Bcontributing to the base of trust and enabling the creation of various partitions, both internal and external. DETAILED DESCRIPTION OF THE INVENTION

[0012] The invention relates to a cloud computing architecture. Such an architecture generally comprises a set of virtual servers, each virtual server being associated with one or more virtual storage disks, each virtual storage disk being materialized by one or more physical storage disks, said physical storage disks being contained within physical computer servers. A user accesses the services provided by the cloud computing architecture, for example, by means of a personal computer, or a server that they control, or a mobile phone via a network such as the Internet or a 3G, 4G, or 5G network.

[0013] As shown in the figure 1The architecture according to the invention comprises a first space or environment A for managing data and / or executing computer programs. In this first space, the data, as well as the manner in which it is managed, and the execution of programs are controlled by a user, customer, or interested party, said user being, for example, a natural person, a company, a government organization, an operator, or a combination of such entities, for example, a natural person and their company, having access to at least some of the services provided by the cloud computing architecture. The first space A is, for example, the user's workstation: a physical server, a multifunction mobile phone (a "smartphone"), or a personal computer.

[0014] The architecture also includes a second space or environment B for data management and / or program execution. This space B is, for example, a room containing a set of physical servers with physical disks, typically located at the operator's or cloud service provider's premises, and therefore remote. In this second space, data management and / or program execution are handled by an operator. The operator's control over the data and / or program execution may be total or partial. This operator is, for example, a cloud computing service provider or an IT infrastructure provider. This operator is not controlled by the user. In practice, and generally, the user purchases the services they require within the architecture from the operator.

[0015] In the case of the present invention, the user does not trust or does not have complete trust in the third-party operator because he does not fully control the management of his data and / or the programs he executes in space B.

[0016] In the architecture according to the invention, first PSA security policies are applied to data management and / or program execution in the first execution space A.

[0017] Security policies should be understood as expected behaviors within data management and / or program execution environments. They are sets of security rules that define, for example, the confidentiality, integrity, and, ideally, availability of the data and / or programs contained within the architecture. These rules can also define permissible behaviors. For example, a user file managed by the operator will always be stored encrypted with a key that is part of the trusted database and will never leave a Hardware Security Module (HSM) forming a physical enclosure. This file can potentially be decrypted by the HSM or the hardware security module in an isolated space, that is, a security domain, typically created dynamically by the hardware security modules of the figure 3A Or 3BThe data is then processed on behalf of the user, and the result is re-encrypted by the HSM (Hardware Security Module), before being stored outside the trusted database (i.e., the TCB) by the operator. The space—the security domain—is then cleared, freeing up the space, or in other words, allowing the operator to assign the machines to other tasks. A security policy can also be defined in the XCCDF (eXtensible Configuration Checklist Description Format) XML language, which is part of the NIST (National Institute of Standards and Technology) SCAP (Security Content Automation Protocol) specifications. This language allows for the representation of a structured set of security rules to support the exchange of security-related information and, consequently, to generalize security best practices.In one example, confidentiality can be maintained, according to a security policy—that is, a rule—by systematically encrypting data. In this simple example, the rule is "systematically encrypt data." This is not the encryption key. In another example, integrity can be maintained, according to a security policy, by monitoring an application's configuration files. In this case, the rule is "monitor an application's configuration files." In yet another example, availability can be managed, according to a security policy, by implementing a redundant architecture. The rule is then "implement a redundant architecture." Generally speaking, a security policy comprises a plurality of rules: "systematically encrypt data AND monitor an application's configuration files AND implement a redundant architecture."Security policies according to the invention generally apply not only to data but also to computer programs or applications.

[0018] In the architecture according to the invention, second PSB security policies are also applied to data management and / or program execution in the second execution space B.

[0019] According to the invention, a security property P is expected by the user for the management of their data and / or the execution of computer programs in the first space A, but also partially or entirely in the second space B, in which they have no trust or only limited trust. This property P is such that compliance with the first security policy (PSA) and second security policy (PSB) guarantees data management or the execution of computer programs that conforms to this property P. Such a property can optionally be described as a security policy. For example, a sensitive file could be processed without encryption in space A, but still according to the rules defined above outside of it, in space B and the rest of the cloud architecture.

[0020] Furthermore, the architecture according to the invention includes a TCB trust base. This trust base is a subset of execution space B. The TCB trust base comprises a hardware component, namely a physical subset including, for example, one or more physical computers / servers / processors and / or memory disks, memory areas, etc. It also includes a software component including data and / or programs. This software component is generally a small subset of space B. Note that execution space A may likewise include a TCB trust base.

[0021] The Trust Base ensures the application of the second PSB security policies in data management and / or program execution within the second execution space B. To this end, the Trust Base has indicators of unauthorized access. More specifically, the hardware component of this base has such indicators. It is therefore "tamper evident." If unauthorized access to the base occurs, regardless of the cause, including an attack or intentional or unintentional degradation of operation, and if, as a result, a potential or actual violation of the second PSB security policies exists, then indicators of this access will be activated, making the access visible, similar to seals. The term "violation" is understood in a broad sense, including any unauthorized intrusion, degradation, theft, modification, or corruption of data or programs.The indicators provide evidence of unauthorized access to the trusted database or a compromise of its integrity. A breach due to unmet assumptions (for example, an inadequate cryptographic algorithm) will not necessarily lead to an indicator being triggered. In one example, and for the implementation of the aforementioned sealing functions, the trusted database includes a hardware security module (HSM). This is a hardware component considered tamper-proof, which generally provides cryptographic functions. It should be noted, however, that a specific software module, such as a software security module, can perform some or all of the aforementioned functions in addition to or instead of an HSM. Therefore, within the scope of the invention, the user can always verify the breach indicators after the fact for the physical component, for example, a server room, equipment, etc.and inspect the authenticity and compliance of the third-party operator's trust base. If the breach indicators are clean, it will be able to ensure that expected behaviors have been followed and that its security objective has been met, without necessarily trusting the operator. The user can then seek assistance—or use the services—of a third party they are willing to trust.

[0022] According to the invention, the software component of the trust base is made available to the user and / or a trusted third party. For example, this software component, and in particular, at a minimum, its portion on rewritable media, and the means to reconstruct it, such as the source code, the compiler, and the generators, will be provided or made available in its entirety to the user and / or the third parties assisting them, namely evaluators, certifiers, consultants, etc., whom the user is willing to trust, particularly because they will typically have been chosen by the user. Similarly, the user is provided with the necessary resources, such as documentation, supporting arguments, means of proof, etc.which allow the expert to audit a priori - some checks can however be deferred to be done a posteriori - the compliance of the announced security properties with a level of precision and detail allowing to be convinced that all execution paths of this software part of the trust base guarantee compliance with the second PSB security policies, under normal operating conditions of the hardware part of said base, and subject to compliance with the underlying assumptions, for example resistance of a cryptographic algorithm, the quality of a random number generator, etc... It must also cover all possible versions / configurations, in particular when the trust base of the third-party operator B may be subject to updates.To ensure compliance with the second set of security policies (PSBs), particularly in the case of software with an infinite number of possible execution paths, one can, depending on the situation, employ formal verification techniques, such as formal proofs, or perform code reviews or exhaustive testing when the low complexity of the software or the relevant part of the software allows it. It should also be advantageous to be able to recreate and / or validate all possible fields or a superset thereof and verify that the second set of security policies is indeed respected in all cases.

[0023] Ultimately, according to the invention, if the first PSA security policies are satisfied, the overall expected operation, i.e. the normal operation, in the absence of a successful attack, of this trust base will conform to the second PSB security policies, and will therefore consequently satisfy P. Example of a hardware security module (HSM) forming a trust base

[0024] The invention could be applied to create next-generation HSMs that would be much more flexible and would significantly reduce the role of HSM manufacturers in the chain of trust. In particular, they would allow: The user chooses the certifier and controls the customization; the software trust base of such an HSM is clearly identified and available for review; the HSM can be used in turn by several users under the control of a third-party operator who would not be trusted; and they are programmable with new processing functions.

[0025] It will also be advantageous to ensure that all the trust placed in the HSM manufacturer is fully auditable: for example, auditing will simply require verifying that the HSM supplied by the manufacturer contains the expected components (hardware or software), without needing to rely on compliance with an unverifiable (or difficult-to-verify) security policy. This last point will be illustrated with an example later.

[0026] Execution space B then includes this next-generation HSM, which could advantageously be implemented using a ProvenCore™< "tamper-resistant" hardware security module. Indeed, the ProvenCore™< appliance has a root of trust, an operating system, and auditable security applications. The appliance's software component will typically form part of the software trust base, for which resources such as documentation, supporting arguments, and evidence to be provided within the scope of the invention exist and have, in particular, mostly been developed for the purposes of the CC EAL7 evaluation of the ProvenCore™<. The hardware component of this hardware security module will typically constitute part of the hardware trust base.

[0027] Examples of ProvenCore™ filtering devices are shown at Figures 2A And 2BThey include a hardware component, referenced as "Hardware" in the figures, equipped with Ethernet ports Eth1 and Eth2, and carrying a formally proven core, referenced as "ProvenCore™" in the figures. This proven core is capable of implementing and even filtering protocol stacks referenced as "Protocol Stacks," with filtering implemented by means of a filter in the associated security hardware module ( Fig. 2A ) or not ( Fig. 2Bto a VPN (Virtual Private Network). Other ProvenCore™ security hardware modules may have purposes other than filtering and may host other applications. In this case, they may have other hardware peripherals. For example, a security hardware module designed as an HSM (Hardware Security Module) may include secure storage security applications, cryptography, etc. Such security hardware modules may also combine different functionalities simultaneously.

[0028] Regarding HSM personalization, an identity, its certificate, and potentially some other root data are typically introduced during the HSM initialization phase. One way to do this is through a pre-personalization step in which the HSM's identity is inserted, along with an asymmetric key pair for the HSM, and certificates or public keys associated with each user. These will later allow each user to create their own root of trust, all under the control of the various users or their trusted third parties who will use the HSM. This last step can be bypassed, as will be explained later in this description, by using transport keys or passwords. The aforementioned pre-personalization step will typically require physical proximity to the HSM.Next, each user can remotely customize the HSM to suit their specific needs and create their own root of trust. In doing so, the user might, for example, establish a trusted channel with the HSM using Transport Layer Security (TLS) with two-factor authentication and pre-distributed asymmetric keys. This customization typically results in the generation of one or more encryption keys. These keys, along with the user's dedicated private keys, will typically never leave the HSM in plaintext. However, it will be possible to encrypt them on the HSM for external storage, either temporarily between user sessions and then restored to the same or a different HSM, or to recover a damaged HSM.To back up and restore these keys on the same HSM, we will typically use a private key known only to the HSM (or a set of HSMs constituting a trusted family). To back up for the purpose of restoring a damaged HSM, we will use, for example, to encrypt the backups of keys specific to each user, for example, a public key of the user, or more precisely a symmetric key generated by the HSM and encrypted with the user's public key so that the latter is the only one who can re-personalize a replacement HSM that will recover the data.

[0029] In the example above, the need to grant even temporary access to critical secrets to third parties, especially humans, was avoided, as auditing their adherence to sound security policies is extremely difficult. While it's possible to audit software or hardware equipped with appropriate auditing tools (documentation, etc.), it's generally not feasible to audit processes performed by third parties unless they are continuously monitored. To further reduce the need for operations requiring the physical presence of the user or their trusted third party during HSM installation or preparation, an auditable feature could be used. This feature would allow remote customization via a one-time secret. For example, upon receiving this one-time secret (password, transport key, etc.) encrypted with its public key, the HSM would begin its customization process (key generation, etc.).This will create an entity that it will link to the user, with traditional mechanisms preventing "man-in-the-middle" attacks. If the secret has been compromised by the operator, the user will realize it. In this case, the operator will have gained access to a critical secret, but they will not be able to use it without the user noticing until they finish customizing their space in the HSM. This one-time-use secret will have no further use.

[0030] Here we see that the software trust base is not necessarily present in its entirety at all times. The software used for pre-personalization or customization may disappear when it is no longer needed. Similarly, some parts of the trust base are not yet loaded during initialization. Likewise, if the software trust base can be updated, the different versions are not generally retained in the embedded system that used them. However, the audit must be able to cover all the software used throughout the product's lifecycle, which means that all these versions and parts must be able to be reconstructed at the time of the audit(s) / evaluations.Revisions to the trust base typically do not exist at the time of the audit / assessment and must be audited either ex-ante at the time of their installation or ex-post, which implies that the auditor has a comprehensive and accurate view of the forms the software trust base can take over time. This generally also requires backing up all used versions. Examples of cloud computing architectures according to the invention

[0031] For the following three examples, the same basic architecture will be used. It is described herein. The cloud service provider (the third-party operator according to the invention) supplements its existing prior art architecture by adding specific rooms. These specific rooms, implemented according to the invention, form an execution space B. They typically house the same servers and equipment as a conventional room, but also include the means defined for the architecture according to the invention, in order to define an execution space B under stricter user control (by a company or user organization) for certain aspects of its security.

[0032] In these specific rooms, the service provider, i.e., the operator, will typically impose certain specific security rules: for example, it will take into account the concept of a "security domain." Such security domains will, by their very nature, be dynamically associated with users wishing to perform one or more sensitive operations (for example, operations on sensitive data). A security domain will thus be associated with (i.e., will be owned by) a single user. The service provider will, for example, refrain from using the same server simultaneously to run different security domains or domains belonging to different users. It will also be required, for example, to properly delete data from the servers before reassigning them to other security domains or users, or at the end of their use, etc.

[0033] A dedicated room will typically be created or prepared under the control of the user or one or more of their trusted third parties. It will be virtually tamper-proof. Indeed, once the room is created under the control of the user or their trusted third parties, it will typically be sealed in such a way that any successful physical access or attack will inevitably leave traces that the user or their trusted third parties can view during regular checks. For increased responsiveness, a security camera system monitoring the dedicated rooms and accessible to the user at all times can also be envisioned; this system itself would be tamper-proof and subject to review during regular inspections.

[0034] The specific room is equipped with means conforming to the invention. For this, for example, hardware security modules are used, which the provider adds alongside the servers of its usual infrastructure and which will allow the implementation and / or control of the rules that the service provider has imposed on itself in order to ensure respect for the properties.

[0035] There figure 3B shows a specific room in a cloud computing architecture comprising S1, S2, and S3 servers, said servers being arranged in an R network, a hardware security module or enclosure of the type shown in Figures 2A And 2B being positioned upstream of each server S1, S2 and S3, and an additional BA box being positioned at the entrance of the room. figure 3Cshows the same room in which, in addition, an additional BAA box controls all or part of the boxes located upstream of the S1, S2 and S3 servers, as well as the additional box shown in figure 3B . There figure 3A shows a specific room comprising a single S1 server and a single hardware security module.

[0036] The hardware security modules or B, BA, and BAA boxes are preferably "tamper evident" modules comprising a ProvenCore™-based computer board, as described in the literature "Security Filters for IoT Domain Isolation," Dominique Bolignano, Embedded Conference, 2018; "Security Filters for IoT Domain Isolation," Dominique Bolignano, Florence Plateau, ISoLa, 2018. The ProvenCore™ core, its launch chain, and, more generally, its trust chain, will typically include some of its applications within the software trust base of operator B. These hardware security modules authenticate, for example, and filter commands and data entering the specific room to verify that they comply with the rules imposed by the cloud provider and, more generally, with PSB security policies.Typically, they filter and control all network access for each machine in the cloud computing architecture of the specific room. For example, one can use the hardware security modules described in the paper on filtering. They will potentially also have other functions, such as certain server administration functions (e.g., dumping and preparing security domains), which would not be performed remotely.

[0037] The security hardware module enabling communication with the outside world will typically need to authenticate and open secure channels (first security hardware module), while the others will not necessarily need this capability (second security hardware module). This architecture can, of course, be optimized by duplicating certain security hardware modules to improve performance or by combining some of them. It's also possible to combine several security hardware modules into one (by creating multi-device, multi-function security hardware modules). A dedicated network (shown in red) can also be used to control / administer the security hardware modules. The specific rooms just described are typically protected rooms within buildings. A dedicated room can also be created by placing a server and one or more security hardware modules in a tamper-evident enclosure.Such a room, containing an S1 server and a BT security hardware module, is shown at the . figure 1 This specific room will then be movable like a server. It can be prepared at a manufacturer's facility under the control of the user or their trusted third party, sealed, and then placed in a standard room of the service provider like any other of their servers.

[0038] In general, ProvenCore™-based hardware security modules are capable of: to run security applications such as filtering, updating, authentication, secure storage, server and data provisioning applications controlled by the hardware security module, network interface control, USB, power supply, etc., server integrity control (including outside the trust base), i.e., HIDS using a TPM or probe, or VPN; to configure the topology of machines, particularly virtual servers in the specific room in which they are located, or to allow only certain commands or information to pass through said room or to said machines / servers. They can also be used to administer a specific machine (a server, for example, to initialize it, reboot it, load a new configuration before rebooting, etc.).For example, to run a specific service on a user's critical data, you would need to assign "cloud server 1" to that user. The corresponding security hardware module will isolate the chosen server and prepare it for the session (it will empty it, initialize it with the correct software and data, which it will have to retrieve and decrypt using keys that only security hardware modules can obtain, etc.). To do this, it can act as a filter (but this assumes that the cloud manages these servers differently, which is generally undesirable) or as a proxy (the security hardware module will receive commands that it will execute if permitted, translating them as needed).potentially serve as a hardware security module HSM, and especially ProvenCore™ hardware security modules have a software component of the trust base and the method for rebuilding it is provided or made available in its entirety to the user and / or trusted third parties.

[0039] Example of a company's cloud architecture with services such as spreadsheet services, editors, tools working on sensitive user data, such as a health application.

[0040] In this case, the user is the company or organization using the service.

[0041] Space A is a computer or the company's internal network. The user is willing to trust operator B for its quality of service but not for the security of their data.

[0042] At certain times, whether because they are given regular opportunities to verify or because they are given the ability to spontaneously create these opportunities, they perform—or have performed—verifications, particularly verifications of breach indicators. Furthermore, if they wish, users can review the software component of B's ​​trust base, especially if certain verifications were not performed initially, or if additional control of the trust base seems necessary. A trusted individual within the company can do this themselves, relying for certain parts on an Information Technology Security Evaluation Center (ITSEC), or any other evaluator or certifier they trust.The trusted person checks the seals and / or the state of the site, verifies for example that it has all versions and applications of the trusted base, checks or has evaluated / audited certain security applications which have not been, can make certain checks of the administrative operations which have been carried out by site B and which are also part of the trusted base, for example asks which version is used or which applications were loaded.

[0043] But the main checks will typically be carried out at the start: Verification of the physical integrity of the space, verification of the presence of the correct breach indicators / witnesses. Verification that the combination of the two security policies PSA and PSB, potentially with underlying assumptions (which appear acceptable to the user), effectively meets the chosen security objective. Precise identification of a subset of B's ​​software (and any evolutions) that is retained in its entirety and can be used if B's ​​indicators are not breached, for a post-hoc verification to ensure that the security objective has been properly maintained (subject to PSA satisfaction): for example, verification of all TCB versions used, verification that they had been correctly evaluated by the user or their trusted evaluator, and re-evaluation of certain parts as needed.The trust base will largely consist of the software for the security hardware modules (ProvenCore, its applications, etc.). Verification is needed to ensure that the architecture allows for the preservation of different versions of the trust base (different versions of ProvenCore and its applications, etc.), and that the quality of the arguments allows for achieving the desired level of trust. Typically, at this point, the server rooms will have been paired with the various users. Users can then load or configure their own HSM to be associated with them, or they can use the new generation HSMs described in the first use case.

[0044] User data can be stored in standard cloud space (sensitive data is encrypted with keys and sensitive data such as keys never travels in plain text in normal cloud space).

[0045] When a user needs to run a service in the cloud architecture that requires security measures, such as editing or processing a confidential document, the encrypted file, which is typically stored in the standard architecture, is retrieved to a specific room according to the invention, respecting the appropriate constraints. Other files necessary for processing can also be retrieved (e.g., a database). A new security domain is typically created, which generally involves temporarily assigning a security hardware module and a server to the task. The security hardware module creates a closed zone, i.e.A security domain loads (or controls the loading of) the correct editing or processing software, creates protective barriers against external access (depending on the case, isolating the domain or allowing it access to certain external information), establishes a secure communication channel with the user to enable interaction and permit or restrict certain data exchanges, etc., correctly initializes the entire system, and performs all associated administrative operations. In particular, certain versions of the processing software or the underlying operating system (e.g., Linux) may be explicitly requested by the user but will typically not be part of the trusted database.Indeed, potential bugs in this part of the software may exist, but if the security domain in which this software stack runs is properly isolated, they cannot be easily exploited by an attacker. The user will typically accept this and will not need to apply the same constraints, because the security properties they desire (for example, confidentiality) will typically be guaranteed by the security architecture, even in the presence of bugs. They will find themselves in the same situation they would have been in if they had run the function locally (without using the cloud) on a properly configured and protected machine.

[0046] Example of an architecture in which the user requests services such as spreadsheet or editor services, the user being a simple individual user.

[0047] Space A is the user's computer. A is willing to trust B for its quality of service but not for the security of its data.

[0048] The user will be able to choose that a CESTI, a certifier, or a trusted person they trust has verified the specific room(s) they will use, which means that the cloud service provider will have used a sufficient number and variety of trusted third-party organizations so that users of the targeted marketing group can find an acceptable third party. Example in which the architecture is a 3G, 4G or 5G type telephone network

[0049] The user is, for example, the telecom operator. However, the hardware used (e.g., infrastructure, base stations, etc.) consists of highly complex objects that constitute space (B), which is under the control of the operator, but also, to some extent, under the control of the provider, since the latter could have granted or denied access to the hardware (updates, sending operations, etc.). The operator is the user according to the invention, while the infrastructure provider is the operator according to the invention because the latter can potentially modify, operate, listen in, or control the infrastructure through hidden channels. An attacker other than the service provider could also play the role of operator according to the invention. The outside world (the hardware supplier as well as all other actors) can also play this role according to the invention. The invention will provide trust to the user (the network operator in this case). Example of an embedded chip with a security domain

[0050] Execution environment (A): A well-controlled system or subsystem that is trusted to perform a certain processing (typically sensitive processing i.e., confidentiality or security).

[0051] Execution environment (B): A less controlled, connected embedded computer that can potentially be attacked (typically by the operator according to the invention) and that will perform certain critical processing for system (A),

[0052] Operator B: the actors in the value chain who collectively develop this embedded computer (chip manufacturer, equipment manufacturer, device manufacturer, etc.) or an attacker exploiting a vulnerability left by one of them.

[0053] Solution: The processor of the computer (B) has at least one security space. For example, on chips based on the ARM™ Cortex A architecture, this space could be that of the TrustZone™, but contrary to what is usually done, the security OS, i.e., the TEE, the boot chain (the Secure Boot, part of the boot loader), and the monitor code will be part of the software TCB as defined by the invention and must be treated as such according to the invention. This will notably imply precise identification of the software TCB and specific processing thereof. The chip manufacturer must, in particular, provide the entire software TCB or sufficient information to allow it to be properly audited by various third parties.

[0054] But most importantly, the TCB must also include the software used in the initial customization and boot phases (even if it disappears due to space constraints). It's also necessary to include the different versions when the trust base can be updated. For the initial phases, we can imagine (1) trusting the hardware (which must have a certain form of "tamper evidence") and having a minimal ROM (documented and potentially scannable in privileged mode), or (2) using a removable chip equipped with a tamper-evident hardware security module that is installed when receiving the device, such as a phone or automotive ECU (the removable chip will be inserted like a SIM card). So, whether the phone or ECU is tamper-evident or not, there will be a slot to insert a removable chip containing all or part of the TCB.

[0055] Chips based on the ARM Cortex-A architecture are just one example. In some newer generations of chips, whether ARM-based or not, multiple security spaces can be created (the NXP iMX8, or certain multi-core or "many-core" architectures, such as that of the new European processor developed under the EPI, i.e., European Processor Initiative). These security spaces are generally achieved through memory controller programming. The software that performs these configurations and / or controls will typically also be part of the software trust base of (B) within the scope of the invention. Example of critical information retrieval and / or deep learning in the cloud

[0056] The use of the cloud for collecting and processing sensitive data (for example, for deep learning) is often considered problematic, particularly regarding privacy. The two aspects described in the examples "remote chip with security domain" and "cloud architecture and their dedicated rooms" can be combined. The embedded security space (B) (for example, in an ADAS computer for autonomous driving in a car that has access to a lot of sensitive data for the driver) communicates securely with a security domain in a dedicated room of the cloud (another part of (B)). The execution space (A) will be, for example, the set of more controlled computers in the car that provide sensitive data to the ADAS computer (vehicle position, camera data, etc.). The user will typically be the driver / manufacturer team.

[0057] Example: use of unused power in embedded systems (for example, a car's processor when it is parked).

[0058] A secure space is used on the unused embedded processor to perform processing on behalf of the cloud (or the user's computers). The cloud or the user's computers constitute space (A), which will, for example, use this unused processing power from (B) for cryptocurrency mining or other intensive processing. The unused processor (or computer) is (B), for example, the main "many"-core processor of a new-generation car. The car owner leases this unused processing power to the miner (i.e., the user), who, without having control of this embedded processor, is assured of compliance with certain security properties.

Claims

1. Secure cloud computing architecture comprising: a first data management and / or computer program execution space (A) wherein the data management and / or program execution is controlled by a user; and a second data management and / or computer program execution space (B) wherein the data management or program execution is controlled by a third-party operator, characterised in that it further comprises: first security policies (PSA) applied to the data or to the program execution in the first execution space (A); second security policies (PSB) applied to the data or to the program execution in the second execution space (B); a security property (P) expected by the user, compliance with said first and second security policies guaranteeing data management and / or execution of computer programs in accordance with that property (P); and a trusted base (TCB) ensuring, in the absence of a breach, the application of the second security policies (PSB) in the management of the data and / or the execution of the programs in the second execution space (B), said trusted base comprising, on the one hand, a hardware part having cookies indicating unauthorised access and, on the other hand, a software part, said software part being made available to the user and / or to a trusted third party and wherein the cookies indicating unauthorised access are visible to the user.

2. Architecture according to claim 1, characterised in that the trusted base comprises a security hardware module, said security hardware module allowing the user to select a certifier to represent it, and wherein the software part of the trusted base is made available to the user or their representative.

3. Architecture according to one of the preceding claims, characterised in that the software part of the trusted base and the manner of reconstructing it is provided or made available to the user and / or to the trusted third party.

4. Architecture according to one of the preceding claims, characterised in that the trusted base is part of a security hardware module the software core of which is formally proven.

5. Architecture according to one of the preceding claims, characterised in that the means are provided to the user that allow him to be convinced that all execution paths of the software part of the trusted base guarantee compliance with the second security policies, under normal operating conditions.

6. Architecture according to one of the preceding claims, characterised in that it includes an infrastructure comprising a subset which comprises one or more physical servers forming the space (B), a hardware part and / or the software base of the trusted base forming a unit(s) (BT) being associated with said servers.

7. Architecture according to claim 6, characterised in that it further includes a hardware part of the trusted base forming an additional security module (BTA), this additional security module being arranged at the input of the subset and having means for filtering data packets entering the subset, this filtering including verification that said data packets meet a security policy.

8. Architecture according to one of the preceding claims, characterised in that the hardware part of the trusted base is provided or made available to the user and / or to the trusted third party.

9. Method for protecting a cloud computing architecture comprising the steps according to which: a first data management and / or computer program execution space (A) is provided, wherein the data management and / or program execution is controlled by a user; a second computer program execution space (B) is provided, wherein the data management and / or program execution is controlled by a third-party operator; first security policies (PSA) are applied to the data and / or to the program execution in the first execution space (A); second security policies (PSB) are applied to the data and / or to the program execution in the second execution space (B); a security property (P) expected by the user is defined, compliance with said first (PSA) and second (PSB) security policies guaranteeing management and data and / or execution of computer programs compliant with this property (P); a trusted base (TCB) is provided, ensuring the application of the second security policies (PSB) in the data management and / or the execution of the programs in the second execution space (B), said trusted base comprising, on the one hand, , a hardware part having unauthorised access indicator means and, on the other hand, a software part, said software part being made available to the user and / or a trusted third party; and in that the data management and / or program execution performed by the user at least partially in the second execution space (B) is considered to be satisfactory to the property (P) expected by the user, if the access-indicating cookies remain blank, the cookies indicating unauthorised access being visible to the user.

10. Method according to claim 9, characterised in that the software part of the trusted base and the manner of reconstructing it is provided or made available in its entirety to the user and / or to the trusted third party.