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 <[email protected]> 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>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
