Is Microsoft really claiming pre-boot authentication (PBA) for Full Disk Encryption (FDE) is not necessary? One could certainly get that impression from recent articles (HERE and HERE) posted by the organization. The first article on “Types of attacks for volume encryption keys” lists a few known historical attacks that “could be used to compromise a volume encryption key, whether for BitLocker or a non-Microsoft encryption solution”, and the second makes statements like “For many years, Microsoft has recommended using pre-boot authentication to protect against DMA and memory remanence attacks. Today, Microsoft only recommends using pre-boot authentication on PCs where the mitigations described in this document cannot be implemented.”
In April 2015 I wrote about “Intelligent Key Management for the Cloud”. In that blog I described the various models for encryption and key management for virtual workloads running in IaaS including:
In the past I have tried to make the case for encrypting physical servers on premise. The argument for not needing to encrypt them is usually that these servers run for weeks, months or even years without being brought down, and that they are physically protected within a well-fortified data center. The protection that FDE (Full Drive Encryption) brings only really applies to data at rest and it seldom is at rest on these servers. I would counter that all drives eventually leave the data center for repair or disposal and having them encrypted protects you from having your old drives with your customer data on them show up on eBay. An encrypted drive can be quickly and easily crypto-erased if it is still operational, and if not, the data is still not accessible without the encryption key.
Today with virtualization and especially with hyperconvergence infrastructure (HCI) the attack surface has greatly expanded and therefore the need for FDE has greatly increased. But before I make my case, here is some background on HCI:
A hyper-converged system is a pre-configured virtualized server platform that combines compute, storage, networking, and management software in a single appliance. Hyper-convergence enables customers to simply and rapidly deploy mixed-workload and virtual desktop integrated infrastructure solutions across local or remote locations. i.e. it is a mini Cloud in a box that can be connected to other HCI boxes.
HCI boxes are still physical things kept on premise, and the argument above for protecting them with FDE still applies. However, the argument for not encrypting them doesn’t. HCI workloads run in Virtual Machines (VM) on top of the hypervisor, not directly on the physical hardware. It is the VM and its data that needs protecting. In today’s fast moving environment the VMs come up and go down much more often than physical machines. In some cases VMs come and go several times a day. When an admin takes a snapshot of running machine or turns it off, the VM is at rest and a VM at rest is just a big file. It can be copied onto a USB memory stick or over the network. In fact one of the advantages of HCI is that workloads (or VMs) can be moved around easily from HCI node (box) to HCI node. Looking forward, HCI vendors are working with the public cloud providers, such as Google, to move workloads seamlessly back and forth between on premise and the public cloud. So unlike physical servers VMs can move around a lot and often are in a data at rest state. This is the perfect application of FDE, but not at the physical (hardware) level. If we encrypt only at the physical level, the only protection we get is for the disposal or loss of the physical drive. However, the VM, is easy to move around, and is still in plain text if copied even when using physical level FDE. The answer then is to encrypt the VM itself, preferably with in-guest encryption that is independent of the hypervisor with the key under the control of the enterprise. This way even if the VM is moved to another HCI box – perhaps in another country or even into a public cloud – the customer keeps control of the data, because it can decide to provide the key or not to decrypt and unlock the VM.
Advantages of VM encryption for HCI include:
- Scalability: VM-level Encryption is highly scalable. It is protection that actually resides with your data and scales with each new VM brought up.
- Security: Physical level Encryption protects against lost or stolen physical drives. VM-level Encryption protects against lost or stolen physical drives, unauthorized data movement, access, replication, etc.
- Continuity: With physical level Encryption, workloads are decrypted (unprotected) in-transit – no continuity in security model. VM-level Encryption protects workloads continuously, persistently as they move, clone, snapshot across your infrastructure
- Portability: Physical level Encryption is reliant on exactly that, your hardware – but what about hybrid IT and workloads in-transit. VM-level Encryption eliminates lock-in to hardware, hypervisors or cloud providers – it’s completely portable protection
- Flexibility: VM-level encryption allows you to encrypt sensitive workloads and run them securely alongside your non-sensitive workloads. Different keys and policies can apply to different VMs
- Governance: VM-level Encryption enables boot-based policies so you can control, who can access your data, where your data resides and how it is protected
- Termination: VM-level Encryption allows you to securely terminate individual workloads as you’re finished with them – it’s simple
To summarize, in the old world some can rationalize not encrypting their physical servers, because there are compensating physical controls such as locked doors and sturdy walls. In today’s world with HCI and virtualization, workloads are virtual, dynamic, mobile, scalable and vulnerable. The solution is to protect them with in-guest encryption with keys under the control of the VM owner.
From May 17th to 19th, I had the pleasure of attending the Fifth International Cryptographic Module Conference (ICMC 2017) with my colleague, Alexander Mazuruc. Alex usually attends this conference which focuses on cryptographic modules and FIPS 140 type issues, but this year there were 8 tracks on related subjects such as Quantum-safe crypto (yes, that is a thing), and Common Criteria. The conference had about 35 different sponsors including the Trusted Commuting Group. Overall I found the conference very informative and a good place to network in the community.
I have written about the security implications of using sleep with encrypted drives in the past and have offered both short term and longer term solutions that would allow users to use sleep under some conditions and not risk (too much) a data breach. Today I am writing to offer another, common sense, alternative: Just don’t use sleep because you don’t really need it.
It has been a while since I have written about UEFI, Secure Boot and their impact on Full Disk Encryption (FDE) pre-boot authentication (PBA) so it’s time for an update on what is new in this area, but first here is a recap because this is a bit of an arcane technical subject. UEFI stands for “Unified Extensible Firmware Interface”. The UEFI specification defines a standard model for the interface between personal-computer operating systems and platform firmware. It provides a standard environment for booting an operating system and running pre-boot applications such as the PBA for FDE. It replaces the traditional legacy BIOS interface that was used with Windows 7 and older systems. Now that Windows 10 is being widely adopted I expect to see UEFI used on almost all new machines.
Last week, I once again had the pleasure and privilege of attending the RSA Conference in San Francisco. I heard estimates of a record breaking 40,000 attendees. It didn’t seem much busier than previous years but as another participant pointed out to me, that might be because it was better organized, with pre-registration for the sessions, this year. This year I focused my sessions on the Cloud.
If you have been following our blogs you know that the ideal FDE architecture has two main components. The actual encryption component is a separate layer from the key management. The encryption can be done by the OS (e.g. BitLocker for Windows or FileVault2 for Mac), by Self-Encrypting Drives (SEDs) or by ISVs such as WinMagic’s FIPS140-2 validated software cryptographic engine.
In a previous blog I wrote that at Black Hat Europe 2015, two forensics experts from KPMG Canada presented their findings in a presentation titled “Bypassing Self-Encrypting Drives (SED) in Enterprise Environments”.
I once again had the pleasure and privilege of attending the largest security conference in the world; the 2016 RSA Security Conference in San Francisco. This year’s conference was well attended with a reported 40,000 attendees. This is up from fewer than 20,000 just a few years ago.
In November at Blackhat Europe 2015, two forensics experts from KPMG Canada presented their findings in a presentation titled “Bypassing Self-Encrypting Drives (SED) in Enterprise Environments”.
This year (2015) the Trusted Computing Group (TCG) Storage Work Group (SWG) published two new specifications derived from the Opal SED specification called Opalite and Pyrite. You may already be familiar with the benefits of using an Opal SED vs software encryption in your laptops and desktops, but are puzzled as to why there are 2 new standards. Perhaps you even wonder if they would be a better fit for your needs than Opal.
I was fortunate to be able to attend the RSA Security Conference in San Francisco last week. The conference was bigger than ever with lots of new vendors displaying a wide breath of security products.