Tankred loves working in open source and focuses on Security and UX. After working on email encryption (OpenPGP), he joined Lightning Labs as lead application developer. Since then he’s been able to work full time on Bitcoin key management in the context of a Square Crypto grant.
The risks of Bitcoin custody for end users
Bitcoin is an asset that is difficult to store safely. If Bitcoin is to reach mass adoption the majority of users will likely not be very technically savvy. With that comes systemic risk that the community needs to address and find proper tools for. As of today users have several choices when it comes to custody. All come with a certain set of risks and tradeoffs.
Keeping coins on the exchange
Many users, especially newcomers keep their coins on the exchange. Coinbase currently holds around 1 million BTC on behalf of its users. These risks have been addressed many times elsewhere. So I won’t go into them at length here. But among the biggest threats are the risk of the exchange getting hacked or becoming insolvent. Another big one is the user’s account getting hacked e.g. through a social engineering attack or a SIM swap attack. While keeping your coins on the exchange gives users a similar user experience as with a bank, this unfortunately does not come with the same security guarantees such as deposit insurance.
Manage a seed
The second option users have is to store their coins in their own wallet and manage a 24 word seed phrase via a paper backup. While this is usually a good place to start, once users start putting life changing amounts of value behind that seed phrase, they have to think about things like redundancy and security of their paper backup via a passphrase. Anyone who has helped to onboard new bitcoiners knows how difficult that conversation can be. In my own experience most people can write down a seed phrase and store their backup without much of a problem. Talking to them about redundancy and a passphrase usually leads to the conversation ending very quickly. Either they dismiss these risks or just decide to keep their coins on the exchange.
Seedless multisig
There are of course seedless multi-sig solutions in the market like the Casa App. But these have the downside of being closed source and often times expensive. Paying a subscription fee which is a substantial part of a user’s holdings isn’t an option for many newcomers.
From PGP to Signal: encrypted messaging as an example
Having worked in the email encryption space, I know how hard it is to convince users to adopt better security and privacy practices. I co-founded Whiteout Mail in 2013 to make PGP more accessible to mainstream users. The mistake was thinking that we could change the users’ behavior. Today the strong set of PGP keys on SKS public key servers is around 50k (basically nothing in terms of internet scale). Many in the security industry have since given up on PGP and email encryption in general.
Enter Signal. The Signal messaging protocol showed us how it needs to be done. In contrast to PGP the Signal protocol did not require users to change their behavior. Public keys were automatically fetched from a key server which verified the user's phone number. This reduction in security by trusting a central key server was criticized by many in the IT security industry. But these critics underestimated the potential upside in terms of usability and adoption. Due to its ease of use, the Signal protocol could be added to existing messaging applications such as WhatsApp with a simple software update. This meant that over 3 billion WhatsApp users can use end-to-end encrypted messaging without needing to understand the technical details.
I believe that Bitcoin needs to go through a similar evolution to achieve higher market adoption for self custody.
Security Nihilism
Having these types of discussion with hardcore Bitcoiners often reminds me of a quote by Alex Stamos, former CSO at Yahoo and Facebook.
“Security Nihilism is a set of beliefs that includes the assumptions that all attackers are perfect, that everybody faces the worst possible threat scenario, or that any compromise to make a security feature more widespread should be considered a bug.”
- Alex Stamos, Black Hat 2017 Keynote
I believe as a community we need to overcome these restricting ways of thinking to enable creativity and give ourselves permission to experiment.
We need to ask better questions
A good start is to ask better questions. Looking at the current landscape of wallets and products, are we really addressing user needs? In order to overcome the gap between exchanges and non-custodial wallets the following questions come to mind:
- Can we make it easier for newcomers to secure small amounts?
- Can we engineer better UX and better security than custodial solutions?
- Can we “upsell” additional security over time as user funds grow?
My attempt at addressing these questions is something I call the Photon SDK.
Photon SDK: seedless wallet toolbox
Photon’s primary goal is to explore UX and security tradeoffs, specifically for mobile wallets. It’s a set of fully open source components that are currently written in JavaScript for React Native applications. I chose React Native since it allows cheap and easy prototyping during the exploration phase. As these concepts solidify and there is demand by wallets, native implementations for iOS and Android are the next step. The SDK currently consists of these three components:
- photon-keyserver: stores high entropy encryption keys and provides server side security such as rate limited PIN authentication
- photon-lib: a React Native client module that can be integrated into any wallet application
- photon-app: a demo React Native application that documents how these components work together in a final product
2-of-2 seedless cloud backup
Photon’s encrypted cloud backup is very simple and provides a 2-of-2 security model, as described below.
Firstly the wallet seed is encrypted client side and then stored on the user’s iCloud or Google Drive (depending on if they use iOS or Android). Then the encryption key is stored on the photon-keyserver which is protected with rate-limited PIN authentication. The idea is that an attacker would need access to the user’s Apple or Google account to access their cloud storage, as well as know the PIN required to download the encryption key.
Key server Authentication
The key server stores the encryption key required to decrypt the seed from the user’s cloud storage. As such it is important to secure access using a robust authentication scheme. Photon does not require users to sign up with their email address or to create a separate account. Rather, a random key ID that uniquely identifies the user is generated on the key server and stored in the user’s iCloud or Google Drive. This key ID as well as a user chosen PIN is used to authenticate to the key server. Furthermore server-side rate limiting is enforced to increase the security of the user chosen PIN. This allows the seed to be encrypted with a high entropy random encryption key while requiring the user to only remember a short PIN. Currently a time lock of 7 days is enforced on encryption key download after 10 failed authentication attempts. This results in about 19 years to brute force a simple four digit PIN.
Time delayed PIN recovery
As users store considerable value in their wallets, they might desire to set a recovery email address or phone in case they forget their PIN. Since I wanted to retain the fact that Bitcoin does not have a login this feature is purely optional. The SDK supports both email addresses as well as phone numbers for PIN recovery. Users verify ownership of their accounts via email or sms respectively. Upon PIN reset a 30 day time lock is enforced on the key server to mitigate SIM swap attacks. The idea is that an attacker would not have enough time to steal the user’s funds as users would notice loss of their phone number and/or email account within that time. After the time delay users can set a new PIN and recover their funds.
Photon SDK roadmap
While time locked PIN based authentication might provide a sufficient layer of security for smaller amounts of value, I’d like to enable additional layers of security as the user’s funds grow. This approach is inline with the “upselling” strategy proposed earlier.
Backup integrity checks a.k.a. “Health Checks”
This feature will primarily be implemented in the demo wallet application and represent a UX pattern that the SDK will promote as a best practice. Namely to notify the user every 90 days day to practice key recovery. Basically the user is asked for their PIN and the encrypted seed on the user's cloud will be checked for integrity and compared with the wallet’s installed key. If the user has forgotten their PIN or the encrypted key in their cloud storage is corrupt the app can easily recover by rotating keys and creating a new backup.
2FA for photon-keyserver (Google Auth & Fido U2F)
As the user’s funds grow a simple PIN based authentication might not be enough security for many users. In this case the wallet should suggest an additional 2FA (2 factor authentication) method such as Google Authenticator or FIDO U2F compatible hardware keys. Upon key recovery the wallet app will ask users for their PIN as well as one 2FA method.
Seedless multisig
Another feature in the roadmap is open source seedless multisig with a 2-of-3 or a 3-of-5 setup. This will likely be demanded by more advanced users with higher values to secure. There are many directions this feature could go but file based PSBT and XPUB sharing such as in ColdCard wallets would enable a mobile experience that does not require a desktop computer.
Native iOS & Android libraries
As interest in the Bitcoin ecosystem for Photon grows, wallets will likely need native library implementations via Swift and Java. Please reach out if you are experienced in native mobile development and would like to contribute in this regard!
Demo app on Testflight
I’m currently busy putting the finishing touches on the prototype demo app and would love feedback once it’s available for iOS on Testflight. I’m hoping to get feedback on UX flow as well as the security and privacy tradeoffs for users.
Please feel free to reach out if you’re interested in testing the app or contributing via Twitter (@tankredhase). Thanks :)