Wireless Sensor Networks: Security Requirements

1. Security Requirements

As mentioned in the previous articles (Introduction and Limitations), sensor networks are used in a number of domains that handle sensitive information. Due to this, there are many considerations that should be investigated and are related with protecting sensitive information traveling between nodes (which are either sensor nodes or the base station) from been disclosure to unauthorized third parties.

The scope of this article is to analyze basic security concepts before moving into a detail discussion of the various security issues. It is essential to first understand the security requirements that are raised in a sensor environment; by doing so, we could apply appropriate security techniques to ensure the protection and safety of data and systems involved in a more spherical approach. By knowing what we are trying to protect, we could develop a comprehensive and strong security approach to overcome possible security breaches; after all, in order to protect something you must first know that is in danger. Since sensor networks are still a developing technology. Researchers and developers agree that their efforts should be concentrated in developing and integrating security from the initial phases of sensor applications development; by doing so, they hope to provide a stronger and complete protection against illegal activities maintaining at the same time the stability of the system, rather than adding on security functionality after the application is finished.

Moving on, next section analyzes the security requirements that constitute fundamental objectives based on which every sensor application should adhere in order to guarantee an appropriate level of security.

1.1 Confidentiality

Confidentiality requirement is needed to ensure that sensitive information is well protected and not revealed to unauthorized third parties.

The confidentiality objective is required in sensors’ environment to protect information traveling between the sensor nodes of the network or between the sensors and the base station from disclosure, since an adversary having the appropriate equipment may eavesdrop on the communication. By eavesdropping, the adversary could overhear critical information such as sensing data and routing information. Based on the sensitivity of the data stolen, an adversary may cause severe damage since he can use the sensing data for many illegal purposes i.e. sabotage, blackmail. For example, competitors may use the data to produce a better product i.e. safety monitoring sensor application. Furthermore, by stealing routing information the adversary could introduce his own malicious nodes into the network in an attempt to overhear the entire communication.

If we consider eavesdropping to be a network level threat, then a local level threat could be a compromised node that an adversary has in his possession. Compromised nodes are a big threat to confidentiality objective since the adversary could steal critical data stored on nodes such as cryptographic keys that are used to encrypt the communication.

THE FUTURE OF SENSOR NETWORKS

From thermostats in building automation to computer numerical controls in factory automation, device and sensor information is traveling over the same technology that is powering our e-world. But how well is it working, and where is the trend taking us?

Mark Fondl, ICT and Lynn Linse, Lantronix, Inc.

The volume of data carried on a network increases as the devices on it become more sophisticated. Low-end devices may transmit data in 1 bit increments, indicating a simple on/off condition. High-end sensors, on the other hand, contain local intelligence and transmit complex data types measured in bytes (see Figure 1.)

To meet the need for more complex data communications, the industry has looked to other networks. In the process, many have asked: Can Ethernet/TCP/IP be used to replace some of these networks? Can some of the networks be integrated into higher level Ethernet architectures (e.g., DeviceNet over Ethernet, Interbus-S over Ethernet, LonWorks over Ethernet)? Some of the answers to these questions can be found in an examination of implementation costs, ease of use, performance, and vendor support.

Implemention Costs

Ethernet costs are not inherently lower than the other networks. For the foreseeable future, cost can be justified only by concentrating multiple sensors on one Ethernet interface.

Other factors contributing to the cost of implementation are the CPU resources. Here, Ethernet does not compare favorably with an architecture such as DeviceNet. For example, DeviceNet can run on a CPU with 4000 bytes of code and 176 bytes of RAM. Ethernet, though, requires a minimum of 64,000 bytes of code and 64,000 bytes of RAM. Here, many implementers insist the minimum is more like 256 KB each, but they would prefer 2–4 MB of code and RAM. If the volumes are low and the margins are high, the simpler software offsets Ethernet’s greater CPU requirements. But as volumes rise and margins shrink, the lower resource needs of something like DeviceNet will force a price premium for Ethernet with the same sales volumes.

Consideration of connection costs—especially for bit-level sensors in industrial environments—causes some to favor ASI and DeviceNet wiring. Optimized for machines in which many discrete sensors are located in a relatively small area (50 m), these sensor networks are ideal. But extending their range poses some difficulty, and based on response times of these clusters, bridging with Ethernet may provide value.

Ease of Use

Here the focus is on long-term support of software configuration. This has multiple facets:

TCP/IP ease of use is based on the wide availability of skilled technicians and tools.
But TCP/IP (at the moment) lacks the high-level standards that allow auto-replacement, which is supported in DeviceNet and ASI.
The complexity of the options found in TCP/IP can overwhelm inexperienced users.
Systems such as DeviceNet and ASI are well suited for applications in which the communications are kept on a local scale. But when the data travel into extended areas and applications in which specialized network skills are required, then a commercial TCû/IP network becomes attractive. Network evaluation can be as simple as a “ping” from almost any computer. Commercial technologies aimed at simple diagnostics will eventually become common. Training individuals to support TCP/IP will be much easier. Device networks feeling this pressure will undoubtedly develop simpler and even browser-based tools.

Performance

With a well-designed network, TCP/IP will perform quite well. But the network must be well designed. An isolated subnet with limited or master/slave functions can expect reliable 2–5 ms times. But the instant you add routers or other noncontrol traffic (including Web servers), you can expect delays of 500 ms or more. So Ethernet performs only as well as the user designs it to perform.

A sparsely designed Ethernet, which underuses its capacity, can rival or beat any deterministic control network. But a poorly designed Ethernet can be an operational nightmare.

Web access via TCP/IP is a common unrealistic hope. With control traffic running at 5–10,000 Bps, users often overlook the fact that a Web page can attempt to force millions of bytes of data through a network at the same time that control data are being transmitted, dwarfing the control traffic. Users and vendors still have to learn the tradeoffs here. Some Web access is wonderful, but this needs to be shared/supplemented with Web resources stored off the control network.

To improve performance on the sensor level, automation companies are experimenting with UDP and variations of limited TCP/IP stacks. These stacks listen only to certain types of transmissions, ignoring others and eliminating a retry structure for a high-speed master-slave structure. This is similar to how I/O has worked for years with PLCs. The architecture and wiring are Ethernet, but the openness is traded for performance.

Most systems don’t need this level of performance and should stay with standard Ethernet. As the technology continues to improve, you can imagine a time when a conventional approach will surpass proprietary methods.

Service and Support
Support for Ethernet TCP/IP systems is good, but the actual media (e.g., cables, connectors, and power) are rather unindustrial. Many TCP/IP experts have an IT mentality, not a plant-floor mindset, so they misunderstand what users want or modify existing systems in ways that hurt the industrial user in an effort to improve the system according to other criteria.

«o users still need to learn about the technology and watch over the shoulders of the experts. Ask questions, and make sure the IT experts learn how you view the problem.

Openness

Ethernet TCP/IP systems provide an open network platform, but high-level application standards are still in flux. TCP/IP is often viewed as a false open standard because its higher layers are proprietary. Modbus/TCP and some of the new encapsulations of òeviceNet, Foundation Fieldbus, and Profibus will help in this area by providing interfaces that will allow different protocols to communicate with each other. But that still leaves a lot of application standards that are not interoperable.

Many of these network architectures encapsulate other protocols, but the interoperability does not extend to the physical and transport layers. This prevents the various buses from communicating with each other. So there is still a great deal of work to be done in this area.

Flexibility

Just about anything is possible with global TCP/IP, but the reliability of its performance depends on the skill of the implementer. However, there is still a need for a more industrial and optimized sensor bus.

As data requirements increase, hybrid and direct Ethernet systems will become commonplace. High-level sensors with serial ports are already being linked over Ethernet. The protocols are transported transparently on top of TCP/IP and delivered to a host, which in some cases is unaware that they were carried over a LAN.