Model S REST API

[aviators99]

Looking forward to applying the new functionality. It will be interesting to see how they implemented alerts on the car alarm - through the app or out of band (ie text message).

Well, I wouldn't get too excited. The new API is much more secure, and our fun is about to be over :-(
The old server is still active (and compatible), but it won't be for long.
The new authentication is OAuth.

New API server is https://owner-api.dev.teslamotors.com , which I guess could be encouraging for the future. Streaming API server seems to be the same as before.

There are a bunch of new commands, but they only work on the new server.

 

[apacheguy]

Well, I wouldn't get too excited. The new API is much more secure, and our fun is about to be over :-(
The old server is still active (and compatible), but it won't be for long.
The new authentication is OAuth.

So what's there to worry about? Given that the host name contains the words "owner API" I doubt that TM is going to shut us out.

How does OAuth work? They give each user an API token to use instead of the cookie method?

 

[Olen]

There are plenty of OAuth-libs out there for various languages, so OAuth in it self should not cause a big problem. If you post some more info I am more than happy to try to get something useful out of it.

 

[markb1]

OAuth is encouraging, since it is intended for opening up APIs to third parties, without revealing user passwords. So maybe Tesla will officially open the API to us. It does prevent unauthorized third parties from the using the API, though, since requests need to be signed (per my rudimentary understanding). So presumably we'll need to sign up with a developer program to get access to the new API. Hopefully the old API keeps working until that is in place.

 

[apacheguy]

How does the mobile app sign requests? What's to prevent us from using the same key?

 

[Olen]

As far as I know, there is nothing in the oauth spec itself that requires the requests to be signed by a registered party. And even if Tesla demands that, it could possibly be implemented by an automated process, with a simple registration process on the web.
So I still have great hope that we will get access to the APIs.

 

[markb1]

How does the mobile app sign requests? What's to prevent us from using the same key?

If it's cryptographically signed, the key is private. I guess it would have to be embedded in the app, so not impossible to get your hands on, but it's not sent anywhere, so you can't sniff it from the wire. Not sure how OAuth does it.

I know there are two incompatible versions of OAuth, and 2.0 doesn't support signing. The OAuth 2.0 editor actually quit and withdrew his name from the project because he wasn't happy with the direction it was taking.

 

[aviators99]

As far as I know, there is nothing in the oauth spec itself that requires the requests to be signed by a registered party. And even if Tesla demands that, it could possibly be implemented by an automated process, with a simple registration process on the web.
So I still have great hope that we will get access to the APIs.

Maybe, but I would expect it will be months (if not years) before such a program is in place. In the meantime, I expect we'll be losing access via the other method pretty soon, once 6.0 is completely rolled out.

 

[markb1]

I decided to try my hand at sniffing the SSL traffic between the app the server. I'm kind of stuck. I managed to get my own CA cert installed on an Android device, and I can get the browser to trust certificates signed by that CA, but the Tesla app does not seem to trust my CA. And suggestions on what to try, next?

 

[apacheguy]

If you sniff the traffic locally (I.e. Packet sniffer installed on the phone itself), then shouldn't it be readable? That way you don't have to forge a self signed cert.

Anyone think that they can decompile the mobile app and extract the necessary private key?

---updated---

They are using certificate pinning. On ios there is a folder called SSLpins.plist in the library folder.

 

[markb1]

If you sniff the traffic locally (I.e. Packet sniffer installed on the phone itself), then shouldn't it be readable? That way you don't have to forge a self signed cert.

It would not be be readable, because it's encrypted.

Anyone think that they can decompile the mobile app and extract the necessary private key?

On Android, yes. Really the OAuth credentials are what we need. The private key for the SSL session would be useful for reverse engineering, but that's generated on the fly, not built into the app. I'm making some progress, but I'm going into this not knowing what I'm doing. Wondering if there is a private place to discuss this? Not sure I want to post everything in public.

They are using certificate pinning. On ios there is a folder called SSLpins.plist in the library folder.

Probably something like that, but I'm using Android for this. But it's looking like decrypting the SSL session may not be the easiest route.

 

[markb1]

I managed to get the vehicle list. I'm not going to post Tesla's OAuth secrets, so don't ask. But here's everything else.

First, you need to get the bearer token. To do this, you need to post a JSON object to https://owner-api.teslamotors.com/oauth/token

(You will need to fill in the empty strings below.)

{
   "grant_type" : "password",
   "client_id" : "",
   "client_secret" : "",
   "email" : "",
   "password" : ""
}

That will return a JSON object containing the bearer token. That must be put in an HTTP header like this:

Authorization: Bearer 1234abcd

(1234abcd is the bearer token, but in practice, this will be a much longer hexadecimal number.)

Simply get https://owner-api.teslamotors.com/api/1/vehicles using the above header, and a JSON object will be returned with the vehicle list.

 

[markb1]

Here is a list of all the commands I could find.

The following take the form "api/1/vehicles/<id>/command/<command>":

charge_max_range
charge_standard
sun_roof_control
flash_lights
honk_horn
door_lock
charge_port_door_open
trunk_open
remote_start_drive
upcoming_calendar_entries
set_temps
charge_start
auto_conditioning_start
charge_stop
auto_conditioning_stop
door_unlock

The following take the form "api/1/vehicles/<id>/data_request/<command>":

charge_state
climate_state
drive_state
gui_settings
vehicle_state

Misc:

api/1/vehicles/<id>/wake_up
api/1/vehicles/<id>/mobile_enabled
api/1/notification_preferences
api/1/vehicle_subscriptions
api/1/vehicles
oauth/token
users/change_password

 

[hans]

I managed to get the vehicle list. I'm not going to post Tesla's OAuth secrets, so don't ask. But here's everything else.

First, you need to get the bearer token. To do this, you need to post a JSON object to https://owner-api.teslamotors.com/oauth/token

(You will need to fill in the empty strings below.)

{
   "grant_type" : "password",
   "client_id" : "",
   "client_secret" : "",
   "email" : "",
   "password" : ""
}

That will return a JSON object containing the bearer token. That must be put in an HTTP header like this:

Authorization: Bearer 1234abcd

(1234abcd is the bearer token, but in practice, this will be a much longer hexadecimal number.)

Simply get https://owner-api.teslamotors.com/api/1/vehicles using the above header, and a JSON object will be returned with the vehicle list.

I understand how to fill in email and password but what about client_id and client_secret? What values should I populate these fields with in order to get the bearer token? Is this "Tesla's OAuth secrets" that you can't post or something else?

 

[markb1]

Is this "Tesla's OAuth secrets" that you can't post or something else?

Yes, those are the OAuth secrets. I just don't feel comfortable giving that out. Though Tesla didn't go to great lengths to secure those values. They are built into the APK, as they pretty much have to be, but not obfuscated.

 

[apacheguy]

Again, given that the server host name is "owner-api" I seriously doubt they are trying to keep this secret. Sounds like they are trying to keep it open to all of us.

 

[markb1]

Again, given that the server host name is "owner-api" I seriously doubt they are trying to keep this secret. Sounds like they are trying to keep it open to all of us.

But given the way that OAuth is typically used, each developer gets their own ID and key. So the keys aren't shared. So I agree that it looks like they are preparing to open things up, but I do not think they will be passing out the same key to everyone.

 

[aviators99]

Again, given that the server host name is "owner-api" I seriously doubt they are trying to keep this secret. Sounds like they are trying to keep it open to all of us.

Considering that they have encrypted it in the app, they aren't willing to give them to us yet. Although they obviously know that it's easy to decrypt (at least for the Android version).

 

[Olen]

Great progress!
I hope the proper people at Tesla reads this thread and realizes that this kind of development will happen no matter what, so they add the proper infrastructure to make sure we can get our own set of secrets.
It took less than two days before you found their keys. And while I support your decision not to share them, it is only a matter of time before someone else will either do do that on purpose, or leak them by mistake.

 

[markb1]

It took less than two days before you found their keys.

To be fair, they didn't do much to hide them.