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

Abstract

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 to generate a zero-knowledge proof from this vector commitment, said 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. Fig. 1.

Description

Title of the invention: Method for providing attestations in a multi-tenant virtualized computing platform technical field

[0001] The present presentation relates to the field of virtualized computer platforms and more particularly to attestations, especially in-depth attestations, in such platforms. Previous technique

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

[0003] Classically, attestation mechanisms take the form of a so-called "challenge-response" protocol in which the verifier sends a challenge to a target accompanied by a random number generator, called a nonce. The target generates proofs in response to this challenge and sends them to the verifier. Generally, the proof is based on a root of trust of the target. The proof generally consists of demonstrating, by providing 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 particular case of virtualized computer platforms, it is known to use deep attestation mechanisms, commonly called "deep attestations" in English.

[0005] A virtualized computing platform typically comprises 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 for securing the virtualized computing platform. The behavior of the root of trust is assumed to be known and reliable, as any faulty behavior of the root of trust cannot be detected. The root of trust may consist 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 the 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 deep attestation method, known as "single-channel" attestation, is known for providing deep attestations in virtualized computing platforms. In this method, only one entry point to the target is accessible to the verifier. The verifier sends a challenge to the virtual machine, which generates an attestation to prove that the virtual machine is in a valid state. The verifier then transmits the challenge and the attestation to the hypervisor, which in turn generates an attestation to prove that it is in a valid state based on the virtual machine's attestation, thus providing a composite attestation. This composite attestation is transmitted to the verifier in response to the challenge. One of the drawbacks of this method is the generation of a new hypervisor attestation for each virtual machine. This method is therefore neither scalable nor efficient.

[0011] Another method, known as multi-channel, overcomes this drawback of the single-channel method by sending a challenge to the hypervisor and the virtual machines separately, making implementation more efficient. However, this method does not allow verification of the valid state 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: “A Cryptography View of Deep-Attestation, or How to Do Provably-Secure Layer-Linking” describes a method combining these two approaches, involving the generation of two separate attestations, similar to a multi-channel method. The difference lies in the content of the hypervisor attestation, which is generated to contain proof that the link between the virtual machine and the hypervisor is in a valid state. In particular, 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 should be noted that components of a virtualized computing platform may belong to different tenants. Thus, several verifiers may request attestations for components belonging to a particular tenant. In this case, it is necessary to be able to ensure the security and the confidentiality of other components, in other words components not belonging to the holder for whom a certificate 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, at the target level, a significant computational complexity for generating the attestations.

[0016] There is therefore a need to provide comprehensive attestations that are free, at least in part, from the drawbacks inherent in the aforementioned known methods. In particular, there is a need for comprehensive attestations that allow for 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, in a platform where resources are held by a plurality of tenants.

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

[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 transmission step 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, of 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 virtual machine attestation key; - a step of transmitting the vector commitment via the second secure channel to the hypervisor; - a receiving step, via the first and second secure channels respectively, of a virtual machine attestation generated by the virtual machine from at least the virtualized root of trust and of 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 secure third channel between a verification entity and the relay server, a communication module configured for: - Submit a certificate 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 for: - Submit a certificate 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. - Receive, via the second secure channel, a hypervisor attestation generated from at least one root of trust and a vector commitment, a communication module configured for: - Receive a certificate request via the third secure channel, - Transmit a virtual machine certificate, proof, and vector commitment via the third secure channel. a generation module configured to generate a vector commitment from a vector, a verification module configured to check at least one hypervisor attestation, a generation module configured to generate a proof so that it carries an indication that the hypervisor is in one configuration among 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 advantageously allows proving, through a simple and easy-to-implement procedure, that the link between said virtual machine and the hypervisor exists and is valid, without disclosing all the virtual machines controlled by said hypervisor. In particular, vector commitment ensures the confidentiality of the identities of the virtual machines controlled by the hypervisor and, a fortiori, of their configurations.

[0021] The attestation key or keys 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 computer platform and the verification entity or entities also makes it possible to control communication with the verification entities and therefore the sending of attestation requests to the virtualized computer 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 computing 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 by means of the zero-knowledge proof cryptographic protocol, thus making it possible to provide 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 configuration of the hypervisor which may belong to a tenant other than the tenant of the virtual machine for which an attestation is requested.

[0027] In response to the attestation request of 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 made the appropriate checks.

[0028] The generation of virtual machine and hypervisor attestations can be done by any known deep attestation generation method. In particular, they can be generated by a method such as that described in the publication Ghada Arfaoui, Pierre-Alain Fouque, Thibaut Jacques, Pascal Lafourcade, Adina Nedelcu, Cristina Onete, Léo Robert: “A Cryptography 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 the attestations may include the signature o 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 in particular 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 comprises a commitment chain providing a list of values ​​rather than a single value. The verification entity's check of the vector commitment provides it with proof as to whether or not a value belongs to the vector commitment; in other words, during the check, the verification entity only partially opens the transmitted list, access to each value in the list requiring the provision of specific additional information distinct from that of the other values ​​in the list.

[0033] The generation of a vector commitment advantageously allows the aggregation of several queries into one, limiting the clutter of the root of trust RoT.

[0034] The vector commitment preferably has a constant size to avoid the leakage of information relating to other virtual machines. Thus, 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. Thus these Random values ​​must be selected so as not to impact the verification.

[0035] In particular embodiments, the method of providing attestations includes a step of verifying 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 virtual machine attestation key, 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 transmission step, via the first and second secure channels, of 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 implementing a virtualized root of trust per virtual machine, in which: Each virtual machine is configured to: - Establish an initial secure channel with a relay server, - Receive a certificate request via the first secure channel, - Generate a certificate from at least the virtualized root of trust in response to said certificate request, - Transmit the said certificate 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 a certificate from at least the root of trust and the vector commitment, - Transmit the said certificate via the second secure channel.

[0038] The invention also relates to a method for verifying 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, 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 receiving step, via the third secure channel, of 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 configuration among 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 to verify the virtual machine attestation and 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 for: - Send a certificate request via the third secure channel, - Receive a virtual machine certificate, proof and vector commitment, via the third secure channel. a verification module configured for: - Verify a virtual machine attestation, and a zero-knowledge proof.

[0040] The verification may include verifying that a public key contained in the virtual machine attestation is 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 corresponding to the public key of the virtual machine public key 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 particular embodiments, the virtualized computing platform has a cloud computing architecture. In particular, the virtualized computing platform may have a Network Function Virtualization (NFV) architecture, that is to say, one 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 from the detailed description that follows. This detailed description refers to the accompanying drawings. Brief description of the drawings

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

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

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

[0049] [Fig.2] and [Fig.3] Figures 2 and 3 represent the steps of an example of implementation work of a process according to the invention,

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

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

[0052] [Fig.6] Fig.6 illustrates an example of the hardware architecture of a relay server and / or a verification entity according to the invention. Description of the implementation methods

[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 [Fig. 1] and is 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 stated, the virtualized computing platform comprises a CM hardware layer, a VMM hypervisor, and a VM1, VM2 virtual machine layer. In the example of [Fig.1], the PIV virtualized computing platform comprises two virtual machines held by two separate tenants.

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

[0056] The RoT root of trust 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, vRoTl, vRoT2, respectively. The virtualized roots of trust vRoTl, 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 conforming to the technical specifications defined by the Trusted Computing Group (TCG) consortium. In particular, it may conform to the ISO / IEC 11889 standard.

[0059] Virtualized vRoT roots of trust can be vTPMs, virtualized trusted platform modules or "Virtual Trusted Platform Module", in English, corresponding to a software representation of a TPM trust module.

[0060] For each of the virtual machines VM and hypervisor VMM, a private-public key pair (sk, pk) can be determined beforehand. 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 roots of trust vRoT and the root of trust RoT, respectively.

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

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

[0063] System 1 further comprises 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 channel Cl can be established between said virtual machine and the relay server PRXY.

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

[0067] The secure channels Cl, C2 can be established using the virtualized roots of trust vRoTl, vRoT2 and the root of trust RoT 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 limiting. 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 method of in-depth attestations implemented by a system 1 according to the invention.

[0073] The steps described in [Fig.2] represent steps of the in-depth 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 the steps described in [Fig.3] represent the steps of the in-depth 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 several virtual machines, only one hypervisor attestation is generated for that hypervisor.

[0076] The PRXY relay server can be configured to implement steps El00 to E19012.

[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 VM virtual machine can be configured to implement steps E410 to E430.

[0080] In a prior step, not shown, a first secure communication channel can be established between the PRXY relay server and a virtual machine VM, 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 a verification entity EV.

[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 VM whose configuration the verification entity wishes to verify, and to the VMM hypervisor that hosts said 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, at step E100, the REQ_ATT attestation request.

[0084] Preferably, the PRXY relay server performs an El 10 verification step at 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 illustrated in [Fig. 1], the verification entity EV2 would not be authorized to request an attestation for the virtual machine VM1. On the other hand, The EV2 verification entity has the authorization, in other words is empowered to, request a certificate for the VM2 virtual machine.

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

[0087] Alternatively, this step El 10 is performed in parallel with the attestation generation steps by the virtual machine and / or the hypervisor, or after receipt of said attestations generated by the virtual machine and the 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, during a step E120, via a second secure communication channel C2, the REQ_ATT attestation request to the VMM hypervisor. 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 (vRoT) associated with that virtual machine. The private key of the hypervisor is advantageously kept secret in the root of trust (RoT).

[0092] At step E220, the hypervisor generates a vector VECT. This vector VECT can be generated from the nonce and the public keys {vAK.pk};, {vAK.pk}; corresponding 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 predefined. For example, the vector commitment may 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] The vector commitment advantageously carries information that allows the link between the virtual machine and the hypervisor to be attested in response to the attestation request. Furthermore, the vector commitment allows only a portion of the information it contains to be revealed. Indeed, the vector commitment can only be partially verified based on auxiliary information.

[0098] The PRXY relay server transmits, during a step E150, 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: o = Sign(Ak.sk, CONF, VC), with o 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 step E160i, the hypervisor attestation is obtained by the PRXY relay server.

[0103] At step E170, the PRXY relay server verifies, at least partially, the hypervisor attestation and generates, at step E180, proof that this verification step has been performed. 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 an attestation is requested in said attestation request.

[0104] This proof is generated by means of a cryptographic proof protocol with zero disclosure of knowledge, for example by means of 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], where N is 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 noncel{vAK.pk};, the proof being generated from this partial opening of the vector commitment. At index i may be found all public keys of virtual machines belonging to said verification entity.

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

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

[0108] At step E340, the verification entity verifies the evidence ji, by implementing any conventional verification method.

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

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

[0111] As shown in [Fig. 3], 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 CL

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

[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 in particular from a public / private key pair and a predetermined signature scheme.

[0115] For example, the virtual machine can calculate: o = Sign(vAK.sk, vCONF, H (noncelvAK.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 CL

[0117] The relay server receives the virtual machine attestation during step E1602 and transmits it during an E1902 step 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 comprises: an M100 establishment module for a first secure channel between at least one virtual machine and the relay server, an M10 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 Ml50 communication module configured to: receive an attestation request via the third secure channel, and transmit a virtual machine attestation, a proof and a vector commitment, via the third secure channel, an Ml60 generation module configured to generate a vector commitment from a vector, an Ml70 verification module configured to verify at least one hypervisor attestation, an Ml80 generation module configured to generate a 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, E160i.

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

[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 computer platform is advantageously configured to implement a certificate generation method 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 stages of the processes according 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 computing 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 embodiments, 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 may consist of software elements but is preferably implemented in the form of 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 standards.

[0144] The read-only memory of the PIV virtualized computing platform constitutes a processor-readable recording medium on which is recorded 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 equivalently defines functional modules (software) of the virtualized computing platform.

[0146] This program may 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.

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

[0148] The invention also relates to a computer-readable information or recording medium, 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 may include a storage means, such as a ROM, for example a CD-ROM or a circuit ROM microelectronics, or a magnetic recording device, for example a floppy disk or a hard disk.

[0150] On the other hand, the information or recording medium may be a transmissible medium such as an electrical or optical signal, which may be transmitted via an electrical or optical cable, by radio, or by other means. The program according to the invention may, in particular, be downloaded onto an Internet-type network.

[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 a 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

Demands

1. Method of providing attestations in 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, implemented by a relay server, comprising: - a step (E120) of transmission 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, of an attestation request (REQ_ATT) transmitted to the relay server by a verification entity (EV) via a third secure channel established between the verification entity (EV) and the relay server (PRXY); - a step (El40) of generating a vector commitment (VC) from a vector (VECT) itself generated by the hypervisor from at least one public virtual machine attestation key; - a step (E150) of transmission of the vector commitment via the second secure channel to the hypervisor; - a step (E1602;E160i) 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 (VC); - a step (E1902; E1900) 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 vector commitment, a cryptographic proof protocol with zero disclosure of knowledge, and the hypervisor attestation; - a step (E1902; E1900) of sending at least the virtual machine attestation, the proof and the vector commitment to the verifying entity, via the third secure channel.

2. A method according to claim 1, comprising a verification step (El 10) 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 forwarding, if necessary, the attestation request to the virtual machine and the hypervisor.

3. 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: - a step (E410; E210) of receiving an attestation request (REQ_ATT) 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 (E220) of generation and transmission of a vector (VECT) by the hypervisor, from at least one public virtual machine attestation key, to the relay server (PRXY) via the second secure channel; - a step (E420; E240) 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 (VC) generated and transmitted by the relay server (PRXY) from the vector (VECT); - a step (E430; E250) of transmission, via the first and second secure channels, of the virtual machine and hypervisor attestations, respectively, to the relay server.

4. 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: - a step (E320) of sending an attestation request (REQ_ATT) to a relay server (PRXY) via a third channel secure established between the verification entity (EV) and the relay server (PRXY); - a step (E330) 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 configuration among 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 (E340) of verifying the virtual machine attestation and the proof.

5. A method according to any one of claims 1 to 4 wherein the zero-knowledge cryptographic protocol is a ZK-SNARK protocol.

6. A method according to any one of claims 1 to 5, 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.

7. 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), the hypervisor implementing a virtualized root of trust (vRoT1, vRoT2) per virtual machine (VM1, VM2) to a verification entity, comprising: - an establishment module (M100) of a first secure channel between at least one virtual machine and the relay server, - an establishment module (M110) of a second secure channel between the hypervisor and the relay server, a module for establishing (M120) a third secure channel between a verification entity (EV) and the relay server (PRXY), a communication module (ML30) configured for: • Submit an attestation request (REQ_ATT) 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 (M140) configured for: • Submit an attestation request (REQ_ATT) via the second secure channel, • Receive, via the second secure channel, a vector (VECT) generated from at least one virtual machine attestation public key, • Transmit a vector commitment 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 commitment (VC), a communication module (ML50) configured for: • Receive a certificate request (REQ_ATT) via the third secure channel, • Transmit a virtual machine certificate, proof, and vector commitment via the secure third channel. A generation module (Ml60) configured to generate a vector engagement (VC) from a vector (VECT), A verification module (ML70) configured to verify at least one hypervisor attestation, A generation module (ML80) configured to generate a proof that indicates 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

8. hypervisor attestation, vector commitment and zero-knowledge cryptographic proof protocol. 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 an initial secure channel with a relay server, • Receive an attestation request (REQ_ATT) via the first secure channel, • Generate an attestation from at least the virtualized root of trust in response to said attestation request, • Transmit the said certificate 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 a certificate from at least the root of trust and the vector commitment (VC), • Transmit the said certificate via the second secure channel.

9. Verification entity (VE) configured to request attestations from a virtualized computing platform (VCP) 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 module for establishing a secure channel with the relay server (PRXY), - a communication module (M320) configured to: • Send an attestation request (REQ_ATT) via the third secure channel, • Receive a virtual machine attestation, a proof and a vector commitment, via the third secure channel, - A verification module (M330) configured to: • Verify a virtual machine attestation, and a zero-knowledge proof.

10. Communication system (1) comprising: - a virtualized computing platform (VIP) according to claim 8, - a relay server (PRXY) according to claim 7, - one or more verification entities (EV1, EV2, EV3) according to claim 9.

11. A 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 6.

12. 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 6.

Images