3
$\begingroup$

Say I have a pair of public and private keys associated with some resource (e.g. a TLS certificate for a website mycoolsite.com). I am free to take those keys and reuse them for a different resource (e.g. for anotherneatsite.net). My question is: is there an efficient way to "tag" the original keys with the data "this key is for mycoolsite.com" such that removing the tag would invalidate the keys?

The idea would be to allow an authentication system to reject a public key if it were reused for a different account. To be clear, this is a general question about public key encryption systems, not just TLS.

$\endgroup$
1

2 Answers 2

4
$\begingroup$

My question is: is there an efficient way to "tag" the original keys with the data "this key is for mycoolsite.com" such that removing the tag would invalidate the keys?

Yes, that's basically what certificates do, where you can have a domain name in the X500-style RDN (Relative Distinguished Name). It is also possible to have (critical) extensions that contain additional data such as the subject alternative name or key usage. "Critical" means that the extension should not be ignored even if the extension is unknown. All this data is signed by the CA issuing the certificate and MUST be validated by a verifier.

Of course, even a MUST within a certificate verification procedure can be ignored. It is not possible to invalidate the key itself, and you cannot force a system to ignore data sent to it from the outside (unless you sandbox the system I suppose).

Nor is it possible to disallow the user to copy the public key or to request a certificate somewhere else. Sometimes specific CA's will keep an ID of the keys within the certificates they have signed. In that case a CA could choose to ignore a certificate request with an "old" key - although in my experience this is more about avoiding errors within the system.

And finally, it is not possible to restrict the use of a private key. The holder of an RSA private key could use that key for signing or for key establishment, even if the certificate information states otherwise. The certificate just states what the key pair can be used for, but it is up to the party that receives, validates and trusts the certificate to enforce this.

$\endgroup$
4
  • $\begingroup$ So putting aside the social system of certificate authorities, there's no known cryptographic way to tie a key to a piece of information? $\endgroup$
    – Ian H
    Commented Feb 15, 2022 at 19:44
  • $\begingroup$ A piece of information in this case being the resource in the question I imagine? Because otherwise it would become a different question. $\endgroup$
    – Maarten Bodewes
    Commented Feb 15, 2022 at 20:04
  • $\begingroup$ Yeah -- the use case here is a system where the client generates the key itself without consulting a centralized authority. So I can't rely on the social infrastructure that TLS certificates enjoy (and it's not clear that even that infrastructure can enforce this, see for example this situation koen.engineer/a-tale-of-private-key-reuse-8ff0cb766fa5). $\endgroup$
    – Ian H
    Commented Feb 15, 2022 at 20:07
  • 5
    $\begingroup$ @IanH Just because you need a CA, doesn't mean you need a third-party CA. You'd have a self-signed CA cert that you'd be in control of for your own infrastructure. And if you don't want to use a CA at all, you can just have a self-signed certificate that restricts the use of your public key. Essentially, the answer to your question is that you need to bundle some metadata with your public key to restrict its use, which is what a certificate does. $\endgroup$
    – knaccc
    Commented Feb 15, 2022 at 21:19
1
$\begingroup$

One way is this:

  1. Client generates private & public key.
  2. Client sends public key to server.
  3. Server generates a derived key from the client's public key and a random nonce.
  4. Server sends the nonce back to client, who can use it to create a derived private key.

In this way both client and server contribute randomness to the key, so the client cannot choose a poor quality or reused key by itself. At the same time, the server never knows the private key.

How to perform step 3 depends on the algorithm used. There are some examples in answers to this question.

$\endgroup$

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.