How to identify the customer by the public key of a certificate

Question

How do I identify the X client, Y client and Z client when they try to authenticate via API... Example... such a customer sends me the key uy2395734asdfas, how do I know that that customer is respectively the client Y?

Answer 1

Only with the public key is this impossible. In fact it is possible, but anyone can claim to be "Customer Y", even if it is not.

---

Such a customer sends me the key uy2395734asdfas, how do I know that that customer is respectively the client Y?

If you only have the public key, what you have is the same as a token. This public key will be associated with "Client Y" in a database of the type:

Cliente   | Chave
Cliente Y | uy2395734asdfas
Cliente X | aa3342131ssaxsd

You do not have any cryptographic guarantee, so the tags of your question criptografia, ssl and openssl can be ignored.

---

If you want to identify the user and know if he is actually the owner of the corresponding public-key private key, you have to "test"/"challenge" (key-Challenge or Challenge-Response Authentication). As said above, anyone could submit a request using the public key uy2395734asdfas. To prevent this you need a proof that actually the person who is ordering has the respective private key.

Assuming, for example, you are using Eddsa/ECDSA, at each request the client should SIGN the body of the request. It must also contain its own public key.

This way you check the signature against the public key; and check the database for anyone associated with this public key. Your problem here will be to mitigate a replay-attack, so you can add a expires or nonce to prevent re-use of signatures.

---

On my website, which I use Ed25519, what I do is very simple, there is a header:

X-Signature: [assinatura]

All requests must be made using a:

{"public_key": [chave publica], "expires": [tempo para expirar], [resto do corpo]}

This way, I simply check if the subscription is valid and not expired, then check if it exists in the database. "Expires" is less efficient than a "nonce", but is more convenient because it saves generation of signatures.

This technique has a problem with the GET method, but I don’t use GET, so no problem, but it’s just what I use, not what I should use (or recommended to use).

---

You can also use the challenge method only when logging in, that is: you create a challenge (n-random bytes) and ask to sign in, in order to prove that it has the corresponding private key. If all is well you create a traditional session, not needing to involve the signature in all requests.

---

Since your question is tagged ssl and openssl... There is another way using SSL/TLS itself, which can be complex depending on the language you are using, but is more robust.

This method is known as the TLS Peer Authentication. First, you create a certificate that will act as a certifying authority, generating certificates for customers (you don’t need the private key to generate the certificates).

For the client, in each request, it will be necessary to use the certificate, it will contain the public key in which you can associate with "Client Y". All validation of certificates and signatures will be done on the same TLS layer, which reduces the likelihood of some wrong deployment on your part. In Golang, for example, you can get customer certificate information using the ConnectionState.PeerCertificates.