Huie-Ying Lee wrote: > Garrett D'Amore wrote: >> Huie-Ying Lee wrote: >>> Hi, all: >>> >>> This proposal is about resolving the following 2 enhancement requests: >>> -RFE 4868006 (encrypt(1) and mac(1) needs to support token objects) >>> -RFE 6517162 (pktool genkey needs to support generic secret key) >>> >>> My preliminary proposal has been reviewed by the KMF core team. >>> Below is >>> the updated design and I would appreciate any comments by next >>> Tuesday, Jan/30. >>> >>> Thanks, >>> Huie-Ying >> >> >> The most useful way to deal with secret symmetric keys is to allow them >> to be used with key wrapping facilities (e.g. import a session key >> wrapped with one's one public key -- needing the secured private key to >> get at it) or with key agreement algorithms like Diffie-Hellman. >> Unless your design supports one or the other of these, I don't see much >> value in secured (as in a hard token) symmetric keys. >> >> Am I missing something? >> >> -- Garrett > > Hi, Garrett: > > Thank you for the comments. > > If I understand your email correctly, what you sugggested is to > provide key > wrapping facilities for a symmetric key to be used for key > exchanging. For example: > senerio: > > Party A > 1. Create a DES key > 2, Wrap it with party B's public key > 3. Sent the wrapped key to Party B > > Party B > 1. Receive the wrapped key from party A > 2. Unwrap it with party A's private key > 3. use the DES key to comunicate with party A
You've already corrected in a separate e-mail the error in Party B line 2 above. > > If my guess is correct, I think this is good suggestion and can be > addressed in a seperate enhancement. And to support this new > enhancement, > I think we also need to enhance "pktool" to support keypair generation > which > is not supported directly for now. Absolutely. I've not looked at pktool yet, but the ability to manage key pairs (as well as the certificates associated with them) is critical for any system that purports to be for secure PKI management. > > The current Solaris encrypt(1), decrypt(1), and mac(1) commands > are simple, they just takes a keyfile or a passphrase, converts that to > a session key, then perform the crypto operations. A user needs to > store the keyfile safely or remember the passphase that he/she uses for > each key. These are pretty limited forms of use, and not suitable for commercial users who need to manage their key material securely (e.g. government users that need to comply with FIPS 140-2.) The Venus board (vca driver) under Solaris 9 supports secure key management (I've not looked at it since Solaris 10), and it would be nice if products like this could interact with the common Solaris tools in a "standard" way. > > The RFE 4868006 here is just to add the token object support to these > 3 commands, > which allows a user to use a key that is already in a PKCS11 > keystore. If a user > uses many keys for various tasks, with the token object support, > he/she only needs > to remember the pin to the keystore, instead of mantaining many > keyfiles or > remembering many passphrases. Yes, but I think you will find far, far fewer users of this feature than you would if the system supported key exchange or agreement as I've suggested. The need for a solution to the problems I've out lined is largely behind the existence of the Venus (SCA 4000) and Mars (SCA 6000) products. I would humbly suggest you make certain that your design features include plans for key wrapping, key unwrapping, key pair generation (and export of the public key and ideally creation of an appropriate certificate), and key agreement (diffie-hellman). It is also important to note that PKCS#11 provides standard facilities for these, so it should not be hard to add support to userland tools as long as you are using PKCS#11 underneath. -- Garrett D'Amore, Principal Software Engineer Tadpole Computer / Computing Technologies Division, General Dynamics C4 Systems http://www.tadpolecomputer.com/ Phone: 951 325-2134 Fax: 951 325-2191
