OASIS PKCS 11 TC

 View Only

  • 1.  C_EncapsulateKey and CKA_LOCAL

    Posted 09-12-2024 07:39

    Hi,

    the spec currently states that CKA_LOCAL is always set to FALSE.  This makes sense for the DH/ECDH variants of encapsulation given that the secret key is derived. 

    But for RSA-PKCS, RSA-OAEP, RSA-X509 and ML-KEM encapsulate operation, the secret key is directly/entirely generated in the token with no external input. Shouldn't the value of CKA_LOCAL be TRUE for this set of mechanisms?

    I don't see this as being any different from generating a symmetric key on Token A and then wrapping it off and unwrapping it on to Token B.  On Token A, CKA_LOCAL==TRUE and on Token B, CKA_LOCAL==false.

    For C_Decapsulate, I understand why CKA_LOCAL==FALSE.

    Thanks

    Darren



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


  • 2.  RE: C_EncapsulateKey and CKA_LOCAL

    Posted 10-24-2024 10:05
    Was there an answer to this comment?
    I do not remember hearing one at meetings and do not see one in my mail
    archive.

    On Thu, 2024-09-12 at 11:39 +0000, Darren Johnson via OASIS wrote:
    > Hi,
    >
    >
    > the spec currently states that CKA_LOCAL is always set to FALSE. This makes sense for the DH/ECDH variants of encapsulation given that the secret key is derived.
    >
    >
    > But for RSA-PKCS, RSA-OAEP, RSA-X509 and ML-KEM encapsulate operation, the secret key is directly/entirely generated in the token with no external input. Shouldn't the value of CKA_LOCAL be TRUE for this set of mechanisms?
    >
    >
    > I don't see this as being any different from generating a symmetric key on Token A and then wrapping it off and unwrapping it on to Token B. On Token A, CKA_LOCAL==TRUE and on Token B, CKA_LOCAL==false.
    >
    >
    > For C_Decapsulate, I understand why CKA_LOCAL==FALSE.
    >
    >
    > Thanks
    >
    >
    > Darren
    >
    >
    > ------------------------------
    > Darren Johnson
    > THALES
    > ------------------------------
    >
    >
    > Reply to Sender : https://groups.oasis-open.org/eGroups/PostReply/?GroupId=2731&MID=513339&SenderKey=3f070387-8dee-4cac-95fe-018dcac0bc98
    >
    > Reply to Discussion : https://groups.oasis-open.org/eGroups/PostReply/?GroupId=2731&MID=513339
    >
    >
    >
    > You are subscribed to "OASIS PKCS 11 TC" as simo@redhat.com. To change your subscriptions, go to http://oasis.connectedcommunity.org/preferences?section=Subscriptions. To unsubscribe from this community discussion, go to http://oasis.connectedcommunity.org/HigherLogic/eGroups/Unsubscribe.aspx?UserKey=bc41eb59-01f8-48d1-b3ab-01910465bdb5&sKey=KeyRemoved&GroupKey=663447a7-9ffe-4dea-940e-018dce2b3da9.

    --
    Simo Sorce
    Distinguished Engineer
    RHEL Crypto Team
    Red Hat, Inc


    Original Message


  • 3.  RE: C_EncapsulateKey and CKA_LOCAL

    Posted 10-24-2024 13:51
    > Was there an answer to this comment?
    > I do not remember hearing one at meetings and do not see one in my mail
    > archive.
    We didn't give one.

    My 2c:

    Local means locally generated. The question is "Are KEMs locally
    generated". KEMS can be created out of KEX like DH or KEA (like RSA).
    Logically kems use the public keys as part of the operation and thus the
    encapsulated key is logically not purely generated locally. However Many
    Kems are implemented as a KEA wrapping a generated key. ML-KEM is even
    weirder. It's a KEX used to generate a transport key for a KEA and the
    encapsulated key is purely generated locally.

    So do we surface the underlying KEM mechanism in the CKA_LOCAL, making
    it mechanism specific for C_Encapsulate, or do we says these are
    effectively protocol keys who's underlying usage an purpose is they are
    'logically' dependent on the recipient's public key.

    I personally lean toward the latter interpretation, but
    1) we should be purposeful in which ever way we go.
    2) this is not a strongly held preference and interpreting them they way
    Darren supposed is not unreasonable (though it means we'll need to add
    CKA_LOCAL to each encapsulation mechanism.. and deal with funky things
    where the key may be derived from a local key and part of the public key
    (actually ML-KEM is the latter. a random key is mixed with the public
    key via a KDF to create the encapsulated key. The random key is
    encrypted using a ML-KEA and in the Decaps state the random key is
    decrypted and mixed with the public key via the KDF).
    >
    > On Thu, 2024-09-12 at 11:39 +0000, Darren Johnson via OASIS wrote:
    > > Hi,
    > >
    > >
    > > the spec currently states that CKA_LOCAL is always set to FALSE.
    > This makes sense for the DH/ECDH variants of encapsulation given that
    > the secret key is derived.
    > >
    > >
    > > But for RSA-PKCS, RSA-OAEP, RSA-X509 and ML-KEM encapsulate
    > operation, the secret key is directly/entirely generated in the token
    > with no external input. Shouldn't the value of CKA_LOCAL be TRUE for
    > this set of mechanisms?
    > >
    > >
    > > I don't see this as being any different from generating a symmetric
    > key on Token A and then wrapping it off and unwrapping it on to Token
    > B. On Token A, CKA_LOCAL==TRUE and on Token B, CKA_LOCAL==false.
    > >
    > >
    > > For C_Decapsulate, I understand why CKA_LOCAL==FALSE.
    > >
    > >
    > > Thanks
    > >
    > >
    > > Darren
    > >
    > >
    > > ------------------------------
    > > Darren Johnson
    > > THALES
    > >


    Original Message


  • 4.  RE: C_EncapsulateKey and CKA_LOCAL

    Posted 10-24-2024 15:13
    On Thu, 2024-10-24 at 17:50 +0000, Robert Relyea via OASIS wrote:
    > Local means locally generated.

    Yes "but what dos it reaaally mean?"

    Jokes aside, this CKA_LOCAL flag is something I have not look into
    closely, what do people use it for? How is it important where a key is
    generated?

    Simo.

    --
    Simo Sorce
    Distinguished Engineer
    RHEL Crypto Team
    Red Hat, Inc


    Original Message


  • 5.  RE: C_EncapsulateKey and CKA_LOCAL

    Posted 10-24-2024 18:07
    What CKA_LOCAL means is very clearly defined in the specification. Wrapping and then unwrapping does not preserve the value of CKA_LOCAL as true - that is explicitly covered. Deriving keys also does not set the value of CKA_LOCAL to true.

    It is basically very clearly defined in terms of what the *application* has done - i.e. application calls to specific functions control the value of the attribute - not the underlying internal operations performed. It isn't defined as "generated locally" independent of the function that is used to perform that generation being listed. It does not stand conceptually alone. 

    For Key Objects:

    CKA_LOCAL - CK_TRUE only if key was either 
    * generated locally (i.e., on the token) with a C_GenerateKey or C_GenerateKeyPair call 
    * created with a C_CopyObject call as a copy of a key which had its CKA_LOCAL attribute set to CK_TRUE

    And

    The CKA_LOCAL attribute has the value CK_TRUE if and only if the value of the key was originally generated on the token by a C_GenerateKey or C_GenerateKeyPair call.

    For Domain Objects:

    CKA_LOCAL - CK_TRUE only if domain parameters were either 
    * generated locally (i.e., on the token) with a C_GenerateKey 
    * created with a C_CopyObject call as a copy of domain parameters which had its CKA_LOCAL attribute set to CK_TRUE

    And

    The CKA_LOCAL attribute has the value CK_TRUE if and only if the value of the domain parameters were originally generated on the token by a C_GenerateKey call.

    And

    - If C_CreateObject is used to create a key object, the key object will have its CKA_LOCAL attribute set to CK_FALSE.
    - The key object created by a successful call to C_UnwrapKey will have its CKA_LOCAL attribute set to CK_FALSE.
    - The key object created by a successful call to C_UnwrapKeyAuthenticated will have its CKA_LOCAL attribute set to CK_FALSE.
    - The key object created by a successful call to C_DeriveKey will have its CKA_LOCAL attribute set to CK_FALSE.

    It also:
    - Must not be specified when object is created with C_CreateObject.
    - Must not be specified when object is generated with C_GenerateKey or C_GenerateKeyPair.
    - Must not be specified when object is unwrapped with C_UnwrapKey.

    That is the entire definition of its meaning.

    It anyone is applying any meaning beyond that or for other object types other than Key Objects and Domain Objects or a meaning for functions other than C_GenerateKey or C_GenerateKeyPair (or C_CopyObject) then they are leaping beyond the specification text.

    Unless we have explicitly defined separate handling for CKA_LOCAL under C_EncapsulateKey (which we haven't as it also states CKA_LOCAL is FALSE) then there should be no confusion as to what it means *currently*. 

    Extending the definition to one that is *mechanism* dependent rather than *function* call dependent isn't a path that makes sense to me.

    I also think this is consistent because we have explicitly defined that C_DeriveKey does not set CKA_LOCAL to true so we are not implying some unstated limitation of the definition - we already noted it in terms of which called functions set the value and that deriving a key conceptually isn't one of those.

    Tim.




    Original Message


  • 6.  RE: C_EncapsulateKey and CKA_LOCAL

    Posted 10-24-2024 19:47

    THALES GROUP LIMITED DISTRIBUTION to email recipients

     

    Thanks everyone.

    That makes sense.  You are right, the spec is very clear on what CKA_LOCAL means and when CKA_LOCAL should be set to true.

    And the way Bob documented it is consistent with the rest of the spec.

     

    I was viewing things with a more strict definition of what "generated locally" means, but my definition wasn't in line with how the spec defines it.

     

    Thanks

     




    Original Message


  • 7.  RE: C_EncapsulateKey and CKA_LOCAL

    Posted 10-24-2024 20:09
    On Fri, Oct 25, 2024 at 9:47 AM Darren Johnson via OASIS <Mail@mail.groups.oasis-open.org> wrote:
    > I was viewing things with a more strict definition of what "generated locally" means, but my definition wasn't in line with how the spec defines it.

    There are many things in the specification we could (and I'd suggest would) do differently.
    But after 27.5 years of CKA_LOCAL being defined that way I think we should leave it alone and if we wanted some other meaning we would introduce a new attribute to cover it.

    CKA_LOCAL was added in PKCS#11 v2.0 published 15 April 1997 - it did not originally list the functions as part of the definition but it did have the current text within each function.
    It was PKCS#11 v2.1 published 22 December 1997 that added the explicit function references in the definition. I think we can reasonably presume someone felt it important to make it clear in the definition what was spread out across each of the functions for similar reasons to why you raised this. 

    I've always mentally read it as meaning that the application explicitly asked the token to generate the key.

    Tim.




    Original Message


Related Content