On 7/8/2015 4:47 PM, ma...@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.
_______________________________________________
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss
