 Ladies and gentlemen, is everybody up for an exciting round of spot the Fed? So who would like to spot a Fed? Raise your hand, please. The lady in the back with the pink hair. Come on down. You have to bring your Fed with you, ma'am. Oh, he's a Fed. All right, we will get the session going now. I want to introduce Thomas Munn. He is going to talk about data hiding in Linux. He was going to talk about BSD, but that half of the presentation team isn't here. So here's Thomas. Hi, thanks for your patience. Unfortunately, TGR met with circumstances beyond both of our control and cannot speak today. So his stuff is in the presentation for those of you who are BSD people. Unfortunately, I don't want to look kind of silly because I don't know a huge amount about it. I've set up IDS sensors on it, but I am beyond that not a BSD guru or God. So with that, I'm going to begin. Before I begin, here's some interesting devices. This is a 30-gig USB 2.0 hard drive. It's $150, and it's available based on, and I don't know who they are, but this is where I bought it, based on computers.com, and it's an incredible little device. It's 30 gigs, and it's about the size of a pack of cigarettes and weighs about six or seven ounces. It doesn't cost like $400 like a lot of the available USB drives. I'll tell you what these are for later. This, you can't really see, is one of these USB key chain fobs. You can get them in capacities ranging from eight megabytes up to one gigabyte. This version is the eight gig version I bought at CompUSA for $30. Eight megabyte, sorry. Anyways, this is actually an unrelated device, but my prototype for this whole project was a Nomad. Originally, I wanted to be able to store a file system on an MP3 player, so that I could keep my data on the MP3 player and have it look like an MP3 player when actually, in fact, it was a data storage device for more than just MP3s. So anyways, those are just the three devices of interest before I begin. Basically, I don't know if any of you have been through layoffs, but I've been through five now, and when they happen, especially if you're in the security industry, they happen very quickly. Pretty much, you get in in the morning and they say, you are terminated. They don't even say that. They try to get all the passwords out of you first. So if someone starts asking you for all your passwords in your security, you know that there's probably a problem. But anyways, so what happens is you get in and they essentially, they just give you a trash bag and you start filling your trash bag with your personal effects. If you have any personal data, and I need to stress very strongly that you should not be using this to save your employer's data on your hard drive illegally. I strongly advocate that you do not do that. Network diagrams, things like that, are property of the company, and as an ethical and practitioner of security, you have no right in keeping those documents. On the other hand, if you have databases and general information which you gather, which are not of a specific nature to your employer, it's just for me it's an ethical thing. I don't like them to have my problem solution database that I've been collecting for the last three or four years. I keep a database of all my solutions. That's my property. It's not theirs. So it was in reaction to this that I did this whole presentation. I got to the point where I wanted my data to be my data. I wanted my programs to come with me. I did not want to have to worry about if I were laid off suddenly and arbitrarily having to try to back up data which they wouldn't let me back up. So this is a whole context for this project. I'm going to stand up. Basically, there's a number of ways you can do this. You can use USB devices. You can use encrypted file systems. One of the more interesting ways that they do it is actually through wireless cards. Basically, you use them in ad hoc mode and you have a mini network of two, which is the computer that you have and the computer that is out in a location. You can transmit information through that channel using either the loop AES or other encrypted mechanisms. That's another interesting way. That was Will's side of the story. Basically, that's the part that we're not going to do. You see my presentation. Basically, employers will eliminate you quickly. You will not have any time to back up your data. You use a USB or removable device that stays with you and encrypting that data ensures that if someone steals this, your data will not be accessible to them. So if you've got some personal or email or anything like that that is of a sensitive nature, you can use this device to essentially make it very hard or very expensive for either whoever it is you're trying to prevent from getting your data. It's a very expensive process. I looked at a number of different packages. There was originally what they called the kernel patch for Linux, which was actually compiled into the kernel. But you had to patch the kernel each and every time you upgraded your kernel, which is something of a pain. I don't know if any of you have done that. I can't use it with stock kernels. For instance, if I'm one of those people who doesn't like to compile kernels, and there's plenty of them, you can actually use this product without recompiling your kernel, which is kind of nice. You just use the source code tree and I'll get into that later. So that was one of the reasons for choosing a module. Another reason for choosing the module, this is a special version of loop.o. It has the AES bindings built into it so that if they don't have a loop.o module, then they can't even decrypt your data. So if you keep the loop.o module on your device and mounted in an unencrypted partition, and then insmod and force it from this as opposed to the actual hard drive on which your system, the person who you're trying to protect your data from doesn't even know you're trying to protect your data from them. I mean, there's no real indication of the fact that it's on the system. Adding GNU PG on a device like this even increases your security further. You essentially have your private key as well as the encrypted password on your key chain USB, which is with you at all times. So that even if they get a hold of that, they get a hold of the modules, they still have to get a hold of this in the keys and they have to know your private key password before they can get into the device. Basically you can obtain the loop-AES sources from SourceForge. If you just go to SourceForge and type in loop-AES, it will in fact show you the appropriate link. They upgrade it fairly frequently. I'm rather pleased to say that in the process of the upgrading, they do not break. So you can actually have a loop-AES 1.0.c and loop-AES 1.0.6.f, and you can still read the file system. It doesn't break the file system from rev to rev, which I've seen other products that do do that and it's kind of nice because then I don't have to redo my encrypted disk every time. When loop-AES actually has really good documentation, read the readme before you do anything. They tell you exactly what you need to do. Everything in this presentation and a lot more is actually covered in the readme. It's very well documented. One thing that they tell you that if you want to get started real quick and you don't want to bother reading it, compile your kernel first. In other words, you don't have to install it, but you at least have to do some basic kernel options. You cannot compile the loop back file system into your kernel and you just do that and you don't have to worry about the rest of the modules because that's the only thing you really want. If you're already doing a kernel from scratch, I mean from stock, if you don't like to say you're using Red Hat or one of the other 17,000 different versions of Linux, I bet you could even load the module into BSD using the Linux compatibility mode, which would be an interesting thought if somebody actually wants to try that, but I don't know how well it would work because it's kernel space that might do really bad things to your system. You also have to get what's called the Util Linux collection, which contains a modified mount and low setup utility. It also contains some modified man pages which tell you how to do things. What you do is you essentially, you get the loop AES source, well first you compile your kernel, then you get the other, then you get Util Linux. You place it, you untar the Util Linux, then you take the Util Linux and you put it in there and you untar it there and then you run their utility and there's a patch, you have to actually run a patch and then you do the make and follow the directions and you're pretty much, as they say, cooking with gas. So basically the first step is patch Util Linux after you've untarred it. Go to fresh meat if you don't know what Util Linux is and just type in Util-Linux and you can get the source code. So you basically do patch minus P0 less than patch file name, assuming you are in the directory which contains the loop-AES source. So in other words, if you untarred it in temp, it would be slash temp slash loop dash AES dash blah, and then you would do patch minus P0 once you were in those directories. Again, follow the readme and do exactly what it says. It really, I felt kind of dumb because I screwed it up and I messed up a kernel or two and I couldn't boot and if I just read the documentation, I would have been fine. So save yourself a lot of pain and read the documentation from top to bottom before you do anything. I'll say that, this will be the last time I say that. So you patch Util Linux. Again, here's some gotchas. Loop AES requires that loopback support not be put in the kernel. If you put loopback in the kernel, it will not work. Make sure that you are using the correct kernel version before compiling. In other words, you have to make sure that whatever kernel you want this thing to work for is in fact the kernel you're booting from. Now, what I did with one of the stock Red Hat systems as a test was I took whatever the current one was, undid their source code from it and what happens is if you don't actually compile the kernel yourself, it will complain. It will say, this will taint the kernel and I'm not going to use it. So you can force the kernel load with no detrimental effects to the system. But you have to force it and there's a couple of scripts which I think I included in this presentation. Anyways, so that's just one. You have to be obviously root to install kernel modules. I mean, I figured all of you would know that but I just wanted to put it in. You must do a make menu config before compiling loop AES. In other words, choose your appropriate kernel options and make sure that you choose the right processor. Your kernel won't boot. You must compile USB in the kernel as a module. I had horrible time when I put USB directly in the kernel. There are order dependent things that need to be done in a certain way for things to work. If you put it in the kernel, the USB-UHCI module will load before the modules that you need and you just can't control the order and you have to control the order. Now, if you use a stock Mandrake, Red Hat, Suzy, or any of them, it'll probably just work out of the box. When I did it, it was on my old system with, you know, I'm an old kernel person and I've been compiling kernels since 91. So I tend to compile my own kernels. But I just tried it for, just for one's sake, is it doesn't work from it. So, anyways, so basically this is the hard way. So you have to compile in SCSI support as a module. You have to compile in SCSI generic modules, the disk modules. You need the USB-UHCI, or if you want to use the high speed version 2, you'll need the 2.5.29 kernel series, which also has USB-OHCI, which supports 400 mega second. Default speed for the USB device is 12 megabits. So you're looking at about a megabyte per second transfer when you're actually storing things. Like, again, for USB 2.0, you will definitely want to use 2.5. Again, it's experimental, use it at your own risk. Installing USB, this is, again, for those who like to do it the hard way. You have to install SCSI, SCSI generic, SCSI disk, USB, USB-UHCI and USB storage. After that, you can do your, you can manually put in your loop.o. So for instance, after you do all the modprobes, SCSI, modprobes, SCSI dash generic, et cetera, et cetera, et cetera, you do modprobespaceloop.o. And of course, if you did it the way that I described with the stock kernel, you would need to do intsmod and then minus f, followed by the path of where the loop.o is stored. Again, that can depend highly on system. I recommend using a way to the jet passes. Anyways, so you can just do that wherever you want. Again, the, I wasn't going to say see the website for those scripted world modules, but I haven't had a chance to update my DNS. So anyways, I can provide that script if anyone wants. It's pretty simple. Basically again, follow the lead me that comes loop.es. The first thing you want to do is run low setup to set up the device. The commands are in the lead me under getting up file system using GNU PG that this is the particular architecture that I found or single user system is the best. There's a lot of other scenarios that cover how to do encrypted swap, how to do encrypted file systems for different users, how to do, you know, they cover a wide range of options. And for those of you that don't want to use GNU PG, you can just use a nice 40 character password if you're using AES 192, which is what I recommend. 256 is a little too slow and I think a bit excessive because I mean, you know, it's the top end. But the 192 version, you have to type in a 46 character or 40 character password minimum. And you get one chance to type it. So if you type it wrong and you forget it, that's it. I mean you type it once, there's no verification. You just run low setup followed by the password and hope you type it right because if you type it wrong, it's pretty much useless and you'll have to start over again because you won't be able to mount it. Again, I recommend manually mounting the file system to test it. You can try doing, they have a nice part where they talk about using FSTab, where you just put, you know, the device name, which can be a file. This will be like slash mnt slash file one, which is the actual encrypted low setup device that you created. Now, all setup can be used in several ways. It can be used on files. It can be used at the block level. In other words, I can do low setup slash dev slash sda one. I can actually set up a device instead of just a file. So the entire file system is encrypted. It's not even just a file, but the whole file system is loop AES encrypted. So it's just absolute garbage and it's not a file. So then you can even obfuscate what type of file system it is until they actually know what the encryption is. So you can use like a mega file system if you really want to be obscure and really make things difficult because you've got to know, I mean, yeah, you can look at the header, but I mean, the average person who would probably be trying to do that probably wouldn't think that. If you can eliminate 75% of the un-clever people in the world, you've done a very well job. So anyways, keep all the scripts and modules on a separate removable hard drive. Keep GNU, PG on a USB key chain. Don't forget, back up your USB disk, because if this suddenly drops from a very high high down to concrete, all of your data will be gone. So I recommend, there's several ways you can back up. If you're using a file, it's really easy. Just copy the file to a remote media. If anyone gets a hold of it, so what? They can't do anything with it. If you want to actually do the file system, you kind of have to un-encrypt the data. You know, while the file system is mounted, you have to back it up, make it tall, and then if you're really worried, GNU, PG-encrypted and store it on a CD or Dattape or whatever it is that you used to back up. Basically, what I do is I actually have on this guy, there's three partitions. The first one is a Windows partition. Don't tell anybody. The second one is just a device-level encrypted EXT3 file system, which is actually not really. It's a loop AES. I used LO setup to set it up. And then the third is un-encrypted, and I keep the keys on that just because at the time I didn't have this. And for those of you that don't want to spend the extra money, it's a slightly more convenient way. So what you have to do is you have to go to root because you have to be root to do all this unless you want to set up sudo or make the route mountable by users. But basically, going to root, you sim link the .gnupg directory in the root file system to the place where you store your gnupg keys to decrypt the file system. So that way you don't have to do any... You don't keep any of the public keys on the system. That's the whole purpose of the exercise. You basically... I mount the USB hard drive on like home slash user name, whatever that happens to be. And I create a script that automatically mounts the disk. And again, that script... You can do one of two ways. If you want to do it conveniently, you've got a shellcode compiler, and you write the script, you name it something obscure, and you shellcode compile it, so it's just another binary. So you name it like ls1. So like for mounting, for instance, you'd have ls1. For unmounting, it would be ls2. So if they look at your history, they say, oh, ls1, and it doesn't print anything out and you really don't know what it does because you just turn all the echoing off. And so it's fairly obscure. And it's still convenient, so you have the scripts on the system. If you're really paranoid, you put it on here and just shell script format. I have a start and end script, which I keep unencrypted on the disk because I don't really care. I'm not that paranoid. So I log in this route. I type in start. It asks me for my GNU PG phrase, which actually I haven't migrated yet. It would look here for it. And this is a... You can also send link to this. I mean, whatever your send link is, you can create it to where your keys are stored. Now, there's two keys. Well, there's two parts of it. There's your private key, which is used to decrypt. Then there is the actual encrypted 47 random... Like you take like dev random and you actually cat it to a file and then you encrypt that file with the GNU PG. You have to make it ASCII or it doesn't work very well. But so you actually like dev random. So you're actually using a fairly random password that's 47 or however many characters you want. There's a nice little dd hack. I think I live... I don't know if I listed in here, but it's pretty cool because it actually creates... It's in the documentation when you get the loop AES package. So you can set your box size to 104 and have a 104 character password if you really, really, really, really want to make it hard for someone to get it. Again, erase roots bash history. If you're really paranoid, your dot bash history has absolutely everything. Or whatever the other one is dot history. I don't... If you're using Sun, although if you're using... Actually, if you're using Sun, you can use Linux. Anyways, I either link it to DevNull or have a script at the end script it greater than roots bash history so that it gets rid of any evidence of that having been used. Okay. Here's the hardware sources again. The 30 gig USB drive is www.basoncomputers.com. Now, they're friendly Chinese people and don't ask them how to get this to work in any Linux, but it does work. I actually have made it work. With a modern USB kernel, it's just plug and play. In fact, it even unmounts it automatically if you just unplug it. It's kind of cool. The key chains, you can Google USB key chain. I like the T-Rex one because it's really small. It's small and it actually has a little key thing on it. There's about 14 different ones you can get. You might want to get a USB hub, especially if you're using this because you've got to plug it in the back of the computer or you have to get one of those stupid extension cables. So I recommend a four-port USB hub. Now, even better is if you get a USB 2.0 controller. Now, some interesting things I've found. There is a new USB 2.0 PCMCIA card available. It's $60. And what you can do is, so if you want to be cheap, you buy yourself a PC card reader for your desktop and you plug it into your desktop and then if you want to use it on your laptop, you just plug the USB 2.0 into your laptop. So it's kind of a portable way to take the USB 2.0 with you without having to spend $60, you know, the N plus one for each one you want. You have to buy the controller. The only thing I have not tested because I did not have a chance to buy it, whether or not it actually works under Linux. Now, I do know it uses the one that I found was a, I can't remember it was ATEC or something, ATEC. And it uses the NEC chipset which is reputed to work in the kernel traffic. And as of the 2.5.29 as of yesterday, supposedly has been listed as working. I've not tried it, so don't hold me to that. But it's ironic to think that Linux will probably have USB 2.0 support before Windows. Anyways, since the file system is encrypted at the device level, you can put stuff on NFS drives and have the contents be secure from eavesdropping. So for instance, one of the applications that you can actually do is have an NFS drive where you keep your home directory. Say that you've got NFS mounts and you don't want, you know, Joe Blow, system administrator who you don't have any control over working at your stuff. So you create a happy little file system that you mount with a low setup. Now obviously, if you don't have control of your workstation, well, you're out of luck. But for the most part, if you can do a boot or, you know, run any kind of, well, not that I would ever advocate hacking a SolarisBox, but it takes about 10 seconds to get root on a SolarisBox and install your own modules, although it wouldn't work on a SolarisBox because it's not Linux, but anyways. You could actually GAC put it on an SMB file system. So you could actually use low setup. Set up the file system across the network on your Windows network and use low setup and mount to mount the file system using SMB. You could do the same thing for Netware. You could use the same thing for Andrew. You could do the same thing for any kind of a disconnected, any kind of a file system. So you, I mean, for the, you know, so it's really powerful. So you can essentially have trusted data on an untrusted source. Now the nice thing is when the data is being sent across the network, it's encrypted because it's going through the loopback driver. What happens is the data, essentially, it goes to the unencrypted of the loopback device. The loopback device encrypts it with AES and writes it to the device so that no matter where you're writing to, it's always encrypted. Obviously if someone has access to the local system, well, no. Or yes, and now here are some caveats. If your loop file system is mounted, it is vulnerable. It means it is unencrypted and can be readable by anyone who has read access to the system. Now you can use file system permissions in Unix to make it 7-0-0 and protect it a little better, but again, that's subject to the file system permissions in Unix. Another thing you need to bear in mind is that if you lose your key, you have lost the data. It's pretty much history. So back up your keys. In fact, media like this are nice because you can put a write protect tab on this. And you just put it in write protect mode and it's flash media. It's not being rewritten. So it'll practically never wear out in theory. So that's a nice thought for... They're durable. You drop them. Who cares? There's no moving parts. You drop this, you're in trouble, especially if it's moving. Again, another thing, another thought. Devices like this. For instance, the Terrapin mine. You can use those kinds of devices. You can use PDAs. Removable, accessible storage with a removable, mountable file system. In other words, all these devices that you have that can do Windows SMB you can use to store the data. So your form factor is practically unlimited with this application. Again, you can do it across wireless. You can do it with this. You can do it with this. You can do it with a one gig key chain. So your options for where you want to store the stuff, you can store it on CDRW if you just want to have a CDRW drive. And... Okay, other possibilities. Foppy, zip disks, jazz disks, avoid they do tend to eat data. Encrypted root file systems. You can actually have the root file system before you even boot the system being encrypted. So if you're truly paranoid and have a laptop, you type in a password before it'll even boot. I mean after the BIOS password, which of course you all put on your laptops, don't you? You can swap for those of you worried about what goes on in your swap and whether or not it can be read. Again, view the readme file inside of loop dash AES for even more wonderful ideas. And this is the part where I actually will I stop because this is the other option that I did not correct. How much time do I have? What time is it? I have 30 minutes? 25 minutes? Okay. I'm going to open you up for questions in a second. I'm going to cross a very cool utility on FreshMeek two days ago. It's called SMB, I mean PAM underscore mount. And what it does, I haven't used it yet, but it allows a user to mount a loopback encrypted file system automatically upon login. So all that nasty stuff that I saw about logging in this route, you don't even need to do that. You just log in as your user, you type your password, and in theory it'll mount your file system. Be aware that the character password thing though might be a problem because if you only have a miniscule eight character password loop AES will say go to hell and you're not going to encrypt this because I need 40 characters. So you, you know, remember your famous quotes and things like that for passwords. They make very good passwords. Anyways, well at least they did make very good passwords. Again, so that's SMB underscore mount is a very cool thing. And like I said, I've been using this now for months. Like I said, I go in the morning, I mount the device, I save all my stuff. The only time I ever notice the fact that it's only a megabyte per second is when I'm compiling source code and I forget that I actually am on the system. Or when I'm copying things from it that are not, you know, anything more than one megabit. Obviously copying a 10 megabyte file from that file to say temp for whatever. That's the only time I notice because its file system caches everything. So you really don't see the performance penalty. Another thing is I highly recommend using EXT-3 on any kind of removable device. FSC cane, a 10 gig disk or a 30 gig disk can take years off your life. So I highly recommend that you run a journaling file system of some kind or some kind of a soft update system because these things can be disconnected in moments notice. Again, the USB 2.0 option is very cool because this goes from 1 mega second to 7 or 8 megs a second. For processor, I have a 1 gigahertz Athalon and I have not noticed any significant processor utilization even during heavy disk access 2%. With no difference, I benchmark the non-encrypted, this is the encrypted partition so at one megabit there is no system slow down on a reasonably modern processor. Obviously the libretto would probably be a different story. Other than that, this thing is kind of cool because it comes with like a little case and a nice, well this is the yucky Belkin one but they actually come with a really nice cable that's really long so you can just take it with you and in addition to using this thing for your you can have all your analysis tools on this and you just plug it into your compromised host, you've got your statically linked versions of all your utilities and you can use it for forensics. Anyways, I feel like the ginsu commercial. Anyways, do you want me to open this up for questions now? I'm pretty much done if we're an active group for asking questions. I'm asking the audience as somewhat non-rhetorical. Or are we all hot and just want to be done? I'm sure. The URL for which? The URLs, I thought that I had them but I don't think I do. The URL actually for group AES is I'm going to have to go through this. Come on, BSD. I thought I had URLs. I don't. The URL for group AES, go to sourceforge and type in and go to the search box and type in loop-AES. That will find it. For PAM underscore mount, let me go to a command prompt and I will tell you exactly what that is because I do have that on the system. www.basoncomputers.com is where you buy these and obviously www.nomadworld.com I'm not that I buy one because it's pretty useless at this point but they're cool. Okay, yes, I'm logged in as root. I know it's bad. Okay, where cd slash home slash jam Okay, cd PAM PAM underscore mount is available on Freshmeat www.freshmeat.net and just type in Freshmeat www.freshmeat.net It is not a porn site although it sounds like one. Anyway, so basically that's the PAM mount utility. That one is, I'm going to play with it because it's kind of nice to think that you could have a multi-user system with different encryption options for each different user. Any other questions? I guess you. If you have an IDE hard disk, what? You're basically asking can you encrypt a block device like an IDE hard disk? Yes. You can use any kind of a device that is a block device. I negligible because it's AES. It's actually designed to be fast. It uses the render algorithm. If you're familiar with that, it's much more efficient than does or triple does which is just a nightmare without hardware acceleration. Like I said, a modern processor probably about 4-5% of processor. Again, it's throughput the same. I've not seen any slowdown up to on megabit. There might be some issues, but that's what multi-processers are for. No, I didn't say that. I've only tested up to a megabyte per second. I have used it on a system where I was using a 26 meg per disk just subjective and I did not notice any difference. I was able to copy a file almost instantaneously as if it was a normal hard drive. It's pretty much transparent. Questions to continue? I guess the gentleman in the back over there, please speak up much louder. I cannot hear you. Can you come up? I cannot hear you. Okay, thank you. Yeah. There is obviously the problem that if mount knows how to mount a loopback encrypted file system, probably someone doing crypto analysis would be able to see the fact that it was in fact done using that cipher. However, at least you've introduced a layer of obscurity on which I know they say security through obscurity is bad, but it's at least a layer of obscurity that probably 75 to 95% of the people in the world or at least in most circles that you run into are not going to be able to figure out. But I think to answer your question, yes, crypto analysis would probably reveal the existence of the disk. Now if you want to get really kind of sneaky, you might try thinking about using steganography and writing your own file system driver and storing the encrypted file inside of a nice big MP3, but that's a different story. Sir, do these what? They're exactly the same. At least I think they are. Questions? Ma'am? Oh, sorry. I didn't know you. Okay. The kernel hive? Oh, well, originally the kernel, those kind of just stopped. I went to the kernel source, single the crypto directory, and the kernel patch is like 2.3, and I know that they list some other guys way out in the middle of nowhere, but I'm just saying, like I said, in my searches, and again I may be ignorant, that does happen sometimes, I also did not like the idea that it was directly in the kernel. I wanted to be able to load and unload a module so I could read the system without anybody to read or not read an encrypted file system. So that was one of the... I did use the encrypted files, the kernel patch, and it worked great. In fact, I think it's a little faster, to be honest, because it's directly in the kernel, it's not a module and all those things. So anyways, that's my answer. Questions? I guess that is it. Thank you for your attention and time.