 Okay, so right so let first let me backtrack a little bit and start with a bit of context So In the Linux kernel device device mapper is Provided an I quite to create virtual layers of block devices and those block devices usually have the name Dave dm 0 dev dm 1 and so on and you'd have create sim links dev mapper Target where target is the dm target name and They are used for whole bunch of purposes among which Transplant encryption of block devices using dm creep module and As well as integrated checking both for Read only targets for the whole device as well as per sector integrate information. They're also used for the logical volume manager LVM and And a whole bunch of other things you can check dm setup or the this directory in the Linux Canal source train Here's an example of such virtual block device stack. So here we have to this as the an sdb on which We map Dev mapper crept pv0 dev mapper PV1 Which are Encrypted devices and they are used together as physical volumes for VG my VG and For logical volumes in that VG LV1 to LV4 LV1 is mounted on Roots LV2 on Va LV3 on home and LV4 is used as web device Um So one thing that people Seem like people sometimes forget about is that encryption for crypto gets is not done by crypto itself but instead by the canal crypto API and The source device that is SDN sdb in the in the previous stack I showed Can be either random noise in that case we talk about plain dm creep device or have a header with metadata Metadata it consists of type of metadata the cipher encryption cipher the key derivation function the UID and That's used for key management and that's what creep setup does it does it read those header and the performance key management So the most common header is locks At least for Linux these days and Crypts up read that does perform key management and uses leave the mapper to create the map devices and then delegates all the crypto to the to the canal and I should say that for non volatile volumes that is volumes other than swap and slash DMP It's usually a good idea to use locks rather than playing the M-Crip device because that means Well, there is more infrastructure to prevent yourself from shooting yourself in the food So Crips it up in devian, so we are shipping a whole bunch of packages. I Just listed a few here. So we have Crips that have been and a leap ship creep setup respect for the upstream bits respectively for the upstream binaries and the shell libraries and for those two we also ship you debs for integration in the devian installer and We also have Gazians of scripts That are spread across those two packages and those scripts are used for I used to pass crypto and turn the crypto entry into creep setup open commands With substitutable arguments and while we also ship creep scripts to Use the output of a program as a passphrase As well as in a trimfs Boot scripts and hook scripts for unlocking at early boot stage so these days the Our scripts are spread across those two packages as I said since about a month or two and So creep setup is a transitional dummy package that depends on the two on these two and well it would remain so for another Really cycle to ensure like a smooth upgrade path So one thing that's quite important emotion, I think is that We are upstream for these bits That is we so our work is not only about packaging But it's also I mean we need to do the QA and the maintenance and well development of the scripts that we are shipping and That's some Debian derivatives are depending on So and since Crips that up especially at unlocking at early boot stage is a fairly low level when things break they break quite badly and That makes people Quite angry at us. So we need to be quite careful with a QA here Okay, so here's a timeline of the project with a few selected highlights so in 2004 the Linux channel was released Linux 2.6.4 with the first release containing the dm3p module and Shortly afterwards the crypt that are planned into Debian about one year later upstream released one or two Just in time for H We had The first pathman crypto release so it was possible to set up encrypted volume in the installer then skipping a lot of like seven years of and a lot of Development Interdent 13 upstream released 106 and the Lux default self-emode Switch from I think CBC to XDS, which I think most of you are using today and Skipping another five years Upstream release 2.0 earlier this year with a new Lux to on this format Which I might talk about if I have a little bit of time at the end and a bunch of experimental features In about two months ago, you know, so no and I met for packaging sprint and we kind of Refactored and we wrote the whole Debian bits and So we yeah, we removed a lot of code duplication Do did some triaging and unfortunately also introduce some migrations and in the future into them in hopefully before the Freeze upstream will release a 2.1 and Lux format will default to Lux too Okay, so now I will focus on unlocking at early boot stage Because that's what most our work is about So we also provide script for unlocking at later stages Mostly for manual unlocking and Cisvenic scripts. So for those of us who are using system D system D comes with its own Crypto parser and unlocking logic and So they're not using The creeps of the binaries at all they're using liquid that but not the big creeps of binaries And I should say to give proper credits I should say that all of this is joint work with Jonas Mer and a bunch of other contributors So along the years we have added support for multiple use case That's what people wanted to have like they have a custom Block device stack and they want to they want to be able to unlock it and they Doesn't come out of the box. So they come up with their own work around and We Oh so But but they are not aware they are not always aware of our work and so they I guess we are bad at Advertising or something So this is why I want to talk about this today about this today But so first I have a plea that is that you should never use our own each my first script as a baseline for your own Scripts because those are using our internal API and is therefore subjects to change without notice So if you want to use the like custom In the term effect negation, you need to stick to the community interface or if it's not powerful enough then ask us to extend it So when we had these prints we kind of rewrote the whole Initram of Fests integration as I said and that broke a lot of third party scripts. Unfortunately, I filed RC bug against them the one I found at least but I Don't know. It's a bit unfortunate. It's not because it's a shell script that it's like a free access for copying Okay So one thing I want to talk about is Remote unlocking using SSH. So since Lenny The drop-bar SSH server has in it from a fit in each my first integration and today it's it leaves in the interim of drop-bender MFS package That is you can SSH you can install drop-bar SSH into your unit ID of your server and then SSH into that unit ID and unlock the Your device there. So what happens? That's the initram of Fests boot scripts are blocking on the password prompt but you can access to it remotely and dump your own passwords in the in some Well as pass fee for and some magic happens and you bypass that password password prompt that's on the local console and There I should point out that the SSH Hoski are not encrypted in the unit ID So if you don't have encrypted boot Those are accessible by anyone that just pulls the hard drive even if the machine is is powered off So don't use the same whole SSH Hoski for drop-bar and for the main system So, yeah, well drop-bar had Interim of integration since quite many years and but there was no proper integration really with Cripset up and people came up with their own work around for that and one of the things that you find on the internet is tutorial that say all you can just run this our own Criptrude interim Fests boot script and then kill it afterwards And Well, they claim they seem to work, but I argue that well first. It's a local script. It's our own script It's not to be meant It's not supposed to be run in a non interim FS environment and Especially it's not to be supposed to be run multiple times in parallel and it's also racing. So that's fairly bad. I mean that can yield to lots of Corner cases like that might yield an unputtable system another Solution that people came up with actually this used to be in Cripset up documentation for quite a while is to run cat and then dump the standard input into the ask pass fee for and so you run that from SSH and So while it seems to work the The downside is that there is no passphrase prompt. So you don't know if you have multiple encrypted device You don't know which one you're unlocking And also it echoes passphrase to STD out. So it's like it's it's okay If you are dumping something into it like a file or something But if you want to prompt it's not so nice and so it's a racy because well if the This is a fee for but if the fee for is not it does not exist yet you are creating your regular file and well you end up with a Unputtable system So this is personally how I got involved with a Cripset up Packaging team because I was maintaining drop there are still maintaining it and I wanted better integration with Cripset up so I wrote this Script that supposed to eliminate rates at least that's acclimate does and If the standard input is not a terminal it behaves like the one above and if it is the terminal it loops through each device that needs to be unlocked at in drama first stage and prompts for those Prompt for the passphrase and disable echo so it does it's like it behaves like an actual password prompt and not like cat Okay, so if you're interested in Unlocking at like remote unlocking. You might also be interested in the clevis tank Infrastructure so that's some infrastructure developed by red hat and that does automatic unlocking without key is cross So there was a talk about this at falls them last year for them 2017 Which you might want to look at and it's already in the beyond is maintained by Christophe beetle and it works with great cut, but not with any term fs tools yet. I know in term fs tools scripts currently in In that package And there is like a fh to To add in term fs tool support But the proposed scripts are buggy and they violate our API and so I hope they won't land as in In the in the end I get some feedback about it and I hope I have been heard But I didn't hear any follow-up yet. It was just a few weeks ago. So No worries Okay, so another thing we are shipping as part of the devian packages are Key scripts so key scripts as I said is something like if you want to if you don't want to password prompt But you want to run the program and use the output of that program as a key file You can use key scripts. There's an interface that will put that we provide for that and we currently ships ship six of them We have decrypt derive That drives the passphrase for unencrypted key of another group device We have the crypt new PG and the crypt SSL that add the symmetrically encrypted key file to the unit ID and then at early boot stage ask you to unlock that I mean to decrypt that That encrypted key file So that you can and and then done the plain text of that key file into the and use that as passphrase for the for the device And then we have this one is pretty nice key CTL it's used To cache passphrases using the canal carrying so it's pretty useful if you have multiple devices that use the same passphrase We also have Open SC for smart card support And pass dev that is if you have your your key file on a removable device like a USB stick or something You can store your yeah store your key file there and then you can use pass dev to turn on that and something that's coming is It's currently under review Would probably land in the biennium a few weeks. It's something for open PGP smart card But if you're using key script the one thing I should mention is that Keyscript are not supported by system D yet, and that's quite unfortunate sadly We really hope that it eventually will and if the system they maintain a yes, then Please do something about it like it's so in the meantime the The workaround is to add the interim of s option to the crypto pantry to force unlocking at interim of a stage and not later that is if you have if you're using keyscript for Device that needs to be unlocked at early boot stage like a root device or resume device Say then it's no problem, but if it's something if you're using keyscript for another of those Like if you're using keyscript to unlock your home device Then this won't be unlocked at interim of a stage by default, but it will be unlocked later in the boot process by by Pid one of the main system That's you these days it system D and if you're using keyscript there it will break So they'll walk around use it from a fast option in your crypto boundaries And that will force the device to be unlocked at the stage. It's a bit ugly, but Well, it works for now on the other hand if you switch interim fs from interim fs tools to say Drake or something Then this walk around won't work anymore. Just so you know Another neat thing is So when we talk about encrypted a foolish encryption We often say we often hear that well, you need we cannot have foolish encryption You need to have booting in in the clear. It's actually not true with bootloaders that can unlock Lux volumes such as grab2 and The idea here is that Yeah, you can use your bootloader to unlock the volume that's holding that's holding boot And unfortunately since the currently there is no the canal doesn't provide any interface to And the bootloader doesn't provide an interface to pass the the passphrase or I don't know the key from the bootloader to the canal you need At the Slash boot and the other devices are still unlocked at interim fs stage. So you only have your unit ID there But it's possible to Unlock it again using a key file And in that case that key file needs to be present in the unit ID so what you do is you can Set that viable it's set to a glob and if that if you have if the key file matches that pattern Then the the the key is copied to the unit ID On the other hand if it's if it's not if you are trying to unlock a device that's not a route That's not holding slash and that's not a reason device then There is no need to do that there is no need to to set a key file pattern here You can be because the the key file the device will be unlocked after slash is mounted And here yeah, I should also mention that's here I did key slot equal one and the reason for that is that I find it easier to Do key rotation With this because I don't need to have my own passphrase in in dev.key I can use for instance a binary passphrase Like a binary data and use that as in a in the second key slot and then I use So key slot a number from zero and I use that in the To unlock using the key file But if I want to unlock manual if I want to unlock using the prompt then it would be key slot equals zero and Grab doesn't support key slots, but since it tries the first one it will try the key slot equals zero by default Okay, and if you do that Be aware that the initrum FS is by default world readable So it prints a warning if it's if you have a key file pattern that's not empty and if you don't have a Restrictive your mask So but yeah, you need to make your interim FS not world readable and the one way to do that is to set your mask to some Permissive value to a restrictive value sign So one of the recent changes is So that's that's fairly new. That's from like two months ago. So is that now we are using C surface to discover block device stacks So we are we're usually traversing C's dev block and so on to reliably discover encrypted devices And concretely what that means is that? Device mapper so LVM DM creeped and so on and Raid stacks are now supported out of the box and in whichever order whichever combination and so on So multiple device beta FS or any FS exposing a Directory under C's FS are supported out of the box So that's not unfortunately the FS does not expose a directory under C's FS So the FS is not supported. I mean the FS auto discovery for the FS is not supported out of the box I don't know. They might add at it. Hopefully at some point we'll see But so this is pretty neat because that means our auto discovery code is now very short and It's just like a simple reclusive loop and that means it's the Yeah, we have we can Traverse arbitrary complicated block device stacks like if you have I don't know something very Weird like a three device beta FS for that you use for the root file system and you have the foot the first device is I don't know like Raid on top of to the M3 devices and the second device is Like LVM where the PV's are on to The M3 devices and the third device is the opposite like DM or on top of LVM. That's fairly weird Block device stack, but we are supporting that out of the out of the box Unfortunately we broke the eye and There is a bug upon for that the reason why we broke it is that in finish finish install the stage the In updating my face So it is a at finish Finish install the stage the internal fs in image is rebuilt, but The ccFS and proc FS are not mounted at a stage no longer mounted in the into the target file system so The internal fs that you get I mean it doesn't have we cannot do the auto-discovery and you end up with an unbootable system This bug is still open, but The DI maintainer should be aware of it So you might have heard of this cve 2016-44-84 So that was a cve that was filed at the end of 2016 where so the idea was that well if you keep answering If you keep pressing the enter key at the lux password prompt eventually you will get to an internal fs the bug show and I Don't know really it got I only mentioned it here because it got a lot. I'm fair amount of media coverage But we argue we argue that it's not really That much of a problem because encrypted devices are not readable. They are still locked But and also that's not really a crypto problem because what the reason why you end up to internal fs the bug shell is because Interim fs tools will Drop you to the bug shell if it cannot mount the The root device after trying for a number of times So what we had a mitigation in place for this we decided to remove it because it caused more pain than good So what we are doing instead is we sleep one after each unsuccessful unlocking attempt and just to Defeat local brute force attacks, but maybe the the bootloader should pass panic equal Sack to the boot argument list and that will have the effect of rebooting instead of dropping to a debug shell But I mean So of course like it's if you do that, but you can still edit your grab front or something It is it's not really useful. So we will still need to secure the whole boot process, but well, it might still be useful It might be worth to do when like secure boot becomes more common right now we argue that it's It's not a real. I mean they got a CV assigned, but It's not really a trips that a problem. That's all position on it So I should yeah, so about things that needs improving is a better QA so What I said when we did these three factoring work We had quite a few more quite a few we had two or three fairly bad regressions and We are testing things, but we currently have like a semi automatic test suite where we deploy preceded seed VMs With a custom partitioning script that takes ETC crypto and ETC FS tab as input But so it's semi-automated. Well, it's almost automatic because the VM is deployed in an Unattended fashion, but we still need to press the to enter the passphrase manually So semi-automatic and we'd love to have something more automated. So if you have some idea about how to do that We would love to hear So because well, we still have to test like a 20 or 30 of the like most common setups and That's not something that scales Yeah, so one thing that's We have been delaying for some time now. We are halfway through the freeze and Halfway through the release cycle and it would be a real nice if a key script support would be added in system D for Buster, I Mean that would we have this this has been a outstanding variation for Yeah to to release now, so It broke a lot of setups I think that most people have a walk around for in place now But I don't know if we switch from in from FS tools to some other in authority system That will break again. So I mean that's something that Like that needs Action another thing is I'm internally internalization and accessibility respectively for people that don't speak English and people with visual impairment Because at in the first at each of the first stage Well, it's there is no get tech support and there is no beep But yeah, so we have a bug open like wishlich burst bug open to have To add get tech support into each of my first That's the first stage and then we can start to localize our password prompts another thing we are working on is the uke looks new feature that's something where you can Use a special passphrase to wipe all your key slots so that's there is a patch in a Kali Linux for that and And But it has not been merged into a trim yet, and I think a trim doesn't want to doesn't like that feature But well it can be useful in situation where one is forced to unlock the The disk say and the attacker has not made down Backup of the header because of course if the attack attacker has done a backup of the header Then he's game over. He doesn't help Another feature is another feature working on is a luck suspend. It's something where we are Where we freeze the IO on all active encrypted devices before suspending on RAM And why the encryption keys from the from the memory So and when you resume you land into a TMP FS C at root that contains the crypts the binaries and you are prompted into For your password so that you can unlock the disk So one thing I should mention about this feature is that it only protects Data at rest because well all your data that's in memory is still there. So if someone takes a memdump Then it would have access to all your data that's in memory, but not your key because it's white and usually Like the well your GPG key or whatever you can flush it before your suspenders also So those those this key material is protected, but the data at the rest of the data that's in memory is not protected Yeah, all right, I should mention what's the state of this so It we got it to work, but it's not ready for like adoption because The the kernel insist on thinking before suspension and If you have outstanding IO on the encrypted device this Well, there is no way the The kernel can I can sync so it will just freeze forever and then fail to do suspension So I have you know Can just briefly briefly talk about this new and this format Lux to It's as I said the new on this format. It's right now if you you need to if you want it you need to format with Type equal Lux to but conversion is also possible. Although You don't benefit for from all Features from Lux to if you are converting from Lux one. It has a new key derivation function Which is the memory hard KDF called argon to it's the winner of the password hashing competition Another nice feature is the to have backup headers So if usually the header is at the beginning of the disk So but if the first sector is I don't know damaged Then you lose all your data all your disk So if you have a backup header at least you can retrieve that so that's pretty nice feature And another nice feature is to store the encryption key in the canal caring so that they are not accessible By user space tool and So upstream gave a talk about Lux to at first damn this year you might want to look at it There are a few other nice feature But they are more experimental and they definitely won't be present investor one of them is authenticated encryption So this is not something that's possible with XTS for instance, or any kind of Format that like length preserving on krypton mode because there is no way you can store the the authentication data but upstream developed a new DM module called DM integrity and use that to store per sector Integrated information and The real thing is so if you know a bit of crypto, you know that it's usually very bad to use the same IV to you to encrypt the same data using the same IV and the same key and But if you are using If you are using a Like a length preserving mode such as XTS there is no way you can have a random IV or have a sequence like change the IV So there's sort of the IV that's used in XTS is the sector number But with this new DM integrated thing you can use a random you You can use a random IV instead also so it's pretty nice thing and Yeah, well with that said I think that's all I had to say You can contact the team at this address and If you want to contact me probably you can contact me at this address and that's it Hi When I use looks There's I did not find there is any good way to pass To use a smart card. I use a way to pass pass a decrepit it Which mark out are you talking about what which smart card are you talking about? I'm you now using clue can look. Yeah, that's open PGP then. Yes, so we have a wait a few weeks. It's a being worked on right now I don't have a bug number, but Check on the BTS and you will see there is a bug number like a bug number It's a bug open for that and just wait a bit and it would be it will definitely been buster, but yeah Not how long well it takes It would be in buster wait a few weeks or subscribe to the bug and yeah, okay, thank you so much. I Was curious Why you chose to Warn about an insecure you mask when there's a key embedded in the in it ramfs rather than Changing the you mask Yeah the reason for that is Yeah, I thought about doing something like this, but Let's see Just drop their installs account in it ramfs tools configuration hope it does. Yeah, but you must Right, but drop there. We drop there is Unconvicted like with rubber you always want to secure your mask because you always have keys there While there you if usually the most common I mean usually the key file pattern thing is empty. Yeah, you don't have keys to store and But I think it would be possible to implement a logic where you had test and then you said the you mask Because after all that's just source key source shell files. So that should work, but yeah, yeah Yes, that's probably a good way to do I don't know. I don't remember if MK need to my first source is the hooks config also It's the separate set of hooks that yes, exactly. Yeah, so that's that's it. We will need to add a new file Yeah, okay There was another thing I was just about the the local support in the net ramfs Don't you might have missed it? But I actually said can you send this as a can you really send this as a merge request and then oh, we can do a Okay, I guess I missed it. Yes. Thanks. Okay First thanks for all the work you've done encryption of our laptops is very important for security and then So you said that We may convert from Lux one to Lux two. Yes So Lux two is a feature only of poster, right? Yes, all right. And then first, how do I do it? And second question is You said mentioned that we lose features if we just convert what you're doing is so So, how do you do it you? check the crypto man page and there is a like a New trips it up convert dash dash type equal Lux two And then you run that I don't I think you well you need to close your device first But you can do it from the internet fast for instance So the only thing it touches is the header. It does not touch the the rest of the data at all So what you miss you don't have a backup header So you still have a single header at the beginning of the disk also The You the the encryption keys are not stored in the canal caring I believe so the canal caring is disabled by default and the default KDF so Lux one is using the KDF in Lux one is hard-coded to PB KDF to and that's when you Convert you on you don't need to unlock your disk when you convert So the KDF is preserved, but you can upgrade the KDF to Agon to what you need to do is to add a new key slot And then remove the old key slot, but yeah, so it's if you want to upgrade to a new KDF you it's It's a two or three stages process Yeah, the thing that's all yeah, the thing also that you will miss is Authenticated encryption and this random IV thing But anyway, those are experimental right now and I should not be using production And they definitely won't be ready by by the time person is released Question concerning the drake out in a drama first generator that other Disciplines are using if Debian would move in the long run also to drake out would it be an advantage for you or just Not so I Mean so right now I would really strongly object against it because of this key strip thing so because People are using that and They had been so we have this suggestion and We told them okay, you can the work around is to unlock your device at the intro my first stage But if there is no work around then I mean that's fairly bad and I Don't know but if that's fixed, I don't have I don't I never tried to break it myself. So I don't have an opinion it's probably better at at like building the dependency graph than the Than the intro of s tools just in the same way that send is better than she's been it for that but Yeah, I don't know like I never use that It's one minute left Didn't so my question is if Debian currently has much more features for crypt setups than drake out so that was I don't know. Okay much more. No, I don't think that will so no I think for creeps that up. I don't think it will gain feature. It it might be equally good But I don't think it will gain feature So for both in the drama fest tools as well as for drake cut you can use Plymouth as you install it It will work with key scripts. You don't need to use it to display actually the splash Yeah, that's basically it and Just repeating what Thomas said sort of As long as group set up only supports in a trauma fast Then any trauma fest tools is the defect or any trauma has generated and I think we should have an option to change it But that's supported you can use drake out with creeps that up, I think and I think that's it I guess