Entries Tagged "cars"

Page 9 of 19

Memphis Airport Inadvertently Gets Security Right

A local newspaper recently tested airport security at Memphis Airport:

Our crew sat for 30 minutes in the passenger drop-off area Tuesday without a word from anyone, and that raised a number of eyebrows.

Certainly raised mine. Here’s my question: why is that a bad thing? If you’re worried about a car bomb, why do you think length of time sitting curbside correlates with likelihood of detonation? Were I a car bomber sitting in the front seat, I would detonate my bomb pretty damned quick.

Anyway, the airport was 100% correct in its reply:

The next day, the airport told FOX13 they take a customer-friendly “hassle free” approach.

I’m certainly in favor of that. Useless security theater that adds to the hassle of traveling without actually making us any safer doesn’t help anyone.

Unfortunately, the airport is now reviewing its procedures, because fear wins:

CEO Scott Brockman sent FOX13 a statement saying in part “We will continue to review our policies and procedures and implement any necessary changes in order to ensure the safety of the traveling public.”

EDITED TO ADD (4/12): The airport PR person commented below. “Jim Turner of the Cato Institute” is actually Jim Harper.

Posted on March 25, 2016 at 12:26 PMView Comments

Cory Doctorow on Software Security and the Internet of Things

Cory Doctorow has a good essay on software integrity and control problems and the Internet of Things. He’s writing about self-driving cars, but the issue is much more general. Basically, we’re going to want systems that prevent their owner from making certain changes to it. We know how to do this: digital rights management. We also know that this solution doesn’t work, and trying introduces all sorts of security vulnerabilities. So we have a problem.

This is an old problem. (Adam Shostack and I wrote a paper about it in 1999, about smart cards.) The Internet of Things is going to make it much worse. And it’s one we’re not anywhere near prepared to solve.

Posted on December 31, 2015 at 6:12 AMView Comments

Volkswagen and Cheating Software

Portuguese translation by Ricardo R Hashimoto

For the past six years, Volkswagen has been cheating on the emissions testing for its diesel cars. The cars’ computers were able to detect when they were being tested, and temporarily alter how their engines worked so they looked much cleaner than they actually were. When they weren’t being tested, they belched out 40 times the pollutants. Their CEO has resigned, and the company will face an expensive recall, enormous fines and worse.

Cheating on regulatory testing has a long history in corporate America. It happens regularly in automobile emissions control and elsewhere. What’s important in the VW case is that the cheating was preprogrammed into the algorithm that controlled cars’ emissions.

Computers allow people to cheat in ways that are new. Because the cheating is encapsulated in software, the malicious actions can happen at a far remove from the testing itself. Because the software is “smart” in ways that normal objects are not, the cheating can be subtler and harder to detect.

We’ve already had examples of smartphone manufacturers cheating on processor benchmark testing: detecting when they’re being tested and artificially increasing their performance. We’re going to see this in other industries.

The Internet of Things is coming. Many industries are moving to add computers to their devices, and that will bring with it new opportunities for manufacturers to cheat. Light bulbs could fool regulators into appearing more energy efficient than they are. Temperature sensors could fool buyers into believing that food has been stored at safer temperatures than it has been. Voting machines could appear to work perfectly—except during the first Tuesday of November, when they undetectably switch a few percent of votes from one party’s candidates to another’s.

My worry is that some corporate executives won’t interpret the VW story as a cautionary tale involving just punishments for a bad mistake but will see it instead as a demonstration that you can get away with something like that for six years.

And they’ll cheat smarter. For all of VW’s brazenness, its cheating was obvious once people knew to look for it. Far cleverer would be to make the cheating look like an accident. Overall software quality is so bad that products ship with thousands of programming mistakes.

Most of them don’t affect normal operations, which is why your software generally works just fine. Some of them do, which is why your software occasionally fails, and needs constant updates. By making cheating software appear to be a programming mistake, the cheating looks like an accident. And, unfortunately, this type of deniable cheating is easier than people think.

Computer-security experts believe that intelligence agencies have been doing this sort of thing for years, both with the consent of the software developers and surreptitiously.

This problem won’t be solved through computer security as we normally think of it. Conventional computer security is designed to prevent outside hackers from breaking into your computers and networks. The car analogue would be security software that prevented an owner from tweaking his own engine to run faster but in the process emit more pollutants. What we need to contend with is a very different threat: malfeasance programmed in at the design stage.

We already know how to protect ourselves against corporate misbehavior. Ronald Reagan once said “trust, but verify” when speaking about the Soviet Union cheating on nuclear treaties. We need to be able to verify the software that controls our lives.

Software verification has two parts: transparency and oversight. Transparency means making the source code available for analysis. The need for this is obvious; it’s much easier to hide cheating software if a manufacturer can hide the code.

But transparency doesn’t magically reduce cheating or improve software quality, as anyone who uses open-source software knows. It’s only the first step. The code must be analyzed. And because software is so complicated, that analysis can’t be limited to a once-every-few-years government test. We need private analysis as well.

It was researchers at private labs in the United States and Germany that eventually outed Volkswagen. So transparency can’t just mean making the code available to government regulators and their representatives; it needs to mean making the code available to everyone.

Both transparency and oversight are being threatened in the software world. Companies routinely fight making their code public and attempt to muzzle security researchers who find problems, citing the proprietary nature of the software. It’s a fair complaint, but the public interests of accuracy and safety need to trump business interests.

Proprietary software is increasingly being used in critical applications: voting machines, medical devices, breathalyzers, electric power distribution, systems that decide whether or not someone can board an airplane. We’re ceding more control of our lives to software and algorithms. Transparency is the only way verify that they’re not cheating us.

There’s no shortage of corporate executives willing to lie and cheat their way to profits. We saw another example of this last week: Stewart Parnell, the former CEO of the now-defunct Peanut Corporation of America, was sentenced to 28 years in prison for knowingly shipping out salmonella-tainted products. That may seem excessive, but nine people died and many more fell ill as a result of his cheating.

Software will only make malfeasance like this easier to commit and harder to prove. Fewer people need to know about the conspiracy. It can be done in advance, nowhere near the testing time or site. And, if the software remains undetected for long enough, it could easily be the case that no one in the company remembers that it’s there.

We need better verification of the software that controls our lives, and that means more—and more public—transparency.

This essay previously appeared on CNN.com.

EDITED TO ADD: Three more essays.

EDITED TO ADD (10/8): A history of emissions-control cheating devices.

Posted on September 30, 2015 at 9:13 AMView Comments

Remotely Hacking a Car While It's Driving

This is a big deal. Hackers can remotely hack the Uconnect system in cars just by knowing the car’s IP address. They can disable the brakes, turn on the AC, blast music, and disable the transmission:

The attack tools Miller and Valasek developed can remotely trigger more than the dashboard and transmission tricks they used against me on the highway. They demonstrated as much on the same day as my traumatic experience on I-64; After narrowly averting death by semi-trailer, I managed to roll the lame Jeep down an exit ramp, re-engaged the transmission by turning the ignition off and on, and found an empty lot where I could safely continue the experiment.

Miller and Valasek’s full arsenal includes functions that at lower speeds fully kill the engine, abruptly engage the brakes, or disable them altogether. The most disturbing maneuver came when they cut the Jeep’s brakes, leaving me frantically pumping the pedal as the 2-ton SUV slid uncontrollably into a ditch. The researchers say they’re working on perfecting their steering control—for now they can only hijack the wheel when the Jeep is in reverse. Their hack enables surveillance too: They can track a targeted Jeep’s GPS coordinates, measure its speed, and even drop pins on a map to trace its route.

In related news, there’s a Senate bill to improve car security standards. Honestly, I’m not sure our security technology is enough to prevent this sort of thing if the car’s controls are attached to the Internet.

EDITED TO ADD (8/14): More articles.

Posted on July 23, 2015 at 6:17 AMView Comments

Ford Proud that "Mustang" Is a Common Password

This is what happens when a PR person gets hold of information he really doesn’t understand.

“Mustang” is the 16th most common password on the Internet according to a recent study by SplashData, besting both “superman” in 21st place and “batman” in 24th

Mustang is the only car to appear in the top 25 most common Internet passwords

That’s not bad. If you’re a PR person, that’s good.

Here are a few suggestions for strengthening your “mustang” password:

  • Add numbers to your password (favorite Mustang model year, year you bought your Mustang or year you sold the car)
  • Incorporate Mustang option codes, paint codes, engine codes or digits from your VIN
  • Create acronyms for modifications made to your Mustang (FRSC, for Ford Racing SuperCharger, for example)
  • Include your favorite driving road or road trip destination

Keep in mind that using the same password on all websites is not recommended; a password manager can help keep multiple Mustang-related passwords organized and easy-to-access.

At least they didn’t sue users for copyright infringement.

Posted on February 16, 2015 at 6:45 AMView Comments

Common Risks in America: Cars and Guns

I have long said that driving a car is the most dangerous thing regularly do in our lives. Turns out deaths due to automobiles are declining, while deaths due to firearms are on the rise:

Guns and cars have long been among the leading causes of non-medical deaths in the U.S. By 2015, firearm fatalities will probably exceed traffic fatalities for the first time, based on data compiled by Bloomberg.

While motor-vehicle deaths dropped 22 percent from 2005 to 2010, gun fatalities are rising again after a low point in 2000, according to the Atlanta-based Centers for Disease Control and Prevention. Shooting deaths in 2015 will probably rise to almost 33,000, and those related to autos will decline to about 32,000, based on the 10-year average trend.

There’s also this story.

Posted on January 16, 2015 at 6:19 AMView Comments

1 7 8 9 10 11 19

Sidebar photo of Bruce Schneier by Joe MacInnis.