A subset of IaaS, cloud computing is quite ahead of the buzzword phase. It’s a dominant force with individuals, businesses, and governments using cloud services to cut short the hassles of an on-premise tech stack. Cloud is the epitome of convenience, economy, and scalability. Put simply, cloud computing is when you borrow computing resources like storage, RAM, CPU, etc., over the internet without physically hosting anything. A daily life example is Google Drive or Yahoo Mail. We trust these companies with data–sometimes sensitive personal or business-related information. Generally, an average user doesn’t bother about the privacy or security of cloud computing. But anyone decently informed about the history of surveillance or current sophisticated cyber attacks must raise their guard or at least be informed about the situation at hand.
What is Cloud Cryptography?
Cloud cryptography addresses that sense of insecurity by encrypting data stored in the cloud to prevent unauthorized access. Encryption is a technique of using a cipher (algorithm) to convert standard information to a scrambled version. In that case, the attacker won’t make sense of the details even if it gets exposed. There are various types of encryptions based on the use case. So it’s important to use a quality cipher for cloud data encryption. For instance, can you understand the following text: Iggmhnctg rtqfwegu jkij-swcnkva vgejpqnqia & hkpcpeg ctvkengu, ocmgu vqqnu, cpf CRKu vq jgnr dwukpguugu cpf rgqrng itqy. No! It might be some puzzle to a human brain, but use any Caesar decoder, and they will break it apart in seconds: Even someone well versed with Caesar cipher can see that all letters in the ciphertext are two alphabets ahead of their plaintext counterparts. So the point is to use a strong cipher, like that of AES-256.
How does Cloud Cryptography work?
The last few lines of the previous section might have given an impression that you will choose a cipher to encrypt the data. Technically, it can work like that. But normally, the cloud service provider enables native encryption, or you avail encryption-as-a-service from a 3rd-party. So we’ll divide this into two categories and see the implementation.
#1. Encryption at Cloud platform
This is the most simplistic method where the reputed cloud services provider takes care of the encryption. Ideally, this applies to:
Data at rest
This is when the data is stored in the encrypted form before transferring to the storage containers or afterward. Since cloud cryptography is a novel approach, there is no predefined way of doing things. There are many research publications testing various methods, but what’s crucial is real-life application. So how does a top-notch cloud infrastructure company like Google Cloud protect data at rest? As per Google’s records, they divide the data into small groups of a few gigabytes spread across their storage containers on different machines. Any specific container may contain data of the same or different users. Moreover, each packet is encrypted individually, even if they sit in the same container and belong to a single user. This means that if the encryption key-related to one packet gets compromised, other files will remain secure. Besides, the encryption key is changed with each data update. Data at this storage level is encrypted with AES-256, except for a few persistent disks created before 2015 using AES-128 bit encryption. So this is the first encryption layer–at the individual packet level. Next, the hard disk drives (HDD) or solid-state drives (SSD) hosting these data chunks are encrypted with another layer of AES-256 bit encryption, with some legacy HHDs still using AES-128. Please note that the device-level encryption keys are different from storage-level encryption. Now all these data encryption keys (DEKs) are further encrypted with key encryption keys (KEKs), which are then centrally managed by Google’s Key Management Service (KMS). Notably, all KEKs use AES-256/AES-128 bit encryption, and at least one KEK is associated 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 backed up, tracked every time someone uses it, and can only be accessed by authorized personnel. Up next, all the KEKs are encrypted again with AES-256 bit encryption generating the KMS master key stored in another key management facility, called Root KMS, that stores a handful of such keys. This Root KMS is managed on dedicated machines in each Google Cloud data center. Now, this Root KMS is encrypted with AES-256, creating a single root KMS master key stored in the peer-to-peer infrastructure. One Root KMS instance runs on every root KMS master key distributor holding the key in random access memory. Every new instance of root KMS master key distributor is approved by already running instances to avoid foul play. In addition, to handle the condition where all the distributor instances need to start simultaneously, the root KMS master key is also backed up in just two physical locations. And finally, less than 20 Google employees have access to these highly classified locations. So this is how Google practices cloud cryptography for data at rest. But if you want to take matters into your own hands, you can also manage the keys yourself. Alternatively, one can add another layer of encryption over this and self-manage the keys. However, one should remember that losing these keys also means being locked out of your own web project. Still, we shouldn’t expect this level of detail from all other cloud providers. As Google charges a premium for its services, you might benefit from a different provider costing less yet fitting your specific threat model.
Data in transit
This is where the data travels within the cloud provider data center or outside its boundaries, such as when you upload it from your own machine. Again, there is no hard-lined way to protect the data in transit, so we’ll see the Google cloud implementation. The whitepaper in this regard, encryption-in-transit, states three measures to secure non-stationary data: authentication, encryption, and integrity check. Within its data center, Google secures data in transit by endpoint authentication and integrity confirmation with optional encryption. While a user can opt for additional measures, Google confirms top-notch security on its premises with extremely monitored access granted to a few of its employees. Outside its physical limits, Google adopts a differential policy for its own cloud services (like Google Drive) and any customer application hosted on its cloud (like any website running on its compute engine). In the first case, all traffic first goes to the checkpoint known as Google Front End (GFE) using Transport Layer Security (TLS). Subsequently, the traffic gets DDoS mitigation, load-balancing across the servers, and is finally directed towards the intended Google Cloud Service. For the second case, the responsibility to ensure data in transit security falls mostly to the infrastructure owner unless they aren’t using another Google service (like its Cloud VPN) for data transfer. Generally, TLS is adopted to make sure data hasn’t been tampered with en route. This is the same protocol used by default when you connect to any website using HTTPS, symbolized by a padlock icon in the URL bar. While it is commonly used in all web browsers, you can also apply it to other applications such as email, audio/video calls, instant messaging, etc. However, for the ultimate encryption standards, there are virtual private networks which again provide multiple layers of security with advanced encryption ciphers such as AES-256. But implementing cloud cryptography on your own is tough, which brings us to…
#2. Encryption-As-A-Service
This is where the default security protocols at your cloud platform are weak or absent for specific use cases. One of the obviously best solutions is to oversee everything yourself and ensure enterprise-grade data security. But that is easier said than done and takes away the no-hassles approach for which someone opts for cloud computing. So that leaves us to use Encryption-as-a-service (EAAS) such as CloudHesive. Similar to using cloud computing, this time, you ‘borrow’ encryption and not CPU, RAM, storage, etc. Based on the EAAS provider, you can avail encryption for data at rest and in transit.
Advantages and Disadvantages of Cloud Cryptography
The most pronounced advantage is security. Practicing cloud cryptography ensures your users’ data stays away from cybercriminals. Although cloud cryptography can not stop every hack, it’s about doing your bit and having proper justification if things go wrong. Coming to disadvantages, the first one is the cost and time it needs to upgrade the existing security framework. Besides, there is little that can help if you lose access to the encryption keys while self-managing. And since this is a nascent technology, finding a time-tested EAAS isn’t easy either. Conclusively, the best bet is to use a reputed cloud service provider and bank on native cryptographic mechanisms.
Wrapping Up
We hope this could give you a glimpse of cloud cryptography. To summarize, it’s about data security related to the cloud, including when it travels outside. PS: Check out some cloud cost optimization solutions for AWS, Google Cloud, Azure, etc.
