Tiered Firmware Features

I posted this earlier, but I believe it may have been discarded due to the
subject heading. Several key words in it could have confused an automated
script to discard it as junk. Crossing my fingers that I don't double post
here...

I am developing a widget. Management wants me to structure the firmware in
such a way that the widget has a few tiers of functionality. The
functionality is all enabled in firmware. So for example a user may
purchase the base unit and then decide at a later date to upgrade to a
second or third tier of functionality. The idea is to provide a unique key
to unlock the features.

I have the idea to relate the key to the serial number of the widget. This
takes care of the unique aspect preventing the key from being applied to
other widgets that have not been upgraded. So, the user enters the key and
it's hashed against the serial number to produce a bit field which
indicates what features are to be enabled.

Any suggestions as to an alternate approach? Or perhaps a robust method to
produce the desired result from a key and device serial number?

eeboy wrote:
> I posted this earlier, but I believe it may have been discarded due
> to the subject heading. Several key words in it could have confused
> an automated script to discard it as junk. Crossing my fingers that I
> don't double post here...
>
> I am developing a widget. Management wants me to structure the
> firmware in such a way that the widget has a few tiers of
> functionality. The functionality is all enabled in firmware. So for
> example a user may purchase the base unit and then decide at a later
> date to upgrade to a second or third tier of functionality. The idea
> is to provide a unique key to unlock the features.
>
> I have the idea to relate the key to the serial number of the widget.
> This takes care of the unique aspect preventing the key from being
> applied to other widgets that have not been upgraded. So, the user
> enters the key and it's hashed against the serial number to produce a
> bit field which indicates what features are to be enabled.
>
> Any suggestions as to an alternate approach? Or perhaps a robust
> method to produce the desired result from a key and device serial
> number?

Your post certainly made it through this time.  Your concept sounds good, 
but I don't have any better solutions for you.

Scott

On Aug 13, 8:31=A0pm, "eeboy" <ja...@jasonorsborn.com> wrote:

> Any suggestions as to an alternate approach? Or perhaps a robust method t=
o
> produce the desired result from a key and device serial number?

The method you have described is one common method. Another method is
for the device to generate a random challenge and decrypt a response
provided by your unlocker. This avoids the need for serializing the
device's firmware.

On Aug 14, 3:31=A0am, "eeboy" <ja...@jasonorsborn.com> wrote:
> ...
> Any suggestions as to an alternate approach? Or perhaps a robust method t=
o
> produce the desired result from a key and device serial number?

How about FCS32 of the two? Mind you, I have *never* done that, just
recently
handled ethernet address hashing which was done this way and thought
it might be
an idea...

Dimiter

-----------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/