Reply by Clint Sharp August 15, 20092009-08-15
In message <bJOdnV80wOzpYh7XnZ2dnUVZ_tednZ2d@giganews.com>, eeboy 
<jason@jasonorsborn.com> writes
>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.
How about using something like a teaclipper to load up new firmware with the features enabled? Obviously teaclipper is for PIC hardware but the basic idea should be applicable to any hardware with ISP capabilities and you get bug fix capability as well.
>Thanks!
-- Clint Sharp
Reply by bigbrownbeastie August 15, 20092009-08-15
On Aug 14, 3:06=A0pm, ajacks504 <adam.p.jack...@gmail.com> wrote:
> On Aug 14, 4:09=A0am, Boo <reply_to_group_not_me@spam_me_no_spam.net> > wrote: > > > > > >> 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? > > > Was the house the same price as other houses with (n-1) rooms ? =A0If s=
o then
> > providing the unlock price was no more than the difference between the =
value of
> > other houses with (n) rooms and the original price then that would seem=
like a
> > good thing to buy as a step on the ladder. =A0Cheaper than having to mo=
ve when a
> > new pair of feet arrive. > > > =A0> Or the V8 engine where some cylinders have to be enabled > > > > in the software? > > > Ditto. =A0So long as the original price reflects the fact that only 6 c=
ylinders
> > are available and the unlock price is no more than the difference then =
why is
> > that bad value ? > > > I think you are approaching it from the wrong aspect : =A0if a customer=
doesn't
> > require an advanced set of features then ISTM it's wholly positive from=
their
> > POV to give them the option of avoiding the software development costs > > associated with features they don't require. > > > -- > > Boo > > douche.
i like how mature google groups have become.
Reply by ajacks504 August 14, 20092009-08-14
On Aug 14, 4:09=A0am, Boo <reply_to_group_not_me@spam_me_no_spam.net>
wrote:
> >> I think OP's proposed functionality is perfectly valid. > > > How would you feel about buying a house with a room locked up before yo=
u
> > pay some extra? > > Was the house the same price as other houses with (n-1) rooms ? =A0If so =
then
> providing the unlock price was no more than the difference between the va=
lue of
> other houses with (n) rooms and the original price then that would seem l=
ike a
> good thing to buy as a step on the ladder. =A0Cheaper than having to move=
when a
> new pair of feet arrive. > > =A0> Or the V8 engine where some cylinders have to be enabled > > > in the software? > > Ditto. =A0So long as the original price reflects the fact that only 6 cyl=
inders
> are available and the unlock price is no more than the difference then wh=
y is
> that bad value ? > > I think you are approaching it from the wrong aspect : =A0if a customer d=
oesn't
> require an advanced set of features then ISTM it's wholly positive from t=
heir
> POV to give them the option of avoiding the software development costs > associated with features they don't require. > > -- > Boo
douche.
Reply by Boo August 14, 20092009-08-14
>> 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?
Was the house the same price as other houses with (n-1) rooms ? If so then providing the unlock price was no more than the difference between the value of other houses with (n) rooms and the original price then that would seem like a good thing to buy as a step on the ladder. Cheaper than having to move when a new pair of feet arrive. > Or the V8 engine where some cylinders have to be enabled
> in the software?
Ditto. So long as the original price reflects the fact that only 6 cylinders are available and the unlock price is no more than the difference then why is that bad value ? I think you are approaching it from the wrong aspect : if a customer doesn't require an advanced set of features then ISTM it's wholly positive from their POV to give them the option of avoiding the software development costs associated with features they don't require. -- Boo
Reply by D Yuniskis August 14, 20092009-08-14
Tim Wescott wrote:
> On Thu, 13 Aug 2009 09:08:08 -0700, D Yuniskis wrote: > >> 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. >>>> > -- snip -- >> 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... > > You didn't read the original post. The OP doesn't want this, his > management does. And if you haven't worked with irrational, immovable > dictates from management, then you've been self-employed for your entire > life.
An engineer's job is to educate management on the tradeoffs of various approaches. If engineer doesn't *think* about what he is doing and blindly does as he is told, he gets the management that comes with this sort of thinking. Tell your management: "I can do this. If you want the product to be *inexpensive* (to build, sell, etc.) then I will have to do it in a fashion that anyone with suitable motivation will EASILY be able to reverse engineer and *defeat* those 'protections'. And, nowadays, with self-publication via the Internet so common, it won't take long before any sort of hack to defeat this protection is published and exploited. Here, look at these N web sites with explicit details of how to: reprogram your cell phone (gee, I suspect Verizon, Cricket, etc. have much DEEPER POCKETS than we do *and* are highly motivated to keep people from taking one of *their* phones -- heavily subsidized -- and using it on some *other* provider's network... yet, the details for breaking their 'sophisticated' locks on their products are published in plain sight for all to see!), 'steal' TiVo, etc. Do we, with our limited resources, want to waste energy with a 'multitiered approach'? Or, would we rather come up with trivially different hardware designs/packaging that sidesteps this entire issue? For example, I could reduce the memory requirements of the basic product and squeeze it into a slightly cheaper hardware configuration to better maximize profits for that 'low end' device and still meet the target sell price. Then, I could move to a slightly more capable platform to offer the extra features we want to peddle to the 'upscale' market. Perhaps we might even want to take it a step further than we had originally planned to make a truly 'deluxe' model." Dealing with clients is no different than dealing with (employer) management. In some senses, it can be even worse as often they don't have the depth of experience/awareness to know what they can and can't realistically do with a technology. You still have to "educate them" regardless of whether you work for them as a full time employee or just a "one-time contractor". I don't claim to understand my clients' markets. I try to get a good idea of their customers' needs in the time that I have available for this. Common sense is often indispensible. And, try to educate the client on how he *might* address those needs. Whether that is defining a system that is future-safe; or hacking something together for a "zero time-to-market"; or some other crazy approach to an off-the-wall problem. But, the client calls the shots -- just like your "irrational management" scenario. (Of course, I am lucky in that if those decisions ultimately lead the company into making a bad marketing/implementation decision, *they* pay for them and not me) I didn't see anythiong in the original post that indicated the OP was averse to taking on this educational responsibility. Of course, he *may* just be interested in a pay check...
Reply by Tim Wescott August 14, 20092009-08-14
On Thu, 13 Aug 2009 09:08:08 -0700, D Yuniskis wrote:

> 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. >>>
-- snip --
> 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...
You didn't read the original post. The OP doesn't want this, his management does. And if you haven't worked with irrational, immovable dictates from management, then you've been self-employed for your entire life. -- www.wescottdesign.com
Reply by Nobody August 14, 20092009-08-14
On Thu, 13 Aug 2009 06:56:36 -0500, 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. > > 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?
The level of security for a given amount of effort depends upon the hardware. In particular, whether the user can read the flash and/or re-program it externally (meaning, without involving the existing firmware). If the device can be re-programmed externally, someone can reverse-engineer a fully-unlocked firmware image which is posted on the 'net for everyone to use. Any additional checks can be disabled in the firmware. If the device can't be re-programmed externally, life is much simpler, as you can make the portion of the firmware which allows reprogramming perform validation. Life is simpler still if the user cannot read the flash. Even if the key-generation algorithm becomes known, reverse-engineering a serial number from an existing key is hard provided that the hash function is secure, and the set of serial numbers is too large to use brute force. The simplest approach is for a key to be authenticated with a digest obtained by hashing the concatenation of the data (the unlock flags), the device's serial number, a salt, and a secret. The code which performs the unlocking would calculate the digest itself and check that the result matches the digest contained in the key. This won't work if the user can read the flash, though, as they can discover all of the code and data which is required to generate a valid key. In that situation, you need to use a public-key authentication system. Even if the user knows the algorithm and the correct answer, they won't be able to calculate the input which is required to obtain that answer. However, this is a fair amount of work, and may be impractical for a low-end microcontroller.
Reply by Nobody August 14, 20092009-08-14
On Thu, 13 Aug 2009 21:15:11 -0400, Datesfat Chicks wrote:

>> 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?
This is how many digital signature algorithms work. RSA encryption is anti-symmetric: what is encrypted with the public key can be decrypted with the private key and what is encrypted with the private key can be decrypted with the public key. The former is used for encryption, the latter for authentication. In each case, the private key is private and the public key is public.
> 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?
The device contains the public key; the private key remains in the hands of the manufacturer.
Reply by D Yuniskis August 13, 20092009-08-13
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.
Reply by Datesfat Chicks August 13, 20092009-08-13
"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