Another Bone to Pick with Microsoft

Back in August Microsoft deployed their Anniversary Update for Windows 10.  I learned my lesson on early adopting anything coming out of Redmund, so I have my Professional copies set to defer feature updates.  I do not intend to take on those updates unless I absolutely have to.  Well, yesterday Microsoft forced my hand and jammed the Anniversary Update down my throat, like it or not.  I did everything I could to stop it, even editing the registry to make my ethernet connection register as a metered service.  It still downloaded it.  I unplugged the cable from the back of the machine which stopped the download midstream and frantically Googled for a way to stop it.  Not finding one, I phoned Microsoft for a solution.  The tech I finally spoke to told me there were two solutions they could offer.  1) Let the update finish and then use the recovery option to go back to an earlier build.  2) Stop all updates completely.  So, I had to choose between a bad option and a bad option.

I understand that security updates are important, so I went with bad option number one.  Now I get to the bone I am picking.  I have my computer encrypted with Bitlocker, and other stuff.  In process of installing this rather large update, Windows required a few reboots.  During the first reboot, I unlocked my encrypted thumb drive that contains the key file required for my computer to boot, and I prepared to enter the password also required to boot, and watched in amazement as it simply continued on with the install without any input from me.

Let’s put this into perspective.  I have configured Bitlocker to require a key stored on a TPM chip installed on the motherboard, a key file stored on the above-mentioned hardware encrypted thumb drive, and a twenty character alpha-numeric pin (the maximum length Bitlocker supports).  My computer, while installing the update, rebooted.  The screen showed the video card post screen, the raid post screen, and the motherboard post screen that handed the process over to the Windows boot loader.  At that point, with only the TPM portion of the process fulfilled, the Windows Update process continued to write to an encrypted file system.  How?

I presume that the RAM was cleared, so the encryption key shouldn’t have been stored there.  The file system is encrypted, so it could not have been stored there as the update process would not have the key to read the key.  So the only place left is the unencrypted boot sectors of the system drive.  That is a massive security hole that completely destroys the point of encryption.  If the key was written to an unencrypted portion of the system drive, that key is now recoverable by a hacker or other threat to my digital security.

The other possible explanation, Windows temporarily disabled Bitlocker for the duration of the update process.  This is an equally bad situation.  It took hours to fully encrypt the 930GB of usable space on my system drive, despite that fact that it’s four striped SSD’s.  How then, can the update process, in a matter of minutes, circumvent that encryption?

This whole post boils down to one thing.  What little faith I had in Bitlocker is gone.  At great expense and with much effort, I have switched to other solutions.  Thank you, Microsoft for costing my hundreds of dollars and many hours to fix your gaping security holes.

Leave a Reply

Your email address will not be published. Required fields are marked *