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 protected]> wrote: > Greetings > > I have a special question about malware in IoT. > cool > The scenario is as > follows: > > All nodes/devices in the network have an internal clock that gets > synchronized > 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. > In case malware is written/introduced to a node/device, for example t > hrough 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. > 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 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 _______________________________________
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
