Re: MUSCLE Disk encryption and more
I don't know about the rest of it, but a former colleague of mine worked on a secure booting system using a smartcard. I don't see anything on his web page about it but you could contact him directly. http://www.citi.umich.edu/u/itoi/ But if you really are concerned about "very skilled hackers" you will need significant hardware protection, like a processor with integrated boot code or an epoxy potted processor and boot rom module. Even then you won't be able to completely protect the system against everyone. *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
MUSCLE FW: SecurityFocus Call for Linux Articles
Wouldn't it be great if someone here could pump up the movement in this manner. See below ;-) Greetings, SecurityFocus is currently looking for writers to develop articles for the Linux focus area. Articles are generally 2000 - 2200 words long, and SecurityFocus offers compensation for each published article. We are currently developing articles on the following topics: 1. Using Linux IPSEC Gateways 2. Discussion of and hardening with Openwall patches. 3. Chroot Jail Projects, and available chroot tools. Also use of chroot jail. 4. Installing, using, and securing NSA Security-enhanced Linux. 5. Libsafe. 6. Immunix, features, deploying Immunix. If you are interested in putting together an article on one of these topics, or if you have a different topic that you would like to explore, please put together a detailed outline and submit it to me sometime before Tuesday, June 26. If you have any questions or concerns regarding this call for writers, please feel free to contact me. Thank you all, Stephen Entwisle Editor SecurityFocus (403) 213 3939 ext. 235 http://www.securityfocus.com _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE Disk encryption and more
On Fri, 22 Jun 2001, Jim Rees wrote: > But if you really are concerned about "very skilled hackers" you will need > significant hardware protection, like a processor with integrated boot code > or an epoxy potted processor and boot rom module. Even then you won't be > able to completely protect the system against everyone. It seems to me, to do completely secure boot protection all one really needs is an encrypting disk controller. Imagine a device that sits between the drive and IDE (or SCSI) disk controller. This device encrypts every block of information going to the disk, and decrypts every block leaving the disk. The keying for this device can be done simply: a keypad is mounted in a 5.25" drive faceplate and the key is entered directly to the encryption device; the underlying computer architecture is not involved. Now, of course, there are particular issues of concern here .. as to how and when the user should key the device, and so forth. And data integrity concerns if the user enters the wrong key. But much of this can be handled in the same fashion as OS-supplied disk encryption methods. We are just taking the OS out of the loop. The entire drive gets encrypted, along with the OS, boot record, and partition table -- everything. Since the key is never handled by the main computer, hacking it won't help. One would need to inspect the encryption device itself while it is running to extract the key. This can be made very difficult by using secure key management techniques (ie, moving the key around in RAM, and XORing it with known bit patterns, etc. This also prevents "burn in" of RAM and takes care of data remanence issues). Also, tamper-proofing the device is also a possibility. Such a system, properly designed and implemented would be secure against pretty much every attacker. Sure, there are sophisticated ways to get by good tamper-proofing in the lab -- but unless the machine is IN the lab already, its no good because at power-off the key is gone forever (since you did the smart thing and took care of data remanence issues). -- Michael Graffam ([EMAIL PROTECTED]) *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE Disk encryption and more
Hi Why not, but this solution is not solving my problem. This just provides encrypted disk. My main concern, is disallowing the user to run its own executables. For answering peoples questions, I don't want to protect this hardware against governements or very high budgeted crackers. My customer is not the army neither a bank. This product won't be nuclear missiles, ATM machine or whatever high security level device. All he want is to disallow its customers to use the hardware for another purpose than the ones he defines. I know it's impossible to have a 100% secure system. All I want is to make it hard enough that it won't worth the price of the device. The smartcard I'm going to use is home made and tamper-proof. This is the centralized unit I'm planning to use for the security. I have as well a specialized processor, with secure memory area and encryption co-processor. All I'm looking for is how to make everything without having too much impact on the performance and making it a pain in the ass to crack. I can sign the kernel, the executables and the libraries. The loader (lilo) can be in the securized memory of the processor. So before it loads the kernel, it checks the signature with the smartcard. Then I'm quit sure it's my own kernel that runs on this machine. From that, the kernel can check the executable by computing its CRC and compare it with the signed CRC (stored in the ELF header). The signed CRC is checked by the smartcard itself. I know that checking the CRC of the executable can lead to slowlyness (have to load each page of it), but I don't think I have the choice. For the encryption the international kernel patches could help. I still have to find a mean to use the smartcard without impacting the performance too much. I know the user will be able to remove the processor and put another one, but it will be expensive enough to discourage people doing it. One other problem that remains is to protect some executables from reverse engineering, but I don't think its a mandatory feature. I think it's very hard to perform, because whatever solution I find, the cracker just have to spy the memory bus to have the ASM code. One can protect the hardware, but its a device we gonna produce it in million... This is just the current status of my thoughts. I gathered some idea from some people and I found an interesting project about signed executable for Linux run by IBM. My main concern is to make sure its my kernel that runs on this machine. From that point I think everything gonna be alright. I think the solution resides in the processor security features. But I didn't looked at it for the moment. From want I eared I can have secured ROM memory bundled inside the processed, wich could solve my loader problem. Any comment, any idea? Anybody have experience on it? Thanks to everybody who answered to my initial mail. Bye. Quoting [EMAIL PROTECTED]: > On Fri, 22 Jun 2001, Jim Rees wrote: > > > But if you really are concerned about "very skilled hackers" you will > need > > significant hardware protection, like a processor with integrated boot > code > > or an epoxy potted processor and boot rom module. Even then you won't > be > > able to completely protect the system against everyone. > > It seems to me, to do completely secure boot protection all one really > needs is an encrypting disk controller. > > Imagine a device that sits between the drive and IDE (or SCSI) disk > controller. This device encrypts every block of information going to > the disk, and decrypts every block leaving the disk. The keying > for this device can be done simply: a keypad is mounted in a > 5.25" drive faceplate and the key is entered directly to the > encryption > device; the underlying computer architecture is not involved. > > Now, of course, there are particular issues of concern here .. as to > how and when the user should key the device, and so forth. And data > integrity concerns if the user enters the wrong key. But much of this > can be handled in the same fashion as OS-supplied disk encryption > methods. > > We are just taking the OS out of the loop. The entire drive gets > encrypted, along with the OS, boot record, and partition table -- > everything. Since the key is never handled by the main computer, > hacking > it won't help. > > One would need to inspect the encryption device itself while it is > running > to extract the key. This can be made very difficult by using secure > key > management techniques (ie, moving the key around in RAM, and XORing it > with known bit patterns, etc. This also prevents "burn in" of RAM and > takes care of data remanence issues). Also, tamper-proofing the device > is also a possibility. > > Such a system, properly designed and implemented would be secure > against > pretty much every attacker. Sure, there are sophisticated ways to get > by good tamper-proofing in the lab -- but unless the machine is IN the > lab already, it
Re: MUSCLE Disk encryption and more
I know that checking the CRC of the executable can lead to slowlyness (have to load each page of it), but I don't think I have the choice. This shouldn't be slow at all. You have to load the pages anyway, right? I hope you're not thinking about sending the entire kernel to the card, that would be silly. Just ship the signed crc to the card for checking. I'm a little curious about the legal aspects. This certainly seems to go against the spirit of the GPL. But technically it's probably legal. The user can still modify the software, he just can't run it once he's modified it. *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE Disk encryption and more
On Fri, 22 Jun 2001 [EMAIL PROTECTED] wrote: > On Fri, 22 Jun 2001, Jim Rees wrote: > > > But if you really are concerned about "very skilled hackers" you will need > > significant hardware protection, like a processor with integrated boot code > > or an epoxy potted processor and boot rom module. Even then you won't be > > able to completely protect the system against everyone. > > It seems to me, to do completely secure boot protection all one really > needs is an encrypting disk controller. > > Imagine a device that sits between the drive and IDE (or SCSI) disk > controller. This device encrypts every block of information going to > the disk, and decrypts every block leaving the disk. The keying > for this device can be done simply: a keypad is mounted in a > 5.25" drive faceplate and the key is entered directly to the encryption > device; the underlying computer architecture is not involved. I believe one of the requirements from the original poster was that users could not take the system (which is obviously "Linux-friendly") and use it as their own workstation. Correct me if I'm wrong (I've deleted the original email) but they plan on giving away the boxes as an "appliance" for which they'd sell the service. They want to prevent what happened to that one company (whose name I've forgotten, naturally) who was selling web appliance service. They gave you a box for free (I think it ran QNX) and expected you to buy monthly ISP service from them. Knowlegable Linux hackers would sign up for the service, get a free appliance, cancel the service, and install Linux on the box. Voila, free Xterm. What is needed is some way to physically require some sort of authentication, else the system is unusable. And it must be proof against hardware hacking. The military has stuff like this. And it's EXPENSIVE. We don't give it out for free. And nothing is tamper-proof. THere are only varying degrees of tamper-resistance. Then there's all the stuff about encrypting the data on disk, etc. --Jeremy Jeremy Impson Sr. Associate Network Engineer Advanced Technologies Department Lockheed Martin Systems Integration email: [EMAIL PROTECTED] phone: 607-751-5618 fax: 607-751-6025 *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE Disk encryption and more
The user will be able to change the code, that's not the matter, but it wont be able to run it on my customer's hardware. That's the point. And I don't this it goes against any law neither any license. I'm sure it doesn't go against any GPL spirit. It's even possible that my source will be partly available. It depends on the customer. But for the modified kernel parts, I'll have to publish it or I'll go against the Linux licence. For the CRC stuff, it was what I meant. Quoting Jim Rees <[EMAIL PROTECTED]>: > I know that checking the CRC of the executable can lead to slowlyness > (have to > load each page of it), but I don't think I have the choice. > > This shouldn't be slow at all. You have to load the pages anyway, > right? I > hope you're not thinking about sending the entire kernel to the card, > that > would be silly. Just ship the signed crc to the card for checking. > > I'm a little curious about the legal aspects. This certainly seems to > go > against the spirit of the GPL. But technically it's probably legal. > The > user can still modify the software, he just can't run it once he's > modified > it. > --- -°) Patrick Valsecchi /\\ _\_vhttp://dante.urbanet.ch/~patrick/index.html *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE Disk encryption and more
On Fri, Jun 22, 2001 at 10:00:35PM +0200, Patrick Valsecchi wrote: > The user will be able to change the code, that's not the matter, but it wont be > able to run it on my customer's hardware. That's the point. And I don't this it > goes against any law neither any license. > > I'm sure it doesn't go against any GPL spirit. It's even possible that my > source will be partly available. It depends on the customer. But for the > modified kernel parts, I'll have to publish it or I'll go against the Linux > licence. > > For the CRC stuff, it was what I meant. Aren't CRC algorithms easy to reverse? So an attacker could generate his own program and simply add some bogus code at the end that'll make the CRC come out the same as an existing program... then steal the signed CRC from the approved program and use it. A keyed cryptographic hash (i.e. HMAC) would be more secure. But slower than CRC. Sha-1 or RIPEMD-160 in hardware might speed that up. If you use the smartcard to verify the kernel's signature, the kernel could then verify the signatures of programs instead of sending them all (or just their signed CRCs) to the smartcard. Since smartcards are slow, this would speed up loading. Tivo does something similar (linux that end-users aren't supposed to play with), you might check out what people are saying about them. Eric *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE Disk encryption and more
Aren't CRC algorithms easy to reverse? Sorry for the sloppy terminology. Obviously this has to be a cryptographic hash, not just a crc. But I still think performance will not be a huge issue. dumaguete# ls -l /bsd -rwxr-xr-x 1 rees wheel 2172784 Jan 25 16:11 /bsd dumaguete# time md5 /bsd MD5 (/bsd) = c0f5740842c563d820906a318461d1e4 0.2u 0.0s 0:00.76 31.5% 0+0k 49+2io 13pf+0w *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE Disk encryption and more
On Fri, 22 Jun 2001, Patrick Valsecchi wrote: > I can sign the kernel, the executables and the libraries. The loader (lilo) can > be in the securized memory of the processor. So before it loads the kernel, it > checks the signature with the smartcard. Then I'm quit sure it's my own kernel > that runs on this machine. From that, the kernel can check the executable by > computing its CRC and compare it with the signed CRC (stored in the ELF > header). The signed CRC is checked by the smartcard itself. Ok, so you have a bunch of executables and a table of pre-computed CRC's. Where do you store those CRCs? You'll need to store all of them in your secured memory, but that memory better be accessable by software because if you have to update (ie: fix bugs) the bins, or kernel, you don't want to have to replace the hardware. You're striving for security here, but if you lock all those CRC's in ROM and someone finds a hole -- you're pinned. You won't be able to offer a security patch to your users because you can't replace your own binaries. And, this won't help anyhow .. because it would be easy for an attacker to load an arbitrary bin with a proper CRC. Just create a bin with a few K of static space in it, all zeros, calculate the CRC, and then modify the static space to give the proper CRC. This really isn't all THAT hard to do, really.. trial and error, mostly. You'll need to use something cryptographically secure .. like MD5. And now your speed penalty just jumped up a few orders of magnitude. > My main concern is to make sure its my kernel that runs on this machine. From > that point I think everything gonna be alright. I think the solution resides in > the processor security features. But I didn't looked at it for the moment. From > want I eared I can have secured ROM memory bundled inside the processed, wich > could solve my loader problem. Using the same technique described above, it wouldn't be hard to load a custom kernel either. And if you're going to have module support, you'll need to worry about plugging that hole too. -- Michael Graffam ([EMAIL PROTECTED]) *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE Disk encryption and more
Thanks you, this is a very good recapitulation. Even better that my first mail ;-) Quoting Jeremy Impson <[EMAIL PROTECTED]>: > On Fri, 22 Jun 2001 [EMAIL PROTECTED] wrote: > > > On Fri, 22 Jun 2001, Jim Rees wrote: > > > > > But if you really are concerned about "very skilled hackers" you > will need > > > significant hardware protection, like a processor with integrated > boot code > > > or an epoxy potted processor and boot rom module. Even then you > won't be > > > able to completely protect the system against everyone. > > > > It seems to me, to do completely secure boot protection all one > really > > needs is an encrypting disk controller. > > > > Imagine a device that sits between the drive and IDE (or SCSI) disk > > controller. This device encrypts every block of information going to > > the disk, and decrypts every block leaving the disk. The keying > > for this device can be done simply: a keypad is mounted in a > > 5.25" drive faceplate and the key is entered directly to the > encryption > > device; the underlying computer architecture is not involved. > > I believe one of the requirements from the original poster was that > users > could not take the system (which is obviously "Linux-friendly") and use > it > as their own workstation. Correct me if I'm wrong (I've deleted the > original email) but they plan on giving away the boxes as an > "appliance" > for which they'd sell the service. They want to prevent what happened > to > that one company (whose name I've forgotten, naturally) who was > selling > web appliance service. They gave you a box for free (I think it ran > QNX) > and expected you to buy monthly ISP service from them. Knowlegable > Linux > hackers would sign up for the service, get a free appliance, cancel > the > service, and install Linux on the box. Voila, free Xterm. > > What is needed is some way to physically require some sort of > authentication, else the system is unusable. And it must be proof > against > hardware hacking. > > The military has stuff like this. And it's EXPENSIVE. We don't give > it > out for free. > > And nothing is tamper-proof. THere are only varying degrees of > tamper-resistance. > > Then there's all the stuff about encrypting the data on disk, etc. > > --Jeremy > > Jeremy Impson > Sr. Associate Network Engineer > Advanced Technologies Department > Lockheed Martin Systems Integration > email: [EMAIL PROTECTED] > phone: 607-751-5618 > fax: 607-751-6025 > > *** > Linux Smart Card Developers - M.U.S.C.L.E. > (Movement for the Use of Smart Cards in a Linux Environment) > http://www.linuxnet.com/smartcard/index.html > *** > --- -°) Patrick Valsecchi /\\ _\_vhttp://dante.urbanet.ch/~patrick/index.html *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE Disk encryption and more
Ok, so you have a bunch of executables and a table of pre-computed CRC's. No, you have a bunch of executables, and for each you have a crypto hash signed with a private key. You could store the public key in the secure rom, but this guy wants to use a smart card, presumably because he wants to be able to re-key. Of course the card and the secure hardware still have to share a key (or key pair) so they can mutually authenticate. *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE Disk encryption and more
Hi, It's still crude, but we have a paper on smartcard based secure booting: http://www.citi.umich.edu/techreports/ Boot up from secure ROM, and use a smartcard to make sure kernels and application binaries are good. -- Concentration .. Naomaru Itoi *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE Disk encryption and more
On Fri, 22 Jun 2001, Jim Rees wrote: > Ok, so you have a bunch of executables and a table of pre-computed CRC's. > > No, you have a bunch of executables, and for each you have a crypto hash > signed with a private key. Ok. > You could store the public key in the secure rom, but this guy wants to use > a smart card, presumably because he wants to be able to re-key. Of course > the card and the secure hardware still have to share a key (or key pair) so > they can mutually authenticate. Ok, well lets see .. the signatures of each bin can be stored on the smartcard along with a patched kernel. Ok, that will work so long as the hardware is intact. Speed may be a slight issue, but I doubt it will be all that bad. The hacker will just replace the CPU and ROMs of the machine that require the smartcard to boot, thats all. I know that we like to ignore this fact, but the case of the Net-appliance that was hacked was mentioned. Did you know that people replace the processors and ROMs in those things for FUN, to give better performance? Small companies will start up selling kits to hack the machine, all that will be required in the end is the ability to solder. And that is the obvious hack -- some brilliant minds will likely find an easier way. I really don't think that there is a solution short of secure, tamper-resistant hardware. And giving away that sort of stuff isn't all that cost-effective. -- Michael Graffam ([EMAIL PROTECTED]) *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
