Identity Network

Locke: A Peer-to-Peer Private Key Store to Replace Passwords


Connor Peters
[email protected]
www.locke.id

DRAFT 1

 

Abstract

Locke is a peer-to-peer network that alleviates people from the responsibility of managing their private keys. This is accomplished by distributing Shamir key shards to self-defined trusted community members, allowing people to provide decentralized authentication and recovery services for their family. By combining the security benefits of modern fault tolerant peer-to-peer networks with the pragmatic security of secret sharing mechanisms, Locke becomes a peer-to-peer network that supplies a generic API to authenticate individuals. Locke formally defines data types for people, relationships, communities, and the self to create a simplistic digital analog to a person’s real-world identity. Locke establishes protocols that allow people to formally manage their relationships with each other and interact with external services safely and anonymously.

 

1. Introduction

Modern peer-to-peer networks have become incredibly resilient and performant for a number of important applications from file sharing to payment processing. Despite the token-economics fueled shenanigans of the so-called “crypto” community, decentralization has a number of benefits that come from distributing computation across many devices.

First of these benefits is reliability. When data is securely distributed among many devices there is no single point of failure. Second of these benefits is performance. When computation is run in parallel among many devices, the performance gain can be substantial for well-designed algorithms. The third major benefit is censorship resistance. When data is distributed among many isolated devices it becomes hard or impossible to directly influence the outcome of a given transaction.

These 3 benefits make decentralization a great choice for building systems that require extreme stability such as financial systems or disaster-recovery systems.

However, when a decentralized system is created, to best preserve these benefits, the creators must deliberately forgo giving themselves the power to influence or control the system. This is a noble idea of effective altruism but is not without serious tradeoffs itself:

First of these tradeoffs is that of responsibility. If the system ends up causing someone harm, there is no person or organization directly liable for recourse. The second tradeoff is that of recovery. If a participant in a decentralized system loses their ability to access the system, there is no clear way to return them their rightful access. The third and last tradeoff is that of maintenance. There has never been a human system created that does not require ongoing maintenance in some capacity to function. While many decentralized systems have formally defined maintenance practices in place, they are often limited in their ability to directly maintain the system since they cannot directly force peers to cooperate.

When it comes to hosting a person’s identity or protecting an organization’s digital assets, these tradeoffs have proved too severe to make decentralization viable. For this reason the Locke Identity Network is not a pure trustless decentralized system. Rather, it’s a hybrid system that uses centralized gateway servers to bootstrap people in the network, a clustered topology of peers to authenticate and recover lost accounts, and individual people to host peers and keys on their smartphones.

The paper introduces Locke, a novel peer-to-peer network seeking to become a single authentication layer for the Internet. Locke combines the learnings of the past 2 decades to build a network that is durable, secure, performant, self-sovereign, and recoverable. The central principle behind Locke is that all humans require community in order to secure themselves in this world.

 

2. Background

This section outlines the technologies that Locke combines to create a secure and scalable Identity Network.

 

2.1 Distributed Hash Tables (DHTs)

A distributed hash table is a key->value store that is split among many devices, providing an interface to efficiently lookup the value of a key without needing any centralized coordination. Locke uses a DHT to resolve peer IDs to IP addresses, enabling peers to query each other without worrying about underlying network conditions.

Locke uses the S/Kademlia DHT [1] built on libp2p, an open source networking stack built by the authors of IPFS [2].

 

2.2 Decentralized Identifiers (DIDs)

A decentralized identifier is a persistent label for an entity that verifies them without needing to reference a central registry. The most common DIDs use a public blockchain such as Hyperledger Indy to store public keys, with ownership of the corresponding private key being the authenticating factor.

In Locke’s case there is no central registry of DIDs at all. Instead, people are required to host their DIDs themselves, resulting in true anonymity on the network. See section 4.2 for more details.

 

2.3 Blockchains

A blockchain is a record of immutable transactions that peers in a decentralized network can read from and write to. Blockchain transactions are irreversible in nature, enabling a consistent state to be achieved among many self-interested peers with a consensus algorithm.

Locke does not have a root public blockchain as cryptocurrencies do. Instead, Locke uses many private blockchains to record a history of transactions between people. Consensus is achieved among permissioned peers using the Practical Byzantine Fault Tolerant (PBFT) algorithm [3]. See 3.2 for more details.

 

2.4 Shamir’s Secret Sharing

Shamir’s secret sharing is an algorithm that allows a secret to be split into shares (often referred to here as “shards”) that can later be recombined to recover the original secret [4]. Shamir shards are completely useless by themselves and only a few of the shards are needed to be combined to output the full secret (known as the shard threshold).

Locke uses Shamir’s to distribute trust to community members, enabling them to recover lost accounts or revoke access from a compromised device.

 

2.5 Post-Quantum Cryptography

Existing asymmetric cryptographic algorithms are at risk of being broken in the future with quantum computers. New post-quantum safe cryptographic algorithms are currently in development that utilize hard lattice problems to provide protection against quantum attacks.

Locke uses Dilithium in conjunction with ED448 to sign messages, combining both tried and true elliptical curve cryptography along with newer post-quantum cryptography. This adds an additional future-proof security layer while also ensuring that should the new experimental algorithms be broken, the integrity of the system is not compromised.

The combination of these five technologies result in a peer-to-peer network with a clustered, multilayered topology from which the protocols necessary to create a single login layer for the Internet become possible.

 

3. Identity Network Design

The Locke Identity Network is a peer-to-peer network that seeks to provide an accurate and useful digital analog for people’s identity. This is accomplished by defining formal data types for people (3.1), self (3.2), relationships (3.3), and community (3.4). These four decentralized data types provide interfaces for a new authentication protocol described in section 4 that preserves four desirable properties:

  1. Anonymity
  2. Individual Sovereignty
  3. Security
  4. Recovery

These four properties are somewhat oxymoronic in nature, being that there are always some tradeoffs between security & individual sovereignty. Locke does not guarantee that all four properties are fully preserved at all times but pragmatically provides multiple protocols for people to decide for themselves which properties they value at any given time.

Locke strongly defends anonymity inside the network by always requiring people to supply DIDs themselves. Without a public registry of DIDs there is true anonymity inside and outside the network; distinct from the pseudonymous model blockchains use that can be deanonymized by correlating activity over time.

Onboarding and external authentication requests come in through Locke’s centralized gateway nodes. Peers communicate with one other using the encrypted QUIC transport protocol. Messages are additionally signed by the post-quantum secure Dilithium signing scheme. Peers on the network are identified by their peerID, a base58 encoded hash of their public key. These peerIDs are registered on a DHT and map to an IP address. Since Locke is designed to be hosted on smartphones, peer IP addresses are never considered static. Peers regularly broadcast their IP addresses to ensure that they aren’t dropped when their IP address changes.

 

3.1 People

A person on the Locke Identity Network is defined by all the peers they own and all the relationships they have. With this design a person can buoy their real-world security by either adding new devices or forming new relationships. This simplistic model allows a person’s identity to be flexible, changing over time as they do.

In Go, this data structure looks like:

type Person struct {
    Personame  string
    Shards     []shard    // see section 4.2 for shard encoding
    Peers      blockchain // stores an array of owned peerIDs
    DIDs       blockchain // stores external relationships
    Community  blockchain // stores internal relationships
 }

To represent people as a collection of disparate peers requires that owned peers be well coordinated and fault resistant. Every top-level field in the person data type is a blockchain that achieves consensus with a practical byzantine fault tolerant algorithm. See section 3.2 for details.

To further enforce anonymity in the network people are not given a persistent unique ID to represent themselves with. Instead, people input a simple human-readable string called a personame that represents themselves locally in the network. This unusual limitation is deliberate to prevent protocols from circumventing the anonymity of the network. Rather than referencing a persistent entity inside the network, external services must reference DIDs supplied and hosted by people.

To limit the ability of attackers to try and target a person’s community members, communities are considered to be private information known only to the members of the community itself. A person’s list of DIDs is also private information. DIDs are a base58 encoded hashes of public keys, with the corresponding private keys being split up using Shamir’s and stored among community members (details in section 4.2).

 

3.2 Self

The “self” is simply a person that knows private information:

type Self struct {
    Person
    PeerID     string
    PrivateKey crypto.PrivateKey
 }

Every peer has a copy of their self, hence the peerID and  device-specific private key fields.

To keep a person’s peers in sync, all peers must broadcast all changes made to their state. However it is inevitable that someone’s smartphone will be lost or compromised by an attacker. To account for that inevitability, all self state must be byzantine fault tolerant. Locke employs an implementation of the practical byzantine fault tolerant algorithm [1] to replicate state among owned peers. This results in a resilience of 3𝒇 + 1, meaning that to protect against a single fault 𝒇 (eg. a smartphone being lost), a person must have the magic number of 4 or more trusted devices total.

Those devices can be owned by that person or they can be trusted devices owned by a community member. Community members can validate that sync messages between an individual’s devices are received to increase fault tolerance without being privy to the message data itself. This is accomplished by including a hash digest of the content in every message.

Onboarding new peers to the self is a sensitive operation that requires at least 2 established peers to sign off on. A new peer is onboarded to the self with the following 5 step process:

  1. Generate a new peer ID by hashing a new public key and storing the corresponding private key locally.
  2. Add the new peer ID to the DHT.
  3. Give the new peer ID to 2 already established owned peers (or just 1 if that’s all the person owns), usually via a QR code or magic link. If there are no owned peers then this is a new person and peer coordination is not necessary.
  4. The established peers broadcast the new peer ID to all other owned peers and community members.
  5. All peers engage in a PBFT transaction to add a new block to the self.Person.Peers blockchain containing the new peer ID along with the existing peer IDs.

It is common and expected that a state broadcast will not be received by all peers since smartphones and other personal devices are often not connected to the Internet. This lack of connectivity is not considered a fault, these messages are simply stored in a buffer and are retried every 15 minutes, eventually allowing peers that were offline to be brought up to speed asynchronously. Devices will be dropped completely if atomic state is not achieved after 90 days.

From this point on it is assumed that any data stored at the “person” level is stored using the PBFT algorithm to achieve consistent state among owned peers.

 

3.3 Relationships

Now that multiple devices are able to come to consensus to define a person, multiple people must be able to come to consensus to form communities. This is accomplished with relationships called dramas. A drama is a dialogue of transactions between people, immutably recorded onto a permissioned blockchain:

type Drama struct {
    ID           string
    Transactions []Transaction
 }

type Transaction struct {
    ID          string
    Initiator   map[string]string // Personame -> PeerID
    Recipient   map[string]string // Ditto
    Type        string
    Trust       int
    Timestamp   time.Time
    ProcessTime time.Duration
 }

The trust field is an integer between 0 and 100 that represents the quality of the relationship at any point in time. This value can improve or degrade depending on a variety of conditions defined by protocols (see section 4.1).

Dramas provide a transparent and monitorable byzantine fault tolerant logging system that greatly increases the security of the network. Having an immutable trail of permissioned “relationship receipts” allows people to learn of and retroactively handle malicious attacks by revoking access and limiting damage. Dramas are used to authenticate trusted peers by requiring them to supply past transactions, essentially using shared experiences between individuals as an authentication factor.

Dramas additionally allow people to gain recourse against an adversary in the real world by becoming unforgeable verifiable evidence usable in any court system. This is another example of Locke being a pragmatic system that provides real world security.

The process for recording a transaction between people as follows:

  1. Person A sends a message to Person B.
  2. Person B creates a new transaction and writes it to the drama that represents their relation with Person A.
  3. Person B sends a reply back to Person A, along with the transaction they created.
  4. Person A writes that transaction to their corresponding drama and sends back a confirmation of atomic state.

In this way, dramas are used to achieve consensus among people.

If a person does not receive confirmation that a transaction has reached atomic state it will be stored in a buffer and retried.

 

3.4 Community

Now that data types for people and relationships are established, the structure of communities emerge:

type Community struct {
    People  []Person
    Dramas  map[string]string // Personame -> DramaID
}

Every person has a copy of their community, and a copy of their community’s community. Communities are limited to being known by first-degree connections. Locke does not map out secondary connections between individuals by default. Additional protocols can be written that could map out second-degree connections among individuals to provide functionality, but they will likely lower the security of the participating individuals by revealing previously hidden information about their community members.

Newly added community members are considered “pending” for 36 hours after being added to protect against foul play. After the 36 hour pending period is over, the new community member is considered to be trusted for a period of time. Over time that trust value degrades and must be refreshed by requiring community members to supply past transactions to prove that they’ve been recording them honestly. This trust value degradation is dictated by protocols distinct from the structure of the network, see section 4.1 for details.

The process for adding a community member is as follows:

  1. Person A invites person B to become a member of their community by generating an OTP and concatting their current peer ID. This string is converted into a QR code or magic link and shared out-of-band with Person B.
  2. Person B ingests the QR code or link and automatically sends the OTP back to Person A.
  3. If the OTP is valid, person A responds with their identity to person B.
  4. Person B adds Person A to their community and responds with their identity.
  5. Person A adds Person B to their community and starts a new drama to represent their relationship.

Functionally, communities are a LAN inside the Locke WAN that become a reliable and trusted store of “cloud” data for individual people. The community size must be between 0 and 16, see 4.2 to see why.

These 4 data types — people, self, relationships, and community — provide a simple, accurate, and flexible digital analog to a person’s identity by accounting for both the material self and the social self [6]. Section 4 outlines the initial use case for such a network: community auth.

 

4. Authentication & Recovery

No matter how clever a system is, authentication ultimately always comes back to key ownership. Keys come in many different packages, from passwords to fingerprints to RSA keys to gait models. But they’re always there, stored somewhere, to eventually be verified against an assertion. Authentication solutions such as SQRL [7] rely on storing keys on-device while standards such as OpenID rely on federated key storage. There are pros and cons to both.

Public key authentication protocols such as SQRL and Webauthn [8] use private keys stored on a local device to authenticate, a significant improvement over traditional passwords, both in terms of security and usability. The tradeoff is that if a smartphone or master key is lost the owner can lose access to their entire online identity or be wholly impersonated by an attacker.

Federated authentication, on the other hand, places trust among centralized identity providers such as Google and Microsoft, allowing them to decide how best to store a person’s keys. This makes them ultimately responsible for people’s security. They typically choose to use password-based authentication, public key authentication, or in some cases biometric authentication. Federated authentication is again, more secure and usable than passwords. But comes with the tradeoff that people are now more susceptible to the whims of large companies who may have substantial incentives to track their internet usage.

Locke can be thought of as a combination of the two: a federated key store that uses public key authentication, where people get to pick family members to be their fedorators. Locke stores keys by distributing Shamir’s shards to a person’s self-defined community of family & friends. This design decision is made on the thesis that in order to operate securely in this world, people need to have a community of some sort that they can trust at some level. And that for the majority of people, their community is perhaps more trustworthy than their own ability to manage keys.

If that assertion is true, then distributing key shards to community members provides 2 benefits:

  1. A key can be recovered if it is lost or forgotten.
  2. A key can be revoked should a trusted device be compromised.

By sharding keys and distributing them among community members, people are free to “forget” their keys, alleviating them of the sole responsibility of maintaining their security. The keys are ultimately reassembled not on the device that initiates the authentication request, but a separate device, over the network, to prevent attackers from ever being able to see a plaintext key. If their device is then lost or hacked people are able to decentrally recover their keys without ever exposing them to the compromised device.

 

4.1 Distributing Trust

In order to safely distribute key shards to community members there must be a way to quantify the trust between individuals. But trust is a slippery thing. Trust between people can degrade over a long period of time or extremely rapidly. The trust shared among one relationship might be contingent upon trust shared in a separate relationship. Trust might come coupled with a power dynamic that gives one party power over the other, such as with a boss or a parent. There are an infinite number of ways that trust can manifest itself between 2 self-interested agents.

Locke provides a pragmatic solution to this problem by defining trust as a continually debated probability from 0 – 100% and providing a user interface for people to comfortably define, roughly, the trust value ( T ) they feel a relationship deserves. T directly determines (a) how many shards are entrusted to a recipient and (b) how many shards that recipient will release to a community member during an authentication request (see 4.3).

T is stored in the drama that defines the relationship between 2 individuals (3.3). Multiple trust values are stored in a single drama. For example, Person A’s trust for Person B is one value, while Person B’s trust for Person A is a separate value, differentiated in the drama by the initiator and recipient fields. Both individuals are therefore privy to how much trust the other has granted them.

A community member’s initial T is determined by selecting a role:

Role Initial T
Parent/Significant Other 90%
Sibling 85%
Grandparent 80%
Aunt/Uncle 75%
Cousin/Niece/Nephew 70%
Friend 85%


From there, T rises or falls at an increment i depending on a wide variety of active & passive authentication factors. The goal of Locke is to eventually model out enough passive authentication factors such as proximity, gait, typing style, and input patterns to enable truly seamless & interaction-less authentication. Whatever the data is, the point is that authentication is a continual process that happens by requesting shards from community members. This gives Locke’s authentication a probabilistic quality that greatly improves overall network security by finely scoping access tokens (4.3).

To save space this initial implementation does not provide a complete trust degradation algorithm; that will be expanded upon in future papers. This iteration only defines the interface through which that process will be executed.

Every i seconds (180 by default) peers broadcast a tailored <<BROADCAST: H, data>> message to each one of their community members containing a SHA256 hash ( H ) of the last transaction mutually agreed upon in their shared drama. This represents the shared history between the 2 agents and is used as the base authentication mechanism to ensure peers maintain a good behavior of correctly recording transactions, even among faulty nodes.

This broadcast is immediately responded to with a <<PING>> message to confirm the broadcast was received and to allow the receiving party to gauge the latency. In future work Locke will expand the <<BROADCAST>> protocol to add passive authentication data and a corresponding trust degradation algorithm to allow T to be constantly evaluated by both parties.

 

4.2 Distributing Keys

Now that trust among people is defined, the next question is how to distribute key shards to people based on T. Firstly, every key is encoded into a single string containing it’s type, domain, DID, and key value concatenated and delimited by a colon:

type:domain:did:key

That string is then broken into exactly 1000 shards. This base shard number was chosen because it provides enough pieces to model trust with a high level of fidelity while avoiding unnecessary overhead. From those 1000 shards a certain number are given to the community and the rest are kept, becoming the self-trust value. Therefore, the more a person trusts their community the less they need to trust themselves and vice versa.

The number of shards entrusted to the community is determined by a simple formula:

Community Shard Num =
(Base Shards / (Community Num + Owned Peer Num)) * Total Trust


Total trust is the sum of each community member’s T. This formula results in a number less than 1000 that entrusts increasingly more shards to the community the higher the total trust value gets, while keeping increasingly more shards depending on how many peers the self owns.

The amount of shards kept ( k ) becomes:

Kept Shards ( k ) =
Base Shards – Community Shard Num


k is evenly distributed among a person’s owned peers such that each peer has their own unique store of shards by default. If more uptime is required shards can be copied among owned peers instead.

The amount of shards entrusted to each individual person in the community is determined by an individual’s T as a percentage of the total T, multiplied by the total number of community shards.

Individually Entrusted Shards =
(T / Total Trust) * Community Shard Num


To finish off this model a shard threshold is needed. For simplicity, the base threshold is initially set to 50%, meaning that 500 of the 1000 total shards are needed to reassemble any given key. This threshold can change depending on the security level of a specific key:

1 = confidential, 50% threshold
 2 = secret, 60% threshold
 3 = top secret, 70% threshold

The threshold determines the overall number of shards needed to reassemble the key. Therefore, the number of shards necessary for a person to retrieve from their community in a typically auth request is the threshold minus k.

With 2 owned peers and a base threshold of 50%, the resulting shard distribution for communities of size 1 – 16 looks like:

Size of Community Est Total Trust Community shards Avg Per Community Mem Shards Kept % Kept Auth Threshold Avg Ppl Auth Num Avg Ppl Recover Num
1 95% 317 317 683 68.33% -183 -1 2
2 180% 450 225 550 55.00% -50 -1 3
3 255% 510 170 490 49.00% 10 1 3
4 340% 567 142 433 43.33% 67 1 4
5 400% 571 114 429 42.86% 71 1 5
6 500% 625 104 375 37.50% 125 2 5
7 560% 622 89 378 37.78% 122 2 6
8 600% 600 75 400 40.00% 100 2 7
9 720% 655 73 345 34.55% 155 3 7
10 800% 667 67 333 33.33% 167 3 8
11 880% 677 62 323 32.31% 177 3 9
12 960% 686 57 314 31.43% 186 4 9
13 1040% 693 53 307 30.67% 193 4 10
14 1120% 700 50 300 30.00% 200 4 10
15 1200% 706 47 294 29.41% 206 5 11
16 1400% 778 49 222 22.22% 278 6 11


These values and this model will be tweaked over time to better represent how humans exist and trust one another. These initial results show that again, the magic number is 4. Four devices or four total members in a community result in a secure, recoverable, networked key store.

Locke’s Shamir shards are encoded similarly to SLIP-0039 from Satoshi Labs [10], excluding the key hierarchy fields. For simplicity Locke does not employ a two-level shard scheme. Instead, the trust distribution model along with the large number of shards created per key should be enough for most use cases. The resulting verifiable shard encoding looks like:

 

Identifier Security Level Threshold Shard Value SHA 256 Digest
32 bits 2 bits 10 bits 16n bits 128 bits

 

  1. Identifier: a 32 bit number used to verify that the shards belong to the same key. Not randomly generated, this ID is incremented by the owner for each new key.
  2. Security Level: a value from 1 – 3 that determines the importance of keeping this particular key secure with 3 being the highest.
  3. Threshold: a value from 2 – 1000 that dictates how many shards are required to reassemble the key.
  4. Shard Value: the Shamir share generated from GF(216). Shamir’s is applied to every 2 bytes of an arbitrarily long input, and then bundled together to create the shard value.
  5. Digest: the first 128 bits of the SHA256 hash of the shard, used as a checksum.

The shard distribution process is as follows:

  1. Generate f(1002) shards for each given key such that f(0) is the key itself and f(1) is the key’s digest to validate its reassembly.
  2. Compute current community trust values to determine how many shards should be entrusted to each community member.
  3. Store the shard ID and the checksums for the shards associated with each community member.
  4. Send each community member the shards: <<SHARD, []s>>
  5. Store the shard ID, the number of shards entrusted, and each person’s response in the appropriate drama.
  6. Delete the key.

This sharding process can be repeated at will to invalidate shards that have been compromised and will automatically trigger if a community member’s T falls below 50%.

 

4.3 Authentication

Now that a person’s community is storing their key shards, there must be a secure way of gathering them and a safe place to reassemble the key. Start by asking community members to send their shards with an <<AUTH, H, key_id, dest>> request. Community members can respond with a 500, 404, 401, or 200 status code. If T for the authenticating person is under 50%, the community member will return a 401 Unauthorized response. If T is over 50%, the community member will return a 200 Success response and release a number of shards in proportion to T to the preferred location specified by dest.

If the key is reassembled on the peer that initiated the authentication request, as you would expect, then if that device becomes compromised all of this rigmarole would be for nothing. Hackers would still be able to perfectly imitate a victim by capturing the keys as they come in, and T won’t go down fast enough to prevent that no matter how accurate a typing pattern model may become. Instead of immediately releasing the shards back to the device that requested them, it’s in people’s best interest to choose a different location, depending on the circumstances.

Following the advice of [9] Locke provides multiple protocols for people to choose from that balances the trust given to community members with the responsibility required by the self:

  1. Self-Sovereign: the key is always assembled on the device of the authenticating person & the access token is generated by the authenticating service.
  2. Federated: the key is assembled on Locke’s gateway nodes & when possible, the access token is generated by Locke on behalf of the authenticating service.
  3. Hybrid (default): the key is assembled on a different peer owned by the authenticating person & the access token is generated by either the authenticating service or Locke. The different peer could be a device such as a laptop left at home, a lookout node, or a highly trusted community member’s device (to be defined in future work).

A lookout node is a virtualized peer that Locke hosts for people. People own their lookout nodes, but Locke runs and maintains them. This optional feature adds some centralization to the network but provides 5 massive benefits:

  1. Key assembly doesn’t happen on people’s smartphones.
  2. Authentication uptime is guaranteed.
  3. Locke is responsible for maintaining node security.
  4. A percentage of computing power on the network is controlled by Locke making it more resilient to 51% attacks.
  5. Lookout nodes can have their own internal protocols to monitor the security of the network as a whole and respond to attacks automatically (to be defined in future work).

Lookout nodes have all the same authentication functionality of a normal peer, while also being designated key assemblers for the Hybrid key assembly protocol.

Once the community members receive an <<AUTH, H, key_id, dest>> request, they first authenticate the requestor by making sure H matches their records. If a person needs to authenticate from a device that is not an owned peer, and as such won’t have access to H, then they’ll need to provide a strong active authentication factor to community members (to be defined in future work).

After the person is authenticated, community members sanity check that the destination satisfies the authenticating person’s protocol preference. For instance, if they prefer the Hybrid protocol, community members must check that the destination isn’t the same as where the request came from and that it’s a peer owned by the authenticating person. If everything checks out, the community member releases the number of shards they have in proportion to T to dest and sends a separate 200 status code response to the peer that initiated the request detailing the number of shards they’ve released.

Once enough shards are gathered, <<AUTH>> requests are stopped and the key is reassembled. The actual authentication process from there depends on the use case. If the key is a password then Locke simply acts as a password manager and autofills that into a browser. If the key is a private key, Locke can participate in any public key authentication protocol such as WebAuthn or SQRL. Locke itself is agnostic to the type of authentication and as such can be plugged into any system. Whatever access token is returned in response to the authentication will be forwarded from dest to the peer that initiated the authentication process.

Along with being designated onboarding peers, Locke’s gateway nodes provide a centralized API to act as secure federators and generate fine-grained access tokens on behalf of external services. These tokens are signed JWTs with a TTL of i (180 seconds). Generating extremely short lived tokens greatly enhances people’s security by limiting the scope of access before a new authentication process must ensue. In future work, Locke will define an API to further limit the scope of tokens by assigning each token specific actions and capabilities, verified by an access control system.

 

4.4 Recovery

Recovery is a manual process separate from authentication. One of the main benefits that comes from delegating trust to a community is that recovery can happen completely out-of-band, authenticated and negotiated by people who are already familiar with each other. Ultimately, all that needs to happen for a complete identity recovery is for enough community members to bring all their key shards together.

This type of recovery is not the equivalent to a “forgot password” reset email. When a person needs to “recover” a password for an online account, a link is usually sent to their email address. That link is already authenticated, meaning that ownership of the email account becomes the sole authentication factor. This puts all a person’s eggs into a single email basket and presents a huge security risk. Locke’s recovery process is very different as it’s a hard recovery for someone who lost a device or had their entire digital identity compromised.

The process can be initiated from an owned peer or a trusted community member’s device. In the future, the ability to recover from an untrusted browser session using an active authentication process will be defined. First, a <<RECOVER, personame, context>> request is sent to all community members. Each community member then generates an OTP and is instructed to share it out-of-band with the recovering person. It can be shared as a magic link, QR code, or mnemonic code. Once they receive the code back, the recovering person is considered authenticated and every shard for every key is released to the device that initiated the request. 

This places the onus of authenticating a recovery request to the community members themselves. Locke suggests that this process happen over a phone call to provide a layer of pragmatic biometric authentication that only humans are capable of.

 

5. Conclusion

Locke provides a vision of the future where technology can improve humanity by enabling disparate communities to self-organize. Where individuals own their data and people trust & communicate with those in their local community. Locke’s Identity Network is modeled after the anthropological truths in which humans live and ultimately seeks to provide a secure and useful digital identity for everyone.

 

5.1 Future Work

This document is Locke Improvement Proposal 00-01. Future LIPs:

LIP 00-02: Attack and access structure analysis
LIP 00-03: Trust degradation model
LIP 00-04: Active authentication from untrusted devices
LIP 00-05: Action-based access control
LIP 00-07: Lookout node coordination for automated attack response

 

5. References

[1] I. Baumgart and S. Mies: S/Kademlia: A Practicable Approach Towards Secure Key-Based Routing, In Parallel and Distributed Systems, 2007

[2] Juan Benet: IPFS-Content Addressed, Versioned, P2P File System, 2014, https://github.com/ipfs/ipfs/blob/master/papers/ipfs
-cap2pfs/ipfs-p2p-file-system.pdf,

[3] M. Castro and B. Liskov: Practical Byzantine Fault Tolerance, in Proceedings of the Third Symposium on Operating Systems Design and Implementation, 1999

[4] A. Shamir: How to share a secret, in Communications of the ACM, 1979

[5] S. Kamvar, M. Schlosser, and H. Garcia-Molina: The EigenTrust Algorithm for Reputation Management in P2P Networks, in Proceedings of the 12th International Conference on World Wide Web, 2003

[6] R. Perinbanayagam: Identity’s Moments: The Self in Action and Interaction, 2012

[7] S. Gibson, SQRL: Secure Quick Reliable Login, 2013

[8] Many authors, Web Authentication: An API for accessing Public Key Credentials, 2021, https://www.w3.org/TR/webauthn-2/

[9] B. Hill: Common Flaws of Distributed Identity and Authentication Systems, 2011

[10] Many authors, SLIP-0039: Shamir’s Secret-Sharing for Mnemonic Codes, 2017, https://github.com/satoshilabs/slips/blob/master/slip
-0039.md