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

[Sophie Schmieg <[e-mail]>]

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