July 01, 2008
In the embedded world, it is not always clear what is meant by "secure."
While preparing for this month's special feature on security, I had the opportunity to talk to Benjamin Jun, vice president of technology for Cryptography Research, a company that specializes in solving complex data security problems. He asserts that embedded designers know that security is important; however, in the embedded world, it is not always clear what is meant by "secure." The amount of effort required to make systems secure varies depending on the particular threat risk.
Jun points out that there are three levels of security with escalating degrees of importance:
- Application security refers to applications authorized to run on specific devices. We see this on our PCs when we are requested to enter a key code that enables the application license. This can also be observed on wireless mobile devices, which require authorization to run on networks such as Verizon or T-Mobile.
- Operating platform security is built into the device to prohibit malware from running. Organizations such as the Trusted Computing Group provide guidance on how to implement this level of security, and many embedded processor suppliers incorporate these safeguards in their products. For example, Intel has Trusted Execution Technology, ARM has TrustZone, and the list continues.
- Tamper resistance offers additional safeguards, usually in the form of tamper-resistant hardware that prevents unauthorized access and cloning. Service providers such as cable companies typically subsidize tamper resistance to protect access to their content. Jun remarks that interest in this level of security is increasing noticeably.
To improve security in embedded devices, Jun recommends that designers consider the following guidelines:
- Look at your protocols for exchanging keys and certificates. Keys enable something to happen, but software does not have access to them.
- Develop a strong specification for how the device should manage risk and the security steps that should be taken. Most security problems develop because someone used the wrong security tools or did not clearly specify how exchanges should take place at the junction between systems, where many security attacks occur.
- Implement a recovery mechanism if possible so that devices can be updated with the latest security patches. Devices become more susceptible to intrusions over time and cannot always readily update with new security patches.
Jun has received feedback from embedded developers indicating that they are primarily worried about providing a safe and secure boot environment for their devices as well as safe and secure compartments to protect code. During the boot process, they don‚Äôt want software modifying the device‚Äôs original intent; the code must be verifiable before the processor begins executing. Developers previously built their own solutions until now, as tools to accomplish this are becoming commercially available. Trust zones are the most widely used method today due to cost.
Hypervisors and virtualization techniques, which enable small compartments to operate with very safe and secure code, are starting to become common. Most operating system suppliers have some mechanism to provide secure virtualization. It is expected that many new devices deployed in coming months will include security schemes leveraging hypervisors or virtualization.
Jun reinforces the reality that security is a continuum and encourages designers to understand the requirements and changes that might impact security. Designers must be able to adapt to changing conditions and advancements made in security technology.
And just when you might be starting to feel secure, along come companies like InfoGard (www.infogard.com) that can conduct simple and differential power analysis (SPA and DPA) on your electronic devices and make power measurements to generate usage models. Monitoring reveals software loops that can make it possible to clone the device and breach its security protection. Fortunately for us, InfoGard works with device builders to find these power patterns and recommends ways that the device can be modified to make it more secure.
Feel free to share your thoughts through e-mail or visit our blog at www.embedded-computing.com to add your comments.
Jerry Gipper, Editorial Director