I have been reading so many thing about leaks of surveillance recently,

Most of the things covered under NSA 2013 Mass surveillance disclosure

I use the chips of Microchip for designing few embedded systems. I may use ARM chips in future too for some systems.

My question is, are these chips really safe from back-doors theoretically?

I came across this article : Intel chips could let US spies inside: expert

It makes me wonder if chips are really safe from spying at hardware level?

  • 3
    \$\begingroup\$ There's some suggestion that the hardware random number generators may be biased or weakened. There's no evidence of a general purpose back door. But it's extremely hard to prove one way or another. \$\endgroup\$ – pjc50 Sep 20 '13 at 14:11
  • 10
    \$\begingroup\$ Would you believe any answer here that said they are safe anyway? I don't see how it is possible to answer this question to your satisfaction if the answer is they are safe. This question is therefore pointless. \$\endgroup\$ – Olin Lathrop Sep 20 '13 at 14:54
  • 1
    \$\begingroup\$ The question is in a way impossible to answer unless you're the NSA. However, I like the discussion it brings and the topic of security which is often overlooked in microcontrollers \$\endgroup\$ – Gustavo Litovsky Sep 20 '13 at 15:18
  • 2
    \$\begingroup\$ Nothing to see here, move along. \$\endgroup\$ – Samuel Sep 20 '13 at 16:20
  • 2
    \$\begingroup\$ A backdoor isn't something a piece of equipment is safe from. It is either a feature that it has, or a feature that it doesn't have. A tamper-proof chip could have a backdoor. Any black box with inputs and outputs can support a backdoor, added by the designer. \$\endgroup\$ – Kaz Sep 20 '13 at 18:23

If you engage your tin-foil beanie hat and look at currently commercially available technology - basically no.

Given the fact that you could fabricate, on a microscopic sliver of silicon, a CPU with storage & some sort of comms (wireless, NFC, waggling a spare pin, superimposing a comms signal as low-level noise on a pin, whatever) which would presumably only ever become active on command, then I don't really see that you can consider anything bigger than a grain of sand to be 100% NSA-proof. Possibly not even the grain of sand, depending on the fit of your beanie.

I'm half way through reading "Spycraft" by Robert Wallace & H. Keith Melton (highly recommended) and the stuff they were doing and building in the 1960s and '70s is still quite impressive even now. Compared to commercially-available stuff of the time, it's astounding. So, extrapolate that level of tech to modern standards, and basically they could put anything anywhere.

Likewise backdoors - hell, it's all over the place that they've got backdoors in all sorts.

A better question to ask is does it matter? or maybe should I worry about it? or even would they bother?

Frankly, people worry about the wrong stuff. Before this Snowden stuff broke, people were worrying about a bored police employee being able to watch them via CCTV scratching their arse on the high street, or ANPR cameras being a bit too efficient at catching them speeding. No-one (normal) was wondering if the interwebs were secure, or their iPhone, or whatever.

So, while I'm sure they could do something like this, I'm fairly sure it's not worth their while doing it, or your while worrying about it.

Look out for the little black helicopters.

| improve this answer | |
  • \$\begingroup\$ Yes security matters for few industries i work for.Hence i did ask that but looks like its not a problem unless i have some communication periphearal in my system. \$\endgroup\$ – Gopi Sep 20 '13 at 16:58
  • 4
    \$\begingroup\$ @Gopi It seems that you are also unaware of TEMPEST. You need to seal your system in a metal can that has no holes. \$\endgroup\$ – Joe Hass Sep 20 '13 at 17:10

A classic article on this sort of thing is Ken Thompson's Reflections on Trusting Trust. In the article, Thompson describes a way to insert a backdoor into an operating system by compromising the compiler. The backdoor in the compiler detects when it's compiling the login logic, and inserts a backdoor then. Furthermore, the compiler detects when it is compiling a new copy of itself, and inserts a copy of the backdoor into the compiler. Thus, you could rebuild the entire OS from clean source code and still have the backdoor present. The only way to find it would be to disassemble the compiled programs.

Thompson's attack is purely software, but let's see if we can invent a hardware attack. The classic attack against programs is the buffer overflow: overfill an input buffer in a program until you run off the end, overwriting the return pointer in the stack frame with a pointer back to your exploit code in the buffer. Tons of work has been done in modern systems to make this attack harder: checking bounds on the buffer, marking the buffer region as not executable, and limiting certain operations to only trusted code. That makes the job of an attacker much harder, but what if that attacker could insert a small finite state machine into the CPU itself?

The no-execute bit would be moot because it's just a piece of information that the CPU is free to ignore, and likewise for privilege rings. There is no need to overflow the buffer either if our malicious FSM is designed to detect a secret pattern in the values of sequential memory accesses, like what would happen when copying or comparing a string. The FSM would allow the CPU to operate perfectly normally as long as the key sequence was not present. A random key sequence only a few hundred bytes long would be almost impossible to trigger by chance, so the risk of accidental activation leading to discovery is low. Once activated though, you could have an in-circuit emulator that you control on any network connected machine in the world.

In theory, that's a pretty devastating attack. Is it practical, and even more importantly, is it real? It's hard to say. On one hand, it's easy to hide a few extra transistors in a modern CPU full of multiple epitaxial layers and 22nm scale features. On the other hand, if someone did discover the exploit, either before or after it was used, the economic and political consequences for the responsible parties would be severe. A chip manufacturer would have a hard time claiming that a third party put something in their mask set without their knowledge. Then again, with programmable microcode, the exploit doesn't necessarily need to be in the mask.

To really be sure, you'd have to design your own chip with a roll of rubylith and an x-acto knife. Why bother though? Your system is more likely to be vulnerable because of flaws in its own engineering. Why would an attacker take the risk and expense of attacking your chips at the foundry when they can just take advantage of one of the exploitable bugs already provided?

| improve this answer | |
  • \$\begingroup\$ It's easy to imagine in a reasonably sized CPU a hardware equivalent of the International Underhanded C Contest, where a certain arrangement of logic leads to an exploit that is deniable as an unintended consequence and not obvious to someone examining the code/schematic. \$\endgroup\$ – John U Sep 23 '13 at 8:06

That will depend on what the type of application. For this to be true, I guess you are talking about having a a Microchip microcontroller to send emails or/and post information to a server, then the information that you are sending can be compromised in some way during the communication or inside of the receiving host.

One way to avoid being detected by NSA, is to implement your own communication medium with your personal encryption algorithm in the microcontroller. For example to communicate with a couple of friends on the same street, it rather "easy" to implement a custom network using for example zigbee or some 800/400 MHz custom protocoll with custom encryption. This way you can be out of the radar...

But you can not compare the Microchip microcontrollers to a Intel processor. They come from a very different breed.

| improve this answer | |
  • \$\begingroup\$ Good info.Will keep in mind. \$\endgroup\$ – Gopi Sep 20 '13 at 16:58
  • 5
    \$\begingroup\$ Right. Come up with your own encryption and communications protocol that NSA can't crack. Use the highly secure 800/400 MHz frequencies. Good luck with that. \$\endgroup\$ – Joe Hass Sep 20 '13 at 17:08
  • \$\begingroup\$ Well... If you would connect a simple keyboard and display to a microcontroller and have time to encrypt the messages with AES256, then I guess sending them over 800/400MHz is not an issue. In fact, if you want to communicate with "local" friends that might be the best option since you will not be sending any packets over the internet... And again this is if you want to be texting friends that are in reach of an 800/400MHz signal. Each friend could also repeat the messages to others in order to extend your range... \$\endgroup\$ – teixeirafms Jun 5 '18 at 22:14

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