protect software

This is kind of an in depth question and what you do will depend on how secure you need to be, the best security comes in the form of devices that have hardware security features however these are not widely available to the mass market as they require a large initial investment to create them unique to each customer. For a normal device you can use encryption mechanisms and thoughtful board design to lower the possibility of someone reverse engineering or hacking your board.

For example the first thing I would do from a hardware perspective is make the JTAG interface to your part hard to access if not buried in the PCB all together, if someone wants to read the data out of your part and your JTAG is exposed all they would need are the development tools and they could make a dump of the memory map. Blocking these will make it that much harder to gain access to the contents of the device, since it now means they would have to get into the software of the device some how to read out the data, or they would have to get a logic analyzer or capture device of some sort on the data bus to see what actually comes out of the memory. The downside of doing this is that it could limit your ability to debug the board if you run into trouble during production so you have be relatively confident with your design.

Additionally if the device can be booted out of an external mechanism such as over USB, SD Card, or UART you may want to block those out unless you need them for your application, if the hacker can somehow get the device into an alternate boot mode (by modifying the value on the boot pins) they could take control over the device over one of these interfaces, similar to the JTAG though arguably much more difficult. Of course if you block your JTAG and all your other alternate boot interfaces and somehow your board stops booting your only option would be to burn a new flash chip and remount it to the board, so again you must balance maintainability with security.

From a software perspective you could put an encryption algorithm in your boot code, so that the bulk of your application is not readily available to read out of flash. The downside of this is that it will take some effort to develop a proper procedure to verify the application and decrypt it, as well as potentially additional time to actually perform the decryption at boot time. This is also still vulnerable if the hacker is able to gain emulation access or boot their own code to the device, as they would be able to read your boot loader and reverse engineer the decryption algorithm so it is not totally secure but adds another layer of deterrence.

I am certain there are more in depth ways to protect your software so you may want to contact a consultant, these are just some thoughts that come up from my experience trying to answer this question in the past, without a custom secure type device I do not know of a highly hack proof solution (I am sure there is some way to get into almost any type of security).

Dear Bernie,
thank you very much.

Bernie Thompson said:

From a software perspective you could put an encryption algorithm in your boot code, so that the bulk of your application is not readily available to read out of flash. The downside of this is that it will take some effort to develop a proper procedure to verify the application and decrypt it, as well as potentially additional time to actually perform the decryption at boot time. This is also still vulnerable if the hacker is able to gain emulation access or boot their own code to the device, as they would be able to read your boot loader and reverse engineer the decryption algorithm so it is not totally secure but adds another layer of deterrence.

Hello, this topic seems very interesting to me. I would like to know a little more about it. I am using dm6437, but I do not understand well how an encryption algorithm could be added to my boot code. Should be this added to the .ais file? I mean, from my point of view, boot loader can't be modified as it resides in rom memory of DSP. So I think it should be done in the .ais boot image file, is this right? But I find this very easy to hack, reading the whole flash I would obtain all I need to hack it (I do know if this is exactly what Bernie was refering too).

Could someone give me some hints about this?

Thanks in advance

James Thorton said:

Should be this added to the .ais file? I mean, from my point of view, boot loader can't be modified as it resides in rom memory of DSP. So I think it should be done in the .ais boot image file, is this right?

This would be added to the .ais file, though at the point you have your own decrypting boot loader you may as well just have the boot loader in ais format since the rest of the program would be decrypted by by this boot loader you could leave it as a seperate segment of flash outside of the ais image (i.e. you write two images to flash, an ais decrypter/loader and the encrypted application image).

James Thorton said:

But I find this very easy to hack, reading the whole flash I would obtain all I need to hack it (I do know if this is exactly what Bernie was refering too).

This is true, which is why this is just a way to obfuscate the code to make it less obvious how it works, more of a pickett fence than a solid barrier to a real hacking attempt. All this is doing is making it so that if the memory itself is read somehow that the actual application would not be directly readable/disassemblable, so the hacker would have to realize that there is encryption and find the code in the decrypter/loader to reverse engineer the system. How much effort it would take to hack would be dependent on how complex your decrypter is, there would be minimal prevention of a hacker just outright copying the flash image, though you could have the decrypter do some hardware integrity check before decrypting, or make the decryption dependent on some of your own specific hardware (i.e. read a key value from something obscure on your board for the decryption).

Bernie Thompson said:

This would be added to the .ais file, though at the point you have your own decrypting boot loader you may as well just have the boot loader in ais format since the rest of the program would be decrypted by by this boot loader you could leave it as a seperate segment of flash outside of the ais image (i.e. you write two images to flash, an ais decrypter/loader and the encrypted application image).

           Where I can find more information about to write my own bootloader and using two ais image as you describe? I have been surfing in the ti.com but I have not be able to find any revelant document.

James Thorton said:

Where I can find more information about to write my own bootloader and using two ais image as you describe?

The second image would not have to be ais, it could be whatever format you want if you write your own boot loader. There is not much documentation out there on multi stage encrypted boot loading, this is largely left up to the end developer, the main document to reference for DM643x booting in general is SPRAAG0d.