[Discuss] NAS: encryption

[Richard Pieri]

On 7/8/2015 4:47 PM, markw at mohawksoft.com wrote:
> There are a lot of moving parts. Take for instance, the AES encryption
> algorithm. This is a known quantity and you can "trust" that it works when
>   given any two independent implementations of it can encrypt/decrypt.

Yes. And this is one of the ways that FIPS 140-2 certification is 
useful. It means that a test lab accredited by NIST has verified that, 
among other things, a given implementation of AES is correct. Or at the 
very least correct per the security profile and the security level being 
tested against. Likewise key generation and key management if these are 
part of the security profile.


> Next, how safe is your private key? Why use brute force when the key can
> be had by bad programming?

This is where problems like compiler optimizations can bite you really, 
really hard. Private keys can be exposed even with the best code if it's 
compiled incorrectly. OWASP has a simple example here:

https://www.owasp.org/index.php/Insecure_Compiler_Optimization

That's assuming the compiler generates good object code. All bets are 
off if the compiler is broken:

http://lkml.iu.edu/hypermail/linux/kernel/1407.3/00650.html


> "trusting" that a closed system like encrypted hard disks is probably OK,
> but if you are paranoid, it isn't.

There is an attack against software-based encryption like dm-crypt that 
most of you probably have not considered, an attack that has nothing to 
do with code or compilers or key management but with drives themselves. 
The attack is possible because of logical block addressing (LBA).

One of the features of LBA drives is a self-repair mechanism. All LBA 
drives ship with a reserve of unused blocks. When the failure of an 
allocated block is detected by the controller a reserve block is 
allocated, the contents of the original block are copied to the reserve 
block, the new block is mapped over the original block, and the original 
block is deallocated. This is automatic and transparent. Normally it is 
not possible to access these deallocated blocks but replacing the 
controller with a recovery controller will grant access to the entire 
medium.

If self-repair happens to blocks encrypted by the OS then you will have 
multiple identical blocks on the medium. If a new block is changed then 
you have an information disclosure similar to changing the contents of 
an encrypted container stored on a copy-on-write file system. If an 
attacker can identify the nature of the change then he may be able to 
parley that into a known plain text attack against the affected blocks.

Self-encrypting drives should be resistant to attacks against data 
remnants if the encryption is implemented below the self-repair 
mechanism. Encryption is always on (the lock/unlock mechanism controls 
access, not encryption) so even unlocked SEDs should be resistant.


 > We should all be paranoid.

I'm going to flat out disagree with this last assertion. Paranoia is an 
irrational fear. We should not be paranoid. We should be rational about 
security.

-- 
Rich P.