[Cryptography Team] FIPS OpenSSL Crypto++ and CryptoAPI

[Kyle Hamilton]

On 10/12/06, Ron Teitelbaum <Ron at usmedrec.com> wrote:
> Hi Kyle,
>
> Welcome again to the team.  I am very happy to have you as part of our
> validation effort.  I am looking forward to working with you to meet your
> goals and I'm very interested in learning more about what you are working
> on.  I hope that we can all learn more about the validation process and that
> we can help teach others.

I'll see what information I can get from other sources, obviously, but
I'm quite certain we'll ALL get a lesson in government bureaucracy
here. :P

> Here is a link to my original email after talking to the lab:
> http://lists.squeakfoundation.org/pipermail/cryptography/2006-July/000211.ht
> ml I spoke with J. Mark Braga of SAIC CMTL http://www.saic.com/infosec/cmtl/
> they were very clear that 140-2 - level 2 validation is what most software
> systems work towards.  There is a possibility that I misunderstood or that
> the -2 and level 2 got confused, but that seems unlikely since, as you said,
> 140-1 doesn't apply.

It is entirely possible that what Mr. Braga was referring to was the
fact that everything to be validated MUST comply with FIPS 140-2
(i.e., version 2), not version 1... simply because version 1 is no
longer validatable.  As I mentioned in an earlier mail, there is no
software system which is validated to any level higher than level 1
(even Microsoft Windows Server 2003's FIPS.SYS kernel module -- and
you can bet that if MS could have gotten a higher level of validation,
they would have).

>  I guess my understanding was that the security policy
> needed to include standards that must be followed for someone else to have a
> 140-2 level 2 validated system derived from our code.

That is correct.  This turns it from a "low-assurance" scenario to a
"medium-assurance" scenario -- as long as the security policy states
that there are implementation requirements necessary to get medium
assurance, which become the responsibility of the IT staff which
supports the system (which includes audit logs, tamper-evident tape to
seal the machine from any hardware modification, appropriate security
administration and privilege separation, and so on).

But, if the software that performs the encryption isn't validated to
perform to level 1, then all the above procedures don't make the
implementation FIPS-validatable.

>  I also understood
> that we needed a reference implementation that exhibited these standards,
> but I figured we would set that up somewhere once we needed too.  In order
> to support the physical requirement I figured we needed to say in our
> security policy that the server needed to be in a locked room with a lock
> pick resistant door, and those that have a key need to have clearance
> through a process that includes...  I have no idea what to think about
> TCP/IP access and I guess if that completely invalidates level 2 then I
> can't imagine that most systems used comply with level 2 validation (unless
> TCP/IP in a secure WAN is acceptable).

It doesn't necessarily invalidate level 2, but it makes it MUCH more
difficult to validate, as all possible inputs need to be tested to
ensure that the cryptographic boundary cannot be breached.  I may be
wrong about "no possible covert channel" being a requirement for level
2, but I'm fairly certain it's necessary for level 3.


> We need more clarity around this issue, but it doesn't have to happen now,
> first things first.  I'm sure there is a lot more we will learn as we go.

Aye.  First, we need to figure out what we're going to use, and how
we're going to use it.

> You goals for helping to increase the usage of cryptography fit very nicely
> with the stated goals of this team.  Your p2p project opens up some very
> interesting questions as to security since it is the client that needs to be
> secured and the hardware is potentially in the hands of the attacker.  I am
> also very interested in this question and I hope that we can spend some time
> discussing this, either in the group or off line.

I'll gladly spend time discussing it (though it really may not belong
here).  There's an application called RapidShare, at
http://www.lunamutt.com/ , that does at least part of what I want to
do... but its key and identity management are very poor at best, and
it has an unaudited web of trust implementation.

> Welcome to the team!

Thanks! :)

I notice that you're from US Med Rec; it may also interest you that
I'm attempting to build a set of specifications by which at the very
least auditing can be implemented for any attempted access to a
database.  (In my case, I'm expanding the capabilities of a MUD
software's database layer in order to more proactively find attempted
violations of security policy, and I must use C to do it -- but it's
my experience that implementation can be done in any language as long
as the policy is specified and the appropriate methodologies are used
during development.)  This might have some good aspects for HIPAA
compliance, if appropriately specified.  (Access to and use of keys
are also good candidates for this type of audit logging -- which
brings it back into scope for purposes of this list. ;) )

-Kyle H