Re: [COSE] COSE Support for AES-CTR and AES-CBC

[Hannes Tschofenig <[e-mail]>]

Hi Sophie,

Thanks for your comments.

The functionality of ciphers without integrity protection was introduced not to save bytes over the wire but to support a firmware update use case.
It seems that this intention is not well articulated in the draft and hence we will have to add more text.

https://datatracker.ietf.org/doc/html/draft-ietf-suit-firmware-encryption-09 provides a more detailed description of the firmware update scenario, see particularly Section 8.

Hence, we are by no means suggesting that AES-CTR and AES-CBC should be used for generic usage. We highlight this be registering the algorithms as “deprecated” thereby avoiding accidental usage by developers who just browse through the IANA COSE algorithm registry. In the draft itself we also mention several times that the two algorithms do not offer integrity protection and that an additional mechanism must be used to provide this integrity protection.
Ciao
Hannes

From: COSE <[e-mail]> On Behalf Of Sophie Schmieg
Sent: Thursday, October 27, 2022 8:13 PM
To: Arciszewski, Scott <scottarc=[e-mail]>
Cc: Zundel, Brent <brent.zundel=[e-mail]>; [e-mail]
Subject: Re: [COSE] COSE Support for AES-CTR and AES-CBC

Hi all,

I'm Sophie from Google's ISE Crypto team and wanted to add a few comments to this proposal.
I have to agree with Scott's other objection, adding unauthenticated encryption modes will open COSE to several attacks.

Attack 1: Signature Stripping
Since the kid of the authentication layer and the encryption layer would no longer be correlated, the attacker can replace the outer signature/mac layer with their own valid signature/tag without knowing the plaintext that they are signing. The usual defense against this attack is to use an IND-CCA2 cipher and include the sender identity in the plaintext. However, CTR and CBC mode are not IND-CCA2 and would therefore not be able to implement this mitigation. This means that there has to be an implementation enforced mapping from outer kid to inner kid to mitigate this attack.

COSE, similar to JOSE, defines the algorithm in the ciphertext instead of the key. In JOSE, this design weakness results in several common vulnerabilities (alg=none, HMAC to ECDSA attacks). In COSE, this weakness is currently mitigated due to the limited selection of algorithms and the strict separation of digital signatures and MACs. However, adding new algorithms to COSE can affect the security of existing algorithms, as implementations might trust the ciphertext's algorithm information and not have algorithm information on the key. You can find more information about this family of attacks in my RWC talk [1]. This leads to the following family of attacks, which can be combined with Attack 1.

Attack 2: GCM to CTR authentication key compromise attack
AES-GCM is a combination of AES-CTR and GHASH, with the tag being the CTR encrypted output of the GHASH of the rest of the ciphertext. Knowledge of the unencrypted GHASH output allows the attacker to calculate the authentication key used by AES-GCM, allowing for forgeries. In a situation where the attacker has access to a (partial) decryption oracle, they can manipulate the ciphertext, switching from AES-GCM to AES-CTR and extracting the unencrypted GHASH output and with it the GCM authentication key.

Attack 3: GCM to CTR malleability attacks
AES-GCM using AES-CTR for its encryption leads to another attack, allowing the attacker to switch the algorithm from GCM to CTR, and stripping the tag of the ciphertext. This bypasses the authenticity check of GCM, allowing the attacker to manipulate the ciphertext (and with that the plaintext). This attack can even be used to turn a mere decryption failure oracle into a decryption oracle, by crafting messages that trigger decryption failures if a plaintext guess is incorrect, leading to another way to exploit Attack 2.

Attack 4: GCM to CBC plaintext recovery attacks
Changing the algorithm field from AES-GCM to AES-CBC can lead to another type of attack, where guesses of 16 bytes of plaintext at a time can be verified via a CBC padding oracle. The details are summarized (including a proof of concept) in the description of CVE-2020-8911 [2].

In general, COSE is already a fairly overly verbose standard (e.g. including the algorithm identifier in the ciphertext), so it seems to me that saving the 16 bytes of overhead of the GCM tag is not worth the risk of opening implementations up to these attacks which we know from JOSE implementations are extremely frequent mistakes.

Re: Cryptographic review of standards using CBC and CTR mode: Even though the modes are well understood, the interactions between modes are much less obvious, see for [3] for a detailed discussion of this issue. The attacks I lined out are far from theoretical, and have plagued various implementations (whether they are implementing JOSE or not implementing any particular standard), so I think having cryptographers review standards that use modes like this could be a good idea in general.

[1] https://youtu.be/CiH6iqjWpt8?t=1045
[2] https://github.com/google/security-research/security/advisories/GHSA-f5pg-7wfw-84q9
[3] https://ieeexplore.ieee.org/document/959888
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.