Introduction
To access your assets you need your signing key. Under Utila's MPC protocol, the signing key is split into two key shares; each in a separate physical location. When signing a transaction, Utila reconstructs the key from its shares.
Examples of where to store your private key are on a decentralised file system or different regions of a cloud provider; on different devices like USB flash drives, hardware wallets, or written on a piece of paper and stored in a safe box.
Managing risks
Utila never holds the client's entire key. Under Utila's MPC protocol, there are two key shares that are stored in two separate physical locations
One key share is stored on the cloud service managed by Utila
Its corresponding key share is stored on the device used for signing transactions (mobile device with Utila app or co-signer machine).
Consequently, it is crucial to keep this architecture in mind when granting access to users, provisioning devices, and especially considering various operational elements to ensure maximum business continuity and operational efficiency.
Losing access to all of your team's key shares, may mean that you are locked out of your funds.
When access to all your devices is lost, losing access to assets is much more probable than you might expect, due to the inherent vulnerability of mobile devices.
Following are practices you can follow to manage the risks.
Personal Backup recovery phrases
Keep your recovery phrases in a safe place. Without these, you will need the admin quorum to approve any new device you use.
Recovery phrases should be managed collectively at the organizational level by your security team or security stakeholder. For example, written on a piece of paper and stored in a safe box.
Assign multiple users with signing privileges
When setting up your Utila vault, you should assign at least two other vault users with user roles that have transaction signing privileges (either Admin or Signer user roles).
Admins should provision at least one additional spare device set up and stored securely.
Create a Vault Key backup
Utila’s disaster recovery solutions are designed to ensure customers can access their assets in the unlikely event of a non-recoverable incident. In the event that all devices and all recovery phrases are lost, you need to recover using your vault key backup.
Backups are created at the vault level.
Both key shares (e.g., ECDSA, EdDSA) in the vault are encrypted and made available for export. This export is known as the encrypted vault backup or recovery package.
The customer retains the ability to decrypt and access the key shares. This ensures that assets remain accessible without requiring any further involvement from Utila.
Creating a recovery package is a sensitive security operation and should be done only after careful consideration and agreement. The process requires admin quorum approval and is further protected by the cryptographic signing of the encryption key, ensuring that only authorized users can generate a valid recovery package. Signing the encryption key also enables future wallet keys to be added to the same recovery package without requiring a new one to be created.
Make the Admin Quorum larger
Some actions, like creating a personal backup, assigning user roles, or setting a transaction policy, are extremely sensitive. They should always require a high threshold or the ability to choose specific admins to approve the action.
The minimum is one administrator. but it's recommended to have more in case one administrator is not available when approving operations that may result in the transfer of funds.
Create transaction policies
Policies automate the transaction approval process, either blocking transactions, or sending transactions.
Customize policies to suit the needs of your organization.
Assign user roles carefully
It is important to differentiate between the types of user permissions.
If a user doesn't need to approve actions, they should not be assigned the admin role.
Segregate devices
Consider provisioning a device for operations on Utila that is separate from your day-to-day personal device, thereby reducing the amount of time your signing device is put to day-to-day use (provided your operations can handle this setup).
Provision multiple devices per user
Consider provisioning some devices as spare devices. These should be static and stored securely, to be used as backup devices in case of need.
Periodic Reviews
It is critical to conduct periodic reviews on your entire setup: users, devices, backups, test internal guidelines and processes, and make sure you are adhering to the highest standards of operational redundancy and security.
Recovery events
Device Migration
If you are getting a new phone and want to migrate from one device to another, first recover, then verify, and only then erase.
The iOS and Android migrations do not recover and migrate the key shares, as they are stored in secure enclaves in the devices. Therefore, it is critical to first ensure you have successfully recovered your key shares to a new device.
Only once your successfully verified key shares are loaded to new device - can you go ahead and wipe the old device.
Mobile app deletion and changes to device biometrics authentication
Never delete the mobile app or change biometrics unless instructed to by the Utila Team - the key shares are tied to the Utila app and therefore will be erased when the app is deleted.
You will only be instructed to delete the Utila app if there is a personal backup in place, or if there are additional active devices available to generate new key shares for you.
Team Member Turnover
You should already make sure to put in place a smooth off-boarding process that includes a thorough review of all the team member's access points.
If you have a team member leaving your team, the rule of thumb is similar to device changes: First ensure you have enough active devices with key shares before removing the team member's access.