[6tisch] TSCH and CCM security proofs

[Tero Kivinen <[e-mail]>]

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]