Confirm
471
edits
Changes
m
* tokenID* reqHMACkey* respHMACkey* respXORkey The client uses tokenID and reqHMACkey for a HAWK (https://github.com/hueniverse/hawk/) request to the "GET /account/keys" API, using tokenID as "credentials.id" and reqHMACkey as "credentials.key". The server uses tokenID to look up the corresponding token, then derives reqHMACkey to validate the request. The server then pulls kA and wrap(kB) from the account table, concatenates them, encrypts the pair by XORing it with the derived respXORkey, and attaches a MAC generated with respHMACkey.
→Obtaining keys kA and kB
= Obtaining keys kA and kB =
Clients which have successfully proven knowledge of the account password exchanged an authToken for either a sessionToken or an accountResetToken will also receive a keyFetchToken. This single-use token allows the client to retrieve kA and wrap(kB), which enables the client to encrypt and decrypt browser data (bookmarks, open-tabs, etc) correctly. The token As above, the keyFetchToken is used to derive several values:tokenID, reqHMACkey, respHMACkey, and respXORkey, which are used in a HAWK request to the "GET /account/keys" API.
[[File:PICL-IdPAuth-keys-server.png|keyFetchToken: server encrypts keys]]
"kA" and "kB" enable the browser to encrypt/decrypt synchronized data records. They will be used to derive separate encryption and HMAC keys for each data collection (bookmarks, form-fill data, saved-password, open-tabs, etc). This will allow the user to share some data, but not everything, with a third party. The client may intentionally forget kA and kB (only retaining the derived keys) to reduce the power available to someone who steals their device.
Note that /account/keys will not succeed until the account's email address has been verified. Also note that each keyFetchToken is single-useand short-lived.
= Signing Certificates =
