Ethereum Foundation DevCon 6 - Security Track, 15 Oct 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Time-locked Recovery Factors for Secret Sharing by Leonard Tan | Devcon Bogotá

Description

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/time-locked-recovery-factors-for-secret-sharing/

Verifiable delay encryption allows us to construct time-locked secret shares which reveal themselves after some time. Paired with share refreshing, this allows users to automatically recover their account after a set amount of time even if they have lost secret shares, without compromising key security. Setup requires no user input which allows for a streamlined UX, and we show a demo of this functionality by generating and recovering a private key using this technique.

Speaker(s): Leonard Tan
Skill level: Intermediate
Track: Security
Keywords: Secret sharing,VDF,key management

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers.
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

A

A

Recovery factors um it's going to be kind of interactive, um we'll do some thought, experiments and we're going to start with like a toy problem and then a toy solution and let's see whether we get something that works. So what are we really talking about? What we're trying to solve right?

A

The main problem I'm trying to solve is that c phrases are bad right and C phrases contribute to loss, teff and even terrorism and seafrases are like a very long password right, they're easy to use uh easy to lose sorry easy to compromise, and basically we write it down. It's like you know, um writing a Post-It note, that's you!

A

Basically, when you run out of C freeze and what we should really be using is multi-factor authentication, right, NPC or multi-6, and why we should use it is the outcome of Decades of evolution and user authentication right. Since 1986 people have been trying to push uh multi-factor authentication and it works, it provides better security, prevents phishing attacks and is relatively easy to set up. So hopefully you also use this after this talk and let's just talk a bit about NPC and multi-6.

A

So um most of you guys are probably familiar multi-6 and maybe a bit about NPC and both of them have very similar properties right um they're, both better than C phrase. They are more hack resistant. You have to compromise multiple factors before you lose your account, um there's better redundancy. So if you lose one factor, you're still, okay and that's also the possibility of additional checks right, like a daily spending limits, for example. But there are some differences, so NPC is off chain multi-6, usually on chain as a smart contract.

A

um So multi-six can support much more complex access structures. Think, like organizations right thousands of people trying to vote for something, um whereas NPC usually costs less to deploy and operate because of chain. So there's no gas multi-6 also have trustless access to on-chain state, for example, um pricing from dexes, as well as like limits based on block time, um whereas NPCs cross chain, but actually you can use both right.

A

um One is probably more useful in, like a large setup and one's probably more useful for personal setup, so NPC is probably more useful for personal setup. So I'll talk a bit very briefly about NPC, because we need to understand this before we talk about um even multi-6 and how to use recovery factors. So first we need to understand how to share a secret key right.

A

Imagine you drew a line and the Y intercept represents your private key right now you draw three points in a line, and then you erase the line right and with one point: if you only have one of the points you can't redraw the line right, it's not possible. Any number of lines could pass through it on by two you can you can redraw the line and recover your key? This is basically xiaomi's secret sharing, um which splits a private key into multiple shares and by tying each share to some user Factor.

A

We can get multi-factor authentication on private keys and where does NPC come in NPC does all of this except there's no line drawing, and basically it avoids a single point of failure, because, when you're generating a key, if you're, if your device is compromised at that point in time, the key could be stolen, whereas NPC just does that in a distributed way for today, we'll just limit the scope to personal key management, but of course you can use NPC for other things as well, managing it in like an organization if you wanted so the Crux of the problem, and what my talk is mainly about is there's this binary dilemma right between non-custodiality and custodiality.

A

What do I mean right? We say a key is non-custodial if a user has full control of the majority shares, so let's say you had three shares right and you require two of them to reconstruct a key as long as two of them are fully owned by the user.

A

It's considered non-custodial since the user can easily move his key as well as use it, but no other person can control the key, whereas aqui is custodial of third parties, which we call custodians right have control over a majority of the shares, and it's pretty obvious that the above are exclusive properties right. You kind of like two majorities, so either get non-custodiality or you get full custodiality and there's some special cases like if the user owns a share Enterprise share, but let's not think about that for now.

A

But realistically would it be nice if we have something better, ideally right. What I really want is that my private key should be non-custodial all the time until I've accidentally lost all my factors or you know, touch food I die. Then it's somehow you know transitions to become custodial right so that at least macro to assets can be retrieved, sounds impossible right.

A

Okay, let's try and solve The Impossible time lost secret shares. So, firstly, before we get into that right. What is a Time long?

A

um It's basically something that takes a long time to decrypt the multiple variants right, if you guys have been following the merch, um they use verifiable, delete functions uh and all that, but we are just going to use the most basic one which is repeated squaring and realistically it really doesn't matter what you use just think, it's locked for a long time. That's what matters right and you know what? Let's just do this right. Let's just have an extra share right. We have three just now. You require two to redraw the line.

A

Let's just have one more right, one more this time. Log and let's say your house caught fire, you know and you've lost both your laptop and your phone, so you lost two factors: uh they're now, Ash and but luckily right, you've prepared ahead of time. You generated a four share, the time lock for like one month and you put it somewhere other than your house, so it didn't catch on fire.

A

You put it in public um in a month's time it unlocks and with your other share, which is like an email share, you can get back your key perfect, not really that doesn't work. So, let's see why right the problem is that now you're, just one compromise, Factor away from losing a key, so let's say it as a patient attacker adversary, just waiting right, he just Waits a month.

A

Well, your time of share will eventually unlock right after a month and remember it's in the public domain, because it's not your house, someone could access it and then they just need to steal any one of the factors right to get a key. So basically you go for 2fa to really one fa. So that's no good solution. Two! Let's improve that right. Let's do time. Log shares with key refresh so once again new content right. What is key refresh um for those who don't know.

A

Basically, a key refresh is a way to refresh the shares of a SQL share secret sharing, while keeping the private key the same. The private key here is the star right, it's the star, so there's a private qcm and the way we do it is kind of you just draw another line. That goes through the same point, the same y-intercept, which is a key, and then you get rid of the old shares.

A

Basically, all the shares are different, but your key is the same, and the point here is that as long as you don't lose two factors on the same line right, you don't lose two factors before you did a q refresh. Your key is safe right because, even if they compromise these factors, they can't redraw the line impossible and the two lines are completely unrelated. So that's what key refresh does um there are a lot of protocols that do that today? But please don't do it like this there's a lot of other stuff. You can do.

A

Please don't do that in production. So now we have some idea. What key refresh does what, if we just keep refresh before the time locks up right? So we do a key refresh whenever you use a wallet, maybe once a week the time loss one is like a month right. So as long as you use it once a week, you're fine. So when you use it, you do a key refresh. You give out the shares, even when the time lock share unlocks right.

A

The attacker can't get anything even if it steals another Factor right, because he can't get back um the line. So you can't get back the same line, so it seems like a safe right and this seems to work right. The setup seems to have a lot of properties that we want during normal operation. Attacker can solve the time log, but I cannot use the other shares since key refreshes occurred. It's on a different line, there's an interesting property here.

A

So if you guys have been following time, timeline research and like verifiable, delay, encryption um you'll know that there are some research being done, there's some research being done on homorphic, Tunnel puzzles and all that um because it makes it cheaper. But in our case, actually it's good that it's expensive. It's a feature. We want it to be expensive because we don't want attackers to be getting through the timelock easily or even people do it parallely, and in the case, when you lose your key, you won't mind doing the work, so it doesn't matter.

A

The expense is not wfdo.

A

um So during normal operation, you're fine, but if you're a catastrophic loss right, you lose all your user factors, you I, don't know somehow lose all your user factors, then, if the time loss share is reviewed and um share, refresh won't happen right because you didn't have your shares, so you can't share refresh. Then you can use the custodial share with the email share and the timelock share to reconstruct the key.

A

So it's kind of like a Deadman switch of a smart contract wallet except it's done in NPC, so we've created a non-custorial setup that degrades in the custodial setup on loss. But that's it. Thank you. No I'm kidding this this kid. There's this four holes there's no way that's gonna work right. So, firstly, what happens if a phone share is stolen, then the timelot shot unlocks. Let's consider that right, so your phone chair is there, it's been stolen right. Someone just stole your phone.

A

Well, what are you going to do well, you're, going to key refresh right. That's the only thing you have protecting.

B

A

Shares you're going to keep refreshed. You bought a new phone, so you're a new show on that phone perfect, but the attacker and the hacker who like and hood and teeth who stole your phone, is not going to actually delete the shares. There's no one turn and when a month passes and the timeline expires, he's going to be able to steer key gone terrible.

A

Okay, maybe what we can do is stop making more shares right. The reason why this person was able to get a key was because he had more cryptographic material, so we're going to do is instead of having more shares. The time of share itself is just going to be my phone share right, so this person stole my phone and then he gets.

A

The timeline service is also my phone share, so he doesn't really get anything new, so I'm safe, uh not really, um if you store your laptop right and the timeline unlocks you're running the same problem. So it looks like we're in a dilemma here right. What really can we do um a new solution right? Let's split the device share into a time, lock, share and then a custodial sub-share right. So how does that look like? How does that look like?

A

So what we're going to do? Is we have this initial setup right, two out of three factors: you have an email, login, a phone uh and a laptop share so that they actually start based on these factors and we're going to split the phone factor into two sub shares. Let's explain it to and one will be time locked and the other will be encrypted in your email right.

A

So this way, let's say if someone's used any of the factors and they get a time of share, they still have to compromise another factor, which is your email right. So key recovery still works. If you lose everything you still have, let's say you lose both your phone and your laptop it caught fire in the house right.

A

um You still have the time lock share and the email share which you can use to reconstruct your phone share and- and you already have emotion, so you can redraw the line right so you're, still safe from catastrophic loss but adversary. Can't actually get your key unless he also compromises another Factor, so you still get the two fa properties perfect, but it's also another problem. The email provider might not delete shares during key refresh. Let's see why that's a problem, what happens if, let's say the email provider doesn't delete shares right?

A

So let's go back to the scenario right. You do key refresh right and the email provider instead of doing key refresh properly and during key refresh you're supposed to discard the old shares. He doesn't just keeps the evil share.

A

After all, why not? Why shouldn't he keep it well after a month, passes right. So, let's go back a bit after a month passes right! This is going to unlock right. The time launcher is going to unlock and it's going to reconstruct the phone share on the previous secret, sharing polynomial and reconstruct your key. So, even though you refresh your shares, this is still a problem as long as the custodian doesn't delete the share right. You still have this problem where, when the time log expires, the custodian can get your key foreign.

A

No custodial factors- let's just get rid of all the custodians and third parties, there's a problem. There, though we're trying to solve for the disaster case when you lose all your user own factors. Do you really want all your factors to be lost, because if they're, all user owned and something happens to you, such that all the factors go away, there's going to be no way to recover a key, and this problem is really less of a problem than a statement.

A

It's not possible to get recovery from catastrophic loss without third parties having at least threshold minus one shares.

A

Let's see why, right, um fundamentally, if custodians only control- let's say, threshold minus two Which is less than threshold minus one. um With a Time log shared that unlocks after one month, they will only have threshold minus one right, so threshold minus two plus one. So we only have special minus one shares which is not sufficient. It's not going to meet a threshold so because it doesn't mean the threshold, you need some other Factor.

A

You need some user owned factor and that's impossible in this scenario since we're assuming that the users lost all their shares, so they can't access anything. So we haven't really solved a non-dilution problem. Remember this solution of removing custodians was to get rid of the non-delision problem, but it's a non-solution, so we haven't really solved the non-dilusion problem right.

A

um We still need third parties to hold threshold minus one of the shares, but we can't guarantee deletion so in one month the custodian might be malicious and it'll still the key.

A

We have a final solution for now, one of end deletion.

A

So there are many forms of trust right and the best kind of trust is like trustless right, zero of n, but there are also other trust factors like U of N and one of N, and maybe so like half you know, majority of n um and one way to do that is maybe there's a way to make it such that we can delete the factor if at least one of the end of the parties follow the rules. So what we could do is right. We could have the custodial software.

A

Be further split across a hundred independent custodians like Guardians and trust that one of them will delete it during the refresh as long as they do, the key material is gone. This isn't ideal right, one or n is not as good as zero and trustless, but it's close enough and the cell gets bigger. 100 000 is actually pretty close to trustless and also doing NL and SQL. Sharing is very fast, it's quite practical.

A

So this is what a setup looks like right. We have the two or three setting. We split it into two one is time locked like I saw earlier, and then this one is split in amongst a bunch of Guardians right. However, many you want and doing normal operation right.

A

If you do key refresh- and at least one of these Guardians deletes the share you're not going to have enough pieces to reconstruct the phone share, so it's good enough, so adversary can get it and neither can the custodial provider, um but during catastrophic loss when all user factors are gone. So your phone factor and your platform factor is gone at least there's some way to recover it because your email factor is still there.

A

The tunnel Factor will unlock and the Guardians should, in this scenario, return the shares to you, so you can reconstruct reconstruct your key there, a bit more complex but much better than what we started with so I have a demo, but it doesn't work very well on still internet, so you guys can check it out on slides below or the link there.

A

um And, if you don't like the solution, you can also just use a Smart contract. Wallet with a message is much simpler. Not everything is NPC really so some open problems, um the Guardians can maybe grief you. So that's your catastrophic loss. The guidance can just refuse to return their shares to you unless you pay them an exorbitant fee.

A

um It's also a problem of how should the Guardians know when what's the key and return the shares to you. So these are some open problems, we're exploring. So that's all. Thank you very much for coming to my talk.

A

A

Hello I think I'm a bit early. So um does anyone have any questions?

A

B

A

B

um So the time locked piece is a bit of a magic box that just works. Are there any like practical algorithms, yeah.

A

Just that I've um I need the oh mistake anyway. But anyway, if you go check out slides online, they said just uh it's implemented in JavaScript, so you're running faster, but is the most um far the most common and simple algorithm is a repeated squaring algorithm. So you can just look it up, it's quite popular and, and it works in this case yeah. It was for just this use case. You don't need anything very complex.

A

uh Yes, it's Asic resistant in a sense that it requires sequential steps. You can't paralyze it, so um you could maybe build an Asic for squaring, but it's not possible to paralyze the computation. So it's sequential yeah any other questions. Yes, ah okay, so we're considering the scenario. The whole point of this setup right is complex, but the whole point of this is to protect against catastrophic loss right so during catastrophic loss.

A

You're going to have this issue where you've lost, basically, all your user own factors like phone and laptop the email we're just assuming it's custodial, there's always some way a subpoena. The guy you know, there's always some way to get it. But what what might happen right is um the time not show unlocked, but the Guardians, knowing that you didn't refresh your shares have now detected that you've lost your factors and now they're gonna grieve you right, they're gonna be like.

A

If you don't pay me, you know, half of what's owned by this account I'm not going to give you back the shares and- and this is extra extra challenging hero, because you only need one Garden to grieve since there is no redundancy here yeah. So there's one one problem: there's an open problem to solve any other questions.

A

Go ahead, yeah um someone not deleting a share and someone keeping the share.

A

um The problem here is that the the actors here are Dynamic they're, not static, so do I will delete my share if I'm, pretty sure, you're refreshed right, then you're not going to be. You haven't lost your account, so my share is actually worthless, but when I do detect right, maybe you have no on-check activity for like um like three weeks right, a little suspicious three weeks, um then I'm gonna modify my behavior in in accordance to that. So it's kind of hard to model it that way.

A

I I, think a much more comprehensive way to think about a threat model is to think about the different types of attacks, because the number of ways you can attack is uh limited, since there isn't much interaction between the parties. It's really just about factors yeah any other questions.

A

All right, thank you very much.