A Truly Self-Sovereign Identity System

07/01/2020
by   Quinten Stokkink, et al.
Delft University of Technology
0

Digital identity is essential to access services such as: online banking, income tax portals, and online higher education. Digital identity is often outsourced to central digital identity providers, introducing a critical dependency. Self-Sovereign Identity gives citizens the ownership back of their own identity. However, proposed solutions concentrate on data disclosure protocols and are unable to produce identity with legal status. We identify how related work attempts to legalize identity by reintroducing centralization and disregards common attacks on peer-to-peer interactions, missing out on the strong privacy guarantees offered by the data disclosure protocols. To address this problem we present IPv8, a complete system for passport-grade Self-Sovereign Identity. Our design consists of a hierarchy of middleware layers which are minimally required to establish legal viability. IPv8 is comprised of a peer-to-peer middleware stack with Sybil attack resilience and strong privacy through onion routing. No other work has offered an operational prototype of an academically pure identity solution without any trusted third parties, critical external services, or any server in general.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

11/03/2021

A Survey of Self-Sovereign Identity Ecosystem

Self-sovereign identity is the next evolution of identity management mod...
06/22/2021

Self-sovereign identity as a tool for digital democracy

The importance of digital identity as a foundation for digital public se...
07/26/2020

Who Watches the Watchmen? A Review of Subjective Approaches for Sybil-resistance in Proof of Personhood Protocols

Most current self-sovereign identity systems may be categorized as stric...
01/21/2020

Resilient Privacy Protection for Location-Based Services through Decentralization

Location-based Services (LBSs) provide valuable features but can also re...
03/08/2018

Digital Identity: The Effect of Trust and Reputation Information on User Judgement in the Sharing Economy

The Sharing Economy (SE) is a growing ecosystem focusing on peer-to-peer...
06/05/2018

Deployment of a Blockchain-Based Self-Sovereign Identity

Digital identity is unsolved: after many years of research there is stil...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

Abstract

Digital identity is essential to access services such as: online banking, income tax portals, and online higher education. Digital identity is often outsourced to central digital identity providers, introducing a critical dependency. Self-Sovereign Identity gives citizens the ownership back of their own identity. However, proposed solutions concentrate on data disclosure protocols and are unable to produce identity with legal status. We identify how related work attempts to legalize identity by reintroducing centralization and disregards common attacks on peer-to-peer interactions, missing out on the strong privacy guarantees offered by the data disclosure protocols. To address this problem we present IPv8, a complete system for passport-grade Self-Sovereign Identity. Our design consists of a hierarchy of middleware layers which are minimally required to establish legal viability. IPv8 is comprised of a peer-to-peer middleware stack with Sybil attack resilience and strong privacy through onion routing. No other work has offered an operational prototype of an academically pure identity solution without any trusted third parties, critical external services, or any server in general.

1 Introduction

Who are you? is the central question in this time of identity theft, phishing attacks, election meddling, fake reviews, behavioral tracking, and bots spreading misinformation on social media. Our identity and daily life is going digital, including our friendships, education, employment, healthcare, finance, and entertainment. Solving the problem of digital identity is becoming a societal concern [68, 59]. The scope for digital identity is broad, as it should be usable for both filling in online web forms and also for boarding international flights. In this paper we introduce a novel distributed infrastructure for digital identity which meets the stringent passport-grade requirement of governments, provides strong privacy protection for citizens, and does not rely on any third party.

Self-Sovereign Identity (SSI) is a new approach to online identity. This approach promises to solve the current problems around online identity and provide the underpinning for our digital society and economy [96]. The essential premise of SSI is that it is in your complete control. No central entity exists to manage your identity, give you permission to use it, or which can revoke your entire online presence. The SSI approach empowers individuals and entities themselves to manage their identities in a decentralized fashion, without reliance on any third-party identity provider.

A basic SSI contains cryptographically signed information such as I am older than 21, I am licensed to drive a car, and a more complex My pre-tax income lies between 40k and 50k, which are called verifiable claims. In a future form we believe that all your online passwords, car keys, credit cards and even banknotes will be stored in some form of personal digital wallet. For instance, various central banks are experimenting with Central Bank Digital Currency [29]. These verifiable claims need to be signed and given to you by trustworthy issuers, but do not contain any personally identifiable information. This approach using a wallet is known as claim-based identification [25, 4, 82]. SSI is designed to protect your privacy and only disclose the minimally required information. Current scientific research in this area is primarily focused on the data disclosure protocols and ensuring minimal or even zero privacy leakage (e.g., Zero-Knowledge Proofs [42]).

Our aim is to close the gap between state-of-the-art academic proposals and deficient (non-)commercial offerings, and on the other side real-world usage of SSI for each transaction within our daily lives: from airplane boarding to online product reviews. The special property that we offer is strong privacy, without compromising on security. Our approach is compliant with one of strongest consumer privacy protection laws: The European Union GDPR [54].

Within this work we focus on strong privacy for SSI. Deanonymization of users, the loss of strong privacy, is rarely performed through frontal attacks on the cryptography of data disclosure protocols. Device fingerprinting is one of the main methods to compromise privacy of Internet users [99, 16]. We are not the first to suggest using Tor to address this privacy concern [91], but we are the first to create a viable prototype in a truly Self-Sovereign manner (a truly zero-server approach). We document our complete system, geared towards deployment and standard setting.

Our scientific contribution is two-fold:

  1. We provide a complete and substantiated design for the creation of Self-Sovereign Identity solutions with strong privacy called IPv8.

  2. We discuss the performance, drawbacks and possible attacks on the identified core components of a passport-grade Self-Sovereign Identity solution.

2 Problem statement

Verifiable claims (e.g. “I am older than 21”) form the heart of Self-Sovereign Identity [25, 4, 82]. Existing work in this area often reduces the problem as merely a data disclosure problem, thereby ignoring many other problems and essential components. A complete architectural view of Self-Sovereign Identities is missing, which would identify open problems and outline these many components. We believe passport-grade digital identity is required for broad societal usage, necessarily involving governments. To date, no work has identified or addressed the gap between state-of-the-art academic research and the functional and legal requirements of governments. Existing works which offer a complete digital identity solution contain a large number of (fragile) components which compromise Self-Sovereignty or compromise privacy; they nullify Zero-Knowledge Proofs [16]. The problem remains how to provide an academically pure Self-Sovereign Identity solution with strong privacy, full decentralisation, and only depending on pure peer-to-peer communication. All existing work depends on a central permissioned server (Hyperledger Indy [46]), central non-profit organization (IRMA [6]), central universal resolver (DID [83]), or smart contract payment handler (uPort [65]).

The philosophical principles for Self-Sovereign Identity have been already established [4]. The concept of Self-Sovereign Identity dictates that no third party should be able to observe or interfere with either establishment or verification of claims over identity data. We formulate the first exact technical problem specification as follows: Two peers communicate their requests and responses (requiring integrity and authenticity) to perform identity disclosure with accountability via a decentrally established covert channel. The identity data disclosure should allow for four types of messaging over two message flows (see Figure 1):

  • Flow A: Claim creation (A.1) and attestation to a created claim by an issuer (A.2).

  • Flow B: Request for proof of a claim (B.1) and subsequent proof of a claim (B.2).

An analogous physical example of this digital interaction is a citizen claiming to be older than 21 (A.1) and a government providing a passport that proves this claim (A.2). The citizen in this example could then later attempt to buy liquor in a liquor store which would ask for proof that this citizen is over 21 (B.1) for which the citizen shows his passport (B.2). We will discuss the various implementations of claims such as this one in Section 6.

Figure 1: The two communication flows when establishing and verifying a claim. Both flows go through the subject in a Self-Sovereign Identity solution.

3 IPv8 Design

We now present our system which fulfills our technical problem description: IPv8. IPv8 has been initiated in 2016 and created in tight collaboration with both government and industry. Our methodology consists of an iterative process of documenting, rapid prototyping, small-scale trials, and deep-dive sessions. Legal experts have established that in legal terms Self-Sovereign Identity is an unexplored field. Our design complies as much as possible with existing standards for authentication. For instance, authentication levels for digital identities have long since been standardized by the National Institute of Standards and Technology [44].

An essential IPv8 design choice for security and privacy is that the verifiable claims are stored in encrypted form. Unlocking these encrypted claims requires passport-grade facial recognition. This component in IPv8 is supplied by IDEMIA, the paper-based passport supplier of Kingdom of the Netherlands. After various cycles of real-world testing and re-design we identified

7 top-level requirements, and derived a middleware architecture with 3 layers, see Figure 2.

Figure 2: The stack of components that makes IPv8.

3.1 Communication Substrate

The bottom-layer of IPv8 within Figure 2 provides communication services. This also introduces top-level requirements (1),(2), and (3). Peers must be able to (1) communicate without an intermediary. To disallow this communication from being modified by a malicious peer, messages must be (2) authentic and maintain (3) integrity.

Messaging Interface. The messaging interface serves the design pillar of decentralized communication. The messaging interface standardizes communication between nodes in the network and is responsible for blocking (but not detecting) network-level attacks like spam attacks [63].

Decentralized Public Key Infrastructure. The DPKI layer serves authenticity and integrity of messages between peers using digital signatures. This middleware layer also makes sure blacklisted identities are not communicated with and forms the basis for identity-to-identity communication.

3.2 Anonymization Overlay

Our second layer of Figure 2 facilitates decentral (4) anonymization to both disallow malicious peers blocking communication and malicious verifiers from tracking subjects (becoming the malicious intermediary in another message flow). To establish anonymization, peers in the network will have to be able to (5) synchronize information.

Overlay Framework. The network overlay middleware facilitates synchronization between peers and handles common interactions for (structured and unstructured [81]) overlays. It facilitates user-defined message flows and handles messages for internal session management, like NAT puncturing. This layer also detects attacks and node churn. Overlays building on this middleware will simply be shown a list of peers (based on public keys) they can send messages to.

Anonymization Overlay. The anonymization overlay is required for anonymization of communication, which we will refer to as communication through covert channels. This layer allows users to rendezvous and communicate covertly without publicly announcing this on a DHT mechanism, which could be blocked by attackers.

3.3 Identification Layer

Using the anonymization, peers should be able to (6) identify themselves using a data disclosure scheme. However, peers do need to be held (7) accountable for their actions to have their identities hold legal value.

Persistent Storage Overlay. To facilitate a wide array of commitment and revocation schemes used by the SSI layer, applications need to be accountable. This accountability is achieved through the storage of immutable information (verifiable integrity). The stored information may be available network-wide, such as in blockchain, or behind access control lists (only shared and verifiable for selected parties).

Self-Sovereign Identity Overlay. Finally, the SSI overlay allows for identification. This layer handles the SSI-related communication between pseudonyms. It defines the semantics, storage and method of proving claims tied to pseudonyms. The high-level functionality of this layer is exposed to the application layer.

4 Communication Substrate

Any machine-to-machine communication constitutes a breach of identity. Fundamentally, any signal that is sent out into the world can be tracked to a source (be it a radio signal, an IP-address, or otherwise). This is a law of nature and seems to prevent any identity solution from being privacy preserving. However, being identifiable in a local neighborhood does allow for covert communication establishment on a pseudonym basis. As Self-Sovereign Identity dictates the absence of intermediaries, a central server cannot mediate a covert communication channel however. Therefore, IPv8 includes decentral networking primitives that form the basis for establishing covert communication channels (which we discuss later in Section 5) defining a communication protocol with open membership, interoperability and trust.

Whereas the topic of peer-to-peer messaging and its corresponding network protocols is a dead topic to academia, it remains the primary attack vector on Internet-scale decentral systems like Bitcoin and remains littered with open problems 

[72, 50]. One may be tempted to patch up existing identity solutions using Tor [91]. Sadly, the straightforward application of Tor is not sufficient for these types of systems [15].As these networking primitives are often omitted not only from the literature but also from the implementation, we present a short overview of essential features of peer-to-peer communication in adversarial settings. Self-Sovereign Identity solutions need to consciously consider their networking primitives or face deanonymization on the application layer.

4.1 Messaging and DPKI

Both Decentralized Public Key Infrastructure [1] and Message Oriented Middleware [9] have been well-explored. As they form the primary attack vectors on IPv8, we briefly discuss the responsibilities and functionality of these layers.

Messaging interface. IPv8 allows for messaging over heterogeneous media, like the Internet, Bluetooth, NFC and any other medium that allows for messages to be sent (even QR-codes—though camera-to-camera communication is quite impractical). Due to the abstraction over all these types of connection media, IPv8 provides a connectionless messaging API to higher layers (hiding possible connection sessions). This allows IPv8 to be used by both stateful network session managers like TCP and stateless frame-based session managers like UDP. The messaging interface abstracts over all these media, but explicitly exposes the available interface options to the overlay middleware. This interface must allow the overlay layer to close connections to detected Sybils, spammers or otherwise malicious nodes [63].

Given an adapter for the message serialization format, we note that the messaging interface does not hamper the interoperability sought after by Self-Sovereign Identity solutions. Ultimately, the control over what data gets sent over the communication channels lies with the overlay layer. Even though IPv8 defines a default format, users of are not bound to it. However, a properly defined binary format like IPv8’s will use less space than Google’s Protobuf or JSON implementations [78], the consequences of which we will evaluate in Section 8 (with JSON being the primary messaging format of IPv8’s competition).

Decentralized Public Key Infrastructure. The DPKI middleware of IPv8 is tasked with managing peers: public keys with their respectively known connection interfaces and channel identifiers. This forms the fundamental design principle of IPv8: identity to identity communication. The DPKI layer manages supported cryptographic protocols and takes care of creating signatures for all outgoing messages and verifying signatures for all incoming messages.

One of the principles of Self-Sovereign Identity is the ability to choose whatever identity the user likes. This freedom is still bound by implementation though and—at the time of writing—IPv8 only supports the following key formats: SECT163K1, SECT233K1, SECT409K1, SECT571R1 and EC25519 (with the latter being the default as it has been proven to be secure [13]). The supported elliptic curves are the first major hurdle for users of our SSI framework as two users cannot communicate if they do not share the same cryptographic algorithms. IPv8 encourages (but is not bound to) elliptic curve cryptography, as it has smaller public key and signature sizes [10].

4.2 Overlay Framework

Given our messaging and DPKI middleware, we now reach the abstraction layer of a distributed event-based system and its many facets and security concerns [70]. The overlay framework drives the event-driven nature of all network overlays in our architecture, providing the ability to hook in periodic tasks. These tasks range from peer discovery and peer churn to instigating push-based gossip. Though all messages that reach the overlay framework are bound to an identity, these identities may still be malicious or otherwise byzantine. The overlay framework makes the process of dealing with these unwanted nodes opaque for any overlays built on top of it. This framework ensures that peers available to the overlay will converge to a set of non-byzantine peers.

Figure 3: Time for gossiped information to converge for different network and local neighborhood sizes, using the IPv8 neighborhood creation protocol.

Peer discovery. The gossip protocols in IPv8 overlays will not work if the network graph is not robust, that is all honest nodes being interconnected in one large component [33]. Therefore, the peer discovery mechanism of IPv8 converges to a set of honest nodes through periodic random walks, which repeatedly sample the known peers and bootstrap nodes to expand their neighborhood. We note that no decentral protocol exists that guarantees a non-eclipsed/non-Sybil neighborhood upon bootstrapping into the network, only algorithms that converge over time [92]. We have chosen the method of testing physical resources to avoid Sybils [97] (which we discuss in Section 5).

Our peer discovery protocol will actively connect to 20 other peers to form a neighborhood and allow for up to 30 total open connections through the active peer discovery of other peers. This brings the information dissemination time of gossiping protocols down to seconds for networks of even millions of users, we show the result of a simulation with the King latency dataset [28] and our deployed protocol in Figure 3. This convergence time will be the primary driver for performance of distributed synchronization mechanisms.

Hole punching. An interface that has been discovered cannot necessarily be communicated with. Many interfaces (e.g., Firewalls and NAT layers) will need to be punctured or hole punched before two-way communication can be established [38]. This is a complex procedure for peer-to-peer networks, especially for TCP with IPv4 addresses. IPv8 remembers the introducing peers (the network state in Figure 2), which can facilitate establishing connections to introduced peers. The particular messages to send to perform hole-punching, upon deciding to connect to an introduced peer, are defined by the actual interfaces.

Churn. Offline nodes cannot forward data, which severely impacts the performance of overlay logic [60].Next to having a list of interfaces and corresponding addresses, peers also store the time the last message was received. Periodically, a random sample of peers is checked for liveness – 30 seconds by default, after which a peer will be contacted twice (after 10 and 20 seconds). After a full minute (based on Internet measurements of timeouts of deployed NAT algorithms [49]) without any messages a peer is dropped.

Synchronization. Given a set of (1) live, (2) connected and (3) non-Sybil peers, a peer can synchronize information with the network through gossip or flooding. Being able to synchronize views with other honest peers allows a peer to make use of both audit and revocation mechanisms, important for Self-Sovereign Identities. The manner in which information is disseminated and to what level the network is synchronized is specified per message and per overlay.

5 Anonymization Overlay

All identity overlay messages in IPv8 are sent and received covertly through the anonymization overlay. Especially for mobile usecases, device fingerprinting can instantly deanonymize even the cryptographically most secure protocol. Furthermore, an attacker that is able to determine a channel between two peers can perform a DOS attack to prevent communication from happening. To solve these issues we have introduced covert channels through the Tor onioning protocol with hidden services [32, 73]. This allows all peers to decentrally establish a hidden channel through several other peers for anonymization, without being susceptible to man-in-the-middle attacks using Tor exit nodes [15]. To achieve this covert channel construction being both (1) decentralized and (2) attacker-resilient utilizes two novel protocols unique to IPv8.

Fingerprinting. The ability to fingerprint communication channels or hardware [99] completely negates the security guarantees of identity disclosure protocols [91]. This is often overlooked in the marketing and creation of identity solutions. Static or semi-static identifiers such as MAC addresses or IP addresses make it readily apparent that any two disclosed unlinkable attributes or unlinkable pseudonyms belong together (even MAC randomization often will not help  [67, 94]). For example, Camenisch-Lysyanskaya signatures allow for derivation of a new and unlinkable signature over the same data [24]. However, presenting two signatures from the same device with the same MAC address and the same IP address (both leaked over Wi-Fi) makes these signatures completely linkable. This has even also practically been shown to be a primary attack vector for the poster-child anonymized cryptocurrency ZCash [16].

DOS attacks. An attacker may not always wish to deanonymize a user, sometimes blocking the identification itself may be sufficient. For example, if a representative of a competing company fails to get a loan in time to execute a particular contract, the contract may expire and go to its competitor. This type of attack will be harder to protect against in the age of smart contracts and automated digital markets as—by design—no human can reason about external factors. Originally explored through mixnets [26], by introducing covert channels, attackers cannot practically discern the communication channel of their target. The only way for an attacker to block communication is to indiscriminately attack all communication in the entire network. Whereas one-off attacks (such as defection attacks or DOS attacking of a particular peer) are hard to detect in a network, forcing the attackers to perform multiple indiscriminate attacks helps in the detection of attackers [80].

Decentralized Hidden Services. The Tor protocol was originally created to allow covert channels to be established [32]. Through the process of onioning over multiple network participants, information is practically anonymized as the original source of the information cannot practically be found. This onioning consists of several layers of encryption of the same data, both hiding the preceding and following path the information will travel through—only being fully decrypted at the end of the path. An extension to the Tor protocol allows two peers to interact with end-to-end encryption over two of these onioned communication paths linked together, called hidden services. IPv8 uses a novel decentralized version of Tor’s hidden services protocol, not requiring centralized directory servers [73].

Attack resilience. As IPv8 is fully decentralized, attackers can introduce Sybils into the network to attack our path selection protocol (this protocol is also called telescoping). To avoid Sybils, IPv8 finds a sufficiently diverse set of peers through tests of physical resources [97]. This type of practical Sybil avoidance was first explored in the context of DHT security [92]. Concretely, our novel protocol test latency in a manner for which fake latencies are detected over time [90]. The idea is that, over time, a non-Sybil peer will be available and selected to establish a covert channel, allowing communication to the outside world. A Sybil attack will never cause a permanent or unrecoverable partitioning of honest nodes in the network when coupled to a random walk strategy for peer discovery [22], as deployed in IPv8.

Figure 4: The time until an honest node is found by IPv8 as the fraction of Sybil identities increases.

To show the practical attack resilience of our protocol, we sample real peers from our Tribler network. We also create Sybils, where each Sybil only introduces other Sybils and actively attacks our protocol by artificially modifying its latency. We sample from both groups to create different fractions of attackers, for a total of peers. We then measure the amount of time it takes for an honest node to be found and a covert channel to be established. We have graphed the results of our deployed protocol in Figure 4. Even in a Sybil network, honest nodes connect (and retain) other honest nodes after seconds. If we extrapolate these results to our network of 50 000 nodes, this means attackers will need to be responsive with almost million Sybil identities to delay bootstrapping nodes by almost

minutes. We have estimated the cost of this attack on our current network to be roughly

million USD in our previous work [90].

6 Self-Sovereign Identity Overlay

After establishing a covert channel to another peer in the network possibly in adversarial conditions, finally a data disclosure protocol can be used. We first discuss the fundamental workings of Self-Sovereign pseudonyms, their management, and their interactions using IPv8. In Section 7 we elaborate on this Self-Sovereign Identity disclosure scheme and show how to elevate the resulting pseudonyms to a passport grade Self-Sovereign Identity.

Zero-Knowledge Proofs. Zero-Knowledge Proofs form the core of the information disclosure mechanism in IPv8. A Zero-Knowledge Proof is a construction that allows one party to learn of only a property of some information known to the other party, without revealing the actual information [42]. A practical example is only revealing a subject is over 21 but not the exact age of the subject. This differs from signatures as Zero-Knowledge Proofs provide a decoupling of authenticity and knowledge of information (only providing the latter, whereas a digital signature provides both). We build upon this decoupling and it will be important for establishing pseudonyms of legal status.

In IPv8, the Zero-Knowledge Proof library contains three algorithms: non-interactive Peng-Bao range proofs [75], Camenisch-Lysyanskaya signatures [24] and our own variant of identity-based Proof of Plaintext [43] construction in the encrypted domain using Boneh’s cryptosystem [18]. Which algorithm is used, is driven by the semantic layer using the Zero-Knowledge Proof library and parameterization of the algorithms is stored inside metadata supplied with each commitment. IPv8 abstracts over these Zero-Knowledge Proofs by modularizing them and adding an interface for the application layer to create and prove any implemented proof. The nomenclature for a commitment that represents information (held by and of an individual) that can be shown to have certain properties is an attribute, when supplied with metadata it becomes a credential [5] over which claims are made (A.1 in Figure 1).

The storage of each attribute concerns three types of data (of which IPv8 implements two): the data supporting an attribute, the private data to support the proving of the attribute, and the public data bound to the pseudonym. Of these three types of data, the data behind the attribute is not stored by IPv8 and can be stored on secure hardware or reconstructed from the memory of the user (e.g., a password). In whatever manner this information is retrieved at runtime, which is application and use case specific, it is supplemented with the private data stored by IPv8 to form answers to the challenges posed by the other party involved in the Zero-Knowledge Proof (the verifier). To create these challenges, the verifier does need to know the semantics (specifying the ZKP algorithm) and the public data needed for the proof (e.g., the cryptographic commitment). A subject can whitelist a verifying party to receive the metadata for a certain attribute through applications built on IPv8.

Web of trust. The credibility of an attribute lies not with the data it holds, but with those who attest to its truth. What distinguishes a passport from a list of identity information is the signature of your government. This same concept holds for digital identities as well. For example, the fact that a subject has an age and can show it is over 21 has no legal value unless the government has digitally signed for the fact that the data in the commitment this was shown for is correct. IPv8 exposes the public keys that signed for certain attributes, but leaves the trust model to the application layer.

In IPv8 the signatures of third parties are collected (just like the PGP web of trust [100]) to attest to the credibility or truth of attributes (A.2 in Figure 1). These signatures are made independently by third parties over the metadata of the attribute, whereby this attestation is locked to a specific commitment and ZKP protocol to avoid misuse of the signature. However, this web of trust forms a social network: a side-channel that allows for fingerprinting [88]. The selective disclosure of metadata and attestations is left to the discretion of the user and over-use will allow for this attack. Paradoxically, a single centralized attesting authority actually avoids this as no social network can be derived.

Figure 5: Information structure of pseudonyms: a chain of hashes from attesting signatures towards an originating pseudonym public key.

Attribute-based pseudonyms. By combining Zero-Knowledge Proofs, metadata, and third-party signatures (attestations), a pseudonym of legal status can be created. As IPv8 is Self-Sovereign, a pseudonym can simply be created by generating a key pair with any of the elliptic curves supported by IPv8—without identity vetting.

A user can add attributes to its pseudonym by attaching attributes using the hash of the preceding attribute (or the public key of the pseudonym), like the hash chains of blockchains. Metadata will have to support each attribute, for which we once again use a hash to point to the respective attribute. Finally, the collected third party signatures point to the metadata through a digital signature (which internally also uses a hash), which in turn binds the metadata to the public key of the signing third party—a pseudonym in itself (forming a web of trust between pseudonyms). We now have pseudonyms with attributes and we can fall back to the NIST recommendations on Attribute-Based Access Control for the business logic surrounding these pseudonyms [51]. The resulting structure of a single pseudonym is shown in Figure 5.

Each pseudonym should contain as few attributes as possible. The more information is revealed through a pseudonym, the stronger the correlation with a particular individual or other pseudonyms will be. By creating an immutable linked list of attributes, we allow for attributes to depend on each other. This immutability makes sure attributes are not mixed-and-matched from other pseudonyms, creating session guarantees. For instance, a driver’s license may critically depend on a particular name, but the name may not always have to be disclosed. To obfuscate the commitments belonging to the undisclosed attributes, each attribute only contains the hash of the public data and the hash of the preceding attribute. The actual commitment will only be shared when executing the Zero-Knowledge Proof over the attribute.

Each attribute is tied to the public key of the pseudonym. However, ownership of this public key has to be shown—at least once—to tie the session in the covert channel to the presented pseudonym. This can be done by providing a digital signature over a nonce (supplied by a verifying party) with the private key belonging to the pseudonym, but should only be done once and when any verification is performed, as usage of this key weakens its security [62].

Authentication through attributes. A session with a pseudonym may be authentic and covert, but device theft may have occurred: the holder of the device might not correspond to the enrolled identity. What drives the value and interoperability of Self-Sovereign Identities, is the portability of its available authentication mechanisms [96].Not only should you be able to verify a certain property of data signed for by a third party, you should be able to verify the same authentication was used at the time of verification. This allows an application to bind the physical user to its device. For this verification of third party authentication, we can also use the attributes of a pseudonym [57].

The contents of authenticating attributes can vary from One Time Passwords (e.g. with YubiKey [52]) to static passwords and even biometric checks (we have even implemented Physically Unclonable Functions (PUFs) on off-the-shelf SRAM chips [86]). It is important that these types of checks include liveness detection. Though attacks on hardware (tokens) and biometry are prevalent (iris scans and facial detection can be fooled [84, 66]), the more authentication attributes are added to a pseudonym, the better its security guarantees will be (going even far beyond the standards of the NIST on demand [44]). The first prototype of IPv8 included only (closed-source) facial recognition by IDEMIA. The holder of the device was challenged to move his or her face in a certain direction, one of the available mechanisms to avoid spoofing [40].

Verification of attributes. At some point in its business logic a verifying party will require a proof of some attribute of a pseudonym: a request for information disclosure (B.1 in Figure 1). We assume this initial interaction happens outside of IPv8, but provides a link between the two respective identities (for example by scanning a QR code of the key of each user or communicated within an HTTPS session—both of which we have implemented for IPv8). The verification logic in IPv8 is then intiated by the verifying party requesting proof of a certain type of (standardized) metadata. A simplified typical request would be ("age", "ZKRP Peng-Bao", "version 3")—specifying the semantics, the ZKP algorithm and the parameterization of the required attribute. Such a request for verification is mapped onto the available attributes of a pseudonym based on the metadata. IPv8 will present the application layer with the most recent attribute that fulfills the verification requirements.

Through the REST API of IPv8 the outstanding verification requests are communicated to the holder of a pseudonym and have to be manually allowed (this is the principle of control in Self-Sovereign Identities). When allowed, IPv8 will automatically share (1) the metadata of the particular attribute, (2) the attribute and all preceding attributes in the hash chain and (3) the attestations belonging to this metadata (B.2 in Figure 1

). After confirming the structural integrity of the hash chain, the verifier’s IPv8 instance will generate a series of challenges for the presented ZKP. The subject’s IPv8 instance will answer these requests automatically and the verifier’s IPv8 instance then calculates the output of the ZKP. The verifier will then check it’s REST API to see the outcome of the ZKP protocol, which usually completes within a few seconds, and reason about the presented probability (the default settings of IPv8 go up to roughly

probability, completing in on a modern smartphone).

7 Persistent Storage Overlay

A Self-Sovereign Identity of passport grade requires more than just revealing information. To be on the level of passports, audit logs must exist for governments to hold individuals accountable for their use and misuse of their identities [3, 76]. Punishable but correct identity use would be an individual breaking the law after gaining access to some resource (e.g. a certified bank employee logging into his bank system and stealing all of the money). Punishable and incorrect use would be attempting to identify with the claims of others, i.e. identity theft—which is a federal offense in many parts of the world [93]. To enforce punishment, parties attesting to the truth of attributes may want to revoke their attestation of a particular attribute. The validity of a passport may, for example, need to be instantly retracted once the individual commits a terrorist act. Both of these punishable acts require persistent storage, albeit in different fashions.

Audit logs. Use of any pseudonym has to be auditable to hold individuals accountable and to be trustworthy. The trust in pseudonyms in IPv8 is anchored in attributes and the pseudonyms that attest to them through a web of trust. At the same time, Self-Sovereign Identity is inherently permissionless. To hold individuals accountable a longer-term log of interaction will have to be maintained. By storing the commitments, metadata and attestations presented to a verifier, the state of a pseudonym at the time of using it to engage in a business transaction can be captured—as we have explored in our previous work [89]. However, as attributes are essentially conflict-free data types [87], no network-wide consensus is required (or desirable for that matter). For example, a liquor store should be able to prove to an auditor (through the construction we explained in Section 6) that a pseudonym it has interacted with had valid facial recognition and was older than 21.

Though the audit logs are immutable through signatures (to avoid tampering and to hold legal status), they should not be shared publicly. Only certified auditors may piece together which individual belongs to the particular pseudonym. We achieve this by requiring all businesses to check for an attribute that is attested by a certified auditor (e.g. a facial recognition attribute made by a government). Through the auditor maintaining (with a Proof of Plaintext Knowledge) a secret link between the attribute of the pseudonym and the central register of all citizens, pseudonyms can be held accountable. Note that both the user and the verifier of the Self-Sovereign Identity may choose not to allow auditing, but will probably be forced —by law— to do so. This is a regulatory gray area as more stringent regulation only follows after widespread use—as has happened for cryptocurrencies [77]—which we attempt to enable preemptively.

Practically, the auditability of pseudonyms functions much like collaterals in cryptocurrencies [7]. Any legal pseudonym holds a cryptographic commitment signed by an auditing authority as a collateral for passport-grade interaction. This commitment does not have to be used for all use cases, only for passport-grade interactions. We note that new pseudonyms can be enrolled on-demand by the user at passport level using a combination of unlinkable signature derivation (e.g. using CL signatures [24] or BLS signatures [19]), commitment blinding (for example Pedersen commitments [74]) and a commitment equality scheme (for example Boudot’s commitment equality check [23]). The regulatory requirements for decrypting such a commitment have not been standardized or drafted at this point in time.

Revocation. The philosophy of Self-Sovereign Identities is that users control their own data and are free to remove it or hide it from others [4]. This allows the citizen the control over the use of the identity information of the respective citizen. However, the credibility or value of presented information lies not with the information itself—but with the authority that signs for it. A practical example is that the signature of a government holds more power over the truth in the eyes of a third party of residence permits than the signature of your next-door neighbor.

Figure 6: The self-reinforcing loop of credibility through digital signatures.

With the practical imbalance in authority, digital signatures become the primary method of credibility in a decentralized identity system. In turn, with deriving credibility comes the risk of influencing the legitimacy of authorities [45], forming the feedback loop of Figure 6. Signatures over false data or false claims result in reputation damage (and therefore the credibility to be derived from signatures of this entity). As passports and the certification of passports are a paid service, managing this risk also has monetary value. For any authorities signing for data of citizens (users of the identity solution) making sure that their signatures only apply to correct data or claims is therefore of the utmost importance to their credibility and therefore business model or public services. Being able to rectify or revoke signatures by authorities that have been granted to citizens is therefore the cornerstone of crediblity and legality.

Several solutions have been deployed to enable revocation by authorities [48]. The first and fastest solution adds a link to the revocation register (central server) of the signing authority, e.g., a revocation authority in IRMA [64]. However, the signing authority will have to be online and can track the use of the attribute (see our earlier notes on fingerprinting)—which is not self-sovereign. The second solution is the complete decentralization of revocations using a shared log, e.g., a blockchain—as used by Sovrin [53]

, and (anonymized) membership tests for signatures/attestations. Writing to a shared log takes more time for the revocation to reach finality, could invalidate the incentives the log was built around and has the issue of unbounded growth of the log. The third solution is to include validity terms into the metadata of attributes, e.g. epochs of lifetime in Idemix 

[14]. By applying shorter validity terms to attributes, the risk of the snapshot of the attribute being out of date is mitigated. The downside of validity terms is that they are snapshots and are not instantly revoked. None of the available revocation methods fits all use cases, but IPv8 enables all three.

(a) Enrollment
(b) Verification
Figure 7: Latency of credential creation and verification using different identity semantics and solutions.
(a) Enrollment
(b) Verification
Figure 8: CPU usage of credential creation and verification using different identity semantics and solutions.

8 Evaluation

The primary carriers for Self-Sovereign Identities are mobile devices, as they are portable and can be easily supplied with identity information (e.g. biometry through their camera or by plugging in hardware tokens into the USB port). Next to the time it takes to actually establish claims and prove them, which form the main flows of Figure 1, we also measure the CPU and network traffic (in Section 8.2 and Section 8.3 respectively). These are relevant performance metrics, as mobile devices often have scarce resources (or at least limited battery life). Both CPU and networking capabilities of mobile devices are limited and costly. Hereby we show which of the components of our system warrant performance optimizations. For example, the chosen parameterization of the anonymization layer greatly impacts the latency of both attribute enrollment and verification.

Bartolomeu [11] presents several options for systems to benchmark against: Hyperledger Indy, uPort, Veres One and Jolocom. If we eliminate all solutions that either use a permissioned blockchain or require payment to use (two clear indicators that a solution is not truly Self-Sovereign), we end up with no solutions. Even though we object to naming these solutions Self-Sovereign, for the sake of benchmarking, we will still compare our “transaction” delay (attribute enrollment) to these solutions in Section 8.1 (except for Veres One, which was already identified as non-competitive by Bartolomeu [11]). Furthermore, given the nature of our use case, we do not believe throughput is an appropriate metric for passport-level interactions. One does not perform multiple requests for mortgages per second.

For a fair comparison, we only measure the creation/enrollment and verification of attributes/credentials of each solution. This highlights the performance difference, or lack thereof, between the often-discussed data disclosure implementations. For IPv8 this means the removal of the anonymization layer, discussed separately in Section 8.4.

We have benchmarked our Python implementation of IPv8. All experiments are performed on a virtual machine running Ubuntu 19.10, with 4 CPU cores fixed to 3.50 GHz and 16 384 MB of memory. All attribute enrollment and verification structures in IPv8 are measured as-is with default settings, no modifications have been made to the publicly available source code. We note that we measure IPv8’s compatibility layer for the IRMA protocol [6] (which in turn is an implementation of Idemix [14]) and should not be assumed to necessarily be equal to the performance statistics without our protocol integration. To IPv8’s disadvantage, we will assume that the blockchain solutions also reach instant finality as soon as a transaction for a block is created and that no attackers exist in the network (optimistically, blockchains can handle up to roughly 50% attackers [69]—though practically probably less [35]).

(a) Enrollment
(b) Verification
Figure 9: Network usage of credential creation and verification using different identity semantics and solutions.

8.1 Latency

Mobile devices and hardware tokens have been used for identification for decades, but have never seen wide adoption due to (among other factors) high latency [20]. Clearly, critically depending on a Proof-of-Work blockchain in an identity solution is unacceptable, as it pushes the latency of credential creation to an hour (to reach the commonly imposed 6-block rule for probabilistic finality [95]). This is too slow for most passport-grade interactions, e.g., electronic border control should be done in 30 seconds [58]. As a side note, using a permissioned blockchain to create identities with a lower latency creates a chicken-and-egg problem: you require a centrally known identity to create your identity (also having to answer to a central party before entering the system is naturally not Self-Sovereign). From a latency perspective, no blockchain is (at the time of writing) a good fit for Self-Sovereign Identities.

Eliminating blockchains from the equation, we end up with just the credential (creation and verification) middleware. With Hyperledger Indy, uPort and Jolocom all follow the W3C DID standard and allow for schemas and public keys to be customized. For all implementations we create a credential schema with a single attribute. IPv8 goes beyond this and also allows for different proving structures, which we measure and visualize separately. We measured IPv8’s interactive Zero-Knowledge Proofs for the -bit and -bit input spaces (we leave out the -bit proof). We measured IPv8’s Non-Interactive Zero-Knowledge Range Proof, which we refer to as the Peng-Bao proof (after its creators [75]). Lasty, we measured IPv8’s blinded signature scheme based on Idemix [14]: IRMA [6]. The boxplots of all of these credential implementations are given in Figure 7, for both enrollment and verification of credentials. The disclosure schemes implemented in IPv8 are presented to the left of the dotted line, those on the right side of the dotted line are the solutions we benchmark against.

From our latency comparison, we find no clear winner from all of the evaluated credential implementations. What is gained in enrollment latency is lost in verification latency and vice-versa, with Hyperledger Indy being the most consistent between these two categories (but also not the fastest). All of the evaluated solutions are well within the 30 second usability range. It would be dishonest to claim that the 1024 bit space Zero-Knowledge Proof of IPv8 is the best solution, as it can only handle up to 128 bytes of information securely (for reference: this can code most addresses in world) while the other credential solutions can handle arbitary-size inputs. What this does show is that choosing the correct credential disclosure protocol is important to satisfy the need for either low enrollment or low verification latencies. A freedom of choice only IPv8 offers.

8.2 Cpu

We have known for decades that (next to displays and disks) CPU processing induces a significant power drain on computing devices [98]. However, the actual power use of a device is hard to predict or generalize due to the heterogeneity of hardware, Operating Systems and their process scheduling algorithms. As we have run our experiments on a homogeneous virtualized setup, we provide a ballpark estimate for the “power rankings” of the different Self-Sovereign Identity solutions. As in the previous latency experiment, we measure each credential creation and verification implementation separately. The results are visualized in Figure 8. Only uPort offers a suprise, in that it has a much higher CPU usage for both enrollment and verification of credentials. From our experiments, we infer that CPU is not a significant distinguishing factor for current Self-Sovereign Identities.

8.3 Network Traffic

Next to processing power, the power drain due to wireless traffic is also a major factor in battery drain of mobile devices [31]. To this end, we also evaluate the network traffic as a result of the various credential implementations. We use the same setup as in the latency and CPU measurement sections. We further explicitly note that our reasoning for looking at the network traffic is based on the power consumption and not the latency (which we have already shown in a previous experiment). Since the deployment of 3G mobile communication networks, mobile phones are able to transfer megabytes per second [36]. We will momentarily show that the transfer rate of several megabytes is already overprovisioned for the needs of identity solutions.

We once again benchmark our credential structures against Hyperledger Indy, uPort and Jolocom and visualize the total network traffic in Figure 9. The most obvious result is that interactive Zero-Knowledge Proofs require much more traffic than Non-Interactive Zero-Knowledge Proofs and signature schemes to verify. The worst case, IPv8’s 4096 bit proof, requires up to 70 kilobytes of data to be transferred (though this is still completely acceptable for devices capable of communicating at several megabytes per second). The low traffic for Non-Interactive Zero-Knowledge Proofs is expected, as it is the design goal of such proofs [17]. Lastly, the signature scheme variants also show limited network use. However, as all of the solutions we have benchmarked IPv8 against communicate through (mostly) human-readable JSON, we see the network traffic greatly inflated. This seems to be a consequence of the modern software engineering practices of containerized microservices [41] and Javascript-based implementations [55]. The network traffic of these solutions could have been reduced by utilizing a binary format [78].

8.4 Anonymization

Thus far we have shown the feasibility of using different credential implementations with vastly different cryptographic primitives. We now discuss the performance implications of the anonymization middleware in IPv8. We measure the performance of our anonymization through real users of Tribler [79]. We give the creation time for circuits (covert channels) of the three lengths default to Tribler: 1 hop, 2 hops and 3 hops. This hop count corresponds to the amount of intermediaries that decrypt and forward data in a circuit. The more hops a circuit contains, the harder it will be for an adversary to decrypt or block any particular channel. By default, Tribler opens and maintains 4 through 8 of these circuits per resource session.

We have visualized the time it takes to create a circuit for differing hop counts in Figure 10. We show the parameterization of the anonymization middleware is very important for the latency of the overall identity solution. Using 1 hop anonymization, the anonymization latency is hardly significant in respect to the latency of the credential implementations (Figure 7). Using 2 hops of anonymization, the anonymization latency is comparable to the credential implementations. Finally, at 3 hops of anonymization, the anonymization latency is dominant in respect to the credential implementations. This brings us to the discussion of what hop count to use wich is, after 16 years of Tor deployment, still an open problem [12].

Figure 10: Circuit creation time in IPv8.

9 Related Work

A promising start has been made in the field to try and make sense of all the available information disclosure technology, its mapping to the W3C DID standard [83], and its interaction with blockchains [71, 54] and distributed storage like IPFS [37]. A critical view of the system components of Self-Sovereign Identity, however, is missing in academia and is only briefly discussed in industry whitepapers, the most notable analysis coming from SelfKey [39]. Many SSI solutions claim they are anonymous, but this is erroneous as they only achieve pseudonymity and do not address device fingerprinting [91]. We postulate that anonymity and identity disclosure protocols are orthogonal, but can be combined to achieve pseudonimity with selective disclosure of information.

Early work using central servers. Early work focuses on supplying users with the ability to tie their claims to a token-based identity, as examplified by Microsoft Passport [25], OAuth [27], FIDO [61] and OpenID [82]. At the time, the use-case of identification of users was to reidentify with the same central server—but these works did the ground work for cryptography, the terminology (e.g., “claims” and “relying parties”), and the principles of Self-Sovereign Identity.

Unlinkable signature-based disclosure schemes. Many of the mainstream Self-Sovereign Identity solutions are based on signature derivation (most notably Idemix’s CL signatures [24] and JSON Web Tokens [34]), possibly storing revocations on blockchains [2]. These signatures bind the key of the identity holder to the disclosed data and usually allow derivation of a new signature that is also valid for the same data (which is claimed to make this data unlinkable, though fingerprinting makes users completely linkable as we have previously discussed). Examples of these types of systems are IRMA [6], Jolocom and uPort [47], ClaimChain [56], and HyperLedger Indy and its flagship implementation of Sovrin [85].

ZKP-based identities. Identification through Zero-Knowledge protocols has been proposed decades ago [30] and is once again hailed as the primary driver for cryptographic Self-Sovereign Identities [8]. However, Zero-Knowledge Proofs over data remain scarcely documented and rarely implemented by academia [21], though this type of system is widely proposed by industry, with https://github.com/peacekeeper/blockchain-identity listing Self-Sovereign Identity solutions based on blockchain, mostly using smart contracts on the Ethereum blockchain.

10 Conclusion

Research on Self-Sovereign Identities is obsessed with cryptographic information disclosure protocols. However, our analysis shows that these protocols are not a differentiating factor between Self-Sovereign Identity solutions. Instead, the performance and security concerns appear at the—often undiscussed and perhaps ignored and neglected—edges of the system and its middleware layers. As a prominent example, device fingerprinting attacks allow for almost trivial deanonymization of even the most advanced cryptographic information disclosure schemes. We have shown the feasibility of a passport grade Self-Sovereign Identity through our design and implementation of IPv8. Though implementations of the information disclosure protocols of IPv8, HyperLedger Indy, uPort and Jolocom have equivalent latencies, the establishment of covert channels is shown to quickly become dominant for common security settings, leading to latencies in the order of several seconds. Our Self-Sovereign Identity solution of IPv8 cannot be fingerprinted, allows for passport-grade interactions, and has acceptable interaction latency.

Availability

All code of IPv8 is available on GitHub at https://github.com/Tribler/py-ipv8 and is provided under the GNU LGPL 3.0 license.

References

  • [1] K. Aberer, A. Datta, and M. Hauswirth (2005) A decentralized public key infrastructure for customer-to-customer e-commerce. International Journal of Business Process Integration and Management 1, pp. 26–33. Cited by: §4.1.
  • [2] A. Abraham, F. Hörandner, O. Omolola, and S. Ramacher (2019) Privacy-preserving eid derivation for self-sovereign identity systems. In International Conference on Information and Communications Security, pp. 307–323. Cited by: §9.
  • [3] R. Accorsi (2008) Automated privacy audits to complement the notion of control for identity management. In Policies and Research in Identity Management, pp. 39–48. Cited by: §7.
  • [4] C. Allen (2016) The path to self-sovereign identity. Life with Alacrity. Cited by: §1, §2, §2, §7.
  • [5] G. Alpár and B. Jacobs (2013) Credential design in attribute-based identity management. Cited by: §6.
  • [6] G. Alpár, F. van den Broek, B. Hampiholi, B. Jacobs, W. Lueks, and S. Ringers (2017) IRMA: practical, decentralized and privacy-friendly identity management using smartphones. HotPETs. Cited by: §2, §8.1, §8, §9.
  • [7] M. Andrychowicz, S. Dziembowski, D. Malinowski, and L. Mazurek (2014) Secure multiparty computations on bitcoin. In 2014 IEEE Symposium on Security and Privacy, pp. 443–458. Cited by: §7.
  • [8] D. Baars (2016) Towards self-sovereign identity using blockchain technology. Master’s Thesis, University of Twente. Cited by: §9.
  • [9] G. Banavar, T. Chandra, R. Strom, and D. Sturman (1999) A case for message oriented middleware. In International Symposium on Distributed Computing, pp. 1–17. Cited by: §4.1.
  • [10] E. Barker and Q. Dang (2015) NIST special publication 800-57: recommendation for key management, part 3: application-specific key management guidance, revision 1. External Links: Document Cited by: §4.1.
  • [11] P. C. Bartolomeu, E. Vieira, S. M. Hosseini, and J. Ferreira (2019) Self-sovereign identity: use-cases, technologies, and challenges for industrial iot. In 2019 24th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA), pp. 1173–1180. Cited by: §8.
  • [12] K. Bauer, J. Juen, N. Borisov, D. Grunwald, D. Sicker, and D. McCoy (2010) On the optimal path length for tor. In HotPets in conjunction with Tenth International Symposium on Privacy Enhancing Technologies (PETS 2010), Berlin, Germany, Cited by: §8.4.
  • [13] D. J. Bernstein (2006) Curve25519: new diffie-hellman speed records. In International Workshop on Public Key Cryptography, pp. 207–228. Cited by: §4.1.
  • [14] P. Bichsel, C. Binding, J. Camenisch, T. Groß, T. Heydt-Benjamin, D. Sommer, and G. Zaverucha (2009) Cryptographic protocols of the identity mixer library. In Technical Report, Vol. 99740, pp. 3730. Cited by: §7, §8.1, §8.
  • [15] A. Biryukov and I. Pustogarov (2015) Bitcoin over tor isn’t a good idea. In 2015 IEEE Symposium on Security and Privacy, pp. 122–134. Cited by: §4, §5.
  • [16] A. Biryukov and S. Tikhomirov (2019) Deanonymization and linkability of cryptocurrency transactions based on network analysis. In 2019 IEEE European Symposium on Security and Privacy (EuroS&P), pp. 172–184. Cited by: §1, §2, §5.
  • [17] M. Blum, P. Feldman, and S. Micali (1988) Non-interactive zero-knowledge and its applications. In

    Proceedings of the twentieth annual ACM symposium on Theory of computing

    ,
    pp. 103–112. Cited by: §8.3.
  • [18] D. Boneh, E. Goh, and K. Nissim (2005) Evaluating 2-dnf formulas on ciphertexts. In Theory of Cryptography Conference, pp. 325–341. Cited by: §6.
  • [19] D. Boneh, B. Lynn, and H. Shacham (2001) Short signatures from the weil pairing. In International Conference on the Theory and Application of Cryptology and Information Security, pp. 514–532. Cited by: §7.
  • [20] J. Bonneau, C. Herley, P. C. Van Oorschot, and F. Stajano (2012) The quest to replace passwords: a framework for comparative evaluation of web authentication schemes. In 2012 IEEE Symposium on Security and Privacy, pp. 553–567. Cited by: §8.1.
  • [21] Y. Borse, A. Chawathe, D. Patole, and P. Ahirao (2019) Anonymity: a secure identity management using smart contracts. Available at SSRN 3352370. Cited by: §9.
  • [22] E. Bortnikov, M. Gurevich, I. Keidar, G. Kliot, and A. Shraer (2009) Brahms: byzantine resilient random membership sampling. Computer Networks 53 (13), pp. 2340–2359. Cited by: §5.
  • [23] F. Boudot (2000) Efficient proofs that a committed number lies in an interval. In International Conference on the Theory and Applications of Cryptographic Techniques, pp. 431–444. Cited by: §7.
  • [24] J. Camenisch and A. Lysyanskaya (2002) A signature scheme with efficient protocols. In International Conference on Security in Communication Networks, pp. 268–289. Cited by: §5, §6, §7, §9.
  • [25] K. Cameron and M. B. Jones (2007) Design rationale behind the identity metasystem architecture. In ISSE/SECURE 2007 Securing Electronic Business Processes, pp. 117–129. Cited by: §1, §2, §9.
  • [26] D. L. Chaum (1981) Untraceable electronic mail, return addresses, and digital pseudonyms. Communications of the ACM 24 (2), pp. 84–90. Cited by: §5.
  • [27] E. Y. Chen, Y. Pei, S. Chen, Y. Tian, R. Kotcher, and P. Tague (2014) Oauth demystified for mobile application developers. In Proceedings of the 2014 ACM SIGSAC conference on computer and communications security, pp. 892–903. Cited by: §9.
  • [28] F. Dabek, R. Cox, F. Kaashoek, and R. Morris (2004) Vivaldi: a decentralized network coordinate system. In ACM SIGCOMM Computer Communication Review, Vol. 34, pp. 15–26. Cited by: §4.2.
  • [29] L. B. de France (2020)(Website) External Links: Link Cited by: §1.
  • [30] Y. Desmedt (1988) Abuses in cryptography and how to fight them. In Conference on the Theory and Application of Cryptography, pp. 375–389. Cited by: §9.
  • [31] N. Ding, D. Wagner, X. Chen, A. Pathak, Y. C. Hu, and A. Rice (2013) Characterizing and modeling the impact of wireless signal strength on smartphone battery drain. ACM SIGMETRICS Performance Evaluation Review 41 (1), pp. 29–40. Cited by: §8.3.
  • [32] R. Dingledine, N. Mathewson, and P. Syverson (2004) Tor: the second-generation onion router. Technical report Naval Research Lab Washington DC. Cited by: §5, §5.
  • [33] P. Erdős and A. Rényi (1960) On the evolution of random graphs. Publ. Math. Inst. Hung. Acad. Sci 5 (1), pp. 17–60. Cited by: §4.2.
  • [34] O. Ethelbert, F. F. Moghaddam, P. Wieder, and R. Yahyapour (2017) A json token-based authentication and access management schema for cloud saas applications. In 2017 IEEE 5th International Conference on Future Internet of Things and Cloud (FiCloud), pp. 47–53. Cited by: §9.
  • [35] I. Eyal and E. G. Sirer (2014) Majority is not enough: bitcoin mining is vulnerable. In International conference on financial cryptography and data security, pp. 436–454. Cited by: §8.
  • [36] E. Ezhilarasan and M. Dinakaran (2017) A review on mobile technologies: 3g, 4g and 5g. In 2017 second international conference on recent trends and challenges in computational models (ICRTCCM), pp. 369–373. Cited by: §8.3.
  • [37] J. G. Faísca and J. Q. Rogado (2016) Decentralized semantic identity. In Proceedings of the 12th International Conference on Semantic Systems, pp. 177–180. Cited by: §9.
  • [38] B. Ford, P. Srisuresh, and D. Kegel (2005) Peer-to-peer communication across network address translators.. In USENIX Annual Technical Conference, General Track, pp. 179–192. Cited by: §4.2.
  • [39] T. S. Foundation (2017-09)(Website) External Links: Link Cited by: §9.
  • [40] J. Galbally, S. Marcel, and J. Fierrez (2014) Biometric antispoofing methods: a survey in face recognition. IEEE Access 2, pp. 1530–1552. Cited by: §6.
  • [41] M. Garriga (2017) Towards a taxonomy of microservices architectures. In International Conference on Software Engineering and Formal Methods, pp. 203–218. Cited by: §8.3.
  • [42] O. Goldreich, S. Micali, and A. Wigderson (1991) Proofs that yield nothing but their validity or all languages in np have zero-knowledge proof systems. Journal of the ACM (JACM) 38 (3), pp. 690–728. Cited by: §1, §6.
  • [43] S. Goldwasser and D. Kharchenko (2005) Proof of plaintext knowledge for the ajtai-dwork cryptosystem. In Theory of Cryptography Conference, pp. 529–555. Cited by: §6.
  • [44] P. A. Grassi, M. E. Garcia, and J. L. Fenton (2017) NIST special publication 800-63-3: digital identity guidelines. External Links: Document Cited by: §3, §6.
  • [45] J. Grolin (1998) Corporate legitimacy in risk society: the case of brent spar. Business Strategy and the Environment 7 (4), pp. 213–222. Cited by: §7.
  • [46] T. H. W. P. W. Group (2018)(Website) External Links: Link Cited by: §2.
  • [47] A. Grüner, A. Mühle, and C. Meinel (2019) An integration architecture to enable service providers for self-sovereign identity. In 2019 IEEE 18th International Symposium on Network Computing and Applications (NCA), pp. 1–5. Cited by: §9.
  • [48] J. Hajny and L. Malina (2012) Unlinkable attribute-based credentials with practical revocation on smart-cards. In International Conference on Smart Card Research and Advanced Applications, pp. 62–76. Cited by: §7.
  • [49] G. Halkes and J. Pouwelse (2011) UDP nat and firewall puncturing in the wild. In International Conference on Research in Networking, pp. 1–12. Cited by: §4.2.
  • [50] E. Heilman, A. Kendler, A. Zohar, and S. Goldberg (2015) Eclipse attacks on bitcoin’s peer-to-peer network. In 24th USENIX Security Symposium (USENIX Security 15), pp. 129–144. Cited by: §4.
  • [51] V. C. Hu, D. Ferraiolo, R. Kuhn, A. Schnitzer, K. Sandlin, R. Miller, and K. Scarfone (2014) Guide to attribute based access control (abac) definition and considerations. External Links: Document Cited by: §6.
  • [52] T. A. Jacobs (2016) Secure token-based authentication with yubikey 4. Linux Journal 2016 (265), pp. 1. Cited by: §6.
  • [53] D. Khovratovich and J. Law (2017) Sovrin: digital identities in the blockchain era. Cited by: §7.
  • [54] G. Kondova and J. Erbguth (2020) Self-sovereign identity on public blockchains and the gdpr. In Proceedings of the 35th Annual ACM Symposium on Applied Computing, pp. 342–345. Cited by: §1, §9.
  • [55] E. K. Kristensen and A. Møller (2017) Type test scripts for typescript testing. Proceedings of the ACM on Programming Languages 1 (OOPSLA), pp. 1–25. Cited by: §8.3.
  • [56] B. Kulynych, W. Lueks, M. Isaakidis, G. Danezis, and C. Troncoso (2018) ClaimChain: improving the security and privacy of in-band key distribution for messaging. In Proceedings of the 2018 Workshop on Privacy in the Electronic Society, pp. 86–103. Cited by: §9.
  • [57] J. Kurmi and A. Sodhi (2015) A survey of zero-knowledge proof for authentication. International Journal of Advanced Research in Computer Science and Software Engineering 5 (1). Cited by: §6.
  • [58] R. D. Labati, A. Genovese, E. Muñoz, V. Piuri, F. Scotti, and G. Sforza (2016) Biometric recognition in automated border control: a survey. ACM Computing Surveys (CSUR) 49 (2), pp. 1–39. Cited by: §8.1.
  • [59] H. Leitold and B. Zwattendorfer (2011) STORK: architecture, implementation and pilots. In ISSE 2010 Securing Electronic Business Processes, pp. 131–142. Cited by: §1.
  • [60] J. Li, J. Stribling, R. Morris, M. F. Kaashoek, and T. M. Gil (2005) A performance vs. cost framework for evaluating dht design tradeoffs under churn. In Proceedings IEEE 24th Annual Joint Conference of the IEEE Computer and Communications Societies., Vol. 1, pp. 225–236. Cited by: §4.2.
  • [61] R. Lindemann (2013) The evolution of authentication. In ISSE 2013 Securing Electronic Business Processes, pp. 11–19. Cited by: §9.
  • [62] G. Linklater, C. Smith, A. Herbert, and B. Irwin (2018) Toward distributed key management for offline authentication. In Proceedings of the Annual Conference of the South African Institute of Computer Scientists and Information Technologists, pp. 10–19. Cited by: §6.
  • [63] G. Loukas and G. Öke (2010) Protection against denial of service attacks: a survey. The Computer Journal 53 (7), pp. 1020–1037. Cited by: §3.1, §4.1.
  • [64] W. Lueks, G. Alpár, J. Hoepman, and P. Vullers (2017) Fast revocation of attribute-based credentials for both users and verifiers. Computers & Security 67, pp. 308–323. Cited by: §7.
  • [65] C. Lundkvist, R. Heck, J. Torstensson, Z. Mitton, and M. Sena (2017)(Website) External Links: Link Cited by: §2.
  • [66] A. Makrushin and A. Wolf (2018) An overview of recent advances in assessing and mitigating the face morphing attack. In 2018 26th European Signal Processing Conference (EUSIPCO), pp. 1017–1021. Cited by: §6.
  • [67] J. Martin, T. Mayberry, C. Donahue, L. Foppe, L. Brown, C. Riggins, E. C. Rye, and D. Brown (2017) A study of mac address randomization in mobile devices and when it fails. Proceedings on Privacy Enhancing Technologies 2017 (4), pp. 365–383. Cited by: §5.
  • [68] R. McKenzie, M. Crompton, and C. Wallis (2008) Use cases for identity management in e-government. IEEE Security & Privacy 6 (2), pp. 51–57. Cited by: §1.
  • [69] D. Mingxiao, M. Xiaofeng, Z. Zhe, W. Xiangwei, and C. Qijun (2017) A review on consensus algorithm of blockchain. In 2017 IEEE International Conference on Systems, Man, and Cybernetics (SMC), pp. 2567–2572. Cited by: §8.
  • [70] G. Mühl, L. Fiege, and P. Pietzuch (2006) Distributed event-based systems. Springer Science & Business Media. Cited by: §4.2.
  • [71] A. Mühle, A. Grüner, T. Gayvoronskaya, and C. Meinel (2018) A survey on essential components of a self-sovereign identity. Computer Science Review 30, pp. 80–86. Cited by: §9.
  • [72] T. Neudecker and H. Hartenstein (2018) Network layer aspects of permissionless blockchains. IEEE Communications Surveys & Tutorials 21 (1), pp. 838–857. Cited by: §4.
  • [73] L. Øverlier and P. Syverson (2007) Improving efficiency and simplicity of tor circuit establishment and hidden services. In International Workshop on Privacy Enhancing Technologies, pp. 134–152. Cited by: §5, §5.
  • [74] T. P. Pedersen (1991) Non-interactive and information-theoretic secure verifiable secret sharing. In Annual international cryptology conference, pp. 129–140. Cited by: §7.
  • [75] K. Peng and F. Bao (2010) An efficient range proof scheme. In 2010 IEEE Second International Conference on Social Computing, pp. 826–833. Cited by: §6, §8.1.
  • [76] L. Peyton, C. Doshi, and P. Seguin (2007) An audit trail service to enhance privacy compliance in federated identity management. In Proceedings of the 2007 conference of the center for advanced studies on Collaborative research, pp. 175–187. Cited by: §7.
  • [77] G. Pieters and S. Vivanco (2017) Financial regulations and price inconsistencies across bitcoin markets. Information Economics and Policy 39, pp. 1–14. Cited by: §7.
  • [78] S. Popić, D. Pezer, B. Mrazovac, and N. Teslić (2016) Performance evaluation of using protocol buffers in the internet of things communication. In 2016 International Conference on Smart Systems and Technologies (SST), pp. 261–265. Cited by: §4.1, §8.3.
  • [79] J. A. Pouwelse, P. Garbacki, J. Wang, A. Bakker, J. Yang, A. Iosup, D. H. Epema, M. Reinders, M. R. Van Steen, and H. J. Sips (2008) TRIBLER: a social-based peer-to-peer system. Concurrency and computation: Practice and experience 20 (2), pp. 127–138. Cited by: §8.4.
  • [80] B. Pretre (2005) Attacks on peer-to-peer networks. Dept. of Computer Science Swiss Federal Institute of Technology (ETH) Zurich Autumn. Cited by: §5.
  • [81] Y. Qiao and F. E. Bustamante (2006) Structured and unstructured overlays under the microscope. Cited by: §3.2.
  • [82] D. Recordon and D. Reed (2006) OpenID 2.0: a platform for user-centric identity management. In Proceedings of the second ACM workshop on Digital identity management, pp. 11–16. Cited by: §1, §2, §9.
  • [83] D. Reed, M. Sporny, D. Longley, C. Allen, R. Grant, and M. Sabadello (2020-04)(Website) W3C. Note: Working Draft External Links: Link Cited by: §2, §9.
  • [84] C. Roberts (2007) Biometric attack vectors and defences. Computers & Security 26 (1), pp. 14–25. Cited by: §6.
  • [85] C. Saraf and S. Sabadra (2018) Blockchain platforms: a compendium. In 2018 IEEE International Conference on Innovative Research and Development (ICIRD), pp. 1–6. Cited by: §9.
  • [86] A. Setyawan Sajim (2018) Open-source software-based sram-puf for secure data and key storage using off-the-shelf sram. Master’s Thesis, Delft University of Technology. Cited by: §6.
  • [87] M. Shapiro, N. Preguiça, C. Baquero, and M. Zawirski (2011) Conflict-free replicated data types. In Symposium on Self-Stabilizing Systems, pp. 386–400. Cited by: §7.
  • [88] M. Srivatsa and M. Hicks (2012) Deanonymizing mobility traces: using social network as a side-channel. In Proceedings of the 2012 ACM conference on Computer and communications security, pp. 628–637. Cited by: §6.
  • [89] Q. Stokkink and J. Pouwelse (2018) Deployment of a blockchain-based self-sovereign identity. In 2018 IEEE International Conference on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData), Vol. , pp. 1336–1342. Cited by: §7.
  • [90] Q. Stokkink, C. U. Ileri, J. Pouwelse, and J. S. Rellermeyer (2020) Latency-aware sybil-resistant neighborhood formation. Cited by: §5, §5.
  • [91] M. Stopar, M. Bizjak, J. Modic, J. Hartman, A. Žitnik, and T. Marc (2019) Emmy–trust-enhancing authentication library. In IFIP International Conference on Trust Management, pp. 133–146. Cited by: §1, §4, §5, §9.
  • [92] G. Urdaneta, G. Pierre, and M. V. Steen (2011) A survey of dht security techniques. ACM Computing Surveys (CSUR) 43 (2), pp. 1–49. Cited by: §4.2, §5.
  • [93] N. Van der Meulen (2006) The challenge of countering identity theft: recent developments in the united states, the united kingdom, and the european union. National Infrastructure Cyber Crime program (NICC). Cited by: §7.
  • [94] M. Vanhoef, C. Matte, M. Cunche, L. S. Cardoso, and F. Piessens (2016) Why mac address randomization is not enough: an analysis of wi-fi network discovery mechanisms. In Proceedings of the 11th ACM on Asia Conference on Computer and Communications Security, pp. 413–424. Cited by: §5.
  • [95] M. Vukolić (2015) The quest for scalable blockchain fabric: proof-of-work vs. bft replication. In International workshop on open problems in network security, pp. 112–125. Cited by: §8.1.
  • [96] F. Wang and P. De Filippi (2020) Self-sovereign identity in a globalized world: credentials-based identity systems as a driver for economic inclusion. Frontiers in Blockchain 2, pp. 28. Cited by: §1, §6.
  • [97] H. Wang, Y. Zhu, and Y. Hu (2005) An efficient and secure peer-to-peer overlay network. In The IEEE Conference on Local Computer Networks 30th Anniversary (LCN’05) l, pp. 8–pp. Cited by: §4.2, §5.
  • [98] M. Weiser, B. Welch, A. Demers, and S. Shenker (1994) Scheduling for reduced cpu energy. In Mobile Computing, pp. 449–471. Cited by: §8.2.
  • [99] Q. Xu, R. Zheng, W. Saad, and Z. Han (2015) Device fingerprinting in wireless networks: challenges and opportunities. IEEE Communications Surveys & Tutorials 18 (1), pp. 94–104. Cited by: §1, §5.
  • [100] P. R. Zimmermann (1995) The official pgp user’s guide. Vol. 5, MIT press Cambridge. Cited by: §6.