Forums

Firmware Feature Unlock Method

Started by eeboy August 13, 2009
I am building a widget. Management wants to have several tiers of
capability which are all firmware enabled... meaning the hardware is
exactly the same just certain capabilities are 'unlocked' in firmware. A
typical scenario would be the end user purchases the base widget. A year
down the road they want to upgrade to the widget plus model. They would
purchase from us a unique 'key' which could be applied to the system
enabling the new features. 

I should mention that I am not so much worried that a user will attempt to
'crack' the 'key' scheme. The typical user would not be capable of this but
I would still like to make the scheme somewhat complex so that it's not
obvious and would take a bit of time to figure it out. The typical user
may, however, attempt to apply this one 'key' to their 4 other units.
Essentially trying to get 5 for the price of 1. So, the 'key' has to be
unique to the system. 

My only thought is to burn the widget serial number into FLASH during
manufacturing. The 'key' could then be compared against the serial number
(using some method) to produce a bit field which indicates which features
are unlocked. Make sense?

Any suggestions on how this can be better accomplished?

Thanks!
"eeboy" <jason@jasonorsborn.com> wrote in message 
news:bJOdnV80wOzpYh7XnZ2dnUVZ_tednZ2d@giganews.com...
>I am building a widget. Management wants to have several tiers of > capability which are all firmware enabled... meaning the hardware is > exactly the same just certain capabilities are 'unlocked' in firmware. A > typical scenario would be the end user purchases the base widget. A year > down the road they want to upgrade to the widget plus model. They would > purchase from us a unique 'key' which could be applied to the system > enabling the new features. > > I should mention that I am not so much worried that a user will attempt to > 'crack' the 'key' scheme. The typical user would not be capable of this > but > I would still like to make the scheme somewhat complex so that it's not > obvious and would take a bit of time to figure it out. The typical user > may, however, attempt to apply this one 'key' to their 4 other units. > Essentially trying to get 5 for the price of 1. So, the 'key' has to be > unique to the system. > > My only thought is to burn the widget serial number into FLASH during > manufacturing. The 'key' could then be compared against the serial number > (using some method) to produce a bit field which indicates which features > are unlocked. Make sense? > > Any suggestions on how this can be better accomplished?
My suggestion is to rely on encryption algorithms and cryptographic hash algorithms rather than "complexity" (although certainly some of these algorithms are non-trivial). You are handicapped in this application in that you don't have the ability to conceal anything from a technically savvy user. The obvious suggestion is as follows: a)Each key that you distribute is the concatenation of two parts: 1)The statement of features enabled by key, which might be as simple as an integer or a bitmask. 2)The SHA1 hash of the concatenation of: i)The unit serial number, AND ii)An integer or string "hardcoded" into the code so that it can only be found in the assembly-language instructions, not in a string table or other table, AND iii)At least one machine or peripheral register which is known to return a specific value. This value would not appear in the code anywhere, but the code would have the ability to obtain it easily on demand. The more obscure the better, AND iv)The "statement of features". b)To generate the key (at your location), just form the SHA1 hash based on the information above and append it to the "statement of features". c)To verify the key, the embedded code would verify that the SHA1 hash matches the statement of features and the other inputs to the SHA1 hash. In order to crack your scheme, the user would have to figure out all of the following: #1)The "hardcoded" data in (ii), above. #2)The "machine specific" data in (iii), above. #3)The algorithm you are employing. http://en.wikipedia.org/wiki/SHA_hash_functions Datesfat
>I am building a widget. Management wants to have several tiers of > capability which are all firmware enabled... meaning the hardware is > exactly the same just certain capabilities are 'unlocked' in firmware. A > typical scenario would be the end user purchases the base widget. A year > down the road they want to upgrade to the widget plus model. They would > purchase from us a unique 'key' which could be applied to the system > enabling the new features. > > I should mention that I am not so much worried that a user will attempt to > 'crack' the 'key' scheme. The typical user would not be capable of this > but > I would still like to make the scheme somewhat complex so that it's not > obvious and would take a bit of time to figure it out. The typical user > may, however, attempt to apply this one 'key' to their 4 other units. > Essentially trying to get 5 for the price of 1. So, the 'key' has to be > unique to the system. > > My only thought is to burn the widget serial number into FLASH during > manufacturing. The 'key' could then be compared against the serial number > (using some method) to produce a bit field which indicates which features > are unlocked. Make sense? > > Any suggestions on how this can be better accomplished?
Some targets have a unique serial number ID burned into the nonvolatile memory (for example the STM32). Using that feature would be useful for your purpose. You can base your key on the serial number and all your problems will be solved. JJS
Datesfat Chicks wrote:
> "eeboy" <jason@jasonorsborn.com> wrote in message > news:bJOdnV80wOzpYh7XnZ2dnUVZ_tednZ2d@giganews.com... >> I am building a widget. Management wants to have several tiers of >> capability which are all firmware enabled... meaning the hardware is >> exactly the same just certain capabilities are 'unlocked' in firmware. A >> typical scenario would be the end user purchases the base widget. A year >> down the road they want to upgrade to the widget plus model. They would >> purchase from us a unique 'key' which could be applied to the system >> enabling the new features. >> >> I should mention that I am not so much worried that a user will >> attempt to >> 'crack' the 'key' scheme. The typical user would not be capable of >> this but >> I would still like to make the scheme somewhat complex so that it's not >> obvious and would take a bit of time to figure it out. The typical user >> may, however, attempt to apply this one 'key' to their 4 other units. >> Essentially trying to get 5 for the price of 1. So, the 'key' has to be >> unique to the system. >> >> My only thought is to burn the widget serial number into FLASH during >> manufacturing. The 'key' could then be compared against the serial number >> (using some method) to produce a bit field which indicates which features >> are unlocked. Make sense? >> >> Any suggestions on how this can be better accomplished? > > My suggestion is to rely on encryption algorithms and cryptographic hash > algorithms rather than "complexity" (although certainly some of these > algorithms are non-trivial). > > You are handicapped in this application in that you don't have the > ability to conceal anything from a technically savvy user.
That depends on your definition of "technically savvy" and the OP's actual hardware/system implementation. E.g. some devices have "unique" data embedded within (e.g., some CPUs have serial numbers; the OP's system might contain something like an iButton, etc.). You also have to decide how sophisticated the user will be and/or how motivated he will be to hack it. Then, how easily other users could benefit from his hack (assuming the hacker elects to publish information on this). I.e., if you're making a $10 widget, it's just not worth their time to try to "steal" some features that, perhaps, "cost" another $2. [NB., there will always be those motivated by the intellectual challenge] Finally, you need to look at the *character* of your user base. I.e., if your users are "corporate types" who will later rely on your goodwill to continue doing business with them, they probably won't risk pissing you off by stealing from you. But, let's assume the OP is selling to The Unwashed Masses and, if getting morefeatures is just a matter of pushing buttons in some sequence (or typing in a password), then you have to rely on how closely you can guard your "secret"
> The obvious suggestion is as follows: > > a)Each key that you distribute is the concatenation of two parts: > 1)The statement of features enabled by key, which might be as simple > as an integer or a bitmask. > 2)The SHA1 hash of the concatenation of: > i)The unit serial number, AND > ii)An integer or string "hardcoded" into the code so that it can > only be found in the assembly-language instructions, > not in a string table or other table, AND > iii)At least one machine or peripheral register which is known to > return a specific value. This value would not appear in the code anywhere, > but the code would have the ability to obtain it easily on > demand. The more obscure the better, AND > iv)The "statement of features".
In some scenarios, you might also include an "expiration criteria". E.g., "until 12 June 2010" or "fopr 2,366 activations", etc.
> b)To generate the key (at your location), just form the SHA1 hash based > on the information above and append it to the "statement of features". > c)To verify the key, the embedded code would verify that the SHA1 hash > matches the statement of features and the other inputs to the SHA1 hash.
An alternative (similar) scheme is to use a public key scheme where you *encode* the above information with a private key and your device *decodes* the encoded "message" with a *public* key. This prevents the user from seeing the "algorithm" by which you encoded the original data (i.e., so they can't generate new data)
> In order to crack your scheme, the user would have to figure out all of > the following: > > #1)The "hardcoded" data in (ii), above. > #2)The "machine specific" data in (iii), above. > #3)The algorithm you are employing. > > http://en.wikipedia.org/wiki/SHA_hash_functions
The biggest issue IMO is that you are relying on flash to hold the unique identifier. AND, to hold the UPDATED (unlocked) data that enable the added capabilities. Depending on where tis flash is physically and electrically located, a simple scheme to beat all of this is to put the device into flash programming mode and just overwrite the original flash contents with the contents of an "unlocked" flash image. Yeah, then that unit will have the same "serial number, etc." as the unit from which the original image was extracted... but, unless those units can talk to each other (or some other party who can keep track of serial numbers to verify "no duplicates") they will both (even if "both" is actually *thousands*) work exactly as expected. The OP's problem has been "solved" to varying degrees over the years in many different ways. Without more knowledge of the intended market, the expected *losses* due to copying, etc. its hard to decide what to spend (effort, money) trying to discourage (not PREVENT) that. Consider just offering the advanced features as part of the base model, instead. Tack on a little bit of money if those fdeatures set you apart (and above) your competition. But, I think you'll find most folks get annoyed about having to repurchase something that they already *purchased* (which is what "buying an upgrade code" feels like to many people! Give them something tangible for their money instead of just a "feature" and they are more willing to buy) Just my 10b cents...

eeboy wrote:

> I am building a widget. Management wants to have several tiers of > capability which are all firmware enabled... meaning the hardware is > exactly the same just certain capabilities are 'unlocked' in firmware. A > typical scenario would be the end user purchases the base widget. A year > down the road they want to upgrade to the widget plus model. They would > purchase from us a unique 'key' which could be applied to the system > enabling the new features.
[...] Customers will love you for this. Paying extra for unlocking the feature which is already implemented in the code is disgusting. It is better to provide the different versions of firmware with the advanced features, or at least pretend that you are upgrading the firmware, not just unlocking the features.
> My only thought is to burn the widget serial number into FLASH during > manufacturing. The 'key' could then be compared against the serial number > (using some method) to produce a bit field which indicates which features > are unlocked. Make sense? > > Any suggestions on how this can be better accomplished?
Many flash memories have the unique serial number register and the OTP register which could be programmed to some secret value associated with the serial number. This is indended to be used as the protection against the copy cats, and you don't have to make any modification to the main firmware for every production unit. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
>> I am building a widget. Management wants to have several tiers of >> capability which are all firmware enabled... meaning the hardware is >> exactly the same just certain capabilities are 'unlocked' in firmware. A >> typical scenario would be the end user purchases the base widget. A year >> down the road they want to upgrade to the widget plus model. They would >> purchase from us a unique 'key' which could be applied to the system >> enabling the new features.
> Customers will love you for this. Paying extra for unlocking the feature > which is already implemented in the code is disgusting. It is better to > provide the different versions of firmware with the advanced features, or > at least pretend that you are upgrading the firmware, not just unlocking > the features.
You may be disgusted, but such functionality is pervasive today. And it's inescapable. It's a very common vendor/customer relationship. You pay for what you use and you don't get what you don't pay for. We all use many such products every day. You don't buy lines of code, you buy value. I think OP's proposed functionality is perfectly valid. JJS
On Aug 13, 3:04=A0pm, "John Speth" <johnsp...@yahoo.com> wrote:
> >> I am building a widget. Management wants to have several tiers of > >> capability which are all firmware enabled... meaning the hardware is > >> exactly the same just certain capabilities are 'unlocked' in firmware.=
A
> >> typical scenario would be the end user purchases the base widget. A ye=
ar
> >> down the road they want to upgrade to the widget plus model. They woul=
d
> >> purchase from us a unique 'key' which could be applied to the system > >> enabling the new features. > > Customers will love you for this. Paying extra for unlocking the featur=
e
> > which is already implemented in the code is disgusting. It is better to > > provide the different versions of firmware with the advanced features, =
or
> > at least pretend that you are upgrading the firmware, not just unlockin=
g
> > the features. > > You may be disgusted, but such functionality is pervasive today. =A0And i=
t's
> inescapable. =A0It's a very common vendor/customer relationship. =A0You p=
ay for
> what you use and you don't get what you don't pay for. =A0We all use many=
such
> products every day. > > You don't buy lines of code, you buy value. =A0I think OP's proposed > functionality is perfectly valid. > > JJS
i too am irritated by the feature unlock method on hardware i know. value added pricing is junk. if the code is internal to the uC that you are reading, you could just read protect it. If external, at least use an unlock sequence and read protect it. of course, like anything, there are ways around this too... all this code hashing BS, unlock sequences, having to find out numbers, etc... if your motivated and are already looking at the disassembled firmware, why would you bother? just find the check, hard code a "jump" over it to the location of the "privileged" mode that the conditional branch would take. to be fair, i think that you were talking about unleashing a general crack solution on the internet, then yes, you would need all those things. you would also have to fix the checksum on the FLASH and depending on the architecture, that attack might not work at all. [NB., there will always be those motivated by the intellectual challenge] agreed, where there is a will, there is a way.

John Speth wrote:
>>>I am building a widget. Management wants to have several tiers of >>>capability which are all firmware enabled... meaning the hardware is >>>exactly the same just certain capabilities are 'unlocked' in firmware. A >>>typical scenario would be the end user purchases the base widget. A year >>>down the road they want to upgrade to the widget plus model. They would >>>purchase from us a unique 'key' which could be applied to the system >>>enabling the new features. > > >>Customers will love you for this. Paying extra for unlocking the feature >>which is already implemented in the code is disgusting. It is better to >>provide the different versions of firmware with the advanced features, or >>at least pretend that you are upgrading the firmware, not just unlocking >>the features. > > > You may be disgusted, but such functionality is pervasive today. And it's > inescapable. It's a very common vendor/customer relationship. You pay for > what you use and you don't get what you don't pay for. We all use many such > products every day.
Garmin, HP come to mind. To me, this is a strong motivation for avoiding their products.
> You don't buy lines of code, you buy value.
I like to own the piece of hardware. The software is just the necessary evil to make the hardware work.
> I think OP's proposed > functionality is perfectly valid.
How would you feel about buying a house with a room locked up before you pay some extra? Or the V8 engine where some cylinders have to be enabled in the software? VLV
"D Yuniskis" <not.going.to.be@seen.com> wrote in message 
news:h61dm5$16s$1@aioe.org...
> >> b)To generate the key (at your location), just form the SHA1 hash based >> on the information above and append it to the "statement of features". >> c)To verify the key, the embedded code would verify that the SHA1 hash >> matches the statement of features and the other inputs to the SHA1 hash. > > An alternative (similar) scheme is to use a public key scheme > where you *encode* the above information with a private key > and your device *decodes* the encoded "message" with a *public* > key. This prevents the user from seeing the "algorithm" by > which you encoded the original data (i.e., so they can't > generate new data)
You may be right and I'd have to look it up, but are you sure that that type of security is a feature of the public/private key algorithms? I thought it was only guaranteed that once encrypted with the public key, you wouldn't be able to get any information about the private key? My fear is that given the private key (obtained from the embedded device), the user may be able to devise a public key that will also work with the private key? I'm gonna have to look that up. I think you're right, but I'm not sure. Datesfat
Datesfat Chicks wrote:
> "D Yuniskis" <not.going.to.be@seen.com> wrote in message > news:h61dm5$16s$1@aioe.org... >> >>> b)To generate the key (at your location), just form the SHA1 hash >>> based on the information above and append it to the "statement of >>> features". >>> c)To verify the key, the embedded code would verify that the SHA1 >>> hash matches the statement of features and the other inputs to the >>> SHA1 hash. >> >> An alternative (similar) scheme is to use a public key scheme >> where you *encode* the above information with a private key >> and your device *decodes* the encoded "message" with a *public* >> key. This prevents the user from seeing the "algorithm" by >> which you encoded the original data (i.e., so they can't >> generate new data) > > You may be right and I'd have to look it up, but are you sure that that > type of security is a feature of the public/private key algorithms? > > I thought it was only guaranteed that once encrypted with the public > key, you wouldn't be able to get any information about the private key?
You never see the private key! What you see is something encrypted *using* the private key. When you decrypt it (with the PUBLIC key), you recover the "cleartext". This is how you use this technology to *prove* you created something; you "sign it" with the private key (that only *you* know) and anyone can look up your public key (which is not a secret!) to decrypt it and see the cleartext. This is the opposite process of how you normally use this technology to send encrypted *messages* (which you don't want anyone other than the intended recipient -- i.e., the guy who has the private key that fits the PUBLIC key that you used to encrypt the message you sent *to* him).
> My fear is that given the private key (obtained from the embedded > device), the user may be able to devise a public key that will also work > with the private key? > > I'm gonna have to look that up. > > I think you're right, but I'm not sure.
Schneier is your friend.