PingDirectory

Dealing with a compromised encryption key

When an encryption-settings definition is compromised, all data encrypted with that definition is vulnerable, and you must stop using the definition immediately.

About this task

If an encryption-settings definition becomes compromised, such as an unauthorized individual obtaining access to the encryption key, then any data encrypted with that definition is vulnerable because it can be decrypted using that key. It’s important that the encryption-settings database is protected to ensure that its contents remain secure. For example, using file permissions or file system access control lists (ACLs).

In the event that an encryption-settings definition is compromised, stop using the definition immediately. You must re-encrypt any data encrypted with the compromised key with a new definition or purged from the server. Do this on one server at a time to avoid an environment-wide downtime and complete it as quickly as possible on all servers that used this definition at any point in the past to minimize the risk of data exposure.

To respond to a compromised encryption settings definition:

Steps

  1. Create a new encryption-settings definition and make it the preferred definition for new writes.

  2. Ensure that client traffic is routed away from the server instance to be updated.

    If the PingDirectory server is accessed through a PingDirectoryProxy server, then you can set the health-check-state configuration property for any LDAP external server definitions that reference that server to have a value of unavailable.

  3. To ensure that external clients are not allowed to write operations in the PingDirectory server instance, set the writability-mode global configuration property to have a value of internal-only.

  4. Look at the monitor entries with the ds-replication-server-handler-monitor-entry object class to ensure that the value of the update-sent attribute is no longer increasing.

    This signals that all outstanding local changes are replicated out to other servers.

  5. Stop the PingDirectory server instance.

  6. Delete the replication server database by removing all files in the changeLogDb directory below the server root.

    As long as all local changes have been replicated out to other servers, this does not result in any data loss in the replication environment.

  7. Export the contents of all local DB and changelog backends to LDIF.

  8. Re-import the data from LDIF.

    This causes the data to be encrypted using the new preferred encryption settings definition.

  9. Export the compromised key from the encryption settings database.

    For precautionary measures, do this to back up the key in case you need it in the future, such as if some remaining data was later found to have been encrypted with the key contained in that definition.

  10. To no longer allow the PingDirectory server instance to use the key, delete the key from the encryption settings database.

  11. Start the PingDirectory server instance.

  12. Allow replication to bring the server back up-to-date with any changes processed while it was offline.

  13. To re-allow externally-initiated write operations, change the value of the global writability-mode configuration property to enable.

  14. To allow client traffic to be routed again to that server instance, reconfigure the environment.

    An example is changing the value of the health-check-state property in the corresponding LDAP external instance definitions in the PingDirectoryProxy server instances back to dynamically-determined.