As we design and build, we take into account a holistic view of risks and mitigations – including what pitfalls customers face in practice. We typically build a ‘threat model’ that accounts for potential attack vectors across different sets of attackers, their motivations, and their tactics and techniques. When we write a threat model, we start by considering all the ways a customer could be harmed by an attacker – all the bad things that could possibly happen. After getting that on paper, we prioritize what mitigations to build based on the impact, reach, and likelihood of different events in practice, given how people use the product.
Because what happens in practice - availability, security, and user experience all accounted for - is the only thing that matters.
In a series of posts, we’ll cover major factors that contribute to the security of self-custody products, explore a few of the most common security issues that arise with self custody, and illustrate what kinds of features do - and don’t - help mitigate them. Our posts will cover:
- Broad security considerations for self-custody wallets
- Seed phrases: what these human-readable versions of bitcoin keys are, and why we’re building without them
- Hardware wallet screens: in what scenarios they do and don’t provide extra safety (including common misunderstandings), why we aren’t incorporating one into Bitkey hardware, and features we’re considering that can help defend against mobile malware
We’re looking forward to your feedback on these topics. Now, let’s review the wider security considerations that matter when deciding to own and manage your bitcoin with a self-custody wallet..
Keeping keys safe
To truly own their bitcoin, people need to hold their own private keys rather than entrusting them to a third party. So, with self-custody, they’re going to have some binary bits they need to hold onto and keep secret – and they need a safe place to keep them.
Many factors influence how safe a particular storage option for those bits might be. Several goals that led us to our 2-of-3 multisignature design and inclusion of a hardware component include:
- Avoid persistent internet connectivity. When keys stored in a platform that is regularly connected to the internet are compromised, they can generally be abused immediately to steal funds. Offline platforms used to store keys give customers more control over when the keys are used, and pose an extra barrier for attackers who have more opportunities to compromise a persistently-connected computer like a mobile device or especially a desktop. Online platforms are a bit like leaving your bike on the street overnight – keeping it inside your home instead while you’re not using it might not defend against every possible theft scenario, but it’s a lot less likely to get stolen there!
- Limit attack surface. Devices built to do a small set of tasks typically require less effort to secure than devices built to serve as general purpose computing platforms. For example, the code required to run a modern smartphone is many orders of magnitude larger and more complex than the code required to run a typical hardware wallet. This added complexity means more ways for attackers to abuse the platform as they attempt to compromise keys and transactions, and far more nooks and crannies for defenders to secure. Simple, purpose-built platforms like hardware wallets are a lot like physical safes – made to do one job well, so that securing valuables doesn’t depend on always remembering to lock every door and window.
- Invest in platform resilience. Even after investing in platform security - with a combination of security features, scrutiny of the platform by security researchers, and quick and consistent patching of vulnerabilities - no platform is perfect. Self-custody wallets can be more resilient to failures when they use multiple components of the system to achieve critical security and availability properties - and when they invite scrutiny by developing openly.
- Make it hard to make mistakes. Seemingly impenetrable defenses can completely fail in practice if they depend too heavily on people behaving in a certain way. Systems that require their customers to build up extensive knowledge or conduct complicated, error-prone operational processes in order to use them safely can be powerful for some technical experts – and unsafe for everyone else.
How Bitkey Can Help
We're building Bitkey with a focus on security, resilience, and simple user experiences for a broad audience. Our system security choices mean Bitkey:
Uses three keys instead of one, by default. Unlike in a single-signature setup, an attacker must be able to compromise more than one key in order to steal funds - compromising one key is not enough.
Incorporates secure hardware to keep one key stored offline. Storing one of the keys in a device that is not persistently connected to the internet helps reduce the attack surface available to malicious parties looking to steal keys - and thus your money.
Doesn't require customers to hold onto seed phrases, which are hard to hold onto and easy to get stolen.
Incorporates important platform security features, the details of which we'll cover in depth in future posts. We’re designing for considerations including, but not limited to:
- Safe key generation, storage, and management on each of the three platforms that store a key (mobile app and secure hardware - which hold 2 keys controlled by the customer; and Block servers, which hold only one key, not enough to move money in this 2-of-3 model)
- Secure authentication on each of the three platforms
- Features that enable customers to ensure they're using the legitimate Bitkey mobile app and hardware
- Finding and fixing security issues by inviting scrutiny in the open and investing in security patching and hardening
Over the next few days, we'll post our next two installments in this series, focusing on why Bitkey doesn't use seed phrases and why Bitkey hardware doesn't have a screen. If you haven't already, hit the subscribe button so you don't miss them -- and let us know what else you want to hear about at firstname.lastname@example.org, on Twitter, or on nostr.