Uploaded image for project: 'EJBCA'
  1. EJBCA
  2. ECA-3461

Add encryption key information to key recovery data in database

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: EJBCA 6.1.0
    • Component/s: None
    • Labels:
      None
    • Issue discovered during:
      Customer

      Description

      Goal:
      In the KeyRecoveryData table, being able to know which key was used to encrypt a specific entry, allowing to use multiple keys (an old and a new), and potentially do key roll-over of the key recovery encryption key.

      New functionality:
      New functionality
      We want to have an indication in the KeyRecoveryData table which key was used to encrypt the data, giving possibility for future functions like key roll-over.
      The CMS message format already includes all information about the specific algorithms used, this information is already present, so new version of EJBCA can use other symmetric encryption algorithms (for example changing AES256_CBC to something else) without changes to the current schema.

      By adding three new columns to the KeyRecoveryData table it will always be possible to figure out which key was used to encrypt the data. Also the CA can change to a new keyEncryptKey and the old data can still be decrypted as long as the old key is available in the CAs Crypto Token. It will even be possible in the future to break the connection between a CA and key recovery data, i.e. use a generic key encryption key for all CAs.

      The new columns in KeyRecoveryData will store:
      cryptotokenid – the id of the Crypto Token where the keyEncryptKey resides, it will be the CAs current Crypto Token id at the time of storing an entry.
      alias – the alias of the keyEncryptKey that is used to encrypt the entry, it will be the CAs current keyEncryptKey at the time of storing an entry
      publickeyid – the key id of the public key corresponding to the private keyEncryptKey used to protect the entry. The publickeyid is calculated as a SubjectKeyIdentifier, same as used in CertificateData table.

      Allowing the new columns to be null avoids the need to complicated upgrade of current entries.
      When alias is null, the same behavior as current is used, i.e. the CAs current keyEncryptKey is used.
      When alias is not null, the key alias in the column alias is used to decrypt the entry. If this alias does not exist, the CAs current keyEncryptKey is also tried (the key may have changed alias name).

      The column cryptotokenid is not used explicitly at this time, but it can be used for trouble shooting if Crypto Tokens are changed for a CA.
      The column publickeyid is not used explicitly at this time, but it can be used for trouble shooting if key aliases are renamed. If you know the key id it will be possible to figure out an exact key (and certificate), regardless of alias name that was used.

      Upgrade:
      The upgrade process consists of adding columns, with value null/0, to the KeyRecoveryData table. The field will not be populated for old entries. The behavior for old entries will be the same as current functionality. If a customer want to take advantage of new functionality for old entries, a manual database command can be used to insert a value in old entries. This will be documented.

      Test:
      A test will be added to the already existing system tests for key recovery:

      Add key recovery data (1) using a CAs specific keyEncryptKey
      Recover the data (1)
      Change the CAs key encrypt key
      Recover the data (1)
      Add key recovery data (2) using the new CAs specific keyEncryptKey
      Recover the data (2)
      Remove the first keyEncryptKey from the CAs Crypto Token
      Recover the data (1), should fail now
      Recover the data (2)

        Attachments

          Activity

            People

            • Assignee:
              tomas Tomas Gustavsson
              Reporter:
              tomas Tomas Gustavsson
              Verified by:
              Mike Agrenius Kushner
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: