CMK Tenant Security Client

The Tenant Security Client is an SDK which provides a simplified interface for making requests to the Tenant Security Proxy. It provides method calls for encrypting and decrypting tenant data either as a single document or in batch operations.

All data passed to the SDK is encrypted directly within the SDK. Your customers’ data is never transferred to the Tenant Security Proxy. Instead, the Tenant Security Proxy is responsible for generating document encryption keys (DEKs) and encrypted document encryption keys (EDEKs) and providing them to the client, which uses the key to do the encryption work. If these acronyms are confusing, envelope encryption will give you a better sense of how these keys are generated and used.

On an encrypt operation, the client sends a request to the Tenant Security Proxy to generate and encrypt a DEK using your customer’s KMS. The Tenant Security Client then uses this DEK to AES encrypt the provided data. An Encrypted Document Encryption Key (EDEK) and the encrypted data are returned to your application to be persisted. The unencrypted DEK is immediately discarded.

The cardinal rule for CMK is that you, the vendor, are never given access to the unencrypted DEK. You store the encrypted DEK alongside encrypted application data. Since only the customer can unlock the EDEK, this pattern gives your customers independent access control and an independent audit log.

On a subsequent decrypt call, your application provides the encrypted DEK and the encrypted data to the Tenant Security Client, which will use the Tenant Security Proxy to decrypt this EDEK. The EDEK decryption, or unwrapping operation, is done in conjunction with your customer’s KMS, producing the original DEK used to encrypt. This resulting DEK is passed back to the Tenant Security Client, where it is used to decrypt the data back to its original form.

SDK Languages

The Tenant Security client library is provided in multiple languages:

• Java
• NodeJS
• PHP
• Go