VMware Blockchain uses decentralized key generation and multi-signature schemes.

During the initial system setup, each Replica node starts with an assigned set of bootstrap keys. An operator generates these keys, which are used by the BFT consensus mechanism to agree on the published keys.

Every Replica node must generate a new set of private and public keys for the system to become operational and handle external requests. The keys must be published to the rest of the Replica Network using the previously assigned bootstrap keys and the consensus mechanism.

After the new key pair is published, the old one is deleted from all the Replica nodes. The new keys are saved on the VMware Blockchain reserved pages.

Every message transmitted on the Replica Network is then signed with the Replica node private key using the multi-signature scheme. To verify the signature, the receiver of the message must know the signing parties' exact order. The receiver also gets a bit-vector of signers with the message transmitted with a multi-signed message.

Transaction Signing and Verification

A mechanism for transaction signing and signature verification is required to support non-repudiation. This mechanism lets the platform verify that every command originates from the right place so that commands are executed successfully and not rejected by the Replica Network.

The Client nodes’ private key signs all transactions sent from the Client nodes to the Replica Network. The Replica Network verifies the signature before executing the command. If there is an attempt to dispute the execution of a command, the signed transaction can be retrieved to establish that the Replica Network received the request from one of the Client nodes.

You must enable the transaction and signature persistency to retrieve a signed transaction. Activating the transaction and signature persistency has performance and storage implications. Therefore the following configuration options must be considered:

  • The default option stores only the transaction signature and not the transaction itself. Therefore, the impact on storage and performance is negligible.

  • The disable option does not have persistence. The signature is verified but not persisted, so there is no impact on storage and performance.

  • Storing the transaction and the signature on-chain option requires double storage capacity and causes performance degradation. Therefore, this option is recommended only for customers with low volumes of transactions.

Replica and Client Node Key Rotation

For security reasons, a system operator must be able to replace the Replica or Client node keys. The operation of changing keys is called key rotation. The key rotation operation does not require any downtime.

An operator can initiate the rotation of the keys of a specific Replica or Client node or rotate the keys for all the Replica or Client nodes in a command.

Key rotation is initiated from the reconfiguration tool. The private key of the operator signs the request for the key rotation, and the Replica Network validates the signature of the request before execution like any other command. For the operation to be successful, the platform must reach a consensus of N-f Replica nodes. The following keys can be rotated:

  • Replica node consensus signature keys

  • Client node signature keys

  • Client node BFT client pool TLS keys

  • Replica node Inter-replica TLS keys

  • Daml Ledger API TLS key

After the keys are rotated, the operation is logged on-chain, and relevant nodes are informed about the new keys.

Replica and Client Node Key Secure Store

The Replica and Client node Signature keys, Ledger API, and TLS keys are stored on the Replica and Client node VM disks securely.

The Signature and TLS keys are encrypted using a symmetric key and stored on the disk in their encrypted form. Then, the same symmetric key is used to decrypt them. The symmetric key is generated randomly with AES 256 encryption and loaded into the blockchain platform to encrypt the secrets that secure the messages and TLS connection. The platform only exposes a restricted API to the Replica or Client VM to define where to store the symmetric key.

The symmetric key can be stored in the following ways:

  • An encrypted file on the Replica or Client node VM disk.

    The file is encrypted with a fixed password. This option provides minimal security for encrypting the symmetric key. Therefore, this option is seldom recommended.

  • A Virtual Trusted Platform Module (vTPM).

    A vTPM is a software-based representation of a physical Trusted Platform Module 2.0 chip that acts as any other virtual device. For vTPM details, see Virtual Trusted Platform Module Overview.

    You can configure vTPM in the infrastructure descriptor file for deployment. See the Understanding the Infrastructure Schema Parameters in the Using and Managing VMware Blockchain .

  • A USB hardware security module (HSM) device.

    The YubiHSM2 USB HSM device complies with NIST FIPS 140-2 Level 3. See https://www.yubico.com/product/yubihsm-2-fips/. As a hardware-based solution, it is both inexpensive and portable. Every ESXi host in a deployment must have a USB HSM device.

    You must deploy the USB HSM manager OVA file. Then configure USB HSM in the infrastructure descriptor file for deployment. See the Understanding the Infrastructure Schema Parameters in the Using and Managing VMware Blockchain .