Next Generation Security for Blockchain Wallets — Now Open Source

By Rebecca Aspler on ALTCOIN MAGAZINE

Rebecca Aspler

Published in

The Dark Side

8 min readNov 28, 2018

Introduction — Blockchain Security is Still a Challenge

Blockchain is radically changing the transaction-based industries. Protecting these crypto asset transactions, requires the protection of a private key that is a must have, in order to sign every transaction. It is interesting to note that regardless of the transaction type, whether its a cryptocurrency, a smart contract on a user’s identity, a voting transaction or the metadata of a supply chain package — all of these transactions rely on the very basic ability of the owner to securely sign the transaction with their private key.

This embedded vulnerability of having to protect a private key which is a single point of compromise, is still a largely unsolved challenge. It is enough to take just one look at the total amount of hacks, as expressed in the following image, and it is easy to understand investors’ anxiety whenever it comes to keeping their cryptocurrencies safe.

In the traditional banking world, there are various ways in which banks can protect transactions of consumers and investors, including the callback of money that fellow banks respond to respectfully. That is not the case with blockchain assets and hence the greater need to protect these assets and hence their keys.

Alternative Blockchain Security Solutions

Today’s blockchain security solutions are either free and insecure, or secure but costly and complicated to develop, operate and use. An open source library that Unbound Tech has recently released, is now addressing this challenge.

With blockchain assets (i.e. keys and seed secrets) being a single point of compromise, they are a highly vulnerable and lucrative target when stored in memory, even if using methods such as white-box cryptography, which were proven easy to break (e.g. in the CHES 2017 Capture the Flag Challenge, where 94 white-box implementations were all broken, most of them within less than a day).

More secure methods like Multi Sig introduce significant management complexity and development overhead, as (i) more keys need to be managed and (ii) they are heavily ledger dependent, thereby requiring constant coding efforts in order to support new and existing assets, as well as for maintaining sophisticated approval policies.

Dedicated cryptographic hardware-based solutions such as hardware tokens and HSMs need to support blockchain cryptography (specifically BIP32 and the relevant signing algorithms), otherwise very limited security value is provided; for example, using a mobile device’s secure enclave (assuming it doesn’t support BIP32 in the hardware) provides marginal value, as the BIP32 seed will appear in the clear in the unprotected OS memory when generated and while in use — where it is highly vulnerable.

The alternative of using secure hardware trusted execution environment (TEE) such as Intel SGX sounds tempting, however it was proven to be broken by software side channel attacks over and over in the past few years, so it’s security guarantees are questionable at best.

Moreover, the common problems with all hardware-based solutions such as high cost, platform availability, maintenance and lost devices make it a secure but a highly inconvenient, inflexible and non-crypto agile choice.

Securing Blockchain Wallets — Now Open Source

Committed to support blockchain security and the open source community, the newly released Blockchain Crypto MPC library provides all the cryptography needed in order to secure crypto assets — while being as or more secure than dedicated cryptographic hardware — for free.

Contents wise, the open source library consists of:

1. Support for two-party ECDSA secp256k1 — key generation and signing

2. Two-party EdDSA ed25519 — key generation and signing

3. Two-party BIP32 — generation, hard derivation and normal derivation.

4. Key share refresh

5. Zero-knowledge backup

Leveraging MPC for the protection of cryptographic keys and secrets, the blockchain security open source library can be characterized by the following critical security-features:

1. No single point of compromise — Compromising the seed or key material requires the attacker to compromise both the server and the endpoint simultaneously. Sensitive keys and secrets are shared as two random shares, which are stored on separate, segregated machines (‘machine’ stands for any computing device). Each of these shares alone tells nothing whatsoever about the key material.

2. No key or seed material ever appears in the clear throughout its lifecycle, including while in use and during generation. All cryptographic operations performed throughout the key lifecycle are performed without ever combining these 2 shares together. This includes signing, derivation and even generation. Bottom line — no key material or secret in the memory, ever. It is proven mathematically that obtaining the key material requires access to both key shares, thereby requires compromising both machines. A single machine, even if completely compromised and controlled by an attacker, can reveal nothing about the key material — simply because the key material never resides in any single machine.

3. Key shares refresh: The key shares are continually modified, and this modification is done without modifying the key itself. It is computationally efficient and can be performed very frequently — thus forcing the attacker to compromise both machines at virtually the same time in order to obtain key material.

4. Guaranteed non-repudiation; the application server cannot sign any transaction without cooperation from the endpoint device.

5. Resilient to side-channel attacks.

6. Milliseconds performance speed (assuming you are using bots to approve transactions. Humans can take as long as they wish).

Multi Party Computation (MPC). The key never exists as one entity.

What are the Typical Use Cases?

How can you leverage this open source library? We thought of two typical use cases where wallets would find this open source library useful:

Endpoint/Server Use Case — This use case is common for wallet service providers. The user has a mobile wallet on their endpoint device, typically their mobile phone or laptop. The wallet application communicates with a server application. The BIP32 seed and all signing keys are always split between the end user’s device (participant 1) and the service provider (participant 2). Performing any cryptographic operation on the seed or private key requires cooperation of both participants (and communication between them).

Mobile/Laptop Use Case — This is a use case involving two end-user devices that typically belong to the same user. For example, a mobile phone and a laptop. Each device runs an app and both participants collaborate to create a secure blockchain wallet and sign transactions. The BIP32 seed and all signing keys are always split between the mobile device (participant 1) and the laptop (participant 2). Performing any cryptographic operation on the seed or private key requires cooperation of both participants (and communication between them).

Don’t Forget Key Backup. A Challenge on its Own.

Backup is one of the most challenging aspects of crypto asset key management. This section briefly describes the backup functionality that the MPC open source library supplies you with and two potential usage scenarios.

The open source library includes a unique backup mechanism that introduces zero-knowledge backup: an encrypted cold backup that allows public verifiability. This property is significant, as it allows both participants to verify the correctness of the backup at any point in time without decrypting it. It therefore makes this verification secure and prevents a situation where a wrong backup was generated and stored.

1. User-Managed Backup- This is a common form of backup, with the role of backup management mostly on the end-user. An encrypted backup of the wallet can be stored in multiple locations for redundancy (for example, it can be stored by the service provider as described in the Endpoint/Server use case). The private key for this backup should be in the user’s sole possession, preferably in a cold backup. The backup recovery process should be used only for disaster recovery.

2. Service Provider and Trusted 3rd Party, Managed Backup — The following scenario is an expansion of the Endpoint/Server use case that includes a 3rd party trustee service. The trustee service is used only when either the user’s device and/or the service provider have lost their respective key shares.

This model creates a user-transparent backup, effectively similar to a 2-of-3 scenario: each quorum containing 2 of the 3 participants noted above would suffice to perform a cryptographic operation. This is performed by creating three different random share pairs upon wallet and seed generation. In the diagram, key share A is used by the user’s device and the Trustee Service, key share B is used by the user’s device and the Wallet Service Provider, and key share C is used by the Wallet Service Provider and the Trustee Service. It’s important to highlight that each of these pairs is completely independent, each is effectively a backup of the same seed.

Bringing it all Together

Unbound Tech is releasing this open source library — helping blockchain developers resolve the ongoing challenge associated with crypto asset and blockchain applications: the protection of cryptographic signing keys and seed secrets. It is our commitment to drive the blockchain security forward, committed to blockchain advancement and to the open source community.

For more details and for the code and documentation, go to Unbound GitHub now.