Someone might ask the question, what if a risk manager or auditor performed a risk assessment of the Bitcoin protocol?

I decided to give it shot, noting please that this is not intended to be a detailed technical exercise. It is aimed at highlighting the controls embedded in the protocol for managing traditional systems risks.

Overview of the protocol

To start with, what is the Bitcoin protocol?

  • Basically, it is a simple electronic ledger system.
  • The ledger is stored in a completely decentralised way, anyone can host a copy.
  • All Bitcoins are created as rewards from mining. Mining is the process performed by network users to cryptographically verify and record transactions.
  • The main transaction performed on the Bitcoin network is where a user sends Bitcoin to another user. There is a small fee linked to transactions paid to the miners who verify and record the transaction.
  • So, a user’s Bitcoin ledger balance is the sum of all Bitcoins received from other users, less any Bitcoin sent. Added to this is any Bitcoin received as rewards from mining or received as fees.

Assessment approach

Let us challenge the Bitcoin protocol as an auditor would. When assessing any system, auditors usually try and assess the risks relating to completeness, accuracy, and validity of transactions.

Where assessing completeness requires that controls be implemented to ensure that transactions cannot be:

  • Omitted from being recorded.
  • Reversed or deleted.
  • Duplicated.
  • Be incomplete in terms of data included in the transaction record.

Where assessing accuracy requires that controls be implemented to ensure that transactions cannot be:

  • Recorded inaccurately.
  • Calculated inaccurately.

Where assessing validity means that only authorised users can process the transactions. So that transactions cannot be:

  • Processed by an unauthorised user.

Bitcoin Assessment

Using the above approach, let us have a look at each of these in turn, using the table below:

RISKCONTROL
Transactions are omitted:

Can a transaction be created but not recorded on the network?
Transactions can only be created once they submitted to the network and mined.

When a transaction is mined a cryptographic hash is created from the detail of that transaction together with all the transactions included in its transaction block, and a hash of all other transactions ever processed on the Bitcoin network.

Once that hash is mined the transaction will be posted and recorded forever.
Deleted or reversed:

Can an existing transaction somehow be deleted or reversed, thus altering balances?
If a user of the network attempted to delete a transaction, the cryptographic hash of the block where the transaction is recorded will fail the hash check and the deletion will be rejected by the network.
Duplication or unauthorised insertion:

Can a transaction be duplicated or inserted in the blockchain to influence balances?
In much the same way as a transaction being deleted, if someone tried to insert or duplicate a transaction. The hash check will again fail, and the change rejected by the network.
Incomplete data:

Can required data is left out when creating a transaction?
The Bitcoin protocol is created with strict data validations in place so that no record can be created without the precise required fields and formats.
Recorded inaccurately:

Can payment transactions be recorded inaccurately?
Again, strong validations are in place around the recording transactions to the blockchain. The requirements for balance checking, formatting numbers and other fields are stringently applied.
Inaccurate calculations:

Is it possible for calculations are inaccurate?
Outside of cryptography, calculations in the Bitcoin protocol are relatively simple and include calculations of miner fees, balances etc. These calculations are all pre-programmed in the source code.
Source code:

Why can’t anyone just change the Bitcoin source code, so the protocol operates differently or sends new coins to someone?
Changes to the source code are governed by a strict requirement that only allows changes if 95% of miners agree to the change. This is embedded in the protocol. It is virtually impossible to accept a fraudulent source code as it would require an unrealistic collaboration of thousands of parties to occur.
Unauthorised transactions:

Can someone transact on behalf of someone else?
To transact on the Bitcoin network each user must have a Bitcoin wallet. Wallets contain a key pair using the SHA-2 algorithm, the public key is freely available, and the private key is kept secret and only resides offline in the wallet. A user can only transact on the network when in possession of the private key.

In this way if appropriate security is retained over the private keys by using a secure wallet, unauthorised transactions cannot be processed on the user’s account.

Synopsis and areas for testing

So, there you have it, we have performed a very simple risk assessment of the Bitcoin protocol like an auditor would.

The integrity of the protocol and management of key risks is maintained by the cryptography and a very strongly coded protocol.

As we have mentioned in our prior blog post the one area within the Bitcoin protocol that is “hackable” is the access to the private keys in people’s wallets, as this is the access point for allowing transactions to be submitted. The rest of the controls within the Bitcoin protocol are “hard coded” into a very strong code base, which is very difficult to change.

Future articles will cover the controls and assurance around Bitcoin wallets. We also intend to look at code base reviews with a focus on smart contracts.

References: http://Bitcoin.org

Acusyne Consulting is a team of audit, risk, governance, and technical security consultants. We constantly seek better ways of doing our work, using research, industry best practice, and automation. Specialties include:

  • Information technology risk management
  • Information technology governance
  • Information technology general controls audits
  • Technical security audits (including cyber)
  • Application controls audits
  • Penetration testing