Firmware Feature Unlock Method

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.

Datesfat

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

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"

In some scenarios, you might also include an "expiration criteria". E.g., "until 12 June 2010" or "fopr 2,366 activations", etc.

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)

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...

[...]

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.

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

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

A

ar

d e

or

g

t's

ay for

such

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.

Garmin, HP come to mind. To me, this is a strong motivation for avoiding their products.

I like to own the piece of hardware. The software is just the necessary evil to make the hardware work.

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

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

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).

Schneier is your friend.

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.

The device contains the public key; the private key remains in the hands of the manufacturer.

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.

-- snip --

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

Tim Wescott wrote:

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...

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.

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

u

then

lue of

ike a

when a

inders

y is

oesn't

heir

douche.

you

o then

value of

like a

ve when a

ylinders

why is

doesn't

their

i like how mature google groups have become.

In message , eeboy writes

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.

--
Clint Sharp