Subject: [6tisch] TSCH and CCM security proofs

From: Tero Kivinen <[email-masked]>
Date: Thu, 11 Jul 2019 00:47:08 +0300

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-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 11 Jul 2019 07:44:20 +0000

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-masked]> On Behalf Of Tero Kivinen
> Sent: mercredi 10 juillet 2019 23:47
> To: [email-masked]
> 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.
> 
> 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:
> 
> 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.
> 
> 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:
> 
> 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):
> 
> 
> 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).
> 
> 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
> NOTE 3 — Test vectors for cryptographic building blocks are given in Annex C.
> --
> [email-masked]
> 
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 12 Jul 2019 01:24:02 +0300

> Do you have an intention to add text like this in a draft or in

I think it will be enough for our IETF drafts to just say:

  Implementations MUST use different L2 keys when using different MIC
  lengths, as using same key with different MIC lengths might be
  unsafe (i.e., using same key for both MIC-32 and MIC-64). See IEEE
  802.15.4 Annex B.4.3 for more information.
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Mon, 15 Jul 2019 15:09:30 -0400

> lengths, as using same key with different MIC lengths might be unsafe
    > (i.e., using same key for both MIC-32 and MIC-64). See IEEE 802.15.4
    > Annex B.4.3 for more information.

This seems like it isn't a problem.
It would apply to network-wide keying only.
While I guess we could include multiple Link_Layer_Key with the same
key_id, and a different key_usage, that wasn't the intention.  I
guess one could use a different K1 and K2 with a different MIC length, but
have no idea why a network would want to mix MIC-32 and MIC-64.

I imagine that there performance or power tradeoffs to using the longer MIC
lengths, other than there are more check bytes?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 18 Jul 2019 00:35:56 +0300

> It would apply to network-wide keying only.

It applies all keys, not only network-wide keys. 

> have no idea why a network would want to mix MIC-32 and MIC-64.

Most common use might be someone using MIC-32 for beacons, but using
MIC-64 for actual data or something like that.
draft-ietf-6tisch-minimal-security seems to be using different keys
when the mic length is different (k1, and k2), and when k1 and k2 are
same it will always use same mic length, so there is no problem there.

Anyways it might good idea to add the warning somewhere, just incase
someone adds new combinations without realizing this problem.
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Wed, 17 Jul 2019 21:31:40 -0400

Tero Kivinen <[email-masked]> wrote:
    >> unsafe > (i.e., using same key for both MIC-32 and MIC-64). See IEEE
    >> 802.15.4 > Annex B.4.3 for more information.
    >> 
    >> This seems like it isn't a problem.  It would apply to network-wide
    >> keying only.

    > It applies all keys, not only network-wide keys.

yes, but if one uses 802.15.9, then the likelyhood of repeated keys is pretty
low, right?

    >> key_id, and a different key_usage, that wasn't the intention.  I guess
    >> one could use a different K1 and K2 with a different MIC length, but

    > MIC-64 for actual data or something like that.

Yes, but why do that?
What's the benefit?

    > someone adds new combinations without realizing this problem.

okay.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 22 Jul 2019 18:40:20 +0300

> yes, but if one uses 802.15.9, then the likelyhood of repeated keys is pretty

No. Broadcast keys are most likely same for some time, and if you join
the network before they are changed, the 15.9 will deliver you the
same keys than last time. Pairwise keys generated by 15.9 are of
course going to be different. 

>     > MIC-64 for actual data or something like that.

Most likely saving bytes over the air. The EBs are sent quite often,
and things that are there are already known by anybody who is already
joined the network, thus they only care about the exact timing of the
frame, not really about the content. Of course if there is changes for
the network setup indicaed by EB, then it would be different, but I do
not think anybody does that, as chaing any of the parameters inside
the network (timing, channels used etc) would really mess up the
network completely thus tearing down the network and starting over is
better option.
-- 
[email-masked]