I am curious whether someone in this community knows the answer to the following question.

We currently have a setup with BitLocker and TPM which only allows a system to boot OS's (and software) which is signed with Windows keys.
The problem is, is that this setup allows the possibility to boot from non-Windows OS's, like Fedora, and other custom software that is signed with Windows keys.

This introduces the problem of cold-boot attacks (https://www.ethicalhacker.net/features/root/using-cold-boot-attacks-forensic-techniques-penetration-tests), where a system boots a tiny boot loader, after which the contents of the RAM are written to external storage.
Keys could possibly be extracted from the image.

Is a setup possible where a system only boots from our specific Windows, and none other?
I know the implementation of a pincode before booting Windows could remedy this issue, but the administration of all the pincodes is not really an option at this moment.

If you need more information, please let me know.

Rinke, I am sure I fully understand your problem. But one thing: why would "the administration of all the pincodes" not really be an option at this moment? You don't need to know those, the user has to know those.

Furthermore: if you set the bios to only boot from your hard drive, how would an attacker proceed to boot his Linux? He would need to enter the bios and change the boot order to his Linux. Now what would happen then? He would try and start windows first, to get the key into RAM again. Would that happen? NO! Because the TPM chip will not let the system boot after the BIOS was changed. It will request the recovery key and that's why your attack is not even possible.

It would only be possible if you had Linux already installed on a second partition with a boot loader to choose between both before the attack takes place.

Rinke, I am sure I fully understand your problem. But one thing: why would "the administration of all the pincodes" not really be an option at this moment? You don't need to know those, the user has to know those.

Furthermore: if you set the bios to only boot from your hard drive, how would an attacker proceed to boot his Linux? He would need to enter the bios and change the boot order to his Linux. Now what would happen then? He would try and start windows first, to get the key into RAM again. Would that happen? NO! Because the TPM chip will not let the system boot after the BIOS was changed. It will request the recovery key and that's why your attack is not even possible.

It would only be possible if you had Linux already installed on a second partition with a boot loader to choose between both before the attack takes place.

• Proposed as answer by Shaon ShanMicrosoft contingent staff 22 hours 6 minutes ago

Rinke, I am sure I fully understand your problem. But one thing: why would "the administration of all the pincodes" not really be an option at this moment? You don't need to know those, the user has to know those.

Furthermore: if you set the bios to only boot from your hard drive, how would an attacker proceed to boot his Linux? He would need to enter the bios and change the boot order to his Linux. Now what would happen then? He would try and start windows first, to get the key into RAM again. Would that happen? NO! Because the TPM chip will not let the system boot after the BIOS was changed. It will request the recovery key and that's why your attack is not even possible.

It would only be possible if you had Linux already installed on a second partition with a boot loader to choose between both before the attack takes place.

• Proposed as answer by Shaon ShanMicrosoft contingent staff Monday, May 04, 2015 9:15 AM
• Marked as answer by Bruce WoodingModerator Wednesday, May 13, 2015 12:27 AM

Hey Ronald,

First of all, thanks for you answer. Sorry for the late reply. I had expected to receive an e-mail when a reply was given, but assumed wrong.

First, we do need to know all the pincodes. If one of our users forgets his pincode, and is unable to work for a day, that is everybody's problem. So the administration is necessary, but quite tedious. Hence we are pursuing a different solution.

Second, your solution made me view the problem from a different angle. It is possible to select a different device to boot from right now, but this is made possible by the firmware of the laptop, and not so much by Windows. So we have to disable that function. I think this is enough for us.

This however, is not a solution to the cold boot attack. After shutting down a system, the RAM can still be cooled and inserted into a different device. The key can be extracted from RAM. Then, inserting a second hard disk with Fedora installed as first HDD in the laptop, and mounting the current HDD with Windows as second drive in Fedora, the disk can be decrypted using the key. This, I assume, can only be mitigated by implementing the pincode before booting Windows.

So the question still remains: how can we make it impossible to boot from (a signed) Fedora?

• Edited by rinke2015 18 hours 40 minutes ago

Hi and welcome back.

You didn't understand, yet. If we implement a PIN and the user forgets it, he can phone us and we provide the recovery key and he's back in. The key will be saved to active directory automatically.

As for cold boot attacks: if the laptop is stolen when turned on or in standby - surely, taking out the RAM, cooling it and reading the key is possible. So make your people shutdown or hibernate their devices, disallow standby. Tell them they should not leave their laptop on for hours when unattended and/or implement a GPO to put idle laptops to hibernation after some hours. This is the best practice.

You could also pull a rather drastic measure: only buy mobile devices with fixed RAM (those exist).

Hey Ronald,

First of all, thanks for you answer. Sorry for the late reply. I had expected to receive an e-mail when a reply was given, but assumed wrong.

First, we do need to know all the pincodes. If one of our users forgets his pincode, and is unable to work for a day, that is everybody's problem. So the administration is necessary, but quite tedious. Hence we are pursuing a different solution.

Second, your solution made me view the problem from a different angle. It is possible to select a different device to boot from right now, but this is made possible by the firmware of the laptop, and not so much by Windows. So we have to disable that function. I think this is enough for us.

This however, is not a solution to the cold boot attack. After shutting down a system, the RAM can still be cooled and inserted into a different device. The key can be extracted from RAM. Then, inserting a second hard disk with Fedora installed as first HDD in the laptop, and mounting the current HDD with Windows as second drive in Fedora, the disk can be decrypted using the key. This, I assume, can only be mitigated by implementing the pincode before booting Windows.

So the question still remains: how can we make it impossible to boot from (a signed) Fedora?

• Edited by rinke2015 Wednesday, May 20, 2015 12:44 PM