Design Considerations

Spoofing attacks

The mechanism for registering an ephemeral key in Keysmith appeared to have a shortcoming in that a knowledgeable attacker is able to impersonate a user to gain access to the wallet.

Description

The flow for the original user-key registration goes like this:

A savvy attacker would be able to impersonate another user by supplying the victim's email address in both of these API calls.

The weakness here is that there is no authentication in the first call.

Resolution

The resolution is basically to ensure that API calls to exchange the key are authorized.

Internal Google SSO

A way to do this for the internal SSO process is to change the API signature such that the email address are not supplied via the parameters. Instead of the email address, the API accepts access_token which the server uses to retrieve the email address of the user from Google.

This way, the caller of the API cannot spoof the email address.

The sequence diagram below illustrates the changes in the supplied parameter in steps 1 and 5.

Alternatively, there is also consideration for merging these two endpoints. The sequence diagram below describes the changes but this is not a confirmed design yet.

External Google SSO

With external Google SSO, the request to exchange the key has to be accompanied by a JWT which is signed by the private key of the partner application. The endpoint can verify the JWT using the shared public key from the partner before processing the request.

This is secure on the basis that the private key of the partner is not compromised.