Data privacy illustration. Facebook
Crypto wallets have become a user-desired browser feature but at the moment of writing, only Brave and Opera have jumped into the bandwagon. Aside from transfers of cryptocurrency, these wallets have other, not-so-well-known features. For example, passwordless logins is an interesting topic, but we will cover that in another article. Here, we will look into the client-side encryption use case of crypto wallets and how browsers with such a feature can improve privacy.
Client-side encryption conceals data in the browser before it is sent to the server. With new data privacy regulations on the rise, it presents an opportunity for service providers to disconnect themselves from data leaks liability by handling encrypted data in the browser itself, where it is accessible only to the user.
There are two common ways to conceal data using encryption – secret-key encryption (symmetric encryption) and public-key encryption. The former uses a secret key and allows clients to decrypt data using the same key they used to encrypt it. Quite straightforward. Whoever has the secret key has access to the data.
Public-key encryption, on the other hand, requires a pair of secret and public keys. It encrypts data with the public key and decrypts it with the secret one. Thus, only users with the secret key can access encrypted data.
In order to apply encryption to a piece of data, we need to have either a secret key or a pair of secret and public key. We avoid the need to store a secret key by generating it using a browser’s crypto wallet, for instance Brave’s built-in crypto wallet.
To do that we use the crypto wallet message signing functionality and, fortunately for us, most browser and hardware wallets implement RFC 6979 (deterministic signatures) as a countermeasure to weak random number generators.
This means that the same message signed by the same crypto wallet account always produces the same exact message signature. Finally, we can generate a secret key for our encryption purposes by hashing the resulting signature.
In conclusion, we can start encrypting data after we generate secret and public keys using a static message and a crypto wallet’s message signing functionality.
The client-side encryption use cases can be grouped by the two aforementioned encryption schemes.
The secret-key encryption allows the user to store data available only to themselves. It is commonly used in cloud storage services, where the user encrypts files locally and then sends them to a server. The cloud storage provider then stores the encrypted data, but has no access to the actual content.
Public-key encryption, on the other hand, allows users to securely send messages to other users by encrypting them with the other user’s public key. This way, users can pass private messages or share private information on a platform, guaranteeing that content is only accessible to the recipient.
Smart cards and chipped ID cards with encryption capabilities can be used to perform those encryption operations and are arguably a more secure option, however, they require specific drivers and browser extensions that allow web applications to use them. On the other hand, all you need for a crypto wallet is a smart phone (Opera) or a desktop browser (Brave).
Client-side encryption can significantly improve security and privacy of medical patient portals. Patient data is very sensitive in nature and breaches can cost a lot in damages to the portal operator and to its users. It’s enough to do one search on “medical data breach” on the web to find that these breaches happen very often, which is ironic because they can be easily prevented using data encryption.
Let’s consider an interaction between a patient, a medical laboratory and a medical doctor in a patient portal. Assume that all participants have set up crypto wallet accounts and have provided their public keys to the system. When the participants enter the system, they are asked to unlock (generate) their secret keys by signing a message. Once that is done, they can now encrypt data and send private messages.
The patient and their doctor are exchanging messages, encrypted with the other’s public key. Therefore the entire communication is secret and the messages are only available to the doctor and the patient. The patient stores some personal data using his secret key, for instance – name, age, gender, height, weight.
When a health professional asks for this information, the patient can retrieve the encrypted copy of their personal data from the portal, decrypt it, extract the need information and send it secretly. Likewise, the medical laboratory can send the results directly to the patient and the patient can decide to forward that record to the doctor, or to another health professional.
Even if there is a data breach and the whole database is leaked, the data stored on the server is encrypted and is only available to users with the keys to decrypt it.
Client-side encryption certainly increases user privacy, but it’s not without its limitations. The account recovery and secret-key changing process is more complex than the simple sending of a reset password email. If a user loses their wallet, they lose their key and therefore the encrypted-with-it-data is considered irreversibly lost forever.
Fortunately, crypto wallets’s seed recovery phrase (seed words) will rescue the account in such scenarios. On the other hand, if the account or secret key is compromised, the user should be able to reencrypt all their data on the server with a new secret key.
Client-side encryption can significantly improve user privacy and security. It will not only decrease the risk of damages due to data breaches, but will also give control over the data back to the user. The only requirement is for the user to have a phone or a browser with a crypto wallet to enable client-side encryption. What follows is for web application developers to start using it.