[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 new pktool(1) command supports many new features. It includes

     gencert - creates a self-signed X.509v3 certificate<br>
     gencsr  - creates a PKCS#10 certificate signing request file
     import  - imports objects from an external source
     export  - exports objects from the keystore to a file
     list    - lists a summary of objects in the keystore
     delete  - deletes objects in the keystore
     download - downloads a CRL or certificate file from an external source
     genkey   - creates a symmetric key in the keystore
     tokens   - lists all visible PKCS#11 tokens
     setpin   - changes user authentication passphrase for keystore access

Although this pktool(1) command doesn't support keypair generation directly,
however, a RSA/DSA key pair will be generated internally for the gencert and
gencsr subcommand.

> 
>> 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.
>

I'm not familiar with the secure key management for Venus board on Solaris9.
So I consulted with the engineer who did the VCR driver for Solaris10 today.
She mentioned that there is a tool called "pk11export" which can export
a certificate and the associated private key from a Venus card.

If this is the feature that you concern, then it is actually supported in
the new pktool export subcommand already  The new pktool(1) also supports the import
command which will import the content of an PKCS12 file to a token.

Are these the features you are looking for ?

Back to my original proposal, the encrypt(1), decrypt(1) and mac(1) are existing
Solaris10 commands, what I am proposing are only enhancement to those commands
which I believe are not directly related to your concerns.

Am I missing something ?

>> 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.
> 

The new pktool(1) command is very comprehensive and supports many features
you mentioned, although it doesn't support key agreement at this moment.
It is part of KMF (key management framework) phase 1 deliveries which was
recently integrated into Solaris ONNV_53, which is included in the
Solaris Express B55 that you can download from the OpenSolaris download center.
We would welcome any feedback from you; please send your comments to
kmf-discuss at opensolaris.org.

When I sent out the proposal yesterday, I originally included the entire
new pktool(1) man page (22 page long).  However, the email bounced back because
the email body is too big, so I removed it and only included the diff file.
This might have contributed to some confusion.

Thanks,
Huie-Ying