A little over a week ago, I wrote about how the authentication model for an unpublished Tesla REST API was architecturally flawed because it failed to take basic precautions against the sharing of credentials with third-parties common to most REST-based services these days. Since its publication, the main criticism of the article centered around the fact that the API is neither a published API nor has it been advertised as being meant for third-party consumption.
The adding of value to devices and services with or without the knowledge/permission of their creators is an integral part of the Internet of Things. These days, people expect an API around their devices. They will discover any APIs and add value to the device/service—even if the task requires a little reverse engineering work. A responsible creator of a device or service in today’s world defined by the Internet of Things must therefore do the following things—always:
- Give it a public API
- Protect any internal communications so they can’t be reverse engineered
- Protect any public communications so that they don’t put end users at risk when they leverage third-party devices and services
Whether the API is published or not, this perspective doesn’t consider that we’ve slowly been evolving the way we use technology. As we rethink many of the devices we use at work and home, we have to rethink our expectations not only of how these devices work in isolation, but also of how they work together. Whether it’s a phone, a car, or a light bulb, technology users should expect that these devices are capable of secure interactions.
The Burden of Security
The flaw I exposed in the Tesla API results from Tesla placing the burden of managing authentication credentials entirely on the shoulders of end users. In other words, the soundness of the Tesla API rests on the premise that end users should never, in any circumstances, leverage third-party tools to interact with their cars. Tesla has no responsibility to make an unpublished API secure against third-party malfeasance or misfeasance.
As a general rule, I don’t like approaches to software architecture that force users to choose between leveraging useful functionality and being secure, especially when the option to have both is easily addressed. If you place the burden of security on the user instead of the API, the proper response for a user is to forgo all value-added functionality from third parties in order to operate securely. In my experience, convenience always wins in the battle of convenience versus security, and it’s folly to expect users to change.
Three phenomena exemplify my view of this problem:
- Cloud computing, where end users are sticking things “into the cloud” for greater agility while central IT admonishes them for “going rogue”
- BYOD (bring your own device), where end users are leveraging a wider variety of devices than those vetted by corporate IT to enable them to do things corporate IT can’t envision
- The “Internet of Things,” where all services and devices are interconnected via rich APIs and function well beyond the intentions of their designers
If we didn’t have users going beyond the intent of the creators of a device or service, we wouldn’t have any of these things. We wouldn’t even have many of the things we take for granted today like online banking.
Cloud computing is most secure when the cloud providers empower users with the tools to operate securely in the cloud. Trying to stop people from going into the cloud isn’t the solution. The same goes with BYOD. You can try to stop people from using their devices on your corporate network. The result, however, will be that they will stop using your corporate network. That neither provides you with greater security nor does it stop users from using their devices to do work.
When speaking of the Tesla Model S, however, we’re talking about the “Internet of Things”—the point at which all devices and all services communicate with one another as needed without much, if any, human intervention.
A Story of an Interconnected World
One of the fundamental aspects of the Internet of Things is that the vendor doesn’t get to determine valid “use cases” for their devices or services. In fact, the point of an interconnected world is to create value well beyond the imagination of a device’s original inventors. Tesla, for example, may or may not have envisioned a world in which my car, my alarm clock, the weather, light bulbs, and my home security system are talking to each other to get me out of the house. I have and likely so have many, many others.
It takes only a few modern devices and some programming know-how to start building your own Internet of Things. No fancy wiring or custom hardware is necessary.
Here are the components:
- Light bulbs with an API like the Philips Hue light bulbs
- A Raspberry Pi or even a general purpose laptop, desktop, or server
- A car with an API like a Tesla Model S
- A programmable thermostat with an API
- An internet connection
- A tablet device
The critical features of all of these components are that they can connect to the Internet and they have an API. Except for the custom programming on the Raspberry Pi, they don’t know anything about the other things they will work with.
They are specifically not connected through some purpose-specific local connection. None of them are built knowing anything about the others, yet they end up being fundamentally interconnected by RESTful APIs and a bit of programming.
The Myth of the Private API
Perhaps the root of the question where security lies boils down to the question of whether the Tesla should be considered part of the Internet of Things. While it’s cool to have your house automatically warm up your car when you wake up, it may not be a scenario in which Tesla has chosen to participate. They have not published their API and, for all we know, it was never designed to support such an interconnected reality.
When it comes to modern devices and cloud services, however, there’s no such thing as a private API. More to the point, Tesla didn’t take the most basic precautions to make the API a truly private API, nor did they take the most basic precautions to protect users against the use of the API in third-party applications. In other words, it’s the worst of all worlds—not published, private, or secure.
I sincerely believe that ultimately there is no such thing as a private API for consumption over the public Internet. Certainly there exist APIs of all sorts to support private communications between components of an application. The Dell MCM software acquired from the company I founded, Enstratius, has both a public RESTful API and several internal SOAP APIs. We neither publish nor talk much about the internal APIs. What’s important to note, however, is that a customer can do anything they need to do using the public REST API and we’ve also taken steps to make sure that customers can’t reverse engineer and leverage the internal APIs.
While Tesla uses the APIs for communication between their mobile apps and the car, they’ve neither taken the basic steps to protect it against third-party usage nor is it constructed in a tightly coupled, private fashion. As a consequence, people have reverse engineered the API and begun creating value-added services around it. These aren’t rogue tools aimed at capturing your credentials—they are truly valuable services that should not require Tesla’s blessing. I have even used some of them myself.
The Philips Hue also followed a similar path. The last time I checked, it was also “not published.” That didn’t stop me from writing a generic light bulb management API to talk to the Hue light bulbs and it certainly hasn’t stopped the rich ecosystem that has grown around those APIs. It also didn’t stop an outside researcher from skewering the security model of the Hue API. In short, failure to publish an API doesn’t make an API a private API. As long as it is consumable over the Internet and in a format that can be reverse engineered, people will reverse engineer it and add value to your creation.
One thing lost in my original article is the fact that I have been praising Tesla for having an API. In fact, in discussing it on Twitter and in other places, I noted that I’d rather have my Tesla with its flawed API than to have it with no API at all. The key point of the article, however, was that in an interconnected world, it is irresponsible to create an API without protections that enable users to leverage that API with third-party devices and services. It’s especially irresponsible because common best practices for REST API security (OAuth and request signing) easily deal with that problem without a lot of programming overhead.