Empowering Security: Exploring Cloud Cryptography with a Dynamic Case Study on Google Cloud

cloud computing , a subtype of IaaS, is beyond the hype stage. Cloud services are a powerful tool that people, companies, and governments are using to reduce the headaches associated with maintaining on-premise IT stacks.

Cloud is the pinnacle of affordability, scalability and ease of use.

Simply put, cloud computing means not hosting anything physically and instead using the internet to borrow computer resources like RAM, CPU, storage etc.

Google Drive and Yahoo Mail are two examples in everyday life. We entrust these businesses with our data, which sometimes includes sensitive personal or business data.

A typical user is generally unconcerned about cloud computing security or privacy. However, anyone familiar with the background of surveillance or sophisticated cyberattacks occurring today should be on high alert, or at least the situation at hand.

What is Cloud Cryptography?

The feeling of insecurity is reduced by cloud cryptography, which encrypts data stored on the cloud to prevent illegal access.

The process of converting regular information into a scrambled version using a cipher (algorithm) is called encryption. In such a case, even if the information is made public, the attacker will not be able to understand it.

Depending on the application case, several types of encryption exist. For this reason, it is important to encrypt cloud data using a high-quality cipher.

For example, can you understand the following passage?

Iggmhnctg rtqfwegu jkij-swcnkva vgejpqnqia & hkpcpeg ctvkengu, ocmgu vqqnu, cpf CRKu vq jgnr dwukpguugu cpf rgqrng itqy.

Absolutely not!

Although this seems like a problem to the human mind, anyone with a Caesar decoder can solve it in seconds:

All letters in ciphertext are two letters ahead of their plaintext equivalents, as even a knowledgeable user of Caesar ciphers can see.

Therefore, the key is to choose a powerful encryption like AES-256.

How does Cloud Cryptography work?

The last few paragraphs of the previous section probably revealed that you will choose a cipher to encrypt data.

It could work in theory. However, native encryption is often enabled by a cloud service provider, or you can use encryption-as-a-service from a third party.

So let’s break it down into two groups and see how it’s done.

1. Encryption at Cloud platform

This is the simplest method in which encryption is handled by a reputable cloud service provider.

It is ideally related to:

Data at rest

This is a situation in which data is encrypted before or after being transferred to a storage container.

Since cloud cryptography is a new method, there is no set way to do things. Numerous research papers examine different methods, but practical implementation is the most important.

So how is the rest of the data protected by a premier cloud infrastructure provider like Google Cloud?

According to Google’s notes, the data is divided into small groups and spread across multiple machines’ storage containers, each containing a few gigabytes. A given container can contain data from the same or different users.

Furthermore, even if multiple packets from the same user are stored in the same container, each packet is encrypted separately. This indicates that even if one packet’s encryption key is compromised, additional files will remain secure.

Additionally, every time the data is updated, the encryption key is modified.

Data at this storage level is protected using AES-256, except for some persistent drives made before 2015 that use AES-128 bit encryption.

Thus, at the level of individual packets, this is the first encryption layer.

Then, an additional layer of AES-256 bit encryption is applied to the hard disk drive (HDD) or solid-state drive (SSD) that stores these pieces of data; Some older HHDs still use AES-128 encryption. Note that storage-level encryption and device-level encryption use different keys.

Currently, Google’s Key Management Service (KMS) is in charge of centrally managing all data encryption keys (DEKs) once encrypted using encryption keys (KEKs). Interestingly, at least one KEK is connected and all KEKs use AES-256/AES-128 bit encryption with each Google cloud service.

These KEKs are rotated at least once every 90-day interval using Google’s common cryptographic library.

Each KEK is logged every time it is used, backed up and accessible only by authorized persons.

Next, an additional key management facility called Root KMS, which maintains a smaller number of these keys, once again generates a KMS master key by encrypting all KEKs using AES-256 bit encryption.

In each Google Cloud data center, a dedicated computer is used to maintain this root KMS.

Currently, the peer-to-peer architecture stores a single root KMS master key that is encrypted using AES-256.

Each Root KMS master key distributor with keys stored in random access memory has a single instance of Root KMS running.

To avoid collusion, each new root KMS master key distributor instance is authorized by the currently running instances.

In addition, the root KMS master key is backed up to only two physical locations to address situations when all distributor instances must be started simultaneously.

Finally, access to this highly classified location is restricted to fewer than 20 Google employees.

This is how Google handles the rest of the data using cloud cryptography.

However, you can also handle the keys yourself if you want to take matters into your own hands. As an alternative, one can self-manage the key and apply an additional layer of encryption to it. But it’s important to remember that misplacing these keys can also lock out your own website.

However, we should not rely on all other cloud providers to deliver this information. Given that Google charges more for them its services, you might benefit from a different provider costing less yet fitting your specific threat model.

Data in transit

This data is routed in or out of the cloud provider’s data center, as in the case of uploading from your own computer.

Again, there is no hard way to secure data while it is being transmitted, which is why Google Cloud will be used.

The Encryption-in-Transit whitepaper lists three steps to protect non-stationary data: integrity checking, authentication, and encryption.

Google uses optional encryption with endpoint authentication and integrity confirmation to protect data while it is in transit to its data centers.

Although users have the option to take further precautions, Google confirms that its facilities are very secure, with only a select group of employees having access that are closely monitored.

Google has different policies for its own cloud services (such as Google Drive) and third-party cloud services outside of its physical boundaries any customer application hosted on its cloud (like any website running on its compute engine).

In the first scenario, all traffic uses Transport Layer Security (TLS) to pass through the Google Front End (GFE) checkpoint. The traffic is then routed to the desired Google cloud service with load balancing and DDoS mitigation across servers.

In the second scenario, the infrastructure owner has the primary duty to ensure data security in transit, unless another Google service (such as a cloud VPN) is used for data transmission.

TLS is typically used to ensure that data has not been altered in transit. The HTTPS protocol, indicated by the padlock symbol in the URL bar, is the same protocol that is automatically used when you connect to any website.

Despite being widely used by all online browsers, you can also apply it to other applications such as email, audio/video calls, instant messaging, etc.

2. Encryption-As-A-Service

This is a situation where your cloud platform’s default security measures are insufficient or non-existent for certain use cases.

Taking responsibility for everything yourself and ensuring enterprise-grade data security is undoubtedly one of the best options. However, that’s easier said than done, and it takes away the hassle-free experience that makes people choose cloud computing.

Our only option is to use encryption-as-a-service (EAAS) providers such as CloudHasive. At this time, as with cloud computing, you can use CPU, RAM, storage, etc. Rather than “borrowing” encryption.

Depending on the EAAS provider, you can get encryption for data in transit and at rest.

Advantages and Disadvantages of Cloud Cryptography

Safety is the main advantage. By using cloud cryptography, you can be sure that hackers cannot access your customers’ data.

Cloud cryptography is not impenetrable, but it is important to be careful and have a proper explanation if something goes wrong.

When it comes to drawbacks, the first is the cost and time required to update the current security architecture. Plus, when self-managing, there’s not much you can do if you misplace the encryption key.

Additionally, the tried and true EAAS is hard to find because it is a young technology.

Ultimately, your best options are to rely on native cryptographic techniques and use a reputable cloud service provider.

Wrapping Up

We hope this has given you an overview of cloud cryptography. In essence, it deals with cloud-related data security including external data transport.

For the majority of use cases, the best cloud infrastructure providers, such as Google Cloud, Amazon Web Services, etc. Provides adequate security. However, it doesn’t hurt to familiarize yourself with the technical language before sharing your important apps with anyone.

READ |Revealing the power of cryptography and its 3 dynamic forms

---