Bitkey notes
Intro
The Bitkey product is more than the Bitkey hardware and the Bitkey team has done a great job of building a novel system with a careful consideration for recovery. The team has been very responsive to feedback, and i'm sure we will see the product continue to be iterated on and improved.
A security ceiling
The product is designed to reach people who would otherwise keep their bitcoin on an exchange. Users who wish to migrate to a more robust and secure multi-vendor multisig would need to abandon the Bitkey ecosystem in order to switch to a different system (e.g. DIY with Sparrow or managed with Casa/Unchained).
This creates a security ceiling for Bitkey users. Technical bitcoin users may feel that the product does not meet their needs because it can't be used as part of a "standard" multisig setup.
Understandably the Bitkey team don't want to expose their users to the sharp edges of private keys in the normal use of the wallet, and doing so would likely lead to users shooting themselves in the foot. For this reason, directly allowing users to integrate the Bitkey hardware into a traditional multisig setup is unlikely, and without a screen would not be a very compelling device to add to a quorum.
The strength of the Bitkey product, is the ecosystem that the team has developed - a system with remarkable recovery functionality by leveraging a 2of3 scheme (Phone, Hardware, Server) and encrypted cloud backups. It is unlikely that their users would wish to leave this safety net in order to use traditional multisig.
A frosty future for bitkey?
Fortunately there is a way that Bitkey users could upgrade to multivendor multisig, while retaining the great recovery experience for their Bitkey keys. This wouldn't expose less technical Bitkey users to any additional risk, but would make Bitkey useful to a larger number of people.
This could be achieved by leveraging FROST to aggregate the Bitkey signatures down to a single schnorr key, which could in turn be used in threshold multisig scheme. This idea was raised by Craig Raw in Citadel Dispatch 151.
This would preserve the elegant and sophisticated recovery scheme for Bitkey users, while also allowing those users to break out of the Bitkey walled garden should they wish to add additional keys.
This would also bring great benefits such as the ability to recover funds without moving UTXO's.
Pure Theory?
What's interesting to note is that in October 2024 the block team published a report explaining a novel design for smartphone-based bitcoin wallet.
In short, the report describes
- A 2-of-2 (phone & server). For recovery, the user has an encrypted copy of the server’s key share. The scheme uses FROST meaning the user can unilaterally spend without needing to sweep the utxos.
- The backup (an encrypted copy of the server’s key share) is stored in the phones secure enclave, and requires a time delay followed by a biometric scan to access.
- The server blind signs, leveraging zero knowledge proofs to enforce signing policies without learning about the transaction itself.
Clay Garrett
From recent github activity, it appears that Bitkey team may be implementing this, we can see that there is now FROST being used with a 2of2 scheme.
What happened to the "server-as-a-screen" concept?
In 2023 the Bitkey team published a blog post arguing that screens are not a panacea. To summarise the article, the team broadly argued that
- Screens are not practical for verification. Comparing alphanumeric strings shown on the spending device to those shown on on small screens is difficulat, and this is likely not done by the target demographic (those who currently use custodial exchanges to hold bitcoin).
- Screens don't protect users against (a sufficiently) compromised sending device (phone / laptop). For this reason they argued that an alternate architecture which uses a server "as a screen" to sign data would be advantageous, as it this signature could be verified by the hardware device, guaranteeing that the data was not manipulated in flight.
The team outlined how devices lack of a screen could be mitigated through use of the Bitkey Server "as a screen" for both receiving and sending:
- Receiving: The receive address is signed by the hardware device and sent (via the Bitkey app) to the Bitkey Server, where it is displayed (following signature verification) for the sender on a webpage.
- Sending: The transaction is sent from the Bitkey app to the Bitkey server, which displays the transaction data on a webpage. The sender visits the webpage on another device, and clicks confirm. The server signs the authorisation and sends it to the hardware device (via the Bitkey app) which can verify the servers signature.
A common misunderstanding - The "server as a screen" is not implemented
To quote Matt Odell in the most recent episode of Citadel Dispatch
The Bitkey device does not have a screen on it, but my understanding of the setup is that the bitkey server is also verifying stuff (so that if your mobile phone is compromised you are not recked)
As far as I understand, the current system does not make use of the "server-as-a-screen" model for sending or receiving as described above.
This means that users of the Bitkey are currently blind signing, putting full faith in the Bitkey app.
Faith in a blind signer
Let us discuss how the users of Bitkey could be vulnerable to a malicious entity taking control of some of the Bitkey infrastructure.
Malicious App & Server
The security model of Bitkey is that this does not happen.
But for completeness, in the case that both the Bitkey app and the Bitkey server are compromised the app could construct a transaction sending all funds to the hackers address. This transaction would be sent to the server which would sign the transaction (regardless of any daily spending limit which the user has requested be enforced).
Malicious App
Suppose just the Bitkey app is compromised. Again, on update it immediately initiates a transaction spending the entire user funds to the hackers address.
By default all transfers require the hardware wallet to sign. Any user who has set a daily spending limit higher than their funds balance could have their entire funds stolen, with the malicious app sending a transaction to the server, which would sign. The app could hide transfer information from the user, so even if a user has set a daily spending limit lower than their funds balance each day the app could steal that balance of funds. This may mean that it some time could pass before word spreads that a malicious update was released.
For users who have set a low daily spending limit, the malicious app could wait until the user initiates a spend and prompt the user to "sign with their bitkey hardware", but actually get the hardware to authorise removal of the spending limit.
At this point, the malicious app could send the authorisation to remove the spending limit and subsequently send a theft transaction. At this point, the server, having been instructed to remove the spending limit, freely signs the transaction.
