(was out on PTO, sorry I missed this last week)
On 4/15/14 2:33 PM, J. Ryan Stinnett wrote:
> As part of my work on the App Developer Tools team, I'm adding support
> to Firefox OS to allow devices to be debugged over a WiFi connection to
> improve developer UX.
Cool project. I'd go with your suggestion of some sort of shared secret
delivered by QR code, rather than an FxA thing. The desktop/debugger
displays a code, the phone/debugee (in some kind of "Enable Remote
Debugging" menu) scans it, then the phone has a list of which debuggers
are allowed to connect, one per scanned code, and you can remove things
from the list later.
> 1. Does this seem like a reasonable use case for Firefox Accounts?
Eh, not especially, but if the use case called for remote debugging
(e.g. your left your phone on your desk at work, and you want to
spontaneously debug it from your desktop at home), then maybe :). QR
codes give a "you must have physical access to enable debugging" model,
which feels more correct to me. Just like plug-in-a-wire-to-debug, but
without the annoying wire.
> 2. I am not sure what authenticating two FxA signed-in devices to each
> other would look like in detail. Is there prior work in this area that
> can be used for this purpose? Something from Sync perhaps?
So, FxA gives you two things: proof of account ownership (in the form of
a Persona-style signed assertion) and some encryption keys. Any device
which logs into the same account will get the same master keys. From
these, we derive different keys for different purposes (so revealing one
of them doesn't threaten the secrecy of the others). Sync uses one of
those derived keys to encrypt the uploaded bookmarks/tabs/etc.
So if I had to use FxA for this purpose, I'd define an "FxOS-Debugging"
derivative encryption key and use it as the shared secret. Logging into
the same FxA on both sides would be enough to derive the same key.
(we have two separate categories of keys: one called "kA" which remains
constant despite account resets, and a second called "kB" which is tied
to the password. Whether you use kA["FxOS-Debugging"] or
kB["FxOS-Debugging"] depends upon whether you want your debugging
authorizations to survive changing the account password, or whether you
want to prevent a compromised FxA auth server from getting debugging
access.. probably the latter)
You could also get a signed assertion on both sides, and include a TLS
session identifier in the assertion ("the owner of FxA account Foo is
willing to be a debugger over TLS session Bar", plus another for the
debugee), but I don't think most TLS APIs give you access to the session
id.
In any case, the lack of TLS identities to work with (no PKI) makes it
tricky to convert a shared secret into a secure session. TLS-SRP is an
option, if there's some way to tell the other side which secret you're
going to use ahead of time (I haven't looked at the TLS-SRP API, but if
it basically takes username+password, then you could use one hash of the
shared secret as username, and a different hash as password).
You could also create ephemeral TLS certs, establish the TLS session,
then HMAC the certs with the shared secret and send the MACs through the
new connection: a MitM could intercept/modify those messages, but
couldn't forge the MACs. You need a full-size shared secret for this to
be safe, though.
You might have to give up on TLS and use your own encrypted transport
instead. NaCl's symmetric "crypto_secretbox()" function should be
enough, but you can get fancier (which also might make it easier to
prevent replay attacks).
Hope you find that useful.. I'd love to help out. Grab me off-list if
you'd like to chat more.
cheers,
-Brian
_______________________________________________
Dev-fxacct mailing list
[email protected]
https://mail.mozilla.org/listinfo/dev-fxacct
