How to prevent your code from executing on another same microcontroller?

Go To Last Post
16 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Greetings everyone,

 

I am currently designing a module (a led sequencer), which I am unsure how to sell/distribute. In the end microcontroller could be any of megaAVR series (haven't figured out yet), currently developing on ATmega2560. Let's say I finish up the module with all the components and sell it to the client. The module will be in unprogrammed state.

 

Now every client will have different requirements, so the module have to be configured according to the client needs. To do this I will have a website set up, which then client will visit and set his requirements, (design animation patterns for each led, speed and what not) and the site will generate his hex file for him, which he will be able to download and upload himself to the module with USB ASP. Normally I would've just generated a .eep file instead of the whole hex file, but the configuration data could be so large that I can't put in eeprom. Hence the hex file.

 

Now the problem with this is that anyone can visit the site and get a hex file, the module is fairly simple just a micro with a voltage regulator, few inputs and outputs with transistor attached to drive the load, very easy to replicate.

 

So all this will be duplicated fairly quickly. What can be done to have some protection ? Like the hex file only uploads to the module which is only sold by me, not anyone else's ?

Any opinions ? or how would you do it if you had to ?

 

Thanks.
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Xmega devices have a unique serial number on each chip.

Silicon Serial Number devices could be attached to any micro. (e.g. Maxim)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

schtevo wrote:
Silicon Serial Number devices could be attached to any micro.

 

So with that, all my modules will have the same serial number, that I would check in code, if that matches then execute code?

Is that how it will work?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Xmega devices have a unique serial number on each chip.

 

If you can get the micros ahead of time & know their serial numbers, you could have your program check for approved serial numbers...this is not a very good approach, if you sell a lot or don't know the micro #'s ahead of time, but is simple.

If the wrong # is detected display some led garbage, so the pirate gives up.

 

Or, on the webend, keep a list of sold items ( serial numbers)...anyone connecting to the downloader, must have a known (approved) serial number...if they don't, down load some garbage pattern.  

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:

Xmega devices have a unique serial number on each chip.

 

Okay I got it, but right now the application is almost complete with megaAVR can't really change to another micro right now, but let's assume If I do, how would I read the unique number on the chip and check if it is legit before flashing the hex file ? Because the site will only generate the hex file, it has no other way to know that the module is legit or not, so that it could generate bad hex with garbage pattern.

 

Also with megaAVR I thought client won't have to buy an expensive programmer, the cheapo $2 clone USBASP will do the job, with Xmega he has to get the actual programmer, the overall price will go up.

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Heisen wrote:

So with that, all my modules will have the same serial number, that I would check in code, if that matches then execute code?

Is that how it will work?

Pretty much. Except all your modules with have their own unique serial number. The code or part of it will need to know which specific board it was made for.  So when the customer gets online to create their magic light show, they will probably need to connect their module to the computer to read the serial number and pass to the code generator.  Convenient since they have to connect for programming anyway.

 

Alternatively, the code generator may hold a list of simple unit numbers that correspond to the micro's serial numbers.  With a simple number index, the customer could simply key this into the code generator which looks up and compiles for the matching micro's serial number, e.g. read production serial number off the module (sticker) and type into code gen.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Heisen wrote:
Also with megaAVR I thought client won't have to buy an expensive programmer, the cheapo $2 clone USBASP will do the job, with Xmega he has to get the actual programmer, the overall price will go up.

 

I'd expect a "bootloader" would be a better alternative.  That way the client doesn't need any device except a connecting cable.  Maybe even a USB to RS-232 or USB to logic level UART.

 

Edit:

Can you get USB<->USART cables for $2?  Guess it could be more expensive! surprise

Last Edited: Mon. Apr 12, 2021 - 10:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OHhhhhh!! Very clever. I got it. The value of microcontroller with built in unique serial number is very high. Now I wish megaAVR had a unique serial number that would have been awesome.

 

I don't wanna switch to Xmega, specially now when I am at very end.

 

How about megaAVR with Silicon Serial Number, will that work? First time hearing about silicon serial number device.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The megaAVR may also have (undocumented) unique signatures  https://www.avrfreaks.net/forum/undocumented-signature-row-contents

 

Also, the SRAM contents on powerup is random, but it's always almost the same "random" for each individual chip. See discussion starting here: https://www.avrfreaks.net/commen...

And a paper that also touches on this subject  https://spqrlab1.github.io/papers/holcomb-FERNS-IEEE-Computers.pdf

 

So it's almost certainly possible to ID a single mega.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Heisen wrote:
What can be done to have some protection ? Like the hex file only uploads to the module which is only sold by me, not anyone else's ?
Authentication

Heisen wrote:
or how would you do it if you had to ?

  • Data-at-rest encryption

A crypto-authenticator contains keys and a crypto engine.

Data could be static (one of the .init functions) or auto (constructor and destructor functions)

  • Secure MCU

The last revision AVR32 have FlashVaultTM (UC3C, UC3L)

Arm TrustZone®; SAM L11 might be a match when porting from smaller megaAVR.

  • FPGA are secure

Secure data paths and data stores with control paths from a non-secure MCU, or, all-in (AVR, RISC-V)

 


Symmetric Authentication with a non-secure MCU – Use Case Example - Developer Help via Definitions and FAQs | Trust Platform | Microchip Technology

 

Enhance system security with better data-at-rest encryption - Embedded.com

AT32UC3C datasheet summary

Protect Automation Designs with Low-Cost Security Processors | Mouser

Alorium Technology | FPGA Development Boards | Arduino Compatible

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Most XMEGA also have an AES crypto engine and the DES instruction.

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Heisen wrote:
... the cheapo $2 clone USBASP will do the job, with Xmega he has to get the actual programmer, the overall price will go up.
Indeed (simple hardware to mate an XMEGA to a USBasp)

Cheap USBASP knockoff programmer | Jim's Projects (XMEGA at 1/3 page)

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There's so much good free stuff nowadays, why do you think someone will be bothered to try to steal your fancy led blinker?  2 people?  Maybe 3? Maybe nobody?

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Customer specific-use-once-password on your website. S/He has to contact you again to get a new password.

Ross McKenzie ValuSoft Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If it's a "Secret Key" you want then put one in EEPROM at the factory. Simples.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

More likely to be lifted is customer data (trademarks, copyrighted data, licensed data, prices, operations [work, effort, time], ...)

Some customer data is secured due to legal (USA DMCA, USA HIPAA, EU GDPR, etc?)

 

"Dare to be naïve." - Buckminster Fuller