 So good morning, great that some of you made it on the first slot, my name is Tim and I'm gonna present you the project Closelet to Encrypt. Thank you for giving me the opportunity to speak here in front of you. So what is Closelet to Encrypt? It's a project by Jonas Maurer and me. We are both freelancing system engineers living in Germany and we're planning to bring full disk encryption into the suspend mode for DBM and hopefully it's derivatives. So why is it useful to you? Full disk encryption only protects the data while it is at rest, which means when your system is powered off, which for most people is like very little time anymore because they just like close their laptop and take it somewhere. So we're trying to improve this time span where your system is protected to all the times when it's in suspend mode or sleep mode, just the same. And hopefully this will save your data at night or while you're on the move or while your laptop is on a train or something. So first of all, why is this even difficult? Well, we're locking up, we're locking away your running operating system. If this doesn't sound difficult to you, like you, it was difficult to me. So there's all kinds of race conditions that can happen. Since we've locked away all of your file systems, the kernel might want to access it because some process is requesting something that would be like the file on your system. So we have to make sure that we really know what happens before we enter the suspend mode and after we resume and that only processes access some data once we have unlocked the system again. Well, and then there's the thing that usually memory management is transparent, which is great, you don't have to care if you're developing an application. But since the swap space is located on your hard drive, which we will encrypt and lock, and the memory is actually unencrypted, we have to be sure what part of the memory is located where. So since this is the dev room, I'm gonna dive in right into the details of how we implemented this. So system D is standard in Debian nowadays, so we start with a drop-in unit for system D and we override the command that happens on suspend mode. Usually it calls binary call sleep.c and we override it with a wrapper for our purpose, which we call clip set up suspend wrapper. This wrapper then uses the inner drum of S that you have already used during boot. I mean, that's, I'm guessing you have a full disc encryption here, right? So otherwise, all this doesn't make sense. So we're reusing this and loading it into a wrapper in your memory. Then we're using the unified C groups hierarchy to transparently freeze all of your processes. So every C group has something that is like a freezer attribute and we just call it to freeze, something system D tells you shouldn't do because it's like interfering to all kinds of processes, but it seems to work quite well at the moment. Then we change root into the rum of S and we call our own binary crypto depth suspend. So what this does is it first locks a lot of memory because we need a lot of memory afterwards because standard key derivation hash function is argon to i, which is memory hard, which means it needs a lot of memory. So we have to make sure the memory is actually available. Then we're telling the kernel to not sync before a suspend. There's a attribute called sync unsuspend. Then we manually sync the system, meaning writing everything from memory to hard disk that should be written there. Then we do the lock suspend of all your locks devices and then we tell the kernel to suspend, which it then does in the way that it usually does. So what is this attribute? Does power sync unsuspend? Yeah, it's our first accepted kernel contribution. We were very happy. It was a long way. It's a tiny patch, but it's coming in actually the next release in 5.6. It was a very interesting exercise in interacting with the open source community. I can tell you later if you're interested. Basically, it is runtime flag that tells the kernel if it should sync before suspend or shouldn't. There has been a built-in flag before, which we obviously couldn't use because we're aiming for upstream adoption. And not everyone wants to use our program, probably. So going back into the details, the kernel has suspended and now we wake it up afterwards. It resumes. It gives back the power to the process that was running before suspend. In this binary, we unlock all the devices that we have locked before. We go back out to the wrapper and basically we just reverse everything that we did before. We even unlock your GDM session or something. Okay, so since I have very little time, I had to pre-record the demo. So I hope that you believe me that it does what I will tell you. But otherwise, I have been running this, like it's running on my system right now so you can also check later. So here I am, mining my business. I'm suspending the system there. Yep, it's suspended now. I'm sending ACPI command to wake it up again and I hope you can see it asks for the password of your encrypted device. It could be multiple devices. You could use all the functions that have been there in the crypto package before. So can you use key files, like special security keys or whatever. All right, what's next? So we need to do more testing, right? The suspend mode is something that is very particular. So we have to test it on all kinds of different systems. And we hope that maybe some of you will help us with that because we're very soon gonna merge the code with the upstream crypto package. So that in Debian testing, you can then just up install crypto minus suspend and it will transparently encrypt your file system when going to suspend mode. We're waiting basically for the new kernel to come upstream as well or to be released so that it makes sense that you can actually do some testing without compiling your own kernel. Then there's this very tricky situation if you are low on memory. As I said, argon2i, it needs about usually one gig of run when unlocking device, which you might not have. So if you're very knowledgeable about kernel memory management, please talk to me. Obviously, there are more secrets in your memory than just the lux keys. So we were playing to include some scripts to get away some of those secrets as well. Yep, and then I want, I'm short on time, sorry. I want of course to thank the original crypto authors. I want to thank the crypto maintainers who had the idea for this project. Gillem and Jonas, whom I've been working with, which was really great. And they're having people trying to tackle this problem before. I think our approach is the most advanced one, but they have done great work as well. And last but not least, I want to thank Prototype Fund who has been funding this project in the last five months. They have a new round open. You can apply if you live in Germany. They fund open source work. And yeah, if you're interested, you can visit our GitLab repo, open some issues or send the email personally. Thank you very much.