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