listen to this article:
A common challenge application architects and developers face is the need to encrypt application data. As more attacks penetrate secure networks, we see that the standard perimeter and network protection is no longer sufficient. Today, the common recommendation is to encrypt the data that must be secured. With the requirement to encrypt data, developers are now facing a new set of challenges:
- How to encrypt the application data?
- How to keep the application working with encrypted data?
- How to protect the encryption keys?
Choosing the Right Encryption Method for Your Application
Here is just a subset of questions you need to answer to select the proper encryption methods for your application:
- Which encryption method should I use (symmetric or asymmetric)?
- Which algorithm should I use (RSA, ECIES, AES, 3DES, etc.)?
- Which key size should I use?
- Which mode of operation should I use (for example, PKCS#1 v1.5 or v2.1 for RSA; AES-CBC, AES-CTR, AES-GCM, or AES-CCM)?
- How should I use it correctly (for example, random IV or just non-repeating)?
- How should I deal with error messages?
This is a multi-step process in which one step that is implemented incorrectly can cause security risks.
Multiple systems have been left vulnerable by an improper choice of method or an improper implementation. For example, padding oracle attacks on CBC encryption are very common, and RSA-key-wrapping vulnerability has been found in HSMs and smart cards due to the use of PKCS#1v1.5.
Make Sure Your App is running With Encrypted Data
Assuming you have done the research and found the proper encryption scheme for your data, including decisions such as which key size and modes to use, the next question is “How do you keep the application working with encrypted data?”.
The results of an encryption process (the encrypted value) are usually binary data of some size. So, if you initially had “username” as text, “invoice amount” as double and “invoice date” as timestamp, after encrypting it you now have 3 different binary blobs.
To fix this issue, you must change your database structure and allow storage of these binary data items. But what happens if you have used some of these data items (like the username) in an SQL query, such as finding all users with the first name “David”? The data stored in the database no longer stores the word “David” in plaintext; instead, it is a binary blob.
After doing the proper research and selecting the proper encryption scheme from a security perspective, you may be left with a broken application. This happens, for example, if you encrypt something that your application includes in SQL queries. This is a showstopper.
One method that can help solve this issue is that of tokenization. Tokenization should be used in special cases, such as:
- When the ciphertext needs to get transported via various systems that expect the same type or format of the plaintext. Some systems even require that the format of the ciphertext passes various validation schemes, such as a Luhn check for credit cards.
- When the ciphertext needs to have the same result on every encryption of the same plaintext, such as when performing a lookup from a database for the record key.
In general, however, the recommendation is to use standard strong encryption and only tokenization in the above cases. The best approach is to use a hybrid method. For example, tokenization for lookup and encryption for the rest of the information.
Where To Store the Application Encryption Keys?
Let’s assume you have found the proper encryption method and fortunately you only need to encrypt fields that are not part of any SQL search query. This means that encrypting won’t break the application and you can now implement it in your application. But now another question arises.
Where do you store the key for encryption?
- In your application code?
- On the disk next to the application?
- In the database?
- Derive it from a user password?
These questions not only reflect security issues but also usage issues. If you decide to store the keys on a disk next to the application and you have more than one server for availability, you will now need to sync this key between the different servers.
Also, there are other key management questions:
- How is the key generated, revoked, and replaced if needed?
- Will the key be rotated or backed-up?
- What else do you need to do to manage your keys?
- Assuming that you have resolved all the above, how can you guarantee the safety of your keys?
Summary of the Challenges for Application Level Encryption
Coming back to the original problem statement, encryption is required as networks are no longer safe. If your key material is somewhere on the network (like on a disk or in a database) it can be revealed; and once revealed, all encryption effort is useless. With the key, an attacker can decrypt the encrypted data and steal it, so why would you bother to encrypt?
The set of obstacles and risks mentioned so far is often a show stopper for implementing encryption in applications. This is a situation where you understand that you must use protection but cannot use it due to the circumstances – a tough spot to be in professionally.
Offering an Alternative: Application Level Encryption API
To overcome the challenges, Unbound provides an application-level encryption API, that allows application developers to properly protect and operate on the selected data without all the hassle involved.
The API hides the details of the encryption process from developers, allowing them to concentrate only on domain expertise. Unbound provides an abstraction layer that simplifies the encryption process and at the same time automatically protects encryption keys.
It works by hiding the complexities associated with encryption (such as choosing the key length; deciding between symmetric and asymmetric methods; and choosing the encryption algorithm and its mode of operation). To use Unbound for database encryption, all you need to do is choose which database fields require protection, answer several simple questions about them (such as “Do you need to perform searches on this data?” and “Is this a password field?”). Unbound does the rest for you.
Unbound protects the encryption keys and handles the entire encryption process – from choosing the most appropriate encryption algorithm and keys to protecting the encryption keys in a secure manner inside CORE Information Security by distributing them between several servers. By distributing the keys between multiple servers, Unbound’s Core Solution eliminates a variety of threats to encrypted data. Once randomly distributed using MPC (Multi-Party Computation) technology, the encryption keys are secure from rogue administrators, stolen privileged credentials, zero-day and other threats.
Unbound gives organizations an easy and reliable way to protect sensitive data without breaking existing functionality and without requiring cryptographic expertise. Unbound then automatically protects the encryption keys from malicious attackers and misuse by distributing them randomly so they are never in one place to be stolen.
(For details about setting up and managing the CORE Information Security server, installing the client, and configuring it please see the UKC Installation Guide.)
Advantages Developers Gain
- Ease of deployment – Unbound provides a small piece of code that application developers can easily integrate within their existing application.
- Cryptographic knowledge is not required – Application developers do not need to know which encryption algorithms they need to use for different data objects. Instead, they just choose which data objects they want to encrypt and define their properties. Unbound automatically chooses the best algorithm for the requirements.
- Transparent – Unbound encrypts data with minimal or no changes to the database structure and works with any database.
- Running operations over the encrypted data in a database – CORE Information Security supports advanced operations – such as SEARCH, JOIN, EQUALS, BETWEEN, and UNIQUE, while choosing the strongest algorithm based on these parameters.
- Key protection – Unbound randomly splits the encryption keys across servers so that they are never in any single place to be stolen.
Achieving Application Encryption Security
Encryption is difficult to accomplish, not only because of the security challenges but also because of the standard development tasks involved. This explains why many organizations are unable to use data encryption. Building on top of the Unbound MPC core technology, application-level encryption removes all these obstacles and makes it easy and affordable for developers to encrypt sensitive data, having both high security and usability in the development process and in the application itself.