1

As a preface, what I am asking is highly related to this question. That said, the question linked was asked in 2011 (7 years ago), and I imagine the microcontroller world has changed (at least to some degree) since that time.

I want to include sensitive info as part of a program on some sort of uC - AVR, ARM, whatever. I want to protect this data against people who obtain physical access to the device (if I lose it, or if it's stolen). I want to be able to easily reprogram/re-flash this device. I am assuming I have a perfect (but not otherwise useful) method of authenticating myself to the device that an attacker wouldn't have - so it knows it's me, but I can't use this authentication to, say, generate an encryption key or anything like that. How can I protect my code?

Additional information: I know there are fuses to prevent hex dumps, and may just have to use those depending on the answers to this question. I know they can be defeated by de-lidding and laser-probing the uC, but they'll keep your average hobbyist out. Unfortunately, those also make reflashing more difficult, requiring an external programmer (which is undesirable). I'm OK with having to add some additionally circuitry/components to the device, I really just need to see what's possible (and what's changed since 2011).

EDIT:

I have been asked for more clarity regarding my specific problem, so I'll add it in here. I'll note that I originally decided against it because (1) I don't want to bottleneck answers into a specific vein of thought, and (2) I figured I would get more "don't do this"-type answers that useful ones. With that said:

I'm working on a hardware password manager. I know, there are a bunch of these out right now. This one would read a fingerprint, and type a corresponding password (acting as a USB keyboard). If the source code on the uC is secure, then I feel (given my potential attack vectors) this will be secure enough for my own personal use - will I recommend it to a government agency? Obviously not. The uC uses a special key to communicate with the fingerprint scanner, and the fingerprint scanner can respond with a digital representation of the fingerprint that could be used to decrypt a password stored on the uC.

The main problem: If physical access to the device is obtained, an attacker could obtain the special key from the uC, get the fingerprint (stored on the scanner for comparison), and decrypt the password stored on the uC again. If the uC (or the hex from the uC) is not readable, an attacker cannot as easily obtain this information. Thus: how do I keep the information secure, while still being able to easily-enough reprogram the uC?

Helpful
  • 387
  • 3
  • 10
  • 3
    If you assume the existence of magic (perfect authentication), then anything is possible. But if you want anyone else to reason logically in your universe, you have to lay out the ground rules in a lot more detail. As it stands, this question is far too vague and/or broad to usefully address here. Perhaps you would do better to lay out the actual problem that you're trying to solve, rather than presupposing a solution. – Dave Tweed Nov 02 '18 at 02:11
  • 3
    Any serious attacker interested in the code would pay the <$2000 and have some specialist do it. Anyone else would only read out the code out of curiosity, not use it elsewhere. Maybe they find a bug in your software and send you a patch. How nice. This whole protection stuff has no use case. – Janka Nov 02 '18 at 02:12
  • @DaveTweed, I have edited the question to provide more details. – Helpful Nov 02 '18 at 02:24
  • @Janka, I have edited the question to provide more details. – Helpful Nov 02 '18 at 02:25
  • It's the same as with any other key then. How valueable is the thing you protect with it? – Janka Nov 02 '18 at 02:32
  • That's a good point, and it's also subjective. For myself, I wouldn't store my bank password or something in this device - just in case. But if I sell the device, somebody else might. Do I expect somebody to go straight to decapping and laser probing to extract the info? No. But I don't want to make it easy for them, either. I'd say I'm protecting against as much as I can if decapping/laser probing weren't a potential attack vector, since it doesn't seem like I can protect much against that anyway. – Helpful Nov 02 '18 at 02:34
  • There's really no such thing as an impenetrable encryption. Someone will find a pattern behind your cryptography sooner or later. There are methods, however that can greatly reduce a hacker's patience. I would advise you to look into doing some research on such methods. –  Nov 02 '18 at 02:34
  • @KingDuken That's a good point as well: if they lose interest, I've won. Do you have any recommended links? – Helpful Nov 02 '18 at 02:34
  • Not necessarily. Dissuading a single hacker is a single battle in a war. I remember one time we set up a sting operation at my work where we put a Windows machine on a private network at my work and we monitored network activity. Literally within 30 seconds, the Windows machine got compromised because they're looking for those ports with insecure devices. Thankfully this is a dummy network so we just trapped the monster in a closed room. That being said, there is software (even open source) that will encrypt your data. –  Nov 02 '18 at 02:39
  • Also look into **checksums**. –  Nov 02 '18 at 02:40
  • 1
    There are a couple of open source Bitcoin hardware wallets, I'd recommend you to look into those to see what makes them tick. – sx107 Nov 02 '18 at 02:44
  • One thing that I've seen in a lot of hardware password managers are OTPs - one-time-passwords - and a general "If physical access is gained, you're screwed" mentality. I don't want that. – Helpful Nov 02 '18 at 02:45
  • Possible duplicate of [Securing code on an AVR/Arduino and delivering updates](https://electronics.stackexchange.com/questions/1920/securing-code-on-an-avr-arduino-and-delivering-updates) – Chris Stratton Nov 15 '18 at 05:09
  • @ChrisStratton I have edited very slightly to confirm why this is not a duplicate question, did you even read it? – Helpful Nov 15 '18 at 22:48
  • Your question *is not* meaningfully different. In truth both should be closed as too broad, in addition to yours being a duplicate of the earlier one. – Chris Stratton Nov 15 '18 at 22:56
  • I'll conceded that I haven't nearly as much stack exchange experience as others. Yet, if I understand correctly, stack websites are a sort of database of information that people in that field (programming for overflow, EEs for here, etc) can reference. Have a 7-year-out-of-date database seems unhelpful to me: if you were working on something and could only find nearly-decade-old references, you'd probably search for something newer, no? – Helpful Nov 15 '18 at 22:58
  • No. The other question is not out of date. And revisiting things only because time passed is not part of what stack exchange is about, especially when you have only *speculation* and no facts. Point to something *specific* which you think makes the other question inapplicable. But consider that of the 3 current close votes, 2 are for being "too broad" and only one is a duplicate vote. – Chris Stratton Nov 15 '18 at 23:13
  • Very well - if we want to be specific, the other question focuses on AVR only and this question is - admittedly in a "too broad" sense - open to ARM or other microcontroller architectures. I also find myself a bit miffed that a question that essentially boils down to "How can I prevent the code on my microcontroller from being dumped/read" is "too broad." – Helpful Nov 15 '18 at 23:17

1 Answers1

3

Flash & lock the microcontroller with a bootloader which loads encrypted code from external flash into RAM. Then the external flash can be rewritten at will. For bonus points use a microcontroller with some high-security flash for storing the encryption key.

There are also microcontrollers with multiple flash regions- you can put the bootloader on one and lock it and have the encrypted code on the others (perhaps multiple, for safe updates).

If there are vulnerabilities in your code then it can be hijacked and read out from RAM.

τεκ
  • 4,229
  • 1
  • 16
  • 17
  • A good answer, so is storing an array of various encryption keys in EEPROM to use as the hash for the encryption. But you need to un-encrypt it to be of use, and some of the best encryption schemes require government issued certificates to reverse the process. You can also insert 'garbage' bytes to confuse hackers-to a point. –  Nov 02 '18 at 04:59