Pre-Boot Authentication: Wisdom in Security – Part 2

In my recent blog “Pre-Boot Authentication. Wisdom in Security”  I wrote in conclusion:

Bottom Line: ‘No PBA’ is not a wise choice for enterprises

Microsoft’s reasoning that you don’t need PBA because the known memory attacks are difficult to pull off on most modern hardware is simply wrong because the threat is much more than just those  attacks.”

One such attack made headlines last week. In response, our customers asked us about the recent report from F-Secure   Garry McCracken, our Vice President Technology responded in his blog that we recommend to customers to 1) Disable sleep and use hibernation instead, and 2) use PBA as part of the data security plan.

The attack by F-Secure made headlines, and it’s good for the industry to notice and prevent.

Furthering the conversation, I’d like to add that:

1)     A device is vulnerable if it physically has unencrypted sensitive data when an attacker has physical access to it.

  1. Data on disk must be encrypted.
  2. Leave no sensitive data in RAM, or even simply no data in RAM. We usually discuss that the disk encryption key is in RAM and that’s vulnerable; but the computer RAM (e.g. 8G of RAM) can contain lots of sensitive data.  That RAM data vulnerability is an issue, regardless of BitLocker or other FDE solution.  And note that today, hibernation is fast and is probably adequate for most users.

2)    “No PBA” contributes to this problem because it makes the device vulnerable even though the device has FDE and no data in RAM (it is shut down or in hibernation).  The attacker can still power on the device, and without PBA, the device will have data in RAM sitting to be exploited. In addition, “no PBA” let the attackers attack the boot process, which offers many more additional ways to attack on top of the “data in RAM” issue.

If enterprises just follow these two basic recommendations, all the complex Cold Boot attack issues with memory overwrite, etc. won’t matter, or will be of minimal effect.  The wisdom of security says: why bother with all complex issues if the right solution is simple: disable sleep and have PBA.

Granted, without sleep and with PBA, users have additional inconveniences when using computers. However, at this stage of IT security, I believe some minor inconveniences to establish peace of mind are more than justified. WinMagic has worked hard on making security transparent to users, but we will need more time and more industry support to make it happen.

We have actually worked hard to bring convenience to users on these two issues:

Secure Encrypted Virtualization (SEV)

  • One of the features of Secure Encrypted Virtualization (SEV) is that the RAM memory is encrypted. This allows sleep without the vulnerability or the RAM content. So, if you like “Sleep”, it might be available again – and secure

“No PBA”

  • For “no PBA” we have tried several things. Firstly, we have tried to ensure secure PBA meaning the user’s environment can allow our technologies to manage the PBA, taking over user interaction.  Enterprises can have a “proximity” smartcard so that user doesn’t have to do anything – like no PBA – even though there is a secure PBA with the smartcard authentication.  Or, we have currently offer “Pre-Boot Networking AutoBoot” which also boots without user intervention, if user is within the corporate network and the device is considered “not compromised”.  To be clear, complex big data analytics could be used to determine if a device has been compromised.  We just not there… yet.

By the way, we’ve worked hard on SEV not just because it allows sleep, but because SEV enables secure workloads, even if the workload is on the cloud and others have physical access to it.  For example, disk and memory.  Read our previous blog on the Cloud Trust.  For me, my “2 cents” says SEV is a game changing technology, not only for secure cloud workload, but also for secure workload against malware.

Wisdom doesn’t say things will happen now, but things will happen!

Previous Post
The Cold Boot Attack is Back
Next Post
Protecting Cloud Workloads against Undisclosed Access in Microsoft Azure