Many thanks Tero. Do you have an intention to add text like this in a draft or in annex of a draft?
All the best, Pascal > -----Original Message----- > From: 6tisch <[email protected]> On Behalf Of Tero Kivinen > Sent: mercredi 10 juillet 2019 23:47 > To: [email protected] > Subject: [6tisch] TSCH and CCM security proofs > > When I was doing 802.15.4 revision review, I found out that the Annex B says > that security proofs for CCM* only apply when nonce contains security level. > In TSCH mode nonce, the nonce does NOT include security level so the CCM* > security proofs cannot be used, thus it needs to revert back to normal CCM > security proofs, and that means that same key cannot be used with different > mic lengths. I.e., if you want to use MIC-32, MIC-64, and MIC-128 you must > use different keys for each of them. > > With non-TSCH mode it is safe to use same key for all of them, and the > security proofs still work. With TSCH not so much. > > I do not think there is any practical attack, as the security axiliary header > which is part of the MIC does contain the security level even in TSCH case, > but > perhaps we still want to mandate in 6tisch that different key lengths MUST > use different keys just to keep in sync with CCM security proofs. > > This is text that has been there since 2006, but which I did just noticed now, > and which those who specified TSCH nonce generation also had missed. I > noticed it now when I started making proposed changes to fix the text and > remove all references to M=0 case, as we did remove encrypt only feature in > 2015. > > So from 802.15.4-2015: > > ---------------------------------------------------------------------- > B.4.3 Restrictions > > All implementations shall limit the total amount of data that is encrypted > with a single key. The CCM* encryption and authentication transformation > shall invoke not more than 2^61 block cipher encryption function invocations > with the same key in total. > > The CCM* decryption and authentication checking transformation shall not > expose any information if any verification check fails. The only information > that may be exposed in this case is that the authenticity verification > transformation failed; all other information, such as the purported plaintext, > shall be destroyed. > > NOTE 1 — With regard to security of the CCM* mode of operation, the > CCM* mode coincides with the original CCM mode specification (ANSI > X9.63-2001 [B2]) for messages that require authentication and, possibly, > encryption, but also offers support for messages that require only encryption. > Moreover, it can be used in implementation environments for which the use > of variable-length authentication tags, rather than fixed-length > authentication > tags only, is beneficial. As with the CCM mode, the CCM* mode requires only > one key. The CCM* specification differs from the CCM specification, as > follows: > > — The CCM* mode allows the length of the Authentication field M to be > zero as well (the value M = 0 corresponding to disabling > authenticity because then the Authentication field is the empty > string). > > — The CCM* mode imposes a further restriction on the nonce N: it shall > encode the potential values for M so that one can uniquely determine > from N the actually used value of M. > > As a result, if M is fixed and the value M = 0 is not allowed, then there are > no > additional restrictions on N, in which case the CCM* mode reduces to the > CCM mode. In particular, the proof of the CCM mode applies (Jonsson [B7] > and [B8]). > > For fixed-length authentication tags, the CCM* mode is equally secure as the > original CCM mode. For variable-length authentication tags, the > CCM* mode completely avoids, by design, the vulnerabilities that do apply to > the original CCM mode. > > For fixed-length authentication tags, the security proof of the original CCM > mode carries over to that of the CCM* mode (also for M = 0), by observing > that the proof of the original CCM mode relies on the following properties, > which slightly relax those stated in Jonsson [B7] and [B8] (relaxed property > indicated in italics): > > > — The B_0 field uniquely determines the value of the nonce N. > > — The authentication transformation operates on input strings B_0 || > B_1 || B_2 || ... || B_t from which one can uniquely determine the > input strings a and m (as well as the nonce N). In fact, for any two > input strings corresponding to distinct triples (N, m, a), neither > one is a prefix string of the other. > > — All the A_i fields are distinct from the B_0 fields that are > actually used (over the lifetime of the key), as those have a Flags > field with a nonzero encoding of M in the positions where all A_i > fields have an all-zero encoding of the integer 0. > > Hence, if M is fixed, then the CCM* mode offers the same security properties > as the original CCM mode: confidentiality over the input string m and data > authenticity over the input strings a and m, relative to the length of the > authentication tag. Obviously, if M = 0, then no data authenticity is provided > by the CCM* mode itself (but may be provided by an external mechanism). > > For variable-length authentication tags, the original CCM mode is known to > be vulnerable to specific attacks (e.g., Section 3.4 of Rogaway and Wagner > [B13]). These attacks may arise with the original CCM mode because the > decryption transformation does not depend on the length of the > authentication tag itself. The CCM* mode avoids these attacks altogether by > requiring that one shall be able to uniquely determine the length of the > applicable authentication tag from the A_i fields (i.e., from the counters > blocks). > > NOTE 2 — With regard to the interoperability between CCM mode and CCM* > mode of operation, the CCM* mode reduces to the CCM mode in all > implementation environments where the length of the authentication tag is > fixed and where the value M = 0 (encryption-only) is not allowed. > In particular, the CCM* mode is compatible with the CCM mode, as specified > in IEEE Std 802.11TM-2007 (for WLANs), IEEE Std > 802.15.3TM-2003 (for WPANs), and IEEE Std 802.15.4-2003 (for older > WPANs). > > NOTE 3 — Test vectors for cryptographic building blocks are given in Annex C. > -- > [email protected] > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
