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]<mailto:[email protected]>> wrote: Gregory Braekevelt <[email protected]<mailto:[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]<mailto:[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<http://www.thomaswatteyne.com> _______________________________________
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
