OpenSigner: Open-source non-custodial key management

Transcript

Okay. Hey. Hi everyone. This is Joan from OpenFort. You have to excuse a bit my voice. I'm a bit cold. Um so I might just like take a couple of like sips of water between the presentation. Um I'm here to introduce you OpenSigner. This is a project we've been working for the past 6 months, give or take. Um and it's implementation like a key management implementation that we use also internally at OpenFort. So, yeah. OpenSigner is a open-source self-hostable key management solution.

And so, when we sit with our team a year or so ago, um the space was already like pretty developed with a lot of um solutions in the market that were going through, okay, how do I make my users sign in through applications in a smooth way, embedded wallets, cross-up wallets, global wallets, like all this jargon across, hey, we actually want to abstract as much as possible the whole management of seed phrases, passwords etc. Um One of One of the main problems that we saw with the this, um you know, solutions today is that for the most part, they all lock you down into a specific architecture.

Um And so, when we sit with the team, we're like, okay, what are the components that we see in today's wallet that are actually required for you to abstract as much as possible from the user while keeping as much sovereignty on the infrastructure to offer that that service. Right? Um And so, here I basically outline some of the criterias um that we decided to follow, one being yet as little um you know, vendor lock-in as possible. Obviously um you know, being custodian is pretty straightforward, but like offering this at like at the minimum requirement of like being non-custodial is like extremely critical.

Um and then one of one of the parts as well um or like how we decided to um design OpenFortress sorry, OpenSigner as well is that um you know, we wanted to be as agnostic as possible to any sort of solution that existed today. That means that you could actually use OpenSigner in any chain, that you could actually use OpenSigner with any auth provider solution that you are familiar with etc. And so this is kind of like the checkbox that we kind of like uh you know, been trying to develop towards and kind of like been very um you know, pragmatic and strict to to comply.

So obviously MIT license, so anybody can just like free to like work um self-host in any fashion that they want to. They don't have to ask uh or you know, um any license around it etc. The other important part obviously like keeping as much as possible the non-custodial aspect of it. I think you know, one of the like when you spend um some time within like the wallet infrastructure space, you actually realize that the um it's kind of like hard to see what parts of this architecture of people like of other solutions are actually custodian and what parts are not.

To give an example for instance there were some um you know, projects that on paper um you know, when you look at the how they manage the key um like the whole splitting, like different nodes etc. etc. makes sense. But then when you specifically look at like how do they authenticate these users first within their system, you actually realize that because they control the authentication provider, they can actually issue any sort of like JWT token that they wanted. So they could actually re-authenticate themselves uh within their system and actually extract any keys that they wanted. And then this was like completely unrelated to the key management that the system had in itself. It was just on the authentication solution. Right? So

there's like a lot of nuances on like how you actually apply and like plug and play these different systems. Um yeah, and the last of it is kind of like being chain agnostic. So today we've tried um with different like signature curves. So you can have Ethereum one, Solana. We also be like a proof of concept on Bitcoin etc. But that's kind of like the idea of like how we landed to open signer. And so one of the obviously um the we're going to get a bit deeper on like how technically looks like and how we kind of like create the recreate the private keys etc. The one of the key primitives that we we we build open signer on top of is the Shamir Secret Sharing. So this is like a very kind of

like old battle-tested algorithm to split private keys or like any other any other set of like secrets. Um we also build on uh you know, good ideas within the space on like shoulders of of like giants. For instance, on the self-hostable part of it, if any of you have been using Signal it's like a very like the the approach to you know, the way that they encrypt their their secrets is pretty straightforward. It works pretty well cuz they have an entropy that they ask to the user and then they store that secret um within their database but without your entropy they can basically do nothing. This is like a very simplified version of it and you can do the same with wallets by asking the user to put like a PIN code or

or a password. But in either case, these are like like different design spaces that later on can be applied to to wallets as well. Um and yeah, we we also audited this with with Quantstamp for people to use. All right. So the way that open signer works is that we have different components of it. One is like all all obviously like you can self-host and we're going to get into this. But like one it's uh iFrame. This is basically where the private key is created and split. And then that uh split of the private key, which I think I have somewhere else. This uh create like this is split of uh private key is then stored in like these three different components. Um

one is the local storage, then you have the hot storage and the cold storage. So, what what the what does it mean? Like basically, hot storage is the place that um you know, you would have your own like Postgres uh SQL um database. It's a like in itself, it's share, it's like a completely useless. Like you can't do anything with it. So, this part is like the hot storage in itself like you can you can build your own implementation. We have a sample implementation on Go with like you that you can use, but um you can build it to like depending on your own authentication solution that you want to use. So, if you're using Firebase, better off, etc. etc. You can or like just a simple email password. Um you would put like a you you would store it in that database. Um then we have the

cold storage, and this is basically where we put as much kind of like attention as possible because the way that um it works is that once you split this private key in three different uh shards, the cold storage becomes kind of like the the weakest point because if you want to self-host, um if you want to self-host, the the cold storage needs to be the place where you actually either encrypt one of these third uh recovery shares with the user's password or um you know, you you basically um or you basically can encrypt that like using other methods like what we look at the passkeys, uh PRFs, and and things like that.

Now, the way that uh so, we just talked about how we are creating like uh this uh you know, these keys on the iFrame, and then you split it and store in different places. But, the the the the the crux of it all is like how we actually this this this uh this wallets, right? So, a user first logs in into the into the platform. You create a passkey. You want to sign something. Then you use the hot storage and you use the local storage. Two out of three and you create it and and you sign the transaction. All good. What about you know, recovering this pass like this this this this private key? Well, to recover this this private key, then we'll use just the hot storage and the cold storage. Now, the way that we

recover the the content of this the hot storage is by like an an open signer offers three different methods. The first method is the password. So, it's basically the user saying, "Hey, my PIN code is 1 2 3 4." Please don't do that, but you get the point. And so, once you you encrypt this, it's a stored on the on the cold storage and then obviously no one no one can no one can see that and touch it. Then we have an automatic method. This is like a more um how to say like more complex method that's more variables, but um it's also an interesting one and it's basically using the encryption that the developer like an encryption the developer gives us from their own back end and an encryption that comes from the cold storage in itself. Now, if you are

self-hosting, the automatic is a bit tricky because you could technically reproduce the private key because you are self-hosting the hot storage and the cold storage and you are seeing those those those secrets from the from the developer's back end, which is your own. Um what we do to mitigate this part is basically offering um like an OTP validation. And so, with the OTP validation, basically the user needs to put like a one-time PIN on on on the recovery kind of like user flow. And so, in that case, we add like an extra layer just to validate that, "Okay, this is the user actually asking to recover the key. It's not the developer doing it on in itself." And then the passkey is the

one that I'm really really excited. I did like probably many of you are familiar with like faces at face ID um or similar methods to unlock the the the device. But there's like an extension of passkey that is called PRF. And it's actually super cool cuz it allows you to actually encrypt data. And so you could actually like for devices that uh which today is I think like most all or all all the Android and Apple devices, you could actually request the user for a passkey uh signature that encrypts on device on local the um the the the the recovery share. And so you can just save that recovery share

encrypted with passkey from the local from from the close uh from from the close storage directly. And this is actually like a super cool method because it beats the other two out of the park. One because you don't need to actually remember as a user what's your password. Like you know, you don't remember if it's like 1 2 3 4 or 8 8 8 8 or whatever. And also because it has no dependencies. So literally even if automatic is better for the user ex- from a user experience because you encrypted directly with the shares that I was mentioning on the back end, you have zero dependencies with any other part of the system.

And so it's the one that I we actually pushing like any developers to to adopt and start using in. The only um you know, caveat with passkeys which is still like a um kind of like a being pushed uh for the ecosystem to adopt is that some um secret managers are not working very well with PRF. So if you use uh LastPass um or similar secret managers, like it sometimes it prompts like errors that they cannot uh work with this with this sort of like encryption.

And so uh it works though very good natively with um Google um password and Apple password. So it's it's it's getting there. Then this is just like a Well, I mean, a very self-explanatory architecture diagram. What What I was trying to explain here is like if you go from a mobile app or a web app, um basically the flow the flow of um you know, key management here would be that the user um logs in. From the login, you go into I mean, logs in into a not service that you can choose. Then the auth server like the auth service basically validates that the user UID um is correct on your database and it passes well with the JWT token. Once the

auth and validates this, it creates the private key and it splits it in like these three shards that I mentioned before. And so, the first three shards goes to the auth service, the hot storage, and the cold storage. And so, basically the idea here is that you always would need like a two out of three in any sort of like like in any sort of like shape or form. And so, for the first time that you are creating the private key, the the way that you would be signing is usually using this this two. And the reason you're using this two is very straightforward. It's because um it's way faster to do a two out of three of a method that you have on device and the one that you are authentication that basically reaching out where like in whatever region or or geography that you

have your cold storage. But if you are recovering the private key, then you would be using just the hot storage and the cold storage because on every single process, the auth storage is basically discarded. Like you don't store the the the auth storage uh on device. Like every time that you just um you know, stop doing something within the app, then the auth storage is removed. And so, you uh you'll have to like regenerate it and recover it again within those two. Then then stores the the new generated storage within those.

Wait. So, here um yeah, I'm I'm just trying to outline as well like kind of like how OpenSigner um you know, stands across like other solutions in the market. I think like the like for me and like for our team, the most interesting aspect of it all if you if you're thinking on on the long term is like how much locked in you are within a wallet system that you might be using. Um and so yeah, like I want to stress very much like the whole vendor lock-in and like being MIT um that anyone can use. Th- This is actually very important because like the more I I like as this as the as as the space moves more compliance and like

more enterprisey you get like some requirements from people saying, "Hey, you know, I actually want to understand the system. I actually want to host this part of like some part of the system within my within our compliance kind of like buckets or compliance um you know, sandbox." And so this this sort of implementations do a good job at allowing that. Um versus the other part where you probably have to go like, "Yeah, let me show you like my you know, SOC 2 certificates. Let me show you like all these uh different attestations that I can do etc. etc. which I actually without actually accessing the the the you know, the system in itself. Um and then yeah, the the other the the last part that I want to mention here is

on the signing cost. Um Sorry, the the signing bit and one of the because you are actually self-hosting this uh this system, you actually can decide where the replicas of the cold storage live. And so in an event of uh you know, if you're targeting a specific geography of users, then it wouldn't really matter because you have the cold storage within like a specific geography and then it's completely fine, it's completely fast. But it as you like uh grow within like a different geographies, you you actually distribute this uh cold storage within like different geographies and actually beats most of you know solutions out of the park because for the most part all these um

you know all these services like all all other you know wallet infrastructure solutions will say like yeah if you want to have like this specific um you know SLA or if you want to have like this specific performance and you have to go into like an enterprise deal and like you have to pay as much etc. etc. With this system you like you literally just have like the cold storage located like co-located in whatever server um geography that you need based on your um you know on your on your user behavior and it's kind of like almost free like it it costs nothing to store like a cold storage is like a very simple database as a matter of fact. And so that's also like a very interesting value proposition of OpenSigner.

So yeah to recap um pretty much like the way that we design OpenSigner again is like to be completely non-custodial so you can offer a very smooth UX um with familiar methods etc. at the expense of not having to deal with like all the private key and like all these yeah all all all the issues that happen to go with that. It's designed to be zero locking so I mean I I didn't put like a the code block but because I usually find it just loses in these type of situations but like you can literally it's just like a docker file then you can make run like the docker file within an instance and just start using it. 10 MB and then it goes extremely fast if you co-locate it in whatever geography that your users

are. Yeah that's it. If you enjoyed it please fork it use it give it star. And uh yeah thanks thanks a lot for for your time. We can take some questions right now. We have couple of minutes. >> Thank you. One question, if you fear losing your passkey device, which I do, can you have two of them like one or the other for recovery? Yeah, so usually passkeys are linked it's our domain bound

encryption methods. And so for the most part if that like I'm assuming you have let's say you have like a an iPhone and that's where like you store the passkeys or something similar. Like usually these iPhones they have like their backup within the iCloud. And so if you buy another iPhone and like login or like if you go through a computer and you login through like your Apple iCloud account, you're you're good to go. Okay, well but if if I have a FIDO key, I lose it or if it's on Windows Hello, I reset the NGC. So that's Yeah, that would be So what's your solution? Yeah, that that would be problematic for

in that case what we usually like the end state of this sort of solutions works towards either social recovery and or the ZK email. And so the idea here is like once you have this EOA then you probably go to like you want to go towards having a smart contract wallet or something similar. And then it's like through within this this a smart contract wallet that you would just regenerate another signer and then you're good to go. Like the best developer practice here is like you have this implementation that gets you like 95% there. And that for edge cases where you want to start like when you actually have a lot of money and things like that, then you're probably already using like a multi-sig.

And if you don't like you should. And then in that multi-sig you just like regenerate the signer that that that you lost and that should be good. We can take one last question. Um hi. So, you mentioned PRF and and and and biometrics and that you're excited about it and I share that sentiment. It's just um I would like to echo what what the other gentleman said. Like there is actually um a point of friction at the moment, right? That that that the that the biometrics and PRF in general is is super tight to the ecosystem. So, like if I have a MacBook and I have an Android phone. Yeah. Like I can't really seamlessly and it's not

about a recovery. It's just about like you co-using them at the same time, right? Like how do you eliminate that point of friction going forward so that I can I don't have to regenerate the signer, but I can like seamlessly use both at the same time. Yeah. So, my experience with this um there's a an improved version of passkeys that like a WebAuthn improved version that are that are that are like like they're discussing within the community now that what they're actually doing is like tackling this a specific issue that they want to be able to migrate the domain bound passkey to whatever other domain bound that domain bound that you want to use. So, in theory like this is something known by the community already and so they're working towards making it more um portable. Does that make sense?

Um again, like it's not there, but I still I feel like for the most part whenever you start talking with the actual users um like any kind of like security option or like security setup that you have brings some good solution, but it also comes with like some like for instance, passwords are great, but like people are forget PIN codes. Like people forget long passwords and stuff like that. So, everything's kind of like on the step towards like going to that direction. And so with in the case of WebAuthn, it's kind of like the whole um I I don't remember the name of like the association that like is FIDO or something. I don't I don't remember, but they're actually working towards like this portable um um characteristic or like feature of

Husky. Yeah. So, thanks for presentation and thanks for coming. Yeah, thanks guys.