Confirmed users
471
edits
Identity/AttachedServices/Architecture: Difference between revisions
Identity/AttachedServices/Architecture (view source)
Revision as of 04:53, 3 July 2013
, 3 July 2013→Sign-Up / Sign-In
| Line 31: | Line 31: | ||
Attaching a profile to an account is called "Sign In To The Browser". The UI for this is still under discussion, but will involve the user typing an email address and a password into chrome browser UI (for both new-account creation and signing into an existing account, as well as password reset). This password will be stretched on the client side (using techniques from [[Identity/CryptoIdeas/01-PBKDF-scrypt]]) and used to generate an "SRP password" and a wrapping key (using techniques from [[Identity/CryptoIdeas/02-Recoverable-Keywrapping]]). | Attaching a profile to an account is called "Sign In To The Browser". The UI for this is still under discussion, but will involve the user typing an email address and a password into chrome browser UI (for both new-account creation and signing into an existing account, as well as password reset). This password will be stretched on the client side (using techniques from [[Identity/CryptoIdeas/01-PBKDF-scrypt]]) and used to generate an "SRP password" and a wrapping key (using techniques from [[Identity/CryptoIdeas/02-Recoverable-Keywrapping]]). | ||
The SRP Password is then used in a protocol ([https://id.etherpad.mozilla.org/picl-idp-protocol | The SRP Password is then used in a protocol (see [[Identity/AttachedServices/KeyServerProtocol]] and the [https://id.etherpad.mozilla.org/picl-idp-protocol picl-idp-protocol etherpad]) to speak with the Key Server . [http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol SRP] is an interactive "zero-knowledge" protocol which gives the participants exactly one chance to show that they agree on a password. The outcome of SRP is a random session key: if the password was correct, both sides will wind up with the same key (otherwise their keys will be different). This session key is used to protect and authenticate some additional messages, which are used to retrieve the class-A and class-B master data-encryption keys, and a "certificate renewal token". This token allows the browser to obtain a signed certificate for a special "PICL Account" identifier (e.g. GUID@picl.persona.org). These certificates will be used for Persona/BrowserID authentication to the storage servers (described [[#Storage_Server_Authorization|below]]). | ||
The class-B master key is encrypted by a derivative of the stretched user password. The master keys are then used to derive per-datatype encryption keys. We use different keys for each datatype so that in the future, we can share e.g. bookmarks with a third party (by telling them the decryption key) without also sharing e.g. stored-passwords. | The class-B master key is encrypted by a derivative of the stretched user password. The master keys are then used to derive per-datatype encryption keys. We use different keys for each datatype so that in the future, we can share e.g. bookmarks with a third party (by telling them the decryption key) without also sharing e.g. stored-passwords. | ||