Mobile security

The mobile app is one approval layer among multiple secure layers of security that each critical Fireblocks operation has. It has two primary security functions: securely storing mobile MPC key shares and enforcing authentication and encryption methods.

You also have the option to replace the Fireblocks mobile app with an API Co-Signer to automate your approval and signing operations. This article is tailored toward mobile app users only. Read more about the Fireblocks API Co-Signer in this article.

Types of keys stored on your mobile device

Your mobile device’s secure environments store two types of keys:

• Private MPC-CMP key share: Owner, Signer, and Admin’s private key shares that they use to sign transactions.
• Configuration key: Another key on your device, for approving workspace configuration or policy changes, adding users, and other actions that require Admin Quorum approval.

App security model: One thing you are, one thing you have

You must set up two authentication and decryption methods for your Fireblocks mobile app. You use the methods below every time you need to approve or access your stored MPC key share for signing through your mobile app:

• "Something you remember" (six-digit PIN code)
• And either:
  • "Something you are" (fingerprint ID or face ID)
    or
  • "Something you have" (Yubikey NFC).

While the Fireblocks Console requires you to use a 2FA app during log-in before you can trigger workspace change or transactions, the Fireblocks mobile app requires authorized users to authenticate using a fingerprint scan, facial recognition scan, or a Yubikey before each action.

Therefore, for security, users in roles with approval or signing privileges must link their Fireblocks mobile app to their workspace during onboarding to use these methods.

Depending on the action you are taking, the authentication on your mobile app will enable you to:

• For transaction signing: access your MPC key share to sign the transaction with it.
• For transaction approval: approve the transaction using the configuration key.
• For workspace or policy changes: approve the transaction using the configuration key.

Fireblocks mobile app data transfer security

The Fireblocks mobile app transfers data with TLS (Transport Layer Security) encryption, including bidirectional TLS, with certificate pinning support. This enables the highest level of security, prevents man-in-the-middle attacks, and prevents data from being tampered with or replayed.

Approving on the Fireblocks mobile app

Using multi-approver workflows

If you set policy rules requiring multiple approvers to approve a transaction before it can be signed, each approves on their mobile app with the encrypted configuration key on their device. Only after all the approvers approve, the Designated Signer assigned in your TAP rules signs the transaction with the private key share on their device.

See detailed steps in the approving and signing with the Fireblocks mobile app article.

Signing on the Fireblocks mobile app

The signing process for transactions that originate from your Fireblocks Vault includes a secure key ceremony process that for security, separately validates one key share that is stored on an authorized signing device and multiple key shares that are stored by Fireblocks in the cloud.

The full private key is confirmed as the sum of its parts, but the key shares are never combined in one place to act as a potential single point of compromise.

Selecting Authorized Signers for signing on the mobile app

Initially, only your workspace Owner sets up a device with a private MPC-CMP key share stored on it. At that point, when they submit a transaction, they are the only approver and signer.

Therefore, once they approve on their device, they can also immediately sign the transaction. Once your workspace has additional authorized approvers and signers, your transaction authorization policy (TAP) rules dictate who is the Designated Signer for a transaction. Once a transaction receives the required approval(s) based on your TAP, the signing process begins.

See the user roles authorized to approve and sign transactions in the user role access table.

Technical signing steps for a transaction

Transactions that originate from your Fireblocks Vault require the use of the Fireblocks MPC signing mechanism. This section explains the technical signing steps for those transactions.

Fireblocks also enables you to withdraw funds from your connected exchange or fiat account. Your experience is similar when submitting those transactions, however, that process uses configuration keys with your exchanges and does not use Fireblocks MPC keys.

A transaction is first initiated either using the Fireblocks Console or the Fireblocks API. Then there are several stages depending on your TAP rules and transaction type: Submitted, Pending Screening, Pending Authorization, and Queued until reaching Pending Signature. Technical signing steps begin at the Pending Signature step.

See more about these stages in the transaction lifecycle article. At the Pending Authorization stage, a Designated Signer is identified based on your TAP, unless your TAP allows the initiator to be the signer. If the initiator is the signer, then they sign automatically after approval(s). The remaining steps for technical signing before transmitting a transaction to the blockchain are:

1. The Designated Signer’s Fireblocks mobile app notifies them that an approved transaction is ready for signing.
   
   1. If they are also a listed approver in your TAP rule or initiated the transaction, their approval simultaneously approves and authorizes their signing of the transaction. After they authenticate in the app and the key share ceremony is completed, they sign automatically.
2. They follow the prompts in the app to sign and transmit it to the blockchain.
   
   1. They review and confirm the transaction’s details.
   2. They enter their pin code and complete biometric authentication.

3. The Fireblocks mobile app performs a private key share ceremony* to separately validate both the Designated Signer’s MPC key share on their device and two MPC key shares Fireblocks stores in the cloud so that the transaction can be signed.

   *For security, the key share ceremony validating the key share on the Owner’s device and the two separate key shares Fireblocks stores in the cloud is done by a cloud-based mediator. The mobile device does not directly communicate with the cloud servers hosting the other key shares when signing. This ensures all 3 shares are never combined in the same place at once.

4. The transaction is signed using the three key shares individually, one after another.
   
   

   Important

   Since the three key shares are never combined in one place either in the cloud or on the same hardware, this distributed MPC signing scheme ensures a unified private key can never be a single point of compromise.

Biometric authentication

The Fireblocks mobile app does not store biometric data like fingerprint or facial recognition data. Instead, biometric data is stored in your device’s secure environment - either the secure enclave for iOS devices or the Trusted Execution Environment (TEE) for Android devices.

Changing your biometric data will cause an error message the next time you try to take any action requiring authentication in the Fireblocks mobile app. In this event, you are prompted to do a recovery if you are the Owner or re-enroll your device if you are a Signer or Approver. Read more in Key Share Recovery for an Owner’s device and re-enrolling mobile devices.

These high-level diagrams represent the Apple and Android TEE implementations of the MPC signing application on supported mobile devices.