Enabling Secure Boot, BitLocker, and Device Guard on Windows 10 IoT Core
With the release of Creators Update, Windows 10 IoT Core improves its security feature offerings to include UEFI Secure Boot, BitLocker Device Encryption and Device Guard. These will allow device builders in creating fully locked down Windows IoT devices that are resilient to many different types of attacks. Together, these features provide the optimal protection that ensures that a platform will launch in a defined way, while locking out unknown binaries and protecting user data through the use of device encryption.
UEFI Secure Boot is the first policy enforcement point, located in UEFI. It restricts the system to only allow execution of binaries signed by a specified authority. This feature prevents unknown code from being executed on the platform and potentially weakening the security posture of it.
BitLocker Device Encryption
Windows 10 IoT Core also implements a lightweight version of BitLocker Device Encryption, protecting IoT devices against offline attacks. This capability has a strong dependency on the presence of a TPM on the platform, including the necessary preOS protocol in UEFI that conducts the necessary measurements. These preOS measurements ensure that the OS later has a definitive record of how the OS was launched; however, it does not enforce any execution restrictions.
BitLocker functionality on Windows 10 IoT Core allows for automatic encryption of NTFS-based OS volume while binding all available NTFS data volumes to it. For this, it’s necessary to ensure that the EFIESP volume GUID is set to C12A7328-F81F-11D2-BA4B-00A0C93EC93B.
Device Guard on Windows IoT Core
Most IoT devices are built as fixed-function devices. This implies that device builders know exactly which firmware, operating system, drivers and applications should be running on a given device. In turn, this information can be used to fully lockdown an IoT device by only allowing execution of known and trusted code. Device Guard on Windows 10 IoT Core can help protect IoT devices by ensuring that unknown or untrusted executable code cannot be run on locked-down devices.
Locking-down IoT Devices
In order to lockdown a Windows IoT device, the following considerations must be made...
UEFI Platform & Secure Boot
In order to leverage Device Guard capabilities, it is necessary to ensure that the boot binaries and UEFI firmware are signed and cannot be tampered with. UEFI Secure Boot is the first policy enforcement point, located in UEFI. It prevents tampering by restricting the system to only allow execution of boot binaries signed by a specified authority. Additional details on Secure Boot, along with key creation and management guidance, is available here.
Configurable Code Integrity (CCI)
Code Integrity (CI) improves the security of the operating system by validating the integrity of a driver or application each time it is loaded into memory. CI contains two main components - Kernel Mode Code Integrity (KMCI) and User Mode Code Integrity (UMCI).
Configurable Code Integrity (CCI) is a feature in Windows 10 that allows device builders to lockdown a device and only allow it to run and execute code that is signed and trusted. To do so, device builders can create a code integrity policy on a 'golden' device (final release version of hardware and software) and then secure and apply this policy on all devices on the factory floor.
To learn more about deploying code integrity policies, auditing and enforcement, check out the latest technet documentation here.
Turnkey Security on IoT Core
To facilitate easy enablement of key security features on IoT Core devices, Microsoft is providing a turnkey 'Security Package' that allows device builders to build fully locked down IoT devices. This package will help with:
- Provisioning Secure Boot keys and enabling the feature on supported IoT platforms
- Setup and configuration of device encryption using BitLocker
- Initiating device lockdown to only allow execution of signed applications and drivers
- A PC running Windows 10 Enterprise
- Windows 10 SDK - Required for Certificate Generation
- Windows 10 ADK - Required for CAB generation
- Reference platform - release hardware with shipping firmware, OS, drivers and applications will be required for final lockdown
Development IoT Devices
Windows 10 IoT Core works with various silicons that are utilized in hundreds of devices. Of the suggested IoT development devices, the following provide firmware TPM functionality out of the box, along with Secure Boot, Measured Boot, BitLocker and Device Guard capabilities:
Qualcomm DragonBoard 410c
In order to enable Secure Boot, it may be necessary to provision RPMB. Once the eMMC has been flashed with Windows 10 IoT Core (as per instructions here, press [Power] + [Vol+] + [Vol-] simultaneously on the device when powering up and select "Provision RPMB" from the BDS menu. Please note that this is an irreversible step.
For Intel's MinnowBoard Max, firmware version must be 0.82 or higher (get the latest firmware). To enable TPM capabilities, power up board with a keyboard & display attached and press F2 to enter UEFI setup. Go to Device Manager -> System Setup -> Security Configuration -> PTT and set it to <Enable>. Press F10 to save changes and proceed with a reboot of the platform.
Raspberry Pi 2 nor 3 do not support TPM and so we cannot configure Lockdown scenarios.
Generate Lockdown Packages
Download the DeviceLockDown Script package, which contains all of the additional tools and scripts required for configuring and locking down devices
Start an Administrative PowerShell (PS) console on your Windows 10 PC and navigate to the location of the downloaded script.
Mount your reference hardware platform (running the unlocked image) to your PC via network share using
net use \\a.b.c.d\c$ /user:username password
Generate keys for your device using
.\GenerateKeys.ps1 -OemName '<your oem name>' -outputPath '<output directory>'
- The keys and certificates are generated in the specified output folder with appropriate suffix.
- Secure your generated keys as the device will trust binaries signed with these keys only after lockdown.
- You may skip this step and use the pre-generated keys for testing only
Install the generated .pfx certificates by clicking on the pfx files directly or using the below powershell command
Import-PfxCertificate -FilePath $pfxfile -CertStoreLocation Cert:\CurrentUser\My
- General section : Specify the package directories
- Tools section : Set the path for the tools
(e.g. <Windows10KitsRoot>C:\Program Files (x86)\Windows Kits\10\</Windows10KitsRoot>)
- SDK version installed on your machine is under
C:\Program Files (x86)\Windows Kits\10\
- SDK version installed on your machine is under
- SecureBoot section : Specify which keys to use for secure boot (PK and SB keys)
- BitLocker section : Specify a certificate for Bitlocker data recovery (DRA key)
- SIPolicy section : Specify certs that should be trusted
- ScanPath : Path of the device for scanning binaries ,
- Update : Signer of the SIPolicy (PAUTH keys)
- User : User mode certificates (UMCI keys)
- Kernel : Kernel mode certificates (KMCI keys)
- ScanPath : Path of the device for scanning binaries ,
- Packaging : Specify the settings for the package generation
In order to assist with testing during the initial development cycle, Microsoft has provided pre-generated keys and certificates where appropriate. This implies that Microsoft Test, Development and Pre-Release binaries are considered trusted. During final product creation and image generation, be sure to remove these certifcates and use your own keys to ensure a fully locked down device.
The apps from Microsoft App Store can be allowed by including the Microsoft Marketplace PCA 2011 certificate in the configuration settings.xml:
xml <Cert>db\MicrosoftMarketPlacePCA2011.cer</Cert> <!-- Microsoft MarketPlace PCA 2011 -->
6.Execute the following commands to generate required packages:
```powershell Import-Module .\IoTTurnkeySecurity.psm1 # Generate the security packages for retail New-IoTTurnkeySecurity -ConfigFileName .\settings.xml (or) # Generate the security packages for test New-IoTTurnkeySecurity -ConfigFileName .\settings.xml -Test ```
Test Lockdown packages
You can test the generated packages by manually installing them on a unlocked device by the following steps
Flash the device with the unlocked image (image used for scanning in earlier step).
Copy the following .cab files to the device under a directory e.g.
Initiate staging of the generated packages by issueing the following commands
applyupdate -stage c:\OemInstall\OEM.Custom.Cmd.cab
If you are using custom image, then you will have to skip this file and manually edit the
c:\windows\system32\oemcustomization.cmdwith the contents available in
applyupdate -stage c:\OemInstall\OEM.Security.BitLocker.cab applyupdate -stage c:\OemInstall\OEM.Security.SecureBoot.cab applyupdate -stage c:\OemInstall\OEM.Security.DeviceGuard.cab
Finally, commit the packages via
The device will reboot into update OS (showing gears) to install the packages and will reboot again to main OS. Once the device reboots back into MainOS, Secure Boot will be enabled and SIPolicy should be engaged.
Reboot the device again to activate the Bitlocker encryption.
Test the security features
SecureBoot : try
bcdedit /debug on, you will get an error stating that the value is protected by secure boot policy.
BitLocker : To validate that bitlocker encryption has been completed, run
sectask.exe -waitenableforcompletion 1
If it returns 0, that means all drives on the system have been bitlockered successfully. Any other return code is failure.
=> Wait until BitLocker encryption is completed on all NTFS volumes.
=> Timeout in seconds to wait for enable to complete.
=> If timeout not specified, it will wait indefinitely or until enable completes.
0 : BitLocker encryption successfully completed, volume is Bitlocker encrypted.
ERROR_TIMEOUT: Timeout waiting for completion, encryption still in progress.
Failure/Other code: returns the failure error code returned by the bit locker service.
DeviceGuard : Run any unsigned binary or a binary signed with certificate not in the SIPolicy list and confirm that it fails to run.
Generate Lockdown image
After validating that the lockdown packages are working as per the settings defined earlier, you can then include these packages into the image by following the below given steps. Read IoT manufacturing guide for custom image creation instructions.
In the workspace directory, update the following files from the generated output directory above
- SecureBoot :
Copy ..\Output\SecureBoot\*.bin ..\Workspace\Common\Packages\Security.SecureBoot
- BitLocker :
Copy ..\Output\Bitlocker\*.* ..\Workspace\Common\Packages\Security.Bitlocker
- DeviceGuard :
Copy ..\Output\DeviceGuard\*.* ..\Workspace\Common\Packages\Security.DeviceGuard
- SecureBoot :
Add RetailOEMInput.xml and TestOEMInput.xml under the ProductName directory with lockdown package feature ID
buildpkg all(this generates new lockdown packages based on above policy files)
buildimage ProductName test(or)retail(this generates new Flash.ffu)
Flash the device with this new Flash.ffu and validate the security features.
See SecureSample as an example of a lockdown dragon board configuration.
Alternatively, you can generate the security packages in the IoTCore Shell itself, see adding security packages for the details.
Developing with CodeSigning Enforcement Enabled
Once the packages are generated and lockdown is activated, any binaries introduced into the image during development will need to be signed appropriately. Ensure that your user-mode binaries are signed with the key .\Keys\ ***-UMCI.pfx. For kernel-mode signing, such as for drivers, you’ll need to specify your own signing keys and make sure that they are also included in the SIPolicy above.
Unlocking Encrypted Drives
During development and testing, when attempting to read contents from an encrypted device offline (e.g. SD card for MinnowBoardMax or DragonBoard's eMMC through USB mass storage mode), 'diskpart' may be used to assign a drive letter to MainOS and Data volume (let's assume v: for MainOS and w: for Data). The volumes will appear locked and need to be manually unlocked. This can be done on any machine that has the OEM-DRA.pfx certificate installed (included in the DeviceLockDown sample). Install the PFX and then run the following commands from an administrative CMD prompt:
manage-bde -unlock v: -cert -cf OEM-DRA.cer
manage-bde -unlock w: -cert -cf OEM-DRA.cer
If the contents need to be frequently accessed offline, BitLocker autounlock can be set up for the volumes after the initial unlock using the following commands:
manage-bde -autounlock v: -enable
manage-bde -autounlock w: -enable
Should there arise a need to temporarily disable BitLocker, initate a remote PowerShell session with your IoT device and run the following command:
Note: Device encryption will be re-enabled on subsequent device boot unless the scheduled encryption task is disabled.
Disabling Device Guard
The turnkey security script generates SIPolicyOn.p7b and SIPolicyOff.p7b files in the folder. The wm.xml packages the SIPolicyOn.p7b and places it on the system as SIPolicy.p7b.
C:\src\iot-adk-addonkit.db410c\TurnkeySecurity\QCDB\Output\DeviceGuard\Security.DeviceGuard.wm.xml … <files> <file destinationDir="$(runtime.bootDrive)\efi\microsoft\boot" source="SIPolicyOn.p7b" name="SIPolicy.p7b" /> </files> ..
If you create a package that takes the SIPolicyOff.p7b file and places it as a SIPolicy.p7b, it will apply this package and the Device Guard will be turned off.
Send feedback about: