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.
NVMe technology had a big presence at the Intel Developer Forum (IDF), held in San Francisco of September this year. There were products and demonstrations from about a dozen leading vendors including Intel and Micron. I also attended quite a few sessions, but the one on NVMe was the only one that was overflowing with people.
Last month I wrote about the necessity of performing Pre-Boot Authentication (PBA) in order to get the full benefit of confidentiality that Full Disk Encryption (FDE) can provide. However, there are some environments where corporate security policy might allow for a less secure configuration as tradeoff for better usability. For example, I have conceded in the past that if a user is within the physical confines of his company, say travelling from one floor to another for a meeting, that sleep / standby (S3) might be an acceptable risk.