Code protection

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.

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,

 Bruno

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,RAW
BootMode=SPIMASTER

; NO_CRC,SECTION_CRC,SINGLE_CRC
crcCheckType=NO_CRC

;__________________________________________________________
;BSR Add Start:
; Security settings (keys, options, list of sections to encrypt, etc.)
[Security]

; Security Type: GENERIC, CUSTOM, NONE
securityType=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 characters
encryptionKey=4A7E1F56AE545D487C452388A65B0C05

; Debug key
;keyEncryptionKey=0B94A91D33E597097F6C426F8F016872

; SHA Algorithm Selection
genericSHASelection = 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 = 0x00180001
PLL0CFG1 = 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 = 0x15010001
PLL1CFG1 = 0x00000002
DDRPHYC1R = 0x000000C4
SDCR = 0x0A034622
SDTIMR = 0x184929C8
SDTIMR2 = 0xB80FC700
SDRCR = 0x00000406
CLK2XSRC = 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.out
ENCRYPT=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 = 40
Parsing 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 = 233360
AIS file generation was successful.
Wrote 233580 bytes to file Code.bin.
Conversion is complete.

___________________________________________________________________________

End of SecureHexAIS_OMAP-L138.exe:

Bruno Scherrer said:

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,RAW
BootMode=SPIMASTER

; NO_CRC,SECTION_CRC,SINGLE_CRC
crcCheckType=NO_CRC

;__________________________________________________________
;BSR Add Start:
; Security settings (keys, options, list of sections to encrypt, etc.)
[Security]

; Security Type: GENERIC, CUSTOM, NONE
securityType=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 characters
encryptionKey=4A7E1F56AE545D487C452388A65B0C05

; Debug key
;keyEncryptionKey=0B94A91D33E597097F6C426F8F016872

; SHA Algorithm Selection
genericSHASelection = 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 = 0x00180001
PLL0CFG1 = 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 = 0x15010001
PLL1CFG1 = 0x00000002
DDRPHYC1R = 0x000000C4
SDCR = 0x0A034622
SDTIMR = 0x184929C8
SDTIMR2 = 0xB80FC700
SDRCR = 0x00000406
CLK2XSRC = 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.out
ENCRYPT=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 = 40
Parsing 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 = 233360
AIS 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).

Regards,

Jakez

Bruno,

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.

Regards,
RandyP

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) ?

Regards,

 Bruno

Randy,

I've just removed the the mark you have  talked  about.

Hope everything's ok now...

Regards

Bruno

Bruno,

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

Regards,

Jakez

Hi Bruno

Bruno Scherrer said:

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 said:

- 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.

Regards

Mukul

Hi Jakez, Mukul

I'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
   

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.

1- Is there any source code for loading/decrypt AIS and SecureAIS bin files from Spi Flash on the C6748?

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.   

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)...

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.

Regards,

Rahul

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.

Jakez

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.

Regards,

Rahul

Hi,

Still, the way to generate {genKeyHeaderFileName} is not clearly specified. As far as I know it seems that we have to do the below steps manually:

1. Build a firmware to call to Secure Kernel API functions to encrypt a user encryption key by function SK_setUserKey (which come as an unencrypted header in the AIS image in step 2 below), then pass the result back to host PC through a connection (?)

2. Generate an AIS image with exit mode = SECUREWITHSK so that secure kernel is loaded, and with user encryption key specified in input ini file

3. Boot the AIS image using Secure UART boot host utility

Now if it is correct, the host PC should receive the encrypted key header encrypted by KEK. However, there are some difficulties in those steps:

1. I cannot find any source code or header file to call to Secure Kernel API (they are described in OMAPL138_C6748_Generic_Security_Users_Guide_v1 0 2.pdf), does it means I have to copy source code from the pdf file, which is pretty a bad way.

2. The pdf does not specify how to get the encrypted header after call to SK_setUserKey, and also the part of passing the encrypted header back to host PC is quite annoying since we have to handle it manually.

3. I think the whole above process is quite complicated and I don't know why TI does not provide any tool to automate this process?

Thank you,
Long 

Long,

Your feed back is valuable to us. We do acknowledge that there is room to improve the Generic secure software package and hence have already been working on providing an updated package. The updated Secure Boot software package will integrates examples, additional documentation, Secure kernel API source and headers etc. I can send you a beta version of the package if you provide me the detail of your local TI contact. We are working towards updating the package on ti.com in this month. This package should help you resolve the first  issue you have raised.

On the second issue you raise, writing the encrypted header back to the PC may not be the best practice for going to production, because each device has a different KEK so you will have to repeat this process on all devices individually where you get the encrypted header out, recreate the boot image and then flash it back. A more efficient process would be to flash the unencrypted header with the encrypted application and then bind the code to the device during the first boot. For this purpose we have some example code to show the binding process wherein you need to add a control statement at the top of you application that checks if the header in flash is encrypted or not. In case the header is not encrypted you encrypt the header in the application and then re flash that portion of the flash from within the application.

Most of the customers who program secure devices choose to get the secure boot image obtained from Secure Hex AIS tool preflashed on the device and allow the first boot on the device to bind the application image to the device using the process described above. For customers who choose not to trust the manufacturer with the flashing of the boot image, there is always the option to open the debug taps in a secure facility and use the Flash writters provided in the flash and boot utilities for general purpose device to program the flash.

Let us know if you still see the need for automating the process and we can discuss further how TI can improve the offering.

Regards,

Rahul

Hi Rahul,

I sent you a private message regarding the contact, and hope that I can receive the package soon since our company is in urgent to get a demonstration working.

For the second issue, we have asked TI and are confirmed that we can order a bunch of devices with the same KEK, so we can do it in my way without worrying about the trust of manufacturer. Since the final goal is to protect our IP, I think using one KEK or each KEK for separate devices bring the same level of security, because they all protect the same firmware. So, could you please provide me the detail of how to get the encrypted header after call to function SK_setUserKey, and also we need to reference the sample of having some control statements on top of application to check the header whether or not is encrypted - the way that you mention.

I am very thankful for your prompt response and hope to receive more supports from you.

Regards,

Long

Long,

Just a clarification on your comment on the second issue. KEK is designed to be a  random number that is unique to a device . This is programmed in the efuses to protect the user encryption key and bind the user code to the device. Due to the nature of this key and it`s functionality, I don't believe you can have a bunch of devices with the same KEK(unless there is a process I am not aware of). You are right, having one KEK will also protect your IP, but if the KEK is random, a potentially malicious program will need the device number as well as the KEK to get to your IP as they are tied together. Unfortunately, I haven`t received your private message that specifies your TI contact. Could you ask them to contact me, so that we can iron out this detail.

For use of the setUserKey API, and the control code look at the binding example in the package that I sent you. All the secure kernel API code is in the support files.

Regards,

Rahul

Dear Rahul,

Is the beta (after two years) now available? May I request for sample code / example / .ini file for SecureBoot?

Jeff

Jeff,

You asked same question here: http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/347040/1214496.aspx#1214496 and it was already answered.

Please avoid posting same question multiple times...thanks.

Can u sent the file(For use of the setUserKey API, and the control code)  to me ? I  want to kown  how to compile the code .