protection in MCU

[Cyber_xxl]

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?

[Skimask]

If you have to ask the question....

[lapm]

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.

[amyk]

Here's how its done: http://www.bunniestudios.com/blog/?page_id=40
More interesting stuff here: http://www.flylogic.net/blog/

[Rerouter]

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.

[JTR]

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... 

[Rerouter]

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

[dannyf]

For better encryption, you need to figure out how people attack it.

On that, google Sergei Skorobogatov.

[Psi]

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.

[westfw]

Note that avrs will not run code from ram...

[Psi]

True

You could always write an interpreter 

[abyrvalg]

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

[amyk]

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...

[abyrvalg]

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

[Alphatronique]

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 ..

[matkar]

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.

[mazurov]

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.

[Alphatronique]

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     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 ...

[Alphatronique]

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     , 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 ..

 

[Cyber_xxl]

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.

[Alphatronique]

Hi

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

but basiccard was easy to get and low cost

[abyrvalg]

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

[Alphatronique]

Hi even bomber was not very hack proof

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

i hope at least it put 3 trial before lock it 

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 ..


 

[abyrvalg]

Hahaha, I guess some "khaki brain"s logic was "00000000 is 10^8 complexity"

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.

[Alphatronique]

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 

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

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