Disclaimer: I am the founder of nunchuk.io, a startup that specializes in multisig Bitcoin wallets. Some of Nunchuk’s services overlap with Bitkey, particularly the Iron Hand plan. Despite this, I strive to be objective in my review.

Block recently introduced a self-custodial solution for Bitcoin called Bitkey. This review delves into Bitkey’s features, highlighting its strengths and potential areas of concerns.

I. Overview of Bitkey

Design Breakdown:

• 2-of-3 multisig wallet: Bitkey operates on a 2-of-3 multisig wallet system, which requires two signatures to withdraw funds. This setup includes:
• A hot key managed by the mobile app,
• An NFC-based hardware key (no display),
• And a hot key maintained on the Block server.

The underlying theme behind the Bitkey architecture is that it prioritizes usability above all else. This is reflected in the decisions to go with a “hot” mobile key (instead of 2 “cold” hardware keys), and a hardware that doesn’t have a display. It also tries to abstract away entirely key generation and backup issues.

(Quick terminology note: A “hot” key is one that is frequently connected to the Internet, making it more vulnerable to attacks. A “cold” key is one that is kept offline.)

Specifically, the user doesn’t see how any of the keys are generated when setting up the wallet, which is a sharp contrast to traditional self-custodial solutions on the market. The tasks of backing up the keys and wallet configuration are also mostly hidden, besides being required to connect to an existing cloud storage.

Altogether, this results in a smooth onboarding process and a very clean UI. It also comes with major trade-offs. But, let’s look at its strengths first.

II. Strengths of Bitkey

Device:

• Build quality: The hardware device feels really solid in your hand and seems durable. This speaks to Block’s experience in making hardware for over a decade.
• Fingerprint reader: The fingerprint reader is responsive and easy to use.
• NFC is the future: NFC is a great choice as the data transfer medium. It is fast and significantly more secure than Bluetooth.

App Experience:

• User interface: Clean and intuitive, with a straightforward setup process. It took me less than 10 minutes to set up the wallet.
• Wallet functionality: Basic yet functional, featuring custom fee settings and a spending limit (“Mobile pay”) feature for enhanced security and convenience.

Co-Signing Server:

• Effortlessly integrates into the user experience, remaining largely invisible.

Overall, the Bitkey team absolutely crushed it on the UI/UX front.

Now, let’s look at the not-as-good parts.

III. Areas for Improvement

There are 3 areas of concerns: security risks due to large attack surfaces, the lack of interoperability with the rest of the self-custody ecosystem, and Bitkey’s business model.

Security Risks Due to Large Attack Surfaces

Bitkey introduces four intricate recovery protocols (Cloud Backup, Delay and Notify, Social Recovery, and Break Glass), each adding new layers of complexity and potential security considerations.

The Bitkey team acknowledges this trade-off themselves. For example, regarding the Delay and Notify protocol:

“Delay and Notify represents a tradeoff: rather than requiring customers to always keep control of 2 keys, we chose to allow customers a path to recovery when they’re down to 1 key — while this may introduce more attack surface, we believe that providing resilience to accidental loss leads to more safety in practice.”

While this type of approach certainly can protect the users more in one type of scenario (e.g. the user’s own mistakes), it also leaves a lot of room for potential exploits in other types of scenarios (e.g. a targeted attack or Block being hacked).

Let’s go through a few concrete examples:

(a) Two of the Three Keys Are Hot

The fact that the design includes 2 hot keys running on Block-developed software (the third key also runs on Block-developed software, but it is not hot), means that effectively in the worst case, Block, or an entity taking over Block, can control 2 of the 3 keys.

Perhaps Block might get hacked. The hack could come from an outsider or an insider. Perhaps it is a government’s takeover.

Additionally, the fact that the hardware key doesn’t have a display further pushes security responsibilities onto the server.

If the Block server gets compromised, there might be a number of ways an attacker can exploit the system. By rolling out malicious software updates to the mobile app or the hardware, or by skipping server security checks when funds are withdrawn or when unauthorized recoveries are initiated.

(b) Phone Exploits

The phone is another potential vulnerable point of attack, given how much easier it would be to gain access to the phone, relative to the other 2 keys.

For example: an attacker can gain temporary access to the phone, then proceed to shut off all communications to the owner from Block (blocking SMS, turning off push notifications, labeling Block emails as spam), before triggering the Delay and Notify protocol using the phone in his possession. By isolating and blocking all communications from Block, the attacker essentially nullifies the “Notify” aspect of the protocol.

When the waiting period has expired, the attacker can gain access to the phone for a second time. This time he’d swap out the original Bitkey hardware with a new one, and sweep the funds to his now-controlled wallet. All without the owner knowing.

If the assumption is that the average Bitkey user isn’t good at key management and backups (and would opt for Bitkey instead of other self-custodial solutions), it might be reasonable to also assume that many of them don’t have good security practices either, when it comes to protecting the phone.

Suggestion for Block: Get rid of the hot mobile key and use 2 hardware keys instead. The base layer of Bitcoin is not meant for buying coffees, which means that the benefit of having a hot mobile key at your fingertips is not as great as one might think.

(c) Explicit Cloud Dependency

The Cloud Backup protocol assumes that when the user loses access to the cloud storage (iCloud or Google Drive), or when the cloud storage accidentally wipes the backup data, Bitkey can reliably detect that the backup is gone and notify that the user immediately recreate and reupload the backup data. But this detection might not always work correctly. At the minimum, the protocol relies on Apple and Google being nice and not breaking their cloud APIs.

Absent a reliable way to detect missing backups, the user might not know that their backup data is gone before it’s too late.

The Bitkey team recognizes this as well, but considers this risk low.

(d) Social Recovery

Another area that could be ripe for potential exploits is Bitkey’s Social Recovery feature, which depends on the Trusted Contact(s) being able to verify that the recovery request indeed comes from the owner. However, in the age of AI where voices and videos can trivially be faked, this presents new complications.

The several example scenarios above by no means form a complete security analysis, but they demonstrate that the Bitkey design introduces new security risks that might not be well understood, given how large and complex the attack surfaces are.

Interoperability Issues

Historically, when a user purchases a hardware signing device (such as a Coldcard, a Ledger, a Trezor, a Jade, etc.), the expectation is that once purchased, the user would be free to use the device however they want. They can even use the device with third-party wallet software, if they don’t want to put too much trust in the hardware vendor.

However, that is not the case with the Bitkey hardware. The Bitkey device is tightly coupled to Block, and as things currently stand, cannot be used outside of the Block ecosystem.

The Break Glass protocol is intended for users to migrate off of the Bitkey. But this migration process can be confusing and highly technical (which Bitkey admits). It also relies on software developed and maintained exclusively by Bitkey. This means vendor lock-in risk is real, and it leaves the users with no recourse if there is a system-wide bug or failure within Block.

Suggestion for Block: Interoperability is a crucial part of security. Even more so when it comes to Bitcoin self-custody. Make Bitkey interoperable.

Business Model Sustainability

Fundamentally, when you buy a Bitkey, you don’t just buy the device. You’re also subscribing to several security services from Block, including but not limited to:

• Securing the server key, maintaining co-signing policies, maintaining the mobile app, maintaining the infrastructure needed for the 4 recovery protocols.

The user would be making a one-time payment to Block, but if Bitkey is expected to be used for a very long time, it means that the company has to subsidize the maintenance cost of keeping the above services up and running indefinitely.

In fact, given how infrequently the hardware is meant to be used, the initial one-time payment can be seen as mainly for buying the Bitkey software services, not the hardware itself.

The cost of maintaining the infrastructure can go up significantly when you consider the fact that there is a natural cap on the economies of scale in this line of business: Block might be holding security-sensitive private keys on behalf of millions of users.

For each user wallet, Block would need to have a dedicated server key associated with the user’s account, or Block runs the risk of sharing one single key (or keys derived from a single key) between millions of user wallets. That would be a huge security concern.

Think of it this way: scaling an assisted self-custody service to a million users is unlike scaling a website to a million users. Some of the users might store a few thousand dollars worth of Bitcoin with the service, some a few million dollars or more. Do you want everyone to be sharing the same server key?

Regardless of how Block generates and manages the server keys used in specific Bitkey user wallets, what’s clear is that the cost of maintaining this security infrastructure can be non-trivial.

Either Block needs to assume that the average hardware replacement rate is high enough (thereby turning one-time fees into a recurring stream of revenue), or Block will need to subsidize Bitkey users using revenue from other parts of the business, such as Cash App.

Now, will we see a world where an average Bitcoin user typically upgrades their hardware signing device every few years, just like how one upgrades their iPhone? Perhaps, but this is unlikely.

Thus, on close inspection, it appears that Bitkey’s business model requires subsidies and is not self-sustainable.

IV. Bitkey vs. Tapsigner: A Comparative Overview

Given the fact that the Bitkey and the Tapsigner both try to improve on usability and target entry-level users, it warrants a quick comparison.

• Tapsigner can also be used in “seedless”, or beginner-friendly, mode.
• Tapsigner can be used to emulate Bitkey’s “Social Recovery” protocol: one can give the encrypted backup of the Tapsigner to a family member, but remain in control of the decryption key.
• Tapsigner is more versatile and can be used in a diverse set of multisig setups, including those that have a screen for independent transaction verification.

If you were to use the Tapsigner as a single-sig wallet, you would lose some of the benefits offered by Bitkey 2-of-3 model, but the Tapsigner security model would be much easier to reason about. Generally speaking, the less complex a security solution, the lower the chance it can be attacked.

V. Conclusion

Bitkey’s entrance into the self-custody market is a welcomed event.

Bitkey, as a self-custodial solution, sits somewhere between a stand-alone Tapsigner and a fully-open, interoperable multisig wallet. It does better than the stand-alone Tapsigner in some areas (e.g. 2-of-3 security), while poorer in other areas (e.g. not interoperable; tightly coupled to Block as things stand).

I believe Bitkey can significantly move the needle in the major upcoming battle for self custody, if it can address some of the weaknesses described in this article. I humbly made 2 suggestions to the Bitkey team: switch to a dual-hardware-key design, and make Bitkey interoperable with the rest of the self-custody ecosystem.