Subject: [6tisch] about draft-piro-6tisch-security-issues-01

From: Giuseppe Piro <[email-masked]>
Date: Fri, 23 May 2014 11:57:41 +0200

Dear all,

 I tried to summarize main issues recently discussed on the
draft-piro-6tisch-security-issues-01 (many thanks to Michael and Renè for
that).

 In what follows, they have been organized in macro categories, where both
your comments and my replies can be found.

 Please, let me know if my proposals have sense. Otherwise, indicate which
issues will remain still uncovered.

I'm looking forward to receive your further considerations.

 Thanks all,

Giuseppe

 -----

Issue #1 - Title of the draft

 [Michael R. @ Wed, May 14, 2014]: I don't agree with your title! I don't
see how  this is a "security framework". It is something much more useful
and important.

 The title will be changed with “Layer-2 security aspects for the IEEE
802.15.4e MAC”

Issue #2 – Derivation of Master Default Keys and unsecured frames

 [Michael R. @ Wed, May 14, 2014]: The Setting-up Phase seems to assume a
provisioning process to distribuite this MasterKey.  It could be that the
MasterKey comes from something like 1x/PANA?

 [Rene S @ Tue, May 20, 2014]: it is assumed that each node is
preconfigured with a master key M_k that is shared amongst all devices
(Section 6.1.1), from which default keys D_k are derived using a publicly
known function (with potentially other inputs, which are to be assumed
publicly known). This seems to imply that all default keys can be
considered as publicly known strings (!).

 [Rene S @ Tue, May 20, 2014]: the 802.15.4-2011 specification mistakenly
does not allow mixing of secured and unsecured traffic (see, e.g., my
emails of end of January 2014 on this). In particular, the hybrid security
network (as mentioned in Section 5) is not possible with 802.15.4-2011 or
802.15.4e-2012.

  The goal is to have a secured network, where all packets are encrypted
and unsecured MAC frames are not supported (according to the condition ‘d’
in Sec. 7.3.2 of the IEEE 802.15.4 std).

 In this context, the Master Key refers to the “fake key” that all all
nodes know from the beginning. It can be provided by the network
administrator or directly by the manufacturer. It is used to:

   1.

   protect beacon messages
   2.

   protect data frames storing messages of the join procedure handled by
   upper layers

 Thanks to the knowledge of the Master Key, all nodes, also those that has
not yet completed the join procedure, may communicate with secured MAC
frames (unsecured frames are not supported in a secured network).

 At the end of the join procedure, the node could obtain the Default Key
from the network by using high-level protocols like PANA/.1x (which also
offer authorization and authentication services). The Default Key, which
cannot be more considered as a publicly known strings, is used to protect
all broadcast messages and those exchanged between a couple of nodes for
negotiating a layer-2 key.

 Since the draft focuses on the MAC layer, I believe that this document is
not the right place where describing how PANA/.1x protocols can be used for
that purpose.  We can just assume that high level procedures (i.e., those
related to the join process) will obtain the Master Key from a specific
entity into the network.

 Issue #3 – Definition of secured configurations

 [Michael R. @ Wed, May 14, 2014]: Thank you for giving the network
definitions in section 5.0. It would be worth making it clear in the
definition of fully secure that all

broadcasts are encrypted, including the beacon. The _Hybrid Secured
network_ is likely the most common, and not because nodes are not capable
of encryption, but because they don't have the key (yet!!).

 [Thomas W. @Tue, Jan 7, 2014]: About the functionality, the draft
describes 5 configurations (Full, Unsecured, Partial, Hybrid, Flexible),
some of which support a combination of secured and unsecured L2 frames
depending on the capabilities of the devices. Can you comment on the
rationale between these configurations? I believe it is useful to look at
desired functionality first, and determine the configurations afterwards.
Naively, I am a bit scared of combining secured and unsecured. TSCH
networks are envisioned in the context of the IT/OT convergence to operate
in mission critical environments, so I would lean towards having only a
single configuration: fully secured.

  Starting from the initial Thomas’s comment, I will focus the attention
only to secured configurations.

 As indicated by Michael, the only two configurations that can be allowed
are (their definition is different to the one already present into the
draft):

   1.

   _fully_secured_configuration_: all devices have already ended the join
   procedure and have obtained the Default Key;
   2.

   _hybryd_secured_configuration_: some devices didn’t yet completed the
   join procedure and they have not yet the Default Key.

 In both configurations, all packets are encrypted (it is not possible to
exchange unsecured frames in a secured network). However, there are
different levels of security:

   1.

   Beacon and data frames containing join messages are encrypted by means
   of the Master Key ( a “fake key” provided by the network administrator
   before the network deployment).
   2.

   Broadcast messages and data frames used to negotiate the layer-2 key are
   protected with the Default Key.
   3.

   Any other unicast messages are protected with the Link Key properly
   negotiated through a KMP algorithm.

Issue #4 – Focus on the IEEE 802.15.4e

 [Rene S @ Tue, May 20, 2014] the draft relates to 802.15.4-2011. I would
suggest making this relative to 802.15.4e-2012 (which describes the TSCH
protocol and corresponding MAC extensions).

 With respect to security aspects, the IEEE 802.15.4e standards just
proposes few amendments. They will be taken into account for the writing of
the upgraded version of the draft.  However, the most of details provided
in Sec. 3 will remain still valid.

Issue #5 – KMP

 [Michael R. @ Wed, May 14, 2014]: My understanding is that 6.3 describes a
way to get fresh per-cluster keying. It appears that this is done over a
layer-2 protocol.  Why not MLE?

 [Rene S @ Tue, May 20, 2014]: the draft introduces new 802.15.4-command
frames to implement the key negotiation phase (Section 6.3). As such, this
would constitute a change to the 802.15.4-2011 and 802.15.4e-2012
specification. Besides, this also implies that the key negotiation phase
can only deal with one-hop behavior.

[Rene S @ Tue, May 20, 2014]: the key negotiation phase using the anonymous
Diffie-Hellman scheme (Section 6.3.3) that uses ordinary Diffie-Hellman
groups in the ring of integers Zp, where p is a prime number that indexed
by a publicly computable integer (Section 6.3.1, Step c1)) and where p has
at least bit-size 128 (see Appendix A.1). The ordinary Diffie-Hellman
problem in integer rings Zp of this order of magnitude sizes is efficiently
computable, thereby rendering this scheme completely insecure

  The negotiation of the layer-2 key will be handled by MLE by using new
Information Elements (we have already designed the new approach).  Hence,
the next version of the draft will propose a KMP protocol fully based on
the adoption of IEEE 802.15.4e IEs.

 In the upgraded version of the draft, the KMP protocol will be handled by
using certified DH and Station-to-station protocol. No restrictions on the
key of the public/private key will be considered. As a consequence,
security issues related to the ordinary Diffie-Hellman problem in integer
rings Zp will be no more present.

   Issue #6 - Authorization step

 [Rene S @ Tue, May 20, 2014] the key negotiation protocol deals with
authenticated key agreement and does not consider potential authorization
steps.

 Should authorization be performed by higher layers during the join
procedure (see Issue #2) ? If so, KMP could still ignore this aspect.

-- 
*Giuseppe Piro, PhD*
Post Doc Researcher
DEI, Politecnico di Bari
via Orabona 4 - 70125 (Bari), Italy.
email: [email-masked]
phone: +39 080 5963301
web: telematics.poliba.it/piro

---

From: Rene Struik <[email-masked]>
Date: Fri, 23 May 2014 11:21:15 -0400

Hi Giuseppe:

Some further feedback below.

Best regards, Rene

On 5/23/2014 5:57 AM, Giuseppe Piro wrote:
> draft-piro-6tisch-security-issues-01 (many thanks to Michael and Renè 
> for that).
>
> In what follows, they have been organized in macro categories, where 
> both your comments and my replies can be found.
>
> Please, let me know if my proposals have sense. Otherwise, indicate 
> which issues will remain still uncovered.
>
>
> [Michael R. @ Wed, May 14, 2014]: I don't agree with your title! I 
> don't see how  this is a "security framework". It is something much 
> more useful and important.
>
> [Michael R. @ Wed, May 14, 2014]: The Setting-up Phase seems to assume 
> a provisioning process to distribuite this MasterKey.  It could be 
> that the MasterKey comes from something like 1x/PANA?
>
> (Section 6.1.1), from which default keys D_k are derived using a 
> publicly known function (with potentially other inputs, which are to 
> be assumed publicly known). This seems to imply that all default keys 
> can be considered as publicly known strings (!).
>
> [Rene S @ Tue, May 20, 2014]: the 802.15.4-2011 specification 
> mistakenly does not allow mixing of secured and unsecured traffic 
> (see, e.g., my emails of end of January 2014 on this). In particular, 
> the hybrid security network (as mentioned in Section 5) is not 
> possible with 802.15.4-2011 or 802.15.4e-2012.
>
> and unsecured MAC frames are not supported (according to the condition 
> ‘d’ in Sec. 7.3.2 of the IEEE 802.15.4 std).
>
>     protect data frames storing messages of the join procedure handled
>     by upper layers
>
RS>>
Of course, use of a master key that is "printed in a spec" is 
cryptographically the same as not using security at all. There are some 
caveats, though: (a) successful processing of secured incoming frames, 
results in a state change on the recipient device (update of nonce value 
- 802.15.4-2011, 7.2.3, Step q). With fake security, this would result 
in potential ways to set the frame counter to any value (including the 
"infinity" value). (b) processing of secured incoming frames requires 
the availability in a PIB table of the originator's address (see 
802.15.4-2011, 7.2.3, Step g). Without this, incoming security 
processing will fail. {BTW - for clarity: my comment was pointing at a 
mistake in 802.15.4-2011, which precludes the mixing of secured and 
unsecured traffic.}
<<RS
>
> 1.
>
>
> Thanks to the knowledge of the Master Key, all nodes, also those that 
> has not yet completed the join procedure, may communicate with secured 
> MAC frames (unsecured frames are not supported in a secured network).
>
> At the end of the join procedure, the node could obtain the Default 
> Key from the network by using high-level protocols like PANA/.1x 
> (which also offer authorization and authentication services). The 
> Default Key, which cannot be more considered as a publicly known 
> strings, is used to protect all broadcast messages and those exchanged 
> between a couple of nodes for negotiating a layer-2 key.
>
RS>>
Okay - it is indeed possible for the security manager to hand a 
network-wide key (which you call Default Key above) to the joining 
device, as part of the joining protocol and after successful completion 
of the authenticated key agreement scheme. In my understanding, this is 
not how this is written in your 01-draft, though.
<<RS

> Since the draft focuses on the MAC layer, I believe that this document 
> is not the right place where describing how PANA/.1x protocols can be 
> used for that purpose.  We can just assume that high level procedures 
> (i.e., those related to the join process) will obtain the Master Key 
> from a specific entity into the network.
>
>
> network_ is likely the most common, and not because nodes are not 
> capable of encryption, but because they don't have the key (yet!!).
>
> describes 5 configurations (Full, Unsecured, Partial, Hybrid, 
> Flexible), some of which support a combination of secured and 
> unsecured L2 frames depending on the capabilities of the devices. Can 
> you comment on the rationale between these configurations? I believe 
> it is useful to look at desired functionality first, and determine the 
> configurations afterwards. Naively, I am a bit scared of combining 
> secured and unsecured. TSCH networks are envisioned in the context of 
> the IT/OT convergence to operate in mission critical environments, so 
> I would lean towards having only a single configuration: fully secured.
>
> As indicated by Michael, the only two configurations that can be 
> allowed are (their definition is different to the one already present 
> into the draft):
>
> 1.
>
>     _fully_secured_configuration_: all devices have already ended the
>     join procedure and have obtained the Default Key;
>
> 2.
>
>     _hybryd_secured_configuration_: some devices didn’t yet completed
>     the join procedure and they have not yet the Default Key.
>
> In both configurations, all packets are encrypted (it is not possible 
> to exchange unsecured frames in a secured network). However, there are 
>     Beacon and data frames containing join messages are encrypted by
>     means of the Master Key ( a “fake key” provided by the network
>     administrator before the network deployment).
>
> 2.
>
>     Broadcast messages and data frames used to negotiate the layer-2
>     key are protected with the Default Key.
>
> 3.
>
>     Any other unicast messages are protected with the Link Key
>     properly negotiated through a KMP algorithm.
>
>
> [Rene S @ Tue, May 20, 2014] the draft relates to 802.15.4-2011. I 
> would suggest making this relative to 802.15.4e-2012 (which describes 
> the TSCH protocol and corresponding MAC extensions).
>
> proposes few amendments. They will be taken into account for the 
> writing of the upgraded version of the draft.  However, the most of 
> details provided in Sec. 3 will remain still valid.
>
>
RS>>
The difference is indeed not that huge. Please note, though, that 
security processing for TSCH is specified differently than for non-TSCH 
mode operations. (Whether this has been wisdom remains to be seen, since 
depending on unfallability of ASN numbers.)
<<RS
>
>
> Issue #5 – KMP
>
> [Michael R. @ Wed, May 14, 2014]: My understanding is that 6.3 
> describes a way to get fresh per-cluster keying. It appears that this 
> is done over a layer-2 protocol.  Why not MLE?
>
> [Rene S @ Tue, May 20, 2014]: the draft introduces new 
> 802.15.4-command frames to implement the key negotiation phase 
> (Section 6.3). As such, this would constitute a change to the 
> 802.15.4-2011 and 802.15.4e-2012 specification. Besides, this also 
> implies that the key negotiation phase can only deal with one-hop 
> behavior.
>
> [Rene S @ Tue, May 20, 2014]: the key negotiation phase using the 
> anonymous Diffie-Hellman scheme (Section 6.3.3) that uses ordinary 
> Diffie-Hellman groups in the ring of integers Zp, where p is a prime 
> number that indexed by a publicly computable integer (Section 6.3.1, 
> Step c1)) and where p has at least bit-size 128 (see Appendix A.1). 
> The ordinary Diffie-Hellman problem in integer rings Zp of this order 
> of magnitude sizes is efficiently computable, thereby rendering this 
> scheme completely insecure
>
> Information Elements (we have already designed the new approach). 
>  Hence, the next version of the draft will propose a KMP protocol 
> fully based on the adoption of IEEE 802.15.4e IEs.
>
RS>>
The outcome of the join protocol should include a shared (link) key 
between the joining node and its neighbor or network manager, which will 
end up in the MAC PIB table, including associated keying related 
information. This join protocol should also deal with frame counter 
initialization and updates and resolving this with the ASN entry. I do 
not think it would necessarily be a good idea to treat join protocol 
messages as anything different from MAC data frames (i.e., it is higher 
layer traffic). This holds the more so, since join protocol will include 
some flows with the network manager, who may be multiple hops away (and 
MAC has no knowledge about anything more than one hop).
<<RS
>
> In the upgraded version of the draft, the KMP protocol will be handled 
> by using certified DH and Station-to-station protocol. No restrictions 
> on the key of the public/private key will be considered. As a 
> consequence, security issues related to the ordinary Diffie-Hellman 
> problem in integer rings Zp will be no more present.
>
RS>>
Ordinary Diffie-Hellman groups defined over the ring of integers mod p 
(when implemented at the right security level) will be prohibitively 
expensive on constrained devices. The only viabl option here would be to 
use elliptic curve based Diffie-Hellman groups.
<<RS
> authenticated key agreement and does not consider potential 
> authorization steps.
>
RS>>
An authenticated key agreement scheme can ignore authorization steps; a 
join protocol, which includes both key agreement, authorization, and 
configuration steps cannot.
<<RS
> email: [email-masked] <mailto:[email-masked]>
> phone: +39 080 5963301
> web: telematics.poliba.it/piro <http://telematics.poliba.it/piro>

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Giuseppe Piro <[email-masked]>
Date: Sat, 24 May 2014 10:07:55 +0200

Hi Renè,  thanks for you further comments.

Please, find my considerations below.

On Fri, May 23, 2014 at 5:21 PM, Rene Struik <[email-masked]> wrote:

> results in a state change on the recipient device (update of nonce value -
> 802.15.4-2011, 7.2.3, Step q). With fake security, this would result in
> potential ways to set the frame counter to any value (including the
> "infinity" value). (b) processing of secured incoming frames requires the
> availability in a PIB table of the originator's address (see 802.15.4-2011,
> 7.2.3, Step g). Without this, incoming security processing will fail. {BTW
> - for clarity: my comment was pointing at a mistake in 802.15.4-2011, which
> precludes the mixing of secured and unsecured traffic.}
> <<RS
>

​GP>>​
I agree with comment (a) but at the moment I do not have a solution to that
problem : I have to reader more carefully the draft for that.
W.r.t comment (b), it is possible to avoid this issue by indexing the
Master Key implicitly (this allows the node that has not a Device
Descriptor of the sender to correctly decrypt the received packet).
 The Master Key may be identified implicitly by setting
KeyIDMode=0x00 and device_addressing_mode = NO_ADDRESS
In this case, the DeviceDescriptor, selected in the DeviceDescriptor lookup
procedure, is the one associated to the coordinator and no errors will
arise from the procedures.
 What do you think ?
If this has sense, we will describe in details such an aspect in the next
version of the draft.
 ​<<GP​

> has not yet completed the join procedure, may communicate with secured MAC
> network-wide key (which you call Default Key above) to the joining device,
> as part of the joining protocol and after successful completion of the
> authenticated key agreement scheme. In my understanding, this is not how
> this is written in your 01-draft, though.
> <<RS
>

​GP>>​
​The derivation of the Default Key (or Network Key) as described in this
mail has not been presented in the draft. It is just our proposal that we
will consider during the writing of the next version of the document.
​<<GP​
​

​
​

> is not the right place where describing how PANA/.1x protocols can be used
> for that purpose.  We can just assume that high level procedures (i.e.,
> those related to the join process) will obtain the Master Key from a
> specific entity into the network.
>
>
>    Broadcast messages and data frames used to negotiate the layer-2 key
>    are protected with the Default Key.
>     3.
>
> The difference is indeed not that huge. Please note, though, that security
> processing for TSCH is specified differently than for non-TSCH mode
> operations. (Whether this has been wisdom remains to be seen, since
​GP>>​
​I will take care about the 802.15.4e amendments. ​
​<<GP​

>
>  Issue #5 – KMP
>
>  [Michael R. @ Wed, May 14, 2014]: My understanding is that 6.3 describes
> a way to get fresh per-cluster keying. It appears that this is done over a
> Diffie-Hellman groups in the ring of integers Zp, where p is a prime number
> that indexed by a publicly computable integer (Section 6.3.1, Step c1)) and
> where p has at least bit-size 128 (see Appendix A.1). The ordinary
> Diffie-Hellman problem in integer rings Zp of this order of magnitude sizes
> is efficiently computable, thereby rendering this scheme completely insecure
>
> initialization and updates and resolving this with the ASN entry. I do not
> think it would necessarily be a good idea to treat join protocol messages
> as anything different from MAC data frames (i.e., it is higher layer
> traffic). This holds the more so, since join protocol will include some
> flows with the network manager, who may be multiple hops away (and MAC has
> no knowledge about anything more than one hop).
> <<RS
>
> use elliptic curve based Diffie-Hellman groups.

​GP>>​
​OK, thanks for the clarification. We will include into the draft a
solution based on ECDH
​<<GP​

> configuration steps cannot.

​GP>>​
​OK, I agree
​<<GP​

-- 
*Giuseppe Piro, PhD*
Post Doc Researcher
DEI, Politecnico di Bari
via Orabona 4 - 70125 (Bari), Italy.
email: [email-masked]
phone: +39 080 5963301
web: g <http://telematics.poliba.it/piro>iuseppepiro.com