Keystone Product Design Principles
Articles on: Keystone Blogs
Building a hardware wallet to protect your assets is very much like making a wooden bucket to hold water. The Wooden Bucket Theory states that the bucket capacity is determined by a bucket’s shortest stave. The same is true for hardware wallets as focusing on several aspects would result in the neglect of other aspects that leaves the hardware wallet with vulnerabilities negating the effectiveness of the entire device as a whole. In the language of digital security, this is commonly known as the need to avoid a single point of failure — it only takes one thing to go wrong for a person to lose all their coins. To provide the community with solutions that achieve financial sovereignty, it’s important to view the user experience holistically and account for all the aspects of the storage process, including the potential for human error which new users may be more prone to.
Maximizing Attack Cost
Nothing on this planet is unhackable — to a hacker, it’s just a matter of costs vs profits. What hardware wallets do is implement mechanisms that effectively build up the attack cost without significantly raising the costs for the hardware wallet owner.
Hardware wallets isolate your private keys from the internet because physical attacks cost significantly more than remote ones. In terms of how air-gapped your hardware wallet is and how costly it is for a hacker to steal your assets, how a hardware wallet connects to its companion app is crucial. Using QR codes or microSD cards for data transmission has significant security advantages for air-gapping your keys compared to USB and Bluetooth, in which these data transmission methods have larger attack surfaces due to their interactive connections.
Supply chain attacks are also dangerous partly because the only protection most hardware wallets have is tamper-proof packaging which does not prohibitively increase the cost of an attack for a sophisticated or seasoned attacker. Keystone has implemented similar packaging measures for their hardware wallets but has also introduced a Web Authentication process which is much more meaningful in raising the attack costs for an attacker.
Physical attacks are frequently disclosed in the hardware wallet industry. We adopted a Secure Element, the standard defense mechanism against physical attacks, but also implemented another security mainstay of the traditional banking industry — a self-destruct mechanism that triggers upon disassembly. The applied mechanism is also commonly found in ATMs and credit card terminals so that all sensitive information such as private keys is erased if someone tries to open the device up (be aware that the device will be bricked if you do this yourself).
Minimizing Trust
Centralized systems are mostly built on trust and are a model of security that is continually threatening collapse. This is apparent with incidences like the fall of Arthur Anderson during the Enron scandal and everywhere today regarding disasters related to the coronavirus pandemic.
Satoshi Nakamoto raised the flag of decentralization and started a movement to build a trustless system for the ultimate safest asset. In order to provide a product that provides people with true financial sovereignty, it’s necessary to make it as trustless as possible.
While it may be sobering, it should be said that achieving completely trustless hardware is almost impossible if we look at the manufacturing process from a bottom-up perspective: silicon — chip & circuit board — chip base code — chip firmware — wallet application. One way to minimize trust is to use QR code data transmission to allow users to easily verify all the information that goes in and out of the hardware wallet.
Another major step we took was to release the hardware wallet industry’s first open-source firmware for our Secure Element. While we’re unable to open-source the design and base code of the Secure Element due to manufacturer IP concerns (general-purpose MCUs can’t open source these either), the firmware code allows a user to verify all important cryptographic operations. We chose a Secure Element vendor that would allow us to release these firmware codes in hopes it will help end the controversy over whether Secure Elements are ultimately beneficial to security or not.
With open source Secure Element firmware, you can easily verify:
How the recovery phrase and master private key are generated from the entropy
How child private keys and public keys are generated/derived
That the signing procedure happens entirely within the Secure Element
Your private keys never leave the Secure Element
Unfortunately, there are three functions that can’t be verified because they are realized by the base code and chip design:
Random number generation (TRNG)
Cryptographic algorithms like ECDSA
How it prevents physical attacks (side-channel attacks)
TRNG can be verified by running a test like FIPS 140–2. Check out Trezor’s results of running a FIPS 140–2 test for STM32’s TRNG (note: the Secure Element must be able to give raw analog entropy to perform this test). We also allow user-supplied entropy in the form of dice rolls. Users can easily bypass the TRNG when generating their wallets. Cryptographic algorithms like ECDSA can also be verified by running diagnostic tests.
In terms of physical attacks, hardware-wallet attack history clearly demonstrates that Secure Elements significantly raises the attack costs when compared to a general-purpose MCU. Again, security is more of a relative concept than an absolute one.
Open sourcing is not a one-time thing but a long-term project. Our latest milestone was open sourcing the device schematic (circuit diagram). And we will open source the code of the operating system layer in the future.
We are also embracing PSBT so you can build up multisig with other hardware wallet brands to minimize your trust for any single hardware wallet brand and avoid single points of failure.
Taking Human Error into Consideration
Numbers from late 2019 shows the number of bitcoin owners in the US went up 81% compared to 2018. There are now 36.5 million people in the US who own some form of crypto asset. An increasing number of newbie users are entering this area which will inevitably amplify the damage done by human error: an estimation of 4 million bitcoins lost forever.
The pity is that for the past few years, most hardware wallet vendors have invested in technical security. While we debate whether hardware wallets should use Secure Elements or not, we tend to forget to think about hardware wallet security from the perspective of a basic user. As hardware wallets are no longer made for just advanced users, we can no longer ignore the mass market.
When we designed Keystone, human error was taken seriously and influenced the following decisions:
The mobile-only companion app: Most people are not aware of the threat of phishing attacks and at times, tricked into downloading malicious companion apps when using their desktop pc. The tradeoff here is that the Tor network is not easy to implement on mobile devices which are generally not as flexible and customizable as desktops. However, we also make Keystone compatible with Electrum, Wasabi, and other third-party wallets that advanced users can use as their watch-only wallets instead of our mobile companion app.
A 4-inch touchscreen: This enables more effective prompts and a better typing experience. By providing space for a second input field, a large touchscreen can significantly lower the risk of typing in the wrong passphrase. A big screen also allows you the versatility to receive funds and directly store them without ever connecting to the internet — all you have to do is present a freshly generated QR code to the sender in person. A big screen can also help solve the issue of Blind Signing.
Firmware upgrades exclusively signed by the Keystone team: This counters potential social engineering attacks that trick users into installing malicious third-party firmware. Warnings that caution users about third-party firmware aren’t enough since not all users are educated or cautious enough to understand this threat.
Avoiding Single-Point-of-Failures
The value of a decentralized system is in avoiding collapse due to any single point of failure. This same core principle applies to hardware wallet designs: they are only as strong as their weakest vulnerability. When designing Keystone, we tried to address this issue meaningfully from as many angles as possible:
Keystone allows you to split your recovery phrase into three shares, any two of which can be used to reconstitute the whole phrase. We divide your recovery phrase according to the SLIP39 Shamir’s Secret Sharing backup standard provided by SatoshiLabs and advise you to store the shares in three separate locations to reduce the likelihood of loss occurred from any single point of failure.
We use detachable batteries and provide AAA support because most users don’t think about how to properly store device batteries. While the majority of electronic products are not designed for long-term storage, hardware wallets are likely to be used on a different timescale, possibly even for a lifetime. Hardware wallets should not rely on any single type of power supply as AAA batteries may one day be vital if the rechargeable lithium battery fails.
Multisig is the ultimate counter to single points of failure and we are proud to have embraced it in a big way. For those who are unfamiliar with how pivotal Bitcoin multisig is for security, we strongly recommend you check out this tutorial by Michae Flaxman. If you want to use multisig for Ethereum and other EVM chains, please check our integration with Gnosis Safe.
Interoperability Matters
The Keystone team doesn’t quite agree calling Keystone a “hardware wallet” because we think a more accurate notion would be an “offline signer”. We are making Keystone compatible with as many software wallets as possible. There are several benefits doing so:
Making a hardware wallet compatible with many software wallets is another level of “avoiding single points of failure”. If a software service is halted or its maintenance is stopped, users can easily switch to an alternative software to interact with the blockchain.
Being compatible with many software wallets can make Keystone fit into different user scenarios. Examples include the coinjoin with Wasabi Wallet & Web3 support with both MetaMask extension and mobile version. Furthermore, Keystone is even compatible with DeFi projects like SushiSwap through web pages.
This strategy can make our team more focused on the most important part — how to help users sign transactions more securely. An example would be how Keystone can decode complex DeFi transactions and let users know what they are actually signing.
We really love the idea of Composable Wallets by Andrew Hong. A hardware wallet (or ideally, signer) should focus on the security layer which has 4 components — key pair generation, wallet recovery, transaction and message signing/ABI decoding.
Final Words
Two things we are looking forward to develop for hardware wallets:
Bypassing any general purpose MCU or ARM chip while making the Secure Element control and communicate with all the I/O. Doing so would close the most significant attack surface on a hardware wallet. This will realize greater trust minimization of the Secure Element.
A fully open source Secure Element brings a whole new level of trust minimization. Google is currently working on this.
If we apply the wooden bucket analogy to the entire cold storage process, hardware wallets become just one stave of a larger wooden bucket. Other staves include storing your recovery phrase, protecting your online privacy, choosing a wallet system whose structure balances the priorities of security and efficiency, and other junctures where things could go wrong. Education on these and other topics is part of the Keystone team’s responsibility as a hardware wallet vendor as we seek to provide solutions for the community so they can secure their financial sovereignty.
It is important to look at security from all angles and we appreciate your input on our products. Please feel free to reach out to us on Twitter @KeystoneWallet with your thoughts and questions.
Updated on: 17/02/2023
Building a hardware wallet to protect your assets is very much like making a wooden bucket to hold water. The Wooden Bucket Theory states that the bucket capacity is determined by a bucket’s shortest stave. The same is true for hardware wallets as focusing on several aspects would result in the neglect of other aspects that leaves the hardware wallet with vulnerabilities negating the effectiveness of the entire device as a whole. In the language of digital security, this is commonly known as the need to avoid a single point of failure — it only takes one thing to go wrong for a person to lose all their coins. To provide the community with solutions that achieve financial sovereignty, it’s important to view the user experience holistically and account for all the aspects of the storage process, including the potential for human error which new users may be more prone to.
Maximizing Attack Cost
Nothing on this planet is unhackable — to a hacker, it’s just a matter of costs vs profits. What hardware wallets do is implement mechanisms that effectively build up the attack cost without significantly raising the costs for the hardware wallet owner.
Hardware wallets isolate your private keys from the internet because physical attacks cost significantly more than remote ones. In terms of how air-gapped your hardware wallet is and how costly it is for a hacker to steal your assets, how a hardware wallet connects to its companion app is crucial. Using QR codes or microSD cards for data transmission has significant security advantages for air-gapping your keys compared to USB and Bluetooth, in which these data transmission methods have larger attack surfaces due to their interactive connections.
Supply chain attacks are also dangerous partly because the only protection most hardware wallets have is tamper-proof packaging which does not prohibitively increase the cost of an attack for a sophisticated or seasoned attacker. Keystone has implemented similar packaging measures for their hardware wallets but has also introduced a Web Authentication process which is much more meaningful in raising the attack costs for an attacker.
Physical attacks are frequently disclosed in the hardware wallet industry. We adopted a Secure Element, the standard defense mechanism against physical attacks, but also implemented another security mainstay of the traditional banking industry — a self-destruct mechanism that triggers upon disassembly. The applied mechanism is also commonly found in ATMs and credit card terminals so that all sensitive information such as private keys is erased if someone tries to open the device up (be aware that the device will be bricked if you do this yourself).
Minimizing Trust
Centralized systems are mostly built on trust and are a model of security that is continually threatening collapse. This is apparent with incidences like the fall of Arthur Anderson during the Enron scandal and everywhere today regarding disasters related to the coronavirus pandemic.
Satoshi Nakamoto raised the flag of decentralization and started a movement to build a trustless system for the ultimate safest asset. In order to provide a product that provides people with true financial sovereignty, it’s necessary to make it as trustless as possible.
While it may be sobering, it should be said that achieving completely trustless hardware is almost impossible if we look at the manufacturing process from a bottom-up perspective: silicon — chip & circuit board — chip base code — chip firmware — wallet application. One way to minimize trust is to use QR code data transmission to allow users to easily verify all the information that goes in and out of the hardware wallet.
Another major step we took was to release the hardware wallet industry’s first open-source firmware for our Secure Element. While we’re unable to open-source the design and base code of the Secure Element due to manufacturer IP concerns (general-purpose MCUs can’t open source these either), the firmware code allows a user to verify all important cryptographic operations. We chose a Secure Element vendor that would allow us to release these firmware codes in hopes it will help end the controversy over whether Secure Elements are ultimately beneficial to security or not.
With open source Secure Element firmware, you can easily verify:
How the recovery phrase and master private key are generated from the entropy
How child private keys and public keys are generated/derived
That the signing procedure happens entirely within the Secure Element
Your private keys never leave the Secure Element
Unfortunately, there are three functions that can’t be verified because they are realized by the base code and chip design:
Random number generation (TRNG)
Cryptographic algorithms like ECDSA
How it prevents physical attacks (side-channel attacks)
TRNG can be verified by running a test like FIPS 140–2. Check out Trezor’s results of running a FIPS 140–2 test for STM32’s TRNG (note: the Secure Element must be able to give raw analog entropy to perform this test). We also allow user-supplied entropy in the form of dice rolls. Users can easily bypass the TRNG when generating their wallets. Cryptographic algorithms like ECDSA can also be verified by running diagnostic tests.
In terms of physical attacks, hardware-wallet attack history clearly demonstrates that Secure Elements significantly raises the attack costs when compared to a general-purpose MCU. Again, security is more of a relative concept than an absolute one.
Open sourcing is not a one-time thing but a long-term project. Our latest milestone was open sourcing the device schematic (circuit diagram). And we will open source the code of the operating system layer in the future.
We are also embracing PSBT so you can build up multisig with other hardware wallet brands to minimize your trust for any single hardware wallet brand and avoid single points of failure.
Taking Human Error into Consideration
Numbers from late 2019 shows the number of bitcoin owners in the US went up 81% compared to 2018. There are now 36.5 million people in the US who own some form of crypto asset. An increasing number of newbie users are entering this area which will inevitably amplify the damage done by human error: an estimation of 4 million bitcoins lost forever.
The pity is that for the past few years, most hardware wallet vendors have invested in technical security. While we debate whether hardware wallets should use Secure Elements or not, we tend to forget to think about hardware wallet security from the perspective of a basic user. As hardware wallets are no longer made for just advanced users, we can no longer ignore the mass market.
When we designed Keystone, human error was taken seriously and influenced the following decisions:
The mobile-only companion app: Most people are not aware of the threat of phishing attacks and at times, tricked into downloading malicious companion apps when using their desktop pc. The tradeoff here is that the Tor network is not easy to implement on mobile devices which are generally not as flexible and customizable as desktops. However, we also make Keystone compatible with Electrum, Wasabi, and other third-party wallets that advanced users can use as their watch-only wallets instead of our mobile companion app.
A 4-inch touchscreen: This enables more effective prompts and a better typing experience. By providing space for a second input field, a large touchscreen can significantly lower the risk of typing in the wrong passphrase. A big screen also allows you the versatility to receive funds and directly store them without ever connecting to the internet — all you have to do is present a freshly generated QR code to the sender in person. A big screen can also help solve the issue of Blind Signing.
Firmware upgrades exclusively signed by the Keystone team: This counters potential social engineering attacks that trick users into installing malicious third-party firmware. Warnings that caution users about third-party firmware aren’t enough since not all users are educated or cautious enough to understand this threat.
Avoiding Single-Point-of-Failures
The value of a decentralized system is in avoiding collapse due to any single point of failure. This same core principle applies to hardware wallet designs: they are only as strong as their weakest vulnerability. When designing Keystone, we tried to address this issue meaningfully from as many angles as possible:
Keystone allows you to split your recovery phrase into three shares, any two of which can be used to reconstitute the whole phrase. We divide your recovery phrase according to the SLIP39 Shamir’s Secret Sharing backup standard provided by SatoshiLabs and advise you to store the shares in three separate locations to reduce the likelihood of loss occurred from any single point of failure.
We use detachable batteries and provide AAA support because most users don’t think about how to properly store device batteries. While the majority of electronic products are not designed for long-term storage, hardware wallets are likely to be used on a different timescale, possibly even for a lifetime. Hardware wallets should not rely on any single type of power supply as AAA batteries may one day be vital if the rechargeable lithium battery fails.
Multisig is the ultimate counter to single points of failure and we are proud to have embraced it in a big way. For those who are unfamiliar with how pivotal Bitcoin multisig is for security, we strongly recommend you check out this tutorial by Michae Flaxman. If you want to use multisig for Ethereum and other EVM chains, please check our integration with Gnosis Safe.
Interoperability Matters
The Keystone team doesn’t quite agree calling Keystone a “hardware wallet” because we think a more accurate notion would be an “offline signer”. We are making Keystone compatible with as many software wallets as possible. There are several benefits doing so:
Making a hardware wallet compatible with many software wallets is another level of “avoiding single points of failure”. If a software service is halted or its maintenance is stopped, users can easily switch to an alternative software to interact with the blockchain.
Being compatible with many software wallets can make Keystone fit into different user scenarios. Examples include the coinjoin with Wasabi Wallet & Web3 support with both MetaMask extension and mobile version. Furthermore, Keystone is even compatible with DeFi projects like SushiSwap through web pages.
This strategy can make our team more focused on the most important part — how to help users sign transactions more securely. An example would be how Keystone can decode complex DeFi transactions and let users know what they are actually signing.
We really love the idea of Composable Wallets by Andrew Hong. A hardware wallet (or ideally, signer) should focus on the security layer which has 4 components — key pair generation, wallet recovery, transaction and message signing/ABI decoding.
Final Words
Two things we are looking forward to develop for hardware wallets:
Bypassing any general purpose MCU or ARM chip while making the Secure Element control and communicate with all the I/O. Doing so would close the most significant attack surface on a hardware wallet. This will realize greater trust minimization of the Secure Element.
A fully open source Secure Element brings a whole new level of trust minimization. Google is currently working on this.
If we apply the wooden bucket analogy to the entire cold storage process, hardware wallets become just one stave of a larger wooden bucket. Other staves include storing your recovery phrase, protecting your online privacy, choosing a wallet system whose structure balances the priorities of security and efficiency, and other junctures where things could go wrong. Education on these and other topics is part of the Keystone team’s responsibility as a hardware wallet vendor as we seek to provide solutions for the community so they can secure their financial sovereignty.
It is important to look at security from all angles and we appreciate your input on our products. Please feel free to reach out to us on Twitter @KeystoneWallet with your thoughts and questions.
Updated on: 17/02/2023
Updated on: 21/02/2023
Thank you!