•  
• EDN Europe MAGAZINE
•  
• Free SUBSCRIPTION
• Subscription Renewal
• View Media Kit

• EDN
• EDN Australia
• EDN Asia
• EDN China
• EDN Japan

Silicon simplifies embedded-system security

AS THE INCREASE IN CLONING AND INTELLECTUAL-PROPERTY THEFT DEMONSTRATES, SECURING EMBEDDED SYSTEMS FROM HACKERS IS RAPIDLY BECOMING A NECESSITY FOR MANY ORGANISATIONS. DEDICATED HARDWARE GREATLY SIMPLIFIES THIS DIFFICULT TASK.

In last month’s edition of EDN Europe, Steve Robinson introduced many of the cryptographic techniques currently in use and described methods of implementing security algorithms on commonly available microcontrollers in software (Reference 1). From his analysis, it is clear that developing your own security regime is a nontrivial task that many engineers will find challenging. Silicon vendors, aware of this fact and the growing need for secure links within and between embedded devices, are beginning to make available hardware-based solutions that greatly reduce the developer’s task while making life extremely difficult for hackers. Several of these vendors are able to exploit their experience within the smartcard industry, where hardware cryptographic engines secure the user’s data at a very low per-unit implementation cost (Reference 2).

In talking to several securityindustry insiders, it is clear that while many engineers perceive the need to secure their systems, many more appear to believe that embedded systems are somehow intrinsically secure—the “security by obscurity” myth. It is also evident that a significant percentage of engineers wishing to implement security measures have no clear idea of the level of potential threat or type of adversary that their systems may encounter. Start by asking what you’re trying to protect and from whom. Threats may range from digital-rights-management theft by a consumer wishing to download music files for free, to a foreign government whose motivation is to reverse-engineer a secret system. Obviously, the resources available to mount an attack vary enormously across these examples, and ultimately nothing will stop a truly determined hacker with sufficient expertise and resources from unveiling the contents of an IC or system.

You can glimpse some insight into available techniques from legitimate commercial enterprises such as Chipworks, which specialises in reverseengineering systems and analysing ICs to ensure that the IP (intellectual property) that lies within doesn’t infringe rights that their clients hold. Capabilities that the company offers include “semiconductor circuit extraction from decapsulating and delayering the chip, to transistor-, gate- and blocklevel extraction identifying interconnections and components”, which generally involves microprobing the wafer and/or observing its layers with a scanning electron microscope before re-assembling them with nanometre accuracy. This is fascinating technology, but hugely expensive and inappropriate for all but the most sensitive situations—that is, assuming you concur with the securityindustry mantra that a system is secure when the resources necessary to crack it are more valuable than the secret you’re trying to protect.

DEFEND YOUR CHIPS

One of the commonest security concerns for manufacturers is the potential for competitors to reverse-engineer a successful product and steal its IP. Historically, IP theft has been a particular issue for FPGA vendors, whose products used to be relatively easy to hack into. Notionally at least, anyone with sufficient motivation would find it easy to intercept the serial bitstream between a configuration memory and a conventional SRAM-based FPGA using nothing more than a logic analyser—and the same applies for a lot of volatile devices that use memories for power-up initialisation. Actel in particular has used this argument to promote its nonvolatile devices that use antifuse technology. For many engineers, it is worth assessing the convenience that configuration memories offer in terms of ease of development and product upgrades versus the risk of firmware theft that some may consider what marketing types refer to as FUD (fear, uncertainty, and doubt). If such memories are important to you, hardware is available to help secure them.

In practice, today’s FPGAs are sufficiently complex to make reverseengineering a configuration bitstream a distant possibility for most hackers, even without the silicon vendor employing any kind of bitstream encryption. One reason is that there is minimal information in the public domain regarding the structure and encoding of the proprietary bitstreams that the FPGA vendors employ. This doesn’t mean that an attacker cannot simply record and replay the bitstream to clone the product, as the growing trend for far-Eastern producers to manufacture grey-market goods shows.

Because all FPGAs employ a bitstream for configuration, even nonvolatile devices can be open to attack. One potential method involves the readback facility that some vendors offer. The intention of readback is to allow the developer to take a snapshot of the internal state of the FPGA at some moment, which the device returns as a bitstream comprising elements such as configuration data, the state of lookup tables, and memory. This debug information lacks much of the original configuration bitstream’s data such as file headers and initialisation commands, but a knowledgeable hacker could substitute this information with relative ease. It is also possible to conduct a readback difference attack, whereby the hacker controls the clock signal and observes signal changes cycle-by-cycle. Accordingly, vendors that offer readback typically embody bitstream encryption options that disable this mode when set, using mechanisms such as multiple majority-voting registers that hackers are unlikely to crack (see Reference 3 for an analysis of FPGA security issues).

Similar concerns extend to embedded firmware, which increasing lies in on-chip flash. Accordingly, microcontroller vendors routinely embed a memory-locking feature that prevents the toolchain from reading the chip’s memory. Techniques that appear in development environments such as P&E Microcomputer Systems’ programming module for Freescale’s CodeWarrior suite include generating a security key during programming, with any subsequent readback requiring this key to access the flash. This approach makes it difficult to simply clone the flash, even of entry-level 8-bit devices such as the MC9RS08 series that also block flashmemory reads if the programmer sets a bit in nonvolatile memory. Setting this bit still allows access to RAM and registers from background-debug mode. Crucially, it also permits developers to reset the security bit by erasing the entire flash area—which allows a hacker to impersonate a device by substituting code that, for instance, permits entry to a building. Illustrating the evolutionary nature of security issues, future devices will employ more sophisticated mechanisms to deflect this type of attack.

Combining hardware and software approaches, the Lockbox technology that Analog Devices deploys in several new Blackfin processors allows you to safeguard code in external memory and execute that code securely. Being a general-purpose DSP/microcontroller architecture, the Blackfin’s code and data spaces reside in separate on-chip areas of fast SRAM that a bootloader initialises at power-up, typically from one or more flash chips. Because its security features are optional, a Lockbox- enabled Blackfin operates exactly as a normal device if the developer leaves the chip in the default open mode that follows every power-up or entry from reset. Phil Giordano, senior DSP applications engineer at Analog Devices, explains that the primary defences Lockbox uses are encryption and digital signature authentication, but the technology goes further by providing on-chip hardware and firmware to ensure the integrity of the code that the processor runs: “This ability is useful to ensure, for example, that any firmware update originates from you and not from some hacker.” Lockbox also provides each device with a unique identity that is useful to prevent cloning or in applications such as digital-rights management, enabling the developer to effectively lock memory contentto an individual processor and/or that processor to a particular boot source. If an unforeseen event compromises a device’s security, it is possible to exclude that device from the system.

 

Lockbox partitions an OTP (onetime- programmable) area of on-chip memory into a 4-kbyte secure area to store secret data such as cipher keys for decrypting sensitive data, and another 4-kbyte open area for data including the device’s identifier and the public key that is essential for secure-mode operation (Figure 1). This write-protectable OTP isn’t part of the Blackfin’s linear memory map, but instead is organised as a 64-kbit serial memory yielding approximately 50k usable bits that are accessible in 128-bit pages via four 32-bit peripheral registers. A separate ROM contains firmware to control the authentication procedure that—in conjunction with the Blackfin’s programmable secure execution mode—provides the mechanism for the device to run only trusted code. Secure-mode operation also enables access to the secure area of OTP and gives the developer control over the secure system switches that manage the chip’s hardware protection features, such as JTAG accesses.

The digital-signature mechanism utilises standards-based algorithms that comprise SHA-1 (secure hash signature standard) according to FIPS PUB 180-2 and a subset of ECDSA (elliptic-curve digital-signature algorithm) according to ANSI X9.62-1998 that supports the Koblitz curve. Giordano points to Reference 4 as a good description of these techniques. The authentication process occurs in two domains, the first of which is off-chip. The developer starts by producing application code in the traditional way, typically using Analog Devices’ VisualDSP++ toolchain on a host PC. This code can be plaintext, or you may wish to encrypt sensitive data using an algorithm of your choice, storing cipher keys in the Blackfin’s secure OTP. In either case, the next step is to compute a hash of the file using SHA-1, which produces a 20-byte message digest. You then encrypt this hash digest using an ECDSA utility and generate a private key/public key pair, storing the private key safely within your organisation. The file-signing process produces a 163-bit result that forms the digital signature, which you transfer to the Blackfin’s boot source along with the application code.

At the on-chip level, you program the device’s OTP with any data that you wish to store, placing the public key in a predefined area. Then, following any power-up or reset event, the processor executes boot code from its on-chip ROM. This process loads the processor’s instruction SRAM with a kernel start-up file that the developer stores in external memory, commanding the Blackfin to download the application code and digital signature into its data SRAM. Assuming that authentication is enabled, the kernel start-up code calls the secure-entry service routine within the Blackfin’s ROM. This firmware asserts system switches that disable the chip’s JTAG emulation interface and DMA access to internal memory to prevent attackers from accessing these routes, while leaving open public JTAG operations that are necessary for boundary- scan testing. Meantime, dedicated hardware detects any instance of the program counter moving outside of the security firmware’s address range—in which case the processor asserts its non-secure mode and refuses to run the code that it was attempting to authenticate. This may happen if, for instance, an interrupt occurs that the core responds to, requiring another authentication request for recovery. Allowing interrupts by default preserves the ability to respond to realtime events under all circumstances, and it is user-configurable.

Assuming normal event flow and successful file transfer to on-chip memory, the Blackfin’s firmware hashes the application file and deciphers the encrypted signed hash digest using the public-key record within its OTP. Providing the calculated hash value matches the original, the core transfers the instruction content of the application code to its instruction RAM, and secure-mode execution continues within internal memory. The architecture allows you to mix encrypted and plaintext application code, so one code segment may decrypt another segment that you wish to hide from view, prior to executing that segment. You can digitally sign both the encrypted and plaintext code prior to subsequent authentication by the Blackfin. If the authentication process fails, the processor denies secure-mode execution rights together with any access to secure data before returning to open-mode execution. Again, the developer determines how to handle such exceptions—for instance, you might try reloading the application code to ensure that no corruption occurred during the file-transfer process.

Giordano says that he often encounters users who believe that encryption equals security: “Encryption more correctly equates to confidentiality, but encryption does not necessarily equate to trust or integrity.” He asserts that digital signatures help to ensure trust, integrity, and origin identity, so it will benefit developers to encrypt their code if they wish to ensure confidentiality. Depending on processor variant, Lockboxenabled Blackfins are available now from around $7.95 to $22.00 (1000) and enjoy development support from the $895 ADZS-BF527-EZLITE and $995 ADZS-BF548-EZLITE.

With a device such as the DS5250 from its secure-microcontroller family, Maxim makes it possible to protect code and data within an 8052-compatible environment. This 25-MHz chip loads and executes up to 4Mbytes of 3DES-encrypted application software from external memory via its 8-bit data bus (Figure 2). During the initial boot sequence that commissions the system, the chip reads plaintext application code from the serial port, and encrypts it using DES or 3DES before storing it in external memory. On-chip hardware encrypts this code via a secret key that the chip generates using a true random-number generator: this key is never visible to the outside world. The chip then writes encrypted code to external memory. As well as encrypting instructions and data, the write-back process also scrambles external-memory addresses, so there’s no occurrence of sequential instructions or data appearing in off-chip memory. Furthermore, combining the address value with the key results in identical plaintext data values assuming non-identical values in random locations within external memory.

In subsequent operation, the chip’s hardware performs encryption and decryption in real time, so that there is no additional processing burden relative to a standard insecure microcontroller. Other security features include two selfdestruct input pins that allow external tamper-detection hardware to erase the DS5250’s internal secure batterybacked SRAM including the code-encryption key, with or without Vcc being present. The microcontroller also includes high-speed RSA and 3DES encryption accelerators for general application use. A software library is available for on-chip RSA keyset generation, meaning that you don’t need to load an RSA keyset in a potentially insecure manufacturing environment. The device is available now in an 80-pin MQFP and an 100-pin MQFP. Due to the secure nature of the device, you will need to contact the factory and complete a nondisclosure agreement to access its full specifications.

SECURE MEMORIES LOCK SYSTEMS

Unless you’re an expert cryptographer, securely storing secrets on a conventional microcontroller is unlikely to be successful. Eustace Asanghanwa, application-engineering manager for Atmel’s cryptographic products, says that the company recognised at an early stage that designers require solutions for both client- and host-side security, independently of which platform they are currently using: “It’s essential to view the entire system to identify its weakest link and minimise the opportunity for attacks.” He too advises you not to confuse encryption with security—encryption forms just one part of a properly designed secure system.

Tackling client-side security, Atmel’s CryptoMemory products exploit challenge- and-response sequences that range from password-protected, standard- mode operation to mutual authentication and encryption. Nine devices offer user-memory densities from 1 to 256 kbits, with each device including a 2-kbit configuration memory with a 37-byte OTP area for user-defined codes and another 160-byte area for keys and passwords. Depending on chip density, you can optionally divide the user-EEPROM area into 4, 8, or 16 zones, configuring access rights for each zone within the configuration memory. Each device also embeds a 64-bit hardware encryption engine, but you’ll need to sign a nondisclosure agreement to gain access to details of the encryption and mutual authentication procedures. You can however easily evaluate the devices in standard-mode operation using the company’s AT88SC-DK1 adaptor-design kit, which provides evaluation software, source examples, and a development library (see sidebar “Try the kinesthetic route to security”). Other CryptoMemory features include 2.7-to-5.5V operation, data encryption for internal memory, and additional layers of metallisation that obscure the die from microprobing. Anti-tamper circuits watch for abnormalities such as out-of-specification supply-voltage, clock-frequency, and temperature conditions, and include delay circuits that defeat dictionary attacks, where the hacker attempts multiple data combinations in the hope of arriving at the right answer. Packaging options span PDIP/SOIC to smartcards and wafers, with the IC formats sharing the same pinout and two-wire interface as conventional 8-pin serial memories.

Complementing its client-side chips, Atmel’s CryptoCompanion chip works alongside the host, with this device storing up to sixteen 64-bit root secrets —useful for situations where different secrets enable alternative capabilities in the client. There’s also an internal 128- bit secret that the CryptoCompanion chip can use to identify itself to the system. Because generating truly random numbers is fraught with difficulty and not viable via software, the chip includes a multi-stage hardware protocol built upon an internal hardware noise source and pseudo-randomiser that performs to FIPS-140 standards. The chip also uses SHA-1 to derive the CryptoMemory’s key from the root secret and the memory’s unique 120- bit identifier. In combination with a 128-bit key, SHA-1 also protects data that is sent to the chip during programming. Atmel asserts that there are no known practical attacks on the algorithm that might allow an adversary to retrieve the root secret from the results of this process.

Maxim also offers secure memories, such as the DS28CN01, which connects to the host microcontroller or FPGA via an I2C/SMBus interface. Available in an 8-pin SOP for less than $1.00 (1000), the device appears as memory-mapped I/O for challengeand- response authentication using the SHA-1 standard. It also offers a general-purpose 1kbit EEPROM array with programmable write protection and EPROM-emulation abilities. The factory programs every device with a unique and unalterable 64-bit identifier that you can use to generate a unique 64-bit SHA-1 authentication key. This identifier also serves as an electronic serial number at the board or system level. Other useful attributes include two address pins, 5.5V-tolerant I/O, and a 1.62-to-5V power-supply range.

LOCK YOUR COMMUNICATIONS

If fully securing the integrity of a design is an impossible task, it is possible—and often very highly desirable—to secure communications at board, module, or system level to a degree that makes it practically impossible for hackers to penetrate. Obvious examples include industrial infrastructures as well as anywhere public safety may be at risk, such as in building automation and security systems—many of which run embedded Linux that, without appropriate defences, represent an open door to a hacker. Similarly, with so many embedded systems now using Internet connections, securing data exchanges while ensuring that hackers have no route to the system’s internals is arguably a best-practice necessity. The growing interest by utility companies in remote meter reading is also an area of considerable activity, especially as many of these companies plan to deploy powerline-based communications.

Running computationally intensive encryption algorithms such as AES, DES, or TDES can cripple even a 32-bit machine. For instance, a 50-MHz version of the ubiquitous ARM7TDMI performs software-based AES encryption at around 4.3 Mbps, which is not only too slow for many applications but also locks the processor out of being able to respond to other tasks while the algorithm runs. Accordingly, it is desirable to offload encryption tasks to a dedicated coprocessor. Atmel’s recent 7XC additions to the network-centric AT91SAM7X series that EDN Europe reviewed back in February 2006 (Reference 5) embed hardware encryption engines alongside the ARM7TDMI core and peripherals that include 1-Mbps CAN (controller-area-network), 10/100-Mbps Ethernet, and 12-Mbps full-speed USB ports. Available with 128, 256, and 512 kbytes of flash and 32, 64, and 128 kbytes of SRAM, the new AT91SAM7XC chips operate at up to 55 MHz under worstcase conditions, accelerating AES and TDES throughput to as much as 80 Mbps.

Widening the application scope of its popular 32-bit series of ColdFire processors, the recently announced MCF51JM128 and MCF52235 from Freescale each include a hardware CAU (cryptographic-acceleration-unit) together with a random-number generator that computes FIPS-140 compliant 32-bit values. Simplifying the programming model, the CAU implementation tightly couples with the ColdFire V1 and V2 cores via the conventional ColdFire coprocessor interface to support AES, DES, TDES, MD5, and SHA-1 cipher and message-digest functions. Easing integration with existing cryptographic libraries and useful for developers wishing to write custom routines, Freescale’s ColdFire CAU software library demonstrates how to implement low-level cryptographic functions using the co-processor interface in as generic a manner as possible (Reference 6). Rudan Bettelheim, product manager for Freescale, says that the company’s secure-technology centre has made available encryption engines for at least five years: “We’re now seeing a considerable change in the embedded marketplace that we’re very well-placed to serve.”

Using largely the same underlying technology, Freescale’s encryption engines divide into two segments: lowerend algorithm engines that require the host processor for direction, and examples such as those that appear in high-end ColdFire and PowerQUICC processors. The more sophisticated devices are capable of bus mastering and autonomous operation, reading descriptor tables of what to encrypt and where to place the results. Several E-suffix versions of the company’s PowerQUICC-III microcontrollers, including the MPC8555E, MPC8541E, and MPC8548E, feature securitymodule implementations that benefit from comprehensive documentation. Application note AN3075 provides an overview of the security module within the MPC8555E together with the procedure for building and running a security driver on the $4996 Linux-based MPC8555CDS platform; companion document AN3085 describes implementing AES message authentication using this hardware base. Also consider the MPC8360E PowerQUICC II Pro processor, which benefits from the MPC8360E-RDK development system that’s available for $999.

SMARTCARD EXPERTISE

As the world’s largest microcontroller producer, Renesas also has extensive experience in the smartcard industry that the company is now extending into the industrial arena. Daniel Borleteau, security-program manager at the company, says that while the core hardware components are similar, industrial applications place additional requirements on security-component suppliers: “Industrial users require SPI or I²C connectivity rather than the smartcard’s ISO-7816 interface, together with different packaging and wider environmental specifications.” But he observes that the largest difference between the classic secure-microcontroller market and emerging industrial use is the level of engineering support that is necessary: “While financial users know exactly the level of security they want, we’re working very closely with our industrial customers to identify their needs.” To become a solutions provider for this wider marketplace means greater demands on technical support and software provision, with Renesas working on its own developments as well as in partnership with third-party software suppliers.

Borleteau explains that for industrial applications, the company decided to adopt a two-chip approach that combines a general-purpose microcontroller with a secure device, allowing users to retain their existing hardware and preserve the code base. The basis for the new three-member N-series of secure devices is the company’s AE4 architecture that appears in devices such as the AE46C1 smartcard chip (Figure 3). For the N-series, the H8/300H processorbased 16-bit core addresses less on-chip memory than the AE46C1—up to 18 kbytes of EEPROM, 4 kbytes of RAM, and 112 kbytes of ROM—as industrial users developing in C don’t need the Java virtual machine that smartcards implement. Other differences include the addition of an internal clock and four GPIO pins that you can configure for I²C or SPI. Available in a 20-pin QFN, the N-Series retains the 16-bit randomnumber generator and an optional 1024- bit modular-multiplication-unit that in conjunction with Renesas’ software libraries perform a range of symmetric and asymmetric ciphering algorithms, including 3DES and RSA, as well as hash algorithms, including SHA-1. Other security features includ e comprehensive anti-tamper mechanisms and an FMU (firewall-management unit) that monitors memory accesses. An evaluation kit is available by arrangement with the factory.

For more information
Actel www.actel.com	Freescale www.freescale.com	Analog Devices www.analog.com
Maxim www.maxim-ic.com	Atmel www.atmel.com	P&E Microcomputer Systems www.pemicro.com
Chipworks www.chipworks.com	Renesas http://eu.renesas.com

REFERENCES

Robinson, Steve, “Safe and secure: data encryption for embedded systems,” EDN Europe, June 2008, pg 24, www.edn-europe.com/article. asp?articleid=2176. Marsh, David, “Get smart—smart cards pass the global test,” EDN Europe, February 2003, pg 22, www.edn-europe. com/article.asp?articleid=1165. Drimer, Saar, “Volatile FPGA design security—a survey,” Computer Laboratory, University of Cambridge, April 2008, www.cl.cam.ac.uk/~sd410/. “Elliptic Curve DSA,” http:// en.wikipedia.org/wiki/Elliptic_Curve_DSA. Marsh, David, “Low-cost ARM kits ease 32-bit migration,” EDN Europe, February 2006, pg 21, www.edneurope. com/article.asp?articleid=1392. “ColdFire CAU software library,” document number MCFCAUUG, Freescale Semiconductor, February 2007, www.freescale.com.

CONTACT DETAILS

You can reach Contributing Technical Editor David Marsh at forncett@btinternet.com.