Re: Booting a GELI encrypted hard disk
Hi Pawel, Pawel Jakub Dawidek wrote: Daniel Marsh wrote: Even if all data on a drive is encrypted, the partition table is not. Software based disk encryption works on partitions. That's not true. One can configure full disk encryption using GELI. To do it you need to have a small USB pen-drive or CD-ROM with /boot/ directory, but that's all you need. Then you actually boot from your unencrypted pen-drive, but mount all file systems from encrypted disk. So far, so good ... The pen-drive is not needed for your system to run and you can be easly take it with you, which is not always the case for your laptop. Are you saying that the USB pen-drive can be removed while the system is running (after it has booted)? I remember that it was impossible in the past to remove the root vnode (which in this case would be the /boot file system from the pen-drive). Did that change recently? Or is there a way to change the system's root vnode from the pen-drive to the root file system on the encrypted disk? If so, then how? I'm just curious. The ability to change the root vnode would open several interesting possibilities, beside fully encrypted disks. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd One of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs. -- Robert Firth ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Booting a GELI encrypted hard disk
On Thu, Oct 25, 2007 at 03:53:34PM +0200, Oliver Fromme wrote: The pen-drive is not needed for your system to run and you can be easly take it with you, which is not always the case for your laptop. Are you saying that the USB pen-drive can be removed while the system is running (after it has booted)? I remember that it was impossible in the past to remove the root vnode (which in this case would be the /boot file system from the pen-drive). Did that change recently? Or is there a way to change the system's root vnode from the pen-drive to the root file system on the encrypted disk? If so, then how? The boot directory is different that root file system. /boot/ directory is only accessed by loader before root file system is mounted. The root file system can be mounted from encrypted disk, because loader loads the kernel (and eventually geom_eli.ko module) from the /boot/ directory. Most of the time /boot/ directory is on the root file system, but there is no need for that - you can boot from different /boot/ directory and have different /boot/ directory in your root file system. -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpb9gKin9aG5.pgp Description: PGP signature
Re: Booting a GELI encrypted hard disk
Pawel Jakub Dawidek wrote: On Thu, Oct 25, 2007 at 12:46:53AM +0800, Daniel Marsh wrote: Even if all data on a drive is encrypted, the partition table is not. Software based disk encryption works on partitions. That's not true. One can configure full disk encryption using GELI. To do it you need to have a small USB pen-drive or CD-ROM with /boot/ directory, but that's all you need. Then you actually boot from your unencrypted pen-drive, but mount all file systems from encrypted disk. The pen-drive is not needed for your system to run and you can be easly take it with you, which is not always the case for your laptop. This is EXACTLY what I have now. Soon as the machine is booted, my thumb disk comes with me. The ONLY information on the thumb drive is /boot, a directory /keys and an /etc that has only an fstab (to mount the .eli partitions from the hard disk) and a loader.conf file to locate the keys. This was originally my objective and have got it in place. Now the machine is nearly upgraded to 7.0. Steve ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Booting a GELI encrypted hard disk
Pawel Jakub Dawidek wrote: On Thu, Oct 25, 2007 at 03:53:34PM +0200, Oliver Fromme wrote: Are you saying that the USB pen-drive can be removed while the system is running (after it has booted)? I remember that it was impossible in the past to remove the root vnode (which in this case would be the /boot file system from the pen-drive). Did that change recently? Or is there a way to change the system's root vnode from the pen-drive to the root file system on the encrypted disk? If so, then how? The boot directory is different that root file system. /boot/ directory is only accessed by loader before root file system is mounted. Ah, right. I forgot that the /boot directory is only accessed by the boot blocks and loader(8) during boot, but not by the kernel, so it isn't actually mounted. Once the kernel mounts its root file system, it will be the real one from the encrypted disk. Thanks for clearing up my confusion. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd That's what I love about GUIs: They make simple tasks easier, and complex tasks impossible. -- John William Chambless ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Booting a GELI encrypted hard disk
The ONLY information on the thumb drive is /boot, a directory /keys and an /etc that has only an fstab (to mount the .eli partitions from the hard disk) and a loader.conf file to locate the keys. My bad, my bad. loader.conf is located under /boot of course. Steve ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Booting a GELI encrypted hard disk
The boot directory is different that root file system. /boot/ directory is only accessed by loader before root file system is mounted. Ah, right. I forgot that the /boot directory is only accessed by the boot blocks and loader(8) during boot, but not by the kernel, so it isn't actually mounted. Once the kernel mounts its root file system, it will be the real one from the encrypted disk. I don't know if this is absolutely true. I haven't tried it yet, but I don't think that /boot on the encrypted disk is necessary. I will rename the directory and reboot and see if it barfs. On the same track, upgrading this system has been easy so far. I do a build/install kernel into /boot on the encrypted disk, then simply copy the /boot/kernel directory over to the thumb drives /boot directory. However, making a mistake such as building and installing the wrong kernel config without crypto and GEOM_ELI leads to all sorts of problems. Relatively easy to recover from, but a waste of time to track down (I posted about this to -stable this AM). Steve ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Booting a GELI encrypted hard disk
Steve Bertrand wrote: I haven't tried it yet, but I don't think that /boot on the encrypted disk is necessary. I will rename the directory and reboot and see if it barfs. It shouldn't be necessary. Once the kernel is loaded, the system never looks at /boot again. Unless, of course, you want to load a kernel module. Those are located in /boot/kernel by default, but you can change the if needed (see sysctl kern.module_path). Also, some system utilities that use KVM functions (vmstat, top, ps) might require access to the kernel file. But that can be changed, too: sysctl kern.bootfile. Other than that, the /boot directory isn't used at all during normal operation. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd The scanf() function is a large and complex beast that often does something almost but not quite entirely unlike what you desired. -- Chris Torek ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Booting a GELI encrypted hard disk
Oliver Fromme wrote: Steve Bertrand wrote: I haven't tried it yet, but I don't think that /boot on the encrypted disk is necessary. I will rename the directory and reboot and see if it barfs. It shouldn't be necessary. Once the kernel is loaded, the system never looks at /boot again. Unless, of course, you want to load a kernel module. Those are located in /boot/kernel by default, but you can change the if needed (see sysctl kern.module_path). Also, some system utilities that use KVM functions (vmstat, top, ps) might require access to the kernel file. But that can be changed, too: sysctl kern.bootfile. Other than that, the /boot directory isn't used at all during normal operation. This is correct, I tested it. Also, this system (with GEOM_ELI built into kernel) successfully upgraded from 6.2 to 7.0 with ULE scheduler enabled with no problems at all. Cheers! Steve ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Booting a GELI encrypted hard disk
On 10/23/07, Steve Bertrand [EMAIL PROTECTED] wrote: I am voraciously attempting to get a FreeBSD system to boot from a GELI encrypted hard disk, but am having problems. You don't need to encrypt the whole harddisk. You can encrypt separate slices. There is no need to encrypt stuff like / or /usr; what is there that needs to be kept secret? Maybe not encryption, but integrity protection is very important for laptops. GELI supports integrity protection for a while now. If you don't protect integrity of your entire laptop disk, it is trivial to trojan userland utilities and/or kernel and steal your password. If someone needs your data, he can dump encrypted partition, trojan your system and once you connect to the internet and attach your encrypted partition, the trojan will send the password to the attacker. Many people often leave their laptops in hotels rooms, for example. I don't quite grasp in what level you are using the term 'integrity' here. My knowledge of encryption at the storage level is limited at best... I'm just finding out all the finer points (temp directories, swap etc). However, I'll throw out what I wanted, what I have and then a question: Want: - a FreeBSD system that runs from a fully encrypted disk with passphrase and an encryption key on a removable thumb disk that can be removed so that upon reboot, can not be started Have: - a FreeBSD system that runs from a fully encrypted disk with NO passphrase (due to known, seemingly unsolved keyboard interaction problems) that boots from a thumb drive that has an encryption key so that when rebooted, does not boot (thumb drive can be removed once boot procedure complete)) Question: - if the disk (PC) is stolen, having the entire disk encrypted so no one can even tell what OS is on it, does it make it secure to the point that no one will know what to look for anyway (eg: what is in /usr)? If someone does not know the OS, then it makes it more difficult to know what string or text attacks to perform, right? (I'm not trying to start a security via obscurity/bikeshed war, I seriously wouldn't mind opinion). I think it's fantastic. I'm not a disk forensic specialist, but it's good enough for what I want. Again...thanks to everyone who worked on the GEOM infrastructure. Performance is adequate in my benches so far for what I need, so long as one has adequate memory as to not have to run a disk-based swap space. Steve Even if all data on a drive is encrypted, the partition table is not. Software based disk encryption works on partitions. How far into the boot sequence do you get before your system crashes without the key present? I would assume as far as reading the / partition to get the kernel etc... It would have read the partition table and the boot loader, known which partition was the active partition and tried booting it. Now, to identify what OS this disk has on it you can check the partition table and see what type has been set for each slice/partition. You will be able to see that there is a BSD style slice on the disk just by running `fdisk /dev/mystolendiskdevice` You now know it's a BSD OS, you could then make a guess as to what version of BSD by the type of machine it was taken from, based on what hardware is supported by each BSD. I believe their slices and layout are identical but the file systems differ. The person with your disk could then start trying to determine what kind of disk encryption is in place. So, a disk drive (I believe Seagate ship them now) that has an encryption chip built in to do hardware encryption regardless of software in use would be an excellent measure. On top of that add your GELI. Juts my 3 cents. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Booting a GELI encrypted hard disk
On Thu, Oct 25, 2007 at 12:46:53AM +0800, Daniel Marsh wrote: Even if all data on a drive is encrypted, the partition table is not. Software based disk encryption works on partitions. That's not true. One can configure full disk encryption using GELI. To do it you need to have a small USB pen-drive or CD-ROM with /boot/ directory, but that's all you need. Then you actually boot from your unencrypted pen-drive, but mount all file systems from encrypted disk. The pen-drive is not needed for your system to run and you can be easly take it with you, which is not always the case for your laptop. How far into the boot sequence do you get before your system crashes without the key present? I would assume as far as reading the / partition to get the kernel etc... It would have read the partition table and the boot loader, known which partition was the active partition and tried booting it. Now, to identify what OS this disk has on it you can check the partition table and see what type has been set for each slice/partition. You will be able to see that there is a BSD style slice on the disk just by running `fdisk /dev/mystolendiskdevice` You now know it's a BSD OS, you could then make a guess as to what version of BSD by the type of machine it was taken from, based on what hardware is supported by each BSD. I believe their slices and layout are identical but the file systems differ. The person with your disk could then start trying to determine what kind of disk encryption is in place. That's all irrelevant. Security of GELI (or any sane cryptographic system) doesn't depend on secrecy of algorithms used. -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpA1kmMdGF3e.pgp Description: PGP signature
Re: Booting a GELI encrypted hard disk
On Wed, Oct 10, 2007 at 07:53:49PM +0200, Roland Smith wrote: On Wed, Oct 10, 2007 at 09:04:34AM -0400, Steve Bertrand wrote: Hi all, I am voraciously attempting to get a FreeBSD system to boot from a GELI encrypted hard disk, but am having problems. You don't need to encrypt the whole harddisk. You can encrypt separate slices. There is no need to encrypt stuff like / or /usr; what is there that needs to be kept secret? Maybe not encryption, but integrity protection is very important for laptops. GELI supports integrity protection for a while now. If you don't protect integrity of your entire laptop disk, it is trivial to trojan userland utilities and/or kernel and steal your password. If someone needs your data, he can dump encrypted partition, trojan your system and once you connect to the internet and attach your encrypted partition, the trojan will send the password to the attacker. Many people often leave their laptops in hotels rooms, for example. -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgp48YVSMzslF.pgp Description: PGP signature
Re: Booting a GELI encrypted hard disk
I am voraciously attempting to get a FreeBSD system to boot from a GELI encrypted hard disk, but am having problems. You don't need to encrypt the whole harddisk. You can encrypt separate slices. There is no need to encrypt stuff like / or /usr; what is there that needs to be kept secret? Maybe not encryption, but integrity protection is very important for laptops. GELI supports integrity protection for a while now. If you don't protect integrity of your entire laptop disk, it is trivial to trojan userland utilities and/or kernel and steal your password. If someone needs your data, he can dump encrypted partition, trojan your system and once you connect to the internet and attach your encrypted partition, the trojan will send the password to the attacker. Many people often leave their laptops in hotels rooms, for example. I don't quite grasp in what level you are using the term 'integrity' here. My knowledge of encryption at the storage level is limited at best... I'm just finding out all the finer points (temp directories, swap etc). However, I'll throw out what I wanted, what I have and then a question: Want: - a FreeBSD system that runs from a fully encrypted disk with passphrase and an encryption key on a removable thumb disk that can be removed so that upon reboot, can not be started Have: - a FreeBSD system that runs from a fully encrypted disk with NO passphrase (due to known, seemingly unsolved keyboard interaction problems) that boots from a thumb drive that has an encryption key so that when rebooted, does not boot (thumb drive can be removed once boot procedure complete)) Question: - if the disk (PC) is stolen, having the entire disk encrypted so no one can even tell what OS is on it, does it make it secure to the point that no one will know what to look for anyway (eg: what is in /usr)? If someone does not know the OS, then it makes it more difficult to know what string or text attacks to perform, right? (I'm not trying to start a security via obscurity/bikeshed war, I seriously wouldn't mind opinion). I think it's fantastic. I'm not a disk forensic specialist, but it's good enough for what I want. Again...thanks to everyone who worked on the GEOM infrastructure. Performance is adequate in my benches so far for what I need, so long as one has adequate memory as to not have to run a disk-based swap space. Steve ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Booting a GELI encrypted hard disk
On Wed, 10 Oct 2007 23:09:10 +0200
Roland Smith [EMAIL PROTECTED] wrote:
On Wed, Oct 10, 2007 at 02:34:16PM -0400, Steve Bertrand wrote:
If you encrypted / and /usr, you might actually make the system more
vulnerable to a known-plaintext attack, because there are a lot of files
with well-known contents there.
I can get away with not having / encrypted, but I need /var encrypted
for databases and logs etc, /tmp so any temporary files are secured and
the swap file (swap very rarely gets used).
You can even encrypt /tmp with a one-time key (see 'geli onetime').
don't forget to do the same with your swap partition :) It may be a bit slower,
but your swap would have quite a bit of interesting info if your system used it.
In my rc.conf, i have :
# ENCRYPTED SWAP PARTITION - OPTIONS
geli_swap_flags=-e aes -l 192 -s 4096 -d
and /etc/fstab reads:
# DeviceMountpoint FStype Options DumpPass#
/dev/ad0s1b.eli noneswapsw 0 0
[]
However using a USB device presents it's own problems. If you plug-in a
USB stick there's no telling which device node it ends up with,
depending on how many other USB devices are on the bus. To make device
recognition easier, you should use a GEOM label on the USB stick, so
you'll know which /dev/label/* device node it gets. And you'd probably
have to hack an rc script to mount the USB stick _before_ the system
tries to attach the GELI device(s).
[...]
And remember that this USB stick is another thing you have to back-up
and store in a safe place. It would be bad if you lost your data because
your USB stick died or got lost.
hmm I find it much easier to have my normal partitions in clear text, and
then have big files (4 , 8 Gb) which I attach as a device node and mount as
part of my normal directory tree.[1]
Why do this? well, for a number of reason that work for me :
- my backups are VERY simple. Unmount my encrypted disks, back up the lot. How
do you, safely and with commonly available tools, backup a fully encrypted
partition? (yes, you could mount it, backup and encrypt the backup but
that's doubling up too much)
- I can take any of my disks and mount it in ANY other freebsd computer with
minimal fuss ( even a freebsd VM).
- i find the whole thing about having to have the USB @ boot time a bit of a
pain.
- same goes for keeping good, safe backups of USB keys...
- it works pretty well for specific work... eg, you want to have all your DB
data kept safely - make the postgresql script depend on your script and you
will be prompted for it on startup.
totally paranoid
BTW, is any work done on plausible deniability for geli? such as truecrypt's
feature :
http://www.truecrypt.org/docs/?s=plausible-deniability
/tp
thanks!!
[1]
-
#!/bin/sh
sudo mdconfig -d -u 11
sudo mdconfig -a -t vnode -f ~/blah.dsk -u 11 \
sudo geli attach /dev/md11 \
echo Running fsck... \
sudo fsck -p -t ufs /dev/md11.eli \
sudo geli detach -l /dev/md11 \
sudo mount -o noatime /dev/md11.eli ~/blah
sudo chown betom:betom ~/blah
--
and, the first time, to create blah.dsk:
dd if=/dev/random of=blah.dsk bs=1024 count=5
mdconfig -a -t vnode -f ./blah.dsk -u 13
sudo geli init -e AES -l 256 -s 4096 /dev/md13
sudo geli attach /dev/md13
sudo newfs -U /dev/md13.eli
_
{Beto|Norberto|Numard} Meijome
I've dirtied my hands writing poetry, for the sake of seduction; that is, for
the sake of a useful cause. Dostoevsky
I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Booting a GELI encrypted hard disk
That's a heck of a lot of trouble to go to, considering someone would have to steal your drive, alter it and put it back without you knowing it! Essentially, what I'm looking for is thus: - someone breaks into my always-locked equipment room - someone steals the box(es) in question, which obviously means shutting down the unit I don't want said thief to be able to retrieve the data after the box is stolen, which is why I'd like a passphrase, and a removable key. Even if the passphrase is captured, the data will still be protected because I have the only key to the system 35 miles away on my person. If the intruder has physical access to the machine, it would be much easier to put a keylogger device between the keyboard and the machine. There is no possible way this would go unnoticed. Anyone that could gain access to the already secured room would have a window of about 15 seconds to break into the building after hours (secured/alarmed), smash in the secured equipment room door, grab the box (out of about 40) and run. It's questionable though, whether you should leave your computer in an environment where this can happen undetected and probably better solved by increasing real life security. Like I said, it won't go undetected. The equipment is in a very secure equipment area, inside of a secured and alarmed building. All equipment is monitored 24/7, so if the box was physically altered, I would be alerted via SMS/email immediately. An important point that too many people forget. I agree, but this is not the case here. I just want the data protected if the box goes down, whether by physical intruder, or I force it down myself. Steve ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Booting a GELI encrypted hard disk
As you can see only /home is encrypted because the rest doesn't hold data worth encrypting. Well, on mine it will. I was talking about my system. Yours will of course be different. :-) I know. I was not trying to be sarcastic in any way. Sorry if it seemed that way :) You can even encrypt /tmp with a one-time key (see 'geli onetime'). I will likely do this with /tmp and swap. Also have a look at the geli_* variables in /etc/defaults/rc.conf. Will do. It only needs to be present during creation of the GELI devices (geli attach). The rc scripts know they have to load GELI and attach the devices if they see an .eli device in /etc/fstab. Geli will ask for the passphrase(s) during boot-up if you're using them. You can specify which key-file to use in the geli_[devicename]_flags variable in /etc/rc.conf However using a USB device presents it's own problems. If you plug-in a USB stick there's no telling which device node it ends up with, depending on how many other USB devices are on the bus. To make device recognition easier, you should use a GEOM label on the USB stick, so you'll know which /dev/label/* device node it gets. And you'd probably have to hack an rc script to mount the USB stick _before_ the system tries to attach the GELI device(s). Getting around these issues is trivial. The only requirement is that my thumbdrive comes with me after the machine is reloaded. And remember that this USB stick is another thing you have to back-up and store in a safe place. It would be bad if you lost your data because your USB stick died or got lost. Understood. This has been considered, and it's exactly what I do with my TrueCrypt encrypted information on my Windows workstation. Steve ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Booting a GELI encrypted hard disk
Hi all, I am voraciously attempting to get a FreeBSD system to boot from a GELI encrypted hard disk, but am having problems. All of my searches lead to the same problem...GELI passphrase can not be entered correctly upon boot. I have tried everything I have found on the web (including disabling 'kbdmux' in the kernel) to no avail. Is there any chance that anyone here has found a resolution to this problem, in the 6.x branch, and if not, has it been looked/resolved within -current? Does anyone have a suggestion for a workaround? Thanks for any advice. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Booting a GELI encrypted hard disk
On 10/10/07, Steve Bertrand [EMAIL PROTECTED] wrote: Hi all, I am voraciously attempting to get a FreeBSD system to boot from a GELI encrypted hard disk, but am having problems. All of my searches lead to the same problem...GELI passphrase can not be entered correctly upon boot. I have tried everything I have found on the web (including disabling 'kbdmux' in the kernel) to no avail. Is there any chance that anyone here has found a resolution to this problem, in the 6.x branch, and if not, has it been looked/resolved within -current? Does anyone have a suggestion for a workaround? You could always use a key without a passphrase... unsafe as it is, put the key on a usb device that you remove once the machine has booted? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Booting a GELI encrypted hard disk
Daniel Marsh wrote: On 10/10/07, Steve Bertrand [EMAIL PROTECTED] wrote: Hi all, I am voraciously attempting to get a FreeBSD system to boot from a GELI encrypted hard disk, but am having problems. All of my searches lead to the same problem...GELI passphrase can not be entered correctly upon boot. I have tried everything I have found on the web (including disabling 'kbdmux' in the kernel) to no avail. Is there any chance that anyone here has found a resolution to this problem, in the 6.x branch, and if not, has it been looked/resolved within -current? Does anyone have a suggestion for a workaround? You could always use a key without a passphrase... unsafe as it is, put the key on a usb device that you remove once the machine has booted? That is what I was going to try next. The 'howtos' I've been reading require putting many of the boot files on the thumb drive, so would it even be possible to unmount/remove the usb stick after the machine is booted up? If I was to do it this way, I would likely use two separate key files, on two separate USB sticks. Reference: http://www.proportion.ch/index.php?page=31 Thanks for your feedback. Steve ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Booting a GELI encrypted hard disk
On Wed, Oct 10, 2007 at 09:04:34AM -0400, Steve Bertrand wrote: Hi all, I am voraciously attempting to get a FreeBSD system to boot from a GELI encrypted hard disk, but am having problems. You don't need to encrypt the whole harddisk. You can encrypt separate slices. There is no need to encrypt stuff like / or /usr; what is there that needs to be kept secret? All of my searches lead to the same problem...GELI passphrase can not be entered correctly upon boot. I have tried everything I have found on the web (including disabling 'kbdmux' in the kernel) to no avail. With a normal AT keyboard I can enter the passphrase without problems, for a non-root partition. Does anyone have a suggestion for a workaround? Put all the data that really needs to be encrypted on a separate slice, and encrypt that. Leave the rest unencrypted, especially /boot. As a rule of thumb; don't bother encrypting anything that you can just download from the internet. :-) Here's how it looks on my machine; Filesystem SizeUsed Avail Capacity Mounted on /dev/ar0s1a496M126M330M28%/ devfs 1.0K1.0K 0B 100%/dev /dev/ar0s1g.eli120G 82G 28G75%/home /dev/ar0s1e496M 16K456M 0%/tmp /dev/ar0s1f 19G4.7G 13G26%/usr /dev/ar0s1d1.9G152M1.6G 8%/var As you can see only /home is encrypted because the rest doesn't hold data worth encrypting. If you encrypted / and /usr, you might actually make the system more vulnerable to a known-plaintext attack, because there are a lot of files with well-known contents there. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgp8756KQUjO9.pgp Description: PGP signature
Re: Booting a GELI encrypted hard disk
Roland Smith [EMAIL PROTECTED] wrote: On Wed, Oct 10, 2007 at 09:04:34AM -0400, Steve Bertrand wrote: I am voraciously attempting to get a FreeBSD system to boot from a GELI encrypted hard disk, but am having problems. You don't need to encrypt the whole harddisk. You can encrypt separate slices. There is no need to encrypt stuff like / or /usr; what is there that needs to be kept secret? Encryption isn't only useful for private data, it also reduces the risk of third parties replacing your binaries with Trojans while your away. Fabian signature.asc Description: PGP signature
Re: Booting a GELI encrypted hard disk
Put all the data that really needs to be encrypted on a separate slice, and encrypt that. Leave the rest unencrypted, especially /boot. As a rule of thumb; don't bother encrypting anything that you can just download from the internet. :-) Fair enough, this makes sense. Thank you. As you can see only /home is encrypted because the rest doesn't hold data worth encrypting. Well, on mine it will. If you encrypted / and /usr, you might actually make the system more vulnerable to a known-plaintext attack, because there are a lot of files with well-known contents there. I can get away with not having / encrypted, but I need /var encrypted for databases and logs etc, /tmp so any temporary files are secured and the swap file (swap very rarely gets used). So, I will test it as you suggested, however, would it be possible to still house my key on a removable USB stick, and after the slices are mounted into the file system successfully to then unmount and remove the USB drive and have the box remain in operation, or does the key need to be accessed throughout all disk reads/writes? Essentially, I'd like it so that if the box reboots while I am gone, or if I want to reboot it remotely there is theoretically no way for someone at the console to re-mount the encrypted slices? Thank you for all of this info! Steve ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Booting a GELI encrypted hard disk
On Wed, Oct 10, 2007 at 02:34:16PM -0400, Steve Bertrand wrote: Put all the data that really needs to be encrypted on a separate slice, and encrypt that. Leave the rest unencrypted, especially /boot. As a rule of thumb; don't bother encrypting anything that you can just download from the internet. :-) Fair enough, this makes sense. Thank you. As you can see only /home is encrypted because the rest doesn't hold data worth encrypting. Well, on mine it will. I was talking about my system. Yours will of course be different. :-) If you encrypted / and /usr, you might actually make the system more vulnerable to a known-plaintext attack, because there are a lot of files with well-known contents there. I can get away with not having / encrypted, but I need /var encrypted for databases and logs etc, /tmp so any temporary files are secured and the swap file (swap very rarely gets used). You can even encrypt /tmp with a one-time key (see 'geli onetime'). Also have a look at the geli_* variables in /etc/defaults/rc.conf. So, I will test it as you suggested, however, would it be possible to still house my key on a removable USB stick, and after the slices are mounted into the file system successfully to then unmount and remove the USB drive and have the box remain in operation, or does the key need to be accessed throughout all disk reads/writes? It only needs to be present during creation of the GELI devices (geli attach). The rc scripts know they have to load GELI and attach the devices if they see an .eli device in /etc/fstab. Geli will ask for the passphrase(s) during boot-up if you're using them. You can specify which key-file to use in the geli_[devicename]_flags variable in /etc/rc.conf However using a USB device presents it's own problems. If you plug-in a USB stick there's no telling which device node it ends up with, depending on how many other USB devices are on the bus. To make device recognition easier, you should use a GEOM label on the USB stick, so you'll know which /dev/label/* device node it gets. And you'd probably have to hack an rc script to mount the USB stick _before_ the system tries to attach the GELI device(s). Essentially, I'd like it so that if the box reboots while I am gone, or if I want to reboot it remotely there is theoretically no way for someone at the console to re-mount the encrypted slices? Well, if you don't know the passphrase during boot-up (you get 3 tries), the geli devices will not be created and mounting the slices depending on them will fail. so you don't _need_ a keyfile for that. And remember that this USB stick is another thing you have to back-up and store in a safe place. It would be bad if you lost your data because your USB stick died or got lost. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpzTSDTZjJCa.pgp Description: PGP signature
Re: Booting a GELI encrypted hard disk
On Wed, Oct 10, 2007 at 08:18:38PM +0200, Fabian Keil wrote: Roland Smith [EMAIL PROTECTED] wrote: On Wed, Oct 10, 2007 at 09:04:34AM -0400, Steve Bertrand wrote: I am voraciously attempting to get a FreeBSD system to boot from a GELI encrypted hard disk, but am having problems. You don't need to encrypt the whole harddisk. You can encrypt separate slices. There is no need to encrypt stuff like / or /usr; what is there that needs to be kept secret? Encryption isn't only useful for private data, it also reduces the risk of third parties replacing your binaries with Trojans while your away. If that someone can replace binaries on a running system, you're box has been h4x0red and you're screwed anyway. Doubly so if your encrypted filesystem was mounted at the time. :-) Disk encryption is mostly a defense against data-loss in case of the machine or disk being stolen. It's easy enough to make a list of SHA256 checksums of all binaries and store that on the encrypted partition, so you can check the binaries any time you want. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpumPH70Xyal.pgp Description: PGP signature
Re: Booting a GELI encrypted hard disk
On Wednesday 10 October 2007 23:17:01 Roland Smith wrote: On Wed, Oct 10, 2007 at 08:18:38PM +0200, Fabian Keil wrote: Roland Smith [EMAIL PROTECTED] wrote: On Wed, Oct 10, 2007 at 09:04:34AM -0400, Steve Bertrand wrote: I am voraciously attempting to get a FreeBSD system to boot from a GELI encrypted hard disk, but am having problems. You don't need to encrypt the whole harddisk. You can encrypt separate slices. There is no need to encrypt stuff like / or /usr; what is there that needs to be kept secret? Encryption isn't only useful for private data, it also reduces the risk of third parties replacing your binaries with Trojans while your away. If that someone can replace binaries on a running system, you're box has been h4x0red and you're screwed anyway. Doubly so if your encrypted filesystem was mounted at the time. :-) I think the case he's describing, is that one can remove the harddisk, mount it as secondary drive, replace system binaries with keylogging enabled binaries and then put it back. You won't notice this till you read daily security report in a default system. It's easy enough to make a list of SHA256 checksums of all binaries and store that on the encrypted partition, so you can check the binaries any time you want. Like sysutils/tripwire. Even if the system doesn't let you boot if system binaries have changed, the damage is probably done already because the geli passphrase binary logged your passphrase. It's questionable though, whether you should leave your computer in an environment where this can happen undetected and probably better solved by increasing real life security. -- Mel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Booting a GELI encrypted hard disk
On Wed, Oct 10, 2007 at 11:37:55PM +0200, Mel wrote: Encryption isn't only useful for private data, it also reduces the risk of third parties replacing your binaries with Trojans while your away. If that someone can replace binaries on a running system, you're box has been h4x0red and you're screwed anyway. Doubly so if your encrypted filesystem was mounted at the time. :-) I think the case he's describing, is that one can remove the harddisk, mount it as secondary drive, replace system binaries with keylogging enabled binaries and then put it back. You won't notice this till you read daily security report in a default system. That's a heck of a lot of trouble to go to, considering someone would have to steal your drive, alter it and put it back without you knowing it! If the intruder has physical access to the machine, it would be much easier to put a keylogger device between the keyboard and the machine. It's questionable though, whether you should leave your computer in an environment where this can happen undetected and probably better solved by increasing real life security. An important point that too many people forget. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpwUiArodJxb.pgp Description: PGP signature
