ZenGo is a secure cryptocurrency wallet that uses multi-party computation (MPC) technology. CertiK's SkyFall team conducted a thorough review of many mobile wallets and found that ZenGo's MPC solution provides stronger security defenses than regular mobile wallets. In particular, ZenGo's wallet can defend against direct attacks from privileged attackers, such as those who leverage zero-day vulnerabilities or advanced malware to gain root access on user devices, especially for high profile wallet users. This is an emerging threat for wallet developers to take into consideration.

However, defending against privileged attackers is challenging. Our review presents a new attack vector that is orthogonal to the MPC method in ZenGo. We reported the security issue and ZenGo made a prompt response to fix this issue. We are pleased that ZenGo took our concerns seriously, acknowledged and actively addressed the issue in a timely manner. In this blog, we will delve into the technical details of our finding and discuss how we work with ZenGo to improve the overall security of MPC wallets. Based on our thorough review of ZenGo's security design and their professional response to the identified issue, we firmly consider ZenGo to be a highly secure consumer wallet solution on the market today.

What is MPC?

Multi-party computation (MPC), sometimes also referred to as secure multi-party computation (SMPC), is a subfield of cryptography that allows multiple parties to jointly sign a transaction while keeping each party’s key private.

MPC technology enables users to better secure their cryptocurrency private keys, as it can distribute the key among multiple parties, which eliminates any single point of failure. This approach, often called "threshold signatures", has been adapted by many crypto custodians and wallet providers to protect crypto assets. Among them, ZenGo is one of the most well-known and well respected MPC wallet providers.

As shown in the following illustration, instead of having a single traditional private key to sign transactions, multiple private key shares participate in the transaction signing process and generate one final signature for validation.

General MPC Design to Generate Signature

At CertiK, we recognize the importance of understanding the challenges and potential security risks associated with the MPC approach to crypto asset protection. We aim to better protect Web3 users by exploring and addressing these challenges. In particular, we seek to answer the question of how MPC wallets can offer better protection compared to traditional crypto wallets.

ZenGo MPC Design and Security Guarantees

Following our previous work on evaluating different crypto wallets designs, we look into the MPC based crypto wallets. Specifically, we evaluated ZenGo, one of the most highly respected MPC wallets on the market, and the leading self-custodial MPC wallet for consumers. During our evaluation, we continued with the same threat model outlined in the previous study: “if your device is compromised by malware, can the crypto wallet still protect your assets?”

ZenGo Security Architecture Overview

As shown in the above diagram, ZenGo Wallet’s security architecture and recovery process is much more layered than traditional wallets and has a unique security design. The security features offered by ZenGo include but are not limited to:

Two Party Signature Scheme: The MPC design on ZenGo implements a two party signature scheme. Two key shares are involved for each user to generate a transaction signature: One is stored on ZenGo’s server (master key 1), another is stored on the user's devices (master key 2). Neither ZenGo or the user has knowledge about the secret that the other party holds.

TEE-Based Protection: In addition, to prevent Man-in-the-Middle and Man-in-the-APP attacks, ZenGo application uses a TEE (Trusted Execution Environment) solution to sign the HTTP request data using a TEE exclusive key. This TEE based device key is generated within the TEE when the user sets up the device and can never be extracted, even by the operating system itself.

With these security features, attackers can no longer steal user’s private keys from memory or storage files and fully control a ZenGo user’s assets. ZenGo also utilizes TEEs to protect the interaction between server and client from being modified, meaning Man-in-the-Middle and Man-in-the-App attacks are effectively prevented. Our review confirms that ZenGo indeed has a secure design and implementation that defends against these attacks. This is already at the best level of security among all the wallets being reviewed, including those with Trustzone support. We will release a separate report about our findings on vulnerabilities for other wallets with secure enclave support.

ZenGo’s secure design and implementation successfully defend against the above mentioned attacks, including attacks from privileged levels. However, handling all types of privilege attacks are non-trivial, especially considering the attackers can read (and in certain cases write) arbitrary memory. By reviewing the wallet’s entire threat surface, we were able to identify an implementation issue in ZenGo that allows us to bypass certain protections as a privileged attacker, which we will introduce later.

Before we get to the actual threat, let us review the security mechanism of ZenGo Wallet.

Security Practices in ZenGo Wallet

A classic crypto wallet only needs a single private key. Users always have means to either reveal the private key or mnemonic words and import the private keys into other wallets later to spend their funds. This poses a threat: users may lose their private key or it can be stolen and then the attacker can fully possess the assets.

MPC wallets work differently. There is no single private key, users now only hold one share of the private key and have no knowledge of the rest of the shares. From this perspective, attackers cannot directly move funds even after obtaining the user’s personal key share. To further protect users, ZenGo uses multiple means to enhance their security design beyond just two party signature schemes, such as TEE based device protection, face scan based biometric authentication, additional key encryption, etc.

Protections in User Sign Up & User Recovery Process

During the user signup and recovery process, ZenGo employs the following protections to guard user assets.

User Identification Protection: The nature of the two party signature scheme requires the user to interact with another party (server side in the case of ZenGo) to spend their funds. To be able to identify users and associated key shares stored on the server, ZenGo requires the user’s email address in order to register an account. As we show in the following figures, to prevent the risk of email hacking ZenGo uses a facial scanning technique (Zoom by FaceTec) to bind the biometric information with the user account. Users are required to scan their faces to authenticate during the signup and recovery process after email verification.

App-Server Communication Protection: To ensure that the ZenGo server is interacting with the legitimate user’s device(s), ZenGo generates and enrolls an asymmetric key in the TEE environment during the signup and recovery process. All interactions between the ZenGo app and server need to be signed by this specific key. The attacker cannot directly read this key and it is very difficult to be abused in order to perform Man-in-the-Middle and Man-in-the-App attacks, as it is protected by hardware backed security solutions.

ZenGo User Signup and Recovery Process

User Key Share Protection: It is risky to have the users store and backup the plaintext of their key share, as it jeopardizes all the security measures provided by ZenGo. To address this issue, ZenGo generates an encryption key during the signup process. The encryption key encrypts the user’s key share and ZenGo stores the ciphertext on their server. The encryption key, however, is not shared with ZenGo and is forced to sync with user’s Google Drive/iCloud. Only after the user passes both email verification and server based biometric authentication, can the encrypted key share be retrieved to user devices and further be decrypted. Among which, the server based biometric authentication (FaceTec face identification) is nearly impossible to bypass via regular 2D/3D face reconstruction attacks.

Transaction Signature Generation

ZenGo Transaction Process

To sign a transaction, the ZenGo app performs a series of interactions with the ZenGo server. During the interactions, ZenGo uses their open-source two party signature solution and user key share to generate the two party signature. Then the ZenGo server further completes the signature and broadcasts the transaction. All the requests in this process are time-stamped and signed in the TEE to maintain the message integrity.

An Issue Found with ZenGo’s MPC design

As we discussed before, many cryptographic keys are involved in ZenGo’s security design and each of them have different responsibilities. In the following table, we show what keys are used and how they are protected by ZenGo.

With this table, we can see that there are three keys used on the client side: Master Key 2, Device Key and Encryption Key. The attacker needs to obtain both the Master Key 2 and Device Key in order to interact with the ZenGo server and steal a user’s funds. As introduced in the previous transaction detail section, Master Key 2 is used as plaintext in memory to participate in the two party signature generation. It allows the attacker to read the process memory and extract the master key 2. As a mitigation, all transaction requests to the ZenGo server need to be signed by a device key, which can not be read/extracted. This process is done in the TEE, which is beyond the control of the attackers.

However, even though ZenGo’s security design takes many aspects into consideration, CertiK’s SkyFall team still found one misimplementation. After carefully reviewing all APIs available in the ZenGo application, we noticed that certain APIs allow attackers to trick the ZenGo server and easily generate a new device key to use it on any other devices. This device key enrollment API lacks necessary security protections. Attackers can generate a new NIST P-256 Elliptic Curve key on other devices. The attacker then abuses the device key enrollment API and enrolls the newly generated keypairs to act as a new user device and initiate transactions. We name this attack a Device Fork Attack and we show how to exploit it in the following section.

Device Fork Attack on ZenGo Wallet.

As shown in the previous section, the attackers need to possess a ZenGo user’s Master Key 2 and a valid Device Key to steal their assets.

Master Key 2: The Master Key 2 is a fixed key and used as plaintext in memory in order to participate in the two party signature process. Due to the complexity and uniqueness of the two party signature algorithm, this process cannot be done in TEE. As a consequence, a privileged attacker can simply dump the process memory or hijack certain system APIs to extract the Master Key 2. The following screenshot shows the Master Key 2 we were able to extract on the iOS platform.

Device Key: A valid Device Key is generated on user devices in the TEE during the signup or recovery process as a mitigation of the previous threat. The Device Key cannot be read by privileged attackers. However, the attacker can use the same Device Key enrollment API to enroll another pair of keys and use it. The Device Key enrollment API only has a very basic authentication mechanism: a regular plaintext stored JWT token and client share / Master Key 2, which the attacker has access to. By design, the server code should have also verified Facetec biometric authentication, however in practice the code failed to enforce it due to a logic flaw.

In our attack, we mimic a privileged attacker and constantly monitor the victim device. Once the ZenGo application is started, we immediately extract the Master Key 2 from memory and read the API token from the local database. The information is enough for the attacker to completely possess the user's funds.

Once we have the API token, we generate a new device key and invoke the device key enrollment API to register the device key on ZenGo server. We then construct all API requests to interact with the ZenGo server to initiate transactions. The generation of two party signature is a very unique process for MPC wallet but thanks to ZenGo’s open source spirit, we were able to compile the two party signature library used in the official ZenGo app and run it locally.

In the above screenshot, we show how we were able to extract Master Key 2 and enroll a new Device Key on behalf of the victim. We then utilize these two keys to send 0.00222 ETH to the “attacker’s account”. This whole process remains invisible to the victim and takes just a few seconds.

To fix this issue, ZenGo implemented FaceTec biometric authentication enforcement on the server side for the device enrollment. The server API level mitigations immediately eliminated the possibility of performing such an attack without the need to update client code.

Timeline

• 02/26/2023 CertiK reports inappropriate protected device key enrollment API issue to ZenGo.
• 02/26/2023 ZenGo responded to the report and scheduled the follow up meeting.
• 03/13/2023 CertiK and ZenGo discussed the root cause of device key related security issues, potential impacts and possible mitigations.
• 03/22/2023 ZenGo deployed patches to fix the device key enrollment issue.
• 03/22/2023 CertiK confirms the issues have been resolved.

Summary.

In our recent evaluation of ZenGo – the most popular MPC-based crypto wallet available to individual users – we thoroughly examined the security measures employed to safeguard users' assets. These include two-party signature schemes, TEE-based device protection, and biometric-enforced user sign-up and recovery. Despite these measures, Certik identified a critical API access authentication issue in ZenGo's implementation that could be exploited in rare scenarios. This vulnerability could allow privileged attackers to bypass existing security measures and steal users' funds if their devices are compromised.

ZenGo promptly addressed the issue and deployed a patch, which we thoroughly reviewed and confirmed to have fixed the reported issue. With this patch deployed, we believe ZenGo can prevent even privileged users from accessing user funds. Defending against privileged attackers is a difficult task, and not many mobile wallets can handle it. ZenGo's security practices demonstrate a comprehensive approach to protecting users, surpassing those of many regular wallets on the market today.

We appreciate ZenGo's efforts to systematically address security challenges in protecting Web3 users and their prompt actions in responding to our findings and issuing patches. We are pleased to see such a commitment to security from a leading crypto wallet provider.