Security for Wireless Networks

Security in Wireless Sensor Networks

Despite their ubiquity, security and networking technologies for sensors and other smart objects are still very much in their infancy, and there is tremendous technical and market opportunity in this arena.


  • Page 1 of 1
    Bookmark and Share

Devices and “smart objects” like industrial sensors are rapidly outnumbering workstations on networks worldwide, with some experts projecting that within 5 years there will be over 100 non-PC devices for every workstation on a network. Some devices, like sophisticated printers or routers, are relatively “intelligent” and have comparatively ample memory, processing and bandwidth resources at their disposal. As such, we can usually apply some of the security techniques originally developed for networks of PCs directly to the new “citizens” on the network. But at the very low end, devices like environmental sensors often present a unique challenge because of the extreme resource constraints they impose on security architects.

Industrial control systems have relied on smart objects like sensors and actuators for years to interact with and oversee factory processes. A typical system consists of battery-powered sensors that send information to a smarter, wired control device. Today’s sensors are tiny, inexpensive to manufacture, and don’t need a lot of power—an essential characteristic, since many sensors are expected to operate long-term without access to line power. Most wireless objects get their power from batteries, but interesting new classes of devices are emerging that scavenge electricity directly from the environment.

Computational and communication resources in sensors can be quite limited; just a few megahertz of CPU power paired with several hundred Kbytes of RAM and EEPROM are typical. Most modern sensors utilize radio frequencies to communicate, though optical and infrared communications are also sometimes used, but are less common because of the line-of-sight requirement. Bluetooth might seem like a natural for these networks, but is rarely used because of its relatively greedy power requirements.

Wireless Networks of Sensors

Some smart objects, like sensors, are typically scattered to cover a specific area of interest. While the range of each object, or node, is limited by its radio transmitter, we generally assume that each node can contact any other, though they may have to rely on nearby nodes to relay their communications to the target. The nodes send data to a “sink” or base station. These centralized stations are systems comparatively rich in CPU and storage resources, and are often used to stage and transmit information to larger IP-based networks, including the Internet.

There are a few important factors we always need to keep in mind when working with these networks. First, global addressing systems usually aren’t possible—so we need to be data-centric. Second, power is very scarce, and we often can’t get more if we need it. Transmitting data can consume 1000x more power than processing it, on a per-bit basis. Furthermore, we can’t assume that we know exactly where any given node is at any given time, and sensor networks are often “infrastructureless” which means they need to work in a distributed manner, or not at all. Finally, we certainly can’t depend on any of our objects to be tamper-proof or use any kind of “trusted” computing platform since these characteristics often make the individual nodes prohibitively expensive.

Sensor Network Security

Security requirements often vary with application and context, but in general, security for wireless sensor networks should focus on the protection of the data itself and the network connections between the nodes. Confidentiality, integrity and authentication are the most important data security concerns. When considering the network itself, we need to protect fair access to communications channels (or media access control) and we often need to conceal the physical location of our nodes. We must defend against malicious resource consumption, denial of service, node capturing and node injection. Sometimes our applications require secure routing to guard the network from the effects of nodes “gone bad.” Finally, we need some mechanism for protecting the mobile code itself.

Because distributed control networks like these tend to be extremely vulnerable to simple node attacks, weaknesses in a subsystem can easily be exploited to mount attacks on the whole network, even beyond the “sink.” So it is crucial to design sensor networks with security in mind from the very beginning, not as an add-on feature of the system. That’s largely because security will almost always add some overhead, which means increased power requirements—something that’s difficult to shoehorn in to an already-designed system. Tight integration of security techniques in processing and communications simply allows for more efficient use of scarce resources.

Key Management in Sensor Networks

Key management is usually named as the primary obstacle to true security for sensor networks. In other words, the defining characteristics of wireless sensor networks conspire to make it difficult for two nodes to securely share a secret key, a basic requirement of encrypted communications.

The nodes in these networks can’t rely on a central security infrastructure like a Kerberos server. The best-practices method for key management on the Internet—RSA, or Diffie-Hellman-based public key cryptography—is often prohibitively expensive for sensor networks, at least in terms of processing, storage and communications requirements. Key management based on elliptic curve cryptography may offer a solution, but as of yet there is no consensus on standards for its use in sensors.

What are our other options? Well, we could preload a single secret key onto all of the nodes…but the capture of a single node would then compromise the entire network. Another approach is to preload that single key, then establish “link keys” unique to every pair of nodes based on the original secret key. Then destroy that original secret key. Unfortunately, this scheme gets unwieldy for even medium-sized networks, and rules out the addition of new nodes after the initial network setup—usually a deal-breaker.

We could leverage a trusted base station to establish link keys with each node, but this is difficult to implement in many sensor networks because it requires time synchronization across nodes. Then, of course, the trusted base station becomes a single point of failure for the entire network—a definite no-no in security architecture.

Random key predistribution protocols show some promise in the literature. In these schemes, a random subset of a large pool of keys is preinstalled in each object. If the key set is large enough, then every node can establish connections with at least a few others and thereby patch together a secure network containing all objects. The downsides to this approach include a requirement for a trusted base station, and tamper-resistant hardware in each node to conceal the keys—usually another deal-breaker.

The fact is: there’s no easy answer for key management in sensor networks. Sensors are always getting smarter and more capable, and companies like Mocana work hard to super-optimize cryptographic implementations so that device designers can leverage public key techniques for key management. On the other hand though, “there’s always room at the bottom” and someone will always need a device that’s smaller and less power-hungry than the last-best design. For those cases, some additional security risk will have to be incurred using one of the compromise key management techniques listed above.

Sensor Hardware and Software

Sensors have a triple role in most networks; they act as data collectors, processors and as traffic forwarders for other objects in the network. When public key management isn’t an option, the most common approach is to periodically disseminate fresh keys to nodes, and accept the risk that those keys might be intercepted during dissemination. But there are still environments where persistent keys need to be present in the objects to decide whether or not a node can “play” on the network. Unfortunately, a malicious user could paralyze these networks by either capturing a single object (node) and extracting the secret keys or by modifying the networking code of a captured object.

Tamper-resistant hardware could mitigate these concerns (to protect keys and routing functions) but at significant added expense. For these reasons, many security functions on sensors are relegated to software.

Consider too that tamper-resistant devices can’t be updated or patched dynamically. On the other hand, dynamic software update capability comes at a security cost. A hacker could inject code into the network and initiate a denial-of-service attack, or force a sensor to exhaust its battery by tricking it into performing useless computations or radio transmissions. Given the homogeneity of code across many sensor networks—for example, among clouds of thousands of tiny sensor nodes—such attacks can be disastrous.

Protecting code update dissemination is therefore essential. Again, if capabilities permit, public key mechanisms provide best-practices protections (e.g., code signing). But other options exist. An encryption mechanism with locally shared secret keys (group keys) can ensure that a particular code update originates from an already-trusted set of objects. Code distribution algorithms can themselves be hijacked for malicious purposes, but new techniques like CPA and DPA can mitigate these concerns. However, the same mechanisms can be used to propagate a new, malicious code distribution technique as well.

Device-based “micro intrusion detection systems” could be one answer. Under Mocana’s NanoDefender system, when a new application is compiled, NanoDefender performs a static analysis of the code to determine the call flow of the executable. The system determines which functions call which functions, and which functions make which system calls. Later, at link time, the executable is instrumented to track function calls. Finally, at runtime, the code and the modified OS together enforce the proper call flow. Such a system (if the sensor has sufficient resources to run it) can virtually eliminate the threats of arbitrary code execution and malware injection.

Routing Security in Sensor Networks

The biggest problem for wireless networks of sensors is that of network operational security. In other words, the problem involves a hierarchical organization of nodes in networks and the secure connectivity between sensor nodes and base stations. The functions that we’re looking for include confidentiality, secure routing, detection of bad behavior among nodes, and the ability to “excommunicate” naughty nodes from the network.

On the Internet and other infrastructure networks, there is a clear separation of roles: there are end systems (nodes) and intermediate systems (routers, switches and the like). But in sensor networks each node is potentially a router for some other nodes. This creates an entirely new set of vulnerabilities in the network layer. For example, routers can become “neglectful,” in that they selectively do not forward packets from other nodes, or they can become “selfish,” in the sense that they prefer to give preference to their own packets. Such behaviors are often the result of denial-of-service attacks.

Wireless sensor networks have a lot in common with wireless ad hoc networks, but many of the security mechanisms designed for ad hoc networks simply won’t fly on networks of sensors. Unlike in ad hoc networks, not every pair of nodes in a sensor network needs to communicate. Also, in ad hoc networks many security mechanisms usually rely on public key algorithms, which are sometimes too expensive in terms of resources for sensor networks. We could attempt to adapt a secure routing protocol based on secret-key cryptography, but it would impose non-trivial packet overheads in addition to necessitating the gathering of node state information.

Routing misdirection is an attack whereby malicious nodes advertise false routes to either inject artificial traffic into the channel, direct traffic to a fraudulent base station or node, eliminate part of the network by overtaxing its resources or avoid forwarding packets entirely. Such an attack can be foiled using authentication, network monitoring and redundancy techniques. Authentication mechanisms based on distributed certification authorities have been proposed, but these have been shown to be tough to implement in real-world environments.

Some network monitor applications can have neighbor nodes listen to both the sender and forwarder of a message, and notify the sender if the exact packet is not forwarded to the next hop of the route within a specific time limit. Unfortunately, packet comparison is not enough, since aggregation points may delay transmissions until enough information has been collected. Even if the time threshold is long enough, aggregated data will probably not match transmitted data. This will result in mischaracterizing the aggregation node as a “bad actor.”

Battery Attacks

Attacks targeting the battery exhaustion of nodes are termed attacks on “system lifetime.” Why would an attacker bother? Suppose, for example, a sensor network is deployed as an early-warning system for biological or chemical attacks. Because of the widely distributed nature of the sensor network, it would be almost impossible for a terrorist to physically destroy it. An easier option would perhaps be to insert a few misbehaving nodes that force the legitimate sensors to work continuously until their batteries are totally exhausted. Then the terrorist could proceed with his real-world attack, undetected.

There is a difficult trade-off in the case of sensor networks. These devices have a triple role: as data collectors, processors and forwarders. The goal of the network is to be working as long as possible, in order to transfer information from the objects to the sinks. But the objects “want” to participate in the network as little as possible, in order to stay active for a longer lifetime.

This creates conflict for the node, and sets the stage for battery attacks. Selfish behavior and “unfairness” in cooperative protocols can be considered weak forms of denial-of-service attacks, and there are many others more advanced such as sleep deprivation attacks. Link layer protocols for channel arbitration can even be manipulated to exhaust batteries or simply degrade network performance. For example, channel jamming results in transmission errors, which make nodes retransmit data and increase transmission power to overcome noise. Another form of attack is interrogation. A selfish node may continuously request channel reservation. In cooperative MAC protocols, like those based on IEEE 802.11, neighbor nodes are forced to reply to those requests and thus eventually consume all their energy reserves.

Most, if not all of the problems in current approaches to securing networks of smart objects arise from the fact that security has been designed as an add-on, not as an integral part of the network architecture. The resource constraints common to wireless sensor networks often deprive the security architect of one of our favorite tools: public key cryptography. Fortunately, even the “lowest” modern sensors are getting better processors and more memory, enabling them to “speak IP” and participate in the global public key infrastructure. Good work, too, has been done on optimizing and miniaturizing public key algorithms, and elliptic curve approaches can sometimes work well. When memory is just too tight, or processors just too weak, however, clever work-arounds and hard compromises are needed.

San Francisco. CA.
(415) 617-0055.