BLU Discuss list archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss] NAS: encryption
- Subject: [Discuss] NAS: encryption
- From: bogstad at pobox.com (Bill Bogstad)
- Date: Tue, 7 Jul 2015 13:50:20 -0400
- In-reply-to: <559C0CFA.2040506@gmail.com>
- References: <5596D8DA.2000201@gmail.com> <55980A9F.4020007@gmail.com> <BY1PR0401MB1641117906253C39D8075681DC940@BY1PR0401MB1641.namprd04.prod.outlook.com> <sjmd203evpz.fsf@securerf.ihtfp.org> <559C0CFA.2040506@gmail.com>
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
- Follow-Ups:
- [Discuss] NAS: encryption
- From: richard.pieri at gmail.com (Richard Pieri)
- [Discuss] NAS: encryption
- References:
- [Discuss] NAS: buy vs. build
- From: tmetro+blu at gmail.com (Tom Metro)
- [Discuss] NAS: encryption
- From: tmetro+blu at gmail.com (Tom Metro)
- [Discuss] NAS: encryption
- From: blu at nedharvey.com (Edward Ned Harvey (blu))
- [Discuss] NAS: encryption
- From: warlord at MIT.EDU (Derek Atkins)
- [Discuss] NAS: encryption
- From: richard.pieri at gmail.com (Richard Pieri)
- [Discuss] NAS: buy vs. build
- Prev by Date: [Discuss] NAS: encryption
- Next by Date: [Discuss] NAS: encryption
- Previous by thread: [Discuss] NAS: encryption
- Next by thread: [Discuss] NAS: encryption
- Index(es):