On Jul 22, 2024, at 5:35 AM, Ken Takayama <[email protected]> wrote:
Ilari, > - So if it is combined KDF+KW, it is alg of this layer. > - Otherwise, it is alg of next layer. It seems like section 4.6.2 of RFC 7518 "JSON Web Algorithms" <https://datatracker.ietf.org/doc/html/rfc7518#section-4.6.2> > In the Key Agreement with Key Wrapping case, Data is set to the octets of the > ASCII representation of the "alg" (algorithm) Header Parameter value. On the other hand, section 5.2 of RFC 9053 says, > This field indicates the algorithm for which the key material will be used. > This normally is either a key wrap algorithm identifier or a content > encryption algorithm identifier. That's why I'm still not convinced to use ECDH-SS+A256KW (-34) for AlgorithmID in COSE. Right, ECDH+AES-KW (-29 through -34) are broken. When fixed, they’ll have different IDs. Laurence, > I’ve modified it to show some options to address the attack. Thanks! I could update the chart. Since it is generated by the aasvg tool, colors fade away... Your proposal is depicted [Rec], and fed into ContextR.open(aad=Rec, ct=eCEK). Does it mitigate lamps attack only with COSE-HPKE? In my proposal [Rec] would replace [CIS] as input to HKDF for ECDH+AES-KW. That of course would have to have a new algorithm ID. It’s not compatible with -29 through -34, but adding the HKDF later as Hannes proposed isn’t compatible either. With this, [Rec] is input as AAD to HPKE Open() and [Rec] is input to the HKDF. These are different, but they achieve the same result. In HPKE Open(aad=Rec), open will fail with an error code and stop the decryption. In ECDH+AES-KW, the wrong CEK will be produced and the content decryption will produce a garbled result or produces an integrity check failure. In a conversation with Hannes last night, he told me that Paul C. van Oorschot told him that either of these are fine. Also, in some ways Recipient_structure is not that different from Context Info Structure. They both have an algorithm ID and cover the protected headers. They are both input into the processing at the same place. The main difference is that all the extra stuff to address weak keys, bind to context and such goes in COSE headers in Recipient_structure rather than an arcane inherited structure half of which doesn’t make sense, is ill-defined and such. Really appreciate the nice diagrams and thinking here!! LL ```aasvg Direct Direct+KDF AES-KW Direct ECDH ECDH+AES-KW COSE-HPKE .---. .--. .---. .---. .---. .---. .---. .---. .---. | PSK | | SS | | PSK | | pkS || skR | | pkS || skR | | pkS || skR | '-+-' '-+' '-+-' '-+-' '-+-' '-+-' '-+-' '-+-' '-+-' | | | v v v v v v | | | +--+------+--+ +--+------+--+ .-+------+-. | | | | ECDH | | ECDH | | ContextR | | | | +-+----------+ +--+---------+ '-+--------' | .-' | v v | | | .---. | .--+--. .---. .--+--. .---. | .---. | || CIS | | | DH SS || CIS | | DH SS || CIS | | | Rec | | | '-+-' | '--+--' '-+-' '--+--' '-+-' | '-+-' | v v | v v v v | .-' | +-+---+-+ | +-+-------+-+ +-+-------+-+ | | | | HKDF | | | HKDF | | HKDF | | | | +---+---' .-' +-----+-----+ +---+-------+ | | | | | .----. | | .----. | | .----. | | || eCEK | | || eCEK | | || eCEK | | | | '--+-' | | '--+-' | | '-+--' | | v v | v v v v v | | +-+----+-+ | +-+----+-+ +-+-+---+-+ | | | Unwrap | | | Unwrap | | open | | | +---+----+ | +---+----+ +----+----+ v v v v v v .-+------+-------+------------+----------------+-------------+---. | Content Encryption Key (CEK) | '---------------------+------------------------------------------' | .----. | | CIS? | | '-+--' v v +-------------+----+--------+ .-----------------. | HKDF if cek-hkdf [Hannes] | | Encrypted Payload | +-------------+-------------+ '--------+--------' v v +----------------------+------------------------------+--------------+ | Content Decryption with ce_alg = AES GCM, CCM, CTR, CBC, ... | +---------------------------------+----------------------------------+ v .---------+--------. | Plaintext Payload | '------------------' PSK : Pre Shared Key SS : Shared Secret pkS : (Static or Ephemeral) sender's Public key skR : recipient's Private key CIS : COSE Context Information Structure DH SS : DH-Shared Secret Rec : Recipient_structure [Laurence] eCEK : encrypted CEK in COSE message ``` <cek_hkdf_decryption.png> 2024年7月22日(月) 6:59 lgl island-resort.com<http://island-resort.com/> <[email protected]<mailto:[email protected]>>: On Jul 20, 2024, at 11:42 PM, Ilari Liusvaara <[email protected]<mailto:[email protected]>> wrote: On Sun, Jul 21, 2024 at 10:16:20AM +0900, Ken Takayama wrote: Understand. We have to consider what the COSE library implementers are facing. I've attached a chart describing the decryption procedure, including the current key distribution methods in COSE 9053 and cose-hpke, and the approach proposed by Hannes. (Please fix it if I'm wrong.) The actual implementations have to "correctly" set the Context Information Structure but its explanation in RFC 9053 is ambiguous, especially the AlgorithmID. I find AlgorithmID mostly clear: When deriving keys, it is alg of the layer the key is used on. - So if it is combined KDF+KW, it is alg of this layer. - Otherwise, it is alg of next layer. To be more clear, it’s algorithm ID of the next _COSE_ layer, right? In the case of two-layer cose where you have a COSE_Encrypt and a COSE_Recpient, the “next algorithm ID" secured by the COSE_Recipient layer is the one performed in the COSE_Encrypt layer. (The COSE_Recipient can do all sorts of things with lots of algorithms internally and all those IDs need to be secured, but that is not what we’re talking about here; in particularly when a COSE_Recipient does KEM + KW or such, it’s not the algorithm ID of the KW). Things get bit hairy when deriving IVs. Clearly AlgorithmID=34 (0x18 0x22) when deriving IVs, but what exactly triggers IV derivation[1]? And then things get really hairy with PartyUInfo and PartyVInfo. Those are by far the most difficult part of the CIS. There’s no scenario where HPKE needs PartyU and PartyV, right? (the only reference in RFC 8610 to NIST SP 800-56A is about making sure input keys are of the right form) LL _______________________________________________ COSE mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
