Well, we have a wonderful concept of Public Key Infrastructure (PKI), which if planned and implemented properly, can be a good fit for the answer to build customers’ trust in a cloud. Before discussing in detail the implementation and challenges of PKI in cloud, let’s learn or refresh some basics. Each and every security process, layer or software must implement and cover the CIA triad. What is CIA?

C-Confidentiality: It refers to the process to ensure that information sent between two parties is confidential between them only and not viewed by anyone else.

I-Integrity: It refers to the process to ensure that the message which is in transit must maintain its integrity i.e., the content of the message must not be changed.

A-Availability: The systems available for fulfilling requests must be available all the time.

Along with these, some important parameters are described below:

Authentication: the process of confirming someone’s identity with the supplied parameters like username and password.

Authorization: the process of granting access to a resource to the confirmed identity based on their permissions.

Non-Repudiation: a process to make sure that only the intended endpoint has sent the message and later cannot deny it.

More information is available in our Certified Cloud Security Professional (CCSP) Boot camp.

Public Key Infrastructure (PKI)

To provide security services like confidentiality, authentication, integrity, non-repudiation, etc., PKI is used. PKI is a framework which consists of security policies, communication protocols, procedures, etc. to enable secure and trusted communication between different entities within as well as outside the organization. PKI is built as a hybrid mode of the symmetric and asymmetric encryption. Let’s discuss this in brief:

Symmetric Encryption: A single key is used to encrypt and decrypt the message sent between two parties. Symmetric encryption is fast, and this type of encryption is effective only when the key is kept absolutely secret and secure between two parties. But to transmit this secret key over an un-trusted network i.e., Internet, comes asymmetric encryption.

Asymmetric Encryption: A pair of keys is used to encrypt and decrypt the message. The pair of keys is termed as public and private keys. Private keys are kept secret by the owner, and the public key is visible to everyone. Here is how it works: Suppose ‘A’ and ‘B’ want to communicate using asymmetric encryption. So ‘A’ encrypts the message with ‘B’ public key so that only ‘B’ can decrypt the message with its private key. After decrypting the message, ‘B’ will encrypt the message with ‘A’ public key so that only ‘A’ can decrypt it using its own private key. Sounds like a perfect solution, doesn’t it? Well as far as secrecy is concerned it is, but when it comes to real world scenarios, asymmetric encryption is pretty slow as the keys involved in this process are of 1024, 2048 bits ,etc. and after the initial handshake, for subsequent requests this overhead still needs to be incurred. So what to do?

In comes the PKI approach, which is a hybrid approach of symmetric and asymmetric encryption. In this, the handshake process happens with asymmetric encryption to exchange the secret key used for symmetric encryption. Once the secret key is exchanged, the rest of the communication happens over asymmetric encryption. In this way, security and performance are both achieved. PKI is a hierarchal model which is comprised of the below components:

Certificate Authority (CA): This entity issues certificates for requests received. This can be in-house or trusted third parties CA like ‘Verisign’, ‘COMODO’, ‘Thwate’ etc.

Registration Authority (RA): This entity performs the background checking process on the requests received from end point entities like their business operations in order to avoid issuing any certificate to a bogus entity.

Certificate Revocation List (CRL): This is the list issued that contains a list of the certificates which are no longer valid to be trusted.

End-point Entities: These entities make requests for the certificates in order to prove their identity and gain trust over the Internet.

Certificates Repository: This is the repository which contains a list of issued certificates which the end point entities can retrieve in order to verify the corresponding server. For end users, this repository is usually located in the browser, such as Firefox, IE, Chrome, etc.

As it can be noted, the maintenance of these keys is of utmost importance and losing control over these keys will leave the encryption on data useless. Key management is an important process and the most challenging process, as any deviation in this could lead to data loss. The key management life cycle involves the following steps:

Creation The first step in the key management life cycle is to create a key pair and apply access control around it. While creating the key, certain important factors need to be considered like key length, lifetime, encryption algorithm, etc. The new key thus created is usually a symmetric key and it is encrypted with a public key of the public-private key pair.

Backup Before distributing keys, first of all the backup of keys should be made to some external media. As normally the key created is a symmetric key a.k.a shared key which should be encrypted with a public key from the key pair, then it becomes important to protect the other part of key pair i.e. the private key. Also the policies around the backup media and vaults should be up to the same effect as is designed for any critical business operation to recover from any type of disruption.

Deployment After the key is created and backed up, then it is ready to be deployed in the encryption environment. It is advisable to not directly put these keys into action on the production environment. The key operations should be analyzed, and if successful the key should be used for encrypted production data.

Monitoring Monitoring of the crypto systems is very important to check for unauthorized administrative access and key operations such as: creation, backing, restoring, archival and destruction.

Rotation Keys should be rotated on a regular basis with the keys that are either meant to be expired or need to be changed following a business change. It is important to realize that keys should not be put into system.

Expiration As per the best practices dictated in compliances like PCI-DSS, it is important that even valid keys need to be changed after a span of time, not only after the keys are expired. Before the expiration phase, key rotation phase should take place by replacing the associated data with new keys.

Archival Before the destruction of keys, archival of expired and decommissioned keys is important if there is still related data in the environment that needs to be recovered like data for recovery operations. This phase is very important from the business decision perspective, and there are some appliances which never go for the destruction phase that causes a risk to be attached. Archived copy of the keys should be properly secured.

Destruction After the business use of key is over or its validity expires, secret and private keys should be destroyed in an efficient manner. All the traces of keys should be completely removed from the whole environment, even from the removal media, and vaults where the keys are stored for backup processes.

PKI Risks on Migrated Data

We cannot sit back and relax by implementing a PKI over the business applications and data which is migrated to the cloud, because when the data migrates to the cloud, various issues tend to arise, such as:

Because in the way the cloud model is designed, control over the migrated data to the cloud is completely lost.

The key management server, which is responsible for storing and managing keys – if hosted in the cloud then there is a risk from the CSP side. The risk is in how we can be sure that the CSP is making sure that our keys are secure, i.e. what access controls mechanism, SOD (segregation of duties) and policies the CSP (Cloud Service Provider) has put in place.

If some third party vendor solution is leveraged for PKI deployment, then where all the keys are used; what model for key management the vendor is using; how the vendor is making sure that even if deployed in cloud, customer keys are secured from the vendor remote access (SaaS APIs) and from some Virtual Machine (VM) corruption event such as, what will happen if a snapshot of the VM is stolen – will the keys reside in the snapshot, and if yes, for how long?

How to make sure that if the customer has leveraged a vendor’s PKI SaaS service, then even the vendor does not have access to the customer’s keys, and what measures the vendor has implemented to address the multi-tenant issue.

After decommissioning of systems in the cloud, how to make sure that data is completely removed from systems.

Recommendations

The below sections describe some of the best practices and design that organizations must follow in order to reap true benefits of PKI in cloud.

The key management server must be hosted within the organization, and whenever the data which is hosted in the cloud needs keys to decrypt the data as a part of end-user request, the key management server provides them. The key used for decryption should never be stored in the cloud VMs and must be in-memory for a few-nano seconds only.

With the above discussed model, all the data that is leaving and entering the organizations can be encrypted and decrypted respectively.

All the VMs that are hosted in the cloud must be encrypted to protect data loss when a VM snapshot is stolen.

When the data which is encrypted and put in a cloud is no longer needed, the organization must revoke the keys associated with it, so that even if some trail of data remains in the decommissioned VM, it cannot be decrypted.

The Hardware Security Model (HSM) should be used to store keys for cryptographic operations such as encryption, decryption, etc.

Use of old and insecure protocols like Data Encryption Standard (DES) must be avoided.

Conclusion

An environment with a poorly managed Public Key Infrastructure (PKI) is as good as an environment with no PKI. However, when organizations plan to migrate data to a cloud and decided to implement PKI onto any cloud model, i.e. public or private, they should make sure that complete ownership of the keys falls on their plate.

References

https://cloudsecurityalliance.org/guidance/csaguide.v3.0.pdf http://research.microsoft.com/pubs/132506/distributed%20key%20lifecycle%20management.pdf http://www.secureconsulting.net/2008/03/the_key_management_lifecycle_1.html