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

From: Ludwig Seitz <[email-masked]>
Date: Wed, 06 May 2015 08:55:59 +0200

On 05/01/2015 12:57 AM, Jim Schaad 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.
[...]
> 3.  Integrity and low-level origination based on a long term shared key:
[...]
>
> 8. Confidentiality, integrity and low-level origination based on a long term

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

I'm only conjecturing (which is why I kept quiet initially) but since 
our common experience is that people tend to be lazy when it comes to 
security, I would guess that these will be the most commonly used cases.

Why do I think so? Because these cases seem to be the most easy to 
configure and administrate, so that's what the majority is going to use.

Regards,

Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Göran Selander <[email-masked]>
Date: Wed, 6 May 2015 13:04:35 +0000

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" <[email-masked]> wrote:

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

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

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

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

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

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

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

A combination of 7 and 5 is an option to d, but replacing an AEAD with AES
probably be more optimal.

>What percentage of the time do we think these options are going to be

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

>Jim
>_______________________________________________
>Cose mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/cose

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 6 May 2015 21:01:24 -0700

> -----Original Message-----
> From: Göran Selander [mailto:[email-masked]]
> Sent: Wednesday, May 06, 2015 6:05 AM
> To: Jim Schaad; [email-masked]
> 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.
> 
> A. The interaction between potentially constrained endpoints. This includes
> wrapped subsets of CoAP messages, e.g. resource representations.
> 
> constrained endpoint, including wrapped keys/security contexts, credentials
> such as public keys or certificates or other assertions.
> 
> 
> 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))
> 
> We assume in all these constructs that the keys used are pre-established, or
> that new symmetric keys can become established.
> 
> variant allowing distinction between symmetric/asymmetric key here
> denoted "skid"/"akid". The identifers needed differ between the cases:
> 
> (i) and (ii) are key push methods based on known recipient key (sk1 and PK,
> respectively). Method (iii) assumes the inclusion of sender "epk"
> (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)
> >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.
> >
> >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.
> 
> 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.  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.

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

No it does not - not the addition of origination that was missing in the first case.

> >some type of key derivation on the shared security would be suggested.
> >The option only provides for end-to-end integrity between the parties.
> >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.
> 
> 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.

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

> 
> >
> >7.  Confidentiality, integrity and low-level origination based on a
> >short term shared key: This scenario shares most of the same
> >functionality as does
> >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.
> 
> >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.)
> 
> 
> 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.

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

---

From: Göran Selander <[email-masked]>
Date: Thu, 7 May 2015 07:11:47 +0000

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

>>includes
>>credentials
>>PK,
>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.

>No it does not - not the addition of origination that was missing in the

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?

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

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

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

>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

---

From: Derek Atkins <[email-masked]>
Date: Mon, 11 May 2015 11:04:24 -0400

Hi Jim,

Sorry for the late LATE response.  My current use case is purely #5.

I see value in many of the others, but currently I only see myself using
#5 in my current product line.

-derek

"Jim Schaad" <[email-masked]> writes:

> 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
> Under the current system this would be setup using a DTLS session along with
> 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
> Integrity can be forged by any party that knows the shared-secret.  In 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
> Origination of the message cannot be proved to a third party.  Both parties
> term shared key: This scenario shares most of the same functionality as does
> 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

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant