Rokt values the security of your customers' personally identifiable information (PII) and utilizes best-in-class approaches in protecting it. We exclusively use the HTTPS protocol to communicate between the client application and the Rokt servers. HTTPS provides security by directing the protocol over a Transportation Layer Security (TLS) connection and ensuring the authenticity of all requests and responses, protecting the privacy and integrity of the exchanged data.
If you want an extra layer of security on your customers' PII, you can choose to encrypt the data prior to transfer, and Rokt can decrypt it on receipt.
The encryption of PII is an advanced integration method and requires working collaboratively with the Rokt development team during implementation. It is more effort than a standard Rokt integration for your development team, including ongoing maintenance (e.g., yearly key rotation).
Rokt supports asymmetric key encryption (RSA/ECB/OAEPWithSHA-256AndMGF1Padding) for four data attributes designated as PII (first name, last name, email, and phone number).
First you need to encrypt each attribute individually on your end. As part of the Rokt SDK integration, you provide the encrypted values along with the Key ID (which references which key version was used in the encryption), as well as any non-PII attributes without encryption.
Using the common key, Rokt can decrypt the PII and use it like any other data.
To get started, contact your Rokt account manager who can start the conversation between your development team and the Rokt development team.
Rokt generates and distributes the public/private key pairing. Together we will agree on the definition of the Key ID. You can indicate if you want the keys distributed in a particular way. You should provide the technology you use for your backend and frontend (e.g., C#, Java, Ruby) so that Rokt can test the encryption and decryption process prior to sending.
Make a change to the standard Rokt PII attributes found in the Rokt snippet by adding
Enc to the following key/value pairs:
So the encrypted attributes would be:
All other attributes should remain the same, as specified in the standard documentation or by your account manager. You should not attempt to encrypt any other attribute besides the four mentioned.
For each request/initialization:
- Use your public key to encrypt each PII attribute value individually
- Base64 encode each encrypted value
- Send the following to Rokt:
- Encrypted (and encoded) values with the above keys
- Non-PII key/value pairs as plain text
- Key ID for Rokt to identify the correct key for decryption
When you are ready, contact the Rokt team so that we can verify your implementation.
Rokt supports key rotation on a yearly basis (or longer). Key rotation will need to be manually coordinated.