Intellectual property security: A challenge for embedded systems developers -

Intellectual property security: A challenge for embedded systems developers

Editor’s Note: In this Product How-To article, Sachin Gupta describes how an embedded design’s IP can be accessed and protected, using Cypress PSoC 1 devices as an example.

A company’s success – and its future – depends on the creation and successful defense of intellectual property (IP), which is generally defined as “creations of the mind for which exclusive rights are recognized.” IP is the outcome of innovation and work done by an organization/person and gives a company's products an edge over competitors.

For an organization that manufactures embedded systems, IP can be:

  • Firmware implementation of a system
  • Hardware implementation; i.e., signal chains or output control using innovative methods that differentiate the product from others
  • Any innovative method to solve a particular problem in the system

An embedded system implementation that uses the minimum possible hardware resources is one example. This reduces the manufacturing cost of the product, in turn making it easy to sell in a competitive market.

IP security is a major challenge for any company. Each product is created only after a significant amount of R&D and innovation. After releasing the product to the market, a significant concern for an embedded system manufacturer is reverse engineering, a bitter reality in today’s market. It can significantly impact the product revenue if a competitor can hack your IP and copy your design.
When it comes to IP security in embedded systems, the first thing that comes to mind is the firmware that goes along with the microcontroller/microprocessor. Some system designers do not think beyond firmware to consider hardware, which is also at risk for design theft (Figure 1 ).

Figure 1: Typical Embedded system

This hardware is used to interact with external peripherals, to sense inputs, to generate outputs and also for signal conditioning. Let us take the example of an e-Bike control system. Figure 2 shows one possible implementation of such a system.

Figure 2: e-Bike control system

As shown in Figure 2, the firmware written for the MCU usually takes inputs like bus (supply) voltage and speed command, performs signal conditioning, and converts it to digital. Then it does various calculations and makes decisions based on the firmware written for the MCU, such as controlling a motor and LED outputs.

IP security for an embedded system can broadly be divided into two parts.

  • Protection against unauthorized access to the firmware
  • Hiding analog and digital resources and their interconnection

Protection against unauthorized access to the firmware: Different microcontrollers have different means of protecting the code stored in flash from unauthorized access, and some may not provide any protection option at all. At a higher level, all solutions revolve around disabling reading from the Flash memory area. Some devices disable read and write access for the entire flash memory system. This solution makes it impossible to add bootloader support in the end system. If a bootloader needs to be implemented in the system and IP security also is important, the system designer needs to select the appropriate microcontroller.

Some microcontrollers divide the flash into multiple blocks with each block protected at a different security level. In such devices, it is possible to implement a bootloader and still achieve the same protection level. Let us take the example of flash protection provided by PSoC 1 devices, which support various modes of flash protection:

  • Unprotected mode
  • Factory upgrade mode
  • Field upgrade mode
  • Full protection mode

The selected protection mode is loaded into NVL (non-volatile) bits at the time of programming, and cannot be changed at runtime to avoid any accidental change to protection level and to avoid an attacker attempting to modify firmware by writing specific code in the unprotected area of flash.

Unprotected mode: In this mode, all external and internal writes and reads are allowed. This protection mode is good to be used at the time of development when device does not need to be given to any 3rd party. This mode should not be used for production.

Factory Upgrade mode: This protection mode is useful in the systems where individual flash blocks need to be updated by an external programmer. This protection mode does not allow external reads. However, external writes, internal reads, and internal writes are allowed. If a particular block needs to be updated by an external programmer without erasing the entire memory, this is the mode to be used.

One of the examples where this mode is useful is a system that needs to be calibrated by a customer/installation team, and needs to store this calibration data in flash. Though this upgrade is useful in such a system, this mode must be avoided if a higher security mode can be used. The reason is the lack of protection against an external write.

If someone inserts the code in the upgradable area to read the flash, it will make IP unprotected. However, in these devices this security level can be assigned only to specific blocks and a higher security level can be assigned to others. So, it must be ensured that only non-critical code is saved in these blocks.

Field Upgrade mode: This protection mode disables external writes and reads. Internal writes and reads are allowed. It is not possible to read/write flash from a programmer interface. This mode fits best for systems that need bootloading support. In bootloader-based embedded systems, the bootloader program receives flash data to be written by means of a communication protocol and then writes to flash using an internal program.

Similarly, a read operation is performed using internal commands. So, flash is read only if the bootloader wants to do so. The bootloader program can be stored in the blocks that have a higher security level (full protection mode) so that the bootloader program itself cannot be modified. Addition of encryption to bootloader communication can further help in reducing the chances of flash reads.

Full Protection mode: This protection mode is ideal for production if flash blocks do not need to be upgraded in the field or use internal programs. This mode prevents access to the flash in any way possible. Internal as well as external read and write are disabled in this mode.

An appropriate protection level must be set by the system designer while generating the hex file to be programmed in the production ready systems. The system designer must consider all possible ways to implement maximum IP security.

In a system where different sections of flash need to be assigned different protection levels, it is good to check at what flash granularity protection can be set. Some microcontrollers allow only one protection level for flash. Some devices allow block sizes of a few kB each and some as small as 64 bytes. Using a device that divides flash into small blocks allows a minimum of required flash area to be kept under lesser protection compared to others. Otherwise, it either results in waste of flash or exposing more flash content to safety threat.

Hiding analog and digital resources and their interconnection
SomeOEMs put tar or epoxy on PCBs to make it tougher for competitors toread part numbers. For high-volume systems, it is possible to get custompart numbers printed on ICs. Custom part numbers also make it hard tofind the actual part number. However, none of these approaches isfoolproof.

Competitors can track down various connections,observe signals on various pins, and find out the parts used in thedesign. Finding how various blocks are connected on a PCB is not a hardthing to do. The only solution for hiding various peripherals and theirinterconnection is to hide these things physically. For example, if allconnections can be hidden inside a single chip, it becomes moredifficult to understand the signal chains and to determine theperipherals used in the system.

Considering the fact thatintegration of peripherals in a single chip helps in hidinghardware-related information, system-on-chip (SoC) devices are the bestwhen it comes to protection against reverse engineering. However, someSoCs have dedicated pins that provide a reverse engineering loophole;i.e., when dedicated pins are provided on the devices for peripherals,it is easy to determine the peripheral used. So, using a SoC that hasflexible routing capability and allows any peripheral to be connected toany pin provides better security against reverse engineering.

Let us look at three high-level implementation examples for the e-Bike control system shown in Figures 3 (a), 3(b), and 3(c) (These are very high level block diagrams. For the sake of simplicitythey do not include various other components on the PCB). Theseimplementations are:

  • Figure 3(a): Using individual blocks that are soldered on a printed circuit board
  • Figure 3(b): Using an SoC with dedicated peripheral pins
  • Figure 3(c): Using an SoC with flexible I/O routing

Figure 3(a): Individual component based implementation

Figure 3(b): SoC with dedicated peripheral pins

Figure 3(c): SoC with flexible I/O routing based implementation

Ifan engineer is given these three PCBs to be reverse engineered thatimplement the same system in three different ways, which one will bereverse engineered quickly? The obvious answer is the implementationshown in figure 3(a) as everything is exposed on the PCB. It will takelonger to reverse engineer the implementation shown in figure 3(b). Butstill it is possible to get a high-level idea of the implementation.

However,for the implementation based on Figure 3(c) it will be tough orimpossible to determine the implementation as it is more like a blackbox that takes some inputs and gives some outputs. There is no way tofind out the analog signal chain implemented in the system as this SoCallows all peripherals to be connected to any pin and internallyperipherals can be connected to each other without using any physicalpin. Also, protection logic cannot be determined as there is nodedicated pin used for the programmable logic.

The only possibleway to reverse engineer this solution is to read the registers thatdecide the connections between the peripherals and pins. But thewould-be IP thief must go through the challenge of reading the flash todo it. If someone is able to break the flash’s security or if the systemdesigner has failed to implement required flash protection, the signalchain can be determined if peripherals have fixed addresses, as in thecase of most MCUs.

Programmable SoC devices such as the PSoC 1provide the best possible security from this form of IP theft. Thesedevices use generic analog and digital blocks along with programmablerouting. Any peripheral can be implemented in the same generic block.For example, a programmable analog block can be used to implement aprogrammable gain amplifier (PGA), analog-to-digital convertor (ADC),comparator, filter, or even a capacitive sensing block. A programmabledigital block can be configured as a timer, counter, UART, PRSgenerator, or an SPI. Any of these blocks can be connected to any pin.

Allthis is decided by register values stored in flash and are loadedduring the boot process. The location where these values are stored inflash is not fixed and depends on the program. Also, location can bechanged by the system designer at the time of compilation. Beyond that,these values can be changed at run time to reconfigure these blocks toact as a different peripheral. For example, a block that was configuredas a programmable gain amplifier at start-up can be reconfigured to actlike a comparator or an ADC. So, it is almost impossible to reverseengineer the hardware resources used in the designs that are implementedusing these devices.

The threat of reverseengineering is the bitter reality of today’s world. For the success ofany product, IP security features must be added to the system to avoidunauthorized access to your IP. It is important to hide both hardwareand firmware implementation to achieve the highest level of security.

DifferentMCU manufacturers provide different methods to protect flash fromunwanted read/write. Security technique and effectiveness must beevaluated before selecting a device for the system. SoCs withprogrammable resources and programmable routing abstract all thelow-level implementation of the system and expose only a black box thatis almost impossible to reverse engineer.

Sachin Gupta is a Senior Applications Engineer with Cypress Semiconductor. He holds adiploma in Electronics and Communications from Vaish TechnicalInstitute and a Bachelors in Electronics and Communications from GuruGobind Singh Indarprastha University, Delhi. He works with various SoCproducts and specializes in capacitive sensing and embeddedapplications. He is also expert in board layout reviews for good analogperformance and EMC/EMI issues. His areas of interest are mixed-signalapplications design and sensor interfacing. He can be reached at .

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.