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.
A colleague brought the following Microsoft Security Advisory to my attention, that says “Microsoft is revoking the digital signature for four private, third-party UEFI (Unified Extensible Firmware Interface) modules that could be loaded during UEFI Secure Boot.”
In my last blog on computer forensics I addressed the question: does software Full Disk Encryption (FDE) Thwart Computer Forensics? To recap, a software encrypted drive could prevent effective forensics. However, if you have enterprise key management and forensics software that can interface with it to get the media encryption key (MEK) then it doesn’t have to be any more challenging than doing forensics on an unencrypted drive.
A colleague and I attended the Spring 2014 UEFI Plugfest in Seattle earlier this month. It was well worth attending as we had the opportunity to test and have one on one conversations with: Microsoft, Intel, the PC OEMs including HP, Lenovo, Dell, and of course the BIOS companies AMI, Insyde, and Phoenix. It was my second year in a row attending, and the third for my colleague, so we are now getting to see how things develop and change over time.