Encryption, paranoia and virtual machines

[Jamon Camisso]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/25/2011 01:20 PM, Christopher Browne wrote:
> No, it assumes that the data is encrypted before transmission.  In
> that case, the server never receives it in unencrypted form, so that
> risk simply doesn't exist.
> 
>> For example, assuming physical access, what is to prevent someone from
>> running a forensic recovery tool on say /var/spool files, or on a swap
>> partition if either location handled data destined for the encrypted
>> database?
> 
> What prevents this is that the data was encrypted before it was
> received by this server.
> 
>> For me at least, while encrypting the whole disk is definitely a
>> shot-gun approach, the overhead is slight and reduces complexity. I
>> certainly don't notice any performance issues with AES on an SSD.
> 
> The problem is that encrypting the whole disk is the "Vitamin C as a
> cure for cancer" cure; it is quite likely that it only provides any
> protection in peoples' imaginations, rather than providing *actual*
> protection.
> 
> In order for "whole disk" encryption to function requires that there
> be an encryption key on the server, and if that is so, then that key
> IS vulnerable to being found by the system administrators.  Not "might
> be vulnerable" - it right well *IS* vulnerable to anyone with physical
> access, which makes any security being claimed into a mirage.
> 
> It doesn't matter how many people think good thoughts about this form
> of "security", they may feel good about Sacro Cranial Therapy, or the
> merits of homeopathy.  "Good feelings" don't make any of it effectual.

So here we have two different trust models at work. In the first case,
the assumption is that data is not being tampered with or siphoned off
at the origin *before* encryption. The source data is assumed to be
trustworthy.

This assumes a number of things about the network, physical security,
encryption being used etc. Crucially, this also entails trust in the
person(s) administering the box.

The second case is the human one, where the attempt is to mitigate
against the possible actions rogue administrator. This entails that
every system said administrator can access is locked down such that they
cannot interfere with the encryption, either at the source or
destination. But then who locks down the box in the first place? Another
administrator? A policy based configuration tool? Who hires that
administrator or controls those files?

Do you hire 2 administrators to check each others' work? What it they
team up and go rogue?

The crux of the issue is that at some point, a) the law of diminishing
returns kicks into effect, and b) you have to trust a person or a
machine or a network at some point. No matter how much work is done, at
a certain moment it becomes a leap of faith that the systems or the
people around you are trustworthy. I much prefer trusting in the latter,
however naive that might sound.

Jamon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJOz+I0AAoJEDJp9n+rTckFgbUP/0BhsoH6ujnest9Oj8+68y8i
ohHHGP8pRuuBXQHzBrMciT2JMOpaX72EUID6g77eE1Zkd6/vMZT8GBnQpk13YS58
L87VYWHOR96qTtc9Zlq5ghBto3GOvqrHEH9VcANbCI47MDkg8wz0cLLqwPBjeNK1
SNYss4p8xOx04NNRomOuIyp1dIgwEmQsOTUMBpULzm5ilxPd7E4MGB3kXuizMHyJ
ZLq710UUFmjicCmOV5aIUNi+Y/gu2+GBuL3YxFWgGWEhOfLvc/Vh1t89QNckcm8R
5B2oJ77aGVFVdX4/Rmofifr+Qlzd/nwbZlgMYN23+NJdHpZg2Nkuibmfby0+hHgx
rNUm7+wlP985gTQbk+PpBq5HaL4pH0OGFIme+BufNXFT+02XhilmL9VfXUBssLQJ
SS5BzBoe9314KtPko7tPFB95Pl0yRVTyRRrp/fcM2rZ2RfZm+VmfnGeoj4UpBizz
H9bAdRVc6bdLQUgZ+NiyBK85H3Zmn9VyJRHVUedlsGkfzeDzEdHxMZIUSmbA2IES
L4ahQR2+I0PeeO+qmFX9hzWlDNw1sVr855AtOf7YRfo67Ogqvve1/l17kXKGy1/Z
tA7sO2hKBvfhtsp4hPWbX5okKlubzGWtUFCjbEaFSxbVbypdlnhqRsz/6brhUkFg
tVTsCqwjDajJTmo8wPU+
=7aPl
-----END PGP SIGNATURE-----
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists