How can we exchange public keys between two servers in a secure way?

Question

I have two servers with a pair of RSA public and private keys.

We do not use a CA for the internal communication yet and therefore we need to exchange keys without CA.

I need to establish a trust between two servers: I need to copy a public key form the first server to the second server and the public key from the second server to the first server.

Note that it is not Diffie–Hellman key exchange (that explained very well in "Diffie-Hellman Key Exchange" in plain English).

The simplest way is just manually copy the public keys from one server to another.

An additional option is to use the following homegrown flow:

1. Generate a one-time token on the first server
2. Copy the token manually to the second server
3. The first server accesses the second server via an API. Ase the token for the API authentication. The API implementation exchanges public keys between servers

Any suggestions to improve the flow?

Do we have some best practices flow, since homegrown flows are usually bad for security?

Answer 1

This will mean a lot of unneeded overhead. I'd suggest following:

• Since you don't have certificates issued by CA, create your own CA. Namely, create a self-signed certificate and add it to a key store on both servers, so that your certificate is trusted.
• Issue certificates to each server and sign them with private key of your own CA.
• Make your servers use their certificates when communicating with the others.

Thus you will actually use PKI.

In the future, when you get certificates from the real (commonly known) CAs, the only thing you will need to do will be to replace your own self-signed CA certificate by (also self-signed) certificate of a real CA.

Answer 2

No, I don't think that the solution is good. Let’s go through it:

1. This is fine
2. If we can manually copy, why not copy the public keys directly?
3. Here's the real problem. As this is done on an insecure connection, you can't be sure that the first server actually talks to the second server.

You weren't specific on how the exchange works, but using the token as simple API authentication token will not prevent a MITM attack.

In the communication between the two servers, an attacker can:

• intercept the token when the first server sends it, forward it to authenticate & send a fake public key to the second server
• send a fake public key to the first server in place of the real one from the second server

Or visualized:

A  ------ token ----->  E  -- authenticate with token --> B
A  <-- fake pkeyB ----  E  <------ real pkeyB ----------- B
A  --- real pkeyA --->  E  ------- fake pkeyA ----------> B

You seem to want symmetric key crypto, maybe something like Kerberos. But for the use-case you describe, copying the keys manually seems easiest (or exchanging them insecurely and manually checking the received keys fingerprint).

Answer 3

The only way to establish initial trust between two servers separated by an untrusted network has to involve a manual¹ step. This can be achieved either by copying it manually or by manually comparing whether the keys are transmitted correctly before trusting them. The manual comparison is typically done using a key fingerprint. It can be done by comparing a secure hash (like SHA-256) of a copied file as well.

There are other ways, but they must involve transporting a piece of information between the two servers, there's no way around it. It can be proven mathematically. Copying the key via untrusted connection and comparing a fingerprint manually is the most straightforward way, in my opinion, and also fairly standard.

Note that for a network of servers you only need to transport one key per server added to the network, for a total of N - 1 such operations for a network of N servers. If you wish to add server X to a network of servers A, B and C trusting each other's keys you only need to establish initial trust between X and, for example, A. Trust between X and B and between X and C can then be established by means of key signing.

---

¹ The word manual here was used for simplicity. What is essentially meant is that a piece of information must be sent from one party (server) to another through a trusted channel. This trusted channel might be the operator driving to the server with key fingerprint written down on a piece of paper as it might be a trusted cable connection. Furthermore for a connection to be trusted in the context of public key exchange it only needs to be resistant to man-in-the-middle attacks, or, in other words, it needs to preserve the integrity of the message. Potential eavesdropping of the connection doesn't harm this trust, as all such an attacker could learn are the public keys.

Answer 4

If you have access to any trusted HTTPS server, post the public key of every server on it, download on the servers.

If your HTTPS server is properly configured, no MitM can change the public keys, and the servers can download securely the public key of every other server. And if cost is an issue, Let's Encrypt lets you create a public facing SSL certificate for free.

Answer 5

Public keys are safe to share unencrypted. If you need extra level of security then you may want to consider generating new key pairs first to share thouse temporary key public parts to send your original public keys and destroy temporary keys and reinitiate your session with original public keys.

But if you still need to be safe from MIM-attack by substituting your temporary and original public keys during transfer then you should rely on some trusted root storage or use hardcoded public keys to initiate session. In both of these ways security of these keys outdated with time and need to be re-issued time-to-time.

Answer 6

One alternative for key distribution is DNS: keys, or rather key fingerprints, published in DNS records, protected by DNSSEC. Two standard examples of this are SSHFP (for SSH host keys) and DANE (for arbitrary services using TLS) but you can equally roll your own in TXT records or similar if that makes more sense for what you need the keys for.

Ultimately this isn't bypassing the need to have a preexisting signing authority you trust (in this case, the DNS root and DNSSEC chain from it to your domain), but it does bypass the web PKI/CA ecosystem, if that's what you want.

Answer 7

The task is no different to securely copying a file between two servers.

Assuming you have an access to both servers, you trust both servers and you trust the channel you use to access both servers (else, the whole thing is pointless).

You just copy the file using whatever means you use to connect to the servers.

Both servers are connected somehow (else, you don't need to establish trust between them). You can as well transfer the file by the possibly untrusted, but faster connection between them. In this case, you have to check the result of the transfer by calculating and comparing the hashes of the original file and the copy, using the secure connection between you and the servers. If the files are short enough, you can as well compare the files themselves and not the hashes.

Answer 8

Your proposed homegrown flow still requires a CA. In order to securely call the proposed API and not be subject to a MiTM or impersonation attack, you need to identify to the caller that the callee can be trusted - which requires a CA.

If you already have a secure way to contact both servers, use that to send them the keys - even if that way is to drive over to where the servers are located and load the keys from a USB stick. If that secure way is to SSH into them (and you don't get any certificate warnings, which means this actually isn't a secure method), then you already have access to a CA that you can utilize for internal communication.