Fireblocks API Keys can be created via the web console or the API:

• For creating API keys via the console please check the following guide
• For adding additional API keys please refer to the following API endpoint

API Authentication

Fireblocks API involves a secure authentication process that should be followed both when creating the API key and when calling Fireblocks API with the created key.

The Fireblocks API uses an API key and a request signing process to provide a highly secure communication protocol.

The general process for creating the first API key is the following:

• Create an RSA4096 private key
  • Run:
    openssl req -new -newkey rsa:4096 -nodes -keyout fireblocks_secret.key -out fireblocks.csr -subj '/O=<your_organization>'
• Generate a CSR file from the previously create RSA private key
• Browse to the Fireblocks web console and go to the Settings -> Users -> Add User -> API User
• Give the API key a name and choose the permissions for this key (same permission as user roles )
• Upload the generated CSR file
• Choose if Co-Signer setup is required

Once all of the steps above are done, and the relevant approval quorum was reached, the API Key will be ready in the Users tab and you copy the API Key value.

Every request with this API Key should follow the API Authentication scheme defined by Fireblocks.
Learn more about the required API Authentication here

API Keys Management Best Practices

Your API credentials and accounts are a prime target for hackers. It is important to understand and implement our best practices for working securely with the Fireblocks APIs.

Role-based access control

• When adding API users, ensure that the API user's role is provisioned in accordance with the least privilege principle. Fireblocks supports many different roles for role-based access control, and an API user can be any one of these.
• Create as many API users as needed to separate duties and create security boundaries.

👍

Best Practice

It is best to have 2 separate API users for different functions, such as:

1. A 'Viewer' role that performs read-only operations.
2. A 'Signer' role with transaction signing capabilities.

Create Transaction Authorization Policy rules for API users

API Users with transaction initiation and signing capabilities are able to execute transactions like any other Fireblocks Console user.

It is imperative that you create strong Transaction Authorization Policy (TAP) rules to govern what types of transactions these API users can conduct.

👍

Best Practice

It is best to create TAP rules that limit API users to transact from a specific account and only up to a certain amount. This requires additional approvals or blocks the transaction, preventing users from trying to exceed the pre-defined amount or from transacting from an unauthorized vault account.

Whitelisting IP addresses for API requests

Each API user type on your workspace can whitelist specific IP addresses to only allow API calls from the provided address(es). If there aren't any whitelisted IP addresses for a user, API requests are possible from any IP address.

🚧

Address format requirements

Only /32 IP addresses are accepted. Do not enter addresses as a range of values.

👍

Best Practice

It is best practice to explicitly whitelist the only IPs that you expect to be calling the Fireblocks API.

Generating & storing RSA 4096 private keys

Each API user requires a corresponding public/private key pair used to sign requests. It is imperative that you keep your Fireblocks Secret Key (fireblocks_secret.key) safe and secure.

Ways to keep your public/private key pair secure:

1. Generate a unique CSR file and corresponding public/private key pair for each unique API user, such that if one API user's keys are compromised, other ones will not be.
2. Generate the CSR file and corresponding public/private key pair in an offline (air-gapped) environment for added security.
3. Ensure that your fireblocks_secret.key is stored securely in a hardened environment with advanced security controls such as multi-factor authentication and endpoint protection agents.

Do not embed API keys directly in code or your API code source tree

API keys embedded in code can be accidentally exposed to the public.

👍

Best Practice

Instead of embedding your API keys within your applications, store them in environment variables or in files outside of your API code's source tree.

This is particularly important if you use a public source code management system such as GitHub.

Rotating API keys

If rotating API keys is part of your organization's security policies and best practices, you can delete the existing keys and create new ones. This includes API keys paired with your API Co-Signer(s).

👍

Best Practice

Before you begin, use the Get all API keys endpoint to view all the API keys paired to a specific API Co-Signer in a paginated list.