CBOR Object Signing and Encryption (COSE): AES-CTR and AES-CBC
Extracted elements (25)
AES-CTR and AES-CBC algorithm identifiers are registered as 'Deprecated' in the COSE Algorithms registry to prevent accidental use without a companion integrity protection mechanism, signaling that these should only be used in carefully controlled scenarios.
AES-CTR and AES-CBC are specified for COSE because there are situations where a separate mechanism such as a digital signature provides integrity protection, making an AEAD algorithm unnecessary. The IETF SUIT WG software manifest is cited as a primary example where a digital signature is always present.
AES-CBC mode requires a 16-octet (128-bit) IV; use of a randomly or pseudorandomly generated IV ensures that encryption of the same plaintext yields different ciphertext. This IV requirement increases overhead compared to AES-CTR.
AES-CBC requires padding of the plaintext; the padding algorithm specified in Section 6.3 of RFC 5652 MUST be used prior to encrypting the plaintext to allow the decryptor to unambiguously remove padding.
COSE libraries that support AES-CTR or AES-CBC and accept Additional Authenticated Data (AAD) as input MUST return an error if one of these non-AEAD algorithms is selected, to prevent callers from expecting AAD protection that cannot be provided.
Implementations encrypting and decrypting with AES-CTR MUST validate that the key type, key length, and algorithm are correct and appropriate for the entities involved.
Implementations MUST NOT use the same keying material with more than one mode; for example, the same key must not be used with both AES-CTR and AES-CBC, to avoid cross-protocol concerns.
Implementations MUST use AES-CBC in conjunction with an authentication and integrity mechanism, such as a digital signature, because AES-CBC does not provide integrity protection.
Implementations MUST use AES-CTR in conjunction with an authentication and integrity mechanism, such as a digital signature. Without this companion mechanism, it is trivial for an attacker to forge ciphertexts.
Implementations MUST use fresh keys with AES-CTR. Using static keys with AES-CTR is inappropriate because extraordinary measures would be needed to prevent IV reuse across power cycles.
The 'protected' header MUST be a zero-length byte string when using AES-CTR or AES-CBC.
The same IV and AES key combination MUST NOT be used more than once with AES-CTR. The encryptor may generate the IV in any manner that ensures uniqueness per key.
When using AES-CTR or AES-CBC, the decryptor MUST ensure that no external additional authenticated data was supplied, since neither algorithm can provide integrity protection for external AAD.
AES-CBC COSE algorithm identifiers: A128CBC (value -65531, 128-bit key), A192CBC (value -65530, 192-bit key), A256CBC (value -65529, 256-bit key). All three are registered as 'Deprecated' to discourage accidental use without a companion integrity mechanism.
AES-CTR COSE algorithm identifiers: A128CTR (value -65534, 128-bit key), A192CTR (value -65533, 192-bit key), A256CTR (value -65532, 256-bit key). All three are registered as 'Deprecated' to discourage accidental use without a companion integrity mechanism.
For an AES-CBC COSE key: the 'kty' field MUST be 'Symmetric'; if 'alg' is present it MUST match the AES-CBC algorithm; if 'key_ops' is present it MUST include 'encrypt' when encrypting and 'decrypt' when decrypting.
For an AES-CTR COSE key: the 'kty' field MUST be 'Symmetric'; if 'alg' is present it MUST match the AES-CTR algorithm; if 'key_ops' is present it MUST include 'encrypt' when encrypting and 'decrypt' when decrypting.
IANA registered six COSE algorithm identifiers in the 'COSE Algorithms' registry: A128CTR (-65534), A192CTR (-65533), A256CTR (-65532), A128CBC (-65531), A192CBC (-65530), A256CBC (-65529). All entries have 'Capabilities' of '[kty]', 'Change Controller' of 'IETF', and are marked 'Deprecated'.
AES-CTR IV reuse with the same key is catastrophic: if the same key stream is used to encrypt two plaintexts, XORing the ciphertexts cancels the key stream and directly exposes the XOR of the plaintexts, from which separating the plaintexts is straightforward.
An attacker can replace COSE algorithm identifiers with AES-CTR or AES-CBC identifiers in messages that originally used AEAD algorithms (e.g., AES-CCM, AES-GCM), then strip the authentication tag to bypass integrity protection and manipulate ciphertext or extract keying material.
Data forgery is trivial with AES-CTR: an attacker who knows a plaintext block can XOR the corresponding ciphertext block with any desired replacement plaintext, and decryption will yield the attacker's chosen plaintext. This makes a companion authentication mechanism mandatory.
Implementations should provide integrity protection for the 'kid' field to prevent undetected stripping of the authentication and integrity mechanism, which could trick the recipient into using a different key.
Precomputation meet-in-the-middle attacks against block cipher modes reduce the effective strength of AES-CTR and AES-CBC to 2^(n/2) bits where n is the key length. Using long keys (256-bit) is the best countermeasure.
Since AES has a 128-bit block size, ciphertext becomes distinguishable from random values after 2^64 blocks are encrypted with a single key. Implementations should change the key before reaching this limit.
With AES-CBC, implementers should perform integrity checks prior to decryption to avoid padding oracle vulnerabilities (Vaudenay). An attacker able to strip the authentication mechanism can replace it with their own, and may guess plaintext 16 bytes at a time by switching algorithm identifiers and observing padding acceptance.