Dr. Dobb's Journal January, 2005
The day after I returned from last September's Boston Embedded Systems Conference, my friend Ess mentioned an interesting conversation he had while snaking a hands-free cellular-phone wire through his car's dashboard.
A well-dressed guy walked by, saw what Ess was doing, and they got to talking about those little touches you add to a favorite car. Ess, who's something of a tinkerer, showed off several mods, including his ExxonMobil SpeedPass epoxied onto the gas cap.
The guy observed that most people carry their SpeedPass on their key ring. It turned out he'd done a stint of valet parking and, whenever he and his compadres got a keyring with a SpeedPass, they'd use pliers to extricate the RFID chip, re-seal the case with a dab of glue, and enjoy free gas for a month.
As they say at http://www.speedpass.com/: "Always take your Speedpass device with you when you are away from your car, or when you leave your car keys with someone else—for example, in situations when you drop off your car for valet parking or for car repair service."
What's wrong with this picture?
This year, Embedded Security Seminar sessions ran in parallel with the familiar Embedded Systems Conference, describing the state of the art and where we must go from here. An emphasis on security is a welcome sight for an industry that's traditionally produced user-hostile interfaces with no security whatsoever.
Now that we're starting to build friendly equipment, though, we must contend with definitely hostile users, if not overt attackers. Worse, those attackers will have the hardware in their hands, because that's what ubiquitous computing really means.
In the human realm, you must earn the trust of others, not assume it. You cannot, for example, expect them to simply hand you their money based on your assurances that you are an honorable person. Conversely, you will give someone else your money or your information only after you have established that they will handle it appropriately.
Trust can be personal, based on a long-standing relationship, or institutional, based on the rule of law applied to business transactions. While you may not know that big-box retail clerk personally, you can safely assume she will not make a bootleg copy of your credit card and that, if she does, the law is on your side.
In the network realm, however, trust is based entirely on the blind faith that a program professing to be trustworthy really is. Do you know exactly what an ActiveX control means when it claims to have a valid signature? Do you accept an RPM based on a valid MD5 checksum? Have you ever installed an expired or invalid security certificate for a "known-good" web site?
Embedded devices must handle the mechanics of security without human intervention because, as more and more devices sprout network connections, fewer and fewer humans can oversee their action. Even if you wanted to keep track of every electrical outlet and switch in your house, every can in your pantry, and every article of clothing in your closet, how often would you be willing to run a security audit or even check the logs?
Not very often, if our experience with home computers is any indication.
Getting security right for a single, PC-oid network node may be a doable, albeit difficult, project, but creating a solution that scales with the massive deployment of minuscule gadgets is a whole 'nother can of worms. Kevin Ashton's keynote speech on securing the "Internet of Things" showed projected annual shipments of 500×109 RFID tags in the U.S. by 2010. That means RFID tags will chew through nearly 40 bits of address space annually.
He pointed out that Wal-Mart currently sells 60×109 items per year. If each item carries a tag with a unique address, which is the way RFID tags work, then another factor of 10 for the whole industry over half a decade isn't much of a stretch. The fact that tags are currently too expensive by two or three orders of magnitude remains a problem, even if it's just a Simple Matter of Engineering.
Current RFID tags have essentially no built-in intelligence, as they simply transmit their fixed serial numbers in response to an interrogation. There's a strong desire for tags with writable information, tags with analog sensor inputs, and tags that can support mesh networking. The real problem is power consumption, which rises with each additional function in a device with no room or budget for a battery.
He also pointed out a problem that may not have a good technical solution. Suppose everything has a unique ID tag, whether networked or not. Now, what happens when a can of soda, last tracked to your hand, is found at a crime scene? How will your testimony stack up against automatic records that, presumably, can't be faked?
Several talks involved Atmel's AT97SC3201 Trusted Platform Module (TPM), an implementation of the Trusted Computing Group's spec for an on-board secure device, and how to build trusted embedded applications. The TPM is a single-chip microcontroller with crypto accelerator hardware, comprehensive physical tamper-proofing, well-verified firmware, and a straightforward system interface. It handles all the hocus-pocus required for public-key crypto, SHA hashing, digital signing, and so forth and so on.
Systems without a TPM must store their crypto code and keys on a hard drive, Flash-ROM drive, or a similar device, making them vulnerable to snooping and alteration. While you might not make the naïve mistake of putting your private key in a file called, oh, MyPrivate.Key, that's not the only security risk.
One slide in Steve Kinney's talk demonstrated how crypto keys stand out from the usual clutter. Figure 1 is my version of his slide, displaying the first 128×128 bytes of several files on my system as grayscale images. Pure random data is conspicuous because it has very high entropy: Uncorrelated values and no large-scale patterns. Although compressed files, such as JPG and MP3 data, also have high entropy, they also tend to have obvious headers and structures.
Although the TPM contains all your private keys, your system must authenticate itself before the TPM will begin operation. This requires, naturally enough, Yet Another Key stored outside the TPM, which means that an attacker with physical access to the hardware can compromise the system.
The attacker can monitor the data passing between the system and the TPM, locate the external key, help themselves to the data, and break the security. What the TPM can do is encapsulate the crypto machinery and prevent a wide variety of software attacks on your code and data, so it's very good at what it does.
Bill Gatliff moderated a Shop Talk session, much too early on Tuesday morning, on "Experiences in Secure Hardware Design." He was contracted to cook up embedded Linux for a hardware gadget to be sold in a country with, shall we say, a relaxed attitude toward Intellectual Property ownership. The desired result was a combined hardware/software system that couldn't be duplicated, even after the new owners pried it apart for study.
The bottom line turns out to be that you can't protect your IP in such a situation. The "attackers" are at least as smart as you are, they have access to at least the same level of tools, they have far more time on their hands, and they have all the incentive you can imagine.
Participants in several sessions described various means of tamper-proofing, tamper-resisting, or at least making tampering more obvious. The usual panel switches are completely passé: Expect a pressure sensor in a vacuum-sealed box, an optical sensor watching a particular reflection from a hologram grating glued to the lid, or minuscule wires epoxy-bonded across assembly seams. The folks who build gambling machines have some hairy war stories, too.
Regardless of those precautions, an attacker can simply buy (or steal) enough units to figure out how you've done the security, then defeat it with ease. In this Internet Age, one break is all it takes. Remember, they're at least as smart as you are.
Verily: To own is to be root.
Perhaps the single distinguishing feature of embedded programming, in contrast to ordinary applications, is its intimate relation with the real world. Embedded systems typically react to physical stimuli and produce mechanical outputs, rather than rely on I/O filtered through layers of abstraction. Timing is, of course, everything in that realm.
Vince Socci, from On Target Technology (http://www.ontargettechnology.com/), discussed "Actuator Control Design for Safety-Critical Applications" in the worst-possible time slot—Thursday afternoon. Surprisingly, his talk was well-attended and downright fascinating, at least if you like this sort of stuff.
He pointed out the myriad ways that components can fail and how difficult it can be to ensure that those failures do not cause an overall system failure. Simply adding more parts does not necessarily improve the system's reliability, particularly if reliability isn't at the top of the requirements checklist.
A system can't be just a little bit redundant: Either you ensure that no single failure can bring it down or you don't. You must take probabilities into account, as not everything can be redundant, but you must also work with Murphy's Law in mind.
He gave a particularly interesting example of a transmission for a (very) high-end automobile that incorporated two clutches to avoid losing power during a shift (I hate it when that happens. Don't you?). A design review showed that a hydraulic valve failure could activate both clutches and destroy the transmission. Some mechanical redesign averted that, but then they realized how a microcontroller failure could have the same effect. Solution? Duplicate the microcontrollers and add failure-checking circuitry.
Triple-redundant systems go one step further, but three may not suffice for airplane control surfaces. A quad-redundant control system has four parallel control channels, from input sensors to output mechanics, arranged so that it will continue to operate normally even with one channel actively opposing the other three. If two channels fail, the system enters a fail-passive mode that can use an alternate control path. If three of the four channels fail, the control system enters a fail-safe mode that will, at least, not actively try to kill you.
Even though automotive drive-by-wire systems demand the same reliability as aerospace systems, they have diametrically opposed constraints on cost, development time, and product volume. An automobile's environment can be more hostile than a combat aircraft (that is, apart from weapons fire), so you don't get any relief there, either.
The design process for a safety-critical system begins with a simple premise: If a critical part fails, your customer dies. He points out that various industries have evolved many different ways to focus adequate attention on the design process, so that adopting a particular design methodology and conforming to a given standard may well be mandatory.
Software poses a particular problem for safety-critical products because software failure modes tend to make hash of traditional failure models. A mechanical actuator has a limited number of failure modes: stuck-on, stuck-off, frozen-in-place, and so forth. A single software failure, on the other hand, can produce bizarre results. Consider that an early version of the F-16 flight-control software would have rolled the plane 180 degrees when it crossed the equator, had that error not been caught in simulation.
In short, if you're entering the safety-critical arena, expect that your schedule and costs will increase by perhaps a factor of five. That's what it takes to produce dependable systems, which should be a wake-up call in the face of schedule and cost pressure.
There was some talk of Smart Dust, which involves computing power in pepper-flake packages, and how it can be a Force for Good. Alas, there's no room for Security As We Know It in those gizmos, so there's lots of room for hackers. Spoofing SpeedPass chips and hacking RFID tags will be just the beginning.
Information on the semiannual Embedded Systems Conferences is at http://www .esconline.com/. The Microsoft Windows Embedded Essentials Seminar, scheduled for all day Tuesday in Ballroom A, was abruptly canceled. I haven't been able to find out what happened.
The Trusted Computing Group is at https://www.trustedcomputinggroup.org/ home/ (note the https protocol). More on Atmel's Trusted Platform Module is at http://www.atmel.com/products/Embedded/, although the good stuff is under an NDA that I haven't signed.
Promise you won't laugh at the ActiveX security provisions described at http://www.microsoft.com/office/ork/2003/ seven/ch23/SecA05.htm. The Windows XP Security Center can also be spoofed quite easily, as mentioned at http://www.pcmag .com/article2/0,1759,1639276,00.asp.
I used convert -size 128x128 gray:infile outfile.png to produce Figure 1. Linux systems spout random numbers from /dev/random or, if you don't mind slight correlations, /dev/urandom.
Cory Doctorow's presentation on why Digital Rights Management can't possibly work, given to Microsoft Research earlier this year, is at http://craphound.com/ msftdrm.txt.
An RFID blog with useful links is at http://www.rfid-weblog.com/.
An encrypted disk program and a good overview of encrypted filesystems in general is at http://phk.freebsd.dk/pubs/ bsdcon-03.gbde.paper.pdf.
DDJ