Firefly Trust Sync

Abstract

Introducing the Firefly Trust Sync (Firefly) architecture as a decentralized, web-of-trust alternative to address the shortcomings of the Certificate Authority (CA) based Public Key Infrastructure (CA-based PKI) and the Pretty Good Privacy (PGP) web-of-trust. Self sovereign identity is a cornerstone of this architecture and yet it does not rely whatsoever on distributed ledger technology. Essential design elements are presented with initial thoughts on both advantages and disadvantages of this approach as well as some next steps.

Abstract
Introduction
1. Problems
2. Goals
Design
Use Cases
Advantages
Disadvantages
1. A server for each identity
2. UX Challenge
Next Steps

Introduction

The success of the Internet has been based on the independence and asynchrony of participants growing organically. The Domain Name Service (DNS¹) is one of the essential Internet services that functions as a federation of decentralized servers which has tracked the growth of the Internet itself. In first wave of e-commerce a solution was needed for consumers to safely transmit their credit card information to merchants and that drove the development of Secure Sockets Layer (SSL) – later Transport Layer Security (TLS) – and the CA-based PKI. The PGP Web of Trust is an effort to leverage public key cryptography for a slightly more generalized model of trust. And yet all of these technologies are succumbing to growing pains or outright attacks.

The name Firefly evokes one of many biomimetic lessons we may discover in nature².

Problems

The Firefly architecture proposes to address these problems:

The CA-based PKI is fragile

The primary problem with the CA-based PKI is the prevalence of Man in the Middle attacks (MiTM³). There have been a series of band-aid measures like Extended Validation certificates (now seen as a failure⁴) and Certificate Transparency⁵ yet the audits can't scale (directly), it has time windows of vulnerability, it may leak browsing information and it doesn't have a standard user experience (UX) in case of auditing failure⁶.

The PGP Web of Trust has problems

The network of automatically synchronized public key servers⁷ has worked remarkably well despite some unfortunate design choices that the identities (UID's which are often e-mail addresses) are completely exposed and anyone can attach certifications to a key. Largely due to UX failures the convenience of using short ID's led to the Evil-32 attack⁸. And to make matters worse now we are now seeing certificate flooding⁹.

Failure of secure e-mail

Despite the availability of core technologies to send PGP encrypted e-mail it simply has failed due to incredible complexity and absolute lack of UX design. In it's place are a myriad of ad-hoc solutions – often involving some poor messaging implementation on a website which is "secured" by TLS¹⁰.

Goals

Firefly architecture aspires to the following goals:

An additional TLS Certificate check

Validating TLS certificates in Firefly could provide additional assurance to Certificate Transparency Auditing and/or offer an alternative verification path for certificates that do not participate in the CA-based PKI.

An alternative public key verification for identities

Perhaps the most common use of the PGP Web of Trust is to verify the public key of an e-mail correspondent with whom we would like to share secure messages. Firefly could replicate this functionality without some of the design shortcomings of PGP network while providing and countermeasures for known attacks.

Avoid the environmental catastrophe of the blockchain

While it is fashionable for self-sovereign digital identity solutions to rely on distributed ledger technology¹¹ Firefly offers an alternative which will not exacerbate climate change¹².

Design

The core principle of Firefly is that each identity owner shall have exclusive control of their private key material. The impact of this design choice is that if the proposed pre-planned key backup and recovery procedures are not followed there is literally no one to call – the identity will be lost. And yet this is the ultimate way to ensure against abuse by third parties – including services offering convenience via key material management or escrow. This creates an additional incentive to take proper care of key material.

Extending SQRL for peer to peer authentication

Software implementations of Firefly will be built "on the shoulders of giants" as is most software. Core key management will be handled with Steve Gibson's public domain Secure Quick Reliable Login (SQRL¹³) technology. The essential concepts leveraged from SQRL include:

An unique public key pair for every identity relationship

SQRL is designed around a master password based Password Based Key Derivation Function (PBKDF) which generates an Ed25519 Elliptic curve public key pair¹⁴ for every website (identity client) requiring authentication.

This leads to one (of many) SQRL advantages in that disparate websites cannot collude to merge identities as the public key for each site is unique. And it obviates using a password manager as the master password is all that is needed to access the keypair for a given client.

A concise, offline, paper based identity backup solution

The master SQRL identity information can be represented in a few hundred bytes and is designed to printed on paper as QR Code for ease of machine scanning (which is useful in the case of sharing an identity between multiple devices). The offline backup is encrypted using a 24-digit decimal Rescue Code which, obviously, should be stored separately.

Firefly extensions involve using SQRL deliberately for machine-to-machine communication (in addition to human user to machine communication) as well as supporting a superset of the SQRL API for web-of-trust operations.

Bootstrapping with DNS and TLS

Any alternate web-of-trust solution could not be "self hosted" initially and thus Firefly will need to begin (at least) by relying on existing DNS and CA-based PKI solutions. Even if self hosting becomes feasible it makes much more sense to use the existing DNS and CA-based PKI as additional inputs to the trust heuristic (i.e. the answers may provide fascinating telemetry that might suggest that a MiTM is being attempted, for example).

To the degree there is concern about DNS accuracy and/or privacy an interim solution may involve using DNS over HTTPS (DOH¹⁵).

Fortunately it is quite easy now to automate creation of Let's Encrypt¹⁶ TLS certificates.

A distributed graph database

Each Firefly identity node maintains a set of trust assertions that may be queried. Unlike the Secure Keyserver network there is no attempt to constantly replicate the entirety of the trust database everywhere. Based on the the type of the query it may be delegated to peers and coalesce responses for for the caller. In this way the query function will move to where the data is located (not vice versa). As the web-of-trust is inherently a social graph it follows that the data should be organized as a graph database¹⁷. And recursive queries in a graph database can have a significant performance advantage in a graph database vs. a relational database¹⁸.

As each identify requires a server the Firefly architecture begins at the maximum possible level of distribution. Just as a well known public key has multiple signatures a well known identity in the Firefly network will have trust assertions on multiple Firefly servers. In this way the network is resilient against node failures.

In creating a query framework intended to gather multiple data points as input to trust heuristics Firefly can weigh the importance of multiple factors including: social proximity, number of positive assertions, number of revocations, age of as assertions, input from classic DNS and/or CA-based PKI or the PGP Web of Trust. Each heuristic may require differing dimensions of consensus depending on the sensitivity of the decision. In the web-of-trust we don't expect the simplicity of "one" answer and yet the signal of consensus will outweigh the noise when an assertion is trustworthy.

Fortunately there is a wealth of resources in supporting graph database design. By adding time to the traditional entity–attribute–value model¹⁹ it is possible to enable queries over time (and presents an opportunity to take advantage of immutability²⁰). The EAVT schema may be more like the Resource Description Framework (RDF²¹) Schema²² or more like other popular EAVT schemas²³.

The implementation of the query language ("Firefly Script") takes inspiration from Datalog²⁴ and SPARQL²⁵. Especially apropos for running queries across the Firefly network is the SPARQL Federated Query²⁶ standard and implementations²⁷.

Anonymity by default

As each Firefly public key is scoped to the context of a given identity server (as inherited from SQRL) each assertion is, by default, anonymous. Each Firefly user can decide the degree to which their public key on any node may be associated with other identities and/or metadata. In this way a public key may be associated with a traditional UID (e.g. e-mail address, service URL) or remain opaque.

Optional Pet Names

As noted in the paper on Pet Names²⁸ "Zooko's Triangle²⁹ tells us that names can have two out of three properties: decentralized, globally unique, human meaningful."

The domain name of a Firefly server (the scope) and a user public key within that server acts as a globally unique identifier. By design it is decentralized, but alas not human meaningful.

Thus one type of trust assertion in Firefly is the association of a Pet Name to Firefly identity giving us hope for human readability and verification.

Onion query obfuscation

In some cases it may be desirable for Firefly queries to identify their provenance (the requesting server), but this is not strictly required. By leveraging work on federated queries and existing Internet Protocol algorithms (e.g. Time-To-Live) one can imagine constructing a layered approach to querying. At each hop in the query a Firefly server is only aware of the identity of the client and does not need to reveal the peers to which it will forward the query. Given a minimum number of hops this may provide TOR³⁰ like query anonymity.

Use Cases

The following use cases are examples of how the Firefly Trust Sync architecture will operate:

Invitation to Firefly

As with many distributed networks participation starts with with an invitation. Firefly's invitation process is inspired by, but hopefully more simple than that of Secure Scuttlebutt³¹.

To explain how Alice will invite Bob to her network these mnemonics will be used:

AD : Alice Domain = https://alice.rocks
AK : Alice private key
Ak : Alice public key
BD : Bob Domain = https://bob.rocks
BK : Bob private key
Bk : Bob public key

The invitation steps are:

Alice sends Bob an invite code (in the EAVT schema): AD Ak nonce-signed-by-AK
Bob verifies that nonce-signed-by-AK matches Ak
Bob replies by authenticating to AD thus creating BK*/*Bk
Bob sends a message to Alice: BD Bk nonce-signed-by-BK
Alice verifies that nonce-signed-by-BK matches Bk
Alice (AD : Ak) is now connected to Bob (BD : Bk)

Identity linking

On Alice's Firefly identity server she wants to assert that she trusts Bob's identity by entering a fact in the graph database:

Alice inserts an assertion (this example inspired by RDF where aid is an unique assertion id):
- aid, wot:truster, Ak
- aid, wot:id, Bk
- aid, wot:sig, AK-signs-Bk

Verify web site certificates

We would like to use Firefly as verification for web site certificates.

Now adding the following mnemonics:

W : Website URL
Wd : The TLS certificate digest for W

Bob wants to publish an assertion that he trusts a given website's certificate:

Bob inserts an assertion (on BD)
- aid, wot:truster, Bk
- aid, wot:web, W
- aid, wot:webcert, Wd
- aid, wot:sig, BK-signs-W-Wd

Given this information in the Firefly database we can propose an extension to Monkeysphere³² to query Firefly in addition to (or as a replacement to) the PGP Web of trust.

Verify ssh server fingerprints

In the same way that Monkeysphere can improve the security and user experience for both ssh server administrators and users³³ we could propose extensions to Monkeysphere for server identities.

Here the assertion entered into the Firefly database is analogous to that for a web server above (and either may allow specifying a non-standard port).

Send Secure e-mail

By selecting an e-mail as a Pet Name and making trust assertions about it two (or more) correspondents may trust they have the proper public with which to encrypt secure e-mail for each other.

If Alice wants to associate the e-mail bob@bob.rocks with BD : Bk she can insert this fact in the database:

Alice trusts Bob's e-mail
- aid, wot:truster, Ak
- aid, wot:firefly, BD
- aid, wot:id, Bk
- aid, wot:email, bob@bob.rocks
- aid, wot:sig, AK-signs-BD-Bk-email

Alice knows, then, she can encrypt e-mail for Bob, and (through analogous steps) Bob knows he can encrypt e-mail for Alice alice@alice.rocks with AD : Ak.

At this point the secure mail exchange approach of Autocrypt³⁴ could be used for Alice and Bob to communicate securely.

Trust revocation

As the database records a timestamp with every entry (the T in EAVT) revoking a previous trust assertion is as easy as inserting a new fact with the attribute wot:revoke in assertions where wot:sig had been used.

Advantages

Here are some advantages of the Firefly Trust Sync architecture:

Distributed secure database

Considering Firefly as a distributed, secure database can see the immense benefits over using the blockchain as a database³⁵.

Would you use a database with these features?

Uses approximately the same amount of electricity as could power an average American household for a day per transaction
Supports 3 transactions / second across a global network with millions of CPUs/purpose-built ASICs
Takes over 10 minutes to "commit" a transaction
Doesn’t acknowledge accepted writes: requires you read your writes, but at any given time you may be on a blockchain fork, meaning your write might not actually make it into the “winning” fork of the blockchain (and no, just making it into the mempool doesn’t count). In other words: “blockchain technology” cannot by definition tell you if a given write is ever accepted/committed except by reading it out of the blockchain itself (and even then)
Can only be used as a transaction ledger denominated in a single currency, or to store/timestamp a maximum of 80 bytes per transaction

But it’s decentralized!

Energy conservation

In making trust assertions by writing to a distributed graph database Firefly is much more energy efficient that having multiple computers sweat to brute force a one way function³⁶:

By late next year, bitcoin could be consuming more electricity than all the world’s solar panels currently produce – about 1.8 percent of global electricity. That would effectively erase decades of progress on renewable energy.

Given the urgency of global climate change we cannot, in good conscience, advocate an alternative web-of-trust solution which is on track to consume 32 Terawatthours (TWh) of energy³⁷.

There is no cabal

Some might advocate that "proof of stake"³⁸ blockchain technology won't suffer from some of the problems of "proof of work" technology³⁹.

And yet, in practice, it would seem that there is still a cabal of minters that have asymmetric community power to create Initial Coin Offerings (ICO's) and reap the benefits of the droit du Seigniorage⁴⁰.

In Firefly there is no dependence on any one specific, occult blockchain network.

No key escrow

Firefly users are in complete control of their private key material and do not need to trust any third party "escrow" service.

Network tolerant of identity server failures

As each identity is represented by a Firefly node (maximal distribution) and widely held trust assertions are dispersed across the network it is tolerant of temporary identity server failure.

Anti-spam provision

As only trusted identities can make assertions the dispersion of naively "astroturfing" facts is limited.

Anonymity by default

Firefly makes Pet Name style associations on a voluntary basis by starting at a default of anonymity.

Disadvantages

Here are some disadvantages of the Firefly Trust Sync architecture that need further consideration:

A server for each identity

While each Firefly identity does not require a physical "server" per se it does require it's own domain name, TLS certificate, and web service API implementation.

The cost of asserting identities in Firefly is much higher than in the current PGP Web of trust. While this may have a benefit of discouraging the propagation of "noise", it is yet a barrier to adoption.

UX Challenge

One of the failures of the PGP Web of Trust was the utter lack of user experience design. While the building blocks of SQRL, Monkeysphere and Autocrypt have made great progress in addressing parts of the UX challenge, Firefly will need comprehensive UX design to successful

Next Steps

Further discussion and analysis of the Firefly Trust Sync architecture is welcome. Here are a few important next steps to consider:

Immutability and GDPR Compliance

There is a certain engineering elegance to an immutable database and "append only" logs have significant benefits from a security auditing point of view. But what do we do when the "nuclear launch codes" get accidentally added to the database. Or what about very offensive speech?

An early question to resolve is to determine if there's any way to get the security (and other benefits) of an immutable database⁴¹ and yet be in compliance with Europe's General Data Protection Regulation (GDPR⁴²)?

Open Source Prototype

There's nothing like working code to demonstrate that an architecture design is plausible. An essential next step will be to build open source prototypes of Firefly, including necessary extensions to SQRL, Monkeysphere and Autocrypt.

Performance Analysis

Given a prototype Firefly implementation it will be possible to test common operations under synthetic load to determine likely performance characteristics.

Auditing and reproducible builds

Throughout the discussion of Firefly the focus has been about trusting the data in the graph database. Clearly Firefly needs to enable users to trust the software that implements the system as well.

There may be an opportunity to make trust assertions about the reproducibility⁴³ of Firefly software such that users chain trust the "entire chain of custody" of a trust assertion (including the software).