Identity is a foundational aspect of security. If we don’t know who is asking for a service, we can’t know whether or not they are authorized to access it. For this reason, humans need to authenticate before accessing anything. As humans, we are all very aware of the pain around authentication while appreciating its importance. However, we are often less aware that machines need to authenticate in exactly the same way as humans. When I send my password to my bank website, how do I know that it’s actually my bank and not a website impersonating it? The answer is that my bank’s website actually authenticates to me first, before I send my password.
What is Machine Identity?
Stated simply, Machine identity is the task of assigning identities to machines so that they can authenticate and access control can be enforced. Machine identity is sometimes between a human and a machine, as in the example above. However, most of machine identity is actually used for machine-to-machine authentication, as we explain below.
Why Do We Need to Identify Machines?
It is critical that all machines in a network be able to authenticate so that we can establish their identity. This is needed because in today’s zero-trust environments, we need to assume that attackers are inside our networks and eavesdropping on all communication. As a result, everything needs to be encrypted between machines, and this requires establishing identity. It doesn’t help machine A to encrypt a message it sends to machine B if it’s not really talking to machine B. This is solved by the machines first authenticating with each other, and then setting up an encryption key. Note that the above includes encrypting documents sent to a printer, requests from databases, reading from storage, and so on. Without authenticating the machine, it’s impossible to know whether that machine (or application) is allowed to query that data or read that file.
Cryptographic Keys and the Difference Between Machine Identity and Human Identity
All identity relies on a secret, and this secret is what differentiates the legitimate entity from an attacker. Without a secret, an attacker can do everything the legitimate entity can! Human identity is challenging and often requires the use of an easy-to-memorize password, which is typically weak. However, machines do not have this problem, and so strong cryptographic keys – specifically public keys and certificates – are used for machine identity instead.
The Importance of Effective Machine Identity Management
The fact that strong cryptographic keys are used for machine identity means that each machine and entity in an organization needs to be issued a certificate. Furthermore, certificates need to be managed: someone needs to ensure that they are issued to the right entities, that they have the correct policies built in, that they are rotated at the correct intervals, and so on. Given the huge number of devices (especially when noting that every virtual machine is a separate machine needing its own key), this requires effective management. Such management is used for the entire life cycle of keys — including generation of certificates — and issuing policies on allowed cryptographic algorithms and key sizes, deprecating and key rotation, and much more.
Lack of management increases the risk of poor cryptography hygiene, ad hoc policy enforcement, key theft and misuse, as well as high operational risk that can result in service downtime. This is not a theoretical risk. For just one example, in March 2021, Microsoft’s cloud Azure suffered a 14-hour worldwide outage due to a key rotation process error where a critical key was erased prematurely.
The Certificate Issuing Server Point of Attack
As we have mentioned, each key to each machine needs to be issued. Part of this process is the generation of a cryptographically signed certificate that asserts that a specific key is associated with a specific machine. This allows the machine to send that certificate as part of the authentication and key exchange process, so that the other machine indeed knows that it is talking to the correct entity. As a result, the certificate issuing server (often called a root certificate authority or root CA) becomes a major point of attack in the organization. This server constitutes a primary single point of failure since if an attacker steals the signing key for issuing certificates, then they will be able to impersonate any entity in the organization.
Needless to say, the potential damage of such an attack can be huge. However, beyond the threat of stealing the key, even if an attacker is just able to use the key to obtain a fraudulent certificate (e.g., by breaching the machine that is authorized to ask for a new certificate from the issuing server), it can impersonate any machine of its choice. For example, it could impersonate a machine that is allowed to query the customer database for all customer information.
The Challenge of Evolving Infrastructures
Machine identity, therefore, is just as important as human identity when it comes to protecting not just the information of end-users, but also the information of the end-user’s contacts, clients, and other connections in the greater supply chain. Ultimately, the signing key used by the certificate issuing server must be protected – both from theft and from misuse.
This requirement introduces challenges in deploying machine identity. For example, hardware-based key protection comes with operational challenges, and different environments requires different deployments. In addition, traditional HSMs and KMSs do not address key misuse. Finally, different environments (on-premise data centers and different clouds) all work differently. This makes managing keys in hybrid and multi-cloud deployments even more challenging. In addition, it complicates cloud migration, as the method used for managing and protecting keys needs to be changed.
Another risk that must be addressed relates to the keys that are on every machine in the organization. An attacker breaching a machine can steal the key that is used to establish that machine’s identity. Although this is a slower attack (each key needs to be stolen separately), it is still damaging.
A Need for Change: Recommended Best Practices
As a result of the new environments that organizations operate in, and the fact that machine identity is essential, new approaches to key management and protection are needed. Organizations need software solutions that work in a unified way across different environments, and they need to be able to orchestrate all of the keys used for machine identity. Furthermore, mechanisms must be in place to prevent key theft and key misuse, in order to ensure that the certificate issuing server doesn’t become the weak link that enables attackers to penetrate the organization.
Unbound CORE and Venafi
Unbound CORE provides strong key protection from both key theft and key misuse in software, using secure multiparty computation (MPC). In addition, Unbound CORE can fully integrate with certificate management solutions, to provide orchestration for the certificates used for machine identity. The integration of Venafi with Unbound ensures that the keys used by the Venafi certificate issuing server are strongly protected. The use of Unbound CORE for this purpose also means that Venafi can be deployed as a pure software solution (with all the obvious advantages), without compromising on security.
Unbound CORE’s secure enclave for mobiles and desktops can be used to protect keys that are on user devices. Looking forward to next year (2022), Unbound will release a secure enclave for servers that uses MPC to protect keys on any server in the organization, completing the protection of keys used for machine identity. Importantly, all keys in Unbound CORE are managed in a unified manner. Therefore, the same Unbound CORE that an organization uses today to protect the critical keys used by certificate issuing servers will include the capability to protect all keys on all servers next year.
Click here to watch a quick video from Unbound and Venafi on the evolution of machine identity.