I want to make a little safe that only opens up, if you entered the password via serial communication. It would be really bad if it were possible to upload a sketch, because then you can just upload a sketch that opens the safe without a password. Therefore I cut the connection between dtr and reset. But the microcontroller still resets, if you just power it on. Would it still be possible to upload a sketch if you do a power on at the right time? Or is there any other way you could still upload a sketch when you only have access to the usb plug?
Upload using a programmer. That will overwrite the bootloader (if you only upload the sketch) and one can no longer upload via USB. There would not even have been a need to cut the track from DTR to reset.
You don't need a special programmer. An Uno, Nano, Mega, ... can be used as a programmer using the Arduino as ISP sketch (ArduinoISP.ino). See this page.
I use the MiniCore core to bootload my mega328 processors. It makes choosing the options easier.
Overwriting the bootloader is most likely the cleanest solution. But it also makes the development phase less comfortable. I actually didnt just cut the track between dtr and reset, I made it pluggable. So I can just plug it in, upload a new sketch and unplug it after that.
So I still have another question: How likely is it to upload a sketch with a normal bootloader, disconnected dtr-to-reset line, and only access to the USB connector? My scenario with the power on right before the upload was only a theory. Is it really doable?
The safe is only powered by the usb connector, so you can do a power on by just plugging the usb out and in again. But then you also power down the serial connection and my operating system will most likely take longer to re-establish the serial connection than the bootloader timeout.
So is it plausible to upload a sketch on power on? Might it be possible to disconnect the usb's vcc for a short enough time so the operating system won't lose the connection but the microcontroller will shut down? Or is there another way to do that?
Because if it is only thoeretically possible but noone has done it yet, I will at least for now just keep the dtr-reset-line unconnected.
@anon57585045 I'm sorry, but that's the wrong approach when you think about security. I could also just keep the safe opened and hide it, so no other person knows where it is. But I don't want to rely on things like this.
If you are really so concerned about security that you believe that someone might
Guess that there is an Arduino inside, in the first place
Have the patience and ability to write sketches to randomly exercise every possible I/O port, to discover the lock mechanism drive pin(s)
Have the patience and ability to upload possibly hundreds or thousands of test sketches using an extremely inconvenient upload method (that might not even work)
Not be able to simply smash the lock
5,6,7, 8.... etc etc
Why not just put a jumper on the D+ or D- data pin of the USB connector? Then you would have full development access until you pull the jumper, after that nobody would have any upload ability or serial access, just power from the USB.
Another thing you could do, is make the electrical lock interface somewhat complex for the MCU. For example, require that several pins be in a certain state, or even toggle an external latch IC in a certain way, in order to unlock, vs. just toggling one pin. Then it would be humanly impossible to guesswork together a sketch to perform an unlock sequence.
I think I found a solution that does what I want without disadvantages: The new Optiboot implements "fastboot" which means the bootloader only runs after a reset and not after a power on.
That means with the diconnected dtr-to-reset line it should be impossible to trigger a reset and a power on will not allow to upload a sketch. So I only have to update the bootloader once.
Please correct me if I'm wrong!
@anon57585045 I can't disconnect the D+ or D- data pins from the usb because not only the developer but also the user uses the serial connection.
It's generally not a good approach to use obfuscation as a security method because you rely on an attacker that is stupid. But if there is one smart attacker, they will open it. If you are able to upload a sketch you could also download the current code. Then it will not be so hard to change to code to not check for a correct but an incorrect password. This would make all the obfuscation effort pretty much useless.
You also need to understand where I'm coming from. This safe will not be mass produced or be extremely secure or anything like that. I don't even really care if someone could open it by just throwing on the ground really hard. It's just a fun project for me. I'm most interested in learning new stuff by making it right. But I won't learn anything if I see a problem and just ignore it. I want to solve it, even if it's unlikely to ever have a real impact. Besides that there is one demand I have for the safe: I can't make it indestructible especially when the attacker uses the right tools. So I want to at least have a safe that an attacker can't open without leaving any marks. And uploading sketches will exactly do that.
If they can get physical access to your hardware a software hack is not your issue. If the system eventually boils down to a single actuator Im attacking THERE, not trying a mindless hack. I can read your physical WIRING and hack the hardware directly. Work on better physical security, you know, like tripping the alarm when the access panel is opened or hardening your enclosure and putting the controller INSIDE the safe?
The controller is inside the safe. You only have access to a box with a usb connector, that's all. That is why I think about a software attack. But you can still use e.g. a drill. I wont protect against that.
Passwords work 100% through obfuscation. Just the obfuscation of symbols.
My suggestion doesn't work because nobody is smart enough to crack it. It works because nobody is omniscient. It's not about how clever you are, although a little bit would help in this case. It's about how many intelligent guesses you could make, given the finite time needed to perform the crack and the minimum time it takes to make an educated guess. With absolutely no information in hand about such a system, even a seasoned black hat engineer would have little advantage over a fool.
I don't see a problem here. If someone breaks the keypad I have the same problem. You can put a chain around any safe or weld it shut and you will not be able to access it anymore. Besides, I am not trying to build the most secure safe on the planet...
Let's play a game. I am connecting some incredibly simple components to the Arduino. I designed it right now. What you have to do, is write a sketch to correctly read the components. I'll give you two months to crack it. Go.
