How to permanently lock JTAG

Which response??

Read above again - I answer multiple posts - several forums - on occasion the data uploads during composition.. (rarely does reader note this, "live" - you have...)

cb1_mobile said:

Beware though that, "real MCU code security" may not be achieved via simple JTAG port disable  (i.e. it may be possible to employ several other methods to read & extract your MCU's flash content - via non-JTAG means)

New poster, "restates/reaffirms" info far earlier supplied...

A serious/determined "hacker" is likely to have the tools/funds/time to easily "defeat" the bit primitive means employed by this (and most all other) MCU vendors.    As earlier stated - "secure MCUs" are available - but at great increase in cost.

Realize too that it is possible to "decap" the MCU - and via X-ray (and other methods) read the state of even protected memory.  Code Security - as practiced by most MCU vendors - is often more "illusion" than reality.

Defeat of JTAG/SWD may delay/discourage - yet not long impede - those skilled/determined...

Hi guys,

thanks for all the answers.  I really appreciate.

I missed the "Permanently Disabling Debug" section of the datasheet, I'll try that. Although I'm kinda confused now. Won't the "JTAG Unlock Sequence" restore the BOOTCFG register to factory settings thus enabling the JTAG back again? Well, I'll try both and see what happens.

Thanks again for you all for answering so fast!!

Lucas.

Hello Lucas,

Yes the JTAG Unlock Sequence will restore the BOOTCFG register to the factory setting. That is why i mentioned that you would need to ensure that after doing so the JTAG pins are not physically accessible.

Regards

Amit

Amit,

      The term "permanently" is a little bit wrong if you say that the JTAG Unlock Sequence will restore the BOOTCFG register to factory setting. Has TI verified this?

- kel

Hello kel,

The intent of the word "permanent" here is that from the time the device boots the JTAG will not be accessible. On the other hand if the application uses the flash code to change the JTAG IO's to GPIO then there still exists a finite time window for a debugger to connect to the CPU and halt the code execution.

Regards

Amit

Bottom line, there's no way to permanently disable the debug interface. The datasheet even states that "Disabling the debug interface is permanent and cannot be reversed." This is wrong information then. 

Grounding the pins makes things a little more difficult but one can lift the JTAG pins from the PCB and then run the Debug Unlock Sequence. At least the code will get erased after the unlock sequence, but I wanted to protect against flashing the microcontroller with custom firmware as well. 

Lucas.

Hi guys, 

just to let you all know, I've disabled the JTAG via the BOOTCFG register and it worked. But sending the "Debug unlock" sequence to the microcontroller indeed resets the BOOTCFG register to factory settings thus enabling the JTAG back again. I wish there were a way to permanently disable it. Maybe a feature to consider for the next release? 

Thanks anyway,

Lucas.

Hello Lucas,

It is true that it cannot be reverted. Why I say so is because unlike JTAG pins being converted by SW to GPIO, it can be reverted by SW to JTAG. The BOOTCFG when committed with Bit-31 cleared, it cannot be set again. Only a JTAG unlock can be used to recover the same.

Regards,

Amit

Lucas Cuminato said:

. At least the code will get erased after the unlock sequence, but I wanted to protect against flashing the microcontroller with custom firmware as well. 

 Hi, I saw in the past someone cut the JTAG pins... This has to be checked for legality, again as hacker prone, if I wish use a board I use that board IE changing CPU with a new one.

 Erased CPU is just breaking the warranty and never board can be serviced or done at higher price.

 If you wish a secured processor enjoy this technology:

http://www.we-online.com/web/de/leiterplatten/produkte_/embedding/lasercavity_1/Einleitung.php

.. But again is just more and more difficult but not impossible!

I once had a discussion regarding how to prevent tampering of ARM microcontroller. Preventing tampering means the code is still in the microcontroller, no matter what method they try to inject code into the microcontroller. I answered these below. I think these below are a good combination to prevent tampering, However, I am not entirely sure as I have not verified if these 3 below would prevent tampering. 

1. Remove the JTAG connector.
2. Disable JTAG.
3. Set the Flash Protection bits of the microcontroller.

- kel

To reiterate cb1's wise remarks:

Asian manufacturers seeking to clone a device can rapidly decap and x-ray to read out the code.

Lock out will only prevent hobby tinkerers from getting in.

David Hubbard said:

Asian manufacturers seeking to clone a device can rapidly decap and x-ray to read out the code.

 Hi, reverse silicon is not only used in the worst way, is also a method of check silicon is what expected and loyal patent assurance:

 USA examples:

http://www.siliconinvestigations.com/

http://www.chipworks.com/en/technical-competitive-analysis/reverse-engineering-services/silicon-benchmarking

 It's research about how secure is a product example:

https://srlabs.de/

David Hubbard said:

Lock out will only prevent hobby tinkerers from getting in.

 Don't be so sure.. Sulphuric acid and acetone or decapage solution are available at every DIY store, the only blocking on is the wavelenght, when you leave the 300-800nm traces are no more visible with optical microscope so you also need X-ray laser to point silicon cell.. This is blocking hobby linker till they don't have infinite money resource and X laser are not accessible to everyone nor xray can be focused in a simple manner. If you are in the visible wavelength then a simple hobby boy can afford some reverse too.

http://siliconzoo.org/tutorial.html

David Hubbard said:

Asian manufacturers

 My customer some year ago sent a GAL device to an asian firm to reverse.. They sent back a programmed IC but it wasn't working at all. When I was young I made an automated program that generate stimulus thru an hardware specialized test bed reading state of output pin(H,L,Z), this test bed never worked on new pc but a new one built on Agilent vector pattern generator and logic analyzer done same result by hand reversing internal logic... This require a day per chip, the automated test bed some hour on old pc running @8MHz I hope few minutes on new one....

 Time changed resource:

 Young I was dreaming about having an LA and instrumentation lab, time to think how to do..

 Now I own a lab, experience but no much free time....

Roberto - all good points. Hobby tinkerers are more resourceful than businesses are willing to admit!

I always feel like it's a tragedy that businesses are so concerned about reverse engineering by hobbyists. I understand that businesses like to paint them as competitors but frequently it is just a young engineer trying to learn.

Good business models do not require advanced protection measures. This is not just naive, it's where a lot of businesses are moving. Instead of spending countless engineering hours developing custom hardware, a quick software dev team can produce all that's needed and the real value can be in the brand, quality control, customer service, cloud integration, and fast time-to-market.

David Hubbard said:

I always feel like it's a tragedy that businesses are so concerned about reverse engineering by hobbyists. I understand that businesses like to paint them as competitors but frequently it is just a young engineer trying to learn.

 You bet it, when I was Young forever we wished to have source code of UNIX, we where designing PCB by hand on paper, old cad where too much expensive, more than full building price, now we can have  CAD and BSD for free, again we lost a lot of time waiting to use some instrument of college, we where learning from a growing technology. This time thing are different and many old instrument or inexpensive new one are available for less opening new way to old and new hobby entusiast, the worst is new student lost interest due to wrong economy models, so this compensate for HAcking nature.

 About chip and inexpensive tech also see this:

http://hackaday.com/2012/07/05/reverse-engineering-silicon/

 Somewhere I think still own an old poster with 8051 CHIP layout instructing where to point a laser to clear protect bit, it was simple to remove metal cover from ceramic chip.

 I also remember near year 1990 on a fair a FAE of Microchip laugh in front of me about xor protection... It say'd I don't know about how xor work...  The day after microchip "1 2 3 readback" program was ready, buried bit in silicon doesn't help mask biggest issue when you can read xored nibbles I don't know xor property? yes read, zero one nibble, read again, zero another nibble, read again xor and shift and you have all 3 nibble of program for free in no time.. Big EPIC fail! ...

 On Year 2002 this same FAE repeated that error, commercial too raised price so all microchip got the WASTE BIN after good FAE presented me option of MSP430 16bit instead of 8bit expensive competitor... Less expensive, more flexible so I moved some code from CPLD to software too..

 10K chip unit where sold BY TI instead of Micp and them got no more attention from us nor for LCD glass too.

 Time change and fast time to market drive us to do crazy thing instead of plan old best quality test.

 Again play role has changed, young hacker are less and still plagued by lamer activity.

@ David/Roberto,

You guys ride, "tall in the saddle" - good/great points (I believe) by both.  (David - thanks your kind remarks - you are becoming true/valued power here!  (even and especially when you disagree w/cb1...)

Recall earlier statement (this reporter) security via this class MCU is "illusion at best!"  Much like, "Regulators of Wall Street are never as smart, motivated, rewarded and up to date - as those they seek to regulate!"  

In our small firm's (pitiful) attempt to gain "some security" we often add small CPLD and change the address sequencing of external memory from, "normal/customary."  This is as effective as tall brush is in impeding charging lion - but bit delays the cracking of our "hot" code.  (and "calms" investors - till they read another tech article...)

In taking past tech firm public - best advice we received was, "Innovate, innovate, innovate" - price fairly/realistically, and deliver in volume and on time!  Helps also to target "niche" area - less attractive to those w/the resources to "laugh at" your (pathetic) attempts to secure...

(David - if you'd be so good/kind - do, "enable conversations" {bit buried} but w/in forum register/sign-up sheet.  Much like your style - an exchange may prove to our joint benefit...have harvested several "great" contacts that way)

May be that the real/true value of those w/real-world experience registers strongly - this thread.  Company line - pushed/parroted by vendor (and one other) - pales by comparison...  (we taking over - boyz!)

cb1_mobile said:

In our small firm's (pitiful) attempt to gain "some security" we often add small CPLD and change the address sequencing of external memory from, "normal/customary."  This is as effective as tall brush to charging lion - but bit delays the cracking of our "hot" code.

 Hi CB, this is dependant to who is on the cracking side and why is there.

  Old design analysis reported cracking a multiple MSP and two CPLD supporting an high speed custom protocol costed more than buy the code again from me. This is a protection otherwise you can go to lawsuit too.

 Another way is what is doing your code and who can be interested..

 If you are controlling a pulse ion rocket engine.. I can be curious but just ane extraterrestrial can be interested to break your code. If you are selling an Iphone I fear too many are interested to get your knowledge...

Crypt code again is just stopping street man, swapping address data is just old like me and still resemble Julius Cesar small crypt. CPLD are some way secure but not much more than a uC alone.

 Again what is really covering security is uncommon knowledge. Arrogance presumption ignorance break law but never break a bit.

CB1 - thanks for the kind words. I discovered it was defaulted to "Friends Only" under "Allow Conversations From" - never would have found that without being pointed in the right direction.

David Hubbard said:

never would have found that without being pointed in the right direction.

@David - and that's my story too - as (delightfully) expressed by my gf - whether I'm "lost" upon land or high seas...

I've produced brief (manuscript) for your review - check your fresh (now jammed) correspondence...

Let the record show some here (still) try to push a stone to the top of a mountain - using just their nose.

May reality - or business sense - arrive here?   (even briefly)  

Would the US "Gold Repository" Fort Knox - employ a 10 (USD) MCU (from any vendor) to guarantee security?

All solutions proposed are "bandaid" at best - and succeed FAR BETTER in "locking out" (hopeful) users!

Smart, sophisticated, well equipped/skilled/financed hackers will have your code.   (if they want it...)

Reality - even when "unpleasant" must be accepted...

Hi Amit,

To ensure that I understand right...

if I used the JTAG bit to block the code, I can't download or debug any Code Again on this Blocked Tiva Kit , Unless unblocking the Jtag Bit again and this will erase the Last Code in the flash memory. 
and It was better to cut the Jtag pins also. 
Is this right?

and How to block or unblock the JTAG bits ?

Thanks in advance.