Subject: [6tisch] Malware in IoT/WSN with 6tisch + Clock Drift

From: Gregory Braekevelt <[email-masked]>
Date: Mon, 7 Nov 2016 17:16:36 +0000

Greetings

I have a special question about malware in IoT. The scenario is as
follows:

All nodes/devices in the network have an internal clock that gets synchronized
by an operator/gateway. This is done by using a TSCH protocol, for example 6tisch.
In case malware is written/introduced to a node/device, for example through  a
bug or exploit in software or the OS, a corrupted operator/gateway,..., would
this insertion of the malware cause the clock of the node/device to drift?

If yes: would this be big enough to detect? Since variables like heat can
cause small drifts.
If no: could this perhaps be forced in any way? Like forcing the device to
resync everytime any software is added.
If unknown: whats the best way to test this with live nodes/devices and a
synchronized WSN using 6tisch?

I'm mainly searching for information that proofs or counters the fact that
malware (can) cause clock drift.

Thanks in advance!

With kind regards

Gregory Braekevelt
Student Applied Informatics?

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 9 Nov 2016 11:30:08 +0100

Gregory,

Your e-mail was waiting in the moderator queue. Please register to the ML
so you can post directly.

Allow me to answer inline. I'm counting on 6TiSCH-sec DT member to
complement by answer.

On Mon, Nov 7, 2016 at 6:16 PM, Gregory Braekevelt <
[email-masked]> wrote:

> Greetings
>
> I have a special question about malware in IoT.
>
cool

> The scenario is as
> by an operator/gateway.
Strictly speaking, a node synchronize to a time source neighbor. Time
parent-child relationships are installed in the network so synchronization
trickles down from the DAGroot which acts as a time master. See
https://tools.ietf.org/html/rfc7554#appendix-A.8.

> This is done by using a TSCH protocol, for example 6tisch.
If you have no security, that's indeed a problem. A node could change the
time correction it writes in its ACKs to force its child to align to an
arbitrary time base. If this time base is more than guard-time from the
actual time base used, the child de-synchronizes from the network. But if
you have no security at all in the network, that everything is possible,
and this attacks seems very subtle compared to all the damage you can do if
there is no security.

So that's why security is always on in a 6TiSCH network. At the link layer,
all link layers protected using CCM*. In draft-ietf-6tisch-minimal, the
nodes are pre-provisioned with a key; draft-vucinic-6tisch-minimal-security
and draft-richardson-6tisch-dtsecurity-secure-join are two solution to
learn the link-layer keying material during the join process of a mote.

> Thanks in advance!
I this helps.

>
>
> With kind regards
>
> Gregory Braekevelt
> Student Applied Informatics​
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

-- 
_______________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
_______________________________________

---

From: Michael Richardson <[email-masked]>
Date: Sat, 12 Nov 2016 11:49:01 +0900

Gregory Braekevelt <[email-masked]> wrote:
    > I'm mainly searching for information that proofs or counters the fact
    > that malware (can) cause clock drift.

It could be the case, and for a specific device, and a specific piece of
malware, it could be the case.  I see no reason for there to be general rule
like this.

So, yes, malware could cause clock drift, but I see no reason why malware
MUST cause clock drift.

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 16 Nov 2016 12:09:48 +0900

Gregory,

I agree with Michael's response, but I fail to understand the
scope/relevance of what you are describing.

The firmware running on the mote implements the IEEE802.15.4 TSCH state
machine, which includes everything related to timing.
If your "malware" is a complete new firmware, it can do anything it wants,
including introduce an arbitrary drift, blink LEDs, or make coffee.
If your "malware" is a new application running on top of a stack, your
software architecture should rely on the kernel to prevent this application
from breaking/influencing the stack. This can be done by having an MPU
detect when the app accesses memory locations it isnt support to, and
killing it.

I feel that this discussion is related to software architecture, not
protocol/6TiSCH.

Thomas

Thomas Watteyne, PhD

www.thomaswatteyne.com

---

From: Gregory Braekevelt <[email-masked]>
Date: Wed, 16 Nov 2016 14:33:24 +0000

Dear mr Watteyne

I'll explain why the question is relevant for me.

I am researching the possibility whether I can use the tight synchronisation of TSCH in a network of sensors/nodes to detect the presence of malware for research for a master thesis.

What kind of malware it is, doesn't matter for now. But basically, if malware is placed on a node and this action causes clock drift, it might be possible to detect this due to the desynchronisation that follows.

In the coming days, I am going to try and test this after getting more familiar with OpenWSN and 6TiSCH.
If this is not the case, I could always enforce it by making the node to resynchronize everytime new software is added.

Although this scenario would be the best and most fun for me to research, I can also try out different aspects. For example: Using TSCH I might be able to detect the presence of malware due to a difference in time of a certain process or the duration of a packet on the network. I could profile a node and detect difference in it between 2 runs of the profiles.
So in conclusion, I would like to do/research intrusion/malware detection in IoT using TSCH!
Indeed, it isn't specifically related to 6TiSCH but a possibility to use it with/for 6TiSCH. And so I was wondering if I could find some information by contacting you.

I don't think a phone call is necessary. Although this is quite important for me, I can wait for answers and I can continue on my own if this doesn't work. I have multiple options to explore. But thanks for the offer!

Also thanks for the replies so far!

With kind regards

Gregory Braekevelt ?
?

________________________________
Van: Thomas Watteyne <[email-masked]>
Verzonden: woensdag 16 november 2016 4:09
Aan: Michael Richardson
CC: [email-masked]; Gregory Braekevelt
Onderwerp: Re: [6tisch] Malware in IoT/WSN with 6tisch + Clock Drift

Gregory,

I agree with Michael's response, but I fail to understand the scope/relevance of what you are describing.

The firmware running on the mote implements the IEEE802.15.4 TSCH state machine, which includes everything related to timing.
If your "malware" is a complete new firmware, it can do anything it wants, including introduce an arbitrary drift, blink LEDs, or make coffee.
If your "malware" is a new application running on top of a stack, your software architecture should rely on the kernel to prevent this application from breaking/influencing the stack. This can be done by having an MPU detect when the app accesses memory locations it isnt support to, and killing it.

I feel that this discussion is related to software architecture, not protocol/6TiSCH.

Thomas

On Sat, Nov 12, 2016 at 11:49 AM, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

Thomas Watteyne, PhD

www.thomaswatteyne.com<http://www.thomaswatteyne.com>
_______________________________________

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 16 Nov 2016 23:51:59 +0900

Gregory,
Excellent, I get much better what you are trying to do. Allow me to take
this discussion off-list, as not directly related to the standardization
work at 6TiSCH.
Thomas

On Wed, Nov 16, 2016 at 11:33 PM, Gregory Braekevelt <
[email-masked]> wrote:

> I am researching the possibility whether I can use
> the tight synchronisation of TSCH in a network of sensors/nodes to detect
> the presence of malware for research for a master thesis.
>
> What kind of malware it is, doesn't matter for now. But basically, if
> malware is placed on a node and this action causes clock drift, it might be
> possible to detect this due to the desynchronisation that follows.
>
> If this is not the case, I could always enforce it by making the node
> to resynchronize everytime new software is added.
>
>
> Although this scenario would be the best and most fun for me to research,
> I can also try out different aspects. For example: Using TSCH I might be
> able to detect the presence of malware due to a difference in time of
> a certain process or the duration of a packet on the network. I could
> profile a node and detect difference in it between 2 runs of the profiles.
> Indeed, it isn't specifically related to 6TiSCH but a possibility to use
> it with/for 6TiSCH. And so I was wondering if I could find some information
> by contacting you.
>
> I don't think a phone call is necessary. Although this is quite important
> for me, I can wait for answers and I can continue on my own if this doesn't
> work. I have multiple options to explore. But thanks for the offer!
>
>
> Gregory Braekevelt ​
> ​
> ------------------------------
> *Van:* Thomas Watteyne <[email-masked]>
> *Verzonden:* woensdag 16 november 2016 4:09
> *Aan:* Michael Richardson
> *CC:* [email-masked]; Gregory Braekevelt
> *Onderwerp:* Re: [6tisch] Malware in IoT/WSN with 6tisch + Clock Drift
>
> Gregory,
>
> On Sat, Nov 12, 2016 at 11:49 AM, Michael Richardson <
> [email-masked]> wrote:
>
>>

Thomas Watteyne, PhD

www.thomaswatteyne.com