[kmf-discuss] Re: [crypto-discuss] request comments for 2 enhancements

[Huie-Ying Lee]

Garrett D'Amore wrote:
> 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.
>