Telematics and security: Protecting the connected car

Krystyna

---

12th January 2011

At last week’s Consumer Electronics Show, Audi chairman Rupert Stadler announced “There is a revolution taking place. Some of the most exciting new consumer electronics aren’t the ones in your living rooms or in your offices. They’re the ones in your cars.”

As the connected car becomes a reality, the so-called ‘attack surface’—the areas of vulnerability that could be exploited by hackers and assorted other bad guys—is expanding.

While the marketplace of applications and services for connected cars is growing, experts say the market for new kinds of security measures remains underexploited.

Research firm Gartner estimates the security software market was worth more than $16.5 billion in 2010, an 11.3 percent increase from 2009.

But that sum could be much higher in the next couple of years, if every segment of the telematics industry gets up to speed on security.

And there is enough anecdotal evidence to suggest that upgraded security should be a priority.

Security as selling point

In March 2010, a worker laid off by Texas Auto Center used his password to access the dealership’s Web-based system to trigger the vehicle immobilization system on 100 cars.

The system was installed by Texas Auto Center to enable easier repossession if buyers failed to make payments.

Customers were unable to drive their cars for five days—until the dealership finally reset all employee usernames and passwords.

Security is a huge selling point in the enterprise software market, and analysts suggest the telematics industry could do a better job of it in the automotive market.

Earlier this year, researchers at the Center for Automotive Embedded Systems Security created a tool to inject malware into a vehicle’s controlled area network (CAN) bus.

Exploiting a longish list of weaknesses in the CAN protocol, the researchers were able to remotely lock the brakes, keep brakes from engaging, and attach firmware to the telematics unit.

They were surprised to find that, while access controls for the ECU unit were weak, in some cases, even these puny controls had not been implemented.

One caveat to this study is that the attacks could only be carried out in close proximity to the vehicle.

Could internet-connected cars be vulnerable to similar exploits?

“Many security concerns in the computer and embedded systems industries map to the automotive industry, and many threats are now growing there,” says Benjamin Jun, vice president of Cryptography Research, a developer and licensor of security technology.

Balancing usability and security

Much has been made of the security risks in the Chevy Volt’s 10 million lines of software code and 100 microprocessors.

“I wonder who tested the code to see if it’s secure, and I wonder how they’re implementing that,” muses Adriel Desautels, chief technology officer and president of NetraGard, a company that does vulnerability assessments and penetration testing on all kinds of systems.

There is nothing to suggest GM has not done a proper job of locking down the Volt’s systems, but Desautels observes that the auto industry in general has been lax about this.

Moreover, reports that each Volt will have its own IP address have made security experts wonder if cars may get hacked and infected as regularly as computers or even smartphones.

Doug Mutart, director of OnStar architecture and technology, says that’s not true; each Volt will be assigned a temporary, Simple IP address only when it initiates communications with OnStar.

Mutart points out that the OnStar service uses Verizon’s CDMA wireless network, and CDMA is an encrypted spread-spectrum signal that’s very difficult to intercept and decipher.

“By itself, CDMA tends to be one of the more secure wireless networks,” according to Mutart.

“On top of that, in our latest gen, gen 9, we also use digital certificates, very strong cryptographic ciphers that protect packet data.”

On the back end, OnStar is set up much like any ecommerce company, with encrypted communications and data storage, regular vulnerability testing, and stiff user authentification requirements.

“In the balance between usability and security, we err on the side of making it more safe and secure,” Mutart says.

Connected cars also could be vulnerable when they connect to third-party apps, Desautels says.

Look at Twitter-enabled cars, for example.

If they connect to Twitter.com, Desautels says, it’s fairly easy for a hacker to write a worm to infect the website.

“All the cars that pull info from Twitter.com will pull in the worm,” Desautels says.
While they may not lock the brakes, he thinks a hacker could write a worm that would immobilize or lock the car.

Jun of Cryptography Research points to digital content as another area ripe for rip-off, with an already thriving black market selling unlocking codes for maps in GPS devices.

Protecting the back office

There’s another area where OEMs have not gotten up to speed, according to Leo McCloskey, vice president of marketing for Airbiquity: the back office.

When connected cars begin to be traded in the second-hand market, the industry needs to develop mechanisms that will both note the transfer of ownership and make sure the previous owner’s data doesn’t get transferred along with the vehicle.

One thing that’s missing, according to McCloskey, is the ability to provide a unique identifier for a vehicle—whether the VIN, a SIM card in an embedded unit, or something else—and transfer it to the new owner.

“Equally important to onboard security, such as in the chip set, is the back office capability,” he says. “You have to have both.”

More and more, auto manufacturers, dealers, and service providers will have the same asset management issues seen in enterprises, which have to keep track of who has what equipment and who is authorized to access software, McCloskey says.

“Every auto manufacturer is heading down this path,” he adds.

Jun of Cryptography Research says the challenge for OEMs is to build systems with the appropriate degree of robustness against attacks that are known and known to be coming in the future.

“People need to make appropriate architectural choices,” Jun says, which may include hardware security, such as a chip in the infotainment head unit, and software security, which tends to be cheaper but easier to break.

The key is figuring out exactly where to invest in hardware resources and doing it with a minimal footprint.

“If you build something too large and unwieldy,” Jun says, “it creates burdens across the hardware lifecycle.”

Susan Kuchinskas is a regular contributor to TU.

For more on the connected car, see ‘Telematics and connectivity: Which comes first, the app or the money?’ and ‘Social networking and the connected car’.