Method for providing attestations in a multi-tenant virtualized computing platform

Abstract

The invention relates to a method for providing attestations for a virtualized computing platform communicating with a relay server, the relay server being configured to generate a vector commitment from a random vector transmitted by the hypervisor of the virtualized computing platform and generate a zero-knowledge proof from this vector commitment, the proof being generated so as to prove that the hypervisor is in a valid configuration and that the link between the hypervisor and a virtual machine is valid, without disclosing the exact configuration thereof.

Description

Method for providing attestations in a multi-tenant virtualized IT platform

[0001] This presentation concerns the field of virtualized computing platforms and more specifically attestations, particularly in-depth attestations, in such platforms.

[0002] It is known to use attestation provision mechanisms allowing a target to authenticate itself to a verifier by demonstrating that said target meets certain properties.

[0003] Traditionally, attestation mechanisms take the form of a "challenge-response" protocol in which the verifier sends a challenge to a target along with a random element, called a nonce. The target generates proofs in response to this challenge and sends them to the verifier. The proof is usually based on a root of trust of the target. The proof generally consists of demonstrating, through the provision of attestations, that the target is in a valid state, in other words, in a particular configuration, or satisfies a particular property, notably that it is in an uncorrupted configuration.

[0004] In the specific case of virtualized computing platforms, it is particularly known to use deep attestation mechanisms, commonly called "deep attestations" in English.

[0005] A virtualized computing platform typically includes a hardware layer, a virtualization layer, commonly called a "hypervisor", and a virtual machine layer.

[0006] The hardware layer includes a root of trust (RoT). This root of trust is configured to perform one or more specific functions to secure the virtualized computing platform. The behavior of the root of trust is assumed to be known and reliable, as any faulty behavior should be undetectable. The root of trust can be composed of software components. Preferably, it takes the form of a hardware module.

[0007] The hypervisor controls the allocation of hardware resources to be assigned to virtual machines in order to allow the parallel operation of these virtual machines.

[0008] Each virtual machine controlled by the hypervisor can access a virtualized root of trust, vRoT ("virtualized Root of Trust"), of the hypervisor.

[0009] The purpose of deep attestation mechanisms is to provide evidence demonstrating that not only the virtual machines but also the hypervisor and the link between the hypervisor and the virtual machines are in a valid state.

[0010] A well-known method for providing comprehensive attestations in virtualized computing platforms is called "single-channel" attestation. In this method, the verifier has only one entry point to the target. The verifier sends a challenge to the virtual machine, which generates an attestation proving that the virtual machine is in a valid state. The verifier then forwards the challenge and attestation to the hypervisor, which in turn generates its own attestation proving that it is in a valid state based on the virtual machine's attestation, thus providing a composite attestation. This composite attestation is then sent to the verifier in response to the challenge. One drawback of this method is the generation of a new hypervisor attestation for each virtual machine. Therefore, this method is neither scalable nor efficient.

[0011] Another method, known as multi-channel, overcomes the drawback of the single-channel method by sending a challenge to the hypervisor and virtual machines separately, making implementation more efficient. However, this method does not allow verification of the validity of the link between the hypervisor and the virtual machines.

[0012] Ghada Arfaoui, Pierre-Alain Fouque, Thibaut Jacques, Pascal Lafourcade, Adina Nedelcu, Cristina Onete, and Léo Robert, in their article "A Cryptographic View of Deep-Attestation, or How to Do Provably-Secure Layer-Linking," describe a method combining these two approaches. This method involves generating two separate attestations, similar to a multi-channel approach. The difference lies in the content of the hypervisor attestation, which is generated to provide proof that the link between the virtual machine and the hypervisor is valid. Specifically, the hypervisor attestation includes a list of attestation keys corresponding to the virtualized roots of trust of the virtual machines linked to the hypervisor.

[0013] This method is particularly advantageous when dealing with a virtualized IT platform hosted by a single tenant.

[0014] However, it is important to note that components of a virtualized IT platform can belong to different tenants. Therefore, several auditors may request attestations for components belonging to a particular tenant. In this case, it is necessary to ensure the security and confidentiality of other components—that is, components not belonging to the tenant for which attestation is requested.

[0015] Some methods have suggested exploiting the SNARKS cryptographic protocol based on cryptographic techniques such as elliptic curves and hash functions, providing zero-knowledge proofs. However, the proposed methods introduce significant computational complexity at the target level for generating the attestations.

[0016] Therefore, there is a need to provide robust attestations that are at least partially free from the drawbacks inherent in the aforementioned known methods. In particular, there is a need for robust attestations that allow for the efficient and simple verification of the validity status of targets in a virtualized computing platform. There is also a need to improve confidentiality in attestation exchanges, especially in a multi-tenant virtualized computing platform—that is, a platform in which resources are held by multiple tenants.

[0017] The invention aims to meet all or part of these needs.

[0018] The invention relates to a method for providing attestations in 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, the method, implemented by a relay server, comprising: - a step of transmitting to the virtual machine and the hypervisor, via first and second secure channels respectively established between said virtual machine and the relay server and between the hypervisor and the relay server, an attestation request transmitted to the relay server by a verification entity via a third secure channel established between the verification entity and the relay server; - a step of generating a vector commitment from a vector itself generated by the hypervisor from at least one public key of virtual machine attestation;- a step of transmitting the vector commitment via the second secure channel to the hypervisor; - a step of receiving, via the first and second secure channels respectively, a virtual machine attestation generated by the virtual machine from at least the virtualized root of trust and a hypervisor attestation generated by the hypervisor from at least the root of trust and the vector commitment; - a step of generating a proof bearing an indication that the hypervisor is in one configuration among a set of valid configurations and an indication that the virtual machine is associated with said hypervisor, the proof being generated from the hypervisor attestation, the vector commitment and a cryptographic proof protocol with zero disclosure of knowledge;- a step of sending at least the virtual machine attestation, proof and vector commitment to the verification entity, via the third secure channel.;

[0019] Correspondingly, the invention relates to a relay server configured to provide 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 to a verification entity, comprising: a module for establishing a first secure channel between at least one virtual machine and the relay server, a module for establishing a second secure channel between the hypervisor and the relay server, a module for establishing a third secure channel between a verification entity and the relay server, a communication module configured to: - Transmit an attestation request via the first secure channel, - Receive, via the first secure channel, a virtual machine attestation generated from at least one virtualized root of trust.A communication module configured to: - Transmit an attestation request via the second secure channel, - Receive, via the second secure channel, a vector generated from at least one virtual machine attestation public key, - Transmit a vector pledge via the second secure channel, - Receive, via the second secure channel, a hypervisor attestation generated from at least one root of trust and a vector pledge; a communication module configured to: - Receive an attestation request via the third secure channel, - Transmit a virtual machine attestation, a proof, and a vector pledge via the third secure channel; a generation module configured to generate a vector pledge from a vector; a verification module configured to verify at least one hypervisor attestation.a generation module configured to generate a proof such that it carries an indication that the hypervisor is in one of a set of valid hypervisor configurations and an indication that the virtual machine is associated with said hypervisor, the proof being generated from a hypervisor attestation, a vector commitment, and a zero-knowledge cryptographic proof protocol.

[0020] The method of generating proof from vector commitment offers the advantage of proving, through a simple and easy-to-implement procedure, that the link between the virtual machine and the hypervisor exists and is valid, without disclosing all the virtual machines controlled by the hypervisor. In particular, vector commitment ensures the confidentiality of the identities of the virtual machines controlled by the hypervisor and, a fortiori, their configurations.

[0021] The attestation key(s) from which the vector is generated are public attestation keys of the virtualized roots of trust of all or part of the virtual machines held by the holder of the verification entity, preferably of all the virtual machines held by said holder.

[0022] Preferably, the vector is generated from several virtual machine attestation public keys, including at least the attestation public key of the virtual machine for which attestation is requested.

[0023] The introduction of an intermediate entity, in other words a relay server, between the virtualized IT platform and the verification entity or entities also allows control of communication with the verification entities and therefore the sending of attestation requests to the virtualized IT platform.

[0024] In particular, only the intermediate entity, in other words only the relay server, can be authorized to transmit attestation requests to the virtualized IT platform, allowing for improved security and confidentiality.

[0025] Finally, the use of a vector commitment generated from a vector and then sending a zero-knowledge proof according to the invention advantageously masks the exact configuration of the virtualized computing platform, particularly the links between the platform's virtual machines and the hypervisor, while still performing the necessary checks. Thus, a verification entity can efficiently and easily verify the configuration of the resources that concern it, thereby ensuring the confidentiality of the configurations of resources that do not concern it.

[0026] The confidentiality of the hypervisor configuration can be advantageously ensured through the cryptographic zero-knowledge proof protocol, thus enabling the provision of a thorough attestation preserving the confidentiality not only of the identity of virtual machines controlled by the hypervisor other than the one for which an attestation is requested, but also of the hypervisor configuration which may belong to a tenant other than the tenant of the virtual machine for which an attestation is requested.

[0027] In response to an attestation request from a verification entity, the relay server will advantageously send a response indicating to the verification entity whether the hypervisor is in a valid configuration or not and indicating that it has performed the appropriate checks.

[0028] The generation of virtual machine and hypervisor attestations can be done using any known deep attestation generation method. In particular, they can be generated using a method such as the one described in the publication by Ghada Arfaoui, Pierre-Alain Fouque, Thibaut Jacques, Pascal Lafourcade, Adina Nedelcu, Cristina Onete, and Léo Robert: “A Cryptographic View of Deep-Attestation, or How to Do Provably-Secure Layer-Linking,” briefly described above.

[0029] Virtual machine and hypervisor attestations are generated from a predefined signature protocol.

[0030] The signature protocol used to generate attestations may include the signature σ of a message m according to a signature scheme based on a private-public key pair (sk, pk).

[0031] The cryptographic zero-knowledge proof protocol is notably a zero-knowledge-succinct non-interactive ARgument of Knowledge type algorithm, commonly known by the acronym ZK-SNARK (“Zero-Knowledge Succinct Non-interactive ARgument of Knowledge”).

[0032] The vector commitment consists of a commitment chain providing a list of values ​​rather than a single value. Verification by the verifying entity of the vector commitment provides proof as to whether a value belongs to the vector commitment or not; in other words, during verification, the verifying entity only partially opens the transmitted list, accessing each value in the list requiring the provision of specific additional information distinct from that of the other values ​​in the list.

[0033] Generating a vector commitment advantageously allows the aggregation of several requests into one, limiting the congestion of the RoT root of trust.

[0034] The vector commitment preferably has a constant size to prevent information leakage from other virtual machines. Therefore, when the number of requests is less than the expected size of the vector, empty positions are preferably filled with random values, called "dummy" values, which have no use for verification and should not be confused with nonces. These random values ​​must be selected in such a way as not to impact the verification process.

[0035] In particular embodiments, the attestation provision process includes a verification step that the verifying entity is authorized to transmit said attestation request to the virtual machine and the hypervisor; preferably the relay server performs this verification before transmitting, if necessary, the attestation request to the virtual machine and the hypervisor.

[0036] The invention also relates to a method of generating attestations by a virtualized computer 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, the method comprising: - a step of receiving an attestation request transmitted by the relay server via first and second secure channels respectively established between said virtual machine and the relay server and between the hypervisor and said relay server; - a step of generating and transmitting a vector by the hypervisor, from at least one public key of virtual machine attestation, to the relay server via the second secure channel;- a step of generating a virtual machine attestation generated by the virtual machine from at least the virtualized root of trust, and a hypervisor attestation generated by the hypervisor from at least the root of trust and a vector commitment generated and transmitted by the relay server from the vector; - a step of transmitting, via the first and second secure channels, the virtual machine and hypervisor attestations, respectively, to the relay server.

[0037] Correspondingly, the invention relates to a virtualized computing platform comprising a root of trust, a hypervisor, and at least one virtual machine. The hypervisor implements a virtualized root of trust for each virtual machine, wherein: Each virtual machine is configured to: - Establish a first secure channel with a relay server, - Receive an attestation request via the first secure channel, - Generate an attestation from at least one virtualized root of trust in response to said attestation request, - Transmit said attestation via the first secure channel. The hypervisor is configured to: - Establish a second secure channel with the relay server, - Receive the attestation request via the second secure channel, - Generate a vector from at least one virtual machine attestation public key, - Transmit the vector via the second secure channel, - Receive, via the second secure channel,a vector commitment generated from the vector, - Generate an attestation from at least the root of trust and the vector commitment, - Transmit said attestation via the second secure channel.

[0038] The invention also relates to a method for verifying attestations of a virtualized computer 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, the method, implemented by a verification entity, comprising: - a step of sending an attestation request to the relay server via a third secure channel established between the verification entity and the relay server;- a step of receiving, via the third secure channel, at least: - a virtual machine attestation transmitted by the relay server and generated by the virtual machine of the virtualized computing platform, - a proof generated by the relay server bearing an indication that the hypervisor is in one of a set of valid hypervisor configurations and an indication that the virtual machine is associated with the hypervisor, the proof being generated from at least one vector commitment, a hypervisor attestation and a zero-knowledge cryptographic proof protocol, and - the vector commitment; - a step of verifying the virtual machine attestation and the proof.

[0039] Correspondingly, the invention relates to a verification entity configured to request attestations from a virtualized computing platform via a relay server, the 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, the verification entity comprising: a module for establishing a secure channel with the relay server, a communication module configured to: - Send an attestation request via the third secure channel, - Receive a virtual machine attestation, a proof and a vector commitment, via the third secure channel, a verification module configured to: - Verify a virtual machine attestation, and a zero-knowledge proof.

[0040] The verification may include checking that a public key contained in the virtual machine attestation is the same as the public key of the virtual machine contained in the hypervisor attestation. In other words, it may be verified that the vector commitment contains a virtual machine public key that matches the public key of the virtual machine contained in the virtual machine attestation.

[0041] The invention further relates to a communication system comprising: - a virtualized computer platform according to the invention, - a relay server according to the invention, - one or more verification entities according to the invention.

[0042] In certain embodiments, the virtualized computing platform has a cloud computing architecture. In particular, the virtualized computing platform may have a Network Function Virtualization (NFV) architecture, meaning it is based on the virtualization of network functions, or it may be a mobile communications network.

[0043] In particular embodiments, all or part of the steps of a process according to the invention, preferably all the steps, are implemented by computer program instructions.

[0044] Thus, the invention also relates to a computer program comprising code instructions, which when executed by means of a computer enable the implementation of a process according to the invention, as well as a computer-readable recording medium on which is recorded a computer program comprising instructions for the execution of the steps of a process according to the invention.

[0045] The aforementioned features and advantages, as well as others, will become apparent upon reading the detailed description that follows. This detailed description refers to the attached drawings.

[0046] The attached drawings are schematic and are primarily intended to illustrate the principles of the presentation.

[0047] In these drawings, from one figure to another, identical elements (or parts of elements) are identified by the same reference symbols.

[0048] Lare represents a system according to the invention comprising a virtualized computer platform, a relay server and verification entities,

[0049] Figures 2 and 3 illustrate the steps in an example of implementing a process according to the invention.

[0050] This is an example of the functional architecture of a relay server according to the invention,

[0051] This is an example of the functional architecture of a verification entity according to the invention, and

[0052] Laillustre an example of hardware architecture of a relay server and / or a verification entity according to the invention.

[0053] To make the explanation more concrete, an example of a system 1 according to the invention, comprising a virtualized computing platform PIV, a relay server PRXY, and a plurality of verification entities EV, is illustrated in Figure 1 and described in detail below, with reference to the accompanying drawings. It should be noted that the invention is not limited to this example.

[0054] As previously mentioned, the virtualized computing platform comprises a CM hardware layer, a VMM hypervisor, and a virtual machine layer of VM1 and VM2. In the example shown, the PIV virtualized computing platform consists of two virtual machines owned by two separate tenants.

[0055] The CM hardware layer includes a root of trust (RoT).

[0056] The Root of Trust (RoT) provides security services for the PIV platform. In particular, it is used to store and protect the platform's keys, which cannot be used by other resources without this root of trust.

[0057] Each virtual machine VM1, VM2 controlled by the VMM hypervisor can access a virtualized root of trust, vRoT1, vRoT2, respectively. The virtualized roots of trust vRoT1, vRoT2 are independent instances representing the same root of trust (RoT).

[0058] The Root of Trust (RoT) can be constituted by a Trusted Platform Module (TPM). A TPM is a cryptographic processor that conforms to the technical specifications defined by the Trusted Computing Group (TCG) consortium. It may, in particular, conform to the ISO / IEC 11889 standard.

[0059] Virtualized roots of trust (vRoT) can be vTPMs, virtualized trusted platform modules, which correspond to a software representation of a TPM trust module.

[0060] For each virtual machine (VM) and hypervisor (VMM), a private-public key pair (sk, pk) can be predetermined. Each public key (pk) is intended to be disclosed, while the private keys (sk) are intended to be kept secret and are preferably stored in the virtualized root of trust (vRoT) and the root of trust (RoT), respectively.

[0061] Private and public keys are preferably used to generate attestations using a signature scheme.

[0062] Public keys of the virtual machines are also used to generate the vector intended for use in generating the vector commitment. These public keys are subsequently referred to as "attestation public keys".

[0063] System 1 also includes a PRXY relay server and a plurality of EV1, EV2, EV3 verification entities.

[0064] In this example, entity EV1 is a resource verification entity for the tenant that owns virtual machine VM1. This verification entity is therefore authorized to send an attestation request to virtual machine VM1, but not to virtual machine VM2. Entity EV2 is a resource verification entity for the tenant that owns virtual machine VM2. This verification entity is therefore authorized to send an attestation request to virtual machine VM2, but not to virtual machine VM1. Verification entity EV3 relates to a third tenant and is therefore not authorized to request attestations for virtual machines VM1 and VM2.

[0065] For each virtual machine, a secure C1 channel can be established between said virtual machine and the PRXY relay server.

[0066] A secure C2 channel can also be established between the hypervisor and the relay server.

[0067] Secure channels C1, C2 can be established using the virtualized vRoT1, vRoT2 and RoT root of trust respectively.

[0068] For each verification entity, a secure C3 channel can be established between said verification entity and the PRXY relay server.

[0069] This example of a virtualized computing platform architecture is not exhaustive. For example, the platform could include a different number of virtual machines, and several virtual machines could belong to the same tenant.

[0070] System 1 is advantageously configured to allow the implementation of processes according to the invention.

[0071] In particular, the PRXY relay server is configured to implement a method for providing attestation according to the invention, the virtual machines VM1, VM2 are configured to implement a method for generating attestations according to the invention, and the verification entities EV1, EV2, EV3 are configured to implement a verification method according to the invention.

[0072] Figures 2 and 3 represent an example of the implementation of a process of in-depth attestations implemented by a system 1 according to the invention.

[0073] The steps described in 1a represent steps of the deep attestation process according to the invention enabling attestation that the hypervisor is in a valid configuration and that the link between a virtual machine for which the request was transmitted and the hypervisor is valid, while steps described in 1a represent steps of the deep attestation process according to the invention enabling the provision of an attestation of the virtual machine.

[0074] The steps implemented by the hypervisor and the steps implemented by the virtual machine(s) can advantageously be implemented in parallel.

[0075] In particular, in specific embodiments of the invention, the attestation request may relate to a set of virtual machines held by the same tenant. In this case, a virtual machine attestation is generated for each virtual machine in the set of virtual machines, and a hypervisor attestation is generated for the hypervisor(s) linked to the virtual machines in the set of virtual machines. Preferably, when a hypervisor hosts multiple virtual machines, only one hypervisor attestation is generated for that hypervisor.

[0076] The PRXY relay server can be configured to implement steps E100 to E190 1-2.

[0077] The EV verification entity can be configured to implement steps E310 to E340.

[0078] The VMM hypervisor can be configured to implement steps E210 to E250.

[0079] The virtual machine (VM) can be configured to implement steps E410 to E430.

[0080] In a prior, unrepresented step, a first secure communication channel can be established between the PRXY relay server and a VM virtual machine, a second secure communication channel can be established between the PRXY relay server and the VMM hypervisor, and a third secure communication channel can be established between the PRXY relay server and an EV verification entity.

[0081] The EV verification entity can generate a REQ_ATT attestation request in step E310. The attestation request may include a nonce. The attestation request is intended to be sent to at least one virtual machine (VM) whose configuration the verification entity wishes to verify, and to the VMM hypervisor that hosts that virtual machine.

[0082] The REQ_ATT attestation request is transmitted, at step E320, by the EV verification entity, via the third secure communication channel C3, to the PRXY relay server.

[0083] The PRXY relay server receives the REQ_ATT attestation request at step E100.

[0084] Preferably, the PRXY relay server performs an E110 verification step during which it is verified that the EV verification entity is authorized to request an attestation for said virtual machine VM and hypervisor VMM.

[0085] In the example shown, the EV2 verification entity would not be authorized to request an attestation for the VM1 virtual machine. However, the EV2 verification entity is authorized, or empowered, to request an attestation for the VM2 virtual machine.

[0086] Preferably, this E110 step is performed upon receipt of the REQ_ATT attestation request by the relay server. In particular, the PRXY relay server may only forward the attestation request when the verification step indicates that the verifying entity is authorized to request said attestation.

[0087] Alternatively, this E110 step is performed concurrently with the attestation generation steps by the virtual machine and / or hypervisor, or after receiving the attestations generated by the virtual machine and hypervisor. In this case, if the verification indicates that the verifying entity is not authorized, the relay server does not transmit the generated attestations to the verifying entity.

[0088] The PRXY relay server transmits the REQ_ATT attestation request to the VMM hypervisor during step E120, via a second secure communication channel C2. In a particular embodiment, the PRXY relay server transmits the nonce.

[0089] At step E210, the VMM hypervisor obtains the REQ_ATT attestation request preferably containing the nonce.

[0090] A signature scheme is advantageously predefined prior to the implementation of a method according to the invention in order to generate virtual machine and hypervisor attestations by signing a message m.

[0091] Preferably, the signature scheme is based on signing message m using a private key, with message verification performed by a public key associated with the private key. Thus, for each virtual machine and hypervisor, a private / public key pair is determined. The private key of a virtual machine is advantageously kept secret in the virtualized root of trust (RoT) associated with that virtual machine. The private key of the hypervisor is advantageously kept secret in the RoT.

[0092] At step E220, the hypervisor generates a VECT vector. This VECT vector can be generated from the nonce and the public keys {vAK.pk} i , {vAK.pk} icorresponding to the set of public keys of the virtual machines belonging to the verification entity that issued the attestation request, i being a natural number belonging to the interval [1; N], with N corresponding to the number of verification entities: VECT = nonce|{vAK.pk} i .

[0093] The VECT vector is transmitted by the VMM hypervisor, via the second secure communication channel C2, to the PRXY relay server.

[0094] The relay server obtains the VECT vector at step E130 and generates, at step E140, a vector commitment VC from said VECT vector.

[0095] A vector commitment generation scheme is preferably defined beforehand. For example, the vector commitment can be based on a Merkle tree.

[0096] Known vector commitment schemes are described in particular in the article Catalano, D., Fiore, D. (2013). “Vector Commitments and Their Applications”. In: Kurosawa, K., Hanaoka, G. (eds) Public-Key Cryptography – PKC 2013. PKC 2013. Lecture Notes in Computer Science, vol 7778. Springer, Berlin, Heidelberg. https: / / doi.org / 10.1007 / 978-3-642-36362-7_5.

[0097] Vector commitments are advantageous in that they carry information that can attest to the link between the virtual machine and the hypervisor in response to an attestation request. Furthermore, vector commitments allow only a portion of the information they contain to be revealed. Indeed, vector commitments can only be partially verified based on auxiliary information.

[0098] The PRXY relay server transmits, during an E150 step, to the VMM hypervisor via the second secure communication channel C2, the vector commitment VC.

[0099] At step E230, the hypervisor obtains the vector commitment VC and generates at step E240, a hypervisor attestation, among other things from this vector commitment VC.

[0100] The hypervisor attestation can be generated by the hypervisor by signing a message containing the hypervisor configuration and the vector commitment from the hypervisor's private key Ak.sk: σ = Sign(Ak.sk, CONF, VC), with σ the signed message, Sign the message signing function, Ak.sk the hypervisor's private key, CONF the hypervisor configuration and VC the vector commitment.

[0101] This ATT hypervisor attestation is transmitted by the hypervisor, at step E250, via the second secure communication channel C2, to the PRXY relay server.

[0102] At stage E160 1, The hypervisor certificate is obtained by the PRXY relay server.

[0103] In step E170, the PRXY relay server verifies, at least partially, the hypervisor attestation and generates, in step E180, proof that this verification step has been completed. The proof also contains information relating to the hypervisor configuration and the state of the link between the hypervisor and the virtual machine(s) for which attestation is requested in the attestation request.

[0104] This proof π is generated using a cryptographic proof protocol with zero disclosure of knowledge, for example using a ZK-SNARK protocol (“Zero-Knowledge Succinct Non-Interactive Argument of Knowledge”).

[0105] In particular, the attestation verification may involve selecting an integer i belonging to the interval [1; N] with N being the number of verification entities and opening the vector commitment VC so as to obtain the element of the VECT at location i, in this case nonce|{vAK.pk} i The proof is generated from this partial opening of the vector commitment. Index i may contain all the public keys of virtual machines belonging to said verification entity.

[0106] The PRXY relay server then transmits the proof π, the vector commitment VC, and possibly the integer i, via the third secure communication channel C3, to the verification entity EV, at step E1901.

[0107] At step E330, the verification entity EV obtains the proof and vector commitment, and possibly the integer i.

[0108] At step E340, the verification entity verifies the proof π, by implementing any classical verification method.

[0109] In parallel, upstream or downstream of the hypervisor attestation generation, a virtual machine attestation is performed.

[0110] The steps identical to those of the two processes described are not detailed again. The steps common to Figures 2 and 3 are preferably implemented only once.

[0111] As shown in the figure, the virtual machine VM obtains the attestation request at step E410. This attestation request is transmitted by the PRXY relay server to the virtual machine VM via the first secure communication channel C1.

[0112] In response to this request, the virtual machine generates a vATT at step E420.

[0113] This certificate can be generated by any method that is conventionally implemented.

[0114] In particular, this attestation is generated from the virtualized vRoT root of trust and specifically from a predetermined public / private key pair and signature scheme.

[0115] For example, the virtual machine can calculate: σ = Sign(vAK.sk, vCONF, H (nonce|vAK.pk)), with Sign the signature function of the signature scheme, vAk.sk the private attestation key associated with the virtual machine with respect to the virtualized root of trust vRoT, vCONF the virtual machine configuration, H a hash function and vAk.pk the public key of the virtual machine with respect to the virtualized root of trust vRoT.

[0116] This attestation is transmitted, at step E430, by the virtual machine VM to the relay server PRXY, via the first secure communication channel C1.

[0117] The relay server receives the virtual machine attestation during step E1602 and transmits it during step E1902 to the EV verification entity.

[0118] The EV verification entity receives the vATT virtual machine attestation transmitted via the third secure communication channel C3, at step E330.

[0119] At step E340, the verification entity proceeds to verify the vATT virtual machine attestation.

[0120] The PRXY relay server may include modules configured to implement a method for providing attestation according to the invention.

[0121] In particular, the PRXY relay server includes: an M100 establishment module for a first secure channel between at least one virtual machine and the relay server, an M110 establishment module for a second secure channel between the hypervisor and the relay server, an M120 establishment module for a third secure channel between a verification entity and the relay server, an M130 communication module configured to: transmit an attestation request via the first secure channel, and receive, via the first secure channel, a virtual machine attestation generated from at least one virtualized root of trust, an M140 communication module configured to: transmit an attestation request via the second secure channel, receive, via the second secure channel, a vector generated from at least one virtual machine attestation public key, transmit a vector commitment via the second secure channel, and receive,via the second secure channel, a hypervisor attestation generated from at least one root of trust and a vector commitment, an M150 communication module configured to: receive an attestation request via the third secure channel, and transmit a virtual machine attestation, proof, and a vector commitment, via the third secure channel, an M160 generation module configured to generate a vector commitment from a vector, an M170 verification module configured to verify at least one hypervisor attestation, an M180 generation module configured to generate proof such that it bears an indication that the hypervisor is in one of a set of valid hypervisor configurations and an indication that the virtual machine is associated with said hypervisor, the proof being generated from a hypervisor attestation,of a vector commitment and a cryptographic proof protocol with zero disclosure of knowledge.

[0122] The M130 module is configured to implement all or part of steps E120 and E1602.

[0123] The M140 module is configured to implement all or part of steps E120, E130, E150, E1601.

[0124] The M150 module is configured to implement steps E100; E1902; E190 1.

[0125] The M160 module is configured to implement step E140.

[0126] The M170 module is configured to implement step E170.

[0127] The M180 module is configured to implement step E180.

[0128] In addition, the relay server may include an authorization verification module (not shown) configured to verify that a verification entity is authorized to request attestation from a virtual machine.

[0129] A virtualized computing platform is advantageously configured to implement a certificate generation process according to the invention.

[0130] In particular, each virtual machine of the virtualized computing platform is configured to: establish a first secure channel with a relay server, receive an attestation request via the first secure channel, generate an attestation from at least the virtualized root of trust in response to said attestation request, transmit said attestation via the first secure channel, and the hypervisor is configured to: establish a second secure channel with the relay server, receive the attestation request via the second secure channel, generate a vector, transmit the vector via the second secure channel, receive, via the second secure channel, a vector pledge generated from the vector and a zero-knowledge proof cryptographic protocol, generate an attestation from at least the root of trust and the vector pledge, transmit said attestation via the second secure channel.

[0131] Thus, each virtual machine can be configured to implement steps E410, E420, and E430 and the hypervisor to implement steps E210, E220, E230, E240, and E250.

[0132] The EV verification entity may include modules configured to implement a verification process according to the invention.

[0133] In particular, the verification entity includes an M300 attestation request generation module, an M310 secure channel establishment module with the relay server, an M320 communication module configured to send an attestation request via the third secure channel, receive a virtual machine attestation, proof and vector commitment, via the third secure channel, an M330 verification module configured to verify a virtual machine attestation, and a zero-knowledge disclosure proof.

[0134] The M300 module is configured to implement step E310.

[0135] The M320 module is configured to implement steps E320 and E330.

[0136] The M330 module is configured to implement step E340.

[0137] In a particular embodiment, the different steps of the processes according to the invention are determined by computer program instructions.

[0138] Consequently, the invention also relates to a computer program on an information medium, this program being capable of being implemented in a relay server, a virtualized computer platform and / or a verification entity according to the invention or more generally in a computer, this program comprising instructions adapted to the implementation of the steps of a process according to the invention as described above.

[0139] Thus, in certain implementations, the virtualized PIV computing platform has the hardware architecture of a computer. It should be noted that some elements of this architecture may be confused with existing devices.

[0140] More specifically, the virtualized computing platform may include a PC processor, ROM, RAM, a root of trust (RoT), and means of communication.

[0141] It should be noted that the root of trust can be made up of software elements but it is preferentially implemented as a hardware module.

[0142] The root of trust provides platform security services. In particular, it is used to store and protect the platform's keys, which cannot be used by other resources without this root of trust.

[0143] This root of trust is, for example, constituted by a trust module conforming to ISO / IEC standard norms.

[0144] The read-only memory of the PIV virtualized computing platform constitutes a storage medium readable by the processor and on which is stored a computer program according to the invention, comprising instructions for the execution of the steps of a process according to the invention detailed above.

[0145] This computer program defines, in an equivalent way, functional modules (software) of the virtualized computing platform.

[0146] This program can use any programming language, and be in the form of source code, object code, or code somewhere between source code and object code, such as in a partially compiled form, or in any other desirable form.

[0147] Similarly, in certain embodiments, the EV verification entities and / or the PRXY relay server have the hardware architecture of a computer, as shown in Figure 1. It should be noted that some elements of this / these architectures may be confused with existing devices.

[0148] The invention also relates to a computer-readable information or recording medium, and comprising instructions for a computer program as mentioned above.

[0149] The information or recording 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 floppy disk or a hard disk drive.

[0150] On the other hand, the information or recording 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.

[0151] Alternatively, the information or recording medium 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.

[0152] Although the present invention has been described with reference to specific embodiments, it is evident that modifications and changes can be made to these examples without departing from the general scope of the invention as defined by the claims. In particular, individual features of the various embodiments illustrated / mentioned can be combined in additional embodiments. Therefore, the description and drawings should be considered in an illustrative rather than restrictive sense.

[0153] It is also evident that all the characteristics described with reference to a process are transposable, alone or in combination, to a device, and conversely, all the characteristics described with reference to a device are transposable, alone or in combination, to a process.

Claims

A method for providing attestations in a virtualized computing platform (VIP) comprising a hypervisor (VMM) and at least one virtual machine (VM1, VM2), the method, implemented by a relay server, comprising the following steps: - generation (E140) of a vector commitment (VC) from a vector (VECT) generated by the hypervisor from at least one virtual machine attestation public key; - transmission (E150) of the vector commitment to the hypervisor; - reception (E160 2 ;E1601) of a virtual machine attestation and a hypervisor attestation generated from at least the vector commitment (VC);- generation (E180) of a proof that the hypervisor is in one configuration among a set of valid configurations and that the virtual machine is associated with said hypervisor, from the vector commitment, a cryptographic proof protocol with zero disclosure of knowledge, and the hypervisor attestation;- transmission (E1902; E1901) of at least the virtual machine attestation, the proof and the vector commitment to a verification entity. Method according to claim 1 comprising a transmission step (E120) to the virtual machine and the hypervisor, of an attestation request (REQ_ATT) transmitted to the relay server by the verification entity (EV). A method according to claim 2 comprising a step (E110) of verifying that the verification entity is authorized to transmit said attestation request to the virtual machine and the hypervisor, preferably the relay server performs this verification before transmitting, if necessary, the attestation request to the virtual machine and the hypervisor. Method according to any one of claims 1 to 3, the hypervisor implementing a virtualized root of trust (vRoT1, vRoT2) per virtual machine (VM1, VM2), the virtual machine attestation being generated by the virtual machine from at least the virtualized root of trust. Method according to any one of claims 1 to 4, the virtualized computing platform (VIP) further comprising a root of trust (RoT), the hypervisor attestation being generated by the hypervisor from at least the root of trust and the vector commitment (VC). A method according to any one of claims 1 to 5, the transmissions being made via secure channels, in particular the first, second and third secure channels respectively established between said virtual machine and the relay server, between the hypervisor and the relay server, and between the verification entity and the relay server. A method for generating attestations by a virtualized computing platform (VIP) comprising a root of trust (RoT), a hypervisor (VMM), and at least one virtual machine (VM1, VM2), the hypervisor implementing a virtualized root of trust (vRoT1, vRoT2) per virtual machine (VM1, VM2), the method comprising the following steps: - reception (E410; E210) of an attestation request (REQ_ATT) transmitted by the relay server to the virtual machine and then to the hypervisor; - generation and transmission (E220) of a vector (VECT) by the hypervisor, from at least one virtual machine attestation public key, to the relay server (PRXY); - generation (E420;E240) of a virtual machine attestation by the virtual machine from at least the virtualized root of trust, and of a hypervisor attestation by the hypervisor from at least the root of trust and a vector commitment (VC) generated and transmitted by the relay server (PRXY) from the vector (VECT);- transmission (E430; E250) of the virtual machine and hypervisor attestations to the relay server, the transmissions being made via secure channels.; A method for verifying attestations of a virtualized computing platform (VIP) comprising a root of trust (RoT), a hypervisor (VMM) and at least one virtual machine (VM1, VM2), the hypervisor (VMM) implementing a virtualized root of trust (vRoT1, vRoT2) per virtual machine (VM1, VM2), the method, implemented by a verification entity (EV), comprising the following steps:- transmission (E320) of an attestation request (REQ_ATT) to a relay server (PRXY);- receipt (E330) of at least: - a virtual machine attestation transmitted by the relay server and generated by the virtual machine of the virtualized computing platform, - proof that the hypervisor is in one of a set of valid hypervisor configurations and that the virtual machine is associated with the hypervisor, the proof being generated by the relay server from at least one vector commitment, a hypervisor attestation and a zero-knowledge cryptographic proof protocol, and - the vector commitment; - verification (E340) of the virtual machine attestation and the proof. A method according to any one of claims 1 to 8 wherein the zero-knowledge cryptographic protocol is a ZK-SNARK protocol. A method according to any one of claims 1 to 9, wherein the virtualized computing platform has a cloud computing type architecture, such as an architecture based on the virtualization of network functions or a mobile communications network. A relay server configured to provide attestations of a virtualized computing platform (VIP) comprising a root of trust (RoT), a hypervisor (VMM), and at least one virtual machine (VM1, VM2) to a verification entity. The hypervisor implements a virtualized root of trust (vRoT1, vRoT2) per virtual machine (VM1, VM2), comprising: establishment modules (M100, M110, M120) for a first secure channel between at least one virtual machine and the relay server, a second secure channel between the hypervisor and the relay server, and a third secure channel between a verification entity (EV) and the relay server (PRXY); a communication module (M130) configured to: transmit an attestation request (REQ_ATT) via the first secure channel; and receive, via the first secure channel, a virtual machine attestation generated from at least one virtualized root of trust. (M140) configured for,via the second secure channel: Transmit an attestation request (REQ_ATT), Receive a vector (VECT) generated from at least one virtual machine attestation public key, Transmit a vector pledge, Receive a hypervisor attestation generated from at least one root of trust and a vector pledge (VC), a communication module (M150) configured to, via the third secure channel: Receive an attestation request (REQ_ATT), Transmit a virtual machine attestation, a proof and a vector pledge, A generation module (M160) configured to generate a vector pledge (VC) from a vector (VECT), A verification module (M170) configured to verify at least one hypervisor attestation, A generation module (M180) configured to generate proof that the hypervisor is in one of a set of valid hypervisor configurations and that the virtual machine is associated with said hypervisor,the proof being generated from a hypervisor attestation, a vector commitment, and a zero-knowledge cryptographic proof protocol. A virtualized computing platform (VIP) comprising a root of trust (RoT), a hypervisor (VMM), and at least one virtual machine (VM1, VM2), the hypervisor (VMM) implementing a virtualized root of trust (vRoT1, vRoT2) per virtual machine (VM1, VM2), in which: Each virtual machine is configured to: Establish a first secure channel with a relay server, Generate an attestation from at least the virtualized root of trust in response to an attestation request (REQ_ATT) received via the first secure channel, Transmit said attestation via the first secure channel. The hypervisor is configured to: Establish a second secure channel with the relay server, Receive the attestation request (REQ_ATT) via the second secure channel, Generate a vector (VECT) from at least one virtual machine attestation public key, Transmit the vector (VECT) via the second secure channel, Receive, via the second secure channel,A vector commitment (VC) generated from the vector (VECT), generate an attestation from at least the root of trust and the vector commitment (VC), and transmit said attestation via the second secure channel. Verification entity (VE) configured to request attestations from a virtualized computing platform (VIP) via a relay server (PRXY), the virtualized computing platform comprising a root of trust (RoT), a hypervisor (VMM) and at least one virtual machine (VM1, VM2), the hypervisor (VMM) implementing a virtualized root of trust (vRoT1, vRoT2) per virtual machine (VM1, VM2), the verification entity comprising: a secure channel establishment module (M310) with the relay server (PRXY), a communication module (M320) configured to, via the third secure channel: Send an attestation request (REQ_ATT), Receive a virtual machine attestation, a proof and a vector commitment, A verification module (M330) configured to: Verify a virtual machine attestation, and a zero-knowledge proof. Communication system (1) comprising: - a virtualized computer platform (PIV) according to claim 12, - a relay server (PRXY) according to claim 11, - one or more verification entities (EV1, EV2, EV3) according to claim 13. Computer program comprising code instructions which, when executed by means of a computer, enable the implementation of a method according to any one of claims 1 to 10. Computer-readable recording medium on which is recorded a computer program comprising instructions for carrying out the steps of a process according to any one of claims 1 to 10.

Images