 So, let's start talking about BitLocker. As you probably know, if you read the abstract of this talk, BitLocker is technology from Microsoft Windows. It's a full disk encryption technology. It was first introduced in 2006 in Windows Vista. And it's still used today with some minor changes. There was some on disk metadata change in Windows 7 and some encryption algorithms changes in Windows 8 and in latest versions of Windows 10. It supports both encryption of both your system drives and of removable drives. Encryption for removable drives is called BitLocker to Go. There are some small changes into metadata, but other than that, it's basically the same technology. And on disk metadata format is not open, but there are some public information. The original version of BitLocker for Windows Vista was described by Walter Niels Ferguson in this paper. If you are interested in these things, I recommend to read it. And some really smart people were able to do reverse engineering of the metadata format and there are also some existing open source implementations. If you are really interested in how the metadata format look in detail, I suggest you take a look at library called LibBDE by Joachim Metz and there's documentation where the format is really nicely described. So, why do we even care about BitLocker? We have our own disk encryption. It's nice, cool, it's open source, so why don't you care about BitLocker? The problem is that not everyone is using Linux and not everyone is using class. There is still a lot of people that use Windows. Last time I checked it was like 90% on desktop. And if you want to share encrypted data with those people, if you want to have a flash disk that would work on both Linux and Windows, if you have dual boot and you want to have encrypted partition to share data between Windows and Linux, it's not that easy. You need to install some third party applications in either Linux or Windows or in both and use some different encryption technologies, non-native. And as I said, there are some existing tools for Linux that work with BitLocker, but these are not very user-friendly. They use Fuse and implement custom cryptographic functions. And ideally, you'd like to BitLocker devices to behave the same way native encrypted devices behave. You take a flash drive, you put it into your computer, you will be asked for a passphrase and then you can work with it. So, and this is what this talk is about. So, let's take a look at how BitLocker devices actually look. If you create a flash drive in Windows, you enable BitLocker on that. This is what you get. The device will look like there will be some BitLocker header in the start that's used to identify the device as BitLocker and there are offsets for the metadata BitLocker. It's called FVE, full home encryption metadata. BitLocker has three identical copies of the metadata in the middle of the drive. We also have an NTFS header of the open file system. There, it's encrypted, we will get to that later. And of course, we have some encrypted data. In this case, it's four parts of the encrypted data. It's just data that is encrypted. So, of course, there are encrypted metadata, so you need a key to the encrypted because you can create an encrypted flash drive and use it on different computer. That means that the key to the encrypted data is saved on the device. There are actually two types of keys saved in the BitLocker metadata. First one is full-volume encryption key. It's the key that is actually used to encrypt and decrypt the data saved on the drive. It's either 100 and 50 or 256 bits, depending on the Cypher function used. And of course, it's not stored in open format on the drive. That would be really bad design and it wouldn't be really encrypted device. The key is encrypted with a different key called volume master key that's also saved in the metadata, also encrypted. And it can be, it is saved in multiple copies. Every copy is encrypted in a different way. It's called some, these different ways of encrypting the volume master key is called protecting it and we have different protectors. One of the, that is for us, the most important is password protected keys or password protected BitLocker devices because we are talking about flash drives and we will mostly use passwords for this. And with passwords, it looks, it works like this. You get passwords from the user. You get some soul that is stored in metadata. You use some key derivation function BitLocker has. It's our custom key derivation function based on SHA-256 hash function. You do some magic. The function is actually quite easy. It's just looping the SHA-256 like million times with some smaller changes in between and you get the key that can be used to decrypt the volume master key. It's encrypted using AAS CCN. From that you get an open volume master key and you will use it to decrypt the volume encryption key and you get the key to decrypt the data stored on the drive. So that's all quite simple. So now we'll take a step in another direction. Now I will tell you something about how this encryption works on Linux. We use something called DeviceMeper and Lux. DeviceMeper is a kernel module for creating something called MEPT block devices. Basically you take an existing block device and you create a new block device on top of that. You can create it only from part of the device or you can take multiple devices and join it together to one device. If you are using Fedora or well, you are probably using LVM and this is what LVM uses. The additional functionality is provided through something called Targets. There are dozens of Targets for DeviceMeper that can provide caching or mirroring. You can create a rate, thanks to that. But for us, the most important Target is decrypt. You probably can guess from the name that it provides encryption. And it's used in this encryption in Linux. Basically goes the way that you will specify cipher and key for it. And the MEPT device you create, everything you write to the device is encrypted using this provided key and cryptographic function. And if you read from the device, it's decrypted before you actually read it. So it's relatively simple. You can actually create encrypted devices for you only using DeviceMeper. But it's not very user-friendly. That's not a bug, that's a feature. It shouldn't be user-friendly. You shouldn't be using DeviceMeper or DMSTAP directly. But you can do that. Everything you need to do is, you need to know a lot of information about the device. You need to know what cipher is used for that, how the device is made, where the data is stored from the device. And the worst part is, you need to know the key used for encryption. This is just a short version that should be 128 bits. And people tend to not be able to remember such keys. So to make things easier, you have something called LACS. It's a relation of Linux Unified Key Setup. And it's actually a standard that defines some format for storing metadata and key materials on the MEPT device. And basically what it allows us is to create some user-friendly and simple way to work with encrypted devices. You have, there is a tool called CryptSetup that works with LACS and DMCrypt. And basically, if you have an encrypted device and you want to work with it, you just need to say CryptSetup, LACS open, give the name of the device you want as DB, and the name of the DeviceMeper device you want, the name you want for the created DeviceMeper device. I just selected X. CryptSetup will ask for a passphrase, you will type a passphrase, and everything works. It works in the way that the key is stored on the device in metadata and is protected by the passphrase. So, CryptSetup will read the metadata, decrypt the key for you, and create the DeviceMeper device. Do basically the same that you need to do with the DMSetup. So, this probably sounds kind of familiar. And it should sound familiar. Because it actually is very similar how BitLocker works. You have, for BitLocker, you have some BitLocker header, for LACS, you have some LACS header, for BitLocker, you have some FVE metadata. For LACS, you have also some metadata. There are some key slots with keys, and you have some encrypted data. So, can we use the Linux technologies like DMCrypt and CryptSetup to work with BitLocker? I guess you already know the answer, and the answer is yes. And it's actually not that complicated. All you need to work with encrypted data, with DeviceMeper, is these four things. You need to know what cipher to use. You already know that. I mentioned it on the first slide. It's AES in XTS mode for Windows 10. You need to know how initialization vector is computed. You also know that it's simply sector number. You need key, but we know how to get the key from metadata using passphrase. And you need to know where the encrypted data are stored. We also know that it's here and on the three other places. It's actually simple, everything that's not metadata or some header that's data. So, we can use that. And basically use DeviceMeper CryptoTarget for the data parts. And for the metadata parts in Windows, those metadata parts are actually zeros. If we have flux, all the metadata and the last header are at the start of the device. And basically when we create DeviceMeper device, we discard it and the DeviceMeper device is like a few megabytes smaller. And the first part of the encrypted data is actually your format header. So, EXT for XFS header or something like that. Not for BitLocker. They decided to make the open device same size as the encrypted device. So, that's why we have the NTFS header encrypted on a special location because we need to move it to the start of the new device. So, after you have the open DeviceMeper device, you need the header to be in the front. So, it's recognized DeviceMeper device. So, NTFS device and you can mount it. Other DeviceMeper, this is simple. You can basically say, oh yeah, this part will be mapped here. That's what DeviceMeper does. And also, we will use another DeviceMeper target called zero. That's basically a special target that when you read from this device, it will return zeros. That's what we want because in Windows, these parts are zeros. Actually, the way that this works, that you have in NTFS in the MFT table, you have special files for these parts of the device. So, even in Windows, there is some system folder with four, six files that are full of zeros and correspond to these metadata areas. And you get exactly the same in Linux with using the device script. Thanks to that, we are using DM0. So, you will see files with zeros. And it also protects the metadata from accidentally overwriting it. So, yes, I think I already mentioned that using DeviceMeper directly is not very user-friendly. And with Bitlocker, it's even worse because for Lux, you will create only one DeviceMeper device. For Bitlocker, we need to create, this is nine or eight DeviceMeper devices and you really don't want to do that by hand. But you can actually do the very same what we do with Lux. We have Crips setup and we can use it to hide all this crazy DeviceMeper configuration and use Crips stuff for that. And that's actually what I did. I edit support for BitLAK format, BitLocker compatible format, or BitLocker devices in Crips setup 2.3. It's actually not released yet. First, RC version was released two weeks ago, but if you are using Federal Arrow Height or some other app today, this show you can already test it and it's there. And Crips setup now can parse BitLocker metadata, extract and decrypt password-protected keys and construct the crazy multi-segment DeviceMeper device. So it's basically the same as for Lux. We just write Crips setup, BitLAK open, there's SDB2, you will ask for a passphrase, you will put in passphrase and it will create a new device that's open, that has an NTFS on it and you can mount it, sorry. If I request, you can also print some information about the device, basically dump the metadata we know. So this is an example of how some metadata of BitLocker looks like. You can see that this particular device was created in July last year on a computer that was called desktop NPM something. It's encrypted using AAS in XDS mode with 120 bytes key and it actually has multiple key slots. I will get to that later, but first key slot is protected in passphrase, there's some GID, you can see the sort and other information. So what is actually supported? As I mentioned, you can have different types of protectors of the keys. We basically have the key stored in multiple copies. Every copy is protected with a different protector. We support only passphrase and recovery passphrase protectors. Passphrase is basically normal string passphrase entered by you and you create the device. Recovery passphrase is actually created for every BitLocker device automatically and you create it, Windows will create another key slot by recovery passphrase which is some hexadecimal long number and you should print it or save it in some safe location and you can then use it to access the device in case that it's not accessible for some reason. Maybe you forgot the password or you are using some of the unsupported protectors. It's not a problem in Windows, but in Linux you can access it even if the primary protection is for example by TPM but it's also useful in Windows because if your laptop is broken then you can't access it if it's protected by TPM because if you remove the drive from the device it's no longer works with TPM. Unfortunately, these unsupported protectors there's nothing you can do about that. You can't support TPM in Linux because if you boot different operating system then the TPM won't give you the key. From the encryption part, for the encryption part there are actually three types of encryption that care for the data itself. AS XDS, it's in latest version of Windows 10. This is supported in all versions. If you have device, if you have DM Crypt then this will be supported. AS in CBC mode that was from Windows 7 to Windows 10, some other versions of Windows 10. You actually need new kernel, you need kernel 5.3. It's not because we don't support CBC but they have a special way of calculating the initialization vector and that was not supported in DM Crypt. It was added by Nelan Brosch last year so you need kernel 5.3. And the oldest version of BitLocker they actually had their own special cryptographic function. They used CBC on top of that something called LFM diffuser and that's currently being developed or the patches are already finished but not yet merged and it should be available in kernel 5.6 or plain. From the metadata point of view there was change in metadata in Windows 7 and we support only this version of metadata. We don't support the oldest version of metadata. The main reason being that you are not able to create this version of metadata even with Windows Vista, it couldn't create a BitLocker device on Windows Vista. Maybe in future. So, there's four crypts at the top but in the beginning I mentioned that the ultimate goal is to make it completely seamless for user or fresh drive with BitLocker if you will connect it to your computer it will ask you for passports. So, that's what you have few disks for. If you don't know it's a demon that's used by most graphical environments known KDXFC to work with block devices. So, mounting of fresh drives and also unlocking of last encrypted fresh drives is done by BitLocker. And all you need to do is to add support sorry by UDISCs. All we need to do is support BitLocker to UDISCs. It's actually quite simple. We need to be able to identify BitLocker devices that's done by UDF that use the block it you need Utilinux 2.33 or newer. That's like from 2018. And then the device is identified by UDISC as BitLocker and we will just simple add an encrypted interface to that and unlock and lock functions to this device and then from API point of view from UDISC API point of view the device looks the same as Slack's. So, there are no other changes needed in the GUI. And the support for this should be available in UDISCs 2.9. I have the patch yesterday. I haven't posted them yet, but it's really simple change so there should be no problem emerging it. If you are familiar with UDISC's API this is how encrypted devices looks in UDISCs. The blue parts are from UDISC so we already know it's BitLocker and it's TypeCrypto. The red parts are added in the new version. Some UID parsed by Cryptsetup. And basically the only difference from the API point of view is this hint encryption type that says BitLocker for Lacks, it will say Lacks. But just because it has the encrypted interface the users of the API will know that the device is encrypted and they can call some unlock function on top of that. So they will ask you for a passphrase and unlock it. So, it's basically all from me, just a summary. You can now use BitLocker devices in Linux. All you need is Cryptsetup 2.3 or newer for some older versions of BitLocker. You will need also newest kernel but for the new version of BitLocker from Windows 10 all you need is new BitLocker. So, thank you for your attention. Thank you for coming and staying so late. And please test BitLocker support in Cryptsetup and report all the bugs you found. Fine, you were definitely found a lot because there are some subtle differences in the metadata versions. As like two months ago there was a big update for Windows 10 and they added some new properties or some new data to the metadata and it confused Cryptsetup. So there might be some problems you'll find out with different versions of Windows. And have questions, please ask. Okay, so another question. I can understand you can easily read data from the Windows machine but can you create data that Windows machine is not confused? Like, if I can create a BitLocker device. Yes, on Linux In theory you could but the problem is the start I mentioned that the format is not open and even though we understand most of it there are still some blind spots or some unknown spots. Maybe these are important and we probably don't want to create. It should be possible that, no. So, other questions? Yeah, the question was if I look at for service or tool. Yes, I know about the biggest issue with TPM protected BitLocker is that basically TPM is bound to some UFI data and if you boot something else than Windows then you can't get it from TPM because you boot in different operating system. But what about other things? That doesn't work with us. But it will render the password phrase. We can talk about that. Yeah, we can talk about it after. So, because that's the whole way out of TPM, it's not the whole protocol based on the game speed much more than TPM. Okay, some other questions? Okay, is that all? It's a reminder to me I'm just the firmware correcting and at least in the older Windows versions when they're doing uprights of the firmware uprights then they actually refried the policy for the TPM so that they turn off all the binding to the measurements so that you could probably use that to then reboot it to Linux and then you can add it to the TPM and all the measurements don't matter anymore. Okay, that was not a real question. It was some more information about the TPM. I'm just repeating it for the firmware card that it actually should be possible to use the TPM protection from so support TPM protection from Linux. I'm not 100% sure. I am not an expert on TPM. This is what I have been told. And yeah, if it's possible, we can definitely add support for it later or someone else can add support to it later. Everything is open source. So, someone else? Sure, no other questions? Thank you. And you can meet me outside.