done. now, what about security? (was: how to test a robustness of a bootloader?) - Page 1
Forum section: electronics / general

author: JPortici
author_rank: Super Contributor
timestamp: November 11, 2016, 12:51:52 pm
content: In the process of writing my first own bootloader i am trying to pin down what may go wrongat this stage a first version is running on the target microcontroller and i am finishing the pc side application that takes the hex and decode it for the target mcu.the logic of the bootloader is simple:- On its own, write protected sector*- Which is incidentally the boot sector so it has the reset and interrupt vector.- Interrupts are not used by the BL so the IV just points to the application interrupt vector- Communication and control from the master is achieved via a protocol that requires handshaking. Before any operation a specificc command is sent and master waits for responce.- Every frame sent have a corresponding frame sent back so if it doesn't arrive before a timeout it is sent again for three times, after which an error condition is generated on the master side- Every frame has a fixed width. If a frame is interrupted or data gets corrupted or a spur along the line is recognized as a valid byte... but the rest of the frame isn't received until a timeout, the receiving buffer is flushed and communication is reset.- checksums are used to ensure that the received data is valid.- Even thought it is memory protected* the bootloader do a boundary check before actually erasing and rewriting the program memory- Configuration memory modification is bitmasked so that bits that may prevent the bootloader to work are not touchedthis is as much as i could come up with. I may or may be not missing something crucial*i didn't forget about the actual validity of configuration memory in pics like the 18f j series we were talking about in the other topic but that doesn't apply to me, in theory

author: Nick Novak
author_rank: Contributor
timestamp: November 11, 2016, 04:08:25 pm
content: You may want to look into Fletcher's checksum for better error detection in your protocol with little added compute cost. If you're downloading the image to a holding space then I'd CRC the entire image before you commit to booting it. If you're overwriting your application image consider a recovery method to reenter the bootloader in case of the inevitable.Nick

author: JPortici
author_rank: Super Contributor
timestamp: November 11, 2016, 06:22:10 pm
content: already done everything you said.and the bootloader is in the boot space so after a power up the device will boot into the bootloader (and wait for a timeout before exiting), i believe i wrote it before?

author: westfw
author_rank: Super Contributor
timestamp: November 11, 2016, 11:29:46 pm
content: You've done a lot to detect communications errors. What happens after you detect one? Say you bootloader downloads 30k of a 60k application, and then your CRC starts failing, retransmissions don't help, and you decide that the download has failed. Now what? Do you somehow mark the flash so that you know you shouldn't try to execute the half-downloaded code?

author: obiwanjacobi
author_rank: Super Contributor
timestamp: November 12, 2016, 06:01:29 am
content: Perhaps sent the current program in the MCU back to the master for safe keeping or provide a backup memory to be able to revert back to the original program?Add an encryption key? To prevent someone from changing the code if they don't have the key.

author: JPortici
author_rank: Super Contributor
timestamp: November 12, 2016, 09:36:57 am
content: Quote from: westfw on November 11, 2016, 11:29:46 pmthis is something i thought about but haven't implemented yet. i could reflash the first application program row with a changed reset vector that actually points back to the bootloader, keep the first application page in a separate section of the ram and write it only at the endsecurity is not a concern at the moment. i would be surprised somebody actually spends time figuring out the bootloader commands for our products, if not for the heck of doing it. Whenever i get bored i start putting easter eggs allover the place, sometimes i leave them there. Anyway, I'm doing this mainly for one product which is encapsulated in such way that reprogramming it means destroying the enclosure.. and that is an absolutely frustrating experience, trust me, so it can't be updated otherwisetopic was actually what may i have done wrong at the concept leveli wanted to keep things simple but started overthinking and i said to myself "stop. this is good enough. let's ask other people with a fresh POV"

author: hans
author_rank: Super Contributor
timestamp: November 12, 2016, 10:37:57 am
content: A flag to indicate the MCU program is invalid during operations is always a good idea.Consider communication links dropping while uploading.Consider power loss of DUT while uploading.You have considered communication errors.A full CRC on boot of the uploaded program is probably another step to make it more robust, but maybe overkill.Some kind of recovery routine is useful at all times. E.g. a 3 second delay before launching application, while some command makes sure the bootloader doesn't load main application. 3 seconds for some applications is fine, for some it's very long. For very short times, some kind of button press on powerup can also work.The main idea is you can always recover the device in the field, without special cables and stuff, using the bootloader software. A failed bootloader is often a bricked device, which often means it requires servicing at the 'factory'.

author: JPortici
author_rank: Super Contributor
timestamp: November 12, 2016, 12:43:23 pm
content: Lots of great ideas, but i can't use most of them in this specific caseit's a wired remote for another product and because legacy software on the other side they have to estabilish communication in the first 200 ms after startup otherwise the remote will be ignored. newer version of the other product will probably have the bootloader too and i will keep in mind these suggestionsso: due to preexisting hardware and mechanical layout i do not have a test point on the exposed side of the pcbi could use the user input button to stay in the bootloader but i'm already foreseeing the customer keeping it pressed at power upan alternative method like overwriting the application reset vector at start of operations so it stays in the bootloader until the end of the upload should be enoughalso issuing the bootloader start command sequence inside the application will cause a software reset so it will go back to the BLboth of these should take account for power loss and errors during writingcommunication link drop is taken into accout as each frame sent by the host, it has to receive an answer before a certain time, the answer being an "okay" or a "data checksum error" or a "frame checksum error" frame or an "unknown command error" frame in which case the host wait for more than the communication timeout period (to reset the bus) before retrying. after a number of tries an error message is promped to the host with the error condition (timeout/checksum/unknown command)

author: JPortici
author_rank: Super Contributor
timestamp: November 17, 2016, 01:42:19 pm
content: Finally finished a basic bootloader host app (also basic because in VB6)since the only target processor for now is a 26k22 the only type of file expected is a hex file formatted as for the microchip standard (http://www.elproducts.com/understanding-hex-files.htmlfor reference)then proceeds to write every required memory row from the last back to the first.in future if needed different formats will be decoded based on the target processor.process is slow even for a small program but i don't think i can do much about it, doesn't seem slower than a pickit3 doing the same so not really an issue.however, i originally saw this as a way for us to upgrade our existing (potted or encapsulated) hardware. the obvious followup is that our clients could do it themselves without having to send the hardware back to us.problem is, now i'm importing the actual compiled hex and for obvious reasons we can't give that away.what's the norm at this point?i suppose encode the hex, send the encoded hex through the app and then the bootloader decodes and flash it. but how to encode it? i don't have many program words left in the boot block and i'd rather not use a whole other page

author: westfw
author_rank: Super Contributor
timestamp: November 18, 2016, 02:09:17 am
content: Security will depend on your "threat model." Are you worried about your customers, or third parties? Are you sure you wouldn't rather put "good" encryption in the PC-side "firmware upgrade" tool rather than in the bootloader itself? (this provides very little protection against an aggressively malicious customer who can capture the upload bitstream, but keeps the bootloader simple.) Eventually you notice that you're trying to do "good encryption" without really having any mechanism for doing "good key management", which is pretty much inherently hopeless :-(

author: JPortici
author_rank: Super Contributor
timestamp: November 18, 2016, 07:08:13 am
content: that provides zero protection against someone with a hint of technical skills i'm afraid, i never even considered it.doing decryption in the micro is the only possibility i have but there i have no idea of what the market offers and my knowledge in the crypto field is not so high

author: dmills
author_rank: Super Contributor
timestamp: November 18, 2016, 10:32:58 am
content: The crypto problem is a two part thing, and you need to decide what part matters to you.One part is verifying that the code came from you, does nothing to stop someone ripping off your code, but does prevent third party code being loaded.This is essentially public key signing, the bootloader verifies that the signatures match before allowing the code to run, bootloader has a copy of the public key, you keep the private keys in a safe.The other part is preventing your code being ripped off, much harder unless you decode the bitstream in the boot loader and have a secure place in the micro to store the keys.If going there, DO NOT implement your own crypto or write your own library, we have **fun** with people who invent their own crypto and try to write their own libs...Regards, Dan.

author: JPortici
author_rank: Super Contributor
timestamp: November 18, 2016, 11:02:07 am
content: oh yes. my main concern is the second partand idefinetlydon't want to implement my own library. not my area of expertise. Asking for advice on where to look at for knowledge and possibly libraries, for a PIC18.EDIT:... which automatically led to the google search. XTEA was mentione. seems like a balanced choice between code size and security, what do you think?