Digital Identity, Trust and Privacy on the open Internet

Archive for the ‘Blockchain Technology’ Category

Public keys on blockchains: confusing existence with trust

without comments

Today Identity and Access Management (IAM) represents a core component of the Internet infrastructure,  without which users would not be able to obtain online services in a timely and scalable manner. Enterprise IAM infrastructures are well integrated into other enterprise infrastructure services — such as directory services — which provide control over employees and assets. In the case of Consumer IAM most end-users are oblivious to the underlying identity federation infrastructures that allow them to perform Web Single Sign-On (SSO) to various online services and which enables them to grant their mobile apps access to various personal resources (e.g. contacts list, calendar, etc).

The recent emergence of the Bitcoin system has created various discourses of the role of “blockchain identity”. Here the three notable fundamental features of Bitcoin are its combined use of:

  • peer-to-peer network of physically distributed mining nodes,
  • consensus-based transaction status agreement algorithm and
  • restrictive scripting language (opcodes) for transaction expression.

These three aspects of the Bitcoin system provide mining nodes with true independence in processing transactions, subject only to the 51\% majority requirement of the consensus scheme. It is precisely this node-independence that translates to “user independence” in the sense of the user not being beholden to any one mining node (or a small minority of nodes) in the Bitcoin system.

However, it is this “user independence” (in the context of Bitcoin) that have led many to incorrectly extrapolate (speculate) that the same degree user independence can be achieved in all DLTs (distributed ledger technology) in general — something that is not necessarily true in DLTs generically speaking. The Bitcoin system is an instance of a DLT, but not all proposed DLTs possess the three fundamental features of Bitcoin.

Furthermore, many commentators have equated “user independence” (in Bitcoin) to “individual empowerment” in DLTs in general, a jump in speculation that is too far and which have led to confusion among the non-technical audience.

This misunderstanding regarding individual empowerment is exacerbated when the use of self-issued public-key pairs (in the Bitcoin system) is extrapolated to mean that these self-issued keys can be used as a “digital identity” for individuals in general. More specifically, the use of self-issued public-key pairs have led many to deduce (incorrectly) that a public-key used in the Bitcoin system can be “trusted” as a “digital identity” simply because it has been recorded on a transaction-block which has been replicated by all nodes on the peer-to-peer network.

That is, the existence of a key in transaction block is being confused with trust in the provenance and ownership of that key.

Some have even coined the term “trustless” when referring to the peer-to-peer network of mining nodes, forgetting that high-value transaction networks are built on both technical-trust and legal-trust — both leading to business and social trust.

It is worth recalling that this problem of digital identity versus public keys emerged first in the mid-1990s in the context of self-signed X509 certificates,  Simple PKI (RFC2693) and in the Pretty Good Privacy (PGP) system (RFC1991). Although an implementation of the PGP system may provide technical-trust, the PGP proposal was never broadly adopted by industry due to a lack of a corresponding model for business and legal trust.

Written by thomas

April 21st, 2017 at 7:56 pm

Blockchains: Evidence of Mediated Computation

without comments

In writing of the report of the Kantara BSC group (Blockchain and Smart Contracts) – a group that has been meeting bi-weekly for the past 7 months – we have come across numerous use-cases proposed by members who are looking closely at blockchain technology (or more generally from distributed ledger technology).

To enable classification of these use-cases,  some criteria were agree upon that  would highlight the features of blockchain systems. Since the attraction of blockchain technology (and more generally of distributed ledgers) lies in its empowering parties to transact without the need for a single (or few) intermediary, the following criteria has helped the team classify the received use-cases:

  • Individuals controlling their own data: Does the use-case seek to empower individuals to begin with, and does blockchain technology help to achieve that goal.
  • Individuals rising to the level of a “peer” in transactions with others: Does the use-case require individuals to function at a peer-level (or can the same outcome be achieved using other paradigms), and does blockchain technology help to achieve that goal.
  • Evidence of mediated computation: Does the use-case require immutable evidence that a neutral third party (e.g. some computer, somewhere) mediated the transaction, without which the transaction outcome would be worthless to the transacting parties.

The last criterion points to a feature of blockchain technology that is often overlooked. In many discourses regarding applications of blockchain technology, authors assume (forget) that the blockchain system consists of a network of peer-to-peer nodes which perform some computation (e.g. proof or work mining) towards the completion of a transaction. As such, one or more of these nodes are in fact performing mediated computation (to some degree) and at the same time provide evidence of this mediated act.

If evidence of mediated computation is crucial to the acceptance of a transaction, it implies that stronger forms of technical-trust must be produced by the entity (i.e. node; server; device) that is performing the computation. New forms of remote attestation may need to be devised, something along the lines of the SGX architecture that provide evidence that a given computation was performed within a secure enclave.

This raises another prospect: different nodes on a blockchain system may offer different levels of trustworthy computation, each with an associated cost (i.e. tiers of trusted computation services on the P2P network).




Written by thomas

April 2nd, 2017 at 2:56 pm

Query Smart Contracts: Bringing the Algorithm to the Data

without comments

One paradigm shift being championed by the MIT OPAL/Enigma community is that of using (sharing) algorithms that have been analyzed by experts and have been vetted to be “safe” from the perspective of privacy-preservation. The term “Open Algorithm” (OPAL) here implies that the vetted queries (“algorithms”) are made open by publishing them, allowing other experts to review them and allowing other researchers to make use of them in their own context of study.

One possible realization of the Open Algorithms paradigm is the use of smart contracts to capture these safe algorithms in the form of executable queries residing in a legally binding digital contract.

What I’m proposing is the following: instead of a centralized data processing architecture, the P2P nodes (e.g. in a blockchain) offers the opportunity for data (user data and organizational data) to be stored by these nodes and be processed in a privacy-preserving manner, accessible via well-known APIs and authorization tokens and the use of smart contracts to let the “query meet the data”.

In this new paradigm of privacy-preserving data sharing, we “move the algorithm to the data” where queries and subqueries are computed by the data repositories (nodes on the P2P network). This means that repositories never release raw data and that they perform the algorithm/query computation locally which produce aggregate answers only. This approach of moving the algorithm to the data provides data-owners and other joint rights-holders the opportunity to exercise control over data release, and thus offers a way forward to provide the highest degree of privacy-preservation while allowing data to still be effectively shared.

This paradigm requires that queries be decomposed into one or more subqueries, where each subquery is sent to the appropriate data repository (nodes on the P2P network) and be executed at that repository. This allows each data repository to evaluate received subqueries in terms of “safety” from a privacy and data leakage perspective.

Furthermore, safe queries and subqueries can be expressed in the form of a Query Smart Contract  (QSC) that legally bind the querier (person or organization), the data repository and other related entities.

A query smart contract that has been vetted to be safe can be stored on nodes of the P2P network (e.g. blockchain). This allows Queriers to not only search for useful data (as advertised by the metadata in the repositories) but also search for prefabricated safe QSCs that are available throughout the P2P network that match the intended application. Such a query smart contract will require that identities and authorizations requirements be encoded within the contract.

A node on the P2P network may act as a Delegate Node in the completion of a subquery smart contract.  A delegate node works on a subquery by locating the relevant data repositories, sending the appropriate subquery to each data repository, and receiving individual answers and collating the results received from these data repositories for reporting to the (paying) Querier.

A Delegate Node that seeks to fulfill a query smart contract should only do so when all the conditions of the contract has been fulfilled (e.g. QSC has valid signature; identity of Querier is established; authorization to access APIs at data repositories has been obtained; payment terms has been agreed, etc.). A hierarchy of delegate nodes may be involved in the completion of a given query originating from the Querier entity. The remuneration scheme for all Delegate Nodes and the data repositories involved in a query is outside the scope of the current use-case.

Written by thomas

August 6th, 2016 at 1:21 pm