11
$\begingroup$

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.)

Improve this question
$\endgroup$

3 Answers 3

Reset to default
13
$\begingroup$

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).

Improve this answer
$\endgroup$
7
  • 1
    $\begingroup$ 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. $\endgroup$
    – Maarten Bodewes ♦
    Aug 19, 2022 at 10:46
  • 4
    $\begingroup$ 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. $\endgroup$
    – user71659
    Aug 20, 2022 at 1:39
  • 1
    $\begingroup$ 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. $\endgroup$
    – Ángel
    Aug 21, 2022 at 16:09
  • 1
    $\begingroup$ 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. $\endgroup$
    – Ilmari Karonen
    Aug 21, 2022 at 21:46
  • 1
    $\begingroup$ 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. $\endgroup$
    – jpa
    Aug 22, 2022 at 10:49
17
$\begingroup$

In PKIs, this situation is usually accomplished by ensuring Alice doesn't actually know the private key. The key is generated and stored in a hardware security module (HSM), which performs operations, such as key generation, encryption and signing, without disclosing the actual key externally.

When Bob takes over, Alice physically transfers the HSM to Bob, giving assurance that Alice no longer controls the keys. This avoids any changes in the public key, which may be difficult to update, such as when it is used by large numbers of embedded/IoT devices.

Further, HSMs implement secret sharing or multiple user access control such that a certain number of passwords or hardware tokens must be presented for an operation to take place, so these tokens may be physically handed over or reprogrammed, e.g. as employees leave the company.

The security of this scheme depends on the security of the HSM to cryptographic, logical, and physical attacks.

Improve this answer
$\endgroup$
1
  • 1
    $\begingroup$ Yes, I know using an HSM can perfectly solve the transfer problem. However, the question just describes one part of my research and HSM can hardly be applied to the case. So I am looking for some special schemes that use some algebraic method to achieve the goal. $\endgroup$
    – Z. Chen
    Aug 21, 2022 at 12:37
5
$\begingroup$

If an administrative message is identified just by being signed with a specific private key, you can't prevent any entity having a copy of that key from creating valid administrative messages. If the system is not yet deployed (i.e. Alice doesn't know the private key for administrative messages yet), you might be able to deploy a trusted "signing service" that is the only entity that can sign valid administrative messages. Alice and Bob can use separate authentication at that signing service (different API keys, different OAuth tokens, different private keys) in a way that is appropriate for your system. As this authentication of Alice or Bob is only used at the signing service, the recipients don't need to be aware of who signed the message. This basically is the same cryptographic idea as the HSM, but having the "security service" in a (cloud) service instead of a hardware module.

In the long run, on the other hand, systems that do not allow replacement of a "master signing key" often get in serious trouble as soon as the key is either leaked or cryptographic advances require a longer key length.

For systems that are expected to be deployed in a large scale, I highly recommend to have a key replacement plan. A current example of a system that likely can recover from a breach is Intel's SGX enclave system. Due to the Æpic Leak bug, the master key of Intels attestation system leaked, so everyone can fake attestation messages that the remote system would run uncompromised code. Intel had designed a procedure called "TCB recovery" into their code attestation system that allows to enroll new keys that can be trusted again. Without a procedure like that, SGX would have been completely useless by now.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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