Re: use of a PKCS11 plug in for SSL/TLS handshake for mozilla

[Robert Relyea]

Helaine, Hubert wrote on Tue, 30 Mar 04, 2:09 AM: Hi all We are trying to connect a WIM (WAP Identifier Module) smart card, using opensc software based. We have already managed populating all certificates, keys, PIN objects in mozilla databases and run a sign text, or a client authentication. We have registered TLS and SSL mechanisms in our module, but until now, we have not found the solution, to force Mozilla SLL/TLS module to use external plug in instead of internal module to generate the randow and key materials for TLS/SSL handshaking. We would like Mozilla SLL/TLS to continue to use internal module for symetrical cryptography operation (DES, RC2 ...) Please could you help us: there are some PKCS11 FAQ not very clear about this subject: is there a solution ? So NSS assumes that moving the key is expensive (in some cases, it may be impossible), so it works very hard not to move it. Doing server side SSL, you can force most of the operations in your token by the meer fact that the server's private key is in the token. In this case NSS will unwrap the master secret into the token, and continue to operate on that key in the token until if finds something that it needs to do with that key that the token can't do. It then moves the keys out to a different token to do the operation. From then on the key continues in the new token from then on as long as the new token can do all the functions it needs. OK, so far, so good, but what about your case. In this case what is happenning is NSS is looking for a token which can do the requested operation. Because NSS doesn't want to move the key about, and because NSS knows exactly what functions it needs to complete the handshake, NSS will ask for a token that can do all of: CKM_SSL3_PRE_MASTER_KEY_GEN, CKM_RSA_PKCS, and  the symetric algorithm negociated in the SSL handshake (this is assuming an RSA  SSL3/TLS handshake). If no token can do all three, then SSL falls back to just CKM_SSL3_PRE_MASTER_KEY_GEN and CKM_RSA_PKCS. What is happenning is the internal token can always do all three, so even though your token is registers as a prefered TLS, NSS findes that it can't to the symetric algorithm and moves on the the internal token. At this point one can ask, "what difference does it make which token is used for the Key Gen and derive operations?". Since the symetric operations are not done on your token, then the keys are available to software anyway. The internal token has a FIPS validated key generator used to generate the master secret, so the software generated master secret is cryptographically sound. Entropy for the key gen is collected from a number of sources (including hardware tokens which advertise that they are Random number generators). So there is no cryptographic reason to do the operation on the token except that the token is going to protect the keys. If you give them up to the software for a symetric operation, you've lost that as well. NSS tends to be pretty agnostic about where it does operations where there is no need to lock into specific keys (for example, signature verification with public keys.... pretty much happens on the internal token 99% of the time, but c ould be redirected to a token for most of those times as well). The underlying assumption NSS makes about the SSL protocol in tokens is that if  the token knows how to do all the key generation and derivation, then NSS would espect the token to take up the whole protocol before it begins to use it. From a security point of view, it's the only scenario that makes sense, and deciding how to split the work between various SSL components without making this assumption greatly complicates the SSL implementation itself. All that being said, I do not believe we have ever had anyone actually build a client-side "SSL engine"* (that is a token that does the entire SSL operation on the client). We have had experience with vendors building server side SSL engines (mostly we refer to those as accellerators, but some don't actually accellerate... they meerly completely control the keys. Often these devices are FIPS compliant), and we know that you can configure these devices (the FAQ focuses on these devices). If adding the symetric operation does not cause your token to be used in SSL operations (I suggest adding RC4 first as it's the most common SSL cipher negotiated), post back here about your experience and we'll see if there is more configuration that can solve your problem, or if there are actual bugs in our code. bob   ======= Our plugin provides several slots with different capabilities. For example, one does all the hashing/symmetric operations, while another does only asymmetric RSA operations. Can this kind of division lead to problems? The only issue is dealing with keys. For example, if the RSA slot unwraps a key, Communicator needs to move that key to a slot that can do the symmetric operations. Communicator itself uses two tokens internally--one that provides generic cryptographic services without authentication, and one that provides operations based on the keys stored in the user's database and do need authentication. Communicator does this to avoid having to prompt for a password when performing an RSA verify operation, DES encryption, and so on. Therefore, Communicator can move keys around when necessary and possible. In general, you should use different slots unless you have a good reason. Much of Communicator's token selection is based on where the key involved is currently stored. If the token that has your private keys doesn't also do symmetric operations, for example, it's likely that the internal token will end up doing the symmetric operations. If multiple PKCS #11 modules are loaded, how does Communicator determine which ones to use for the mechanisms required by SSL? Communicator uses the first slot it finds that can perform all the required operations. On servers, it's always the slot that contains the server's private key. If I have a multipurpose token that supports all required PKCS #11 functions and provides RSA_KCS and DSA mechanisms but only provides the SKIPJACK_CBC64 mechanism for encryption and no DES or RC4, will Communicator use the token for the RSA_PKCS mechanisms and the internal Netscape PKCS #11 module for DES or RC4 for an SSL connection? Once Communicator starts using a token for a given operation (like S/MIME or SSL), it works hard to keep using that same token (so keys don't get moved around). Symmetric operations supported by Communicator include the following: CKM_DES2_XXX, CKM_DES_XXX, CKM_RC2_XXX. Communicator knows about all the mechanisms defined in PKCS #11 version 2.01, but will not perform those that aren't defined by Communicator's policy mechanism. Regards Hubert __________________________________________________ __________________________________________________ Hubert HELAINE NEC Technologies (UK) Ltd FMDC E-mail : [EMAIL PROTECTED] __________________________________________________ _______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto