|
Hi
Robert
thanks again for your
comments
Sorry to ask so many
questions, but I am a little bit lost to identify the minimum
requirement of a PKSC11 token to supprt NSS/TLS.
I am a little bit
confused about the usage of an hardware token for TLS handshake. I do not
understand why it has been included in WIM definition, if it does not bring more
security.
I have understood that
server is not aware if client use a softtoken or an hardware
token.
I am working in mobile
terminal environment, and I have not yet study the impact to support TLS
PRF function in software (RAM,ROM,MIPS).
Is the software random
of NSS compliant with TLS PRF definition.
I have notice, that
current NSS version use CKM_TLS_PRF_GENERAL mechanism, but new PKCS11 version
2.2 refers CKM_TLS_PRF using specific parameters. This version mentions also
that some parameters should be ommited when then C_DERIVE is
called.
PRF (pseudo random function) in TLS, denoted
CKM_TLS_PRF, is a mechanism used to produce a securely generated pseudo-random output of arbitrary
length. The keys it uses are generic secret keys.
It has a parameter, a CK_TLS_PRF_PARAMS
structure, which allows for the passing of the input seed and its length,
the passing of an identifying label and its length and the passing of the
length of the output to the token and for receiving the output.
This mechanism produces securely
generated pseudo-random output of the length specified in the
parameter.
This mechanism departs from the other key derivation
mechanisms in Cryptoki in not using the template sent along with this
mechanism during a C_DeriveKey function call, which means the
template shall be a NULL_PTR. For most key-derivation mechanisms,
C_DeriveKey returns a single key handle as a result of a successful
completion. However, since the CKM_TLS_PRF mechanism returns the
requested number of output bytes in the CK_TLS_PRF_PARAMS structure
specified as the mechanism parameter, the parameter phKey passed to
C_DeriveKey is unnecessary, and should be a
NULL_PTR.
SSL module uses
CKM_TLS_PRF_GENERAL, should we map it on CKM_TLS_PRF
ssl3_ComputeTLSFinished(ssl3CipherSpec
*spec,
PRBool
isServer,
const SSL3Finished *
hashes,
TLSFinished * tlsFinished)
{
PK11Context *prf_context;
const char *
label;
unsigned int len;
SECStatus rv;
SECItem param = {siBuffer, NULL,
0};
label = isServer ? "server finished" :
"client finished";
len =
15;
prf_context =
PK11_CreateContextBySymKey(CKM_TLS_PRF_GENERAL, CKA_SIGN,
spec->master_secret, ¶m);
....
I was not able
to find any reference to CKF_RANDOM definition nor in NSS code, nor in PKSC11
standard definition. Where should i clain supporting random
generation.
For my first
demonstration step I do not need to create a TLS client compatible with all
tokens types such FIPS. I have only to demonstrate a TLS connection with server
and client authentication, using RSA key exchange method and one cipher suite
(RC4 is fine). I would like to investigate impact of using a
WIM.
Mozilla try to
find this object on our token? What is this object class? is It a specific NSS
object classe.
10: C_FindObjectsInit
[in] hSession = 0x1
[in] pTemplate[1]:
CKA_CLASS Value CE534354 not found for type CK_OBJECT_CLASS
Returned: 0 CKR_OK
When NSS/SSL
fails to do an action with a slot, does it try with an other slot or an other
token, which supports all the required mechanism ?
In which case NSS/TLS need to
create secret, private key objects?
In which case NSS/TLS need
to unwrap key and decript? when temporarily key are
used?
See in text new
questions on possible solutions for using NSS for this
investigation
regards
Hubert
Helaine, Hubert wrote on Wed, 31 Mar 04, 5:45
AM:
Hi
Robert
thanks a lot for
your comments
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.
HH: Do you means
SSL/NSS does not support split of crypto functions between two tokens
when no token supports all functions.
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.
HH: My problem until
now is that SSL does not use my external token, or may as it fails it
moves to the internal module to recovery. :
We
have configured this module has the default one for SSL and
TLS
The module claim to support the following mechanism:
/*
------------------------- RSA Operations
---------------------------*/
{CKM_RSA_PKCS, {128,CK_MAX, CKF_SIGN |
CKF_UNWRAP }, PR_TRUE},
/* ---------------------- SSL Key Derivations
------------------------- */
{CKM_SSL3_PRE_MASTER_KEY_GEN, {48,
48, CKF_GENERATE}, PR_FALSE},
{CKM_SSL3_MASTER_KEY_DERIVE, {48, 48, CKF_DERIVE}, PR_FALSE},
{CKM_SSL3_MASTER_KEY_DERIVE_DH, {8, 128,
CKF_DERIVE}, PR_FALSE},
{CKM_SSL3_KEY_AND_MAC_DERIVE, {48, 48, CKF_DERIVE},
PR_FALSE},
{CKM_SSL3_MD5_MAC, {
0, 16, CKF_DERIVE}, PR_FALSE},
{CKM_SSL3_SHA1_MAC, { 0, 20, CKF_DERIVE}, PR_FALSE},
{CKM_MD5_KEY_DERIVATION, { 0, 16,
CKF_DERIVE}, PR_FALSE},
{CKM_MD2_KEY_DERIVATION, { 0, 16, CKF_DERIVE},
PR_FALSE},
{CKM_SHA1_KEY_DERIVATION, {
0, 20, CKF_DERIVE}, PR_FALSE},
{CKM_TLS_MASTER_KEY_DERIVE, {48, 48, CKF_DERIVE}, PR_FALSE},
{CKM_TLS_MASTER_KEY_DERIVE_DH, {8, 128,
CKF_DERIVE}, PR_FALSE},
{CKM_TLS_KEY_AND_MAC_DERIVE, {48, 48, CKF_DERIVE},
PR_FALSE},
/*
------------------------- RC2 Operations ---------------------------
*/
{CKM_RC2_KEY_GEN, {1, 128,
CKF_GENERATE}, PR_TRUE},
{CKM_RC2_ECB, {1, 128,
CKF_EN_DE_WR_UN}, PR_TRUE},
{CKM_RC2_CBC, {1, 128,
CKF_EN_DE_WR_UN}, PR_TRUE},
{CKM_RC2_MAC, {1, 128,
CKF_SN_VR}, PR_TRUE},
{CKM_RC2_MAC_GENERAL, {1, 128,
CKF_SN_VR}, PR_TRUE},
{CKM_RC2_CBC_PAD, {1, 128,
CKF_EN_DE_WR_UN}, PR_TRUE},
/*
------------------------- RC4 Operations ---------------------------
*/
{CKM_RC4_KEY_GEN, {1, 256,
CKF_GENERATE}, PR_FALSE},
{CKM_RC4, {1, 256,
CKF_EN_DE_WR_UN}, PR_FALSE},
Do we need to claim
supporting
{CKM_RSA_PKCS_KEY_PAIR_GEN,{128,CK_MAX,CKF_GENERATE_KEY_PAIR},PR_TRUE},
if yes why?
Do we need to claim
supporting
/*
------------------------- Hashing Operations -----------------------
*/
{CKM_TLS_PRF_GENERAL, {0, 512,
CKF_SN_VR}, PR_FALSE},
CKM_TLS_PRF
Which operation need
to be supported by CKM_RSA_PKCS? CKF_SIGN, CKF_UNWRAP,
CKF_VERIFY
we have noticed that Mozilla
call unwrap with CKM_RSA_PKCS even if we do not include it in the
flag list. Why?
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
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]
__________________________________________________
|
