Fejoa: The Portable Privacy-
Preserving Cloud

Client Server Authentication in Fejoa

April 3, 2017    Blog Post

The primary client/server authentication method in Fejoa is a simple username/password login. While this sounds quite simple to implement there are a lot of privacy related issues that could go wrong, especially if the server is not necessarily trusted:

  • The password might be intercepted by a third party while logging in.
  • The password might be leaked to the server during the login process.
  • The password is stored insecurely at the server.

In Fejoa the password is not only used to login into the server but also to unlock the keystore and thus to access all data. This makes it even more important that the user password is not leaked during authentication. In the following a high level overview is given that describes how Fejoa derives login and keystore keys from the user password and ensures that the password is not leaked to any third party including the server.

Deriving the login and keystore keys from the user password

In Fejoa a user key is derived from the user password using a key derivation function (KDF). Currently the PBKDF2 algorithm is used but other KDFs such as bcrypt or Argon2 are planned to be supported in the future. A KDF usually takes a random salt value and an iteration count as parameters.

\[ key_{user} = KDF(password, salt_{user}, iterationCount) \]

The goal is to make the calculation of the user key computationally expensive by choosing a high iteration count. This makes it harder for an attacker to use brute force methods to guess the user password; it simply would take too long to try a range of possible passwords. One could say a “weak” password has been strengthen to a strong user key $key_{user}$. The user key is as private as the user password and should not be leaked in any circumstances.

Too derive more keys from $key_{user}$, i.e. a login key and a keystore key, the following approach is used. A user generated salt value is concatenated with the user key and hashed using a cryptographic one way hash function (SHA3):

\[ key_{sub} = Hash(concatenate(key_{user}, salt_{sub})) \]

In this way the secure sub keys $key_{login}$ for login and $key_{keystore}$ for the keystore are derived from the user key. This method has the advantage that the expensive KDF evaluation has to be performed only once and an arbitrary number of secure sub keys can be generated efficiently.

Login process

The KDF iteration count and all salt values are generated by the user. This means the user is in control of the chosen security parameters. However, since the user does not want to remember all these required parameters, the user uploads these parameters to the server. These parameters are the KDF iteration count, the KDF salt $salt_{user}$, and the sub key salt values $salt_{login}$ and $salt_{keystore}$. When logging in, the user requests the required parameters from the server.

The login key $key_{login}$ is used by the server for the user authentication for which reason this key is as well stored on the server. However, as described above, the server can’t practically derive the user password or the user key from the login key.

Summary:

  1. The user requests the KDF parameters required to derive the login key, i.e. the iteration count and $salt_{user}$, and derives the login key $key_{login}$
  2. The user and the server compare their login keys
  3. On a successful authentication the user can access the user data and $salt_{keystore}$ which is required to derive $key_{keystore}$

Possible attacks from the server

When requesting the login parameters the server is able to cheat and send back wrong parameters. For example, the server could send back an iteration count of 1. This would make it much easier to brute force the user password from the exchanged login key. In the following this is called a parameter-attack.

Zero knowledge authentication

For this reason Fejoa uses a zero knowledge protocol to compare the login key between the server and the user. Fejoa uses the EKE2 protocol as proposed in the paper: Authenticated key exchange secure against dictionary attacks by Bellare, Pointcheval and Rogaway. This protocol has the properties that neither the user, nor the server, nor a third party learn anything about the involved secret keys. This means an external attacker can’t learn anything about the login key stored at the server. Moreover, the server can’t perform a parameter-attack as the server does not learn any new information from the user.

Important: when a login fails the client should not automatically attempt to login again using the same login key! If this would be the case, the server could perform a parameter-attack and efficiently verify the validity of a candidate password, i.e. on every login attempt the server tries a new password.

Third party attacks

As already described earlier this login method efficiently prevents third party attackers to login. This also means as long as the server does not leak the user data, a third party attacker can’t steal and brute force the key store. Furthermore, since the security parameters are chosen by the user there is no need to trust the server to store the login key securely (this assumes that the client software assists the user to choose secure parameters). Even if the server gets compromised the user data is safe.

Authentication from a WEP app?

At some point it is certainly desirable for Fejoa to have a web app to access the user data. However, some may already guess that this is not easy to do if the server is not fully trusted. The reason for this is that the server provides the web app code (JavaScript) and by supplying malicious code the server could simply read out the user password. Many services that claim client side encryption are actually suffering from this problem.

A solution would be to use a trusted browser plugin that handles the described authentication and is able to verify the web app provided by the server.


Comments: