<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Maybe we could build an escrow service that's still in control of the user,<br>
for example by splitting the recovery key using shamir's secret sharing and<br>
assigning each part to a recovery step, with a threshold of 3 to reconstruct<br>
the recovery key.<br>
<br>
That's hard to do in practice, but solutions that doesn't depend on perfect<br>
infrastructure security will make everyone sleep better at night.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>My understanding of their process is:</div><div><br></div><div>* Take the FileVault recovery key.</div><div>* Take three user questions; store them on the server.</div><div>* 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.</div><div>* Encrypt the recovery key with kR.</div><div>* Store the result on the server.</div><div>* Throw away kR.</div></div><br></div><div class="gmail_extra">Recovery is:</div><div class="gmail_extra"><br></div><div class="gmail_extra">* Identify as the user.</div><div class="gmail_extra">* Retrieve the questions.</div><div class="gmail_extra">* Solicit the answers and collect other fixed inputs (e.g., disk ID).</div><div class="gmail_extra">* Compute and validate kR.</div><div class="gmail_extra">* Request the encrypted recovery key.</div><div class="gmail_extra">* Decrypt it with kR.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Presumably you would rate-limit requests for keys, require some form of auth (AppleID) to request keys, scope such requests, and encourage users to enter reasonably entropy-rich answers. But it's not an escrow service in the traditional only-protected-by-the-law sense, so this isn't just layering defense-in-depth on top of "oops".</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">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. The bet is that you'll either remember your password (and can thus derive kB), or you can remember your three secret answers (and thus derive kR).</div><div class="gmail_extra"><br></div><div class="gmail_extra">Very security-sensitive users will probably opt to not use escrow, or will enter high-entropy strings instead of "Ambulance Driver" :)</div></div>