NCW Disaster Recovery Process

Developer Discussion
1

I’m testing the Fireblocks Recovery Tool process, and I’ve successfully retrieved Key Share #1 using the Recovery Tool:

{
    "bfc51292-xxxx": {
        "chaincode": "xxxxx",
        "shares": [
            {
                "cosigner": "x-xxxx",
                "MPC_CMP_ECDSA_SECP256K1": "xxxxx"
            }
        ]
    }
}

I expect this JSON data to be used with the

exportFullKeys(chaincode: string, cloudKeyShares: Map<string, string[]>): Promise<IFullKey[]>

function in the web SDK.

However, there’s no detailed documentation explaining how to properly structure the cloudKeyShares input.

Or is there any documentation that explains how to correctly use Key Share #1 after obtaining it?

2

exportFullKeys-

Reconstructs all shares of a CMP key (mobile + cloud shares) into the full public and private keys.@param chainCode - Used for encoding a portable extended key format (BIP-32) - xprv / fprv@param cloudKeyShares - The private key shares stored in the cloud@param callback invoked with the [Set] of [FullKey] that contains extended private key as xprv / fprv and an extended public key as xpub / fpub or a [FireblocksError]

It is for the takeover function:

takeover-

Reconstructs all shares of a CMP key (mobile + cloud shares) into the full public and private keys.@param callback invoked with the [Set] of [FullKey] that contains extended private key as xprv / fprv and an extended public key as xpub / fpub or a [FireblocksError]

An example of takeover use can be found in the demo, where it further derives the extended private for relevant assets key for export where you can import it to MetaMask as an example.

Relevant demo code, for takeover use:

The derivation of asset private key after the takeover and exporting of the extended private key:

3

I was able to successfully obtain the private key using the takeover method. However, as I understand it, the takeover function communicates with Fireblocks’ RPC API and services to export the private key.

What I am currently looking for is a solution to allow my customers to retrieve their private keys even if Fireblocks’ services are no longer available. That’s why I am exploring the Disaster Recovery process.

Now that I have obtained Key Share #1 through the Recovery Tool, how can I successfully export the customer’s full private key without relying on Fireblocks Service(RPC API)?

4

As you shared,
Disaster Recovery.

This is the only option to not use the Fireblocks Service(RPC API)

5

@BetsalelKog The document only explains how to obtain Key Share #1, but it doesn’t mention how
to combine it with the client’s Key Share #2 to obtain the full private key.

6

Hi @patrice the Disaster Recovery kit is designed specifically for the key share located exclusively on Fireblocks servers (Key Share #1).

In the event that Fireblocks ceases to exist and the customer wishes to empower the end-user to perform a full key takeover, the customer must establish an endpoint on their own system.

This endpoint will provide Key Share #1 (generated from the Disaster Recovery kit) to the SDK, enabling the reconstruction of the complete private key.

7

Hi @Wilfred ,
So I need to capture the response format and data that the Fireblocks backend sends to the SDK via the RPC API during the takeover process. Then, I have to build a backend service that replicates this response format in the takeover process and injects Key Share #1. This way, my customers can retrieve their full private key if Fireblocks is no longer available.

Is my understanding correct?

8

While it is theoretically possible to replicate Fireblocks’ RPC response format and inject Key Share #1, this approach is complex and not recommended.

The recommended disaster recovery process is:

  1. The customer establishes an endpoint on their own system to provide Key Share #1 to end-users.
  2. The end-user (via the customer’s app) calls this endpoint to retrieve Key Share #1.
  3. The end-user (via the customer’s app) invokes the SDK function exportFullKeys, which combines Key Share #1 with local Key Share #2 to reconstruct the full private key.

This method ensures a more straightforward and reliable key recovery process.

9

@Wilfred
Yes, based on my initial question, I’ve already obtained Key Share #1 in the format:

{ "bfc51292-xxxx": { "chaincode": "xxxxx", "shares": [ { "cosigner": "x-xxxx", "MPC_CMP_ECDSA_SECP256K1": "xxxxx" } ] } }

However, when trying to use the exportFullKeys method from the Fireblocks NCW Web SDK, I’m not sure how to properly input Key Share #1 into this function. I haven’t found any documentation describing what should be provided in the cloudKeyShares map parameter.

exportFullKeys(chaincode: string, cloudKeyShares: Map<string, string[]>): Promise<IFullKey[]>

Specifically, I need guidance on how to structure the cloudKeyShares map. How should I transform the Key Share #1 data structure I received into the map format required by the exportFullKeys method? The function seems to expect a specific mapping structure, but there’s no documentation explaining how to format the key-value pairs in this map.