Encrypting /home on OpenBSD Laptops

[Brad Tilley-4]

I wrote some notes on how I normally encrypt /home on OpenBSD laptops.
I was hoping misc could read it and bash it around some. I'd like to
know if I'm doing something wrong. No jokes about Beck's ass please :)

http://16systems.com/openbsd_laptop_encryption.txt

Thanks,

Brad

[Ted Unangst-2]

1.  You don't really need to fdisk.
2.  People should be advised to use softraid crypto now.
3.  You don't specify a NUMBER or explain its importance.

The last part is probably the part most people don't understand, so
I'll explain that more fully here.

bioctl says the default for a similar keying scheme is 8192, but
there's no special reason it must or should be a power of two.  The
number of rounds used determines how difficult it is to crack your
password, after an attacker recovers the salt and the encrypted
volume.  More rounds means more work per guess.  So you may want to
run some experiments, raising the number until it takes 10 seconds,
for instance, or whatever you consider an acceptable amount of time to
wait.  The time and effort increases linearly, doubling rounds means
doubling the time.

Some numbers to consider.

At 1 second per guess, it takes about a day and a half to go through
half of /usr/share/dict/words.

In order to get the effort up to just 1 second on my laptop, I need
30000 rounds, 4x the default.  You could try using 300,000 rounds,
that would buy you maybe a week of time if you chose a weak password.
Just remember that unlike doubling the size of a crypto key or
increasing the length of your password, for increasing rounds, pain
and gain are directly linearly proportional.

But there's a limit to how high the rounds should go.  In order to get
that same 10x assurance in time, you could also just add a number on
to the end of your dictionary word and save yourself the annoyance
every time you log in.  Adding just two letters to your password
probably buys you more time than you'd ever be willing to pay.

In the past, I've hesitated to recommend a number, but in
consideration of the fact that your choice of password domain and
length matters far more, I'll throw out a generalization.  I think
increasing above the default makes sense, but probably not more than
about 1 second, where it will start to annoy you.  30k-40k rounds,
let's say.

4.  If you stick with vnconfig, I'd make a slightly bigger deal about
backing up the salt.  People may have a tendency to copy the vnd
backing file as a backup, omitting the salt, which makes it impossible
to restore.  softraid stores the salt with the raidinfo, so you
whatever you're doing for backup, you aren't as likely to omit it.

On Fri, Oct 30, 2009 at 7:57 PM, Brad Tilley <brad@...> wrote:
> I wrote some notes on how I normally encrypt /home on OpenBSD laptops.
> I was hoping misc could read it and bash it around some. I'd like to
> know if I'm doing something wrong. No jokes about Beck's ass please :)
>
> http://16systems.com/openbsd_laptop_encryption.txt

[Markus Bergkvist]

* To Unmount, do this:

-     # unmount /home
+     # umount /home
      # vnconfig -v -u svnd0

/Markus

Brad Tilley wrote:
> I wrote some notes on how I normally encrypt /home on OpenBSD laptops.
> I was hoping misc could read it and bash it around some. I'd like to
> know if I'm doing something wrong. No jokes about Beck's ass please :)
>
> http://16systems.com/openbsd_laptop_encryption.txt
>
> Thanks,
>
> Brad

[Gonzalo Lionel Rodriguez]

Maybe it's more usefull encrypted a file IN the /home partition and
move the 'shit' there, then you create symlinks (ln -s) to the
encrypted file and done.

2009/10/30 Brad Tilley <brad@...>:
> I wrote some notes on how I normally encrypt /home on OpenBSD laptops.
> I was hoping misc could read it and bash it around some. I'd like to
> know if I'm doing something wrong. No jokes about Beck's ass please :)
>
> http://16systems.com/openbsd_laptop_encryption.txt
>
> Thanks,
>
> Brad

[Joachim Schipper-2]

On Fri, Oct 30, 2009 at 07:57:08PM -0400, Brad Tilley wrote:
> I wrote some notes on how I normally encrypt /home on OpenBSD laptops.
> I was hoping misc could read it and bash it around some. I'd like to
> know if I'm doing something wrong. No jokes about Beck's ass please :)
>
> http://16systems.com/openbsd_laptop_encryption.txt

Encrypting just /home is dangerous. Do you know where vi(1) keeps its
backup files? Are you *sure* that's the only application that works like
that? And that nothing ever uses /tmp?

Realistically, / cannot be encrypted since you need some files to boot,
and /usr can probably reasonably be kept unencrypted. Everything else -
/home, /tmp, /var - needs encryption (or not, but in that case nothing
does). You should also be careful to note that /root is not encrypted
under this scheme.

                Joachim

[Brad Tilley-4]

On Sat, Oct 31, 2009 at 9:30 AM, Joachim Schipper
<joachim@...> wrote:
> You should also be careful to note that /root is not encrypted under this scheme.

The title says it all. Like most normal people, I keep data in /home.
I don't care about meta data that might be in /tmp and I do not wish
to encrypt /. This is not an effort to avoid law-enforcement or
encrypt every bit on the disk, only to provide some privacy for the
vast majority of my data should the laptop be lost or stolen and
end-up in a pawn shop. Encrypting /home does that, nothing more.

Brad

[Jacob Yocom-Piatt-2]

Brad Tilley wrote:

> I wrote some notes on how I normally encrypt /home on OpenBSD laptops.
> I was hoping misc could read it and bash it around some. I'd like to
> know if I'm doing something wrong. No jokes about Beck's ass please :)
>
> http://16systems.com/openbsd_laptop_encryption.txt
>
> Thanks,
>
> Brad
>
>  

don't bother encrypting just /home, do everything except the root partition.

you can do this using softraid crypto as follows:

- dump your existing partitions to another disk connected to the machine
e.g. a usb drive
- wipe the original disk
- do a fresh install from a recent i386 or amd64 snapshot and break to
shell instead of following the usual install option
- follow the content of the softraid manpage to setup an encrypted disk,
using fdisk and disklabel to prepare the disk yourself i.e. (assumes
base disk name is sd0) fdisk -iy sd0, disklabel -E sd0, make a smallish
100-150 MB 4.4BSD partition for root and the rest of the disk set as a
single partition of type RAID e.g. /dev/sd0a is root and /dev/sd0b is
softraid, write disklabel, bioctl -c C -r 32768 -l /dev/sd0b softraid0,
enter passphrase, and now you've got a second disk according to bsd.rd,
sd1. not sure if you need to partition sd1 in the shell or in the
installation script, you can figure it out
- before rebooting make sure that your /etc/fstab lists the crypto
partitions (everything except root) as being on sd1
- when you reboot, the boot process will 'fail' and dump you to shell
since sd1 is not unlocked as part of the boot process
- at a shell do the following to get your disk rollin: bioctl -c C -l
/dev/sd0b softraid0, enter passphrase, issue 'fsck -fp && exit' if you
had a dirty shutdown otherwise just type exit
- normal boot resumes and you've got your machine running with
everything but root encrypted

do note that i used tedu's suggestion of increasing the round count when
making the crypto partition above. the steps listed above are almost
complete but should be ***tested on a spare disk before doing this with
a production system***.

cheers,
jake

[Robert-318]

If you have enough memory you can avoid the /tmp problem by moving it
into RAM:

fstab:
swap /tmp mfs rw,async,nodev,nosuid,-s=2000000 0 0

This will also speed up some things that write to /tmp.

But keep in mind that in case of a crash the content is lost (if this is
relevant for you).

regards,
Robert

Joachim Schipper wrote:

> On Fri, Oct 30, 2009 at 07:57:08PM -0400, Brad Tilley wrote:
>> I wrote some notes on how I normally encrypt /home on OpenBSD laptops.
>> I was hoping misc could read it and bash it around some. I'd like to
>> know if I'm doing something wrong. No jokes about Beck's ass please :)
>>
>> http://16systems.com/openbsd_laptop_encryption.txt
>
> Encrypting just /home is dangerous. Do you know where vi(1) keeps its
> backup files? Are you *sure* that's the only application that works like
> that? And that nothing ever uses /tmp?
>
> Realistically, / cannot be encrypted since you need some files to boot,
> and /usr can probably reasonably be kept unencrypted. Everything else -
> /home, /tmp, /var - needs encryption (or not, but in that case nothing
> does). You should also be careful to note that /root is not encrypted
> under this scheme.
>
> Joachim

[Ted Unangst-2]

On Sat, Oct 31, 2009 at 10:00 AM, Jacob Yocom-Piatt
<jy-p@...> wrote:
> disk name is sd0) fdisk -iy sd0, disklabel -E sd0, make a smallish 100-150
> MB 4.4BSD partition for root and the rest of the disk set as a single
> partition of type RAID e.g. /dev/sd0a is root and /dev/sd0b is softraid,
> write disklabel, bioctl -c C -r 32768 -l /dev/sd0b softraid0, enter
> passphrase, and now you've got a second disk according to bsd.rd, sd1. not

Avoid using partition 'b' for anything but swap.  Yeah, I'm basically
superstitious, but it's best to not tempt fate by putting real data in
the "reserved for swap" partition.

[Joachim Schipper-2]

On Sat, Oct 31, 2009 at 09:52:06AM -0400, Brad Tilley wrote:
> On Sat, Oct 31, 2009 at 9:30 AM, Joachim Schipper
> <joachim@...> wrote:
[My (Joachim's) message, snipped by Brat:
Encrypting just /home is dangerous. Do you know where vi(1) keeps its
backup files? Are you *sure* that's the only application that works like
that? And that nothing ever uses /tmp?

Realistically, / cannot be encrypted since you need some files to boot,
and /usr can probably reasonably be kept unencrypted. Everything else -
/home, /tmp, /var - needs encryption (or not, but in that case nothing
does).]
> > You should also be careful to note that /root is not encrypted under this scheme.
>
> The title says it all. Like most normal people, I keep data in /home.
> I don't care about meta data that might be in /tmp and I do not wish
> to encrypt /. This is not an effort to avoid law-enforcement or
> encrypt every bit on the disk, only to provide some privacy for the
> vast majority of my data should the laptop be lost or stolen and
> end-up in a pawn shop. Encrypting /home does that, nothing more.

You snipped everything except a tangential note and then responded to
the rest of the message. Bad form.

I can't tell whether you miss the point or are arguing that a 90%
solution is good enough.

In the first case: try it. Run vi(1) on some file. Observe the file full
of zeroes in /var/tmp/vi.recover. Edit some stuff in the file. Observe
the file full of snippets of your original file in /var/tmp/vi.recover.
Generalize this behaviour to many other applications.

In the second case: OpenBSD isn't about 90% solutions, and this sort of
thing is exactly why "HOWTO"-style documents are regarded with deep
suspicion here. If 90% is good enough for you, go ahead - but don't tell
others to do it that way. Not even with a huge flashing banner saying
'this is a bad idea' at the top.

                Joachim

[Joachim Schipper-2]

On Sun, Nov 01, 2009 at 09:36:40AM +0100, Joachim Schipper wrote:
> On Sat, Oct 31, 2009 at 09:52:06AM -0400, Brad Tilley wrote:
> > On Sat, Oct 31, 2009 at 9:30 AM, Joachim Schipper
> > <joachim@...> wrote:
> [My (Joachim's) message, snipped by Brat:
                                      ^^^^

Sorry, this was a typo. I didn't mean to offend.

                Joachim

[Brad Tilley-4]

On Sun, Nov 1, 2009 at 3:36 AM, Joachim Schipper
<joachim@...> wrote:

> I can't tell whether you miss the point or are arguing that a 90%
> solution is good enough.

I understand that when I do this *only* /home is encrypted. The title
says it all, right?

> In the first case: try it. Run vi(1) on some file. Observe the file full
> of zeroes in /var/tmp/vi.recover. Edit some stuff in the file. Observe
> the file full of snippets of your original file in /var/tmp/vi.recover.
> Generalize this behaviour to many other applications.

Again, this does not concern me. If it concerns you, then do the 100%
solution you mention.

> In the second case: OpenBSD isn't about 90% solutions, and this sort of
> thing is exactly why "HOWTO"-style documents are regarded with deep
> suspicion here. If 90% is good enough for you, go ahead - but don't tell
> others to do it that way. Not even with a huge flashing banner saying
> 'this is a bad idea' at the top.

It's not a howto for others to follow. The man pages are for that. I
only share this with misc for the sake of criticism (such as this).
Your point is that it does not encrypt enough. However, it encrypts
exactly what I would like encrypted. I'm not trying to stop GCFA
technicians from producing evidence to be used against me in court
(perhaps you are), I am stopping the average thief from pursuing my
/home files. That's all I hope to accomplish.

Brad

[Brad Tilley-4]

Thanks to everyone for the feedback. The biggest criticism to this
approach has been that /var is not encrypted. My practice of only
encrypting /home and using rc.local to setup /home at boot would not
seem to work for /var as /var is needed long before rc.local is
executed. Is anyone using vnconfig to encrypt /var on laptops? How do
you bring this up at boot time and shutdown in an orderly fashion?

Thanks,

Brad

[Alvaro Mantilla Gimenez-3]

On Sat, 2009-10-31 at 09:00 -0500, Jacob Yocom-Piatt wrote:

> - when you reboot, the boot process will 'fail' and dump you to shell
> since sd1 is not unlocked as part of the boot process
> - at a shell do the following to get your disk rollin: bioctl -c C -l
> /dev/sd0b softraid0, enter passphrase, issue 'fsck -fp && exit' if you
> had a dirty shutdown otherwise just type exit
> - normal boot resumes and you've got your machine running with
> everything but root encrypted

I just configure an old laptop with three partitions in it:

wd0a for /
wd0b for swap
wd0d for RAID

I created the partitions for the rest of the system into the softraid
device during the install process and everything was fine. I really
don't notice any performance problem using the laptop as usually do
(check email, surf the net, etc...) but it is a pain in the ass the boot
process going to the shell every time and need to type: bioctl -c C
-l /dev/wd0d

Is it possible to add the bioctl line in some file with the objective to
not write that line all the times? (rc file??) The idea is just to get
the passphrase question before continue the normal boot. If it is
possible...where? I mean, the rc file is very important and I don't want
to fuck the boot process putting the line in the wrong place...

Regards,

      Alvaro

[Matthew Szudzik]

On Sat, Nov 07, 2009 at 05:39:47PM -0600, Alvaro Mantilla Gimenez wrote:
> (check email, surf the net, etc...) but it is a pain in the ass the boot
> process going to the shell every time and need to type: bioctl -c C
> -l /dev/wd0d

 http://marc.info/?l=openbsd-misc&m=124187397614485

[Brad Tilley-4]

On Sat, Nov 7, 2009 at 12:07 PM, Brad Tilley <brad@...> wrote:
> How do you bring this up at boot time and shutdown in an orderly fashion?

I found mount_vnd that should do it.

[Alvaro Mantilla Gimenez-3]

On Sun, 2009-11-08 at 00:41 +0000, Matthew Szudzik wrote:
> On Sat, Nov 07, 2009 at 05:39:47PM -0600, Alvaro Mantilla Gimenez wrote:
> > (check email, surf the net, etc...) but it is a pain in the ass the boot
> > process going to the shell every time and need to type: bioctl -c C
> > -l /dev/wd0d
>
>  http://marc.info/?l=openbsd-misc&m=124187397614485

Thanks so much !! Works fine !!

     Alvaro

[elias r.]

Am 11/01/2009 09:36 AM, schrieb Joachim Schipper:

> On Sat, Oct 31, 2009 at 09:52:06AM -0400, Brad Tilley wrote:
>> On Sat, Oct 31, 2009 at 9:30 AM, Joachim Schipper
>> <joachim@...>  wrote:
> [My (Joachim's) message, snipped by Brat:
> Encrypting just /home is dangerous. Do you know where vi(1) keeps its
> backup files? Are you *sure* that's the only application that works like
> that? And that nothing ever uses /tmp?
>
> Realistically, / cannot be encrypted since you need some files to boot,
> and /usr can probably reasonably be kept unencrypted. Everything else -
> /home, /tmp, /var - needs encryption (or not, but in that case nothing
> does).]
>>> You should also be careful to note that /root is not encrypted under this scheme.
>>
>> The title says it all. Like most normal people, I keep data in /home.
>> I don't care about meta data that might be in /tmp and I do not wish
>> to encrypt /. This is not an effort to avoid law-enforcement or
>> encrypt every bit on the disk, only to provide some privacy for the
>> vast majority of my data should the laptop be lost or stolen and
>> end-up in a pawn shop. Encrypting /home does that, nothing more.
>
> You snipped everything except a tangential note and then responded to
> the rest of the message. Bad form.
>
> I can't tell whether you miss the point or are arguing that a 90%
> solution is good enough.
>
> In the first case: try it. Run vi(1) on some file. Observe the file full
> of zeroes in /var/tmp/vi.recover. Edit some stuff in the file. Observe
> the file full of snippets of your original file in /var/tmp/vi.recover.
> Generalize this behaviour to many other applications.
>
> In the second case: OpenBSD isn't about 90% solutions, and this sort of
> thing is exactly why "HOWTO"-style documents are regarded with deep
> suspicion here. If 90% is good enough for you, go ahead - but don't tell
> others to do it that way. Not even with a huge flashing banner saying
> 'this is a bad idea' at the top.
>
> Joachim
>

Especially because OpenBSD isn't about 90% solutions i still don't
understand why nobody seems to be interested in finding a solution for
encrypting entire / (except sth like the /boot partition like it is in
(yeah, i know...) linux + luks.
E.g. certificates are normally stored in /etc and in most
encryption-cases you would surely like to protect them, too.

greetings,

Elias

[Brad Tilley-4]

On Fri, Nov 13, 2009 at 8:50 AM, elias r. <obsdml@...> wrote:

> Especially because OpenBSD isn't about 90% solutions i still don't
> understand why nobody seems to be interested in finding a solution for
> encrypting entire /

If you are only concerned about data in /home and protecting against
theft, then this is a 100% solution. If you are concerned about
encrypting every bit on your computer because you have an evil,
unscrupulous opponent who will go to great lengths to get your data in
clear text, then you have larger issues that no amount of technology
or encryption will solve.

If this opponent gains access to the hardware and you, then all bets
are off even when you have a 100% encryption solution. They don't need
PhD's in math and Crays to crack the encryption. They just need a guy
with no conscious and a pair of pliers (or a hammer) from Walmart.
It's simple and effective and most anyone off the street can do. There
are no language barriers either. Violence is universally understood.

So, what are you trying to protect and who are you trying to protect it from?

Brad

[Otto Moerbeek]

On Fri, Nov 13, 2009 at 02:50:40PM +0100, elias r. wrote:

> Am 11/01/2009 09:36 AM, schrieb Joachim Schipper:
> >On Sat, Oct 31, 2009 at 09:52:06AM -0400, Brad Tilley wrote:
> >>On Sat, Oct 31, 2009 at 9:30 AM, Joachim Schipper
> >><joachim@...>  wrote:
> >[My (Joachim's) message, snipped by Brat:
> >Encrypting just /home is dangerous. Do you know where vi(1) keeps its
> >backup files? Are you *sure* that's the only application that works like
> >that? And that nothing ever uses /tmp?
> >
> >Realistically, / cannot be encrypted since you need some files to boot,
> >and /usr can probably reasonably be kept unencrypted. Everything else -
> >/home, /tmp, /var - needs encryption (or not, but in that case nothing
> >does).]
> >>>You should also be careful to note that /root is not encrypted under this scheme.
> >>
> >>The title says it all. Like most normal people, I keep data in /home.
> >>I don't care about meta data that might be in /tmp and I do not wish
> >>to encrypt /. This is not an effort to avoid law-enforcement or
> >>encrypt every bit on the disk, only to provide some privacy for the
> >>vast majority of my data should the laptop be lost or stolen and
> >>end-up in a pawn shop. Encrypting /home does that, nothing more.
> >
> >You snipped everything except a tangential note and then responded to
> >the rest of the message. Bad form.
> >
> >I can't tell whether you miss the point or are arguing that a 90%
> >solution is good enough.
> >
> >In the first case: try it. Run vi(1) on some file. Observe the file full
> >of zeroes in /var/tmp/vi.recover. Edit some stuff in the file. Observe
> >the file full of snippets of your original file in /var/tmp/vi.recover.
> >Generalize this behaviour to many other applications.
> >
> >In the second case: OpenBSD isn't about 90% solutions, and this sort of
> >thing is exactly why "HOWTO"-style documents are regarded with deep
> >suspicion here. If 90% is good enough for you, go ahead - but don't tell
> >others to do it that way. Not even with a huge flashing banner saying
> >'this is a bad idea' at the top.
> >
> > Joachim
> >
>
> Especially because OpenBSD isn't about 90% solutions i still don't
> understand why nobody seems to be interested in finding a solution for
> encrypting entire / (except sth like the /boot partition like it is in
> (yeah, i know...) linux + luks.
> E.g. certificates are normally stored in /etc and in most
> encryption-cases you would surely like to protect them, too.

What's the point of encrypting certificates? They only contain
information that is public.

        -Otto