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 protected]> wrote:

> 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 protected]>
> *Verzonden:* woensdag 16 november 2016 4:09
> *Aan:* Michael Richardson
> *CC:* [email protected]; 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 protected]> wrote:
>
>>
>> Gregory Braekevelt <[email protected]> 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.
>>
>>
>> _______________________________________________
>> 6tisch mailing list
>> [email protected]
>> 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
> _______________________________________
>



-- 
_______________________________________

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
_______________________________________
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch

Reply via email to