Intel RST BitLocker eDrive Win10 conflicts

[idata]

Hi,

I'm trying to use BitLocker eDrive hardware encryption, but Intel RST 14.5.0.1081 is confilicting. I know this because when I uninstall RST, it works, but when it's installed it uses software encryption (BitLocker asks if I want to encrypt whole drive or only used portion)

This problem existed with an older version of RST on Windows 8.1 too and was fixed in version 13.2 (not entirely sure of exact version) but seems to be back.

Discussion about the issue earlier: https://forums.lenovo.com/t5/ThinkPad-T400-T500-and-newer-T/T440s-How-to-enable-the-Windows-eDrive-feature/td-p/1364811 T440s: How to enable the Windows eDrive feature? - Lenovo Community

Using Windows 10 x64 and Samsung 850 EVO SSD...

[HKim49]

This bug / incompatibility has been for many years.

Any updates?

[LWhit1]

Hi Esteban,

it's been over a month since you lasted posted. Can you give us a status update please?

Thanks

[moneytree]

strophy wrote:

Hi Esteban,

it's been over a month since you lasted posted. Can you give us a status update please?

Thanks

EstebanC_Intel never replied after only enabling software encryption. Maybe he never figured out how to enable eDrive hardware encryption.

[LWhit1]

Nearly 3 months since Esteban confirmed the bug and went off to fix it, is this the maximum speed for Intel support? Did you lock yourself out of your laptop or what happened?

[DLazz]

I don't even think it matters a whole lot. The newest driver wouldn't even install on my box because it evidently is no longer supported on the newest RST builds.

I have a Z97 board, btw.

[PRile]

To EstebanC_Intel,

A Intel 535 Series drive does employ hardware encryption using AES 256bit. However, it is NOT an eDrive, and as such will not be recognized by bitlocker as a hardware encryption capable drive. You are using bitlocker in Software Encryption mode.

Today most SSD's are also SED's. However, only a small subset of SED's are actually Opal V2 or eDrive compliant - a requirement to use Bitlocker in Hardware Encryption mode. Bitlocker falls back to Software Encryption mode.

You can recognize which Bitlocker mode your're using, because with Software encryption you will be given the option to only encrypt the used parts of the disk. With Bitlocker Hardware encryption (on an eDrive), you will NOT be prompted to encrypt only the used parts of the disk.

One other thing that often goes unnoticed about eDrive compliant drives. The entire drive is actually NOT encrypted. Instead ranges of the drive get encrypted. In a Windows 10 clean install, the 4th partition - where the C Drive [os] is stored is encrypted, but other partitions are not.

It's a shame that there isn't any good updated documentation that describes Bitlockers Hardware Encryption mode.

One other thing that make this topic confusing, is that some SED's that are eDrive capable, are not shipped in eDrive mode (Samsung). Others are shipped in eDrive mode (Crucial). So in some cases you must first push the drive into eDrive mode using a vendor supplied utility. Even more confusing, when you couple an eDrive with TPM 2.0, the ownership of the TPM is taken over by Windows 10 installation - automatically (unless disabled). It's believed that Microsoft does this so that a user doesn't try to use the ATA mode (not eDrive mode), to lock the drive (think Bios Hard Disk password). It's easy to confuse a Bios ATA password with a Bitlocker TPMandPin challenge - but they are very different.

I hope someone will write a white-paper on all this once the TCG and Microsoft figure out how to actually make Opal and eDrive's secure. It was demonstrated at a Black hat conference that an encrypted drive can simple be moved to a second computer (while keeping it powered) and all of the data can be accessed. Until these standards actually encrypt the SATA commands to communicate with the drive, instead of only unlocking the drive, all SED hard disk data is not really secure, unless the drive is powered down. Once the drive is unlocked by a valid user, it remains unlocked and vulnerable until it is powered down again. So if your data is sensitive, don't just lock the keyboard, or even "standby" the computer. You must hibernate or power down to actually "secure" the data.

https://www.pcworld.com/article/3004670/business-security/self-encrypting-drives-are-hardly-any-better-than-software-based-encryption.html Self-encrypting drives are hardly any better than software-based encryption | PCWorld

https://www.blackhat.com/docs/eu-15/materials/eu-15-Boteanu-Bypassing-Self-Encrypting-Drives-SED-In-Enterprise-Environments-wp.pdf https://www.blackhat.com/docs/eu-15/materials/eu-15-Boteanu-Bypassing-Self-Encrypting-Drives-SED-In-Enterprise-Environme…

[DLazz]

I don't recommend anyone attempt to recreate the steps I outlined in the Youtube clips up above because now I have some really weird stuff going on.

After I recorded those videos, I undid my work (removed RST, re-enabled Bitlocker on all volumes).

A few days after that, Windows updated and I had to reboot. Upon rebooting, I noticed my plain HDD's (also Bitlocked) didn't automatically unlock even though they're set up to. When I went to the Control Panel to see what was up, the Bitlocker Drive Encryption option was completely gone. I could still work with my drives via manage-bde, but for whatever reason it wasn't in the Control Panel.

After a few hours of digging, I realized that Bitlocker makes a triumphant return to my Control Panel as soon as I turn it off Bitlocker on my SSD. I can Bitlock my HDD's all day and it works fine, but as soon as it's enabled on my SSD it disappears from Control Panel and Auto-unlock on my HDD's stops working.

I figured I'd just leave this here as a warning. It might be a Microsoft issue, it might be related to RST.

Regardless -- I am at a point where I can't reliably enable Bitlocker on my volumes for one reason or another.

The above issue was resolved by KB3189866.

[DLazz]

It appears as though there's a new version of RST out. (v 15.2.0.1020)

There is no mention of the eDrive bug in the change log.

I'm going to give it a whirl.

Edit: No I'm not. "Platform not supported". Running Win 10 x64.

[Artemiris]

Just reporting in that the hardware encryption issue with RST is still present with the latest version as of date. Version 15.5.0.1051. Not worth trying it out as I have tested it myself. Ended up resorting to a system restore to regain access to my drive.

[MEver2]

EstebanC_Intel It's now been nine months since anyone from Intel participated in this thread, and there's still no resolution for the hardware encryption problem with RST.

Intel: What's going on with this? Can anyone provide an update?

[JW8]

Intel, any update on ever getting this fixed??

I also found that Windows Update is starting pushing an updated AHCI driver. (Intel RST 14.8 in my case). This is breaking working systems.

I installed windows, enabled edrive via Bitlocker, and everything was working, using the default windows driver (as detailed in this thread). Then at some point, windows update installed the RST driver. Windows continued to work normally, but Bitlocker was broken, saying that the drive was not encypted. I had to install the drive in another machine to decypt the drive.

I've since added a rule via group policy to prevent any driver changes. (PCI\VEN_8086&DEV_8C03)

https://support.microsoft.com/en-us/help/2500967/how-to-stop-windows-7-automatically-installing-drivers https://support.microsoft.com/en-us/help/2500967/how-to-stop-windows-7-automatically-installing-drivers

Windows 10 x64

Lenovo T440p

Samsung 850 Pro

[Artemiris]

Hello, it's been a while since I last replied in this post and I've changed my setup a bit: now my eDrive is my OS drive. (I took a break from using eDrives for a while until now) Difference I noticed from back in the day is that Windows starts up fine, no issues with long loading times and the eDrive being completely inaccessible which I had when I had my eDrive as a secondary drive.

There's still an issue related to it however. Upon installing RST Windows 10 will fail to recognize the eDrive as being hardware encrypted. BitLocker won't recognize any form of encryption whatsoever. I verified this with "manage-bde -status c:". When I reboot into safe-mode, however, it will prompt me to fill in the recovery key for the encrypted drive.

This means that the eDrive is still fully hardware encrypted, but Windows simply fails to recognize it as an encrypted drive. Because of this BitLocker allows you to "re-encrypt" the already encrypted drive, but with software encryption instead. Obviously this isn't necessary, since the drive is already encrypted and requires a properly setup TPM/PTT to automatically open the drive. Otherwise it will not be accessible.

I've reinstalled Windows now, but again without RST installed. I guess I have to stick with this setup for a while.

I am putting this here, because if you have a similar situation as me, and are wondering why your drive is not encrypted: it is encrypted, it just isn't able to recognize it.

[n_scott_pearson]

Forgive me for what might be considered a dumb question, but why are you installing Intel RST anyway? The only time that you should be installing Intel RST is if you want to use RAID or disk caching (Intel SRT or Optane). If you are not using any of these technologies, you should not be installing it. It offers no advantages otherwise.

...S

[Artemiris]

Quoted from Intel:

"Intel® Rapid Storage Technology offers greater levels of performance, responsiveness, and expandability than ever before. Whether you are using one or multiple serial ATA (SATA) or PCIe drives, you can take advantage of enhanced performance and lower power consumption from the latest storage technologies. Additionally, you can rest easy knowing you have added protection against data loss in the event of a hard drive failure."

[n_scott_pearson]

I am not going to argue with you Rafael, but that quote is talking about the performance gains that you can get using RAID or one of the HDD Caching technologies (SRT (SSD-based Caching) or Optane memory-based caching) that it supports (this is where the 1 comes from, since you can cache a single HDD). The pure gains you might get just using it as a replacement SATA driver are minimal and, IMHO, not worth the effort (especially when considering this bug).

...S

[Artemiris]

Well I'm not too familiar in this area so you can always correct me, I'd rather have someone correct me so I can learn. It's just that I'm quoting it from Intel directly, but I always take it with a grain of salt ('cuz it could just be written down like that for marketing purposes)

[PRile]

I'm seeing a similar problem. I have a crucial eDrive and a NUC with TPM 2.0. manage-bde -status shows:

Hardware Encryption - 1.3.111.2.1619.0.1.2

So I know that I'm using Bitlocker in eDrive mode. But when I move the drive from the NUC to another computer, the drive is not recognized as a BitLocker encrypted drive, so I am not prompted to enter a Recovery key.

Could you try accessing your drive on another computer? Does it start the recovery mode?

I'm trying to determine if this is a crucial eDrive implementation bug, or a Microsoft Bitlocker eDrive bug. Everything works fine and as expected if I use Software Encryption, so I really think this is an eDrive issue. Your message might suggest that Bitlocker is not doing a good job recognizing the presence of an eDrive, so it never starts the Recovery dialog, and never sends the AK key to the unlock the drive.

This is really frustrating - and DANGEROUS. While encrypting is working great, should the NUC fail, I will not be able to recover the data in another computer via the Recovery Key - if Bitlocker can't recognize its looking at a eDrive.

Any comments?

[npole]

I can confirm that this bug still exists. Not able to enable bitlocker with hardware encryption with any version of Intel RST. We are not able to use the feature we want even though we have paid for all the right products to enable and use hardware encryption (OEM, motherboard, Storage, Microsoft). I feel cheated by Intel.

Platform details below:

System Model: Fujitsu Lifebook S935 Laptop

OS: Windows 10 Pro v1709

CPU: Core i5 5200U

Motherboard Model: Fujitsu FJNB284

BIOS Version: FUJITSU Phoenix v1.13 dated 13.Apr.16 (updated)

Storage devices present: Samsung SSD 850 EVO 500GB

RAIDs: None

RST driver versions tested: 14.8.0.1042

Couldn't install the latest version of RST (v15), error was incompatible platform.

I went ahead and did everything from start. Took full backup, did Secure Erase (as recommended) using Samsung magician tool, reinstalled Windows 10, enabled Bitlocker and it encrypted with Hardware encryption. Find output of 'manage-bde' below:

Windows updated the RST after a while and the bitlocker 'lock' icon was gone and manage-bde status of drive said protection off and encryption as none. All attempts to force hardware encryption using command line arguments didn't work, it said hardware not supported. Unfortunately I couldn't find the screenshots (lost in 1000s of images).

I had to enable Bitlocker with software encryption:

[Artemiris]

Did you read the post I made earlier? Hardware encryption is still enabled after you install RST, it's just not detected by Windows. Go ahead and try to unlock your drive on another PC, it's not going to work and you're unable to read its contents until you use a recovery key.

Sorry for double post.

[npole]

I just did a full wipe and reinstall of my laptop and got to enabled the hardware encryption.

The Secure Erase function of Samsung tool didn't work, so I had to run Diskpart > Clean the disk before installing.

After installing OS I used Samsung Magician to check for 'Encrypted Drive' and it was already enabled. I DID NOT install the Intel RST drivers and didn't install any drivers from laptop OEM. Now it has all Windows updates and applicable native drivers (or default from MS) for SSD and all devices on laptop. I enabled Bitlocker with GUI and after a restart SSD encryption was enabled.

Will keep close track on what driver installation the encryption gets knocked off. (Last time too it was running with h/w encryption but got reverted soon after installing one of the drivers)

[ALost]

Hi,

can you please check your event viewer, if you also get the following error message when using stock windows AHCI driver with your Samsung drive:

A TCG Command has returned an error.

Desc: AuthenticateSession

Param1: 0x1Param2: 0x60000001CParam3: 0x900000006Param4: 0x0Status: 0x12

EnhancedStorage-EhStorTcgDrv

Opcode : TcgLib

I see this error in a boot up sequence on my Crucial MX300 1Tb + HW Encryption + Windows AHCI driver.

Thank you in advance!