Your Stark Keys Belong in Your Wallet

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.

Background on StarkEx 

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.   

Key Management in StarkEx DApps Today

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.

Problems With The Current Approach for MPC Wallets

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: 

• Organizations using MPC wallets expect to be able to enforce a transaction policy, which can block certain transactions and require other transactions to be subject to the approval of multiple users. In StarkEx DApps, transactions are signed with a Stark key stored on the user’s device and do not require any interaction with the wallet after the initial onboarding. This means that once a user within the organization has access to the Stark key, that user can perform any StarkEx transaction and the wallet cannot enforce any policy on those transactions.
• Organizations using MPC wallets expect to be able to revoke the wallet access of a user, for example if the user leaves the organization. Again, with StarkEx DApps, this is no longer possible –  if the user gets access to the Stark key, there is no real way to revoke this key and prevent that user from using it, even after they leave the organization.
• MPC wallets are often non-custodial, meaning they do not have direct access to the user’s private key. StarkEx DApps derive the private Stark key from a Layer 1 message signature. However, signed messages are not usually considered to be secret, and wallets are likely to store them or log them. Since anyone with access to the signed message can derive the private Stark key, the wallet provider essentially gets direct access to the private Stark key of the customer.

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.

Fordefi’s Secure 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:

1. Extending our MPC protocol to support the StarkEx curve and the Pedersen hash function. This update allows us to generate Stark keys in our MPC wallet and sign StarkEx transactions.
2. We are extending our API to allow signing messages with the Stark signature scheme. This would allow our programmatic clients to benefit from Stark signatures very soon.
3. We are extending our browser extension to expose an interface that allows DApps to request Stark signatures from the wallet, without exposing the private Stark key to the DApp. This interface would allow DApps to avoid the unsecure in-browser Stark key derivation, and instead rely on the wallet to generate and store the private Stark keys, as it should. We look forward to working with StarkEx DApp developers to integrate this new secure wallet interface into their DApps. 

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.