Data Encryption: Which Data Encryption Mechanism Should You Use?

Data Encryption: Which Data Encryption Mechanism Should You Use?

A
by Amelia Scott — 3 years ago in Security 5 min. read
2652

Do you want your data to be secure at rest, in transit, or during use? This framework is for developers who want to identify the best encryption mechanism for their data needs.

In the past few years, encryption and cryptography have firmly been incorporated into the mainstream. This is mainly due to private conversations that revolve around technology giants and the rapid rise in popularity for Bitcoin.

Today, even laymen understand that encryption is a technique for hiding data from plain sight. They also understand its importance.


For many years encryption has been an integral part of enterprise software design. These capabilities were historically provided by the underlying infrastructure and libraries that IT and developers used. They simply had to turn on flags in builds, enable configurations in servers, and use transport layer security (TLS), in their networking infrastructure.

But with the move to microservices-based architecture and infrastructure-as-code paradigms, individual teams are now responsible for the security of their application and infrastructure stack, and it has become important for them to understand how to properly leverage encryption for all the services they develop.

To properly secure data, it needs to be protected at rest, in transit, and use. Below are various common encryption terms and frameworks, and what developers can do to leverage them properly.

Data must be secure at rest, transit, and during use to be properly protected. Here are some common encryption terms and how developers can use them.

Rest encryption of data

Data at rest is the way data is stored in persistent storage. If the data is not encrypted, an attacker can gain access to your device or the physical storage infrastructure. There are many ways to encrypt data at rest.

Encryption dist – OR file system – Level

The implementation of the virtual storage layers is used to encrypt disk- and filesystem-level encryption. This encryption is transparent to all applications software and can be deployed with any storage layer regardless of its encryption capabilities.

Responsibility: Today, all cloud vendors provide this capability, and this is not something developers have to worry about — they just need to enable it.

Threats It Protects Against Stolen disks or other storage media.
Also read: 10 Types of Developer Jobs: IT Jobs

Server-Side Encryption

Server-side encryption is responsible to encrypt and decrypt data transparently from clients. Only the server has access to cryptographic keys used in encryption.

The cloud-native world can have a server that is either a cloud service controlled by the cloud provider or one built by developers and keys managed by them. Encryption is transparent from the client’s perspective.

Responsibilities: This feature is available in many cloud services, so developers will need to enable it if it exists.

Developers can create and manage their own server-side encryption mechanisms. These can be combined with cloud-based server-side encryption.

Threats It Protects Against: If the developers create them, they can steal data or other storage media and filesystem-level attacks.

Client-Side Encryption

The client is responsible for the encryption of data before it is sent to the server. The client must also decrypt data during retrieval. This makes it more difficult to design software. Client-side encryption has the advantage that not all stored data must be encrypted. Only the most sensitive can be protected. This is useful when computation costs are a concern.

Responsibilities: Developers are responsible for designing and making the process as smooth as possible for both the client and the end-user.

It protects against the following threats: Man-in-the-middle internal threats to storage providers
Also read: How To Calculate Your Body Temperature With An iPhone Using Smart Thermometer

What are the limits of encryption of data at rest?

Although encryption of data at rest is considered the best practice, it is not without its limitations.

It is crucial to know where and how the encryption keys are kept, who has access to them, and so forth. Although there are many good options for key storage security, it is crucial to properly set them up.

Key management problems are unfortunately all too common and more likely to cause confidentiality breaches than breaking modern encryption algorithms. Most people know at least one person who lost access to their smart devices’ data because they forgot their backup key.

Advice for Developers: Use the cloud provider’s resources for key management if you can. Many services offer simple configuration toggles that enable encryption at rest. They also provide transparent key management. You should use a customer-managed key whenever possible to ensure the highest level of security.

Suggested tools: Management services for major cloud providers, including Amazon Web Services (AWS) Key Management Service (KMS)?Microsoft Azure Key VaultAndGoogle Cloud Platform (GCP) Cloud Key Management.

Key rotation, the recommended practice of regularly changing secret keys, can cause disruption and cost. Large volumes of data will need to be encrypted and then decrypted again. This can be a problem if an employee who has access to the key leaves of the key is considered compromised.

Advice for Developers: If possible, use the cloud provider’s resources for automatic key rotation. All three major providers today support automatic master key rotates, which are just a simple configuration flag to enable encryption.

A master key is a reference to the current encryption key in these situations. This means that all data encrypted with the rotated key will be lost if a key is changed. Manual rotation is possible but it can be difficult.

Suggested tools: AWS KMS and Azure Key Vault. GCP Cloud Key Management.
Also read: How To Access Flags In Chrome + 5 Best Chrome Flags Settings

Encryption of Data in Transit

As engineers run their administrations in the cloud, integrating with other outsider administrations, encryption of data in transit turns into an unquestionable requirement. For quite a long time, there was a lot of pushback because of worries about dormancy in applications, and as such numerous applications never executed transit-level encryption.

Nonetheless, HTTPS has made immense execution gains over the previous decade, and all administrations today have come to utilize it — with HTTPS in any event, being utilized interchangeably with the terms SSL and TLS.

Exhortation to Developers: Enabling HTTPS for any open endpoints is a need today and is very easy to do. There will be some minor arrangements that should have been done, yet in case you are using any of the significant cloud suppliers, you can rapidly and flawlessly produce and integrate declarations with your administrations.

Proposed Tools: Each of the cloud suppliers offer an approach to creating public and surprisingly private testaments. So there’s AWS Certificate Manager, Azure App Service, and GCP Certificate Manager. Assuming you need to utilize another assistance, LetsEncrypt is free and has apparatuses for programmed age and revolution.

Encryption of data during use

This area is gaining increasing attention. It addresses the fact that data must be made available in plain text form during processing by applications. Even with the most robust encryption techniques used for data in transit and at rest, it is often the application that poses the greatest threat to data theft.
Also read: Bobbie Formula Reviews 2024 (Read Before You Buy)

Here are two recent methods to deal with data privacy threats while they are still in use.

Confidential Computing: This is possible thanks to the advancements in CPU chipsets that provide a trusted execution environment inside the CPU. It provides real-time encryption/decryption of data stored in RAM of computer systems while it is being processed and ensures that keys are only accessible to authorized applications code.

This technology allows anyone with administrative access to the key to decrypt and encrypt data. VMS application’s sensitive data cannot be accessed maliciously by its hypervisor or the other.

Homomorphic encryption: This class of encryption algorithms allows for certain types of computations on encrypted data. These operations are typically limited to a few arithmetic operations.

Recent attempts have been made to extract analytics information from homomorphically encrypted data. Many companies claim to be able to search for sensitive or confidential data and collaborate with analytics teams working on highly sensitive data.


Tokenization is a similar technique that companies use to avoid these issues altogether. This involves replacing sensitive data with non-sensitive counterparts that have no business value. The original sensitive data is stored in highly secure locations, which can be offsite or at a third-party location.

An example of this is when an online retailer stores credit card tokens rather than credit card numbers. An authorized payment processor can only access the original credit card number if it is needed.

The credit card number is stored with a third-party service. This protects data and offloads compliance burden to the business responsible for security. However, token replay attacks could make it vulnerable. Therefore, tokens must be protected.

There is no single security technique that IT or development teams can use to protect their data from prying eyes, just as there are not many other security methods. However, the above framework is a great starting point for companies that embrace digital transformation and take a collaborative approach towards security.

Amelia Scott

Amelia is a content manager of The Next Tech. She also includes the characteristics of her log in a fun way so readers will know what to expect from her work.

Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments

Copyright © 2018 – The Next Tech. All Rights Reserved.