Secure Cloud Authentication with Private – Public Keys

You cannot ignore the various cloud based services that most of the enterprises use on a daily basis. Some of these services use password authentication but many of them use public and private keys for authentication.

The use of public / private keys have increased, and is now being used by a number of protocols and applications. The primary reason for this is improving security, since the keys provide a much better security than a password that was chosen by a user. In order to provide cloud services, we have to ensure we’re properly protecting our public/private keys.

Sample encryption & decryption process

Some Business areas where public/private keys are used:

The most common use of the public/private key pairs are by the applications hosted on cloud based dedicated servers. You simply rent a dedicated server from cloud service providers such as Microsoft Azure or Amazon Web Service. All it requires is a bank account and a few simple mouse clicks to get a dedicated server up and running in matter of minutes.

The administrators use SSH daemon for interacting with them. The Secure Shell or SSH, is an cryptographic (encrypted) network protocol to allow remote login and other network services to operate securely over an unsecured network. You will use the public-private keys to secure your application while password authentication is disabled.

Often used in the banks and other kinds of financial institutions; the website application issues a new key for every user who are given access to this service.

Developers use the public-private keys to authenticate, via the private key to push or pull the source code in the cloud environment. The cloud tools simplify the installation and maintenance of the source code repositories.

Understanding Key Security

Asymmetric encryption uses the public and private keys, to authenticate the system or encrypt/decrypt the data, while in transit. The public key can always be shared with the public as it is used for data encryption while the private key can only decrypt data. Using specific commands the keys can be generated which can accept various arguments to fine-tune the key generation process.

Ways to improve security of public and private keys:

  1. Use password-protected keys:

It is important to select a strong password when generating the private key, to protect it from an unlawful use. An attacker who has gained access to the machine that stores the private keys will eventually be able to access the private keys which in the unencrypted form can provide an attacker access to the cloud-based system.

The attacker can gain access to the machine through various techniques like uploading the shell through a web-based vulnerability in the web application. He will be able to gain partial access to the underlying file system or the access/directory where administrators often place the private keys for authenticating the other cloud-based systems.

This emphasizes the importance of encrypting the private keys with an additional strong password that  prevents the attacker from gaining access to other systems.

  1. Use a strong key.

When creating the private key, it is possible to instruct the ssh-keygen command, to create keys of the following size: 1024, 2048, 4096 and so on. The private keys are usually constructed from the product of two randomly generated prime number. The strength of the public/private key encryption lies in the fact that it’s very easy to calculate the product of two randomly chosen prime numbers, but it is difficult to determine which of the two prime numbers were used by knowing their product.

It is advisable to choose the 4096- bit key that is currently considered secure as it contains enough possibilities to prevent the attacker from using brute-force to gain the passwords in real time.

  1. Reduce the login time.

Using the public and private keys, involves providing password for the private keys all the time. The ssh-agent which stores the decrypted private key in the cache for the duration of the session, can reduce the time it takes to authenticate the system.
The decrypted key can then be used to authenticate the cloud-service without providing the private key password. The decrypted version of the key is only available in the cache and only to the ssh-agent process, while the actual file in the file system remains encrypted. An attacker with access to the file system, will only be able to steal the encrypted version of the private key.

  1. Back up your keys.

Creating backup is a good idea when you rely on a number of public/private key-pairs to authenticate the cloud-based services. Otherwise, if the keys are lost through hard drive failure or accidental file removal operation, the user would no longer be able to authenticate the cloud-based service.

Failing to back up the keys properly can result in getting locked of the cloud service. Contacting the cloud service provider can restore access to the system, but the process is long and cumbersome. In the worst-case scenario, access to the system is lost completely. This can happen if everything is encrypted in the cloud and the cloud-service provider doesn’t have any access to the system or files.

Usage of the public and private keys have increased and is now used by a number of cloud-based services instead of the passwords to authenticate the system, as it provides much better security. Therefore, properly securing the public and private keys are necessary to prevent the attackers from gaining access to the cloud service.

There are ways to protect the public and private keys on the client. So even if an attacker is able to compromise the client, he won’t be able to use the keys. Keep in mind that an attacker who has gained the private keys can authenticate the cloud service and perform a lot of malicious actions like stealing user data, decrypt sensitive information and disrupt the service, among others.

For more details or information, connect with us at info@sysfore.com or call us at +91-80-4110-5555. Website: www.sysfore.com

0 0 votes
Article Rating
guest
0 Comments
Inline Feedbacks
View all comments