Timeline for Securing PCB from illegal redistribution [closed]
Current License: CC BY-SA 4.0
23 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 30, 2022 at 17:07 | vote | accept | Yann | ||
| Dec 29, 2022 at 20:52 | history | closed |
brhans user319836 Elliot Alderson |
Opinion-based | |
| Dec 29, 2022 at 15:43 | answer | added | Matt S | timeline score: 4 | |
| Dec 29, 2022 at 14:48 | comment | added | brhans | Right, on-the-fly decryption of FW is not feasible for all MCUs, but some do support it. It's a feature which needs to be built-in to the MCU. Although I'd imagine you could probably come up with some sort of interpreter which could be flashed unencrypted and could do on-the-fly decrypting of interpreted code - something like encrypted micropython ... not sure how you'd keep the encryption keys secure though. | |
| Dec 29, 2022 at 8:00 | comment | added | Yann | @vir for the current state this is more a philosophical question, as I had difficulies to find some informationon the net. I don't have a product neither sell anything. I was wondering why SP from my example never implement such anti copy devices. | |
| Dec 29, 2022 at 7:57 | comment | added | Yann | @brhans decryption on the fly seems not feasible for all microcontroller. I'm used to STM32 but never read this was possible. | |
| Dec 29, 2022 at 7:52 | comment | added | Yann | @Matt actually prevent the copy of the PCB. | |
| Dec 28, 2022 at 19:41 | comment | added | Tim Williams | @DanMills Ah yes, thanks -- most relevant is case law like this! | |
| Dec 28, 2022 at 19:26 | comment | added | Dan Mills | @TimWilliams IIRC one of the gane console manufacturers (Nintendo?) tried that from the software side, the cartridge was required to contain their logo as a bitmap at the start of the ROM and this was displayed and validated at startup. Theory was this made it a trademark issue not a copyright one. IIRC they eventually lost on the grounds that it was a functional requirement for a cartridge in that system and thus not protectable except by patent! | |
| Dec 28, 2022 at 11:56 | review | Close votes | |||
| Dec 29, 2022 at 20:56 | |||||
| Dec 28, 2022 at 11:48 | comment | added | brhans | @Yann some MCUs would put the decryption in the bootloader so that you supply it with the encrypted firmware and the bootloader then decrypts it and flashes the decrypted FW. Other MCUs are capable of decrypting and running encrypted FW on-the-fly, so the encrypted FW is what's flashed. | |
| Dec 27, 2022 at 22:07 | comment | added | Tim Williams | On the more esoteric side: it's a shame that most PCB-scale features correspond to frequency response in the 10s GHz. You could, for example, embed a trademarked logo into the board, in such a way that its EM response is distinctive, and can be authenticated by the hardware and firmware. This might be feasible for something like a wideband VNA. The trademark would then give legal standing for import restrictions or international suit. This is analogous to the Game Boy scanning for the trademark on startup. | |
| Dec 27, 2022 at 21:39 | comment | added | RemyHx | See it as a compliment. They will buy your stuff too. | |
| Dec 27, 2022 at 21:29 | comment | added | Matt S | @Yann actually, it's not clear to me if you're trying to prevent copying of the PCB or of the firmware. The lockout chip did neither -- it actually used a crypto handshake to validate cartridge authenticity -- but the concept is, I think, similar to the idea of having an on-board hash function verifying board authenticity. | |
| Dec 27, 2022 at 21:27 | comment | added | vir | I would ask yourself how many of these boards do you intend on selling, are they going to be prevalent enough to make cloning worthwhile for a third party, how much you're willing to spend on making an anti-duplication system that works and is transparent to the end user, and if the cost of dealing with the inevitable headaches from deploying and maintaining the anti-duplication system make it worthwhile. | |
| Dec 27, 2022 at 21:16 | comment | added | Yann | Actually extracting the firmware is not the issue in my example case of the sp flight controller, as they provide the firmware for free at each update. But they are loosing money to copies of PCB where the factory firmware works well on the copied PCBs | |
| Dec 27, 2022 at 21:12 | comment | added | Jonathan S. | Of course there are MCUs that are powerful enough to do cryptography. There are even ones with crypto accelerator hardware. And "reverse engineering" in this context refers to "extracting the firmware". However, if such an encryption system is not implemented by a professional, it'll likely be very easy to bypass since every tiny mistake can render the entire system insecure. | |
| Dec 27, 2022 at 21:10 | comment | added | Yann | @Matt the reverse engineering consists of cracking the hash, right? | |
| Dec 27, 2022 at 21:08 | comment | added | Yann | @Jonathan an encrypted firmware keeps encrypted until you decrypt it before flashing. Does MCUs can decrypt firmwares on the go? That's seems pretty resources intensive. | |
| Dec 27, 2022 at 21:04 | comment | added | Matt S | An engineer that used to work at my company would design sensitive electronic components in two parts bridged by a pin header or ribbon cable. This prevents any one manufacturer from selling factory extras, at the cost of careful design (especially with high-speed signaling). This doesn't prevent anyone from reverse engineering a finished product. A "factory hash on an external EEPROM" sounds like a lockout chip -- which works until someone reverse engineers it, e.g. in the NES vs Tengen fight in the 80's. | |
| Dec 27, 2022 at 20:48 | comment | added | Jonathan S. | If you do it right, a secure microcontroller with encrypted firmware updates might be all you need. | |
| Dec 27, 2022 at 20:46 | comment | added | Solar Mike | Reverse engineering is a thing. | |
| Dec 27, 2022 at 20:41 | history | asked | Yann | CC BY-SA 4.0 |