ESP8266 Developer Zone

Re: code read protection

2015-08-28T22:28:58+08:00

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

have phun

Statistics: Posted by rudi — Fri Aug 28, 2015 10:28 pm

Re: code read protection

2015-08-10T18:49:57+08:00

newton123 wrote:
..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. (**)

newton123 wrote:
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"

Statistics: Posted by rudi — Mon Aug 10, 2015 6:49 pm

Re: code read protection

2015-08-10T10:25:42+08:00

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!

Statistics: Posted by newton123 — Mon Aug 10, 2015 10:25 am

Re: code read protection

2015-08-09T03:48:10+08:00

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.

Statistics: Posted by eriksl — Sun Aug 09, 2015 3:48 am

Re: code read protection

2015-08-09T03:11:11+08:00

blubb wrote:
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.

Statistics: Posted by rudi — Sun Aug 09, 2015 3:11 am

Re: code read protection

2015-08-08T21:26:00+08:00

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

Statistics: Posted by blubb — Sat Aug 08, 2015 9:26 pm

Re: code read protection

2015-08-08T19:14:58+08:00

blubb wrote:
So your decryption key is composed of the (fixed) unique ids from flash and uC?

part of seed in bootprocess, yes -
but not clear 1:1
example:
checksum
firmware id
..

its only compare by algo the right id's who is firmware written for -
if != no boot

blubb wrote:
These can be easily read out by anyone.

2048/4096 RSA?
are you sure?

edit:
be sure you have understand the basic in encrypting/decrypting and the basic in authentication.
the authentication is done in bootprocess - only is this ok - the decrypting process start.
sign and verify is from company at begin - if firmware will be firsttime flash in company.
..
stolen crypted firmware is worthless for the thief.

Statistics: Posted by rudi — Sat Aug 08, 2015 7:14 pm

Re: code read protection

2015-08-08T18:37:08+08:00

So your decryption key is composed of the (fixed) unique ids from flash and uC? These can be easily read out by anyone.

Statistics: Posted by blubb — Sat Aug 08, 2015 6:37 pm

Re: code read protection

2015-08-08T09:14:29+08:00

btw:
a simple protect way:

you have the unit in the company.
the units have unique id over chip id example ( ESP8266 )
the units have unique id over flash ic ( example winbond's unique id mac - not product id - that not the same! )
the units have a firmware that is encrypted with parts of this two unique id
and a own company id - example for reseller.

now the firmware is unique for only this unit.
and the firmware is encrypted -
at every update the unit - online
the unique will checked -
if ok - the units get a update for ota
in bootmode, the process again check the firmware
if not legal - no boot -

offline - the same , but with company own downloader.
..

if someone 'can' dump the firmware
the firmware can be copy to an other -
but will not start.

the second way - ( hot )
the firmware can not be copy to an other-
the bootprocess will be corrupt.

the process is simply until professional.
pity that the boot loader is not available -
but is ok - the at goes back in lib too, this is pity too.

best wishes
rudi

Statistics: Posted by rudi — Sat Aug 08, 2015 9:14 am

Re: code read protection

2015-08-08T08:58:20+08:00

blubb wrote:
Since the firmware sits in a regular flash chip which can be desoldered easily, the only possible protection would be encryption.

you are right, done well

blubb wrote:
The decryption key needs to be in the ESP microcontroller, in a write-only area.

not only this one - there are more possibles with more ways.

blubb wrote:
I doubt this is possible with the current chip.

sorry -
To believe is to know nothing ))))

Statistics: Posted by rudi — Sat Aug 08, 2015 8:58 am

Re: code read protection

2015-08-08T08:44:02+08:00

SpenZerX wrote:
If you encrypt flash memory you will not be able to execute code directly from flash.

are you sure that no way given to do this?

SpenZerX wrote:
For data it's OK.
Illegal copy of Firmware can be detected by talking home(register device).

this is a too late time point - the firmware was stolen just in this moment.
this is bad tim factor for a develop company with million units..

SpenZerX wrote:
Upgrade process can talk home, too.

only if you are welcome with your original chip&firmware

Update/Webserver with AES256

http://youtu.be/2RqG_T-iinE

protected AT Version with AES256

http://youtu.be/eVfmBTm5Isg

protected developer key in AT+GMR
und extended security tags

http://youtu.be/QjjikxtHoCI

SpenZerX wrote:
I don't think it's possible to hide firmware with current hardware.

hide is not possible - you are right thinking.

btw
i have ask espressif simply for possible open the boot source for more security tags,
or minimum tempate for own,
i get answere that is not possible to get this.
so i start my own bootloader with aes256 and decrypt on the fly.
the seed is in the firmware file and more security tags.

this extends the bus writing/read encrypted over SPI, UART, I2C and so on.. too.
debug in aes mode is also possible.

i am so sorry for not open the simple boot code.
but i accept the answere. so i start my own, with more extend functions.

src
viewtopic.php?f=15&t=665

btw:
a simple bootloader base is here from richard burtons, but this is only bootfunction

http://richard.burtons.org/2015/05/22/a ... ing-rboot/

Statistics: Posted by rudi — Sat Aug 08, 2015 8:44 am

Re: code read protection

2015-08-08T05:51:14+08:00

If you encrypt flash memory you will not be able to execute code directly from flash. For data it's OK. Illegal copy of Firmware can be detected by talking home(register device). Upgrade process can talk home, too. I don't think it's possible to hide firmware with current hardware.

Statistics: Posted by SpenZerX — Sat Aug 08, 2015 5:51 am

Re: code read protection

2015-08-07T17:22:34+08:00

Since the firmware sits in a regular flash chip which can be desoldered easily, the only possible protection would be encryption. The decryption key needs to be in the ESP microcontroller, in a write-only area.
I doubt this is possible with the current chip.

Statistics: Posted by blubb — Fri Aug 07, 2015 5:22 pm

Re: code read protection

2015-08-07T15:50:13+08:00

One step ahead towards the end of opaque binary blobs! If you cannot protect the binary you might just as well publish the source Seriously, what if espressif themselves would "protect" their software the same way? It sounds a bit unfair to me this way. Also end users (like me) are getting a but fed up with binaries we cannot verify for quality, backdoors and stealth behaviour. My experience as a systems administrator and having a degree in cs is that the more the source is protected, the worse the quality of the code or the more unwanted behaviour, so I tend be kind of suspicious against fully "protected" code.

Statistics: Posted by eriksl — Fri Aug 07, 2015 3:50 pm

code read protection

2015-08-06T18:31:21+08:00

Hi,
We are trying to enter serious commercial production using ESP8266 as a single chip solution running our application code. It makes sense since our volumes will be huge (millions) & we want to avoid an external microcontroller. We had painstakingly developed our application and then after frantically searching all the documentation, we are realizing that we cannot find any means of protecting our firmware code once its loaded into the ESP

So the big question in case we have missed out something, is there any sort of code read protection available so that someone cannot just copy our firmware from the ESP8266 (either using UART or copying the code directly from the external flash)?

If not, doesn't this seriously handicap the worthiness of using the ESP8266 in commercial applications as a standalone device?

Hope we can get some sort of solution as we have heavily invested in this. I know it sounds stupid, but having worked on flash microcontroller for over a decade, we thought that the code read protection was something to be taken for granted & didn't bother to check

Statistics: Posted by newton123 — Thu Aug 06, 2015 6:31 pm