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

[Russ Housley <[e-mail]>]

Sophie:

I will be glad to go through the security considerations and make sure that all of these have been covered.  However, these concerns do not eliminate the legitimate need for a non-AEAD for SUIT firmware encryption.  Recognizing that AEAD is a better approach in most situations, the IANA registration will say "Deprecated" to avoid someone using it without understanding what they are doing.

Russ

> On Oct 27, 2022, at 2:12 PM, Sophie Schmieg <[e-mail]> wrote:
> 
> 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 <https://youtu.be/CiH6iqjWpt8?t=1045>
> [2] https://github.com/google/security-research/security/advisories/GHSA-f5pg-7wfw-84q9 <https://github.com/google/security-research/security/advisories/GHSA-f5pg-7wfw-84q9>
> [3] https://ieeexplore.ieee.org/document/959888 <https://ieeexplore.ieee.org/document/959888>