A few months ago, several of our customers requested we support dYdX, a DApp built on StarkEx–StarkWare’s Layer 2 solution on top of Ethereum. This turned out to be more challenging than it might have initially seemed, due to the way StarkEx DApps manage keys and interact with wallets. Today at the “StarkWare Sessions'' conference, we presented our findings on some of these issues and demonstrated a proof of concept for the secure StarkEx support we are working on for our wallet.
To provide some background: each StarkEx DApp is a Layer 2 (specifically, it is a type of Layer 2 called ZK Rollup) on top of Ethereum. Each StarkEx DApp has an off-chain sequencer and a verification contract on Layer 1 (Ethereum) that maintains a cryptographic commitment to the state of the Layer 2 (e.g., user balances). Users submit their StarkEx transactions to the sequencer, and the sequencer assembles a batch of transactions, computes a state update, and produces a short, cryptographic proof of the validity of the state update. Just as in Ethereum, users have to sign every StarkEx transaction with their private key. However, to make proof generation and verification more efficient, StarkEx uses a special signature scheme, which is more “friendly” to the proof system. Specifically, StarkEx uses ECDSA signatures over a special elliptic curve (the “Stark Curve”), and the message to be signed is compressed using a special type of hash function (Pedersen hash). This is in contrast, for example, to signatures in Bitcoin and Ethereum, which are ECDSA signatures over the secp256k1 elliptic curve, and which use SHA-256 to compress the message.
The non-standard signature scheme introduces a challenge for StarkEx DApps, since most wallets (such as MetaMask) do not support the non-standard signature scheme. Therefore, DApps cannot use the user’s wallet to store the user’s Stark key and to sign the user’s Layer 2 transactions. StarkEx DApps work around this limitation by generating the Stark private key within the DApp and storing it in the browser’s local storage. The DApps can then sign the user’s Layer 2 transactions with the locally stored key, without interacting with the user’s wallet. As described above, this workaround has a limitation of the key being very volatile: if the user switches devices or loses their device, they lose access to their private Stark key. To solve this problem, instead of generating the Stark key at random, StarkEx DApps generate the private Stark key pseudo-randomly from a message signed with the user’s Layer 1 key. Specifically, when the user onboards a StarkEx DApp, the DApp sends an EIP712 message-signature request to the user’s Layer 1 wallet. When the wallet returns the signed message, the StarkEx DApp uses it as a seed to derive the private Stark key. As long as the Layer 1 message signature is deterministic (as it is in most non-MPC wallets), the user can repeat this onboarding process on other devices, and they would get the same message signature, and therefore the same private Stark key, each time.
Storing private keys in the user’s browser is highly problematic. Malware running on the user’s device is able to steal the user’s private Stark key. The keys are also at risk of a supply chain attack on the code of the DApp or of any of its dependencies. However, the problem is far more critical in the case of MPC wallets. Specifically, storing the private key on the user’s device undermines some of the main tenets of MPC wallets:
In effect, these serious security problems bring about a situation where an MPC wallet provider is faced with the choice between not supporting StarkEx DApps or supporting them in an insecure way. We are not the only company that has noticed this unfortunate situation. Our colleagues at Safeheron and SlowMist have independently identified this issue and are developing their own analysis and solution.
The Fordefi team has not felt comfortable with either of the two choices. We understand the value of StarkEx apps for our users, so we do not want to resort to blocking such DApps as a long-term solution. On the other hand, security is a top priority and we do not feel comfortable with supporting the DApps in an insecure way.
Over the last couple of months, we have been working together with the Starkware team to build a secure access method to StarkEx DApps for our customers. Specifically, our solution consists of several parts:
The solution is still in the works but today at “StarkWare Sessions,'' we presented a proof of concept that demonstrates an end-to-end transaction signature flow on dYdX, a leading StarkEx DApp.
We are excited that this solution will allow our customers to manage their Stark keys securely, as they do any other of their keys. Customers would get all the benefits of Fordefi’s wallet for StarkEx, including the ability to set policies, enforce multiple approvers, revoke access from users that leave the organization, and more.