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.
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.
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.
In order to lockdown a Windows IoT device, the following considerations must be made.
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.
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.
To facilitate easy enablement of key secrutiy 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:
Windows 10 IoT Core works with several leading SoCs 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:
First, download the DeviceLockDown Script package, which contains all of the additional tools and scripts required for configuring and locking down devices
Note: The settings.xml file contained in this package will allow you to configure various options. Here, you can specify which keys to use for Secure Boot, specify a certificate for BitLocker data recovery as well as generate and specify signing keys for user-mode and kernel-mode applications and drivers. 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 to ensure a fully locked down device.
.\GenerateKeys.ps1 -OemName '<your oem name>' -outputPath '<output directory>'
New-IotDeviceGuardPackage -ConfigFileName .\settings.xmlNote: For testing on the Qualcomm DragonBoard 410c with pre-generated keys, you can use ‘QCDB_settings.xml’ file.
Once the packages are generated, they can be installed with the final image creation process. Visit the IoT Commercialization page to learn how to add packages to an IoT image. For testing and validation efforts, install the generated packages by doing the following:
applyupdate -stage c:\OemInstall\OEM.Custom.Cmd.cab
applyupdate -stage c:\OemInstall\OEM.Security.BitLocker.cab
applyupdate -stage c:\OemInstall\OEM.Security.SecureBoot.cab
applyupdate -stage c:\OemInstall\OEM.Security.DeviceGuard.cab
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. Since BitLocker requires Secure Boot provisioning to be completed and the feature to be active, reboot once more to activate BitLocker encryption.
Once the packages are generated and lockdown is activated, any binaries introduced into the image during development will need to be signed appropriately. If you’re using the Microsoft generated keys for development and testing purposes only, ensure that your user-mode binaries are signed with the key located in the downloaded package under .\Keys\OEM-UMCI.pfx. For kernel-mode signing, such as for drivers, you’ll need to specify your own signing keys.
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 BitLockerDRA.pfx certificate installed (included in the downloaded package). Install the PFX and then run the following commands from an administrative CMD prompt:
manage-bde -unlock v: -cert -cf BitLockerDRA.cer
manage-bde -unlock w: -cert -cf BitLockerDRA.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.