Hardware Protection

From Texas Instruments Embedded Processors Wiki

Jump to: navigation, search

Translate this page to

Which hw protection features are available on the platform?

The DM644x, along with the other DaVinci and C6000 family of devices, does not support in hardware any kind of code protection features, nor supports encryption, burning or storing a private encryption key inside the device (in order to use it for decrypting application code / data stored externally).

Additionally, there are no specific security features to protect DSP code or to disable the JTAG.

What could I do to add some hardware protection features on the platform?

If the JTAG pins are easily available on the board then it will not be difficult for somebody to connect an emulator to the device and watch or dump the code via the debugger. Avoiding routing out the JTAG pins on the final product will prevent this as pins are under the chip (BGA package) but of course make impossible field debugging.

The same as for JTAG applies to the boot mode pins. Avoid exposing them so that executing any third party programs on your system will be harder to accomplish.

Embed the critical storage components like the flash and the ext memory in a protective strata of suitable materials, when possible, like perhaps epoxy (to avoid physical access). This might further benefit for general physical stress conditions like mechanical strains.

Make use of BGA packages and avoid routing the memory interface pins to the outer layers of the PCB.

Use an asymmetric encryption algorithm for ciphering the more sensitive parts your code and patch the flash image with the key before flashing. This saves you from storing the private key in some external device that might be more easier to compromise. Further that increases the complexity level of the system a bit thus this will raise the challenge level for some of the attack methods.

When there is an EMAC on the chip then this will have an unique id bound tho it. This ID could be used as key data fed into a symmetric cipher/decipher algorithm for use as a key.

Prevent your software to work on other (copied) hardware by making your application access a specific hardware address to read out a value (for example a register setup in an external device or a set of specially driven GPIOs). If the correct value is not read then the software just exits. This will provide a little barrier on the lesser educated third party cloning approaches for your device.

Download the application image via the EMAC (from the network) will avoid the software

being saved locally on the board. In such a case you might further need to consider some counter measures for any sort of listener like a sniffer program on the network media.

What else does impact on such a protection?

Since the device is a dual core and further offers several boot scenarios so the basic system complexity is not that low on its own. On the one side it might impose a barrier for some approaches, on the other side it widens the attacking options and thus the counter measures to think of. Consider this aspect of the hardware design level of the system and see at which extent the protection might be needed.

The fact of having the ARM side running Linux, might provide some sophisticated application level features in respect to encryption and system self checking in terms of system integrity. But having Linux as a general purpose OS like many other running there will mean having several connectivity services running there and thus exposing some more or less critical long term software modules for functional reasons that might be abused for breaking up protection in the life system.

On the DaVinci and OMAP specific software side, instantiation and run of the DSP algorithms is supported by means of the codec engine framework, which means that the ARM application will be in full control of the DSP. However this framework does not consider having encryption features so this is something you will have to consider at the application level. It will not be possible to modify the codec engine framework to include encryption features, since it is provided for free but not as source, only as a library.

Third party comercials digging such subjects are:

An alternative is to check some TI Third Party company (see http://focus.ti.com/dsp/docs/dspsupporto.tsp?sectionId=3&tabId=1459) that might be able to provide some code additional security features.

The final truth:

Be aware that there are rather special but legal companies on public markets that are even in state of really opening a chip case, operating your system on their likes and getting hands on any sort of semi conductor element including one-time fuses thus altering their states, and up to even the removal of any self-destructive alike add-on, e.g. some acid enclosure.

This means no chip based can ever be really protected regardless of how much efforts you have spent. When physical control on your device can be achieved by a skilled or educated party then it wont keep any of its secrets for too long. Spending more efforts on your side will just force any attacker to grow his efforts as well so you are only relatively reasonably protected from people that cant play on par with you.

But there is always the chance that you have overseen some aspect and there is a specific gap in your design that might enable many others to relatively simply break protection. So be advised for doing intense peer reviews on your whole design and for even planning forward applying more advanced means for the case that a compromising situation does happen, gets more likely, or just less unlikely by the general advance of times.