On 10/17/06, Krishna Sankar ksankar@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
cryptography@lists.squeakfoundation.org