Monday, December 13, 2010


Security of auto ignition systems

New Scientist tells us that the encryption between electronic key fobs and car ignition systems has been cracked in many cases. The reason is that most car manufacturers are using weak and/or home-grown encryption:

A device fitted within the key fob of a modern car broadcasts an encrypted radio signal to the car as the driver starts the vehicle. If the signal is recognised by the car’s receiver, it responds by sending an encrypted signal to the engine control unit (ECU), which allows the car to start. If the driver tries using the incorrect car key fob, the ECU locks down the engine.

For over a decade, immobilisers have played a crucial role in reducing car theft, says Nohl. But the proprietary encryption keys used to transmit data between the key fob, receiver and engine are so poorly implemented on some cars that they are readily cracked, Nohl told the Embedded Security in Cars conference, in Bremen, Germany, last month.

Last year he took just 6 hours to uncover the algorithm used to create the encryption key in a widely used immobiliser — the Hitag 2 made by Dutch firm NXP Semiconductors — making it easy to de-immobilise any car using that algorithm. And in 2005 Ari Juels of RSA Labs in Cambridge, Massachusetts, and researchers at Johns Hopkins University in Baltimore, Maryland, took under an hour to crack an encryption system sold by US technology firm Texas Instruments.

Juels says that these cracks were possible because the proprietary algorithms that the firms use to encode the cryptographic keys shared between the immobiliser and receiver, and receiver and engine do not match the security offered by openly published versions such as the Advanced Encryption Standard (AES) adopted by the US government to encrypt classified information. Furthermore, in both cases the encryption key was way too short, says Nohl. Most cars still use either a 40 or 48-bit key, but the 128-bit AES — which would take too long to crack for car thieves to bother trying — is now considered by security professionals to be a minimum standard. It is used by only a handful of car-makers.

This dovetails with the advice that computer security experts usually give:

  1. Use only modern, well known cryptographic algorithms, which have been thoroughly tested for their security properties.
  2. Use them with modern parameters, including currently accepted key lengths.
  3. Use only mature, well tested implementations. Resist the temptation to write your own.

On point 1, security is not enhanced by using a secret algorithm. Quite the opposite: open, well known algorithms have been scrutinized by the top experts in the field, and are, to the best of our knowledge, secure and impractical to break. That fabulous and super-secret algorithm you came up with may pass your security testing, but it’s almost always the case that once algorithms like that get into use, we find weaknesses in them and they fall fairly quickly.

It’s arrogant to claim that you can devise a better algorithm than the collective great minds of the world can. And if you can, yours should stand up to the public scrutiny needed for an assurance that the algorithm is really better. If secrecy is a necessary part of the algorithm, be assured that it will fail.

Point 2 should be obvious: computing capabilities speed ahead, and for most modern encryption algorithms, the key length directly relates to the time required to break the encryption. If we don’t increase key lengths over time, faster, more powerful processors will crack our systems.

On point 3, we have to remember that encryption algorithms are complex and particular. Bugs in the implementation can result in huge holes in the security... and bugs are inevitable in any implementation. Using a mature implementation, one that’s already been thoroughly debugged, gives the best chance of avoiding such holes. Coding an implementation yourself is a sure way to a weak crypto suite.

It seems counter-intuitive, but with modern encryption, the more public the algorithms and the implementations are, the better the security picture looks.

No comments: