Protecting Spark hardware from bad/malicious code

Hardware
1

Greetings, fellow Spark enthusiasts!

I recently fried one of my Cores by inadvertently touching the uFl swivel connector to pin D0 which, at the time, was programmed as an OUTPUT:

This made me wonder about best practices when building a robust hardware system using the Core/Photon/Electron.

Suppose I have a circuit that has a bunch of sensors, switches, etc. all configured to be inputs for the Core with potentially very low (or zero in the case of a normally closed switch) impedance. Suppose now that I incorrectly flash the Core with firmware that sets those input pins to OUTPUT. Because the components attached to those pins now effectively short the output, the Core is instantly fried. If there are enough of these happening at the same time, there may even be potential of an electrical fire, though I am not sure how likely that is.

A more extreme scenario: a hacker breaks into the Spark Cloud and flashes all online cores with a simple program that sets all the pins to OUTPUT in the hopes of damaging them in the process. This is not about Spark Cloud security per se, but rather the potential consequences of someone getting hold of your auth token.

So, the question I have for you is:

Does it make sense to ALWAYS design a circuit where every pin connected to external components goes through a 220 Ohm resistor, effectively preventing the fatal over-current in the scenarios described above?

And if so, would adding these adversely affect the functionality of attached peripherals, especially something running I2C or SPI?

Would love to hear everyone’s thoughts!

Thanks,
Alexander

1 Like
2

I cant comment on the electrical question you pose but if a hacker gets into your core he could easily erase all the fash memory, reset the device, and now all the cloud keys and backup firmware are gone. Recoverable? Yes. Annoying as hell? Also yes

3

First off, put some heat-shrink tubing or electrical tape on that u.fl connector!

Most of the time we worry about signal conditioning and protection on inputs since real-world sensors have the potential come in contact with ESD (static electricity) or 110/220V AC. So for inputs, yes, people work hard at protection and conditioning.

For outputs I think the answer is only sometimes do we worry about it. Let’s say we did put the imaginary 220ohm series resistor on every output–what do we gain? Well we get some short circuit protection but at the expense of speed and voltage. Maybe we can no longer run our SPI device at full speed or light our status LED as brightly.

Sometimes we do want to limit speed, particular the edge-rate (rise-time or fall-time) of a signal. In that specific case we do add series resistors at the source to help control the overshoot due to too fast and edge or provide a better electrical match to a long wire. In this case we have to look at the capacitance we are driving and think about the DC case with say 20mA of output current can we still meet the minimum logic levels to guarantee the next chip can correctly tell a one from a zero. But this is really to solve a signal integrity problem and not for safety or protection.

4 Likes
4

Thanks for posting this, it is a great "Watch Out!!!" for everyone working with the uFl antenna.

1 Like
5

Thanks @bko!

Makes sense, and I guess given your point on compromising digital data signal integrity with short protection resistors I would rephrase my thought as follows:

It’s a good idea to add a 220ohm (or greater) resistor to any analog input connected to a low impedance component.

So, in the case of a normally-closed switch, I believe the Core will still read a digital LOW when a pin is pulled to ground via this resistor (or HIGH if we’re connecting it to 3V3). But in the case of bad/malicious programming, no damage would be done if it were set as an OUTPUT.

On the other hand, when I have an SD Card connected to the SPI pins (A2-A5), there is arguably no benefit in connecting the resistor, since, even if I were to set all four pins on HIGH (or LOW), it would not damage the core or the SD card, but simply create a hardware error condition that could be cleared by resetting the device and reflashing it with good code, right?

In my particular project, I have a number of analog sensors attached to the Core: a photo resistor to measure ambient light, a Sharp IR distance sensor, and a VOC gas sensor. All these, being 5V devices, have to go through a 4.7K/10K voltage divider to protect the analog inputs on the Core from over-voltage. So, I guess this takes care of my concern also, since setting the pin to OUTPUT would flow the current back though at least the 4.7K resistor.

Your point about connecting impedance matching resistor on longer wire runs sounds familiar also. I had to do something like this to drive a set of WS8212 addressable LEDs per Adafruit instructions. Is this generally the technique used when running a long data line between the Core and another digital peripheral? E.g. an I2C device or even something as simple as a single wire bit-bang driven DHT22 temp/humidity sensor?

Thanks again for weighing in on this topic! As for the u.Fl connector, it will definitely get some heat shrink tubing if I get another external antenna Core. At the moment, chip antennas seem to work great for my application and they certainly make things less “dangerous” :wink:

Alexander

1 Like