|
Hi
Robert
thanks a lot for your
comments
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
- encrypt the pre master
secret, using public server public key to be sent to the server
(pre-master does not live the token)
- Sign H is executed by
the token, using client private key so client private key does not leave
the token
- Session keys are
derivated by the token from the Master key (master does not live the
token)
- Pre-master and
Master secret do not leave the token
In conclusion, the token
is used to protect all asymetric part of the handshake, used to exchange the
secret key material.
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 ?
2- Change the token
selection policy for selection of token for SSL: is it a good idea, which
file need to be modified ?
3- Enable DESxxx,
RC2xxx, RC4xxx mechanisms in my token, but map service on the internal module:
may be possible but a lot of work.
Could you continue to
help me?
thanks
Hubert
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 ! could 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]
__________________________________________________
|
