Blockchain Security for Digital Identity

NOTE: This is an unedited copy of a report written for DHS S&T in September 2016. A full, updated paper which will expand on this work, including discussion of privacy concerns, is forthcoming and tentatively scheduled for release in January 2018.

Introduction

There are numerous public blockchains created for different purposes. They can vary in block size, mining algorithm and other factors which can affect the security of the blockchain network, however, in any blockchain what matters most of all for Confidentiality, Integrity and Availability (C-I-A), is the amount of participation in the network. The “51% attack” which will be discussed, is an excellent example of what can happen when participation in the network is not sufficiently robust. That and the fact that the Bitcoin blockchain has by far the most active participation, led our team to focus on it.

Assumptions and boundaries

The operational security of miners including their ability to protect mining computers and networks is discussed in general and the use of current cybersecurity best practices is assumed. Likewise, offline storage is assumed to be used for most of the data (see below) and that storage.

Assessment of wallet security focuses on the cryptographic key management aspect. As such, the need to protect keys and the risks associated with losing possession and control of them will be discussed in that frame of reference.

Finally, the proofing process undertaken by the registrar during enrollment (see below) is assumed to be appropriate and sufficient with respect to privacy and security for the registrar to accept the claim(s) asserted by the user as valid.

Methodology and scope

Blockchain Graveyard summarizes and references documentation about over forty successful attacks on institutions in the Bitcoin network that were severe enough to cause existential harm. The root causes include server breach (the majority) and application vulnerabilities, but also protocol flaws. These attacks are all very different but in all cases, theft of wallets and/or Bitcoins was the presumed intention. The site is regarded as comprehensive and is actively maintained.

That being the case, our team decided to focus the assessment to blockchain-based identity solution and to accomplish that, a set of identity centric use cases and key aspects of blockchain-based identity solutions are defined, and the assessment is centered around them.

The intent is to make the assessment more substantive and worthwhile by minimizing generalized, non-contextualized discussion of threats and vulnerabilities, which is available in abundance on the Internet, to instead focus on the threats as they affect blockchain-based identity solutions.

Blockchain-based Digital Identity

Benefits of blockchain technology like immutability which can help to establish provenance as well as effective distribution of public keys on a network, are useful in digital identity as enablers for trust and user-centricity. However, other aspects like high transaction confirmation latency are seen as problematic in the same context.

In any case, upon surveying the existing blockchain-based identity landscape, our team gathered a list of key aspects of blockchain-based identity solutions that we believe will most substantially affect the security of any potential solution.

Key Aspects of Blockchain Technology for Identity

Blockchain Selection

Which blockchain to use for a blockchain-based identity solution will have a significant impact on all of C-I-A and ultimately viability of the solution. Higher transaction volume makes surveillance more difficult, the more miners on a network, the more difficult it is to execute the 51% attack and the number of miners obviously affects the network’s availability and performance. With this reality in mind, our team chose to focus on the Bitcoin blockchain.

Level of Assurance (LOA)

Blockchain solutions rely on authentication and identity-proofing (or lack of it) in much the same way as existing technology does; the higher the value of the transaction, the higher the LOA required to perform it. That being the case, the best practice of selecting LOA based on the risk posed by the transaction is assumed i.e. higher LOA is required when the transaction involves more sensitive (valuable) claims.

On-chain or Off-chain Storage

The Bitcoin blockchain can be used to store data. In Bitcoin the contents of the transaction (the payload) consists of the sender, the receiver, the amount of ‘coins’ being transferred and some transactional meta-data.

Thus, for blockchain-based identity solutions, the starting point is to consider what, whether and how digital identity data should be stored on the blockchain. The current one-megabyte block size-limit imposed by the Bitcoin network is thus a key data point from the start. Moreover, storing the data on-chain limits the security controls that can be employed to protect it, while exposing it to the entire network. As a result, existing blockchain-based identity solutions and the experts who design them tend to favor storing only unique identifiers, hashes or “fingerprints” of public key(s) on-chain while using that identifier to point to off-chain storage.

Our team has chosen to follow this prevailing approach by assuming that all data except for a globally unique identifier and a hash of the public key, are stored off-chain.

Use cases

The use cases are defined within the context of a two part scenario:

1) Enrollment or establishment of the participant’s identity and later,

2) Attestation of claims (with consent) for the purpose of authorizing an access

The parties involved are:

1) A participant or user who establishes an identity for the purpose of making some claim(s) that will entitle them to access a resource managed by,

2) A registrar identified by an existing identifier and public key who attests to the claims by signing them and later uses them to manage access-control

Enroll

1) The user establishes an identity by registering a globally unique identifier on the blockchain and storing the private key in their wallet

2) The user signs a set of claims and submits them to the registrar; in effect self-asserting those claims to the registrar

3) The registrar performs their existing proofing process to validate the claim and then signs the claims and stores them in off-chain storage using the globally unique identifier as a lookup pointer

Attestation

1) The user requests access to a resource that is controlled by the registrar and is authenticated using the public key corresponding to the private key that was created by the user during enrollment

2) The registrar validates the request, generates a request for the claims that they require in order to render an access-control decision which is signed by the registrar and presented to the user

3) The user authorizes the registrar to lookup the desired claims by signing the claim lookup request

4) The registrar sends the request for claims, signed by both the user (subject) and the registrar, the attribute store validates both signatures and returns the requested claims

5) The registrar examines the claims and renders access by providing a token to the user who uses it to access the registrar controlled resource

Update

1) Repeat 2) and 3) from Enroll and utilize the existing identifier established in 1)

Removal

1) Repeat 1) through 4) from Attestation except that the request is to remove the claim(s) which are deleted by the attribute store and nothing is returned

Assessment

In applying our assessment methodology to the Bitcoin public blockchain we examine five threats:

1) Loss or theft of a wallet which results in loss of possession and control of the private key that corresponds to the public key used in the enrollment process,

2) The 51% attack which is when 51% of the overall mining capability of the network is controlled by a single party,

3) Network deterioration as a result of a “race to the bottom” with respect to mining profitability,

4) Transaction malleability attacks where malicious actors send transactions that exploit flaws in the validation logic of Bitcoin blockchain network miners and even in absence of such flaws, create disputable results and,

5) Block size which dictates the maximum rate that the network can process transactions.

The sections below contain an explanation of these threats as they pertain to blockchain-based identity solutions and some supposed mitigations which our team will attempt to validate during the course of our development work.

Loss or theft of wallet

The loss or theft of a wallet constitutes the loss of possession and control of the private key corresponding to the public key associated with the globally unique identifier enrolled by the user. Wallet theft through breach of the computer system storing it is prevalent. Malicious wallet software is also an emerging threat. In the case of cloud based wallets, private keys are stored centrally, often encrypted with the account holder’s password rendering them susceptible to the same attacks as passwords, like phishing and data breach.

Impact

1) In the case of a lost wallet, the result is DoS due to loss of access to resources under the control of the digital identity that can no longer be asserted due to loss of the private key that corresponds to it or,

2) In the case of wallet theft, the result is that the attacker can impersonate the user because the private key in the wallet is now under the attacker’s control.

Mitigation

Wallet loss or theft is arguably the Achilles heel of blockchain solutions in general, however, in the context of digital identity it essentially equates to either denial of service or impersonation of the user through destruction or theft and use of credentials respectively. The mitigation therefore is to (at a minimum) protect the wallet from unauthorized access presumably through encryption and back up to separate secure media. Cloud wallet services are more rewarding targets than personal wallets due to the scale of attack thus a local wallet may be more secure but only insomuch as the value of the private keys don’t incent targeted attacks of the same or greater scale. Cloud wallet services should allow the user to increase the level of authentication protecting their account.

The 51% attack

The 51% attack also known as the “Sybil attack” in the context of blockchain that occurs when more than half of the total mining capacity of the network is controlled by a single party. The attack allows the party controlling the majority of mining capacity to manipulate the blockchain. For example, a party controlling more than half of the mining capacity can make it difficult for the particular users to transact by delaying or refusing their transactions.

In the context of our assessment methodology this enables two potential adverse outcomes:

Registering the digital identifier that a user intends to register then,

1) Allows their registration to fail for trying to register the (now existing) identifier or,

2) Creates a separate chain where the original registration succeeds so that the user falsely believes that they have control of the digital identifier.

Impact

1) The user is either unable to enroll which constitutes a denial of service (DoS) or,

2) The user believes that they are enrolled with a particular digital identifier when that identifier is actually associated with a key pair that under an attacker’s control resulting in the attacker being able to impersonate the user.

Mitigation

The 51% attack is a governance problem for the Bitcoin blockchain community and therefore cannot be completely mitigated by any given blockchain-based identity solution provider, however, a solution provider can and should work with the blockchain community to ensure that effective governance prevents the attack from occurring. The other method of mitigation would be to ensure that the design of any system of the blockchain could be readily transferred to or mirrored on another blockchain offering similar or greater stability.

Network Deterioration

Miners are engaged in a “race to the bottom” as the mining reward is halved over time and transaction costs are not assured or even expected to make up for the loss. Thus more and more miners drop out each time the reward is halved which leads to miner homogeneity over time. From a security perspective homogeneity means less demand for mining hardware and software systems leading to fewer of them.

Impact

Less variation in hardware and software across the network increases the impact of any given hardware- or software-based attack by allowing the attacker to target more users with the same attack. In the context of our assessment such attacks would aim to obtain and use the private keys resulting in user impersonation or destroy the keys resulting in DoS for the user. Further, the likelihood of a 51% attack increases as miner homogeneity does.

Mitigation

The rate of discovery and closure of hardware and software security vulnerabilities is commonly referred to as “vulnerability management” in current cybersecurity best practice. Thus, mitigation amounts to improving vulnerability management.

Transaction malleability

Transaction malleability attacks are different from the previously stated attacks in that they target the protocol and software implementations in combination with the processes that solution providers create as part of their solutions. The attacks exploit argued flaws in the transaction validation logic specifically signature validation of mining software. Even in the absence of such flaws, these attacks create the potential for DoS as well as transaction disputes.

Impact

In our assessment context, these flaws constitute the threat of DoS in that a successful attack can prevent the enrollment process from being completed successfully and while they only allow for impersonation in cases where the software implementation contains flaws, they at least introduce issues with respect to non-repudiation of transactions.

Mitigation

Like the 51% attack, these attacks are beyond the ability of any given solution provider to mitigate independently — they require protocol and blockchain network implementation fixes to mitigate — they can be minimized, however, by ensuring that the solution provider takes transaction malleability into account particularly when implementing signature validation.

Block size

The current implementation of the Bitcoin blockchain allows for 1 megabyte of transaction data to be stored in a single block and a new block is generated every 7 to 8 minutes thus the network is limited to about 7 transactions per second. When transaction flow exceeds this rate , some transactions may be delayed or even dropped.

Impact

In our assessment context, exceeding the maximum transaction rate will result in DoS for the user during any process that involves blockchain transactions.

Mitigation

“Side chain” technology which evolved from blockchain and involves creating a hash of a larger bundle of transactions and putting that hash on the main blockchain in order to work around the size limitation, has gained traction as principle mitigation. Migration to another blockchain with more acceptable transaction rate limit, is also an option provided that the solution is sufficiently portable.

Summary

The assessment identifies denial-of-service (DoS) and impersonation as the predominant threats posed to blockchain-based identity solutions. As such, mitigations are increased and improved cybersecurity coupled with better governance of the network. While both of mitigations become more difficult to implement as network participation increases, the broad recognition of the need for these mitigations coupled with the presumed common interest in implementing them does bode well.

Assuming steady improvement in cybersecurity practices among blockchain network participants and the establishment of good governance policies and structures for the blockchain network with respect to security in the short and long term, it presents a valid candidate architecture for digital identity solutions which can stand to benefit from it.

This document, a part of the “Security and Privacy for a Blockchain Based Trust Elevation Chain” project, has been funded in part by the United States Department of Homeland Security’s Science and Technology Directorate under contract HSHQDC-16-C-0059. The content of this document does not necessarily reflect the position or the policy of the U.S. Government and no official endorsement should be inferred.