TM4C123/129 Flash memory security and Bootloaders

A

hmed, what are resource level of attacker you want to protect against?

I suggest you consider this scale

Casual hobbyists
Dedicated hobbyiSTS
Small Corporation, perhaps legal reverse engineering.
Large scale criminal organization
Large Corporation
National security organization

Robert

Sorry for the typeing, the editor is really lousy on this platform

There is, admittedly, a large degree of overlap in those categories but it does give some way to guide your thinking.

Robert

Hello Ahmed,

Besides the scale that Robert has mentioned, we are working on an application note/design to implement security for TM4C129x with boot loader examples that can scale to certain level of security. OTA is also not available for wireless interfaces yet.

Regards
Amit

Hello Robert and Amit,

Thank you both for your help. The scale actually is starting from hobbyists till small corporations. and basically, can anyone just connect a programmer and read the hex file on the controller's flash memory? How can I prevent this from happening to TM4C MCUs?
concerning the boot loader, OTA update function is not critical to me, I'd prefer if there is any currently available boot loader (through USB) from TI.
Also, when do you think that the boot loader examples with security can be published please?

Thank you,
Ahmed

Hello Ahmed,

There is JTAG lock feature on the TM4C device. This is a permanent setting on the device. Once locked a debugger cannot be connected. The only thing that can be done to remove the feature is a JTAG unlock sequence, which will erase the flash code as well. So in the end any one accessing the device shall only see 0xFFFFFFFF.

The USB boot loader is based out of ROM and Flash and there are examples in TivaWare (starting with the name boot_usb) that show how to use the boot loader.

The boot loader with security will be in 1Q'16 after reviewing the steps, content and code. Note that this will not be 100% secured device as security attacks take many shapes and form and TM4C or for that matter most general uC do not safeguard against it. Securing end equipments is rather more complicated than we think and the only actionable item is to make the attack effort (cost and time) higher so that the end result of a security breach is not worth the intruders effort.

Regards
Amit

--- (swear that I clicked "Reply" @ poster's writing - this response aims @ poster - not @ you, Amit.) ---

My friend - reality is (sometimes) harsh & unpleasant.   Vendor's Amit has given you a very fair answer - at the price point of these MCUs (here & from other ARM vendors) - you'd be wise "not" to drink vendor marketing dept.'s "Kool Aid/(assurance)" that such MCUs can be secured.

Consider please "Water Proof" vs. "Water Resistant."   Locking down JTAG prevents one of the easiest means of attack - thus is the equivalent of "water resistant."    Water Proof is far harder - and costlier - to achieve. 

Having past worked @ a "giant" semi-firm - staff & I could have your "JTAG Protected" code (most likely) w/in 15 minutes - faster if we really tried.   On occasion - firms will contact us to "recover" their "secure code" - and once we determine the legitimacy of their need - the process (usually) is quick/easy.

Realize that determined individuals/groups are able to find & hire those highly skilled, superbly equipped, and very well motivated.   Can you (really) expect your sub 10 (USD) MCU to resist such an attack - for long?

Poster Robert & I have written (here) of "secure MCUs" which sell for - at minimum - an order of magnitude beyond TM4C.   Alas - even these may be defeated - although time, effort & cost may rise exponentially.

What then to do - how can you protect yourself?   First to market - continuous innovation - making Sale & Use "Comfortable & Convenient" (i.e. NO 0Ω plague-istors and/or unwanted NMI)  - and attractive pricing.   Oh and it helps if you've chosen a "niche market" - unlikely to attract "giants" - and can acquire various legal protections which may discourage "usual suspects."   But "blocking JTAG" ... perhaps that (may) delay a multi-tasking 6th grader (maybe).

Vendor marketing department's proclamation of "security" sits (not far) from, "fool's gold" - on my bookshelf...

Hello Amit,

Thank you very much for your answer. but I was wondering why the bootloader examples exists for DK boards only and not for the EK? I downloaded the latest TivaWare and found the bootloader capability for special boards only. Can these examples ported to the EK123 or EK129 for example? or it will have problems in porting to these boards? is there any bootloader example for the EK123GXL board please?
Another question related to boot loader, I noticed a boot loader example in Stellarisware for the LM4F232, can this example run without any problems on the TM4C123GH6PM please?

Concerning the security, thank you for providing details on JTAG and dates for publishing the secured boot loader example. and of course I understand now the security level of the TM4C devices.

Thank you,
Ahmed

Thank you very mush for your through explanation about the security issues and the level of security for the MCUs! Can you please post a link to the topic where you and Robert wrote on secure MCUs please? I want to read it for more useful information.
as per the information you have provided to me, I assume that locking the hex file to the chip ID is also can be easily bypassed by any hacker, as well as any method i may know for protection.
And I fully agree with you about the steps to follow for protecting a product! I think it's enough to protect the MCU from hobbyists/small firms, and to follow your advice as well.

Thank you,
Ahmed

Hello Ahmed,

Indeed it is strange that boot loaders are on DK and not EK. One of the initial thought process was to have the same on DK due to the integration of LCD panels, that could use both the boot loaders and grlib to show visual update process. The same can however be modified for EK by removing the grlib drivers. We would assist in doing so as well via the forum (in the past this has been done). Also the next TivaWare release has the boot loaders implemented for EK boards as well.

The application note for boot loaders is planned for end of this month that will basically use a EK-TM4C123GXL to work as a boot loader interface for other TM4C products with PC based application for control and configuration. The source code for PC host and EK-TM4C123GXL will also be available along with the binary and executable.

Regards
Amit

The JTAG disable will stop the casual hobbyists.

Stopping the dedicated hobbyist is more difficult. Consider that the disable is a single bit set somewhere on the ic. All the hobbyist needs to do is change that one bit. Infamously, on one micro, it reputedly was as simple as drilling in a particular part and shining a UV light on that portion of the exposed ic. Most ic's require something a little more sophisticated which may strain the resources of all but the most dedicated hobbyist.

That leads to small corporations, if they are set up for it, this is well within their capabilities. There used to be, maybe still is, a grey market locally providing decoders for satellite TV receivers. Grey rather than black because of geography. The satellite companies would change encryption regularly and updated replacement code would generally not be far behind. And these were not large companies.

As cb1 notes your protection is going to be in quality and in the HW associated with your sw. If your HW is copied it's usually easier to prove infringement since it is physically apparent and perhaps visually obvious.

Robert