0

Oflate there has been a lot of interest in Microcontroller community about security with ARM TrustZone for MCUs. TrustZone is deemed to protect MCUs against software attacks. My question is what are the ways a malicious code can even enter an MCU?

3
  • Here's a good example use-case, I think. I couldn't find a reference in my quick google search, but I remember reading some discussion that this tech would enable Router manufacturers to allow custom firmware like DD-WRT while still complying with the FCC ruling that manufacturers prevent users from messing with the device's transmission power. hackaday.com/2015/08/31/… – nbering Apr 14 '18 at 20:07
  • This article probably covers what I was talking about above, better. The basic idea being to protect the radio-controlling firmware while allowing loading of other custom open source software on the router. arstechnica.com/information-technology/2016/05/… – nbering Apr 14 '18 at 20:13
  • usually via existing built-in firmware update routines. in some edge cases, via file uploading+interpretation, poor handling of fuzzy inputs, overflows, and sqli – dandavis Apr 17 '18 at 4:57
2

I apologize that I am answering this from a little bit of a vague higher level, since I'm not as familiar with the specific attacks that are made against embedded systems.

Commercial Applications for TrustZone

In my comments on the question, I've linked some news articles about Router manufacturers needing to have a trusted environment to run WiFi radio firmware, separate from untrusted code (ie. DD-WRT) to comply with an FCC ruling that manufacturers must put security measures into place to prevent consumers from boosting their 5GHz signals to levels that cause interference outside their rated levels.

This demonstrates a type of attack where a user is intentionally loading code that is not trusted by the manufacturer. This type of crafted software update could be relatively benign (depending on your perspective), or it could be malicious code.

Attack Mitigation

Having a trusted code layer, like ARM TrustZone provides, can also be used as a secure bootloader. To illustrate the purpose of such a system, it helps to understand that a program cannot verify it's own integrity. If one were to check digital signatures, an attacker could just modify the signature that the program was checking against. With a secure loader, you can be assured that the verification process has not been tampered with, and thus can be used to prevent an application that has not been signed (or has been signed with an invalid key), from loading.

The same technique could be used to validate software updates before installation, preventing malicious firmware installation.

0

How to make MCU secured? - Write program and lock program memory from reading externally.

How to make MCU firmware Trustful?

Probably having a root key, with now access form outside. It can be a part of your code. Implement authentication when interacting with other devices, use derivation keys. Implement versioning, to deny working with outdated devices. Implement secured update. Also MCU can work with external memory, so this memory can be vulnerably for mounting attacks. All this is not TrustZone (c) ARM CPU, but how we can make MCU based more secured.

2
  • Just because some MCUs let you lock firmware or memory does not mean you can actually secure it. Think of the ever-popular 8051 for example which has both a firmware read lock and write lock bit. Even with those locks set, it's still fairly trivial to bypass using glitching attacks. In other words, common 8051s are not secure. Locking the data is useless. – forest Apr 17 '18 at 9:44
  • Fair enough, but it is easier build reliable and secured lock mechanism, than full blown Arm Trust Zone, besides not all Trust Applications are encrypted, they are just signed and executed in secured env. – VovCA Apr 17 '18 at 16:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.