Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8152

CBOR Object Signing and Encryption (COSE)

Pages: 121
Obsoleted by:  90529053
Part 3 of 6 – Pages 33 to 51
First   Prev   Next

Top   ToC   RFC8152 - Page 33   prevText

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