Scoutinternal

BitGo Wallet Keys: Private Keys, Public Keys, and Key Recovery Inquiries

BitGo Wallet Keys: Private Keys, Public Keys, and Key Recovery Inquiries

Problem

Customers contact support with questions or issues related to their BitGo wallet keys. Common scenarios include: requesting access to private keys, sharing public keys (xpub) for account verification or recovery, inquiries about the Keyternal (keytern.al) backup key recovery service, lost KeyCards or key files, and questions about importing private keys into BitGo wallets. BitGo uses a 2-of-3 multi-signature key architecture where the user key, BitGo key, and backup key each play distinct roles.

Diagnostics

  • Confirm the customer's identity and account ownership through standard verification procedures before discussing any key-related information.
  • If the customer shares a public key (xpub/tpub), look up the corresponding wallet in internal admin tools to match the key to a wallet name/ID.
  • Check whether the customer's backup key was stored with Keyternal (keytern.al) — this is indicated by a Keyternal confirmation email the customer may have received during wallet creation.
  • Determine whether the customer is asking to view existing keys, import external keys, or recover lost key material.
  • If the customer has shared full key material in their message, note the security violation and instruct them on proper handling (share only first 8 / last 8 characters).
  • Check if the request is actually an account access issue (e.g., frozen account, 2FA reset) that requires key verification as part of the identity confirmation process.

Resolution

Scenario: key-private-keys-public#public-key-shared-for-verification

Trigger: Customer shares a public key (xpub) to verify wallet ownership, often in the context of a frozen account or 2FA reset request.

Signals: xpub, public key, reopen, frozen account, 2FA reset, account locked

Steps:

  1. If the customer has shared the full public key in their message, instruct them: "Only share the first 8 & last 8 Characters always. Do not share the whole content. This is a security precaution."
  2. Ask the customer to confirm the wallet name the public key belongs to.
  3. Look up the public key in internal admin tools to match it to a wallet/account.
  4. Once ownership is verified, proceed with the underlying request (e.g., 2FA reset, account unfreeze).
  5. After completing the action (such as 2FA reset), inform the customer to log back in and follow the instructions to set up their Two-Factor Authentication again.

Notes: Customers may forward their original Keyternal email as proof of key ownership. The xpub in that email can be matched to their wallet.

"Only share the first 8 & last 8 Characters always. Do not share the whole content. This is a security precaution." (ticket #253474)

"We have completed the process of resetting your Two-Factor Authentication. Please log back into your account, and follow the instructions to set up your Two-Factor Authentication again." (ticket #253474)

Scenario: key-private-keys-public#keyternal-backup-key-recovery

Trigger: Customer references Keyternal (keytern.al) as their backup key custodian and needs to recover their backup key material.

Signals: keyternal, keytern.al, backup key, recovery, third-party custodian, KRS

Steps:

  1. Confirm the customer originally selected keytern.al as their trusted third-party backup key custodian during wallet creation.
  2. Advise the customer that Keyternal holds their backup private key in cold storage and the corresponding public key was provided to BitGo for the multi-sig wallet.
  3. Direct the customer to contact Keyternal directly using the recovery contact information from their original Keyternal confirmation email.
  4. Refer the customer to Keyternal's official recovery policy at https://keytern.al/p/recovery/
  5. Remind the customer that BitGo's 2-of-3 multi-sig architecture means they need only 2 of the 3 keys to move funds — the KRS backup key is an emergency measure.

Notes: Keyternal's website is https://keytern.al. Their policies are at https://keytern.al/p/tos/, https://keytern.al/p/recovery/, and https://keytern.al/p/privacy/. If Keyternal is unreachable, the customer can still transact using their user key + BitGo key.

"keytern.al will keep your BitGo wallet backup key safe. ... You are receiving this message because you recently created an account with BitGo and have selected keytern.al as the trusted third-party custodian of your backup keys." (ticket #253474)

"We now hold in cold storage a set of private keys dedicated to your use. The corresponding public keys have already been provided to your wallet provider for use in your multi-sig wallet. Should you ever encounter the circumstance where you would need the backup keys to recover your funds, please contact us..." (ticket #253474)

Scenario: key-private-keys-public#private-key-access-request

Trigger: Customer asks how to view, export, or obtain their private keys from BitGo.

Signals: private key, export private key, view private key, get private key, how to access key

Steps:

  1. Explain that BitGo uses a 2-of-3 multi-signature key architecture. The three keys are: the user key (encrypted with the wallet passphrase and stored by BitGo), the BitGo key (held by BitGo for co-signing), and the backup key (held by the customer or their chosen KRS).
  2. Clarify that the user's encrypted private key is on their KeyCard, which was generated during wallet creation. BitGo does not have access to the unencrypted user private key.
  3. If the customer needs their private key for recovery purposes, direct them to the BitGo wallet recovery process which requires 2 of the 3 keys.
  4. BitGo does not provide raw private key export functionality in the standard UI. If the customer needs to move funds, they should use the normal send transaction flow or the recovery tool.
  5. If the customer has lost their KeyCard, advise that the encrypted user key can still be retrieved from their account if they know their wallet passphrase, but the original KeyCard PDF cannot be regenerated.

Notes: BitGo never has access to unencrypted user private keys. The wallet passphrase is required to decrypt the user key. If both the KeyCard and wallet passphrase are lost, recovery depends on the backup key (from KRS or self-custody).

Scenario: key-private-keys-public#lost-keycard-or-key-file

Trigger: Customer reports they have lost their KeyCard PDF, key file, or wallet backup documentation.

Signals: lost key, lost keycard, key file, lost PDF, key lost, lost keywallet

Steps:

  1. Verify the customer's identity through standard account verification procedures.
  2. Explain that the KeyCard contains the encrypted user key and the public portion of the backup key. If the customer still knows their wallet passphrase, they can still transact normally through BitGo.
  3. If the customer has lost both the KeyCard and the wallet passphrase, determine whether a KRS (such as Keyternal) holds their backup key.
  4. If a KRS holds the backup key, the customer can initiate recovery using the BitGo key + backup key (bypassing the lost user key).
  5. Recommend the customer store any recovered or regenerated key material securely and consider printing a new copy for offline storage.

Notes: BitGo cannot regenerate or resend KeyCard PDFs. The KeyCard is generated client-side during wallet creation and is the customer's responsibility to store securely.

Scenario: key-private-keys-public#import-private-key

Trigger: Customer asks how to import an existing private key or external wallet into BitGo.

Signals: import private key, import key, link outside account, existing wallet, add private key

Steps:

  1. Explain that BitGo's multi-signature wallets generate their own key sets during wallet creation. Importing a single external private key into an existing BitGo multi-sig wallet is not a standard supported operation.
  2. If the customer wants to move funds from an external wallet into BitGo, advise them to create a new BitGo wallet and send funds from the external wallet to the new BitGo wallet address.
  3. For enterprise or API customers who need custom key configurations (e.g., providing their own user key or backup key during wallet creation), refer them to the BitGo SDK/API documentation on wallet creation with user-supplied keys.
  4. If the customer is attempting to use an externally generated key as their backup key, this can be configured during wallet creation but not retroactively applied to an existing wallet.

Notes: Standard BitGo wallets do not support importing arbitrary private keys after creation. The multi-sig architecture requires keys to be established at wallet creation time.

Related