Confirmed users
471
edits
Identity/AttachedServices/KeyServerProtocol: Difference between revisions
Jump to navigation
Jump to search
m
Identity/AttachedServices/KeyServerProtocol (view source)
Revision as of 18:38, 12 July 2013
, 12 July 2013→Login: /session/auth
| Line 42: | Line 42: | ||
To connect a browser to an existing account, we use the following login protocol to transform an email+password pair into (keyFetchToken, sessionToken). These tokens will be used in the next section to obtain encryption keys and signed certificates. | To connect a browser to an existing account, we use the following login protocol to transform an email+password pair into (keyFetchToken, sessionToken). These tokens will be used in the next section to obtain encryption keys and signed certificates. | ||
This protocol starts by using key-stretching to transform the email+password into a "stretchedPW", then feeds this into an SRP protocol to get a session key. It uses this session key to decrypt a bundle of encrypted data from the keyserver, resulting in three values: kA, wrap(kB), and the | This protocol starts by using key-stretching to transform the email+password into a "stretchedPW", then feeds this into an SRP protocol to get a session key. It uses this session key to decrypt a bundle of encrypted data from the keyserver, resulting in three values: kA, wrap(kB), and the sessionToken. The stretchedPW is also used to derive the key that will decrypt wrap(kB) into the actual kB value. | ||
[[File:PICL-IdPAuth-bigpix.png|IdP Auth Big Picture]] | [[File:PICL-IdPAuth-bigpix.png|IdP Auth Big Picture]] | ||
| Line 48: | Line 48: | ||
This same protocol is used, with slightly different methods and constants, to obtain the "accountResetToken". This token allows a client to safely reset the account password. | This same protocol is used, with slightly different methods and constants, to obtain the "accountResetToken". This token allows a client to safely reset the account password. | ||
The protocol is optimized to minimize round-trips and to enable parallelism, to reduce the time it takes to connect a browser to the account to just a few seconds. As a result, the two messages it sends (/session/auth/start and /session/auth/finish) each perform multiple jobs. | The protocol is optimized to minimize round-trips and to enable parallelism, to reduce the time it takes to connect a browser to the account to just a few seconds. As a result, the two messages it sends (/session/auth/start and /session/auth/finish) each perform multiple jobs. In total, the browser requires four messages in three roundtrips (1: auth/start, 2: auth/finish, 3: account/keys and certificate/sign) before it is ready to talk to the storage server. | ||
== auth/start == | == auth/start == | ||