Confirmed users
358
edits
Services/Sync/KeyRecovery: Difference between revisions
no edit summary
(Created page with "{{draft}} = Goal = To securely allow a user to recover their sync key, using only the username and password for their Mozilla Services account. = Overview = Currently the syn...") |
No edit summary |
||
| Line 30: | Line 30: | ||
In initial discussions we've been calling this a "key escrow service", but to me (rfkelly) that conjures up too many big-brother clipper-chip-style associations. Since the idea is that Mozilla won't be able to obtain your sync key even if you enable this service, I think "key recovery service" has more accurate connotations. Thoughts? | In initial discussions we've been calling this a "key escrow service", but to me (rfkelly) that conjures up too many big-brother clipper-chip-style associations. Since the idea is that Mozilla won't be able to obtain your sync key even if you enable this service, I think "key recovery service" has more accurate connotations. Thoughts? | ||
== Key Encryption == | |||
Before uploading to the service, the client encrypts the sync key using its existing standard encryption routines. The encryption key is derived from the username and password using PBKDF2. Details follow. | |||
To encrypt the sync key for storage in the recovery service, the client uses PBKDF2 to derive an appropriate encryption key from the user's account username and password: | |||
salt = get_random_bytes(16) | |||
enc_key = PBKDF2(username + password, salt, 4096, 32) | |||
This is then used to encrypt the sync key via AES-256, with a random IV and HMAC256: | |||
IV = get_random_bytes(32) | |||
ciphertext = AES-256(enc_key, IV, sync_ke) | |||
hmac = HMAC256(enc_key, ciphertext) | |||
The details necessary to decrypt the sync key are serialized into a JSON structure, which is sent to the key recovery service for storage: | |||
{ | |||
// Parameters for key derivation, as used by deriveKeyFromPassphrase | |||
"salt": "b64-encoded salt", | |||
// Encrypted payload, same format as CryptoWrapper WBO output | |||
"ciphertext": "b64-encoded ciphertext", | |||
"IV": "b64-encoded IV", | |||
"hmac": "hex-encoded hmac", | |||
} | |||
Open questions: | |||
* is there something better than PBKDF2 for this purpose? | |||
* should be include the number of iterations in the stored PBKDF2 parameters? Someday we might want to increase it. | |||
* should we mix the HMAC_INPUT string into the PBKDF2 inputs? | |||
== Server Protocol == | == Server Protocol == | ||
Since the server component is intended to run from a high-security restricted-access environment, it is designed to be as simple and light-weight as possible. In particular, it will offload responsibility for authentication to a separate service. | |||
== Client Protocol == | == Client Protocol == | ||