A. Integrating Silent Shard with Phone Wallet
SilentShard SDK to create a distributed ECDSA signature for a message between two devices with the ability to recover a lost device using a recovery phrase.
A great use case of our libraries is to have your phone and cloud node act as parties to interact to enable the user to sign transactions.
MPC Parties
A phone wallet that uses our React Native SDK (Rust as core) to generate, manage and recover the first key share shard1 and generate a valid signature by communicating with the cloud node holding the second key share shard2
A cloud node that uses SDK (Rust as core) to generate, manage and recover key share shard2.
Components of the System
As shown in Fig 1, a system consists of
A mobile application (wallet)
SDK1 (as part of the mobile application)
A backend of the mobile application
SDK2 (will be part of the backend)
Server node (i.e. cloud node)
SDK1 provides React-native binding for our TSS {2, 2} library and SDK2 provides an interface for the backend to communicate with the Server Node.
Protocol Overview and Sessions
There are three sub-protocols:
· Key Generation
· Signature Generation
· Key re-fresh
Execution of all protocols requires establishing a shared session id between two parties. The mobile party is always an initiator. It sends a request to the backend. The backend validates the request according to some business rules, issues a request to Server Node using SDK2, gets the session id, and returns it to the mobile application. Then the mobile application will directly communicate with Server Node to execute {2, 2} MPC-TSS protocol.
Message Exchanges
Two parties (mobile and server) exchange signed messages. The server's public key was created during the server node installation procedure, and the mobile application knows it (for example, it is a build time configuration option) beforehand. The public key of the mobile application is created as part of the installation procedure on a user's device. When the server node creates a new session, it will link provided signing public key to the session.
Key generation
For key generation, we need an additional set of keys - PartyKeys. This object could (and should) be reused for generating different distributed keys. PartyKeys acts as a user identity. Using the PartyKeys object and session ID created by the backend, we could create a KeygenSession. This object holds a state of protocol execution. We will generate the first message, send it to the server node, process the second message, send the third message to the server, and generate key share as a result of key generation.
It is to be noted that the key share is secret material.
Signature generation
Like key generation, we start with creating a session ID. Then we create SignerSession. To create SignerSession we need:
session ID
key share
the hash of the message we are going to sign
chain path
The execution of signature generation is identical to key generation, but in the end, will get a signature. The signature is the raw format.
Last updated