Display vs. No-Display

Displays on hardware wallets serve a critical function in ensuring that what the user sees is what they intend to authorize. The presence of a display allows the user to verify transaction details directly on the device, mitigating the risk of man-in-the-middle (MITM) attacks. In contrast, hardware wallets without displays rely on external devices, such as computers or smartphones, to display transaction information, which can be compromised.

With Display: Hardware wallets with displays are designed to reduce the attack surface for Man-in-the-Middle (MITM) attacks. Since the transaction details are shown directly on the device, the user can verify the information before authorizing it. If the displayed information matches the expected transaction, the user can proceed confidently.

Without Display: For wallets without displays, the risk is significantly higher. Since transaction details are displayed on potentially compromised external devices, an attacker can intercept and alter the transaction data, leading the user to authorize a transaction they did not intend.

Firmware Updates

Firmware updates are a critical aspect of maintaining the security and functionality of hardware wallets. However, the method of performing these updates introduces varying degrees of security risks. In this chapter, we will explore the security considerations associated with different firmware update methods: via USB, Bluetooth, and microSD.

Firmware Update via USB Overview: Updating firmware via USB is one of the most common methods for hardware wallets. This process typically involves connecting the hardware wallet to a computer via a USB cable and running an update utility provided by the wallet manufacturer.

Physical Security: USB connections require physical access to the hardware wallet, reducing the risk of remote attacks. However, the downside is that if an attacker gains physical access to your device, they could potentially compromise it during the update process.

Malware Risks: The connected computer could be compromised with malware designed to intercept or modify the firmware during the update. To mitigate this risk, it’s crucial to ensure that the update is performed on a trusted, secure device and that the firmware file is verified using cryptographic signatures provided by the manufacturer.

Man-in-the-Middle (MitM) Attacks: If the firmware update is downloaded from the internet, there is a potential risk of MitM attacks where an attacker could intercept and replace the firmware with a malicious version. Strong cryptographic verification of the firmware before installation is essential to prevent this.

Power Integrity: During the update process, any interruption in power supply (such as disconnecting the USB cable) could lead to a failed update, potentially bricking the hardware wallet. Therefore, it’s recommended to ensure a stable power connection throughout the update.

Firmware Update via Bluetooth Overview: Bluetooth firmware updates provide a wireless alternative, offering convenience but introducing additional security challenges. This method is typically used with mobile devices and requires a secure pairing process.

Wireless Vulnerabilities: Bluetooth inherently introduces wireless attack vectors, including eavesdropping, unauthorized access, and signal interference. The update process must ensure secure pairing and data encryption to protect against these threats.

Proximity Attacks: Bluetooth updates require the hardware wallet to be in close proximity to the device initiating the update. While this reduces the likelihood of remote attacks, it opens up potential for proximity-based attacks where an attacker could exploit vulnerabilities in the Bluetooth protocol.

Pairing Security: Ensuring that the Bluetooth connection is securely paired is critical. Pairing should be done in a secure environment to prevent unauthorized devices from connecting to the hardware wallet.

Firmware Authenticity: As with USB updates, the firmware must be cryptographically verified before installation. However, the wireless nature of Bluetooth increases the importance of this verification due to the higher risk of data interception or manipulation during transmission.

Battery Considerations: Unlike USB updates, which often power the device during the process, Bluetooth updates rely on the hardware wallet’s battery. If the battery depletes during the update, it could result in an incomplete or corrupted installation, potentially rendering the wallet inoperable.

Firmware Update via microSD Overview: Firmware updates via microSD involve transferring the update file onto a microSD card, which is then inserted into the hardware wallet. The device reads the firmware from the card and updates itself accordingly.

Physical Security: Similar to USB updates, microSD updates require physical access to the hardware wallet. However, there’s an added layer of physical security, as the microSD card is a separate, removable medium that can be stored securely until needed.

Firmware Integrity: The microSD card must be obtained from a trusted source to ensure it is free from tampering. Additionally, the firmware file on the card should be cryptographically signed and verified by the hardware wallet before installation.

Malware on the microSD: There is a risk that the microSD card could be compromised if it is inserted into an infected device before being used for the firmware update. To mitigate this, the card should be formatted and used exclusively for the update process.

Update Stability: microSD updates tend to be more stable than wireless methods, as they are less susceptible to power interruptions or signal issues. However, care should be taken to ensure that the card is fully inserted and the device is powered on properly to avoid update failures.

Data Persistence: Unlike USB or Bluetooth updates, where the firmware is transmitted and then executed, microSD cards allow for persistent storage of the firmware file. This can be advantageous for archival purposes but also requires that the card be securely stored to prevent unauthorized access or tampering.

Secure Elements

A secure element (SE) is a tamper-resistant hardware component designed to securely store sensitive information, such as cryptographic keys, and perform cryptographic operations in isolation from the rest of the device. SEs are often used in smartphones, credit cards, and hardware wallets to protect against physical and digital attacks.

The primary advantage of a secure element is its ability to resist tampering and unauthorized access, making it a critical feature for hardware wallets that aim to protect private keys and seed phrases from extraction, even in the event of a physical breach.

Security Considerations of Using a Secure Element Tamper Resistance: Secure elements are designed with multiple layers of protection, including physical barriers, shielding, and sensors that detect tampering attempts. If a tamper attempt is detected, the SE can erase its contents, rendering any extracted information useless.

Isolation: By isolating cryptographic operations within the secure element, the wallet reduces the attack surface. This isolation ensures that even if the main processor of the wallet is compromised, the private keys stored within the SE remain secure.

Attestation: Many secure elements support attestation, a process by which the SE can prove its integrity to the device or an external party. This feature adds an additional layer of security, ensuring that the secure element has not been tampered with or replaced with a malicious component.

Supply Chain Security: One of the concerns with secure elements is the potential for supply chain attacks. If the SE is compromised during manufacturing or distribution, it could undermine the security of the entire wallet. Therefore, the provenance and integrity of the SE are crucial considerations.

Security Considerations of No Secure Element Hardware wallets without a secure element rely on the general hardware and software of the device to protect the seed phrase and private keys. While these wallets may lack the specialized security features of an SE, they can still provide robust security if designed correctly.

Passphrase Protection: One of the most effective strategies for securing a seed phrase without a secure element is the use of a passphrase. In this approach, the seed phrase is encrypted with a user-defined passphrase, which must be entered each time the wallet is accessed. This method ensures that even if an attacker physically accesses the device and extracts the seed phrase, they would still need the passphrase to generate the valid seed.

Software Hardening: Without a secure element, the wallet’s software becomes the primary line of defense. Techniques such as secure boot, code signing, and memory encryption can be employed to protect the wallet from software-based attacks. Regular firmware updates are also essential to patch vulnerabilities and improve security.

Tamper Evident Design: While lacking the advanced tamper resistance of a secure element, wallets without SEs can still be designed to be tamper-evident. For example, the device casing can be designed to show clear signs of physical intrusion, alerting the user to potential tampering.

Attack Surface: Without the isolation provided by a secure element, the attack surface of the wallet is broader. An attacker could potentially exploit vulnerabilities in the wallet’s operating system or hardware to extract sensitive information. Therefore, the overall security architecture must be carefully designed to minimize these risks.

Passphrase as a Secure Element Alternative In wallets without a secure element, the passphrase can serve as an alternative security layer. Here’s how it works:

One-way Cryptography: The wallet generates a seed phrase during initialization and then uses the passphrase and a one-way cryptographic function to generate the private keys. The passphrase is not stored on the device, making it impossible to access the seed phrase without it.

Protection Against Physical Attacks: If an attacker gains physical access to the wallet and attempts to extract the seed phrase from memory or storage, they would still be unable to find the passphrase. Without the passphrase, the extracted data would be useless.

User Responsibility: The security of this approach hinges on the user’s ability to remember or securely store the passphrase. If the passphrase is lost, the seed phrase cannot be recovered, resulting in the loss of access to the associated assets.

Operating Systems

While general-purpose operating systems like Linux offer flexibility, versatility, and widespread adoption, they inherently lack the specialized focus required to provide ironclad security for private keys. In contrast, a custom operating system, purpose-built to secure these critical cryptographic assets, offers a security model that is inherently more robust.

The Nature of General-Purpose Operating Systems General-purpose operating systems like Linux are designed to handle a wide range of tasks, from running web servers to managing complex databases, and even powering desktop environments. Their architecture is versatile by design, enabling them to accommodate a broad spectrum of applications. However, this flexibility comes at a cost—namely, security trade-offs.

Linux, for example, is built to support a multitude of users, applications, and hardware configurations. It needs to be adaptable, which often leads to a larger attack surface. The OS must balance usability with security, allowing for dynamic software installations, third-party applications, and system updates. These features, while beneficial for general computing, introduce vulnerabilities that can be exploited by attackers.

Moreover, general-purpose operating systems are subject to frequent updates, patches, and modifications. While these updates are essential for fixing bugs and vulnerabilities, they also present opportunities for introducing new security flaws. The reliance on a broad community of developers, each contributing to different parts of the OS, further complicates the security landscape. The result is an operating system that, while powerful and versatile, is not optimized for the singular task of securing private keys.

The Security Focus of Custom Operating Systems A custom operating system designed specifically for securing private keys operates under an entirely different paradigm. Unlike general-purpose OSs, a custom OS is purpose-built with a singular focus—security. This focused approach allows developers to design an architecture that minimizes vulnerabilities and maximizes the protection of private keys.

1. Minimal Attack Surface: A custom OS designed for private key security is stripped of unnecessary features and services. By reducing the number of running processes and eliminating non-essential functionalities, the OS significantly decreases its attack surface. With fewer entry points for potential attackers, the system becomes inherently more secure.

2. Controlled Update Mechanisms: Custom operating systems can implement stringent control over software updates, ensuring that only thoroughly vetted and cryptographically signed updates are applied. This eliminates the risk of introducing vulnerabilities through untrusted updates or third-party software. The update process itself can be designed to be secure, utilizing methods such as air-gapped environments or secure boot mechanisms that verify the integrity of the OS at every startup.

3. Hardware Integration: A custom OS can be tightly integrated with specialized hardware designed for cryptographic operations. For example, secure elements or hardware security modules (HSMs) can be utilized to perform cryptographic operations in a tamper-resistant environment. The OS can be designed to offload critical operations to these secure hardware components, further isolating private keys from potential software-based attacks.

4. Tailored Security Protocols: Custom OSs can employ specialized security protocols that are specifically designed for managing and securing private keys. These protocols can include features such as multi-factor authentication, biometric verification, and hardware-backed encryption. The OS can enforce strict access controls and audit trails, ensuring that every access to a private key is logged and monitored.

5. Predictability and Isolation: In a custom OS, predictability is key. The environment is designed to be as static and unchanging as possible, reducing the likelihood of unexpected behavior or vulnerabilities. Isolation mechanisms can be employed to separate critical processes from the rest of the system, ensuring that even if one part of the OS is compromised, the private keys remain secure.