NHI Security, Part 2: Identity and Secrets

Overall, identity is a deeply complex subject. However, viewing it through the lens of cybersecurity narrows down the topic and makes it simple. Identity enables us to assign a name to a unique instance of something. In turn, this name allows us to bind attributes and actions to the instance, such as the responsibility to perform jobs and functions, authority to take action, and a record of what a named instance has done through logs.

But while identity in the context of cybersecurity may be simple, proving identity is not.

Proof of identity is called authentication, and there are countless ways in which we can provide this proof. Where it gets tricky is showing evidence to prove identity without also giving someone else the ability to copy the evidence and claim the same identity.

This gets even trickier in the context of Non-Human Identity (NHI). We commonly talk about methods of authentication including something you are (e.g., biometrics), something you have (e.g., token), or something you know (e.g., secret). But these methods are all using a human frame of reference. These methods don’t apply the same to NHI.

As entertaining as it might be, AI agents aren’t likely to produce a biometric or pull a physical token out of their pocket any time soon. Without biometrics or physical tokens in digital space, we are left using secrets for authentication. However, in this same digital space, machines are faster than us and perfectly accurate copies can be made in the blink of an eye. Any evidence such as a secret that proves identity must be handled exceptionally carefully so as not to expose it to unwanted duplication.

The advent of asymmetric cryptography helped us out a lot on this front. With the appropriate bindings and assurances, we can use a publicly available key to encrypt something and know that only the holder of the corresponding private key will be able to decrypt it (and vice-versa). The problem is that all the bindings and assurances linking an identity to a public key are administratively cumbersome and technically fragile.

Let’s say Bob gets a digital certificate binding his identity to his public key from a recognized third party Certificate Authority (CA). What happens when that same CA goes out of business or gets internally compromised? Do we revoke the certificate and key, but let Bob keep the identity? How do we know someone hasn’t used a compromised certificate with Bob’s identity? Does Bob use the same identity while he’s working at Company X as when he quits and goes to work at competitor Company Y? Is Bob savvy enough to protect his private key against today’s AI-supercharged fraud attempts?

These same concerns and more translate into the NHI space. A compromise of a CA affects all certificates issued by that CA, regardless of whether used by a human or an NHI. The lifetime of something like an automated process may be shorter than Bob’s (let’s hope); but we still need to create and maintain a three-way link between the CA, the authorizing business org, and the NHI for each and every instance. And when it comes to protecting secrets from attackers, computers get tricked too. We call those vulnerabilities and exploits, and they can definitely result in a stolen private key.

In summary, NHI have few options when it comes to proving identity. The most realistic option is to use a secret; and just like humans, NHI must protect those secrets to prevent impersonation and keep their identity unique. Unfortunately, NHI live in a world where duplication of those secrets is fast, easy, and cheap… making management of those secrets paramount and underscoring the need for NHI-specific security policies.

Part 3: Policy Implications