Solving the Browser Crypto Chicken-and-Egg Problem

Solving the Browser Crypto Chicken-and-Egg Problem

From time to time, questions come up in this board concerning web applications that utilize client-side cryptography (or ‘in-browser’ cryptography), where these applications claim to be designed in such a way that the operators of these applications have ‘zero-access’ to users’ private information. A common example of such an application is Protonmail, which aims to provide end-to-end encrypted email. Protonmail claims that ‘your data is encrypted in a way that makes it inaccessible to us’, and ‘data is encrypted on the client side using an encryption key that we do not have access to’.

In discussions around this subject, the ‘browser crypto chicken-and-egg problem’ frequently comes up. The term was coined in 2011 by security researcher Thomas Ptacek. In essence, the problem is: if you can’t trust the server with your secrets, then how can you trust the server to serve secure crypto code? This article explores a proposed method to solve this problem.

Method:

1. Design the web application as a single page web application.
2. Reference all supporting files with subresource integrity.
3. Store the user’s private encryption key or password in the user’s device.
4. Sanitize all external content in the client-side scripting to mitigate XSS attacks.
5. Have a trusted reviewer review and sign the static page and supporting files.
6. Have the user verify the integrity of the static page using the reviewer’s public key.

While this method provides some level of security, it has its limitations. Browser extensions or injected scripts by antiviruses can modify the page source and invalidate the signature. Additionally, implementing this method on smartphones can be challenging. Lastly, there is still a potential vulnerability where the server can redirect the user to a malicious page using the HTTP Refresh header.