-
Notifications
You must be signed in to change notification settings - Fork 72
/
Achieving Self-sovereignty via Trustless and Keyless Key Management
62 lines (36 loc) · 8.71 KB
/
Achieving Self-sovereignty via Trustless and Keyless Key Management
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
Achieving Self-sovereignty via Trustless and Keyless Key Management
by Frederic Meyer, e-Sovereignty Foundation (contacts below)
Introduction
In the digital world, power belongs to those who own the data. In essence, this means that control of a digital environment (account, profile, database, code, wallet, etc.) is given to whoever has the keys to that environment. These keys come in pairs: a public key (commonly known as a login), to determine what environment the user is trying to access, combined with a private key (or password), to verify his credentials.
In the many years since the digital age, this scheme hasn't changed much and has defined the relationships between users and services (apps, websites, etc.) across the spectrum. Typically, trust is the name of the game, and services are in charge of handling everything for users in their back office, with mixed results. Common problems include: users having little to no power over their environment ; services (whose core business isn't usually security) becoming the guardians of massive data honeypots ; user data being exploited without users' consent and often at their expense, etc.
However, with the coming of decentralized technologies, users are placed directly in charge, with sole and master control of new environments. While this leads to true ownership or self-sovereignty, there is a catch: it also relies on users being able to keep that control indefinitely, no matter what, under threat of permanent lock out.
We are proposing to solve that problem with a trustless and keyless key management protocol. This solution is patent pending, and developed via a non-profit foundation named e-Sovereignty.
1/ The problem of safety and recovery
The challenge with the digital world is that it functions with 0's and 1's. If you have credentials, you will get in. This means that access management needs to be well planned and stand the test of time, with an intrinsic flaw: safety. If a user loses access, there has to be a way for him to get it back. The only reliable safety scheme is one where the user can remain autonomous and perform recovery on his own, which means without a trusted gatekeeper, but if he has lost his access, chances are he also lost all other keys...
Social recovery seems to be a good alternative, but in particular cases, they can prove to lack censorship resistance, or not stand the test of time. For instance, if a user is wrongfully accused of a crime or chased by a repressive state (for whatever political, ideological, religious, ethnic or sexual reasons), even family and friends could turn on him and refuse to give him access back to his environment. In the same manner, personal relationships evolve with the years, and there is never a guarantee that a trusted friend will remain so forever.
2/ Achieving trustlessness and keylessness
a) Trust
In this field, Bitcoin's proposition is interesting in that it relies on a certain degree of anonymity to certify transactions, making it that much harder for censorship to be applied to any particular user. Given that it is actually pseudonymous, it seems that if enough participants are unknown, then the network can be considered trustless, though only time will tell if this stays true. For now, its resilience over the past 10 years has met few challenges, so we could conclude that "pseudonymous anonymity" constitutes a strong solution for trustlessness.
b) Keys
There are three types of keys in existence:
- passwords (or seed keys): though probably the most common type of key to use, they are actually the hardest to manage. First, because they are easily copied and transfered, and second, because either the user creates his password and it will probably be too simple to resist attackers, or the system creates it and it will be too complex for the user to just remember it without writing it down. It is noted that a common way of preserving passwords is Shamir's Secret Sharing, in which pieces (or shards) of the password are distributed to different parties, and a general rule even suggests that they shouldn't know each other. But here again, trust becomes an issue.
- hardware (key device): typically, these come in the shape of a card or USB-type key. Though a strong type of key, this may be the most vulnerable, as it is difficult to keep safe from loss, theft, malfunction or destruction.
- biometrics: obviously the safest and most convenient key to use on a daily basis, and a number of technology companies have begun to deploy this type of keys to operate their products. Again, it isn't fool-proof yet (identical twins are an example), but more importantly, it places a target on the user himself, as body parts can be removed.
There is no ideal and universal type of key, which satisfies convenience, safety and durability. And as stated above, if it's not with keys, it's with a gatekeeper.
3/ Authenticating in an anonymous environment
Of course, going back to a trusted gatekeeper isn't a solution. That is, unless the gatekeeper doesn't know who he is dealing with, in which case, as we've seen with Bitcoin, we can achieve a certain degree of trustlessness. For this, we first have to achieve "anonymous identity".
Identity comes in two forms: who our documents (for instance, for the government or the service) say we are, and who we think we are. There can be variations of both, depending on the service we use, but they will correspond to one of the two forms. They can be turned into a public and private key pair, with ID details (easily accessible information) forming the public key, and security secrets (personal questions and other challenges) forming the private key.
This is how, everyday, companies around the world actually perform "anonymous" authentication. When a user calls in customer service for help, agents first ask identification (or public key), then security questions (or private key). Only then will they grant access to the account.
Thus, in essence, authentication only requires for a user to give information he provided when he first created the account. Making it anonymous is only a matter of keeping each security questions separate from the user's identity, then distributing the questions and having different authenticators certify each answer when a recovery is made. If the security challenges are a success, the user will be authenticated and receive his access back.
4/ Decentralizing authentication
When a user signs up for the service, he automatically enlists as a potential authenticator for other people. At any time, if his personal device is on, he can receive a request to help authenticate someone else in the world, someone he has never met. Once this requester has filled his identity form, storage nodes send his question/answer pairs to a random authenticator (adjusted for time of day). The authenticator actually only sees the answer, but his device forwards the question to the requester. The requester will then have to give a correct response to that challenge for the authenticator to mark it as a success. With a quorum of challenges successfully passed, the requester gets his access back.
The only hurdle to making this protocol both secure and easy-to-use, is in creating the right security questions for every user. For this, we are creating and patenting a wizard that takes the user through a unique process, where in the end, his questions are tailored to him, so that answering them is intuitive to him but impossible for an attacker to guess.
This protocol is blockchain-based, to respond to specific needs for trust and immutability, and it is fueled by a native token. Every time a user is called upon to act as an authenticator, he receives a reward from the network, and from the requester. In case the requester is in a dire situation, stranded and without resources, there are a number of mechanics to allow people to earn enough tokens to launch a recovery request, and at set up, he can also contract an insurance to provide enough means to survive an emergency and launch a recovery.
5/ Conclusion
This is a solution to achieve self-sovereignty, whether it be for identity, financial assets or overall data ownership. Anyone, from any field, individual or corporate, can now have sole and master control of his environment without fear of loss. As for security, it remains to be proved that humans are infallible, and that software can't be hacked. Thus, it is essential that recovery process involve both human participants, first individually then collegially, and software.
This system is detailed in a patent, pending in the US and internationally, though our goal is to deliver it through a non-profit foundation. We are looking for resources in all fields: management, development, marketing and funding.
Frederic Meyer
e-Sovereignty Foundation
WhatsApp: +33603706123