4
$\begingroup$

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.

$\endgroup$
4
  • $\begingroup$ We generally keep questions key management on Information Security. That's something that a new user cannot be expected to know though. If you don't mind, I would like to migrate this to our sister site. However, it would mean that you'd also have to extend your overal Stack Exchange account to include Information Security otherwise you won't be able to control your question or accept an answer. Is that OK with you? $\endgroup$
    – Maarten Bodewes
    Dec 30, 2022 at 2:09
  • 1
    $\begingroup$ @MaartenBodewes I edited the question I think it still belongs here? let me know if that's not the case $\endgroup$
    – telescope
    Dec 30, 2022 at 3:02
  • 1
    $\begingroup$ Such approach is not secure. If an attacker asks the HSM to sign the same publicly known message, then the attacker will obtain the same ed25519 key pair. Whereas if you just use any CSPRNG, the result is not repeatable and nobody will be able generate the same key pair. $\endgroup$
    – mentallurg
    Dec 30, 2022 at 3:13
  • $\begingroup$ Is that the only reason why it wouldn't be secure. Is it assumed to be secure keeping this threat in mind? $\endgroup$
    – telescope
    Dec 30, 2022 at 3:17

2 Answers 2

1
$\begingroup$

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.

$\endgroup$
1
  • $\begingroup$ The private key will not be stored anywhere, but the message used to derive it will be stored. If many keys need to be derived, e.g. because the other one was disclosed, then for every key pair one need to store the message for this pair. $\endgroup$
    – mentallurg
    Dec 31, 2022 at 16:58
0
$\begingroup$

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.
$\endgroup$
14
  • 1
    $\begingroup$ Why would a verifier need to compute a signature? Shouldn't that be "verify the signature"? I'm not sure if your browser didn't update, but the question reads that the signature is deterministically generated, so why would the key pair change per message? $\endgroup$
    – Maarten Bodewes
    Dec 30, 2022 at 1:52
  • 1
    $\begingroup$ @MaartenBodewes: The OP says that the ed25519 key pair will be derived from the message: The message will be first signed by HSM, then the signature will be used as a seed to generate an ed25519 key pair, and this generated key pair will be used to sign the message. Means, everyone who wants to validate the signature will have to repeat all the steps including asking the HSM to first sign the message using its deterministic (RFC 6979) signature, then derive a ed25519 key pair. $\endgroup$
    – mentallurg
    Dec 30, 2022 at 1:57
  • $\begingroup$ Oh, dang, yes you are right. I'll probably have to wonder all night why that is the case. If you'd use a static string to create a signature and derive a key pair (and later just a private key) then the scheme would make at least some sense as you would not have to store the private key permanently outside of the HSM. $\endgroup$
    – Maarten Bodewes
    Dec 30, 2022 at 2:01
  • 1
    $\begingroup$ @MaartenBodewes: If a static string was used, then the derived key pair would be also static and could be used to sign any messages even those that the HSM has not really signed. $\endgroup$
    – mentallurg
    Dec 30, 2022 at 2:03
  • 1
    $\begingroup$ @telescope: I'd suggest you another approach: Generate ed25519 key using any tool of your choice. Encrypt the private key using the HSM. This is what HSMs do well. You will avoid overhead with message that you need to store somewhere, overhead with key generation (you will need to stick to the same algorithm all the time). You will just ask the HSM to decrypt the key without having any "magic". $\endgroup$
    – mentallurg
    Dec 30, 2022 at 3:38

Your Answer

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

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