View source for Security/Reviews/token crypto Android

{{SecReviewInfo
|SecReview name=Token Server Client & Java BrowserID crypto library for Android services projects
|SecReview target=Key server protocol describing client-side key stretching and how to talk to the Fx Account server:
https://wiki.mozilla.org/Identity/AttachedServices/KeyServerProtocol
<bugzilla>
{
"id":"935671,935707"
}
</bugzilla>
HTTP Client for interacting with FxAccount server: (getting a signed Browser ID certificate)
<bugzilla>
{ 
"id":"892025"
}
</bugzilla>
Code for generating HAWK Authorization: headers
<bugzilla>
{
"id":"903123"
}
</bugzilla>
Code that actually authenticates to new Sync storage endpoints with tokens
<bugzilla>
{
"id":"918012"
}
</bugzilla>
This ticket will cover exposing a username/password sign up/sign in flow of some sort.
<bugzilla>
{
"id":"899217"
}
</bugzilla>
}}
{{SecReview
|SecReview feature goal=These  tickets are all part of gluing the Fx Accounts sign up/log in flow on  top of Android Sync.  The use case is that a user wants to create a new  account, or sign in to an existing account with an email address and  password.  Once we have things derived from the email/password pair, we  need to shuffle various access tokens around.  These tickets do that  shuffling.
|SecReview alt solutions=I  guess we investigated about a billion different variations on  email/password, including Sync-style pairing and lots of client-side key  stretching schemes.  We settled on a PBKDF2 + Scrypt + PBKDF2  sandwich.  Brian Warner (warner) is a better reference for what was  considered.
But  these tickets don't dig into the meat of the client-side key  stretching; they assume you get the tokens from somewhere and shuffle.
|SecReview solution chosen=This  is almost exactly the token server dance that was intended for Sync 2.0  before Fx Accounts was a thing.  There's just not many ways to dance  this dance.  I suppose you could ask why a Browser ID assertion instead  of, say, just HAWK credentials.  It decouples the auth server and the  storage servers by introducing a token server in the middle.  This  should help third parties stand up Fx Account-authenticated endpoints.
I'll  further interpret this to mean, technically, "Why are we doing this in  Java?"  We do this in Java because Gecko is  not running when we Sync.   End of story.  Loading Gecko to do this work is not feasible.
|SecReview threats considered=Lots.   The whole token server dance and cryptography has been analyzed, mostly  by ckarlof and warner, on a whole range of facets.  I'd like to focus  this on the actual implementation of the dance to make sure I haven't  done something foolish.  We have considered the Android SecureRandom  random issue https://bugzilla.mozilla.org/show_bug.cgi?id=903907 but don't think it will affect us.  (My memory here is hazy.)
}}
{{SecReviewActionStatus
|SecReview action item status=In Progress
|SecReview action items=nalexander :: try to find diagram showing token flows through servers and clients for dchan :: Friday, 22 November
dchan :: reach out to platform / fxos teams for their implementations of this dance :: Friday, 22 November
yvan :: schedule Fx Accounts sec-review for protocol :: Friday 22, November
}}