ZenGo is a secure Web 3 wallet using Multi-Party Computation (MPC) technology.

Recently, CertiK's SkyFall team conducted a thorough audit and research of numerous mobile wallets and found that ZenGo's MPC solution provides stronger security defenses than ordinary mobile wallets - ZenGo's wallet users, especially those with high value Users can defend against direct attacks from advanced attackers: such as exploiting zero-day vulnerabilities or advanced malware to gain root privileges on user devices.

This threat is new and only discovered by the CertiK team, so MPC wallet developers must pay attention to the details of the attack!

Defending against privileged attackers is challenging. We present a new attack vector in the reported results with the attack vector against the MPC method in ZenGo. We immediately reported this security issue to ZenGo, and ZenGo responded quickly and fixed the issue.

In this post we will dive into the technical details of this discovery and share how we worked with ZenGo to improve the overall security of MPC wallets.

secondary title

What are MPCs?

Multi-party computation (MPC), sometimes called secure multi-party computation (SMPC), is a field of cryptography. It allows multiple parties to jointly sign transactions while ensuring that each party's key is not compromised.

Because MPC technology distributes keys among multiple parties, eliminating any single point of failure, it allows users to better protect their Web 3 private keys, an approach also commonly referred to as"threshold signature", which is currently adopted by many Web 3 custodians and wallet developers to secure Web 3 assets. Among them, ZenGo is one of the most well-known and most used MPC wallet developers.

image description

Generic MPC design to generate signature

Through this research, we have recognized the importance of the challenges and potential security risks associated with the MPC approach for Web 3 asset protection. So we want to better protect Web3 users by exploring and solving these challenges.

secondary title

ZenGo MPC Design and Security Guarantees

Through this research, we have recognized the importance of the challenges and potential security risks associated with the MPC approach for Web 3 asset protection. So we want to better protect Web3 users by exploring and solving these challenges.

So we can think about this question: Why can MPC wallets provide higher security compared to traditional encrypted wallets? How does it do it?

After evaluating different Web 3 wallet designs, we looked at MPC's Web 3 wallet - we evaluated one of the most respected MPC wallets on the market and the leading self-hosted MPC wallet - ZenGo.

image description

ZenGo Security Architecture Overview

As shown in the figure above, the ZenGo wallet has a unique security design, and the security architecture and recovery process are more layered than traditional wallets. Security features provided by ZenGo include but are not limited to:

Two-party signature scheme: ZenGo's MPC design implements a two-party signature scheme. Each user involves two key shards when generating transaction signatures: one is stored on ZenGo’s servers (master key①), and the other is stored on the user’s device (master key②). Neither ZenGo nor the user knows what keys the other holds.

TEE-based protection: In addition, to prevent"middleman"and "APP hijacking"In the attack, the ZenGo application uses a TEE (Trusted Execution Environment) solution, and uses the TEE private key to sign the HTTPS communication content to request the relevant API. This TEE-based device key is generated within the TEE when the user sets up the device and cannot be extracted even by the operating system itself.

With these security features in place, attackers can no longer steal users' private keys from memory or stored files and take control of ZenGo users' assets. ZenGo also utilizes TEE to protect the interaction between server and client from tampering. This also means "middleman" and"APP hijacking"The attack was effectively blocked and defended.

Our audit confirmed that ZenGo does have a secure design and implementation that can resist these attacks, and this is the highest level of security design among the audited wallets we have come into contact with.

ZenGo's security design and implementation successfully defends against attacks including those from privilege and those described above. However, dealing with all types of privileged attacks is not trivial, especially considering that an attacker can read (and in some cases write) arbitrary memory.

By auditing the entire wallet, we were able to discover an implementation issue in ZenGo that allowed us to bypass certain protections as a privileged attacker.

secondary title

Security Practices for ZenGo Wallet

Through this research, we have recognized the importance of the challenges and potential security risks associated with the MPC approach for Web 3 asset protection. So we want to better protect Web3 users by exploring and solving these challenges.

So we can think about this question: Why can MPC wallets provide higher security compared to traditional encrypted wallets? How does it do it?

A classic Web 3 wallet requires only one private key. However, there is always a certain possibility that the user will reveal the private key or mnemonic. So they could lose the private key and watch the attacker take possession of the asset.

secondary title

Protection measures during user registration and user account restoration

During the process of user registration and account recovery, ZenGo adopts the following protection measures to protect user assets.

User Identification Protection: The two-party signature scheme requires that users only have access to their funds when they interact with another party (in ZenGo's case the server side). In order to be able to identify the user and the associated key shares stored on the server, ZenGo requires the user's email in order to register an account.

To avoid email hacks, ZenGo uses facial scanning technology (FaceTec's Zoom) to tie biometric information to user accounts. During the account recovery process after registration and email verification, the user needs to "swipe face" for authentication.

image description

ZenGo User Registration and Account Recovery Process

User Key Share Protection: Asking users to store and back up their key slices is risky as it would compromise any security measures ZenGo provides. To address this security issue, ZenGo generates an encryption key during the registration process. The encryption key encrypts the user's key share and stores the ciphertext on their server.

secondary title

image description

ZenGo transaction process

secondary title

Problem Discovery in ZenGo MPC Design

As we discussed earlier, ZenGo's security design involves many encryption keys, each with different responsibilities. In the table below we show which keys ZenGo uses and how they are secured.

Through this table, we can see that there are three keys used in the client: master key②, device key and encryption key. An attacker would need to obtain both the master key② and the device key in order to interact with ZenGo servers and steal user funds.

As introduced in the previous transaction details section, the master key ② is used as text in memory to participate in the generation of signatures of both parties, which allows an attacker to read the process memory and extract the master key ②. And as a sort of workaround, all transaction requests to ZenGo servers need to be signed by the device key, which cannot be read or extracted. This process is done in the TEE, which is beyond the attacker's control.

However, despite many considerations in ZenGo's security design, CertiK's SkyFall team found a vulnerability in it. After a detailed audit of all APIs in the ZenGo application, we noticed that certain APIs allowed an attacker to trick the ZenGo server and easily generate a new device key for use on other devices.

This device-key-registered API lacks the necessary security protections: an attacker can generate a new NIST P-256 elliptic curve key on another device, and then the attacker can use the device-key to register the API and register a new Generated key pair, pretends to be a new user device and requests a transaction.

secondary title

Device fork attack on ZenGo wallet

As mentioned above, an attacker would need to have a ZenGo user’s master key② and a valid device key to steal their assets.

Master key ②: The master key ② is a fixed key, which is used as plaintext in memory to participate in the signing process of both parties. Due to the complexity and uniqueness of the two-party signature algorithm, this process cannot be done in TEE. Therefore, an attacker with privileged rights can simply dump the process memory or hijack some system API to extract the master key②. The screenshot below shows the master key that we were able to extract on the iOS platform②.

Device key: During registration or account recovery, a valid device key is generated on the user's device in the TEE as a solution to the aforementioned plaintext extraction threat. The device key cannot be read by a privileged attacker, however, an attacker can use the same device key registration API to register another pair of keys and use it.

The device key registration API has only a very basic authentication mechanism: an attacker can use a plain JWT token stored in plaintext and an extracted master key for API authentication. By design, the server code involved in this API should also be Facetec biometric authentication. In practice, however, the code fails to do this due to a flaw in the logic.

In our simulated attack, we simulate a privileged attacker and continuously monitor the victim's device. As soon as the ZenGo application is launched, we fetch the master key from memory② and read the API token from the local database. And this information is enough for the attacker to steal all the funds of the user!

Once we have the API token, we generate a new device key and call the device key registration API to register the device key with the ZenGo server. We then constructed all the API requests to interact with the ZenGo server to initiate transactions. Generating two-party signatures is a very unique and complex process for MPC wallets. Fortunately, the development process of ZenGo has always adhered to the spirit of open source, so we can compile the two-party signature library used in the official ZenGo application and run it locally.

The image above shows how we extract the master key ② and register a new device key on behalf of the victim. We then used these two keys to send 0.00222 ETH to the "attacker's account". The whole process takes only a few seconds and the victim is completely unaware.

Summarize

Summarize

In CertiK's review of ZenGo, we thoroughly checked and audited all the security measures it has taken to protect user assets. These include two-party signature schemes, TEE-based device protection, and biometrics for registration and account recovery.

Despite ZenGo's high level of security awareness and the many measures it has taken to improve its security, CertiK identified a critical exploitable API access authentication risk in ZenGo's implementation. The vulnerability could allow a privileged attacker to bypass existing security measures and steal users' funds if their device is compromised.

ZenGo resolved the issue in a timely manner and deployed a patch, which CeritK then conducted a thorough further audit and determined that the patch fixed the reported risk.

With the patch deployed, we believe ZenGo can effectively prevent privileged users from illegally accessing user funds in the future. Defending against privileged attackers is a difficult task, and ZenGo's security practices show us a comprehensive security approach to protecting users. The wallet's approach surpasses the vast majority of conventional wallets currently on the market.

We are honored to partner with ZenGo and honored to be able to work together and solve security challenges with ZenGo in keeping Web 3 users safe. At the same time, we would also like to thank ZenGo for its timely response to the vulnerabilities we found and the efficient patching of the vulnerabilities.

As practitioners in the security industry, we are very happy to see a top Web 3 wallet company that attaches so much importance to security and has such a high sense of responsibility for users and their funds. We hope that in the future, we can improve the security of more projects and give their users "peace of mind".