Embedded Security (EE Tip #139)

Embedded security is one of the most important topics in our industry. You could build an amazing microcontroller-based design, but if it is vulnerable to attack, it could become useless or even a liability.  EmbeddSecurity

Virginia Tech professor Patrick Schaumont explains, “perfect embedded security cannot exist. Attackers have a wide variety of techniques at their disposal, ranging from analysis to reverse engineering. When attackers get their hands on your embedded system, it is only a matter of time and sufficient eyeballs before someone finds a flaw and exploits it.”

So, what can you do? In CC25, Patrick Schaumont provided some tips:

As design engineers, we should understand what can and what cannot be done. If we understand the risks, we can create designs that give the best possible protection at a given level of complexity. Think about the following four observations before you start designing an embedded security implementation.

First, you have to understand the threats that you are facing. If you don’t have a threat model, it makes no sense to design a protection—there’s no threat! A threat model for an embedded system will specify what can attacker can and cannot do. Can she probe components? Control the power supply? Control the inputs of the design? The more precisely you specify the threats, the more robust your defenses will be. Realize that perfect security does not exist, so it doesn’t make sense to try to achieve it. Instead, focus on the threats you are willing to deal with.

Second, make a distinction between what you trust and what you cannot trust. In terms of building protections, you only need to worry about what you don’t trust. The boundary between what you trust and what you don’t trust is suitably called the trust boundary. While trust boundaries were originally logical boundaries in software systems, they also have a physical meaning in embedded context. For example, let’s say that you define the trust boundary to be at the chip package level of a microcontroller.

This implies that you’re assuming an attacker will get as close to the chip as the package pins, but not closer. With such a trust boundary, your defenses should focus on off-chip communication. If there’s nothing or no one to trust, then you’re in trouble. It’s not possible to build a secure solution without trust.

Third, security has a cost. You cannot get it for free. Security has a cost in resources and energy. In a resource-limited embedded system, this means that security will always be in competition with other system features in terms of resources. And because security is typically designed to prevent bad things from happening rather than to enable good things, it may be a difficult trade-off. In feature-rich consumer devices, security may not be a feature for which a customer is willing to pay extra. The fourth observation, and maybe the most important one, is to realize is that you’re not alone. There are many things to learn from conferences, books, and magazines. Don’t invent your own security. Adapt standards and proven techniques. Learn about the experiences of other designers. The following examples are good starting points for learning about current concerns and issues in embedded security.

Security is a complex field with many different dimensions. I find it very helpful to have several reference works close by to help me navigate the steps of building any type of security service.

Schaumont suggested the following useful resources:

Don’t Trust Connectors, Solder, or Wires (EE Tip #138)

Engineer Robert Lacoste is one of our go-to resources for engineering tips and tricks. When we asked him for a few bits of general engineering advice, he responded with a list of more than 20 invaluable electrical engineering-related insights. One our team’s favorite “Lacoste tips” is this: don’t trust connectors, solder, or wires. Read on to learn more.

One of my colleagues used to say that 90% of design problems are linked either to power supplies or to connector-related issues. It’s often the case. Never trust a wire or a connector. If you don’t understand what’s going on, use your ohmmeter to check if the connections are as planned. (Do this even if you are sure they are.) A connector might have a broken pin, a wire might have an internal cut, a solder joint might be dry and not conductive, or you might simply have a faulty wiring scheme. (See the nearby photo.)

Using the wrong pinout for a connector is a common error, especially on RS-232 ports where it’s approximately 50% probable that you’ll have the wrong RX/TX mapping. Swapping the rows of a connector (as you see here) is also quite common.

Using the wrong pinout for a connector is a common error, especially on RS-232 ports where it’s approximately 50% probable that you’ll have the wrong RX/TX mapping. Swapping the rows of a connector (as you see here) is also quite common.

Another common error is to spend time on a nonworking prototype only to discover after a few hours that the prototype was working like a charm but the test cable was faulty. This should not be a surprise: test cables are used and stressed daily, so they’re bound to be damaged over time. This can be even more problematic with RF cables, which might seem perfect when checked with an ohmmeter but have degraded RF performance. As a general rule, if you find that a test cable shows signs of fatigue (e.g., it exhibits intermittent problems), just toss it out and buy a new one!—Robert Lacoste, CC25, 2013

 

Test Under Real Conditions (EE Tip #137)

The world’s best engineers have one thing in common: they’re always learning from their mistakes. We asked Niagara College professor and long-time contributor Mark Csele about his biggest engineering-related mistake. He responded with the following interesting insight about testing under real conditions.

Mark Csele's complete portable accelerometer design, which he presented in Circuit Cellar 266.  with the serial download adapter. The adapter is installed only when downloading data to a PC and mates with an eight pin connector on the PCB. The rear of the unit features three powerful rare-earth magnets that enable it to be attached to a vehicle.

Mark Csele’s complete portable accelerometer design, which he presented in Circuit Cellar 266. with the serial download adapter. The adapter is installed only when downloading data to a PC and mates with an eight pin connector on the PCB. The rear of the unit features three powerful
rare-earth magnets that enable it to be attached to a vehicle.

Trusting simulation (or, if you prefer, lack of testing under real conditions). I wrote the firmware for a large three-phase synchronous control system. The code performed amazingly well in the lab, and no matter what stimulus was applied, it always produced correct results. When put into operation in the field (at a very large industrial installation), it failed every 20 minutes or so, producing a massive (and dangerous) step-voltage output! I received a call from a panicked engineer on-site, and after an hour of diagnosis, I asked for a screenshot of the actual power line (which was said to be “noisy,” but we knew this ahead of time) only to be shocked at how noisy. Massive glitches appeared on the line many times larger than the AC peak and crossing zero several times, causing no end of problems. Many hours later (the middle of the morning), the software was fixed with a new algorithm that compensated for such “issues.” This was an incredibly humbling experience: I wasn’t nearly as smart as I had thought, and I really missed the boat on testing. I tested the system under what I thought were realistic conditions, whereas I really should have spent time investigating what the target grid really looked like.—Mark Csele, CC25 (anniversary issue)

Specs & Code Matter (EE Tip #136)

No matter how many engineering hours you’ve logged over the years, it’s always a good idea to keep in mind that properly focusing on specs and code can make or break a project. In 2013, Aubrey Kagan—an experienced engineer and long-time Circuit Cellar author—explained this quite well in CC25:

There was a set of BCD thumbwheel switches that I was reading into a micro. In order to reduce the number of input lines required, each 4 bits of a digit was multiplexed with the other digits and selection was made by a transistor enabling the common line of each switch in turn. This was standard industry practice. The problem was that in order to economize, I had used the spare transistors in a Darlington driver IC. Everything worked fine in the lab, but on very hot days the unit would fail in the field with very strange results.

Long story short, the saturation voltage on the Darlington transistor would increase with temperature to above the digital input threshold and the micro would read undefined switch settings and then jump to non-existing code. I learned three things: read and understand all the specifications on a datasheet, things get a lot hotter in a cabinet in the sun than the lab, and you should make sure your code can handle conditions that are not supposed to occur.—Aubrey Kagan, CC25 (2o13)

Want to share an EE tip of your own? Email our editors to share your tips and tricks.

One-Wire RS-232 Half Duplex (EE Tip #135)

Traditional RS-232 communication needs one transmit line (TXD or TX), one receive line (RXD or RX), and a Ground return line. The setup allows a full-duplex communication. However, many applications use only half-duplex transmissions, as protocols often rely on a transmit/acknowledge scheme. With a simple circuit like Figure 1, this is achieved using only two wires (including Ground). This circuit is designed to work with a “real” RS-232 interface (i.e., using positive voltage for logic 0s and negative voltage for logic 1s), but by reversing the diodes it also works on TTL-based serial interfaces often used in microcontroller designs (where 0 V = logic 0; 5 V = logic 1). The circuit needs no additional voltage supply, no external power, and no auxiliary voltages from other RS-232 pins (RTS/CTS or DTR/DSR).Grun1-Wire-RS232-HalfDup

Although not obvious at a first glance, the diodes and resistors form a logic AND gate equivalent to the one in Figure 2 with the output connected to both receiver inputs. The default (idle) output is logic 1 (negative voltage) so the gate’s output follows the level of the active transmitter. The idle transmitter also provides the negative auxiliary voltage –U in Figure 2. Because both receivers are connected to one line, this circuit generates a local echo of the transmitted characters into the sender’s receiver section. If this is not acceptable, a more complex circuit like the one shown in Figure 3 is needed (only one side shown). This circuit needs no additional voltage supply either. In this circuit the transmitter pulls its associated receiver to logic 1 (i.e., negative voltage) by a transistor (any standard NPN type) when actively sending a logic 0 (i.e., positive voltage) but keeps the receiver “open” for the other transmitter when idle (logic 1). Here a negative auxiliary voltage is necessary which is generated by D2 and C1. Due to the start bit of serial transmissions, the transmission line is at logic 1 for at least one bit period per character. The output impedance of most common RS-232 drivers is sufficient to keep the voltage at C1 at the necessary level.

Note: Some RS-232 converters have quite low input impedance; the values shown for the resistors should work in the majority of cases, but adjustments may be necessary. In case of extremely low input impedance, the receiving input of the sender may show large voltage variations between 1s and 0s. As long as the voltage is below –3 V at any time these variations may be ignore.— Andreas Grün, “One Wire RS-232 Half Duplex,” Elektor July/August 2009.