A 2-of-2 MPC Wallet with QR Setup and NFC Signing

,
1

I would like to discuss a wallet design built around three components: Lindell 2-of-2 MPC signing, QR-only initialization, and encrypted NFC communication between a computer and a phone.

The goal is to keep the convenience of a desktop wallet while ensuring that compromising either device alone does not provide unilateral signing authority.

Lindell 2-of-2 MPC as the signing foundation

The computer and phone each hold a private share of one joint signing key. Neither device holds the complete private key.

Using a reviewed implementation of Lindell’s two-party ECDSA protocol, both devices interact to compute a signature without revealing their shares or reconstructing the complete private key.

For Ethereum, the implementation would use secp256k1 and produce one ordinary ECDSA signature under the joint public key. The wallet can therefore use a normal Ethereum address without requiring an on-chain multisignature contract.

The 2-of-2 requirement comes from the signing protocol itself: obtaining the computer’s share alone is insufficient, and obtaining the phone’s share alone is also insufficient. Both devices must participate in signing the same transaction.

Initialize entirely through QR codes

Initialization takes place before connecting the NFC reader.

Each device generates its own secret contribution, and the two devices carry out the required key-generation exchanges through bidirectional QR codes. They agree on the joint public key and derive the wallet address independently.

The user checks the wallet address and pairing fingerprint on both screens.

During the same setup, the devices establish separate communication identities for their future encrypted channel. These communication keys are distinct from the MPC signing shares.

The NFC reader therefore takes no part in generating the signing key or establishing initial device trust. No signing share is stored in the reader.

Carry the signing protocol over NFC

After setup, the computer uses an NFC reader to exchange authenticated, encrypted messages with the phone.

A routine transaction follows this process:

  1. The computer constructs the complete transaction, displays it for local approval, and sends it to the phone over NFC.

  2. The phone independently decodes the actual transaction, including the chain, recipient, asset, amount, fees, and any contract action or spending permission.

  3. The user reviews and approves the transaction on the phone.

  4. The computer and phone run the interactive Lindell signing protocol, carrying the required MPC messages over NFC.

  5. The resulting ECDSA signature is verified and used by the computer to broadcast the transaction.

The user can first transfer the request, review it on the phone, and then hold the phone near the reader while the interactive signing exchange completes.

Both devices bind their participation to the exact transaction that was approved. The phone must not rely solely on descriptions, labels, or simulations supplied by the computer.

NFC is the communication interface; the cryptographic signing takes place on the two devices. The reader remains an untrusted message carrier. Authenticated encryption and replay protection prevent it from silently replacing legitimate protocol messages with different ones.

Renew communication trust through QR

Communication keys can be renewed periodically using another bidirectional QR exchange, entirely outside the NFC channel.

This renews the communication pairing without changing the MPC signing shares or wallet address. A reader cannot introduce a replacement device or silently change the trusted peer.

The phone can remain disconnected from the Internet and perform local transaction decoding and policy checks. Alternatively, it can operate online and independently query blockchain state or simulate transactions.

The intended security benefit

If the computer is compromised, an attacker can prepare malicious transactions and control the computer’s side of the protocol. However, they still need the phone to participate. An honest phone can display the actual request and reject it.

Likewise, a compromised phone alone lacks the computer’s signing share. Each device must retain its own approval boundary.

This depends on correct protocol implementation and meaningful transaction review. Strict 2-of-2 also requires backups that preserve the separation between the shares.

The combination is the proposal: QR establishes trust, NFC carries the encrypted signing interaction, and Lindell 2-of-2 MPC ensures that neither device can sign alone.

I would welcome feedback on the security model and practical implementation of this workflow.

2

In Lindell’s protocol the party that finishes the signature can lose its share to the other device through failed signatures. A corrupted counterpart crafts its last message so the signature only comes out valid when one chosen bit of the finisher’s share is zero, and it learns the result from the chain or from the error. About 200 tries recover the whole share. That’s CVE-2023-33242, the Lindell17 abort issue Fireblocks disclosed in 2023, and several wallets and libraries had to patch it. If the computer finishes the signature (it verifies and broadcasts in your flow), a compromised phone ends up with both shares, and if the phone finishes it, the computer does.

NFC makes this easy to miss, because dropped taps and retries will be normal for users. The finishing device has to keep a dropped or unauthenticated message apart from a run that completed and produced an invalid signature. The second one should never happen without an attack or a bug, so stop signing with those shares after the first one and only continue after a new QR pairing with a share refresh, which makes any bits already leaked useless.

The joint key is a plain EOA, so the phone will also be asked to sign EIP-712 messages and EIP-7702 authorizations, not only transactions. A Permit2 or ERC-2612 permit lets someone else move the tokens without any transaction from this account, and one 7702 authorization delegates the whole account to whatever code the computer picked, on every chain if its chain_id is 0. A compromised computer will ask for one of those instead of a suspicious transfer, so the phone needs to decode typed data as carefully as transactions and refuse 7702 authorizations unless the user turned them on for a known delegate.

3

Thanks for raising these points. The Lindell17 abort issue is a valid concern. I would revise the proposal to use DKLs23 for 2-of-2 threshold ECDSA, using a reviewed implementation with its required session, nonce, and failure-handling rules.

Changing protocols does not remove the need for careful integration. NFC transport failures must remain distinct from cryptographic protocol failures, and retries must never reuse unsafe signing state. QR re-pairing of communication keys is also separate from refreshing MPC shares.

The primary security goal is to prevent a computer compromise from immediately giving an attacker full signing authority. Malware obtaining the computer’s share should still need the independently controlled phone to participate. The same protection should apply in the opposite direction.

Both devices should therefore perform independent checks and require explicit user confirmation. The computer should decode and display the request before approval, and the phone should independently reconstruct its meaning from the actual payload. Both must bind their participation to exactly the content approved by the user.

Your point about permits and EIP-7702 is relevant to that review process. Supported typed-data permissions should expose their spender, amount, expiration, and domain. If 7702 is supported, delegation should be presented explicitly and restricted to reviewed delegates. Unsupported or undecodable requests should be rejected. Software performs the decoding and validation; the user decides whether the action matches their intent.

QR-only initialization and authenticated, encrypted NFC communication remain part of the design. QR establishes the initial device trust before introducing the reader; NFC carries the interactive MPC signing messages and makes routine signing a deliberate interaction involving both devices.

The intended guarantee is that a single-device compromise cannot independently produce new wallet signatures. Preventing users from approving every possible malicious authorization is a broader challenge, but independent review on both devices provides an additional opportunity to identify and reject those requests.