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'
> My knowledge of encryption at the storage level is limited at best...
> I'm just finding out all the finer points (temp directories, swap
> However, I'll throw out what I wanted, what I have and then a question:
> - 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
> - 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))
> - 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
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.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"