I need unique serial number on each of my boards.
Users will generate new firmware (ihex) on website for own board. I automatically compile program with ID and user flash to own board.
Each boards must work only with their own firmware (ID).
I do not have FTDI chip on my boards.
How can I do it?
Serial number in ATmega EEPROM
cheaper and easiest method
it is easy to rewrite ID by user
I2C EEPROM with disabled write
easy to work, low price
AT24C02C 2kbit cost only $0.1
complicated reflash - user must sold IO out, flash it and sold it back to board
Maxim guaranteed no two parts alike
+/- about $1, it is still good
+/- Is it possible to "build" copy of DS2401 with for example ATmega8 and connect it instead of original DS2401?
The problem with Arduino being open source is there is absolutely nothing to stop the user from just flashing it completely and ignoring anything you do, and loading their own code onto it. Especially, if you give them the opportunity to load their own firmware. You'll probably need a separate IC (Probably just another ATMega) that enables/disables functionality somehow, but that isn't fool-proof since again, you can rewrite it. This won't be a cheap solution. You can talk to some of the IC manufacturers (Such as Atmel) and see if they can suggest a solution. Their FAE's are pretty helpful.
pwillard:
The only one that can't be hacked after the fact is the DS2401, since it is mask rom and non-erasable.
Theoretically: Is it possible to make "copy" that send the same electric signals? I mean firmware to another MCU like Atmega* Like send copied RFID signal generated from MCU to reader.
Is possible to buy PROM (programmable read-only memory)? Somothing like I2C EEPROM but only once writable and after that only read. This exactly what I need - I2C/1-wire PROM.
martin159:
Theoretically: Is it possible to make "copy" that send the same electric signals? I mean firmware to another MCU like Atmega* Like send copied RFID signal generated from MCU to reader.
Sure, but it's much easier to edit the firmware in a hex editor - replace your security code with NOPs.
martin159:
Theoretically: Is it possible to make "copy" that send the same electric signals?
Yes you can spoof Dallas 1-Wire messages quite easily. Or the responses from an I2C (EE)PROM.
To secure the serial number from being changed, you will have to store it in an external chip with a CPU and access it with something like CHAP (Challenge-Handshake Protocol) or PKI (Public Key Encryption).
Of course, as fungus pointed out, even with a secure serial number, giving the users the ability to flash their own firmware means they can simply make their firmware ignore the serial number and do whatever they please.
So the question becomes, what kind of user are you defending your project from? Casual users will be defeated by simple measures, but it's really really hard to defeat someone who knows what they're doing... just ask Microsoft how hard it was to secure the XBox against people with logic analyzers sniffing bits between the CPU and RAM!
I don't think there's a way to prevent an Atmel microcontroller from being flashed with "evil" serial-number-ignoring firmware since it lacks code-signing abilities. So I don't think your level of security will ever be enough to defeat anyone beyond casual users.
If you really need to be secure, the best I think you could do is burn the 'security' fuses on the microcontroller to prevent all re-flashing and any "firmware" the users want to run will have to be interpreted scripts, BitLash style, from an SD card or similar external storage device.
EDIT: I forgot about the bootloader. You can burn your "secure" bootloader (with the serial number within) and set the reflash protection fuses on the bootloader only. Now you can allow users to download new firmware only with the bootloader's permission / or have the bootloader verify the validity of the downloaded firmware at each reset.
tylernt:
EDIT: I forgot about the bootloader. You can burn your "secure" bootloader (with the serial number within) and set the reflash protection fuses on the bootloader only. Now you can allow users to download new firmware only with the bootloader's permission / or have the bootloader verify the validity of the downloaded firmware at each reset.
That sounds interesting! Can please provide more information to me?
I would like to offer "function upgrade" to users. For example: original board can read 5 input, but if you buy new firmware (for your board ID) board will read 10 inputs.
When the attacker really want, always protection break. But I do not make hardware like XBox
I found codebender - user can reflash arduino with ethernet shield over internet. Probably codebender bootloader have something like TFTP.
And what about md5 or (easier md2)? ID can be save in firmware as MD2(ID+A+B+C) where A,B,C is constants in firmware. If attacker do not know way to generate hash, he can't modify it in hex editor. Arduino run in setup() check of MD2(EEPROM_read(ID)+A+B+C) == ID_constantInFirmware (hashed during compilation). If hash do not equals, program do not continue.
tylernt:
EDIT: I forgot about the bootloader. You can burn your "secure" bootloader (with the serial number within) and set the reflash protection fuses on the bootloader only. Now you can allow users to download new firmware only with the bootloader's permission / or have the bootloader verify the validity of the downloaded firmware at each reset.
...in which case I just connect 12V to the reset pin and reset the bootloader protection bits.
Face facts: There's no way to make it 100% secure. Many people have spent a lot of money trying to lock things down, none of them have succeeded.
You have to make it just difficult enough that most people won't bother. The secure bootloader is a better idea then serial numbered firmware. It only takes one rogue firmware to get on the web and everybody can find it. Hacking the hardware will only be done by a dedicated few.
martin159:
And what about md5 or (easier md2)? ID can be save in firmware as MD2(ID+A+B+C) where A,B,C is constants in firmware. If attacker do not know way to generate hash, he can't modify it in hex editor. Arduino run in setup() check of MD2(EEPROM_read(ID)+A+B+C) == ID_constantInFirmware (hashed during compilation). If hash do not equals, program do not continue.
I could replace that setup() code with NOPs using a hex editor.
It looks good. In datasheet MCP79412 is schematic (attachment).
I dot want to use RTC. I only need read ID. Is it neccesarry to have 32.768kHz crystal?
In datasheet is:
Separate 64-Bit Unique ID:
- User or factory programmable
- Protected area
- EUI-48™ or EUI-64™ MAC address
- Custom ID programming
Along with the on-board Serial EEPROM and battery-backed SRAM memory, a 64-bit protected space
is available for a unique ID or MAC address to be programmed at the factory or by the end user.
The unique ID location is user accessible by using the unlock ID sequence. The unique ID
location is 64-bits (8 bytes) and is stored in EEPROM locations 0xF0 to 0xF7. This location can be read
at any time, however, a write is inhibited until unlocked.
What benefits MCP79412 have in comparison with normal I2C eeprom like 24c01?
I found only this Arduino library whitch support only RTC (I mean). How comlicated is read/write ID? Can I disable user ID writeing?
The solution could be the fw will be downloaded as encrypted (enc with customer's ID password). The bootloader will decrypt it (on the fly) while flashing it into the flash. The bootloader will include the individual customer's ID (the password - plain or better hashed). The prerequisite has to be the bootloader cannot be read (by a flash programmer). When the avr flash will be erased by the attacker (and the bootloader therefore too) the fw cannot be upgraded anymore.
tylernt:
EDIT: I forgot about the bootloader. You can burn your "secure" bootloader (with the serial number within) and set the reflash protection fuses on the bootloader only. Now you can allow users to download new firmware only with the bootloader's permission / or have the bootloader verify the validity of the downloaded firmware at each reset.
...in which case I just connect 12V to the reset pin and reset the bootloader protection bits.
I believe that during HV programming, whatever bootloader that was in flash is erased, yes? If so, I found this:
which refers to AES-128 encryption. I don't know if that particular bootloader really does encryption, but, if you encrypt your user-firmware downloads such that only your bootloader can decrypt them, and protect your bootloader, then hex editors and HV programmers are defeated as well.
You needn't even use AES-128 (which might be hard to fit into a bootloader). Since we aren't talking about state secrets here, a simpler cryptographic cipher (don't tell anyone which!) will weed out all but the most determined. And if they're that determined, they will do it just for the challenge since the effort it would take to crack would "cost" more than an upgraded license.
EDIT: I see pito beat me to it while I was busy typing.
An alternative that does not involve ciphers uses hashes. In your secure bootloader, you store (as constants) the hashes of every type of firmware you offer. Then when the user wants to program a new firmware, your bootloader compares it's hash with it's stored table of valid hashes. If it matches, go ahead and program. If not, abort. The drawback to this is, if you ever have to do a bugfix on your user firmware, nobody will be able to download it because it has a new hash all the bootloaders out in the wild don't know about.
The key here is the bootloader's code cannot be read. Then you may use a simple cipher and a plain ID stored within the bootloader's code.
The attacker may attempt to break the cipher by comparing the encrypted fw with a typical sequences usually used within the fw - ie vector tables, inits (serial, i2c) and other typical patterns used. When using simple cipher it could be breakable then..
Edit: yea, doc2589.pdf: AES256 would be good enough, I guess
PS: the bootloader shall clean the sram after the flashing, as the key is usually stored there during decryption, the attacker may read the sram somehow after the decryption..
martin159:
It looks good. In datasheet MCP79412 is schematic (attachment).
I dot want to use RTC. I only need read ID. Is it neccesarry to have 32.768kHz crystal?
I doubt the crystal is required to communicate to the device, but I haven't tested it.
What benefits MCP79412 have in comparison with normal I2C eeprom like 24c01?
Well it's primarily an RTC with a little EEPROM and SRAM. But if you don't need the other functionality, I'm not sure what the benefits would be.
I found only this Arduino library whitch support only RTC (I mean).
Good looking library
How comlicated is read/write ID? Can I disable user ID writeing?
Not very complicated, standard I2C stuff. The library has a function to read the ID, so that is very simple. Up until now, I thought that the factory-programmed ID could not be rewritten, but in fact that is not the case, I tested it a little earlier. There's a small hoop to jump through but basically anyone that can read the datasheet could do it. So at best, it would be "security through obscurity".
I don't have a feel for what level of security you need, but there is a lot more awareness in the microcontroller world these days. There are now MCUs that are designed to resist hacking. I'm not familiar with them, but as ever, GIYF.
While you're pricing out RTCs and DS2401s don't forget that ATtinys are price competitive. With an ATTiny you could do the same things as a decrypting bootloader (use it as an interstitial on your programming lines) but also perform runtime checks against the code.
Another solution is to just write all expansion features ahead of time and have unlock codes or dongles for various features. Similar to how a lot of software works now. This requires you having all features planned out ahead of time, but this may be a simpler solution.
We have had this discussion at work, and our conclusion is we don't let the user upgrade the firmware and instead use a trusted technician.
tylernt:
Do ATtinies have bootloader protection fuses?
No but I assume you meant to ask about this...
Table 20-2. Lock Bit Protection Modes(1)(2)
Memory Lock Bits Protection Type
LB Mode LB2 LB1
1 1 1 No memory lock features enabled.
2 1 0 Further programming of the Flash and EEPROM is disabled in High-voltage and Serial Programming mode. The Fuse bits are locked in both Serial and High-voltage Programming mode.(1) debugWire is disabled.
3 0 0 Further programming and verification of the Flash and EEPROM is disabled in High-voltage and Serial Programming mode. The Fuse bits are locked in both Serial and High-voltage Programming mode.(1) debugWire is disabled.
Do you have any experience with it?
How can I encrypt firmware written in Arduino?
All MCU will have the same key?
Can I disable reflash/read of bootloader in MCU?
