GD drm.... - Page 1
Forum section: electronics / general

author: lincoln
author_rank: Regular Contributor
timestamp: June 05, 2015, 07:38:37 am
content: So I work for a small company. We make a small module that has a mcu, fpga, some analog stuff and a few network ports. Depending on how it is setup, it can be a client, server, or both at the same time.most customers that will buy any significant volume are mostly interested in the client and want it for next to nothing. So the business and marketing people make a pricing structure so that if you want the client you get it cheap. One is free to use anyone's server. if you want our server or above you pay more for it.Fine, so we add a define on the code to limit one version to only run client and then we have a second image that everything is enabled. Of course since firmware gets loaded during manufacturing now we have three product lines to manage stock for rather than just one.Then comes up the issue of firmware updates.(the following is a slightly exaggerated dramatization, but not by much)What prevents a customer form loading the full image rather than the gimpy one? Marketing and sales asks.Eng: We can revoke their support contract of a customer maliciously dose that.Marketing: We need to prevent that. you have to figure out how to stop that.Eng: ..... So like the Keurig K Cup 2.0 or Sony's CD copy protection?marketing: Ya, just like that...ENG: <silently screams>Marketing: But we should be able to upgrade customers existing modules if they pay us .Eng: So like an in-app purchases but for hardware.Marketing: Now your getting it, when can you have that done by?Eng: What core feature are you willing to dump off the road map?Marketing: wat?we got it sorted out for now but I have a feeling I haven't heard the last of this. This is just a vent, i would tell my wife but she give me a look when i start talking about work....

author: AndyC_772
author_rank: Super Contributor
timestamp: June 05, 2015, 07:43:50 am
content: OK, so what you need is a single firmware image, and feature keys tied to the serial number of each unit.I'm interested in this too. If anyone could point me (us) in the right direction in terms of crypto libraries that can run on the device, and corresponding software to generate keys on a separate PC, that would be handy - thanks.

author: lincoln
author_rank: Regular Contributor
timestamp: June 05, 2015, 08:03:37 am
content: Ya, sort of like what Rigol dose with their scopes...

author: Kjelt
author_rank: Super Contributor
timestamp: June 05, 2015, 09:52:08 am
content: Yes the main problem is that a hack of this firmware will generate $ for the hacker because you upgrade a cheap product to an expensive product.This might look like heaven to marketing but also to a potential hacker. And for the engineer it is a nightmare since he is always the one who ^*^*& up, when it is hacked or when he says it is not wise to do so.The simple answer is even with good crypto you can never prevent someone with big$ to hack it and gain more $ as we all know.If that is ok (from a security risk analysis) you can do something to prevent the above case.Protect your firmware update by authenticate encrypting it using the smallest and good cipher around such as AES128.In your normal firmware update releases you refuse to update to a firmware that does not belong to the same (sub)product.But if a customer wants to upgrade you sell him a small intermediate custom to one product firmware update that just alters the functionality, BUT it should only run on one device (so you need administrative product ID's and unique product keys).So that leaves two keys for each product: a unique product key and a firmware update key.If you do all the math and let the marketing department set up this service with human beings and explain the $ it costs and what you will gain, then unless you are selling extreme large number of products a year you probably will loose more money on the service than if you just simply sell the customer a small different hardware product.

author: Someone
author_rank: Super Contributor
timestamp: June 05, 2015, 11:35:46 pm
content: Quote from: Kjelt on June 05, 2015, 09:52:08 amSo it has to be easy for the end user to change the function when they are allowed to but not when they are not allowed to, recipe for leveraging a hack.If the margins on the product really are good enough to sell the reduced version for much less, consider putting a different FPGA with the same footprint on the different versions, upgrade process is now sending in the expensive version but you've killed off any possible hacking.The other common option (as seen in scopes) is to have a keygen that is hashed with the serial number of the product, and ideally some secure way to set the serial number of the product.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: June 06, 2015, 12:32:46 am
content: To avoid the risk of hacked firmware, some of the locking process should be done in the FPGA - this doesn't need to be particularly complicated as it's pretty near impossible to extract FPGA functionality from the bitstream, whearas firmware can be disassembled fairly easily.And if possible have the locking mechanism make some change to the FPGA's main functionality, rather than simply have it return a yes/no answer to the firmware. If you can do that then you may not need to be too concerned about signed firmware updates, as the locking is all done in the FPGA.However if the FW update can only be done via a bootloader it's easy enough to obfuscate or encrypt the update files.Even if the FPGA functionality is identical in both client and server, there may be some scope for doing something in the firmware that would make it very hard to figure out. e.g. in client vs. server mode, all the FPGA registers are laid out differently - firmware for client mode uses mode x, server uses mode y. FPGA only implements mode y if some magic unlock sequence is done.Some FPGAs have a unique serial no. - the key would be a hash of this and some constant generated by the FPGA functionality. It would need some kind of hashing as it is possible to read out the USN of the FPGA ( in the implementations I've seen - some may differ), however - the hash function would be hard to discover so wouldn't need to be very complex.The unlock key would be unique to each device, so the same key can't be used on other units as the FPGA's USN would be different.However you should ask Marketing what level of attacker resources should be specified in the security requirement - My guess is they won't have a clue, in which case you can throw back in their face that you can't implement anything without a specification!anything is hackable, it's just a question of resources required.Is there actually a significant risk? Is there really a good argument to be able to do field upgrades to the higher model, as this involves significantly more work - can this be justified over a simple unit or board exchange scheme, based on how many people are actually likely to ever do it?If service contracts are the norm then it probably isn't a big deal anyway.Could you do something sneaky like say that all servers have a unique characteristic/range of their MAC address, and clients refuse to talk to a server with that address range?