Programmable Risk Factors

The semiconductor industry is starting to come around to the realization that security begins at the block level. Intellectual property (IP) is being seen with IP blocks that can be woven into the general-purpose system-on-chip (SoC) hardware layers to secure I/O, data, keys, and various other sensitive or critical information.

But modifying hardware designs in response to the demands placed upon the system, particularly in real time, adds several layers of complexity. It also raises security risks to a whole new level. Today’s complex, reconfigurable SoCs include multiple, heterogeneous processing cores, hardware accelerators, networks-on-chip, on-chip memories, and any number of peripherals. They promise to push out that all too prominent wall of power and complexity, and permit scaling performance while improving energy-efficiency. In a perfect world, a reconfigurable processor can transform itself from a video chip to a CPU to a graphics chip, for example, all optimized and configured so applications to run at peak efficiency. What more can one ask of a bleeding-edge IC?

Reconfigurable devices are more complex, but the basic hardware is the same as is the process for programming. The difference with reconfigurable devices is that they include the circuitry necessary for on-the-fly, arbitrary reprogramming.

The promise of reconfigurable hardware
What’s nice about reconfigurable hardware is that it allows the device it drives to implement hardware functions that would require more physical gates that are actually in the chip. Let’s say, for example, one has a multi-mode cellular phone that functions on both code-division, multiple access (CDMA) and global system for mobile communication (GSM) networks (see Figure 2). Traditional designs would require two different SoC ICs, each with the applicable network radio. And the gate count of each SoC is designed for that RF system, specifically – all gates are accounted for. There are no more, nor less gates used than are needed for the application to function.

Fig. 1: A generic example of how a modern smart phone might reconfigure itself to operate on both GSM and CDMA networks. In both cases, reconfigurable data would be stored in RAM and called to reconfigure the logic as required.

However, with a reconfigurable SoC, the device essentially can offload one system and load the other, not unlike a computer that has Windows, Mac and Unix OSes installed and can run whichever system is required for the application. This approach works well, in scenarios such as dual mode cell phones where only one system is needed at any given time. Because reconfigurable technology requires less hardware to accomplish more functionality, it can provide higher performance and use less power for that same functionality.

Depending upon where one comes from there are several compelling arguments for designing devices with reconfigurable hardware. One is the ability to do bug fixes on the fly. And such devices can, in many cases, be made error-free. From the designer’s perspective, a nice benefit of this technology is increased system reliability. Dynamically reconfigurable devices offer system stability because, if a part of the hardware becomes faulty, it can simply be circumvented. This is a tremendous advantage to mission-critical end users as well. For example, military hardware, in the field, can be dynamically reconfigured, on the fly, for whatever the situation demands. From the end user’s perspective, such flexibility is worth the added cost, in many cases.

From the manufacture’s perspective, reconfigurable SoCs improve yield. All chips have some defects. Depending upon the defect, where it is, and how it affects the functionality of the chip, it can, in standard devices, be flagged and isolated, and the chip can be utilized. Also, these types of chips have more latitude in what they can be used for, since one critical component in a standard chip that is defective, may not be a critical component in another application that the chip can be used for.

Other advantages include:

• Greater functionality with a simpler hardware design. Because not all the logic must be part of the functionality within FPGA or ASIC, at all times, the overhead of supporting additional features is redirected to the cost of the memory required to store the logic design. In modern SoCs, memory is relatively cheap and prolific. And, new functions and be uploaded to this memory and run as required.
• Lower system costs. This is true, mostly with scenarios such as multi-mode cellular phones, but there are others, including consumer set-top boxes, military hardware, and communications systems like RADAR where a reconfigurable SoC is the ideal solution.
• Faster time to market. Again, back to the cell phone example. A manufacturer can do one design with a single, reconfigurable SoC that gets specific programming once it gets out to the field. That way, there is only one development cycle and all the elements and peripheral support (testing, QC, etc.) that comprises it, rather than a separate development cycle, and the CAPEX/OPEX for each product.

Overall, it seems that reconfigurable chips are the greatest thing that has hit the fabs since EDA. However, all that glitters is not necessarily gold. There are some concessions with reconfigurable chips.

For one thing, they are more expensive to produce. There is an offset there, however, because the cost of a single reconfigurable chip may be less expensive than integrating multiple special chips (such as the dual-mode cell phone, for example). However, that is dynamic and really depends upon what the chip will do and what type and how many standard chips it replaces.

Second, they are slower. There is overhead to the reconfiguring stage. It may not be an issue in some applications, such as cell phones, but it certainly can be an issue for on-the fly split-second decision making, such as reconfiguring a weapon at the last minute that needs a different set of parameters to function optimally as it drops its munitions or to re-target.

Next, there can be placement and routing considerations. Each unique configuration can have different interface requirements for ancillary circuits such as memory, I\O, or library calls.

There are other considerations, as well. Timing, latency, and consistency all need to be considered, which adds complexity to the design. Again, in some cases it doesn’t matter, but the more mission-critical the applications become, the more these parameters come into play.

Programmable devices are not immune from typical physical chip compromise techniques either. For example, one well-utilized attempt to extract data from chips is the side-channel attack.

“Non-invasive, side-channel analysis is probably the easiest, lowest-cost method for recovering secret keys from current- generation microchips,” said Pankaj Rohatgi, director of engineering at Cryptography Research. “There are several categories of countermeasures being used to protect against these. More popular methods focus on reducing the signal-to-noise ratio of the information leakage from side channels. These include making algorithmic changes and incorporating balancing in hardware and firmware to reduce the leakage signal and the addition of temporal and amplitude noise.”

He noted that another class of techniques are based on randomizing the data and intermediates being used within the internal calculations of cryptographic algorithms to make the implementations resistant to statistical analysis.

Dealing with traps
Because reconfigurable chips are relatively new in the hardware space, there is a lot of stuff on the drawing board when it comes to making these devices secure. Unfortunately, there is less in the real world to work with.

Securing reconfigurable chips is more difficult than standard chips for the obvious reason that the chips are, well, reconfigurable. Because these chips are reprogrammable via a number of avenues, securing them from malicious onslaughts becomes the No. 1 priority, both in the design and in the field.

There are three basic security areas that reconfigurable architects need to be concerned with when designing such chips. One is making sure that logic-level separation is maintained. Because with reconfigurable hardware the logic is dynamic, a potential hornet’s nest of problems that do not have easy solutions can develop. It is quite possible for a hacker, or even an unsuspecting authorized programmer, to load malevolent configurations that can cause errant program behavior. Alternatively, on the hardware side short circuits; even meltdown or self-destruct routines, if they are available.

Furthermore, in most cases there will be secret or, at least, confidential data that shares the same chip logic or memory as untrusted intellectual property (IP). If the IP turns out to be malevolent, it probes the device or causes it to dump confidential information.

A second area of concern is memory protection and isolation. In typical applications, virtual memory is the approach used to enforce most security policies. In embedded system, there is little if any in the hardware. The present alternative is to build a translation look-aside buffer (TLB) structure out of the logic blocks that populate a modern reconfigurable device. However, that is clumsy, and a new methodology is needed to universally address the way embedded memory is protected and shared.

Third is policy management. Because configurations change in these chips, it stands to reason that multiple policies would be necessary. Therefore, something like dynamic policy management is needed. However, challenges sometimes morph into advantages. As it turns out in reconfigurable chips, unlike standard chips, it is possible to use the hardware to enforcement adaptive security policies – a freebie, one might say.

Reconfigurable chips also provide the ability to override the nominal security policy, if the situation arises. The reconfigurable component of these chips can provide a highly trusted mechanism for secure functionality in changing environments.

And, the pièce de résistance
Finally, if one has to pick an area that would have the highest risk of compromise is, it would have to be on-chip memory. It is ubiquitously accessed by code; it stores data, instructions, and policies. It also is the easiest place to stuff errant code. Once there, the code has access to all parts of the chip. It is also where sensitive data is kept. Memory is the great enabler, but it can also be the most dangerous when it comes to security breaches.

There are new ways to protect that precious memory. One is to build in self-protecting redundancy thought various checks and balance when it is accessed, read or write. Another is to put a strong, no-exception’s security policy in place.

Tagging adds a high level of security to the data within the chip. By tagging system data, information can be tracked as it routes. And if anything out of the ordinary happens to it, the system can be alerted and corrective action taken.

And, of course, securing the I/O. Because memory has such an open interface to the rest of the chip, securing memory I/O is really a critical parameter.