Database Backup

The CORE database is spread across EP and Partner servers. The database on EP contains the data relevant to the EP's role in the MPCClosedMultiparty computation - A methodology for parties to jointly compute a function of their inputs while keeping those inputs private. computations. The database on Partner contains the data relevant to the Partner's role in the MPCClosedMultiparty computation - A methodology for parties to jointly compute a function of their inputs while keeping those inputs private. computations. Each database is meaningless when considered without its counterpart. Nonetheless, to mitigate attempts to combine both parts, each database is encrypted at rest by the system key created during the server's bootstrap.


Two Encrypted Archives

The backup of the CORE database is performed separately by each server in the EP-Partner pair and the result follows the same separation and protection pattern as applied to the database at rest. The encrypted backup is embedded into a tar.gz archive file that includes the following:

  • The encrypted database of the server.
  • The digest of the database.
  • Textual backup metadata.

Backup Methods

The CORE database backup can be done using one of the following methods:

  • Manual backup. It is performed separately on the EP and its Partner server. Both procedures must start within one hour.

Backup Best Practice

The encryption of the CORE database backup and its decryption uses an asymmetric key that is owned and managed by the CORE system admin (outside of the CORE database):

  • The public key (used for encryption during the backup) may be kept in the system - making the system ready for backup.
  • The private key (used for decryption during the restore) should be kept outside of the system.

We recommend:

  • Using different keys for EP and Partner database backup encryption.
  • In the CORE cluster:
    • Use one key for all EPs, and a different key for all Partners.
    • Rotate the backup procedure among the different pairs.

Not Included in the Backup

CORE backup addresses data stored in its database. It doesn't include CORE customization that is done elsewhere. In particular, it doesn't include customization in the following areas:

  1. System configuration files such as Server.xml File and File.
  2. Files in the CORE Client Certificates Folder on EP.
  3. Note
    To access the restored partitions from EP you will need to restore their certificates on EP or to re-register EP as their client.

  4. Certificates that were added to support custom KMIPClosedKey Management Interoperability Protocol - an extensible communication protocol that defines message formats for the manipulation of cryptographic keys on a key management server server requirements. SeeCustom KMIP Server Certificate.
  5. Backup key and configuration files.

Any changes to these items require a custom backup.

Prerequisites Overview

The CORE backup procedure refers to data and settings in the following files on EP and its Partner servers:

  • A keystore file with the backup key. See Keys and Keystores.
  • Automatic backup also depends on its settings. See Automatic Backup Settings.
  • By default, the CORE backup uses the following folder to store its output:
    • Linux: /var/lib/ekm/data/backup
    • Windows: C:\ProgramData\dyadic\ekm\data\backup

      It must be writable by the Windows service account named UnboundTech.

Keys and Keystores

  • Asymmetric key. The encryption and decryption of a single CORE backup archive use an asymmetric key managed by the CORE system admin:
    • The public key is used to encrypt the archive during its backup. It is kept in the system making it ready for recurrent backup procedures.
    • The private key is used to decrypt the database during its restoration. It should be kept outside of the system.
  • Keystore. CORE backup and restore procedures assume that the encryption and decryption keys, their security, and the required crypto operations are provided by one of the Java Security Provider software packages available on the server. In Java 8 and Java 11 environments, we recommend using the following:
    • providername SunJCE.
    • storetype JCEKS.

Automatic Backup Settings

The automatic backup uses settings in its configuration file:

  • Linux: /var/lib/ekm/data/
  • Windows: C:\ProgramData\Dyadic\ekm\data\

Example of the backup configuration file:


Generating Prerequisite Data

To generate the prerequisites, perform the following steps (see example in Backup Prerequisites Quickstart):

  1. Create an RSA key and save it in the JCEKS keystore that will be used by the Restore procedure.
  2. Save the public part of the key in a different JCEKS keystore that will serve the Backup procedure.
  3. Move the backup keystore to the permanent location.
  4. Generate configuration file for the automatic backup.
  5. In the CORE cluster - distribute the generated keystore and configuration files:

    1. from the EP - to the rest of the EPs.
    2. from the Partner - to the rest of the Partners.

Backup Prerequisites Quickstart

Manual Backup Quickstart

Both EP and Partner backup procedures should start at nearly the same time. In any case, the gap between the starts of both procedures must not exceed the key material refresh-interval (seeRefresh and Sync Timers ).


On EP:

On Partner:

We repeat the same command:

Automatic Backup Quickstart

The Automatic backup (also known as API-based backup) is triggered using one of the following methods:

It performs the following:

  • Triggers coordinated backup on both EP and its Partner.
  • Monitors the progress of the backup on both servers.
  • Performs ekm_verify_backup once both backups are completed.
  • Saves the result and the backup parameters.

The following quickstart uses curl to trigger the backup, check its progress, and the result.



  1. Encode the Root SOClosedSecurity officer - UKC partition administrator role. credentials so@root:<Password> in the Base 64 format ("Basic authorization").

  2. Start the backup:
  3. curl -X POST "https://<EP>/api/v1/backup" \
    -H "accept: application/json" \
    -H "authorization: Basic ***********" -k | jq.exe

    It returns the backup ID and its status:

    "id": "7271a7e8ea24b369",
    "state": "IN_PROGRESS",

  4. To check the progress of the backup, probe the status using the returned ID:
  5. curl -X GET "https://<EP>/api/v1/backup/7271a7e8ea24b369" \
    -H "accept: application/json" \
    -H "authorization: Basic ********" -k | jq.exe jq.exe

    "id": "7271a7e8ea24b369",
    "state": "IN_PROGRESS",

  6. Once the process is finished, GET  presents the result:
    • The TEST_SUCCESS indicates that the backup was completed successfully. For example:
    • { "id": "7271a7e8ea24b369", "state": "TEST_SUCCESS", "date": "2020-08-20T12:11:38Z", "file": "database_2020-08-20-12-11-37.tar.gz", "pairHostnames": [ "EP : ep1", "Partner : partner1" ], "version": "2.0.2007.45974",

      In case of mismatch between key material on both servers, the result indicates the mismatching keys. In such a case, use CORE key delete command to remove the partial key data.

      "digestDiff": { "diffRecords": [ { "sectionDiff": "Mismatch in KEY count. \ EP digest count : 87, Partner digest count : 88", "entriesDiff": [ { "objectType": "KEY", "digestSource": "Partner", "uid": "0x0063858a832dc39a59", "name": "256AES", "partitionName": "part4", "version": "1", "detail": "exists only in Partner" }] }] }