Re: [Cose] Key management in the World of COSE

[Göran Selander <[e-mail]>]

On 2015-05-07 06:01, "Jim Schaad" <[e-mail]> wrote:

>
>
>> -----Original Message-----
>> From: Göran Selander [mailto:[e-mail]]
>> Sent: Wednesday, May 06, 2015 6:05 AM
>> To: Jim Schaad; [e-mail]
>> Subject: Re: [Cose] Key management in the World of COSE
>> 
>> Hi Jim
>> 
>> Sorry for the delay. I first describe the needs I see from an ACE point
>>of view,
>> and then later try to map this to the examples in your mail.
>> 
>> From the ACE perspective there are at least two sorts of information
>>flows
>> where COSE objects may be relevant (see sections 2.3-2.4 of
>> http://www.ietf.org/id/draft-gerdes-ace-actors-05.txt):
>> 
>> A. The interaction between potentially constrained endpoints. This
>>includes
>> wrapped subsets of CoAP messages, e.g. resource representations.
>> 
>> B. "Control information” for constrained devices. This include
>>information
>> necessary for authentication and authorization of the other potentially
>> constrained endpoint, including wrapped keys/security contexts,
>>credentials
>> such as public keys or certificates or other assertions.
>> 
>> 
>> Another assumption that may be important here is that we assume that in
>> some cases we can assume some security state can be kept between sender
>> and receiver over several message exchanges (keys, key identifiers,
>> sequence numbers, . . .). I don’t know if your examples assume some
>>aspect
>> of statelessness?
>> 
>> 
>> In terms of message protection, here are the security constructs we had
>>in
>> mind:
>> 
>> a. Symmetric integrity protection  — e.g. MAC(sk, m) b. Symmetric
>> encryption + symmetric integrity protection — e.g. AEAD(sk, m) c.
>> Asymmetric integrity protection — e.g. Sign(PrK, m) d. Symmetric
>>encryption
>> + asymmetric integrity protection — e.g. AES(sk, m); Sign(PrK, AES(sk,
>>m))
>> 
>> sk=symmetric key, m=message, PrK=private key, PK=public key
>> 
>> We assume in all these constructs that the keys used are
>>pre-established, or
>> that new symmetric keys can become established.
>> 
>> In order to reference a pre-established key we assume there is a key
>> identifier associated to the key, e.g. using the "kid" parameter, or
>>some
>> variant allowing distinction between symmetric/asymmetric key here
>> denoted "skid"/"akid". The identifers needed differ between the cases:
>> 
>> a. skid = <identifier of sk>
>> b. skid = <identifier of sk>
>> c. akid = <identifier of PK>
>> d. skid = <identifier of sk>, akid = <identifier of PK>
>> 
>> To allow establishment of new symmetric keys we see use for the
>>following
>> methods in combination with a-d.
>> 
>> (i) AES(sk1, sk2)
>> (ii) Enc(PK, sk2)
>> (iii) ECDH-ES
>> 
>> (i) and (ii) are key push methods based on known recipient key (sk1 and
>>PK,
>> respectively). Method (iii) assumes the inclusion of sender "epk"
>> header parameter and using a known static DH-key of the receiver (and
>> known KDF etc.)
>> 
>> When this key establishment is part of a message exchange as above, it
>> replaces the "skid" parameter used in one of the methods a-d above. It
>> should actually result in the generation of a new key identifier "skid"
>> for the established key, which can be referenced in later exchanges.
>> 
>> We also see the need for establishing keys and key identifiers without
>> combining that with other message exchange, i.e. integrating the key
>> establishment methods with relevant integrity protection such as for
>> example:
>> 
>> (i) + a (key transport of symmetric key with integrity protection,
>>based on
>> shared key)
>> (ii) + c (key transport of symmetric key with integrity protection,
>>based on
>> asymmetric keys)
>> (iii) + a (DH key establishment based on sender ephemeral PK and
>>receiver
>> static PK, authenticated with shared key)
>> 
>> 
>> Further comments inline:
>> 
>> 
>> 
>> On 2015-05-01 00:57, "Jim Schaad" <[e-mail]> wrote:
>> 
>> >I wanted to try and look closer at Carsten's call for more numbers in
>> >different applications, but before I can do that I need to figure out
>> >what applications there are and which ones are currently thought to be
>> >of greater importance.  I have tried to start by looking at the
>> >different security constructs that may be used for these applications
>> >in terms of what the needed security characteristics are.
>> >
>> >1. Integrity based on recipient asymmetric key:  I expect that this is
>> >not a common scenario to happen for CoRE systems.  This scenario
>> >requires that the sender get a certified public key for the recipient
>> >and uses that, along with some ephemeral data local to it, to create a
>> >short term shared secret used to protect the integrity of the message.
>> >This scenario provides no indication of where the data originated, thus
>> >it can be used to create a message for multiple recipients.  An example
>> >of how this would be implemented is the use of CBC-MAC with ECDH-ES
>> key
>> >agreement plus KDF.
>> 
>> Do you mean "it can NOT be used to create a message for multiple
>> recipients”? I don’t see that it actually provides integrity, since
>>anyone could
>> wrap a symmetric key with the recipient public key and replace the MAC.
>>In
>> any case, I agree that this is probably not a common scenario.
>
>Do not conflate the concepts of integrity with the origination.  This
>method only provides integrity.  The message has not been changed since
>it was sent.  You have no idea who sent it.  It could be somebody who
>just generated an ephemeral key and did the key agreement operation and
>sent you a message.  There is no need to postulate somebody who changed a
>message that they received.  In this case all you know is that the
>message was not sent since it was changed, not who sent it.

OK. There are other aspects of integrity which are still not source origin
authentication, e.g. where the verifier has can assert the verification
key but without being able to authenticate the prover. But that is a
different setting.




> Thus a message can be sent to multiple people - they all can verify that
>the integrity on the message is intact and none of them can know who sent
>the message.

Since in this case the integrity is based on recipient asymmetric key, I
assume there would be one instance of public key encrypted secret for each
receiver. I don’t think that will be a common scenario for integrity.

>
>
>> 
>> 
>> >
>> >2. Integrity and low-level origination based on a short term shared
>>key:
>> >Under the current system this would be setup using a DTLS session along
>> >with an extractor to establish the key.  The key would be for
>> >"short-term" use (i.e.  hours not days or weeks).  The option only
>> >provides for point-to-point integrity not end-to-end integrity.
>> >Integrity can be forged by any party that knows the shared-secret.  In
>> >this mode, there needs to be a single recipient of the message.  If
>> >this condition is met, origination is shown by saying "I did not make
>> >this message so the other party must have done so." Origin of the
>> >message cannot be proved to a third party.  An example of how this
>> >would be implemented is the use of CBC-MAC with direct key.
>> 
>> This corresponds to a. above.
>
>No it does not - not the addition of origination that was missing in the
>first case.


I understand your distinction. In essence we make different assumptions
how the direct key was established. You assume DTLS have been run. In my
text I only assume that there is a key identifier associated to the key
and they are both known to the verifier. How the key was established and
whether the key holder was authenticated is left open. In both a and 2 we
agree that this is implemented using a MAC. Why does it matter for the
format how the key was established?

>
>> 
>> >
>> >3.  Integrity and low-level origination based on a long term shared
>>key:
>> >Under the current system this would be setup using a pair-wise key
>> >established between two entities.  The key would be for "long-term" use
>> >(i.e.  weeks or months).  Given that this is a long term used key, the
>> >problem of replay and potential forgeries is greater.   For this
>>reason,
>> >some type of key derivation on the shared security would be suggested.
>> >The option only provides for end-to-end integrity between the parties.
>> >Integrity can be forged by any party that knows the shared-secret.  In
>> >this mode, there needs to be a single recipient of the message.  If
>> >this condition is met, origination is shown by saying "I did not make
>> >this message so the other party must have done so." Origin of the
>> >message cannot be proved to a third party.  An example of how this
>> >would be implemented is the use of CBC-MAC with direct key plus KDF.
>> 
>> I see this as a minor variant of 2. I assume there will be some
>>algorithm
>> identifier that could optionally reference a KDF, and if it does then
>>it is case
>> 3 otherwise case 2. Or what else is the difference?
>
>The difference here is a question of how long one can use a single shared
>key without having problems and how to increase that time period.  If you
>just got a new key from a key agreement operation, then you can use it
>for a while.  On the other hand if you have a key which is hard coded
>into the device, it makes sense to send messages which are not encoded
>with that key but with a secret derived from that key.  This means that
>compromise of the key is a two operation reversal rather than a single
>operation reversal.  Both the integrity on the message and the KDF need
>to be reversed.

Yes I agree with that. What I thought that could be implicit in the cipher
suite definition. Again I don’t see how it impacts the format.

>
>> 
>> 
>> >
>> >4.  Integrity and low-level origination based on two asymmetric keys:
>> >This scenario requires that both the recipient and sender of the
>> >message have well known key agreement keys.  Both entities must be able
>> >to get these either from a trusted third party or over some type of
>> >protocol that includes doing a proof-of-possession check on both sides.
>> >Once this is done, a one-time shared security is generated that is used
>> >to provide both end-to-end integrity protection and a degree of
>>origination
>> knowledge.
>> >Origination of the message cannot be proved to a third party.  Both
>> >parties must have a key that is in the same group.  A uniqueness value
>> >must be interjected into the key agreement process by at least one of
>> >the parties.
>> >It is sufficient that a counter be used for this purposes, it is not
>> >necessary for this value to be random.  An example of how this would be
>> >implemented is the use of CBC-MAC with a ECDH-SS key agreement plus
>> KDF.
>> 
>> I don’t see how this or 9. adds much to the setting we look at.
>> 
>> Either there is a shared secret between the sender and receiver. Then
>>there
>> is no need to do a Diffie-Hellman to derive a fresh shared secret, a KDF
>> would do. Or, the public key of the sender is not known to the
>>receiver, and
>> then this seems to be very similar to ECDH-ES (6. below).
>
>The assumption in this case is that one does know the public key of the
>recipient - either it is hard coded in the system or there is a method of
>querying for it.  It is quite possible that this is not a commonly used
>scenario.

This is a case where the trusted third party (authorization server) in the
ACE architecture should step in and support the authentication process by
providing the recipient public key to the sender (as then would need to be
specified in ACE).


>
>> 
>> 
>> >
>> >5. Integrity and high-level origination based on sender asymmetric key:
>> >This scenario requires that a true signature algorithm be defined and
>> >used as well as the ability for a recipient to query a trusted third
>> >party that the binding of identity and public key is true.  Using this
>> >allows for the origination and integrity of a message to be proved to a
>> >third party, the signature is not directed at any specific party.  An
>> >example of how this would be implemented is the use of ECDSA with SHA-
>> 256.
>> 
>> This corresponds to c. above
>> 
>> >
>> >6.  Confidentiality and integrity based on recipient asymmetric key:
>> >This scenario shares most of the same functionality as does scenario 1.
>> >The required integrity can be obtained by the use of an AEAD algorithm
>> >rather than a MAC algorithm.  An example of how this would be
>> >implemented is the use of AES-CCM with ECDH-ES key agreement plus
>> KDF.
>> 
>> This is (iii) + b. above
>
>Note - this case does not tell you who sent the message - note the
>absence of origination from the title.  This is the reason for doing
>ECDH-SS instead.

I agree with your distinction. Same question as above about why it matters
how the key was established.

>
>> 
>> >
>> >7.  Confidentiality, integrity and low-level origination based on a
>> >short term shared key: This scenario shares most of the same
>> >functionality as does
>> >scenario 2.   The required integrity can be obtained by the use of an
>>AEAD
>> >algorithm rather than a MAC algorithm  An example of how this would be
>> >implemented is the use of AES-CCM with direct key.
>> 
>> This corresponds to b. above.
>> 
>> >
>> >8. Confidentiality, integrity and low-level origination based on a long
>> >term shared key:  This scenario shares most of the same functionality
>> >as does scenario 3.  The required integrity can be obtained by the use
>> >of an AEAD algorithm rather than a MAC algorithm.  An example of how
>> >this would be implemented is the use of AES-CCM with direct key plus
>> >KDF.
>> 
>> Again a minor variant of 7.
>> 
>> >
>> >9. Confidentiality, integrity and low-level origination based on two
>> >asymmetric keys:  This scenario shares most of the same functionality
>>as
>> >does scenario 4.    The required integrity can be obtained by the use
>>of
>> >an
>> >AEAD algorithm rather than a MAC algorithm.  An example of how this
>> >would be implemented is the use of AES-CCM with ECDH-SS key
>> agreement
>> >plus KDF.
>> 
>> See scenario 4 above
>> 
>> >
>> >10. Confidentiality, integrity and high-level origination based on
>> >sender asymmetric key:  This scenario shares the integrity and
>> >origination requirements of scenario 5, however the algorithm choice
>> >there does not provide an confidentiality.  A different confidentiality
>> >mechanism must be used.  Any of the methods used in scenarios 5-9 could
>> >be used for this purpose.  Getting both sets of functionality will
>> >required the use of a wrapped message scenario where the signed
>> message
>> >is wrapped inside of an encrypted message.  (Attempting to do both in
>> >the same message was removed between PKCS #7 and CMS due to security
>> >flaws.  It was possible to both determine who the message signer was
>> >and to do traffic analysis on the content of the message by looking at
>> >the hash of the resulting signature.)
>> 
>> 
>> We are looking for something like d. above. I think this is something
>> different? The comment about security flaw in PKCS#7 seems from your
>> short explanation to relate to sign-then-encrypt, is there also an
>>issue with
>> encrypt-then-sign?
>
>No - my note relates to sign-and-encrypt.  It is not a problem here for
>either sign-then-encrypt or encrypt-then-sign.  Depending on what you
>want to do with the message, sign-then-encrypt is a better thing to do.
>Note since this is asymmetric it is not the same issue as the
>MAC-then-encrypt issues that TLS has.

Could you please explain or provide a pointer to some reference what is
the problem with d and why sign-then-encrypt would be better?

Thanks
Göran

>
>> 
>> A combination of 7 and 5 is an option to d, but replacing an AEAD with
>>AES
>> probably be more optimal.
>> 
>> 
>> >
>> >Which of these ten scenarios do we believe are going to be commonly
>> used?
>> >What percentage of the time do we think these options are going to be
>> >used?
>> 
>> It is difficult to predict, but I would expect the messages related to
>> interaction based on existing keys (A) would be more prevalent than the
>> message related to control information and establishment of keys (B).
>> Further that point-to-point messages would be more prevalent than point-
>> to-multipoint. Hence the most common would be a. and b., followed by c.
>> and d., followed by (i)-(iii) in combination with a-d.
>> 
>> Göran
>> 
>> >This will give us some starting data to look at which structures are
>> >going to be the most commonly used and get a start on which fields in
>> >the structures are going to be present.  There will be some follow on
>> >questions to try and make this determination.
>> >
>> >Jim
>> >
>> >
>> >_______________________________________________
>> >Cose mailing list
>> >[e-mail]
>> >https://www.ietf.org/mailman/listinfo/cose
>