Deriving private keys from a signature/HSM

Question

I have access to an HSM that can sign messages but doesn't have a way to expose the private key. The signatures are deterministic (RFC 6979). Another application only works with ed25519 signatures which isn't supported by the HSM.

Is it safe to have the HSM sign a message and use the signature as a secret to deterministically generate an ed25519 key pair? If not, I would like to know why instead of simply "you shouldn't do this"

If possible, the user should only rely on the HSM for security without having to securely keep another private key.

EDIT:

To clarify here's what I want to do. Have a static message M signed by the HSM producing a signature S. Use S as a secret to derive an ed25519 keypair. Being able to deterministically get back the ed25519 private key from the fixed message without asking the user to store an additional private key is the property i'm looking for.

Are private keys derived from a signature secure compared to being derived from the private key of the HSM itself? Assuming the signature is never revealed but the static message is publicly known.

Answer 1

The main idea of an HSM is that the private key cannot be exported out of it. The way you describe your scheme means that you will have to get the signature out, then create the private key from that outside the HSM. Obviously if your server is compromised then an attacker can get to that private key by extracting it from memory, or by forcing the application to perform a signature.

Another advantage of HSMs is that the operation and algorithms are generally validated to work correctly and not be applicable to e.g. side channel analysis. You cannot rely on that kind of reliability by performing the calculations outside of the HSM.

---

There is an advantage to derive a single key pair from the existing one: you would not have to store the private key in memory while you are not using it. It is possible to keep it in memory and try to destroy it once you've used it.

That said, if the memory contents can be retrieved, if side channels are possible, if the signature generation can be achieved by an adversary then you cannot be sure that the private key gets copied and security gets lost.

---

Initially it seemed that the key pair was created specifically for the message. In that case it might be hard to establish trust in the public key that is part of the key pair. Without trust in the public key verification of signatures is meaningless.

Answer 2

To validate a signature in the standard case, no interaction with the signer is needed. Anyone at any time can take a signed message, compute its signature and check if fits the public key of the signer.

In the scheme that you suggested, each message will use a separate key pair. The validator will not know if this public key really belongs to the HSM. To validate the signature, the validator needs to send the message to the HSM, and the HSM should compute an ed25519 key pair for this message and tell the public key to the validator.

Such interaction can be impossible because of two reasons:

• The validator does not want it, e.g. to prevent the disclosure of the validation fact, disclosure or validation frequency, disclosure of validation dates and times, disclosure the IP of validator, etc.
• The HSM is not available for interaction with validator, e.g. the HSM can not be reached because connections from validator are refused. Or the HSM is not reachable because of maintenance works. Or there was an attempt to compromise the HSM and it has destroyed its internal data. Or the HSM was just routinely reset and replaced by a newer better device and there is no way any more to validate any previously signed messages. In a normal case you can register public key of HSM and would know that message was signed by this HSM even after the HSM was reset or destroyed. But in your scheme this will be impossible.