> Zero knowledge cloud
> Data in our cloud is end to end encrypted so your credentials are never exposed to anyone but you.
A few comments:
1. You might want to avoid calling this zero-knowledge. While your docs suggest some use of E2EE, there seems to be a significant amount of metadata that remains both unencrypted and unauthenticated.
2. Having read your white paper, it appears your E2EE setup is vulnerable to various forms of forgery. In a simple case, an attacker that has compromised your infrastructure can easily substitute the credentials of arbitrary users in a way that is NOT tamper-evident.
3. There seems to be no post-compromise security. If your user private key is compromised (e.g. extracted from the extension's local storage), there seems to be no way to reset it.
4. The recovery flow is questionable. Do you really want to store critical cryptographic material in plaintext and in a third-party cloud?
When rolling out E2EE from scratch, it's very easy to give rise to issues like #2. At Backbone[1], we've created a framework for building end-to-end encrypted applications with building blocks designed to preserve confidentiality, integrity and nonrepudiatiability under a strict threat model.
Feel free to reach out, we're happy to share how we solved issues like the above.
Thank you for reading through the security paper. Please find relevant points that explains the product security.
1. We have been very diligent and do not expose any sensitive user related metadata in any public api that is unauthenticated. The API's are protected using authenticated session that are established with unphishable passwordless MFA.
2. There are multiple things to highlight here. First of all, the user credentials use client-side cryptography and there are no keys in the cloud infrastructure to decrypt for attacker or even idemeum team. Second, the credentials are protected with AEAD that adds an additional integrity and authenticity check on the encrypted data. Third, we have diligently provisioned the cloud infrastructure using private vpc, subnets, security groups and role-based access that makes it harder for attacker.
3. idemeum password vault does not persist the user key in the extensions local storage. The key is broken into shares using cryptographic algorithm and distributed using multiple parties. the key is reassembled when a sufficient number of shares are combined and is used on-demand when required and discarded.
4. saving the recovery in the third-party cloud is optional. users can choose to save the recovery key in their personal backup if needed.
1. You might want to avoid calling this zero-knowledge. While your docs suggest some use of E2EE, there seems to be a significant amount of metadata that remains both unencrypted and unauthenticated.
2. Having read your white paper, it appears your E2EE setup is vulnerable to various forms of forgery. In a simple case, an attacker that has compromised your infrastructure can easily substitute the credentials of arbitrary users in a way that is NOT tamper-evident.
3. There seems to be no post-compromise security. If your user private key is compromised (e.g. extracted from the extension's local storage), there seems to be no way to reset it.
4. The recovery flow is questionable. Do you really want to store critical cryptographic material in plaintext and in a third-party cloud?
When rolling out E2EE from scratch, it's very easy to give rise to issues like #2. At Backbone[1], we've created a framework for building end-to-end encrypted applications with building blocks designed to preserve confidentiality, integrity and nonrepudiatiability under a strict threat model.
Feel free to reach out, we're happy to share how we solved issues like the above.
[1] https://backbone.dev/