Securely managing ones digital estate ("flexible secret sharing")
I proposes the concept of flexible secret sharing as a secure and practical approach to the following problem: People who operate critical digital infrastructure may fail for a longer period of time or forever (so-called bus factor of one). To ensure that in such tragic situation at least the operation of the infrastructure can continue, other people should in principle be able to gain access. However, this must be organized in such a way that reasonable security requirements for the nominal case are maintained. Such a secret-sharing system must also take into account the dynamic social reality of real people: Availability, responsibility and trust levels of persons might change over time, which needs to be reflectable in the secret distribution. However, the process of changing the secret distribution should a) be achievable with minimal communication and b) be manageable with minimal brain sweat (i.e. nice and clear gui for easy overview and self-explanatory actions).
Secure digital inheritance through flexible secret sharing
Alice manages a server with important data for the r&d team of her company and she is also a skydiver. In case something happens to her, other members (Bob, Carl and Dora) should get access to the server. However, sharing the ssh password directly is too insecure because each person has a risk of being hacked or blackmailed, etc.
The technical solution to this is "Secret Sharing". Bob, Carl and Dora each get only one (encrypted) part of the ssh password, a so-called "share". Alice has generated the shares in such a way that there are M=3 in total and N=2 any of them are needed to reconstruct the password. So in case Carl is e.g. traveling around the world while Alice has an accident, Bob and Dora can still take over the server management.
Conceptual solutions  and software based on them [2-5] already exist for this problem.
-  https://de.wikipedia.org/wiki/Shamir%E2%80%99s_Secret_Sharing
-  https://manpages.debian.org/stable/libgfshare-bin/gfshare.7.en.html
-  https://github.com/lapets/shamirs
-  https://github.com/cyphar/paperback
-  https://www.moserware.com/2011/11/life-death-and-splitting-secrets.html
Flexible Secret Sharing (Level 1):
However, the following "flexibility use case" seems not to be covered by available software: Alice has not had an accident so far, everyday life is going on. But Carl leaves the company after his trip around the world. Egon steps in instead. Alice wants to give Egon a PW share as well and at the same time make Carl's invalid. The whole thing should happen in such a way that the PW shares for Bob and Dora do not change. And if at some point Egon should turn out to be a complete fool, an analogous adjustment should be possible: Egons share shoud be invalidated, the others should be kept and to prevent gossip no communication should be necessary for this.
Flexible Secret Sharing (Level 2):
As time passes staff fluctuation occurs more often in the company, plus Alice now also runs servers for other teams, with some overlap in membership. She would like to have a clear interface where she can see a history of who got shares of which secrets and which shares had been invalidated. Also, Alice whishes to manage the secret-shares in that gui (create new shares, invalidate old ones, change parameters M and N, etc.).
Relationship to sustainability
Basically, I think a sustainability-oriented approach to digitization is urgently needed, see bits-and-baeume.org for details. From my point of view, a secure fallback solution for digital secrets has quite a lot to do with sustainable digitization: At its core, sustainability is about making sure we don't leave serious problems for future generations (often related to the ecological domain). Having a secure and uncomplicated transfer process for accessing infrastructure and possibly data for me fully falls within this definition. Additionally, there is the side effect that when implementing the above approach in an organization, the topic of IT security must inevitably be addressed, which is explicitly part of the B&B requirements (see requirement 5).
I think FSS level 1 could be hacked together as a hobby project. However, implementing FSS level 2 as (freemium) web-service would have some benefits:
- Resources for usability, security and convenience features
- Resources for PR → more people would use it
- → more people would think about safely storing secrets (and hopefully stop using sticky notes)
- → less frustration and data loss in companies, NGOs, hack spaces, families, groups of friends etc.