TPM AutoBoot is a new offering in DE v7.1 that strengthens the traditional AutoBoot functionality by using a TPM (if present) to protect the key.
Q: How is TPM AutoBoot different to traditional AutoBoot?
Traditional AutoBoot provides no security for the system.The key used to encrypt the disk is written in plaintext to the disk. TPM AutoBoot secures the key by encrypting it with the TPM; so it is no longer in plaintext.
Q: How does the TPM help secure the key?
The key can only be decrypted by the TPM if the system state has not changed. If the TPM believes the system state has changed, or a new TPM chip is present (e.g. in the case of a new motherboard) it will not decrypt the key. If it cannot decrypt the key, the AutoBoot functionality will fail and the pre-boot will be shown.
Q: With TPM AutoBoot will the system continue to automatically boot?
Yes, if the TPM believes everything is in order the user will not see the pre-boot environment and it will simply boot into Windows.
Q: So like traditional AutoBoot, the first place the user authenticates is to Windows?
Yes, that is correct.
Q: Are there any minimum requirements?
Yes, there are some minimum requirements:
The system must have a TPM 2.0 (All Connected Standby Systems will support TPM 2.0) if using 7.1.0, or TPM 1.2 or TPM 2.0 if using 7.1.1
The TPM owner key must be managed locally and not in Active Directory
The system must include the TPM UEFI protocol in the OEM’s UEFI implementation (again a requirement for Connected Standby)
Q: What are the policy settings for TPM AutoBoot?
You can find the policy options under the title of “User TPM for automatic booting:” and it has three options:
Never– Disk key is written in plaintext to the disk. This is the original AutoBoot functionality.
If Available – If the system has a usable TPM then the TPM will be used to encrypt the key. If no TPM is available, or an unusable TPM is present on the system then the key will be written in plaintext to the disk as per the original AutoBoot functionality.
Required– AutoBoot will only work if the system has a usable TPM. The DE Pre-Boot environment will be displayed on systems that do not have a TPM.
Q: Can TPM AutoBoot be used in conjunction with Reactive AutoBoot?
Yes they can both be used together.
Q: Can TPM Autoboot + Reactive AutoBoot be used in conjunction with the new Connected Standby support and hardening of systems against cold boot attacks functionality?
Q: When is the disk key released so that decryption of the disk can start?
The disk key is released by the pre-boot environment at the same point in the boot process that a user would authenticate. If the disk key is successfully decrypted by the TPM, then the system will boot to Windows. If the disk key is not successfully decrypted by the TPM, the user authentication screen will be shown.
Q: What happens if the TPM cannot decrypt the key?
It will display the pre-boot environment and ask the user to authenticate. If it is even in any doubt, it will not automatically boot the system and instead will display the pre-boot environment and wait for authentication.
Q: Ok so I’ve changed the motherboard, or the boot measurements changed, or the TPM is not happy in general then the User will see Pre-Boot; what do they do now?
If a user has gotten into this situation then they need to perform a Challenge / Response Recovery to get into Windows.
If valid Pre-Boot User credentials are known, the user can simply authenticate and boot into Windows. But as the User has been in this AutoBoot mode the chances of them knowing a valid user credential is low.
Q: And once they are into Windows do they need to do anything special?
No there is nothing more that the user, or a support person or Administrator need to do. The product will automatically re-encrypt the keyusing the new information and normal boot behavior will resume from that point.
Q: Do you do more than ask the TPM to encrypt the key?
Yes we also measure the boot path. Every time the system boots we hash some data about that into the TPM. This means that the TPM will only decrypt the key if the boot path has not been modified.
Q: Ok, but what doest that mean?
Once the disk is unlocked by TPM AutoBoot, it is not possible to boot to another boot path. If a different boot option is selected on start-up then the AutoBoot functionality will fail and the Pre-Boot will be displayed.
Q: How does it work?
The TPM provides a sealing mechanism whereby encrypted data can only be decrypted if the system is in a pre-defined state. On the system start up the firmware and all boot components are measured by the TPM. Measuring consists of extending a hash stored in a TPM register with the code about to be executed. Measurements are performed by firmware and cannot be bypassed. Effectively, the TPM will only allow the decryption of the key if the system is in exactly the same state as when it was sealed. Any change, however small, and it will fail.
Q: Ok, but what if Microsoft updates the Windows BootLoader during a Windows update?
It basically means that the boot measurements have changed. As a result it will mean that the TPM cannot decrypt the key and you’ll need to go through a recovery process in order to get the system to boot properly again.
Q: Wait, so users can perform a Windows update and then they’ll need to make a helpdesk call in order to boot into Windows?
Yes that can happen if the Windows update makes changes to the boot process, for example updating the Windows BootLoader.
Q: Isn’t the DE Pre-boot also in the boot path? What happens if I update that?
If an Administrator rolls out a new version of DE (hotfix,patch, new version, etc) and it updates the DE Pre-boot EFI Application then the boot measurements will also change.
Q: So just like the Windows update scenario, users will need to make a helpdesk call to get into their systems after I push a DE update?
Yes that is correct.
Q: Can you use the new smartphone functionality to help address this and not have helpdesk calls?
No. McAfee Endpoint Assistant can only be used for password reset use cases.