|
|
View previous topic :: View next topic |
Author |
Message |
wirelessage
Joined: 08 Aug 2012 Posts: 34
|
Create a secure SDK code with CCS |
Posted: Mon Nov 18, 2013 11:45 am |
|
|
Hello all:
I am looking to create an SDK (A bunch of APIs for customers to access). So, I looked through some of the forums to see what is available.
Requirements are:
a) Critical code be shipped as libraries.
b) Hex file is encrypted or very difficult to figure out. This is not G14 Classified ) ( for those who have seen movie "rush hour" this may ring a bell).
So far this is what I have figured out for the first requirement which is 'critical code be shipped as libraries':
- You can encrypt the files with "encrypt" option with CCS Compilers which can then be included as a regular file.
- You can use multiple compilation units (create object files), but they have some limitations according to ccs because the compiler is very closely tied to the PIC Hardware, you can use this method only if you are not changing device specific stuff (clock speed for example) through the APIs.
- So obviously, the first method looks safer and can be used.
Second requirement "hex file should not be decryptable or very hard to figure out".
- This one I think is tougher from my understanding so far, because you can encrypt the libraries all you want, but when the customer compiles the code and generates the hex file, it is not encrypted in any way.
- Also, I noticed that the symbol table is visible when one compiles the code (with/without encrypting the files), so it becomes easier to decrypt the hex file and can associate assembly code, because the symbol table is clearly visible/generated.
Any thoughts on how to work around this? |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19545
|
|
Posted: Tue Nov 19, 2013 2:56 am |
|
|
Seriously no standard SDK is done this way.
If the customer is going to be able to use the library, it has to be programmable into the device, hence needs to be standard hex at this point.
The only way you could do what you want, would be to supply your _own_ programmer software, which uses an encrypted bootloader which you pre-load into the chip, and then the customer only has the encrypted files to load.
Even Microsoft do not attempt to encrypt libraries. If you have the SDK, you have the libraries available to disassemble.
This is what NDA agreements are for.
There are some chips that are distributed with encrypted code pro-loaded, which the customer can then access through designated entry points. Quite a few chips that provide encryption/decryption services are done this way, with the core encryption libraries loaded at the factory.
Generally compilers that support encrypted libraries for use with a compiler, are only protecting the core code, not the final result, since this has to be in a standard form to program, unless they are written to only work via a custom programmer interface, which means a custom compiler, and programmer that automatically protects the chip.
Best Wishes |
|
|
wirelessage
Joined: 08 Aug 2012 Posts: 34
|
|
Posted: Tue Nov 19, 2013 10:48 am |
|
|
Ttelmah,
Thanks for your prompt response! This is the response I was "hoping" to get, because I realized that what I am looking for is beyond what most Softwares typically do, and so I asked myself if it is worth doing all this.
That is when I decided to shoot this out on the forum and get feedback.
Appreciate the Input! |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|