Hello list, As promised at IETF 121, I am providing a review of draft-tschofenig-cose-cek-hkdf-sha256-02. Below are my comments and feedback on the current draft
Disclaimer: Not as a cryptographer, but as a general reviewer with previous talks watched as context. Summary: The document specifies an attack against the COSE content encryption key when the algorithm identifier is manipulated. A mitigation method toward this attack is provided. The attack generically targets any CMS payload by downgrading AEAD security to encryption methods without authentication, namely AES-CBC. It apply to many protocols -- similar problem and solution is adopted in the LAMPS WG as draft-ietf-lamps-cms-cek-hkdf-sha256-05, which is now in RFC queue. Comments Attack: 1. AES-CBC mode is prone to chosen cipertext attack since A. it does not provide ciphertext authentication, and B. the fact that cipher blocks are sequentially chained. The attacker can recover the plaintext by guessing and modifying ciphertext blocks. Adding authentication to encryption with associated data can fix the problem, which is then AES-GCM/CCM mode, providing AEAD security. 2. This attack takes advantage of the mechanism that the decrypter victim does not check twice whether or not the encrypted content sent to him is encrypted using CBC or GCM mode. The attacker intercepts a AES-GCM/CCM ciphertext, sends it to the decrypter victim as AES-CBC guess block, and the victim blindly believes in the CBC context and decrypts it without double check. This output can be used for further (off-line) guessing reference. Sensitive information can be further inferred, using some magic presented by Johannes Roth and Falko Strenzke in https://datatracker.ietf.org/meeting/118/materials/slides-118-lamps-attack-against-aead-in-cms-00, originally published in usenix security. Please correct me if I get this part wrong 3. Generally we should choose AES-GCM instead of CBC whenever possible, but due to compatibility and performance reasons, CBC mode cannot be simply obseleted and make the problem go away. Defense: The defense is simple to understand -- bind the content encryption key (CEK) with an authenticated algorithm identifier. This draft adds a new parameter cek-hkdf in the COSE protected header. When this parameter is presented, must use a derived content-encryption key CEK' (original CEK binds with alg parameter of COSE_Encrypt header) or content-authenticated-encryption key. CEK' = HKDF(CEK, COSE_Encrypt.alg) if an attacker manipulates the algorithm identifier, the recipient will derive a different CEK', preventing the attacker from recovering the plaintext content. Moreover, since COSE_Encrypt.alg parameter is authenticated over protected header, the derived CEK' is trustworthy. My other comments are: AES-CBC is not inherently insecure, but it does require a lot of cryptographic engineering best practice to help people correctly use it. This means fixing this problem is not theoretical cryptographer's liability, but best done over defining best engineering mechanisms (standards). So I believe this draft reflects a real problem, and IETF might be the right place to do it. Engineering wise, since the actually-used CEK may come from different sources (Direct, AES-KW, ECDH+AES-KW, COSE-HPKE,...), computing derived CEK' needs a layer to "dock" all these different module inputs. Authors should maybe evaluate how much work is needed to implement this. Another question is in the security considerations: >>> If the attacker removes the cek-hkdf header parameter from the COSE_Encrypt header prior to delivery to the recipient, then the recipient will not attempt to derive CEK', which will deny the recipient access to the content, If the attacker changes the value of the COSE_Encrypt alg parameter prior to delivery to the recipient, then the recipient will derive a different CEK', >>> I am not a COSE expert, but if an attacker tampers with the cek-hkdf or COSE_Encrypt.alg parameter carried in a protected header, maybe it will cannot pass cose protected header integrity check? Please correct me if im missing something. The rest is fine with me. Best regards, Peter (Chunchi) Liu
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
