RFC 8152
CBOR Object Signing and Encryption (COSE)
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.
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.
+---------+-------+----------------+------------+-------------------+ | 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.
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.
+---------+-------+-------------------------------------------------+ | 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 Values8. 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
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.
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.
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
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.
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.
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.
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.
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)
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.
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
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.
+--------------------+-------+----+-----+-----+---------------------+ | 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.
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.
+-------------------+-------+---------------------------------------+ | 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)
