Non-Repudiation Product Description

Identity Panel implements non-repudiation features to allow organizations to attest that changes have been made through the established Identity Panel web APIs, ensure that data has not been deleted or tampered with in the database, and to tie changes back to user accounts creating them.

Non-Repudiation allows an organization to assert that identity data has not been tampered with.

For SaaS users direct tampering with the database by members of an organization is not available.

For non-SaaS users, it is possible to outsource certificate handling to a third party and publish non-repudiation evidence to the third party. This allows an independent entity to validate that data has not been modified or deleted.

Non-repudiation requires a separate Identity Panel license to be enabled, at which point there is a one-time enrollment exercise to assert a baseline state of the database at the time non-repudiation is enabled.

To enable non-repudiation for non-SaaS deployments, it will be necessary to obtain an ECDSA256 certificate. For non-production environments certificates may be generated with OpenSSL, otherwise they should be purchased from an appropriate certificate authority by the organization or by a third party empowered to manage the certificate on the organization's behalf.

Performance Impact

Adding non-repudiation has a modest performance impact on saving data during scans (on the order of a 1 second per 1000 objects saved, or 2 seconds per 10,000 multi-attributes saved for example). For regularly UI use there is no impact. Use of next-generation certificates is key to achieving this performance, which is why older RSA certificates are NOT supported.

Non-repudiation works in two phases: evidence creation and validation.

Evidence Creation

Every time an object is about to be saved, the following actions are taken:

1. Serialize the object to a stable binary form and append the account name of the requesting user
2. Hash the representation with SHA256
3. Sign the hash with an ECDSA256 certificate (comparable but superior to RSA2048)
4. Save the signature, hash, timestamp, user, object id, and application version number in a separate data collection. This table should be secured or serialized offsite to prevent removal of records.

Validation

A non-repudiation validation exercise may be invoked from the Identity Panel settings interface. This should be performed using a database snapshot on a secondary system as it imposes significant server load for an extended duration, or may be performed offsite by a third party. 

The validation procedure checks each eligible object in the Identity Panel database, and each signature record to enumerate the following claims:

1. Do all objects have a valid signature? If not, how many have a problem? This includes:
   1. Are any objects missing a signature?
   2. Are any of the signatures in the history of an object invalid?
   3. Does a re-hash of the object match the hash of its most recent signature (has the object been modified without signing)?
   4. Does the signature have a valid certificate reference?