Customer data security and privacy have always been at the heart of Dashlane. Our core security principle is our zero-knowledge architecture, which ensures nobody can access your data except you. This feels simple, but it’s actually pretty complex to implement in a product like Dashlane. Our security white paper goes into details about how we address that technical challenge.
Why we invested in confidential computing
As our customers and our business evolve, we have to constantly innovate to address new needs. For enterprises, one challenge we faced was how we could integrate with SSO providers in a secure but convenient way for our IT administrators. We tapped into the technology of cloud secure enclaves and confidential computing to unlock that problem and build the best SSO integration among our competitors. We branded it Confidential SSO in recognition of the power of confidential computing.
Read more about our solution in this AWS case study from Amazon.
Most of our business logic is on-device in the client applications (Dashlane browser extensions and mobile applications). This is where we encrypt and decrypt vault data and where our clients use their master password as the key to their vault. No data is ever transmitted in clear to Dashlaner servers, which ensures we can’t access it and leak the data.
With confidential computing, we were able to bring the same level of on-device security to the back-end. The secure enclave is a black box for Dashlane, similar to the customer’s device. Even though the cloud secure enclave is hosted in Dashlane’s AWS infrastructure, no Dashlane employee or third-party can access it. Thus, Dashlane can process customer data securely and privately.
Continuing the journey
In 2024, we’ve been doubling down on our confidential computing investment. It provides us the right toolbox to process and share sensitive customer data while maintaining our zero-knowledge architecture. In an enterprise environment, this is critical as we integrate Dashlane with all the main solutions in our business ecosystem: identity providers, SIEM platforms, messaging providers, and more.
We filed two patents with the USPTO on our unique approach to leveraging secure enclaves. In case you’re curious, here are the references (but it’s a boring read, honestly):
I’ll illustrate the purpose of these innovations with a few concrete examples.
Confidential SCIM
Similar to our SSO integration, we wanted to offer a secure, user-friendly way for IT admins to provision and deprovision users and groups. We already had a SCIM integration, which relied on IT admins hosting a back-end component in their infrastructure, the encryption service. By moving key processing from the encryption service to the cloud secure enclave in AWS Nitro, we were able to reduce the admin’s workload while maintaining security.
SIEM integration
Our larger customers usually aggregate logs into SIEM platforms to have a centralized view of their systems. We made two choices in how we built our SIEM integration for our customers:
- We decided to use a push approach. Dashlane is pushing logs to the SIEM systems. The benefit is that admins have nothing to do on their side to “pull” the logs.
- As we push the logs to an external system, we want to maintain our zero-knowledge architecture and an encrypted flow of data. Yet again we leveraged the secure enclave for that purpose.
Tapping into Slack to nudge employees
It’s relatively easy to build a Slack app. There are hundreds available. It’s way harder when you want to include sensitive and private data in your Slack interactions without ever being aware as a service provider. In our context, we wanted to notify employees that they have compromised, weak, or reused passwords on specific domains. As we were building our Nudges feature and our Slack integration, we used Nitro to build a secure tunnel.
Our secure enclave is responsible for:
- Storing information about compromised, weak, or reused passwords
- Managing the keys, allowing us to send Slack messages to employees
- Making calls to the Slack API
This allows us to notify employees they have a compromised, weak, or reused password on a specific domain without this information being in our back-end infrastructure. In addition, someone accessing our back-end infrastructure cannot send Slack messages to employees on our behalf because secure enclaves are not accessible.
Making passkeys even more secure
Dashlane was the first credential manager to support passkeys on all platforms. Passkeys use public-key cryptography in which the private key is securely encrypted in the Dashlane vault, while the public key is stored with the service associated with the credential. We’ve been considering how to store passkeys in an even more secure way and, in particular, mitigate risks in case the device gets compromised.
We’ve also been experimenting with storing the private key in the secure enclave instead of the Dashlane vault.
What’s next?
Since we started leveraging cloud secure enclaves in our product, we have multiplied our usage by approximately seven, and we expect that trend to continue.
We have many more ideas for the future, such as how we could process data insights in the enclave regarding private and sensitive company data. This is a similar concept to what Apple is doing around data privacy. It’s still a fairly nascent technology, and we are just now seeing its potential to reinvent data privacy and concepts such as zero-knowledge.
If you want to dig deeper, read our Dashlane Security Principles & Architecture white paper.
Sign up to receive news and updates about Dashlane
