2
$\begingroup$

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.

$\endgroup$
1
  • 1
    $\begingroup$ "User logs in by sending username"... 'xcuse me, what? $\endgroup$
    – Maarten Bodewes
    Jan 11 at 18:29

1 Answer 1

2
$\begingroup$

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.

$\endgroup$
1
  • 1
    $\begingroup$ Additionally, with X25519/X448, multiple different public keys produce the same shared secret. You need to include both the sender/recipient public keys in the key derivation. $\endgroup$ Jan 11 at 18:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.