[Discuss] NAS: encryption
Chuck Anderson
cra at WPI.EDU
Wed Jul 8 11:06:32 EDT 2015
On Wed, Jul 08, 2015 at 10:49:40AM -0400, Richard Pieri wrote:
> On 7/8/2015 10:23 AM, markw at mohawksoft.com wrote:
> >The problem with internal drive encryption is getting any level of
> >disclosure and accountability.
>
> This is simply not true.
>
> FIPS security profiles are public record. Here's the security
> profile for the cryptographic module used in several of Seagate's
> enterprise SEDs:
>
> http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1299.pdf
>
> The process of obtaining the certificate is accountability in and of
> itself. The device or software is tested by an accredited test lab
> to ensure that it works as described in the security profile. If
> anything fails to work as documented then the device or software is
> sent back to the vendor to correct the fault or update the security
> profile.
I think this whole discussion revolves around choice. With open
source, I have a choice to audit the code if I so desire, or to hire
someone to do so on my behalf. With internal drive encryption, I have
(almost) no choice but to trust someone else's judgement about the
implementation, whether that be the manufacturer or the government or
some industry body or nonprofit. Their incentives and my incentives
may not always be aligned.
I say "almost" no choice, because I guess I could reverse engineer the
device. But this is much harder to do than if I had the source code
in the first place. Isn't that one of the major selling points of
open source software?
Even if I do not exercise my choice to audit the code, the mere fact
that anyone can chooose to do so at any time can be a deterrent to
trying to "pull a fast one" and hide malicious code in there.
More information about the Discuss
mailing list