This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C1294KCPDT: Preventing embedded software upgrades from getting copied by putting lock

Part Number: TM4C1294KCPDT


I want to prevent my embedded software upgrade files from getting copied by unauthorised people on their hardware. How can i put a lock in my device and the upgraded software so that it gets upgraded only in my device and not anywhere else through USB or RS232.

  • Naman Kumar said:
    How can i put a lock in my device

    There are many different grades of "locks" - are there not?     You avoid (any) mention of your lock's "grade."    (i.e. resistance to attack)

    MCU's here are priced ~10 (USD) in volume - is it reasonable/realistic to expect, "high level security" in so low cost a device?

    You surely have noted that most all governments have been "hacked" - it is assumed that their "protections" exceed that offered by a ~10 (USD) device!

    There have existed very special - and far higher priced - MCUs which made extra efforts to, "Secure their code."

    The electronic trade press has long written about this dilemma - especially noteworthy (I believe) their finding that - most always, "Attackers are more skilled, have greater tech resources, prove more motivated, and are better financed - than those seeking protection!"     Thus it proves "safe to say" - if a "skilled other" wants your code - they shall have your code!      But really - who does?

    Most vendors offer several "gentle" code protection schemes/methods.     (almost all - quickly/easily overcome)       On many occasions - use of vendor "protections" - succeeds (only) in "locking out the (rightful) code developer!"

    Should you doubt this "security assessment" - simply ask the vendor (btw ANY vendor) to provide (in writing) a "Guarantee that by following their directed security methods - your code will not be improperly/illegally  accessed!"      No such vendor will "rise to that challenge" - recognizing the "bandaid" approach to security - which (unfortunately) is the "norm" for MCUs of this class.    (again - most all vendors suffer this weakness - this is no knock upon this vendor - just a simple, "statement of fact and unfortunate reality!")

    (in a past life - at another semi firm - we (sometimes) misplaced our code yet recovered "every byte" by simply "de-capping the MCU and then employing X-Ray.")

    A better approach (usually) is to arrive at the market (very) early - with a well performing product - priced fairly - and with sufficient stock to meet all delivery demand requirements.     (and then pray that no "giant" desires entry to your (hopefully) niche market - and overwhelms (you & all others...)   

  • Completely agree with cb1 and will add a couple of notes.

    As far as the capability of the protection the key question is cost. Not your cost but the attackers. How much is the attacker you are protecting against willing to pay to defeat your protection? You have to raise your protection so that the cost to breach it exceeds the price the attacker is willing to pay over the lifetime of the product.  Note that most microcontroller protections are inexpensive to defeat.

    However your request appears to be something a little different.

    Naman Kumar said:
    I want to prevent my embedded software upgrade files from getting copied by unauthorised people on their hardware.

    So if this is running on your own hardware, someone would have to first duplicate your hardware before running. That's your first point of protection.

    Naman Kumar said:
    so that it gets upgraded only in my device

    This is a somewhat different question, I think, than cb1 and I answered. Files are trivially copied, so you are looking at  a way of ensuring that you file is only usable on your hardware. Effectively, I think this means encryption. There are publically available libraries for this. The hard part, and it's very difficult to overestimate the effort, is keeping the decryption keys private. There is hardware support for that in external ICs.

    Again this begins a cost trade-off. The cost of implementing and managing vs your gain and how much it will cost your attacker to break it. Sophisticated encryption is not worth a penny if your key is 'password' or it's pasted on the back of your product.

    The cheaper method is just making your hardware unique enough and easily enough available that it's simpler/less risky to buy from you that produce a knock-off.

    Robert

  • Robert Adsett said:
    encryption is not worth a penny if your key is 'password' or it's pasted on the back of your product.

    Greetings friend Robert - although - "Did you have to "tell the world" cb1's (normal) 'password' AND its location?"     (although in fairness - (sometimes) our magnitude of security improves - due to the (heavily) discounted/aged adhesive we employ weakening - thus (possibly) offering (some) camouflage for our 'dislodged password.'

    Confess that I never considered the two fine points you identified/admitted.      Poster's use of "putting lock" (which strongly suggests "MCU lock") informed my consideration - which I believe will prove correct...

    It should be noted that we (both) identified, "Early delivery of a well-performing, needs meeting, fairly priced and available product" proves an effective defense (perhaps the only defense) against skilled hackers...

    Good noting your return - is your lawn (still) frozen?

  • Apologies for exposing your top-class security.

    Lawn is currently mud. We did get 56mm of rain (a month's worth) over Thurs to Sat. Happily I'm not in a flood zone, although our eastern neighbour (QU) called in the army to help with flood conditions.

    Robert
  • A security question needs to start with a threat assessment.
    Who is it you are trying to prevent from making copies? What resources do you expect that person/organization to have, and - to cb1_mobiles point - how much are you willing to spend yourself to keep them out? This also needs to be put in relation to what the impact is of an actual breach.

    If your device is communicating with something else - can you individually key your firmware somehow to verify validity against that other thing? For example, if you are connected to the Internet - can you run a check against a server? Encryption is easy to implement of course, but like Robert pointed out, useless without good key management. Maybe look into adding a specialized chip like the AT88SC118 to your hardware and require validation against it in your code?

    This problem is a bit like a water balloon; When you squeeze it in one place, another section pops out... I'd assume specialized security chips can also be de-layered & hacked with the right resources, but is it cost effective?

    You can obfuscate your code, use non-standard interfaces to make connecting at all a hassle, but to completely stop anyone from making a copy you have to keep it locked in inside a vault and not share it with anyone -- which probably is not working with your business model ;)

    You need to know your enemy to make reasonable decisions, and make it just difficult enough not to make it worthwhile for them.

    Good luck!

    </A>
  • One doubts our "security minded" poster (wanted) to hear the "bombardment of cautions" which have flooded upon him. (and apparently reached to, "just west of & including, Quebec.")

    Might it be that these are (very) "new poster" questions/issues - and "threat assessment" - has been (unlikely) to, "Blip poster radar?"     (10 (USD) my bet...)