Re: MUSCLE Disk encryption and more
I'm not an expert, I just know what I read, and I go by my instincts and reasoning. Whether or not your question was lame or not, perhaps that's up for discussion. Either way, that description might not have been the best considered on my part. To set the record straight, e-mail is almost _never_ a trusted path. I stand by my opinion that I think your proposed buisness model is in need of serious rework, and that attempting to provide secured hardware at low or not cost is not an effective way to make money/provide reliable service. Please understand that I'm not an expert in business either, but again, I know what I know and I go by my instincts and reasoning. Protecting your investment is a good thing, freely distributing your investment doesn't seem like a great way to protect it, to me, anyway. Perhaps you can add "Secrets and Lies" by Bruce Schneier to your reading list. It might provide you with some insight into the trusted hardware problem. I do wish you the best of luck in your endeavour, however, and I hope that I haven't irreprably offended you. And yeah, I'll try to be more cordial in the future. Alex [EMAIL PROTECTED] [EMAIL PROTECTED] On Monday 25 June 2001 03:58 pm, Patrick Valsecchi wrote: > 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 > > > > >
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. > > > > > > --- > > > -°)
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
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
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
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
Jim, Suggest you get to grips with the Trusted Computing Platform Alliance, who already have demo systems built to their spec (I saw one such at HP here in Bristol, UK, last autumn). Most of the big western hemisphere PC platform manufacturers have joined this initiative. If they haven't built into their spec a system to control what programs it can run, they should have. Peter T Bristol UK - Original Message - From: "Jim Rees" <[EMAIL PROTECTED]> To: "Smart Muscleheads" <[EMAIL PROTECTED]> Sent: Friday, June 22, 2001 10:13 PM Subject: 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 > *** > > *** 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
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
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
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
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
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, 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
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, 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
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
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
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
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
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
***
