Once upon a time, when the COVID was upon us, I retreated into my lab to write a book on the history of computing. I was fortunate, privileged, and delighted to get the chance to interview some of the people who built the foundational technologies that power our digital lives. People who invented the first data packets, installed the first nodes on the internet, developed the first search engines, and founders of companies that have become household names.
Many from the history of computing began their careers as academics. Their original research was published as they pursued their PhDs. I started to notice some trends. A few notable ones caught my eye (as they pertain to Secret Chest):
- The power of computers has progressed along Moore’s Law since Gordon Moore formulated it in 1965. Which is to say that the number of transistors has doubled every other year since then.
- Encryption algorithms that power the modern PKI stack of infrastructure have not kept pace with Moore’s Law. What Claude Shannon defined as perfect secrecy in the 1940s and 1950s is no longer possible, even though those he influenced, like Hellman, Diffie, Rivest, etc have influenced further generations using his theories. Since DES was introduced in 1975, we’ve just increased the compute power requierd to defeat Shannon’s unicity distance, or the amount of plaintext to derive the secret key. Some of Shannon’s acolytes (and in some cases grad students) even developed other alternatives to secret sharing, but still along the same concepts. However, see the next bullets for why this is no longer sufficient.
- Massive parallelism and grid computing has led to the ability to attack encryption in an asyncrhonous fashion (no pun intended). A grid of supercomputers can reduce the time to decrypt an encrypted database from centuries to years, or with properly balanced workloads, months.
- Quantum computers have become useable. Further, there are universities with super computers and quantum computers that are strung together almost like a grid of computers that can be used to attempt to decrypt data. For example, there are over 100 running in China, including the first to achieve quantum supremacy and Zuchongzhi, one of the fastest quantum computers.
- Post-Quantum encryption research follows the path of trying to build larger and more complex algorithms, which has been the trend since DES was first introduced by IBM at the behest of NIST in the US.
- Nearly every password manager on the market is an encrypted sqlite database. Each typically can be unlocked (or decrypted/accessed) with a password OR a key. Thus, there are two ways to get at secrets that are all stored in one place. One reason for this homogeinity is that programmers get so much “for free” with these open standards and tools. Apple’s keychain, 1Password, Nordpass, and nearly every password manager works the same way.
- Nearly every password manager synchronizes secrets to a web backend, providing 2 or more further potentially compromized locations to gain access to secrets.
- There are flaws. Security researchers search for bugs in code, weak endpoints, and other vulnerabilities – while humans remain susceptable to phishing attacks and other means of intercepting plaintext secrets.
- Our lives becoming increasingly digital and the sense of security of having secrets in a vault means the value of data in a password manager becomes exponentially greater.
- Newer technology like passkeys continue along the Shannon route, where all plaintext required to access a secret is still on a single system. For example, the TPM chip that guards access to secrets can still be accessed with a fingerprint (which generates a key) or a passcode, typically required to be entered at first boot of iPhones, Surface tablets, Macs, Chromebooks, etc. Thus a database of secrets and the necessary components to unlock the secrets can be transferred to a larger system (or grid of systems) to carry out the atomic process of decrypting assets. Further, armed with part of a secret to unlock secrets, the time is reduced to decrypt access to those secrets.
All of this can be interpreted in many ways. While we move the cheese (in terms of how we protect systems and secrets more specifically), bigger keys and more complex algorithms are only a part of the solution.
So all that free time and armed with a collection of academic works from some of the best researchers in history, from Al-Kindi to Florian John Curchod, the Head of Quantum Cryptography Research at Cambridge, we started to think of a new system that broke out of the mold of traditional security researchers. Meanwhile, 1Password raised hundreds of millions of dollars in funding and hired Ryan Reynolds to make commercials. Then LastPass was compromised and we had to reset many of our own secrets. Even Okta has jumped into the business with Okta Personal. All of the existing tools still using the encrypted database that syncs with a web service so all the secrets are in one place modality. But validating the market, and pointing to the fact that the market needs to evolve.
We’ve been writing code and improving algorithms and logic for a couple of years and are getting ready to release Secret Chest. Secret Chest is one of the really old school Dungeons & Dragons spells. You put objects in a box that you then transfer to the ethereal plane. That’s exactly what we do. Also, all of our PoCs, silly microservices, and betas are named after D&D spells (e.g. https://www.nondetection.com, https://www.swiftquiver.com, https://www.findtraps.com, https://www.detectthoughts.com, https://www.findfamiliar.net). But it was important to us that we use the term secret instead of password. Because JWTs, keys, passkeys, SSH keys, etc are as important as actual passwords. And we could imagine some might want to use Secret Chest for the MFA options.
We patented the approach we took in Secret Chest to protect secrets. We use the latest APIs to encrypt secrets into the traditional ECC approach and store them in the same traditional sqlite databases most would expect. However, along the way we split up secrets (or shard them) so we store an encrypted part of each on each device a user has installed Secret Chest on. In the below example, we see a secret with one third of the components required to reverse the encrypted objects into cleartext stored on three devices. Two of those will be required to unlock the secret. That could be my MacBook, my iPhone, or a cloud pin entered on a web page (and so stored on our backend) or entered on an Apple Watch.
Note: Watches don’t have a truly stand-alone secure enclave, so we don’t store any objects on them. They do have a T2, but it’s an extension from apps that supplies data to it, so we mirror the logic from iOS passcodes for incorrect entry to access our backend for a PIN. That means we only ever have one shard on the backend and that the watch supplies that shard by interacting with our API rather than using iCloud Keychain that would potentially place two shards on an iPhone.
No single phase of the process to create and reverse secrets is quantum safe. In fact, I’m not sure that any encryption mechanism today can be considered to truly be such. The atomic process goes beyond traditional MFA approaches, where a key to unlock a secret is provided, or where the software has logic built in not to try unless a second factor is present. Thus, secrets are protected by MFA, but in a way that’s far beyond what traditional MFA provides. The secrets require a user be present and provide multiple biometric (or passcode as an alternate to biometrics) using native technologies and so somewhat futureproofed for zero day support in subsequent releases of operating systems.
We didn’t stop there. We built added logic for sharing secrets, support for different types of secrets (e.g. instead of just passwords, we can protect passkeys), and we developed multi-user secrets, where we can protect keys, passwords, and other secrets in complex devops workflows in a way where multiple humans have to approve a release of software or access to a secret. In other words, we’ve built a quantum safe devsecops workflow to protect the supply chain of software releases.
Those kinds of environments typically require enterprise single sign on. So we support Azure AD, Okta, Jumpcloud, signing in with GitHub, and Facebook sign ins. To make it easier, we stole Apple’s latest design patterns when we copied the look and feel of the home app. To make it scalable and ease our path to compliance we microserviced everything we could on public clouds. To provide enterprise-level telemetry, we added webhook support for every endpoint and robust standards-based APIs and API documentation.
But we forgot about a few basic things – like what happens when a user needs to replace their phone, or it gets stolen. So we’re working on cleaning up the basic stuff right now (although how to replace a full partition of secret data when it’s encrypted and mapped across multiple devices is actually a fair amount of logic). The math is done and we’re almost ready to open up the public beta of Secret Chest. It’s cool. Hopefully not too ahead of its time. And we hope you’ll join us to test it out in the public beta. If you’re interested, please sign up at https://www.secret-chest.com or secretchest.io (there’s a signup form at the bottom). I’m sure we’d be honored to have you. <3