Zero-knowledge encryption in more details
Hi,
can someone explain how the whole concept of zero-knowledge encryption works in the context of Hub<->RDM integration?
I have read the "in-depth" article from CSO at https://blog.devolutions.net/2023/02/devolutions-hub-business-security-first-from-day-one/ however, honestly, its just more marketing.
So, I start the Remote Desktop Manager (RDM), I add a Hub data source. It asks me for a name and email. Ok, I save, and it now sends me (via browser) to Portal login where, for the first and last time, I enter my password which is supposedly my private key.
Lets ignore for the moment that Devolutions now knows my private key (and that its somehow salted and hashed in Devolutions credentials store).
The browser validates, and I presume issues an OAuth-type token in the background. Maybe something else, doesnt matter, something does get sent to the RDM via some url schema and voila, that activates RDM which can now open my hub data. RDM itself NEVER asked me for my key (which is in line with OAuth, but OAuth is by nature NOT a zero-knowledge system).
So, how does this work? Lets assume you are good natured and you will not save my private key as I login, still how does RDM knows whats my private key? How does it load the data without the key without going through a decryption session on Devolution end? Is it sending my password through OS based url callback?
You guys really need a technical white paper not written by marketing.
All Comments (2)
Hi,
We actually have a technical whitepaper available in the Trust Center under the title "Devolutions Hub Cryptographic Design - 2024". This document goes in-depth into our encryption approach and security measures. It can be found using the Trust Center link here:
https://devolutions.net/security/
Zero-Knowledge Principle: In this context, zero-knowledge means that Devolutions servers cannot decrypt your data. This principle is upheld by ensuring that the encryption key, derived from your password and other factors, remains local to your device and is never shared with our servers. Since RDM is the client application, it requires the private key to decrypt the data locally. This approach inherently means that data remains inaccessible from the server-side—only the authenticated, local client can decrypt it.
Encryption Process on Login: When redirected to the webpage for login, your password undergoes local pre-hashing with domain separation, ensuring it can't be used to derive your private key. This process uses robust key derivation functions that significantly reduce the risk of brute-force attacks.
OAuth for Authentication: OAuth tokens handle only authentication and session management, with no connection to data confidentiality. While Devolutions does have access to OAuth tokens, they cannot be used to decrypt your data because the decryption key itself is derived directly from your password, hardware key, linked mobile app, or printed recovery code—all of which remain entirely client-side.
For more details on our cryptographic design, please refer to the whitepaper linked in our Trust Center.
We will make sure to update our content and put forward this whitepaper which might be relevant to other users.Thanks for bringing this to our attention and hope my answer will help! Don't hesitate if you have further questions,
Philippe Dugré
Application security and cryptography specialist
Philippe Dugré
Ok, thanks for the white paper, I'll have the risk mgm team take a look too.
Cheers.