Authentication by hardcoding public key in client software

Question

It would seem to me that mobile applications could reduce network traffic by hardcoding the server's public key into the app.

The idea being that they could then encipher a secret to share with the API using the public key.

We then would seemingly not need to validate the server-side identity, because only the private key holder should be able to decrypt the message.

The conversation could then switch to symmetric encryption immediately, since both sides have knowledge of the key.

Apart from key management issues, in the event of an unrelated private key compromise, is this otherwise secure? What weaknesses, if any, are there for this scheme vs. traditional TLS handshake?

Answer 1

Yes, the basic idea of hardcoding a public key is secure. It is sometimes recommended as an alternative to the complexity TLS and PKI bring – otherwise it can be easy to skip a crucial step and end up with little or no security.

However, the "encrypt a secret for server" scheme has some weaknesses compared to TLS. The clearest is lack of forward secrecy (which admittedly some TLS suites also lack). If an attacker breaks the public key encryption or gets the private server key, they can decrypt all sessions past and future.

A slightly more complex protocol would fix that issue. You could e.g. hardcode a signing key and authenticate an ephemeral Diffie–Hellman key exchange.

(You also miss out on using the available implementations of TLS, needing to write your own code risking mistakes. That is harder to quantify. And like you said, key management may be more of an issue.)