Cryptography
public-key signature pki
Updated Sun, 18 Sep 2022 19:42:54 GMT

Is there any way to (irrevocably) *transfer* a private key to another person?


Let's say that Alice is the administrator of a group. For each message generated by a group member, Alice uses an administrator's private key ($sk$) to sign it, indicating that this message has been checked by her. One day, Bob takes over from Alice. Therefore, Alice sends Bob the $sk$ in a secure channel. But the security concern is that since $sk$ is not changed, Alice still has the ability to sign messages using the $sk$. So I wonder if there is any cryptography technology that can prevent Alice from using this $sk$ after it is sent to Bob.

More generally, this question can be described as follows: Is there a way to transfer the ability to sign from A to B while keeping the same public key and preventing A from signing after the transfer is complete? (If needed, it is okay to change $sk$ as long as other requirements are satisfied.)

Solution

Sign a message revoking Alice's old public key and certifying Bob's newly generated key. Include a timestamp from some timestamping athority and related metadata in the message.

There's no way for the public key to stay the same, unless some CA issues certificates for Alice and Bob and people trust CA's public key and certificates issued by this CA.

Incorporating some relevant comments.

There are some problem with participants rejecting future Bob's messages when the revocation message and the new public key are somehow concealed by Alice. There's also the problem that Alice can fake back-dated messages to make them think it's a valid old message.

For the second part, a timestamping authority need to be established. For the first part, I can't think of any solution. Maybe we should require all messages be signed by at least some minimum number of required people (e.g. 5 out of 7 sign messages and revocation notifications).

Comments (5)

  • +1 – Agreed. Instead of transferring the key there should be a role change, which is linked to the private keys that are used to establish authenticity of any message. I'm not sure about the last sentence; once private keys are shared, anybody with those keys can do anything related to them - at least when it comes to the cryptographic protocol itself. — Aug 19, 2022 at 10:46  
  • +4 – The security of this relies on all users receiving the transfer and revocation message. This has to be guaranteed, or else Alice could continue to use their key. — Aug 20, 2022 at 01:39  
  • +1 – If delivery is not guaranteed, those users that didn't receive the change of ownership message would reject all [legit] messages from now on, as they wouldn't recognize Bob as a valid signer. — Aug 21, 2022 at 16:09  
  • +1 – Also, Alice could still sign a message backdated to before the revocation. This could be a problem unless there's some hard time limit (that Alice cannot change) within which a message must be received (or recorded in some trusted ledger) to be considered valid. — Aug 21, 2022 at 21:46  
  • +1 – One way to prevent the additional concerns is to change the key on every message. I.e. sign with previous key, include the next valid public key. Participants can verify that they have received all messages and in correct order. As soon as Bob has sent his first message, Alice's old key is useless. — Aug 22, 2022 at 10:49  

References