Getting security right in wireless sensor networks
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…
Fortunately, there are very powerful tools for building secure, robust wireless communications networks. It takes diligence and attention to detail, but there is nothing fundamentally hard about it.
Ciphers and Nonces
The most basic cryptographic tool is the block cipher. As an example, AES-128 is a particular block cipher that takes a 16-byte message (the plaintext) together with a 128-bit key, and generates a 16-byte encrypted version of the message (the ciphertext). Anyone with the same key can decrypt the ciphertext to get back the plain text. Anyone without the key cannot get back the plain text. The AES cipher is easy to implement in software, and commonly available in hardware on many radio and microprocessor chips. As far as anyone knows, AES-128 is unbreakable–given the ciphertext, there is absolutely no way to figure out the plain text without the key. Indeed, this cipher was chosen by the US National Security Agency for encryption of secret documents. In all of the reported attacks on WSN security, no one has ever claimed that the AES cipher provided the weak link.
The only known attack on AES-128 is a so-called “brute force” attack, meaning that the attacker tries every possible key to see which one gives a reasonable message. Trying every possible 128-bit key is a big task. If you had one billion computers, and each computer could check one billion keys every second, and you ran all of those computers for one billion years, you would only try about 0.1% of all of the possible 128-bit keys. There are more than 300 billion billion billion billion different 128-bit keys.
A block cipher lets the source encrypt a message so that only the destination (with the same key) can decrypt it (Figure 1).
Figure 1 A source node uses a block cipher and a nonce and a secret key to encrypt a plain text message, turning it into ciphertext. Only someone in possession of the key can decrypt the message. The nonce may be sent in the clear, or may be implicit from the structure of the protocol, such as a timestamp.
Of course, if the messages are something simple like “turn the light on” or “turn the light off,” then even if the messages are encrypted to seemingly meaningless strings of bits, anyone intercepting a few messages will quickly figure out that there are only two different messages. A solution to this problem is to have a message counter, and number each message sent. Due to the nature of the cipher, any change in the message plain text will result in a different ciphertext, and two messages sent at different times, such as “Msg 1: turn the light on,” and “Msg 53: turn the light on” will look completely different to anyone not in possession of the key. As long as the message counter never repeats, the ciphertext will also never repeat. This concept of a message counter that never repeats is called a nonce, for “number used once.”
Message Integrity Check
The message integrity check, or MIC (also sometimes called a message authentication code or MAC), is a cryptographic checksum of the message. By sequentially running all parts of a message through a block cipher with a particular key, the sender of the message creates a short encrypted summary of the entire message, called the message integrity check. This MIC is then appended to the message and sent along with it. The receiver, using the same key, can then perform the same function on the message, calculate its own MIC, and verify that the result matches the MIC that was received. Any changes to the message, even a single bit, will cause the MIC to change, and therefore cause the message to be rejected by the recipient.
Random Number Generators
A person can generate the encryption keys in a WSN, but this is typically impractical and ultimately insecure, as we will see below. Ideally, we’d ask computers to generate the keys for us. We don’t want anyone to be able to guess the keys, so we’d like them to be random, and that requires a random number generator (RNG). Usually people are happiest with computers when they are completely deterministic, and random behaviour is frowned on. Making a computer truly random is not a trivial task, and always involves interaction with something non-digital. Fortunately, radios are intrinsically non-digital, and it has taken a century of progress from the days of Marconi to get them to the point where they deliver digital messages reliably. Any well-designed WSN system will use the radio or some other source of thermal noise as an integral part of its RNG, and will generate truly random numbers.
Even a legitimately obtained device incorrectly deployed could confuse a control system not expecting an additional input. Access control lists (whitelists, blacklists) provide an additional layer of control to ensure that unwanted devices can’t disrupt a network.
Mistakes – Lack of Understanding of the Problem
The single most common mistake in WSN security is not appreciating the magnitude of the problem until it is too late. Building and deploying a wireless lighting control system without security may not sound like a problem until the local college students start making light shows out of your customers’ office spaces.
Even those who realise that security is important may not appreciate the widespread sophistication, software and hardware tools, and skills that are available and regularly applied on the dark side of this conflict. Several WSN companies tout their channel hopping protocols as having some security benefit, as if an attacker will not be able to buy a multichannel receiver and transmitter. Others seem to think that millions or billions of keys is enough to prevent a successful attack, when in fact even billions of billions is not enough [Reference 2]. If there is the possibility of a brute force attack revealing a key, then a key-rotation schedule that is a small fraction of the brute force time will deter the average attacker, but might not stop a very lucky one.
Shared Keys and Software Reverse Engineering
Assuming that a proper cipher has been chosen, and nonces are used, the simplest system will use a single shared key for all cryptographic operations. This approach is fine as long as the key remains secret, but that is a difficult goal to achieve.
An extreme example is the recently reported vulnerability of a Bluetooth-controlled toilet/bidet combo, in which the default pairing key of all zeros was used [Reference 3]. This is really more an example of “no security” than poor security, but illustrates the point that the best protocols are no defence against poorly chosen keys, or even a random key that becomes widely known on the Internet. Bluetooth has excellent security tools, but if you don’t use them properly they are worthless once someone publishes your ill-advised product-wide key on the web.
The next level up is to have a single unique key for each network that is delivered or installed, or a new key each time a network is formed. If you have a good random number generator, and you control all of the hardware in your network, then this approach is fine. However, if any one node in the network is compromised, then the entire network is open to attack. If users are allowed to write their own software on the nodes in the network, then it is quite difficult to prevent a malicious user from finding the network key.
Even if the node software is closed, it is quite difficult to prevent attackers from reading out the code in a microprocessor if they have possession of the hardware. The security literature is filled with examples of such attacks, which often go like this: obtain a legal version of the hardware and break into it to get the code; reverse engineer the code to figure out where the key is stored (this can be as simple as comparing the code from two different networks to see which bits are different); use this information to either figure out how the key was calculated (see Poor Quality RNG below), or to make it much quicker to get the key out of hardware captured from the actual network under attack.
Digital video disk (DVD) security has fallen victim to such an attack, both with the original DVD Content Scrambling System (CSS), and the HD-DVD/Blu-Ray Advanced Access Content System (AACS). Both were compromised by hackers examining player code and exposing and publishing several of the processing keys protecting that material [Reference 4].
With very rare exceptions, you must assume that a determined attacker will be able to obtain your hardware, read out your code, and reverse-engineer your algorithms and software. As a result, a well-designed security system must not depend on the algorithms and software remaining secret and it must not rely on the key or keys in any one device remaining secret. An attacker in possession of one of the network nodes must be assumed to be able to gain complete control of that node, and in a well-designed system the compromise of a single node must not affect security in the rest of the network.
The simplest solution to this reverse-engineering problem is to ensure that every communication session (or flow of data between two endpoints) has its own unique keys that are unknown to any other nodes in the network. In this case, even a compromised node in the network cannot snoop, manipulate, or impersonate the data or commands from any other node in the network.
next; key distribution…
Assuming that appropriate protocols and ciphers are used, a network with unique random keys for each end-to-end session protects the confidentiality, integrity, and authenticity of network communication (Figure 2).
Figure 2 Most secure WSN systems use two levels of keys: end-to-end session keys and one or more link keys. Each pair of motes with an end-to-end communication channel will have a unique shared key for encryption and authentication. In addition, a link key is used for hop-by-hop authentication.
However, arriving at this situation presents vulnerabilities in some systems. It is usually inconvenient to pre-program every node in the network with all of the unique keys that it will need for all future sessions, so keys need to be distributed after network formation. In some systems, this has been done by sending the initial session keys “in the clear” (not encrypted), under the assumption that the network is then only vulnerable to an attack for a brief period of time during network formation. Unfortunately, an attacker may well be able to set up his snooping equipment and wait patiently for a network reset, or in fact cause a network reset by power cycling the network controller or gateway, or through some other method.
A simple solution to this problem is to install a single unique key on each node in the network at manufacturing time, and have a single trusted security manager in the network, which is given those keys, allowing a secure session between each node and the security manager. The security manager then generates the required keys for all other sessions, and sends them via its secure channels to each of the devices involved. Alternatively, there is another suite of tools using public key infrastructure, which provides similar functionality as well as other benefits [Reference 5].
Poor Quality RNG
Among those who take security seriously, perhaps the single most common mistake is the use of a random number generator with poor randomness. Even with all of the proper protocols and ciphers, the network is only as challenging to attack as the keys are difficult to guess.
Common mistakes here are the use of non-cryptographic random number generators, or cryptographic random number generators with seeds (initial values) that are non-random.
Random numbers are useful in many different applications in computer science, so many operating systems have a “rand()” function built in. For example, the original UNIX rand() function maintained an internal 32-bit state, and computed the next random number and next state based on the current state. A user could seed this RNG with a 32-bit number, and then each call to rand() would generate the next value in a sequence of four billion values. It wasn’t a great RNG, but it was good enough for most non-cryptographic applications. Today, however, it would be a simple homework assignment to generate a table in a single desktop computer that contained all four billion possible random numbers, and their location in the sequence. No amount of randomising the seed will help – the RNG itself is not sufficiently sophisticated.
Cryptographic RNGs use much more internal state – typically at least 128 bits. With 128 bits, as discussed above, even billions of computers operating for billions of years are extremely unlikely to find a pattern in the sequence of numbers. The implementation and test procedures of good cryptographic RNGs are well documented [Reference 6].
Even the best RNG algorithm is only as random as the seed with which it was provided. A common mistake in two WSN security systems was pointed out by [Reference 7], in which they discovered by reverse engineering the software binaries of both products, that they were using a very non-random seed. Both products used the time function (in seconds) as the seed of their random number generator. Since there are only a few tens of millions of seconds per year, even a modest laptop computer can generate all possible keys by a quick search of the last few decades.
next; secure networks…
While the news is full of examples of failed wireless security, the world is filled with wireless networks that are in fact secure. Secure networks just aren’t newsworthy. As discussed above, a secure network requires both a secure protocol, and a secure implementation (Figure 3).
Figure 3 Proper use of well-known security techniques allows reliable delivery of confidential, authentic, unmodified messages from source to destination. Invalid use or attacks are both detected and thwarted.
Some examples of well-designed security protocols in WSNs include the Wireless HART and ISA100.11a industrial automation protocols, and the ZigBee Smart Energy protocols. All of these protocols have undergone extensive review by security experts, and many implementations have sailed through similar review.
In particular, the Wireless HART protocol is the basis of secure networks deployed in critical infrastructure applications all over the world, from the Arctic Circle to the Arabian Desert. End-users of this technology trust WSNs to supply process control information reliably and confidentially between authenticated end-points. Customers in such industries, as well as the vendors who supply them, have confidence in their networks because of deep analysis and testing of the protocols and implementations that underlie them.
In WSNs for industrial process automation, it was understood from the beginning that security was critical, and the protocols and implementations reflect that reality. As new protocols emerge, especially for the Internet of Things, some of the hard lessons will need to be relearned in application environments where it may not be as obvious that security is critical. As the preceding examples above have shown, there are some who have not yet learned these lessons. Fortunately, it is just as easy to provide “industrial quality” security in Internet Protocol (IP) applications as in industrial applications. Examples include SmartMesh IP from Linear Technology, and several of the emerging IP standards.
The consequences of poor security in wireless sensor networks are severe. It is unfortunate that there has not been a serious attempt to secure many products on the market today, or that those that have done so, have failed in that effort. Fortunately, using well-established principles, appropriate protocols and ciphers, and the randomness inherent in the physics of thermal noise, it is possible to build systems that are both secure and efficient. Many such protocols and implementations exist, and there are secure wireless networks all over the world. Everyone in the wireless sensor networking space will benefit when all of the rest of the networks are secure too.
2. Electronic Frontier Foundation, “Cracking DES”, O’Reilly Media, 1998.
7. Lucas Apa, Carlos Hollman, “Compromising Industrial Facilities from 40 miles away,” Blackhat 2013.
Kris Pister is Chief Technologist, and Jonathan Simon, Systems Engineering Director, at Dust Networks Product Group, Linear Technology.
next; Sidebar; Sensors that can be placed “Anywhere”…
Sidebar; Sensors that can be placed “Anywhere”
Ross Yu, Dust Networks
Whether on the surface of a city street to sense available parking spots, or in industrial hazardous locations, the demand for sensor information has never been higher, and new applications require sensors to be placed in locations that were previously thought to be impractical. In order to place a sensor anywhere data needs to be collected, sensors must be truly wireless—both for communications and power. Since sensors need to be placed optimally for data collection, and not necessarily optimally for RF communications, the devices must be able to communicate both reliably and securely if wireless sensor networks are to continue to gain acceptance and to be used ubiquitously.
SmartMesh embedded wireless mesh sensor networks, from Linear Technology’s Dust Networks product line are successfully deployed by end users in some of the toughest RF environments, including industrial process plants, data centres, smart parking applications, railcars, and mining (Figure 1).
Figure A: Streetline has deployed SmartMesh wireless mesh networks from the Dust Networks product line to improve parking in such cities as Hollywood, California.
Built on the Linear’s ultralow power, LTC5800 802.15.4 System-on-Chip, SmartMesh networks are embedded systems complete with both hardware and networking software that deliver secure mesh sensor networks with >99.999% data reliability and ultralow power.
Time Synchronised for Low Power
SmartMesh networks communicate using a Time Synchronised Channel Hopping (TSCH) link layer, a technique pioneered by Dust Networks and a foundational building block of wireless mesh networking standards, such as WirelessHART (IEC62591) and IEEE 802.15.4e. In a TSCH network, all motes in the network are synchronised to within a few microseconds, enabling network nodes to sleep at ultralow power between scheduled communications, typically resulting in a duty cycle of < 1%. In a SmartMesh mesh network, wireless nodes, even routing ones, typically consume <50 μA average, enabling multi-year battery life on a pair of lithium AA batteries, or even operation on energy harvested power.
Path and Frequency Diversity for Reliability
Time synchronisation enables channel-hopping on every transmitter-receiver pair for frequency diversity. With a SmartMesh network, every packet exchange channel-hops to avoid inevitable RF interference, and multiple transmissions can occur simultaneously, increasing overall network bandwidth. Each device has redundant paths to overcome communications interruption due to interference, physical obstruction or multipath fading. If a packet transmission fails on one path, a mote will automatically retry on the next available path and a different RF channel (Figure 3).
Figure B. Path and Frequency Diversity – In a SmartMesh wireless network, if communication fails on the “green” arrow, node D retries on the “red” arrow using another channel.
Secure Mesh Solution
SmartMesh networks have several layers of security to address confidentiality (through encryption), integrity (of a message) and authenticity (verifying that a message is from the stated sender). At the link-layer, packets are authenticated at each hop using a Message Integrity Check (MIC) based on a run-time key and a time-based counter. This ensures that only motes that are synchronised and have been admitted into the network by the manager can send messages. Additionally, packets are authenticated and encrypted end-to-end using run-time session keys and a shared counter. This ensures that only the intended recipient will understand the message (data privacy), and that replays, data corruption, or man-in-the-middle attacks can be avoided (data security). SmartMesh’s 128-bit AES cipher has been certified to U.S. NIST Advanced Encryption Standard, FIPS-197. Encryption keys are generated using a true thermal random noise generator, as measured in the LTC5800 RF front-end with the antenna disconnected. This serves as the entropy source to seed a cryptographic random number generator (Table 1).
Choose from three increasingly strong levels of device authentication with the use of Access Control Lists (ACLs)
128-bit AES-based encryption (NIST FIPS-197 certified) with multiple keys ensures privacy and confidentiality of the data
Thermal Random Noise Generator
Uses thermal noise as measured in the LTC5800 as the entropy source
Message Integrity Check (MIC)
Data transmitted is protected by message authentication codes to ensure that it has not been tampered with
Synchronised Key Changeovers
The entire network can be programmed to change over to a new encryption key automatically
Customized Key Rotation
The customer decides how often the network should change keys, balancing extra security with additional network traffic
Ross Yu is Product Marketing Manager, Dust Networks Product Group, Linear Technology.