Most enterprises use various cloud-based services on a daily basis. Some of these services use password authentication,...
but many of them use public /private keys for authentication.
Some of the most common services that use public/private keys are secure websites regularly used by enterprises that require each client to have a private key for authentication. This is often found in banks and other kinds of financial institutions. In such cases, the website application issues a new key for each user who is given access to the service once they incorporate the keys into the system.
Developers working in software companies often use cloud source code hosting when they have to authenticate via private key to push or pull the source code. Cloud tools are normally used instead of internal applications because they simplify the installation and maintenance of source code repositories. The users of the service normally use public or private keys for authentication, which allows an attacker with a private key access to the source code of an application. This could have disastrous effects on the application and possibly the whole company.
The most common use of public/private key pairs is by applications hosted on cloud-based dedicated servers. Renting a dedicated server from a cloud-based company is easy, and all that is required is a few simple mouse clicks. Anybody with a bank account can get a dedicated server up and running in a matter of minutes and the service is quite cheap. Because of the prevalence of renting dedicated servers, the administrators use an SSH daemon for interacting with them. To achieve maximum security, the SSH daemon has to be protected in such a way that public or private keys are used while the password authentication is disabled. This is a common practice nowadays since administrators are becoming more security aware.
Hardening security of public/private keys
Asymmetric cryptography uses public and private keys to authenticate to the system or encrypt/decrypt the data in transit. The public key can always be shared with the public as it is used for the data encryption, while only the private key can decrypt the data. The keys can be generated by using the ssh-keygen command, which accepts various arguments to fine-tune the key generation process.
There are four ways to improve the security of these public and private keys:
1. Use password protected keys: It's important to select a strong password when generating a private key to protect it from unlawful use. An attacker who has gained access to the machine storing private keys will eventually be able to access the private key, which in unencrypted form can provide an attacker access to the cloud-based systems.
An attacker can gain access to the machine through numerous techniques like uploading a shell through a Web-based vulnerability in a Web application. After the Web shell is uploaded to the machine, the attacker will be able to get partial access to the underlying filesystem. The attacker will also be able to access /etc/ directory, where administrators often place private keys for authenticating to other cloud-based systems.
When the private keys are not encrypted and the attacker has enough permissions to access them, he will be able to authenticate to the other SSH daemon in the cloud without needing to provide a password. This emphasizes the importance of encrypting the private keys with an additional password, which would have prevented the attacker from gaining access to other systems.
Even if the private key is encrypted it's important to choose a strong password when generating the key, because otherwise an attacker could brute-force the password by using a dictionary attack. Normally, a dictionary with most common passwords is used, and if the private key was encrypted by using one of those passwords, an attacker can easily brute-force it. In order to prevent that, we have to use a strong password.
2. Use a strong key: When creating the private key it's possible to instruct the ssh-keygen to create the keys of the following sizes: 1024, 2048, 4096 and so on. The private key is usually constructed from the product of two randomly generated prime numbers. 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's difficult to determine which of the two prime numbers were used by knowing their product.
If an attacker can brute-force the prime numbers used in the key generation, he can obtain the private key. Therefore it's important to make the brute-force operation as difficult as possible. By knowing the product two 512-bit numbers gives a 1024-bit number, the product of two 1024-bit numbers gives 2048-bit number, the product of two 2048-bit numbers gives a 4096-bit number, and so on, you can conclude that a 4096-bit key was generated from two 2048-bit prime numbers. So by increasing the size of the key, the number of possible prime numbers also increases.
It's advisable to choose at least a 4096-bit key, which is currently considered secure as it contains enough possibilities to prevent the attacker to brute-force the passwords in real time.
3. Reduce the login time: Using public and private keys can get annoying because you have to provide the password for the private keys all the time. An ssh-agent -- which stores decrypted private key in cache for the duration of the session -- can reduce the time it takes to authenticate to the system.
The decrypted keys can then be used to authenticate to the cloud-service without providing the private key password. The decryption version of keys is only available in cache and only to the ssh-agent process while the actual file on the file system remains encrypted. An attacker with access to the file system will only be able to steal an encrypted version of the private key.
4. Back up keys: Creating backups is a good idea when you rely on a number of public/private key-pairs to authenticate to the cloud-based services. Otherwise, if the keys get lost through a hard drive failure or accidental file removal operation the user would no longer be able to authenticate to the cloud-based service.
See Infosec Institute's accompanying article on securely managing public/private keys for cloud services
Failing to properly back up the keys could result in getting locked out of the cloud service, which would cause many problems. In the best-case scenario, contacting the cloud-service provider would 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 happens if everything in the cloud is encrypted and the cloud-service provider doesn't have any access to the system or files.
Because the consequences of lost keys can be devastating, ensure there is a strong backup process in place. One of the most secure backup services I've experimented with is Bacula, which is quite complicated and requires some time to master, but every minute spent is worthwhile. Other simpler services -- though not as powerful as Bacula -- include Areca Backup and SpiderOak.
The usage of public/private keys has mushroomed and is now used by a number of cloud-based services. Many of the services use public or private keys rather than passwords to authenticate to the system, which provides much better security. Therefore, properly securing public/private keys is necessary to prevent attackers from gaining access to the cloud service.
There are ways to protect 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 without many difficulties. Keep in mind that an attacker who has gained private keys can authenticate to the cloud service and perform a lot of malicious actions like steal the user data, decrypt sensitive information, disrupt the service, among others.