[Discuss] NAS: encryption

[Derek Atkins]

"Edward Ned Harvey (blu)" <blu at nedharvey.com> writes:

>> From: John Abreau [mailto:abreauj at gmail.com]
>> 
>> "Edward Ned Harvey (blu)" <blu at nedharvey.com> writes:
>> 
>> > You seem to think there's an obstacle which isn't really real -
>> > Encryption is very cheap computationally, so cheap indeed it can be
>> > done by the disks themselves.
>> 
>> 
>>  On Tue, Jul 7, 2015 at 1:14 PM, Derek Atkins <warlord at mit.edu> wrote:
>> I don't trust my disks to do the encryption, mostly because there's
>> really no way to verify that it's doing it correctly, and the key
>> management gets a lot harder.
>> 
>> The way I read it, the message wasn't that you should trust the disk to do the
>> encryption; it's that encryption has very low overhead today, and the
>> reference to disk-based encryption was merely to illustrate that point.
>
> It seems silly not to trust the disk to do encryption, when you'd
> trust some software that you equally haven't decompiled and inspected.

You assume that I haven't done that.

However, more importantly, I can easily verify that the software is
doing it's job by booting the system without it and verifying the disk
is actually encrypted.  I can even verify *what* the encryption is
(which means I can use test vectors to verify that it's encrypting
properly and not doing something silly like rot13).

I.e., I can pick a sector, write some known plaintext to that sector
through the encryption, then turn off the encryption and read the
ciphertext off the disk and compare that to the expected ciphertext.
There's no way to do that kind of verification when you offload the
encryption to the disk.

> I am saying both: Encryption has very low overhead today, and yes it's
> ok to do it in the disk hardware. Nowadays, you can download a dozen
> different AES libraries in any language - including javascript. Not
> that javascript is relevant in context, just to point out, AES is
> SOOOOOO ubiquitous that it's literally everywhere and in
> everything. The idea that the disk is going to have a broken
> implementation of AES is beyond far-fetched, into unbelievable
> land. And like I said - it isn't any less likely to be the case in the
> overriding software. Which I guarantee also has a working
> implementation of AES.

This I do completely agree with.  AES is everywhere.  It's in our CPUs.
It's even in our microcontrollers and RFID cards!!!  It's pretty much
ubiquitous.  That doesn't mean it's actually *USED* correctly (most
implementation of AES are limited to ECB mode, not even CBC, let alone
XTR/CTR/CCM/GCM modes).

> The only thing you need to *actually* be concerned about is where do
> the keys come from, how do they get managed, and do they cause
> inconvenience. And I guess it wouldn't hurt to actually plug one of
> the disks into another system and confirm that encryption is *turned
> on*. But as long as it's turned on, and the keys are good and managed,
> yes I trust disk hardware to do the encryption just as much as I trust
> the application software.

This is also a concern, but I want verifiable encryption.  I don't know
how to verify on-disk disk encryption whereas I can verify off-disk disk
encryption.  (I admit that I haven't actually played with on-disk disk
encryption, but my understanding is that the disk firmware blocks
read/write access without proper keys instead of providing ciphertext).

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available