Recap

In the first part of our 'Saga of Saga' series, we initiated a discussion on the concept of true vulnerabilities, setting the stage for a deeper analysis. Now, in Part 2, we'll delve further into Saga's robust security design and implementation, appreciating its resilience even in the face of potential bootloader vulnerabilities. 

Security Hurdles in Mobile Crypto Wallets

Let's now navigate the technical maze of Saga. We find that Saga is built upon the Android Open Source Project (AOSP). It's almost a mirror image of your regular Android devices, with two notable features: the dApp Store and the Seed Vault. The dApp Store serves as the gateway to the vast ecosystem of Solana (a wonderland we might explore in future blogs), while the Seed Vault significantly boosts the device's security level.  

Incorporating the Seed Vault: A Look at System Settings 

The Seed Vault, listed first in the System Settings, is designed to support the creation and management of your crypto wallet's seed. But it's far more than just a system-level application; it's your gateway to a more secure trusted zone. 

Untrusted Apps: No Access to Trusted Computing 

You might wonder, what sets the Seed Vault apart from the standard crypto wallet on Android? Recall our recent discussion about the Trusted Computing Base (TCB)? Unfortunately, almost all mobile wallets fail to fully adhere to the TCB design principle.  

Some simply have no understanding of trusted computing. They might even store passwords and secret keys in plaintext. Others find themselves limited by the capabilities of the underlying operating system. Take Apple, for instance. While it does possess a Secure Enclave Processor (SEP) on iOS for handling cryptographic operations on sensitive data, it's exclusively used by its native apps. An unofficial app does not enjoy the luxury of utilizing the SEP on its own will. 

On Android devices, you could leverage the Hardware-backed Keystore API to do crypto related operations, so that the secret keys never leave the Trusted Execution Environment (TEE). 

Solana utilizes ed25519, an elliptic curve designed for use with EdDSA. This was recently included in FIPS 186-5, the Digital Signature Standard (DSS) issued by National Institute of Standards and Technology (NIST), as of February 2023. Notably, ed25519 is supported in the Hardware-backed Keystone on Android. 

However, just because ed25519 is supported in the Android framework does not automatically give you the ability to use EdDSA. It's up to the vendor of the underlying chipset to decide whether to implement the corresponding cryptographic operations. Surprisingly, even the Google Tensor chipset that comes with the Google Pixel 6 doesn't provide support for EdDSA yet. 

Considering the significant fragmentation among Android vendors, it's unwise for a mobile wallet app to solely depend on hardware-backed features. 

Crypto Compatibilities of Crypto Currencies 

In fact, most apps are unable to leverage the Hardware-backed Keystore for signing purposes; their use is largely confined to secure private key storage! This is because major cryptocurrencies, such as BTC and ETH, are intentionally designed to be incompatible with certain standard encryption protocols. 

The signing algorithm implemented on iOS and Android devices is ECDSA-secp256r1, also known as NIST P-256, which is recommended by the NIST. Worries regarding the NSA’s potential to crack the crypto system have been present since cryptocurrencies were first created. As a result, BTC and ETH deliberately use an alternative signing algorithm, ECDSA-secp256k1. However, this "mitigation" forces mobile apps to extract the credentials from the TEE and operate within a less secure environment. 

The threats present in an insecure computing environment aren't solely from malicious attackers; they can also originate from careless or misbehaving wallet developers. The Slope Wallet Sentry Vulnerability serves as an example of this, having occurred within a Solana mobile wallet. In this case, the seed phrases for users' private keys, stored in plaintext, were unintentionally transmitted to a centralized server without encryption. Thousands of wallets were compromised, and millions of funds were stolen due to the exposed credentials. 

Securing the Unsecure: The Potential of Seed Vault 

Seed Vault implements centralized, mandatory access control for users' credentials. Rather than dealing with the keys directly, the wallet must make requests to the Seed Vault to sign any transactions. This approach significantly reduces the attack surface within mobile wallet applications. 

At present, the Seed Vault exclusively supports Solana, but it has the potential to resolve compatibility issues associated with ECDSA signing algorithms for other crypto currencies. They could integrate any wallet-specific cryptographic operations within a Trusted Applet (TA), leveraging the crypto API made available by Qualcomm Secure Execution Environment (QSEE). As the vendor of Saga, they are both privileged and obligated to provide the most secure solutions. 

Another significant yet often overlooked risk within the mobile system is that the wallet app could suffer from a UI forgery attack. A malicious app could draw another layer of graphics over the wallet app, presenting fraudulent transaction confirmations or signature requests. This could lead to user interactions being misdirected or intercepted. The ultimate solution to this issue is using a Trusted UI, directly provided by the TEE. Once again, this calls for the vendor's privilege. 

 There are many tasks that vendors can and should do. What have they done for Saga? To understand this, we need to explore the security-related system design principles of Android. 

Exploring Android's Normal World

Android devices operate on various privilege levels with a range of programs:  

User Space Programs (EL-0)

These are the most common applications on your device. They fall into four categories:  

1. Untrusted Apps: Installed or downloaded from the dApp Store, these apps are typically not considered trustworthy. For example, dAppStore and Solflare are two such apps. 
2. Preinstalled Apps: Preinstalled on the Android ROM, these apps may be vendor-certified but should not possess extra privileges. SeedVaultManager and SolanaSettings are examples of this category. 
3. System Apps: Builtin apps on vanilla Android, or selected by the vendor, these apps have elevated permissions and control sensitive system settings. WalletProvider and SeedVaultServiceApp are examples of system apps. 
4. System/Vendor Services: Different from the apps, these services interact with Android's binder IPC mechanism, offering key functionalities and operating within restricted sandboxes. For example, vendor.osom.seedvault-service and vendor.qti.hardware.trustedui are two such services.  

Kernel (EL-1) 

The Android kernel manages these user space programs. Gaining kernel privilege can allow access to lower execution levels and the ability to perform sensitive actions, such as spying on phone calls and stealing your bitcoins.  

Hypervisor (EL-2) 

Qualcomm operates a hypervisor at EL-2, with the Android system as a monitored virtual machine. More virtual machines can be launched via an agent service on Android, found at /product/etc/init/qvirtmgr.rc. 

# Qualcomm Virtualization Manager 
service vendor.qvirtmgr /product/bin/qvirtmgr 
    class late_start 
    user root 
    group root 
    disabled 
    oneshot

Trusted VM (EL-1) 

This service loads configurations from /product/etc/qvirtmgr.json. 

{ 
	"qvirtmgr" : { 
		"major_number": 1, 
			"minor_number": 0, 
			"vm_config" : [ 
			{ 
				"name"          : "trustedvm", 
				"loader_type"   : "secured", 
				"restart_level" : "relative", 
				"try_count"     : 3, 
				"boot_wait_time": 2, 
				"boot_ops"      : "start", 
				"disk" : [ 
				{ "image"   : "/vendor/vm-system/trustedvm/system.img", "label" : 11 } 
				], 
				"enable"        : true, 
				"legacy"        : true 
			}, 
			{ 
				"name"          : "cpusys_vm", 
				"loader_type"   : "secured", 
				"restart_level" : "relative", 
				"boot_wait_time": 2, 
				"boot_ops"      : "start", 
				"enable"        : true, 
				"legacy"        : true 
			} 
		] 
	} 
}

We can see a virtual machine – "trustedvm" – booting with a customized system image from /vendor/vm-system/trustedvm/system.img. This image is independent of the Android system image, and its execution is isolated from the Android world. An attacker with Android kernel privilege can't infiltrate the running trustedvm directly. 

The trustedvm is dedicated to third-party programs by the vendor and for interaction functionality for the trusted UI. We found a program "tvmapploader" handling service requests from the normal world and delegating operations to the trusted apps inside the secure world. 

Note that you don't need any vulnerability to gain kernel privilege on Android. If your device supports unlocking, you can flash your customized boot image onto your device, as we discussed in the previous blog. 

However, communication from the normal world to the secure world is bridged through the trustedvm, making direct communication with the secure world challenging, you'll need another system image to interfere with the trustedvm. This is likely why hackers don't directly attack the Seed Vault and demonstrate on a BTC wallet instead.  

Despite all these measures, all parts of the normal world can be tampered with, potentially even in a fully patched Saga, if it's unlocked. So, the question is, If an attacker manages to gain root privilege through a backdoor on your phone, does this put the Seed Vault at risk? Let's investigate the design of Saga's secure world to find out. 

Demystifying the Seed Vault in the Secure World

The trusted applications, seedvault.mbn and argon2kdf.mbn, are in the directory /vendor/firmware_mnt/image/, and they play crucial roles in Seed Vault's operations. (This research was conducted on the first released version of Solana's Saga smartphone, originally released as TKQ1.221220.242 in April 2023.) 

These files are 64-bit arm64 ELF shared objects, stripped and unencrypted. This allows us to understand their low-level operations through reverse engineering. 

Decoding the Secure Storage

The file seedvault.mbn is the core component of Seed Vault's secure storage system. It provides several interfaces: 

1.  SeedVault_generateSeedIndices     
2.  SeedVault_importSeedIndices     
3.  SeedVault_wipeSeed     
4.  SeedVault_signTransaction    
5.  SeedVault_authPublicKeys    
6.  SeedVault_changeSeedPassword     
7.  SeedVault_retrieveSeedIndices     
8.  SeedVault_verifyPassword     
9.  SeedVault_recoverSeed    
10.  SeedVault_enableBiometric     
11.  SeedVault_disableBiometric    
12.  SeedVault_getAttemptsLeft    
13.  SeedVault_getSeedInfo     
14.  SeedVault_getSeedSalt 

These functions are straightforward and properly implemented. 

Sensitive data is stored within the secure file system (sfs) provided by QSEE. The system can support up to 8 different seed vaults. The relationship between seeds and users is maintained in the /seedvault_info file. This file is structured as follows: 

struct seedvault_info {
	struct {
		uint64_t seed_id;
		uint32_t user_id;
		uint8_t flags;
	} vaults[8];
};

Each seed is identified by a unique seed_id and is stored in a file named /seedvault_${seed_id}. The seed file is structured as follows:  

struct seed {
	uint32_t version;
	uint64_t seed_id;
	uint32_t user_id;
	uint8_t seed_salt[32];
	uint8_t seed_key_nonce[12];
	uint8_t seed_key_enc[32];
	uint8_t seed_key_tag[16];
	uint8_t salt[32];
	uint8_t sha256_recovery_seed[32];
	uint8_t seed_nonce[12];
	uint8_t seed_enc[113];
	uint8_t seed_tag[16];
	uint8_t remaining_attempts;
};

Limited Attempts Stop Guessing Attacks

The seed never leaves the Trust Zone, and all operations related to the seed are executed within it. It's important to note that the seed is not stored in plain text, but instead, it's encrypted and always requires the correct password to access. Biometric authentication methods do not function until the seed is successfully accessed for the first time with the correct password.  

If the password is unknown, there are only 10 attempts allowed to guess it. This is controlled by the remaining_attempts field in the securely stored seed. After 10 unsuccessful attempts, the seed is erased, your vault is gone forever! 

The seedvault.mbn communicates exclusively with the trustedvm, which receives input passwords through a trusted UI. It's as if, during this process, the display and touchscreen are unplugged from the Android and reconnect to an invisible device. Therefore, even without explicit limitations, malicious programs cannot automate password guessing. Importantly, this process remains secure even in the face of a root privilege attack on the Android system, because the attacker cannot interfere with or simulate the interaction during the use of the trusted UI.   

Infeasibility of Offline Seed Cracking

You may propose the following: could I not simply extract the seedvault files from the secure file system, potentially exploiting a vulnerability, and then brute force the password to recover the seed? 

While theoretically possible, this approach comes with significant challenges. The seed is used, and its authenticity verified in two cases: 

1. Decrypting with the correct password. 
2. Recovering with known mnemonic phrases. 

In the first case, the client in the Normal World, whether compromised or not, is required to employ a specialized algorithm to derive a tz_password, combining the guessed user password with a seed_salt that is queried from seedvault.mbn. 

Remember trusted app argon2kdf.mbn? argon2 is a key derivation function designed to resist GPU cracking attacks (argon2i) or side-channel attacks (argon2d). The Seed Vault password uses the hybrid version argon2id with enhanced parameters (iterations=8, memory size = 256KB), significantly amplifying the difficulty of brute-force attacks.  

The second scenario is less likely to be attacked. It’s a mechanism to whether a newly recovered seed from the mnemonic phrases corresponds to the old one. The plaintext of the original seed is never stored in the file system. Instead, the SHA-256 hash of the initial seed, combined with a random 32-byte salt, is preserved. The validation can only be passed if you are aware of the true mnemonic phrase! 

In conclusion, it’s just impossible to hack your seed vault if you use a strong password! This remains true even if your phone is physically hacked via a true bootloader vulnerability! 

Conclusion

The crypto community has witnessed the emergence of numerous wallets, yet what truly matters is a wallet that can be implicitly trusted while remaining uncompromised. Through trust computing isolation and fortified key storage, Saga has set a high benchmark for mobile cryptocurrency security. While no system is completely invulnerable, Saga's approach has drastically minimized potential points of attack.  

As we continue to delve into this rapidly evolving landscape, our focus remains on identifying potential vulnerabilities and enhancing security. It is our hope that more wallet providers will rise to the challenge, offering innovative solutions that match, if not exceed, the trustworthiness and safety Saga has showcased. 🫡 

About Offside Labs

Offside Labs is a professional team specializing in security research and vulnerability detection. Our primary focus includes rigorous bug hunting, comprehensive audits, and expert security consultation. We have extensive experience in the web3 environment and strive to enhance the security posture of our client's projects in this rapidly evolving digital space. 

References

1. https://offside.io/blog/saga-of-saga-part-1-unlocking-the-debate-on-true-vulnerabilities  
2. https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/keystore/java/android/security/keystore2/AndroidKeyStoreKeyPairGeneratorSpi.java;l=147-153 
3. Securing Web3 Mobile Wallets with TEE: Delving into the Security Guarantees and Real-world Implementation Pitfalls, Yuan Zhuang @ Certik, MOSEC 2023 
4. https://www.qualcomm.com/content/dam/qcomm-martech/dm-assets/documents/How-5G-is-enabling-resilient-communication.pdf 
5. https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#argon2id 
6. https://slope-finance.medium.com/slope-wallet-sentry-vulnerability-digital-forensics-and-incident-response-report-d7a5904e5a39
7. https://csrc.nist.gov/pubs/fips/186-5/final