Author Topic: protection in MCU  (Read 12091 times)

0 Members and 1 Guest are viewing this topic.

Offline Cyber_xxlTopic starter

  • Newbie
  • Posts: 2
protection in MCU
« on: December 04, 2013, 12:17:01 pm »
Hi,
I want set additional protection on Atmega128, because the fuse protection can be removed very easy. Some company, like RussianSemiResearch.com, can do it. Anybody used this service? What technology use by this company? Can I make it myself?
« Last Edit: December 06, 2013, 08:32:47 am by Cyber_xxl »
 

Offline Skimask

  • Super Contributor
  • ***
  • Posts: 1433
  • Country: us
Re: protection in MCU
« Reply #1 on: December 04, 2013, 01:14:15 pm »
If you have to ask the question....
I didn't take it apart.
I turned it on.

The only stupid question is, well, most of them...

Save a fuse...Blow an electrician.
 

Offline lapm

  • Frequent Contributor
  • **
  • Posts: 564
  • Country: fi
Re: protection in MCU
« Reply #2 on: December 04, 2013, 01:20:15 pm »
I quess is doable in home, if you have enough time, right chemicals and good eguipment.

Its not exactly lets dremel top off this package deal...

But if you need to ask price, you probably dont need it. Its usually easyer just design it yourself then reverse engineer software from chip thats seriously abused. I have ever heard only couple cases where this sort of extreme measures was done.
Electronics, Linux, Programming, Science... im interested all of it...
 

Offline amyk

  • Super Contributor
  • ***
  • Posts: 8275
Re: protection in MCU
« Reply #3 on: December 05, 2013, 05:52:54 am »
Here's how its done: http://www.bunniestudios.com/blog/?page_id=40
More interesting stuff here: http://www.flylogic.net/blog/
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4694
  • Country: au
  • Question Everything... Except This Statement
Re: protection in MCU
« Reply #4 on: December 05, 2013, 08:03:20 am »
the cheapest way to add additional protection to your chip is cut off the programming pins, file off the number and seal in a metal epoxy,

I'm slowly reverse engineering a security dongle that has done just that, and its become easier for me to log security keys from a man in the middle attack than slowly whittle away a few microns of epoxy at a time with acetone.
 

Offline JTR

  • Regular Contributor
  • *
  • Posts: 107
  • Country: au
Re: protection in MCU
« Reply #5 on: December 05, 2013, 08:32:42 am »
the cheapest way to add additional protection to your chip is cut off the programming pins, file off the number and seal in a metal epoxy,

Well that would be good ESD protection. Somehow I think you still might need a condom though...  :-DD
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4694
  • Country: au
  • Question Everything... Except This Statement
Re: protection in MCU
« Reply #6 on: December 05, 2013, 09:15:56 am »
i'll give JB weld as an example (in this particular case) its metal based, but not overly conductive, something like 100K between 2 dip pins, and i have a functional device in my hands that says it can work
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: protection in MCU
« Reply #7 on: December 05, 2013, 11:51:53 am »
For better encryption, you need to figure out how people attack it.

On that, google Sergei Skorobogatov.
================================
https://dannyelectronics.wordpress.com/
 

Offline Psi

  • Super Contributor
  • ***
  • Posts: 9951
  • Country: nz
Re: protection in MCU
« Reply #8 on: December 05, 2013, 12:25:49 pm »
You really cant stop people from getting the code if they're determined and have the money, you can only make it harder/expensive, usually by potting it.

You can also add features in code to detect if the code is running on a clone and make the product fail randomly.
It's best to do that rather than refusing to run because you want the person copying your product to "think" they have succeeded until after they ship the clone. (unless the product has a safety aspect)

I may have stolen these ideas for other people, i think Mike talked about one of them in a vid.

1) Kill a few bytes of the EEPROM by looping a random write as part of your board testing procedure.
Then test for the dead byte in code at startup. If the byte works you know the code is running on a non
genuine product.

2) Have a tuned/special circuit that looks innocuous but can be precisely tested for in code by clocking an output at a set frequency and monitoring the response.
(resistors are good, you can use 0.1% where there is no apparent reason for it (except the tuned circuit). Anyone reverse engineering the board would never expect it and will spec a generic 5 or 1% resistor which you can then detect.

3) Use some of the undocumented atmega programming commands to change the product ID so it doesn't match any ATmega out there. Then check for that in code at startup.

4) Add a battery to the board (soldered on) and store the real MCU code in RAM (kept alive by the battery).
In the MCU flash store some different code that does work but has lots of bugs.
Anyone trying to extract/read you chip will likely interrupt the power, not realize they just lost the firmware, and pay a company to extract the fake firmware from the mcu.
Obviously this method gives your product a finite lifetime before the battery dies, even if you use a rechargeable.

5) If your circuit includes some known external clock source and you're using the mcu's RC osc you can max out the RC cal byte then test for the unusual clock rate by comparing it to the known ext clock.
FT232RL for example can output a clock


The hard part with all these techniques is making sure they will never activate in your official products.
« Last Edit: December 06, 2013, 02:17:25 am by Psi »
Greek letter 'Psi' (not Pounds per Square Inch)
 

Online westfw

  • Super Contributor
  • ***
  • Posts: 4199
  • Country: us
Re: protection in MCU
« Reply #9 on: December 05, 2013, 12:44:36 pm »
Note that avrs will not run code from ram...



 

Offline Psi

  • Super Contributor
  • ***
  • Posts: 9951
  • Country: nz
Re: protection in MCU
« Reply #10 on: December 05, 2013, 12:45:36 pm »
True

You could always write an interpreter  :-DD
Greek letter 'Psi' (not Pounds per Square Inch)
 

Offline abyrvalg

  • Frequent Contributor
  • **
  • Posts: 824
  • Country: es
Re: protection in MCU
« Reply #11 on: December 05, 2013, 01:01:34 pm »
We had issues with our PIC-based dongle being cloned. A SemiResearch-affiliated guy told us that PICs are easy targets for tapping some security-related signal with microprober needle, then reading the flash usual way. We had developed a simple countermeasure - destroy PGC/PGD pin's on-chip IO buffers. We had used a ZIF socket with all pins grounded, except PGC/PGD connected to a high current 12V source via switch - insert the PIC, flip the killswitch on, count 1,2,3, flip the switch off - done. We were testing both functionality and programming mode inaccessibility after that and reliability was very high (some 2-3 failures from a thousand). And no more cloning at all. But that doesn't work well for all models, I had tried the PIC16F877A the same way later and magic smoke escaped it.

Locking to some sw-detectable feature gives much lower degree of protection - with 8-64K firmware sizes for an adequate skilled reverser it will take just half a day spent in disassembler to figure out such tricks
 

Offline amyk

  • Super Contributor
  • ***
  • Posts: 8275
Re: protection in MCU
« Reply #12 on: December 05, 2013, 02:29:34 pm »
A SemiResearch-affiliated guy told us that PICs are easy targets for tapping some security-related signal with microprober needle, then reading the flash usual way. We had developed a simple countermeasure - destroy PGC/PGD pin's on-chip IO buffers.
And of course the obvious counter-countermeasure is to just tap those lines on the die too - if they were determined enough to decap the chip and probe signals on the die a faulty I/O buffer isn't going to stop them. More likely the cloners just moved on...
 

Offline abyrvalg

  • Frequent Contributor
  • **
  • Posts: 824
  • Country: es
Re: protection in MCU
« Reply #13 on: December 05, 2013, 05:38:11 pm »
And of course the obvious counter-countermeasure is to just tap those lines on the die too - if they were determined enough to decap the chip and probe signals on the die a faulty I/O buffer isn't going to stop them. More likely the cloners just moved on...

No, those guys who ordered clones were definitely willing to continue (a bloody dogfight for that specific market segment had continued for at least 3 months more), but something wasn't so easy as before. This approach also denies other methods like power glitch fuse bypass and selective UV erasing mentioned in some link above. SemiResearch had some more advanced approach also - something with direct electrostatic sensing of trapped charge locations in flash die area, but that's too complex/expensive for the most consumer-grade targets I guess.

There are ready-made solutions with battery-backed SRAM like Psi had mentioned in (4) - famous DS5240/DS5250 secure MCUs for example, but they are quite expensive and hard to buy. We've seen one DS5240-based security box that had SRAM preloaded by developer, but many customers complained about boxes self-destructed (no, no explosions, just SRAM keys reset :D) during shipping - bad battery contact + strong vibrations in transport I guess.

Also I've heard that some recent Atmel products were designed with security bit tampering in mind - the bit cell itself was moved into a layer under main flash array to prevent both selective erase and needle tapping. And there was some kind of proof - one very lucrative cloner's target security box based on AT91SAM7S256 was never cloned.
 

Offline Alphatronique

  • Regular Contributor
  • *
  • Posts: 129
  • Country: ca
    • Alphatronique Inc.
Re: protection in MCU
« Reply #14 on: December 05, 2013, 06:17:30 pm »
Based on past experience whit same issue  ,bad guy use nitric acid for melt the package epoxy
the use micro probe for tap into internal flash memory directly  ,so it not use programing interface
noting may stop it since it read flash directly ...  forgot  to sand chip part number it writed on the die ,at time i got that kind of issue it have cost 5K$ to my competitor for got code .. 

so if you have that kind of issue on a expensive product it have only one solution that may work
use unique serial number chip (maxim made some) and validate user via internet whiting a database ,so if serial number not fit user location or was knot fake ,not let system operate normally , so if clone it not able to boot-up , it need to decompile and patch code for bypass internet activation  ,put that on a FPGA make it more hard since decompile a FPGA was not easy and FPGA fab legal dep keep eyes on that kind of tool

another similar way was use internet remote firmware uploading via encrypted bootloader wit each user have unique key based on unique silicon serial number

hope it help everything else was futile and easy to bypass ..

Marc Lalonde CID.  IPC Certified PCB Designer.
Alphatroniqe inc.   www.alphatronique.com
 

Offline matkar

  • Regular Contributor
  • *
  • Posts: 153
  • Country: si
  • Sixty percent of the time it works EVERY time.
Re: protection in MCU
« Reply #15 on: December 05, 2013, 08:55:08 pm »
Microchip produces some EEPROMs with unique MAC address permanently written on it. You could use this as a mean of hardware identification by your firmware.

On the other hand you have to ask yourself if it's worth wasting your time and money chasing a better protection. There is a bigger chance someone will copy your idea and not the product. If your code isn't huge, doesn't have some special proprietary algorithms, does not incorporate some expensive to buy protocol stack or the product isn't produced in ten thousand pieces per year, there is a very slim chance anyone even trying to read the content.
 

Offline mazurov

  • Frequent Contributor
  • **
  • Posts: 524
  • Country: us
Re: protection in MCU
« Reply #16 on: December 05, 2013, 09:14:52 pm »
I want set additional protection on Atmega128, because the fuse protection can be removed very easy.

Switch to a newer MCU. Old ones were very easy to hack; the ones introduced in the last 5 years are many times more secure and having them read by aforementioned services is expensive.
With sufficient thrust, pigs fly just fine - RFC1925
 

Offline Alphatronique

  • Regular Contributor
  • *
  • Posts: 129
  • Country: ca
    • Alphatronique Inc.
Re: protection in MCU
« Reply #17 on: December 06, 2013, 02:05:30 am »
Hi new CPU just use a smaller die something like 45nm instead of 180nm

but hacker tool advance to so it false security felling to use newer chip

if you look http://www.chipworks.com/ alredy read and publish image from die of main chip of  xbox one   :-DD  even if it use 28nm   ,so really  your newest cortex chip was pice of cake ..

and material for expose die and probe was available in lab of many university


and general micro was not designed for be secure by DIE probing attack  so everyting insde micro may read whit no problem Flash/Rom/EEprom
for got that level you need to go into secure MCU market that require heavy NDA for buy it

that a exemple article written for defat smart card that was designed for be tamper resistant DIE and even here you will see that it quite easy to read it flash/rom

http://www.mikahk.com/topics/hack-microcontroller.asp

so as i said FPGA whit encrypted load (xilinx DNA) was way to go  or/and internet activation

remain was futile ...

Marc Lalonde CID.  IPC Certified PCB Designer.
Alphatroniqe inc.   www.alphatronique.com
 

Offline Alphatronique

  • Regular Contributor
  • *
  • Posts: 129
  • Country: ca
    • Alphatronique Inc.
Re: protection in MCU
« Reply #18 on: December 06, 2013, 03:29:34 am »
HI

another way for implement secure design ,but never test it myself for this one ..

use a smart card chip that connect to your micro controller (www.basiccard.com)
encrypt packet bethen your MCU and the card ,elliptic if possible

then on your application code ,hardcode some function into hardcoded address into memory space (no label or else for identify it)
then instead of use "call XYZ_functio"  use "JMP" to the absolute address of that function  (will return into it bit later you will understand why)

so on you code when need that function ,you send encrypted packet to the card whit that function name on it (or better a number)   then card use look-up table and return the good
hard coded address of that function iso decrypt packet on the mcu
and make a JMP to this absolute address  ...

since source code and linker not knot were that function was were in memory (no label but hardcoded address)
even if code was disassembled it will take  lot of time figure how to patch code for it work without the smart card   :scared:  , you may even put some function into the smart card

and smart card may cut for keep only bare die and solder it up-side down on the pcb ...
this save place and this add only ~10$ to the design

just need to carefully chose witch function will be hide  .need to be critical function
but not called to often since card calling will induce some lag ..

sorry for my bad english was dyslexic and english was not my native language to .. ;D

 
Marc Lalonde CID.  IPC Certified PCB Designer.
Alphatroniqe inc.   www.alphatronique.com
 

Offline Cyber_xxlTopic starter

  • Newbie
  • Posts: 2
Re: protection in MCU
« Reply #19 on: December 06, 2013, 08:39:04 am »
With smart cards is a good idea. Instead you can use the crypto MCU. But they also hack. But the price for such a hack is very high.
 

Offline Alphatronique

  • Regular Contributor
  • *
  • Posts: 129
  • Country: ca
    • Alphatronique Inc.
Re: protection in MCU
« Reply #20 on: December 06, 2013, 01:44:55 pm »
Hi

put hand on crypto MCU good luck ;-)  ,require solid company background and NDA

but basiccard was easy to get and low cost
Marc Lalonde CID.  IPC Certified PCB Designer.
Alphatroniqe inc.   www.alphatronique.com
 

Offline abyrvalg

  • Frequent Contributor
  • **
  • Posts: 824
  • Country: es
Re: protection in MCU
« Reply #21 on: December 06, 2013, 11:28:29 pm »
I feel like we all went a bit too far in the discussion. Let's ask topic starter what kind of product he wants to protect and advise something adequate. Cut pins/scratched marking will be enough for yet another oven timer, but even a smartcard can be weak for a pocket sized orbital bomber :D
 

Offline Alphatronique

  • Regular Contributor
  • *
  • Posts: 129
  • Country: ca
    • Alphatronique Inc.
Re: protection in MCU
« Reply #22 on: December 06, 2013, 11:53:52 pm »
Hi even bomber was not very hack proof :scared:

http://tywkiwdbi.blogspot.ca/2008/11/us-nuclear-secret-unlock-code-was.html

i hope at least it put 3 trial before lock it  >:D

seriously fist post talk about AVR Mega128  and link to russian site that unlock it for 1000$

so at that price everything that may generate some money may a target ... 
cost less to read the chip that try to rewrote code ..


 

Marc Lalonde CID.  IPC Certified PCB Designer.
Alphatroniqe inc.   www.alphatronique.com
 

Offline abyrvalg

  • Frequent Contributor
  • **
  • Posts: 824
  • Country: es
Re: protection in MCU
« Reply #23 on: December 07, 2013, 12:55:39 pm »
Hahaha, I guess some "khaki brain"s logic was "00000000 is 10^8 complexity" :D

I've checked that first link - looks like some russian branch of a company that I've mentioned (SemiResearch.com - those are from Lithuania, but I've heard some their people had moved to Moscow recently).
Btw, they offer some "installation of 3-level security", which are:
"Level 1" - IC epoxying
"Level 2 - hidden breaking of pin inside case" - picture looks like some hole was drilled into the IC at right location to break the connection, then filled with epoxy - a bit more advanced "cut the pins" approach.
"Level 3 - hidden removing inside chip control logic of pin" - that must be I/O buffer destruction.
 

Offline Alphatronique

  • Regular Contributor
  • *
  • Posts: 129
  • Country: ca
    • Alphatronique Inc.
Re: protection in MCU
« Reply #24 on: December 07, 2013, 01:12:01 pm »
it fun that all that 3-level not lock itself out  ::)

since normally it probe the flash memory bus directly by microprobing it
(ok when lasy sometime it only force to knot state the fuse bit)

not to forgot that that protection service you need to send your chip to the bad guy  |O

that way was also not manufacturing friendly if you do some volume 

smart card chip ,FPGA or internet activation remain  better and more secure..

Marc Lalonde CID.  IPC Certified PCB Designer.
Alphatroniqe inc.   www.alphatronique.com
 

Offline abyrvalg

  • Frequent Contributor
  • **
  • Posts: 824
  • Country: es
Re: protection in MCU
« Reply #25 on: December 07, 2013, 05:38:43 pm »
not to forgot that that protection service you need to send your chip to the bad guy  |O

That's what my post was about - their protection methods are no rocket science, we had discussed them all here. So no need neither to send the chips nor to pay for that, all those things can be implemented even by a home hobbyst.

As I understand, probing full flash bus will require some 20+ micropositioner needles (data, address, control) instead of just 1+ for security bit - more expensive equipment setup, more complex work. So rather cheap and easy tinkering with programming pins can make some difference too.
 

Offline Alphatronique

  • Regular Contributor
  • *
  • Posts: 129
  • Country: ca
    • Alphatronique Inc.
Re: protection in MCU
« Reply #26 on: December 07, 2013, 06:20:48 pm »
Hi

blowing the input pin or drill into it  will not remove the rest of circuit on the die itself
still may probe before pin buffer or some were else in the logic block ,also that may damage chip and lower down the MTBF of your design ,just use knot ESD damaged part   

not to mention that it have also trick that not need to have more that 2 -3 probe
as exemple read it one bit at the time  so need to read the flash array 32 time and move to next bit of data each time for a 32 bit bus  8)

but it have also many other way to do it .. and dump code from a chip like glitch ,study current draw on every clock cycle  etc etc .... (the even not require to expose die )

so if you need protection from average joe just sand part number of every chip  and pour it into epoxy , but if you need to protect from bit bigger or motivated people you need  big artillery ..
4-5 time a year was hore a hardware security consultant by company that got clone issue
that more current that most people thing ..  now money was in soft IP not longer in PCB/SCH design

p.s. best trick was never show your stuff in a trade show if your not 100% production ready
that a fatal error ,some guy will buy one unit then copy it and mass produce it before you
during time you try to setup your prod and complete certification ...
i see it just to much often ... 
the one that win was the one that able to fill the market before it competitor ..

 

« Last Edit: December 07, 2013, 06:37:17 pm by Alphatronique »
Marc Lalonde CID.  IPC Certified PCB Designer.
Alphatroniqe inc.   www.alphatronique.com
 

Online westfw

  • Super Contributor
  • ***
  • Posts: 4199
  • Country: us
Re: protection in MCU
« Reply #27 on: December 08, 2013, 05:17:03 am »
Quote
the one that win was the one that able to fill the market
I'm not convinced that IP theft is necessary or sufficient for this.  Perhaps if the original vendor spent more time learning how to manufacture his product, serve his market, and support his customers, and less time being paranoid, "protecting his IP", and sanding the markings off the chips in his PCB, his customers wouldn't have been "stolen."

"Can't deliver" is a MUCH deadlier sin than "your version is slightly more expensive than this no-name vendor with the same product."

I knew a guy who was selling an rs232 thermometer (for machine room monitoring), and sanding the numbers off his chips.  I mean, really?
 

Offline Alphatronique

  • Regular Contributor
  • *
  • Posts: 129
  • Country: ca
    • Alphatronique Inc.
Re: protection in MCU
« Reply #28 on: December 08, 2013, 04:23:19 pm »
Hi , not sure someone what to clone a thermometer ?    and no real IP here to

this is a example of that o talk about ,http://www.gedigitalenergy.com/MD/catalog/BMT300.htm
it take 6 year in R&D whit a team of ~10 full time staff (ING ,Physics ,math,electic etc)
so you end up whit a product that sold for price of car  ,90% of that was firmware IP
hardware was similar to a 4 x 125MHZ + 8 x 12MHz Scope ..

if company "X" what to buy 10 system  and it cost 1000$ for read from the code from the DIE
what did you think it do ...  for price of one system it may recover the code and reverse engineering the hardware    , so if gouvernement "Y" what 1000 system ?

same apply to any specialised and expensive tool  ,optic fiber ,medical ,diagnostic tool

now if you look into consumer market like cell phone ,tablet ,set-up box ,game console etc etc
on every one you will find at least one  SOC or ASIC ,ok first reason was reduce BOM cost
but that also effective protection system  like iphone that use it own in-house CPU

and finally raspberry pi it sold over 2-million unit no copy  ,again main cpu was custom

i bet that if arduino was not open source will end up whit clone instead of copy
so put it open source was also a kind of protection , you may copy it but not use name
end user knot what it have on hand ...

not forget that when some one clone a product most of the time it also a fake
so legitimate company got support\warranty call to  ,until it realise that it service
unit that it never build itself ..   and end customer was not aware that it have but a clone

so think that in any product encrypted boot-loader ,and disable jtag in software was a minimum
even for rs232 thermometer  8)   but for more aggressive mesure need to set proportionally whit unit sale price or volume of sale ..
 

Marc Lalonde CID.  IPC Certified PCB Designer.
Alphatroniqe inc.   www.alphatronique.com
 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 4078
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: protection in MCU
« Reply #29 on: December 10, 2013, 08:36:31 pm »
There are mcu's that can run code encrypted with AES, and the key is write only by design, not accesible by bus matrix. Sometimes even dummy circuits are added around that part of otp to fool the die readers.
But AES parts come with a price and export limitations.
 

Offline Alphatronique

  • Regular Contributor
  • *
  • Posts: 129
  • Country: ca
    • Alphatronique Inc.
Re: protection in MCU
« Reply #30 on: December 20, 2013, 08:17:54 pm »
Hi

hi just grab that thesis paper from hackaday post

read encryption key only by sound of PCB ....

http://www.tau.ac.il/~tromer/papers/acoustic-20131218.pdf

same was already done in past whit supply current  of cpu/micro
naturally it may also serve to dump code when combined with glitching of supply...

original post
http://hackaday.com/2013/12/20/ambient-computer-noise-leaks-your-encryption-keys/


Marc Lalonde CID.  IPC Certified PCB Designer.
Alphatroniqe inc.   www.alphatronique.com
 

Offline SArepairman

  • Frequent Contributor
  • **
  • Posts: 885
  • Country: 00
  • wannabee bit hunter
Re: protection in MCU
« Reply #31 on: January 07, 2014, 04:08:49 pm »


just give me some plane tickets and a bottle of vodka and I will "protect" your MCU  :box:
 

Offline SeanB

  • Super Contributor
  • ***
  • Posts: 16284
  • Country: za
Re: protection in MCU
« Reply #32 on: January 07, 2014, 04:45:56 pm »
Nice musical interlude there.....

Thumbs up for that!
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf