1040315 - use FxA "kA" to encrypt/authenticate FMD requests

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: FindMyDevice, enhancement)

Description

[Brian Warner [:warner :bwarner]]

In bug 1036393, freddyb suggested improvements to limit the damage of a
compromised FMD server. With the current design, a compromise could quietly
track every device which had FMD enabled, or erase all of them at the same
time. He and I were discussing a more end-to-end approach to improve on that.

Firefox Accounts provide, in addition to assertions of account control, two
categories of secret keys. "Class A" keys are available to the
fxa-auth-server, and to users who can convince this server that they control
the account, either by proving they know the current account password, or by
responding to an email challenge. "Class B" keys are only available to users
who know the password: the fxa-auth-server does not know the class B key, and
users who forget their password will not be able to access the Class-B keys.

For each class, the FxA client manages a master key (kA or kB), and produces
derivatives for various domains and purposes (using the HKDF algorithm). Sync
uses a sync-specific kB derivative to encrypt Sync data.

For FindMyDevice, we could use a FMD-specific kB derivative to sign
browser->server->device requests (like "please tell me your location", or
"please erase yourself"). This would prevent a compromised FMD server from
e.g. tracking all FMD-enabled devices, or mass-erasing all of them. The idea
is to make the device skeptical of the server, and only honor requests if
they were actually made by the user. The server is necessary to relay these
requests, but isn't the one creating them.

Each request would be individually signed by the FMD web page, running on the
browser (desktop/laptop/etc) where the user is trying to locate their lost
device. They must first sign into an FxA account (with their password), and
thus get access to the kB derivative for the FMD server domain. The request
would be forwarded through the FMD server to the device (stored briefly on
the server while the SimplePush notification is delivered and the device
checks in to fetch the request).

Then the device would ask the OS for the same kB derivative, and verify the
signature (probably an HMAC) before honoring the request.

We could even encrypt the location data with a similar derivative key, so the
FMD server wouldn't learn the device location directly. (the web page that it
serves to the user's browser would learn it, of course, but passive
observation of the FMD server wouldn't enable surveillance. Also the maps
server can tell which map tiles you fetch. But every little bit helps).

We could also do this with a kA derivative instead of kB. This would add the
usability feature that users who forgot their FxA password could still use
FMD, by first resetting their FxA account. But it would add the vulnerability
that a compromised fxa-auth-server (or compromised user email account) would
be able to make FMD actions. Note that the reliance set excludes the FMD
server even if we use kA: only a compromise of the fxa-auth-server would leak
the kA key. This is the pattern we want to push with FxA in general:
concentrate the security on the fxa-auth-server where we can focus our
defensive resources.

It might be appropriate to give the user an option during FMD signup:
"Protect your device location and remote-wipe control with your FxA
password?". We were considering this choice for Sync, before deciding that
the UX was too hard and simply made kB the default, but FMD could be a
different situation.

To build this, we'd need to enhance the FxOS FxA API (navigator.mozId) to
include domain-specific derived keys. We'd also need to provide similar
web-content APIs for the browser side, something we've discussed a lot
(https://wiki.mozilla.org/Identity/CryptoIdeas/02-Recoverable-Keywrapping ,
https://wiki.mozilla.org/Identity/CryptoIdeas/03-ID-Attached-Data) but
haven't specced out yet.

Comment 2

[JR Conlin [:jrconlin,:jconlin]]

Does this value change when a user changes their password? If so, it may not be suitable for this product.

A user may create an account weeks, months or years before they require this service. Unless they're required to enter their password frequently, they will undoubtedly forget what it is when they're stressed already about having lost their device.

Comment 3

[Brian Warner [:warner :bwarner]]

Nope, kA and kB remain constant over password *changes* (where you enter both old and new passwords to change it). Over password *resets*, however, (where you don't remember the old one), kB is replaced with a new random value (kA remains the same).

But yeah, I agree that remembering an infrequently-used password will be one of the least desirable tasks when somebody has just had their phone stolen or lost.

Hm, this would be a good place for "social auth": you can mark friends (via their address book entries) as the ones who can find out where your phone is, and their devices get a copy of the special reveal-your-location token.

Comment 4

[JR Conlin [:jrconlin,:jconlin]]

I'm sure I could make a joke here about "Nobody ever expects to marry their pending ex-spouse".

I do agree that there's a lot of room here to do something fairly clever and help out the user while keeping things secure. Maybe there's a way we can entice the user to enter their password more frequently so they remember it. (heh, "Enter your password correctly in our Pop Quiz and get a free sticker!" How could that possibly be abused?)

Comment 5

[Frederik Braun [:freddy]]

[Blocking Requested - why for this release]:
I think we can do a lot better for FMD and I had the impression that everybody agreed here.
Can we try to get this in for the next version?

Comment 6

[JR Conlin [:jrconlin,:jconlin]]

freddyb: Are you saying that we should not allow users who have forgotten the password they may have set months ago to be able to recover the device they just lost, or that we should require users to specify a secondary party to whom they entrust access to their device for now and forever? 

I agree that FxB tokens would be splendid to use. Do you have metrics on how often a user enters in their password on their mobile device so that we don't provide a poor experience during a very stressful time?

Comment 7

[Frederik Braun [:freddy]]

No, I am not saying that. Maybe I should have been a bit more wordy:

I think we agreed that reducing the harm a compromised FMD server could do is a good thing. FxA already stores account credentials, so using them provide this benefit: We could argue that an evil FMD server is technically unable to control a user's device. It would also need FxA to collude.

We also discussed that a forgotten key *and* a forgotten device is a likely use case, which we want to *include* in this feature. So the suggestion was to use kA which does *not* change when a user resets their password.

Do you have any additional concerns?

Comment 8

[JR Conlin [:jrconlin,:jconlin]]

Ah, pardon my confusion. Yes, I will see about adding kA encryption. This will also require client work and testing. I am not sure when that can land and be tested due to current staffing constraints, but we can push forward to allow this to be enabled.

Comment 9

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

> [Blocking Requested - why for this release]:
> I think we can do a lot better for FMD and I had the impression that
> everybody agreed here.
> Can we try to get this in for the next version?

I'm not sure that's possible, sadly.

FMD is extremely resource constrained, the product is in the process of being handed off to a new team, 2.1 work is already well underway, and warner's proposals are vague and would require lots of UX time. Altogether, I think we can safely remove the nomination, so I'm doing that now.

As far as getting this into FMD for 2.2 or beyond, it's important to bear in mind that there are many other demands on the schedule, and the benefits of building a stronger cryptosystem may not be worth the cost.

One short-term option to consider: maybe there are server-side security improvements that could be made to reduce the odds of the server being compromised.

FWIW, I read this bug more as a going-away braindump from warner, who recently left Mozilla, rather than a specific task to be undertaken a week or two later.

Paging Vishy to get product input, and Chris Karlof to translate warner's thoughts above to a higher-level cost/benefit statement that non-experts can easily digest.

Comment 10

[Chris Karlof [:ckarlof]]

> maybe there are server-side security improvements that could be made to reduce the odds of the server being compromised

Just a thought: maybe we should be doing that anyway. :)

The design of an end-to-end protocol FMD with authenticated and encrypted messages should be carefully considered, and I would assume is out of scope for 2.1.

Lots of things to figure out:
* how FMD gets access to a kA derivative on the Web and FxOS
* what the client <-> client authenticated protocol looks like, how we version it, and what the error paths look like if you have incompatible clients trying to communicate
* what happens if we need to reset kA for a user, and how clients respond 

A related product question is how these changes might impact the effectiveness of the service vs without them.

Comment 11

[vkrishnamoorthy]

I agree that we should backlog this work and not address it in 2.1

Comment 12

[Gervase Markham [:gerv]]

Cory Doctorow:

"Imagine a user-centric, data-centric, freedom-centric version of this
security measure: all devices would have to be sold with encrypted
filesystems by default, so that users whose phones are lost or stolen
can be sure that their data is intact, that their bank accounts won’t be
raided, that the correspondence with their lawyers and doctors and
lovers won’t be read, that their search history and photos won’t be exposed.

OSes would invite users who were worried about deterring physical theft
to initialize their devices with a secret — a key or passphrase — that
can be entered into a website, which signs it and transmits to the
phone, ordering it to wipe itself down to the BIOS. In that scenario, a
phone could only be bricked if both the customer and the carrier
cooperated."
http://radar.oreilly.com/2015/02/an-internet-of-things-that-do-what-theyre-told.html

I agree with Cory that a user-centric version of FMD would not allow the FMD server to send a remote-wipe command the phone will accept, without the intervention of the user. If this bug is a route to that, that would be great. Using kA would require the FxA server and the FMD server to collude, which seems fairly good proof against hacking but not against subpoena. Using kB would mean Mozilla is unable to wipe your phone, period.

Gerv

Comment 13

[BMO Automation]

Firefox OS is not being worked on