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

From: "Jim Schaad" <[email-masked]>
Date: Thu, 30 Apr 2015 15:57:17 -0700

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.

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.

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.

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.  

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.

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.

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.

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.

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.

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

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.

Jim