Shredding confidential code

Jimmy Song

Other Parts Discussed in Thread: TMS320DM6437

Hello All,

I have a question on the security of code that has been loaded into the evaluation board:

How can one permenantly shred binary code that has been loaded to the evaluation board? I mean "shred" in the way of those professional data security software, for example, PGP, rathe than merely "overwrite" or otherwise "delete" the content from the file system. Because in PC environment the execution of "del (delete)" DOS (or Windows command console) command merely remove the file's entry from file system while the acutal data content still remains on the disk, and therefore susceptible to malicious recovery attempts.

It might only involve privacy issues for PCs that are for personal use, but in DSP development if the evaluation board get into the hands of people with malicious intent, I wonder if by using specialized tools they can recover the binary code from the board. The code, even compiled into the binary form, can be valuable and confidential. I therefore would like to know how this possibility (recovery) can be completely eliminated.

In PC this is usually easy with PGP or other data security software's shredding function.
In CCS, does there exist a similar function, in which version?
If CCS doesn't , does TI provide separate software utility to do this?
If this cannot be done by software, is there any physical means to achieve this (by UV, for example)? Does TI provide such device or service? How much is the charge?

I sincerely appreciate any one who would provide the helpful answer.

Jim

over 14 years ago

0 JohnS over 14 years ago

TI__Guru**** 162305 points

Jim,

CCS doesn't have any specific features to help with this. Some devices come with security features to prevent this sort of thing. What devices are you considering? I could move your post into one of the device forums where the experts on the security features of the device could answer.

Regards,

John

0 Jimmy Song over 14 years ago in reply to JohnS

Intellectual 330 points

Dear John,

I am using a DM6437 EVM.

Does compiled binary code stored inside CPU, or on DDR2 memory on the memory that is connected to the CPU?
In what situation among the above two, if CCS do support shredding, can the program be shredded?

Sincerely,

Jim

0 JohnS over 14 years ago in reply to Jimmy Song

TI__Guru**** 162305 points

Jim,

CCS does not support shredding.

I am going to move the thread into a C6000 device forum to see if they have any ideas on how to help with this.

Regards,

John

0 Jimmy Song over 14 years ago in reply to JohnS

Intellectual 330 points

Dear John,

Thanks very much for help.

Jim

0 Brad Griffis over 14 years ago in reply to Jimmy Song

TI__Guru*** 125430 points

Jimmy Song said:

I am using a DM6437 EVM.

Does compiled binary code stored inside CPU, or on DDR2 memory on the memory that is connected to the CPU?

In what situation among the above two, if CCS do support shredding, can the program be shredded?

Just to make sure we're all on the same page, did you actually use flashburn or your own utility to take your application and burn it to the flash? If so, I'd recommend just erasing the flash. That will physically set every bit to a 1. I think only the NSA could recover your program at that point!

If you never actually wrote your program to flash you don't need to do anything (if that wasn't apparent).

0 Jimmy Song over 14 years ago in reply to Brad Griffis

Intellectual 330 points

Dear Brad,

Brad Griffis said:

Just to make sure we're all on the same page, did you actually use flashburn or your own utility to take your application and burn it to the flash? If so, I'd recommend just erasing the flash. That will physically set every bit to a 1. I think only the NSA could recover your program at that point!

No Brad, I am only using CCS 4's "connecting to target" through XDS560 emulator. Where will the binary data be stored? Will it be inside or outside the CPU (DDR2, flash) ?

linker.cmd said:

-stack          0x00000800      /* Stack Size */
-heap           0x00000800      /* Heap Size */

MEMORY
{
    L2RAM:      o = 0x10810000 l = 0x00020000
    DDR2:       o = 0x80000000 l = 0x1000000
}

SECTIONS
{
    vectors        >        0x80000000, RUN_START(_ISTP_START)
    .bss        >   DDR2
    .cinit      >   DDR2
    .cio        >   DDR2
    .const      >   DDR2
    .data       >   DDR2
    .far        >   DDR2
    .stack      >   DDR2
    .switch     >   DDR2
    .sysmem     >   DDR2
    .text       >   DDR2
/* .ddr2       >   DDR2*/
}

This is my linker file. It seems that text (program) and data section are stored into DDR2. Does this mean I have to shred DDR2? It might be a silly question, because DDR2 is a a type of SDRAM, which ultimately is a random-access-memory which does not retain its bits' value after losing power. So the assurance for confidentiality comes immediately when I plugged the power cable off?

Is this correct?

Alternatively, if I write like this:

linker.cmd with .text and .data section stored in FLASH said:

MEMORY
{
    L2RAM:      o = 0x10800000 l = 0x00020000
    DDR2:       o = 0x80000000 l = 0x10000000
   Flash:       o = 0x90000000 l = 0x00400000

}

SECTIONS
{
    vectors        >        0x80000000, RUN_START(_ISTP_START)
    .bss        >   DDR2
    .cinit      >   DDR2
    .cio        >   DDR2
    .const      >   DDR2
    .data       >   flash
    .far        >   DDR2
    .stack      >   DDR2
    .switch     >   DDR2
    .sysmem     >   DDR2
    .text       >   flash
/* .ddr2       >   DDR2*/
}

In this situation, do I have to erase the flash content as you have mentioned?

Jim

0 Brad Griffis over 14 years ago in reply to Jimmy Song

TI__Guru*** 125430 points

Jimmy Song said:
Does this mean I have to shred DDR2?

Once the DDR controller stops refreshing it all the values disappear! Personally I don't think you need to do anything at all.

Jimmy Song said:

Alternatively, if I write like this:

MEMORY
{
    L2RAM:      o = 0x10800000 l = 0x00020000
    DDR2:       o = 0x80000000 l = 0x10000000
   Flash:       o = 0x90000000 l = 0x00400000

}

SECTIONS
{
    vectors        >        0x80000000, RUN_START(_ISTP_START)
    .bss        >   DDR2
    .cinit      >   DDR2
    .cio        >   DDR2
    .const      >   DDR2
    .data       >   flash
    .far        >   DDR2
    .stack      >   DDR2
    .switch     >   DDR2
    .sysmem     >   DDR2
    .text       >   flash
/* .ddr2       >   DDR2*/
}

In this situation, do I have to erase the flash content as you have mentioned?

[/quote]

Well, that's not how you would put your data into flash. There's a tool called HexAIS that would take your original out file as an input and then it would generate an "AIS" table which would get written to flash using a tool such as flashburn. In that scenario you would need to erase the flash, and if you're really paranoid you might want to do something where you write random data back into the flash and erase it again. Though personally I don't think that's necessary...

0 Jimmy Song over 14 years ago in reply to Brad Griffis

Intellectual 330 points

Dear Brad,

Brad Griffis said:

Well, that's not how you would put your data into flash. There's a tool called HexAIS that would take your original out file as an input and then it would generate an "AIS" table which would get written to flash using a tool such as flashburn. In that scenario you would need to erase the flash, and if you're really paranoid you might want to do something where you write random data back into the flash and erase it again. Though personally I don't think that's necessary...

What happens if I build the project with this "not the right way" linker.cmd file, which specifies .text sections to the flash address, and uses no HexAIS or flashburn at all?

Will any data be written?
Will I get only garbage/broken data on the flash?
Is using HexAIS combination, or similar utilities, a MUST if one wants to write data to flash?
Do you recommend writing executable code to flash instead of ROM? In terms of run-time speed, which is faster? Economically, which is cheaper?

Jim

0 Brad Griffis over 14 years ago in reply to Jimmy Song

TI__Guru*** 125430 points

Jimmy Song said:
What happens if I build the project with this "not the right way" linker.cmd file, which specifies .text sections to the flash address, and uses no HexAIS or flashburn at all?

When you try to load the program CCS will give you a "data verification error" because it will attempt to write the data to flash but will fail miserably. Nothing at all will get written because CCS will not execute the precise sequence of commands necessary to initiate a write to NOR flash. It will do a simple "write" (which will fail completely) followed by a read which will then trigger the data verification error.

0 Jimmy Song over 14 years ago in reply to Brad Griffis

Intellectual 330 points

Dear Brad,

Brad Griffis said:

Nothing at all will get written because CCS will not execute the precise sequence of commands necessary to initiate a write to NOR flash.

If this is due to CCS's inability in writing directly to NOR flash, can CCS write directly to ROM? I noticed that on SPRS345d, TMS320DM6437 Digital Media Processor (Rev. D), p. 14, there are addresses starting from

0x0010 0000 to 0x0010 FFFF, 64k
0x1010 0000 to 0x1010 FFFF, 64k

are boot ROM. In debugging scenario which all my source code, vector.asm, linker.cmd as well as referenced libraries are compiled and loaded into the chip by CCS 4, are these boot ROM used? If they are used, what exactly is the "booting" process here? Can CCS write directly to them? Do I require a special device in order to write on them? Are they erasable? Are they (the boot ROM) the only ROM with in a C6000 chip?

Sincerely,

Jim

0 Brad Griffis over 14 years ago in reply to Jimmy Song

TI__Guru*** 125430 points

ROM = Read Only Memory

This is part of our fabrication process so there is no possible way to overwrite it. Only TI can change the boot ROM and that would be through a manufacturing change, i.e. a device revision.

0 Jimmy Song over 14 years ago in reply to Brad Griffis

Intellectual 330 points

Dear Brad,

The question is now resolved. Thanks very much.

Jim

Processors

Processors forum

Shredding confidential code