I want to design a system that hinges on ECDSA. All messages are signed using the algorithm, and this is used to prevent spoofing.

However, if a user were to somehow lose control of their key, they would be forced to create a new key to sign their messages.

Is there any mechanism that can be implemented to transition people to the new signing key securely and automatically? Additionally, how could one "revoke" the old key?


Yes, but there are potentially far reaching consequences. I'm going to answer your question more generally.

The simple answer is to revoke the signing key. As easy as that answer is for a user key, there are still issues. For example, is everyone who might rely on that signature subscribed to and updating based on our CRL? If not, revoking the key has no real effect.

If we were to reframe it just a bit, though, and talk about a code signing or certificate signing key, the problem is bigger. You can still "simply" revoke the key... but the impact is that everyone who references our CRL will no longer trust anything signed by that signing key! As you can imagine, this will lead to a significant amount of work to resign everything.

How you revoke the key will depend, of course, on the specific package that you are using. It typically involves populating data about the compromised key into a certificate revocation list which must then be circulated to all trusting entities.

How do you automatically migrate them to a new key? Well, if they have lost control of the key it's hard to imagine this as an automatic process; it really is more a reaction to an incident. For normal key changes, however, many products handle this automatically (Microsoft Certificate Services with autoenrollment, as an example, or with self-service certificate renewal) and with others it is pretty manual (PGP, OpenSSL) though you could certainly automate it to a degree.

The difficulty in building such a system from scratch is that, typically, you will prefer -not- to generate or store the private key for the certificate, especially for a user certificate; you would really like them to generate the private part of the key. This usually means that they will need to be involved somehow.


Both PGP and the global SSL PKI solve this problem in roughly the same way. You create a super "trusted" key with a long expiration which you guard with religious fervor; key stays encrypted, tucked away in a holy temple, only ever glimpsed by duly anointed CSOs, that sort of thing. It's the one you trust. You do not use it.

Then with that key, you sign your "every day" key. It has a relatively short expiration, but you follow best security practices with it nonetheless. Still, it goes where it is needed to go.

When you ever suspect that the "every day" key may have been compromised, you revoke it and sign a new one with the holy temple key.

Revocation is as simple as keeping a list of revoked keys (probably their hashes) in a globally visible location. That list should be signed. When someone checks whether to trust a key, they check the key's signature path up to a trusted root. They also check the revocation list.

Performance of key revocation checking is an issue, but if your key infrastructure is small, you can easily have only one global revocation list which you push to everyone on a regular basis.


Using PGP, the answer is to use a signing subkey, you can then attach the subkey to an unusable ("stub") master key and use that in everyday work. If that key is lost, the certification key can be used to designate a new signing subkey; the recipient will need to update the key from a keyserver though.

With X.509, no such mechanism exists.

For both, you can improve security by keeping the key on a smartcard, from which it cannot be exported. The OpenPGP smartcard does not even have a command to export a key, while smartcards for use with X.509 have a "non-exportable" attribute on keys that can be reset only by erasing the key slot.

Smartcards are hardened against common attack vectors like ionizing radiation, over-/undervoltage and over-/underclocking, and require the user to present the correct PIN, limiting the number of attempts.

For even stronger security requirements:

  • a "Class 2" smartcard reader has its own keypad for entering the smartcard PIN, so it cannot be intercepted on the PC. This can be used with standard smartcards.

  • a "Class 3" smartcard reader has its own keypad for PIN entry, and an alphanumeric display that is controlled by the card only, so the data to be signed can be displayed before the PIN entry. Here, custom code is needed on the smartcard, which represents a significant development cost.

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.