A Successful Integration: RegData Protection Suite (RPS) and Thales CipherTrust
Laurent Chuat
Security Consultant
We are happy to announce a new integration between two major partners of Kyos: RegData and Thales. RegData Protection Suite (RPS) is now able to use Thales’ CipherTrust Manager as a key management solution (KMS). We are very excited about this news, as this will allow us to propose a data-protection solution that is secure, scalable, and tailored to each application’s requirements.
But to fully understand this integration, we need to take a step back and cover some basics of data protection.
Table of contents
Add a header to begin generating the table of contents
Data Protection: Why and Where
Many strategies can be employed to prevent attackers from penetrating a system. These include intrusion detection systems, VPNs, firewalls, and more. While these measures are crucial for defending against external threats and controlling access to a network, they fall short in safeguarding data from internal threats and more sophisticated attacks. Such defenses often fail to protect the data once an intruder has bypassed the initial barriers. Furthermore, with the advent of the cloud, the concept of “network perimeter” has become increasingly blurry. This is where data protection becomes indispensable. As data breaches are both costly and highly damaging to a company’s reputation, it is essential to go beyond the traditional approach of network-perimeter security.
Protecting sensitive data with cryptography therefore appears as an obvious choice, but there remains the question of where to apply encryption exactly. Indeed, cryptography can be integrated into an existing system in a variety of ways. From the bottom of the stack to the top, here are a few examples of where encryption can be used:
- at the storage level, to encrypt an entire storage device;
- at the file-system level, to transparently encrypt individual folders/files and protect data at rest;
- at the database level, to encrypt specific columns;
- at the application level, to selectively transform sensitive data early, either from the application itself or through a dedicated proxy.
These different approaches are not exclusive—they can (and often should) be used conjointly. Each method has its pros and cons. But protecting data at the highest layer (i.e., the application layer) has many advantages. It allows for fine-grained control over what data is protected, enabling the protection of specific elements rather than encrypting entire files or databases. This approach is particularly useful for protecting personally identifiable information (PII) such as names or account numbers. Additionally, application-level encryption can be tailored to the needs of specific applications, allowing developers to implement custom protection schemes (data transformations) that may preserve a specific format, for example. Furthermore, protecting data at the application layer keeps it secure through its lifecycle, ensuring that sensitive information remains protected both at rest and in transit. Finally, it is also possible to configure how the data is revealed (or not), depending on the context of the request (i.e., who is requesting the data and how).
RegData Protection Suite (RPS)
Protecting data at the application level: This is where RegData comes in. Their platform, RegData Protection Suite (RPS), goes beyond simple data encryption and offers a range of highly configurable transformation methods such as pseudonymization, anonymization, tokenization, and encryption.
RegData can be adopted with two main integration patterns: either a proxy is introduced between the application server and the client to intercept and transform data, or the data is transformed from the application using a library that calls the RegData API.
Another major benefit of RegData is contextual protection: for example, it is possible to configure whether/how data is revealed to the client, depending on various attributes. For example, a sensitive piece of data could be fully revealed to a group of users while remaining tokenized to another group.
What is tokenization?
Tokenization replaces sensitive data elements with non-sensitive equivalents, called tokens, that have no exploitable value. This process is ideal in scenarios where data needs to be processed or analyzed but must remain confidential.
For example, in the handling of bank account numbers such as IBANs, tokenization can replace the actual IBAN with a fake IBAN (a token). This way, the sensitive data is kept secure, while the token can be used in the data environment without risk. This is especially useful in financial services, where privacy and security are paramount yet data is required for processing transactions and performing analytics. The tokenization process can also be configured to ensure that the tokenized IBAN looks like an IBAN, meaning that it retains some properties like format or checksum computation.
CipherTrust Manager as a KMS
So why integrate RegData with CipherTrust? To answer this question, we need to talk about keys. In the context of data protection, a question just as important as how and where encryption is applied is how and where keys are stored. As a compromised key can compromise the security of the whole system, protecting keys is obviously paramount.
Thales offers a wide range of products and features for data protection under the CipherTrust brand. At the center of this offer is CipherTrust Manager. One of the main roles of this manager is to act as a key management solution (KMS), not only for products that are part of the CipherTrust offer, but also for third-party solutions. CipherTrust Manager can thus create, store, use, and provide keys to clients through various protocols (including a REST API).
Using a KMS enhances security by storing all cryptographic keys in a single, secure location. Key centralization minimizes the risk of unauthorized access and simplifies the oversight of these critical assets. By leveraging Thales’ CipherTrust Manager, RPS gains key protection and management features that help in preventing potential breaches.
Moreover, the separation of duties is clearly defined in this integration. CipherTrust manages the cryptographic keys, while RegData handles the data transformations. This separation ensures that no single entity has complete control over both the keys and the data. By maintaining a clear boundary between these functions, organizations can further enforce security policies and comply with regulations that demand strict access controls and audit trails.
The benefits of integrating RPS with an external key manager like CipherTrust thus include enhanced security, compliance, and flexibility. It allows organizations to manage keys across multiple environments, be it cloud or on-premises, without sacrificing control over their cryptographic keys. Furthermore, the use of an external KMS like CipherTrust provides scalability and resilience, ensuring that key management capabilities can grow with the business needs.
Physical Protection with an HSM
To go one step further with the protection of cryptographic keys, it is possible to use a hardware security module (HSM) as a root of trust. Thales has its own range of compatible HSMs (under the Luna brand), but third-party HSMs are also supported in CipherTrust Manager.
So why use an HSM? The problem with the long-term storage of keys is that, if a key is stored on regular hardware, there is always the possibility that someone with physical access to that hardware will be able to extract the key. An HSM is a physical device designed to address this problem.
The HSM can be configured to act as a root of trust for the entire system: to protect its secrets, CipherTrust Manager uses a series of keys that stems from a non-exportable key generated and protected by the HSM. In other words, that root-of-trust key is created by the HSM and can never leave it. Even for an attacker with physical access to the HSM, it will be virtually impossible to retrieve the key because the HSM was specifically designed not only to detect any such attempts but also to prevent them.
Technical Details of the Integration
Now let’s dive into some of the nitty-gritty details of the integration. How does RPS access the keys that are stored and protected by CipherTrust Manager?
As RPS uses different types of keys (not just AES or RSA keys, for example), so-called opaque keys are employed in CipherTrust Manager. Opaque means that the keys are not treated as generated by a specific algorithm or with a specific format but are instead just stored as a blob of data. These opaque keys are then used to encrypt data in RPS. Therefore, these opaque keys take on the role of data-encryption keys (DEKs) here.
Then comes the question of how to securely export the keys, i.e., transfer them from CipherTrust Manager to RPS. For this purpose, the REST API is used over HTTPS. This implies that an authenticated and confidential tunnel is created by TLS to transport the keys. However, the possibility that the keys could be intercepted by network equipment (through TLS termination) must be considered. This is a common scenario for many organizations. For this reason, an additional AES key is used to encrypt every opaque key. This AES key therefore acts as a key-encryption key (KEK). As every DEK has its own unique KEK, the total number of keys is doubled.
Now it would seem that we are back to square one, because the KEK must be exported as well, but there is a trick we can use with AES keys. Indeed, CipherTrust Manager provides an API endpoint that allows us to wrap an AES key with a public key before exporting it. The private key that corresponds to the public wrapping key will never have to be revealed. This way, RPS can securely retrieve the AES KEK (even with a TLS termination proxy intercepting traffic), retrieve the opaque key (i.e., the DEK), and decrypt it with the KEK.
Conclusion
This integration gives us a complete and mature system for application data protection. With this solution, we will be able to tackle a range of challenges and offer our customers tailored security configurations that fit each of their requirements. As we have seen, the benefits of this integration are numerous: flexibility, scalability, security, separation of concerns, and more. We are very excited by this development and look forward to supporting more and more customers with the deployment of this solution.
More information on this subject?
We are at your disposal!