Key-Based Authentication: Using Cryptographic Controls To Manage Access To Enterprise Resources

Enterprises have a wide array of resources to protect: file shares, email servers, production systems, databases, source code repositories, DevOps tools, and more. If key-based authentication is enforced for all of these different resources, and the keys are secured in a centrally-managed KMS or HSM, the enterprise can easily enforce granular controls, monitor access to resources, audit key usage, and restrict access as required. Learn more in this post.

Authentication is the process of verifying an end-user’s identity to make sure they’re the person they say they are. While there are many different ways to authenticate an end-user, this post will explain key-based authentication and discuss how it can be layered into any enterprise environment to strengthen security, centralize policy enforcement, and simplify audits.

An Overview of Authentication

The first step to authentication is identification. This is when an end-user declares an identity, normally by entering a username. Authentication is the process that verifies the end-user is, in fact, the entity they are claiming to be.

There are several ways the enterprise can authenticate end-users:

  • Something They Know – a password, passphrase, or PIN
  • Something They Have – a smart card, physical security token, or mobile device
  • Something They Are – biometric factors such as fingerprint, voice, or retina scans

 

Sometimes, other factors are taken into account, such as “somewhere they are,” based on geolocation tracking via GPS and IP address monitoring, and “something they do,” like the way that an end-user types, which can be identified through keystroke analysis.

Multi-Factor Authentication

Multi-factor authentication is any authentication process that uses more than one form factor to verify the identity of end-users. MFA provides an incredible boost to security: Microsoft states that “MFA can block over 99.9 percent of account compromise attacks.”

Consider the inverse of this finding: systems that only require end-users to enter the password associated with their username are vulnerable to compromise. This is true because end-users cannot be relied upon to create strong passwords. They may use short and simple passwords, which can be easily cracked through brute force attacks, or they may use passwords that are related to their personal life and relatively easy to guess with social engineering tactics.

It’s hard to overstate the importance of multi-factor authentication. It should be implemented in place in every enterprise environment, and enforced on every sensitive resource.

Key-Based Authentication

Key-based authentication, also called cryptographic authentication, is the process of using cryptographic keys in a challenge-response handshake to prove one’s identity. This falls in the “something you have” category.

Key-based authentication is already deployed widely throughout every enterprise environment. Protocols like TLS, SSH, and remote desktop (RDP) all use cryptographic keys for authentication purposes. The process works as follows:

  1. An end-user sends a request to access a particular resource to a server.
  2. The server generates a random value and sends it to the end-user, requesting that the end-user sign that random value with their private key to verify their identity.
  3. The end-user uses their private key to sign the random value and sends the resulting digital signature to the server.
  4. The server uses the end-user’s public key (sometimes extracted from a certificate) to verify the digital signature.
  5. If the digital signature is valid, the server approves the request and gives the end-user access to the resource they need.
  6. The end-user accesses the resource. When the session is terminated, they will no longer have access to the resource and will need to authenticate again to regain access.

Private Keys Must Always Be Private

It’s important to keep in mind that the private keys must always be kept private. Unlike passwords, which are typically known (in some form) to both the user and the verifier, private keys are unshared secrets, which means they must always be kept secure and never shared with anyone.

If attackers steal a private key, they can authenticate to a server just as the authorized end-user would. That’s true because cryptographic authentication assumes that only the authorized end-user has access to the private key. Unfortunately, in many cases, sensitive cryptographic keys— TLS keys, SSH keys, RDP keys, even file and database decryption keys— are left unprotected in software on endpoint devices. This creates serious vulnerabilities, introduces significant risks, and may present compliance challenges.

It is essential to store all private keys in a hardware security module (HSM) or secure key manager to keep the keys out of the hands of threat actors. When the private keys are properly secured in an HSM, key-based authentication provides an extremely high level of security. It’s practically impossible to steal the keys from the HSM and, assuming that only authorized end-users have access to the keys, the resources that require key-based authentication will also be extremely secure.

Authentication Upon Authentication

Enforcing cryptographic authentication and storing the private keys in a centrally-managed HSM greatly improves the enterprise’s security posture. The next step is to ensure that only authorized end-users are able to use the private keys. This requires another layer of authentication.

With the keys centrally secured and managed, end-users must send a request to the key management system every time they need to use a key. The end-user is allowed to use a key, but the digital signature is generated without the key ever leaving the HSM.

Additionally, the enterprise can authenticate the user through multiple factors, including MFA, device authentication, approval workflows, and more, before approving the request and allowing an end-user to use a key. This effectively enforces those strong controls on the downstream resource— no matter whether it’s a file share, email server, database, source code repository, web application, or production system— without requiring any modifications to the server itself.

In addition to significant security benefits, this architecture provides a few other advantages:

  • Policy is set from one interface on a per-key or per-user basis.
  • Access to keys is centrally granted, revoked, monitored, and managed.
  • Granular security controls can be enforced with a few clicks.
  • All key usage is logged and auditable, simplifying compliance.

 

Get in touch with the Garantir team to learn more about deploying this cryptographic architecture in your environment.

Share this post with your network.

Share on linkedin
LinkedIn
Share on twitter
Twitter
Share on reddit
Reddit
Share on email
Email