How risky is it writing a mounted bitlocker decrypted windows ntfs partition

Question

I setup up a multi os system with Windows11 and Linux. I found out, that it's possible to mount bitlocker encrypted ntfs windows partition (/dev/sda3 as root) from linux:

cryptsetup bitlkDump /dev/sda3
cryptsetup open -y --readonly --type=bitlk /dev/sda3 bitlk-65536
mount -t ntfs -o,ro /dev/mapper/bitlk-65536 /mnt/
# ...
umount /dev/mapper/bitlk-65536 
cryptsetup close bitlk-65536

I always used readonly flag for both cryptsetup open and mount options for mapper. It's surley possible to mount bitlocker encrypted ntfs partition rw, like:

/dev/mapper/bitlk-65536 on /mnt type ntfs3 (rw,nosuid,nodev,relatime,uid=1000,gid=1000,iocharset=utf8,windows_names,uhelper=udisks2)

How risky are write (delete) operations on a mounted bitlocker ntfs3 partition? According to documentation, it's even already risky and experimental to add bitlocker windows ntfs partition to /etc/crypttab and decrypt and mount windows partition at linux boot time.

I like to ask, before I have to setup up Windows11 again (after possible filesystem crash).

Kind regards,

[email protected].

Answer 1

Short answer:

It's safe, but make sure to always have a backup (you should have a backup of all data you don't want to lose regardless of storage technology involved).

Long answer:

BitLocker is a proprietary technology and the specification of the on disk metadata is not public.

This means all support of BitLocker in Linux is result of reverse engineering so there is always a chance that something is implemented wrong in Linux. Good news is, that this problem exists mostly when reading and parsing the on-disk metadata and not when dealing with actually reading and writing the data -- that's just standard AES-XTS (AES-CBC with older versions of BitLocker) encryption which is also used by LUKS by default so the kernel code which actually deals with reading and writing the data from/to the disk is well tested and safe.

Also the NTFS on BitLocker is just a standard NTFS so once cryptsetup parses the metadata and unlocks the BitLocker device and you get a NTFS filesystem that can be mounted, there isn't much to get wrong that could result in data loss. (Or at least nothing that could be more dangerous than writing to a normal NTFS without BitLocker).

It's the parsing of the BitLocker metadata and decrypting the volume encryption key which is a challenge and even if cryptsetup gets that wrong, you won't be able to mount the NTFS file system (and damage it by writing something to it) because the cleartext device will contain only garbage (incorrectly decrypted data that cannot be mounted and even that shouldn't happen, the BitLocker support in cryptsetup is written in a way that anything unknown or unexpected in the metadata will result in an early error).

The BitLocker support in cryptsetup is still marked as experimental, but it was added in 2.3.0, nearly 4 years ago, so since that it was tested by many people and I am not aware of anyone losing data (so far). So it's probably pretty safe to use.

Answer 2

Due to the nature of encryption, if it decrypts correctly at all, likely writing to an encrypted volume is no more dangerous than writing to an unencrypted volume. Modern encryption doesn't allow a partial failure of decryption, it is intentionally an all or nothing operation.

Having said that, mounting even an unencrypted NTFS volume from linux is extremely dangerous, especially if there is any chance at all the system could be rebooted without unmounting it. There is a high risk even without encryption that the volume can be corrupted on even a normal reboot if anything goes wrong with the unmount. (I've even seen windows corrupt its own volume in these circumstances, but it is less common.)

Additionally, storing the encryption key in a file presents a security risk. Typically bitlocker stores the key in the TPM, so storing it in a file defeats the purpose of using bitlocker at all. Encrypting the linux volume and storing its key in the TPM may mitigate this somewhat, but this weakened security posture and risks of sharing NTFS between the two operating systems casts doubt on the wisdom of sharing an encrypted volume like this at all.