Re: Full Disk Encryption solutions selected for US Government use

Ben Laurie <benlinks.org> writes:
>Peter Gutmann wrote:
>> "Steven M. Bellovin" <smbcs.columbia.edu> writes:
>>> On Mon, 18 Jun 2007 22:57:36 -0700 "Ali,
Saqib" <docbook.xmlgmail.com> wrote:
>>>> US Government has select 9 security vendors
that will product drive
>>>> and file level encryption software.
>> Out of curiousity, are any open source FDE products
being evaluated?
>>
>> Given that it's for USG use, I imagine the FIPS 140
entry barrier for the
>> government gravy train would be fairly effective in
keeping any OSS products
>> out.
>
>? OpenSSL has FIPS 140.

But if you build a FDE product with it you've got to get the
entire product
certified, not just the crypto component.

(Actually given the vagueness of what's being certified you
might be able to
get away with getting just one corner certified, but then if
you have to use a
SISWG mode you'd need to modify OpenSSL, which in turn means
getting another
certification.  Or the changes you'd need to make to get it
to work as a
kernel driver would require recertification, because you
can't just link in
libssl for that.  Or...).

Peter.

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

Peter Gutmann wrote:
> Ben Laurie <benlinks.org> writes:
>> Peter Gutmann wrote:

>>> Given that it's for USG use, I imagine the FIPS
140 entry barrier for the
>>> government gravy train would be fairly
effective in keeping any OSS products
>>> out.
>> ? OpenSSL has FIPS 140.
> 
> But if you build a FDE product with it you've got to
get the entire product
> certified, not just the crypto component.
> 
> (Actually given the vagueness of what's being certified
you might be able to
> get away with getting just one corner certified, but
then if you have to use a
> SISWG mode you'd need to modify OpenSSL, which in turn
means getting another
> certification.  Or the changes you'd need to make to
get it to work as a
> kernel driver would require recertification, because
you can't just link in
> libssl for that.  Or...).


A slightly off-topic question:  if we accept that current 
processes (FIPS-140, CC, etc) are inadequate indicators of 
quality for OSS products, is there something that can be 
done about it?  Is there a reasonable criteria / process 
that can be built that is more suitable?

iang

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

On 8 Oct 2007 10:12:58 -0700, Stephan Somogyi wrote:
> At 02:11 +1300 09.10.2007, Peter Gutmann wrote:
> 
>> But if you build a FDE product with it you've got
to get the entire product
>> certified, not just the crypto component.
> 
> I don't believe this to be the case.
> 
> FIPS 140(-2) is about validating cryptographic
implementations. It is 
> not about certifying entire products that contain ample
functionality 
> well outside the scope of cryptographic evaluation.
That's more of a 
> Common Criteria thing.

Yes, but an FDE product built on the OSSL FIPS module would
not likely
meet the FIPS 140-2 check box, as there is potentially more
FIPS 140-2
relevant functionality in the FDE product beyond what was
validated in
the OSSL module, such as, say, the whole key life cycle for
the FDE
product. That does not necessarily mean all of the FDE
product is FIPS
relevant, so perhaps the FIPS relevant functionality in the
FDE product
could be self-contained and validated by itself, or perhaps
the whole
FDE product could be validated and the irrelevant
functionality just
excluded from the FIPS requirements, etc. (As Gutmann says
though,
vendors sometimes successfully employ a bit of hand-waving
here, so you
never quite know what will satisfy the FIPS check box.)

> At 14:04 +0100 08.10.2007, Ben Laurie wrote:
> 
>> ? OpenSSL has FIPS 140.
> 
> OpenSSL FIPS Object Module 1.1.1 has FIPS 140-2 when
running on SUSE 
> 9.0 and HPUX 11i, according to
> 
> <http://csrc.nist.gov/groups/STM/cmvp
/documents/140-1/1401val2007.htm#733>
> 
> In the context of a conversation about whether
something formally has 
> FIPS validation or not, the details are important.

Yes, the details are important. The OSSL FIPS module was
tested on those
platforms, but is vendor affirmed on other platforms,
assuming the
module meets the vendor affirmation requirements described
in the FIPS
140-2 implementation guidance on a given "other"
platform.

-Andrew

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

| A slightly off-topic question:  if we accept that current
processes
| (FIPS-140, CC, etc) are inadequate indicators of quality
for OSS
| products, is there something that can be done about it? 
Is there a
| reasonable criteria / process that can be built that is
more suitable?
Well, if you believe a talk by Brian Snow at the NSA - see
http://www.
acsac.org/2005/papers/Snow.pdf - our whole process has
to
change to get assurance, from the beginnings of the design
all the
way through the final product.

I suspect he's right - but I'm also pretty sure that the
processes
involved will always be too expensive for most uses. 
They'll even be
too expensive for the cases where you'd think they best
apply - e.g.,
in protecting large financial transactions.  An analysis of
the costs
vs. the risks will usually end up with the decision to spend
less and
spread the risks around, whether through insurance or higher
rates
or other means.

We keep being told that inspection after the fact will give
us more
secure systems.  It never seems to work.  You'd think that
the
experience of, say, the US auto industry - which was taught
by the
Japanese that you have to build quality into your entire
process, not
inspect *out* lack of quality at the end - would give us
some hint
that after-the-fact inspection is not the way to go.

Given all that ... a FIPS 140-2 certification is actually a
pretty
reasonable evaluation.  It can be because it's trying to
deal with
a problem that can be constrained to a workable size.  You
know what's
supposed to go in; you know what's supposed to come out. 
(This
still works better for hardware than for software, though.) 
Where
FIPS 140-2 breaks down is that ultimately all it can tell
you is
that some constrained piece of the system works.  But it
tells you
nothing, and *can* tell you nothing, about whether that
piece is
being used in a proper, secure way.  (Again, this is
somewhat easier
with hardware, because the system boundaries are much more
sharply
defined - and because of the inflexibility of hardware, they
are also
much smaller.)  Beyond this is Common Criteria, which can
easily be
more about paperwork than anything real.

Until someone comes up with a new way to approach the
problem, my
guess is that we'll see more stuff moved into hardware, with
limited
security definitions above the hardware that we can have
some faith
in - but as little of real value to be said above that as
there is
today.
							-- Jerry

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

At 10:55 PM +0200 10/8/07, Ian G wrote:
>A slightly off-topic question:  if we accept that
current processes 
>(FIPS-140, CC, etc) are inadequate indicators of quality
for OSS 
>products, is there something that can be done about it?

Highly doubtful. The institutional inertia at DoD/NIST is
too great. 
It has been suggested numerous times by numerous concerned
parties 
for at least a decade.

>Is there a reasonable criteria / process that can be
built that is 
>more suitable?

Yes. That part is easy, and some people in the system admit
designing 
a much better system is quite tractable, as long as it is
done in a 
vacuum. However, bureaucracy abhors a vacuum.

My feeling is that the only way that we can overturn the
silliness of 
FIPS-140 / CC is for a major defense ally to implement a
sane system. 
Five years later, and with a lot of vendor push, it could
become a 
third process and the other two could wither over the
ensuing 
decades. If we're lucky.


--Paul Hoffman, Director
--VPN Consortium

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com