4 min read

How we Choose a Processor for the Hardware

Our engineering teams have been hard at work architecting the hardware component of our wallet, and in this post, we will dive into the process of selecting one of the most important parts in our hardware system - the processor.

In a previous post we shared how our hardware device will be one of three elements included in our self-custody bitcoin wallet, providing customers with additional layers of security when moving money and acting as a self-serve recovery kit when a customer loses their mobile wallet. We have also shared details about our hardware design, including how it will be powered (USB-C with rechargeable battery), how a customer will unlock and interact with it (fingerprint sensor or PIN), and how it will communicate with the mobile device’s app (NFC).

This post will focus on the processor in our device which is not a customer-facing component, but sits at the center of our electrical system, providing the brains of the operation and critical to our hardware device security. Sharing our design process publicly is important to our team as we value feedback to develop the most reliable, easy to use, and secure self-custody wallet for a global audience.

The processor lives on a printed circuit board that we refer to as our main logic board (MLB) and is responsible for running firmware that controls the primary functions of the system. This includes things such as the control of subsystems (NFC controller, fingerprint sensor, LED), the hardware’s key generation, signing of transactions, and even power management. It functions in a similar way to a traditional CPU in a computer, but is optimized for low power consumption, space savings, and cost reduction, all of which are extremely helpful when we're building a small, battery-powered device for consumers.

There are four main types of processors that we could choose from to fit our system’s needs:

  • Secure Element: Widely used in smart cards and typically integrate several customer-facing interfaces (e.g. chip card or contactless interfaces), and usually designed to run the  JavaCard operating system.
  • Microcontroller:  Low power, general purpose computing element used for embedded applications. Typically include storage and program memory (e.g. flash and RAM, respectively). Sometimes include additional security features and support for cryptographic algorithms.
  • SoC (System on Chip): Integrates applications processor with other elements of a system (wireless radios, graphics processors, etc.). Usually designed to support more capable operating systems. Common in phones and other demanding embedded applications.
  • Custom ASIC (Application Specific Integrated Circuit): A custom chip designed with a very specific purpose in mind. Unlike the other options, this would allow for the processor to be tailored to the exact needs of the product and would also allow for a fully open-source processor design.

Choosing the right processor is one of the most critical architecture decisions because it impacts how the rest of the electrical system is designed. Between our teams of mechanical, electrical, and firmware engineers we define critical criteria, develop engineering models, and compare designs until we are able to down-select the optimal design for our system. The criteria by which we evaluated options for our processor selection and electrical architecture design included:

  • Performance: The processor runs code (“firmware”) that passes data to and from the NFC subsystem, computes cryptographic signatures, and authorizes use through a fingerprint matching algorithm. Each of these can be computationally intensive for a small processor, so it’s critical to choose a part that has an adequate core clock speed, ample flash and RAM, and ideally hardware acceleration for cryptographic algorithms needed to securely move money on the bitcoin network and store the secret data involved. On the other hand, the part should be capable of low power operation during periods of inactivity and should only consume a moderate amount of power during its most active states. This will increase the device’s battery life and improve the customer experience.
  • Transparency: We believe that auditability and verifiability of the device’s operation are essential to earning the trust of our customers, and we plan to open source as much of the device's firmware and electrical design as possible. The processor we select should be compatible with this approach and should allow our team to publish source code for not only the application layer, but ideally the entire operating system and hardware abstraction layer.
  • Security: Although our multi-sig key implementation means that the hardware device has only one of the three keys (two of which are required to move money), the security and robustness of our design against malicious attacks plays a significant role in the components we select and our architecture design. This means that many security features are mandatory, such as secure boot that ensures only trusted code can run and dedicated key storage that makes extracting the hardware keys difficult. Our goal is to make the hardware device as secure as possible, even though compromising the hardware alone cannot grant access to a customer's funds.
  • Software and Electrical Complexity: The processor should have enough general purpose inputs and outputs (GPIOs) to control the various subsystems in the product, and it should have support for common embedded programming and communication protocols (SWD, I2C, SPI, UART). It should have an open and robust software ecosystem with support for a variety of RTOS options and commonly-used toolchains (e.g. ARM GCC).
  • Supply Chain: Global supply chain challenges and silicon chip shortages introduce considerations around availability and cost of some processor options. We work closely with each manufacturer to assess risks that could impact our development timelines and mass production plans.

Our next post will focus on the pros and cons of the specific processor and electrical architecture designs we considered. We value community input as we work to ensure the hardware we are building is robust, secure, and open source. We look forward to hearing your feedback on our design considerations and are excited to start sharing some of our detailed hardware designs very soon. Reach us at wallet@block.xyz or on Twitter.