Securing SoC Platform Oriented Architectures with a hardware Root of Trust
While it has long been the purview of electronic product vendors to rise to the challenges of managing ever shortening product life cycles, a new trend is afoot that may turn the tables in favor of longer platform hardware life cycles.
As embedded programmable processor based features increase in power, increasingly sophisticated platform System on Chip (SoC) architectures, including configurable hardware, boot code, firmware, and system software now bring to systems the ability to modify basic hardware functions and features without redesigning the SoC from scratch.
The real trick is how to efficiently and securely manage these changes to system hardware throughout the supply chain. For conceptually newer products there will be requirements that drive configuration of in-market system features. In other words, the customer may have the ability in the future to upgrade his product with premium system features after his or her original purchase.
Platform Oriented Architecture Trend
An important trend that has been gaining traction over the past several years is the movement by chip architects toward Platform Oriented Architectures (POA). This is by no means an original concept since the microcontroller and its successors have been a very good examples of POA types of devices over the years.
Clearly, an embedded programmable controller, processor, or DSP can be modified via software to satisfy any number of functional requirements. As an extension of the embedded programmable processor (or controller), a Field Programmable Gate Array (FPGA) provides the ultimate POA conceptual device. One chip can support any number of hardware designs and may even be re-configured in-system.
Of course, due to the restrictions of cost for high volume applications and the unforgiving nature of silicon, hardware systems are typically optimized for the product applications they support. Thus, most product lines have traditionally required multiple chips within a chipset to address each market segment these chips serve. Why then is it important to now consider trends toward what the author has designated POA devices several decades after the invention of the FPGA?
Inevitably the answer to the above question is a matter of economics. A new and more flexible style of architecture is needed in the aftermath of the Structured ASIC (application-specific integrated circuit).
The failure of the Structured ASIC to find a home in between FPGA and ASIC technologies may arguably be the result of the time sensitivity chip designers have with regards to rapid increases in production volume.
In other words, the cost benefits of going with a Structured ASIC solution do not justify including a Structured ASIC step in the migration path from an FPGA in to an ASIC in order to reduce the unit cost as production volume warrants.
A contributing factor to the lack of popularity of the Structured ASIC is the fact that such a device cannot, by definition, serve broad application requirements and be adequately optimized to those same requirements at the same time.
In recognition of this, chip architects are now realizing the benefits of leveraging structured architectures for more narrowly defined application requirements. A multi-media player SoC is illustrated below as an example of a POA SoC device that takes this approach (Figure 1 below).
|Figure 1. Multi-media Application Processor Feature Control|
Within the POA block diagram, there are a number of firm or soft configurable elements within the architecture that may activated or de-activated by issuing secure Feature Control Tickets (FCTs) to an embedded digital asset control core embedded in the POA architecture.
These FCTs may be stored permanently in the SoC's internal non-volatile memory (NVM) or temporarily in volatile memory. These FCTs are essentially switches that may be used to turn on or off features in hardware, firmware, or software and which are secured by a hardware root of trust. For this reason, it is imperative that the FCT and the memory used to store the status of an FCT controlled feature be protected. Each FCT issued to a device should be unique to that device.
By isolating a successful attack on an FCT to a single device, such an attack on an FCT is prevented from compromising all other devices shipped into the market. The importance of a hardware root of trust and security will be discussed in more detail in a later section.