Is it safe to use ECDH shared secret as a simple authentication cookie?

Question

The protocol would look like this:

1. User creates account and provides username, static public key
2. User logs in by sending username
3. Server responds by sending an ephemeral public key
4. For the duration of the user's session, all requests must be accompanied by the ECDH shared secret between user-static and server-ephemeral keys

So the shared secret is used as a raw token or cookie. Assuming the communication is otherwise encrypted by TLS, are there any drawbacks to this? The benefit is "passwordless" authentication without any extra encryption.

Answer 1

You're essentially using knowledge of an ECDH shared secret to prove knowledge of the private key associated with your static public key, thus authenticating yourself to the server.

If you use the same public key to authenticate yourself both to server A and server B, then this would allow either server to impersonate you.

For example, you would log in to server A, and server A would provide your username to server B and request an ephemeral public key from server B. Server A would provide server B's ephemeral public key to the client, as if it had come from server A. The client now provides the ECDH secret as a cookie to server A, and then server A can impersonate you with server B.

Your approach requires the server to keep a copy of every ephemeral public key issued. This would not be necessary if you had provided a signature, which is the normal approach to proving knowledge of your private key. Such a signature would need to be bound to the server you're contacting, to prevent it being used elsewhere. It would ideally also be bound to a server challenge and an expiry date, to prevent a replay attack from anyone that does not know your private key but happens to be able to gain knowledge of one of the signatures.

You can avoid reinventing the wheel by using a TLS client certificate for registration and authentication.