Encrypt Drive Windows 10

[Najee Laboy]

Ifinstead of fully encrypting the hard drive or encrypting the partition on which Windows is installed, I just encrypt a partition where I store my sensitive information, will it increase the chances of my data getting stolen(in comparison to the other alternatives) if my device gets stolen?

If you have a recovery partition in your disk, this one should not be encrypted, but you should encrypt all windows partition be them system or data if you want to be super safe, or only the sensitive data partition if you can accept that an attacker could find traces in temp or swap files.

The initial encryption time does not really matter IMHO. It happens only once. But 10 hours for 150 Gb seems rather weird. SATA disk io throughput should allow around 100Mb/s, so encrypting 150Gb should not exceed a couple of hours.

Encrypt the whole disk. The overhead is negligible, and you don't have to worry about someone stealing your computer and having all your data. And if you have to send your computer to repairs, you don't have to worry about stolen files or compromised applications.

Another benefit is that all data is encrypted by default, so you don't need to keep a mental process of copying sensitive data from the unprotected partition to the protected one. And if you need double protection, create a VeraCrypt volume and use it.

One benefit of encrypting only a partition vs the whole drive is that you can encrypt/decrypt the partition while using the system for other tasks, so you can encrypt it "on demand" so to say, but if you encrypt the whole disk it's decrypted every time you start up and authenticate the system.

In terms of security, as you say, if the machine gets stolen, I would say there isn't much difference between FDE and an encrypted partition in such a scenario. If you use strong encryption on your partition it's highly unlikely that your data will be compromised.

I'd say there is some benefit to using an encrypted partition / folder vs FDE if you only decrypt it when you need to access or store sensitive information and encrypt it again when you're done, so that you don't leave the filesystem in an unencrypted state all the time when you're logged in, as would be the case with only FDE.

Without having more information on the application, FDE is always the safest bet. However, for less critical data and unsophisticated attackers, an encrypted partition or virtual hard drive is probably enough.

The problem is that when you leave the Windows partition unencrypted, then you will also have an unencrypted pagefile (where Windows stores application memory when running out of RAM) and hibernation file (where Windows dumps the RAM when hibernating). When you are working with confidential data stored on your encrypted hard drive, then their content might end up in these files.

There are also other places on the system drive where confidential data might show up (depending on what information you consider confidential, of course). One thing I would always want to be encrypted is the C:\Users directory, because all kinds of applications use it to store temporary (and not so temporary) files. Whenever you view or edit a confidential file, the software you use for viewing might store information about that file in your user directory. When you are sure that you will only use programs to work with confidential files where you know that they won't ever do this, then this might not be a concern. But are you sure about this?

I cannot foresee any shortcomings with this method of encrypting a partition. I often use full disk encryption with encrypted containers within, 7z AES256 archives. So, layers of encryption. I would advise you review which AES-XTS bit size is used, and swap to AES256-XTS, as more rounds, is used. HowToGeek outlines how to use Local Group Policy Editor to change the encryption cipher used.

Data on a lost or stolen device is vulnerable to unauthorized access, either by running a software-attack tool against it, or by transferring the device's hard drive to a different device. BitLocker helps mitigate unauthorized data access by enhancing file and system protections, rendering data inaccessible when BitLocker-protected devices are decommissioned or recycled.

BitLocker provides maximum protection when used with a Trusted Platform Module (TPM), which is a common hardware component installed on Windows devices. The TPM works with BitLocker to ensure that a device hasn't been tampered with while the system is offline.

In addition to the TPM, BitLocker can lock the normal startup process until the user supplies a personal identification number (PIN) or inserts a removable device that contains a startup key. These security measures provide multifactor authentication and assurance that the device can't start or resume from hibernation until the correct PIN or startup key is presented.

For BitLocker to use the system integrity check provided by a TPM, the device must have TPM 1.2 or later versions. If a device doesn't have a TPM, saving a startup key on a removable drive is mandatory when enabling BitLocker

A device with a TPM must also have a Trusted Computing Group (TCG)-compliant BIOS or UEFI firmware. The BIOS or UEFI firmware establishes a chain of trust for the preboot startup, and it must include support for TCG-specified Static Root of Trust Measurement. A computer without a TPM doesn't require TCG-compliant firmware

TPM 2.0 is not supported in Legacy and Compatibility Support Module (CSM) modes of the BIOS. Devices with TPM 2.0 must have their BIOS mode configured as native UEFI only. The Legacy and CSM options must be disabled. For added security, enable the secure boot feature.

Installed operating system on hardware in Legacy mode stops the OS from booting when the BIOS mode is changed to UEFI. Use the tool mbr2gpt.exe before changing the BIOS mode, which prepares the OS and the disk to support UEFI.

If the drive was prepared as a single contiguous space, BitLocker requires a new volume to hold the boot files. BdeHdCfg.exe can create the volume. For more information about using the tool, see Bdehdcfg in the Command-Line Reference.

Device encryption is a Windows feature that provides a simple way for some devices to enable BitLocker encryption automatically. Device encryption is available on all Windows versions, and it requires a device to meet either Modern Standby or HSTI security requirements. Device encryption can't have externally accessible ports that allow DMA access. Device encryption encrypts only the OS drive and fixed drives, it doesn't encrypt external/USB drives.

Starting in Windows 11, version 24H2, the prerequisites of DMA and HSTI/Modern Standby are removed. As a result, more devices are eligible for automatic and manual device encryption.For more information, see BitLocker drive encryption in Windows 11 for OEMs.

Unlike a standard BitLocker implementation, device encryption is enabled automatically so that the device is always protected. When a clean installation of Windows is completed and the out-of-box experience is finished, the device is prepared for first use. As part of this preparation, device encryption is initialized on the OS drive and fixed data drives on the computer with a clear key that is the equivalent of standard BitLocker suspended state. In this state, the drive is shown with a warning icon in Windows Explorer. The yellow warning icon is removed after the TPM protector is created and the recovery key is backed up.

Device encryption uses the XTS-AES 128-bit encryption method, by default. In case you configure a policy setting to use a different encryption method, you can use the Enrollment Status Page to avoid the device to begin encryption with the default method. BitLocker has a logic that doesn't start encrypting until the end of OOBE, after the Enrollment Status Page device configuration phase is complete. This logic gives a device enough time to receive the BitLocker policy settings before starting encryption.

If a different encryption method and/or cipher strength is needed but the device is already encrypted, it must first be decrypted before the new encryption method and/or cipher strength can be applied. After the device is decrypted, you can apply different BitLocker settings.

If a device doesn't initially qualify for device encryption, but then a change is made that causes the device to qualify (for example, by turning on Secure Boot), device encryption enables BitLocker automatically as soon as it detects it.

Encrypted hard drives are a class of hard drives that are self-encrypted at the hardware level and allow for full disk hardware encryption while being transparent to the user. These drives combine the security and management benefits provided by BitLocker Drive Encryption with the power of self-encrypting drives.

By offloading the cryptographic operations to hardware, encrypted hard drives increase BitLocker performance and reduce CPU usage and power consumption. Because encrypted hard drives encrypt data quickly, BitLocker deployment can be expanded across enterprise devices with little to no impact on productivity.

When the operating system identifies an encrypted hard drive, it activates the security mode. This activation lets the drive controller generate a media key for every volume that the host computer creates. The media key, which is never exposed outside the disk, is used to rapidly encrypt or decrypt every byte of data that is sent or received from the disk.

There are three policy settings to manage how BitLocker uses hardware-based encryption and which encryption algorithms to use. If these settings aren't configured or disabled on systems that are equipped with encrypted drives, BitLocker uses software-based encryption:

Encrypted hard drives utilize two encryption keys on the device to control the locking and unlocking of data on the drive. These encryption keys are the Data Encryption Key (DEK) and the Authentication Key (AK):

When a device with an encrypted hard drive is in a powered-off state, the drive locks automatically. As a device powers on, the device remains in a locked state and is only unlocked after the AK decrypts the DEK. Once the AK decrypts the DEK, read-write operations can take place on the device.

3a8082e126