tech-invite   World Map
3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search     Home

RFC 8152

 
 
 

CBOR Object Signing and Encryption (COSE)

Part 3 of 6, p. 33 to 51
Prev Section       Next Section

 


prevText      Top      ToC       Page 33 
7.  Key Objects

   A COSE Key structure is built on a CBOR map object.  The set of
   common parameters that can appear in a COSE Key can be found in the
   IANA "COSE Key Common Parameters" registry (Section 16.5).
   Additional parameters defined for specific key types can be found in
   the IANA "COSE Key Type Parameters" registry (Section 16.6).

   A COSE Key Set uses a CBOR array object as its underlying type.  The
   values of the array elements are COSE Keys.  A COSE Key Set MUST have
   at least one element in the array.  Examples of COSE Key Sets can be
   found in Appendix C.7.

   Each element in a COSE Key Set MUST be processed independently.  If
   one element in a COSE Key Set is either malformed or uses a key that
   is not understood by an application, that key is ignored and the
   other keys are processed normally.

   The element "kty" is a required element in a COSE_Key map.

Top      Up      ToC       Page 34 
   The CDDL grammar describing COSE_Key and COSE_KeySet is:

   COSE_Key = {
       1 => tstr / int,          ; kty
       ? 2 => bstr,              ; kid
       ? 3 => tstr / int,        ; alg
       ? 4 => [+ (tstr / int) ], ; key_ops
       ? 5 => bstr,              ; Base IV
       * label => values
   }

   COSE_KeySet = [+COSE_Key]

7.1.  COSE Key Common Parameters

   This document defines a set of common parameters for a COSE Key
   object.  Table 3 provides a summary of the parameters defined in this
   section.  There are also parameters that are defined for specific key
   types.  Key-type-specific parameters can be found in Section 13.

Top      Up      ToC       Page 35 
   +---------+-------+----------------+------------+-------------------+
   | Name    | Label | CBOR Type      | Value      | Description       |
   |         |       |                | Registry   |                   |
   +---------+-------+----------------+------------+-------------------+
   | kty     | 1     | tstr / int     | COSE Key   | Identification of |
   |         |       |                | Common     | the key type      |
   |         |       |                | Parameters |                   |
   |         |       |                |            |                   |
   | kid     | 2     | bstr           |            | Key               |
   |         |       |                |            | identification    |
   |         |       |                |            | value -- match to |
   |         |       |                |            | kid in message    |
   |         |       |                |            |                   |
   | alg     | 3     | tstr / int     | COSE       | Key usage         |
   |         |       |                | Algorithms | restriction to    |
   |         |       |                |            | this algorithm    |
   |         |       |                |            |                   |
   | key_ops | 4     | [+ (tstr/int)] |            | Restrict set of   |
   |         |       |                |            | permissible       |
   |         |       |                |            | operations        |
   |         |       |                |            |                   |
   | Base IV | 5     | bstr           |            | Base IV to be     |
   |         |       |                |            | xor-ed with       |
   |         |       |                |            | Partial IVs       |
   +---------+-------+----------------+------------+-------------------+

                          Table 3: Key Map Labels

   kty:  This parameter is used to identify the family of keys for this
      structure and, thus, the set of key-type-specific parameters to be
      found.  The set of values defined in this document can be found in
      Table 21.  This parameter MUST be present in a key object.
      Implementations MUST verify that the key type is appropriate for
      the algorithm being processed.  The key type MUST be included as
      part of the trust decision process.

   alg:  This parameter is used to restrict the algorithm that is used
      with the key.  If this parameter is present in the key structure,
      the application MUST verify that this algorithm matches the
      algorithm for which the key is being used.  If the algorithms do
      not match, then this key object MUST NOT be used to perform the
      cryptographic operation.  Note that the same key can be in a
      different key structure with a different or no algorithm
      specified; however, this is considered to be a poor security
      practice.

Top      Up      ToC       Page 36 
   kid:  This parameter is used to give an identifier for a key.  The
      identifier is not structured and can be anything from a user-
      provided string to a value computed on the public portion of the
      key.  This field is intended for matching against a 'kid'
      parameter in a message in order to filter down the set of keys
      that need to be checked.

   key_ops:  This parameter is defined to restrict the set of operations
      that a key is to be used for.  The value of the field is an array
      of values from Table 4.  Algorithms define the values of key ops
      that are permitted to appear and are required for specific
      operations.  The set of values matches that in [RFC7517] and
      [W3C.WebCrypto].

   Base IV:  This parameter is defined to carry the base portion of an
      IV.  It is designed to be used with the Partial IV header
      parameter defined in Section 3.1.  This field provides the ability
      to associate a Partial IV with a key that is then modified on a
      per message basis with the Partial IV.

      Extreme care needs to be taken when using a Base IV in an
      application.  Many encryption algorithms lose security if the same
      IV is used twice.

      If different keys are derived for each sender, using the same Base
      IV with Partial IVs starting at zero is likely to ensure that the
      IV would not be used twice for a single key.  If different keys
      are derived for each sender, starting at the same Base IV is
      likely to satisfy this condition.  If the same key is used for
      multiple senders, then the application needs to provide for a
      method of dividing the IV space up between the senders.  This
      could be done by providing a different base point to start from or
      a different Partial IV to start with and restricting the number of
      messages to be sent before rekeying.

Top      Up      ToC       Page 37 
   +---------+-------+-------------------------------------------------+
   | Name    | Value | Description                                     |
   +---------+-------+-------------------------------------------------+
   | sign    | 1     | The key is used to create signatures.  Requires |
   |         |       | private key fields.                             |
   | verify  | 2     | The key is used for verification of signatures. |
   | encrypt | 3     | The key is used for key transport encryption.   |
   | decrypt | 4     | The key is used for key transport decryption.   |
   |         |       | Requires private key fields.                    |
   | wrap    | 5     | The key is used for key wrap encryption.        |
   | key     |       |                                                 |
   | unwrap  | 6     | The key is used for key wrap decryption.        |
   | key     |       | Requires private key fields.                    |
   | derive  | 7     | The key is used for deriving keys.  Requires    |
   | key     |       | private key fields.                             |
   | derive  | 8     | The key is used for deriving bits not to be     |
   | bits    |       | used as a key.  Requires private key fields.    |
   | MAC     | 9     | The key is used for creating MACs.              |
   | create  |       |                                                 |
   | MAC     | 10    | The key is used for validating MACs.            |
   | verify  |       |                                                 |
   +---------+-------+-------------------------------------------------+

                       Table 4: Key Operation Values

8.  Signature Algorithms

   There are two signature algorithm schemes.  The first is signature
   with appendix.  In this scheme, the message content is processed and
   a signature is produced; the signature is called the appendix.  This
   is the scheme used by algorithms such as ECDSA and the RSA
   Probabilistic Signature Scheme (RSASSA-PSS).  (In fact, the SSA in
   RSASSA-PSS stands for Signature Scheme with Appendix.)

   The signature functions for this scheme are:

      signature = Sign(message content, key)

      valid = Verification(message content, key, signature)

   The second scheme is signature with message recovery (an example of
   such an algorithm is [PVSig]).  In this scheme, the message content
   is processed, but part of it is included in the signature.  Moving
   bytes of the message content into the signature allows for smaller
   signatures; the signature size is still potentially large, but the
   message content has shrunk.  This has implications for systems
   implementing these algorithms and for applications that use them.
   The first is that the message content is not fully available until

Top      Up      ToC       Page 38 
   after a signature has been validated.  Until that point, the part of
   the message contained inside of the signature is unrecoverable.  The
   second is that the security analysis of the strength of the signature
   is very much based on the structure of the message content.  Messages
   that are highly predictable require additional randomness to be
   supplied as part of the signature process.  In the worst case, it
   becomes the same as doing a signature with appendix.  Finally, in the
   event that multiple signatures are applied to a message, all of the
   signature algorithms are going to be required to consume the same
   number of bytes of message content.  This means that the mixing of
   the different schemes in a single message is not supported, and if a
   recovery signature scheme is used, then the same amount of content
   needs to be consumed by all of the signatures.

   The signature functions for this scheme are:

    signature, message sent = Sign(message content, key)

    valid, message content = Verification(message sent, key, signature)

   Signature algorithms are used with the COSE_Signature and COSE_Sign1
   structures.  At this time, only signatures with appendixes are
   defined for use with COSE; however, considerable interest has been
   expressed in using a signature with message recovery algorithm due to
   the effective size reduction that is possible.  Implementations will
   need to keep this in mind for later possible integration.

8.1.  ECDSA

   ECDSA [DSS] defines a signature algorithm using ECC.  Implementations
   SHOULD use a deterministic version of ECDSA such as the one defined
   in [RFC6979].  The use of a deterministic signature algorithm allows
   for systems to avoid relying on random number generators in order to
   avoid generating the same value of 'k' (the per-message random
   value).  Biased generation of the value 'k' can be attacked, and
   collisions of this value leads to leaked keys.  It additionally
   allows for doing deterministic tests for the signature algorithm.
   The use of deterministic ECDSA does not lessen the need to have good
   random number generation when creating the private key.

   The ECDSA signature algorithm is parameterized with a hash function
   (h).  In the event that the length of the hash function output is
   greater than the group of the key, the leftmost bytes of the hash
   output are used.

Top      Up      ToC       Page 39 
   The algorithms defined in this document can be found in Table 5.

              +-------+-------+---------+------------------+
              | Name  | Value | Hash    | Description      |
              +-------+-------+---------+------------------+
              | ES256 | -7    | SHA-256 | ECDSA w/ SHA-256 |
              | ES384 | -35   | SHA-384 | ECDSA w/ SHA-384 |
              | ES512 | -36   | SHA-512 | ECDSA w/ SHA-512 |
              +-------+-------+---------+------------------+

                      Table 5: ECDSA Algorithm Values

   This document defines ECDSA to work only with the curves P-256,
   P-384, and P-521.  This document requires that the curves be encoded
   using the 'EC2' (2 coordinate elliptic curve) key type.
   Implementations need to check that the key type and curve are correct
   when creating and verifying a signature.  Other documents can define
   it to work with other curves and points in the future.

   In order to promote interoperability, it is suggested that SHA-256 be
   used only with curve P-256, SHA-384 be used only with curve P-384,
   and SHA-512 be used with curve P-521.  This is aligned with the
   recommendation in Section 4 of [RFC5480].

   The signature algorithm results in a pair of integers (R, S).  These
   integers will be the same length as the length of the key used for
   the signature process.  The signature is encoded by converting the
   integers into byte strings of the same length as the key size.  The
   length is rounded up to the nearest byte and is left padded with zero
   bits to get to the correct length.  The two integers are then
   concatenated together to form a byte string that is the resulting
   signature.

   Using the function defined in [RFC8017], the signature is:
   Signature = I2OSP(R, n) | I2OSP(S, n)
   where n = ceiling(key_length / 8)

   When using a COSE key for this algorithm, the following checks are
   made:

   o  The 'kty' field MUST be present, and it MUST be 'EC2'.

   o  If the 'alg' field is present, it MUST match the ECDSA signature
      algorithm being used.

   o  If the 'key_ops' field is present, it MUST include 'sign' when
      creating an ECDSA signature.

Top      Up      ToC       Page 40 
   o  If the 'key_ops' field is present, it MUST include 'verify' when
      verifying an ECDSA signature.

8.1.1.  Security Considerations

   The security strength of the signature is no greater than the minimum
   of the security strength associated with the bit length of the key
   and the security strength of the hash function.

   Note: Use of this technique is a good idea even when good random
   number generation exists.  Doing so both reduces the possibility of
   having the same value of 'k' in two signature operations and allows
   for reproducible signature values, which helps testing.

   There are two substitution attacks that can theoretically be mounted
   against the ECDSA signature algorithm.

   o  Changing the curve used to validate the signature: If one changes
      the curve used to validate the signature, then potentially one
      could have two messages with the same signature, each computed
      under a different curve.  The only requirement on the new curve is
      that its order be the same as the old one and it be acceptable to
      the client.  An example would be to change from using the curve
      secp256r1 (aka P-256) to using secp256k1.  (Both are 256-bit
      curves.)  We currently do not have any way to deal with this
      version of the attack except to restrict the overall set of curves
      that can be used.

   o  Change the hash function used to validate the signature: If one
      either has two different hash functions of the same length or can
      truncate a hash function down, then one could potentially find
      collisions between the hash functions rather than within a single
      hash function (for example, truncating SHA-512 to 256 bits might
      collide with a SHA-256 bit hash value).  As the hash algorithm is
      part of the signature algorithm identifier, this attack is
      mitigated by including a signature algorithm identifier in the
      protected header.

8.2.  Edwards-Curve Digital Signature Algorithms (EdDSAs)

   [RFC8032] describes the elliptic curve signature scheme Edwards-curve
   Digital Signature Algorithm (EdDSA).  In that document, the signature
   algorithm is instantiated using parameters for edwards25519 and
   edwards448 curves.  The document additionally describes two variants
   of the EdDSA algorithm: Pure EdDSA, where no hash function is applied
   to the content before signing, and HashEdDSA, where a hash function
   is applied to the content before signing and the result of that hash
   function is signed.  For EdDSA, the content to be signed (either the

Top      Up      ToC       Page 41 
   message or the pre-hash value) is processed twice inside of the
   signature algorithm.  For use with COSE, only the pure EdDSA version
   is used.  This is because it is not expected that extremely large
   contents are going to be needed and, based on the arrangement of the
   message structure, the entire message is going to need to be held in
   memory in order to create or verify a signature.  This means that
   there does not appear to be a need to be able to do block updates of
   the hash, followed by eliminating the message from memory.
   Applications can provide the same features by defining the content of
   the message as a hash value and transporting the COSE object (with
   the hash value) and the content as separate items.

   The algorithms defined in this document can be found in Table 6.  A
   single signature algorithm is defined, which can be used for multiple
   curves.

                      +-------+-------+-------------+
                      | Name  | Value | Description |
                      +-------+-------+-------------+
                      | EdDSA | -8    | EdDSA       |
                      +-------+-------+-------------+

                      Table 6: EdDSA Algorithm Values

   [RFC8032] describes the method of encoding the signature value.

   When using a COSE key for this algorithm, the following checks are
   made:

   o  The 'kty' field MUST be present, and it MUST be 'OKP' (Octet Key
      Pair).

   o  The 'crv' field MUST be present, and it MUST be a curve defined
      for this signature algorithm.

   o  If the 'alg' field is present, it MUST match 'EdDSA'.

   o  If the 'key_ops' field is present, it MUST include 'sign' when
      creating an EdDSA signature.

   o  If the 'key_ops' field is present, it MUST include 'verify' when
      verifying an EdDSA signature.

8.2.1.  Security Considerations

   How public values are computed is not the same when looking at EdDSA
   and Elliptic Curve Diffie-Hellman (ECDH); for this reason, they
   should not be used with the other algorithm.

Top      Up      ToC       Page 42 
   If batch signature verification is performed, a well-seeded
   cryptographic random number generator is REQUIRED.  Signing and non-
   batch signature verification are deterministic operations and do not
   need random numbers of any kind.

9.  Message Authentication Code (MAC) Algorithms

   Message Authentication Codes (MACs) provide data authentication and
   integrity protection.  They provide either no or very limited data
   origination.  A MAC, for example, can be used to prove the identity
   of the sender to a third party.

   MACs use the same scheme as signature with appendix algorithms.  The
   message content is processed and an authentication code is produced.
   The authentication code is frequently called a tag.

   The MAC functions are:

   tag = MAC_Create(message content, key)

   valid = MAC_Verify(message content, key, tag)

   MAC algorithms can be based on either a block cipher algorithm (i.e.,
   AES-MAC) or a hash algorithm (i.e., a Hash-based Message
   Authentication Code (HMAC)).  This document defines a MAC algorithm
   using each of these constructions.

   MAC algorithms are used in the COSE_Mac and COSE_Mac0 structures.

9.1.  Hash-Based Message Authentication Codes (HMACs)

   HMAC [RFC2104] [RFC4231] was designed to deal with length extension
   attacks.  The algorithm was also designed to allow for new hash
   algorithms to be directly plugged in without changes to the hash
   function.  The HMAC design process has been shown as solid since,
   while the security of hash algorithms such as MD5 has decreased over
   time; the security of HMAC combined with MD5 has not yet been shown
   to be compromised [RFC6151].

   The HMAC algorithm is parameterized by an inner and outer padding, a
   hash function (h), and an authentication tag value length.  For this
   specification, the inner and outer padding are fixed to the values
   set in [RFC2104].  The length of the authentication tag corresponds
   to the difficulty of producing a forgery.  For use in constrained
   environments, we define a set of HMAC algorithms that are truncated.

Top      Up      ToC       Page 43 
   There are currently no known issues with truncation; however, the
   security strength of the message tag is correspondingly reduced in
   strength.  When truncating, the leftmost tag length bits are kept and
   transmitted.

   The algorithms defined in this document can be found in Table 7.

   +-----------+-------+---------+----------+--------------------------+
   | Name      | Value | Hash    | Tag      | Description              |
   |           |       |         | Length   |                          |
   +-----------+-------+---------+----------+--------------------------+
   | HMAC      | 4     | SHA-256 | 64       | HMAC w/ SHA-256          |
   | 256/64    |       |         |          | truncated to 64 bits     |
   | HMAC      | 5     | SHA-256 | 256      | HMAC w/ SHA-256          |
   | 256/256   |       |         |          |                          |
   | HMAC      | 6     | SHA-384 | 384      | HMAC w/ SHA-384          |
   | 384/384   |       |         |          |                          |
   | HMAC      | 7     | SHA-512 | 512      | HMAC w/ SHA-512          |
   | 512/512   |       |         |          |                          |
   +-----------+-------+---------+----------+--------------------------+

                      Table 7: HMAC Algorithm Values

   Some recipient algorithms carry the key while others derive a key
   from secret data.  For those algorithms that carry the key (such as
   AES Key Wrap), the size of the HMAC key SHOULD be the same size as
   the underlying hash function.  For those algorithms that derive the
   key (such as ECDH), the derived key MUST be the same size as the
   underlying hash function.

   When using a COSE key for this algorithm, the following checks are
   made:

   o  The 'kty' field MUST be present, and it MUST be 'Symmetric'.

   o  If the 'alg' field is present, it MUST match the HMAC algorithm
      being used.

   o  If the 'key_ops' field is present, it MUST include 'MAC create'
      when creating an HMAC authentication tag.

   o  If the 'key_ops' field is present, it MUST include 'MAC verify'
      when verifying an HMAC authentication tag.

   Implementations creating and validating MAC values MUST validate that
   the key type, key length, and algorithm are correct and appropriate
   for the entities involved.

Top      Up      ToC       Page 44 
9.1.1.  Security Considerations

   HMAC has proved to be resistant to attack even when used with
   weakened hash algorithms.  The current best known attack is to brute
   force the key.  This means that key size is going to be directly
   related to the security of an HMAC operation.

9.2.  AES Message Authentication Code (AES-CBC-MAC)

   AES-CBC-MAC is defined in [MAC].  (Note that this is not the same
   algorithm as AES Cipher-Based Message Authentication Code (AES-CMAC)
   [RFC4493].)

   AES-CBC-MAC is parameterized by the key length, the authentication
   tag length, and the IV used.  For all of these algorithms, the IV is
   fixed to all zeros.  We provide an array of algorithms for various
   key lengths and tag lengths.  The algorithms defined in this document
   are found in Table 8.

   +-------------+-------+----------+----------+-----------------------+
   | Name        | Value | Key      | Tag      | Description           |
   |             |       | Length   | Length   |                       |
   +-------------+-------+----------+----------+-----------------------+
   | AES-MAC     | 14    | 128      | 64       | AES-MAC 128-bit key,  |
   | 128/64      |       |          |          | 64-bit tag            |
   | AES-MAC     | 15    | 256      | 64       | AES-MAC 256-bit key,  |
   | 256/64      |       |          |          | 64-bit tag            |
   | AES-MAC     | 25    | 128      | 128      | AES-MAC 128-bit key,  |
   | 128/128     |       |          |          | 128-bit tag           |
   | AES-MAC     | 26    | 256      | 128      | AES-MAC 256-bit key,  |
   | 256/128     |       |          |          | 128-bit tag           |
   +-------------+-------+----------+----------+-----------------------+

                     Table 8: AES-MAC Algorithm Values

   Keys may be obtained either from a key structure or from a recipient
   structure.  Implementations creating and validating MAC values MUST
   validate that the key type, key length, and algorithm are correct and
   appropriate for the entities involved.

   When using a COSE key for this algorithm, the following checks are
   made:

   o  The 'kty' field MUST be present, and it MUST be 'Symmetric'.

   o  If the 'alg' field is present, it MUST match the AES-MAC algorithm
      being used.

Top      Up      ToC       Page 45 
   o  If the 'key_ops' field is present, it MUST include 'MAC create'
      when creating an AES-MAC authentication tag.

   o  If the 'key_ops' field is present, it MUST include 'MAC verify'
      when verifying an AES-MAC authentication tag.

9.2.1.  Security Considerations

   A number of attacks exist against Cipher Block Chaining Message
   Authentication Code (CBC-MAC) that need to be considered.

   o  A single key must only be used for messages of a fixed and known
      length.  If this is not the case, an attacker will be able to
      generate a message with a valid tag given two message and tag
      pairs.  This can be addressed by using different keys for messages
      of different lengths.  The current structure mitigates this
      problem, as a specific encoding structure that includes lengths is
      built and signed.  (CMAC also addresses this issue.)

   o  Cipher Block Chaining (CBC) mode, if the same key is used for both
      encryption and authentication operations, an attacker can produce
      messages with a valid authentication code.

   o  If the IV can be modified, then messages can be forged.  This is
      addressed by fixing the IV to all zeros.

10.  Content Encryption Algorithms

   Content encryption algorithms provide data confidentiality for
   potentially large blocks of data using a symmetric key.  They provide
   integrity on the data that was encrypted; however, they provide
   either no or very limited data origination.  (One cannot, for
   example, be used to prove the identity of the sender to a third
   party.)  The ability to provide data origination is linked to how the
   CEK is obtained.

   COSE restricts the set of legal content encryption algorithms to
   those that support authentication both of the content and additional
   data.  The encryption process will generate some type of
   authentication value, but that value may be either explicit or
   implicit in terms of the algorithm definition.  For simplicity's
   sake, the authentication code will normally be defined as being
   appended to the ciphertext stream.  The encryption functions are:

   ciphertext = Encrypt(message content, key, additional data)

   valid, message content = Decrypt(cipher text, key, additional data)

Top      Up      ToC       Page 46 
   Most AEAD algorithms are logically defined as returning the message
   content only if the decryption is valid.  Many but not all

   implementations will follow this convention.  The message content
   MUST NOT be used if the decryption does not validate.

   These algorithms are used in COSE_Encrypt and COSE_Encrypt0.

10.1.  AES GCM

   The Galois/Counter Mode (GCM) mode is a generic authenticated
   encryption block cipher mode defined in [AES-GCM].  The GCM mode is
   combined with the AES block encryption algorithm to define an AEAD
   cipher.

   The GCM mode is parameterized by the size of the authentication tag
   and the size of the nonce.  This document fixes the size of the nonce
   at 96 bits.  The size of the authentication tag is limited to a small
   set of values.  For this document however, the size of the
   authentication tag is fixed at 128 bits.

   The set of algorithms defined in this document are in Table 9.

      +---------+-------+------------------------------------------+
      | Name    | Value | Description                              |
      +---------+-------+------------------------------------------+
      | A128GCM | 1     | AES-GCM mode w/ 128-bit key, 128-bit tag |
      | A192GCM | 2     | AES-GCM mode w/ 192-bit key, 128-bit tag |
      | A256GCM | 3     | AES-GCM mode w/ 256-bit key, 128-bit tag |
      +---------+-------+------------------------------------------+

                   Table 9: Algorithm Value for AES-GCM

   Keys may be obtained either from a key structure or from a recipient
   structure.  Implementations encrypting and decrypting MUST validate
   that the key type, key length, and algorithm are correct and
   appropriate for the entities involved.

   When using a COSE key for this algorithm, the following checks are
   made:

   o  The 'kty' field MUST be present, and it MUST be 'Symmetric'.

   o  If the 'alg' field is present, it MUST match the AES-GCM algorithm
      being used.

   o  If the 'key_ops' field is present, it MUST include 'encrypt' or
      'wrap key' when encrypting.

Top      Up      ToC       Page 47 
   o  If the 'key_ops' field is present, it MUST include 'decrypt' or
      'unwrap key' when decrypting.

10.1.1.  Security Considerations

   When using AES-GCM, the following restrictions MUST be enforced:

   o  The key and nonce pair MUST be unique for every message encrypted.

   o  The total amount of data encrypted for a single key MUST NOT
      exceed 2^39 - 256 bits.  An explicit check is required only in
      environments where it is expected that it might be exceeded.

   Consideration was given to supporting smaller tag values; the
   constrained community would desire tag sizes in the 64-bit range.
   Doing so drastically changes both the maximum messages size
   (generally not an issue) and the number of times that a key can be
   used.  Given that Counter with CBC-MAC (CCM) is the usual mode for
   constrained environments, restricted modes are not supported.

10.2.  AES CCM

   CCM is a generic authentication encryption block cipher mode defined
   in [RFC3610].  The CCM mode is combined with the AES block encryption
   algorithm to define a commonly used content encryption algorithm used
   in constrained devices.

   The CCM mode has two parameter choices.  The first choice is M, the
   size of the authentication field.  The choice of the value for M
   involves a trade-off between message growth (from the tag) and the
   probability that an attacker can undetectably modify a message.  The
   second choice is L, the size of the length field.  This value
   requires a trade-off between the maximum message size and the size of
   the Nonce.

   It is unfortunate that the specification for CCM specified L and M as
   a count of bytes rather than a count of bits.  This leads to possible
   misunderstandings where AES-CCM-8 is frequently used to refer to a
   version of CCM mode where the size of the authentication is 64 bits
   and not 8 bits.  These values have traditionally been specified as
   bit counts rather than byte counts.  This document will follow the
   convention of using bit counts so that it is easier to compare the
   different algorithms presented in this document.

   We define a matrix of algorithms in this document over the values of
   L and M.  Constrained devices are usually operating in situations
   where they use short messages and want to avoid doing recipient-
   specific cryptographic operations.  This favors smaller values of

Top      Up      ToC       Page 48 
   both L and M.  Less-constrained devices will want to be able to use
   larger messages and are more willing to generate new keys for every
   operation.  This favors larger values of L and M.

   The following values are used for L:

   16 bits (2):  This limits messages to 2^16 bytes (64 KiB) in length.
      This is sufficiently long for messages in the constrained world.
      The nonce length is 13 bytes allowing for 2^(13*8) possible values
      of the nonce without repeating.

   64 bits (8):  This limits messages to 2^64 bytes in length.  The
      nonce length is 7 bytes allowing for 2^56 possible values of the
      nonce without repeating.

   The following values are used for M:

   64 bits (8):  This produces a 64-bit authentication tag.  This
      implies that there is a 1 in 2^64 chance that a modified message
      will authenticate.

   128 bits (16):  This produces a 128-bit authentication tag.  This
      implies that there is a 1 in 2^128 chance that a modified message
      will authenticate.

Top      Up      ToC       Page 49 
   +--------------------+-------+----+-----+-----+---------------------+
   | Name               | Value | L  | M   | k   | Description         |
   +--------------------+-------+----+-----+-----+---------------------+
   | AES-CCM-16-64-128  | 10    | 16 | 64  | 128 | AES-CCM mode        |
   |                    |       |    |     |     | 128-bit key, 64-bit |
   |                    |       |    |     |     | tag, 13-byte nonce  |
   | AES-CCM-16-64-256  | 11    | 16 | 64  | 256 | AES-CCM mode        |
   |                    |       |    |     |     | 256-bit key, 64-bit |
   |                    |       |    |     |     | tag, 13-byte nonce  |
   | AES-CCM-64-64-128  | 12    | 64 | 64  | 128 | AES-CCM mode        |
   |                    |       |    |     |     | 128-bit key, 64-bit |
   |                    |       |    |     |     | tag, 7-byte nonce   |
   | AES-CCM-64-64-256  | 13    | 64 | 64  | 256 | AES-CCM mode        |
   |                    |       |    |     |     | 256-bit key, 64-bit |
   |                    |       |    |     |     | tag, 7-byte nonce   |
   | AES-CCM-16-128-128 | 30    | 16 | 128 | 128 | AES-CCM mode        |
   |                    |       |    |     |     | 128-bit key,        |
   |                    |       |    |     |     | 128-bit tag,        |
   |                    |       |    |     |     | 13-byte nonce       |
   | AES-CCM-16-128-256 | 31    | 16 | 128 | 256 | AES-CCM mode        |
   |                    |       |    |     |     | 256-bit key,        |
   |                    |       |    |     |     | 128-bit tag,        |
   |                    |       |    |     |     | 13-byte nonce       |
   | AES-CCM-64-128-128 | 32    | 64 | 128 | 128 | AES-CCM mode        |
   |                    |       |    |     |     | 128-bit key,        |
   |                    |       |    |     |     | 128-bit tag, 7-byte |
   |                    |       |    |     |     | nonce               |
   | AES-CCM-64-128-256 | 33    | 64 | 128 | 256 | AES-CCM mode        |
   |                    |       |    |     |     | 256-bit key,        |
   |                    |       |    |     |     | 128-bit tag, 7-byte |
   |                    |       |    |     |     | nonce               |
   +--------------------+-------+----+-----+-----+---------------------+

                  Table 10: Algorithm Values for AES-CCM

   Keys may be obtained either from a key structure or from a recipient
   structure.  Implementations encrypting and decrypting MUST validate
   that the key type, key length, and algorithm are correct and
   appropriate for the entities involved.

   When using a COSE key for this algorithm, the following checks are
   made:

   o  The 'kty' field MUST be present, and it MUST be 'Symmetric'.

   o  If the 'alg' field is present, it MUST match the AES-CCM algorithm
      being used.

Top      Up      ToC       Page 50 
   o  If the 'key_ops' field is present, it MUST include 'encrypt' or
      'wrap key' when encrypting.

   o  If the 'key_ops' field is present, it MUST include 'decrypt' or
      'unwrap key' when decrypting.

10.2.1.  Security Considerations

   When using AES-CCM, the following restrictions MUST be enforced:

   o  The key and nonce pair MUST be unique for every message encrypted.
      Note that the value of L influences the number of unique nonces.

   o  The total number of times the AES block cipher is used MUST NOT
      exceed 2^61 operations.  This limitation is the sum of times the
      block cipher is used in computing the MAC value and in performing
      stream encryption operations.  An explicit check is required only
      in environments where it is expected that it might be exceeded.

   [RFC3610] additionally calls out one other consideration of note.  It
   is possible to do a pre-computation attack against the algorithm in
   cases where portions of the plaintext are highly predictable.  This
   reduces the security of the key size by half.  Ways to deal with this
   attack include adding a random portion to the nonce value and/or
   increasing the key size used.  Using a portion of the nonce for a
   random value will decrease the number of messages that a single key
   can be used for.  Increasing the key size may require more resources
   in the constrained device.  See Sections 5 and 10 of [RFC3610] for
   more information.

10.3.  ChaCha20 and Poly1305

   ChaCha20 and Poly1305 combined together is an AEAD mode that is
   defined in [RFC7539].  This is an algorithm defined to be a cipher
   that is not AES and thus would not suffer from any future weaknesses
   found in AES.  These cryptographic functions are designed to be fast
   in software-only implementations.

   The ChaCha20/Poly1305 AEAD construction defined in [RFC7539] has no
   parameterization.  It takes a 256-bit key and a 96-bit nonce, as well
   as the plaintext and additional data as inputs and produces the
   ciphertext as an option.  We define one algorithm identifier for this
   algorithm in Table 11.

Top      Up      ToC       Page 51 
   +-------------------+-------+---------------------------------------+
   | Name              | Value | Description                           |
   +-------------------+-------+---------------------------------------+
   | ChaCha20/Poly1305 | 24    | ChaCha20/Poly1305 w/ 256-bit key,     |
   |                   |       | 128-bit tag                           |
   +-------------------+-------+---------------------------------------+

                   Table 11: Algorithm Value for AES-GCM

   Keys may be obtained either from a key structure or from a recipient
   structure.  Implementations encrypting and decrypting MUST validate
   that the key type, key length, and algorithm are correct and
   appropriate for the entities involved.

   When using a COSE key for this algorithm, the following checks are
   made:

   o  The 'kty' field MUST be present, and it MUST be 'Symmetric'.

   o  If the 'alg' field is present, it MUST match the ChaCha20/Poly1305
      algorithm being used.

   o  If the 'key_ops' field is present, it MUST include 'encrypt' or
      'wrap key' when encrypting.

   o  If the 'key_ops' field is present, it MUST include 'decrypt' or
      'unwrap key' when decrypting.

10.3.1.  Security Considerations

   The key and nonce values MUST be a unique pair for every invocation
   of the algorithm.  Nonce counters are considered to be an acceptable
   way of ensuring that they are unique.



(page 51 continued on part 4)

Next Section