
Reverse-Engineering Google Nest Devices - jelveh
http://experimental-platform.tumblr.com/post/137835649425/reverse-engineering-google-nest-devices
======
Animats
Then there are the Nest cameras, reporting everything you do to Google.

 _" The telescreen received and transmitted simultaneously. Any sound that
Winston made, above the level of a very low whisper, would be picked up by it;
moreover, so long as he remained within the field of vision which the metal
plate commanded, he could be seen as well as heard. There was of course no way
of knowing whether you were being watched at any given moment. How often, or
on what system, the Thought Police plugged in on any individual wire was
guesswork. It was even conceivable that they watched everybody all the time.
but at any rate they could plug in your wire whenever they wanted to. You have
to live - did live, from habit that became instinct - in the assumption that
every sound you made was overheard, and, except in darkness, every movement
scrutinized._" \- "1984", Orwell

 _" Video and audio signals and data: When you enable the recording or
streaming features of your Nest Cam, we may record and process video and/or
audio recordings from the device, subject to your configuration and settings.
This may include capturing and emailing to you portions of this data as part
of a notification or analyzing the data to identify motion or other events. We
may process information from your Nest Cam so that we can send you alerts when
something happens. In addition, if you have the recording features enabled, we
will capture, process and retain video and audio data recordings from your
device for the duration of your recording subscription period (for example, 10
or 30 days) and you will be able to access those recordings using the Services
during that time."_ \- NestCam privacy policy, Google

~~~
dguaraglia
I'm curious. How else would you implement a cloud-based recording service with
image recognition? (EDIT: full disclosure, I work for Nest through the Dropcam
acquisition)

~~~
bhauer
> _a cloud-based recording service_

Well, there's the rub, right? I think what those of us who consider themselves
self-hosting partisans would say is that we'd prefer a device that allows us
to send its signals to a server we own and operate. The recording and image
recognition would then occur on that server.

In my ideal world, Dropcam (and later Nest) would have provided software I
could install on my own server (located either on my home network or at a data
center). I know that sounds like a far-fetched dream, but that's the ideal I
want, and I will pay twice as much or more for devices that recognize the
emergent demand for self-management.

I have a Dropcam, and I enjoyed using it for a while. But I stopped using my
Dropcam about a year ago because I grew increasingly unhappy with the idea of
its video stream being sent to an untrusted third-party (Dropcam and later
Google/Nest). Since there is no "self-service" mode for Dropcams, it has
become a decoration in my house.

~~~
magicalist
> _we 'd prefer a device that allows us to send its signals to a server we own
> and operate_

There are lots of cameras that do that. You can even mix and match software
and hardware making for real options, not just some vertically integrated
service.

So is the rub that you think that such a device just shouldn't exist for
anyone?

~~~
bhauer
> _[Do] you think that such a device just shouldn 't exist for anyone?_

No. I apologize if that's what you took from my statement.

I hope the future sees technological evolution that makes it easier for common
people to self-manage their devices. Presently, doing so requires more time
and thought investment than traditional "cloud" options. For example, it took
me a bit of time to set up a self-hosted NVR with a network of IP cameras. But
in an ideal world, Dropcam-like devices would exist and provide an option
during setup: "Do you want to use our video hosting service or run your own?
If you choose your own, you'll need to install some software on a computer..."
The Dropcam software is really well designed, it's just a shame I can't run it
on my own server.

Like I said, it's idealistic wishful thinking. But if people want to use
services hosted by third-parties, I don't want to take that option away.

~~~
JustSomeNobody
Definitely wishful thinking. Anything consumer oriented will be forced to the
cloud and use proprietary protocols.

There simply aren't enough of us who want control of our own data to make a
difference.

------
pilif
_> with email and plaintext password_

It's totally reasonable to transmit a password in clear if it's being
transmitted inside of an SSL tunnel (which it is in this case).

Most if not all techniques that would allow for not transmitting the password
in a server-decryptable fashion would require the password or a password
equivalent to be stored in clear on the server.

In case of a breach, that would be devastating.

~~~
jimktrains2
> Most if not all techniques that would allow for not transmitting the
> password in a server-decryptable fashion would require the password or a
> password equivalent to be stored in clear on the server.

That's not true at all! SRP[1][2] allows the server to not have the plaintext
password ever, even during account creation.

Kerberos' KDC doesn't know the plain-text password either[3].

Even HTTP Digest didn't require the password to be stored in plain text [4].
[Edit: though if you leaked HA1 that effectively becomes the credential]

Moreover, client TLS certificates would also fit the bill, as the client key
is never transmitted.

Don't spread FUD if you aren't sure. If you don't know, don't say anything or
say you don't know.

[1] [http://srp.stanford.edu/](http://srp.stanford.edu/) [2]
[https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...](https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol)
[3] [http://security.stackexchange.com/questions/15849/does-
the-k...](http://security.stackexchange.com/questions/15849/does-the-kerberos-
kdc-know-the-users-plaintext-passwords) [4]
[https://en.wikipedia.org/wiki/Digest_access_authentication](https://en.wikipedia.org/wiki/Digest_access_authentication)

~~~
Retric
If password X is hashed to Y, and you store Y that seems ok.

But if you directly check if the client transmits Y then Y is just the new
password.

At a minimum you should be hashing whatever the client sends and comparing
that with the hashed password.

PS: Not that most developers should do this by hand.

~~~
jimktrains2
I don't understand your point. Even if the client sends HASH(password), that
effectively becomes the credential. That's where HTTP Digest is less
successful (as was pointed out by a sibling and I went D'oh for not
remembering).

> At a minimum you should be hashing whatever the client sends and storing
> that.

That's a very narrow view of how to authenticate. SRP and client certs
certainly don't work that way.

~~~
gohrt
Salt.

In SSL/TLS, the data is transmitted using a one-time pad of some kind, so that
intercepting a transmitted token gives you nothing that you can use to
authenticate in a future connection (but you might be able to hijack the
connection you intercepted, if you spoofed the server into thinking you are
the intended client)

[https://en.wikipedia.org/wiki/Forward_secrecy](https://en.wikipedia.org/wiki/Forward_secrecy)

------
supergeek133
> _you cannot operate the camera or switch your thermostat’s settings without
> Internet connection_

This should say *remotely. I know it does in the paragraph before, but
sometimes people only read bullets.

So is the complaint here I can't find out what data the device is sending back
to Nest in whole? And contrary to the post, their Public API is pretty
extensive.

Seems to me this is just another person with a concern around no local
control/data retrieval. There is at least one other thermostat that has that.

~~~
eitally
Well, you can't operate the camera without an internet connection. The only
thing you can do is unplug it & plug it back in.

It's really irritating to use a Nest thermostat with no connection, either,
since you can't set or control your heating/cooling schedule.

~~~
supergeek133
The camera is one thing... but from their perspective I could understand why
they don't want it working locally.

As far as the thermostat, people don't edit their schedules that often really.
Plus at least with the v3 you can do it on the thermostat. I don't know about
the others, I assume not based on the comments.

Plus for others (Honeywell for instance) you can do it locally as well as
remotely.

That being said, scheduling interfaces are SUPER hard to build where people
understand them and it does what they want.

~~~
mikestew
_Plus at least with the v3 you can do it on the thermostat. I don 't know
about the others, I assume not based on the comments._

I don't know if it's always been this way, but my V1 Nest let's me fiddle with
the schedule on the thermostat. Kind of a pain with a rotating ring as your
input device, but it can be done. (Assuming a firmware update hasn't broken
this feature; haven't used the feature in well over a year.)

------
kuschku
> […] creating a walled garden around the user’s own data is a shady move. All
> of my private data should be easibly accessible to me though open API
> without any gimmicks. In its press release Nest promised introducing a
> public API[,] however [it] seems limited in many ways compared to the
> internal API used by Nest mobile app - and to add insult to injury - many of
> its features require an active Nest subscription.

This is exactly one reason why using "Cloud" services for long-living things,
like Hardware, is a great risk.

When Google shuts down Google Reader, we can all migrate to an alternative
easily.

When Google shuts down Nest, people are left with non-working thermostats, and
have to spend money and rebuild their systems to continue on.

Even worse, if just the internet goes down – not that rare in areas in the US
only served by one ISP which doesn’t have to fear competition – one is even
left without heating.

The reaction of the people on the recent case where Nest went down itself, and
people were left without heating, fits well as context for the following
excerpt from "The Sorcerers Apprentice" (1797, Johann Wolfgang von Goethe):

    
    
        Herr, die Not ist groß!      Sir, my need is sore.
        Die ich rief, die Geister    Spirits that I've called
        werd ich nun nicht los.      My commands ignore.

~~~
jedberg
> When Google shuts down Nest, people are left with non-working thermostats,
> and have to spend money and rebuild their systems to continue on.

No, they are left with a normal programmable thermostat with a nicer interface
than most.

> Even worse, if just the internet goes down – not that rare in areas in the
> US only served by one ISP which doesn’t have to fear competition – one is
> even left without heating.

This is not true. The Nest operates perfectly fine without internet.

> The reaction of the people on the recent case where Nest went down itself,
> and people were left without heating

That's not exactly what happened. What happened was there was a bug in the
software that had an issue when their server became unavailable. But this
could happen with any device that is controlled by software. And even if they
had a totally open and accessible API right on the device, this problem still
would have happened.

I don't like the fact that they lock up the data, but we should probably try
to stomp out the myth that the device is totally useless without their
servers.

~~~
cptskippy
> No, they are left with a normal programmable thermostat with a nicer
> interface than most.

Ehh... I don't think the Nest Thermostat is completely programmable from the
hardware itself. You can definitely set temperatures and toggle between
heat/cool, heat, and cool; but I don't think you can edit the schedule. Even
if you could, I don't think I'd want to. The hardware's UI is beautiful but UX
leaves much to be desired.

~~~
mikestew
_but I don 't think you can edit the schedule._

Second time I've seen this in this thread, so I walked over and checked our V1
Nest: yup, you can edit it on the device. And I rescind my earlier comment on
usability: it's actually not _that_ bad. Certainly easier than the
programmable thermostat it replaced.

~~~
cptskippy
I just checked my v1 and I was able to edit the schedule but I have no way of
knowing if I was editing my weekly schedule or making a 1-off correction. I'm
guess it's the later and not the former because the change isn't reflected in
the App.

From my perspective it is pretty bad. While I could edit an entry in the
schedule (e.g. move it, change temp range), I had no way to add or remove an
entry in the schedule, had no idea what the original values were, how to
cancel/undo, or know what I was editing without making a change. It was
frustrating at best.

------
yalogin
I am surprised the Nest devices allow themselves to be man-in-middle'ed like
this. Why are Nest devices accepting a random (valid) certificate? One would
think they will only accept a valid Google certificate, signed by the Google
root certificate.

Am I missing something? The article does not mention about any software
tampering on the device itself.

~~~
kapitalx
This is a man in the middle on the mobile app, which relies on the
certificates on the phone. You just need to add your phony certificate to the
OS's trust store. It's an attempt to find any private APIs that the APP is
using, rather than reverse engineering the protocol between Alphabet and the
nest device.

------
andrewpe
The nest thermostat seems to use firebase.com API from my research.

