Security in-depth

 

Threshold signatures

To sign a message in a system with threshold signatures, several parties (based on the threshold) must cooperate in the signature protocol. Instead of using a traditional private key, the message is signed using a public key and multiple secret shares held by the participating parties.

The ZenGo system is a “two out of two” party ECDSA (the signature algorithm used by Bitcoin, Ethereum and others) threshold signatures system. The two parties are the secure ZenGo server and the ZenGo user’s mobile device.

We use a distributed key generation protocol to generate each secret key separately. That way, no party has access to the other’s secret.  We also created a distributed signing protocol so that both shares are always required to sign transactions on the blockchain. These shares never leave the device that created them. Both protocols are based on the well-known Lindell protocol, which we modified for ZenGo. One of the modifications we made was to ensure that only the mobile device could initiate a transaction. That way, we can never access or move our customers’ funds. You can check and audit our open source implementation on GitHub.

As a result of this distributed setup, ZenGo has no single point of failure. Even if an attacker successfully compromises one of the shares, they cannot spend the victim’s funds or even modify any parameters of the transactions.

To bolster the security of the system, we store the shares using the strongest native security technology available for both the server and the device (e.g. KeyChain and Secure Enclave for iOS devices). To make sure the customer’s share never gets lost, we encrypt it with a key generated on their mobile device. The encrypted share is sent to the ZenGo servers and the decryption key is synced to the customer’s personal cloud service (e.g. iCloud). This prevents the ZenGo server from ever being able to access the client share.

Only the customer can recover their secret share. By authenticating themselves with a 3D biometric face map, the customer can retrieve their encrypted share and begin the restore process. Next, the customer needs to access the decryption key from their personal cloud service. With both the encrypted share and the decryption key, the ZenGo application can reconstruct the customer’s share and restore the wallet.  Note that during this entire process, neither of the external entities (cloud or server) ever has full control of the client share. Therefore, even if the entity is compromised, the account remains secure.

Further reading

For a high-level discussion on the differences between methods of splitting the responsibility of the single private key, see our blog post.

We also recommend you read this basic overview of the ECDSA “two out of two” scheme.

 

Reporting a vulnerability

We encourage the security community to test our systems. You can find more information on how to test ZenGo and report your findings here