Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Back to the OP: Re: Server/laptop full-disk encryption

On 10/1/2014 12:06 PM, Rich Braun wrote:
> Discussion on this topic has veered from the technical -- what's the state of
> open-source or low-cost key-server and encryption software today -- to the
> tactical: why bother?

As it must at some point: even if I were an FAA-certifiend Airframe and 
Powerplant mechanic who could tell you everything there is to know about 
the Continental engine in a Cessna 152, I would be unwise to buy one for 
personal use if I had a wife and two kids to take on vacation. However 
much I might admire the Continental engine or the high-wing design, I'd 
be unwise to ignore the fact that a Cessna 152 has only two seats.

> I'll address the why-bother: I live in the heart of the tech capital of the
> world, San Francisco.  The city is seeing a surge in property crimes, and a
> crook not only grabbed a laptop right out of the bedroom but if he'd chosen to
> do so, could have gotten one or more of the servers which contain a lifetime
> of private data. The use-case is pretty trivial to describe: if a server is
> lost to a future theft, I'd lose sleep over the what-if scenarios of crooks
> who have enough savvy to fence stolen hard-drives to organized extortion rings
> or others who are able to exploit stolen data.

Well, a lifetime of private data is worth backing up, but whether you 
need to protect it from disclosure is a different matter. Unless the 
data contains images of you in SCA garb with a hock of mutton in your 
hand, and you are an elected official who is publicly associated with a 
vegetarian lifestyle, there's little need to worry about it: most 
"private" data is either innocuous, or not traceable back to it's owner 
by any practical means.

And, in most cases, the best practice is to safeguard only images which 
identify the owner by sight, and then only if that sight would turn the 
stomachs of all but the most sophisticated of collectors. Even there, 
the best defense is often a "Publish and be damned!" attitude: after 
all, it /IS/ the twenty-first century. Absent clear evidence of illegal 
activity, "private" data is almost always as exciting as a DOS script, 
and less memorable than President Clinton's question about what the 
definition of "is" is.

This is, jokes aside, an important distinction: national security 
screenings always start with the admonishment that all the government 
cares about is what it *DOESN'T* know, and blunt promises that an 
individual's private life will remain private so long as it can't be 
used to coerce him/her to behave in unacceptable ways.

> That's a far-fetched scenario, perhaps, in a far-flung suburb of Boston but
> I'm not crazy to defend against it here in SF.

It's not crazy to defend against it anywhere: I used to live on Stanyan 
Street next to Kezar Stadium, so I'm familiar with the area. I now live 
in a far-flung suburb of Boston, it's true, but there are risks to 
consider, and precautions necessary, in far-flung suburbs as well as in 

> I will repeat the acceptance-criteria that I raised in my OP:
> (a) the keys are convenient, readily accessible at every reboot
> (b) the keys can't readily fall into the wrong hands

Fingerprint scanner.

> (c) infrequently-accessed filesystems aren't accessible except when needed
> (d) generated keys and pass-phrases have sufficient entropy
> (e) the keys and pass-phrases can survive *me* (e.g. by somehow keeping an
> up-to-date version in a bank safe-deposit box in case I get hit by the
> proverbial bus)

Those are features of every well-designed secure data management system, 
but I'm not familiar with the open-source offerings.

> My model for this is the commercial key-storage systems (and/or HSMs) sold by
> companies like SafeNet and Vormetric.
> Running through the installation procedure for Debian/Ubuntu would, of course,
> encrypt the root filesystems but that's not my question:  I know /how/ to run
> cryptsetup on filesystems of my existing already-installed servers.  But I
> want to address the issues above which aren't addressed by merely typing a
> pass-phrase into an installation script, hoping for the best, and avoiding
> getting hit by a bus or forgetting the pass-phrase (which by the way I do all
> the time: I am forever hitting the forgot-password links at the myriad
> websites which require PW auth).

I use Password Safe, and therefore need only to remember one passphrase 
for every website I use. It's on Sourceforge, but I digress.

> Security is really much harder than you think. My employer pays huge bucks for
> me to think about this on the job, and I can't help but to think about it for
> my personal data as well.

I agree that /some/ parts of security are harder than others: the 
hardest part of all being the decision about /what/ to secure. Your 
employer has a different threat universe to consider than you do as a 
private citizen. Once you decide what needs to be kept secret, and from 
whom, then you can address the mechanics.



E. William Horne
William Warren Consulting

BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!

Boston Linux & Unix /