Back Custom print Link Text Only Rich Text Print

  • CRA-5.4 CRA-5.4 Cryptographic Keys and Wallet Storage

    • CRA-5.4.1

      Licensees must implement robust procedures and protective measures to ensure the secure generation, storage, backup and destruction of both public and private keys.

      Amended: April 2023
      Added: April 2019

    • CRA-5.4.2

      In order to access crypto assets, the device on which the private key is held needs access to a network (which, in most cases is through the internet). A wallet where the private key is held on a network attached device is called a hot wallet. Hot wallets are vulnerable to hacking attempts and can be more easily compromised by viruses and malware.

      Added: April 2019

    • CRA-5.4.3

      Crypto-assets that do not need to be immediately available must be held offline, in a 'cold wallet' (refer to CRA-8.1.9).

      Amended: April 2023
      Added: April 2019

    • Password protection and encryption

      • CRA-5.4.4

        Both hot and cold wallets must be password protected and encrypted. The key storage file that is held on the online or offline device must be encrypted. The user is therefore protected against theft of the file (to the degree the password cannot be cracked). However, malware on the machine may still be able to gain access (e.g., a keystroke logger to capture the password).

        Amended: April 2023
        Added: April 2019

      • CRA-5.4.5

        Licensees must use multi-signature wallets (e.g., where multiple private keys are associated with a given public key and a subset of these private keys, held by different parties, are required to authorise transactions). Noting that there is no way to recover stolen or lost private keys unless a copy of that key has been made, multi-signature wallets offer more security because a user can still gain access to its crypto-assets when two or more Private Keys remain available. (see also CRA-4.1.2 and CRA-4.1.3).

        Amended: April 2023
        Added: April 2019

    • Off Line Storage of Keys

      • CRA-5.4.6

        To mitigate the risks associated with hot wallets, private keys can be stored in a cold wallet, which is not attached to a network. Licensees should implement cold wallet key storage where possible if they are offering wallet services to their Clients.

        Added: April 2019

    • Air Gapped Key Storage

      • CRA-5.4.7

        Wallets may also be stored on a secondary device that is never connected to a network. This device, referred to as an air-gapped device, is used to generate, sign, and export transactions. Care should be taken not to infect the air-gapped device with malware when, for example, inserting portable media to export the signed transactions. Hardware security modules emulate the properties of an air gap. A proper policy must be created to describe the responsibilities, methods, circumstances and time periods within which transactions can be initiated. Access and control of single private keys should be shared by multiple users to avoid transactions by a single user.

        Amended: April 2023
        Added: April 2019

    • Password Deliver Key

      • CRA-5.4.8

        Some wallet solutions enable cryptographic keys to be derived from a user-chosen password (the "seed") in a "deterministic" wallet. The most basic version requires one password per key pair. A Hierarchical Deterministic wallet derives a set of keys from a given seed. The seed allows a user to restore a wallet without other inputs.

        Added: April 2019

      • CRA-5.4.9

        Licensees offering deterministic wallet solutions must ensure that users are provided with clear instructions for situations where keys, seeds or hardware supporting such wallet solutions are lost.

        Added: April 2019

    • Private Key Management

      • CRA-5.4.10

        A licensee must establish and implement strong internal controls and governance procedures for private key management to ensure all cryptographic seeds and private keys are securely generated, stored and backed up. A licensee using a third party crypto-asset custodian must ensure that the third-party custodian establishes and implements such controls and procedures. The procedure must include the following:

        (a) The generated seed and private key must be sufficiently resistant to speculation or collusion. The seed and private key should be generated in accordance with applicable international security standards and industry best practices, so as to ensure that the seeds (where Hierarchical Deterministic Wallets, or similar processes, are used) or private keys (if seed is not used) are generated in a non-deterministic manner that ensures randomness so that they are not reproducible. Where practicable, seed and private key should be generated offline and kept in a secure environment, such as a Hardware Security Module (HSM), with appropriate certification for the lifetime of the seeds or private keys;
        (b) Detailed specifications for how access to cryptographic devices or applications is to be authorised, covering key generation, distribution, use and storage, as well as the immediate revocation of a signatory’s access as required;
        (c) Access to seed and private key relating to crypto-assets is tightly restricted among approved persons, no single approved person has possession of information on the entirety of the seed, private key or backup passphrases, and controls are implemented to mitigate the risk of collusion among authorised personnel; and
        (d) Distributed backups of seed or private key is kept so as to mitigate any single point of failure. The backups need to be distributed in a manner such that an event affecting the primary location of the seed or private key does not affect the backups. The backups should be stored in a protected form on external media (preferably HSM with appropriate certification). Distributed backups should be stored in a manner that ensures seed and private key cannot be re-generated based solely on the backups stored in the same physical location. Access control to the backups must be as stringent as access control to the original seed and private key.
        Added: April 2023

    • Private Key Storage Policy

      • CRA-5.4.11

        Licensees must establish, maintain and implement a private key storage policy to ensure effective and prudent safekeeping of the seed and private key at all times. In particular, such policy must address:

        (a) The keyman risk associated with the storage of seed and private key is appropriately addressed;
        (b) The seed and private key can be retrieved at a short notice without excessive reliance on one or more individuals who may be unavailable due to death, disability or other unforeseen circumstances; and
        (c) Where a licensee maintains a physical copy of the seed and private key, the physical copies of seed and private key must be maintained in Bahrain in a secure and indestructible manner and the same can be used to access the wallets if a need arises.

        The private key storage policy along with other documents and evidences confirming that the seed and private key are held securely must be made available to the CBB upon request.

        Added: April 2023