I'm making an Arduino-based project that will act as a USB-attached PC peripheral, and I want to make sure it can't be re-programmed (either accidentally or maliciously) unless programming is physically enabled on the device itself.
I'm hoping to find a variant of the bootloader that only does its bootloader thing if an IO pin is grounded. If the pin isn't grounded, the bootloader should just jump straight to the program. That pin goes to a jumper that is shorted for development mode, and open for deployment mode.
Options I'm considering:
Find a bootloader with a WP option (why I'm posting today)
Modify the standard bootloader myself
Ground the RX pin whenever an IO pin isn't driven low. My program would set that pin low when it is ready to hear from the host PC, and the programming jumper would gate this behavior.
I can't imagine I'm the first person to look for a solution to this, but I wasn't able to find anything on the forums (lots of threads about read protection, but nothing about write protection).
Has anybody else implemented write-protect? If so, what approach did you take?
Thanks!
I can understand the requirement although I have never considered it or come across a solution.
I don't think the use of an I/O pin would be much protection against a malicious attack - but then if someone maliciously chooses to disable your code what do you care?
If you really are concerned about a malicious attack then maybe a version of the bootloader that needs to receive a secret code as part of the upload message would be more secure. Without the code it just would not work and no examination of the hardware would offer any clue.
Robin2:
I can understand the requirement although I have never considered it or come across a solution.
I don't think the use of an I/O pin would be much protection against a malicious attack - but then if someone maliciously chooses to disable your code what do you care?
I care quite a bit if a malicious attacker disables the code running portions of my home control system. If they do that, they have access to my wiring closet and I have bigger problems than what code is running in my Arduino.
If you really are concerned about a malicious attack then maybe a version of the bootloader that needs to receive a secret code as part of the upload message would be more secure. Without the code it just would not work and no examination of the hardware would offer any clue.
That wouldn't work for my needs, since it could be done remotely and could be vulnerable to replay attacks. A jumper requires physical access to the device and also doesn't require me to modify avrdude to handle the secret key exchange.
The programming jumper has the added benefit that I can make sure I'm programming the right peripheral (I'll eventually have a few variations of these modules plugged in at the same time).
sterretje:
You can remove the boot loader so the device can only be programmed via an icsp programmer.
I considered that, but I'd rather retain serial programming as an option since I tend to like to tweak my projects a lot. Plus the project will be in an enclosure that makes the ISP6 connector a bit hard to get to (my WP jumper will probably be implemented as a button that I have to hold down while I start the download)
Imagine for a moment that a malicious attacker would want to waste his time on reverse engineering your DIY home automation system, which seems pretty unlikely.
If they had access to the USB port, wouldn't they have access to the jumper and ICSP header as well?
If you want to disable USB programming, just interrupt the DTR line of the USB-to-Serial converter, or add a 10µF cap between reset and ground. That'll make sure that you can only program the µC if you manually reset it, so you need physical access to the reset button or the USB cable.
PieterP:
Imagine for a moment that a malicious attacker would want to waste his time on reverse engineering your DIY home automation system, which seems pretty unlikely.
Agreed - nevertheless asking about a write-protect solution seems like a reasonable thing to ask on this forum. No?
If they had access to the USB port, wouldn't they have access to the jumper and ICSP header as well?
No. If an attacker can gain remote access to the PC this is attached to, they can run avrdude. Again, unlikely, but completely possible.
If you want to disable USB programming, just interrupt the DTR line of the USB-to-Serial converter, or add a 10µF cap between reset and ground. That'll make sure that you can only program the µC if you manually reset it, so you need physical access to the reset button or the USB cable.
That might work, though I think tweaking the bootloader to look at a pin would be easier and more reliable.
Robin2:
I had been assuming that you were talking about an Arduino program on Arduino boards that you were selling or otherwise distributing to various users.
Isn't a good lock on the door the best way to keep a malicious attacker away from your home automation system.
This is why I'm not worried about defending against physical access (I have good locks for that), just remote attacks.
Before this thread devolves into an examination of my security measures, can we steer this back to a write-protect solution for the arduino bootloader?
Optiboot is open-source, and with a bit of luck, forum member @westfw might be willing to give you some pointers on where to start.
I still think that you have more serious things to worry about if a hacker has access to your computer. I think you're forgetting about how he can silently access all your private data, install a keylogger to steal your passwords and bank information, read the network traffic of the entire house, infect many other devices on the local network, etc.
Unless you're a very important person, no hacker is going to go through the effort of hacking avrdude to reverse-engineer your DIY project to turn on/off your lights.
PieterP: Optiboot is open-source, and with a bit of luck, forum member @westfw might be willing to give you some pointers on where to start.
Thanks - this is very helpful.
I still think that you have more serious things to worry about if a hacker has access to your computer. I think you're forgetting about how he can silently access all your private data, install a keylogger to steal your passwords and bank information, read the network traffic of the entire house, infect many other devices on the local network, etc.
I completely agree, but a good security design involves layered protection. Just because I have a good firewall doesn't mean I don't also need to secure anything else on my network.
Unless you're a very important person, no hacker is going to go through the effort of hacking avrdude to reverse-engineer your DIY project to turn on/off your lights.
Probably not - but with a single capacitor or a couple lines of code I can KNOW that it isn't possible. I don't understand why I'm getting flack for trying to do proper security engineering.
Rather than discount the threat because I'm not a VIP, consider the general population of arduinos that are attached to PCs at any given time. As IoT continues to gain momentum and solutions like Arduino and RPi are finding their way into more places (e.g., industrial controllers). A hacker just wanting to cause damage could wipe every arduino on every PC they hack. 99.9% of them would be irrelevant, but some of them (like mine) might be doing something important.
How to protect the bootloader seems like responsible engineering and worthy of discussion regardless of my particular application. The likelihood of my system being attacked is immaterial to the question.
If you want to disable USB programming, just interrupt the DTR line of the USB-to-Serial converter, or add a 10µF cap between reset and ground. That'll make sure that you can only program the µC if you manually reset it, so you need physical access to the reset button or the USB cable.
That might work, though I think tweaking the bootloader to look at a pin would be easier and more reliable.
A variant on that would be trivially simple and completely solve your problem
Rather than use the regular USB connection on the Arduino get a USB TTL cable and connect to Rx Tx and GND on the Arduino. Neither your PC nor your Arduino programs will know the difference and it will be impossible to upload a program to the Arduino because there is no connection to RESET.
AND/OR, as someone earlier said, you could dispense with the bootloader and just upload your program using the ICSP pins - using another Uno as the programmer.
Robin2:
A variant on that would be trivially simple and completely solve your problem
Rather than use the regular USB connection on the Arduino get a USB TTL cable and connect to Rx Tx and GND on the Arduino. Neither your PC nor your Arduino programs will know the difference and it will be impossible to upload a program to the Arduino because there is no connection to RESET.
This is a good approach, and I've got an FTDI TTL cable somewhere in my cable bin…
AND/OR, as someone earlier said, you could dispense with the bootloader and just upload your program using the ICSP pins - using another Uno as the programmer.
Getting rid of the bootloader does eliminate it as a vulnerability but it also eliminates it as a handy tool.
I looked at the optiboot source, and it seems trivial to mod it to check a pin (it already bypasses the bootload step for non-external-reset cases). I think I'll give this a try first since it will work with my existing setup - if I run into any trouble getting my optiboot to work then I'll fall back to your TTL serial cable idea.
but it also eliminates it as a handy tool.