[Cryptography Team] re: Common Criteria Documentation...

[Kyle Hamilton]

On 10/17/06, Krishna Sankar <ksankar at doubleclix.net> wrote:
> > there's a lot more to it than that.  Are we going to split
> > efforts between cryptography/FIPS and the remainder of the CC
> > validation, and maybe do it more quickly?  Are we going to
> > focus on FIPS first, and only after we get something that we
> > can submit for validation then worry about the remainder for CC?
> <KS>
>         Yep, good thoughts. As you correctly point out, first we should aim
> for the smallest subset possible; after a successful validation, we can
> extend it. That way we get our infrastructure in place, the processes ironed
> out and get overall experience. We still will have to address some of the
> fundamental issues, but hopefully they are manageable.

The fundamental design (that the VM is self-hosted) is a fundamental
issue -- but, as you say, it should be manageable.  It will take a lot
of work, though.

FIPS 140-2:
- make the timequeue not a singleton, or make a usertimequeue subclass
of the timequeue and call its dispatch whenever the system itself
isn't doing anything (this is just an idea, I don't know how well it
would work... I haven't delved into the scheduling)
- Ensure that the cryptographic objects cannot be changed, cannot be
reflected, and cannot be later diverted (this will be difficult)
- Ensure that cryptographic objects have a critical section capability
(so that the VM can't be written out while unencrypted key data is in
memory)
- Ensure that once a "secure mode" is set, the VM does everything it
can to avoid being debugged by either a native debugger or any
debugger within the VM (to avoid reflection and modification of any
system object and prevent the cryptographic objects from being
reflected)
- Ensure there's a way to verify that the crypto code hasn't been tampered with
- Ensure there's a way to verify that the system code hasn't been tampered with
[etc...]

CC:
- Create the notion of a "security principal", and ensure that private
data of one cannot be accessed by any other (including private keys,
but also including processes)
- Create quotas, by which VM space (and disk space, and processing
time, and so on) cannot be hogged by any individual security principal
[etc...]


>         And as Ron points out, the authenticated site et al can come after
> we go thru a dry run. We should still keep a track of the activities,
> results et al, but not in a strict authenticated way until we have all the
> ducks in a row.

Alright.  I just offer ideas, as I usually do.  If we don't keep track
of it in a strictly-authenticated fashion, we should still be able to
do it via Monticello (especially the unit tests, which should be
written just to verify output from the real routines -- the CSRC at
NIST has a large set of test vectors for various algorithms for
informal verification of correctness, before the full validation is
performed).

>         One important aspect we need to think about now is this minimal
> subset - and what it should consist of and what it should achieve.

I would think, at a minimum, that it should include implementations of:
- at least one FIPS-approved symmetric-key cipher
-- at least two FIPS-approved modes of operation
- at least one FIPS-approved asymmetric-key cipher
- at least one FIPS-approved HMAC function
- at least one FIPS-approved hash function
- at least one FIPS-approved pseudo-random number generation function

- design interfaces to each type if they don't already exist, improve
interfaces if necessary

- Implementation of SSL3/TLS1/TLS1.1/TLS1.2 using defined interfaces
- Implementation of ASN.1 parser and BER/DER/XER encodings of ASN.1
- Implementation of X.509v3/PKIX (aka, PKI)
- Implementation of Certificate Signing Request generation
- Implementation of certificate generation (self-signed, at the least,
and perhaps operate as a CA)
- Implementation of OpenPGP

- Implementation of Image Signing/Verification

>         I will also read thru, understand the current environment and think
> thru the paces. If we can get the cryptography engine certified, it will be
> a win. Am not sure it can be done separately, though.

"A CC evaluation does not supersede or replace a validation to either
FIPS 140-1 or FIPS 140-2. The four security levels in FIPS 140-1 and
FIPS 140-2 do not map directly to specific CC EALs or to CC functional
requirements. A CC certificate cannot be a substitute for a FIPS 140-1
or FIPS 140-2 certificate." --
http://csrc.nist.gov/cryptval/140-2CC.htm

I think it has to be done separately.  Honestly, I'm not sure it can
be done together.

I'm about to upload a whole blob of FIPS, NIST special publications,
and test vectors that I just downloaded from the NIST website to the
Google project.  (Again, just getting everything in one place, since
it's been a bear to find it all in the first place.)

-Kyle H