Sidechain “How To”



How to use the Persistent on Client option for CipherTrust CTE Keys

Imagine you have some really important data. To protect that data, you encrypt all of it. 

The way CipherTrust Transparent Encryption (CTE) works is that a little software agent is installed on systems with encrypted data. When a user or application requests access to encrypted data, that software agent evaluates the request: are you authorized to see this data?

If they are, the software applies the key and decrypts the data.

If they aren’t authorized, the software returns an access denied (“sorry, you don’t get to see that data”) or just returns the encrypted data (“hey, you asked for encrypted data, here’s encrypted data.”) depending on how it’s setup.

There’s one catch – this assumes that software agent has a copy of the key. Otherwise, it can’t apply it for authorized users.

How does it get a copy of the key?

It’s pretty simple, really – it gets a copy from the key manager (CipherTrust) and then holds on to it to use when it needs it. 

It’s actually much more complicated because we are, after all, talking about encryption keys. A key manager just can’t go about handing them out. So there’s a bunch of security around this: mutual authentication, certificates are exchanged, a few layers of encryption are added, and finally you get to a secure, trusted way of handing that key out.

So in a normal operating mode, the encryption agent asks the key manager for a key to use, the key manager authenticates the agent and gives out a key. The encryption agent holds on to it in kernel memory and uses it as necessary.

Nothing goes right all the time

It’s an IT adage that nothing ever really goes as planned. Changes occur, either planned or unplanned, systems go offline at the most inconvenient times, people trip over power cords, and maintenance activities take twice as long as anyone thought they should. 

The engineers at Thales, the brilliant minds that produce the CipherTrust platform, know this reality and created a nice feature called Persistent on Client. It’s so deceptively simple – a mere checkbox actually – that you might be left wondering how such a powerful feature was packed into such a simple checkbox.

Here’s how it works

Imagine you have some really important data, and you encrypt all of it. Let’s say this is a huge database that literally powers your entire business, all encrypted to protect it from cyber threats. Maybe you’re a mortgage company, and this is your mortgage processing platform. 

Now imagine the encryption agent loses that encryption key. Every request for data that comes in is met with a denied (“Sorry, I don’t have a key to decrypt the data. You’re out of luck.”). Since your business is powered by this data, when the data is unavailable, your business is unavailable. This is bad – very bad. 

In reality, the encryption agent is very stable and doesn’t just “lose the key.” But in failure situations, it can easily happen. If the server with the agent is rebooted, for example, and can’t connect back to the key managers (countless reasons for this) it won’t be able to get a key. And you’ll be in a world of hurt with your application down until that connectivity is restored. For a business-critical application, minutes of downtime seem like a lifetime.

These things happen more often than you would think. 

The solution: a locked box with a key in it

 Have you every locked yourself out of your house on accident? Then remembered there was a key in the back yard under a rock by the back door? 

That’s what Persistent on Client does. 

This checkbox enables a nifty feature in the encryption agent where it takes a copy of that encryption key, encrypts it with AES, then stores that encrypted key in a file on the server. This encrypted “lockbox” is protected by a password you set.

Then, if the agent ever gets in a situation where it doesn’t have a key and can’t get one from the key manager, it enables you to unlock the key from the local keystore. In Windows, a dialog pops up asking for the unlock password you set. In Linux, there’s a command-line utility you can run.

Once the agent unlocks the key via this mechanism, it can resume normal operations and it never had to connect to the key manager. Talk about a life saver – when recovery is absolutely necessary, this feature will absolutely save you disruption and downtime.

Should I use this feature?

Yes. The short answer is, yes.

We recommend all of our clients use this feature.

Now, there are security implications. After all, technically the encryption key is now persisted on the server itself, not just in the key manager. The key is encrypted and protected with a password, but there is a non-zero risk with this. If you work in a highly regulated environment with extreme compliance and information security requirements (looking at you, Financial Services) you may not be able to use this feature.

But for the rest of us, we highly recommend you turn this on unless you have a really strong reason for not doing so.

Your next steps

Follow these steps to see whether you have Persistent on Client turned on:

  1. Log in to CipherTrust Manager
  2. Select the Domain with the keys you want to verify
  3. In the left-hand navigation, click Keys
  4. Click the key name you want to check
  5. On the key details page, scroll down until you get to the Attributes menu:
  • Click CTE
  • Verify that Persistent on Client is checked

Now ensure you have a password set by following these steps:

  1. Click the Home square (upper left corner)
  2. Click the Transparent Encryption tile
  3. Click Clients
  4. Select the Client that uses the key you’re validating
  5. On the client details page, at the top, make sure that Password Creation Method is set to Manual
  6. Click Change Password button
  • Set the password

If you have any problems with this process or questions along the way, shoot us an email at [email protected] and one of our engineers will be happy to assist you in setting this up.