Dean wrote, On 2008-07-23 09:08: > Thanks for the answers Wan-Teh and Nelson ... and I do agree with both > of you that the work around would be an abuse of FIPs and I shouldn't > do it if I hope to claim FIPs compliance. > > I'm clearly missing a piece of the puzzle. > > Essentially I have an SSL implementation that I want to change to use > only FIPs certified crypto .... effectivly (hopefully) resulting in a > FIPs compliant JSSE implementation.
But, IINM, such a thing already exists. Does that wheel need reinventing? > I suspect I should be trying to write JNI to wrap the NSS SSL libraries > themselves That's already been done. It's called JSS. http://www.mozilla.org/projects/security/pki/jss/ > and write a JSSE implementation to that API ... I'm not entirely sure, but I think JSS claims to be a JSSE implementation, and if you use it, you can be assured of real FIPS compliance. I think you also have the option of using Java's JCE provider that is actually just a wrapper for PKCS#11, and using a FIPS certified PKCS#11 module (such as NSS) through that interface. I believe that is how Sun's Java SSL (JSSE) provider achieves a claim of FIPS compliance: they use NSS's PKCS#11 module through that JCE/PKCS#11 provider. (But, I'm not sure that they actually do claim FIPS compliance with that.) > Back to the issues of key data. In the client side of an SSL > connection you do not have to decrypt key material from the server. > For the client the pre_master_secret comes from key material passed in > plaintext from the server Strictly speaking, the client random and server random values are not "key material", as that term is used in the FIPS 140 context. > and material generated privately by the client. The client then applies > key expansion functions to the pre_master_secret to end up with bytes to > construct the necessary SecretKeys. (The server does the same, > independantly except it has received the client's contribution to the > pre_master_secret as RSA encrypted data) > > So how can this be done in a FIPs compliant way. In the world of FIPS, you have the concept of a "module". All the keys live in the module, at all times, with these exceptions: public keys (as appear in certs), and session keys that are "wrapped" (encrypted) with those public keys. Keys go in, and do not come out, (except wrapped, under limited circumstances where that is permitted). Keys may be generated in the module, or they may be "unwrapped" in the module from their wrapped form that is input to the module, or they may be derived from a combination of data that is input to the module and a key that is already in the module. All those operations take place in the (FIPS certified) module, and the keys that result generally do not come out of the module. The keys in the module may be used to encrypt or decrypt data that passes in and out of the module, but the keys themselves don't come out (generally). Things done inside the module are done using "handles" for the keys, rather than the values of the keys. > I guess the answer is there must be that NSS has some FIPs approved APIs > that performs the key expansion functions? In a FIPS environment, all those functions must take place inside the module, and the results do not leave the module. > Does anybody have any pointers to relevant functions? If they exist can > I even call these Yes, you call them, but the keys are only in the module, not outside. You call functions that operate on key material that is only inside the module. > or would that still break the spirit of FIPs by passing raw > pre_master_secret bytes generated outside of FIPs land into a FIPs > function? Yes it would. Since the PMS is a key, you would not generate it outside of the FIPS module, and the value would not be passed into (or out of) the FIPS module, except wrapped with the server's public key. > Or am I missing a fundamental design issue..... IE am I totally on the > wrong track here? Think about the work that must be done as being done in one of two places which are inside, or outside, of the FIPS module. The code must be designed to separate keys from data, and key all keys inside a module at all times, accessed by "handles", not by value. The big problem that most people have when trying to work in a FIPS environment for the first time is that they are totally accustomed to using keys by value, and using APIs that pass keys by value. The BIG problem that most folks have, trying to take code that was not written with FIPS in mind and trying to convert it to be FIPS compliant is that they find it difficult to get used to handling keys by handle. Software that was designed to pass everything by value may be difficult to change to get to use handles instead. I know that the Java crypto APIs all had that problem initially, and frankly I don't know what they've done to overcome it, if anything. A client generates a PMS, in the module, and gets a handle for it. The client imports the server's public key into the module, and gets a handle for the imported public key. The client tells the module to wrap the PMS with that public key, and output the wrapped PMS (being wrapped, it's just data). The client inputs the two strings of random bytes (which are just data) and the module derives the master_secret (MS) key from them using the PMS. The module returns a handle on the new MS key. The client inputs the random values again, and tells the module to derive the other keys (and IVs, if relevant) from those random values and the MS key, which the client specifies by handle. The module generates 4 keys for the connection (two encryption keys, two MAC keys, one pair for each direction), and outputs 4 handles. The client then invokes the module to do the bulk encryption/decryption and the bulk MACing using those handles. None of the keys (master secret, or encryption or MACing) ever leaves the module. On the server side, the server already has its private key in the module, and the server code has a handle for it. When the server receives the encrypted PMS, it inputs the encrypted PMS and unwraps it using the private key, which it specifies by handle. The module outputs a handle for the unwrapped PMS. The unwrapped PMS never leaves the module. The server then does the very same steps that the client did, deriving the MS from the PMS, and deriving the 4 connection keys, outputting their handles. The server application never gets to see the bits contains the values of any of these keys (PMS, MS, connection keys), because they never come out of the module. > Once again, thanks for any help you can provide. _______________________________________________ dev-tech-crypto mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
