(This is probably a question for @jpgoldberg, as he's answered similarly detailed questions in the past....)
I've been trying to assess the risks presented by 1Password on a badly compromised system. In particular, I'm trying to determine just what can be done if someone's installed a keylogger that was able to get the user's Master Password.
Unfortunately, the Security Design Whitepaper still has a lot of holes in it, and the deeper I dig into that (and vaults on Windows and macOS), the more questions I have.
I'm very much in a "Trust, but Verify" mode -- I have (and will continue to) recommended 1Password without reservations, but when someone asks me for technical details, with very specific scenarios in mind...I like to be able see the validity of my responses with my own eyes...
I understand vaguely what the 1Password keylogging protections entail, but more clarity there would definitely be helpful.
More client-level detail would be INCREDIBLY helpful. I'd like to be able to directly demonstrate the key derivation steps, and vault decryption, to demonstrate that the system is behaving the way we expect.
A post from September 2016 (https://discussions.agilebits.com/discussion/69566/white-paper-clarifications) helped with this somewhat, but not completely. Like, for example, where is the MUK-salt (I can't remember exactly what you call it) stored? Where is the Secret Key stored? And how is the secret part of the secret key thrown into the derivation mix? (like, as an ascii string, or converted somehow to binary via some unusual number base conversion)? Like the participant in that conversation, I'd love to see some test vectors...
As a more specific example, on Windows, I see an "EncryptedMasterKey" in the "config" table (which looks like it may just be raw AES + HMAC). My suspicion is that the 2SKD process (salt, email, Secret Key, and Master Password) is used to decrypt this EMK (I assume this is how it works, but then it might simply be a million rounds of SHA-256 on the ascii text of the entered password....).
It looks like that EMK also decrypts the "enc_login" field in "accounts", which looks (from experimentation, since I can't yet decrypt it personally) like it must contain the Secret Key and the text of the Master Password. This is logically required so that the app can directly authenticate to the server for multiple team / family accounts.
I've assumed that this EMK also directly decrypts the "mp" in keysets, which then decrypts the private keys, and from that the vaults, etc... Though it may be possible that the EMK only decrypts enc_login, and then the key derivation process is run again for every account using the data pulled out of enc_login. (in fact, experimentation on Windows shows that this may be the case -- breaking the emc_login string by mucking with the raw B64 caused the initial app login to work, but then it couldn't read any items, and I had to sign-in again.) (and it didn't pre-fill the secret key field either).
Through further experimentation on Windows, I'm also wondering where the key derivation process gets the user's email address from -- because even when I changed it in the accounts table, authentication still worked.
Somewhere, there must be a structure that includes Salt, Secret Key, and Email, as used by the client to unlock the whole system (it seems to reset that to whatever the current "first" account is, so if I set up with team A, add team B, then later delete team A, it'll seamlessly shift to using Team B's password to unlock the app). The security of the entire system (assuming a keylogged password) depends on how much of a pain it is to retrieve that data.
I have very similar questions for macOS. The enc_login field looks very different in structure (but probably identical in usage), but I don't see the EncryptedMasterKey field anywhere.
In a comment here (https://discussions.agilebits.com/discussion/comment/385433#Comment_385433) JP says that "the 'local' data store Key Derivation Function hasn't been updated as it should have been." Or is it possible that the EncryptedMasterKey" on windows isn't actually dependent upon the 2SKD process? Has that since been fixed (or is the fix coming in version 7)?
Obviously, a lot of this may change with version 7. (and I really love that you're using the Secure Enclave private key service, too. Is there any reason you couldn't use that to encrypt the local copy of the Secret Key too?)
Ultimately, everything boils down to this:
How strong are the keylogging protections on Windows and macOS?
Assuming an attacker bypasses those protections, how easy is it to extract Secret Key, Email, and Salt (the other items required for the key derivation)? (for the moment, I'm ignoring whether the user has logged in via the web...the Secret Key is trivial to pull from browser Local Storage).
Assuming they get all that, how much of a pain in the neck is it for the attacker to then begin decrypting things? (I suspect "not easy" but also suspect that a determined attacker could work it out in a few days) (if a tool isn't already on GitHub).
We're currently working on adding 1Password MFA support internally, so that a compromise of Secret Key and Master Password can't simply be rolled into an attacker logging in through his own web browser. That's a huge step forward, but the "being able to 'simply' decrypt the local vault" is still a big question mark for us, risk-wise. Having the admin immediately mark the user as "on travel" (to remove the vaults) is an additional good step, provided the compromised system is still attached to the network and the attacker hasn't already copied the data.
I greatly appreciate everything AgileBits does to make this product as open and as transparent as possible, but I really wish you could clarify bits of the White Paper (and fill in the many gaps which remain). I'm struggling to explain the whole system at a deep, "here's exactly how it works" level. But every time I think I've got a good diagram of the system (and it's multiple pages already), I run across a forum post or database entry that throws my understanding into doubt.
(has anyone done a talk on exactly how all this works? I've given a similar talk for iOS encryption...and am really thinking this'd be a fun thing to do...but then I'm kinda weird.)
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided