Getting security right in wireless sensor networks

April 29, 2014 // By Kris Pister and Jonathan Simon, Dust Networks
The Internet of Things (IoT) is growing rapidly, and wireless sensor networks (WSNs) are critical to extending the reach of the Internet infrastructure to “everything.” In fact, WSNs are already in use in critical monitoring and control applications around the world. Any loss of security in these systems may have real and direct consequences on efficiency and safety.

Fortunately, the literature on securing wireless systems is readily available, and best practices are well known. Despite this knowledge, the news is filled with reports documenting successful attacks on wireless in general and WSN in particular. Surprisingly, many products on the market do not embrace even the most basic aspects of system security, and many other products with well-intended security fall short of the mark. We document here some of the common mistakes, and their well-known solutions. Wireless security is not trivial, but with rigorous attention to detail, it is possible to build systems that are not vulnerable to wireless attack.


Security issues are not limited to wireless systems. Indeed, Internet attacks big and small are so common today that they are barely newsworthy. There is a perception that wireless systems are more vulnerable to attack, because anyone with the appropriate radio can communicate with a wireless device from some distance. Of course, on the Internet, anyone with a computer can launch an attack from distances far longer than any radio signal will propagate. The bottom line is that all cyber-physical systems, whether wired or wireless, need to take careful precautions against attack.


The primary goals of security in WSNs are based on providing three elements:

Confidentiality - Data being transported in the network cannot be read by anyone but the intended recipient.

Integrity - Any message received is known to be exactly the message that was sent, without additions, deletions, or modifications of the content.

Authenticity - A message that claims to be from a given source is, in fact, from that source. If time is used as part of the authentication scheme, authenticity also protects a message from being recorded and replayed at a later time.

Confidentiality is required for not only security-related applications but also for common everyday applications. For example, sensor information regarding production levels or equipment status may have some competitive sensitivity. Sensor data should be encrypted so that only the intended recipient can use it.

Both sensing and command information must arrive intact. If a sensor indicates “the tank level is 72 cm” or the controller states, “turn the valve to 90 degrees,” it could be disastrous to lose one of the digits in either one of those numbers.

Having confidence in the source of a message is critical. Either of the two messages above could have very bad consequences if they were sent by a malicious attacker. An extreme example is a message such as, “here’s a new program for you to run.”


The consequences of poor security are not always easy to anticipate. For example a wireless temperature sensor or thermostat might seem like a product with little need for security. But consider the consequences to product sales due to a newspaper headline describing how criminals used a radio to detect the “vacation” setting on the thermostat, and robbed those houses while the owners were gone. The safest course is to encrypt all data.

In the early days of ZigBee, most networks were run with no security. As a result, in a multi-vendor interoperability demonstration in front of many potential customers, a number of ZigBee networks failed dramatically because they interpreted a command from a different network to be a coordinator realignment message, which told them to change channels. There was no way for the ZigBee networks to determine that the messages were coming from a device that was not in their network. This disastrous behaviour was not the result of an actual attack, but rather a lack of authentication, which led to interpretation of packets from a completely different network.

In industrial process automation, the consequences of an attack may be much more dire than the loss of a customer. If faulty process control information is delivered to the control system, an attacker could cause physical damage. For example, a sensor feeding data to a motor or valve controller indicating that the motor speed or tank level is too low could result in a catastrophic failure, similar to what was contrived to happen to the centrifuges in the Stuxnet attack. [Reference 1]

On a purely practical level, even a failed attack or an academic revelation of a potential weakness is likely to lead to a loss of sales, urgent engineering effort, and a major public relations challenge.

next; security tools...