Embedded Systems Week: Security Workshop

I'm at Embedded Systems Week, the major research conference for embedded computing.  Today, I attended the Embedded Systems Security Workshop.  The speakers presented some very interesting results.  But let me concentrate on the keynote by Wayne Burleson of the University of Massachusetts, who spoke on privacy in embedded computing.

He made the very interesting point that trust and security are not the same thing; we don't understand as much about trust as we do about security.  We have identified quite a few threat models in traditional computer security.  The same cannot be said for privacy.  It isn't always clear from whom the threat comes from or what constitutes an invasion of privacy.  Some releases of personal information are  natural, intended, and necessary; some breaches are unnecessary but not particularly consequential; while others can have devastating consequences.  Unfortunately, if we don't understand the threat models, we can't do much to mitigate those threats.

He described two of his projects.  The first developed new techniques for electronic fare payment for transportation systems.  He and his colleagues developed a form of electronic cash that allows the user to pay for a fare and obtain special fares such as senior citizen fares without disclosing other information about themselves.

He then talked about his work on medical system privacy.  The medical community is busy developing all sorts of implanted medical devices that can transmit information about the state of your body to your doctor.  The trick is to be sure that only intended people have access to that information.  Medical devices operate under severe energy constraints, on the order of 10 joules per operation, so any security and privacy techniques employed in the device must be able to be performed at these very low energy levels.  Burleson also pointed out that the risk/benefit analysis in medical devices must be carefully performed.  For example, hacks on pacemakers were revealed a few years ago.  The manufacturers very quickly addressed the problems because of concerns that patients would decide not to have a pacemaker in order to avoid being hacked.  Of course, the risk of dying from lack of a pacemaker is much, much higher than is the risk of having your pacemaker hacked into, but there is no point in taking chances with such analysis.

Car Hacking

The common conception of security problems in cars is theft---someone breaks into your car electronically and drives away with it. The security challenges created by the computers that control your car go far beyond that scenario.  Modern cars are cyber-physical systems with dozens of computers that control safety-critical functions.  All sorts of security problems can cause cars to fail catastrophically---that is, crash.

One important category of vulnerabilities in cars is timing.  If someone messes up the timing of the firing of the spark plugs and fuel injectors in your engine, the engine stops working.  Timing problems in the braking system can cause you to lose control of steering.

How do timing problems occur?  Some of the scenarios are localized.  The engine control unit (ECU) is in charge of sending out all the signals to control the engine.  Problems in the ECU software can cause it to improperly time some of the signals to the engine.  The effects can range from running rough to total engine failure.

But the computers in your car are connected together on a network.  Just as the Internet created new types of security problems for home and business computers, car networks create new vulnerabilities for cars.  Units in the car communicate with each other over the network in real time to coordinate their activities.  Interfere with their ability to communicate and the car itself stops working properly.

The CAN bus has been used in cars for years.  Unfortunately, it is vulnerable to all sorts of timing problems.  For example, one component on the CAN bus can jam the network by sending out too many messages.  The simplicity of the CAN bus means that there is no global control that can monitor and react to these sorts of problems.

The Flexray bus has been designed to avoid many of these problems.  It's starting to appear in cars.  Flexray has some very sophisticated mechanisms.  Time will tell how well they solve old problems and if they create new challenges.

The Maker Revolution and the Embedded World

The Maker movement has reinvigorated my faith in humanity.  I had become increasingly worried that people---both kids and adults---had stopped making things. So many traditional hobbies---model airplanes, plastic models, ham radio---have shriveled.  Working on cars used to be an American passsion; John Steinbeck included an ode to the mechanic as a chapter in The Grapes of Wrath. Today, cars are designed so that amateur car maintenance is very difficult.

Today, we have turned the corner and see people building all sorts of new things in all sorts of ways.  A few key product innovations have helped enable this revolution. Lego Mindstorms certainly introduced a lot of kids to robotics.  3D printers, which were exotic and expensive just a few years ago, have been democratized to the point of becoming household items.

But I am a little surprised that we don't see more integration of the mechanical and computer sides of Makerdom. Sure, we see computers controlling things, but that control is very, very simple.  Concurrency is fundamental to embedded computing.  Computers allow our machines to do several things at once.  But most of the toys I see do one thing at a time, roughly speaking.  Robots perform one operation, then stop and do something else.

Concurrency is, of course, not easy to achieve.  But it is cool.  I hope that we can figure out ways to make concurrency simpler and usable by hobbyists.  That will require new programming models that make it easy to describe concurrency.  We've made some progress on that front for high-end system designers, but those high-level programming languages are too complex to use..  I suspect that a hobbyist-friendly concurrent embedded programming language would be useful not just for high school kids but ultimately to a wide range of professional system designers.

Toilet Hacking

The press recently caught onto the fact that real-world objects, not just computers, can be hacked.  This CNN story on the hacking demonstrations, such as hacking a fancy Japanese toilet, at Def Con and Black Hat is one example, but there are others.  Of course, your toilet can't be hacked if it doesn't have a computer in it.  I've used those fancy Japanese toilets and I find them a little scary, so I'm glad that I don't have one at home.  But this sort of hacking has been a hidden problem for a long time and I am glad that it is coming out into the open.


A lot of the recent stories have been about objects that I would call Internet of Things simply because they perform common functions but are also clearly connected to the Internet.  But a lot of things we don't think about in our daily lives are also connected to the Internet.  Many of us don't have a traditional phone line (what the Bell System used to call POTS, or Plain Old Telephone Service); we instead rely on telephones that are built on top of the Internet.  Quite a few industrial systems are now connected to the Internet.  These network connections provide useful functions but they also open up serious vulnerabilities. 
<p>So long as we understand the security implications of those systems and take care of them properly, things will continue to run along smoothly.  But with great power comes great responsibility, and as the Internet of Things grows we need to be sure to manage it responsibly.  If we don't, all those devices could start to bite us on the fanny.