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

[Robert Relyea]

Helaine, Hubert wrote on Wed, 31 Mar 04, 5:45 AM: Hi Robert   thanks a lot for your comments   I am not a security expert, but my request is due to the definition of WIM (Wireless Identifier Module) by OMA (Open Mobile Alliance) originated by WAP forum. ref. Find attach a link to the version 1.0 which is public, but not TLS compliant. ( http://www.openmobilealliance.org/tech/affiliates/wap/wapindex.html :  WAP-260-WIM-20010712-a document: http://www.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?DocName=/wap/wap-260-wim-20010712-a.pdf ) So there are two issues here: WTLS and using WIM in TLS. In the WTLS case, you will need to implement the entire WTLS protocol and add it to mozilla. NSS does not implement WTLS. Then there is just using the WIM in TLS. In this case the only server facing information about the fact the WIM is being used is when the WIM signs the VerifyCertificate message. None of this has anything to do with the master secret.   My understanding on the add value of using an external token for SSL/TLS handshake, but not for the symetric encryption is: - benefit of a high quality for random number for the pre-master secret Softoken already provides this. It will even use entropy from your token if you advertise CKF_RANDOM on your token flags. - encrypt the pre master secret, using public server public key to be sent to the server (pre-master does not live the token) Softoken handles this OK as well (if it generated the pre-master secret)... though I presume you mean 'pre-master does not leave the token' - Sign H is executed by the token, using client private key so client private key does not leave the token Your token will have to do this. NSS uses the client private key based on the client cert (NSS chooses the CERT you want to use, then uses that cert to locate the key. Once NSS locates the private key, it uses the token the key lives in to do the signing... except for the export key function (which is expected to fail on tokens), NSS never tries to extract a private key it just uses it in place. This part should already work for you. This is also the only part that a remote server will see. - Session keys are derivated by the token from the Master key (master does not live the token) Again the Softoken handles this correctly (assuming it generated the pre-master secret. - Pre-master and Master secret do not leave the token So the pre-master secret and master secret stays in the tokens, but the individual session keys *DO* leave the token? This is a quite unusual scenario. Usually either no symetric keys are protected are all keys are protected. What is the threat model you are trying to protect from?   In conclusion, the token is used to protect all asymetric part of the handshake, used to exchange the secret key material. The master and pre-master secret are part of the symetric handshake. In the RSA case, the only private key in use by the client  is the signing key.   Please could you comment   Whatever the security add value, I need to implement a demonstration of this scenario. What is the best solution to support split of asymetric and symetric operation for handshake: 0- configure secmod database to force use of plugin token for SSL or TLS Key material generation: according to your comments not possible 1- Disable CKM_SSL3_PRE_MASTER_KEY_GEN, CKM_SSL3_PRE_MASTER_KEY_DERIVE, CKM_SSL3_KEY_AND_MAC_DERIVE mechanism from Internal Module: is it a good idea, which file need to be modified ? No, If you do your system is likely not to function is some instances. You might be able to get away with truning of SSL3 or TLS in the softoken flags, though in that case I still think some things might break.   2- Change the token selection policy for selection of token for SSL: is it a good idea, which file need to be modified ?   This will break FIPS complient tokens which only do some of the Symetric operations. You wind up in situations where you have the key you need in a token that won't give it up, but can't do the requested cipher. That is why SSL uses the selection criteria it currently uses. 3- Enable DESxxx, RC2xxx, RC4xxx mechanisms in my token, but map service on the internal module: may be possible but a lot of work. Not necessarily. First I would only do RC4. It's 99.99% of the SSL connections out there anyway. Do you really care if NSS falls back to softoken in the AES, DES, and RC2 cases. If you really want your token to do any of the SSL handshake, then it really should do all of it.   Again, there is no way a server can tell if the WIM is used to generate the pre-master secret or not, so it is not possible for any server to depend on this.   bob _______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto