Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] NAS: encryption



On 7/9/2015 9:55 AM, Derek Atkins wrote:
> However.....  (and this is the big gotcha)...  the certification does
> not talk about HOW the crypto is used!  For example, if you're running
> disk encryption the *crypto* can be fully FIPS compliant, but it could
> still do something stupid with the FIPS-certified crypto.  For example,
> it could be using ECB mode instead of some chaining mode.  Or it could
> somehow store the keys in an unprotected mode.

Yup. There is huge misunderstanding about FIPS and CC. There is the 
assumption that if it is certified then it is good. That's not what the 
certifications mean. They mean that a product works as documented when 
used as documented.

If the security profile says it should be using CBC mode and it is in 
fact using ECB mode then it will not pass and it will not be certified. 
If the security profile says it should be using ECB mode and it does use 
ECB mode then it /will/ pass or at least it will not fail on this point 
because the product conforms to the security profile in this regard. If 
the security profile does not specify then it might pass anyway. Or it 
might not depending on the testing level.

 > [...]
> this is how it works; my understanding was that if the disk is encrypted
> then it wont give you any data without keys.  I.e., you cannot verify
> the encryption is correct.

That's not how SEDs work. Self-encrypting drives are always encrypted 
using the media encryption key (MEK) stored in the firmware. The MEK is 
itself encrypted using the key encryption key (KEK). When shipped, the 
KEK on a self-encrypting drive is null allowing unfettered access to the 
MEK. When you lock a SED you enter a password or phrase. This is hashed 
and stored on a small shadow volume on the drive and the MEK is 
encrypted using the KEK. When the drive is activated in the locked state 
the host sees only the shadow volume which tells the host that an unlock 
code is required. You enter the KEK, the firmware compares the hash with 
the stored hash, and if it matches then the drive decrypts the MEK and 
tucks it away in volatile memory deep inside the controller. Then the 
host is told to rescan the drive and voila! it sees the full disk.

Verifying the encryption entails replacing the controller with a 
non-encrypting controller.

-- 
Rich P.



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org