Method for confirming that a remotely installed version of software is properly configured

Abstract

Systems and methods for confirming that a remotely installed version of a piece of software is installed and configured with specific features. A user machine receives an authentication response from a remote machine on which the software is installed. The user machine then downloads a digital attestation and, if the digital attestation is found to validate the authentication response, then the user machine can download resources to build a local copy of the software. The local copy of the software is built using a deterministic build and this local copy is measured and fingerprinted. The fingerprint of the local copy is compared to the previously received digital attestation. If the digital attestation validates the fingerprint, then the local copy is a similarly configured version of the version on the remote machine. The software, in one implementation, is an OpenVPN server.

Description

Atorney Docket No. 1739P001US01METHOD FOR CONFIRMING THAT A REMOTELY INSTALLED VERSION OF SOFTWARE IS PROPERLY CONFIGUREDTECHNICAL FIELD

[0001] The present invention relates to systems and methods relating to software authentication. More specifically, the present invention provides systems and methods for confirming that a remotely installed piece of software is configured with at least one specific feature.BACKGROUND

[0002] Since the creation of the Internet and the spread of participation in online activities, Internet access is now almost considered, in some sectors, as a human right. This inexorable rise in online activities has come with the unpleasant risks of being online - everything from software pirates, trolls, hackers, identity thieves, and similar ilk. To ensure a safer online presence, security experts usually recommend the use of a VPN (virtual private network) service. Use of such a VPN service masks a user’s IP address and can make a user in Canada appear to be coming from an IP address from anywhere in the world. Such VPN services are almost invaluable, especially when it comes to hiding a user’s geographical location.

[0003] However, while VPNs are useful, there is a possible issue with such services - the VPN providers can track and / or log a VPN user’s online activity. Such tracking and / or logging is, clearly, unwanted as logging the VPN user’s activities reduces the effectiveness of using a VPN. One of the advantages of using a VPN, generally, is from the anonymity that it affords a user. However, tracking a VPN’s activities, and logging such activities, renders the user trackable and, therefore, reduces the VPN’s effectiveness.

[0004] As is well-known, VPNs enhance internet privacy by redirecting a user's Internet traffic, which is normally visible to the Internet service provider (ISP), through an encrypted channel to a VPN provider, who is considered more trustworthy thanAtorney Docket No. 1739P001US01 the ISP. However, customers of privacy-enhancing VPNs must rely on the provider to honestly implement their claimed privacy policies (e.g., log suppression). Unfortunately, customers' trust in VPN providers has been broken with data breaches that resulted in the release of highly sensitive information, including user logs.

[0005] Historical atempts to address this concern include VPN providers' "no logs" policies and associated auditing programs. However, this still requires customers to blindly trust VPN providers to do as they claim.

[0006] Accordingly, there is a need for systems and / or methods that allow users to confirm and / or authenticate that a VPN provider’s VPN servers are configured to suppress user activity logs. Such systems and / or methods, preferably, allow a user to trace and / or track a chain of trust in terms of the VPN provider’s selfassessment of its implementation of privacy policies / privacy measures.SUMMARY

[0007] The present invention provides systems and methods for confirming that a remotely installed version of a piece of software is installed and configured with specific features. A user machine receives an authentication response (or digital signature) from a remote machine on which the software is installed. The user machine then downloads a digital atestation and, if the digital atestation is found to validate the authentication response (or digital signature), then the user machine can download resources to build a local copy of the software. The local copy of the software is built using a deterministic build, and this local copy is measured and fingerprinted. The fingerprint of the local copy is compared to the previously received digital atestation. If the digital attestation validates the fingerprint, then the local copy is a similarly configured version of the version on the remote machine. A further step of confirming that the local copy is properly featured and configured may also be undertaken.Atorney Docket No. 1739P001US01

[0008] In a first aspect, the present invention provides a method for confirming that a remotely installed server software installed on a remote machine is configured with at least one specific feature, the method comprising: a) building a copy of said server software on a local server to result in a local installation of said server software; b) automatically confirming that said local installation is an exact copy of said remotely installed software in terms of configuration and content; and c) automatically confirming that said local installation is configured with said at least one specific feature.

[0009] In another aspect, the present invention provides a method for confirming that a remote installed software installed at a remote machine is configured with at least one specific feature configured and installed, the method comprising: a) sending an authentication challenge to said remote machine; b) receiving an authentication response from said remote machine, said authentication response relating to software operating on said remote machine; c) downloading a digital atestation from a download server that is different from said remote machine; d) confirming that said authentication response is validated by said digital atestation; e) downloading resources for building a copy of said remote installed software on a local machine; f) building said copy of said remote installed software in said local machine to result in a local copy of said remote installed software; g) assessing said local copy to result in a local fingerprint for said local copy; h) confirming that said local fingerprint is validated by said digital atestation; whereinAtorney Docket No. 1739P001US01- when either of confirming steps d) and h) is not confirmed, stopping said method and determining that said remote installed software installed at said remote machine is not verifiably configured with at least one feature configured and installed; and- step f) is executed such that said local copy is compiled and linked deterministically.

[0010] In one embodiment, prior to step a), an authentication response for said remote machine is confirmed to be validated by a digital atestation received from a download server that is different from said remote machine.

[0011] In a further embodiment, the digital attestation includes a cryptographic digest of at least a portion of an operating environment used for said remote installed software.

[0012] For another embodiment, the digital atestation is generated and uploaded to the download server by said remote machine after said remotely installed software has been installed and said remote machine is initially booted.

[0013] In another aspect, the digital atestation includes a cryptographic digest of at least one of:- a kernel of an operating system used by said remote machine;- an initial root fde system of said operating system used by said remote machine;- a kernel command line for said operating system; and- firmware for use by said remote machine.

[0014] In one embodiment, the remote machine is a virtual machine (VM) operating on a host system.

[0015] Yet another embodiment provides that the digital atestation includes a cryptographic digest of at least a portion of an operating environment used for said virtual machine.

[0016] In another embodiment, the digital atestation is a Remote Attestation Report (RAR) generated by said remote machine, said RAR being signed by a hostAtorney Docket No. 1739P001US01 machine on which said virtual machine is operating. For clarity, as used herein, a “remote atestation report” refers to a signed measurement artifact generated by a processor or its embedded security subsystem, and may include not only the measurement and its signature and may include any associated or accompanying credential chain or root certificate necessary or useful for verification.Preferably, if this material is not included with the RAR, such material is expected to be available to users.

[0017] In another aspect, step e) comprises downloading build environment resources for implementing a trusted build environment that is to be used to build a copy of said remote installed software on said local machine.

[0018] As another embodiment, the build environment resources include parameters and input to be used with trusted build environment to build said copy of said remote installed software on said local machine.

[0019] In a further aspect, the method is executed by a machine different from said remote machine.BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The embodiments of the present invention will now be described by reference to the following figures, in which identical reference numerals in different figures indicate identical elements and in which:FIGURE 1 is a detailed timeline / logic flow diagram detailing the steps in one aspect of the present invention;FIGURE 2 is a flowchart detailing the steps in a method according to another aspect of the present invention from the point of view of a user;FIGURE 3 is a schematic flowchart detailing the steps to be executed by an infrastructure operator to implement a variant of the present invention; andAttomey Docket No. 1739P001US01FIGURE 4 is a schematic flowchart detailing the steps to be executed by a user or a verifier when validating an implementation of the present invention according to the variant of the present invention.DETAILED DESCRIPTION

[0021] In one aspect of the present invention, there is provided systems and methods for confirming that software installed on a remote machine is configured such that one or more specific features are installed and / or enabled or disabled. In this aspect, the software is installed on a machine remote from a user and the user machine queries the remote machine for confirmation and / or authentication. The remote machine provides an encrypted authentication response that includes a so- called digital signature. The user machine then downloads a purported copy of a digital remote attestation report from a public server, the purported copy being uploaded by the remote machine when the software was originally booted on the remote machine. The user machine then validates the authenticity of the purported attestation report by verifying the cryptographic chain of trust from the CPU manufacturer’s root certificate (or key) to the attestation report. Upon successful validation, the process proceeds. The user machine then compares the digital signature (received by way of the authentication response) from the remote machine with the purported copy of the remote attestation report from the public server and, if the remote attestation report validates the digital signature, then the process proceeds. Once the remote attestation report has been found to validate the digital signature, the user machine then downloads and builds a copy of the software from the public server, along with the resources necessary to build the software. Preferably, the remote machine downloaded this build copy from the same public server. Once the user machine has downloaded the build copy, this build copy is install ed / built on the user machine using the downloaded resources. The build copy (now a copy local to the user machine or a local copy) is then measured or fingerprinted to result in a digital fingerprint. This now local digital fingerprint is compared / validated based on the purported copy of theAtorney Docket No. 1739P001US01 remote atestation report received from the public server. If the local fingerprint is found to be validated by the remote atestation report, then the local copy is a copy of the software installed on the remote machine. As a final check to make doubly sure that the remote software is configured properly, the local copy is then checked to determine that the one or more specific features are installed and / or enabled or disabled on the local copy. Once this check determines that the desired specific features are installed and / or enabled or disabled on the local copy, then this means that the software installed on the remote machine is equally configured as such.

[0022] For clarity, a fingerprint, as used in this document, is a cryptographic fingerprint (hereinafter “fingerprint” or “digest”) that is a deterministic value derived from one or more digital artifacts through the application of a cryptographic hash or equivalent one-way function. The fingerprint uniquely characterizes the input data with a high degree of collision resistance, such that any modification to the input produces a substantially different output.

[0023] In particular embodiments, the fingerprint may represent a measurement or composite measurement of one or more software or firmware components, such as a kernel image, initialization image, configuration parameters, or firmware module. In some embodiments, the fingerprint may be derived from or applied to cryptographic key material, such that a key fingerprint serves as a compact, fixed-length identifier of a public key, certificate, or other cryptographic credential. In this context, the key fingerprint enables representation, transmission, or storage of potentially large key material (for example, an RSA or post-quantum public key) within constrained or user-defined fields, such as those present in configuration records or remote-atestation reports, without requiring the full key to be embedded.

[0024] The fingerprint or digest may be computed locally or remotely and may be used to verify integrity, authenticity, or identity of a component, device, key, or system state. In certain embodiments, a fingerprint may further be employed in authentication or atestation exchanges to associate a device, process, or communication session with a verified cryptographic identity.Atorney Docket No. 1739P001US01

[0025] The terms fingerprint and digest are used interchangeably and are intended to encompass any one-way digest, message authentication code (MAC), keyed hash, or signature-derived value that serves as an invariant identifier for a digital object, cryptographic key, or composition thereof.

[0026] In one implementation, the software installed on the remote machine is an OpenVPN server software and ancillary software that provides VPN services to users such that users connect to the greater Internet space by way of the OpenVPN server. This provides users with VPN features that safeguard the user’s privacy by hiding the user’s identity, location, and / or activities.

[0027] OpenVPN is Virtual Private Network (VPN) software suite available for Windows, Linux, and Mac. It comprises a server and client. While OpenVPN is used in one implementation of the present invention and has been used in the discussion to follow, any similarly equipped VPN suite (e.g., WireGuard) could be used in its place. For simplicity, for this document, the term “OpenVPN server” is used to refer to the general VPN server software.

[0028] OpenVPN server is usually configured to collect logs on connected users. In one aspect, the present invention uses an OpenVPN configuration that suppresses the generation of logs and uses additional measures to cryptographically prove to users that log generation has been suppressed.

[0029] For one implementation of the present invention, the remote machine uses a version of the Linux operating system. Accordingly, provided below are some points regarding this operating system to allow the reader to beter understand the present invention.

[0030] For the Linux operating system, Linux commences booting when the system firmware passes control to the linux kernel, which is usually supplied with an initramfs (Initial RAM filesystem) image. The initramfs usually contains a very small number of executable and configuration files, the main purpose of which (typically) is to provide the functionality for mounting the rootfilesystem (typically a hard disk present on the machine running the operating system). The functionality of initramfs can be quite minimal (e.g., perhaps a helper program that connects to a network drive or prompts for a password to decrypt the localAttomey Docket No. 1739P001US01 hard drive). Once root is mounted, control is passed to an executable that resides on the newly mounted root partition, and a highly complex startup process ensues. This startup process brings up general networking, USB device hotplugging, graphics, dbus, etc. The time spent by the system before root is mounted (i.e., running code in initramfs) is known as early userspace. Early userspace is capable of running any linux binary, provided that the linux binary is self contained or at least has its dependencies met by the resources available in the initramfs fde system. An arbitrary binary taken from a linux system will typically not execute correctly in early userspace, since it will likely possess unmet dependencies on (e.g., systemd, dbus, graphics, dynamic libraries, etc.). However, many command-line binaries can be compiled statically such that they can be launched in early userspace.

[0031] While early userspace is of little more than academic interest in most IT applications, when the system functionality is extremely simple and / or hardware resources are limited (e.g., for embedded systems), a binary running in early userspace can serve as the terminus of the startup process. For the present invention, the radical simplicity of early userspace is useful. In one implementation, it is preferred that the execution of the OpenVPN server software is demonstrably immune from outside, out-of-channel input from human input devices (e.g. keyboard and mouse), network, serial I / O, storage devices, PCI / passthrough, and management control panels (such as QEMU guest agent or paravirt devices). This is because such input can be maliciously used to reconfigure the system and to enable logging or otherwise monitor traffic. While a normally booted linux system can be configured to ignore out-of-channel inputs, such a configuration would be complex, prone to bugs, and difficult to verify, leaving prospective users unsure of whether the system is truly incapable of collecting logs. On a system that never leaves early userspace, complete severance from outside keyboard, mouse, and network input is trivially effected and easily verified. For this reason, it is preferred that the OpenVPN server is statically compiled and deployed from early userspace. For clarity, it is highly preferred that the Linux system running on the remote machine never leaves early userspace. This allows the Linux system to be locked down and for, as noted above, complete severance from outside keyboard and mouse functions. Thus, inAtorney Docket No. 1739P001US01 the preferred remote machine, once the system is built and booted, no outside input (as in no keyboard or mouse input) can be accepted. Once properly built and configured, the remote machine can, therefore, not be modified to log traffic. As noted above, a configuration that does not log traffic is the desired configuration for the OpenVPN software.

[0032] For a Linux implementation of the present invention, some extra steps may be used. The Linux operating system accepts a wide array of kernel command line parameters that affect operation of the system. Several parameters enable or disable inputs, including keyboards, mice, networking, serial I / O, storage and PCI / passthrough. A second, independent complete severance from external inputs can be effected with a combination of build parameters (that determine how the kernel is compiled), and kernel command line parameters that are specified at the time the VM is launched. One set of build parameters that disables all inputs is given by:CONFIG MODULES=nCONFIG_PCI=n CONFIG_USB=n CONFIG INPUT=n CONFIG HID=n CONFIG SERIO=n CONFIG_VSOCKETS=n CONFIG VIRTIO MENU=n CONFIG VIRTIO PCI=n CONFIG VIRTIO MMIO=n CONFIG HYPERV=n CONFIG PARAVIRT=nCONFIG NET=nCONFIG BLK DEV INITRD=y CONFIG BLK DEV=n CONFIG_9P_FS=nCONFIG VIRTIO FS=nCONFIG TTY=nAttorney Docket No. 1739P001US01CONFIG VT=nCONFIG FRAMEBUFFER CONSOLE=nCONFIG _DRM=nCONFIG_SERIAL_8250=n CONFIG SERIAL CORE=n CONFIG HVC DRIVER=n CONFIG HVC XEN=nCONFIG HVC VIRTIO=nCONFIG HW RANDOM=nCONFIG CRYPTO JITTERENTROPY=yCONFIG KEXEC=nCONFIG KEXEC FILE=nCONFIG_MAGIC_SYSRQ=n

[0033] Similarly, one set of kernel command line parameters that disable the remaining I / O is: pci=off ip=off rd.neednet=O systemd.mask=serial-getty @tty SO. service, serial- getty@hvcO. service

[0034] Note that the above kernel command disables all input / output, and, as such, networking would need to be re-enabled. There are several ways to do this, depending on system design.

[0035] It should be clear that, as noted above, the preferred configuration of the remote machine is such that the Linux operating system never leaves early userspace and that the Linux kernel was built and booted with parameters that disable unnecessary and potentially dangerous I / O. Local input (e.g., from mouse and / or keyboard) cannot be used to reconfigure / adjust the remote machine configuration because:- the initramfs was built in a manner that rendered the keyboard, mouse, and other relevant input / output mechanisms effectively disabled;- the initramfs was built with networking carefully enabled - there exists no means by which a malicious person (either a service operator or anyone else) isAtorney Docket No. 1739P001US01 able to log into a terminal since such services (e.g., SSH server) were never built into the initramfs;- the kernel was built and / or booted with kernel command line parameters that deactivate input devices, including keyboards and mice.

[0036] It should, however, also be clear that networking on the remote machine is not disabled completely as users must be able to connect to the VPN server.

[0037] Virtual machines are another component in at least some implementations of the present invention. Virtual machines (VMs) are software emulations of hardware computer systems, allowing one or more guest operating systems to run on a host operating system. For example, one or more virtualized instances of Windows could be run on a single Mac computer. The host software that coordinates activity between the virtualized environment and host system is known as the hypervisor. While virtualization is sometimes used in desktop computing, the vast majority of virtual machines exist in data centers, where several VMs are typically instantiated on a single server system. When the VM is configured as a server (e.g., email or webserver), it is known as a Virtual Private Server or VPS.

[0038] As noted above, the VM is used in at least some implementations of the present invention. For some implementations, an OpenVPN server is configured within a guest (i.e., run in a VM), which is run on a host system. Although there is a slight performance penalty associated with running OpenVPN inside a VM (as opposed to execution on bare metal), benefits may be reaped on new server CPUs equipped with powerful cryptographic extensions that improve virtualization security as will be explained below. These security extensions can be used with the present invention to cryptographically prove the absence of log collection.

[0039] It should be noted that, for some implementations, a Trusted Execution Environment (TEE) is used in the present invention. A TEE is a secure processing environment furnished by the CPU. A TEE safeguards entrusted data and CPU instructions from other processes running on the same system by ensuring data privacy (i.e., outside processes are prevented from viewing TEEAtorney Docket No. 1739P001US01 data), and data integrity (i.e., outside processes cannot modify TEE data). The TEE is therefore a “black box” in which computing is fully segregated and concealed from the larger system. In the enterprise market, TEEs have recently been unveiled in server CPUs in response to market demands engendered by the move to cloud computing. For example, a medical records company may hesitate to migrate their physical servers to cloud VMs for fear that the cloud provider, which runs the hypervisors, will snoop or (more likely) fail to adequately secure the host machine against malicious infdtration. Both AMD and Intel have developed technologies that allow guest data and code to be completely protected from the host machine via memory and CPU register encryption and additional security measures safeguarding against replay atacks, etc. The AMD and Intel solutions are designated Secure Encrypted Visualization (SEV) and Trusted Domain Extensions (TDX), respectively. In some implementations, the present invention was used with AMD SEV-SNP. However, it should be noted that the present invention applies to all suitably equipped TEEs. Preferably, the remote machine is operated as a TEE.

[0040] It should be clear that the mere protection of data and code is inadequate under most use cases. Using the medical records example explained above, that company must confirm two characteristics of the remote VM before uploading any sensitive data: i) that the running VM is legitimate (i.e., it is the VM image supplied by the company and not some malicious substitute), and ii) the (legitimate) VM has indeed been booted into a TEE VM and not a regular, unprotected VM. Such assurance can be provided in the form of Remote Atestation - cryptographic proof that the remote machine is a legitimate VM image that has been booted into a TEE. On a SEV-SNP-enabled machine, the guest (running in the VM) can send a request for a Remote Attestation Report (RAR) to the hypervisor, which in turn forwards it to the CPU for processing. A valid request will prompt the CPU to send a cryptographically signed RAR to the hypervisor, which will return it to the guest VM. The cryptography is constructed in a manner such that communications are safe from undetectable tampering by a malicious hypervisor. Returning to the medical records example, once the RAR has been reviewed by the medical records company and once authentication to the remote machine has been found to be validated by the RAR, that companyAtorney Docket No. 1739P001US01 can proceed to upload sensitive information with full confidence in the VM’s security. It should be clear that, at least in AMD-based systems, the hypervisor is not the element that directly sends the completed RAR back to the guest VM. The guest VM obtains the completed report by polling.

[0041] While remote atestation was originally developed as a means to verify the integrity and security of private remote VMs, it can be used as a mechanism that allows providers of public Internet services to give cryptographic assurance to customers that the rendered service conforms to certain advertised characteristics. As used in the present invention, the remote atestation concept allows VPN providers to cryptographically prove that i) the VM containing OpenVPN is running in a secure enclave that blocks snooping by the provider (privacy) and guarantees correct execution of the code (integrity); and ii) the VM to which the client is connected is running specific, predefined code (an honest, no-logs configuration of OpenVPN). The entire VM image containing OpenVPN can be shared with the client, allowing the client to i) confirm the honesty of the VM configuration through scrutiny of its image, and ii) to cross check the cryptographic digest of the provided VM image against the counterpart stored in the atestation report to confirm that the remote VM image and the VM image reviewed by the client are one and the same.

[0042] It should be clear that the use of remote atestation, the RAR, and the building of the OpenVPN software in a TEE on the remote machine addresses other potential security issues. To clarify, to implement the remote machine, a VPN operator executes:- a version of qemu with:- a kemel_file,- a initramfs_file,- a commandline_parameter_file,- an emulated firmware file, where qemu is the hypervisor executable, and the four arguments comprise the tetrad as will be explained in more detail below. As noted above, the keyboard and mouse have been disabled and network traffic is carefully filtered. Accordingly, outside parties (including the hypervisor, the host machine, and theAtorney Docket No. 1739P001US01 administrator of the host machine) cannot alter the execution course of the VM guest in a manner that compromises security.

[0043] It should also be noted that, for OpenVPN, one can pass either command line switches and / or config files to the OpenVPN to turn off (or turn on) logging. However, simply configuring OpenVPN in this manner is inadequate because:- the firmware file could contain a backdoor that snoops on OpenVPN's traffic, allowing sensitive information to be exfiltrated;- a carefully chosen kernel command line parameter or the omission of a kernel command line parameter could potentially render the virtualized system vulnerable to outside control;- the kernel file could be that of a compromised kernel that is backdoored to snoop on OpenVPN and exfiltrate sensitive information; and- the initramfs could contain additional software (e.g., a loadable kernel module that snoops and exfiltrates as before, or a script that restarts OpenVPN with logging re-enabled).

[0044] These security vulnerabilities noted above can be completely resolved by using a TEE and remote attestation.

[0045] Provided in Appendix A at the end of this document is a human readable rendering of an RAR generated on a third generation (Naples) EPYC CPU (annotations are in italics).

[0046] Referring to the RAR in Appendix A, the trailing signature in the RAR was generated by the CPU by digitally signing the report with a previously issued VCEK (Versioned Chip Endorsement Key), whose root of trust is held by AMD (the manufacturer of the CPU). As noted above, this implementation used an AMD CPU. Assuming hardware and microcode security, security of the keygeneration and chaining process, and trustworthiness of AMD, this trailing signature can be taken as cryptographic proof that the contents of the report are valid.Atorney Docket No. 1739P001US01

[0047] In the RAR, the sections that may be most relevant to the present invention appear in bold. The Report Data field comprises the arbitrary, guest-supplied data that accompanied the RAR request sent to the CPU by the guest. For the present invention, this Report Data field is populated with a cryptographic key or a fingerprint (or cryptographic digest) of a cryptographic key. In one aspect of the present invention, this field includes the fingerprint of the public component of the asymmetric authentication key used by OpenVPN (running in the guest or remote machine) to authenticate itself to customers. The Measurement field in the RAR includes (in addition to other sundry data) the cryptographic digest of the i) hypervisor firmware (SEV-enabled OVMF), ii) guest kernel, iii) guest initramfs, and iv) guest kernel command line. This tetrad of data, whose “measurement” can be reviewed and verified, initiates the guest’s early userspace with complete determinism. For clarity, the OVMF can be seen to be the firmware used by the VM, the guest kernel is the kernel of the guest machine’s operating system, the guest intramfs is the initial root file system of the guest machine’s operating system, and the kernel command line is the command line used to configure the kernel of the guest machine. In one aspect of the present invention, software inside the initramfs includes the OpenVPN server / OpenVPN software.

[0048] For this implementation of the present invention, since the guest executes within an SEV-SNP -protected VM, the guest’s state cannot be directly manipulated by the host. Furthermore, assuming that the guest has been configured with sufficient security (firewalls, strong login passwords, etc.), it will also be immune to indirect manipulation by the host and, more generally, will remain secure from all other unauthorized outside manipulation. The guest’s time evolution will therefore be confined to a secure envelope of possible system states. In this implementation of the present invention, the guest system’s time evolution is particularly simple, since its functionality will be limited to perhaps two or three simply configured executables running in early userspace (one of which is OpenVPN server). If the guest initramfs has been configured honestly (e.g., with no logs for OpenVPN and a complete disabling of keyboard / mouse / out-of- channel network input / output), one can readily infer that the OpenVPN VM will remain honest over its entire lifespan. Thus, if a customer has, in their possession, an RAR whose Report Data field matches the key or the digest of the key used byAtorney Docket No. 1739P001US01OpenVPN server to authenticate itself, then the customer can review the tetrad comprising the kernel command line and OVMF, kernel, and initramfs source codes. Assuming this tetrad has been found to be sufficient, and if the cryptographic digest of the built tetrad binaries and command line matches the Measurement field of the RAR, the user can then have full confidence that communications through the authenticated OpenVPN server will not result in log collection.

[0049] For greater clarity, it should be noted that, to ensure that the remote machine and the guest VM on that machine is suitably locked down and cannot be changed / adjusted while operational, the remote machine and its guest VM have to be properly configured and initiated. This process will be explained in more detail below but it should be clear that the tetrad determines the intial conditions of the guest VM. The specific “command line” constituting an element of the tetrad is the kernel command line (i.e., parameters passed to the guest kernel when it is booted by the hypervisor). The command line parameters passed to OpenVPN are found in the script that launches OpenVPN from inside the initramfs. Furthermore, the tetrad’s kernel and initramfs already constitute a fully functioning system: no further downloading is necessary or even takes place once the tetrad is used as a new VM guest process as the initramfs already contains all the required software, including OpenVPN, and any required configurations for such required software (in principle, it may be acceptable for the initramfs to download external resources including code or executables, provided that they have been cryptographically signed and are validated before use or execution). OpenVPN (and possibly other software) is downloaded (and possibly cryptographically verified) by the script that prepares the tetrad and this tetrad is fingerprinted at the conclusion of the build process. The measurement counterpart is applied to the tetrad when the tetrad is running as a VM in a TEE that supports remote atestation: a RAR will contain the measurement, along with other data (such as user-supplied data field which is populated with the public fingerprint of OpenVPN’s authentication key).

[0050] Most software is written in source code that must be translated into a final binary executable through compiling and linking (collectively, building). The bitAtorney Docket No. 1739P001US01 sequence of the final binary can either be a deterministic function of the source code, in which case each invocation of the build process produces the same binary bit streams, or non-deterministic, in which case the bit sequence may vary among invocations. Non-determinism usually results from elements such as time stamps within the build environment, use of different compilers, or more generally, other variations in build environment parameters. The run-time performance consequence of non-determinism is almost never of concern. However, non-determinism may have significant security implications, since the functionality of software is far more easily discerned by review of the source code than by review of the compiled binaries, which involves time-intensive reverse engineering; if one wishes to understand the functionality of a given binary and the build process is deterministic, one simply needs to inspect the source code, build the source code, and then verify that the result is bit-for-bit verbatim to the original binary.

[0051] It should also be clear that the concept of deterministic builds (also known as reproducible builds) is used in one aspect of the present invention. The kernel, initramfs, and the OVMF blob of the OpenVPN VM image are built deterministically, allowing users to acquire a full understanding of their functionality through examination of source code alone.

[0052] Referring to Fig. 1, illustrated is a flow / time diagram detailing the steps in a method according to one aspect of the present invention. For this implementation, activity spans three computer systems evolving through time: a client (customer) machine, a server run by the VPN provider, and a second HTTP or FTP server (preferably publicly accessible), also run by the provider, again preferably. In principle, the servers administered by the provider could be consolidated into a single machine, or the provider could further divide operations across additional machines. Other configurations are, of course, possible.

[0053] The steps in a method according to one aspect of the present invention can be delineated into 19-20 discrete steps. Some of these steps can be combined, be executed concurrently, or be reordered.Atorney Docket No. 1739P001US01

[0054] In a preliminary step, it is assumed that the provider has a procedure for generating the VPN server guest tetrad such that the VPN server built / installed is equipped with the desired functionality (e.g., no logging) or with the desired configuration (e.g., with specific features enabled or disabled). This procedure can be implemented by means of a shell script that automates the process (see next section for details on this step). Henceforth, tetrad generation is assumed to be effected by a shell script. As can be seen from Fig. 1, some of the steps are executed by the VPN provider while others are executed by the user. For clarity, from the point of view of the user, it is assumed that the VPN provider has executed its steps and that, as such, the user can execute his / her steps without the need for a VPN provider’s intervention / assistance / involvement.

[0055] In STEP 1, the VPN provider downloads the script. It is assumed that, in most scenarios, the VPN provider operates multiple individual VPN server instances simultaneously and would obtain the most recently updated script from a central repository.

[0056] In STEP 2, the VPN provider builds the three binaries of the tetrad (see next section for details and Appendix B for an example script), which include the guest kernel image (configured to enable SEV-SNP and disable all undesired inputs / outputs), guest initramfs, and SEV-enabled hypervisor firmware (OVMF). The fourth element of the tetrad, the kernel command line string, does not requiring building (i.e., does not require compilation / linking). Additionally, an SEV-enabled hypervisor (QEMU) and an SEV-enabled host kernel may also be built at this time, as required. For some implementations that use SEV functionality that is fully integrated into the Linux kernel, the mainstream hypervisors, and the associated firmware blobs, the build steps may only involve initframfs generation by itself.

[0057] In STEP 3, the VPN provider launches the tetrad as a new virtual machine using the SEV-enabled QEMU and OVMF, which were built previously. Appendix C demonstrates a viable invocation of QEMU with the requisite command line flags.Atorney Docket No. 1739P001US01In STEP 4, the now booted guest in the host machine (the remote machine) generates a new random authentication key. One possible implementation involves executing openssl, which would have been compiled and installed on the guest initramfs, as openssl genrsa -out server . key 2048 which generates a 2048-bit RSA key.

[0058] In STEP 5, if required (if the public key length exceeds the length of the REPORT DATA field in the RAR), the guest computes the cryptographic digest of the public key. Several cryptographic-strength hash functions are available. For example, openssl rsa -in server . key -pubout -outform DER | openssl sha512 - binary > fingerprint . bin creates a SHA512 digest and saves it to fingerprint.bin.

[0059] In STEPS 6 and 7, a remote atestation report is obtained from the host following a request by the guest. Practically, this can be done with the snpguest (https : / / github. com / virtee) snpguest report . / report . bin . / fingerprint . bin which would have been compiled and installed on the guest initramfs. Note that padding of the fingerprint binary is necessary if its length falls short of 64 bytes (SHA512 requires no padding, since it produces digests of exactly 64 bytes). Upon completion of this step, there will exist a newly created file, report.bin, on the guest that is digitally signed by the host CPU’s Versioned Chip Endorsement Key (VCEK), whose ultimate root of trust is held by, in this implementation, the manufacturer of the host machine CPU, AMD.

[0060] In STEP 8, the guest (i.e., the remote machine) publishes the remote atestation report. This step can be carried out with command line versions of e.g., wget, ftp, etc. that upload the report to a public server. Alternatively, the file could beAtorney Docket No. 1739P001US01 passed to the host using one of several possible guest-host data pass-through mechanisms.

[0061] In STEP 9, the guest launches the OpenVPN server.

[0062] STEPS 10-13 embody the typical communication arising from a new connection request made by a client to the VPN server in which the server authenticates itself to the client using the key generated in step 4. The actual number of communication rounds and their content may vary across different VPN server software suites and / or their configurations. The depicted exchange constitutes the theoretically minimum number of rounds required to establish secure, public-key based authentication. The client then extracts the server's public key or public key fingerprint (or obtains the key or fingerprint from another source) and writes it to memory or a file (e.g., fingerprint_server.bin)

[0063] In STEP 14, the client downloads the published remote attestation report generated in steps 5 and 6, verifies its chaining to AMD’s root of trust, and saves it to memory or a file (e.g., rar. bin)

[0064] In STEP 15, the client extracts the Report Data field from the downloaded remote atestation report. This can be performed with a combination of snpguest, xxd, and grep using: snpguest display report rar . bin | grep "Report Data : " -A 4 | grep -v "Report Data : " | xxd -r -p - fingerprint_rar . bin where the result is saved to fingerprint_rar.bin. The client then executes e.g., cmp fingerprint_server . bin fingerprint_rar . bin to extract the fingerprint of the server’s public authentication key. The absence of any output (alternatively, a 0 return value) indicates that the fingerprints match. Any other result nullifies the validity of the report (since it would be unable to cryptographically atest to the honesty of the connected server), in which case the client should disconnect.

[0065] In STEP 16, the client downloads the build script.Atorney Docket No. 1739P001US01

[0066] In STEP 17, the client builds the tetrad. Details for building the tetrad are provided below. An example script for building the tetrad is provided in Appendix B.

[0067] In STEP 18, the client computes the measurement of the tetrad, which can be performed with sev-snp-measure.py (htps: / / github.com / virtee) as: sev-snp-measure . py --vcpus 1 — ovmf OVMF . fd — kernel bzlmage — initrd initramfz --append "pci=off ip=off rd. neednet=0 systemd.mask=serial- getty@ttyS0 . service , serial -getty@hvc0 . service" --mode snp --vcpu-type EPYC- Milan-v2 — output-format hex where the terms appearing in bold comprise the tetrad. The remaining terms also affect the measurement but remain mostly static over time (i.e., they only change when the VPN provider makes certain architectural / hardware modifications to its infrastructure). Note however, that the build script in Appendix B automatically computes the measurement of the tetrad, allowing steps 16 and 17 to be merged.

[0064] In STEP 19, the client extracts the Measurement field of the remote atestation report, which can be computed as snpguest display report rar . bin | grep "Measurement : " -A 3 | grep -v "Measurement : "

[0065] The client compares the result to the measurement of the locally built tetrad (from step 17). A match indicates to the client that the remotely running VPN server is an instantiation of the locally generated tetrad. Assuming the client (i.e., the user) trusts the build process (through review of the build script and / or any source files), the client may then regard a match as an indication that it is safe to proceed and that the OpenVPN server is properly configured (e.g., logging is disabled).

[0066] Finally, note that while the client-side tetrad build and measurement processes have been automated, this will be of litle value to lay users who lack the technical expertise required to critically review the shell script. For this reason, lay clients would likely compare the atestation report’s measurement field to a value published by a trusted third party. This process could be automated by deploying, for example, a publicly accessible JavaScript verification tool.Atorney Docket No. 1739P001US01

[0067] In STEP 20, the client initiates normal VPN traffic with the VPN server.

[0068] As can be seen from Fig. 1, steps 10 - 19 are executed by the user machine, and the user machine requests specific data / downloads, etc. from the remote machine and / or the public server. As an extra step, the user machine can be configured to automatically check its local copy of the installed software (e.g., the local OpenVPN server) to determine if the local copy is properly configured (e.g., logging is disabled). Once this check is completed and passed, since steps 10-19 (once passed and completed) indicate that the local copy is identical to the remote machine installed version, then, logically the remote machine installed version must also be suitably configured.

[0069] Also provided in Appendix C is an example script for launching the guest that runs the OpenVPN server. As noted above, the script in Appendix B builds and fingerprints the tetrad using the present invention. Once this tetrad has been built and fingerprinted, the guest that runs the OpenVPN server can be launched using, as an example, the script in Appendix C.

[0070] For greater certainty, it should be noted that all communications between the user and the instantiated tetrad running as a VM guest on the host / remote machine are encrypted, with the OpenVPN server (running inside the VM guest) authenticating itself to the user using asymmetric cryptography. However, for a beter understanding of the invention, it should be clear that the key generated inside the VM guest is used for OpenVPN authentication and this key does not atest to the veracity of the RAR. Rather, it is the other way around: the veracity of this public authentication key is atested to by the RAR (which contains this key or a fingerprint of this key). In turn, the veracity of the RAR is atested to by AMD / Intel, and, absent a serious compromise of hardware or corporate security, neither the VPN operator nor anyone else is able to atest to the veracity of the RAR. Accordingly, one security value proposition for the present invention is that users are given cryptographic assurance, backed by AMD / Intel, that their counterparty is the OpenVPN server in the initramfs of the tetrad.

[0071] To elaborate, there exists a script inside the initramfs (one of the four components of the tetrad), which generates a random private / public key pair when it boots inAtorney Docket No. 1739P001US01 the guest VM. Every new guest instantiation of the tetrad will generate a unique key pair (assuming integrity of the processor’s random number generator). After the key pair is generated (but before OpenVPN starts accepting connections from users), a script in the initramfs sends a request for the generation of a new RAR to the hypervisor. The request contains a user data field that the requesting script populates with the freshly generated public key (or a fingerprint thereof). The hypervisor forwards the request to the CPU. The CPU then bundles the request’s user data field with more information (including, but not limited to, the hashes of the tetrad elements), signs the bundle with its own key, and returns the signed bundle to the hypervisor. The hypervisor then forwards this reply to the script in the initramfs that initiated the request. This process is cryptographically hardened to preclude a man-in-the-middle atack by a malicious hypervisor. At this point, the script inside the initramfs possesses the newly generated RAR. This generated RAR amounts to cryptographic proof that the freshly generated key was produced on a VM guest that was instantiated using the tetrad. The script then proceeds to upload the new RAR to a public place (e.g., in one implementation this public place is an FTP server accessible to clients) and makes the private key accessible to the OpenVPN server software. When a client connects to the OpenVPN server, the OpenVPN server will authenticate itself using the private key that matches the public key whose fingerprint is embedded in the RAR or whose fingerprint is embedded in the RAR. When a client downloads and inspects the RAR, the client will know that: a) the RAR is authentic (since it was signed by AMD / Intel hardware); and b) the public key validating the authentication response from the OpenVPN server must have been generated by a VM that was instantiated by a tetrad whose fingerprint matches the measurement field of the RAR.

[0072] In terms of preparing the remote machine, the preferred preparation steps to ensure that the method and process are suitably secure from both internal and external tampering are as follows:1. The remote server boots. A hypervisor was previously installed on the server, and the tetrad resides on the server's filesystem.Atorney Docket No. 1739P001US012. Anew virtual machine is spawned in a TEE on the host machine with the firmware-cmdline-kemel-initramfs tetrad. The executed command could be: qemu-system-x86_64 -enable-kvm -cpu EPYC-Milan-v2 -nographic -m8192 ) ) M -boot menu=on -drive if=pflash, format=raw, readonly=on, file= . / 0VMF2 . fd -obj ect meitiory- backend-memfd-private , id=raml , size=$ {MEM}M, share=true-obj ect sev-snp- guest, id=sevO , cbitpos=$ { CBITPOS } , reduced-phys- bits=l , discard=both, kernel-hashes=on-machine q35 , confidential-guest-support=sevO , kvm- type=protected, memory-backend=raml , mport=off-device virtio-net, netdev=networkO -netdevtap, id=networkO , ifname=tapO , script=no, downscript=no, vhost=on -smp 1- append "pci=off ip=off rd. neednet=O systemd.mask=serial- getty@ttySO . service , serial -getty@hvcO . service " -kernel . / bzlmage -initrd . / initramfz3. A script is run that randomly generates a new public / private keypair, VPN- AUTH, Public and VPN-AUTH, Private, both of which are saved on the guest's filesytem (ramdisk). The key is later used by OpenVPN for authentication. The private key never leaves the virtual machine because: keyboard / mouse and / or other dangerous I / O is disabled, no SSH access, and the virtual machine runs in a trusted execution environment. The private key only exists for the lifetime of the virtual machine.4. A script is run that sends a request for remote atestation report (RAR) to the hypervisor. The request's user-specifiable data field (e.g. REPORT DATA on AMD systems) is populated with VPN-AUTH, Public or its fingerprint. The hypervisor forwards the request to the host CPU, which bundles the data field (VPN-AUTH, Public) with other information, including but not limited to, the fingerprint of the tetrad. The processor then signs the bundle with its private key (which never leaves the processor), and sends the signed bundle back to the hypervisor, which ultimately returns it to the script running in guest. Lastly, the script uploads the RAR to a public FTP server or other public place.5. OpenVPN server is launched and waits for new connections.Atorney Docket No. 1739P001US01

[0073] Once the above preparation steps have been completed, then the process can continue from STEP 10 detailed above.

[0074] A number of points must be noted specifically for the process according to the present invention. Specifically, it should be noted that if the general purpose data field is populated with a key fingerprint (rather than the key itself), the key must be provided to the client separately (e.g., via the FTP server). Similarly, in the guest machine (an invocation of the tetrad), the kernel directly spawns an early userspace script responsible for the VM's functionality. This is not necessarily the case for the host system, where a normal (complicated) boot setup is expected. What this means is that the host kernel will not directly spawn the hypervisor. Rather, the hypervisor will be the descendant of many earlier userspace processes (e.g., init, systemd, etc.). As well, it should be noted that, as with secure protocols such as SSL / TLS, all packets over the entire lifetime of the communications channel are cryptographically chained to the original public key authentication via other means such as, for example, HMAC. This means that communications subsequent to authentication are immune from man-in-the-middle atacks.

[0075] When building and fingerprinting the tetrad, it should be clear that building the kernel, the firmware, OpenSSL, and OpenVPN Server are all preferably executed deterministically. For clarity, simply running the script (which sets several build options and environment variables necessary for determinism) is insufficient to guarantee a deterministic build. The build environments and versions of compilers should be identical across builds as a single bit flip in any of the tetrad members will provide an unusable hash used to execute the fingerprinting). To address this, the build script can be executed in a specific live-booted linux system (e.g., Fedora boot disk from Jan 2024), with a specific package version of compilers downloaded to the live system. For convenience, the person doing the build can perform this in a VM such that there will not be a need to reboot their system.

[0076] Referring to Fig. 2, provided is a flowchart of a method executed by the user machine to confirm that a piece of software installed on a remote machine is configured / installed with specific features. As can be seen, the method begins at step 100, that of requesting an authentication response from the remote machineAtorney Docket No. 1739P001US01(i.e., sending an authentication challenge). Step 110 is that of receiving an authentication response (including a public key, if not obtained elsewhere) from the remote machine, with the public key relating to software operating on the remote machine. Step 120 is then that of downloading a digital attestation from a download server. This digital atestation is then compared to the public key or its fingerprint (step 130). If(i) the digital attestation report is verified by checking its signature through a certificate chain terminating in a root of trust,(ii) the atestation validates thepublic key or its fingerprint, and iii) the public key validates the authentication response, then step 140 is satisfied, and the user machine can then download resources for installing a local version / local copy of the remotely installed software (step 150). Of course, if there is no match, then the method ends as this lack of a match indicates that the remotely installed software has authentication issues and that further confirmation cannot proceed.

[0077] After the resources for installing the local version has been downloaded (including the build script, the actual installation software, etc.), then the software is installed / built on the local machine (step 160). This installed / built software is then assessed / measured to give a local fingerprint (step 170). The resulting measurement is then compared to the digital atestation (step 180). If the digital atestation validates the local fingerprint (step 190), then this means that the local copy is a match / copy of the remotely installed version. As a further verification step regarding the features on the installed software, a further step (step 200) can be taken to confirm that the local copy is installed / configured with the desired features. Once this confirmation is effected, then the user can conclude that the remotely installed version has the desired configuration. Regular use of the remote VPN can then commence (step 210).

[0078] The various aspects of the present invention downloads a fingerprint of an installation of software on a remote machine and a user can verifiably confirm that this fingerprint is trustworthy. Then, the user downloads the resources thatAtorney Docket No. 1739P001US01 allow that user to duplicate the software on the remote machine. The installation and setup of the resources are deterministic such that only one installation and result is possible from the resources downloaded. Once the user has installed the software on the local machine, this local installation is fingerprinted and the user can confirm that the local fingerprint from the local installation is the same as the downloaded fingerprint. This would mean that the local installation (including parameters and setings) is identical to the installation on the remote machine. Thus, if the local installation is configured according to a desired configuration, then the remote installation on the remote machine must, logically, have the same desired configuration.

[0079] For greater clarity, while the above discusses disseminating the RAR potentially using a separate server (i.e., the RAR is uploaded to a separate server and then, using FTP, HTTP, etc., the RAR is sent / retrieved by clients), the RAR could be disseminated from within the intramfs itself. The FTP / HTTP server software could be run from within the initramfs itself alongside the OpenVPN server. Alternatively, the RAR could be, as noted above, sent to a different machine and be retrieved / sent out from the different machine, the RAR could be sent to the host, or the RAR could be kept by the guest VM. The guest VM could thus include additional server software, one of whose functions would be to provide the RAR when requested.

[0080] It should also be noted that the steps detailed in Fig. 1 and Fig. 2 can be executed in a sequence different from that illustrated. As an example, a client could download the build software and execute the build and image measurements prior to establishing contact with the OpenVPN server. A person of skill in the art can determine which of the steps can be executed in a different sequence as such a person can determine the data and sequence dependencies that may need to be preserved in the method and process according to the various aspects of the present invention.

[0081] One variant to the present invention allows for select parameters to be passed to a trusted build environment (TBE) that produces the tetrad (i.e., the kernel, initramfs, firmware, and kernel command line string). This allows for some variability (e.g., in the kernel version) in the tetrad such that small foreseeableAtorney Docket No. 1739P001US01 possible changes can be built into the system such that the small changes do not require that the whole infrastructure has to be rebuilt.

[0082] In this variant, the concept of the present invention is intact - a user can verify that a VPN server is properly provisioned and configured to not snoop on a user’s session by downloading a report generated by the VPN operator when the operator initially created the VPN and which fingerprints the installed VPN server. The user then downloads the resources necessary to replicate the operator’s installation of the installed VPN server, creates a local installation of the VPN server, and then fingerprints that local installation. If the local installation fingerprint is validated and assuming that the local installation is properly provisioned and installed to not snoop on a user’s session, then the remotely installed VPN should also be equally properly provisioned and installed to not snoop on the user’s session.

[0083] The variant builds in some configurability by allowing the operator to configure a Trusted Build Environment (TBE or see below for definitions) that accepts inputs to create VPN tetrads. Once this is complete, then a RAR is produced as above. Also, the inputs entered and the outputs of the build process used to create VPN tetrads within the TBE are hashed together and the resulting hash values are incorporated into the RAR that was generated. The resources necessary to reproduce the TBE (including a TBE tetrad) are published along with the RAR and, potentially, the VPN tetrad built with the TBE. A user can thus take the resources necessary to implement the TBE, the RAR published by the operator, and implements a local version of the TBE using these resources (which would, of course, include the inputs provided by the operator). The user then launches, with the specified inputs, a local TBE, which builds a local VPN tetrad and hashes the input and the output of the build process. The resulting hash can then be compared with the hash values incorporated into the RAR. If these are identical, then the VPN tetrad is safe.

[0084] From the above, it should be clear that input TBEoutput. Assuming that the process is deterministic and assuming that the input and the TBE are the same regardless of implementation, then the output should always be the same and, accordingly, a hash of the input and the output should be the same regardless ofAttomey Docket No. 1739P001US01 whether the implementation is a local or a remote installation. Thus, the process, assuming that the TBE is the same (and this is why the operator publishes the resources necessary to install a TBE), should produce the same output for the same input. An operator can thus input whatever parameters are necessary / desired and, as long as these parameters are provided to users or validators, and as long as the TBE is implemented in the same way / manner every time, then the resulting output (and thus the VPN tetrad) will be the same. A user can, with the resulting VPN tetrad, ensure that the resulting local VPN server is properly configured and provisioned. If the local VPN server is found to be properly configured and provisioned, then the remote VPN server (installed and operated by the operator) must be identical in configuration and provisioning.

[0085] To further discuss the details and the implementation of this variant, a glossary of terms used in the discussion is provided below. It should be clear that, since the variant allows for the updating of the various parameters and components used by the present invention, the definitions below, where relevant, include an indication regarding updating frequency.VPN VM: A virtual machine administered by the infrastructure operator that provides public VPN service. The infrastructure operator could also be the VPN operator.VPN Kernel Image: The guest kernel image (e.g. Linux) that is booted as the VPN VM. This component may possibly be frequently updated. In the discussion above, this component was referred to simply as “Kernel Image”. It has been renamed for this section for differentiation from the TBE Kernel Image (see below).VPN Initramfs Image: The guest initial RAM filesystem that is booted alongside the VPN kernel image. This tetrad component may possibly be frequently updated. In the discussion above, this component was referrend to as “Initramfs Image”. It has been renamed / reidentified for differentiation from TBE Initramfs Image (see below).Atorney Docket No. 1739P001US01VPN Firmware Image: The guest VM firmware image (e.g. OVMF) that simulates hardware firmware for the VPN VM. This tetrad component may possibly be frequently updated. In the discussion above, this component was referred to as “Firmware Image”. However, it has been renamed for this section to differentiate it from TBE Firmware Image (see below).VPN Kernel Command Line String: The command line parameters that are passed to the VPN kernel. This component may possibly be frequently updated. In the discussion above, this component was referred to as “Kernel Command Line Parameter String”. This component has been renamed for this section to differentiate it from TBE Kernel Command Line Parameter String (see below).VPN Tetrad: The collection of VPN kernel image, VPN initramfs, VPN firmware, and VPN kernel command line parameter string that together constitute the guest VPN system. In the discussion above, tetrad was referred to as a “Tetrad”. However, in this variant TWO tetrads are now used and, as such, this tetrad has been identified / renamed to differentiate it from TBE-Tetrad (see below).VPN-RAR (VPN Remote Attestation Report): A report signed by the processor whose chain of trust terminates at an AMD or Intel root certificate. The report contains several fields including but not limited to: i) a user-specifiable data field such as REPORT DATA (set by the requester; in this variant this field is the VPN server’s public authentication key or fingerprint thereof), ii) a cryptographic measurement of the loaded VPN kernel, initramfs, and firmware images as well as the kernel command line parameters string. In the discussion above, the VPN- RAR was referred to as the only RAR. However, since this variant now uses two RARs, this was renamed to differentiate it from TBE-RAR (below).Trusted Build Environment (TBE): The environment in which the VPN tetrad and VPN kernel command line parameters are built and measured. This environment strictly disallows any changes to the build and measurement processes, save for those explicitly permited.Attomey Docket No. 1739P001US01Trusted Build Environment (TBE) VM: A virtual machine run by the infrastructure operator and / or end users or security researchers and launched with the TBE tetrad (see below).Trusted Build Environment (TBE) Kernel Image: The guest kernel image (e g. Linux) that is booted as the TBE VM. This image rarely requires updating.Trusted Build Environment (TBE) Initramfs Image: The guest initial RAM fdesystem that is booted alongside the TBE kernel image. This image rarely requires updating. This image will contain, at minimum, some functionality (e.g. shell script) that produces a remote attestation report (RAR). This image will likely contain script(s) that generate the VPN kernel, VPN initramfs, and firmware images and the VPN kernel command line parameters string. These script(s) will likely compute a collective fingerprint (tetrad fingerprint) and outputs the built objects and fingerprints to the host.Trusted Build Environment (TBE) Firmware Image: The guest VM firmware image (e.g. OVMF) that simulates hardware firmware for the TBE VM. This image will rarely require updatingTBE-RAR (Trusted Build Environment Remote Attestation Report): A report signed by the processor whose chain of trust terminates at an AMD or Intel root certificate. The report contains several fields including, but not limited to,: i) REPORT DATA (set by the requester; in this case the field will be a value that can later be used by a user to verify VPN images), ii) a cryptrographic measurement of the loaded TBE kernel, TBE initramfs, and firmware images as well as the TBE kernel command line parameters string.Trusted Build Environment (TBE) Kernel Command Line ParametersString: The command line parameters that are passed to the TBE kernel. This string rarely requires updatingTrusted Build Environment (TBE) Tetrad: The collection of TBE kernel, TBE initramfs, and firmware images and TBE kernel command line parameter string that, together, fully define an instantiation of the TBE.Atorney Docket No. 1739P001US01

[0086] As an example of one implementation of this variant of the present invention, a description and discussion of the implementation is provided below.

[0087] For this implementation, a master shell script is used to reproducibly build the TBE tetrad. As discussed above, the use of a deterministic build system dramatically simplifies the work of external verifiers by eliminating the need to reverse engineer binaries. Verifiers may only need to examine the build shell script if the referenced source code is trusted (e.g. obtained via github). Note this reproducible build is distinct from that of the VPN tetrad (materialized as a VPN build script) that was discussed at length above. It is important to note that the VPN build script is, in contrast to the discussion above regarding the present invention, now embedded inside the master build script. This means that, when the master build script is executed, it will, among other actions, write the VPN build script to the TBE initramfs, which the master build script further configures to automatically execute the VPN build script upon boot.

[0088] Provided below are some of the properties of the generated TBE tetrad. It should, however, be clear that inputs can be disabled with command-line arguments to qemu as well. However, if a malicious operator is assumed, these arguments could be silently dropped without the awareness of subsequent verifiers. In contrast, when inputs are disabled by the initramfs and kernel, they cannot be re-enabled by a malicious operator without invalidating the atestation (TBE-RAR). For greater clarity, full disablement of unwanted inputs requires coordinated (and preferably redundant) configuration across the initramfs, kernel, and / or kernel command line parameters. These properties noted are:- The TBE initramfs is equipped with all required build tools (e.g., make, gcc, git, etc.), as well as guest-side SEV-SNP tools required to generate the TBE-RAR. Unneeded inputs (e.g., keyboard, mouse, and network I / O) are disabled in the initramfs and kernel configuration file. Furthermore, the initramfs contains the VPN build script and is configured to launch this VPN build script at boot. The VPN build script itself is configured to read in a value from / sys / firmware / qemu_fw_cfg / modifable_setting.Attomey Docket No. 1739P001US01- The TBE kernel configuration is modified to disable unneeded inputs (e.g., keyboard, mouse, and or / network I / O) and to enable AMD SEV-SNP, as required. The configuration is further modified to ensure that CONFIG_FW_CFG_SYSFS=y and CONFIG_SYSFS=y to allow a parameter to be passed to the TBE kernel when it is launched by qemu. Note that networking is enabled very carefully to manage or avoid the risks associated with using PCIe devices. It should, however, be noted that, it may be preferable to use qemu's inbuilt networking. Upon completing the kernel configuration, the custom kernel is built. Provided in the appendix is an example for a full set of kernel configuration settings.- The TBE kernel command line arguments are selected to disable unneeded inputs (keyboard, mouse, and or / network I / O), as required.- The OVMF firmware is built with AMD SEV-SNP, or the equivalent for Intel, being enabled.

[0089] For greater clarity, the steps detailed above to disable inputs when implementing / generating the VPN tetrad may also be taken to disable inputs when implementing the variant of the present invention that involves the TBE tetrad.

[0090] To implement this variant of the present invention, provided below are the actions / steps performed by the infrastructure operator to construct a TBE that allows the VPN kernel version to be freely set. What is provided below can be modified to allow other parameters to be freely set, as required. These steps are schematically illustrated in Fig. 3.A. GENERATION OF STATIC TBE ELEMENTS (PERFORMED ONLY INFREQUENTLY)1. The infrastructure operator writes a master shell script that generates the TBE components.2. (Optional) The operator publishes the master shell script.3. The operator executes the master shell script to thereby generate the components of the TBE. These components are theAtorney Docket No. 1739P001US01 i) TBE Tetrad (i.e., TBE Kernel, TBE Initramfs, TBE Firmware, TBE Kernel Command Line Parameter String) and ii) the TBE Tetrad Fingerprint.These components are saved by the operator.4. (Optional) The operator publishes the TBE tetrad fingerprint and / or the TBE tetrad.It should be noted that subsequent verification of the TBE requires verifier access to at least one of: i) the master shell script of step 2 (requires the verifier to build and measure the TBE); ii) the TBE tetrad fingerprint (requires blind trust or the endorsement of a trusted third party); or iii) the TBE tetrad (requires the verifier to measure and scrutinize the built TBE tetrad elements, unless the elements can be trusted or are endorsed by a trusted third party).It should be noted that all or some of these can be published, but the lowest friction for all parties is achieved by publishing, at a minimum, the master shell script and TBE tetrad fingerprint, along with one or more third party endorsements).

[0091] Once the TBE has been created, the VPN server has to be instantiated. The steps provided below are executed by the infrastructure operator to implement a VPN server using the TBE created above. These steps are provided as a continuation of the TBE process above.B. GENERATION OF NEW VPN SERVER TETRAD & VPN-RAR (PERFORMED OFTEN)5. The operator launches the TBE tetrad inside a SEV-SNP -protected VM with an additional command line parameter passed to qemu:-fw cfg name=opt / VPN_KERNEL_VERSION,string=##, (where ## is the desired version of the to-be-built VPN tetrad kernel).Attomey Docket No. 1739P001US016. The VPN build script runs inside the VM and obtains the github version of the kernel found in opt / VPN KERNEL VERSION. which corresponds to the value passed in step 5. The VPN build script then builds the VPN tetrad components, thereby producing the VPN Kernel, VPN Initramfs, VPN Firmware, and VPN Command Line Parameters. The VPN tetrad is then fingerprinted, and the fingerprint is combined with the value in the field VPN KERNEL VERSION and this value is hashed to produce the value to be stored in the REPORT DATA field in a report attestation request (RAR). The request is sent to the CPU to produce the TBE-RAR. When done, the VPN tetrad and TBE-RAR are hex encoded (in whole or in part) and outputted to the console, from where they are read by the host which then decodes from hex as required and saves the tetrad components and TBE-RAR.7. The operator publishes the TBE-RAR and the VPN KERNEL VERSION string of step 5. Note that this step is mandatory.8. The operator deploys the VPN tetrad by launching it within a SEV-SNP VM on the public VPN server.

[0092] After the infrastructure operator has implemented the above steps to implement the present invention, a user can then confirm / validate the remotely installed VPN server. In contrast to the steps executed by the user to validate the nonvariant version of the present invention, the user can execute the steps given below for this variant of the present invention. The steps are for validating the remotely installed VPN server. These steps, to be executed by the user, are schematically illustrated in Fig. 4.STEPS PERFORMED BY THE USER (to validate this variant of the present invention)1. The user downloads: a) the TBE tetrad fingerprint, b) the TBE-RAR, c) VPN KERNEL VERSION, and d) VPN-RAR,Note that the VPN-RAR is generated and published by the running VPN server, as described above in the original version of the present invention.Atorney Docket No. 1739P001US012. The user evaluates the full trust chains for both the TBE-RAR and VPN-RAR. If the roots of trust are verified to be the correct AMD / Intel certificates, the user proceeds. If the roots of trust are not verified, the user aborts.3. The user compares the TBE tetrad fingerprint with the Measurement field in the TBE- RAR. If they match, the user proceeds. If there is no match, the user aborts.4. The user computes Hash(VPN_KERNEL_VERSION, Measurement), where the HashQ is the same hash function that was previously used by the VPN operator (step B-6 above), and Measurement is the Measurement field of the VPN-RAR.5. If the computed hash (step 4) matches the value in the REPORT DATA field of the TBE-RAR, the user proceeds. If there is no match, the user aborts.6. The user has completed the verification procedure and continues to utilize the VPN service as described above. Note that the role of the VPN-RAR’ s REPORT DATA field remains unchanged — it is either the public authentication key for the running VPN server or a cryptographic fingerprint of that key.

[0093] As an optional step to the above process, instead of downloading the TBE tetrad fingerprint, the user can:(i) download a build script for the TBE;(ii) build and fingerprint the TBE tetrad; and(iii) use the locally generated TBE tetrad fingerprint in the above process.

[0094] It should be clear that, while the above description details the use and exchange of keys between remote and local servers, remote and local machines, and between other entities, such keys may be embedded or form part of certificates and these certificates are exchanged between different machines / entities.

[0095] Similarly, public-key cryptography (or asymmetric cryptography) may also be used with the present invention. Such public-key cryptography may be used when the authentication response is exchanged between the various entities involved in the present invention.

[0096] For greater clarity, while the above description mentions some CPU manufacturers and while Intel and AMD CPUs are used in some implementations of the present inventions, other CPUs from other manufacturers may also beAtorney Docket No. 1739P001US01 used. As examples, CPU produced / manufactured by or derived from ARM, Motorola, Apple silicon, RISC V, etc. may also be used with the present invention.

[0097] Also for greater certainty, when this document refers to a user that seeks confirmation of a proper remote configuration, such a user may be software or an agent being executed by or in a machine separate or remote from the other machines detailed above. Such software or agent that seeks confirmation may be executed in its own TEE (trusted execution environment) and may be on a machine different from the environments or machines detailed above or it may be on the same machine but in a different VM.

[0098] In one aspect, the present invention provides systems and methods for confirming that a remotely installed VPN server has a configuration such that users can be sure that VPN operators are not snooping on user traffic passing through the remotely installed VPN server. The VPN operator (or someone operating with the VPN operator) provides (by way of a publicly available server) the resources necessary to install the same VPN server that the VPN operator provides to the user. The user can then download these resources and install the same VPN server locally. The user can then confirm, by way of the locally installed VPN server, the configuration of the remotely installed VPN server, knowing that the locally installed VPN server has the exact same configuration as the remotely installed VPN server.

[0099] To ensure that the user can trust the resources provided by the VPN operator, the VPN operator provides a remote atestation report (RAR) when the remote VPN server was originally installed / built, with the RAR being provided by way of a publicly available server. The authenticity of the RAR can be confirmed by the user by verifying the chain of trust from the remote machine’s CPU manufacturer’s root certificate (or key) to the RAR. Once the RAR has been validated, the user can trust the resources provided by the VPN operator.

[0100] The resources provided by the VPN operator are configured such that the VPN server being installed is locked down - minimal to no user input is configured when the VPN server is being installed / built. The VPN server may be anAttomey Docket No. 1739P001US01OpenVPN server. In one implementation, the VPN server being installed / built is configured, through kernel commands, to disable inputs such as keyboards, mice, network, serial I / O, storage and PCI / passthrough. In addition, the use of build parameters can similarly disable all inputs to the VPN server being installed. Preferably, the VPN server uses one of the various versions or flavors of the Linux operating system and the Linux operating system never leaves early userspace.

[0101] Preferably, the VPN server may operate in a TEE (Trusted Execution Environment) to ensure that the VPN server safeguards entrusted data and CPU instructions from other processes by ensuring data privacy and data integrity. Preferably, the VPN server operates in an SEV-SNP protected virtual machine.

[0102] Also preferably, the resources provided by the VPN operator to install / build the VPN server includes (as a tetrad):- a version of qemu with- a kemel_file,- a initramfs_file,- a command line_parameter_file.

[0103] The tetrad operates to: lock down the VPN server being installed, configures the VPN server, and installs / builds the VPN server in a suitable virtual machine.

[0104] To ensure that the VPN server being installed / built on the user’s local machine is the same in configuration as the remote VPN server, any installation of the VPN server using the tetrad and the present invention is a deterministic build - the kernel, the initramfs, and the OVMF blob of the virtual machine image is the same and any installation will have the exact same configuration as the remote VPN server.

[0105] To assist in the configurability of the VPN server (as in to allow some parameters to change in the VPN server or in the tetrad without having to redo / rebuild the process and the resources), a Trusted Build Environment may be used. For this aspect of the present invention, the VPN operator provides the resources to reproduce the TBE along with the RAR. The VPN tetrad built with the TBE mayAtorney Docket No. 1739P001US01 also be provided. This aspect of the present invention allows the user to build the TBE, install a local version of the VPN tetrad (using the local TBE), and then hash the input and output of the build process. This hashed value can then be compared with the hash value stored in the RAR.

[0106] It should be noted that all the source code included in this document and included in all of Appendix A, Appendix B, Appendix C, and Appendix D are copyright ©2024 Dominic Schaub or copyright ©2025 Dominic Schaub. The author’s moral rights have been asserted and are not waived.

[0107] It should be clear that the various aspects of the present invention may be implemented as software modules in an overall software system. As such, the present invention may thus take the form of computer executable instructions that, when executed, implements various software modules with predefined functions.

[0108] The embodiments of the invention may be executed by a computer processor or similar device programmed in the manner of method steps, or may be executed by an electronic system which is provided with means for executing these steps. Similarly, an electronic memory means such as computer disketes, CD-ROMs, Random Access Memory (RAM), Read Only Memory (ROM) or similar computer software storage media known in the art, may be programmed to execute such method steps. As well, electronic signals representing these method steps may also be transmitted via a communication network.

[0109] Embodiments of the invention may be implemented in any conventional computer programming language. For example, preferred embodiments may be implemented in a procedural programming language (e.g., "C" or "Go") or an object-oriented language (e.g., "C++", "java", "PHP", "PYTHON" or "C#"). Alternative embodiments of the invention may be implemented as preprogrammed hardware elements, other related components, or as a combination of hardware and software components.

[0110] Embodiments can be implemented as a computer program product for use with a computer system. Such implementations may include a series of computer instructions fixed either on a tangible medium, such as a computer readableAtorney Docket No. 1739P001US01 medium (e.g., a diskete, CD-ROM, ROM, or fixed disk) or transmitable to a computer system, via a modem or other interface device, such as a communications adapter connected to a network over a medium. The medium may be either a tangible medium (e.g., optical or electrical communications lines) or a medium implemented with wireless techniques (e.g., micro wave, infrared or other transmission techniques). The series of computer instructions embodies all or part of the functionality previously described herein. Those skilled in the art should appreciate that such computer instructions can be writen in a number of programming languages for use with many computer architectures or operating systems. Furthermore, such instructions may be stored in any memory device, such as semiconductor, magnetic, optical, or other memory devices, and may be transmited using any communications technology, such as optical, infrared, microwave, or other transmission technologies. It is expected that such a computer program product may be distributed as a removable medium with accompanying printed or electronic documentation (e.g., shrink-wrapped software), preloaded with a computer system (e.g., on system ROM or fixed disk), or distributed from a server over a network (e.g., the Internet or World Wide Web). Of course, some embodiments of the invention may be implemented as a combination of both software (e.g., a computer program product) and hardware. Still other embodiments of the invention may be implemented as entirely hardware, or entirely software (e.g., a computer program product).

[0111] A person understanding this invention may now conceive of alternative structures and embodiments or variations of the above, all of which are intended to fall within the scope of the invention as defined in the claims that follow.Atorney Docket No. 1739P001US01APPENDIX A (copyright ©2024 Dominic Schaub)Attestation Report (1184 bytes) :Version: 2Guest SVN (Security Version Number) : 0Guest Policy (196608) :ABI Major: 0ABI Minor: 0SMT Allowed: 1Migrate MA: 0Debug Allowed: 0Single Socket: 0Family ID: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00Image ID: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00VMPL (Virtual Machine Privilege Level) : 1Signature Algorithm: 1Current TCB (Trusted Computing Base) :TCB (Trusted Computing Base) Version:Microcode: 209SNP (Secure Nested Paging) : 10TEE (Trusted Execution Environment) : 0Boot Loader: 3Platform Info (1) :TSME (Transparent Secure Memory Encryption) Enabled: 1 SMT (Simul taneous Multithreading) Enabled: 0Author Key Encryption: falseReport Data: 23 21 2f 62 69 6e 2f 62 61 73 68 0a 6f 70 65 6e73 73 6c 20 67 65 6e 72 73 61 20 2d 6f 75 74 2061 75 74 68 2f 63 61 2e 6b 65 79 20 34 30 39 360a 6f 70 65 6e 73 73 6c 20 72 65 71 20 2d 78 35Measurement : 55 b6 33 47 88 04 ab lc 9e 18 ca 37 e8 30 8f 11 a6 96 9b 94 3d cf 37 74 51 fd 93 45 bd 7c 27 b64f 58 58 56 42 83 3c d9 70 7d 89 61 e7 dl ce f6Host Data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00ID Key Digest: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00Author Key Digest:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00Atorney Docket No. 1739P001US0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00Report ID: ff 5c e6 46 Oe 70 46 c5 bl 25 88 c3 55 0a bl f3 c4 26 al d7 If 36 01 97 17 19 bO 0a f9 e3 bO 23Report ID Migration Agent: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffReported TCB:TCB Version:Microcode: 209SNP: 10TEE: 0Boot Loader: 3Chip ID:95 da 05 eO f2 cO f8 5f al 57 f7 7b 21 95 46 25 c5 73 5e al 77 ef 60 69 11 3a ce b7 Id 6a e2 28 d4 2d 73 4c cc b4 e4 ea 21 97 9c 0b b4 38 90 f6 cl 93 e5 41 c3 2e 68 69 d7 fl a2 98 ab dl 89 ObCommitted TCB:TCB Version:Microcode: 209SNP: 10TEE: 0Boot Loader: 3Current Build: 1Current Minor: 54Current Major: 1Committed Build: 1Committed Minor: 54Committed Major: 1Launch TCB:TCB Version:Microcode: 209SNP: 10TEE: 0Boot Loader: 3Signature:R:03 49 7a 24 46 d9 35 49 8c 73 dO Ob 34 4e 9f 674c 18 3c 77 a9 b5 82 52 8f fc b3 If Oc 85 97 9d fO 9c 0c 76 0b 99 db b6 a2 e5 e9 Oc a2 le 55 4900 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000 00 00 00 00 00 00 00S : fc 00 cb 7a b8 c9 Of f5 34 60 23 d7 86 fb 48 8451 09 al al c3 e5 81 44 c3 86 a5 64 00 e2 c6 b573 4b ed 31 08 d8 f8 10 9c ac 55 fc 57 d9 29 9200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00Attomey Docket No. 1739P001US01 oo oo oo oo oo oo oo ooAtorney Docket No. 1739P001US01Appendix B: VPN Server Virtual Machine Tetrad Generation & Measurement (copyright © 2024 Dominic Schaub)# ! / bin / bashBASE_DIR=" "DEVELOPMENTSBUILDJSEVSNPMEASURESBUILD_KERNEL=1BUILD_OPENVPNDCO=1CONSTRUCT_INITRAMFSSMEASURE DEPLOYMENTSKERNEL_VERSIONSinux-6.7-rc7 ovmf patch=" - AmdSevX64. dsc 2023-12-25 00 : 51 S2.307909313 -0500-+++ AmdSevX64 revised. dsc 2023-12-25 01 : 52 S8.790099618 - 0500@@ -166,7 +166,8 @@LockBoxLib | Ovmf Pkg / Library / LockBoxLib / LockBoxBaseLib . inf \rCustomizedDisplayLib | MdeModule Pkg / Library / CustomizedDisplayLib / CustomizedDisplayLib . inf \rAtorney Docket No. 1739P001US01Frame Buf f er Bit Lib | MdeModulePkg / Library / FrameBuf f erBltLib / Frame BufferBltLib.inf\rB lobVer if ierLib | Ovmf Pkg / AmdSev / B lobVer if ierLibSevHashes / BlobVe rif ierLibSevHashes . inf \r+#BlobVerif ierLib | Ovmf Pkg / AmdSev / BlobVerif ierLibSevHashes / BlobV erif ierLibSevHashes . inf \r+BlobVer if ierLib | Ovmf Pkg / Library / BlobVerif ierLibNull / BlobVerif i erLibNull . inf \rMemEncryptTdxLib | Ovmf Pkg / Library / BaseMemEncryptTdxLib / BaseMemE ncryptTdxLib.inf\rPeiHardwarelnf oLib | Ovmf Pkg / Library / Hardware Inf oLib / PeiHardware Inf oLib . inf \rDxeHardwarelnf oLib | Ovmf Pkg / Library / Hardware Inf oLib / Dxe Hardware InfoLib.inf\r" run command ( ){ eval "$1" if [ $? -ne 0 ] then echo 'Terminating because of error' exit -1 fi} announce ( ){ echo echo "$1" echo} git_clone ( ){ run command "git clone $1" run command "cd 'basename $1 run command "git checkout $2 run command "git reset --har run command "cd . . "Atorney Docket No. 1739P001US01} announce "Performing Initial Setup..." run command "cd $BASE DIR"#run command "mount -o remount , size=48G / run / archiso / cowspace " #run command "pacman --noconfirm -Sy"#run command "pacman --noconfirm -S musl gperf git base-devel linux-headers python-pip docbook-xsl wget ninja pixman nasm iasl cpio patch coreutils" ##run command "wget https: / / archive.archlinux.org / packages / l / linux- headers / $ { KERNEL_VERSION} -x86_64. pkg . tar . zst "##run command "pacman --noconfirm -U ${ KERNEL VERSION} - x86 64. pkg . tar . z st " run command "mkdir -p ${BASE DIR} / vpn build"#run command "In -s -f / usr / include / asm / usr / lib / musl / include / asm"#run command "In -s -f / usr / include / asm-generic / usr / lib / musl / include / asm-generic"#run command "In -s -f / usr / include / linux / usr / lib / musl / include / linux" export SOURCE_DATE_EPOCH=1 if [ $BUILD_OPENSSL ] then announce "Building OpenSSL..." git clone "https: / / github.com / openssl / openssl" "master" "d6e4056805 " run command "cd openssl" run command "mkdir -p / openssl" run command ". / Configure gcc -static -no-shared -- pref ix=$ { BASE DIR} / vpn build --openssldir= / openssl CC= / usr / bin / musl -gcc" run command "make -j $ (getconf NPROCESSORS ONLN) " run command "make install" run command "cd . . " fi if [ $BUILD_LZO ] then announce "Building LZO. . . " git clone "https: / / github.com / nemequ / lzo" "master" "0083878"" run command "cd Izo" run command ". / configure --pref ix=$ { BASE DIR} / vpn build - -enable-static --target=arm-linux-gnueabi --host=arm-linux- gnueabi --disable-debug" run command "make -j $ (getconf NPROCESSORS ONLN) "Atorney Docket No. 1739P001US01 run command "make install" run command "cd . . " fi if [ $BUILD_LIBNL ] then announce "Building LIBNL..." git clone "https: / / github.com / thom311 / libnl" "main" "bdf83151" run command "cd libnl" run command / autogen . sh" run command ". / configure --pref ix=$ { BASE DIR} / vpn build - -enable-static --disable-shared --disable-debug CC= / usr / bin / musl-gcc" run command "make -j $ (getconf NPROCESSORS ONLN) " run command "make install" run command "cd . . " if [ $BUILD_LIBCAPNG ] then announce "Building LIBCAP-NG..." git clone "https: / / github.com / stevegrubb / libcap-ng" "master" "59dfcb4" run command "cd libcap-ng" run command ". / autogen . sh" run command ". / configure --pref ix=$ { BASE DIR} / vpn build - -exec-pref ix=$ { BASE DIR} / vpn build --enable-static --with- python3=no CC= / usr / bin / musl-gcc" run command "make -j $ (getconf NPROCESSORS ONLN) " run command "make install" run command "cd . . " fi if [ $BUILD_LZ4 ] then announce "Bu .." git clone "h ub.com / lz4 / lz4" "dev" "26b3b23" run command run command getconf NPROCESSORS ONLN) " run command ${BASE DIR} / vpn build / lib / " run command ${BASE DIR} / vpn build / include / " run commandfi if [ $BUILD_OPENVPN ] then announce "Building OpenVPN. . . " git clone "https: / / github.com / OpenVPN / openvpn" "master" "c590868a" run command "cd openvpn"Atorney Docket No. 1739P001US01 run command "autoreconf -vi" run command ". / configure --pref ix=$ { BASE DIR} / vpn build - -enable-static --disable-shared --disable-debug --disable- plugins OPENSSL_CFLAGS= ’ -1$ { BASE_DIR} / vpn_build / include ’ OPENSSL_LIBS= ' -L$ { BASE_DIR} / vpn_build / lib -Issl -lerypto’L$ { BASE_DIR} / vpn_build / lib -lcap-ng’ LZ 4_CFLAGS= ’ - 1$ {BASE_DIR} / vpn_build / include ’ LZ4_LIBS=’ - L${BASE DIR} / vpn build / lib -llz4' CC= / usr / bin / musl-gcc LDFLAGS= ' -L$ { BASE DIR} / vpn build / lib -lcap-ng -lnl-3 -Inl- genl-3 ' --host=$ (uname -m) -linux-musl" run command "make -j $ (getconf NPROCESSORS ONLN) LIBS='- all-static ' " run command "make install" run command "cd . . " if [ $BUILD_ZSTD ] then announce "Building ZSTD..." git clone "https: / / github.com / facebook / zstd" "dev" "7cf 62bc2" run command "cd zstd" run command "make clean" run command "make -j $ (getconf NPROCESSORS ONLN) " run command "cp lib / libz std . a ${BASE DIR} / vpn build / lib / " run command "cp lib / *.h ${BASE DIR} / vpn build / include / " run command "cd . . " fi if [ $BUILD_XXHASH ] then announce "Building XXHash..." git clone "https: / / github.com / Cyan4973 / xxHash" "dev""f 91df 68"" run command "cd xxHash" run command "make clean" run command "make -j $ (getconf NPROCESSORS ONLN) " run command "cp libxxhash.a ${BASE DIR} / vpn build / lib / " run command "cp *.h ${BASE DIR} / vpn build / include / " run command "cd . . " if [ $BUILD_ZLIB ] then announce "Building ZLib...Attomey Docket No. 1739P001US01 git clone "https: / / github.com / madler / zlib" "develop" "643el7b" run command "cd zlib" run command ". / configure --pref ix=$ { BASE DIR} / vpn build" run command "make -j $ (getconf NPROCESSORS ONLN) " run command "cp libz.a ${BASE DIR} / vpn build / lib / " run command "cp *.h ${BASE DIR} / vpn build / include / " run command "cd . . " fi if [ $BUILD_OPENSSH ] then announce "Building OpenSSH-Portable . . . " git clone "https: / / github.com / openssh / openssh-portable" "master "”"1036d77b3" run command "cd openssh-portable" run command "autoreconf" run command ". / configure --pref ix=$ { BASE DIR} / vpn build - -enable-static -disable-shared --disable-debug --disable- md2man CC= / usr / bin / musl-gcc LDFLAGS='- L$ {BASE_DIR} / vpn_build / lib ' CFLAGS=' - I${BASE DIR} / vpn build / include'" run command "make -j $ (getconf NPROCESSORS ONLN) LIBS='- -static ' " run command "make install" run command "cd . . " fi if [ $BUILD_RSYNC ] then announce "Building RSync..." git clone "https: / / github.com / WayneD / rsync" "master" "2f 9b963a" run command "cd rsync" run command ". / configure --disable-md2man -- pref ix=$ { BASE DIR} / vpn build --with-included-popt --with- included-zlib --disable-acl-support CC= / usr / bin / musl-gcc LDFLAGS= ' -L$ { BASE_DIR} / vpn_build / lib -static’ CFLAGS='- I${BASE DIR} / vpn build / include'" run command "make -j $ (getconf NPROCESSORS ONLN) " run command "make install" run command "cd . . " fi if [ $BUILD_ASCI IDOCTOR ] then announce "Building ASCIIDoctor . . . " git_clone "https : / / github . com / asciidoc / asciidoc-py3 " "main" "6d9f76c" run command "cd asciidoc-py3 " run command "autoconf"Atorney Docket No. 1739P001US01 run command ". / configure --pref ix=$ { BASE DIR} / vpn build CC= / usr / bin / musl-gcc LDFLAGS= ' -L$ { BASE DIR} / vpn build / lib - static' CFLAGS= ' -1$ { BASE DIR} / vpn build / include ' " run command "make clean" run command "make -j $ (getconf NPROCESSORS ONLN) " run command "make install" run command "cd . . " fi if [ $BUILD_LIBGMP ] then announce "Building LibGMP..." run command "wget https: / / gmplib.org / download / gmp / gmp- 6.3.0. tar. xz" run command "tar xf gmp- 6.3.0. tar . xz " run command "cd gmp- 6.3.0" run command ". / configure --pref ix=$ { BASE DIR} / vpn build - -enable-static -disable-shared --disable-debug CC= / usr / bin / musl-gcc LDFLAGS= ' -L$ { BASE DIR} / vpn build / lib - static' CFLAGS= ' -1$ { BASE DIR} / vpn build / include'" run command "make -j $ (getconf NPROCESSORS ONLN) " run command "make install" run command "cd . . " fi if [ $BUILD_NCURSES ] then announce "Building Ncurses..." git clone "https: / / github.com / mirror / ncurses" "master" "87c2c84c" run command "cd ncurses" run command ". / configure --pref ix=$ { BASE DIR} / vpn build - -enable-static --with-shared=no --without-ada --disable-debug CC= / usr / bin / musl-gcc LDFLAGS= ' -L$ { BASE DIR} / vpn build / lib - static' CFLAGS= ' -1$ { BASE DIR} / vpn build / include'" run command "make -j $ (getconf NPROCESSORS ONLN) " run command "make install" run command "cd . . " fi if [ $BUILD_LIBEDIT ] then announce "Building LibEdit..." git clone "https: / / github.com / cdesjardins / libedit" "master "—"18b6827 " run command "cd libedit" run command ". / configure --pref ix=$ { BASE DIR} / vpn build - -enable-static -disable-shared CC= / usr / bin / musl-gcc LDFLAGS='- L$ { BASE_DIR} / vpn_build / lib -static' CFLAGS='-I${BASE DIR} / vpn build / include'" run command "make -j $ (getconf NPROCESSORS ONLN) "Atorney Docket No. 1739P001US01 run command "make install" run command "cp src / . libs / libedit . a ${BASE DIR} / vpn build / lib / " run command "cd . . " if [ $BUILD_LIBMNL ] then announce echo "Building LibMNL..." git clone "https: / / git.netfilter.org / libmnl" "master" "754c9de”" run command "cd libmnl" run command ". / autogen . sh" run command ". / configure --pref ix=$ { BASE DIR} / vpn build - -enable-static -disable-shared CC= / usr / bin / musl-gcc LDFLAGS='- L$ {BASE_DIR} / vpn_build / lib ' CFLAGS=' - I${BASE DIR} / vpn build / include ' " run command "make -j $ (getconf NPROCESSORS ONLN) " run command "make install" run command "cd . . " if [ $BUILD_LIBFFTNL ] then announce "Building LibNFFTNL . . . " git clone "https: / / git.netfilter.org / libnftnl / " "master" "bc2afbd”" run command "cd libnftnl" run command ". / autogen . sh" run command ". / configure --pref ix=$ { BASE DIR} / vpn build - -enable-static -disable-shared CC= / usr / bin / musl-gcc LDFLAGS='- L$ {BASE_DIR} / vpn_build / lib ' CFLAGS=' - I${BASE DIR} / vpn build / include ' " run command "make -j $ (getconf NPROCESSORS ONLN) " run command "make install" run command "cd . . " fi if [ $BUILD_NFTABLES ] then announce "Building NFTables..." git clone "https: / / git.netfilter.org / nftables" "master" "86a49692" run command "cd nf tables" run command "sh autogen. sh" run command ". / configure --pref ix=$ { BASE DIR} / vpn build - -enable-static -disable-shared --disable-debug CC= / usr / bin / musl-gcc LDFLAGS= ' -L$ { BASE DIR} / vpn build / lib - Igmp -static' CFLAGS= ' -1$ { BASE DIR} / vpn build / include ' -- without-cli "Atorney Docket No. 1739P001US01 run command "make -j $ (getconf NPROCESSORS ONLN) LIBS='- -static ' " run command "make install" run command "cd . . " fi if [ $BUILD_SNPGUEST ] then git clone "https: / / github.com / virtee / snpguest" "main" "4391444"" run command "cd snpguest" run command "RUSTFLAGS= ' -C target-f eature=+crt-static ' cargo build --target x86 64-unknown-linux-gnu --release" run command "cp target / x86 64 -unknown-linux- gnu / release / snpguest ${BASE DIR} / vpn build / bin / " run command "cd . . " fi if [ $BUILD_OVMF ] then announce "Building AMD-ESE OVMF. . . " git clone "https: / / github.com / AMDESE / ovmf" "snp-latest" "09fbe92dc5" run command "cd ovmf" run command "git submodule update --init --recursive" run command "make -C BaseTools" run command ". . / edksetup . sh --reconfig" run command "echo -e \"$ovmf patch\" > ovmf patch" run command "patch Ovmf Pkg / AmdSev / AmdSevX64. dsc ovmf patch" run command "touch Ovmf Pkg / AmdSev / Grub / grub . ef i " run command "build -q --cmd-len=64436 - DDEBUG_ON_SERIAL_PORT=TRUE -n $ (getconf _NPROCESSORS_ONLN) -t GCC5 -a X64 -p Ovmf Pkg / AmdSev / AmdSevX64. dsc" run command "cd . . " fi if [ $BUILD_BUSYBOX ] then announce "Building BusyBox..." git clone "https: / / github.com / mirror / busybox" "master" "2d4a3d9e6" run command "cd busybox" run command "make defconfig" run_command "make CON FI G_EXTRA_C FLAGS =\ "-static / " -j$ (getconf _NPROCESSORS_ONLN) " run command "cd . . " fi if [ $BUILD_SEVSNPMEASURE ] thenAtorney Docket No. 1739P001US01 announce "Building SNPMEASURE . . . " git clone "https: / / github.com / virtee / sev-snp-measure" "main" "40e6720" fi Measure the tetrad (initramfs image, guest kernel, ovmf blob, kernel command line) , and report measured value to user if [ $BUILD_KERNEL ] then announce "Building linux kernel ${ KERNEL VERSION} ..." run command "wget https : / / git . kernel . org / torvalds / t / $ { KERNEL VERSION} . tar . gz run command "tar -xvvf ${ KERNEL VERSION} . tar . gz " run_command "cd $ {KERNEL_VERSION} " run command "make defconfig" run command "make hardening . conf ig " run command " . / scripts / conf ig --enable INET" run command " . / scripts / conf ig --enable NET" run command ". / scripts / conf ig --enable GENEVE" run command ". / scripts / conf ig --enable NF TABLES IPV6" run command ". / scripts / conf ig --enable NF TABLES IPV4" run command ". / scripts / conf ig --module NET UDP TUNNEL" run command ". / scripts / conf ig --enable NETLINK DIAG" run command ". / scripts / conf ig --enable NF DEFRAG IPV4" run command ". / scripts / conf ig --enable IP NF NAT" run command ". / scripts / conf ig --enable NF TABLES" run command ". / scripts / conf ig --enable NFT NAT" run command ". / scripts / conf ig --enable LIBCRC32C" run command ". / scripts / conf ig --enable NF CONNTRACK" run command ". / scripts / conf ig --enable NF DEFRAG IPV6" run command " . / scripts / conf ig — enable NETFILTER_NETLINK" run command ". / scripts / conf ig --enable SEV GUEST" run command ". / scripts / conf ig --disable MODULE SIG ALL" run command ". / scripts / conf ig --enable EXPERT" run command ". / scripts / conf ig --enable DEBUG INFO" run command ". / scripts / conf ig --enable DEBUG_INFO_REDUCED" run command ". / scripts / conf ig --enable AMD MEM ENCRYPT" run command ". / scripts / conf ig --disable AMD MEM ENCRYPT ACTIVE BY DEFAULT" run command ". / scripts / conf ig --enable CONFIG KVM AMD" run command ". / scripts / conf ig --enable CONFIG X86 64" run command ". / scripts / conf ig --enable CONFIG KVM" run command ". / scripts / conf ig --enableCONFIG_CPU_SUP_AMD" run command ". / scripts / conf ig --enableCONFIG CRYPTO DEV SP PSP"Atorney Docket No. 1739P001US01 run command / scripts / conf ig --enableCONFIG_CRYPTO_DEV_CCP" run command / scripts / conf ig --enableCONFIG_CRYPTO_DEV_CCP_DD" run command / scripts / conf ig --enableCONFIG VIRT DRIVERS" run command / scripts / conf ig --enable KVM AMD SEV" run command / scripts / conf ig --enableCRYPTO_DEV_CCP_DD" run command / scripts / conf ig --disableSYSTEM_TRUSTED_KEYS " run command / scripts / conf ig --disableSYSTEM REVOCATION KEYS" run command " / scripts / config --disable MODULE_SIG_KEY" run command " / scripts / config --enable SEV GUEST" run command " / scripts / config --disableIOMMU DEFAULT PASSTHROUGH run command " / scripts / config --disable PREEMPTJCOUNT " run command " / scripts / config --disable PREEMPTION" run command " / scripts / config --disable PREEMPT_DYNAMIC" run command " / scripts / config --disable DEBUG_PREEMPT" run command " / scripts / config --enable CGROUP_MISC" run command " / scripts / config --enable X86_CPUID" run command " / scripts / config --disable UBSAN" run command " / scripts / config --disable CONFIG_MODULES" run command " / scripts / config --disable CONFIG_PCI" run command " / scripts / config --disable CONFIG_USB" run command " / scripts / config --disable CONFIG_INPUT" run command " / scripts / config --disable CONFIG_HID" run command " / scripts / config --disable CONFIG_SERIO" run command " / scripts / config --disable CONFIG VSOCKETS" run command " / scripts / config --disableCONFIG_VIRTIO MENU run command " / scripts / config --disable CONFIG VIRTIO PCI run command / scripts / conf ig --disableC ON F I G_VI RT I O_MM I 0 " run command / scripts / conf ig --disable CONFIG_HYPERV" run command / scripts / conf ig --disable CONFIG PARAVIRT" run command / scripts / conf ig --enableCONFIG_BLK_DEV_INITRD" run command / scripts / conf ig --disable CONFIG_BLK_DEV" run command / scripts / conf ig --disable CONFIG_9P_FS" run command / scripts / conf ig --disable CONFIG_VIRTIO_FS" run command / scripts / conf ig --disable CONFIG_TTY" run command / scripts / conf ig --disable CONFIG VT" run command / scripts / conf ig --disableCONFIG_FRAMEBUFFER_CONSOLE" run command / scripts / conf ig --disable CONFIG DRM"Atorney Docket No. 1739P001US01 run command " . / scripts / conf ig --disableC0NFIG_SERIAL_8250 " run command ". / scripts / conf ig --disableCONFIG_SERIAL_CORE" run command ". / scripts / conf ig --disableCONFIG_HVC_DRIVER" run command ". / scripts / conf ig --disable CONFIG HVC XEN" run command ". / scripts / conf ig --disableC ON F I G_HVC_VI RT 10 " run command ". / scripts / conf ig --disable CONFIG HW RANDOM" run command ". / scripts / conf ig --enableCONFIG_CRYPTO_JITTERENTROPY" run command ". / scripts / conf ig --disable CONFIG KEXEC" run command ". / scripts / conf ig --disableCONFIG_KEXEC_FILE" run command ". / scripts / conf ig --disable CONFIG MAGIC SYSRQ" run command "make olddef conf ig" run command "make -j $ (getconf NPROCESSORS ONLN)KBUILD_BUILD_TIMESTAMP=@1 KBUILD_BUILD_VERS ION=1 " run command "cd . . " fi if [ $BUILD_OPENVPNDCO ] then announce "Building OpenVPN DCO Kernel Module..." git clone "https: / / github.com / OpenVPN / ovpn-dco" "master" "c24380c" run command "cd ovpn-dco" run” command "KERNEL_SRC=$ { BASE_DIR} / $ { KERNEL_VERSION } make -j $ (getconf _NPROCESSORS_ONLN) " run command "cp drivers / net / ovpn-dco / ovpn-dco-v2. ko$ { BASE_DIR} / vpn_build / " run command "cd . . " if [ $CONSTRUCT_INITRAMFS ] then announce "Constructing InitRAMFS . . . " run command "mkdir -p root" run command "cd root" run command "mkdir -p bin dev etc lib mod mnt proc root sbin sys tmp user var" run command "cp ${BASE DIR} / busybox / busybox bin / " run command "cp ${BASE DIR} / vpn build / sbin / nft bin / " run command "cp ${BASE DIR} / vpn build / sbin / openvpn bin / " run command "cp ${BASE DIR} / vpn build / bin / opens si bin / " run command "cp ${BASE DIR} / vpn build / bin / s sh bin / " run command "cp ${BASE DIR} / vpn build / bin / r sync bin / " run command "cp ${BASE DIR} / vpn build / bin / rsync-ssl bin / "Atorney Docket No. 1739P001US01 run command "cp $ { BASE DIR} / vpn build / bin / snpguest bin / " run command "echo \ " root : x : 0 : 0 : : / root : / bin / sh\ " > etc / pas sd" if [ $ DEVELOPMENT ] then run command "cd bin " run command "In — s busybox arp run command "In — s busybox arping " run command "In — s busybox cat" run command "In — s busybox chmod" run command "In — s busybox chown" run command "In — s busybox cp " run command "In — s busybox dmesg" run command "In — s busybox fold" run command "In — s busybox grep" run command "In — s busybox hostname " run command "In — s busybox if conf ig" run command "In — s busybox insmod" run command "In — s busybox ip " run command "In — s busybox ipaddr " run command "In — s busybox kill" run command "In — s busybox killall" run command "In — s busybox le s s " run command "In — s busybox In" run command "In — s busybox Is " run command "In — s busybox Ispci " run command "In — s busybox Isusb" run command "In — s busybox mkdir " run command "In — s busybox modinf o" run command "In — s busybox modprobe " run command "In — s busybox more " run command "In — s busybox mount " run command "In — s busybox ns lookup" run command "In — s busybox ping" run command "In — s busybox powerof f " run command "In — s busybox re set" run command "In — s busybox re start" run command "In — s busybox rm" run command "In — s busybox route " run command "In — s busybox sh" run command "In — s busybox sysctl " run command "In — s busybox systemctl run command "In — s busybox tail" run command "In — s busybox udhcpc " run command "In — s busybox unzip" run command "In — s busybox wget " run command "In — s busybox xargs " run command "cdAtorney Docket No. 1739P001US01 run command "cp ${BASE DIR} / ovpn-dco / drivers / net / ovpn- dco / ovpn-dco-v2. ko mod / " run command ox sh\" > init" run command mount -t devtmpfs devtmpfs / dev\" run commandmount -t proc proc / proc\" > init" run command "echo \ " / bin / busybox mount -t sysfs sysfs / sys\" >~ init" run command "echo \ " / bin / busybox mount -t tmpfs tmpfs / tmp\" > init" run command "echo \"ip link set dev io up\" > init" run command "echo \"ip link set dev ethO up\" > init" run command "echo \"mkdir -p / dev / net\" > init" run command "echo \"echo 1 > / proc / sys / net / ipv4 / ip forward / " > init" run command "echo V'openvpn --config / openvpn . conf ig &\" > init" ” run command "echo \"nft add table nat\" > init" run command "echo \"nft add chain nat postrouting { type nat hook postrouting priority 100 \; }\" > init" run command "echo \"nft add rule nat postrouting ip saddr 10.8.0.0724 oif ethO snat to 192.168.5.64 \ " > init" run command "echo \ " / bin / busybox sh\" > init" run command "echo \"poweroff -f\" > init" run command "find . | xargs -I filename touch -h -t 197001010000.00 filename" run command "find . | cpio -ov --reproducible -- format=newc | gzip -9 > . . / initramf z " run command "cd . . " fi if [ $MEASURE_DEPLOYMENT ] then announce "Measuring Deployment..." cd ${BASE DIR} / sev-snp-measure . / sev-snp-measure . py — vcpus 1 -- ovmf$ {BASE_DIR} / ovmf / Build / AmdSev / DEBUG_GCC5 / EV / OVMF. fd — kernel $ {BASE_DIR} / $ {KERNEL_VERSION} / arch / x86 / boot / bz Image — initrd ${BASE DIR} / initramf z --append " pci=off ip=off rd.neednet=0 systemd . ma sk= serial- getty@ttyS0. service , serial- getty@hvc0. service " --mode snp --vcpu-type EPYC-Milan-v2 -- output-format hex cd . . / . . fi announce "Completed Build. . . "Atorney Docket No. 1739P001US01Appendix C: Launch of the SEV-Enabled Server VPN (copyright © 2024 Dominic Schaub)# ! / bin / bash get_cbitpos ( ){ modprobe cpuid (dd if= / dev / cpu / O / cpuid ibs=16 count=32 8 | tail -c 16 | od -An -t u4 -j 4 -N 4 | sed -re OS=$ ( (EBX & 0x3f ) )get_cbitposMEM=4096 sudo qemu-system-x86 64 -enable-kvm -cpu EPYC-Milan-v2 -nographic -m $ {MEM} M, slots=5 , maxmem=$ ( ( $ {MEM} + 8192) )M \-boot menu=on -drive if =pf lash, f ormat=raw, readonly=on, f ile= . / 0VMF2. f d \-object memory-backend-memf d- private , id=raml , size=$ {MEM}M, share=true \-object sev-snp- guest , id=sevO , cbitpos=$ { CBITPOS } , reduced-phys- bits=l, discard=both, kernel-hashes=on \-machine q35 , conf idential-guest-support=sevO , kvm- type=protected, memory-backend=raml , vmport=of f \-device virtio-net , netdev=networkO -netdev tap, - smp-append " pci=off ip=off rd.neednet=O systemd.mask=serial- getty@ttySO . service, serial -getty@hvcO . service " -kernel / root / initramf s / bzlmage -initrd / root / initramf s / initramf zAttomey Docket No. 1739P001US01Appendix D: Example TBE guest kernel configuration (copyright © 2025 Dominic Schaub)# ===============================# A) Hard lock-down: no local input# ===============================# No loadable modules at all (prevents later re-enablement of drivers) CONFIG MODULES=n# Disable the Linux input subsystem (keyboards, mice, tablets, joysticks, etc.) CONFIG INPUT=n# Disable PS / 2 (i8042) and related serio devicesCONFIG SERIO=n# Disable HID layer (covers USB / BT HID devices)CONFIG HID=n# Disable USB host stackCONFIG_USB=n# Disable virtual terminals and framebuffer consolesCONFIG VT=nCONFIG VT _CONSOLE=nCONFIG VGA _CONSOLE=nCONFIG FRAMEBUFFER CONS OLE=n# Remove all TTY support (no / dev / tty*, no serial consoles, no virtio-console)CONFIG TTY=nCONFIG VIRTIO CONSOLE=nCONFIG HVC DRIVER=nCONFIG HVC VIRTIO=n# Remove magic SysRq and kexec escape hatches CONFIG_MAGIC_SYSRQ=nAtorney Docket No. 1739P001US01CONFIG KEXEC=n# Optional: disable ACPI power / sleep butons if power-buton input is not desired# CONFIG ACPI BUTTON=n# ===============================# B) Networking only# ===============================# Core networking supportCONFIG _NET=yCONFIG _INET=y# Virtio network drivers (for QEMU / KVM environments)CONFIG _VIRTIO=yCONFIG VIRTIO PCI=yCONFIG VIRTIO NET=yCONFIG PCI=yCONFIG ARCH RANDOM=yCONFIG CRYPTO JITTERENTROPY=y# Optional: network console for kernel logs when no local console exists# CONFIG NETCONSOLE=y# ===============================# C) QEMU fw_cfg (host-provided configuration values)# ===============================# Makes -fw cfg blobs available under:# / sy s / firmware / qemu_fw_cfg / by _name / opt / <name> / rawAtorney Docket No. 1739P001US01CONFIG FW CFG SYSFS=y# ===============================# D) SEV-SNP guest enablement# ===============================# x86 memory encryption plumbing and AMD SEV supportCONFIG _X86 MEM _ENCRYPT=yCONFIG AMD MEM ENCRYPT=y# SEV-SNP guest driver: provides / dev / sev -guest with the SNP report ioctl CONFIG_SEV_GUEST=y# UEFI / OVMF and EFI runtimeCONFIG _EFI=yCONFIG _EFI _STUB=yCONFIG EFI RUNTIME SERVICES=y#==========:# E) Early userspace quality-of-life#==========:# Automatic / dev population without udevCONFIG _DEVTMPFS=yCONFIG _DEVTMPFS_MOUNT=y# Tmpfs for simple runtime directoriesCONFIG TMPFS=yCONFIG TMPFS POSIX ACL=y

Claims

Attorney Docket No. 1739P001US01We claim:

1. A method for confirming that a remotely installed server software installed on a remote machine is configured with at least one specific feature, the method comprising: a) installing a copy of said server software on a local machine to result in a local installation of said server software; b) automatically confirming that said local installation is an exact copy of said remotely installed software in terms of configuration and content; and c) automatically confirming that said local installation is configured with said at least one specific feature.

2. The method according to claim 1, wherein prior to step a), confirming that an authentication response for said remote machine is validated by a digital attestation received from a download server that is different from said remote machine.

3. The method according to claim 2, wherein said digital attestation includes a cryptographic digest of at least a portion of an operating environment used for said remote installed software.

4. The method according to claim 2, wherein said digital attestation is generated and uploaded to said download server by said remote machine after said remote machine is initially booted and after said remotely installed software has been installed.

5. The method according to claim 3, wherein said digital attestation includes a cryptographic digest of at least one of:- a kernel of an operating system used by said remote machine;- an initial root file system of said operating system used by said remote machine;- a kernel command line for said operating system; and- firmware for use by said remote machine.Atorney Docket No. 1739P001US016. The method according to claim 1, wherein said remote machine is a virtual machine (VM) operating on a host system and wherein prior to step a), confirming that an authentication response for said remote machine is validated by a digital atestation.

7. The method according to claim 6, wherein said digital atestation includes a cryptographic digest of at least a portion of an operating environment used for said virtual machine.

8. The method according to claim 6, wherein said digital atestation is a Remote Atestation Report (RAR) generated by said remote machine, said RAR being signed by a host machine on which said virtual machine is operating.

9. The method according to claim 1, wherein public key cryptography is used in all communications between said remote machine and a user machine.

10. A method for confirming that a remote installed software installed at a remote machine is configured with at least one specific feature configured and installed, the method comprising: a) sending an authentication challenge to said remote machine; b) receiving an authentication response from said remote machine, said authentication response relating to software operating on said remote machine; c) downloading a digital atestation from a download server that is different from said remote machine; d) confirming that said authentication response is validated by said digital atestation; e) downloading resources for building a copy of said remote installed software on a local machine; f) building said copy of said remote installed software in said local machine to result in a local copy of said remote installed software; g) assessing said local copy to result in a local fingerprint for said local copy; h) confirming that said local fingerprint is validated by said digital atestation;- 65 -Attomey Docket No. 1739P001US01 wherein- when either of confirming steps d) and h) is not confirmed, stopping said method and determining that said remote installed software installed at said remote machine is not configured with at least one feature configured and installed; and- step f) is executed such that said local copy is compiled and linked deterministically.

11. The method according to claim 10, wherein said authentication response from said remote machine is exchanged using an encrypted channel.

12. The method according to claim 10, wherein public key cryptography is used for exchanging said first authentication response.

13. The method according to claim 10, wherein said method includes a step of: i) confirming that said local copy is configured and installed with said at least one feature.

14. The method according to claim 10, wherein said remote installed software is software implementing a remote VPN server.

15. The method according to claim 10, wherein said digital attestation includes a cryptographic digest of at least a portion of an operating environment used for said remote installed software.

16. The method according to claim 15, wherein said digital attestation includes a cryptographic digest of at least one of:- a kernel of an operating system used by said remote machine;- an initial root file system of said operating system used by said remote machine;- a kernel command line for said operating system;- firmware for use by said remote machine.

17. The method according to claim 10, wherein said remote machine is a virtual machine (VM) operating on a host system.- 66 -Atorney Docket No. 1739P001US0118. The method according to claim 17, wherein said digital attestation includes a cryptographic digest of at least a portion of an operating environment used for said virtual machine.

19. The method according to claim 17, wherein said digital atestation is a Remote Attestation Report (RAR) generated by said remote machine, said RAR being signed by a host machine on which said virtual machine is operating.

20. The method according to claim 10, wherein said digital attestation is generated and uploaded to said download server by said remote machine after said remote machine is initially booted and after said remotely installed software has been installed.

21. The method according to claim 1, wherein said remotely installed software is installed in a Trusted Execution Environment.

22. The method according to claim 10, wherein step e) comprises downloading build environment resources for implementing a trusted build environment that is to be used to build a copy of said remote installed software on said local machine.

23. The method according to claim 22, wherein said build environment resources include parameters and input to be used with trusted build environment to build said copy of said remote installed software on said local machine.

24. The method according to claim 10, wherein said method is executed by a machine different from said remote machine.- 67 -

Images