The Fundamental Interconnectedness of Things
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
For the most part, people use the Tesla REST API via the iPhone and Android mobile apps. The apps enable you to do any of the following:
- Check on the state of battery charge
- Muck with the climate control
- Muck with the panoramic sunroof
- Identify where the hell your car is and what it’s doing
- Honk the horn
- Open the charge port
- Change a variety of car configuration settings
- More stuff of a similar nature
For the purposes of this article, it’s important to note that there’s nothing in the API that (can? should?) result in an accident if someone malicious were to gain access. Having said that, there is enough here to do some economic damage both in terms of excess electrical usage and forcing excess wear on batteries.