Enhancing Security on MPC Wallet-dYdX Connections
03/09/2023
By Safeheron Security Team
Safeheron has recently launched the Web3 Suite, which enables customers to securely interact with decentralized applications (dApps) through the Safeheron browser extension, using Multi-Party Computation (MPC) and Trusted Execution Environment (TEE) technology to address the needs of multi-party governance of assets.
As dApps come in various forms and have different security designs, Safeheron's security team regularly reviews dApps that our clients interact with to ensure there are no potential security issues.
The Safeheron security team recently conducted security reviews of several dApps and identified potential issues with certain authorization designs in certain scenarios:
It was found that in certain scenarios, dApp authorization connections can bypass the security protection of private keys in hardware (cold) wallets, potentially granting access to core operation permissions without proper authorization through the hardware wallet.
Self-custodial wallets built with MPC typically do not enable the platform to control a user's assets, only allowing for the transfer of assets with user authorization to participate in MPC computations. However, when connecting MPC wallets to certain dApps, the principle of the platform not having control over user assets can be compromised, enabling the platform to control user assets in the dApp without user authorization. Customers may have the ability to circumvent established transaction policies, and employees who depart the organization may still be able to access and operate the dApp.
Upon discovery of these issues, the Safeheron security team immediately collaborated with the SlowMist security team to verify, confirm, and work on solutions, and SharkTeam participated in issue verification too. Safeheron has disclosed this issue to potentially affected parties.
It has been verified that these issues do not affect the security of MPC wallets in managing funds, and only pose potential security risks when interacting with specific dApps.
Safeheron refers to these issues caused by similar mechanisms as Signature-derived Key Risk, and this article takes dYdX as an example to analyze the need to increase the security of such dApps in specific scenarios, and also to present the solution to achieve this.
Background
Deterministic Random Algorithm in ECDSA
There is a temporary key k in Elliptic Curve Digital Signature Algorithm (ECDSA). The method of generating k determines not only the security of the algorithm but also the consistency of the signature when the same private key is used to sign identical data.
The generation of the temporary key k, using a random number generator during the signing process can lead to non-deterministic signatures. This means that using the same private key, sk1, to sign the same data, hash1, can result in different signatures, sig1 and sig2, being produced.
The implementation of a deterministic temporary key generation method outlined in the RFC6979 in the signing process ensures consistent signature. Specifically, when the same private key, sk1, is used to sign the same data, hash1, the first and second signatures, sig1 and sig2, will be identical.
Common HD software/hardware wallets often use the RFC 6979 protocol to implement the ECDSA algorithm. dYdX and other dApps are based on the features of the RFC 6979 protocol, allowing users to always receive the same signature upon authorizing the signing of fixed data. This signature can then be used as the source in a mechanism of deriving a recoverable L2 key based on an L1 wallet.
Distributed Signing Protocol in MPC-ECDSA Protocol
In the context of MPC, the distributed signing protocol possesses two distinct characteristics that differentiate it from the traditional single private key signature algorithm:
For the purpose of maintaining security, the temporary key k utilized in the signing protocol is generated through the use of a random number generator. This results in the generation of distinct signatures each time the same private key shard is used to sign the same hash multiple times.
In popular t/n protocols such as GG18, GG20, and MPC-CMP, among others, all t participants of the signing protocol can get the generated signature.
dYdX's Logic for Deriving STARK Key and API Key
Authentication methods in dYdX
There are three levels of authentication for the private API in dYdX:
Ethereum Key Authentication
It can be employed to perform tasks such as registering users, registering STARK Keys, managing API keys, and executing forced transactions or withdrawals, among others.
STARK Key Authentication
A separate key pair within the L2 system which can be used to place orders, L2 transfers, withdrawals and other sensitive operations. It adopts the ECDSA algorithm on the STARK curve instead of secp256k1.
API Key Authentication
API keys for interacting with dYdX. All private requests made to dYdX need to be authenticated in this manner.
As per the three authentication methods, dYdX's sensitive operations like placing orders or transferring assets only require STARK Key Authentication and API Key Authentication, eliminating the need for Ethereum Key Authentication.
Key Derivation in dYdX
dYdX's official website UI and TypeScript and Python SDKs have implemented a key management method that is built on the EVM L1 wallet architecture, which aims to prevent the loss of the STARK Key and the API key. The same STARK Key and API key can be repeatedly derived using a fixed derivation algorithm as long as the L1 wallet private key is not lost.
As shown in the figure, the core derivation logic of STARK Key and API key is as follows:
Using the eth_signTypedData_v4 signing method of L1 ECDSA Signer to sign the message 'dYdX STARK Key' to obtain stark_key_signature. This step will ask users to authorize the signature using their wallet.
Using the eth_signTypedData_v4 signing method of L1 ECDSA Signer to sign the message 'dYdX Onboarding' to obtain api_key_signature. This step will ask users to authorize the signature using their wallet.
Deriving the STARK Key public-private key pair from the stark_key_signature. This step is performed locally as most wallets use the RFC6979 protocol to implement the signature algorithm, thus the stark_key_signature is fixed for each signing, resulting in STARK Key having a fixed public-private key pair.
Deriving the API Key from the api_key_signature. This step is also calculated locally, as most wallets use the RFC6979 protocol to implement the signature algorithm, resulting in a fixed api_key_signature for each signing, and thus the API Key is fixed.
If a user is utilizing dYdX for the first time, the interface '/v3/onboarding' must be called for registration. The registration process requires the submission of the STARK Key’s public key, api_key_signature, and the user's L1 address among other details.
When registering with dYdX through the official user interface or SDK, the recovery of the STARK Key and API key can be achieved by following Step 1 to 4 after wallet authorization. This will enable the user to gain access to the operating privileges of dYdX.
PoC
Since the signature obtained in Step 1 and 2 of Key Derivation in dYdX is fixed each time, obtaining the stark_key_signature and api_key_signature after a certain authorization allows users to obtain the STARK Key and API Key in Step 3 and 4. The SlowMist security team has confirmed that obtaining the stark_key_signature and api_key_signature authorized by a wallet account allows for the manipulation of assets within dYdX, such as placing orders, L2 transfers, canceling orders, etc. This also allows for the transfer of assets from the dYdX platform to the attacker’s account via L2 transfers and further withdrawal of assets to the attacker’s L1 wallets.
At the time of this disclosure, dYdX has removed the L2 transfer, so the attackers have no access to transfer assets in dYdX.
Potential Security Concerns
Bypass the Private Key Management in Hardware (Cold) Wallets
In general, the generated signature used in blockchain wallets is not considered sensitive information since they are included in every blockchain transaction and are publicly accessible. As a result, wallet software and hardware cannot implement additional security measures to protect the signature.
In the case of dYdX, the STARK Key and API Key are derived from the stark_key_signature and api_key_signature, respectively. Once these signatures have been used on dYdX, they fall outside of the key management of the wallet application. This means that in the case of a hardware wallet, once it has been used to interact with dYdX, the stark_key_signature and api_key_signature are no longer protected by the security mechanism of the hardware wallet. If an attacker obtains these signatures, they can bypass the security mechanism of the hardware wallet and perform unauthorized actions in dYdX.
Similar mechanisms utilized by other dApps also pose the same security concerns.
Violating the MPC Self-Custody Principle
Self-custodial wallet platforms built using MPC technology typically achieve self-custodianship by decentralizing the management of key shards, meaning the platform cannot independently maintain control over a user's assets without user authorization. These platforms often use protocols such as GG18, GG20, MPC-CMP, and others that use t/n protocols, making the signature available to the t parties involved in the signing protocol.
The potential vulnerability lies in the fact that if a user has used dYdX or similar dApps with an MPC-based self-custodial wallet platform, the platform as a participant in managing key shards would also have access to the stark_key_signature and api_key_signature. This would allow the MPC wallet platform to control the user's assets in dYdX without user authorization.
As a result, the interaction between MPC wallets and dYdX or similar dApps that use signature-derived keys undermines the principle of self-custody for MPC wallet platforms, allowing them to bypass user authorization and circumvent MPC computations to control users' assets in these types of dApps. Customers may be able to bypass pre-defined transaction policies, and employees who have left the organization may still retain the capability to operate the dApp.
Risk of Asset Loss for Users of Wallets Utilizing Random Temporary Key k
Many wallet browser extensions offer interfaces that override the MetaMask extension or connect to dApps through WalletConnect.
dYdX's official UI interface, when registering users through MetaMask or WalletConnect, defaults to wallets that comply with the RFC 6979 specification and does not detect non-compliant wallets. If a user uses a random temporary key k wallet, then when the user closes the browser or switches browsers, the user may have no permission to operate dYdX using the same L1 wallet.
Although it is possible to recover assets through Ethereum Key Authentication, the process is complicated and is likely beyond the capabilities of the average user.
Solutions
Optimizing Key Management in dYdX-like dApps, Building Community Standards for Wallet Interfaces
In the context of dYdX, as dYdX is built on StarkEx and StarkEx is built on the STARK proof mechanism, it requires the use of STARK Key derivation and STARK curve-based signing algorithms. To ensure compatibility with existing EVM wallet ecosystems, dYdX adopts a method of signature-derived key generation, which leads to key management that is outside the scope of private key protection provided by wallets.
To ensure better protection of the STARK Key, it is crucial that the derivation and usage of the STARK Key occur in a secure environment, and that each signature requires user authorization. For instance, both the derivation and signing process should be carried out within a wallet application. A more effective solution would be to collaborate with the wallet community to establish a standard for private key management based on the STARK Key, and for wallets to provide support for the ECDSA signature algorithm on the STARK curve.
For dApps that utilize the native support for hardware wallets, the users can still use hardware wallets for enhanced security. When interacting with dYdX and other dApps without native support for hardware wallets, the Safeheron security team recommends implementing heightened security measures when interacting with dYdX or similar dApps. To ensure the safety of your operating environment, we recommend utilizing a dedicated MacBook specifically for dYdX interactions, keeping browsers and computer software up-to-date, and avoiding the installation of any unnecessary software or browser extensions on your device.
Safeheron is proactively in touch with StarkWare and the community to develop a security model for secure engagement with decentralized dYdX-type applications. Some companies like ZenGo, Fireblocks, Fordefi, etc. are also constructing their own security models to tackle this concern.
Blocking dYdX-like dApps on MPC-based Self-Custodial Wallet Platforms
As a measure to uphold the principle of self-custody, self-custodial wallet platforms can implement a temporary solution by blocking dYdX-like dApps and providing clear notifications to users. To ensure user awareness and safety, these platforms can issue prompts when users connect to dApps, warning of potential risks associated with the use of MPC wallets. To further protect users who have already utilized dYdX through MPC self-custodial platforms, it is recommended that they reconnect to dYdX using a new account and transfer their assets from the old account to this new account.
Enhancing Management Security of STARK Key with MPC-ECDSA on the STARK Curve
For clients who require multi-party governance on assets in dYdX, we can create a tailor-made MPC protocol for the ECDSA used by StarkEx, enabling secure multi-party co-management at the private key level. Safeheron is collaborating closely with the community to develop solutions and is planning to launch the implementation and open-source release of the MPC-ECDSA protocol based on the STARK curve. This will allow our clients to securely manage assets on dYdX through this MPC protocol, while also giving the community the freedom to customize solutions using the open-source protocol.
Ensuring Wallet Compliance with RFC 6979 Standard
To prevent the risk of users losing assets when using a wallet with a randomly generated temporary key k, dYdX and similar dApps should verify compliance with the RFC 6979 standard when connecting to a wallet. If the wallet does not comply with the standard, the user should be warned and the connection should be denied. Furthermore, enhancing the Ethereum Key Authentication process and introducing a more user-friendly method for redeeming assets will make it simpler for users to recover their assets.
Conclusions
Adhering to the highest security standards and a sense of obligation to our users, Safeheron promptly initiated the disclosure process, with all parties taking decisive action to ensure resolution. To mitigate risk, dYdX has suspended L2 transfers. Safeheron is dedicated to open-sourcing support for the MPC-ECDSA protocol on the STARK curve, and further enhancing our product offerings with native support for StarkEx and StarkNet, to better assist users in safeguarding their assets.
In the rapidly evolving Web3 ecosystem, the safety of user funds is a top priority. To this end, Safeheron collaborates closely with the Web3 community, projects, and other security companies to identify and address any potential threats, playing an active role in maintaining the security of the crypto world.
Last updated
