Encrypt & Decrypt
Encrypt attributes for security purposes or decrypt them for purposes of integration.
To provide brands with the utmost flexibility, MXO provides functions allowing for the encryption of a raw value or decryption of an encrypted value using 128, 192, or 256 bit keys.
Implementation
Medallia's implementation of encryption/decryption uses the AES (Advance Encryption Standard) algorithm in CBC (Cipher Block Chaining) mode with PKCS5Padding transformations designed to be compatible with other secure platforms.
The functions mirror JAVA implementations of encryptWithManagedIV() and decryptWithManagedIV() methods as outlined in the Sample Java class to decrypt AES128 encryption article, available on StackExchange. The value generated from encryption uses a random Initialization Vector (IV) value and is output as a Base64-encoded string. There is an expectation that the value to decrypt is also provided as a Base64-encoded string with the Initialization Vector stored as the first 128 bits (16 bytes) of the encrypted Blob.
Secret Key Requirements
- You must provide a 16-, 24-, or 32-byte value to use as a key.
- The key can be either:
- A static value.
- A value referenced from a fixed-key datastore.
Encrypting Data
Example Use Case
A brand want to surface an encrypted version of the TID. They can create an Eligibility Rule to expose the encrypted value.
Example Eligibility Rule
encrypt tid with key "aaCEc6rBZ33xhWt9"
Decrypting Data
Example Use Case
A brand are capturing an encrypted key attribute and want to decrypt that attribute for sharing in a Push Structure. They can create an Eligibility Rule to decrypt the existing value using the defined key.
Example Eligibility Rule
decrypt Encrypted Key with key "aaCEc6rBZ33xhWt9"
Visualizing Results in Monitor
Because both functions are wrapped in Eligibility Rules you can use MXO pull structures to visualize the encrypted and decrypted values being generated.
- Create a new Pull Structure that references the Eligibility Rules containing the encrypt or decrypt functions. Note: The sample structure includes both the encrypted and decrypted values from the example use cases, above, to ensure everything is working in both directions.
- View the Pull Structure in Monitor. MXO displays both the encrypted and decrypted values. Note: Be aware that the values for the Encrypt Eligibility Rule, seen in green below, update constantly, as the Initial Vector, a random value, changes on each refresh.
Using a Fixed Key Datastore to Hide Key Values
Brands may not want to have the secret key value stored as plain text in an Eligibility Rule. You can hide the key value, by holding the key in a fixed-key datastore and referencing that key through a Datastores Data Adapter.
Step 1: Create a Fixed Key Datastore
Create a new datastore with three columns to hold a fixed key and other, related, data.
Attribute | Key | Data Type | Description |
---|---|---|---|
category | PK | Text | The primary key that will group the entries. For example, KEYS |
setting | SK | Text | The secondary key that has a specific setting for the category. For example, ENCRYPTION_KEY |
data | Text | The data specific to the setting. In this case, the value of the encryption key to use. |
The datastore must contain a row that has the following values:
Category | Setting | Data |
---|---|---|
KEYS | ENCRYPTION_KEY | aaCEc6rBZ33xhWt9 |
For more information about Datastores, see an How much information can I view in the Details Panel?.
Step 2: Create a Datastore Data Adapter
Now that you have a datastore, you can create a Data Adapter that uses the fixed key value you specified (KEYS) to expose all the rows in that datastore having a category with the value KEYS. Your Data Adapter should also expose both the setting and data attributes, allowing you to access the specific setting required.
For more information about using fixed keys in your Data Adapter, see Datastores Data Adapter
Step 3: Create an Eligibility Rule to Expose the Encryption Key
After creating your Datastores Data Adapter, you can create an Eligibility Rule that exposes the encryption key row in the datastore. The rule looks for the row in the Data Adapter that has a secondary key (setting) returning the correct data attribute.
After creating that rule, you can use it with the encryption and decryption functions as the required secret key value.