2
$\begingroup$

Let's say we have a server whose job is to sign documents using a private key. Let's say that there's a bug in the software and the private key gets stolen. I'm interested in mechanisms to mitigate the damage.

One thing you could do is have the server throw out keys as it goes. Instead of giving a the server a single private key, you'd give it a sequence of private keys. The node signs doc1 with key1, doc2 with key2, etc. When it's done with a key, it throws out the key completely, so that key can't be stolen any more. There must be some mechanism to procedurally generate the sequence of keys, but I don't know the name of the technique to google it. Anybody know what this is called?

Are there any other cool techniques that can be used to protect the private keys?

I found a paper called "A Forward-Secure Digital Signature Scheme." I think I'm on the right track.

I'm still interested in the second part of my question, though: is there anything I can do besides forward secure digital signatures?

$\endgroup$
  • $\begingroup$ I'm talking about a system that uses public key cryptography to create digital signatures. If the secret key gets stolen, then all the digital signatures that the system has ever created are pretty much worthless. That sucks. I'd like to avoid all the signatures becoming worthless. My particular application is a stake-based cryptocurrency, in which blocks are signed using a private key. But the question applies to any system that uses digital signatures to sign pretty much anything. $\endgroup$ – jyelon Jan 12 '18 at 19:58
  • 1
    $\begingroup$ Is your definition of "cool techniques" limited to cryptographic systems? $\endgroup$ – Q-Club Jan 12 '18 at 20:40
  • $\begingroup$ I wouldn't say there's any particular cool technique I have in mind. Anything practical is interesting. $\endgroup$ – jyelon Jan 13 '18 at 15:17
1
$\begingroup$

A standard solution is to have keys with limited validity keys and a separate, possibly offline long term key signing key. The signing server holds only one key, so even a total comprise of the server won't reveal future keys. Before the active key expires, the server gets a new key signed by the master key and starts using it. We also use certificate revocation lists. If we suspect a key has been compromised before the end of it's validity we not only switch to a new key we publish a revocation of the previous key publicly signed by the leaked key or master key. Verifiers can check this list before trusting a signature.

This setup works rather well with https protecting communications. But is less suitable for signing docyments where you will want document signatures to remain valid for a long time. Even after a key expires or is revoked. Blockchain works welll here and relies on hash functions rather than assymetric ciphers. If you publish a chain of hashes of everything signed with it's time stamp it is difficult to back date a signature as it isn't in the chain. Making many copies of this around the internet or even use an existing blockchain is one way to make such records tamper resistant. You could simply sign the tip of the chain with current active key. And allow an interactive verifier to get high confidence on old documents because you essentially keep resigning everything you signed in the past.

$\endgroup$

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.