This guide will demonstrate how to enable the BitLocker startup PIN for pre-boot authentication on Windows 10 with Microsoft Intune. I will walk through how to accomplish this in a nearly fully automatic way. Let’s start with some facts around BitLocker to understand the technology more precisely. In fact, I think a pre-boot startup PIN is not always necessary. To explain my point of view a bit further, we need to have a more detailed look at the encryption key material handling of BitLocker. The key material security is based mainly on the trusted computing platform concepts. Easy spoken this is the protection of the key material with a TPM (aka TPM only scenario) or with a TPM and pre-boot authentication startup PIN (aka TPM+PIN scenario).

How does BitLocker key protection work?

First, we need to understand the general procedure how BitLocker will get access to the encryption key. The Trusted Computing Group introduced the trusted computing platform. In short this board defined measures for trusted computing. From interest here is the Endorsement Key and the Sealed Storage concept. The underlying idea is to bind private information to the platform configuration to generate the Sealed Storage. The platform configuration includes hardware and software which is being used. The concept of the endorsement key is simple. It is a generated key during manufacturing time on a chip. The key cannot be changed and will never leave the chip. In general these both concepts are widely known by people in form of the Trusted Platform Module (TPM). The TPM has an endorsement key and can only be accessed from unmodified and untampered hardware and software configuration.

In a widely used standard configuration of Microsoft Windows 10, BitLocker is used with a TPM only key protection to protect BitLocker key material. As already explained Windows uses so called platform configuration registers (PCRs) to measure the state of hardware and software configuration (compare article TPM platform validation profile) and releases the key material in an unmodified and untampered configuration is available. We can easily say the integrity of the configuration is proven and therefore the key material is released for BitLocker decryption usage. This leads to a situation, that an attacker needs the complete hardware and can’t modify the platform configuration otherwise the key material is not released. Even in case the complete hardware is stolen, the device might reach the platform configuration state to boot up, but only until the normal Windows logon. At this point in time the attacker needs to overcome the Windows logon which is protected from brute force attacks by slowing down logons retries, in case of unsuccessful logons. In fact, this is a pretty safe configuration to run Windows 10 with BitLocker protection.

No downside at all?

Not really, there are always bypasses in various IT systems and this is true for this BitLocker configuration as well. The fact, that in case of an unmodified platform configuration, the key material is released and put into memory for cryptographic operations can be used for various attacks.

Attacks by accessing the memory in various ways can finally give you access to the BitLocker key material. For example, Direct Memory Access (DMA) ports and Plug and Play mechanisms are used to gain access to memory during Windows run time (aka side channel attacks). But also, the fact that cooled down transistors are not losing their programmatic state immediately, can give the attacker enough time to dump the memory and get BitLocker key material. The latest attack was done by using electric engineering tools like oscilloscope and logic analyzers to read the signals directly from the wires/bus (aka TPM sniffing). For interested readers I recommend reading – Extracting BitLocker Keys from a TPM.

Do I need to worry now?

I don’t think so! Security is always a cat and mouse game, attackers getting better and defenders build better protections. Attacks against BitLocker key material and the platform exist, and new ones will likely be found in future. In the meantime, you must think about against who you want to protect your data. If you target nation state hackers, I don’t think that all this is enough as data will be exfiltrated in some way anyway. If they can’t target easily your device, they will have a complete suite case full of options to accomplish their goals and finally get your data.

Security is about building defense lines and this involves different areas and different technology to finally operate a secure enough but still usable system. I will explain this by using an example. We can choose our hardware wisely to eliminate some side channel attacks in advance. In fact, the Windows 10 hardware certification program makes sure some of these attacks are eliminated by the design of modern hardware. Second, we build several layers of protection around our data. This includes full disk encryption (FDE), state of the art security configurations in Windows, anti-malware protections which can respond immediately in case of threats and malicious behavior, and entity security by encrypting important data individually. The overall security posture of your device (and of course the used services, but these are not in scope of this article) define a successful defense strategy. A well-designed workplace solution and the services around it, with the right principles, will give the average and skilled attacker a hard time as the defense layers are able to counter in all stages of an attack.

Additional countermeasures?

The BitLocker standard configuration in combination with other security measures will balance convenience in usability and security (please also read the Microsoft article BitLocker Countermeasures). If you think your protection level is not enough and a good overall solution can’t be accomplished in your setup, and you want to bolster your security by introducing pre-boot authentication with an additional PIN, the following guide is right for you. The additional PIN requirement during startup adds a kind of control gate to the TPM operation. The new procedure with a startup PIN is as follows. The TPM will not release any key material since the platform integrity is verified and in addition the startup PIN must be entered. Without successful PIN entry during early startup phase, the TPM will not release the key material and therefore no key material will be loaded into memory, which renders most cold boot attacks useless. This is an example how a BitLocker pre-boot authentication startup PIN looks like:

Challenges while enabling TPM+PIN with Microsoft Intune on Windows 10

In my guide Enabling BitLocker on non-HSTI devices with Intune I’m essentially describing how to implement BitLocker encryption on Windows 10 devices with Microsoft Intune for all your devices, even the ones not holding special hardware certifications (HSTI). The guide shows the Microsoft Intune configuration profiles and how to achieve this in a automatic and silent way. The result is an encrypted OS disk without any interaction with the user.

And here lies exactly the challenge when we talk about a user definable PIN. Sure, we could fall back to the Intune capabilities to trigger the BitLocker encryption wizard and not silently encrypt the OS disk. To say it in different words, enabling silent BitLocker encryption will only work with TPM only and not if you enforce a PIN. As soon as you require a PIN you must rely on the BitLocker encryption wizard and the user you must click through it.

The next challenge is that we have to provide a way to do all this as a standard user. Standard user permissions are common and a good security practice. The manual way of enabling BitLocker needs administrative permissions, can be seen on the small UAC shield icon in front of the links:

The solution?

We need a way to ask the user for the PIN and encrypt the OS disk as soon as possible. The idea is to silently encrypt the disk and ask for the PIN later in the process. This way we would have a secured device right after deployment and the user must set his individual PIN afterwards. I follow the same configuration as in my last BitLocker article Enabling BitLocker on non-HSTI devices with Intune and allow “additional authentication at startup” > Allow TPM and Allow startup PIN with TPM. It is not needed to configure the “OS drive Recovery” options as the silent encryption will always backup the key to AAD. The settings below are enough to have everything in place what’s needed:

The challenge with this approach is, that we have to ask for the PIN in user context with standard user permissions and the TPM+PIN key protector must be set in system context.

I’ve created an Intune Windows app (Win32) which has a PowerShell script logic to display a PIN entry dialog and to set the BitLocker key protector TPM+PIN.

SetBitLockerPin – Intune Win32 app files

https://github.com/okieselbach/Intune/tree/master/Win32/SetBitLockerPin

The .intunewin package SetBitLockerPin can be created easily with the Intune Content Preparation Tool and the following command:

.\IntuneWinAppUtil -c .\SetBitLockerPin -s SetBitLockerPin.ps1 -o .\ -q

This way we can target the app as available to the device or user and the user is able to set the PIN as a standard user. We target the Windows app in system context for install. To escape from the system context, I utilize the ServiceUI.exe from the Microsoft Deployment Toolkit (MDT) to present the PIN dialog provided by a small PowerShell script.

The dialog will find the configured minimum PIN length from Microsoft Intune and looks very similar to the original Microsoft Windows BitLocker change PIN dialog. I thought it helps when keeping the same style in regards of creating user adoption material later. The PIN creation dialog can be run with standard user permission as it is triggered from the Company Portal. This is how it looks like:

After entering the new startup PIN, the entry is passed back to the system context by setting the exit code of the PowerShell PIN dialog to the entered PIN. The exit code can easily received by the calling script and used to configure the new TPM+PIN key protector for BitLocker. This is an easy approach to transfer this data and the PIN itself is relatively short lived in memory available. Basic input validation is provided like PIN length and correctly re-entered PIN:

To make sure the BitLocker PIN creation dialog can only be used once I’ve created a detection logic script for the Intune Windows App (.intunewin). This small script DetectBitLockerPin.ps1 checks if the TPM+PIN protector is already set:

Write-Output $(Get-BitLockerVolume -MountPoint $env:SystemDrive).KeyProtector | Where { $_.KeyProtectorType -eq 'TpmPin' }

Use the DetectBitLockerPin.ps1 as a custom detection script in Intune and use the following command for install/uninstall (I don’t have an uninstall but it is a mandatory field)

powershell -ex bypass -file SetBitLockerPin.ps1

Your app Set BitLocker startup PIN app should look like this. The image is also provided in the GitHub:

For further demonstration the very similar Windows Change BitLocker PIN dialog below. We can see it can be run without administrative permission as well:

What about reporting on the Key Protector usage?

As we have no initial PIN creation enforcement here, I thought it is good to have a way, to lead your users who need additional pre-boot authentication, to set the PIN. I’ve created a small PowerShell script which will run periodically (registers itself as scheduled task) and upload the used BitLocker key protector type information to an Azure Table Storage.

The creation of the Azure Table Storage is quite simple. For a more detailed explanation have a look at my fellow Roger Zander’s blog post BitLocker management with Azure Table Storage

The upload script for the BitLocker key protector type information

https://github.com/okieselbach/Intune/blob/master/ScheduleAndUploadBitLockerKeyProtectorType.ps1

You have to fill in the Azure storage account name and the generated SAS signature for the table storage (compare Rogers post if unclear):

Upload it to Intune as a PowerShell script and assign it to your devices you like to protect:

The script will create a local script on the device and a scheduled task to run it periodically. Remember if you don’t like the script to run on your devices anymore, you have to create a uninstall script which deletes the script from C:\ProgramData\CustomScripts\UploadBitLockerKeyProtectorType.ps1 and the scheduled task UploadBitLockerKeyProtectorType.

After Azure table storage creation and PowerShell script deployment, we have an easy reporting solution if the targeted device group has set the PIN accordingly to the organizational requirement.

The table storage can be viewed and queried directly in the Azure Portal:

Or you connect the table storage directly with Microsoft Excel and analyze your data there:

Follow the wizard and provide the Azure storage account and access key and import the table data:

What about user notifications?

To make the life easier for the end users or to simply remind them to set the PIN, we can build a customized email and provide a direct link to the app in the company portal. This way the user can be targeted directly and asked to set the PIN.

First, we need to find the direct link to the app for the Company Portal. This is actually very easy but not obvious. Just use the Share button on the app in the company portal and send the information to you by email or to a OneNote:

After this you will have a link with the application guid in the form:

companyportal:ApplicationId=<yourguid>

With this link you can craft an email to direct your users to the app in Company Portal. Remember this special link can only be used in an email app like Outlook who displays this as an actual link. Outlook on the web will not show it as a link:

Summary

I’ve demonstrated a way to securely deploy Windows 10 with encryption and enabled easy handling to add the PIN as additional pre-boot authentication for BitLocker. Although this is a solution to set a startup PIN with Intune, I really recommend to think twice as a PIN might not bring additional protection if the users are bugged by yet another PIN for the system. If they set them to the same as Windows Hello for Business or even worse they write them down on a post-it and store them along with the device you have no security improvement. This would lead to a situation that an attacker has quite an easy situation, just steal the device and use the PIN written on the post-it for pre-boot authentication startup PIN and for Windows Hello for Business. This situation would have lowered dramatically your security posture which was surely not intended. A pre-boot startup PIN can protect but should be set on systems where users are understanding the risk and actively supporting this security measure. I think for most user’s security must be relatively simple, otherwise they won’t support you or even do things which will lower your security.

Thanks for reading and always think twice about security settings how they will bring value or maybe harm your environment.