Re: MUSCLE Disk encryption and more
Please note that I have been receiving emails which are not meant for me. This has started since I joined your mailing list. Please can you look into it so I no longer receive your email. Karl Katewu [EMAIL PROTECTED] - Original Message - From: [EMAIL PROTECTED] To: Smart Muscleheads [EMAIL PROTECTED] Sent: Friday, June 22, 2001 11:17 PM Subject: 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 *** *** 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
Quoting [EMAIL PROTECTED]: 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. I don't have to store each signature of each bin into the smartcard. I won't have enough RAM for that! I'll store inside each executable and library the signed crypto hash. The kernel will check if the crypto hash is still the same and the smartcard will just check if the signature of the crypto hash. The solution of maintaining a separated DB of signature is not a good idea. I'll need to check if the DB is not altered by the cracker, and it's another source of problem. 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. Yeah, but the CPU is the most expensive part of the system. And I'm sure there is good insulating glues that will make it hard to remove without destroing the main board. If the price of the separated parts is too expensive, the majority will quit. Ok, maybe there will be some crazy hackers that are going the spend all that money, just for the fun of it, but we don't care. All we want is to avoid having thousands of people registering for our stuff and after a cheap hack (software only, for example), don't use it as we want them to use it. We are not going the sell remote controls for nuclear missiles that must only allow the targeting of the bad guys! ;-) --- -°) 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
Patrick Valsecchi wrote: I don't have to store each signature of each bin into the smartcard. I won't have enough RAM for that! I'll store inside each executable and library the signed crypto hash. The kernel will check if the crypto hash is still the same and the smartcard will just check if the signature of the crypto hash. I'm curious as to why the smartcard is being used for the crypto verification as opposed to the boot-loader and subsequently the executable loader. They might for example have a hard coded public key or some root CA depending on how sophisticated you want to be. You of course have to be very careful that the public key or certificate cannot be replaced. If there is some reason to use a smart card then that also has to be handled carefully, otherwise someone could just replace it with something that either always returns successful (for any signature) or allows other (known) keys to sign the executables. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PGP key: via homepage. *** 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, it's offtopic here, but I don't think, it is a good idea to use such policy. Why to protect such thing ?? A good policy is to setup a box and to have a model earning money on services not on the boxes or the system (linux). The user can do what ever he/she wants to do, if the user disconfigured the system, it his personal problem. Or it is a good idea to do a protection (check) over the configuration. But the user has to pay for services, C offers ... With friendly regards Christoph P. Patrick Valsecchi wrote: Hi My company is working for another company (let call it C) that is going to provide Linux boxes to its customers. As C is going to give them free or for a small fee, C doesn't want the customers to use the boxes for another purpose that the one specified by C. C doesn't want the user to be able to: - run another kernel than the one S provides - run executables that have not been signed by authorized developpers or that have been modified (signed executables) - change or alter the dynamic libraries (signed .so files) - have access to the binary of some executables (for avoiding reverse engineering) - save a file and give the disk to a friend (encrypted files, but I need to be fast on read and write, here) All that by using: - a SmartCard - a modified kernel - a specialised hardware for encryption - maybe a modified loader (lilo) And that mustn't be just simple tricks, we must protect those boxes against very skilled hackers. Is there existing projects on those subjects? Is anybody already worked on it? Thanks for your help. --- -°) Patrick Valsecchi /\\ _\_v *** 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 *** -- --- private:[EMAIL PROTECTED] company:[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 Alex Thank you for the lame-ass question. I'm not a specialist in computer security, I'm just beginning to learn. I just asked this lame-ass question to have a feedback and see in what direction my studies must go. So, in the future try to be more compassionate with beginners, please. With the answers I've got from the mailing list, now I have: - List of books for this subject. - What would be my main problems. - Good starting points for my reflexions. Therefore, instead of being rude with me, you can give some other advice (books or ideas). For comming back on Christoph's mail, C will offer a good service. But for that C have to provide a good general purpose hardware. Even if you offer a good service, you'll always have people taking this good hardware for free while not using it with C products. Just imagine you own a tennis court and give rackets for free to your customers (marketing practice). People will just come to your company once and then go to another tennis court with the racket you gave them. Won't you try to protect yourself against that? Alex was right when he said the thread is dead. Now I have all the information I need to start to study on my own. Thanks for the helpfull answers you sent me. Have a good day. PS: If you (Alex) are a highly skilled person in security, could you explain me why I received this mail? Good demonstration of trusted path, isn't it? Quoting Alex Russell [EMAIL PROTECTED]: I think the thread is dead. The orginal poster has been removed from the list (Dave does that to people who ask lame-ass questions). You're right, the business model he was proposing was all kinds of dumb. It's been tried before and works marginally (if at all). The guy didn't have a threat model in place, an acceptable attrition rate for hardware, or a real definition of what he wanted his hardware to be trusted for/against. If you can't trace a path of trust through a system, it's security value is dubious to say the least, and this guy didn't seem to understand what a trust path even implied. Alex [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] - Original Message - From: Christoph Plattner [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, June 25, 2001 4:28 PM Subject: Re: MUSCLE Disk encryption and more Ok, it's offtopic here, but I don't think, it is a good idea to use such policy. Why to protect such thing ?? A good policy is to setup a box and to have a model earning money on services not on the boxes or the system (linux). The user can do what ever he/she wants to do, if the user disconfigured the system, it his personal problem. Or it is a good idea to do a protection (check) over the configuration. But the user has to pay for services, C offers ... With friendly regards Christoph P. Patrick Valsecchi wrote: Hi My company is working for another company (let call it C) that is going to provide Linux boxes to its customers. As C is going to give them free or for a small fee, C doesn't want the customers to use the boxes for another purpose that the one specified by C. C doesn't want the user to be able to: - run another kernel than the one S provides - run executables that have not been signed by authorized developpers or that have been modified (signed executables) - change or alter the dynamic libraries (signed .so files) - have access to the binary of some executables (for avoiding reverse engineering) - save a file and give the disk to a friend (encrypted files, but I need to be fast on read and write, here) All that by using: - a SmartCard - a modified kernel - a specialised hardware for encryption - maybe a modified loader (lilo) And that mustn't be just simple tricks, we must protect those boxes against very skilled hackers. Is there existing projects on those subjects? Is anybody already worked on it? Thanks for your help. --- -°) Patrick Valsecchi /\\ _\_v *** 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 *** -- --- private: [EMAIL PROTECTED] company: [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 *** --- -°) Patrick Valsecchi /\\ _\_v *** Linux
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 ***
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
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
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
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 ***
Re: MUSCLE Disk encryption and more
um you've got a lot of requirements that Linux may or may not be able to meet. I think the biggest problem you're going to have is that if the user has hardware access, the game is over anyway. Really, truly, and completely over. Trusted hardware tends to combat this inability to be able to withstand attack by co-opting environmental factors that change the equation to be more balanced (or hopefully, favourable to the defender). Examples of environmental factor defense mechanisms include (but are not limited to): Placing ATMs in brick walls or recessing them Placing ATMs in well light and traveled locations enforcing physical access controll with gaurds and the like enacting laws that shift the risk ratio out of the realm of acceptable risk for attackers (i.e., death penalties, etc...) Bank vaults are a great way to look at the problem. A bank vault isn't rated to be uncrackable, it's rated for a certian ammount of time against a certian class of attack. By garunteeing a level of integrity and confidentiality for a certain ammount of time, banks can then schedule gaurds to check only every so often and can be sure of catching or deterring said classes of attackers. Moving the discussion to a hardened Linux box, you are disucssing several different forms of attack, each of which is going to need seperate asessment and analysis. Crypto (smartcard based or otherwise) is only a small fraction of the solution and only gaurds against a small subset of your threat vector here. Also, you've yet to begin classifying who you want to defend against (very skilled hackers isn't a valid classification) and for how long, because in the end, everything is crackable. If you want help identifying classifications of attackers, threat vectors, and the like, feel free to contact me offline from the list, as that discussion reasonably belongs elsewhere. HTH, Alex [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] - Original Message - From: Patrick Valsecchi [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 21, 2001 3:39 PM Subject: MUSCLE Disk encryption and more Hi My company is working for another company (let call it C) that is going to provide Linux boxes to its customers. As C is going to give them free or for a small fee, C doesn't want the customers to use the boxes for another purpose that the one specified by C. C doesn't want the user to be able to: - run another kernel than the one S provides - run executables that have not been signed by authorized developpers or that have been modified (signed executables) - change or alter the dynamic libraries (signed .so files) - have access to the binary of some executables (for avoiding reverse engineering) - save a file and give the disk to a friend (encrypted files, but I need to be fast on read and write, here) All that by using: - a SmartCard - a modified kernel - a specialised hardware for encryption - maybe a modified loader (lilo) And that mustn't be just simple tricks, we must protect those boxes against very skilled hackers. Is there existing projects on those subjects? Is anybody already worked on it? Thanks for your help. --- -°) Patrick Valsecchi /\\ _\_v *** 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 *** *** 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 ***
