A Hermit Emerges

Three can keep a secret, if two of them are dead. — Benjamin Franklin

No matter how much software and hardware or how many physical and legal barriers a company has built, security is ultimately provided by communication among its people. Employees reviewing each other’s code make applications secure. Guards checking in on each other with cameras and walkie-talkies can create a secure perimeter. The bodily security of a dive group depends on each diver checking their own and their partners’ equipment. 

Companies that protect bitcoin are groups of people protecting a secret, and there are different challenges for groups of people protecting a secret than there are for a single individual HODLer. Both companies and individuals may value properties such as multisig, cold-storage, air-gaps, open-source, etc., but companies have to contend with additional challenges that individuals don’t:

• Companies have to communicate to coordinate. Knowledge about keys cannot be obscured but must be stored in known and accessible ways to guarantee business continuity.
• Companies can have turnover in high-clearance employees, those previously entrusted with knowledge of keys, or those holding keys themselves.
• Companies often demand signing a higher volume of transactions than an individual, possibly multiple times per day. Keys must be available when required by the business, and employees must be organized in on-call schedules and signing rotations.
• Companies must recognize and design their security for the possibility of malicious employees who comprehend the company’s security policies and intelligently seek to circumvent them.

Multisig does mitigate some of these problems, but not completely. Individual keys within a multisig quorum must still be protected. Nested multisig setups are possible, but incur great cost, complexity, and publicly reveal too much about how keys and signers are related when used to sign transactions.

A single BIP39 seed phrase, hardware wallet, or any other scenario which gives, even temporarily, a single employee full knowledge of the company’s private key without requiring the collaboration and consent of other employees is a security hole.

At Unchained Capital, we practice Collaborative Custody. We protect one of the keys in a multisig quorum, with the others held by our customers and partners. We needed a tool to bridge a gap we perceived in private key management and operations for our company. We believe other organizations protecting private keys may face similar challenges, whether they also use multisig or not.

Introducing Hermit

Hermit is an open-source, sharded, air-gapped wallet designed to help groups of people safely manage and use bitcoin private keys. It has two main features:

• Air-Gapped: Hermit is designed to run in a stripped-down Linux environment on custom hardware with WiFi, Bluetooth, USB, and all other forms of wired & wireless communication removed: an air-gapped system. All communication between the user, Hermit, and an online wallet is done via QR codes, cameras, screen, and keyboard.  Hermit thrives in its solitude.
• Sharded: Ben Franklin never met Adi Shamir. Groups of people can collaboratively protect a secret if each of them only has one piece that grants them no knowledge of the total secret by itself. Using a standard known as SLIP-0039, Hermit splits each key into one or more encrypted shard families. Several shards from a family must be simultaneously co-located and decrypted before the key can be used. Shard families are customizable and allow for groups to apportion trust among their members in whatever way matches their organizational needs.

On their own, neither feature is new, but the combination of both is unique and provides organizations with strong security (the air-gap) along with a simpler way for members to collaboratively manage signing responsibilities (the sharding).

These short videos demonstrate Hermit’s main workflows:

• Creating a new shard family
• Exporting & Importing shards
• Exporting an extended public key (xpub)
• Signing a bitcoin transaction

These videos were recorded on an unmodified commercial laptop, but we recommend running Hermit on air-gapped hardware.

You can view the code here: https://github.com/unchained-capital/hermit

Private Key Sharding

Current Problems with Sharding Private Keys

Shamir Secret Sharing Scheme (SSSS) is employed in one form or another at many bitcoin businesses to split a single private key into M-of-N shards. Shamir is not a substitute for multisig; it is additive security for any private key, because M of these N shards must be co-located to reconstitute the private key.

Consider the following example of the fictional company “Bitbase,” which uses SSSS to protect a private key in cold-storage. Bitbase wants either their CEO (Arthur Armstrong), or CFO to be required in order to sign transactions from their cold storage. Executives are busy people who travel a lot, so Bitbase needs some other employees to be able to step in to sign in case one of the executives is unavailable. These other employees should NOT be able to sign on their own without either executive.

To achieve this, Bitbase uses a 3-of-6 Shamir sharding scheme. The CEO has 2 shards, the CFO 2 shards, and 2 other employees each have a shard. This setup works, but it’s clunky and difficult to scale. Different employees deserve different amounts of trust, but traditional Shamir sharding only provides one level of shards and all shards are equal in weight. As a result, the executives end up with 2 shards each to give them more signing power in this scheme.

What’s needed is a way to explicitly apportion different amounts of trust through shards by letting different shards be “worth” more or less when reconstructing a secret.

SLIP-0039 Sharding with Hermit

SLIP-0039 gives us this ability: we can split a single private key in a way which precisely apportions trust the way we need.

SLIP-0039 uses the word family to describe the two-level hierarchy of shards and groups of shards it creates from a given private key.

At the shard level, SLIP-0039 is just like traditional Shamir sharding. M of N shards must be co-located in order to reveal their data.

The difference is that these shards are organized into some number of groups. The number of shards N and the number of required shards M can be different for each group of shards. Given P groups, Q of them must have sufficient shards co-located in order to finally reveal the original private key for the family. With Hermit, Bitbase can create a group for each executive and make it 1-of-1 shards, letting the executives sign together without coordinating with the employees, and only requiring them to hold a single shard with a unique password- Hermit encrypts shards by default. That said, the executive can still coordinate with 2-of-2 employees should the other executive be travelling. In this new scheme, the executives hold a shard worth ½ of a private key, and each employee holds a shard worth ¼ of a private key. Trust among employees has been allocated appropriately for Bitbase.

This flexibility allows for organizations to build sharding schemes that meet their exact organizational needs. Group 3 could be extended to M employees and require 2-of-M to sign, additional groups could be added, and the family structure could be changed to require M groups of N groups. Bitbase could even build an entirely different shard family to require different divisions of employees to collaborate with each other and not with the executives or employees in our example above.

Hermit also provides organizations some flexibility around rotation or replacement of trusted employees. With Hermit, if a signer in the team needs to be rotated out, and the organization trusts that that signer did not previously exfiltrate their own shard, it may be easiest to simply transfer that signer’s shard to a new employee (remembering to encrypt the shard with a new password). If the old signer is no longer trusted or unable to decrypt their shard, then the organization can create a completely new shard family from the existing key. This allows signers to each get new shards without any external consequences, such as having to change addresses or sign bitcoin transactions. Like any wallet, the absolute most secure thing to do when signers change is to swap out the key with a new one, but many organizations may find these approaches reasonable.

Hermit is Alpha Software

Hermit avoids implementing its own cryptography in favor of using trusted open-source libraries wherever possible. The SLIP-0039 standard and corresponding libraries are very new. For this reason, Hermit is currently considered alpha software.

The SLIP-0039 standard was conceived by SatoshiLabs, Christopher Allen, Mark Friedenbach, and several others. SatoshiLabs has published an open-source reference implementation in Python. C libraries have been published by Justin Lin at HTC and by Unchained Capital’s own Chris Howe.

SatoshiLabs recently announced Trezor Model T SLIP-0039 compatibility, and HTC plans to include SLIP-0039 functionality in their upcoming Exodus mobile phone, to be released in Q1 of 2020.

Unchained Capital believes SLIP-0039 is an improvement over traditional Shamir shares, yet we believe it needs further improvement and review. We are working closely with Christopher Allen and the Blockchain Commons on a Bitcoin Improvement Proposal (BIP) that will include the following: 

• Improving security by becoming curve independent
• Future proofing by including version information in serialized shares 
• Adding metadata (such as shard creation dates) to allow for greater flexibility to support features such as MuSig
• Cryptographic review of the underlying implementation

We believe a standardized approach to Shamir sharding will improve security for all bitcoiners. We invite you to check out Hermit, SLIP-0039, and follow our work on supporting this new standard.