Hi,
Right now I'm working on a board based on a C6748 Dsp and I'd like to now if there is any code protection feature like:
- Preventing Dsp memory read from CCS via an emulator (Xds100 etc...)
- Disabling emulator connection
-....
Thank's in advance for youre help
Bruno
Bruno,
Which version of CCS are you using?
CCS will only do memory reads when you tell it to. This is done when you click Refresh or use the Continuous Refresh feature. Avoid Continuous Refresh and do not click Refresh, then there will not be any CCS memory reads while the DSP is running.
Is this what you are asking about, or are you talking about security modes that might prevent someone else from using an emulator to view your program? For the security modes, please refer to Secure Boot in the datasheet and User Guides.
Regards,RandyP
If you need more help, please reply back. If this answers the question, please click Verify Answer , below.
Search for answers, Ask a question, click Verify when complete, Help others, Learn more.
Hi Randy
Thank you for youre quick reply. and for all the information
In fact I was considering the second issue (security modes) which is new to me.
I've found and downloded the tools and I'll investigate the subject.
Regards,
Hi Randy,
I'm back into Security. I went a little further in the subject but now I'm stuck: the C6748 hangs in booting my Encrypted piece of code from Spiflash.
Here is what I've done:
I've first generated a Secure Code.bin file from a working .out executable code (Code.out) using SecureHexAIS_OMAP-L138.exe
Seems to work fine although I'm not sure of all the parameters I've set (I'm especially wondering about all different Die releases like D800K002 etc...)
I then downloaded the Code.bin file using "sfh_OMAP-L138.exe" after erasing the Flash : seems OK...
And I finaly reset and restarted the Dsp but it hangs somewhere...
- Is there something wrong with my programming sequence?
- is there something wrong with my .ini File?
- Something else?
rem1: I need the DDR to be initialized at boot for code placement
rem2: the .out file is not stripped and has Debug info in it.
Please find below the content of the .ini file as well as a screenshot of SecureHexAIS_OMAP-L138.exe execution
regards,
___________________________________________________________________________
//Start Of File OMAP-L138_generic_secure.ini:
; General settings that can be overwritten in the host code; that calls the AISGen library.[General]; SPIMASTER,I2CMASTER,EMIFA,NAND,EMAC,UART,PCI,HPI,USB,MMC_SD,VLYNQ,RAWBootMode=SPIMASTER; NO_CRC,SECTION_CRC,SINGLE_CRCcrcCheckType=NO_CRC;__________________________________________________________;BSR Add Start:; Security settings (keys, options, list of sections to encrypt, etc.)[Security]; Security Type: GENERIC, CUSTOM, NONEsecurityType=GENERIC; Boot Exit Type: NONSECURE, SECUREWITHSK, SECURENOSK; NONSECURE = Device switches from secure type to non-secure type, jumping to loaded code ; (no secure kernel since no longer secure device).; SECUREWITHSK = Device remains as secure type, secure kernel is loaded, allowing run-time; security context switching.bootExitType = NONSECURE; Option to include in the generated key header the flag to force the JTAG off;genericJTAGForceOff=FALSE; Encrypt section list (ALL or comma-separated list of section names)encryptSections=ALL; CEK used for AES encryption of data - must be string of 32 hexadecimal charactersencryptionKey=4A7E1F56AE545D487C452388A65B0C05; Debug key;keyEncryptionKey=0B94A91D33E597097F6C426F8F016872; SHA Algorithm SelectiongenericSHASelection = SHA256; Binary file containing secure key header for generic device;genKeyHeaderFileName=key_hdr_sha256_enc.bin;BSR_Add End;__________________________________________________________; This section allows setting the PLL0 system clock with a ; specified multiplier and divider as shown. The clock source; can also be chosen for internal or external.; |------24|------16|-------8|-------0|; PLL0CFG0: | CLKMODE| PLLM | PREDIV | POSTDIV|; PLL0CFG1: | RSVD | PLLDIV1| PLLDIV3| PLLDIV7|[PLL0CONFIG]PLL0CFG0 = 0x00180001PLL0CFG1 = 0x00000205; This section allows setting up the PLL1. Usually this will ; take place as part of the EMIF3a DDR setup. The format of; the input args is as follows:; |------24|------16|-------8|-------0|; PLL1CFG0: | PLLM| POSTDIV| PLLDIV1| PLLDIV2|; PLL1CFG1: | RSVD | PLLDIV3|;[PLL1CONFIG];PLL1CFG0 = 0x00000000;PLL1CFG1 = 0x00000000; This section lets us configure the peripheral interface; of the current booting peripheral (I2C, SPI, or UART).; Use with caution. The format of the PERIPHCLKCFG field ; is as follows:; SPI: |------24|------16|-------8|-------0|; | RSVD |PRESCALE|;; I2C: |------24|------16|-------8|-------0|; | RSVD |PRESCALE| CLKL | CLKH |;; UART: |------24|------16|-------8|-------0|; | RSVD | OSR | DLH | DLL |;[PERIPHCLKCFG];PERIPHCLKCFG = 0x00000000;********************************************************************************;******************************* 132 MHz DDR settings ***************************;********************************************************************************; This section can be used to configure the PLL1 and the EMIF3a registers; for starting the DDR2 interface. ; See PLL1CONFIG section for the format of the PLL1CFG fields.; |------24|------16|-------8|-------0|; PLL1CFG0: | PLL1CFG |; PLL1CFG1: | PLL1CFG |; DDRPHYC1R: | DDRPHYC1R |; SDCR: | SDCR |; SDTIMR: | SDTIMR |; SDTIMR2: | SDTIMR2 |; SDRCR: | SDRCR |; CLK2XSRC: | CLK2XSRC |[EMIF3DDR]PLL1CFG0 = 0x15010001PLL1CFG1 = 0x00000002DDRPHYC1R = 0x000000C4SDCR = 0x0A034622SDTIMR = 0x184929C8SDTIMR2 = 0xB80FC700SDRCR = 0x00000406CLK2XSRC = 0x00000000;********************************************************************************;******************************* 150 MHz DDR settings ***************************;********************************************************************************; This section can be used to configure the PLL1 and the EMIF3a registers; for starting the DDR2 interface. ; See PLL1CONFIG section for the format of the PLL1CFG fields.; |------24|------16|-------8|-------0|; PLL1CFG0: | PLL1CFG |; PLL1CFG1: | PLL1CFG |; DDRPHYC1R: | DDRPHYC1R |; SDCR: | SDCR |; SDTIMR: | SDTIMR |; SDTIMR2: | SDTIMR2 |; SDRCR: | SDRCR |; CLK2XSRC: | CLK2XSRC |;[EMIF3DDR];PLL1CFG0 = 0x18010001;PLL1CFG1 = 0x00000002;DDRPHYC1R = 0x000000C4;SDCR = 0x0A034622;SDTIMR = 0x1C912A08;SDTIMR2 = 0x3811C700;SDRCR = 0x00000494;CLK2XSRC = 0x00000000[INPUTFILE]FILENAME=Code.outENCRYPT=TRUE
//End of File OMAP-L138_generic_secure.ini
//Start of SecureHexAIS_OMAP-L138.exe:
SecureHexAIS_OMAP-L138.exe -ini OMAP-L138_EVM_spi_Secure.ini Code.out (command line)----------------------------------------------------- TI Secure AIS Hex File Generator for OMAP-L138 (C) 2011, Texas Instruments, Inc. Ver. 1.25-----------------------------------------------------Creating boot image for a generic secure device.INFO: Boot exit type has been selected as NONSECURE.WARNING: Encrypted Key Header data is absent - generating plaintext version. The Customer Encryption Key will be transferred in plaintext!INFO: Current SHA algorithm is SHA256.Begining the Secure AIS file generation.AIS file being generated for bootmode: SPIMASTER. Signature Hash: D7-3A-83-76-D6-67-16-03-30-3E-71-C5-24-82-C8-60-9D-27-42-15-74-F0-13-15-B4-2E-18-FC-B0-F2-59-C7 Signature Byte Count = 64 Signature Hash: 29-01-20-03-DC-FE-25-B6-B0-E3-13-A4-4B-F1-96-EC-C8-13-37-5E-3C-72-48-45-3A-C9-96-55-CB-0C-DC-63 Signature Byte Count = 40Parsing the input object file, Code.out.Encrypting section .text, since ALL was specified for encryptSections in ini file.Encrypting section .const, since ALL was specified for encryptSections in ini file.Encrypting section .bios, since ALL was specified for encryptSections in ini file.Encrypting section .cinit, since ALL was specified for encryptSections in ini file.Encrypting section .args, since ALL was specified for encryptSections in ini file.Encrypting section .gblinit, since ALL was specified for encryptSections in ini file.Encrypting section .rtdx_text, since ALL was specified for encryptSections in ini file.Encrypting section .sysinit, since ALL was specified for encryptSections in ini file.Encrypting section .switch, since ALL was specified for encryptSections in ini file.Encrypting section .hwi_vec, since ALL was specified for encryptSections in ini file.Encrypting section .trace, since ALL was specified for encryptSections in ini file.Encrypting section .sts, since ALL was specified for encryptSections in ini file.Encrypting section .log, since ALL was specified for encryptSections in ini file.Encrypting section .pinit, since ALL was specified for encryptSections in ini file.Encrypting section .trcdata, since ALL was specified for encryptSections in ini file.Parsing the input object file, Code.out. Signature Hash: 03-44-ED-AC-C6-F9-90-FA-BB-1E-BC-5A-45-29-3F-97-0C-10-45-D8-F3-7E-2A-2D-42-9C-74-41-61-B3-B7-31 Signature Byte Count = 233360AIS file generation was successful.Wrote 233580 bytes to file Code.bin.Conversion is complete.
End of SecureHexAIS_OMAP-L138.exe:
Bruno Scherrer Hi Randy, I'm back into Security. I went a little further in the subject but now I'm stuck: the C6748 hangs in booting my Encrypted piece of code from Spiflash. Here is what I've done: I've first generated a Secure Code.bin file from a working .out executable code (Code.out) using SecureHexAIS_OMAP-L138.exe Seems to work fine although I'm not sure of all the parameters I've set (I'm especially wondering about all different Die releases like D800K002 etc...) I then downloaded the Code.bin file using "sfh_OMAP-L138.exe" after erasing the Flash : seems OK... And I finaly reset and restarted the Dsp but it hangs somewhere... - Is there something wrong with my programming sequence? - is there something wrong with my .ini File? - Something else? rem1: I need the DDR to be initialized at boot for code placement rem2: the .out file is not stripped and has Debug info in it. Please find below the content of the .ini file as well as a screenshot of SecureHexAIS_OMAP-L138.exe execution regards, Bruno ___________________________________________________________________________ //Start Of File OMAP-L138_generic_secure.ini: ; General settings that can be overwritten in the host code; that calls the AISGen library.[General]; SPIMASTER,I2CMASTER,EMIFA,NAND,EMAC,UART,PCI,HPI,USB,MMC_SD,VLYNQ,RAWBootMode=SPIMASTER; NO_CRC,SECTION_CRC,SINGLE_CRCcrcCheckType=NO_CRC;__________________________________________________________;BSR Add Start:; Security settings (keys, options, list of sections to encrypt, etc.)[Security]; Security Type: GENERIC, CUSTOM, NONEsecurityType=GENERIC; Boot Exit Type: NONSECURE, SECUREWITHSK, SECURENOSK; NONSECURE = Device switches from secure type to non-secure type, jumping to loaded code ; (no secure kernel since no longer secure device).; SECUREWITHSK = Device remains as secure type, secure kernel is loaded, allowing run-time; security context switching.bootExitType = NONSECURE; Option to include in the generated key header the flag to force the JTAG off;genericJTAGForceOff=FALSE; Encrypt section list (ALL or comma-separated list of section names)encryptSections=ALL; CEK used for AES encryption of data - must be string of 32 hexadecimal charactersencryptionKey=4A7E1F56AE545D487C452388A65B0C05; Debug key;keyEncryptionKey=0B94A91D33E597097F6C426F8F016872; SHA Algorithm SelectiongenericSHASelection = SHA256; Binary file containing secure key header for generic device;genKeyHeaderFileName=key_hdr_sha256_enc.bin;BSR_Add End;__________________________________________________________; This section allows setting the PLL0 system clock with a ; specified multiplier and divider as shown. The clock source; can also be chosen for internal or external.; |------24|------16|-------8|-------0|; PLL0CFG0: | CLKMODE| PLLM | PREDIV | POSTDIV|; PLL0CFG1: | RSVD | PLLDIV1| PLLDIV3| PLLDIV7|[PLL0CONFIG]PLL0CFG0 = 0x00180001PLL0CFG1 = 0x00000205; This section allows setting up the PLL1. Usually this will ; take place as part of the EMIF3a DDR setup. The format of; the input args is as follows:; |------24|------16|-------8|-------0|; PLL1CFG0: | PLLM| POSTDIV| PLLDIV1| PLLDIV2|; PLL1CFG1: | RSVD | PLLDIV3|;[PLL1CONFIG];PLL1CFG0 = 0x00000000;PLL1CFG1 = 0x00000000; This section lets us configure the peripheral interface; of the current booting peripheral (I2C, SPI, or UART).; Use with caution. The format of the PERIPHCLKCFG field ; is as follows:; SPI: |------24|------16|-------8|-------0|; | RSVD |PRESCALE|;; I2C: |------24|------16|-------8|-------0|; | RSVD |PRESCALE| CLKL | CLKH |;; UART: |------24|------16|-------8|-------0|; | RSVD | OSR | DLH | DLL |;[PERIPHCLKCFG];PERIPHCLKCFG = 0x00000000;********************************************************************************;******************************* 132 MHz DDR settings ***************************;********************************************************************************; This section can be used to configure the PLL1 and the EMIF3a registers; for starting the DDR2 interface. ; See PLL1CONFIG section for the format of the PLL1CFG fields.; |------24|------16|-------8|-------0|; PLL1CFG0: | PLL1CFG |; PLL1CFG1: | PLL1CFG |; DDRPHYC1R: | DDRPHYC1R |; SDCR: | SDCR |; SDTIMR: | SDTIMR |; SDTIMR2: | SDTIMR2 |; SDRCR: | SDRCR |; CLK2XSRC: | CLK2XSRC |[EMIF3DDR]PLL1CFG0 = 0x15010001PLL1CFG1 = 0x00000002DDRPHYC1R = 0x000000C4SDCR = 0x0A034622SDTIMR = 0x184929C8SDTIMR2 = 0xB80FC700SDRCR = 0x00000406CLK2XSRC = 0x00000000;********************************************************************************;******************************* 150 MHz DDR settings ***************************;********************************************************************************; This section can be used to configure the PLL1 and the EMIF3a registers; for starting the DDR2 interface. ; See PLL1CONFIG section for the format of the PLL1CFG fields.; |------24|------16|-------8|-------0|; PLL1CFG0: | PLL1CFG |; PLL1CFG1: | PLL1CFG |; DDRPHYC1R: | DDRPHYC1R |; SDCR: | SDCR |; SDTIMR: | SDTIMR |; SDTIMR2: | SDTIMR2 |; SDRCR: | SDRCR |; CLK2XSRC: | CLK2XSRC |;[EMIF3DDR];PLL1CFG0 = 0x18010001;PLL1CFG1 = 0x00000002;DDRPHYC1R = 0x000000C4;SDCR = 0x0A034622;SDTIMR = 0x1C912A08;SDTIMR2 = 0x3811C700;SDRCR = 0x00000494;CLK2XSRC = 0x00000000[INPUTFILE]FILENAME=Code.outENCRYPT=TRUE ___________________________________________________________________________ //End of File OMAP-L138_generic_secure.ini ___________________________________________________________________________ //Start of SecureHexAIS_OMAP-L138.exe: SecureHexAIS_OMAP-L138.exe -ini OMAP-L138_EVM_spi_Secure.ini Code.out (command line)----------------------------------------------------- TI Secure AIS Hex File Generator for OMAP-L138 (C) 2011, Texas Instruments, Inc. Ver. 1.25-----------------------------------------------------Creating boot image for a generic secure device.INFO: Boot exit type has been selected as NONSECURE.WARNING: Encrypted Key Header data is absent - generating plaintext version. The Customer Encryption Key will be transferred in plaintext!INFO: Current SHA algorithm is SHA256.Begining the Secure AIS file generation.AIS file being generated for bootmode: SPIMASTER. Signature Hash: D7-3A-83-76-D6-67-16-03-30-3E-71-C5-24-82-C8-60-9D-27-42-15-74-F0-13-15-B4-2E-18-FC-B0-F2-59-C7 Signature Byte Count = 64 Signature Hash: 29-01-20-03-DC-FE-25-B6-B0-E3-13-A4-4B-F1-96-EC-C8-13-37-5E-3C-72-48-45-3A-C9-96-55-CB-0C-DC-63 Signature Byte Count = 40Parsing the input object file, Code.out.Encrypting section .text, since ALL was specified for encryptSections in ini file.Encrypting section .const, since ALL was specified for encryptSections in ini file.Encrypting section .bios, since ALL was specified for encryptSections in ini file.Encrypting section .cinit, since ALL was specified for encryptSections in ini file.Encrypting section .args, since ALL was specified for encryptSections in ini file.Encrypting section .gblinit, since ALL was specified for encryptSections in ini file.Encrypting section .rtdx_text, since ALL was specified for encryptSections in ini file.Encrypting section .sysinit, since ALL was specified for encryptSections in ini file.Encrypting section .switch, since ALL was specified for encryptSections in ini file.Encrypting section .hwi_vec, since ALL was specified for encryptSections in ini file.Encrypting section .trace, since ALL was specified for encryptSections in ini file.Encrypting section .sts, since ALL was specified for encryptSections in ini file.Encrypting section .log, since ALL was specified for encryptSections in ini file.Encrypting section .pinit, since ALL was specified for encryptSections in ini file.Encrypting section .trcdata, since ALL was specified for encryptSections in ini file.Parsing the input object file, Code.out. Signature Hash: 03-44-ED-AC-C6-F9-90-FA-BB-1E-BC-5A-45-29-3F-97-0C-10-45-D8-F3-7E-2A-2D-42-9C-74-41-61-B3-B7-31 Signature Byte Count = 233360AIS file generation was successful.Wrote 233580 bytes to file Code.bin.Conversion is complete. ___________________________________________________________________________ End of SecureHexAIS_OMAP-L138.exe:
Hello,
Are you sure your chip is a secure boot enabled one ? (those with an 'E' suffix, see p276 of data sheet sprs586d).
Jakez
You marked my first reply to you as an Answer to your question. Our factory experts are less likely to look at an Answered thread when they are looking for someone to help, so if that did not really answer your question, you can remove that mark. Or tell me and I can find someone who can remove it from the support team.
Your answer to Jakez's question may be crucial. Please include all of the device markings in your reply.
Randy, Jakez,
I'm afraid my chip does not support secure boot. The latest chip version we have is marked as:
TMS320C6748 BZCE
followed by these obscure symbols :
OBAEVXW GI 375 527 ZCE
Obviously there is no E suffix.
The thing is I've planed to make boot encryption work for mid of May the latest so my questions are:
- Do you know if the E suffic C6748 is already avaiIable? (If yes I'll call LogicPd asap to see if they can provide the right SOM)
- If not is there anything else I can do on my chip (like using Secure Kernel for at least encrypt sensible code/data parts) ?
Randy,
I've just removed the the mark you have talked about.
Hope everything's ok now...
Regards
I missed the fact you have a TMS320C6748 instread of OMAP-L138; the description of the code name is given p267 of sprs590d.pdf (secure boot devices not described on previous data sheet versions).
You can see the different versions effectively in production at http://www.ti.com/product/tms320c6748. The nearest secure boot equivalent (and available) for your chip should be TMS320C6748BZCEA3E (375 MHz).
It is difficult to secure a code without a dedicated chip (hence the reason for creating the 'E' versions). With a standard CPU booting on flash EPROM, the whole content of the flash will be accessible via the JTAG link and downloadable (if the JTAG link is broken, the flash can be desoldered and copied).
However, some techniques can make the cloning work significantly harder for the copist (but also for the designer), this one for example:
1. Find specific information bits in your hardware (unique 64-bit signature in some SPI flash ICs, version code of circuits in registers,...) and compute a crypt/decrypt key from them.
2. Encrypt sensible sections in your AIS file with a key that may be specific to a board or a run of boards.
3. At runtime, collect your specific information bits and compute the decrypt key. You will then be able to decrypt sensible code when necessary (relocate it through DMA rather than decrypt in-place, avoid doing that immediatly at starting, make the life harder for the copist).
4. Overwrite code that is no more used (initializations,...), span code sections (avoid a unique block), break the JTAG link if possible (cutting tracks,drilling vias, ...).
Inconvenients: specific information bits may be hard to find or may require a different key for each board; non negligeable additional software
Avantages: needs TMS320C64x assembler reverse engineering to be cracked, rather than simple flash copying
Hi Bruno
Bruno Scherrer Do you know if the E suffic C6748 is already avaiIable? (If yes I'll call LogicPd asap to see if they can provide the right SOM)
Yes C6748 Secure Boot enabled device (Suffix E) are available. I am not sure about the LogicPD SOM with secure device availability, I believe they do have it in stock, but it would be best to confirm from them.
Bruno Scherrer- If not is there anything else I can do on my chip (like using Secure Kernel for at least encrypt sensible code/data parts) ?
Not really, as Jakez explained, you would really need to get hold of the secure boot enabled devices to any meaningful development and debug to have a secure boot application based on these devices.
Mukul
Don't forget to verify answers to your forum questions by using the green "Verify Answer" button.
Hi Jakez, MukulI'm waiting for an answer from Logic, but considering the short time schedule I need to investigate seriously into a solution relying on a non secure chip.
My thougthts lead me to that point:In my design I have a host processor connected on Hpi which could actually download the first Bootstrap into the C6748.During the execution of this first Bootstrap the C6748 could:-deactivate JTAG access-load any encrypted code residing in Spi Flash, decrypt and execute.If this scenario does actually make sense, my new questions are (trying to be as clear as possible :-) :
1- Is there any source code for loading/decrypt AIS and SecureAIS bin files from Spi Flash on the C6748?
2- I'm wondering if/how I can encrypt only parts of an entire .out or .bin file if yes is the partial encryption based on objects (i.e .o files) on specific linker spaces (.text .data..) or on different .out files? I Guess in any case I need a kind of object file parser in order to do that (ie. placing code and Data in right place)...
3- I've downloaded the AES64plus_v1.00 folder and tried it on the C6748 and it seems to run. Question: do you provide a ready to use AES encrypt tool?4- (related to point 2): In fact I would like to know if there are some existing source code and doc explaining how to load an object file (ie placing code and Data based on object header file)
Regards Bruno
On a secure C6748 device, the application code is encrypted using a user provided encryption key(CEK) and the user encryption key is protected by a device specific encryption key(KEK) which is unique and is burned in the Efuse of the device. This process binds the software to that specific device. However in your case even if you encrypt your application you will have to maintain an unencrypted version of your key in memory which exposes your code. So it is recommended that you program a secure device to protect your code and disconnect the JTAG pins.
AIS and SecureAIS images can be interpreted and executed by the bootloader only. What you need is an ability to load and decrypt a non-AIS binary image. Decryption and loading of an binary can be done in code using crypto library and binary loaders. You could perhaps create a 2 stage application implementation. The first stage would consist of a dedicated application to decrypt and load a encrypted binary image. Then encrypt your actual application so that it can be provided as a binary to your first stage. Create an AIS image using the first stage and use that to boot the device. This way when the device boots AIS image will configure the device and begin executing the decryption of the encrypted image from a predefined location in memory.
Parsing and encrypting parts of your application binary will be complex and given your time frame, it may not be recommended. This would also require your decryption module on the device to implement the parser to obtain the original form of the application binary.
3- I've downloaded the AES64plus_v1.00 folder and tried it on the C6748 and it seems to run. Question: do you provide a ready to use AES encrypt tool?
No, Apart from the crypto library we do not provide any ready to use encryption tool.
4- (related to point 2): In fact I would like to know if there are some existing source code and doc explaining how to load an object file (ie placing code and Data based on object header file)
Loaders for COFF and ELF binaries are part of the SYSLINK package. It can be found under SYSLINK/packages/ti/syslink/procMgr/common/loader. I am not very familiar with this module but for specific questions on this you can either post on linux forums or on compiler forums.
I still think getting the secure version of the device is your best option. Hope my suggestion helps.
Good luck.
Rahul
---------------------------------------------------------------------------------Please click the Verify Answer button on this post if it answers your question.---------------------------------------------------------------------------------
Hello Bruno,
Here are some additional information and free advices:
To specifically encrypt data on a board, you first need information that can't be copied easily from a board to another, and which makes a part of the decryption key. The secure boot devices have fuse bits in them that can't be read evan with emulator (hidden bits, except perhaps for TI). The SPI flash mentioned in a preceding answer was used only for its unique (read-only) 64-bit ID feature; other devices have this feature (and some other only this, but NOT all SPI flash have it). Since this information is not hidden, it can be copied; but the goal is to make the copy difficult, by using hard to copy or hard to emulate information containers, by multiplying information sources,... The only hidden information is what you use as information source; however, the access to the chip through the JTAG link can permit to retrieve it (requires a determinated copist). As you use a host processor, it can also give the CPU another part of the decrypt key.
If your goal is more to protect sensible data to leak from the CPU than prevent system cloning, the JTAG link is the weak point.
I've never found any information about simple emulator connection detection through CPU register/memory (don't even talk about JTAG desactivation on standard devices), and would be interested by any (undocumented) data on this.
To make the copy job even more expensive, you may:
- soft method: add a watchdog that resets the CPU without periodic action of it
- hard method: with adequate equipment, drill the via of TDI, TRST or TMS pin under the chip of the SOM (risky but feasible, suppose standard through hole vias; these pins have adequate internal pull-up/down).
About object files:
- COFF (.out) file format is described in spraao8.pdf
- AIS file format is described in spraat2e.pdf.
A second level bootloader for AIS file (which may be restricted to load, fill and jump commands, since the basic CPU initialization would have been done by the first level one) can be written quite easily for the DSP; since you have a decryption library, a specific load&decrypt command can be added. A light command-line AIS files parser/writer is quite straightforward and would be able to manipulate identified code/data loading sections (encrypt & tag), that have to be handled by the second level bootloader.
A parser for COFF files requires much more work than for AIS files, but would permit to localize specific symbols instead of sections, if needed.
Hi all,
Could you show me how to create a genKeyHeaderFileName in *.ini file used for generating secure AIS image?
Thanks!
An,
Please check the wiki section on configuration of ini file for the Secure_HexAIS tool.
http://processors.wiki.ti.com/index.php/Basic_Secure_Boot_for_OMAP-L138_C6748#INI_File_Syntax
Let me know if you have any questions regarding this.