Re: [6tisch] TSCH and CCM security proofs

["Pascal Thubert (pthubert)" <[e-mail]>]

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 <[e-mail]> On Behalf Of Tero Kivinen
> Sent: mercredi 10 juillet 2019 23:47
> To: [e-mail]
> 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.
> --
> [e-mail]
> 
> _______________________________________________
> 6tisch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tisch