 Now we have Bandy here from Cowspot Essen and he's going to show us how we can hide our data when we really need to hide. So have fun with Bandy. Hi, I'm speaking about my project Panpanic. It's about nine months old now. And yeah, I'll tell you what I'm speaking about today. I'm speaking about the very old problem, how this project tries to solve this problem in some way. A little crash cause about Lux, this encryption system in Linux, how Panpanic will interact with Lux. How it might help you in some situations and when it can't help you. And I'll show a live demo how to configure it and destroy a VM. So this old problem is us being the security hole. You might know this XKCD comic, which shows exactly this. But the question here is how do we get out of this situation. For Linux PAM, I had some ideas. Getting out of this, it's some great. Maybe you should know PAM is the authentication module thing which asks for username and password. Yeah, I put my project in there to interact with Linux authentication things. So how do we get out of it? We should make some assumptions about the environment. We have to live in a constitutional state because then we have the ability to deny things. Because this project, it builds on the vulnerability. Also you should encrypt your system. If you use Ubuntu, for example, you just tick the system, tick the box for system encryption and you've got Lux. Take two passwords and two GPT-formatted devices as SD cards, if you wish. Those are used as authentication and the question is why, too, you can read. One is for authentication, the other one is to destroy the key slots in Lux. What is a key slot in Lux? I made this nice thing. We've got the big master key, it's the black big one. We've got the eight slots, the rainbow colored things here. And yeah, those are used, those key slots for the user. So the user uses its key, maybe password, maybe something else. If you're an advanced user, you know how to configure it. This used to unlock the encrypted master key, which is then used to decrypt the Lux container. Yeah, that's how it works. So this is how Lux looks like on the hard drive. We've got the partition header here. And there's some information about how the master key is, what modes are used for the master key, the cyber mode, the key link and some other stuff. And also some key matrix slot information, the keys for the user and they say how to decrypt the master key also. Also, we've got the key matrix slots, that's what I said, the user slots, you can have to eight, as I said, and we've got the bulk data, the container where all those encrypted stuff, the system is in, and yeah, that's how it works. So when we have one to look out the bad guys, Panpanic will execute crypts at the Lux erase, which I looked up in the source code, it actually puts some random data and makes sure that it's not, that you can't get those keys back. That's a good thing and that's what Panpanic is using. And yeah, if you want to be sure that you can back up those things, you should make a Lux header backup, it's about two megabytes of data and doesn't fit on the floppy disk. Yeah, WED might help, I'm quoting Udo Vetter from an earlier talk, where the police tried to stress the rate at once, saying give us a password of your encrypted file system or yeah, the forensics will get it anyway, so give it, no, nice try. Also being forced to type or tell you password lag on borders, I've never been to the US, but I heard it's a common practice there. What won't help is cold boot attacks, people making your device without any electricity and put some freezing stuff in there and yeah, you know the attack, I guess. That's the part of my presentation, I will now make the live demo. My password here is ASTF, so you know. Well, I've installed Panpanic via Ubuntu PPA, we've got a fancy logo, which is not that fancy. And I've got this configuration program using bash menu dialog, so you have the ability to use a media device or password. I will do media devices to show how the media device thinks work. I fixed it a few days ago because it didn't work after another big bug fix I did, so yeah. So I've got to rise it, asleep. So I've got this in the configuration cache now. I put in the Panic device, so I've got here the device for authentication, and here's the device for the Panic, issue of the Panic. So this question here is about destroying the thing you could also say don't destroy it, just reboot. We will destroy it. We don't make a header backup because we don't need it here in this session. Also, I will issue a reboot here. Street mode is like if the Panpanic configuration is corrupt, it doesn't let you in, it doesn't let you lock into your system. So here are some hints how to integrate it in your Panconfig, so we need another terminal. In Ubuntu, I have this common auth and common account thing. Common auth, just put it here. Oops, first include, of course. And the current part, I don't know why they put those things apart. So now we have saved our configuration, it's active. So the first thing you will see is the question of the key. If you use a password, it will say password. So I'm using the Q4 authentication. Of course I've got to put it through the VM again, which is very annoying to be honest. I will press enter and it doesn't work because it's not there. Now it's there. So ASTF and I'm in. I do it again and then the VM will have a disruption thing. And you will see. So I put in the Panic key, the Panic Donger presenter. Oh, I should again put this through here. So it seems to work now and it reboots. ASTF and I successfully destroyed my VM and I'm done. So this was it. There's some time left for Q&A if you have some questions. Thank you, Bandy. Have some applause again. So if you have any questions, please come to the microphones in the room. Yes, please. Thank you for this. What do you think would be a more advanced method to secure your system against a call start? Because this is like the middle solution. Yeah, between somehow securing it and not securing it at all. There's a way to put some lingux, some arguments to let the system make some... It's called memory poisoning. It will put some stuff in the memory which a bit of it secures your system to put out the RAM and read it. So it will make some random data into the RAM and makes your RAM not readable to code put attacks at least if they don't pull your device away, of course. I would ask the signal, Angel, do we have questions from the Internet? The Internet is not distressed and has no questions. Probably still asleep. Okay, then to my left, please. Hello. Thank you for your talk which has been very nicely presented. But in your system, the attacker knows that you gave him wrong information because afterwards the information is gone. He gets a very obvious error message that no data is present anymore. What do you suggest how much work would it be to, after destroying the original partition, have a decoy partition with some not-so-sensitive data on it? Yeah, you could do such things, of course. You also have the ability to configure looks that way, but you have to do it manually, that you have a partition where just your system is unencrypted, for example, or you have it encrypted. It doesn't matter. So, for example, you have a root file system and a home file system. You can configure Panpanic that way that you can just destroy the home partition, for example. So, that's an example of how it could work. Okay, then another one on the right. Is this forensically, do they see what you've done? Is it either written like a random new key that you do not know, or is it like just random data? Is it forensically determined that you don't know the key or that you've actually messed with the system and therefore might have tampered with evidence? You mean the Lux destruction part? Well, it's part of Lux itself. So, it's just put some random data in the small Lux key thing. I read about some special destruction parts. I'm not sure about this, but it's, well, as I've understood and as I've read the source code, it's okay and secure. I don't know if it answers your question. Not really. Is it distinguishable from a normal key that would have been in there? Is it distinguishable from a normal key that would be in the Lux header, the random data? No, so, yeah. So, if you saw the destruction was done, there was a Lux header. It sees the Lux header. Okay, I've got Lux here and it can't read the keys anymore. So, that's the part. Okay, any other questions? I don't see any, so let's have some thank you applause again.