0
$\begingroup$

Consider the following implementation:

Bob wants to communicate long-term with his team over an unsecured channel. Bob and all members of the team generate individual public/private keypairs (ex. RSA) and store/share their public keys on an untrusted key server.

Bob, being the first member of the team, also generates a long-term random symmetric key for the team that he and all team members will use to encrypt their communications. Bob encrypts the team's symmetric key with his public key and also the public key of all current members of the team and stores them on the same untrusted key server.

When new members are added to the team, Bob (or any existing member of the team that can add new members) takes his own encrypted version of the team's symmetric key from the key server, decrypts it with his private key, then copies and re-encrypts it with the new member's public key, storing it back on the key server for the new member to use for future communications with the team.

The problem with this implementation is that the symmetric key can be forged by Eve, a bad actor with access to modify the key server. Since public keys are all available, Eve could take Bob's (or any and all members of the team) public key and encrypt a new symmetric key on the key server. Past communications would then fail to decrypt, however, if gone unnoticed by the team any future communications could be read by Eve. If the forgery occurred when the symmetric key was first stored, no member of the team would ever know that Eve has been reading their communications.

I think that we need some sort of signature on the symmetric key exchange, however, where would the key material for this signature come from? How could we produce a signature in a way that each member of the team could privately verify that their version of the team's symmetric key is authentic? Maybe some other way?


Update #1

One solution could be for Bob to compute a hash of the symmetric key whenever he first generates it, then sign the hash with his private key and store it on the key server. Whenever members retrieve their copy of the symmetric key from the key server, they could also obtain Bob's public key, verify the hash's signature and recompute the hash to verify the symmetric key.

However, the problem I see with this solution is that it seems Eve could still forge a new symmetric key, sign it with her private key, and replace Bob's public key with hers on the key server. This would allow her to impersonate Bob's signature while other team members verify and use the forged symmetric key.

$\endgroup$
  • $\begingroup$ As is, Eve can obtain the key if she can access the server before and after "Bob encrypts the team's symmetric key with..the public key of all current members and stores them on the same untrusted key server": before, Eve replaces the public key of team member Alice by one Eve generated; after, Eve uses the corresponding private key to decipher the key from the cryptogram prepared by Bob for Alice. Eve can even return Alice's public key to the original state, and re-encipher the symmetric key with Alice's public key so that Alice will be able to use the compromised symmetric key. $\endgroup$ – fgrieu Jun 16 '17 at 12:47
1
$\begingroup$

Your scenario seems overly simplified but anyway:

Just have Bob sign the key that he uploads.

You're assuming that people know each other's public keys anyway. So everybody can verify that the key has been signed by Bob.

If you want to keep your one-to-one trust structure the people adding new team members could also sign the key again or just sign that they trust Bob.

$\endgroup$
  • $\begingroup$ What if Bob leaves the team at a later date and his public key is no longer available for others to verify with? I guess that before Bob leaves someone else would have to become the new signing authority for each member's symmetric key? $\endgroup$ – izzle Jun 16 '17 at 12:51
  • $\begingroup$ Additionally, couldn't Eve still forge a new symmetric key that she signs with her own private key and then replace Bob's public key on the key server with hers? $\endgroup$ – izzle Jun 16 '17 at 13:14
  • $\begingroup$ Yeah, both of those points are valid but also treatable. That's why I'm saying the scenario is overly simplified. $\endgroup$ – Elias Jun 16 '17 at 23:52
0
$\begingroup$

I think it's helpful to analyze the social problem here as well: because any member of the team can incorporate a new member, it makes it inherently difficult for the team as a whole to verify whether the new symmetric key that was uploaded is authentic. Because Eve has access to everyone's public key, she can masquerade as a team member and in order for the team to discover the intrusion, they'd need to ask every member whether they incorporated a new member. This leaves me with two takeaways:

1) Make it so that only Bob can add new members. This makes it simple to detect an imposter but it takes for granted Bob is always vigilant and accessible, so it's not ideal.

2) If Alice (or any team member) wants to incorporate a new member, she generates an independent symmetric key, which she encrypts with her private key such that it can be decrypted with her public key. She broadcasts that to the team, which ensures this key was truly generated by her. She then gives that symmetric key to Tom, who encrypts it with his private key. Members of the team can decrypt using his public key and verify Alice gave Tom the symmetric key (i.e. permission to join the group). After this point, the independent symmetric key can be disregarded and the original team symmetric key can be re-encrypted with everyone's (including Tom's) public keys.

$\endgroup$
  • $\begingroup$ ref #2: I am having a hard time following the method you are describing and how it helps to provide authenticity of the team's symmetric key. Can you explain a bit more the reasoning for that strategy? What is the point of the "independent symmetric key" that is being passed around? Why is it being encrypted with private keys and decrypted with public keys? It sounds like it is being used as a signature in some way? $\endgroup$ – izzle Jun 16 '17 at 16:47
  • $\begingroup$ I'm now realizing that my method doesn't solve the problem, so I won't re-explain (unless you want me to). But, what if Alice, a team member, just signs Tom's (new team member) public key with her private key and broadcasts it to the group? This way everyone knows Tom's public key and because Alice signed it with her private key it signals she approves the addition? $\endgroup$ – J. Behnken Jun 16 '17 at 17:09
  • $\begingroup$ The problem at hand isn't necessarily with approving a new member of the team. The problem is that the team member's keys are stored on a key server that cannot be fully trusted and could potentially be tampered with. Therefore, any time a team member needs to use their version of the team's symmetric key or any other member of team's public key he needs to be able to verify that the key has not been tampered with. $\endgroup$ – izzle Jun 16 '17 at 17:43
  • $\begingroup$ I understand your point. I feel as though new member addition is the heart of the problem though because if the number of team members and identities are to remain constant, tampering with the server would become evident by any addition whatsoever. So doesn't the question then become: when a change occurs, how can we validate it? $\endgroup$ – J. Behnken Jun 16 '17 at 17:53
  • $\begingroup$ Yes, you are correct. I attempted to solve this with the solution posted in "Update #1", however, that only verifies and symmetric key leaving the public key used for that verification still at risk. $\endgroup$ – izzle Jun 16 '17 at 18:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.