METHOD FOR PROVIDING CERTIFICATES IMPLEMENTED BY A VIRTUAL COMPUTING PLATFORM

Description

Previous technique

[0001] The invention lies in the field of virtualized computing platforms.

[0002] Document WO 2018 / 162060 A1 is a relevant document in this area.

[0003] There figure 1 represents the known architecture of such a PIV platform. In this example, it comprises three layers, namely: a CM hardware layer; a VMM (Virtual Machine Manager) or hypervisor virtualization layer; and a virtual machine or VM layer.

[0004] In general, the virtualization mechanism gives resources at one layer the perception of exclusive use of potentially shared underlying resources. These underlying resources appear as multiple isolated instances allocated to resources at a higher layer. Each higher-level resource believes it has exclusive use of functionality rendered by the underlying resources and is aware that it is not running directly on the hardware.

[0005] The virtualized computing platform can be used to provide the functionalities of a next-generation mobile network or to implement an NFV (Network Function Virtualization) platform.

[0006] Each virtual machine runs a single operating system instance, called a guest operating system, and operates independently of the other virtual machines on the platform. Each guest operating system requires an isolated virtual machine to run.

[0007] The VMM virtualization software layer or hypervisor is a layer that runs under the virtual machines providing the runtime environment.

[0008] The present invention is more particularly relevant to the context of virtualized computer platforms with a Root of Trust (RoT).

[0009] Conventionally, such a Root of Trust (RoT) is configured to perform one or more specific functions to secure the Virtual Platform Inventory (VPI). It is therefore an element trusted to behave as expected, with any misbehavior of the RoT being undetectable. It should be noted that such a RoT can be composed of software components, but it is preferentially implemented as a hardware module.

[0010] The RoT root of trust thus provides security services for the PIV platform. In particular, it is used to store and protect the cryptographic keys of the PIV platform; these keys cannot be used by other resources without this RoT root of trust.

[0011] This Root of Trust (RoT) can be constituted by a Trusted Process Management (TPM) module that conforms to the technical specifications defined by the Trusted Computing Group (TCG) consortium. In particular, it can conform to the ISO / IEC 11889 standard.

[0012] In the example of the figure 1 The VMM hypervisor includes, for each virtual machine (VM), a virtualized Root of Trust (vRoT) that provides the guest operating system of that VM with the services of the RoT root of trust. Such a virtualized Root of Trust (vRoT) therefore refers to a combination of functionalities provided by the associated RoT root of trust, as well as by the hypervisor (the latter granting access to the RoT root of trust functionalities).

[0013] In the example of the figure 1The PIV virtualized computing platform comprises two virtual machines VM1, VM2, each virtual machine VMi benefiting from the resources of a virtualized vRoTi root of trust, the virtualized vRoTi roots of trust being independent instances representing the same RoT root of trust.

[0014] The invention is not limited to such an architecture.

[0015] For more information on the concepts and definitions introduced for the figure 1 , a person skilled in the art can refer to document [TCG].

[0016] The invention is more specifically situated in the context of the certification of virtualized computer platforms.

[0017] In general, within the context of the invention, attestation is a process by which a virtualized computing platform can assert a property to a verifying entity by providing proof of that property to that entity. For example, the virtualized computing platform can assert that it is trustworthy and has not been corrupted. In this example, the attestation process consists of providing proof of the platform's integrity.

[0018] Other properties may be subject to certification by the platform, and in particular, again by way of example: a certificate relating to the location of the platform; a certificate relating to access rights managed by the platform.

[0019] The invention is even more particularly relevant in the context of deep attestation, in which such an attestation process is carried out for each of the layers of the virtualized computing platform.

[0020] In practice, the attestation of the CM hardware layer is implicit because it is directly conferred by the RoT root of trust present in this layer.

[0021] Therefore, to return to the example of the figure 1 The in-depth certification of the PIV platform involves: the attestation of each virtual machine VM; the attestation of the virtualization layer (or hypervisor) VMM; and the provision of a verifiable and explicit link between the layers (in English, layer binding problem), proof that the different attestations (attestation of the VMM hypervisor, attestation of each of the virtual machines VMs) have indeed been issued for layers of the same PIV platform.

[0022] The trust status of a PIV virtualized computing platform can be determined by a third party only using primitives from the RoT root of trust, these primitives being intrinsically reliable and implemented by a software module but preferably hardware of that platform.

[0023] The VMM virtualization layer (in other words the hypervisor) uses the hardware Roots of Trust (RoT) of the hardware trust module to generate its attestation data.

[0024] These hardware Roots of Trust (RoTs) offer services such as cryptographic key protection and secure execution of cryptographic operations. These services are necessary to allow a third party to verify the trust status of the PIV platform.

[0025] Unlike the VMM virtualization layer, which must run directly on the CM hardware layer, VM virtual machines run in an execution environment created by the hypervisor, called a virtual platform.

[0026] These virtual platforms can use the features of hardware RoT roots of trust, but the hypervisor is involved in configuring access to these features as well as in the communication between these virtual platforms and the hardware RoT roots of trust.

[0027] These security services, for example cryptographic key protection and secure execution services for cryptographic operations, can themselves be considered as virtual roots of trust (vRoTi).

[0028] As mentioned previously, the certification of a virtualized computing platform involves reporting and verification steps for all its software components, in other words, VMi virtual machines and the virtualization layer or VMM hypervisor.

[0029] For its certification, each VMi virtual machine leverages its associated virtual secure platform instance, and in particular the security features offered by the vRoTi trusted virtual roots.

[0030] These virtual roots of trust (vRoTi) can be implemented in software and / or hardware, in the sense that the vRoTi communicates with the Root of Trust (RoT). Their purpose is to infer trust in the attestations of virtual machines (VMs) by establishing a chain of trust from the hardware layer (CM) to the virtual machine.

[0031] Therefore, a virtual machine health assessment can only be performed if the VMM hypervisor health is also validated as part of the attestation of that VMi virtual machine.

[0032] This process constitutes the deep attestation introduced earlier: it allows the trust of the RoT roots of trust to be extended, through the hypervisor with the implementation of the virtual roots of trust vRoTi, to the VMi virtual machines and therefore to the PIV virtualized computing platform as a whole.

[0033] A deep attestation involves the retrieval and subsequent validation, by a remote verification entity, of the attestation data of the VMi virtual machines and the attestation data of the underlying VMM hypervisor. From the remote verifier's perspective, these two attestation reports can be provided by two independent entities. Therefore, the remote verification entity requires proof that the VMM hypervisor, which it is verifying in a deep attestation, is actually running an instance of the vRoTi virtual root of trust associated with the target VMi virtual machine for the attestation. This problem of creating an explicit and verifiable link between the attestation of a virtual machine and the attestation of the hypervisor on which the virtual machine's vRoTi instances are running constitutes the layer binding problem already mentioned.

[0034] THE Figures 2A And 2B illustrate two models of deep attestations, which differ in how the hypervisor's attestation data is transmitted to the remote verifying entity: via the virtual machine's attestation channel (single-channel deep attestation); or via a separate dedicated channel (multi-channel deep attestation).

[0035] There figure 2A represents the known single-channel deep attestation mechanism.

[0036] In this model, the remote verification entity EV establishes a communication channel C with the virtual machine VM through which it obtains the virtual machine-specific attestation data as well as the attestation data of the hypervisor VMM on which the virtual machine runs.

[0037] In this model, the layer linking problem can be solved by including, in the hypervisor attestation data, data specific to the virtual trust module vRoT, thus providing a verifiable cryptographic proof of layer linking.

[0038] This model is not suitable for deployments in which a large number of virtual machines run on the same hypervisor, in particular because the generation of multiple hypervisor attestation reports cannot be done in parallel.

[0039] There figure 2B represents the known multi-channel attestation model in which the remote verification entity EV establishes a first communication channel C1 with the virtual machine to retrieve its attestation data, and then subsequently a second independent communication channel C2 with the hypervisor to retrieve its attestation data.

[0040] This model is well-suited to deployments involving a large number of virtual machines running on the same hypervisor. Unfortunately, the linking between the attestation data of the different layers is very loose, and the layer binding problem is not easy to solve.

[0041] For further information on attestation mechanisms, the person skilled in the art may refer to references [NFV] and [PRA].

[0042] The invention aims to provide a mechanism for in-depth attestation of a virtualized computing platform that does not have the disadvantages of the prior art. Description of the invention

[0043] The invention is defined by the independent claims.

[0044] According to a first aspect, the invention relates to a method for providing attestations implemented by a virtualized computing platform comprising a root of trust, a hypervisor, and at least one virtual machine, the hypervisor implementing a virtualized root of trust per virtual machine and offering root of trust services, this method comprising: a step of establishing a first secure channel between this hypervisor and a verification entity; a step of sending attestation data from this hypervisor in said first secure channel to the verification entity, this attestation data being obtained using root of trust services; a step of receiving, by the hypervisor, in the first secure channel, from the verification entity, at least one cryptographic data intended for the root of trust; a step of establishing a second secure channel between at least one virtual machine and the verification entity, root of trust primitives applied to the cryptographic data being necessary for the establishment of this second secure channel;a step of sending attestation data for said virtual machine in the secure channel established for that virtual machine, this virtual machine attestation data being obtained by the virtual machine using services of the virtualized root of trust associated with said virtual machine. ;

[0045] Correspondingly, the invention relates to a virtualized computing platform comprising a root of trust, a hypervisor, and at least one virtual machine, the hypervisor implementing a virtualized root of trust per virtual machine and offering root of trust services, in which: said hypervisor is configured to: establish a first secure channel with a verification entity; obtain attestation data from this hypervisor using root of trust services; send said attestation data from this hypervisor in said first secure channel to the verification entity; receive, from said verification entity, in the first secure channel, at least one cryptographic data item destined for the root of trust; each said virtual machine is configured to: establish a second secure channel between this virtual machine and the verification entity, root of trust primitives applied to the cryptographic data being necessary for the establishment of this second secure channel;send attestation data for this virtual machine in the second secure channel established for this virtual machine, this attestation data being obtained by the virtual machine using services from the virtualized root of trust associated with said virtual machine.

[0046] Correspondingly, the invention also relates to a set of computer programs comprising: a computer program on an information medium, this program being capable of being implemented by a hypervisor of a virtualized computing platform, this program including instructions configured to establish a first secure channel between the hypervisor and a verification entity; send attestation data from this hypervisor in the first secure channel to the verification entity, this attestation data being obtained using services from a trusted root of the platform; receive at least one cryptographic data from the verification entity in the first secure channel, this cryptographic data being intended for the trusted root;a computer program on an information medium, an instance of this program being capable of being implemented by a virtual machine of the virtualized computing platform, this program instance having instructions configured to: establish a second secure channel between the virtual machine and the verification entity, primitives of the root of trust applied to the cryptographic data being necessary for the establishment of this second secure channel; send attestation data from the virtual machine in the second secure channel, this attestation data being obtained by the virtual machine using services of a virtualized root of trust of the hypervisor associated with the virtual machine and offering services of said root of trust.

[0047] According to a second aspect, the invention also relates to a method for requesting attestations of a virtualized computing platform comprising a root of trust, a hypervisor, and at least one virtual machine, the hypervisor implementing a virtualized root of trust per virtual machine and offering root of trust services, this method being implemented by a verification entity and comprising: a step of establishing a first secure channel between the verification entity and the hypervisor; a step of receiving attestation data from the hypervisor in the first secure channel; a step of sending, to the hypervisor, in the first secure channel, at least one cryptographic data intended for the root of trust; a step of establishing a second secure channel between this verification entity and each of the virtual machines, primitives of the root of trust applied to the cryptographic data being necessary for the establishment of this second secure channel; a step of receiving attestation data from each virtual machine in the second secure channel established for this virtual machine, this attestation data being obtained by the virtual machine using services of the virtualized root of trust associated with said virtual machine.

[0048] Correspondingly, the invention also relates to a verification entity configured to request attestations from a virtualized computing platform comprising a root of trust, a hypervisor, and at least one virtual machine, the hypervisor implementing a virtualized root of trust per virtual machine and offering root of trust services, this verification entity comprising: a module for establishing a first secure channel between the verification entity and the hypervisor; a communication module configured to: receive attestation data from the hypervisor in the first secure channel; send at least one cryptographic data to the hypervisor in the first secure channel, this cryptographic data being intended for the root of trust; and a module for establishing a second secure channel between the verification entity and each of the virtual machines, primitives from the root of trust applied to the cryptographic data being necessary for the establishment of this second secure channel;a communication module configured to receive attestation data from each virtual machine in the second secure channel established for that virtual machine, this attestation data being obtained by the virtual machine using services from the virtualized root of trust associated with the virtual machine. ;

[0049] The invention also relates to a computer program, on an information medium, this program comprising instructions adapted to the implementation of the steps of the process of requesting certificates according to the invention.

[0050] Each of these programs can use any programming language, and be in the form of source code, object code, or code intermediate between source code and object code, such as in a partially compiled form, or in any other desirable form.

[0051] The invention also relates to a computer-readable information carrier, comprising instructions for a computer program as mentioned above.

[0052] The information medium can be any entity or device capable of storing the program. For example, the medium can include a storage means, such as a ROM, for example a CD-ROM or a microelectronic circuit ROM, or a magnetic recording means, for example a hard drive.

[0053] On the other hand, the information medium can be a transmissible medium such as an electrical or optical signal, which can be transmitted via an electrical or optical cable, by radio, or by other means. The program according to the invention can, in particular, be uploaded to a network such as the Internet.

[0054] Alternatively, the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the process in question.

[0055] Thus, and in general, the invention proposes, in order to provide proof of the link between the attestation data of the different layers, to establish secure channels (second channels in the sense of the invention) between each virtual machine and the verification entity, such a secure channel being established by using primitives of the root of trust of the platform applied to cryptographic data sent by the verification entity in the first secure channel established with the hypervisor.

[0056] Therefore, only layers capable of using root of trust services (directly for the hypervisor or indirectly for virtual machines via virtualized roots of trust) can originate these secure channels.

[0057] The invention thus provides proof of a verifiable and explicit link between the hardware layer that hosts the root of trust, the hypervisor, and the virtual machines of the virtualized computing platform.

[0058] In one embodiment, the verification entity produces a comprehensive attestation report of the platform.

[0059] In the embodiment described here, this report is positive if secure channels have been established between the virtual machine and the verification entity. This report includes: the hypervisor attestation data; and the attestation data of each virtual machine.

[0060] The cryptographic data sent by the verifying entity to the hypervisor in the first secure channel and used by the root of trust to establish secure channels between virtual machines and the verifying entity can be of any nature.

[0061] In a particular embodiment of the invention, the verification entity comprises a server, the hypervisor comprises a client, this client and this server being configured to establish between themselves the first secure channel within the framework of a first session conforming to the TLS protocol. This first secure channel is used: by the hypervisor to send its said attestation data to the verification entity; and by the verification entity to send the cryptographic data to the hypervisor.

[0062] The TLS protocol can be used to establish the first secure channel even if the virtual machines and the verifying entity subsequently use another protocol.

[0063] In one particular embodiment, the TLS protocol is also used to establish the second secure channels. More specifically: The cryptographic data sent by the verifying entity in the first secure TLS channel includes, associated with each virtual machine, a ticket and a one-time random variable; the root of trust is configured to calculate, for each virtual machine, a pre-shared key using the one-time random variable associated with that virtual machine; the pre-shared key is used by the virtual machine to request the establishment of a second session with the verifying entity, this second session constituting a resumption of the first session in accordance with the TLS protocol; the second secure channel used by a virtual machine to send its attestation data to the verifying entity being established within the framework of said second session.

[0064] Using the TLS protocol makes it advantageous to establish second channels quickly. Brief description of the drawings

[0065] Other features and advantages of the present invention will become apparent from the description below, with reference to the accompanying drawings, which illustrate an example of an embodiment without being limiting in any way. In the figures: there figure 1 The already described architecture represents the architecture of a virtualized computing platform conforming to the state of the art; figure 2A The already described illustrates the single-channel, in-depth attestation mechanism of the prior art; the figure 2B The already described illustrates the mechanism for in-depth, multi-channel attestation of the state of the art; the figure 3 represents, in the form of a flowchart, the main steps of a thorough attestation process conforming to the invention; the figure 4 illustrates known concepts of the TLS protocol useful for understanding a particular embodiment of the invention; the figure 5illustrates a particular embodiment of the invention in which the verification entity and the virtualized computing platform communicate in accordance with the TLS protocol; and the figure 6 represents a verification entity conforming to a particular embodiment of the invention. Description of the implementation methods

[0066] There figure 3 represents in the form of an organizational chart the main steps of a process for in-depth PAE certification of a virtualized PIV IT platform conforming to the invention.

[0067] This process conforms to a particular embodiment of the invention.

[0068] It is implemented by the virtualized PIV computer platform according to the invention and by a verification entity EV according to the invention.

[0069] More precisely : The virtualized IT platform PIV implements steps F10 to F60 of a PFA process for providing attestations in accordance with the invention; and the verification entity EV implements steps D10 to D60 of a PDA process for requesting attestations in accordance with the invention.

[0070] In this embodiment, the VMM hypervisor of the PIV platform and the verification entity establish a first secure CS0 channel. The establishment of this first CS0 channel corresponds to a step D10 of the PDA attestation request process and a step F10 of the PFA attestation delivery process.

[0071] During step F20 of the attestation delivery process, the VMM hypervisor sends attestation data for itself to the VM verification entity via the first secure channel CS0. This data is obtained by the hypervisor using services from the hardware layer's Root of Trust (RoT). It is received by the EV verification entity during step D20 of the attestation request process.

[0072] During a D30 step, the EV verification entity sends at least one TOK cryptographic data to the VMM hypervisor, via the first secure channel CS0. This TOK cryptographic data is intended for the RoT root of trust of the PIV platform. This TOK cryptographic data is received by the VMM hypervisor during an F30 step.

[0073] The VMM hypervisor stores the TOK cryptographic data in said root of trust RoT during an F40 step.

[0074] Next, each virtual machine on the PIV platform establishes a secure channel with the EV verification entity. This establishment corresponds to step D50 of the PDA attestation request process and step F50 of the PFA attestation delivery process.

[0075] According to the invention, primitives of the root of trust RoT applied to the cryptographic data TOK are required for the establishment of this second secure channel.

[0076] During an F60 step, each virtual machine sends its own attestation data to the EV verification entity in the secure channel established for that virtual machine.

[0077] This attestation data is received by the EV verification entity during a D60 step.

[0078] According to the invention, the secure channels established between each of the virtual machines and the verification entity are established using primitives from the platform's root of trust applied to the cryptographic data sent by the verification entity in the first secure channel established with the VMM hypervisor.

[0079] Therefore, only layers capable of using root of trust services (directly for the VMM hypervisor or indirectly for VM virtual machines) can originate these secure channels.

[0080] The invention thus provides proof of a verifiable and explicit link between the hardware layer that hosts the RoT root of trust, the VMM hypervisor, and the virtual machines of the PIV virtualized computing platform.

[0081] In the embodiment described here, the EV verification entity produces a comprehensive attestation report of the PIV platform during a D70 step.

[0082] In the embodiment described here, this report is positive if secure channels have been established between each virtual machine and the EV verification entity. This report includes: the hypervisor attestation data; and the attestation data of each virtual machine.

[0083] In one embodiment of the invention, the verification entity EV and the virtualized computing platform PIV communicate using the TLS protocol, the concepts of which, important for understanding this embodiment of the invention, will now be described with reference to the figure 4 .

[0084] This figure illustrates more precisely the operations performed by a CLT_TLS client and an SRV_TLS server in the implementation of the TLS protocol.

[0085] The TLS protocol includes a handshake protocol (HS) which authenticates the communicating parties, negotiates the cryptographic modes and parameters allowing the CLT_TLS client and the SRV_TLS server to calculate, during a T10 step, a shared master secret (MS).

[0086] This shared master secret MS is used by the parties to derive their cryptographic keys, such as channel encryption keys.

[0087] During a T20 step, the SRV_TLS server randomly generates a NONCEi nonce, which is a one-time random or pseudo-random number for each VMi virtual machine. The server uses the MS shared master secret to calculate TICKi tickets, using these NONCEi nonces. The SRV_TLS server then sends the TICKi tickets associated with their corresponding NONCEi nonces to the CLT_TLS client.

[0088] More specifically, the SRV_TLS server calculates as many TICKi tickets as it plans to resume sessions ("session resumption" in English) initiated by the CLT_TLS client.

[0089] During a T30 step, the SRV_TLS server and the CLT_TLS client calculate, for each TICKi ticket, a pre-shared key PSKi obtained using the shared master secret MS and the nonce NONCEi associated with that ticket.

[0090] These TICKi tickets can be used by the CLT_TLS client to quickly start future negotiations.

[0091] More specifically, when the CLT_TLS client wants to start a new session based on a previous session (in English "resume"), the client device sends a TICKi ticket in its first message to the server during a T40 step.

[0092] During a T45 step, the CLT_TLS client and the SRV_TLS server calculate a new shared secret MSi' using their respective pre-shared PSKi keys.

[0093] This new shared secret MSi' is used to set up a new secure channel as part of the new session requested by the VMi virtual machine with the EV verification entity.

[0094] This mechanism of the TLS protocol advantageously simplifies the exchange of keys, parameters, and server authentication for the new session (general step T50). If both parties accept this new session, in other words, if the new secrets determined by the CLT_TLS client and the SRV_TLS server match, this implies that the same CLT_TLS and SRV_TLS parties participated in the initial HS negotiation phase.

[0095] For more information on the TLS protocol, those skilled in the art can refer to reference [TLS].

[0096] There figure 5 illustrates the embodiment of the invention in which the EV verification entity conforming to the invention and the PIV virtualized computing platform conforming to the invention communicate according to the TLS protocol.

[0097] In this embodiment: The EV verification entity has an SRV_TLS server; the VMM hypervisor has a CLT_TLS_VMM client; and each VMi virtual machine has a CLT_TLS_VMi client.

[0098] In an unrepresented preliminary step, the EV verification entity sends a message to the virtualized computing platform so that the VMM hypervisor's CLT_TLS_VMM client makes a session establishment request to the EV verification entity's SRV_TLS server.

[0099] During a general step E50, the SRV_TLS server of the verification entity EV and the CLT_TLS_VMM client of the hypervisor VMM perform, as part of an initial session S0, a TLS-compliant handshake similar to the HS phase described previously with reference to the figure 4 .

[0100] It is recalled that this HS negotiation phase includes in particular the calculation by the CLT_TLS_VMM client of the VMM hypervisor on the one hand and by the SRV_TLS server of the EV verification entity on the other hand of a shared master secret MS.

[0101] To calculate this shared master secret (MS), the CLT_TLS_VMM client of the VMM hypervisor invokes primitives from the PIV platform's Root of Trust (RoT). These primitives calculate the MS and securely store it in the RoT. In other words, the hypervisor's CLT_TLS_VMM client delegates the calculation of the MS to the RoT.

[0102] The negotiation phase establishes, for the duration of the first session S0, a secure channel CS0 between the verification entity EV and the hypervisor VMM.

[0103] This secure CS0 channel is used by the VMM hypervisor to communicate (step E54) its DA_VMM attestation data to the EV verification entity, this data being obtained by the hypervisor using the services of the RoT root of trust.

[0104] Still within the same S0 session, the EV verification entity's SRV_TLS server sends (step E56) to the CLT_TLS_VMM client as many TICKi tickets as there are VMi virtual machines in the PIV virtualized computing platform, each ticket being associated with a NONCEi nonce. This number of virtual machines may have been previously communicated by the VMM hypervisor to the EV verification entity. Indeed, the SRV_TLS server expects each VMi virtual machine to initiate its own session with it to communicate its DA_VMi attestation data.

[0105] During an E58 step, the CLT_TLS_VMM client of the VMM hypervisor communicates these ticket|nonce TICKi|NONCEi pairs to the RoT root of trust of the PIV platform.

[0106] During an E60 step, the SRV_TLS server and the RoT root of trust calculate, for each TICKi ticket, a pre-shared key PSKi from the shared master secret MS and the nonce NONCEi associated with that ticket.

[0107] During an E62 step, the virtualized vRoTi trust module associated with each VMi virtual machine obtains a TICKi ticket.

[0108] Once the tickets and nonces TICKi|NONCEi have been sent by the EV verification entity (step E56) to the CLT_TLS_VMM client of the VMM hypervisor, the S0 session ends.

[0109] During an E64 step, the CLT_TLS_VM1 client of the virtual machine VM1 requests to start a new S1 session with the SRV_TLS server of the verification entity EV by sending it the ticket TICK1. A new secret MS1' is calculated by the root of trust RoT and by the SRV_TLS server from their respective values ​​of the pre-shared key PSK1.

[0110] This new session is established if the new MS1 secrets are identical and proceeds in accordance with steps T45 / T50 described previously with reference to the figure 4 .

[0111] A secure CS1 channel is established, for the duration of this S1 session, between the EV verification entity and the VM1 virtual machine.

[0112] This secure CS1 channel is used by the virtual machine VM1 to communicate (step E66) its DA_VM1 attestation data to the EV verification entity, this data being obtained by the virtual machine VM1 using the services of the virtualized root of trust vRoT1.

[0113] Once the DA_VM1 attestation data has been sent to the EV verification entity, the S1 session ends.

[0114] During an E68 step, the CLT_TLS_VM2 client of the virtual machine VM2 requests to start a new S2 session with the SRV_TLS server of the verification entity EV by sending it the TICK2 ticket. A new MS2 secret is calculated by the root of trust (RoT) and by the SRV_TLS server from their respective values ​​of the pre-shared key PSK2.

[0115] A secure CS2 channel is established, for the duration of this S2 session, between the EV verification entity and the VM2 virtual machine.

[0116] This secure CS2 channel is used by the virtual machine VM2 to communicate (step E70) its DA_VM2 attestation data to the EV verification entity, this data being obtained by the virtual machine VM2 using the services of the virtualized root of trust vRoT2.

[0117] Once the DA_VM2 attestation data has been sent to the EV verification entity, the S2 session ends.

[0118] The EV verification entity thus received: the DA_VMM attestation data of the hypervisor; the DA_VMi attestation data of each of the VMi virtual machines.

[0119] The secure channels CS1 and CS2 were established based on the TICK1 and TICK2 tickets received from the verification entity EV and the pre-shared keys PSK1 and PSK2 calculated by the root of trust RoT based on the shared master secret MS and the nonces NONCE1 and NONCE2. Furthermore, sessions S1 and S2 are sessions derived from the first session S0 of the HS negotiation phase.

[0120] Therefore, only layers able to use the RoT root of trust services (directly for the VMM hypervisor or indirectly for VMi virtual machines via the virtualized vRoTi roots of trust) can originate these S1 and S2 linked sessions.

[0121] The invention thus provides proof of a verifiable and explicit link between the CM hardware layer which hosts the RoT root of trust, the VMM hypervisor, and the VM1, VM2 virtual machines of the PIV virtualized computing platform.

[0122] There figure 6 represents a verification entity EV according to the invention. In the embodiment described here, this verification entity EV has the hardware architecture of a computer. It comprises a processor 21, a read-only memory (ROM) 22, a random-access memory (RAM) 23, and communication means 24.

[0123] The ROM 22 type read-only memory constitutes a recording medium within the meaning of the invention. It comprises a computer program according to the invention, this program comprising instructions capable of implementing a method for requesting certificates according to the invention, the main steps of which have been described with reference to the figure 3 .

[0124] When the processor 21 executes the computer program, the EV verification entity is able to establish, using communication means 24, a first secure channel with the VMM hypervisor of a virtualized computing platform.

[0125] In one embodiment of the invention, the read-only memory 22 includes a protocol stack for installing an SRV_TLS server in the EV verification entity, this SRV_TLS server being capable of establishing a secure communication channel with a CLT_TLS client installed in the VMM hypervisor, in accordance with the TLS protocol.

[0126] The 24 communication methods are hardware and software. They are capable of receiving DA_VMM attestation data from the hypervisor in this first secure channel.

[0127] When processor 21 is configured to send at least one cryptographic data to the VMM hypervisor in the first secure channel using communication means 24. In particular, in the embodiment in which the EV verification entity and the PIV platform use the TLS protocol, processor 21 is configured to calculate the TICKi tickets and send them in the secure communication channel to the VMM hypervisor.

[0128] When the processor 21 executes the computer program, the EV verification entity is also able to establish, using communication means 24, a secure channel with each of the virtual machines of the PIV platform.

[0129] The EV verification entity receives the DA_VMi attestation data from these virtual machines, in these secure channels, via the 24 communication means.

[0130] The virtualized PIV computing platform can have the hardware architecture of a conventional computer. The invention does not specify the type of hypervisor. References:

[0131] [TCG]: TCG Virtual Platform WG: Virtualized Trusted Platform Architecture Specification. Specification Version 1.0. Revision 0.26. September 27, 2011. [NFV]: Network Functions Virtualization (NFV); Trust; Report on Attestation Technologies and Practices for Secure Deployments. ETSI GR NFV-SEC 007 v1.1.1 (2017-10). [PRA]: G. Coker, J. Guttman, P. Loscocco, A. Herzog, J. Milien, B. O'Hanlon, J. Ramsdell, A. Segall, J. Sheehy, B. Sniffen “Principles of Remote Attestation. Int. J.Inf. Secur. 1, 2 (June 2011), 63-81. DOI=http: / / dx.doi.org / 10.1007 / s10207-011-0124-7. [TLS]: E. Rescorla, “The Transport Security Layer (TLS) Protocol Version 1.3”, RFC 8446, DOI 10.17487 / RFC8446, August 2018.

Claims

1. Method (PFA) for providing attestations that is implemented by a virtualized computing platform (PIV) comprising a root of trust (RoT), a hypervisor (VMM) and at least one virtual machine (VM1, VM2), the hypervisor (VMM) implementing one virtualized root of trust (vRoT1, vRoT2) per virtual machine (VM1, VM2) and providing services of the root of trust (RoT), this method comprising: - a step of setting up (F10) a first secure channel (CSO) between said hypervisor (VMM) and a verification entity (EV); - a step of sending (F20) attestation data (DA_VMM) of this hypervisor over said first secure channel (CSO) to the verification entity (EV), said attestation data being obtained using services of said root of trust (RoT) ; - a step of said hypervisor (VMM) receiving (F30), over said first secure channel (CS0), from said verification entity (EV), at least one cryptographic datum (TOK) intended for said root of trust (RoT), with a view to setting up (F50) a second secure channel (CS1, CS2) between each said virtual machine (VM1, VM2) and said verification entity (EV); - a step of setting up (F50) the second secure channel (CS1, CS2) between each said virtual machine (VM1, VM2) and said verification entity (EV), primitives of the root of trust (RoT) that are applied to a said cryptographic datum (TOK) being required to set up this second secure channel (CS1, CS2); - a step of sending (F60) attestation data (DA_VM1, DA_VM2) of each said virtual machine (VM1, VM2) over the second secure channel (CS1, CS2) set up for said virtual machine (VM1, VM2), said attestation data (DA_VM1, DA_VM2) being obtained by said virtual machine (VM1, VM2) using services of the virtualized root of trust (vRoT1, vRoT2) associated with said virtual machine (VM1, VM2).

2. Method (PDA) for requesting attestations from a virtualized computing platform (PIV) comprising a root of trust (RoT), a hypervisor (VMM) and at least one virtual machine (VM1, VM2), the hypervisor (VMM) implementing one virtualized root of trust (vRoT1, vRoT2) per virtual machine (VM1, VM2) and providing services of the root of trust (RoT), a said virtual machine (VM1, VM2) obtaining attestation data (DA_VM1, DA_VM2) using services of the virtualized root of trust (vRoT1, vRoT2) associated with this virtual machine (VM1, VM2), this method being implemented by a verification entity (EV) and comprising: - a step of setting up (D10) a first secure channel (CSO) between said verification entity (EV) and said hypervisor (VMM); - a step of receiving (D20) attestation data (DA_VMM) of said hypervisor over the first secure channel (CS0), the attestation data (DA_VMM) being obtained using services of said root of trust (RoT); - a step of sending (D30), to said hypervisor (VMM), over said first secure channel (CS0), at least one cryptographic datum (TOK) intended for the root of trust (RoT), with a view to setting up (D50) a second secure channel (CS1, CS2) between said verification entity (EV) and each said virtual machine (VM1, VM2); - a step of setting up (D50) the second secure channel (CS1, CS2) between said verification entity (EV) and each said virtual machine (VM1, VM2), primitives of the root of trust (RoT) that are applied to said at least one cryptographic datum (TOK) being required to set up this second secure channel (CS1, CS2); - a step of receiving (D60), from each virtual machine (VM1, VM2), over the second secure channel (CS1, CS2) set up for said virtual machine (VM1, VM2), attestation data (DA_VM1, DA_VM2) of this virtual machine (VM1, VM2).

3. Method (PDA) for requesting attestations according to Claim 2, further comprising a step of producing (D70) a deep-attestation report (ATT_REP) for said platform (PIV), this report being positive if said second secure channel (CS1, CS2) has been set up for said virtual machine (VM1, VM2), said report (ATT_REP) comprising: - the attestation data (DA_VMM) of the hypervisor; and - the attestation data (DA_VMi) of each virtual machine (VMi).

4. Method (PDA, PFA) according to any of Claims 1 to 3, wherein: - said verification entity (EV) comprises a server (TLS SRV_TLS); - said hypervisor (VMM) comprises a client (TLS CLT_TLS_VMM), said client and said server being configured to set up between them said first secure channel (CSO) in the context of a first session (S0) according to the TLS protocol, said first secure channel being used: - by said hypervisor to send (F20) its said attestation data (DA_VMM) to the verification entity (EV); and - by said verification entity (EV) to send (D30) said at least one cryptographic datum (TOK) to said hypervisor (VMM) .

5. Method (PDA, PFA) according to Claim 4, wherein: - said at least one cryptographic datum comprises, associated with each said virtual machine (VM1, VM2), a ticket (TICKi) and a one-time random variable (NONCEi); - said root of trust (RoT) is configured to compute, for each virtual machine (VM1), a pre-shared key (PSK1) using the one-time random variable (NONCE1) associated with this virtual machine; - said shared key (PSK1) is used by said virtual machine to request (F50) the set-up of a second session (S1) with said verification entity (EV), said second session (S1) being a resumption of said first session (S0) according to the TLS protocol; - said second secure channel (CS1) used by said virtual machine (VM1) to send (F60) its attestation data (DA_VM1) to said verification entity is set up (F50) in the context of said second session (S1).

6. Virtualized computing platform (PIV) comprising a root of trust (RoT), a hypervisor (VMM) and at least one virtual machine (VM1, VM2), the hypervisor (VMM) implementing one virtualized root of trust (vRoT1, vRoT2) per virtual machine (VM1, VM2) and offering services of the root of trust (RoT), wherein: - said hypervisor (VMM) is configured to: - set up a first secure channel (CSO) with a verification entity (EV); - obtain attestation data (DA_VMM) of this hypervisor using services of said root of trust (RoT); - send said attestation data (DA_VMM) of this hypervisor over said first secure channel (CSO) to the verification entity (EV); - receive, from said verification entity (EV), over said first secure channel (CS0), at least one cryptographic datum (TOK) intended for the root of trust (RoT), with a view to setting up a second secure channel (CS1, CS2) between each said virtual machine (VM1, VM2) and said verification entity (EV); - each said virtual machine (VM1) is configured to: - set up the second secure channel (CS1) between this virtual machine and said verification entity (EV), primitives of the root of trust (RoT) that are applied to a said cryptographic datum (TOK) being required to set up this second secure channel (CS1); - sending attestation data (DA_VM1) of said virtual machine (VM1) over the second secure channel (CS1) set up for this virtual machine (VM1), these attestation data (DA_VM1) being obtained by said virtual machine (VM1) using services of a virtualized root of trust (vRoT1) associated with said virtual machine (VM1).

7. Verification entity (EV) configured to request attestations from a virtualized computing platform (PIV) comprising a root of trust (RoT), a hypervisor (VMM) and at least one virtual machine (VM1, VM2), the hypervisor (VMM) implementing one virtualized root of trust (vRoT1, vRoT2) per virtual machine (VM1, VM2) and providing services of the root of trust (RoT), a said virtual machine (VM1, VM2) obtaining attestation data (DA_VM1, DA_VM2) using services of the virtualized root of trust (vRoT1, vRoT2) associated with this virtual machine (VM1, VM2), said verification entity (EV) comprising: - a module for setting up a first secure channel (CSO) between said verification entity (EV) and said hypervisor (VMM) ; - a communication module configured to: - receive attestation data (DA_VMM) of said hypervisor over said first secure channel (CS0), the attestation data (DA_VMM) being obtained using services of said root of trust (RoT); - send at least one cryptographic datum (TOK) to said hypervisor (VMM) over said first secure channel (CS0), said at least one cryptographic datum (TOK) being intended for the root of trust (RoT), with a view to setting up a second secure channel (CS1, CS2) between said verification entity (EV) and each said virtual machine (VM1, VM2); - a module for setting up the second secure channel (CS1, CS2) between said verification entity (EV) and each said virtual machine (VM1, VM2), primitives of the root of trust (RoT) that are applied to said at least one cryptographic datum (TOK) being required to set up this second secure channel (CS1, CS2); - a communication module configured to receive, from each virtual machine (VM1, VM2), over the second secure channel (CS1, CS2) set up for said virtual machine (VM1, VM2), attestation data (DA_VM1, DA_VM2) of this virtual machine (VM1, VM2).

8. Set of computer programs comprising: - a computer program (CLT_TLS_VMM) on an information medium, said program being capable of being implemented by a hypervisor (VMM) of a virtualized computing platform (PIV), the virtualized computing platform (PIV) comprising a root of trust (RoT) and at least one virtual machine (VM1, VM2), this program comprising instructions configured to: - set up a first secure channel (CSO) between said hypervisor (VMM) and a verification entity (EV); - send attestation data (DA_VMM) of this hypervisor over said first secure channel (CSO) to the verification entity (EV), said attestation data being obtained using services of the root of trust (RoT) of said platform (PIV) ; - receive, by means of said hypervisor, at least one cryptographic datum (TOK) from said verification entity (EV), over said first secure channel (CS0), this cryptographic datum (TOK) being intended for the root of trust (RoT), with a view to setting up a second secure channel (CS1, CS2) between each said virtual machine (VM1, VM2) and said verification entity (EV); and - a computer program on an information medium, an instance (CLT_TLS_VM1, CLT_TLS_VM2) of this program being capable of being implemented by each said virtual machine (VM1, VM2) of said virtualized computing platform (PIV), this instance of the program comprising instructions configured to: - set up the second secure channel (CS1) between said virtual machine (VM1) and said verification entity (EV), primitives of the root of trust (RoT) that are applied to a said cryptographic datum being required to set up this second secure channel (CS1); - send attestation data (DA_VM1) of said virtual machine (VM1) over the second secure channel (CS1), said attestation data being obtained by said virtual machine (VMi) using services of a virtualized root of trust (vRoT1) of said hypervisor (VMM) associated with said virtual machine (VM1) and providing services of said root of trust (RoT).

9. Computer program on an information medium, said program being capable of being implemented by a computer, this program comprising instructions configured to implement a method (PDA) for requesting attestations according to any of Claims 2 to 5.

10. Recording medium that is readable by a computer (PIV, EV) and on which is recorded at least: - a computer program according to Claim 9; or - a computer program of a set of computer programs according to Claim 8.