Here's some more in-depth information on the architecture of Lockbox: https://lockbox.firefox.com/architecture/
I was the architect for a solution solving a similar problem some years ago, and then, as apparently now, the key derivation scheme appears to be a bit of a shell game. Was just reading this and trying to get a picture of how someone could reason about trusting it. This doc specifies four symmetric keys, where two are used for encryption, and two are used as salts.
The salts are derivations, which are hashes from data elements
So simply, we have:
FxA credentials: a string or blob to be determined.
f: some function tbd
k_pre: a bootstrapping scheme initialization key.
k_enc: keystore key.
k_salt: a user-bound diversification component
k_item: a key to encrypt an item within the encrypted container, or "lockbox"
Some definitions:
k_pre :=(f(FxA))
k_enc := (f(k_pre))
k_salt := KDF(k_pre, userid, infostring, length)
item := KDF(k_salt, k_enc)
Question is, what is FxA? Best thing could be is an HSM key with a user-bound diversification component, with some kind of secure provisioning protocol to get it into the device, but from what I can tell from the docs, there are still some exercises for the reader.
What wasn't clear on first reading from the architecture was the protocol they use between where the lockbox is stored, and where its components are used. When I did this, we used a variation of OCRA to prove possession of correct keys and their versions and release verifications for "items," (attributes).
The next useful documentation step would describe a sequence like:
A -> B: init msg
B -> A: challenge
A -> B: (userid, key version, HMAC(k_pre, challenge))
B -> B: derives k_pre(userid)+ HMAC, validates
B -> A: challenge'
A -> B: etc...
Not to be a pedant about this stuff, but to be able to reason about the things we can trust it for, there are some things we can't be handwavy about.