Cryptographic keys are a vital part of any security system. They do everything from data encryption and decryption to user authentication. The compromise of any cryptographic key could lead to the collapse of an organization’s entire security infrastructure, allowing the attacker to decrypt sensitive data, authenticate themselves as privileged users, or give themselves access to other sources of classified information. Luckily, proper management of keys and their related components can ensure the safety of confidential information.

Key Management is the process of putting certain standards in place to ensure the security of cryptographic keys in an organization. Key Management deals with the creation, exchange, storage, deletion, and refreshing of keys, as well as the access members of an organization have to keys.

Primarily, symmetric keys are used to encrypt and decrypt data-at-rest, while data-in-motion is encrypted and decrypted with asymmetric keys. Symmetric keys are used for data-at-rest since symmetric encryption is quick and easy to use, which is helpful for clients accessing a database, but is less secure.

Since a more complicated and secure encryption is needed for data-in-motion, asymmetric keys are used.

The way symmetric key systems work and steps listed below.

  1. A user contacts the storage system, a database, storage, etc, and requests encrypted data
  2. The storage system requests the data encryption key (DEK) from the key manager API, which then verifies the validity of the certificates of the key manager API and the key manager
  3. A secure TLS connection is then created, and the key manager uses a key encryption key (KEK) to decrypt the DEK which is sent to the storage systems through the key manager API
  4. The data is then decrypted and sent as plaintext to the user

Asymmetric key systems work differently, due to their use of key pairs. The steps follow below:

  1. The sender and recipient validate each other’s certificates via either their private certificate authority (CA) or an outside validation authority (VA)
  2. The recipient then sends their public key to the sender, who encrypts the data to be sent with a one-time use symmetric key which is encrypted by the recipient’s public key and sent to the recipient along with the encrypted plaintext
  3. The recipient decrypts the one-time use symmetric key with their own private key, and proceeds to decrypt the data with the unencrypted one-time use key

While these key systems do keep data secure, that makes the cryptographic keys the biggest sources of security concerns for an organization, which is where key management comes in.

To ensure strong security and uniformity across all government organizations, the National Institute of Standards and Technology (NIST) has created Federal Information Processing Standards (FIPS) and NIST Recommendations, referred to as NIST Standards, for sensitive and unclassified information in government organizations. These standards have security methods approved for all government data that is unclassified and sensitive.

Since these standards are approved for all of the government’s sensitive and unclassified data, this means they are best-practice methods for cryptographic key protection for non-governmental companies.

NIST Standards

The first security issue the NIST Standards review are cryptographic algorithms which are used for the encryption of data. Previously in this blog, symmetric and asymmetric cryptographic algorithms were discussed, but the NIST Standards only approve of a few specific types of these algorithms.

For symmetric algorithms, block cipher-based algorithms, such as AES, and hash function-based algorithms, like SHA-1 or SHA-256, are approved. Block cipher based algorithms iterate through a series of bits called blocks and uses different operations, such as XOR, to permutate the blocks over a series of rounds, leading to the creation of a ciphertext.

Hash function-based algorithms use hashes, which are one-way functions, to generate hash data. Asymmetric algorithms are all accepted, NIST says that “the private key should be under the sole control of the entity that “owns” the key pair,” however.Cryptographic hash functions, which do not use cryptographic keys, and Random Bit Generators (RBGs), which are used for key material generation, are also approved by NIST Standards. A list of all algorithms approved by NIST Standards can be found in FIPS 180 and SP 800-90 for hash functions and RBG respectively.
Also discussed by NIST Standards is how cryptographic keys should be used. The most important recommendation is that a unique key should be created at every key creation. A key should not be used for both authentication and decryption, a user should have a separate key for each use. NIST Standards gives advice on what a cryptoperiod should be set to. A cryptoperiod is the time span that a key can be used for its given purpose before it must be renewed or, preferably, replaced with a new key. For asymmetric-key pairs, each key has its own cryptoperiod. The cryptoperiod of the key used to create a digital signature is called the originator-usage period, while the other cryptoperiod is called the recipient-usage period. NIST Standards suggests that the two cryptoperiods begin at the same time, but the recipient-usage period can extend beyond the originator-usage period, not vice versa.


Key Management is one of the essential portions of cybersecurity, and therefore should be executed with all the best-practices in mind. Luckily, the government publishes the NIST Standards which recommend the best ways to minimize security risks related to cryptographic keys.

The NIST Standards discuss how keys should be used, what cryptographic algorithms are approved for government work, and what cryptoperiods for keys should be set to. As NIST Standards are updated, it is worth keeping track of to ensure your security system is always up to date.

Free Downloads

Datasheet of Encryption Consulting Services

Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all aspects of encryption for our clients.

Encryption Services

About the Author

Riley Dickens is a Consultant at Encryption Consulting, working with PKIs, creating Google Cloud applications, and working as a consultant with high-profile clients.

Table of Contents

Secure Shell, or SSH, is a network protocol normally used to connect a user to a remote system over an insecure network. SSH not only authenticates users, but also encrypts communications across networks like the Internet. SSH is used in organizations by system administrators, users, and automated processes to initiate file transfers, manage infrastructure, and provide access to other mission-critical system operations. SSH also works in cloud computing to help deal with network and security issues. SSH keys act as a way of authenticating users without using usernames and passwords. Instead, users have a trusted SSH key pair which authenticates them as the person they say they are.

How are SSH keys used?

SSH key authentication begins with the creation of a key pair. Since authentication with SSH is asymmetric, an asymmetric key pair is created. Asymmetric encryption uses a key pair consisting of a public and private key, also referred to as the authorized and identity keys respectively. The public key gives user access to the remote file system, so that not just anyone can log into the remote file system. Even if an unauthorized user stole the public key, they could not access any information within the remote file system, as they would also need the private key. The private key acts as authentication for the user’s identity, giving the authenticated user access to the data they are allowed access to. As with all private keys, the identity key should be kept secure and should only be accessible by the user who it authenticates. The creation of the key pair only occurs once, meaning the key pair is related to the user through the entirety of its lifetime. A passphrase can also be used to add an additional security measure to the SSH authentication process. The data within the message is encrypted with symmetric encryption.

After the creation of the asymmetric key pair, the client then sends the public key ID to the server for authentication. The server checks for a matching ID number for the public key, and if found, encrypts a message with the public key and sends it to the client. The client then decrypts the message, computes the MD5 hash of the message, and sends it back to the server. If the hashes match, then the client is authenticated into the system and can work within the remote file system.

Why is SSH key management important?

SSH key management is paramount when encrypting connections via SSH. The mismanagement of an SSH key pair can lead to the compromise of the entire remote system being accessed. Below is a list of the risks SSH key management thwarts:

  • Loss of Information

    Attackers that gain control of SSH keys can steal, delete, or modify any data the victim had access to. This can result in the exposure of sensitive data, such as Personally Identifiable Information (PII), or the loss of that same data.

  • Extraneous Key Generation

    Any user with access to the remote system can create a key pair for other authentication purposes. If an SSH key pair were mismanaged and an attacker were to steal the keys, they could create an unlimited number of new key pairs. This would not only make it difficult to manage the legitimate keys, but it would also allow the attacker to login via any of the newly created key pairs if the key pair they stole was deleted.

  • Lack of Expiration Date

    SSH keys do not have an expiration date, like SSL/TLS certificates do, which increases the risk of an SSH key pair becoming mismanaged. The longer a key pair is in existence, the easier it is to not continue protecting it as new keys are created. Older keys are less likely to be rotated too, as system administrators may not know the purpose behind a key. Another issue posed by the lack of expiration date is that when team members leave the organization, they may still have access to their key, allowing them to access any data they could access while at the company. Deletion of older keys also rarely occurs, as system administrators fear they will block important access if they delete the key pair.

  • Solo Keys

    If an employee leaves the organization, they tend to leave behind a single key, leading to a key pair that cannot be used. Users can also lose their keys, causing more issues when attempting to delete them. As before, system administrators are hesitant to get rid of keys they do not know the purpose of, especially since it could interrupt critical systems.

  • Key Sprawl

    As an organization operates over the years, more and more keys are created. With so many keys created, it becomes difficult to track and manage the keys in circulation. This opens the door to attackers to compromise keys, as every single key likely cannot be accounted for.

  • SSH-Based Attacks

    SSH-based attacks are becoming more prevalent every day. Threat actors can leverage compromised private keys and impersonate administrators, modify encrypted traffic, read encrypted traffic, and access material not meant for unauthorized individuals. If an attacker gained access to the remote systems of an organization, they could modify data, delete data, steal data, implement malware, or disrupt critical systems operations.

  • Compliance

    One of the most important reasons to properly manage keys is to be compliant with security standards and regulations. Government compliance and regulation standards such as PCI-DSS, and FIPS, require organizations to keep their SSH keys well-managed. The US National Institute of Standards and Technology (NIST) released guidelines on the best ways to ensure SSH keys are properly managed in their document NIST IR 7966.

Secure your data through Encryption Assessment

SSH key management compliance

To be compliant with standards such as PCI-DSS, HIPPA, and FIPS, there are requirements that must be met:

  • Identities and SSH keys should properly managed to ensure protection of PII and other sensitive data
  • Keys should be rotated when in use for a long time, and deleted if they are no longer active
  • The policy of least privilege should be followed. This means that users should only have access to information they absolutely need, and nothing more. This stops attackers who steal keys from accessing the entire remote system
  • Keys should be swiftly replaced in the case of loss or compromise
  • Security of areas containing payment information or PII data should be especially monitored and segregated from other portions of the network

Best practices for SSH key management

The process of properly managing SSH keys is very important to do correctly. You must ensure full coverage of your organization’s keys and proper coverage of any security vulnerabilities. Following are a series of suggested best practices for proper SSH key management.

  • Discovery and Consolidation

    The first step in the SSH key management process is discovering what and how many keys have been distributed throughout your organization. Keys should be associated with the users and servers they correspond to, and they should be continually checked for how long they have been used. They should be rotated if they have been around for a long time. If the user authenticated by the keys is no longer with the organization, the keys should be deleted to prevent abuse of the key pair. The keys should also be consolidated to one area with the organization. This helps with the management of keys while reducing the attack surface of the keys. Centralizing the storage of the keys helps prevent solo keys and key sprawl from occurring.

  • Policy Creation and Enforcement

    The next step is to create policies to protect the keys. These policies should define:

    • Who can create keys
    • How to create and store keys
    • What keys are created for
    • How long keys should exist before rotation
    • What justifies deletion of a key
    • The maximum access a key should have
    • As long as these policies are enforced by the organization, keys should not be mismanaged and attack vectors for threat actors should be greatly reduced. These policies are the heart of SSH key management, so enforcement of these policies should be made a priority in any organization’s security plan.
  • Risk Identification and Neutralization

    Any and all security vulnerabilities relating to SSH keys should be identified and eliminated. With the centralization of the SSH key pairs, identifying issues becomes easier. Security technicians should look for old or unused keys, insecure storage options, or compromised keys. As previously stated, old keys should be rotated and unused keys should be deleted. This step in the process maintains the remote systems and ensures their continued safety.

  • Key Rotation

    Keys should be rotated regularly, once they have been in use for a while. Both keys in the key pair must be rotated with new keys. This reduces the risk of a key becoming compromised from security technicians not protecting the key as they do not know what it is for. This also reduces the risk of key sprawl. Automation of this step greatly reduces the risk of human error where a key is overlooked and not rotated.

  • Continuous Monitoring and Auditing

    The final step is to continually monitor and audit the keys to ensure they are rotated and deleted at the appropriate times. Without continual monitoring, keys can fall through the gaps and be left after the user has left the organization, opening the company to compromise from threat actors. Through continued monitoring, the risk of key sprawl, solo keys, and not meeting compliance are all taken care of. Automation of this step in the process would eliminate human error from occurring.

SSH key management with Encryption Consulting

Encryption Consulting provides a variety of methods to create your own successful system for SSH key management. We hold monthly webinars relating to SSH key management, encryption key management, key protection on the Cloud, and more. We also provide assessments and training for Cloud key management on AWS, Azure, and Google Cloud Platform. We can ensure your system is meeting compliance standards, and protecting data with the best methods available. We also write weekly blogs that can help you find the best practices to use for your key management needs and learn more about the different aspects of your organization’s data security needs.

Free Downloads

Datasheet of Encryption Consulting Services

Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all aspects of encryption for our clients.

Encryption Services

About the Author

President at Encryption Consulting LLC focusing on providing consulting to customers in the Applied Cryptography space.

SSH or Secure Shell or Secure Socket Shell is a network protocol is how users, sysadmins can access other computers over an unsecured network.

SSH provides strong password and/or public key authentication using which a sysadmin or network admin can connect to any computer or application remotely, execute commands and also move files using SFTP or SSH File Transfer Protocol.

Where can we use SSH?

We can use SSH protocol in various scenarios such as:

  • Providing secure access for users and automated processes
  • Interactive and automated file transfers
  • To issuing remote commands
  • Managing network infrastructure and other mission-critical system components

How does SSH work?

SSH protocol works in a client-server architecture, thus an SSH client connects securely to an SSH server. SSH client would drive the connection set up process and use Public Key Infrastructure to verify the authenticity of the SSH server. Following the setup, SSH protocol uses strong symmetric encryption and hashing algorithm to ensure privacy, and integrity of the data exchanged.


What kind of authentication can be used with SSH?

Several options can be used for user authentication. The most common ones being passwords and public key authentication.

Public Key authentication is mostly used for automated purposes and system administrators for single sign-on. There are two keys namely, the public key and the private key. The public key is configured to the server, and anyone with the private key is granted access to the server and authentication respectively. These private keys are also called SSH Keys.

SSH Key-based authentication is primarily used to enable security automation. We can have automated secure file transfers, automated systems, and also bulk configuration management which can turn out to be helpful.

Using SSH protocol to communicate can be beneficial as SSH provides strong encryption over the messages transferred and also integrity protection against any attacks. Once the connection is established between the SSH client and the SSH server, the data is encrypted using the parameters that were exchanged during the setup. During the setup, symmetric encryption is agreed upon, and keys are exchanged to continue the communication via symmetric encryption. The data transferred between the client and the server is encrypted using industry-standard strong encryption algorithms (such as AES), and the data is also hashed to ensure the integrity of the data being transferred. A hashing algorithm such as SHA-2 is used for this purpose.

Free Downloads

Datasheet of Encryption Consulting Services

Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all aspects of encryption for our clients.

Encryption Services

About the Author

President at Encryption Consulting LLC focusing on providing consulting to customers in the Applied Cryptography space.

Secure Socket Shell (SSH), also known as Secure Shell, for convenience, is a popular protocol that operates on the principle of public key cryptography. Primarily used to secure private transactions, they are leveraged to institute authentication on both the server-side and client-side. It is important to note that the Secure Shell is used to encrypt data flowing to and from a remote system. Some typical use-cases of this kind of cryptography include system-to-system file transfers, remote logins into computer systems, and automated server access without having to manually log in.

One of the biggest benefits of SSH Keys is their resilience against cyber exploits, such as brute-force attacks, given that passwords are not required to be exposed over the web in the transaction. It also features most of the key capabilities of PKI and fundamentally works on the principle of public-private key pairs.

To the uninitiated, SSH Keys and x.509 certificate-based authentication (which also involves public and private keys) might seem similar, but in truth, they could not be any more different.

SSH Keys vs x.509 Certificates – Key Differences:

While x.509 certificates rely on digital certificates and issuing bodies (Certificate Authorities) to sign private keys, SSH Keys are not governed by any institution. They are created, circulated, and used within transacting partners and organizations, and can be managed without any external interference.

That aside, they also possess functionality that their counterparts don’t – the ability to enable remote access to systems. On the other hand, TLS certificates cannot provide that sort of functionality on its own, unless deployed alongside other protocols like FTP.

Risks associated with SSH Keys:

The absence of a governing body presents a veritable challenge in managing SSH keys – a lack of organization. SSH Keys are generated based on need, and when ad-hoc processes govern the issuance of these keys, there’s bound to be key sprawl. This means keys are discarded once they are declared useless or vulnerable, and a lack of inventory renders them difficult to keep an eye on – considering the fact that large organizations may possess hundreds of thousands of SSH keys on file. However, their presence on the server makes them possible back-doors to potential hackers, which can then be abused to conduct data espionage, theft, or breaches.

Key rotation, another important function, is often ignored by administrators. A stale key presents a weak link to malicious actors, which can, again, be abused to exploit network resources.

SSH Key Management Best Practices:

If you do not possess organizational directives toward SSH key handling, it would be in your best interest to institute one now. Enforcing strict policy, exercising audit tracking, and possessing full control and visibility into the SSH key infrastructure can go a long way towards bettering the cyber health of the org. Automation of management is also an excellent way to do this – there are tools available that can actively manage and automate the entire SSH key lifecycle. In the meantime, here are some best practices you can start following immediately to take your cybersecurity up a notch.

Gain Complete Visibility:

Only by finding and locating the keys on your system can you protect them adequately. Run periodic discovery scans across your network with an appropriate tool to locate and inventory all SSH keys. Once this is done, map them with the endpoints they are tied to, and tag them with all the information an administrator would need while dealing with them, such as passcodes

Rotate Keys Regularly:

Stale SSH keys present a golden window of opportunity to hackers who may try to crack their passcodes and infiltrate the server. Set up policy that enforces regular generation, re-keying, and rotation of SSH keys, and ensure that all stakeholders are duly notified when this happens. Care must be taken NOT to reuse passcodes, and to use fresh credentials each time. Automating this process in large organizations can save several man-hours and significant operational costs.

Enforce Audit and Policy:

Create org-wide policy, and ensure that operations/IT personnel adhere to it – For instance, policies on regular key rotation. Furthermore, make liberal use of audit trails using specialized software, in line with industry regulations, to maintain tabs on the use, reuse, and application of all your SSH keys.

Create Role-based Permissions:

Prohibit access and modification of SSH Keys or their credentials by all the personnel in your team(s). Use directory services to provide different levels of privilege for each user category, to prevent haphazard control and promote audit trail.

Avoid the Use of Hard-coded Keys:

When SSH keys are built-into or packaged with software applications, they present a dangerous security vulnerability. Why? Since they’re governed by passphrases, a carelessly issued SSH key with a weak passphrase may be the weak link in an application that hackers could potentially exploit, compromising the integrity of the entire applications. Ensure that SSH keys are centrally managed by a dedicated management system.

If you’d like professional assistance with setting up a scalable SSH key management system, feel free to reach out to us at, and to discover the capabilities of an SSH key lifecycle management and automation tool and how it can fit into your IT processes, visit

Free Downloads

Datasheet of Encryption Consulting Services

Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all aspects of encryption for our clients.

Encryption Services

About the Author

President at Encryption Consulting LLC focusing on providing consulting to customers in the Applied Cryptography space.

Let's talk