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.
Duplicate of this bug: 1036393
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.
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.
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?)
[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?
blocking-b2g: --- → 2.1?
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?
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?
Summary: use FxA "kB" to encrypt/authenticate FMD requests → use FxA "kA" to encrypt/authenticate FMD requests
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.
> [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.
blocking-b2g: 2.1? → ---
> 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.
I agree that we should backlog this work and not address it in 2.1
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
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 5 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.