Uploaded image for project: 'OpenDJ'
  1. OpenDJ
  2. OPENDJ-6594

Backups should use unique symmetric keys and store them with the backup rather than cn=admin data

    Details

    • Type: Improvement
    • Status: Done
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: 7.0.0
    • Fix Version/s: 7.0.0
    • Component/s: backends, security, tools
    • Labels:
      None

      Description

      At the moment encrypted backups are performed as follows:

      1. a symmetric key is acquired from the crypto manager, generating one if needed
      2. a cipher output stream is created using the symmetric key
      3. a ZIP stream is created, wrapping the cipher stream
      4. the files to be backed up are added to the ZIP stream

      Backups with HMAC signature are performed as follows:

      1. A mac key is acquired from the crypto manager, generating one and adding it to admin data if needed
      2. Backup data is hashed with the mac key
      3. The mac key ID is stored in the .info file, it is used to retrieve the mac key from crypto manager at the time of restoring

      There are a couple of issues with these approaches:

      • the same symmetric key is used for all backups, as well as for other purposes such as DB and changelog encryption, although typically DB and backup encryption are not used simultaneously.
      • the keys are stored separately from the data, which may provide a bit more security, but makes the backups less portable since they are effectively "locked" to their deployment
      • the symmetric key encrypts the entire DB content which could be very large and potentially exceed the usage limitations of the key if a transformation like AES/GCM is used for which there is a 64GB limit. (This problem will be fixed with OPENDJ-6723).

      Reference: https://github.com/jedisct1/libsodium-doc/blob/master/secret-key_cryptography/aead.md#limitations

      Acceptance criteria

      This issue may be closed once:

      • the backup mechanism generates new keys for each backup file using a key derivation algorithm that takes a nonce and the master private key and then stores the nonce in the backup file. The HMAC key and encryption key should be different. To restore the backup the restore tool simply needs access to the master private key to obtain the key.
      • we ensure that backups do not use AES/GCM and instead use AES/CBC, which is what we were using in 6.5 and earlier, because this cipher mode has a recommended 2^48 messages usage limit (~ 4 PiB). If users want integrity protection then they can hash/sign the backup. (This is optional because backup files will be small after OPENDJ-6723 is resolved)

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                ondrej.fuchsik Ondrej Fuchsik
                Reporter:
                matthew Matthew Swift
                Dev Assignee:
                Cyril Quinton
                QA Assignee:
                Ondrej Fuchsik
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: