In pursuit of database systems which serve coordination-related purposes, we typically aim to grant agents (think: people) permissions over parts of the database state (e.g. kudos they might own), such that this state can only be changed [in certain ways] with the consent of the owner. The simplest way to effect this ownership is to mark the state (e.g. kudos) as owned by a particular public key, where the agent (person) must remember and keep secret the corresponding private key. This, however, is a rather brittle mechanism with several substantial disadvantages, namely:
- The agent might forget the corresponding private key, losing access to their state.
- The agent might accidentally disclose the corresponding private key, giving others access to their state.
- Third parties might attempt to exfiltrate the private key through means up to and including so-called “wrench attacks” (i.e. physical coercion).
Multiple keys, multisignature accounts, spending limits, etc. can alter or lessen these risks in specific ways, but they do not fix the fundamental problem: the network itself has no concept of “continuous agent identity”, and thus cannot authenticate actions taken by that agent in the way which people themselves would naturally do, e.g.:
- If you randomly attempt to send your entire bank balance to a Nigerian prince, your bank will probably block the transfer and call you (or request that you visit a branch in person).
- By contrast, if you make a moderately sized payment to your sibling, which you’ve done many times before, your bank probably won’t ask any questions.
- When you redeem my lunch debt (you paid last time) with me, I won’t ask you for a password or authentication code – I’ll just check if you appear to be the same person who paid for my lunch last time.
- In the extraordinary case that basic recognition fails – perhaps you’ve engaged in an extensive plastic surgery routine – I might ask questions about our shared history, or call a friend to confirm your story.
In all these cases, authentication is relatively holistic, involving history, likelihood of “genuine intention” to take particular actions, and physical presence which is very difficult/costly to fake. No essential “private key” is necessary, and as such it can neither be lost nor exfiltrated. Wrench attacks, kidnapping, etc. are still possible, of course, but they’re much less likely to be profitable.
Another essential feature of all these cases is that they’re mediated: authentication involves another agent who considers the scenario in order to effect judgement on whether the authentication should be accepted and acted upon or challenged and double-checked. In being mediated, this authentication is also local: the agent authenticating cannot necessarily convince a third party (especially one who does not know the agent whose action is being authenticated), because said third party would not have all of the same context.
How could we implement this kind of authentication in a distributed database system (specifically, Anoma)? This locality poses challenges, for we also want everyone to be able to verify the history, and not require that everyone know everyone else. A few design directions:
- Superimpose this local authentication mechanism on top of public key cryptography, such that agents would indeed possess keys, but different actions would be authenticated in different local ways (e.g. you spending your chris-kudos might require me authenticating you, then we would both sign with our keys), and the equilibrium would work as long as not too many people lose their keys at once.
- Build rate limiters directly into the system, where kudos/tokens/etc. simply cannot move too quickly. This doesn’t itself fix the authentication problem, per se, but it grants more time for reconciling any problems and reduces the benefits that can be gained from attacking the system for a short time.
- Build a more sophisticated digital system for tracking continuity of physical identity – e.g. continuous proofs-of-location – where discontinuous jumps (an authentication request coming from halfway across the world) would raise a red flag (and authentication requests themselves would require proof-of-location).
- Continuous key rotation / “perfect forward secrecy” but for state permissions, whereby the “identity tracking protocol” (say, a combination of agent attestations, proof of location, proof-of-knowledge of the previous key, etc.) continuously rotates the keys which actually grant permissions. This would help a lot in combating key loss / exfiltration – in combination with rate limits, the amount which could be lost to key exfiltration could be capped.
- Time restrictions on permissions usage. This is quite simple but could actually help a lot, because adversaries wouldn’t know what time restrictions you set, and time restrictions don’t require any special context to enforce.
- Embedded chips which cannot be exfiltrated without destroying the key information. Now we’re entering cyborg-territory but the equilibrium here could be very compelling: never lose your keys, no batteries (bio-power as long as you’re alive … somehow), and no incentive to exfiltrate (information would be destroyed).
To be continued…