Loader-mobile

Loading...

DREAM Bitcoin Escrow Payment System Architecture

Published on March 02, 2017 05:02 PM
Slide40

1.0 Introduction

1.1 Design Goals

We have designed the payment system to be:

  • Simple – Easy for customers who don’t know (or need to know) what Bitcoin keys are
  • Secure – Protect customer Bitcoin's if an attacker gains root access to all our web facing servers
  • Scalable – Process thousands of transactions per day, with minimal intervention from DREAM staff

1.2 What We've Built

Our solution is broken into two components; the DREAM marketplace and the Escoin Bitcoin escrow payment system. Similar to the eBay marketplace, and PayPal payment provider relationship.


1.3 Design Summary

The design separates the DREAM application and Escoin payment system through a clean and simple API.

  • Transaction Firewall – In the event that something suspicious or malicious is detected by the Transaction Firewall on the Escoin server or Vault servers at an API or OS level; the admin is notified and outgoing payments are stopped
  • Key Storage – Escoin encrypts the three Bitcoin private keys across three remote key Vaults on separate servers (self-hosted instances of VaultProject). The DREAM application manages payment actions, but never sees or stores the Bitcoin private keys
  • Recovery – Recovery of the Vault requires three different people (located inside and outside the business)

2.0 Payment System

2.1 Introduction

To support escrow with multisig, we considered sending one private Bitcoin key to the client, one to the freelancer, and DREAM retaining the third key for disputes. DREAM wouldn’t hold the keys after sending them to the client and freelancer, and we would be less of a target or risk.

Given our goal of simplicity and scalability, any solution that requires our customers to manage private Bitcoin keys that we generate, adds too much support complexity and user responsibility.

2.2 Security

2.2.1 Platform Risks

The Bitcoin private keys generated for transactions on DREAM are exposed to three primary risks:

  1. DREAM – Our web facing servers are compromised (load balancers, application and database servers), and the attacker uses the Escoin API to make payments to themselves (they don’t have the private keys, but they can use our application to process payments)
  2. Escoin – The payment system is compromised, directly exposing the Bitcoin private keys
  3. Social – Our team (server admin / recovery key holder) is compromised (malware / social engineering)

2.2.2 Key Security Challenge

We could have processed payments through a secure, battle hardened, industry respected key storage and wallet solution like BitGo.

The challenge is that no matter where we store our Bitcoin private keys, an attacker can use our application servers and the Escoin API to process payments. For example; if 5,000 payments were held in escrow, and the attacker compromised our application servers, they could change the client wallet address in all pending escrow transactions to their own, and refund everything to themselves (without ever having access to the private keys). 

2.3 Escoin Payment System

Building our own payment system API makes it easier to add additional cryptocurrencies in the future.

2.3.1 API

To process Bitcoin payments on DREAM, we built a separate payment system on top of Bitcore.io to process transactions called Escoin (Escrow Coin). Escoin provides services to DREAM through an API:

  • Generates New Wallets – Creates new Bitcoin multisig addresses when a client makes a payment, and stores the private keys in a distributed vault
  • Settlements – Releases payments; refunds or partial-refunds to clients, and settlements or partial-settlements to freelancers
  • Balance updates and fiat/BTC exchange rates

2.3.2 Transaction Flow

The payment flow is summarised in the following diagram. This applies to gigs and jobs on DREAM.

2.3.3 Bitcoin Key Storage & Protection

When Escoin generates a Bitcoin multisig wallet address, the three private keys are encrypted in separate key vaults (each Vault is on a different server). If a single Vault was compromised the attacker wouldn’t have access to the funds.

The normal process is as follows:

  1. Escoin receives a request to create a wallet address via its API from DREAM
  2. Escoin creates the wallet address and encrypts the three private keys across three Escoin Vaults
  3. Escoin receives a request to release payment to the freelancer
  4. Providing the Transaction Firewall does not detect anything suspicious or any of the Vaults is not sealed, Escoin decrypts the private keys and makes the payment

The following diagram illustrates the process:

2.4 Customer Wallets

When a client or freelancer registers, we generate a temporary Bitcoin wallet address for them. Requiring every new user to enter a wallet address during registration is too much friction, however a wallet is necessary to deal with refunds for clients, and earnings for freelancers.

The DREAM assigned wallet address is unusable by the customer. Funds may be held in the wallet, however as soon as the client or freelancer adds their personal wallet address in their Payment Settings, funds are transferred and the temporary DREAM wallet address disregarded.

2.5 Multisig

The design of the application is built around Multisig, albeit Escoin holds all the keys across three vaults. The keys are assigned to different user profiles; under normal circumstances the client and freelancer keys are used, and if DREAM needed to arbitrate a dispute, we would use our key and the client or freelancer key, depending on the flow of the transaction (refund or payment release).

3.0 Transaction Firewall

The transaction firewall mitigates the risk of an attacker compromising our application and database servers, bypassing our HIDS, and attempting to use the Escoin API to process transactions from the DREAM application servers. The Transaction Firewall consists of:

  • Modules – Monitor and detect suspicious API events, and operating system events
  • Actions – Perform an action based on an event

3.1 Modules

There are (currently) two types of detection modules:

  • OS – Any event at an operating system level
  • API – Any event at an API level

The transaction firewall is continuously monitoring the OS, e.g. if an unexpected outbound TCP connection was initiated from the Escoin server the Vault would go into lockdown (flush Vault access keys from memory), and would require three key holders to recover the system.

Using the event API / WALLET MISMATCH as an example; when a multisig address is requested by DREAM, it sends the client wallet address and freelancer wallet address with the transaction to Escoin. When a payment release is requested by DREAM, the addresses are checked against the original request. In the event of a discrepancy an action will occur.

3.1.1 Modules & Events

The modules are very much work in progress and will be enhanced as we grow. They currently include:

3.2 Actions

The following actions may be performed based on the criticality of the event.

In the event that the system enters the Lockdown state, the only way to make any payments from the Escoin system is to reinstate the Vault keys on the Escoin servers.

In the event that the system enters the Seal state, the only way to make any payments from the Escoin system is to manually unseal the vault on the Escoin Vault server.

4.0 Key Management & Recovery

The Escoin Vault system can be in three states:

  • Active = Vault is active with read / write enabled
  • Write Only = New wallets can be generated, and the keys stored, however payments cannot be made because private keys cannot be read
  • Sealed = The Vault is completely locked down

In order to change the Vault state back from Write Only or Sealed, to Active, three separate people must run a local client-side script (that doesn’t store any confidential information) which connects to a private API through a secure proxy network.

4.1 Process



5.0 CCSS Compliance

CryptoCurrency Security Standard (CCSS) is a set of requirements for all information systems that make use of cryptocurrencies, including exchanges, web applications, and cryptocurrency storage solutions.

We have studied and strictly followed the CCSS guidelines and if audited believe we could achieve Level 3 Certification.  Note that as of March 2017, the framework is in draft and self-certification is required (we confirmed this with CCSS).



Please wait while your files are uploaded