OASIS PKCS 11 TC

 View Only

  • 1.  Allowing the generation of private key objects only

    Posted 09-12-2024 07:57

    Hi,

    Is there a need to allow applications to only generate a private key object instead of generating the key pair.  This is something we see often in our own infrastructure as well as customer deployments.

    Steps Performed:

    • generate key pair
    • extract public key attribute(s)
    • sometimes a certificate object is created on the token, or externally
    • delete public key
    • locally use private key for sign/decrypt/derive (depending on the specific use-case)

    Most (but not all) private key types already contained the public key information. Now that we have the CKA_PUBLIC_KEY_INFO attribute, all private keys will have the corresponding public key information.  So we could support a method for only generating the private key object to eliminate the extra overhead of creating and deleting the public key object; which significantly improve ephemeral/single-use key pair use-cases. 

    I could see this working in at least two ways:

    1. Support private key generation through the C_GenerateKey API, where only a single template is provided (the private key template plus the required attributes that were typically only provided in the public key template).
    2. Enhance C_GenerateKeyPair in a way that will instruct the token to only create the private key objects; potentially by only providing a single template (the private key template plus the required attributes that were typically only provided in the public key template).

    To support this, we may want a token flag that would indicate if this type of functionality is supported or not.

    There may be other ways to support this.  These are the only two solutions that we have considered so far.

    Thanks

    Darren



    ------------------------------
    Darren Johnson
    THALES
    ------------------------------


  • 2.  RE: Allowing the generation of private key objects only

    Posted 09-12-2024 12:58

    Hi,

    Is there a need to allow applications to only generate a private key object instead of generating the key pair.?? This is something we see often in our own infrastructure as well as customer deployments.

    Steps Performed:

    • generate key pair
    • extract public key attribute(s)
    • sometimes a certificate object is created on the token, or externally
    • delete public key
    • locally use private key for sign/decrypt/derive (depending on the specific use-case)
    This use case, where you have the cert and key on the token, it's probably best *NOT* to delete the public key from the token (see publicly readable certs profile). That said, I think you are more interested the the ephemeral use case.

    Most (but not all) private key types already contained the public key information.

    Actually, This is really only true of RSA, however:

    Now that we have the CKA_PUBLIC_KEY_INFO attribute, all private keys will have the corresponding public key information.??

    I think this is the thing that makes the idea plausible.

    So we could support a method for only generating the private key object to eliminate the extra overhead of creating and deleting the public key object; which significantly improve ephemeral/single-use key pair use-cases.

    The ephemeral/single-use key pair use-cases. Aren't as outlined above, but may have a similar semantic.

    • generate ephemeral key pair.
    • extract the public key (via it's attributes)
    • Send those attributes in a protocol
    • delete public key....
    • Receive ciphertext from protocol
    • complete KEM/KEK/KEX operation.
    • delete private key.

    I could see this working in at least two ways:

    1. Support private key generation through the C_GenerateKey API, where only a single template is provided (the private key template plus the required attributes that were typically only provided in the public key template).
    2. Enhance C_GenerateKeyPair in a way that will instruct the token to only create the private key objects; potentially by only providing a single template (the private key template plus the required attributes that were typically only provided in the public key template).

    To support this, we may want a token flag that would indicate if this type of functionality is supported or not.

    yes, or we could have a C_GenerateSinglePrivateKey API. We are post PKCS #11 v3.0, so new functions for new operations is now considered the norm.

    There may be other ways to support this.?? These are the only two solutions that we have considered so far.

    Obviously this is a 3.3 or later enhancement:).

    bob

    Thanks

    Darren



    ------------------------------
    Darren Johnson
    THALES
    ------------------------------




    Original Message


  • 3.  RE: Allowing the generation of private key objects only

    Posted 09-17-2024 05:59

    THALES GROUP LIMITED DISTRIBUTION to email recipients

     

    Thanks for the feedback.

    I agree. This is certainly for 3.3 or later.

    I like the new API suggestion.

     

    We can discuss this on the next call. And if we think the idea has merit, I can work on a proposal based on whichever of the three options we think make the most sense.

     

    Thanks

    Darren

     




    Original Message


  • 4.  RE: Allowing the generation of private key objects only

    Posted 09-18-2024 17:04

    Random thoughts/questions:

     

    I'm not clear on what problem is being solved with this proposal.

    These would all be with CKA_TOKEN FALSE?

    The point is to skip having to delete the public key object?

    Would a "delete on session close" option that deletes all objects created during that session be sufficient/better?

     

    Thanks!

     

    Sincerely,

    Jonathan

     

     

     




    Original Message


  • 5.  RE: Allowing the generation of private key objects only

    Posted 09-18-2024 20:24

    THALES GROUP LIMITED DISTRIBUTION to email recipients

     

    Hi,

    I guess it isn't solving a real problem so much as it is addressing a huge inefficiency in specific use-case like one-time-use/ephemeral keys.

    The public key is not used on the token, so there is no need to create it.  That eliminates the overhead of creating another object on the token as well as deleting it.

     

    The types of keys "should" be created with CKA_TOKEN=false.  And that means they are stored in a much faster type of storage type (typically RAM) and both creation and deletion are much faster.  But that still doesn't mean they take an insignificant amount of time. Especially for network attached devices.

     

    I don't think relying on a C_CloseSession call to clean up the object makes the most sense either.  Sessions are often reused for performance reasons as well.  This may result in many public key objects being accumulated by the token such that the eventual call to C_CloseSession will be significantly slower as it will have many more objects to delete.  Not to mention consuming resources/memory of a token. 

     

    Thanks

    Darren

     




    Original Message


Related Content