Security in automotive electronics: press here to steal

Wayne Chavez, global manager for automotive controllers at Freescale Semiconductor, related this week a story about the growing issue of security in automotive microcontrollers. Seems there is—or at least was until recently—at least one car model from Daimler-Chrysler that could be purloined in the following fashion. First, knock off a remote-controlled side mirror, exposing the CAN bus that runs through the car’s chassis control system. Second, attach your own microcontroller board to the CAN bus and use it to gain control of the car’s theft-prevention system. Third, drive away, trying not to laugh too loudly.

Everyone associates automotive electronics with extreme demands for reliability. But as automotive microcontrollers and SoCs assume more and more of the mission-critical responsibilities for the automobile—keeping it running, keeping it intact, keeping it in the family—the need for security and authentication in those processors has grown rapidly and, for the most part, unremarked. Chavez says the demands are not yet as high as in, say, secure Smart Cards for banking, but they are headed that direction.

There are two separate issues involved, Chavez continues. First, there is the problem of intentional intrusion. In tomorrow’s highly computerized vehicles, a thief, vandal, or assassin could achieve his purposes with elegant ease if he could gain control of a just a single key piece of code in the right microcontroller core. This makes authentication of access to the processors and protection against unauthorized intrusion increasingly important.

The problem emerged earliest in engine control software, where it has been fashionable in some circles to recode engine controllers for more power and torque at the expense of fuel efficiency, emissions and, quite probably, engine life. To prevent this, some manufacturers are now protecting program store with access keys. Not far behind will be intrusion monitoring, memory encryption and all the other techniques familiar to developers of Smart Cards and digital rights management systems.

The second issue is unintentional intrusion. There are so many processors, often coded by different vendors, operating in the same networks now that designers have to protect their systems against inadvertent corruption by another processor somewhere else in the network. This concern, Chavez says, is causing embedded designers to embrace one of their oldest enemies, the memory management unit. By providing hardware memory protection, an MMU can intercept most accesses to protected memory by unauthorized tasks, keeping an error in one program from crashing other unrelated systems.

In the past, embedded designers have sometimes used MMUs during prototype debug, but generally stripped them out or disabled them once the system was verified. Now, the MMU is gaining favor as a run-time protection against the unintended. It’s getting to be a cruel world out there for defenseless little MCUs, and designers are taking steps to bring them home safe.