Re: [gentoo-hardened] Hardened laptops

[Norman B. Robinson]

I haven't seen anything directly like this on the gentoo-hardened list 
yet. I have seen the loopback encrypted filesystems and distro 
discussions (nothing that isn't in the archives).

That said, you asked for comments; I have a few ideas.

NOT TRUSTING YOUR SYSTEM:
Realizing more and more that encryption is a needed part of my working 
environment (I can't trust my administrators) this is of interest. I'd 
like to also see User Mode Linux encyption addressed; how do you encrypt 
your files if you DON'T want to trust your administrator? I've never 
seen the functional aspects of user security, including various levels 
of security risk (i.e., if you use UML encryption you could be exploited 
by X, X, and X in Y environment) explained to end users.

RECOVERING YOUR SYSTEM:
I do not know how the 'phone home' option available on some laptops 
works. I've never seen it explained (I'm assuming if it isn't done in 
hardware a low level format of the harddrive erases any capability of a 
ip locator being sent out). Perhaps rather than approaching the project 
from an 'absolute' security standpoint you could address how you could 
be more secure (various 'levels') and how you could address real 
problems (like someone stealing your laptop, taking it home and plugging 
it into broadband/dialup; having the previously mentioned 'phone home' 
ip packet being sent out could be considered 'more secure' in that you 
increase the likelyhood of either recovery or being able to remote 
connect and detonate your data). Perhaps a honeypot boot environment for 
the unwary that didn't provide a password would be useful - rather than 
completely disabling the laptop (which would encourage formatting) it 
allows use and sends out a packet of information with it's IP address to 
a specified server.

USABILITY:
Zero-Interaction Authentication (ZIA) from Univ. of Michigan is an 
interesting real workable solution for a proximity security token; it is 
a limited broadcast area radio that has an encryption key. The system 
encrypts when the user walks out of range and decrypts when the user 
comes back in range. Barring sniffing and replay issues it addresses the 
problems of user involvement in token keys. This isn't too different 
than say a memory device with a security token except you don't have to 
plug it in and it decreases the downtime during decryption. This general 
idea is really about usability (the concept of keys (the memory device 
or radiokey) and the concept of not 'interfering' with the use of the 
computer because of encryption).

USABILITY and ENCODING:
Part of the solution may to actually create a simplified encryption 
process. Rather than having the user memorize a strong key have a 
short-term key with defined lockdown based on time. In the situation 
where I'm going away from my desk I might just want a simple password to 
lock the computer, when I reboot I want a stronger password (in case *I* 
am not the one doing the rebooting!) and when I know I'm travelling I 
want to lock it with a password and keyed cdrom token.

REDUNDANCY and NO BRAINER FALLBACK
Part of the usability above also should consider that humans are 
imperfect beings. We sometimes forget things and loose our keys. 
Addressing the issues of forgetting your password through split keys 
(one you give to your friend, one you give to your mom, one you leave at 
home and only two are needed to decrypt and reset your password) is 
(pardon the pun) key. :) Also you should provide the information about 
who can partner to decrypt your data to the end-user in case they forget 
who they gave split keys to.

Also consider that you might want to have different physical keys work 
on the same lock. I might have a USB memorystick with my key token(s) 
AND I might have a CDROM that has the same key. Please allow me to use 
one if the other isn't available.

GIMP vs GEEK
Consider that also you may want to remotely destroy your data - instead 
of a phone home msg from a stolen laptop you might want the laptop to 
also PULL from a location and if it finds a key phrase it detonates the 
data - completely wipes the harddrive. This pull prevents the various 
firewalls from blocking your initiation of destruction. Nothing saying 
you can't delete your data and leave a broadcasting honeypot either!
This situation also warrents mentioning of a dead-man's switch. If I 
don't provide a password token within 'X' minutes/hours/days the system 
initiates data destruction. I know it is all encrypted - but you can't 
decrypt what doesn't exist. I makes it so they have to have hardware and 
have imaged your data before they begin brute-forcing it. (ok, ok, they 
could just put you in a dark space and begin breaking your fingers...)

Finally, if you are unfamiliar with the term you should look up TEMPEST. 
Although originally a method of blocking electronic transmissions that 
could be picked up by 'the enemy' by incasing computers in metal, there 
are several software methods, such as 'tempest fonts' that you may wish 
to consider in conjuntion with your efforts.
http://216.239.37.104/search?q=cache:ucOb7yYGZasJ:www.cl.cam.ac.uk/~mgk25/ih98-tempest-slides.pdf+tempest+software+techniques&hl=en&ie=UTF-8

NO LAPTOP's AN ISLAND:
We also need to address how you get your data off of your system and 
onto a new system securely. This includes backup. Once your data is 
encrypted you can of course copy the filesystem but you need to copy the 
ENTIRE filesystem. And you should be able to log in, and copy the system 
from within the system (which would in this scenario be an unencrypted 
system) to another computer. Yes, yes, easy enough to say use SSH, SCP, 
etc. but address this rather than having a gaping hole in your security 
plan (that hole being an uninformed end-user that is *ignorant*). Having 
a solution doesn't mean that you prevent another solution from being 
used, just that you've already thought it out and made it a no-brainer.

That's all my comments :)

Warm encrypted regards,

Norman


mike@××××.org wrote:

>I am interested in working on a secure laptop meta-project.  Laptop
>security is interesting because some amount of physical security must
>be addressed.  Laptop theft is big buisiness, after all.
>
>A well designed laptop operating system would be centered around encrypted
>filesystems and would have many applications:
>
>1.  People who want to protect their personal data from theft.
>
>2.  Buisinesses that want to protect secrets stored on their fleet
>of laptops.
>
>3.  Military applications -- laptops are all over today's battlefield
>and a lucky ambush could easily reap classified information.
>
>4.  Etc...
>
>A company named NAH6 (http://www.nah6.com) has a product like this.
>They use Linux in order to boot Windows from an encrypted volume.
>I would like to focus on a Linux environment as an end.  The idea is that a
>lost or stolen laptop will not give up any sensitive information.
>
>Here are the components I envision including their current status:
>
>1.  Encrypted root filesystem.  The 2.6 Linux kernel and util-linux 2.12
>will provide this using an encrypted loopback interface.  A speedier
>compromise is to use encrypted home directories only.  I maintain a PAM
>module, pam_mount, that mounts encrypted home directories transparently.  [ If
>you don't mind a shameless plug, there is an article about pam_mount in the
>August Linux Journal. ]
>
>2.  Encrypted swap partition (or no swap at all).  This is necessary because
>otherwise programs could swap secrets to a plaintext disk.  The 2.6 Linux
>kernel's encrypted loopback interface can do this.
>
>3.  An inproved authentication system.  Encryption algorithms are useless
>if a weak key is used.  Therefore it may be desireable to authenticate
>when booting and mounting an encrypted root filesystem (or mounting an
>encrypted home directory) using a physical token or other strong means.
>
>4.  An intrusion detection system.
>
>5.  Obviously, otherwise hardened software.
>
>Comments?  Has anyone else talked about this around here?
>
>--
>Mike
>
>
>--
>gentoo-hardened@g.o mailing list
>
>
>



--
gentoo-hardened@g.o mailing list