copyright notice
link to the published version: IEEE Computer, January, 2019

accesses since January 21, 2019


Hal Berghel

Just as the shifts changed at Jaguars, a noted Las Vegas ‘gentleman's club' one afternoon in May, 2003, FBI agents burst into the manager's office guns in hand. So, according to the LA Times [JOHNSON], began Operation G-Sting, the federal sting that convicted four Clark County Nevada County Commission and two San Diego, CA city councilmen on bribery charges.

Flash Forward to March, 2010. Disgruntled former employee of the Texas Auto Center in Austin, TX remotely triggers the installed aftermarket GPS devices to set off car alarms, flash the headlights and shut off the engine starting system of one hundred of TAC's customer's personal vehicles leaving them stranded with disabled or unusable automobiles [POULSEN].

What does the conviction of four county commissioners from Las Vegas have to do with the Texas Auto Center hack? The answer is vehicle telematics, one of the emerging digital threat vectors in use by hackers, criminals, terrorists, governments, and invasive businesses.


The Texas Auto Center ( ) is apparently one of those car dealers of last resort for those who are credit-challenged. These car centers have been a staple in poor communities for many years, specializing in high interest and NINJA loans. The trick to making such loans profitable is the ability to recover the car if the payments are in arrears. In years past, this was the purview of the Repo man. Now, we throw new-wave repo-technology at the problem in the form of a digital, remotely-operated “real world asset protection” system like Payteck ( ).

TAC used the Payteck GPS and starter-interrupt systems for asset management (i.e. theft reduction) – apparently a winning combo for finance companies that specialize in NINJA car loans. Unlike the GPS trackers formerly used, the Paytech enables finance companies and used car companies to both locate and disable the car if the payments became delinquent. Sounds fine in practice. But what if a disgruntled former employee of TAC used a co-worker's login credentials to go rogue on the unsuspecting used car buyers. That's exactly what happened when a former employee disabled one hundred recently sold vehicles as an act of revenge against the former employer. This reads like a bad NSA surveillance expose, and as with the latter one has to ask, “Where were the checks and balances?” Apparently, the Paytek and auto center folks assumed that theft or unauthorized elevation of authentication privilege could never happen to them and that it would be impossible for an employee or hacker to behave improperly! This is an example of what I've called Faith-Based Security (FBS) [BERG1] – a cousin of Security Through Obscurity (STO). If such strategies are effective, it's by accident rather than design.

Even if you are financially well-heeled, your cars aren't immune to FBS and STO security measures. Don't get lulled into complacency because you avoid NINJA financing. One may accomplish the same objective with any car through the internal computer system – even by hacking the audio system [MCMILLAN]. I'll return to this theme.

Operation G-Sting was a hack of a different color. This time, it was the Feds who took advantage of the vehicle telematics system. The convicted bagman – the head of the Clark County Commission who was a former cop – decided that in order to avoid government eavesdropping, he'd conduct all sensitive discussions regarding the bribing of elected officials in his car that just happened to have OnStar enabled. Much to his chagrin, the pre-installed General Motors' OnStar folks were all too willing to activate the microphone for the FBI, thereby allowing the latter to listen in on conversations in the vehicle (all without benefit of warrant). These recorded conversations provided the key evidence for the convictions. In one of life's little ironies, after the county commissioners had been released from prison the 9 th Circuit Court (that includes both California and Nevada) ruled that such OnStar spying was illegal because it required tampering or disabling the OnStar vehicle recovery mode which violates the customer's terms of service [MCCULLAGH]. That is, the 9 th circuit court has ruled that OnStar wiretapping and surveillance was an egregious violation of a corporate term of service under current law ( , and not that it in any way violated the customer/citizen's expectation of privacy!

In a bizarre twist, the 2011 OnStar revised terms of service, extended OnStar's promised focus on continuous vehicle recovery mode and specifically allowed OnStar to collect driving and location data from car owners even if they had they had their OnStar subscriptions cancelled. This produced a PR nightmare for OnStar who temporarily at least stopped this practice [HILL] a t the behest of former Senator Al Franken (D, MN) and Chris Coons (D, DE). OnStar has since resumed the practice of collecting any information, for any purpose at any time. (cf. )

These prosecutions were ‘interesting' from several perspectives. One of the two San Diego City Councilmen was 2010 . The convicted former politicians who made up the Las Vegas contingent of bribe recipients have set apparently aside their political aspirations for the moment and directed their attention to less visible vocations in public relations, marketing and the law [MORRISON]


Vehicular telematics is but one of the later instantiations of Orwellian digital dystopia, but with its own distinctive twists including the increased exposure to malicious hacking and the potential for abuse of individual privacy,

As with other innovative technologies, modern vehicular telematics is a mixed blessing. There is no doubt that some telematics associated with convenience, safety, mechanical reliability, and entertainment are welcomed by many consumers and to varying degrees. On my latest vehicle, I most appreciate features like forward collision alert, 360-degree surround vision, distance indication, front pedestrian braking, cross traffic alerts, active cruise control, lane keeping assist, parking sensors, blind spot monitoring, navigation systems with traffic alert, adaptive lighting, and a host of other warnings and driver assistance features. I'm confident that the roads would be safer if such features would be available on all modern vehicles, and am pleased to see that some car manufacturers like Subaru and Toyota include most of these features in their base models.

No matter how useful, those telematics features are the least interesting from the point of view of security and privacy. The more intriguing features are those that entail security and privacy vulnerabilities. We begin with a convenience feature that largely goes unnoticed these days: the vehicle remote, also called the wireless fob, that is used in lieu of a key to control access to a vehicle or remotely initiate some action on the vehicle (e.g., remote start). Originally designed about 40 years ago for remote keyless entry, fobs are functionally similar to more feature-rich mobile devices.

Originally designed as a substitute form of keyless entry for the keypad on the driver's door, the fob is a short-range radio frequency transceiver. In my case, the fob passively exchanges proximity information with the car so that when it is within a few meters of the car, a logo is projected on the ground to detect motion and open the rear hatch, turns on various lights, and activates the opening buttons on the door handles. In addition, push buttons on the fob enable it to communicate instructions to the car to remotely start the engine, lock or unlock the doors, open the rear deck hatch, and set off the car alarm. Many of these features are further configurable. So the modern fob has taken on the character of modern remote controllers associated with multimedia devices.

So what's the problem? To begin with, RF appliances are never optimal for security-sensitive applications: radio frequencies neither respect individual privacy nor obey property lines. So the communications between car and fob should be understood to be broadcasts throughout the immediate neighborhood. This makes them susceptible to a gamut of hacks, ranging from denial-of-service (e.g., to deny access vehicles) to replay attacks to name but a few. And this is nothing new. Computer scientist Avi Rubin has been lecturing about such vehicle insecurities for many years [RUBIN]. The Center for Automotive Embedded Systems Security at the University of Washington and the University of California San Diego ( have been conducting research on vehicle telematics vulnerabilities for even longer. One of their classic papers in 2010 {KOSCHER] references articles on vehicle vulnerabilities as far back as the early 2000s. In a subsequent paper, [CHECKOWAY], these same researchers evaluate a cornucopia of attack vectors that affect modern automobiles. One of this center's projects, Car Shark, provides working demonstrations of these vulnerabilities. They have since extended their work to include using vehicle telematics for driver profiling and fingerprinting. The irony that this research has been so extensively covered over the past ten years that it has been featured in Popular Science [BOYLE] should not be overlooked.

Confirmation of these problems isn't hard to obtain. Samy Kamkar ( ) recently developed a suite of such attacks. [GREENBERG] and reported same in a 2015 DEFCON talk [OWNSTAR]. His tool, OwnStar runs a replay attack against OnStar fobs by inserting itself between a GM vehicle's transeiver and either OnStar apps on mobile devices or the fobs themselves. His video explains all of this in detail.

While OwnStar targets older RF-based keyless entry systems, modern vehicles use rolling code systems that prevent OwnStar replay attacks. Rolling codes use algorithms to generate code sequences based on pseudorandom random number. As long as the vehicle transceiver and the fob/mobile app transceiver use the same seeds and rolling code algorithm, the sequences can be validated even if the codes are non-consecutive. This means that while continuously changing, rolling code generators suffer from the serious defect of predictability: once the algorithm is known an endless sequence may be generated, each one of which can be determined to be legitimate. Based on this observation, Kamkar developed RollJam [ROLLJAM] which offers a replay attack for modern RF-based keyless entry systems that use rolling codes. This reaffirms our observation that RF is really not well suited when security is important (read: if you want to keep your car, boat, airplane, from being stolen; garages from being opened by home invaders; proximity card lock compromises, etc.).

A question naturally arises: why do car companies use digital technologies that are so easily compromised? In this case, challenge-response authentication based on a reasonable key derivation function would go a long way toward avoiding replay attacks. Such technology has been well understood and successfully deployed for decades, so why aren't they used for keyless access systems? The answer is that the manufacturer's cost benefit analysis suggests that their legal exposure from the resulting safety deficiencies and security vulnerabilities from non-use will not cost them much. In the absence of regulations with teeth or large-scale public blowback, there is little incentive to protect the customer. Since the beginning of the industrial revolution, the absence of risk has always been a strong disincentive to serious process improvement where product safety is at issue. By the way, these same vulnerabilities may apply to other remote access systems including remote garage door openers, proximity card access systems, etc.

But keyless access is not the greatest security and privacy vulnerability. Far greater is the new cell phone synchronization environment. A decade or so ago Bluetooth synchronization between a cell phone and the vehicle's communication systems was focused on the hands-free use of the cell phone. The voice recognition system in the vehicle sent the appropriate codes to the phone (for dialing, searching contact lists, etc.), but otherwise played a passive, facilitative role in the communication. On modern GM systems that I'm familiar with, and presumably other systems as well, the Bluetooth synchronization actually uploads data from the cell phone and stores it in the vehicles computer database – without the user's permission and possibly without the user's knowledge. This compounds the privacy problem of a lost cell phone. Even if cell phone data is encrypted, and the phone is locked, it is not that difficult to retrieve pins, passwords and encrypted data in plain text. Companies such as Cellebrite ( have offered mobile forensics devices that serve this purpose for decades. But the lowest hanging fruit in this attack vector is the automobile. The only data access protection that my car offers is a 4-number pin valet lock. This bad idea is both polished and refined: it offers limited data protection against a determined adversary while at the same time making vehicular telematics inconvenient for the owner. Such bad ideas don't just happen naturally – they require serious effort from incompetent designers. This isn't innovation, it's enervation.

A similar situation applies to the access of data through the on board diagnostics (OBD) ports under the dash. While it seems reasonable to make diagnostic data available to manage engine performance, optimize safety systems, etc. when OBD ports became the preferred option for smog tests a decade or so ago, that opened an entirely new vulnerability to the car owner. While automobile manufacturers could have restricted the OBD information sharing to just those datum of use to the smog inspectors, instead they opened the OBD ports to a much wider variety of data – including historical accelerometer data, speed data, GPS data, trip timings and usage data, Originally, these “black box” OBD devices were used by insurance companies (e.g., Progressive's Snapshot program) to earn premium rate discounts – drivers were even given discounts to have them installed in their vehicles. As any good personal injury attorney will attest, one of the first questions they ask of accident investigators is where the “other” vehicle had one installed so that it may be subpoenaed as evidence in court. Sans black box, an attempt will be made to recover the vehicle data directly from the automobile. This data can be used by an insurance company to confirm good driving behavior but it can also be used by personal injury attorneys and prosecutors to justify liability claims for allegedly bad driving behavior. Somehow this equivalence just never seemed to register with the public. Incidentally, OBD black box devices are now popular general aftermarket automobile appliances for GPS tracking, monitoring driving behavior, etc. ( ).


I don't mean to impart any special blame to General Motors or OnStar for breaches in personal security and privacy. All car manufacturers offer similar services. Ford SYNC which was based on Microsoft Auto OS offers the same range of services as GM/OnStar. The same may be said for LexusLink, BMW Assist, Mercedes Mbrace, and so forth. As near as I can tell, all manufacturers approached telematics exclusively from a marketing point of view with little or no consideration for consumer privacy protection. This is not to deny potential advantage to collision detection and reporting capabilities. Nor is it to criticize the use of motor vehicle event data recorders (MVEDR) per se. However, for detection and reporting accidents, MVEDRs don't require more than a few minutes of pre-crash recorded data collection to serve the passenger's public safety interests. So even if we assume that vehicle speed, engine RPM, service brake status, lateral acceleration, roll angles, antilock braking system status, seatbelt status, steering wheel position, and airbag-related data would be useful to first responders, a simple FIFO data collection strategy that would only retain the most recent data would serve perfectly well. In other words, the claim that event data recorder information has to be retained for longer periods, or shared with the manufacturer via telephone or satellite links, doesn't pass my smell test. That was essentially the issue that Senators Franken and Coons raised with OnStar.

At the heart of the privacy vulnerability is the manufacturer's insistence on a simple, integrated vehicle data retention policy that will serve all demands: crash reporting, smog inspection, manufacturer's revenue potential from the sale of telematics options, manufacturer and 3 rd party marketing and advertising revenue, etc. It is this over-simplistic integration that is genesis of the problem. Of course, the rationale is obvious: automobile manufacturers have discovered that using and selling access to this data can be enormously profitable [HOWARD]. Car companies and dealers are finding that the sale of customer data is another lucrative source of profit along with the interests and fees associated with car loans. However, unlike the case of car loans, the customer has no right of refusal regarding the sale of his/her personal data.

It is quite telling that automobile manufacturers have not packaged these data collection technologies in the form of optional modules that the customer may or may not purchase, and that may be removed if the service is no longer desired. The manufacturers do not want to give the customer that choice because (a) many would choose not to purchase these options, and (b) the manufacturer would lose the opportunity to re-purpose the data for profit. In the case of my new car, the OnStar equipment is built into the car. Any attempt to disable or remove it not only disables other non-privacy invasive systems like navigation, the entertainment system, and Bluetooth connectivity, but it also voids the manufacturer's warranty. And there's no way to avoid Internet connectivity on modern premium cars. [SCHNEIER] My car will attempt to authenticate with all insecure proximate WiFi networks whenever the car is started. If there's a way to disable this feature, I haven't found it. One need only read up on Operation G-Sting to confirm the dangers of all of this insecurity. The FBI aren't the only ones listening!

With the proliferation of unwanted and unneeded passive interfaces like Bluetooth, Internet and WiFi connectivity, the ability to invasively record passenger compartment audio and video, the integration of myriad sensors, cameras, and microphones, and the mega-integration of all of these components into an insecure multimedia and networked infrastructure, the potential for privacy abuse in modern automobiles is enormous. Add to that the profit motive for the manufactures to use or sell this data, and we have a new frontier for privacy abuse, fraud, and theft. The question isn't whether these new automobile systems will be exploited to our cost, but when and to what degree.

This is not to deny that there are other manufacturers capturing this data. Mobile device manufactures do the same thing. Literally hundreds of smartphone apps are known to share such data as real time GPS location with 3 rd party vendors [DEVRIES ]. It is not easy (and may not be possible) to shut such features off as the manufacture/provider ultimately have the control over enabling/disabling services. However, at least in the case of mobile devices, you have the ability to shut the device off. That's not an option with modern automobiles.

There are also more mundane privacy exposures such “large scale and covert collection of personal data” through Microsoft Offices' ProPlus subscriptions [CIMPANU] which shares motivations with vehicle telematics and mobile apps, but under the office productivity suite rubric. I'll expand on this in a future column.



[JOHNSON] Johnson, John, The Talk of Las Vegas is Operation G-Sting, Los Angeles Times, December 21, 2003. ( )

[POULSEN] Poulsen, Kevin, Hacker Disables More Than 100 Cars Remotely, Wired, 03.17.10, ( ).

[BERG1] Berghel, Hal, Faith-Based Security, Comm. ACM, 51:4, April, 2008, pp. 13-17.

[MCMILLAN] McMillan, Robert, With hacking, music can take control of your car, IT World, March 14, 2011. ( )

[MCCULLAGH] McCullagh, Declan, Court to FBI: NO spying on in-car computers, c|net, Nobember 19, 2003, ( )

[HILL] Hill, Kashmir, OnStar Kills Its Terrible Plan to Monitor Non-Customers' Driving, Forbes, September 27, 2011 ( )

[MORRISON] Morrison, Jane Ann, Politicians come and go after serving corruption sentences, The Las Vegas Review-Journal, March 21, 2010 ( )

[RUBIN] Ribom. All your devices can be hacked, TED talk (2011). ( )

[KOSCHER] Koscher, Karl, et al, Experimental Security Analysis of a Modern Automobile, 2010 IEEE Symposium on Security and Privacy, pp. 1-16. ( )

[CHECKOWAY] Checkoway, Stephen, et al, Comprehensive Experimental Analyses of Automotive Attack Surfaces, USENIX Security Symposium, August 10-12, 2011. ( )

[BOYLE] Boyle, Rebecca, Proof-of-Concept CarShark Software Hacks Car Computers, Shutting Down Brakes, Engines, and More, Popular Science, May 14, 2010. ( )

[GREENBERG] Greenberg, Andy, The Greatest Hits of Samy Kamkar, Youtube's Favorite Hacker, Wired, 12/17/15. ( )

[OWNSTAR] Kamkar, Samy, Drive it Like You Hacked It: New Attacks and Tools to irelessly Steal Cars, DEFCON 23 (2015). ( ).

[ROLLJAM] Greenberg, Andy, This Hacker's Tiny Device Unlocks Cars and Opens Garages, Wired, 8/16/15. ( )

[HOWARD] Howard, Phoebe Wall, Data could be what Ford sells next as it looks for new revenue, Detroit Free Press, Nov. 13, 2018. ( ).

[SCHNEIER] Schneier, Bruce, Click Here to Kill Everybody: Security and Survival in a Hyper-connected World, W.W. Norton (2018).

[DEVRIES] DeVries, Jennifer, et al, Your apps Know Where You Were Last Night, and They're Not Keeping It Secret, The New York Times, Dec, 10, 2018. ( )

[CIMPANU] Cimpanu, Catalin, Dutch government report says Microsoft Office telementry collection breaks GDPR, ZeroDay/ZDNet, November 14, 2018 ( )