code read protection

newton123
Posts: 3
Joined: Thu Aug 06, 2015 1:50 pm

code read protection

Postby newton123 » Thu Aug 06, 2015 6:31 pm

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

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

eriksl
Posts: 159
Joined: Fri May 22, 2015 6:22 pm

Re: code read protection

Postby eriksl » Fri Aug 07, 2015 3:50 pm

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.

blubb
Posts: 116
Joined: Mon Jun 22, 2015 5:35 am

Re: code read protection

Postby blubb » Fri Aug 07, 2015 5:22 pm

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.

SpenZerX
Posts: 41
Joined: Thu Apr 16, 2015 9:30 pm
Location: Germany
Contact:

Re: code read protection

Postby SpenZerX » Sat Aug 08, 2015 5:51 am

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.

User avatar
rudi
Posts: 197
Joined: Fri Oct 24, 2014 7:55 pm

Re: code read protection

Postby rudi » Sat Aug 08, 2015 8:44 am

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/

-------------------------------------
love it, change it or leave it.
-------------------------------------
問候飛出去的朋友遍全球魯迪

User avatar
rudi
Posts: 197
Joined: Fri Oct 24, 2014 7:55 pm

Re: code read protection

Postby rudi » Sat Aug 08, 2015 8:58 am

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

-------------------------------------
love it, change it or leave it.
-------------------------------------
問候飛出去的朋友遍全球魯迪

User avatar
rudi
Posts: 197
Joined: Fri Oct 24, 2014 7:55 pm

Re: code read protection

Postby rudi » Sat Aug 08, 2015 9:14 am

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

-------------------------------------
love it, change it or leave it.
-------------------------------------
問候飛出去的朋友遍全球魯迪

blubb
Posts: 116
Joined: Mon Jun 22, 2015 5:35 am

Re: code read protection

Postby blubb » Sat Aug 08, 2015 6:37 pm

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

User avatar
rudi
Posts: 197
Joined: Fri Oct 24, 2014 7:55 pm

Re: code read protection

Postby rudi » Sat Aug 08, 2015 7:14 pm

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.

-------------------------------------
love it, change it or leave it.
-------------------------------------
問候飛出去的朋友遍全球魯迪

blubb
Posts: 116
Joined: Mon Jun 22, 2015 5:35 am

Re: code read protection

Postby blubb » Sat Aug 08, 2015 9:26 pm

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

Who is online

Users browsing this forum: No registered users and 28 guests