The proliferation of connected systems is offering huge advantages to individuals and businesses the world over. Formidable cost savings are possible in terms of time efficiencies and additional features. Consider, for example, a utility company that is now able to connect to electric meters over the Internet. Think how many person-hours will be saved when, instead of sending a reader to check on individual meters, a management center can connect to a large number of meters and collect billing information instantly.

Usually, when designing an application such as meter checking, networking code is verified and tested for proper operation within a well-defined test environment. Testing often includes interoperability with numerous other products using well-behaved and friendly software that has been verified to comply with the networking protocol specifications. But many businesses find that while such embedded systems operate flawlessly in the test lab, unexpected problems arise after deployment on the Internet. When the tested system is connected to the Internet, software for which it has not been tested is likely to communicate with the system. There is no guarantee that such software will behave properly. In fact, the system could connect with hostile software written specifically to launch break-in, denial-of-service and buffer-overflow attacks.

Many systems are neither designed nor tested to withstand such attacks over the Internet, and the attacks may occur regardless of whether the system is using proprietary protocols or standardized ones such as HTTP. Attacks can also be launched at various levels of the communication software stack: the network level (IP), the transport level (TCP) and even the application level, through application protocols such as HTTP and proprietary protocols.

While an attack may be mounted against a specific target, such as a government operation or a specific corporation, attackers often start out by scanning a network to see what addresses might be vulnerable. In our electric meter example, hackers may simply be looking to create mayhem with any organization rather than specifically targeting a utility company.

Attack software is designed to exploit limitations in a system's code, such as poor handling of illegal messages (messages that do not follow the system's specification). Of course it would be formidably expensive and unrealistic for most companies to test software against every possible form of attack. The number of test cases-or the number of variations of illegal messages-is huge. Adding to the complications is the increasingly popular usage of third-party software components, often called middleware. Purchased software- such as Web servers and middleware in the form of Corba, for instance-is expected to be robust, but that is not always the case; and testing of third-party software is beyond the scope of most software projects. While it is impossible for test engineers to come up with the thousands of potential attacks that might breach a system's security, the Internet Engineering Task Force (IETF) offers a powerful solution with its Internet Protocol Secure (IPsec) protocol.

The best way to ensure that real-world operation will be the same as it is in the test environment is to control what software is allowed to communicate with a particular system. This can be achieved by using the IPsec protocol standardized by the IETF and integrated into the TCP/IP stack.

IPsec is applied at the IP layer; consequently, all higher-level protocols are protected (TCP, HTTP, proprietary application protocols, etc.). This means that designers do not have to modify their applications for security considerations.

IPsec is already a popular security protocol and is even a requirement in IPv6. The protocol is most well-known for encryption, yet it provides several additional security services, including authentication, integrity and replay protection. In this discussion, we will focus on the authentication service, which offers a less-common approach to security.

Two hosts that communicate using the IPsec protocol's authentication service will have a shared secret key. Authentication checks are made based on this secret key, and a host that does not have a valid key will not be able to generate messages that can pass the receiver's authentication check.

Working with IPsec, designers can ensure that communication from hostile hosts is prevented by configuring the system to drop all packets that are not IPsec-protected. Only legitimate hosts will be able to send packets to the system, since they will be the only ones with valid shared secret keys. Such a configuration will make the embedded system invisible to outsiders on the network. The system will be running in stealth mode; it will not even answer Internet Control Message Protocol echo requests (pings) from hosts that cannot send valid IPsec packets.

Using IPsec in this manner allows control over which software will be used to communicate with the embedded system. Thus the real-world operation will be the same as the test lab operation, and attackers will be shut out. In the example of the electric utility that needs to check meters, nobody but the management host will be able to communicate with the meters, and only the meters will be able to communicate with the management host. Any application used to gather data, calculate billings or achieve any number of other functions (verify proper operation, flag problems, etc.) will run above the IP layer and will be protected by the IPsec authentication service. As long as the implementation has ensured that non-IPsec packets are dropped, the IPsec protocol alone will be enough to ensure security as the application is deployed over the Internet.

At this point it's logical to ask, what prevents an attacker from using hostile IPsec software, and how can we be sure that the IPsec software communicating with our system is the same that was used in the test configuration? Haven't we only moved the problem to the IPsec code?

Yes, the problem has been moved to the IPsec code, and this is exactly the point. The IPsec protocol is standard technology that can be purchased, often as an integrated part of a TCP/IP stack. It requires only purchasing the right TCP/IP stack, and entering a key. However, the implementation must be extensively tested against attacks and illegal messages. This is feasible for two primary reasons: First, the IPsec protocol has been designed with robustness in mind, which makes testing simpler than it would be with many other protocols. Second, because IPsec is a standardized protocol, it will be used with many applications around the world. The investment in design and testing can be shared among many applications and many partner companies.

In addition to the authentication capabilities described here, IPsec can also encrypt packets, verify that packets have not been modified in transit and check that packets are not replayed. These are all worthwhile advantages when building secure code for Internet-connected systems.

Roger Boden is chief technology officer at Interpeak AB (Stockholm, Sweden).

See related chart