1Password & the Public Key Directory?
Hello, I'm a 1Password for Teams user and I have a nagging question at the back of my head regarding sharing vault items.
At the simplest level, to share the items in a vault, one merely needs to encrypt the item with the public key of the recipient.
1Password for Teams server never has a copy of the decrypted vault key and so is never in a position to share it. Only someone who has that key can encrypt a copy of it. Thus, an attack on our server could not result in unwanted sharing.
However, the server has all public keys of 1Password for Teams members.
A user’s entry is located using the email address the user provided when signing in and the accounts entry for the matching domain. The user’s entry includes the pub_key eld which is used to encrypt all of the user’s secrets.
When a share is initiated, the client trusts that the public key the server returns is valid, when using it to encrypt the vault key.
My question is, I'm the event that the server is compromised, could the attacker silently send his own public key to clients requesting for a user's public key? That way, the attacker, knowing his own private key, could get access to the unencrypted vault key when his target shares a vault item with anyone.
Comments
-
Hi @1actobacillus!
That is very well spotted!
First a minor correction. An item isn't directly encrypted with the other person's public key, but the key to a vault is what gets encrypted with the public key. But this doesn't change your main question:
I'm the event that the server is compromised, could the attacker silently send his own public key to clients requesting for a user's public key?
Yes. (though there would need to be some other server manipulations as well to get away with this). Our server is kinda sorta operating like a certificate authority in that you must trust that the public keys we distribute actually belong to the individuals we say they belong to.1 And this, there is some mischief that could be done by someone who controls the server. This is a notoriously difficult problem to solve in a way that is both secure and usable. The whole X509 certificate system is an example of how difficult it is.
One of the things we are looking at is doing something similar to what Whisper Systems Signal app does. As an advanced option you can see the key fingerprint of a public key you are using and then confirm with the (putative) owner in some out of band method (outside of the control of Signal) to see if they report the same key fingerprint.
Manually verifying public key fingerprints is notion that goes way back, but trying to make this usable is much harder. And unless you have some trusted third party (acting like a certificate authority), it cannot be automated. At most this can only be some advanced feature that a small portion of users will actually avail themselves of, though all should.
-
We are not actually signing the public keys, so we aren't behaving like a CA in the respect, but we are delivering the public keys, which gives us the same power and involves the same trust relationship. ↩︎
0 -
