These days, security is being built into embedded applications at all levels, including the hardware. However, the wide range of encryption applications, standards, and protocols makes it difficult at best to create a universal platform. The tables on common encryption standards (Table 1) and common encrypted protocols (Table 2) give just a clue of the options available.
Hardware can address a host of security issues. For example, AES (Advanced Encryption Standard) encryption acceleration in Rabbit Semiconductor’s Rabbit 4000 can be used with an SSL stack. It speeds the process, but it only provides security for data being transmitted between the 8-bit microcontroller and another network device. It does not guarantee that the information is correct or from a particular source, only that it will move from point A to point B without being tampered with or viewed.
SSL/TLS provides endpoint authentication and encryption, but improper configurations can be susceptible to things like man-in-the-middle attack. Improper use of security software and hardware is the main reason developers need to be aware of its use as well as misuse. Simply putting something in hardware does not mean an approach will be useful in the long run. The SDMI (Secure Digital Music Initiative), a digital rights management (DRM) scheme, used a hardware-based key system to implement a digital watermarking scheme. SDMI was flawed and has since disappeared into the archives of the Internet. It is on par with the Content Scrambling System (CSS) used with DVD movies.
Securing the base SDMI started from the right point with a unique, unalterable key. But normally, this must be surrounded by more hardware to prevent tampering. For many systems where physical security is not an issue, platforms such as the Trusted Computing Group’s TPM (Trusted Platform Module) can provide the basis for a secure system.Initially implemented as separate and secure chips, many TPMs were incorporated into PC motherboards such as IBM laptops. VIA Technologies implemented a version called Padlock that adds features like AES encryption. These types of platforms can support operating- system features such as Vista’s BitLocker, an encrypting file system.
Zilog’s 32-bit ARM922T-based Zatara microcontroller highlights most of the options required for securing a microcontroller, including a secure boot ROM and tamperdetection support (Fig. 1). In particular, there is a 40-kbyte secure RAM that will be zeroed if the tamper-detection circuits are attacked.
Tamper detection is not new. But it is becoming more common and moving up the food chain to larger processors. Most 64-bit processors are mated with external hardware to address this problem, as with a TPM. Yet securing a system from the inside out is critical to a fully secure system.
Still, a system that takes security to extremes may only be required in certain circumstances such as controlling a nuclear reactor or managing large cash transfers. In these cases, the added cost and complexity of the controlling microprocessors are less of an issue.
The softer side of security Software is critical to system security regardless of the base it starts from. Obviously, running secure code from the start is an issue that is best addressed by a hardware solution. But once running, a system needs additional secure software to manage system security.General Software’s Embedded BIOS with StrongFrame is one way to address the underlying software aspects of a system. Its Boot Security Application is a firmware application that establishes trust between the hardware and applications. It was designed to prevent the operation of a system that has been compromised by the unauthorized tampering with the BIOS, operating system, or application. It uses digital signatures to track trusted objects. The 20-kbyte module can be compressed by 50% in ROM. The system can be extended using Firmbase Technology’s Trusted Computing Base (TCB), which supports plug-in Security Authorities allowing custom authentication and authorization.
General Software’s approach targets a range of standard processor architectures and operating systems, while Freescale’s Mocana Device Security Framework is targeted at Freescale processors such as the PowerQUICC series. The PowerQUICC has had an encryption engine almost since its inception because its targets include routers and gateways that provide virtual private network (VPN) support. Hardware encryption significantly improves the throughput of secure information.
Mocana has a range of software products like its Embedded Security Suite. But the Mocana Device Security Framework modules for Freescale processors are designed to integrate this software with the PowerQUICC security engine so developers don’t have to deal with the hardware directly. Modules include support for SSL Server, SSL Client, SSH Server, SSH Client, IPsec/IKEv1 and IKEv2, and Certificate Management Client. Designed for open standards, the system is RFC-compliant and multicore- friendly.
Continued on page 2.
Adding on security Incorporating security acceleration and support into hardware has its advantages, but it is not the only way to do it. Keeping the support outside the microcontroller often is easier or better for a particular application.One simple way to add base security support to any microcontroller with an I2C interface is to use a secure memory product like Atmel’s AT88SC25616C crypto memory (Fig. 2). The security aspects of the system are self-contained, with the authentication occurring inside the chip.
Typically, an application on the host microcontroller acts as a gateway to the secure memory using a key provided by an outside source, such as a user or a remote application. This provides access to memory within the chip that usually will be another key that can be used by the host to perform another secure function, such as authenticating a downloaded update or gaining access to a remote system.
Most secure memories provide this level of support. Atmel also provides a more sophisticated hierarchy with multiple password keys that provide selective access to different memory zones within the chip. Different passwords can provide access to overlapping zones, allowing shared access to information.
Normally, these chips only store additional encryption keys or indices, though small amounts of data can be stored as well. Storing keys enables additional encrypted data to be stored outside of the chip. For example, the keys could be used to decrypt data on a hard disk.
Atmel’s 13.56-MHz RFID CryptoRF operates in the same fashion, except that the chip is accessed via an RFID reader. It has a 64-bit cryptographic engine with dual authentication capability and storage capacity up to 64 kbits.
Larger amounts of storage can be linked to a microcontroller by placing the data on a hard-disk drive like Seagate’s Momentus 5400 FDE.2 (Fig. 3). Secure hard disks provide access to a tremendous amount of storage, but clear (unencrypted) data moves between the host and the drive.
One advantage to placing the encryption engine on the drive is that it can be tuned for the transfer rate of the drive. The drive supports multiple user and administrative passwords. The Momentus 5400 FDE.2 is also compatible with trusted platform modules (TPMs).
New cryptography approaches DES (Data Encryption Standard), which is no longer in regular use, is an encryption standard that was broken long ago using brute force techniques. Likewise, 3DES (triple DES) has been replaced by the more robust AES. Still, AES is not the end of the line. That’s why on-chip encryption systems continue to morph to match the latest security technology. Often, multiple encryption standards are supported by on-chip accelerators.Another popular encryption system that is being deployed is based on elliptic curve cryptography (ECC). ECC is a public-key cryptography system based on the algebraic structure of elliptic curves over finite fields. It is an option for wireless technologies like ZigBee. One reason for its use is scalability. In theory and practice, ECC scales better than AES, the most popular encryption standard.
Encryption methodologies continue to crop up, though acceptance typically takes a long time. Challenging a new approach often requires new thinking. One example, from SecureRF, is called lgebraic Eraser (see “SecureRF May Have The Holy Grail For Encryption” at www.electronicdesign.com, ED Online 13706). It utilizes a linear-based security protocol that is applicable to symmetric (secret-key) and asymmetric (public-key) cryptography.
Continued on page 3
DRM doesn't provide security DRM is important to many and a bane for most, but it tends to be inextricably linked to hardware-based security and encryption. The dependency on hardware support is in part based on the need for end-to-end protection of content and the required throughput of a system. For example, encryption/decryption of streaming audio or video must occur at line speeds or playback quality will suffer.Consumer demand seems to be pushing DRM out of the audio space, but it remains critical on the video side. Highbandwidth Digital Content Protection (HDCP) protects some HDTV content today, and it is built into the source and destination of HDTV devices including Blu-ray and HDTV drives. Luckily, transport of data between devices is assumed to be in the clear, so it does not involve any encryption or protection. In general, only devices created as endpoints need to address this type of DRM.
On the other hand, protecting the object code of an application is often desirable. This may require encryption if the code is coming from a non-secure, offchip site such as a flash memory chip. In this case, the processor would have to decrypt the code as it is executed. This isn’t common, but several microcontrollers can perform this function, such as the 8051-based DS5250 from Maxim-IC.
Another approach is to have a boot loader that can decrypt off-chip code into an on-chip RAM and then execute from RAM. The decrypted code is lost when power is removed. The typical alternative is to use an on-chip code protection scheme that typically prevents the flash memory from being read by the usual debugging means. It usually prevents programming of the flash without an additional key. Otherwise, a rogue application could be loaded in a small part of the memory. The application could then download the remainder of the intact code to an attacker.
Multilevel security Controlling code and access to code is typically part of a microcontroller’s memory and system protection system. Highly secure systems typically combined this with options such as secure boot and secure storage to bring up a secure operating system such as SE Linux (Security Enhanced Linux) from the NSA (National Security Agency). A further extension is support for virtual machines.With the exception of the secure boot and secure storage, encryption isn’t necessarily part of the systems’ security. Instead, standard microcontroller virtual memory and virtual-machine support is sufficient to implement multilevel security (MLS). Additional hardware features can be incorporated into a system, but these are rarely found on standard microcontrollers.
The reason developers need to know about these aspects of security is that they do not require additional hardware, but the software does make certain assumptions about the starting point of the system, such as the boot process and the operating system. Systems that fail to meet these assumptions can be compromised often without resorting to any decryption. Unfortunately, these aspects of security are beyond this article, so do not assume that simply including hardware encryption or even secure boot features will provide a secure system.
