Hi Christian, On 2024-07-31 17:21, Christian Amsüss wrote:
Hello COSE key users, (selectively putting the overlapping authors in CC to get their attention -- or should I rather CC CoRE and LAKE?)implementing more and more of the full CoAP security stack, I find myself creating a lot of private keys, practically stored as CBOR files containing a COSE key. Using a standard format comes with the risk of mixing up key uses, so I'd like to set key_ops on them to ensure that, for example, a P-256 key created for EDHOC method 3 (ECDH) is not used for method 0 (signing). None of the CoAP security standards that use asymmetric keys (EDHOC, Group OSCORE) elaborate on which of their operations relate to which key_ops: Do they match that table? Or would they, in that table, correspond to completely new values for table 5 of RFC9052?
==>MTI think that the available values in Table 5 of RFC 9052 should be sufficient, in particular 1 (sign) and 7 (derive key).
I haven't implemented a key store like yours, but I would imagine the 'key_ops' parameter in the stored COSE Key to be as follows.
* For use in Group OSCORE- In an OSCORE group that uses the group mode (and, possibly, also the pairwise mode), key_ops = [ 1 ].
If the Signature Algorithm used in the OSCORE group is EdDSA, you may also want to store the private key that results from the remapping to the X25529/X448 coordinates.
Instead of recomputing it multiple times, that private key can be more conveniently retrieved when there is need to use it for deriving pairwise sender/recipient keys to use in the group. In that resulting COSE Key, I would have key_ops = [ 7 ].
- In an OSCORE group that uses only the pairwise mode, key_ops = [ 7 ]. * For use in EDHOC- If the EDHOC peer in question supports the EDHOC cipher suites 0 and 1 as well as all the four EDHOC authentication methods, then the EDHOC peer stores two private keys, i.e., one with key_ops = [ 1 ] and one with key_ops = [ 7 ].
Per [0][1], the latter Diffie-Hellman key should not be the result of a coordinate remapping from the former signing key.
- If the EDHOC peer in question supports the EDHOC cipher suites 2 and 3 as well as all the four EDHOC authentication methods, then the EDHOC peer stores two private keys, i.e., one with key_ops = [ 1 ] and one with key_ops = [ 7 ].
Per [0][1], the two keys should be different. <==
Whichever ops they relate to: How do they interact? In particular, outside of the combination of Group OSCORE in group mode (signing) and pairwise mode (static-static derivation), is there any combination that is allowed, which would ease the proof-of-possession step of joining an OSCORE group by performing that proof during EDHOC rather than in a later PoP step? And: How does either outcome follow from the key_ops that should be placed on a key generated for Group OSCORE?
==>MTIf I understand correctly, there are some delicate aspects to consider when thinking of such "combinations".
Let's say that we have an OSCORE group that uses the group mode (and, possibly, also the pairwise mode). This means that:
* The authentication credentials used in the group are paired with signing keys.
* The proof-of-possession that the OSCORE Group Manager has to achieve relies on a signature, as evidence that a node attempting to join the group possesses its own private signing key.
A "combination" here would be that EDHOC is run between the joining node and the OSCORE Group Manager, in such a way that the joining node authenticates itself with a Diffie-Hellman credential, for which the Group Manager will achieve proof-of-possession as per EDHOC.
If the goal here is for the Group Manager to rely on the proof-of-possession from EDHOC in order to skip achieving it again during the joining process, there seems to be two delicate points:
* The proof in [2] that Group OSCORE builds on admits the use of a signing key also for key agreement operations (if required, after coordinate remapping), specifically within the Group OSCORE protocol.
However, the scheme above would need a second exception where the signing key (if required, after coordinate remapping) is also used for key agreement operation towards authentication with Diffie-Hellman in EDHOC.
As discussed in [1], such a double purpose is generally not recommended unless proven secure otherwise. At least I cannot point to a security proof that reassures about deviating from [1] for the case above.
* Let's say that the joining node has an EdDSA signing key to use in the OSCORE group, and (deviating from the recommendation above) uses the corresponding Diffie-Hellman key obtained from coordinate remapping to authenticate itself with EDHOC.
From the EDHOC execution, the OSCORE Group Manager achieves proof-of-possession of the Diffie-Hellman private key of the joining node.
As far as I know, this does not additionally provide proof-of-possession of the signing private key of the joining node, which the Group Manager has to achieve in the interest of the Group OSCORE protocol.
Although I wish/hope that that was fine, at least I cannot point to a security proof saying so.
The reverse "combination" would be the case where the OSCORE group uses only the pairwise mode.
Hence: the authentication credentials to use in the group are paired with Diffie-Hellman keys, for which the Group Manager has to achieve proof-of-possession; and the joining node uses the corresponding signing key for authenticating itself in EDHOC, by means of a signature.
It seems that the same as above holds in reverse for this case too. Best, /Marco [0] https://www.rfc-editor.org/rfc/rfc9528.html#section-9.2 [1] https://www.rfc-editor.org/rfc/rfc9052.html#section-12 [2] https://eprint.iacr.org/2021/509 <==
Best regards Christian
-- Marco Tiloca Ph.D., Senior Researcher Phone: +46 (0)70 60 46 501 RISE Research Institutes of Sweden AB Box 1263 164 29 Kista (Sweden) Division: Digital Systems Department: Computer Science Unit: Cybersecurity https://www.ri.se
OpenPGP_0xEE2664B40E58DA43.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
