On 23/08/2016 10:17, Richard Newman wrote: > Maybe we could build an escrow service that's still in control of > the user, > for example by splitting the recovery key using shamir's secret > sharing and > assigning each part to a recovery step, with a threshold of 3 to > reconstruct > the recovery key. > > That's hard to do in practice, but solutions that doesn't depend on > perfect > infrastructure security will make everyone sleep better at night. > > If I understand you correctly, that's what I'm suggesting; Apple's > recovery service isn't able to access the key itself without the user's > secret answers. > > My understanding of their process is: > > * Take the FileVault recovery key. > * Take three user questions; store them on the server. > * Take three user answers. Stretch them into a key, kR, presumably with > a salt (stored) and associated with the user or device in some way. > FileVault is associated with a particular disk and probably with some > other particular hardware components, so there are other reproducible > inputs here. > * Encrypt the recovery key with kR. > * Store the result on the server. > * Throw away kR. > > Recovery is: > > * Identify as the user. > * Retrieve the questions. > * Solicit the answers and collect other fixed inputs (e.g., disk ID). > * Compute and validate kR. > * Request the encrypted recovery key. > * Decrypt it with kR. > > > In a sense, this is exactly what we do for `crypto/keys` on the Sync > server: we store the keys that you use to decrypt Sync records, and we > store them wrapped by kB, which is a key derived from a secret you know.
It's also basically how we store kB. It's not derived directly from your password, it's a fully-entropy key that's wrapped with a key derived from your password for storage. Ryan _______________________________________________ Sync-dev mailing list Sync-dev@mozilla.org https://mail.mozilla.org/listinfo/sync-dev
