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 Tue, Jul 7, 2015 at 1:31 PM, Richard Pieri <richard.pieri at gmail.com> wrote:
> On 7/7/2015 1:14 PM, Derek Atkins 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.
>
>
> Yes, there is a way to verify that they doing it correctly. It's called FIPS
> certification. If the drive does it incorrectly then the drive doesn't get
> certified.

If you are refering to FIPS_140-2, I would note this (unverified) info
from the Wikpedia
article:

https://en.wikipedia.org/wiki/FIPS_140-2

---
Reception

Steven Marquess[unreliable source?] has posted a criticism that FIPS
140-2 validation can lead to incentives to keep vulnerabilities and
other defects hidden. CMVP can decertify software in which
vulnerabilities are found, but it can take a year to re-certify
software if defects are found, so companies can be left without a
certified product to ship. As an example, Steven Marquess mentions a
vulnerability that was found, publicised, and fixed in the
FIPS-certified open source derivative of OpenSSL, with the publication
meaning that the OpenSSL-derivative was decertified. This
decertification hurt companies relying on the OpenSSL-derivative's
FIPS-certification. By contrast, companies which had renamed and
certified a copy of the open source OpenSSL-derivative were not
decertified, even though they were basically identical, and did not
fix the vulnerability. Steven Marquess therefore argues that the FIPS
process inadvertently encourages hiding software's origins, to
de-associate it from defects since found in the original, while
potentially leaving the certified copy vulnerable.[7][dead link]

---

Unless the FIPS certifying agency does code audits, it's impossible
for them to know if there are deliberate or inadvertent problems.
Since we are talking about code running in the firmware of a disk
drive, it is not inconceivable that there are all kinds of problems.
Using anything that is certified is more of a "butt covering, I won't
get fired" thing then any real guarantee of much more than basic
quality.  All programmers make mistakes and where security and
software is concerned that once in a million chance of hitting the bug
can approach certainty with a dedicated attacker.

Bill Bogstad



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