Manage Public/Private Keys for a Secure Cloud Authentication
Most enterprises use various cloud-based services that needs authentication in order to be accessed; starting from personal services like cloud email solutions and business socializing websites to enterprise services. Secure websites are the most common enterprise services that use public/private keys requiring each client to have a private key for authentication. In such cases, once the keys are incorporated into the system, the website application issues a new key for each user, giving access to the service. The prevalent use of public/private key pairs is by applications hosted on cloud-based dedicated servers.
Enterprises most often have to have access to the following services:
Source code hosting: It allows an attacker possibly to gain access and steal the source code of an application or a system although it simplifies the development and maintenance of source code repositories.
A website: If the website allows user authentication, it should be run over Transport Layer Security (TLS) in order for a secure session to be established prior to entering the credentials.
Domain name service: An attacker can disrupt the enterprise service and attack all of the visitors of the service by pointing all domain records to his own malicious website since this is where all the records for their domains are kept and managed.
Dedicated servers: A hacker can obtain all user credentials from login requests coming over the network or install a backdoor into the system and disrupt the service running on a server if they have gained access to a dedicated server.
Although these services can be installed and maintained in an company’s internal network by company administrators, there are cloud service providers offering the same kind of services for free or possibly for small subscription fee. Cloud tools are normally used instead of internal applications because they simplify the installation and maintenance of source code repositories.
The most common use of public/private key pairs is by applications hosted on cloud-based dedicated servers. Because of the prevalence of renting dedicated servers, the administrators use an SSH daemon— a cryptographic network protocol for operating network services securely over an unsecured network— for interacting with them. Since administrators are becoming more security aware, the SSH daemon is being protected in such a way that public or private keys are used instead of password authentication.
Securing public/private keys
In asymmetric cryptography, both public and private keys are used to decrypt/encrypt the data in the transit or authenticate the system. The public key can be shared with anyone as the data decryption is possible only with the private key. To generate the keys for accepting various arguments, the ssh-keygen command is used.
Four ways to improve the security of these public and private keys are:
Password protected keys: An attacker will be able to access the private key after gaining access to the machine storing private keys, which in unencrypted form can provide an attacker access to the cloud-based systems. While generating a private key, a strong password is important. Even if the private key is encrypted, it is important to choose a strong password when generating the key, because otherwise an attacker could brute-force the password by using a dictionary attack.
A strong key: Since the private key is constructed from the product of two randomly generated prime numbers, it's difficult for an attacker to determine the two prime numbers used to create the key. By increasing the size of the key, the number of possible prime numbers also increases. To make brute-force operation as difficult as possible, a 4096-bit key must be generated from two 2048-bit prime numbers.
Faster login time: Instead of providing the password for private keys, an ssh-agent stores the decrypted private key in cache to reduce the time it takes to authenticate. An attacker with access to the file system will only be able to steal an encrypted version of the private key, as the actual file on the file system remains encrypted. The decryption version of keys is only available in cache and only to the ssh-agent process.
Backing up keys: Failing to create a backup solution can result in being locked out of a cloud service or disable a way to decrypt the already encrypted files. In the worst-case scenario, access to the system can be lost completely, and contacting the cloud-service provider would restore access to the system using long and cumbersome process.
The use of public/private keys have increased, and are now being used by a number of protocols and applications. An attacker having gained a private key can possibly log in to various cloud systems or decrypt possibly leaked encrypted data. Keeping this in mind, it is essential to ensure proper protection of public/private keys. So even if an attacker is able to compromise the client’s data source, the keys will still be unusable.