Preventing Windows Encryption Provisioning

Binary Boss

Preventing Windows Encryption Provisioning

Some may find it difficult, and annoying, to set Opal security on their Crucial SSD after a regular Windows 10 fresh installation.  If you use sedutil, or plan to, it's best to set that up BEFORE installing Windows, as Windows will take ownership of the SSD during its default installation procedure.

 

Once Windows 10 is installed, you will sometimes find yourself with error messages when trying to  initialize Opal security, quite commonly the error message of NOT_AUTHORIZED and thus, a TakeOwnership failure which prevents SED-specific software the ability to initialize and setup the drive with the end-user's specifications.  These errors are more prevalent when attempting to set up Opal security on a Windows device using a Linux partition or a small Linux distro as opposed to a SED software's Windows executable.  Even so, I have had software like Wave Security (junk software, anyways) fail Opal security setup within Windows regardless.  This is because, as mentioned above, Windows will take ownership of the drive by default by provisioning Opal's C_PIN_SID and C_PIN_MSID template columns using a RNG (random-number generated) PIN.  This is similar to how Windows 8 and 10 now take ownership of a device's TPM by creating, and then immediately discarding, a TPM password automatically without allowing the end-user to set his/her own.  However, unlike SEDs, the TPM ownership can be changed to allow end-user password creation easily via Group Policy or a simple numerical registry change.

 

In my opinion, Microsoft does not need to take ownership of anything relating to security on a user's device and the fact that Microsoft is starting to take ownership of hardware automatically, and without any setup input by the end-user, in my opinion, negates complete security of a device.  Even though Microsoft will tout that it's "more secure" for the software to do it, I'm of the belief it's none of Microsoft's business nor duty to set up hardware security and should always be under control of the end user.  Moreover, I understand they do this by default because they want everyone who has a self-encrypting drive to use the eDrive feature which relies on BitLocker to manage.  That said, I'm not particularly privy to eDrive nor am I to Microsoft thinking it's their job to take ownership of any piece of hardware I own.  Conversely, I also understand some like eDrive because it's free and basically sets itself up without issue, so long as your motherboard meets all of the requirements including UEFI v2.31+ and Secure Boot.

 

Though I personally use WinMagic Enterprise to deploy SED provisioning and PBAs to connected devices, sedutil is a great open-source utility for pure Opal security control.  With sedutil, it's best to set your boot device up prior to installing Windows 10 (or 8), when the SSD is factory fresh, or after doing a PSID revert.  This in itself will prevent Windows from being able to provision the device itself.  One can do a PSID revert, secure erase and sedutil setup from a single bootable USB stick with Parted Magic on it by simply copying the Linux sedutil executable and PBA to the USB stick's root directory.  Once you do that, you can boot into Parted Magic, use sedutil to do a PSID revert, use Parted Magic to do a secure erase of the drive, and then setup the fresh drive with sedutil and install the PBA using Parted Magic's terminal, and all from a single bootable USB stick.

 

One can also use a custom unattend.xml or autounattend.xml to prevent provisioning during Windows installation:

 

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
    <settings pass="windowsPE">
        <component name="Microsoft-Windows-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <ComplianceCheck>
                <DisplayReport>Never</DisplayReport>
            </ComplianceCheck>
            <DiskConfiguration>
           <DisableEncryptedDiskProvisioning>true</DisableEncryptedDiskProvisioning>
                <WillShowUI>Never</WillShowUI>
                <Disk wcm:action="add">
                    <CreatePartitions>
                        <CreatePartition wcm:action="add">
                            <Order>1</Order>
                            <Size>100</Size>
                            <Type>EFI</Type>
                        </CreatePartition>
                        <CreatePartition wcm:action="add">
                            <Order>2</Order>
                            <Size>128</Size>
                            <Type>MSR</Type>
                        </CreatePartition>
                        <CreatePartition wcm:action="add">
                            <Order>3</Order>
                            <Size>450</Size>
                            <Type>Primary</Type>
                        </CreatePartition>
                        <CreatePartition wcm:action="add">
                            <Order>4</Order>
                            <Extend>true</Extend>
                            <Type>Primary</Type>
                        </CreatePartition>
                    </CreatePartitions>
                    <ModifyPartitions>
                        <ModifyPartition wcm:action="add">
                            <Format>FAT32</Format>
                            <Label>System</Label>
                            <Order>1</Order>
                            <PartitionID>1</PartitionID>
                        </ModifyPartition>
                        <ModifyPartition wcm:action="add">
                            <Order>2</Order>
                            <PartitionID>2</PartitionID>
                        </ModifyPartition>
                        <ModifyPartition wcm:action="add">
                            <Format>NTFS</Format>
                            <Label>WinRE</Label>
                            <Order>3</Order>
                            <PartitionID>3</PartitionID>
                            <TypeID>de94bba4-06d1-4d40-a16a-bfd50179d6ac</TypeID>
                        </ModifyPartition>
                        <ModifyPartition wcm:action="add">
                            <Format>NTFS</Format>
                            <Label>WinOS</Label>
                            <Letter>C</Letter>
                            <Order>4</Order>
                            <PartitionID>4</PartitionID>
                        </ModifyPartition>
                    </ModifyPartitions>
                    <DiskID>0</DiskID>
                    <WillWipeDisk>true</WillWipeDisk>
                </Disk>
            </DiskConfiguration>
            <ImageInstall>
                <OSImage>
                    <InstallTo>
                        <DiskID>0</DiskID>
                        <PartitionID>4</PartitionID>
                    </InstallTo>
                    <InstallToAvailablePartition>false</InstallToAvailablePartition>
                    <WillShowUI>OnError</WillShowUI>
                </OSImage>
            </ImageInstall>
        </component>
</settings>
</unattend>

At the WindowsPE settings pass, you can set disable <EncryptedDiskProvisioning>, which by default, is set to false.  This will prevent Windows from automatically provisioning your Crucial SSD (or any SED), which will give you the ability to decide how you want to set your SED up after Windows is installed.  Also note how the EFI partition is first as opposed to the Windows Recovery partition.  This aids in slightly quicker chain-loading of the OS by a PBA since it's able to locate the EFI boot manager in the first partition  Though it's not required to have the EFI partition first, and Windows' default setup puts the Recovery partition first, the proper way to set up a UEFI/GPT hard drive is by setting the EFI partition first.  The reason it's not done this way during default installations is because Windows uses the MBR-style partition setup automatically during installation, then adds the EFI System and MSR partitions once the GPT partitioning format is recognized.  Similarly, this is why Windows installation does not create the MSR partition at the proper size of 128 megabytes.  This in no way affects the Windows Recovery partition from working properly, as the REagentC.exe will auto-detect the partition location of Windows Recovery and set its location for Windows.

 

Now comes the <TCGSecurityActivationDisabled> setting.  This setting either enables (default) or disables, using Group Policy, the provisionioning of current unprovisioned eDrives.  Though this pass is not mandatory for a single SED installation for a boot drive, since setting <DisableEncryptedDiskProvisioning> to true already prevents the provisioning of the boot drive, it will prevent BitLocker from attempting to make any changes, via Windows' eDrive feature, on additional SEDs set up after a Windows installation, which is beneficial if you change your boot device by doing a backup and restore, dual-boot or simply add a 2nd SED as a non-boot drive.  Moreover, this setting in itself will also prevent Windows from provisioning a boot device, like <DisableEncryptedDiskProvisioning> does, if set to the WindowsPE settings pass for setup.  If this pass is used to prevent TCG Security Activation, it can easily be enabled using gpedit.msc and going to Local Computer Policy > Computer Configuration > System > Enhanced Storage Access.  I personally set both <TCGSecurityActivationDisabled> and <DisableEncryptedDiskProvisioning> to true in my autounattend.xml to prevent any provisioning of any sort by Windows.

 

So what's the difference between an unattend.xml and autounattend.xml?  Well an unattend.xml is fairly basic because it's meant as a generic setup script for all client machines being deployed an install.wim using a Windows Deployment Server over PXE at boot, or it can be entirely custom - like an autounattend.xml - used after a SysPrep on a specific device.  An Autounattend.xml is used for custom Windows installations generally designed for a single specific PC/laptop.  Upon the start of a Windows OS setup, Windows setup first searches for an autounattend.xml which needs to be put in the root directory of the installation media.  If found, Windows installs itself entirely based on the autounattend.xml's settings.  If it's not found, Windows installs with all of it's default settings.

 

If anyone wants an autounattend.xml that disables all encryption provisioning - and much of Windows' behind-the-scenes data gathering - I can upload a fairly universal one for both UEFI and MBR that you can edit to your liking.