Hi Valerio - It's definitely out of my league, however as totally a dirty hack you could try compiling 'hwinfo' or a similar command into busybox and then making a script that outputs the CPU info to a text and then use that as the keyfile for your luks system. All you would need to do then is to make sure that the script and necessary tools get added to initramfs with update-initramfs. There is probably a MUCH more elegant way to do that, but as I said, this is totally out of my league and I would start my sleuthing with a more in-depth look into the capabilities of initramfs. Good luck! I'd appreciate a how-to or at least a good summary of your findings back here, since this seems like a fun project. Cheers, m On Thu, Jan 22, 2009 at 2:06 PM, Valerio Paris Mitritsakis <valerio@xxxxxxxxxxxxxx> wrote: > Deal all, > > thanks for the replies. I think the CPU ID would be ok with me with a > passphrase in another slot that could be used > if the CPU gets fried. Is there a known way to implement it or do I have to > boldly go where no man has gone before? > > regards, > > Valerio > > > Μητριτσάκης Βαλέριο Πάρις > Σύμβουλος Πληροφορικής > Ηλεκτρονικός Μηχανικός Τ.Ε. > MSc Network Systems > MCP ID: 5745185 > > Mitritsakis Valerio Paris > IT Consultant > Electronic Engineer > MSc Network Systems > MCP ID: 5745185 > ----------------------------------------------------------------------------------------------------------------- > Συμβουλευτικές Υπηρεσίες Πληροφορικής - Τεχνική υποστήριξη Η/Υ & Δικτύων > IT Consultancy Services Computer & Network Tech Support > http://www.mitritsakis.gr > ----------------------------------------------------------------------------------------------------------------- > > > > > > On Jan 22, 2009, at 3:28 PM, Matt Rosales wrote: > >> Those are valid points. The way I was thinking about implementing it >> was by having the script create a hash of sorts that is used as a >> keyfile. This could be backed up on USB in case of hardware failure, >> as you noted, however would serve the purpose if only the hard drive >> was stolen. >> Of course, you are right about a thief stealing the whole computer, >> but that wasn't Valerio's original requisite... This seems like a >> niche usage, but this could be a sneaky way to prevent the hard drive >> from being removed, especially in conjunction with a normal >> passphrase. I especially like the CPU unique ID for this purpose. >> >> On Thu, Jan 22, 2009 at 12:15 PM, Stefan X <stefanxe@xxxxxxx> wrote: >>> >>> Matt Rosales schrieb: >>>> >>>> I am looking into the possibility of having an Ubuntu 8.04 >>>>>> >>>>>> installation with an encrypted filesystem. As it is supported out >>>>>> of the box I managed to get it up and running in no time. However >>>>>> what I would really need is the system to boot without prompting for >>>>>> a passphrase. I just want to prevent someone from unplugging the >>>>>> hard disk and mounting it on another machine. So far I have seen >>>>>> that this can be done with a USB Key with a key file however I do >>>>>> not want to use a USB Key. >>>> >>>> You know, I was thinking about a similar thing the other day; perhaps >>>> using the reported model number or some other sort of identifying >>>> information from your USB keyboard or mouse. It may not be unique, but >>>> the combination of the USB devices attached to your computer could >>>> potentially make a moderate 'keyfile' replacement, no? >>> >>> Problematic if a) you want to replace a device or a device quits service >>> and b) if the thief takes the whole computer together with the hard >>> drive. Probably Joe Average could execute this even easier than removing >>> the harddrive. >>> >>> AFAIK at least Intel CPUs have an unique ID which could be used for your >>> purpose. Also this does not prevent against b) it may be more consistent >>> than your USB device combinations. Keep in mind that you may run into >>> trouble if your CPU becomes defect which should occur seldom. >>> >>>> Maybe a hack would be having initramfs run a small program that makes >>>> a hash based on connected devices, and then saving that as a keyfile >>>> in memory that is read by cryptsetup. If you have the wrong devices >>>> connected, the keyfile won't match, and the system won't be unlocked. >>>> What do you think about that? Possible? Or just silly? It could be >>>> used in combination with a password to prevent the drive being put >>>> into a different computer and the password bruted, especially since >>>> the hash would only be generated at boot, and thus wouldn't be present >>>> if an attacker was attempting to mount a filesystem from within >>>> another already-booted OS. >>>> >>>> Just pondering. >>>> >>>> -- >>>> GPG Key ID: 113828CC >>>> >>>> >>>> On Thu, Jan 22, 2009 at 12:43 AM, Teddy Hogeborn >>>> <teddy+dm-crypt@xxxxxxxxxxxxx> wrote: >>>> Valerio Paris Mitritsakis <valerio@xxxxxxxxxxxxxx> writes: >>>> >>>>>>> I am looking into the possibility of having an Ubuntu 8.04 >>>>>>> installation with an encrypted filesystem. As it is supported out >>>>>>> of the box I managed to get it up and running in no time. However >>>>>>> what I would really need is the system to boot without prompting for >>>>>>> a passphrase. I just want to prevent someone from unplugging the >>>>>>> hard disk and mounting it on another machine. So far I have seen >>>>>>> that this can be done with a USB Key with a key file however I do >>>>>>> not want to use a USB Key. >>>>>>> >>>>>>> Is there any other way? >>>> >>>> There are two ways to do this. The first way is to store the password >>>> in a file. This method, however, has drawbacks, as you point out: >>>> >>>>>>> I know that this would compromise security and probably kind of beat >>>>>>> the purpose for what I would use LUKS however I want to prevent Joe >>>>>>> Average and not Joe Hacker from reading my disk. >>>> >>>> The other method, if you run Ubuntu or Debian, is to use the Mandos >>>> system, which requests a password from a server on the local ethernet >>>> network. It's all encrypted in all sorts of ways; see the FAQ in the >>>> latest README file for details: >>>> http://bzr.fukt.bsnet.se/loggerhead/mandos/trunk/annotate/head:/README >>>> >>>> The Mandos packages for Debian and Ubuntu are named "mandos-client" >>>> and "mandos", and are available in Debian unstable right now, and also >>>> - From the project home page, which also has documentation, etc: >>>> >>>> http://www.fukt.bsnet.se/mandos >>>> >>>> /Teddy Hogeborn, Mandos Developer >>>> >>>>> >>> --------------------------------------------------------------------- >>> dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ >>> To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx >>> For additional commands, e-mail: dm-crypt-help@xxxxxxxx >>>>> >>>>> >>> >>>> --------------------------------------------------------------------- >>>> dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ >>>> To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx >>>> For additional commands, e-mail: dm-crypt-help@xxxxxxxx >>> >>> >>> --------------------------------------------------------------------- >>> dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ >>> To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx >>> For additional commands, e-mail: dm-crypt-help@xxxxxxxx >>> >>> >> >> >> >> -- >> matt@xxxxxxxxxxxxxxx >> GPG Key ID: 113828CC >> >> --------------------------------------------------------------------- >> dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ >> To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx >> For additional commands, e-mail: dm-crypt-help@xxxxxxxx >> > > > --------------------------------------------------------------------- > dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ > To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx > For additional commands, e-mail: dm-crypt-help@xxxxxxxx > > -- matt@xxxxxxxxxxxxxxx GPG Key ID: 113828CC --------------------------------------------------------------------- dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx For additional commands, e-mail: dm-crypt-help@xxxxxxxx
