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-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"

On 10/10/07, Steve Bertrand <iaccountsibctech.ca> 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-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"

Daniel Marsh wrote:
> On 10/10/07, Steve Bertrand <iaccountsibctech.ca> 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-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"

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         Size    Used   Avail Capacity  Mounted
on
/dev/ar0s1a        496M    126M    330M    28%    /
devfs              1.0K    1.0K      0B   100%    /dev
/dev/ar0s1g.eli    120G     82G     28G    75%    /home
/dev/ar0s1e        496M     16K    456M     0%    /tmp
/dev/ar0s1f         19G    4.7G     13G    26%    /usr
/dev/ar0s1d        1.9G    152M    1.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/~r
smith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much
appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725
(KeyID: C321A725)

Rolannessto <rsmithxs4all.nl> 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

> 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-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"

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/~r
smith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much
appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725
(KeyID: C321A725)

On Wed, Oct 10, 2007 at 08:18:38PM +0200, Fabian Keil
wrote:
> Rolannessto <rsmithxs4all.nl> 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/~r
smith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much
appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725
(KeyID: C321A725)

On Wednesday 10 October 2007 23:17:01 Rolannessto wrote:
> On Wed, Oct 10, 2007 at 08:18:38PM +0200, Fabian Keil
wrote:
> > Rolannessto <rsmithxs4all.nl> 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-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"

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/~r
smith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much
appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725
(KeyID: C321A725)