Firmware Feature Unlock Method

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.