code read protection

[rudi]

Hmmm, I must have misunderstood how the key is created. Could you post a link to your actual code?

think, i have not write right.
perhabs you will have a try and watch this :

try to understand this basics :

signing
https://www.youtube.com/watch?v=bvaHLp1BXaM

storage encrypted files
https://www.youtube.com/watch?v=K2jtYLVJZtM

https://www.youtube.com/watch?v=_WNxFtI5A9E


after this you will understand the doings
better later; the basics are here from
atmel ATSHA204 -
the same prinzipal can do without
the special hardware, the trick how that works, is not open..
in an other way, i work with sdhc and the register in an other
example; this will be open later time, the processes are not
in iram - because you can debug it -
so i found a solution with stack directly
and the register of esp. but this is not
open src just in time, because this is for
comerzial doings and services for prof.
companies how want protect the firmware.
( like newton123 - if he need )

the other doings aes256 and sdhc is open.

have a look and try a base sdhc example for luna
http://www.mikrocontroller.net/topic/370665#4222927

this will be later base for save pic from webcam,
and so on.. and secure boot from sdhc,
example RAW mode ( without flash )
and FAT32 Mode ( with Flash )
yes - you have read right.

[eriksl]

In the end all kinds of copyright protection always hinder the normal user, while the serious cracker that will gain $$$ with it won't be stopped by it. Simply don't do it. It's futile and your endusers will be bothered sooner or later.

[newton123]

Thanks for the inputs. Rudi's work is inspiring & appreciate the efforts there. But in my opinion its futile. No amount of enctryption/decryption is going to help if you are storing your key in memory which can be read back. So its just a matter of few hours or at most few days for a hacker to dump the code & isolate the part that is reading the keys for decryption and be able to figure out the keys!

[rudi]

..No amount of enctryption/decryption is going to help if you are storing your key in memory which can be read back.

sory, the key is not stored in memory, there is no key availabel to read.

try to think pictured about this:

"consideration"

simple example without signing:
one part of key is a src of the chip id ( not chip id cleartext! )
the next part of key is a src of individal key ( company sign with a unique id each unit : example own serial number ) .. is a part
the next part of key is a src of mac id from spi flash ( its a unique mac id ) not the product nr this is a other and not unique id
.. and more extends..

the parts are all not equal - each esp8266 chip has its own const HARDWARE chip id in register, each spi flash has its own const MAC ID ( 64 bit ) in register,
the company gives a unique encrypted seed in the unit ( watermark )

this parts are part of a key for encrypting the file.

if hacker have the firmware dump, there is no clear text of key*s
there are only funtions like this:

*boot = decrypt( file *0x01000 , key_a *system_get_chip_id(), key_b *system_get_mac_id_flash(),........................)

if one parameter not the same like company has flashed it with originaly chips, the decrypted firmware file will be corupt.

simple example
the encrypting key will be the originally unique chip id
in factory the firmware will encrypt by the originally unique chip id
only decrypting with the right originally unique chip id is possible
if firmware was dump and copy it to other chip ( this has a other chip id )
the bootprocess decrypt the firmware not with the originally unique chip id - it decrypt with copy unique chip id of destination chip -
this will be go false. if revers enginiering the firmware dump, you will see only the function "system_get_chip_id()", but not the cleartext,
that was originally encrypted.

this only one of more as 12 possiblte parts. (**)

So its just a matter of few hours or at most few days for a hacker to dump the code & isolate the part that is reading the keys for decryption and be able to figure out the keys!

one possible way for the hacker:
he must know, which data was take for encrypting in the first time of flashing the original chip.
then he can emulate parts of this at every boot at the copy chip.
but not all - ( i have not sayed all here )
so the firmware will be corupt.

the bootloader is signed
the firmware is signed
only update's with signed firmware exactly written for this chip is possible

but you are right.
one day AES256 will be hacked
but then espressif have many many many new series of esp8266 on market with aes512.. or other and we are all old or died in > 2050

hope this helps a little.

best wishes
rudi

edit:

(**)
which is currently standing here,
to form the key from a concatenation of more than 12 parts,
which are comparatively different for each chip hardware.

nothing is 100 percent secure- which is random to blame
"nichts ist 100 prozent sicher - der zufall ist schuld daran"

[rudi]

push#
viewtopic.php?f=15&t=665#p3482

have phun