Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
  • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities

Definitions

• the present invention relates to the field of attestation of virtualizable computer systems. More specifically, the present invention relates to methods and devices for attesting an integrity of a virtual machine. BACKGROUND
• the trusted computing group has defined some means through which a software integrity of a platform can be measured and, subsequently, validated by a remote verifier or attestation server.
• the process of validating the integrity of a platform is called attestation or remote attestation (see "TCG PC Client Specific Implementation
• BIOS Basic Computinggroup.org/wp- content/uploads/TCG_PCCIientlmplementation_1 -21_1_00.pdf
• FIG. 1 a schematic diagram of different components of a server is shown, wherein a hypervisor (HV) supporting virtual trusted platform modules (vTPMs) and virtual core roots of trust for measurement (vCRTMs) is running on a physical platform (compute node) supporting a physical core root of trust for measurement (pCRTM) and a physical trusted platform module (pTPM).
• HV hypervisor
• vTPMs virtual trusted platform modules
• pCRTM virtual core roots of trust for measurement
• pTPM physical trusted platform module
• two virtual machines (VM) are running on the hypervisor.
• the virtual machines VMs rely on virtual roots of trust (vRoTs) which are implemented in software and are equivalent to the physical roots of trust (pRoTs) of a physical platform.
• vRoTs virtual roots of trust
• the vRoT run on the hypervisor and assist in the attestation process of the virtual machine or platform they are assigned to. They are also considered inherently trusted in the virtual platform itself, because (as in the case of pRoTs), they use a different execution domain from the one of the software of which they should attest the integrity.
• an execution domain separation is provided by the fact that the pRoTs execute within a different chip (i.e., the pTPM).
• the execution domain separation is provided by the capabilities of the hypervisor or virtualization layer to separate the execution of the virtual platform code from the HV code where the vRoTs are executed.
• the pTPMs and the vTPMs provide implementations of the pRoTs/ vRoTs required to enable a remote attestation of physical platforms or virtual platforms, respectively.
• the vRoTs are software components running in a different execution environment than the one of the software which should be attested.
• the deep attestation requirements for a remote attestation of a virtual platform or machine, it is required to validate not only the measurements of its software, but also the measurements of the underlying virtualization layer which implements the vRoTs. This can be achieved by using a remote attestation for both the virtualization layer or HV and the virtual platform or VM and only make a judgment on the integrity status of the later based on the combined result of its measurements validation and that of the virtualization layer.
• a successful validation of the virtualization layer measurements by means of a remote attestation, as required by a deep attestation, provides some guarantees that the vRoTs (implemented in the virtualization layer or HV) have not been tampered and the virtualization layer is behaving as expected.
• the virtualization layer has assigned the correct set of vRoT instances (e.g., vCRTM and vTPM instances) to the virtual platform.
• vCRTM and vTPM instances e.g., vCRTM and vTPM instances
• the virtualization layer is responsible for running sets of vRoT instances of multiple virtual platforms, but there is no explicit guarantee provided regarding the assignment of a specific set of vRoT instances to a specific virtual platform. There is not even an explicit guarantee that the set of vRoT instances assigned to the virtual platform are indeed running on that virtualization layer. This issue is also called by the TCG the layer binding problem (see the above mentioned reference "Virtualized Trusted Platform Architecture Specification").
• the remote verifier should be provided proof that the virtual platform is using the specified set of vRoT instances running on the specified virtualization layer. In the absence of such a proof, the reliability of the integrity validation result is diminished, since there is uncertainty regarding the vRoTs used to generate the integrity report and the validation result itself cannot be fully trusted.
• a remote attestation procedure that does not fulfill the requirements of deep attestation and layer binding can still be able to calculate an integrity status for a virtual platform, however the relevance of this status can be questionable.
• it can be difficult to determine whether the virtual roots of trust (vRoTs) the virtual platform relies on have been tampered or falsified.
• a remote attestation procedure that fulfills the requirements of deep attestation and layer binding ensures trust in the vRoTs (and the integrity reports generated by them) as they effectively become part of the so-called chain of trust starting from the hardware RoT, e.g., the physical core root of trust measurement (pCRTM) and the physical TPM (see “TCG Attestation PTS Protocol: Binding to TNC IF-M",
• WO2016085592 A1 a scalable solution addressing the deep attestation and layer binding problem is described, wherein the solution is based on secure enclaves (i.e. Intel SGX technology) to provide evidence that the vTPM is running on the specified HV.
• secure enclaves i.e. Intel SGX technology
• the solution both scales and fulfills the requirements of deep attestation and layer binding, however it is highly dependent on the specific hardware support in the physical platform (i.e. SGX support, TXT support, write-once registers, etc.).
• the devices may be computing devices such as data center servers, personal computers or terminal devices.
• server refers to a device as defined above.
• the invention relates to a method for attesting, by an attestation server, an integrity of a virtual machine (VM) supported by a hypervisor (HV) running on a server, the method comprising the steps of encrypting a first nonce using a virtual endorsement key, vEK, sending a VM attestation request to the VM and a HV attestation request to the HV, wherein the VM attestation request comprises the encrypted first nonce, receiving a VM attestation report from the VM, the VM attestation report being generated by the VM, and a HV attestation report from the HV, the HV attestation report being generated by the HV, verifying whether the VM attestation report is based on the first nonce, and validating the integrity of the VM on the basis of the verification of the VM attestation report and on the basis of the HV attestation report.
• VM virtual machine
• HV hypervisor
• the method further comprises the steps of verifying whether the HV attestation report includes the vEK and the first nonce, and validating the integrity of the VM if the VM attestation report is based on the first nonce and if the HV attestation report includes the vEK and the first nonce.
• the encrypting of the first nonce is performed according to a privacy certificate authority (PCA) protocol defined by the trusted computing group (TCG).
• PCA privacy certificate authority
• TCG trusted computing group
• the invention relates to a method for generating attestation reports, by a virtual machine (VM) and by a hypervisor (HV) running on a server, the method comprising the steps of receiving, by the VM, a VM attestation request, and, by the HV, a HV attestation request, wherein the VM attestation request comprises an encrypted first nonce encrypted using a virtual endorsement key, vEK, decrypting, by a virtual trusted platform module, vTPM, running on the HV, the encrypted first nonce on the basis of a vEK stored in the vTPM in response to a decryption request from the VM, receiving, by the VM, a first quote from the vTPM, wherein the first quote is signed with a virtual attestation identity key, vAIK, stored in the vTPM and comprises the first nonce, generating, by the VM, a VM attestation report about the VM, the VM attestation
• the method further comprises the steps of storing, by the vTPM, the first nonce and the vEK, the stored first nonce and the vEK being accessible by the HV, and reading, by the HV, the stored first nonce and the vEK, wherein the generated HV attestation report includes the stored first nonce and the vEK.
• the method further comprises the steps of hashing, by the VM, the first nonce, generating, by the VM, the first quote on the basis of the hashed first nonce, hashing, by the HV, the first nonce and the vEK, receiving, by the HV, a second quote from a physical trusted platform module (pTPM) of the server, wherein the second quote is generated on the basis of the hashed first nonce and of the vEK and wherein the second quote is signed with a physical attestation identity key (pAIK), and including, by the HV, the second quote in the HV attestation report about the HV.
• pTPM physical trusted platform module
• the invention relates to an attestation server for attesting an integrity of a virtual machine (VM) supported by a hypervisor (HV) running on a server
• the attestation server comprises a processor configured to encrypt a first nonce using a virtual endorsement key, vEK, and a transmitting unit configured to send a VM attestation request to the VM and a HV attestation request to the HV, wherein the VM attestation request comprises the encrypted first nonce, and a receiving unit configured to receive a VM attestation report from the VM, the VM attestation report being generated by the VM, and a HV attestation report from the HV, the HV attestation report being generated by the HV, and wherein the processor is further configured to verify whether the VM attestation report is based on the first nonce, and to validate the integrity of the VM on the basis of the verification of the VM attestation report and on the basis of the HV attestation
• the attestation sever comprises a public part of the vEK (VEK PU B), a public part of a virtual attestation identity key vAIK (VAI K PU B), a public part of a physical endorsement key pEK (pEKpuEs) and a public part of a physical attestation identity key pAIK (PAI K PU B), and wherein the processor is further configured to validate the integrity of the VM by means of the VM attestation report, of the VAI K PU B and of the VEK PU B, and to validate the integrity of the HV by means of the HV attestation report, of the pAIK PU B and of the pEK PU B-
• the invention relates to a server which is configured to run a virtual machine (VM) and a hypervisor (HV), wherein the virtual machine VM is configured to receive a VM attestation request, wherein the VM attestation request comprises an encrypted first nonce encrypted using a virtual endorsement key, vEK, wherein the hypervisor HV is configured to receive a HV attestation request, to decrypt, by a virtual trusted platform module, vTPM, running on the HV, the encrypted first nonce on the basis of a vEK stored in the vTPM in response to a decryption request from the VM, wherein the virtual machine VM is furthermore configured to receive a first quote from the vTPM, wherein the first quote is signed with a virtual attestation identity key, vAIK, stored in the vTPM and comprises the first nonce, and to generate a VM attestation report about the VM, the VM attestation report comprising the first quote, and wherein
• VM virtual
• the invention relates to a system comprising an attestation server and a server, wherein the attestation server comprises a processor configured to encrypt a first nonce using a virtual endorsement key, vEK; and a transceiver configured to send a VM attestation request to the VM and a HV attestation request to the HV, wherein the VM attestation request comprises the encrypted first nonce, and to receive a VM attestation report from the VM, the VM attestation report being generated by the VM, and a HV attestation report from the HV, the HV attestation report being generated by the HV, wherein the processor is further configured to verify whether the VM attestation report is based on the first nonce, and to validate the integrity of the VM on the basis of the verification of the VM attestation report and on the basis of the HV attestation report, and wherein the server comprises a virtual machine (VM) and a hypervisor (HV) running on
• VM virtual
• the invention relates to a computer program comprising a program code for performing the method of the first aspect or any one of the
• the invention can be implemented in hardware and/or software.
• FIG. 1 shows a schematic diagram of server comprising a hypervisor and two virtual machines
• Fig. 2 shows a schematic diagram of a system comprising an attestation server and a server comprising a hypervisor and a virtual machine according to an embodiment
• Fig. 3 shows a schematic diagram of a system comprising an attestation server and a server comprising a hypervisor and a virtual machine according to an embodiment
• Fig. 4 shows a schematic diagram of a system comprising an attestation server and a server comprising a hypervisor and a virtual machine according to an embodiment
• Fig. 5 shows a schematic diagram illustrating several steps of a method for attesting an integrity of a virtual machine according to an embodiment
• Fig. 6 shows a schematic diagram illustrating several steps of a method for attesting an integrity of a hypervisor according to an embodiment
• Fig. 7 shows schematic diagram of a method for attesting an integrity of a virtual machine according to an embodiment
• Fig. 8 shows a schematic diagram of a method for generating attestation reports by a virtual machine and by a hypervisor running on a server according to an embodiment.
• FIG. 2 shows a schematic diagram of a system 200 comprising an attestation server 230 and a server 210 comprising a hypervisor 214 and a virtual machine 212 according to an embodiment.
• the attestation server 230 and the server 210 can communicate via a communication channel 220, for instance, a wired or wireless communication channel 220.
• the attestation server 230 can attest the integrity of the virtual machine (VM) 212 supported by the hypervisor (HV) 214 running on the server 210.
• the attestation server 230 comprises a processor 232 configured to encrypt a first nonce using a virtual endorsement key, vEK, and a transceiver 234.
• the transceiver 234 can be configured to send a VM attestation request to the VM 212 and a HV attestation request to the HV 214, wherein the VM attestation request comprises the encrypted first nonce, and to receive a VM attestation report from the VM 212, the VM attestation report being generated by the VM 212, and a HV attestation report from the HV 214, the HV attestation report being generated by the HV 214.
• the processor 232 can be configured to verify whether the VM attestation report is based on the first nonce, and to validate the integrity of the VM 212 on the basis of the verification of the VM attestation report and on the basis of the HV attestation report.
• transceiver Although reference is made in the previous paragraph to a transceiver, it is clear that this is not the only possible implementation.
• the transmitting and receiving function in this and in the following embodiments can also be carried out by separate independent units, such as a transmitter (transmitting unit) and a receiver (receiving unit).
• the server 210 can generate, by means of the VM and of the HV, attestation reports of the virtual machine VM 212 and of the hypervisor HV 214 running on the server 210.
• the virtual machine VM 212 as well as the hypervisor HV 214 are configured to receive, from the attestation server 230, the VM attestation request and the HV attestation request, respectively.
• the VM attestation request can comprise the encrypted first nonce encrypted using the virtual endorsement key, vEK.
• the HV 214 can be configured to decrypt, by a virtual trusted platform module, vTPM, running on the HV 214, the encrypted first nonce on the basis of the vEK stored in the vTPM in response to a decryption request from the VM 212.
• the virtual machine VM 212 can furthermore be configured to receive a first quote from the vTPM, wherein the first quote is signed with a virtual attestation identity key, vAIK, stored in the vTPM and comprises the first nonce, and to generate a VM attestation report about the VM, the VM attestation report comprising the first quote.
• the hypervisor HV 214 can furthermore be configured to generate the HV attestation report about the HV 214.
• the attestation of the HV 214 is initiated after the VM attestation report or integrity report has been already received by the attestation server 230 or remote verifier.
• different channels are used for attesting the VM 212 and the HV 214, namely the attestation server 230 connects to both VM 212 and HV 214 independently, as schematically illustrated in figure 3.
• This embodiment of the invention allows a multiple channel independent deep attestation and has the advantage of performing a deep attestation of the VM 212 and of the HV 214 in a scalable manner.
• the server 210 can support a plurality of VMs running on the same HV 214, and the attesting server 230 can attest the plurality of VM at once.
• the attestation server 230 can initiate an attestation of the HV 214. Since the attestation of the HV 214 is performed after the attestation of all VMs, the solution scales.
• Embodiments of the invention allow also to implement a scalable layer binding into the aforementioned multiple channel independent deep attestation. To this aim, in
• the layer binding mechanism is tailored to the architecture of the multiple channel independent deep attestation and the scalability is advantageously maintained unchanged, as explained in the following steps.
• the encrypted nonce during VM attestation is used, which can only be decrypted by a vRoT (i.e., vTPM running on the HV 214) that holds the private parts of both the vRoT instance identification key and of the vRoT instance integrity report signing key.
• vRoT i.e., vTPM running on the HV 2114
• the public part of the identification key the key which was used for decryption
• the decrypted nonce are added to a list maintained in the HV 214.
• FIG. 4 shows a schematic diagram of an embodiment of the system 200 comprising the attestation server 230 according to an embodiment and the server 210 according to an embodiment, which comprises the hypervisor 214, the virtual machine 212 and the physical platform or compute node 216.
• the attestation server 230 is configured to perform the VM attestation of the VM 212 and the HV attestation of HV 214 on the basis of the aforementioned multiple channels independent deep attestation method.
• Each of the VMs 212 and the HV 214 can be attested as an independent platform while, later on, the attestation server 230 can correlate the results of each VM attestation with the one of the HV 214 it is running on.
• This embodiment has the advantage that the deep attestation requirements are appropriately addressed and the VM integrity report or attestation report is built on top of a CoT rooted in the pRoT of the HV 214.
• the keys used to sign integrity reports (AIKs - attestation identity keys) of each platform as well as their golden measurements are pre- registered in the attestation server 230, wherein the golden measurements define a set of measurements describing a state of the software of a platform that is considered to be not tampered.
• the golden measurements define a set of measurements describing a state of the software of a platform that is considered to be not tampered.
• TCG Attestation PTS Protocol Binding to TNC IF-M
• http://www.trustedcomputinggroup.org/resources/tcg_attestation_pts_protocol_binding_to _tnc_ifm) can be executed in order to create an integrity report or attestation report for each platform and deliver it to the attestation server 230 for evaluation.
• the main steps of such an attestation protocol can be summarized as follows: Firstly, the attestation server 230 establishes a network connection to an attestation agent running on the target platform (i.e., VM 212 or HV 214) via the communication channel 220. Secondly, the attestation server 230 generates a random nonce and it includes it in the attestation request sent to the attestation agent of the VM 212 or HV 214 (steps 1 .1 and 2.1 in Fig. 4).
• the attestation agent collects integrity data and requests a signature or quote form the pTPM/vTPM (steps 1 .3 and 2.3 in Fig. 4). Then, it provides also the nonce received from attestation server 230 so that it is also included in the signed data. This ensures freshness of information (i.e., anti-replay protection). Finally, the integrity data together with the quote (which together form the integrity report) are sent back to the attestation server 230 for evaluation (steps 1 .4 and 2.4 in Fig. 4).
• the HV attestation should be performed only after the integrity reports of all the targeted VMs running on top of it have successfully been received by the attestation server 230.
• the processor 232 of the attestation server 230 can be configured to execute this sequence, namely the HV attestation is initiated only after the VM attestations are completed. If the processor 232 cannot execute this sequence, the VM integrity reports or attestation reports may not be fully trusted, since a potential attacker can have a (ideally short) time window to compromise the vRoTs without being detected during the current attestation cycle.
• the attestation server 230 can validate the integrity state of both platforms types, namely VMs and HV 214.
• the integrity report of the HV is validated before starting the validation of any of the integrity reports of the VMs running on top of it. This ensures that the integrity reports of VMs are validated only in case it can be shown, by means of the HV integrity report validation, that their respective vRoTs are not tampered.
• the attestation server 230 verifies the measurements in the integrity report against golden measurements registered for that platform or a profile that is applicable to that platform (it usually does not scale to register golden measures for each platform, as multiple platforms have the same software configuration).
• the attestation reports generated according to embodiments of the invention provide strong deep attestation and layer binding proofs.
• Figure 5 shows a schematic diagram illustrating several steps of a method for attesting the integrity of the virtual machine VM 212 according to an embodiment.
• the attestation server 230 or attestation authority (AA) encrypts the nonce sent to the VM 212 with the public part of the virtual endorsement key (vEK).
• the vEK similar to an EK for pTPMs, is generated at the creation of the vTPM instance (assigned to the VM 212) and cannot be removed. Its purpose is to serve as an identifier of the vTPM instance (see also step 1 .1 in Fig. 4).
• the encryption can be performed according to a privacy certificate authority (PCA) protocol defined by the TCG, which is supported both in TPM family 1 .2 (see TPM Main Part 3 Commands, clause 15.2, "TPM Activate Identify”: http://trustedcomputinggroup.org/wp-content/uploads/TPM-main- 1 .2-Rev94-part-3.pdf) and TPM family 2.0 (Trusted Platform Module Library Part 3:
• PCA privacy certificate authority
• the VM attestation agent of the VM 212 decrypts the nonce using the vTPM, which can contain the private part of vEK and vAIK. Only if the VM 212 has access to the specified vTPM instance, it can successfully perform this step (see also step 1 .2 in Fig. 4). Additionally, the vTPM can store (e.g., write to a file) in the HV file system the decrypted nonce and public part of vEK (vEKPUB) used for decrypting that nonce. Thirdly, the VM attestation agent of the VM 212 requests a quote from the vTPM signed with the vAIK (see also step 1 .3 in Fig. 4).
• the VM attestation agent can provide the vTPM a hash of the previously decrypted nonce for inclusion in the quote. Hashing the nonce provides the advantage that the actual nonce value is known only by the attestation server 230 or AA and the VM 212 that has access to the correct vTPM instance, even when the protocol is executed over a non-secure connection (attacker cannot replay an attestation sequence).
• Figure 6 shows a schematic diagram illustrating several steps of a method for attesting the integrity of the hypervisor 214 according to an embodiment.
• the attestation agent running on the HV 214 can create a list with information regarding the public parts of vEKs of each active vTPM instance and the nonces which are used to decrypt (see also step 2.2 in Fig. 4).
• the list is created by the HV attestation agent based on the data exported by each vTPM instance to the HV file system (see also the description of step 1 .2 with reference to Fig. 5).
• the list of VEK PU B and the associated decrypted nonces list can be hashed and this hash can be included in the pTPM signed quote that is part of the HV integrity report (see also step 2.3 in Fig. 4).
• the generated hash can be combined (a hash over both) with the nonce provided by the attestation server 230 or AA in the HV attestation request. This provides the advantage that, at the same time, an attacker cannot perform a replay attack and also that the quote signatures prove the integrity of the list.
• the integrity report sent back to the attestation server 230 or AA can also include the list of vEKs and nonces (see also step 2.4 in Fig. 4).
• the HV attestation agent can ensure that the VEK PU B and nonces exported by the vTPM instances which have been included in the list sent as part of the HV integrity report are removed from the file system. Since the nonces are relevant only for one (the current) attestation cycle, there is no advantage to accumulate this information over time. This can also reduce the data payload in the HV integrity report.
• a database can be updated with the contents of the list containing the public parts of vEKs and the nonces which they can decrypt on the HV 214.
• the database can record the links between a HV identity, a vEK and a nonce that was decrypted by the vEK, as part of a vTPM instance running on the identified HV (see also step 3.1 .3 of Fig. 4).
• two additional checks can be performed. It can be checked whether the nonce in the quote is actually a hash of the nonce sent encrypted in the attestation request.
• a successful verification of the nonce implies that the VM 212 can have access to the appropriate vTPM instance containing the private parts of both vEK and vAIK (see also step 3.2.1 in Fig. 4).
• the nonce can further be checked against the database updated in step 3.1 .3 of Fig. 4, during HV integrity report validation (see also the aforementioned steps of the HV 214 validation method). If the nonce is found in the database as being processed with the expected vEK and on the expected HV 214, it can provide a sufficient evidence that the layer binding was properly addressed (see also step 3.2.3 in Fig. 4).
• An advantage of the attestation method of the VM 212 and of HV 214 according to embodiments of the invention is that it provides a cryptographic proof that the vTPM used in VM attestation was running on the expected HV 214. This is due the fact that only a vTPM with the proper vEK and vAIK can decrypt the nonce sent encrypted by the attestation server 230 or AA. Moreover, the HV attestation protocol provides signed proof by means of the quote that the nonce decryption operation was performed on that specific HV 214.
• Another advantage of embodiments of the attestation method of virtual machines and of the HV 214 is that it scales, supporting deployments with big numbers of VMs running on the same HV 214. This is facilitated by that fact that only one HV attestation is required following the attestation of multiple different VMs, without any impact on security.
• the attestation method also helps in limiting the attack surface, as it does not require invasive introspection of vTPM sensitive internal data by other HV components.
• the VEKPUB and nonces that originate from the vTPM instances can be collected by the HV through a simple "push" mechanism: the vTPM instance can write these values to designated areas of the HV file system. This can effectively be a one-way, write-only communication channel that can be enforced and protected through existing confinement technologies (e.g., SELinux).
• FIG. 7 shows schematic diagram of a method 700 for attesting the integrity of the virtual machine VM 212 according to an embodiment.
• the method 700 comprises the steps of encrypting 702 a first nonce using a virtual endorsement key, vEK, sending 704 a VM attestation request to the VM and a HV attestation request to the HV, wherein the VM attestation request comprises the encrypted first nonce, receiving 706 a VM attestation report from the VM, the VM attestation report being generated by the VM, and a HV attestation report from the HV, the HV attestation report being generated by the HV, verifying 708 whether the VM attestation report is based on the first nonce, and validating 710 the integrity of the VM on the basis of the verification of the VM attestation report and on the basis of the HV attestation report.
• vEK virtual endorsement key
• the method 700 can be performed by the attestation server 230 described in the context of figure 2. Further features of the method 700 result directly from the functionality of the attestation server 230 and its different implementation forms.
• FIG. 8 shows a schematic diagram of a method 800 for generating attestation reports by the virtual machine VM 212 and by the hypervisor HV 214 running on the server 210 according to an embodiment.
• the method 800 comprises the steps of receiving 802, by the VM 212, a VM attestation request, and, by the HV 214, a HV attestation request, wherein the VM attestation request comprises an encrypted first nonce encrypted using a virtual endorsement key, vEK, decrypting 804, by a virtual trusted platform module, vTPM, running on the HV 214, the encrypted first nonce on the basis of a vEK stored in the vTPM in response to a decryption request from the VM 212, receiving 806, by the VM 212, a first quote from the vTPM, wherein the first quote is signed with a virtual attestation identity key, vAIK, stored in the vTPM and comprises the first nonce, generating 808, by the VM 212

Priority Applications (2)

Applications Claiming Priority (1)

Publications (1)

Family

ID=58264529

Family Applications (1)

Country Status (2)

Cited By (7)

Families Citing this family (1)

Citations (1)

Family Cites Families (6)

• 2017
  • 2017-03-08 WO PCT/EP2017/055491 patent/WO2018162060A1/en active Application Filing
  • 2017-03-08 CN CN201780087951.9A patent/CN110770729B/zh active Active

Patent Citations (1)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events