Internet of Things Security at Enigma 2016

Nicolas Papernot
Jan 27, 2016 · 5 min read

Enigma is a security conference launched this year by the USENIX association. Here are a few notes I jotted down during talks by Tadayoshi Kohno and Stefan Savage covering the security of Internet of Things (IoT).

Computer Security and the IoT (Tadayoshi Kohno)

This talk covered several situations where the IoT is a source of security and privacy risks. The IoT refers to any connected device that a user might want to purchase. These devices include door locks, thermostats, automobiles, refrigerators, and many others. Users are attracted by these devices because they come with lots of benefits, but one may wonder what security and privacy risks are implied when using connected objects. Some of these questions include: Does the IoT affect safety? Are there privacy leakages concerns? Can information about IoT users be inferred by adversaries? What are the financial risks? Can IoT objects be used as stepping stones towards other attacks? Are connected objects zombies?

Example 1: the modern automobile

Nowadays, automobiles are computers on wheels: the number of computers in a automobile can range from 10 to 100. Computers increase the safety of automobiles (e.g., supporting automatic breaking features). However, in a security evaluation of 2009 sedans, researchers found several security vulnerabilities exploiting these onboard computers.

For instance, the diagnostics port (found under the steering wheel) can be used to communicate with other elements of the car. Even without physical access to the car, telematics installed within the car allow for over-the-phone attacks, and internet connections via FTP similarly open doors for attackers. To showcase the importance of their discovery, researchers were able to remotely control car brakes to disengage them. Another scenario is an attacker calling the car, exploiting vulnerabilities to implement new software, connecting the car over the Internet to its own server, and then running a theft program which starts the engine and unlocks doors. The attacker can then easily drive away with the car. Using a similar procedure, an attacker can initiate remote surveillance of the car’s passengers including tracking the car’s GPS position as well as the sound recorded by the microphone used for hands-free calling inside the car.

Example 2: children’s toys

Researchers found that toys equipped with WiFi and a webcam can be hacked to make webcams accessible to external adversaries. The privacy risks are immediate, but other risks like financial risk (blackmail) should be taken into account.

Example 3: home power line monitoring

Companies are offering home power line monitoring to create bills itemized by each appliance using electricity in home. Researchers asked themselves: how much can you learn about activities going on within a home by monitoring the power line? They found that it was possible to infer a lot about what is going on inside the home, including which TV show is being watched by monitoring patterns in the power line (because in this case each show induces a different pattern).

Example 4: home automation

Home automation controllers enable consumers to control all sorts of connected objects inside their houses like door locks, refrigerators, furnaces… The question here is can you compromise the home automation controller to affect devices within a home. An example attack demonstrated that it is possible to remotely control a CFL light bulb plugged in a dimmer controlled by home automation to have it turn on and off until it pops. This outlines the risk of using home automation controllers and the connected objects they are controlling as stepping stones: first control home automation, then the dimmer, then the CFL bulb to cause a fire. Another risk lies with networked IoT systems that may long outlive intended service life and security patch lifecycle, thus becoming security zombies.

Modern Automotive Vulnerabilities: Causes, Disclosures and Outcomes (Stefan Savage)

A car is no longer only a mechanical device: it is a very complex distributed system. Cars typically have 20 to 40 electronic control units — computers. Such computers’ computing power, operating systems, and software parts greatly vary. They are internally connected by a car network mainly composed of two buses. Some components act as proxies to allow these two buses to communicate. Cars are also externally connected by wired and wireless channels.

Car networks are not hardened. If one connects to the diagnostic port, one can get complete control over the car. Indeed, the way all cars are designed, once you are inside the network, you have full control over the car’s systems. Communication over buses is done in an announcement fashion (with no reference to the source of the message). A car’s network has very extensive control on its various parts: indeed, the network is used for maintenance so it must allow for maintenance staff to put the car in unsafe states to be able to operate. The same network is also used for electronic control unit updates.

In 2011, researchers demonstrated remote takeover of the car’s internal network without physical access and at arbitrary distance. Indeed, the external attack surface is very large:

  • one can create a CD that takes over the car by exploiting a vulnerability in its CD player. Similar attacks are conceivable using USB ports.
  • lots of short range digital channels like bluetooth, wifi, and keyless entry exhibit vulnerabilities.
  • long range digital channels as cellular channels, HD radio, and satellite radio also exhibit vulnerabilities. For instance, different assumptions made by different manufactures about the block size handled by the 3G software interface of a car led to a buffer overflow vulnerability.

The automobile industry is particularly exposed because of its specificities:

  • environmental pressures: budget for security process is limited because adversaries are not identified today. Furthermore, the high regulatory and market pressure on feature creation, as well as the time to market pressure, also contribute to making security secondary for car manufacturers.
  • supply chain issues: source code for car software is frequently not available as it is how suppliers make profits. Furthermore, that software exhibits extreme heterogeneity and source code can greatly vary from one vendor to the other.

Finding solutions to these problems is very hard because disclosing security vulnerabilities can have dramatic consequences on end consumers. One of the first important points is to minimize real harm: provide information and knowledge about vulnerabilities to car maker as well as regulators, without publicly releasing code or details yet. The goal is to improve automotive security in an industry with very little capacity to deal with the problem. In the short term: some bugs can be fixed in next model and mitigations implemented for some channels (e.g., cellular channels by collaborating with cell carriers). More long term solutions require important changes to development practice and contracting practice. Security design must be an input to the overall electrical design of a car.

The direct and indirect impact of car security in the US includes the now common remote update mechanisms, the creation of a cybersecurity community within the Society of Automotive Engineers and the National Highway and Traffic Safety Administration, as well as the creation of 2 bills.

The takeaways from this talk were that cars are computers on wheels and lots of complex issues make it challenging to fix their security bugs. The question of disclosure is pretty tricky as there is real life harm possible.

Please leave any comments you may have below or reach out to me on Twitter at