How to secure my Arduino sketch

Projects General Guidance
1

Hello mates

I am a bit confused about Arduino bit lock, what I need is simply as follow:

1- I need to prevent others from making a copy of my program, the hex file should be secured as well
2- My program needs to be able to read and store values in EEPROM
3- I still need to update the program with new releases

My worries are the following:

1- I will brick the MCU and render it unusable, but can I get around that if I get USBtinyISP programmer to completely erase the ATMega328B chip and reprogram it again?
2- I will not be able to make updates to the program
3- My program will not be able to read and write to EEPROM

Can someone please direct me to the right path (which I believe is the bit lock) as the subject is really overwhelming to me despite that I have over 30 years programming experience in VB, but not in Arduino world to that extent, however my programming experience still helps me to write complicated Arduino sketches like the one I am trying to protect now which is actually my first sketch ever for a complicated Anti Carjacking system.

I would really appreciate any help

Cheers

2

Is there some kind of password in the Anti Carjacking sketch ?
There are security chips with encryption.

Your sketch is not in the Arduino board, only the compiled binary code.
The compiler does extreme optimizations, it is almost impossible to reverse engineer the binary code back to source code.

After a reset, the Arduino software connects to the bootloader of a Arduino board. You can avoid that by burning the code with a programmer (such as your USBtinyISP).

If you set the lock bit, then the Flash memory can no longer be read. I read that a full erase is possible, but I have never tried a full erase. It needs to be set in HV mode (by applying a High Voltage to the reset pin). Here is an example for that: https://www.instructables.com/ATMEGA328P-FUSE-RESET/

If you make it possible in your circuit that the RESET pin can be lifted to 12V, and also connect the USBtinyISP, then the full erase should work.

The more security you add, the higher the chance that there is a bug and something does no longer work. That's just how it is.

Are those ATmega328PB chips in stock at the moment ? Or maybe in half a year :grimacing:

3

Hello mate

Thanks for your reply, yes there is a password to free the engine and it is stored in EEPROM (not encrypted currently), I am also using with the keypad, GROW R503 fingerprint reader which can be used as well

I am not really worry about reverse engineering as it is so complicated that will be really hard to reverse engineer, I am more worried about cloning the hex file after they get it.

To be honest, I am really hesitant to use the lock bits, and now you made me even more hesitant as I will take you advice on board due to the fact that there will be many releases and I will need to be able to update the boards with ease and no hassle, so I am thinking of an idea without messing with the fuses and lock bits through my programming and I would love to discuss it with you briefly and with your expertise you will be better to qualify

Here it is:

1- For every copy of the program there will be a serial number that is unique to each copy on each Arduino board, let's call it SN

2- The SN will be stored with each board on EEPROM (encrypted would be best)

3- The SN is also hard coded in the setup() and whenever any board starts, it will check that hard codded SN in setup() and compares it with the decrypted SN value stored in EEPROM

4- If they do not match, the program will halt or goes into an endless useless loop

This way if the clone the hex file, firstly, if they try to understand it, I am hoping that it will be hexed enough that they will understand nothing, secondly, if they just try to install it on any other boards, it will not work because the other board does not have the unique value stored encrypted in EEPROM

And finally if that works and secure enough, I do not need to mess with lock bits etc and go tough that complicated path. what do you think mate?

One final question please, to completely erase the chip, how long I need to apply the 12 volt to the reset pin? And that amount of volts will not fry it?

Cheers

4

But, one might give it a thwack.

5

The internal EEPROM of the ATmega chip or an external EEPROM ?
The program avrdude is used to read and write the code and also the eeprom. If someone can read the Flash code, then the EEPROM can be read as well.
The communication with an external EEPROM via I2C can be captured with a Logic Analyzer.

You need two things: the main storage with a key and a small component with a matching key. I think that is how everyone does it. If the communication to the small component can be captured, then it should be encrypted.

You can apply 12V to the reset pin at any time. Apply it as long as you are working with the programming mode. You use the USBtinyISP in the same way, but then in HV mode for the extras.

Have you seen the schematic of the Arduino Nano ? It is missing a protection diode from RESET to 5V. When the RESET pin is at 5V and the DTR signals pushes it shortly to 10V with a pulse, then the HV mode is enabled. Perhaps some signals are needed at the programming (SPI) pins, but sometimes the bootloader gets corrupted during that very short time in HV mode.

During the manufacturing of the ATmega chips, data is written in the chip. For the ATmega32U4 there is a guaranteed unique identifier. The ATmega328P has them as well, without the guarantee.
Search for: boot_signature_byte_get().
The DS18B20 has a guaranteed unique identifier, but only if you buy a genuine DS18B20. Probably all the DS18B20 on Ebay/AliExpress/Amazon are counterfeit.

If you make a CRC that is a combination of the signature bytes and the identifier from the DS18B20. And then store it (encrypted) in the internal EEPROM and use the lock bit, then you have a good barrier for someone who wants to copy it. However, a encryption chip costs less than a dollar and creates a bigger barrier. Is a rolling code possible (the previous code is used to generate a new code).

6

I disagree: reverse engineering of a BIN file for an MCU is not so difficult (using a disassembler).

In order to protect your FW in a device, you need a processor with "Trust Zone":
it will place sensitive code into a region of memory which cannot be read from the outside. Or: this code there can only be accessed, read and executed by a "secure" piece of code.
And any debugger access is prohibited by HW.

Otherwise: everybody can connect a debugger and read out your MCU FW, even reading a QSPI flash.

PCs have some approaches to encrypt the entire hard disc: when reading from it - it has to be decrypted. But for an MCU way too much (and slowing down).
If so: you could think about to encrypt all the code, with a key. A piece of SW in MCU reads such code, as data, from memory, decrypts it and places it into another memory, so that it is executed from there. But still not save: if somebody would trace your instructions done (from the outside) or read the memory content where the decrypted code is located (just stop MCU and read the memory with a debugger) - it can be still being stolen.

A processor with "Trust Zone" seems to me the only reasonable option.

You could also think about to encrypt a little bit of your code. You have to force your users to enter a key. You decrypt now this code, place it into another memory and you jump to it.
So, it makes it harder for "bad guys" to understand what your code will do, but potentially they will see still a lot of code open (read via a debugger).

Or, to make it hard to attackers: you write "self-modifying" code: this is hard to disassemble, to change back to C-code. It needs understanding what happens during runtime (but still possible to figure out).

Or: use a USB dongle, with an encrypted key on: your program just continues when dongle was seen and key was correct.

Everything can be hacked: you can just add barriers to make it harder for attackers to read your code.
Otherwise you have to design a system which has a "red" and a "white" zone. The red is encrypted and no way to access it, to read it out (with external means).

Or: you place your MCU into a shell, an enclosure: if somebody opens it, just to hook up a debugger - you have a switch to realize when it was opened. If so, you erase all your data, maybe also your MCU ROM flash (the code itself).
But it might need an internal battery, self-powered to realize: otherwise, the hacker will disconnect any power, your protection switch does not work anymore and all the time for the hacker to open your device.

7

How does Nano33IoT's crypto chip work?

8

At some point the question becomes, is it easier to write new code from scratch, or attempt to reverse-engineer the code?

9

My guess (no familiar with this one, my home is Portenta H7, also having a similar crypto chip):
it takes data (some bytes), with a key and can convert into an encrypted result (or decrypt).
It is not related to do something automatically, e.g. encrypt memory.

It is used to "key negotation", to encrypt/decrypt any data, as sequence of bytes. But you have to send it to the chip. The chip contains the algorithm (and is faster as in SW).

This chip does not protect anything (if you do not use it via SW).

10

You can clone easily: use debugger, read flash content, copy it to exact the same board - and done!

For a developer: they would never reverse engineer in a way to convert BIN code back to source code. They would try to find your GitHub project. It is too time consuming.
Anyway, as an engineer I would love to have nice source code with comments, hints ...

Without "TrustZone" - everybody can connect debugger and duplicate your setup (by read and flash on another board).

11

I agree that is why I said "Almost"

I will watch the videos, thanks

Cheers

12

I guess it will be much easier to write a code from scratch than trying to hack other one's hex converted code

Cheers

13

Thanks mate, would you please elaborate a bit or direct me to where I can find detailed info about what you are suggesting

Cheers

14

Thanks mate for all the proposed solutions, obviously I need to do a lot of homework to get around that, I actually thought about your last proposal of opening the box which can trigger something to do something else, like as you said removing all content from the MCU

Cheers

15

Thanks koepel, it is stored in the internal EEPROM, so it can be read and decrypted as you stated, well, I have to find the best and easiest to implement solution that may just make it harder to hack the code but surely will not prevent it

Cheers

16

If this is for a commercial product, keep in mind that when using Arduino and gcc tools that you are using open source and by using that open source you are subject the licensing requirements of those modules.
gcc startup, runtime libraries, and the Arduino core library are all LGPL 2.0+
Many Arduino libraries are also LGPL 2.0+ but not all of them.
Some of the other most common licenses for Arduino libraries are BSD, MIT, GPL 2.0 and GPL 3.0

While LGPL 2.0+ does allow creating closed source products, it is pretty much impossible to fully comply with the LGPL 2.0 license requirements when using Arduino.
This is because when using LGPL 2.0 or GPL 2.0 licensed components in your image, the user has the right to be able to modify any of the open source modules and rebuild the image using the modified code which means you must provide a way for them to do this.
This is next to impossible to do when using Arduino if not also providing the source code to the sketch since, as far as I know, the Arduino IDE does not provide a way to rebuild a f/w image with a pre-compiled sketch object.

If using any component licensed as GPL 3.0 to build your image, then the f/w image must licensed as GPL 3.0 which means that that the user/customer is entitled get access to your source code if he asks for it.
i.e. you can't create a closed source product when using GPL 3.0 licensed components/libraries in your f/w image / program.

Make sure you fully understand the open source license agreements involved if you wanting to use Arduino to create your f/w image and are wanting to keep your source code closed source.

--- bill

17

Oh YES - good point!
If you are based on Open Source - you cannot commercialize and "hide". And you should not frustrate people using your system, when they know it is Open Source - but you prohibit insights (even make debugging impossible).

Very good point!

18

But it is possible to create a commercial product using open source components and keep your source code closed.
For example, there are many products and devices from companies like Apple, Microsoft, Samsung, GoPro, and many others that use open source in their products.
When doing so, you have have to provide a way for users to rebuild the executable images with prepcompiled objects for the closed source components.
This allows them to modify the open source components without having to provide the source code to the "secret" proprietary modules.

This is easy to do if using a *nix OS with gcc tools and build tools like make and/or automake to do the build.

Apple uses BSD licensed code since it is much more liberal than GPL/LGPL.
i.e. BSD is nearly freeware.

I'm very familiar with Samsung phones, GoPro cameras, and TomTom GPS devices as I have contacted each company about LGPL licensing issues.
All of them were quick to respond and address the issues.

Yes there are instances of companies and developers blatantly cheating and violating the LGPL/GPL license agreements in their programs/products, but they run the risk that at some point it may catch up with them.

--- bill

19

So anyone who ever wrote anything for profit with LibreOffice owes somebody something?

(sort of tongue-in-cheek)

20

@xfpd
I Guess I'm missing something or the humor.
GPL/LGPL open source licenses apply to using the open source code as part of a larger work or when making a derivative work.
i.e. using open source code or an open source library to build an executable image like a program or f/w image.
It does not apply to anything created by using an executable that happens to contain open source components.

In the case of LibreOffice, it is licensed for free for any use including commercial use under the terms of MPL 2.0

So no issues using LibreOffice for creating works, including for commercial purposes.
Now, for anybody creating or writing code for LibreOffice or creating extensions, or distributing modified versions of LibreOffice in source code form, they will need to comply with the LibreOffice MPL 2.0 license.
And then to complicate things depending on how it is linked, it may revert to GPL/LGPL since there are GPL and LGPL components involved.

--- bill