Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share

2 Answers 2

up vote 2 down vote accepted

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.

share

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.

share

This site is currently not accepting new answers.

Not the answer you're looking for? Browse other questions tagged .