Mailinglist Archive: opensuse (1620 mails)

< Previous Next >
Re: [opensuse] Fresh 13.2 install fail - two problems - help please
On 11/08/2014 06:45 AM, listreader wrote:
The brtfs looks fine, or at least I can browse what's in
there. The xfs partition, though, appears broken. I had LUKS
encrypted it during the install/format process but when I try to mount
I get the familiar bad old message about:

I am massively in favour of encryption, no matter what the FBI says, no
matter what the NSA says about it being the death of the 'berry.
http://www.zdnet.com/former-nsas-chief-lawyer-blackberrys-encryption-efforts-led-to-its-demise-7000035459/#ftag=RSS86a1aa4

But you'll note that both of these have to do with mobile devices.
You'll also note, I hope, that many of the stolen USB "breaches" were
unencrypted data on a _mobile_ data store.

I'm also massively in favour of encrypted data channels!

But I don't encrypt data on static machines.
(usually)

An encrypted FS or data store that is available in the clear while the
system is booted anyway makes no sense to me. It only makes sense if
the machine itself is physically insecure, that the drive could be
stolen. And not really even then; if the machine is physically insecure
the whole thing could be stolen, and booted, or the data extracted while
the machine was running, or, given physical access, a keystroke recorder
could be plugged in.

Per user encryption that is only made available in the clear by the
user, possibly, though I hope not, when the user logs in, begins to make
sense on a static machine that is protected from some classes of
physical hacking. One might reason that the "My Accounts" (or "My Nude
Pictures") is encrypted and only unencrypted while the appropriate
application is run, and re-encrypted at the end of that run.

Never the less, if the (static) machine is not physically protected a
keystroke recorder can be used to get the key prior to stealing the
encrypted data.

If the (static) machine is physically protected then I don't see the
justification for encrypted file system that is mounted & unencrypted,
at boot time by the kernel and kept unencrypted while the system is
running. It might make some marginal sense if the machine is off most
of the time, but I'd be hard pressed to justify that myself.

Then there's the issue of backups. Are they done of the encrypted FS or
are they done of the running, unencrypted FS? Are the backups, which
are not on portable media, encrypted and/or physically protected?

Then we get into the thorny matter of key management. If the kernel is
to automatically unencrypt & mount the FS at boot time then the kernel
need to know the key or have the key to the key management system (which
may be an encrypted file... And so on regressing indefinitely)


I'm sure people are going to disagree with what I've said. I *DO* want
to hear other reasoned views. But before you do, read what I've written
carefully. I've tried to make clear the difference between mobile
devices and mobile data on the one hand, and static machine such as
servers (in farms, at service providers) on the other, and to make clear
that the risks associated with allowing unlimited physical access to
static machines cannot be fully mitigated by encrypting file systems or
even individual files. Derived from the latter, if you have physical
protection then the value of encryption is ruined if the machine is
running with the file system mounted clearly accessible.

However it is the MOBILE which concerns me most. That includes backups
from the static machines. If we are talking about mobile data in any
form, be it backup takes, on cell phones/tablets, on laptops &
chromebooks, or stored in the cloud and flowing backwards and forwards,
then there is a good justification for encryption.

Encryption is not a magic ointment that one applies to cure ills and
protect from hackers. Having that attitude will lead you to disaster in
one form or another.




--
A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting frowned upon?

--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups
References