Show HN: TideCloak – Decentralized IAM for security and user sovereignty
github.comHey HN!
After 6 years of R&D, our small team is excited to share our project TideCloak - an IAM designed to help developers move fast without worrying about catastrophic breaches or overpowered admins with keys to the kingdom.
Traditional IAMs rely on centralized authority - admins, root certificates, and decryption keys - which create glaring vulnerabilities in a breach. To address this, we’ve integrated Keycloak (Red Hat’s IAM) with a decentralized key architecture powered by our (academically validated) Ineffable Cryptography.
Here’s the idea: keys are split across a decentralized network (our Cybersecurity Fabric) so no one ever holds the full key. Even in a breach or F$%k up, there’s no unchecked authority exposed.
Right now, TideCloak uses the Cybersecurity Fabric as an IdP, meaning users authenticate without their credentials being stored or shared. Essentially, users bring their own authority - without needing to trust anyone else to keep it safe.
Coming soon: - Identity Governance Administration to prevent super admin abuse. - User-sovereign digital assets, where assets are secured with unique decentralized keys to protect against mass breaches.
We’ve just launched a free developer sandbox, and we’d love your feedback: https://github.com/tide-foundation/tidecloak-gettingstarted
It’s still early stages, and your input will help us improve.
Thanks for taking a look - ask us anything!
What is the "Cybersecurity Fabric"? I see it mentioned a lot, but having trouble filling in details.
Update: I found the answer and the research paper[1]. Based on what I've gleaned so far, this looks pretty awesome. It's like.. Horcruxes, but the participants assemble it blindly and instead of getting a soul, you get access to something without revealing the key.
[1]: https://arxiv.org/abs/2309.00915
Reminds me of this
https://blog.cloudflare.com/red-october-cloudflares-open-sou...
Check how many analogies I managed to squeeze into this thought piece https://medium.com/bugbountywriteup/how-nature-holds-the-key...
Analogy = Nailed! Can we use that one?
Sure. Double-check my lore though. ;)
> keys are split across a decentralized network [...] so no one ever holds the full key. [...] in a breach there’s no unchecked authority exposed.
so shamir secret sharing, which requires users to coordinate to unlock vaults and get tokens, and if one key gets compromised, the attacker still has to solve the coordination problem with a threshold of other key holders. that's within the realm of things we trust today.
there are a few black boxes and flags in the description that would ordinarily get hammered pretty hard by security people who have to make decisions about this stuff, but more charitably:
I'm guessing the fabric is probably a ledger that users subscribe to and that's how it becomes decentralized? imagining how this works, tidecloak adds its fabric as a party to each users (ephemeral?) SSS vault, where the fabric would usually be a centralized dependency, but if the number of SSS parties on the user vault is 3 or greater, your fabric key also requires coordination with another party to participate in unlocking the vault, so it can only participate optionally in an SSS vault decrypt- and probably just for something like a change/recovery operation?
(I'm speculating a bit to draw out some concrete corrections, as the some of those term usages in the description would draw heavy flak in a technical sales or architecture meeting.)
So many great points raised here! Allow me to try and cover as much as possible. In a way, you can say TideCloak uses the Fabric as a key vault for (1) each user's authority (2) its own central authority. This way, even when TideCloak is completely breached, neither its users or own authority and authorization can be compromised. For simplicity, let's call those "authorities" keys. Whenever use of those keys is required, TideCloak makes a request to the Fabric, and as a swarm, the Fabric manifest that request in a multi-party fashion (a few steps up from standard SSS) and replies with the required artefact (access token, ephemeral decryption keys, signed consent, etc) in such a way that the secret keys are never assembled or exposed. Tidecloak itself, therefore, holds no user credentials or root certificate, so a breach of the IAM or an administrator is far less consequential. That API request is, for all intents and purposes, the coordination you mentioned. The Fabric is a "centralized dependency" as much as DNS is, or the internet. Yes, without the Fabric, those vaults are inaccessible – but the Fabric is robustly highly-available and resilient. Regarding the potential flak you mentioned, if you meant from describing the technology in high level terms, noted! If you meant because the approach we’re proposing introduces (and requires) a shift from today's paradigm, I think you’re devastatingly spot on. We’re expecting this concept to attract pushback, because it demands relinquishing centralized ownership of those authorities to some "ineffable" vault that no one can access. It's a big ask – but, it's also the only guarantee that if no one can access it, it can never be compromised. In my mind I’d liken it to the objection "on-demand hosted" architecture attracted in the early 2000s, which later became the ubiquitous "cloud". We can't avoid the resistance to change other than by continuing to push forward with the help of the significant academic scrutiny we’ve received to date, and the tailwind of a community interested in advancing it through participation.
Thank you. The challenge here is how to trust it. I think leading with stating that this is a paradigm shift is key, and then it's important to show how it pivots from first principles. Right now, the description has what appear to be proprietary product terms (fabric, ineffable, etc) where ordinarily there would be some more familiar terms of art from cryptography.
How much of this is net new, and are we asking people to suspend their disbelief?
Not sure how to quantify "how much is new" as like all other breakthroughs are "built on the shoulders of giants". I'd find it almost impossible to answer that same question accurately if it was asked about something like Kyber (Post quantum cryptography) - which would probably be newer than Tide. A proper answer would require quite a lengthy seminar, I'm guessing. Your last question is a fascinating one and the answer is: no. We're not asking people to suspend their disbelief. On the extreme contrary: we'd encourage them to challenge it as much as they should challenge their current beliefs. Today's automated belief in all existing Zero-Trust vendors may be misplaced/misguided. The blind beliefs in all IAM vendors should be re-examined. We ask for people to question their automated belief in the integrity of processes such as: "JWT introspection" where the same entity that generated an attestation is now requested to validate it, or if an OIDC connection is "secured" by a shared "client secret", there's no need to verify the JWT signature, or it's safe to send passwords over HTTPS because it's secure by SSL, or it's safe to store passwords on a server because it's hashed and salted, or passkey is foolproof because it's stored in the TPM, etc... How many of these beliefs are verifiable to the end-user???
How does TideCloak's decentralized key architecture relate to W3C DID standards [1]? Do you see TideCloak aligning with DID Core principles in future development?
[1] https://www.w3.org/TR/did-core/
Yep - there's already a working group in the Keycloak community aligning with various standards. In our case, the Cybersecurity Fabric is the component that handles ownership, secure portability and revocation.
> Web users can now sign up and sign in to your SPA, being served customized content to authenticated and unauthenticated users and based on their predefined roles.
They're not really being served customized content, are they? All the content is in the react app - so client side - even if not logged in?
I suppose one could argue the authz details are "served" based on login - but the example could really use an example of api/db access unless I'm missing something?
You understand it perfectly. This is an example of an SPA that displays content based on authentication/roles – all client side. This was to demonstrate the simplest, most straightforward implementation in a few minutes. If you look closer, the authentication is secure by a signed-JWT which can easily be extended to server side content customization and direct api/db access. Developers in our beta program are already doing this across ReactJS / NextJS / Java / Dotnet / PHP/ Etc.
Right. I hope the example can be extended to include a sample api service - as understanding how to verify the jwt, check blacklisted tokens are essential to actually using this.
I'm worried junior devs might look at such examples and believe it is real code.
That point is pure gold! This is such a critical aspect that we hardly see addressed even in the leading platforms. This exact sentiment was the drive behind our SDKs primary premise: Assume a breach! Assume an error-prone junior dev. Assume belief an example code is real code. We aim to have our technology protect user's authority/identity from buggy developers. We want to protect the organization's systems from mistakes the developers or administrators have made. We aim to protect companies from themselves. Our documentation is in its very early days. We've got the technology, but we don't have a (much needed) sample api service yet to demonstrate how the dev DOESN'T need to verify the JWT or qualify against blacklists (the SDK will do it), DOESN'T need to worry about session hijacking, etc. But that's exactly what we're working towards.
A common weakness in schemes like this is that the user has to trust that the decentralized network operators don't collude and don't all have the same vulnerabilities.
Absolutely true! And that’s only half of it. In schemes like this, how can you even tell the operators are following protocol? How do you know it's not a façade? At the edge of all those schemes, there's a point where you simply must rely on blind trust. Solving this challenge was one of our greatest motivations – and the only way to replace blind trust is through total verifiability. As far as we’re aware, our approach is the only one that allows verifiability on all facets: 1) access to source code, 2) having the ability to verify client-side code in run-time is another (in two different ways), and 3) last, but most important, anyone can opt to run parts of their keys on their own privately hosted nodes – so even if the entire network is colluding, you have the guarantee your own nodes aren't. Happy to elaborate.
Given that IAM is used by cloud providers as a lock-in mechanism, how do you plan to get them to allow users to use your IAM? Or is this not aimed at that market?
Congrats on the launch!
Thanks. The ideal end game is for the Cybersecurity Fabric to become a de-facto standard for best practice security inside the biggest platforms in the world (Entra, Okta, AWS, Google etc). So individuals can login with Tide (i.e. with their own authority). The protectionism only works until one plucky provider decides to use an open standard and starts winning business from the others... But let's assume that's years down the track, if we're right about that.
For now we're quite happy to provide an alternative for platform developers not bound to the big end of town.
The TideCloak (Keycloak) component does provide for options like federating or synchronizing with other IAMs in greyfield enterprise environments, to stage the integration.
Is the Cybersecurity Fabric an open standard? I didn't see any licenses in the Github repository. Is Tidecloak just an implementation of an open protocol? Or is it entirely proprietary?
Tricky question, because the answer to this will evolve in time (as planned). First, thanks for pointing out the license issue on Github. We'll fix that right away. The Cybersecurity Fabric operates based on the Tide Protocol: our WIP open standard. TideCloak is exactly that: just an implementation of that protocol on a Keycloak IAM. The protocol is "source available" but "commercially restricted" - similar to the BSL modus operandi. It'll take us some time to properly document that protocol to a level adequate for release - but in the meantime, we'll provide office hours and direct interactions with the community to share that knowledge.
Amazing. I wanted this, but didn't want to build it.
You did.
Thank you!
Cheers! The idea is that anyone can tap into the Fabric, but also participate in it (coming soon)
Are the encryption quantum safe?
The multi-party-computation and zkps used to generate the keys, authenticate to them, encrypt / decrypt and sign with them are PQ resilient. The key presentation layer (i.e. the key standard we've currently deployed) are elliptic curve based, so in theory would be susceptible. We're already working on other key presentations, including PQC algorithms, all handled in multi-party. We're already able to manage SSH keys in the Fabric.
They're working with a quantum safe research team from Wollongong Uni to create a quantum safe key. The whole scheme by itself is based on shamir SS that is quantum safe.