Encrypting identity graph data using Keymaster

Keymaster is a self-serve encryption feature from Index Exchange (IX) that allows Real Time Identity (RTI) providers to protect their identity graph data using asymmetric key pair encryption. For instructions on how to encrypt identity graph data, see Encrypt identity graph data.

How it works

Keymaster has the following two main functions:

  • The collection of keys and key versions for encryption
  • The encryption of identifiers with the keys

The steps in the Keymaster process are detailed below.

Step 1

The RTI provider calls the authentication endpoint to retrieve their access token.

Step 2

Using their access token and provider ID, the provider calls the Keymaster API to create and then get their RSA public key and key pair version.

Step 3

The RTI provider encrypts the people-based identifier using the public key. As part of the standard Optimal Asymmetric Encryption Padding (OAEP) scheme, the people-based identifier is further encrypted with a "salt" value. This makes sure that each identifier will be different every time it's encrypted.

The key and key version can be changed or updated at any time. By changing the key version, identity graph providers can gracefully fall back on any previous key pair version if the correct keyID is specified in the response, or they can quickly update to a new key pair version in the event of a graph leakage.

Step 4

Optionally, RTI providers can transmit audience files to IX that are populated with hashed people-based identifiers. These audience files should be populated with the identifiers that have been encrypted using the public key created in step 2, so that when they are decrypted, a match can occur.

Step 5

Every time a user visits a publisher page, the IX Identity Library™ checks to see if there is a cached people-based identifier and key version for that user in local storage. If the cached identifier and key version are present, no call is made to the RTI provider endpoint and the identifier and key version are passed directly to the IX ad server (see 5a in the diagram above).

If there is no people-based identifier found in local storage, the IX Identity Library calls the RTI provider endpoint. RTI providers respond with the key version and associated people-based identifier, which is encrypted with the public key (see 5b in the diagram above).

Note: For every network call, the encrypted identifier for a user rotates because of the salt value attached to it, making it virtually impossible for a third party to intercept.

Step 6

The IX Identity Library collects the encrypted identifier and passes it to the ad server, which ingests both the public key-encrypted identifier and the key version. The key version instructs IX on which version of the private key to use to decrypt the public key-encrypted identifier.

Step 7

Optionally, the decrypted people-based identifier can now be used for audience lookups in the IX ad server against the hashed identifiers that were previously sent in the audience file transfer in step 4.