# Passport Security Model
## 1. Hardware Overview
Passport strives to offer best-in-class hardware security through a model of security-via-openness. Our hardware security philosophy can be described as follows:
* Be as transparent as possible, with open source circuit designs, schematics, and bill of materials. Vulnerabilities can be more quickly discovered in an open source model.
* Only purchase components through reputable suppliers and distributors. This means buying from American companies like Arrow, Digikey, and Mouser.
* Make use of available components, so that experts can build their own Passports from scratch without our knowledge or permission.
* Use more trustable components, such as a tamper-evident screen, an open source true random number generator, and standard AAA batteries.
* Minimize the use of black-box silicon; i.e., closed source chips running unknown firmware. Use only chips from reputable suppliers like STM and Microchip, and try to use “dumb” chips that are not running any OS or executing unknown code.
* Assemble our hardware in the USA, including circuit boards, under close supervision by Foundation Devices team members.
Completely air-gapped, Passport communicates only via QR codes or microSD cards – Passport includes no USB port or wireless communications of any kzind.
Passport uses the following key components:
* STMicroelectronics STM32H753 microcontroller. Our open source MicroPython code runs on this processor. This is the only chip in Passport that executes code, and we know 100% of the code running on this chip.
* Microchip ATECC608A secure element. This security chip is explicitly designed to safeguard private keys, but is simple enough that it does not execute any code. We use the 608a primarily for its secure key storage slots.
* Sharp LS018B7DH02 memory display. In addition to being ultra low power, this screen has its circuitry etched directly into glass instead of using an embedded processor. Its circuitry can be visually inspected, and is therefore considered tamper-evident.
* Omnivision OVM7690 camera. This camera assembly provides an image output to our STM microcontroller. No QR processing occurs on the camera; all QR processing takes place in our open source code on the microcontroller.
* MicroSD card slot. This is used for firmware updates and large PSBTs.
* Physical keypad. This is used for navigation and user input and is considered tamper-evident.
* Avalanche noise source. This open source implementation of a true random number generator allows for a provable source of entropy without any black-box silicon. Same general design used by bunnie in the Betrusted project.
* Ambient light sensor.
* ADP 5587 keypad controller chip.
* 2MB External SPI Flash. This provides temporary storage for firmware updates and a UTXO cache.
## 2. Glossary of Terms
The following definitions are used in the descriptions in the remainder of this document.
* **Device Hash** - A SHA256 hash over the MCU's unique ID, the Secure Element's unique ID, and the device's one-time pad. This hash is used in several places when a value is needed that ties strongly to a specific Passport.
* **JTAG** - A standard for connecting debug probe hardware to an embedded system such as Passport. This tool is most commonly used by embedded system developers. JTAG gets its name from the **J**oint **T**est **A**ction **G**roup, which codified the standard.
* **MCU** - An acronym for **M**icro**C**ontroller **U**nit. This is the embedded equivalent of a CPU. Passport's MCU is the STM32H753.
* **One-Time Pad** - A random number (72 bytes in Passport) that is used for encoding and encrypting various values as described below. The Passport One-Time Pad is also hashed into the Device Hash.
* **RDP** - An acronym for **R**ea**D**-out **P**rotection, which is a security feature of STM32 microprocessors which can prevent attackers from accessing the MCU using a JTAG debugger.
* **Secure Element** - A security ASIC that provides secure storage and retrieval of secret data, also allowing for supply chain attestations, PKI support and other security-related hardware functions. Passport uses the Microchip ATECC608A Secure Element.
* **XFP** - The e**X**tended **F**inger**P**rint is obtained from the first 4 bytes of the RIPEMD160 hash of the SHA256 hash of a public key. This is usually the master public key, resulting in what is sometimes referred to as the Master XFP. An XFP is just a shorthand way of identifying a wallet or a signer in a multisig quorum. An XFP is typically formatted in hexadecimal, for example, 0xA1B2C3D4. Note that some wallets byte-reverse the XFP, so 0xA1B2C3D4 is sometimes displayed as 0xD4C3B2A1.
## 3. Security Overview
### 3.1 Philosophy
Passport’s general security philosophy can be described as follows:
* **Open source everything.** No unknown code runs on Passport and expert users can review every line of code.
* **Protect from compromised computers with a physical airgap.** USB and Bluetooth have large attack surfaces, so Passport relies on a physical QR code or microSD airgap. QR codes are always preferred.
* **Protect from physical attacks.** Passport uses a secure element, which significantly increases the cost of an attack to hundreds of thousands of dollars. Passport also implements supply chain validation, PIN entry limits, anti-phishing PIN, and more.
* **Assume the microcontroller will be compromised.** Most microcontrollers, even those with advanced security features like firewalls, are insecure and trivial to compromise. Passport ensures that all sensitive data is first encrypted and then stored in the secure element. Passport also attempts to alert the user if the STM part is compromised by a sophisticated attacker.
* **Keep it simple.** By default, Passport only allows installation of firmware signed by Foundation Devices. Passport presents a simple UI and does not include complex features like secondary wallets or self-destruct PINs. Passport encourages use of an encrypted microSD card or multisig, rather than writing down seeds in plaintext.
### 3.2 Security Feature Summary
Some key security features (described in more detail in later sections) include:
* Secure Element stores the user’s Bitcoin seed XOR'd with a random "one-time pad" value that is unique to each Passport, and encrypted with a random pairing secret shared by each Passport and Secure Element.
* The PIN is required to:
1. Change the PIN,
2. Change or clear the seed,
3. Read the seed from the Secure Element.
* The Secure Element includes monotonic counters that enable PIN attempt tracking, where the Secure Element will “brick” itself by no longer permitting login attempts if the maximum number of attempts is exceeded.
* Discovery of the pairing secret without knowing the Secure Element read key (derived from the user’s PIN, hashed up with a one-time pad) does not reveal the private key.
* MCU is programmed at the factory with a random pairing secret which is required for communication between the MCU and the Secure Element (used as a MAC, or Message Authentication Code).
* MCU is locked down to RDP level 2 at factory initialization time. (However, an advanced attacker may be able to power glitch the MCU back to RDP level 1 or 0 using custom hardware, and assuming they have direct physical access to the device for a period of time.)
* MPU (Memory Protection Unit) is configured to make certain regions of flash and RAM read-only.
* By default, the bootloader will only install firmware signed by Foundation Devices, which closes off an entire category of attack vectors. The only caveat is that a signed-in developer can also load their own public key and Passport will allow firmware signed with the corresponding private key to be installed.
* Firmware updates must be signed by any 2 of 4 keys held in various locations by Foundation Devices. This ensures some fault-tolerance if a key is compromised or lost, and prevents any single employee from releasing their own firmward updates.
* During factory provisioning, and when updating firmware, all unused flash will be erased and then programmed to zero to ensure it cannot be written again without erasing the entire flash sector (which would invalidate the firmware).
* Serial port used for Python console on development boards is not populated and debug output is disabled in firmware releases.
* The bootloader ensures that the MCU is still configured for RDP level 2 before executing the main firmware, and if not, it will reset the MCU to RDP level 2 before continuing.
* We may offer an alternative developer variant of Passport that is not set to RDP level 2 – this would allow advanced users make modifications to the code to suit their special requirements.
- This version would allow end-users to lock down the Passport to RDP level 2 once they have validated the firmware.
- They would also be able to only allow firmware signed by their own private keys to be loaded.
- They could allow Foundation firmware to be installed as well, but they could also build firmware that prevents this.
* Passport includes a supply chain verification mechanism based on asymmetric keys and a public web server. Each Secure Element contains a secret which is used as part of a challenge/response mechanism to prove that the Passport is genuine.
## 4. Firmware Organization
The firmware is split into two parts:
* **Bootloader** - A simple bootloader that handles factory initialization and firmware updates only. This code is stored in the first sector of flash (128K available) and is not updatable after factory initialization. The last 2K of the bootloader holds some secret information including the pairing secret and a one-time pad (but not the seed).
* **Updatable Firmware** - The remainder of the code lives in the rest of the internal flash, including the code that communicates with the Secure Element. This code is updatable so that Foundation can deploy updates for a wider range of potential bugs or vulnerabilities compared with other hardware wallets. Firmware updates must be cryptographically signed with two of Foundation’s four valid keys or else the bootloader will not install the update. This prevents malicious third-party firmware from being installed.
## 5. Firmware Signing
Foundation goes through the following steps to prepare and sign a firmware update:
* A developer builds the current source code into a firmware image file.
* Sign the file with one of the Foundation keys using the `cosign` tool.
* Pass the partially-signed file along to one of the other signers.
* Sign the file with another one of the Foundation keys, using the `cosign` tool.
* The `cosign` tool ensures that two different signing keys are used.
## 6. Factory Firmware Installation
For initial firmware and bootloader installation during manufacturing, Foundation uses a custom Python firmware installation and provisioning script talking to an ST-LINK V2 JTAG device which is connected to a developed bed-of-nails device into which each Passport is placed for testing and initial programming.
The manufacturer will go through the following steps:
1. Connect the Passport to the “bed of nails” fixture.
2. Enter a command on the Linux laptop to start the firmware installation.
3. The installation script will do the following:
* Load the supply chain secret onto the Passport
* Copy the firmware and bootloader to the Passport.
* Reset the device to start its execution for the first time.
* The bootloader sees that the MCU secrets have not been initialized and the Secure Element has not been configured, so it does both of those steps.
* The final step is to lock down the MCU into RDP level 2 to completely disable the JTAG interface.
* Once complete, the bootloader transitions control over to the main MicroPython firmware.
Note that this procedure is vulnerable to a MITM attack at the factory. For example, replacing the Linux laptop with a different laptop or using a cable in the middle that watches for programming to start and replaces the desired firmware with alternate firmware. This is why a Foundation Devices team member will always control and monitor the Linux laptop, including removing it from the factory at the end of each day.
## 7. Firmware Updates
Passport firmware updates will be performed by the bootloader code only. Firmware update files have two slots in the firmware update header for signatures. The bootloader requires two different and valid Foundation signatures to be present (or a single user signature), otherwise it will not install the update.
The update procedure is:
1. User initiates a firmware update from the Firmware > Update Firmware menu.
2. MicroPython code reads the firmware header from the microSD card and checks that the format is correct and the timestamp is not older. This allows Passport to notify users if there is a problem with the update. It currently does not validate the signatures at this point, as that will happen momentarily in the bootloader anyway.
3. If all is OK, Passport will copy the firmware from the microSD card into external SPI flash (~1.7MB available), then reset the MCU.
4. On restart, the bootloader will check external SPI flash and see that there is a firmware update available.
5. The bootloader will repeat the header verification and then additional ensure that the signatures are valid. If the firmware does not pass the checks, an error message will be displayed, and the bootloader will erase the external SPI flash and continue to boot the current version of firmware without making any changes.
6. If all checks pass, the bootloader will copy the firmware update from external SPI flash to internal flash, then continue booting the MCU to MicroPython.
To avoid bricking Passport during firmware updates, the firmware includes the following additional protective measures:
1. If Passport crashes or loses power while copying an update from microSD to external SPI flash, then when the bootloader attempts to validate the update either (a) the header will be invalid or (b) the firmware hash will fail. The bootloader notifies the user of the failuire, then clears the update from external SPI flash so that it does not check it again.
2. If Passport crashes while copying the new firmware from external SPI flash into internal flash, then upon reboot, it will simply restart the copy process again – beginning with re-erasing the internal flash.
3. In some cases, when power is lost while copying from external SPI flash to internal flash, one of the internal flash sectors can become corrupt. Passport's bootloader detects this situation, erases the sector, then restarts the copy process.
## 8. Hardware Security
The following sections describe the mechanisms used at runtime to secure the MCU, flash and RAM against attacks. The goal is to prevent inspection of the Secure Element pairing secret in flash and also in RAM. In addition, there are brief periods of time during which the private key is in RAM when signing transactions or if the user requests to see it. It must not be possible to read this RAM externally or via unprivileged code installed by an attacker.
### 8.1 RDP
Read-out Protection (RDP) prevents reading of the following areas:
- Main flash memory.
- Backup registers in the Real-Time Clock (RTC).
- SRAM4.
- Option bytes (Level 2 only).
RDP has three levels:
- **RDP level 0** means this protection is turned off.
- **RDP level 1** means this protection is turned on but can be reversed by setting the option bytes, although it will also erase all of the flash in the process.
- **RDP level 2** means this protection is turned on, and it cannot be turned off. ___**RDP level 2 also prevents all JTAG access, which completely eliminates an entire category of attack vectors.**___
During Passport development, we typically run with RDP at level 0 unless we are testing the security, in which case, we set it to RDP level 1. However, for production, it is set to RDP level 2. As part of the provisioning process, the RDP level is set to 2, and then the circuit board immediately loses connection with the JTAG interface used to provision each Passport.
### 8.2 MPU
The Memory Protection Unit (MPU) is used to restrict access to various regions of flash and RAM from reading, writing, and/or execution. For Passport, since MicroPython runs in privileged mode, the main thing is to mark all RAM regions as non-executable:
* AXI SRAM
* SRAM1, SRAM2, SRAM3 and SRAM4
* ITCM
* DTCM
* Backup memory
NOTE: Since no unsigned code can be loaded onto the device, these features are not strictly necessary, but provide additional defense-in-depth.
## 9. Secure Element Slot Configuration
Passport uses the ATECC608A Secure Element chip, which contains 16 slots that can be configured in various ways. Reading from and writing to some of the slots in Passport is configured so that it requires first proving knowledge of the value in another slot.
For example, in order to update the Last Login Counter or the PIN itself, you must prove that you know the PIN. Other slots are completely unreadable but can be used internally by the Secure Element in combination with some MAC (Message Authentication Code) checks that are frequently performed.
Figure 1 - ATECC608A Secure Element Slot Configuration
Figure 2 - Passport Validation Page