Our previous post on this topic covered the types of processors that we considered for the hardware component of our wallet and the criteria we used to evaluate them. This post will focus on how we could incorporate each of the options we explored and how the system architecture for each design stacks up against the criteria we set for evaluation. We will explain the pros and cons of each option and explain why we believe a specific secure microcontroller from Silicon Labs is the right processor for our hardware.
From the four types of processors that we initially considered we primarily focused on three options: Secure Element (SE), System on Chip (SoC), and Microcontroller (MCU). While a custom ASIC (Application Specific Integrated Circuit) processor could be tailored to our hardware needs and be fully open-sourced, it requires significant development time, investment, and a team of silicon designers. The benefits of a custom ASIC for this hardware were weighed against our design options that utilized readily available processor components, and while we are lucky to have a silicon design team here at Block that could build a custom chip for this product, these weren’t the right tradeoffs for our first product.
Design options and downselection
Once we narrowed our design options to three processor types (SE, SoC, MCU) we started designing a high-level system architecture for each that would achieve our performance and security goals. We looked at specific processor component options and compared each implementation based on its performance metrics, security features, transparency goals, and design complexity. The table below helps to summarize these architectures and how they compare against each other:
As we worked to make a decision for our hardware we weighed each of these criteria based on how critical they were to achieving our core product goals. For our hardware design, we highly value security and transparency, so our analysis prioritized these qualities. The security requirements for our hardware narrowed the available candidates to a very small set. Our main security criteria includes secure boot, secure key storage, the ability to securely provision initial cryptographic keys and device identifiers, and physical attack resistance.
While a Secure Element (SE) would meet our security criteria, it would also prevent us from publishing certain layers of firmware (e.g. the Hardware Abstraction Layer). This is due to compliance requirements that push Secure Element vendors toward secrecy, as these parts are often used in sensitive government smartcard applications that mandate obscurity of low level details and restrictive NDAs to access documentation. They are often tied to a specific operating system (OS) choice (like JavaCard OS), and choosing another OS or adding custom device drivers requires heavy involvement from approved third-party developers. We prefer an open model of firmware and hardware development – we think that means both a stronger ecosystem of bitcoin-enabling products and greater security over time.
General purpose SoCs and MCUs offer the ability to be more transparent with source code, but they do not typically have the cryptographic acceleration or security features required for the product. An external security chip (cryptographic coprocessor) could be used for key management, but this exposes additional attack surfaces and doesn’t allow us to implement secure boot as robustly as we’d like. In contrast, Secure Elements and secure MCUs have many security features built in.
A secure MCU with the right features allows us to achieve both security and transparency, as these parts typically offer more flexible development (e.g. choice of OS) and full ownership of the firmware, including the Hardware Abstraction Layer. This also gives us the ability to publish source code at our discretion. While full ownership of the firmware requires our team to take on additional development work, the increase to complexity is modest. With a secure MCU, we think we can develop significantly faster than with a Secure Element chip, as the latter could require a third party to be in the loop for our development process. Finally, supply chain constraints like cost and availability are important considerations in selecting the right chip. No option is risk-free from a supply chain perspective, but we see shorter lead times and better acquisition parameters for secure MCUs compared with Secure Elements and a fewer number of parts to procure when compared with general purpose MCUs.
Secure MCUs have some downsides: they require more power than the Secure Elements typically used in smartcards as some are designed to take advantage of NFC power harvesting. Because our total power requirements have to account for other factors, like allowing customers to use the fingerprint sensor even when the hardware isn't in the phone’s contactless field, we will need a battery regardless. We can therefore tolerate the increased power consumption of an architecture based on a secure MCU, and believe it will not detract from the customer experience.
Our processor decision
Confident that a secure MCU offered the best balance against the criteria for our product, our team developed a shortlist of components that could work. Of all the options we considered, the Silicon Labs EFR32MG24 secure MCU offered the most compelling mix of security features and gave us the most flexibility for transparency. The EFR32MG24 boasts an impressive range of security protections, is based on the ARM Cortex-M33 architecture, and comes with standard controls such as TrustZone®, which helps isolate security-sensitive code. This is important to ensure firmware is secure against attacks over its communication interfaces. In addition to this, Silicon Labs has offered many extra layers of protection that can help ensure secret keys stay, well, secret. The EFR32MG24 features a separate core for storing and using keys, encrypted by a PUF, which means the root plaintext secret key doesn't even need to exist within the device while it's powered off. The chip also includes fault injection and side-channel countermeasures, which helps secure the wallet even if it is in an attacker’s hands. Moreover, the chip offers cryptographic acceleration for a wide range of useful algorithms.
Regarding transparency, we intend to open-source as much of our firmware and hardware design as possible. This helps others verify that the hardware does what we claim - and only what we claim. Furthermore, we believe that inviting scrutiny is critical for security, and an open design and codebase encourages that. Using this part from Silicon Labs allows us to build a product with the degree of transparency that we want.
Finally, the part offers an ample amount of flash and RAM, an attractive number of GPIOs that can be used to control the system, and several low power states that can be used to optimize for power consumption and prolong battery life.
Designing a system around the processor
With the processor selected, the next step was to complete an initial design of the electrical system. Below we show our electrical engineering system block diagram with our selected secure MCU (EFR32MG24) at the center of the system architecture. The block diagram provides a high level overview of the main components in our systems and the critical dependencies between them. The diagram is arranged so that the processor sits at the center of the design while customer-facing interfaces are located at the left and right boundaries. The components have also been grouped into separate regions for power and I/O.
What’s next
We hope these posts have helped provide insight into our engineering process and decision-making logic in selecting the processor for the hardware component of our wallet. We welcome any feedback on our decision, especially if there are criteria we should have weighed differently or options we may have overlooked. It’s important to our team that we consider all feedback and options as we strive to make the most robust, secure, open source hardware we can, and we will invite scrutiny along the way. Reach us at [email protected] or on Twitter.
So what’s next? We are preparing to make our first hardware prototypes to enable our engineering teams to start testing firmware, designing test stations, validating electrical performance, and testing mechanical reliability. Stay tuned as we look forward to sharing this work soon.
