I know that vmware's Vsphere VM's can be encrypted using a KMS server but can the actual drive which vsphere is hosted on be encrypted? In Microsoft the hyper-visor host can be encrypted if bit-locker is enabled.
Not explicitly. You can, however, use Secure Boot to ensure that only signed code is ran: https://blogs.vmware.com/vsphere/2017/05/secure-boot-esxi-6-5-hypervisor-assurance.html
Based on Kyle Rudy's vmware link the following is good to note:
https://blogs.vmware.com/vsphere/2017/05/secure-boot-esxi-6-5-hypervisor-assurance.html
TPM and TXT
The question always comes up in customer conversations of “Does this require TPM or TXT??”. The answer is no. They are mutually exclusive. Secure Boot for ESXi is purely a function of the UEFI firmware and the validation of cryptographically signed code. Period.
Note that TPM 1.2 and TPM 2.0 are two vastly different implementations. They are not backwards compatible. There is support, via 3rd parties like HyTrust, for TPM 1.2 in ESXi 6.5.
TPM 2.0 is not supported in 6.5.
Standard BIOS firmware vs UEFI firmware
Typically, switching your hosts from their standard (legacy) BIOS firmware to UEFI firmware in some operating systems will cause issues. With ESXi, you can switch with no modification to ESXi. If you have installed 6.5 using standard BIOS and you want to try out Secure Boot then in the host firmware you can switch and ESXi will come up.
Related
Are Intel PTT (Intel Platform Trust Technology) and TPM chips functionally equivalent?
If I had a board with a Intel processor that supported PTT, would I have the same functions as if I had a hardwired TPM chip, e.g support of Trousers, etc.?
How do you discover if a particular Intel processor supports PTT?
The Intel Platform Trust Technology (PTT) architecture, first introduced in 2013 on 4th generation chips, implements TPM functionality within the CPU. PTT fully supports all Microsoft’s requirements for firmware Trusted Platform Module (fTPM) 2.0 specification.
To your operating system and applications, there should be no discernible difference between using PTT or using a dedicated TPM chip.
You will typically have an option in your firmware configuration utility to enable or disable PTT if your processor supports a fTPM. On Windows, you can check if you are using a TPM or a fTPM (PTT) by running TPM.MSC. On Linux, check under /sys/class/tpm, sys/kernel/security/tpm or your boot log.
The easiest way is to check in the BIOS. Usually you have to enable it in the BIOS if you want to use it because the default is disabled on all the systems I've seen.
I am trying to add a TPM 2.0 enabled device to Azure Device Provisioning Service Enrollment List. This requires the Endorsement Key (EKPub) of the TPM.
What would be the best way to extract (find out) the EKPub (Endorsment Key) of a TPM? I appreciate your help.
Intel provide a suite of tools for interacting with a TPM 2.0 which you can download from here: https://github.com/tpm2-software/tpm2-tools
Note you'll have to also compile and install abrmd (a resource manager) and the tss stack/libraries. The tools work on Linux (Ubuntu, RedHat, CentOS, Debian at least, and Raspian on the Raspberry PI with a suitable TPM board).
The command you're looking for here is: tpm2_createek which will generate the EK and store it in the TPM. Meaning, that the TPM 2.0 has a seed value from which the EK (and AK) is generated when needed. Typically - at least we do - is generate the EK and AK, then move these to persistent handles so they survive power down.
https://github.com/tpm2-software/tpm2-tools/blob/master/man/tpm2_createek.1.md
Xen has the ability to attach virtual trusted platform modules (vTPMs) to guest VMs: http://wiki.xenproject.org/wiki/Virtual_Trusted_Platform_Module_(vTPM). I would like to know if there is any Openstack integration for this feature - can managed VM for instance be provisioned vTPMs?
I saw something similar for Hyper-V here:
http://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/hyper-v-vtpm-devices.html
OpenStack provides the following as part of Cloud tenant threat mitigation:
Use separated clouds for tenants, if necessary.
Use storage encryption per VM or per tenant.
OpenStack Nova has a Trusted Filter for Filter Scheduler to schedule workloads to trusted resources only (trusted computing pools), so workloads not requiring trusted execution can be scheduled on any node, depending on utilization, while workloads with a trusted execution requirement will be scheduled only to trusted nodes.
With the following process:
Before you can run OpenStack with XenServer, you must install the hypervisor on an appropriate server .
Xen is a type 1 hypervisor: When your server starts, Xen is the first software that runs. Consequently, you must install XenServer before you install the operating system where you want to run OpenStack code. You then install nova-compute into a dedicated virtual machine on the host.
While XAPI is the preferred mechanism for supporting XenServer (and its deprecated sibling XCP), most existing Xen Project integration with OpenStack is done through libvirt below.
compute_driver = libvirt.LibvirtDriver
[libvirt]
virt_type = xen
Hardware TPM is also supported:
Our solution essentially mimics how one may download software and compute its SHA-256 hash and compare against its advertised SHA-256 hash to determine its legitimacy. It involves using Intel TXT, which is composed of hardware, software, and firmware. The hardware, attached to the platform, called the Trusted Platform Module (TPM)[3], provides the hardware root of trust. Firmware on the TPM is used to compute secure hashes and save the secure hashes to a set of registers called Platform Configuration Registers (PCRs), with different registers containing different measurements. Other components are Intel virtualization technology, signed code modules, and a trusted boot loader called TBOOT1. Essentially the BIOS, option ROM, and kernel/Ramdisk are all measured in the various PCRs. From a bare metal trust standpoint, we are interested in PCRs 0-7(BIOS, option ROM). The kernel/Ramdisk measurements would depend on the image the tenant seeks to launch on their bare metal instance. PCR value testing is provided by an Open Attestation service, OAT[2]. Additional details in references.
with these security considerations:
At the time of this writing, very few clouds are using secure boot technologies in a production environment. As a result, these technologies are still somewhat immature. We recommend planning carefully in terms of hardware selection. For example, ensure that you have a TPM and Intel TXT support. Then verify how the node hardware vendor populates the PCR values. For example, which values will be available for validation. Typically the PCR values listed under the software context in the table above are the ones that a cloud architect has direct control over. But even these may change as the software in the cloud is upgraded. Configuration management should be linked into the PCR policy engine to ensure that the validation is always up to date.
References
Tighten the security of your OpenStack Clouds - OpenStack Superuser
Xen, XAPI, XenServer - OpenStack Configuration Reference - kilo
XenServer - OpenStack
XenServer/XenAndXenServer - OpenStack
XenAPI Specific Bugs : OpenStack Compute (nova)
OpenStack - Xen
Xen via Libvirt - OpenStack Configuration Reference - liberty
Hypervisors - OpenStack Configuration Reference - kilo
OpenStack Docs: Overview of nova.conf
OpenStack Docs: nova.conf - configuration options
OpenStack Docs: Telemetry configuration options
Configure APIs - OpenStack Configuration Reference - kilo
OpenStack Docs: Glossary
Bare-metal-trust - OpenStack
Baremetal driver - OpenStack Configuration Reference - juno
OpenStack Docs: Integrity life-cycle
Current Series Release Notes — Nova Release Notes 16.0.0.0b3.dev171 documentation
Enhanced-Platform-Awareness-OVF-Meta-Data-Import - OpenStack
Example nova.conf configuration files - OpenStack Configuration Reference - kilo
Chapter 7. Configuring a Basic Overcloud using Pre-Provisioned Nodes - Red Hat Customer Portal
Feature Support Matrix — nova 16.0.0.0b3.dev171 documentation
Trusted Computing for Infrastructure (pdf)
What is Hyper.sh | Hyper.sh User Guide
Xen TPM Manager
Supporting Open Source Software Development in SSOs/SDOs
Xen Cloud Platform Virtual
Machine Installation Guide (pdf)
OpenStack Docs: Security hardening
policy.json - OpenStack Configuration Reference - kilo
Appendix B. Firewalls and default ports - OpenStack Configuration Reference - kilo
New, updated and deprecated options in Kilo for Orchestration - OpenStack Configuration Reference - kilo
How can I develop applications that use Arm's trust zone? Specifically, I want to develop a program that can save sensitive data in the secure world.
Should this program run in the normal world or the secure world? I know there are trustlets in the secure world, do I need to develop trustlets? Are there SDK or API
that I can use to directly interact with an existing secure world os or do I need to compile and install my own secure os?
Any advice will be greatly appreciated.
Thank you!
There are two extremes. These are documented in the Software overview chapter of ARMs Security Technology: Building a Secure System using TrustZone Technology.
APIs
At the one end of the spectrum, there is only a set of APIs which can be called from the normal world. This is detailed in the SMC calls for Linux. For instance, if the device contains a public-private key, an API call could sign data. The normal world would never have access to the private key, but anyone can verify that the device is original by verifying the signature. So the normal world is free to forward this request over any communications interface. This maybe part of authenticating a device.
Co-operative OSs
In this mode, there is a full blown OS in both the secure and normal world (called TEE and REE elsewhere). The OSs must co-operate with interrupts and scheduling. They may also use SMC calls, lock free algorithms and semaphores along with shared memory.
ARM recommends using the FIQ for the secure world and to leave the IRQ for the normal world. Specifically, there are settings to stop the normal world from masking the FIQ ever. All of these issue rely on the type of IPC, scheduling, interrupt response, etc that the system needs.
The simplest Secure scheduler would always pre-empt the normal world. Only the idle task would yield the CPU to the normal world. A more flexible solution would have the schedulers co-operate so that both worlds can have higher and lower priority tasks.
The better way is install a REE OS and a TEE OS in one device. When a program wants to do some sensitive things, the device will change to TEE OS, so you can deal with sensitive date securely. When you have done with sensitvie date, device will change to REE OS.
But implementing two OS switch on a device is a tough work.
Operating Systems such as MobiCore already exist and have been deployed on mass market devices such as Samsung Galaxy S3.
MobiCore is an OS that runs alongside Android, so trustlets (= MobiCore apps) can communicate with Android apps via a set of system calls to the MobiCore driver, which is the part of the Android OS in charge of communicating with the trusted execution enviromnent.
If you are looking to develop trustlets for MobiCore as explained above, you must become a MobiCore developer, which you could theoretically do by signing up as a developer for MobiCore's Trustonic venture.
If you wish to use ARM's TrustZone technology on your own device / dev board with an open-source secure OS, perhaps you can use OpenVirtualization's SierraTEE, which seems to be compiled for Xilinx Zynq-7000 AP SOC and also compatible with Android as the rich OS.
You can use OPTEE(Open Sourec Portable Trusted Execution environment) OS. If you are looking for trusted execution environment application examples, which are also know Trusted Applications(TA), then you can check this optee trusted applications examples repository and this TA using OP-TEE and Comcast Crypto API.
Optee os provides following APIs for writing Trusted Applications:
Secure Storage APIs for secure storage
Cryptographic Operations APIs for encryptiion, decryption of secure credentials and data
Secure Element API which help in hosting applications or applets on tamper-resistant platform
Time APIs
Arithmetical APIs
For client side or normal world optee provides:
Tee client side Apis
You can refer documentation here.
If we need to do OS reload on a remote machine, how can the network boot be enabled on the client machine without making any changes in the BIOS ??
I am in a try to develop a control panel, in which this feature is included. i.e., fully automated OS reload and thinking of using the pxe boot. But enabling and disabling boot from network is a problem. Any work around, please ?
Hacker approach: Use the bootloader to load GPXE from the harddisk.
You'll need a version that fits to your NIC: Images for many hardware types and booting methods can be generated at ROM-o-matic. Use the PCI ID from the NIC to programmatically select the version that fits best. People may also have add-on network cards, e.g. for gigabit LAN.
This way you don't need to fiddle with the mainboard and network card specific ways to turn PXE on.
First, since your question is not programming related, I suggest you pose it again on the sister site serverfault.com. You might get more/better answers there.
Second, I do not think you will be able to remotely activate PXE on arbitrary machines. Maybe this works when you have Intel's AMT (Active Management Technology) on those machines, but then you already have BIOS access. But nevertheless you could activate PXE boot on all machines and from your PXE server, selectively offer boot images only to those machines you want to. All other machines would then just boot the installed OS. The FAI (Fully Automatic Install) system uses that approach, but is Linux only, AFAIK.
I agree with Dubu that reliable enable/disable of PXE boot in the BIOS across heterogeneous target hardware is not readily achievable. The better suggestion is to configure all your target machines to include PXE prior to local disk in their configured boot order always. You can PXE boot to something like PXELINUX and have the default choice be a local disk boot. Then you can selectively target particular machines to PXE boot into a network loaded OS (for OS reinstallation purposes) by configuring symlinks with the target machine's MAC address inside the PXELINUX TFTP root.