Afternoon. How is everyone's DEF CON going?
So this talk is on back-dooring the front door.
And it got a lot of slides, so I'm just going to get right into it.
To start off, I'm J-Max. I work as a software engineer.
Hacker for fun. I like doing things with locks.
And the thing I always like to tell people is the best puzzles are the ones that were never meant to be solved.
And I think that explains a lot about the hacker attitude.
Now, all opinions expressed in this talk are my own.
They aren't my past, present, or future employer's opinions.
And if you see something you like and you want to reach out later, you can find me on Twitter, at J-Max.
So obviously this talk is going to be about the Internet of Things.
And we just lost video.
There we go. Internet of Things.
So our homes are getting smarter and we're bringing more technology into our homes to replace traditionally dumb or mechanical objects.
And for this talk, we're going to be looking at the August lock.
Particularly the August smart lock that I have on stage here.
This is what an August lock looks like when you put it on your door.
I don't know if you can see it on the screens up there, but it replaces the thumb term on your deadbolt.
So if you live in an apartment like me, this is a great option because you don't actually have to replace the outside of your lock.
That would annoy your landlord.
And the device itself is just Bluetooth low energy.
And it gives you smart lock features like auto unlocking, unlocking when you approach the door, those type of things.
But what got me interested in this lock was actually August's marketing team.
One of the things I like to do when I'm looking at a technology is see what claims the company has.
What the company distributing it is making.
Now on August's website, the quotes that I'm showing you up here, they're actually no longer on their website.
You can find them on the Wayback Machine.
But they said such things as, their lock is unlike physical keys which can be duplicated and distributed without your knowledge.
They also said, it's safer than codes that can be copied.
And so we get this reoccurring theme that it's not like a traditional key.
It's somehow safer.
And their most aggressive claim, I'm going to let them explain it to you because I don't think you would believe me if I told you.
August is the lock that requires no key.
Only an invitation.
An invitation that you can give and take away whenever you please.
Keyless, codeless, and completely secure.
And completely secure.
And completely secure.
And completely secure.
And completely secure.
And completely secure.
So I didn't just loop that video for the hell of it.
That's actually what I did when I first heard this piece of marketing material.
I went back to that YouTube video and just played that section over and over again thinking I must have misunderstood something.
Because I'm sure what they're trying to do is comfort people and say,
oh, we know it's technology, but it's safe technology.
And their thought was this will make people feel comfortable with our lock and think it's secure.
However, that's not really how I took it at all.
I kind of took this as, well, you have a completely secure lock.
Sure, it would be worth looking into, I suppose.
I don't think I've ever seen a completely secure lock.
So putting together the security claims.
Obviously, they claim perfect security, which is a little amorphic.
But they also claim things like guest access can be revoked at any time.
Guest permissions can be limited to a schedule.
Guests can't use the unlock feature.
They can't access lock settings.
They can't see who's using the lock.
And the keys can't be duplicated.
We saw that claim twice in two different forms.
They said their codes can't be duplicated.
They don't have codes that can be copied.
And they don't have keys that can be duplicated.
They also say that you can track who enters and exits your home.
That should say home, not phone.
So to start looking at the lock, I said,
I'm going to map out the API.
I work as a software engineer.
Let's just look at the boundaries of this application.
Let's approach it black box.
But the problem is, which API?
There's actually two APIs in the August lock.
There's the one between your phone and the lock.
And the one between your phone and the cloud.
Or if you read XKCD, someone else's computer.
And working as a software engineer, mostly on web applications,
I wanted to look at that HTTP one first.
The REST side.
So what I did is I downloaded MTMProxy.
And if you're not familiar with this tool,
you really should get familiar with it.
It's an awesome tool.
Super easy to use to get in the middle of any application,
particularly if they're using SSL.
So I installed the certificates on my phone.
Fire up MTMProxy and launch the application.
And I get something that looks like this.
And what this is indicating is that the August application is
using certificate pinning.
Now, if you're a developer and you develop mobile apps,
certificate pinning is a really good idea.
And you should absolutely have it on.
On your applications.
However, if you're a hacker and you're trying to figure out
how something works, it's a real pain in the ass.
So we need a way around this.
One solution is to use iOS Kill Switch.
It's originally developed by ISEC Partners.
There's a new version, iOS Kill Switch 2.
Basically what it does is shut off certificate validation
on your iPhone.
Now, this being a DEF CON talk, I really didn't want to walk in
and shut off SSL on my phone.
And then connect to the DEF CON Wi-Fi and see what happened.
I don't think that would work out well for me.
So I need a better solution.
Fortunately, August built one into their application.
If you just tap on the hamburger, press and hold on the
version number, and then you type the super secret phrase,
Dreadful DAO, casing matters, make sure your Ds are capital,
you'll get access to their debug menu.
On their debug menu, at the very top, you'll see a URL.
That URL is the endpoint to your device.
I think that their application is talking to when it reaches out
to the cloud.
If you just tap on that, it pulls up this menu.
Now, I obviously don't want to look at staging and their
development environments because, well, that's probably
outside of scope and I don't really want any nasty letters
from August.
But this other option looks pretty cool.
So if you just tap on that, it opens another dialog where you
can specify any endpoint you want.
Now, obviously, if you can specify any endpoint you want,
they can't have pinned the certificate for every endpoint
in the world.
So I just enter an endpoint I control.
And again, you can specify any endpoint you want.
It can be HTTP or HBS, so you can choose not to deal with
HTTPS at all if you want to.
Enter an URL you control.
Hit custom.
The application will crash.
And when it relaunches, boom, you're in the middle.
So now we have access to all the traffic back and forth and we
can start looking at how the application works.
And one key thing I'd like to point out here is unlike iOS
kill switch, sorry, SSL kill switch, this didn't require a
jailbreak.
There's no jailbreak required.
This could be a stock phone and this would work.
And being a developer, a thought occurred to me, there's
probably a sprint review where some developer walked in the
room and was just like, I've implemented certificate pinning.
We're good.
Ship the perfect security claim.
So we're going to cross that out.
Now, obviously, after we map out the API, we can build up a
collection.
I use Postman, put together a collection of all the endpoints
that it talks to.
This collection will be available in the GitHub
repository after this talk.
Now, looking through all the APIs that the August application
uses, one of them caught my interest.
And that was this one.
And for those who can't see what's on the screen, it's the
mobile application telling August's servers that you just
unlocked your lock.
And this is the owner of the lock doing it.
And what's interesting here is it's not anonymous.
This is tied to your account.
So what August is doing is they're building up a collection
of every time you've entered or exited your house.
If you're the owner of the lock.
This is something your schlag and your dumb locks are not
going to do.
It's a little creepy.
I'm not sure I want a company that makes a lock that they can
open also being able to build a profile of when I'm home and
when I'm not home.
Those two sets of data together would be incredibly valuable on
the black market.
So let's fix this.
MTM proxy can actually modify traffic as well as just
listening to it.
So with a little script, we just go ahead and do this.
We intercept all the APIs that log data about locking and
unlocking.
And we tell the application, yeah, 200.
Everything's good.
And we don't tell the web servers anything.
And the nice thing about this is it gives us privacy.
But if we remember, they made the claim that you'll know when
your guests open your door.
Well, the way they know that guests open your door is the
mobile application logs to their server, hey, I just opened this
door.
And then they notify you, Jimmy opened your door.
Obviously, if you can just say, I'm sorry.
I'm not going to tell you when I open a door, that kind of
defeats that feature.
But they also said guests can't be notified or see the activity of
feed of a lock.
Well, it turns out if we look at this API, there's an API to set
notifications.
So when someone opens your door, it's supposed to notify you and
say, someone opened your door, someone locked your door.
And if we just specify any lock, it could be a lock you don't own
and any user.
So we say, I don't own that lock.
And we say, notify me when this user opens this lock.
It doesn't matter what the lock is or what the user is, August
will dutifully notify you that that user opened the lock.
Even if you don't own that lock, even if you're not a guest on
that lock, any lock in the world.
But what else can we do?
Well, August has this idea of owners and guests.
Or as they like to call them, users and super users.
But guests are supposed to be limited in what they can do.
Specifically, they're not supposed to be able to use
things like the auto unlock feature, and they're not
supposed to be able to change lock settings.
But how does the mobile application know when you're an
owner and when you're a guest?
Well, it's actually this message right here.
They say, user type, user.
And if it's user type user, you're a guest.
If it's super user, you're an admin.
So let's just use MTM proxy again, and we'll just replace
user with super user, and we get access to that.
So let's go back to the menu as a guest.
So this is the first big interesting discovery we have
here, which is the lock itself has no concept of owner and
guest.
It only knows about users.
The entirety of the access control model is implemented
server side and in the application.
And since they're relying on you to talk to the server, well, we
can just cut that out eventually.
So to the claim that guests can't do these things, I just
have to say that's wrong.
Guests can absolutely do them.
They may not be able to do them through your application, but
they can do them.
So now the list of claims looks something like this.
Less gray and more red.
But I think we can do more.
We only looked at one side of the API right now.
What about that Bluetooth side?
Now, in case you forgot, it's structured like this.
The lock itself has no wireless.
It relies on your phone to talk to the cloud.
So if you want to play with Bluetooth low energy, a good app
to start with is light blue.
It's great for enumerating services and just seeing what
Bluetooth low energy looks like.
And you'll get something like this.
So this is an August lock.
And because we're able to connect to it and pull
services from the thing, we know that we're able to pair it with
it, which means it must just be using it just works pairing
because I never had to enter a pin.
But August relies on a second layer of encryption.
So that's not too big of a deal.
But I would like to intercept some traffic.
And if you look at Bluetooth low energy long enough, you're
eventually going to run across the Ubertooth, which is supposed
to make this really easy.
Unfortunately, I didn't think it was that easy.
And after about a week, I said, well, this is too hard.
I need to find something else.
But again, there's a better solution.
It's built into the August application again.
If we go back to the previous menu, there's this send logs
button.
If we just tap on it, it's going to take us back to the
app that it will pull up a screen that looks like this.
And for those who can't read it in the back of the room, it's to
auto unlock at August.com.
Now, if, like me, you look at that title and say, I wonder if
this will auto unlock my lock, I hate to disappoint you, it
won't.
What it will do is get you an e-mail from their VP of
engineering asking why you just sent this to them.
.
But what I'm going to do is just replace that with my e-mail
address to avoid those e-mails.
And that's it.
Then once I get on my computer, I open it up in notepad plus plus
and I search for cipher text.
And what you know, on the left side of the screen is the cipher
text for the communication between the phone and the lock.
And on the right side of the screen is the plain text.
So man in the middle attack built into the application.
So that uber tooth I bought, completely useless, throw it
out.
I just need their mobile app.
And again, no jailbreak is required to do any of this.
In particular, for the Bluetooth lock, you don't have to do
If you just use August support instead of Dreadful DAO, you'll
just get the send logs button and it will work just as well.
So now that we have the Bluetooth, how do they
authenticate with the lock?
Now, it's fairly simple.
Again, all access control is on the web server.
So when your phone connects to the lock, your phone then
generates 64 bits of random data.
They send that 64 bits to the web server.
The web server encrypts it into a packet to be able to
send to the lock.
Your phone gets it from the web server and then hands it off to
the lock.
The lock is able to decrypt it and then generate its own 64
bits, hand it back to your phone.
Your phone can't decrypt it, so it hands it to their server.
And then their server hands it back to you, decrypted.
And you take those two things, you glue them together, and
that gives you a session key.
And then you just use AES and that session key, and now you
can talk to the lock.
Now, what's interesting here is you'll notice this is all
symmetrical.
This is the lock encryption, which means the web server and
the lock must have the same key.
So how did they get that key onto the lock?
One option is burnt in at the factory and there's absolutely
no way to pull it out.
Another option would be maybe it's flashed in with the
firmware.
So, let's request firmware as a guest.
So as a guest user, I request access to, I request a copy of
the firmware.
And to make it interesting, I'll request firmware that
doesn't exist.
And I get a response that looks like this.
And I get a response that looks like this.
And at the bottom of that request, just a normal 404 for
a piece of firmware that doesn't exist, I see the serial number
of my lock and then a bunch of garbage.
That garbage looks awful suspicious.
Why is there garbage in HTML?
So if we open that up in a hex editor, and we just start
walking through this and trying random series of bits and just
skip the obviously wrong ones, like the all zero sections,
we'll come across the highlighted one.
And that decrypts the packets that were sent to the
server.
And that decrypts the packets that were sent to the web
server.
So now we know that must be the key that's being used.
This key I'll call the firmware key.
I think August internally calls it the online key.
But I think firmware key is more accurate in this case.
So this key appears to be unique for every lock.
But with this key, we're actually able to emulate the
web server.
Now the way August works is there's actually 256 key slots
in each of these locks.
Key slot zero is this key.
The firmware key.
Now, if we go back to their claims, they said it's safer
than codes that can be cached.
It can be copied.
And it's unlike physical keys that can be duplicated or
distributed without your knowledge.
Well, I didn't have any problems copying and pasting it.
So duplication seems to work.
I also didn't have any problems distributing it,
because you all have it now.
So this silver lock, if anyone tries to sell this to you on
eBay, it is worth nothing.
But it actually goes further.
If we take those log files we got earlier.
I need to stop touching this HDMI cable.
If we take those log files we got earlier, and we just run
grep on them, looking for some interesting stuff, we can
pull a lot out of there.
We can actually pull all the offline keys.
We can pull all the usernames, passwords, the firmware key,
the JWT tokens that are used to talk to the web server.
So basically all the secrets.
So that log file not only contains all the Bluetooth
traffic, but it also contains all the passwords that
you need to talk to the web server.
Now, I think most of these are fixed at this point.
But you'll probably still be able to pull offline keys from
those logs.
So now the list looks a little bit more like this.
Not so hot.
So the moral of the story here is, with a smart lock, don't
give access to someone you wouldn't give a key to.
Because in spite of what the vendor claims, it behaves much
more like a traditional pin and tumbler system, where when you
hand someone a key, they can do anything with that.
Then it behaves like an e-mail you send through Gmail or
something like that.
It behaves like a physical key.
If you give someone guest access to one of these locks, assume
they can get permanent access.
So all the code after this talk will be published on GitHub.
There's the address.
I'll tweet it out after this as well.
So I think we're doing good on time, actually.
Much faster live.
So I'm going to do a couple more things.
I'm going to do a couple demos here.
So obviously I have two locks here.
There's a bunch of wires coming out of them, so you probably
won't trust anything I do with them.
So we're going to be using a new lock that's never been
associated with any account.
But before I switch them out, I want to show you something.
So if we look at this silver lock here, and we just go to
settings, and we go down to the bottom, I don't know if everyone
can see the version of software that lock happens to be
running.
So we're going to do a couple demos here.
It's safe to say that is not factory firmware.
Which means that the code being pushed to these locks is
unsigned.
So the lock itself could be running any code, because it
doesn't have any signature checking to make sure that the
code came from August.
But now I'm going to switch that lock out, and we're going to do a
demo.
I'm just going to unpower this one so I don't pick it up in the
demo.
So this is a brand-new lock that's never been associated with
any user's account.
And hopefully it's not doa.
Pull out the battery tab.
And now we're going to do a demo.
.
Okay.
So we have a new lock on our door now.
Fresh from the factory and right out of the box.
In this perfectly secure state.
.
Okay.
Let's add this to our account.
So we're just going to go in here and set up a new lock.
If you have the august application, don't try to beat
me to this.
.
.
.
There we go.
We'll name it front door since that's the name of this talk.
And we'll put in our defcon house.
And we'll go ahead and configure it.
So to calibrate the lock, we just put it on our door.
Lock it.
Unlock it.
Sets up the lock.
Okay.
Now we have a lock on our door.
.
And it opens and closes as you can see.
Let's make sure it still connects here.
There we go.
So there's our lock.
Let's invite a guest user to this lock.
So I'm just going to invite myself, another account.
And we can see on the front door the access level is none.
Let's just change that.
We're just going to change that to guest.
It reminds us that guests can't use the auto unlock.
They can't invite other guests.
They can't control lock settings.
A bunch of stuff we know probably isn't true.
We'll just update that.
Okay.
So now we have a guest user.
And you know what?
Let's go back and let's make sure that we have notifications
turned on.
And we do.
Great.
So we should be notified then every time this user attempts
to use this lock.
.
Okay.
Let me just shut down the flashing lights demo here.
There we go.
And we're just going to run backdoor.js.
Can't see?
Okay.
Let me font size this.
Does anyone know where the font size is?
Thank you.
The obvious answer is answer.
Okay.
So Atwood's law is in play here.
Anything that can be written in JavaScript will eventually be
written in JavaScript.
So I figure if we're going to detect hardware,
we might as well write the exploits in JavaScript.
So we can see the results here.
It connected to the lock, added a backdoor,
and then disconnected from the lock.
And if we go back to the other screen,
we still haven't been notified that anything has happened.
So we know we're connected to the lock.
We're just going to go back to the other screen.
We know we backdoored the lock.
Let's see if we can just cycle the lock.
So I'm just going to try to open and close the lock
as that guest user.
Thank you.
So we're connected to the lock.
And it should...
There we go.
Start opening and closing.
So we just made it from a guest user.
We added a backdoor to the lock.
And now we're using that backdoor
to open and close that lock.
And if we go back and we look at the owner's phone,
they still have been notified we used that lock.
But...
What happens when we revoke access from that guest?
So if I go to the guest,
and I...
I'll just delete him altogether.
I don't want him accessing any of my locks.
He's gone.
And we cycle the lock again.
It should still work.
For those in the back room,
if you can see the lights on the lock,
that will tell you when it's open and closing.
Green is open.
Red is closed.
So there we go.
The lock is opening and closing.
.
Thank you.
And they'll actually just keep going on forever.
We'll just disconnect from that.
So plenty of time.
So let's try the high-risk demo here.
What I'm going to do is I'm actually just going to factory
reset this lock.
So if I go back to the iPhone here,
there's our lock.
We'll issue a factory reset.
.
.
So now that lock has been reset to factory state.
And if we go back to our demo,
let's do something else maybe.
Let's go back to the lights.
It should still connect up and still work.
There we go.
We established a connection.
And now it's sending the light up.
And the screen is.
There we go.
That'll make it better.
.
But there's still the possibility that maybe August
clears the keys when you add it back to your account.
So let's just add it back to a user's account.
Start setting.
Setup.
Scan for locks.
This part takes a while apparently.
There we go.
Front door.
We'll actually add it to a different house.
We'll just skip the calibration this time.
Not too interested.
Okay.
So there's our lock again.
And it still works.
Let me close out of this.
Disconnect from it.
Okay.
If we go back to our guest user who was once a guest to this
lock, the lock has been factory reset and it's been added to a
new house.
And we see if it still works using the back door we
previously inserted.
And, again, what should happen here is it will scan for the
lock. It's going to find the lock,
connect to the lock, and then it's going to open and close it
indefinitely.
.
So the interesting thing here is if you bought one of these
locks used off of eBay and you put it on your front door, the
previous owner had access to it.
Previous owner had the ability to assert an offline key.
And the previous owner now knows where you live.
So, again, it models much like a physical lock, just like buying
a used pin and tumbler lock.
means that you have a key that someone else could have a copy of.
Buying a used August lock means you have a lock
that someone else could have a key for.
So there's a bunch of mistakes made, obviously,
in the August application.
There's a log-sensitive data.
It doesn't differentiate between guest and owners at the lock.
It does that all remotely and at the application level.
The firmware is not signed.
There's no apparent way for a user to discover
if their lock has been backdoored.
But you actually don't even need a backdoor of the lock
because that firmware key is so central to the lock's operations.
The system relies on guests reporting
when they open and close the lock.
And the vendor makes claims
that they have two-factor authentication
when really they only have two-step authentication.
There's a couple things that they've fixed,
and the final one, this one's really entertaining,
is all the key material for the lock
is not actually stored on the Apple keychain.
So it's all just in a preference file.
So if you just look at your iOS backups,
you can just pull keys for these things if you want.
But they've done a couple things correctly.
For the most part, they've been fairly responsive.
Their application does use certificate pinning,
which is pretty good.
And their protocol makes use of nuances.
And this is important because they use CBC
in the mode for their encryption.
And if you know cryptography and AES,
you'll know that with CBC,
if you're using AES, you'll know that with CBC,
if you're using an all-IB like they are,
you can have repeat messages
that can disclose what someone's doing.
So the use of nuances is important.
Additionally, they don't just rely
on the Bluetooth low-energies security mechanisms.
They built in their own.
So this brings me to my real point,
which is why we need hackers,
why we need security researchers.
Because the security claims that vendors are making
can't be validated by consumers.
Consumers lack the expertise,
necessary to determine if these claims are valid.
So they have to take the manufacturer's word for it.
And what can be asserted without proof
can also be dismissed without proof.
And if a vendor isn't providing evidence
of the claims of the security of their device,
then we should assume that there is no security in that device.
So that's, got through that pretty quick.
So I will actually take questions.
There's a microphone in the front,
if anyone has any.
That was really amazing.
Thank you.
I do have one burning question.
Yes.
How did you get the password
that allowed you to get into the debug mode
of the application?
Sure.
So there's a couple ways you could do it.
You could look at the iOS application
and try to get the IPK off the phone.
Initially tried doing that
and reversing iOS apps is a little difficult.
So I just download the Android app
and then it's obvious.
Hi, my name is David Rogers.
I'm from the IoT Security Foundation.
So fantastic work.
We've seen this all over the place.
And particularly in consumer products that are going out.
So this is an open invitation really to yourself
and to everyone in this room.
We're reaching out to people to come and help us
because this stuff is absolutely shocking.
You know, we've been through this in the mobile industry.
We've fixed it time and again.
As you mentioned, all the stuff for the iOS apps,
you know, some of these consumer products companies
have never done anything like this before
or they're creating minimal viable products.
And selling this stuff for crazy prices.
So let's just kind of stop it now
and come and help us.
IoT Security Foundation.
Thank you.
How much were these and can I get some?
Because I want to play with them.
Of the smart locks?
Yes.
So you can pick them up on eBay
for maybe $150, the original version.
Outstanding.
If you want their latest revision,
which most of this stuff still works on,
you can get those for about $200, $220 new.
And then obviously, again, look at eBay.
If you're researching security,
a block doesn't really matter, so buy it off of eBay.
The other question was,
did they fix anything in the app?
Or, you know, if I go buy or download the app right now,
did they fix anything in it?
Or can you provide the unpatched version
so we can play with it?
If you just download the...
The iOS app today, you can still unlock that debug menu.
And so the question was whether it was patched or not.
So one of the key things here is the firmware side of it, right?
Because we're using...
We're interacting with the lock directly from the computer here.
So one of the important things,
and it's on the debug menu there.
Let me show you it.
Oh, and thank you.
Is this disable over-the-air updates.
This is a really good feature if you want to look at these.
And I recommend...
If you buy one, get it with factory firmware
and check that box immediately.
You can also check it by modifying your iOS backups.
But the reason why I want to check that is
there's a UART on the device,
and the factory firmware logs to UART,
and every revision thereafter doesn't.
So keeping it at the stock firmware will give you a way in.
Additionally, I'll be publishing all the code for this
so that you can work with that as a base,
and that'll get you connected.
So if you're connected to the lock,
it'll take care of these security mechanisms,
and it should let you do some of the basic stuff yourself.
You can also use that to write an application
that doesn't have the logging of when you open and close your lock
if you care about your privacy.
I don't know if I missed it,
but was your future access to it
because you rested that key zero, that firmware key,
from the lock, and you said that was per lock?
And have you seen an ability to change that key zero at all?
I have the ability to change it.
I don't recommend people change it because it's high risk.
You can brick a device by changing that key.
If you change it to something,
and you change it to a value you forget,
or you mess up while you're changing it
and it ends up in some intermediate state,
you end up in a world of hurt
because that firmware key is the only one that can enroll new keys.
So it's a fairly high-risk key to change.
So the code I'll be publishing has a safety check in it,
so by default it's not going to let you do that,
but it also has the ability to bypass that safety check
so you can replace it.
If you do replace that key,
their application will stop to work on your device.
For what was involved in the back door I was showing,
what's actually happening is I'm inserting this key,
the one up on the screen, which no one can read,
into key slot 200.
And the reason I'm putting in key slot 200
is because the mobile application,
starts putting offline keys at key slot 1,
and if you get their keypad device,
it starts putting offline keys at key slot 255.
So any number in the middle
is going to survive for quite some time.
So this is actually using a different mechanism
to maintain access.
So even if they rotate firmware keys on reset,
unless they clear all offline keys,
this would still work.
Thank you.
I have two questions.
So the first one,
you showed that you had a modified firmware loaded
on the thing.
Did you do anything with that,
or was it just to show that they weren't signing it?
So in that one,
the only modification is actually the changing
of the version number.
Because the goal was just to show that you can put
custom firmware on it.
I didn't write a custom firmware to do anything interesting.
But obviously you could.
Right.
So the other question is,
as far as I could tell from following your kind of narrative
of the whole thing,
if I were just walking around with light blue
and I saw an object,
an August smart lock,
none of the phones that you had would be able to open it.
I would have had to already either bought it from somebody else
and all that stuff,
or given it to somebody else,
or I'd have to already have guest access and then upgrade.
Right.
So everything I've shown here will get you from guest
to permanent access or near permanent access.
The only one that didn't require any authorization
was notification of when the lock is unlocked or locked.
But in that scenario,
you do need to know the owner's phone number
or their email address.
And if you see the lock on their door,
it broadcasts the ID.
In the light blue application,
you can pull the lock ID off of it.
And that's how it's identified in the system.
And that remains the same,
no matter how many times it's reset.
Cool. Thank you.
So that's my talk.
The final I'll give you is,
if you want to play with the locks at all,
Best Buy is a great place.
Most of the locks at Best Buy
aren't actually paired with anything.
You can use them to access your account.
If you walk in, they have an August demo booth.
Just fire up the August application
and associate with your account,
and it'll give you something you can play with on their APIs.
One last question.
Was there any indication that maybe the AES key
was actually derived from the serial number?
I don't have any evidence of that.
I don't know how it's generated.
I'm assuming it's random
and it's probably using the same mechanism
they used to generate offline keys.
I also don't think it's generated from the serial number
because you used to be able to enroll non-existent locks
in their APIs.
And for those ones, it wouldn't hand you a key back.
So there's probably a database somewhere
that has a table joining the lock ID
and then the offline key that's the firmware key.
Great.
If you want to play with this,
the IoT Village has a lock, a smart lock there.
I'll be publishing this immediately hereafter
and providing a link on Twitter
so you can take it over there and mess with their lock.