Kraken Security Labs, our expert team of security researchers, identified vulnerabilities within the Safepal S1 hardware wallet. While we were not able to steal cryptocurrency from the wallet, we demonstrate certain weaknesses that may make future compromise possible.
At Kraken, we try to discover attacks before they happen. Upon discovery, we disclosed the full details of these vulnerabilities to the Safepal team on November 18, 2020.
Improving the security of technologies we all enjoy is an important process to grow the digital asset industry and believe that awareness and education are a vital component of that mission.
Ineffective Tamper Detection
Our testing found Safepal’s tamper detection to be, at best, ineffective. According to the Safepal documentation: “Inside S1 there is embedded with self-destroy and data-erasing mechanisms. Once there is any software or physical attack detected by multiple sensors, the wallet will initiate a self-defence mechanism, the self-destruction mechanism will erase the private key and all wallet data, keeping the hacker from getting sensitive data, keeping your asset from wrong hands.” We found that the device would stop booting when we took it apart but that we could re-enable the device by re-attaching a single pin and that the device’s contents were not erased. Further testing and communication with Safepal revealed that the wallet will erase data only when (a) the device is powered on and (b) when the single pin previously mentioned is disconnected for longer than 10 seconds. In a theft, it seems unlikely that a motivated attacker would trip this alarm.
Open Source Licensing Violations
The wallet contains the GPLv2 licensed U-Boot and Linux Kernel. The use of these GPL-licensed components requires Safepal to distribute the source code for their product so that users can inspect and modify the code running on the user’s device. We requested the source code from Safepal but they refused to provide it, which means that Safepal is violating GPL licensing. Violations like this have resulted in litigation and we have urged Safepal to disclose their source code. Safepal released firmware V1.0.24 at https://www.safepal.io/upgrade to fix this issue.
Downgrade Attack
We used a flash programmer to flash back a previous firmware, which was not detected by the device. Preventing an attacker from downgrading the firmware to an earlier version is essential to ensuring security, as it prevents downgrading to, for example, a vulnerable version of a firmware.
Further Research
Furthermore, we determined that the highly-modified version of U-Boot, which can typically only support secure boot through “FIT images” or the SoC’s proprietary secure boot process, was encrypted and obfuscated. We present some findings regarding U-Boot but we time-limited our review due to the obfuscation. In our experience, the application processors that communicate to the secure element are consistently the weak-point in cryptocurrency hardware wallets, and the SafePal S1 is no different. It appears as if Safepal either developed or re-used significant obfuscation techniques in their product, which was effective in slowing down our research, but it is not clear, due to this obfuscation and lack of transparency of their GPL source code, if the SafePal S1 truly has a validated secure-boot chain or not.
We appreciate Safepal responding to these concerns. We encourage you to review their response at https://blog.safepal.io/our-response-to-the-security-findings-from-kraken-security-labs.
The SafePal S1 is a cryptocurrency hardware wallet that runs embedded Linux with a system on a chip (SoC). As a result, the architecture of this wallet is different from the microcontroller-based ones that are most popular (e.g., Trezor and Ledger wallets). The challenge in securing any embedded Linux-based system is how to secure the boot process as most, but not all, Linux capable micro-processors require external flash storage and external RAM. Additionally, while Linux may be one of the most extensively used operating systems, it does not ship in a secure state, which requires Safepal to either buy a solution or add hardening themselves.
High-level hardware analysis
The hardware of the SafePal is significantly different from other common wallets such as the Ledger Nano S/X or the Trezor One/T: Both are based on microcontrollers, but the SafePal is based on a full System-on-a-Chip running Linux. We tested the S1P_Ver03 hardware revision.
The main processor of the device is marked as “SafePal S1”, however the underlying processor is most likely an Allwinner processor. This was determined by matching the pin-out of the Safepal S1 (in pin-out) to the Allwinner i3 processor ( https://dn.odroid.com/obsolete/Allwinner_i3_Datasheet_V1.0.pdf ). Most notably, this processor does not have any integrated flash, instead the device boots off an external flash chip, a Zbit Semiconductor ZB25VQ64. Additionally, a second SOIC-8 chip is on the board, which is assumed to be the secure element. Unfortunately, we could not discover the vendor from the chip marking.
The processor of the SafePal: SafePal S1 IDC80X1E – an Allwinner chip.
Finding 1: Tamper Detection Bypass
According to the Safepal documentation: “Inside S1 there is embedded with self-destroy and data-erasing mechanisms. Once there is any software or physical attack detected by multiple sensors, the wallet will initiate a self-defence mechanism, the self-destruction mechanism will erase the private key and all wallet data, keeping the hacker from getting sensitive data, keeping your asset from wrong hands.”
The tamper detection system was analyzed in multiple steps:
Case opening
First, it was tested whether opening the SafePal wallet, both using destructive and non-destructive methods, would cause a tamper event. Opening the case of the S1 did not cause a tamper event or stop the S1 from working.
Removal of RF shielding
The SafePal processor, flash, secure element and PMIC are shielded by an RF can. The RF can is held in place using multiple clips around the can, and not fully soldered down. This makes non-destructive removal very easy, using a small flat-head screwdriver. Removal of the RF can lead to the device not booting successfully anymore. By performing measurements, it was determined that the upper-right RF can clip was not connected to ground like the other clips. By re-connecting the clip to ground, using a .4 mm piece of wire to connect the clip to an exposed ground-pad next to it, the tamper-event could be silenced, and the SafePal wallet was working again. Notably, no reset of the device took place, and the old credentials (PIN etc) stayed valid.
No other tamper-detection measures could be found.
Potting
Both the flash chip and the secure element were potted using an unknown compound. However, heating it with a heat gun made the potting compound brittle. The compound could then be scraped away using a small flat-head screwdriver, without breaking any component of the device. This allows direct access to the SPI pins for further probing.
Flash dumping
After establishing the type of flash chip by reading the marking, an attempt was made to dump the flash in-system using flashrom. As the chip was not supported by flashrom at the time of this writing, custom support had to be implemented in flashrom. This allowed gathering a full flash dump.
During further analysis, it was determined that the first 0x8000 or so bytes of the flash are set to read-only using the OTP security functions of the flash chip, while the rest of the flash chip is both readable and writable.
Flash content analysis
Starting at the 5th byte of the flash memory, the string “eGON.BT0” could be found. Further research revealed this to be a common header for an early-stage bootloader on Allwinner based devices: https://linux-sunxi.org/EGON
Finding 2: GPL Violations
Starting at address 0x40000, an Android boot-image, including a Linux kernel, was found, indicating that the device runs Linux. Given that no GPL notice was given or found, this indicates a GPL violation. Further requests directly to SafePal did not yield any results.
At address 0x2A0000, a SquashFS filesystem was found, and extracting it revealed a full Linux root filesystem, including again, multiple GPL licensed tools.
At address 0x740000, a JFFS2 filesystem was identified, containing configuration data including transaction addresses within a sqlite3 database.
Additionally, a JPEG boot logo image and the shutdown logo JPEG image were found.
Flash modification attempts
Multiple attempts were made at modifying the contents of the flash chip:
It was determined that the Linux kernel, the SquashFS filesystem, and the boot logo were modifiable. However, a modification led to the device refusing to boot.
The contents of the JFFS2 filesystem and the shutdown logo were modifiable without making the device unbootable, however changes to the shutdown logo were not reflected on actual shutdown.
Modification of the first stage bootloader was not possible because of the aforementioned security bits set in the flash chip.
Flash rework
It is likely possible to gain code execution on the device by replacing the main flash chip. As the contents stay identical, this is not detectable by the device. To gain code execution, multiple checks have to be reverse engineered and deobfuscated. While possible, this is especially time consuming, especially given the complexity of the U-Boot obfuscation chain, and was therefore not done as part of this audit.
Firmware upgrade
The firmware upgrade process contained in the wallet_update binary was analyzed and reverse engineered. Firmware upgrades can be downloaded from the SafePal website after entering a serial number, however it was determined that the firmware update is identical for identical hardware revisions, and so no personalization of the upgrade takes place. All devices were received with firmware version v.1.0.17, which was latest at the time. The firmware upgrade can be found at https://www.safepal.io/fw/S1F/v1.0.17/upgrade.bin
It was also found that the firmware upgrade is encrypted, and modifications to the firmware binary cause the upgrade process to fail.
During analysis of the wallet_update binary it was found that the binary is obfuscated using a lot of XOR-ed data. By binary patching wallet_update it was possible to run it in qemu-user-mode, allowing decryption of the firmware upgrade on a regular system.
It was also found that the firmware upgrade, after successful decryption, performs what is assumed to be an ECDSA signature check on the firmware. The implementation looks very similar to trezor-crypto, however no acknowledgement (required by trezor-crypto’s license) could be found, so this could not be fully validated.
Finding 3: Downgrade attack
Preventing an attacker from downgrading the firmware to an earlier version is essential to ensuring security, as it prevents downgrading to, for example, a vulnerable version of a firmware.
During this audit, v1.0.18 of the SafePal Firmware was released. A wallet was upgraded to that firmware, booted and tested. After verifying the firmware upgrade was successful, a flash programmer was used to flash back the previous v1.0.17 firmware. This downgrade left the device fully functional, the downgrade was not detected by the firmware and the wallet kept working regularly, indicating vulnerability to downgrade attacks.
Boot process
First stage bootloader
Most Allwinner devices use U-Boot as a second stage bootloader, however U-Boot could not be found on the flash-system. Instead, references to “XBOOT” and “XTAB” were found in the flash, though this did not match any known bootloader such as https://github.com/xboot/xboot.
Given that the device runs Linux and that the boot configuration needs to occur somewhere, the first stage bootloader was reverse engineered using Ghidra. It was found that this first stage bootloader uses a lot of obfuscation for obfuscating strings and key material, and eventually it was found that the first stage bootloader decrypts a second stage bootloader. To understand the decryption and validation of this second stage bootloader, the entire bootloader was emulated using the Unicorn Engine emulator, allowing full decryption of the second-stage bootloader. The first-stage bootloader was also found to validate an ECDSA signature of the second stage bootloader.
Second state bootloader
A quick analysis of the second-stage bootloader immediately revealed that it’s a modified U-Boot bootloader. Given that U-Boot is licensed under the GNU Public License and no GPL notice or source-code could be found, this constitutes a GPL violation.
It was found that U-Boot was modified with certain obfuscations and decryption methods.
Application analysis
Two binaries, ‘wallet’ and ‘wallet_update’ were recovered from the extracted squashfs filesystem. wallet is the main wallet application, while wallet_update implements the firmware upgrade process.
A time-of-check to time-of-use (TOCTTOU) issue was found in the firmware upgrade check of the wallet binary. However, the wallet_update functionality performs a second check that could not be bypassed. Also, a third check is performed on each boot which fails even on bypassing the software locks.
Configuration & database analysis
On the JFFS2 filesystem are two configuration files: wallet.cfg and wallet.db.
Wallet.cfg contains configuration items such as whether the wallet was already set up, and the wallet name. It was found that this configuration can be freely changed, allowing an attacker to modify configuration items such as the wallet name freely.
The wallet.db is a sqlite3-based database, containing information on the transactions, configured coins, and addresses on the wallet. Modifying the database leads to the wallet-application not working (the SafePal will only show a black screen). It is unclear whether this is because of a SQLite incompatibility (the version used on the wallet is 3.7.11 from 2012) or because of an additional unknown protection.
Database analysis
As the database contains private information (addresses & transactions), an attempt was made to recover addresses from the device. By analyzing the wallet binary it was found that the addresses stored in the database are encrypted using AES, with the key being derived from various static sources as well as from what is presumed to be secure-element input.
Certain modifications also lead to the device requesting the user to re-setup the wallet, however re-flashing the device with an unmodified flash-image restored full wallet operation. This can indicate an inefficient tamper detection & response methods.
