-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
time-delayed social recovery scheme #218
Comments
@tmpfs You mentioned this:
Could you elaborate? It sounds like you're implying that the secret sharing threshold should be considered private enough that the backend server isn't allowed to store it? |
I would prefer it if the server has no knowledge of the threshold as otherwise we would have the ability to adjust it, whilst it's not a severe problem I think it's worth avoiding if possible. As a general design principle I am trying to give the server the least amount of authority and knowledge of accounts as possible. Tangential, I had in mind that in order to create a social recovery group all the other participants would need to have installed SOS, this was because I envisaged us using threshold signatures which would require all participants to have p2p connections. I wonder what you think about this requirement? |
When I weigh up the pros and cons of threshold signatures I think we should avoid them for this use case. Storing the threshold on the server is not really an issue as the server is responsible for triggering the release process anyhow. Pros
Cons
I wonder whether a simple solution which just uses the account identity signing key to identify recovery group participants is enough. The server then just needs to know the addresses of the recovery group participants and the threshold required to start the recovery process. In particular, I like that this would not require all the recovery group participants to be online at the same time during recovery group creation and triggering recovery. |
i'm in the same boat there. Compared to simply storing the recovery threshold on the server, the costs of implementing a threshold signature scheme just aren't worth it. Besides, the real security of the vault is derived from the end-to-end-encryption of the recovery package. Even in the most extreme scenario where the SoS server is ransacked, with all the encrypted vaults exposed lastpass-style, attackers would also need to phish or steal secret recovery shares from customers in order to decrypt those vaults.
I think creating the recovery group should be possible without the shareholders needing to installing any software. Shares can just be SLIP-39-style mnemonics written on paper, or digital files on USB drives. The SoS server doesn't need to know how many shares were issued - only the threshold, and how to verify each share. Here's how I'd do it: Share Distribution
RecoveryAt the recovery stage, then absolutely the shareholders will need to install or run specialized software to trigger the recovery countdown, and eventually decrypt and access the recovered vault.
Advantages
Limitations
Footnotes
|
If we wanted we could extend the recovery process to integrate more tightly with SoS itself. Instead of shares saved on paper, the share could be saved automatically in encrypted form on the server, such that only the correct shareholders can access and decrypt them. But for the sake of accessibility we definitely need to support fully offline shares. |
@conduition , this is great, thank you. Some minor nitpicks and a few higher level comments afterwards. In Share Distribution (2):
I think this should read let m be the master key which decrypts the customer's recovery pack. A recovery pack is just a mapping of vault identifiers to (automatically generated) diceware passphrases (see In Recovery (2) I think the identifier sent will be the account identifier (just an Ethereum style address) as they are recovering an account but restricted only to the folders that the account owner chose when they created the recovery pack/group. Note that here I think the server will need to know the vault identifiers that exist in the recovery pack before encryption to release only the vaults that the account owner has explicitly granted recovery rights to. I should really write an overview of the architecture and terminology so that the language is clear for the terms I have used. Will get to that soon!
That is right, I always imagined that a single trusted person is the executor, so we would need to store that information too I think and either a) only allow the executor to start/complete the recovery process or if possible b) let anyone start the recovery process but only allow the executor to complete recovery. We might also want to allow multiple executors with a priority weighting in case an executor is dead or otherwise unavailable. I really like your direction of allowing recovery group/pack creation without the app installed by the other parties. But I do wonder if it will affect the UX of the recovery group creation flow, for example, if everyone had the app installed we could make recovery share distribution seamless (E2EE encrypted delivery of the key shares). I am torn on this one, need to consider it some more and maybe see what the the UX is like with the flow you describe, for example, participants are going to need to know who the other participants are (including contact details) in order for them to sign to trigger recovery. I assume this is fine but it's quite a lot of effort on the part of the person creating the recovery pack to get this right and I really want this to be very, very easy to use so it appeals to everybody. I thought by having everyone use the app a lot of the legwork of these notifications/participant co-ordination could be handled in-app.
Yes, now I re-read this I think we need to support both flows. Let's start with the fully offline use case you describe and then later enhance with an improved UX where possible. On your footnotes, I think we have 1) already covered due to using a recovery pack which is independent of the account master password and 2) is very cool - so if a recovery participant dies the owner could just issue a new share to somebody else - is that right? And footnote 3) is interesting, are there any benefits from separating the share encryption and signing keys? Really very excited to have you working on this, what's the next step, should we write a specification or would you prefer to get stuck in to a draft PR? |
I agree, I think I need to know the difference between "Folders", "Accounts", and "Vaults" before I get too carried away here.
Ah, so the account owner can dictate which parts of their Account are recoverable through the social recovery process? That might merit some more careful consideration. These "folders" will need to be encrypted separately from one-another, so that an account owner can change each folder's encryption key independently, to scope the access of the recoverers as they prefer.
Idea for this:
i made a simple protocol which enables this access structure without adding any extra data to the recovery shares. Happy to share if you're interested.
All sounds good to me. This can also be enforced cryptographically using sharded secret sharing groups, so that one specific share (the executor's share) is mandatory to recovery the vault, plus some threshold of less-trusted shares. You could allow more than one "executor share" as well, although there is no concept of 'fallback', so that part would need to be enforced server-side.
Exactly correct.
Sorry, I think was vague in that footnote. let me clarify with an example. Picture a 2-of-3 recovery group, Alice, Bob, & Carol. Alice and Bob cooperate to initiate the recovery countdown, but then Alice disappears. At the end of the recovery countdown when Bob receives the encrypted vault, he and Carol can decrypt it together. Alice was the shareholder who originally helped start the countdown, not Carol, but Alice and Carol's shares are functionally equivalent when it comes time to decrypt the recovered vault.
Same here! I think a high-level design document would be the next concrete step, listing requirements and describing the architecture. But before I get into that, i'd like to take some time to get my build environment set up and explore the frontend/backend source code repos for a while. |
@conduition, I have had a go at this in the overview. Please let me know if the language can be improved or anything is not clear. Later I intend to document the binary file formats in great detail but for now want to keep focused on the sync logic.
Let's say for now the executor can recover all the folders that the owner has granted the recovery group access to? Which means that we can encrypt the recovery pack (as opposed to a single password) and your protocol continues to work as intended. I think the scope is implicit as the owner chooses which folders are included in the recovery pack during recovery group/pack creation.
This is brilliant! I love it :)
Please do 🙏
I like the idea of enforcing the use of the executor's share, however I don't know if it would be possible to change the executor? Without that I think the death of an executor would invalidate the entire recovery (which we should avoid IMO) - is that correct?
This is a very important property for the protocol to have, great design 👍
I think this is another important property for the protocol to have, we need to ensure that as much as possible (except in very extraordinary circumstances) it is possible to complete the recovery process. I wonder if once we have a specification we should draw a graph, I think a visualization would really help with my mental model. |
Thanks, that's very helpful. I'm not sure why you're using diceware passwords for decrypting each Vault, instead of just using raw encryption keys, but that's probably out of scope for this issue. let's chat about that on slack.
All sounds good to me. As long as we allow the owner to update the recovery pack on-demand, they can change the set of recoverable folders however they want.
If there's only one "executor-share", and the executor disappears at the same time as the owner, then yes, everyone else is hooped unless they can find his share. I think sharding would still be a cool feature regardless as it would allow people to give higher privileges to more trusted friends/family. Maybe not something we need for our PoC but something we can plan for in the future. |
Yep, the owner can store the full recovery key in their identity vault and be able to adjust the folders in the recovery pack, whenever they want, that's a nice touch.
I would like to understand more about sharding, can you point me to a resource to learn more about it please? |
I have two options for you.
|
Probably the best in-the-wild implementation of SSS is Trezor's SLIP39 spec. Specifically, this section talks about sharding, although the more common terminology is 'groups'. They reference this document for justification. Sharding works by breaking shares up into smaller shares. For example, you can shard your secret into three groups of shares: family, friends, and colleagues. You might set the groups up such that if any two groups out of the three are in agreement, then they can cooperate to recover the secret. However, you might not trust each of your colleagues as much as your family. Your family group might be a 2-of-4, while your colleagues' shares are a 10-of-12. There's no theoretical limit on how deep you can go. Shards can be broken into shards which can be broken into more shards. They can be customized to oblivion and back. But to reduce cognitive overhead and complexity it's probably best to limit it to at most two levels of sharding depth, which is what Trezor has done. |
I added a draft of the aforementioned social recovery design document: #234 It lists basic requirements and details the setup stage, but not the recovery stages yet. |
Carrying this out of the email thread:
Requirements:
The text was updated successfully, but these errors were encountered: