This is probably Question #1 an engineer might ask when faced with security as a requirement for an embedded systems application.

Unfortunately, there are a large number of "security packages" available, and an embedded engineer new to security may only know of security as encryption or virus protection. While encryption is a tool used for security and virus scanners technically provide security, neither one likely provides what is needed.

Fortunately, these days security is integrated into many applications and the packages you need are usually dictated by what your application will interface with. If your application is Web-based, it probably will use SSL/TLS (Secure Sockets Layer, also known as Transport Layer Security).

Other applications use technologies like IPSEC (Internet Protocol Security) or CCMP (WPA2 Wi-Fi encryption). Knowing what the acronyms mean isn't as important as knowing which protocols you need to support. Once you know what you need to support, then you can go shopping.

Figure 1: Common applications and potential security solutions

Obvious Questions
Question #2: How do I implement a security package for my application? Depending on the application, this may be as simple as running an executable with security enabled. For example, if you are running embedded Linux or Windows CE, there are probably applications that provide a lot of the security you need, like an SSH (Secure Shell) client. If binaries aren't available, then there may be source code available.

Open-source packages like OpenSSL and OpenSSH are considered among the best implementations of those security protocols available and the best part is that they are free to use. Avoid implementing your own security protocol. Unless you are a cryptography expert, chances are your implementation will be vulnerable.

Question #3: How secure is my system? Once you have implemented your application and added in all of your security protocols, it is natural to ask how secure the result is. This is where you need to start thinking like a criminal, or hire someone who does (though hiring actual criminals is not recommended).

Anything that can be exploited by an attacker will be if the gain is significant enough. The purpose of security is to make the cost of breaking the security greater than the value of the gain for the attacker. Modern cryptography relies on mathematics that would take thousands of years to work out using modern computer hardware.

Unfortunately, any protocol or algorithm out there may have an undiscovered vulnerability that makes breaking it much easier, and hardware performance continues to improve at a fantastic pace, bringing that "thousands of years" number down significantly.

The remaining questions address some of these issues and hopefully give some insight into how to evaluate and deploy secure embedded applications.

Non-Obvious questions
Question #4: Where is the application going to be deployed? For an embedded system, location is as important as any other factor in determining what security measures are needed. Many embedded applications may be installed in places where an attacker has unfettered access to the hardware.

When an attacker has physical access, software-based security mechanisms fail, and hardware mechanisms don't fare much better. If you are implementing world-class security in your application, make sure the physical security employed is at least equivalent to the security in the application.

Question #5: Who are the potential attackers? To come up with a list of potential attackers, think about everyone who would benefit from compromising your system. This might include business rivals, terrorists, secret illegal government agencies, or bored teenagers.

The people who stand to benefit the most from attacking your system are usually the most likely to attack it, but the attacker may not be interested in what you are most concerned about, which leads us to our next question.

Question #6: What information is most valuable to attackers? (Hint: it might not be what you think it is) This is kind of a trick question, because an attacker may not even be after information. It may be sufficient to shut down your application, as would be the case if a disgruntled customer could turn off his network-enabled electric meter to get free electricity.

In other cases, the attacker may just be interested in controlling the hardware. Already we see PCs being hijacked and turned into zombies that flood victims' web sites with traffic or shut down entire systems with loads of emails " and the attackers can make money doing it. As more and more devices are networked, it is highly likely that someone will see those devices as a huge pool of hardware resources ripe for exploitation.

Question #7: How is wireless network security different from wired network security? Wireless networks add a layer of vulnerability beyond that found in a wired network " the physical transmission medium.

For a wired network, the transmission medium is a wire. Wire-tapping to eavesdrop on communications requires physical contact with the wire or close physical proximity. Wires can be routed through secure buildings, underground, on top of telephone poles, or through concrete, thus limiting the physical contact possible.

With a wireless network, the transmission medium is the air. With a wireless device broadcasting information in all directions, an attacker needs only an antenna to gain access. For this reason, most wireless protocols employ some type of built-in encryption.

Figure 2: Wired versus wireless security

Question #8: Can the hardware or software I choose affect security? Some systems are going to be more secure by default, either due to higher quality software or through specific security enhancements.

Check with others who have deployed the systems you are evaluating and try to find out what applications they have been used in before. Look for hardware security features that have proven records just as you would when choosing a software security protocol for your application.

Question #9: What are the known attacks against the security technology I am using? If you need high security for your application, keeping up with security news is vital. Every day, thousands of hackers and researchers are working to break security.

Those that do their jobs well become famous (or infamous), so there is plenty of incentive to derive new attacks against existing systems. Make sure that you know the current state of your security technologies by learning all the known attacks, and keep up with the reports to be sure that no new attacks have been discovered.

Question #10: Does my system really need the highest levels of security? This final question presents a different way of thinking about security. It is very easy to fall into the philosophy that you need absolutely the best, most robust, most powerful security available, but the truth is that you probably don't need that much.

As an example, think about the electricity metering example " do you really care if anyone can eavesdrop and look at data being sent out from the meter?

With existing meters, all someone has to do is walk up and look at the dial, so it probably doesn't matter if you have the highest level of encryption for the networked version. You are mostly concerned that the information is collected properly and delivered without being tampered with.

There are less expensive methods to achieve that result without resorting to comprehensive security implementations. When evaluating security for your application, think about how much security is really needed " you can save a lot of hardware cost and development time by avoiding security you don't need.

Timothy Stapko is lead software engineer for Digi International www.digi.com with focus on the Rabbit line of embedded products. Stapko has more than 8 years software industry experience and is the author of Practical Embedded Security.