Author Profile
Image credit: Unsplash
Passkeys are emerging as a popular passwordless phishing resistant authentication technology. Passkey is a friendly brand name for a set of standards supported by browsers, web services, identity providers and more. The standards like FIDO2, WebAuthn and platform authenticators dont have the same ring as “Passkey”. At the heart of these authentication mechanisms is a technology that Apple calls “Secure Enclave” chips and the broader industry calls TPM chips. The TPMs are like mini HSMs that sit inside our laptops, tablets and mobile phones. They can create private keys inside these TPMs in such a way that no one can read the private keys including the attackers.
These TPM chips can be used for much more than phishing resistant authentication. They are used by Apple for the ApplePay payment system. They are used for verifying integrity of software that’s installed on the devices and much more. We estimate there are more than two billion devices in consumer hands that can perform these secure signature operations. For the first time in the history of the internet we have a reliable way to identify users using these chips and attribute their actions. This will allow us to approach cybersecurity in a fundamentally different way.
Why is this important?
One of the biggest reasons this is important is the evolution of generative AI technologies. The voice, image and video generation capabilities of generative AI technologies have gotten so good that we can not tell the difference between a real person and a deep fake online. This will lead to all kinds of social engineering attacks. Every form of digital interaction we can have today can be deep faked. We can not tell if the person on the phone is our boss or an AI. We can not tell if the person on the zoom call asking us to wire money is our CEO or a generative AI bot. This can lead to huge explosions in social engineering attacks. We currently have no way to protect against such attacks.
But no amount of generative AI can deep fake a private key (assuming the key is big enough). Using non-extractable private keys in a TPM is the only way we can defeat the AI bots. But to defeat the social engineering techniques we discussed above, we need more than phishing resistant authentication. We need reliable ways to attest facts and prove possession for every action or transaction. For example, a HR person could attest he/she has checked an employee’s government issued identity. A hiring manager could attest they have issued a specific device to a new employee. A finance employee could attest he/she has approved a wire transfer. A good example of this is iMessage contact key verification feature recently introduced by Apple. It provides you a way to verify a person’s authenticity cryptographically using secure enclaves. It is unfortunate that consumer technologies are doing this better than the enterprise identity systems.
Attestation
Whatever is your view of the blockchain technologies; maybe you are a skeptic and you think Bitcoin and other shitcoins are all a giant ponzi scheme. Maybe you are a believer and you think blockchain technologies will fundamentally change financial services as we know it. Whatever is your view, you have to give credit that Blockchain technologies have made a few cryptographic concepts mainstream. We could make use of them more often in the cybersecurity world. Three of them in particular are very relevant:
- Concept of hardware wallets: Store a private key in a hardware wallet and it becomes your identity.
- Signing every transaction with the private key stored in hardware wallets. This attests the transaction was performed by a specific identity.
- Maintaining a tamper-proof audit log of all signed transactions as an immutable ledger. This becomes the source of truth in terms of knowing who performed what action.
These cryptographic concepts are not new. We have known how to do these since the 70s. What is new is that our devices can act as hardware wallets now because of TPMs. This means that we can sign every action we perform online using these hardware wallets. We can maintain an audit log of these signed actions as a proof of who performed them. More importantly, we can do this with a really good user experience. It can be as simple as paying with your Apple Pay on your phone.
In this blog series you will see this pattern of signing actions/transactions using hardware wallets being used repeatedly for various attestation purposes. Everything from authorizing specific actions, to certifying code commits to signing images. We will use the example of the Procyon solution to describe how we implement some of these techniques. In theory, you can do this by yourself too.
User impersonation and social engineering
Most common way the attacker can impersonate a trusted user is by compromising the credentials associated with the user. Luckily passkeys can solve the problem of simple credentials like passwords. They can prevent the basic phishing attacks. But they don’t address two other common forms of impersonation attacks:
- Session hijacking attacks like stealing post authentication tokens like session cookies, bearer tokens, kerberos tickets etc.
- Attacker adding themselves as a trusted user by social engineering.
We will discuss ways to prevent these attacks in this section.
Session hijacking attacks
As recent Okta support systems breach highlights, session token(or cookie) theft is the easiest way to bypass all authentication systems. According to publicly available data, the Infostealer malwares are posting 17 million stolen credentials every month to the dark web. Most of these are post authentication credentials like bearer tokens. You might have the most secure phishing resistant authentication system. But if the attackers steal the post authentication session token, they have effectively bypassed it.
One way to solve it is to not rely on session tokens and use TPM based signatures to re-verify every subsequent session is coming from the same trusted device. But doing this for every request becomes too expensive computationally. Better way is to maintain a persistent connection, something like a mutual-TLS connection to the IDWall so that the IDWall can verify the requests are coming from the trusted device and send this attestation information to the backend servers in request headers. Procyon’s solution follows this approach to prevent session hijacking attacks.
Attacker adding himself as a trusted user
Second problem is how do we prevent the attacker from adding himself as a trusted user. In the enterprise context, we can rely on something like the HR department to attest to the users. Or maybe it is the hiring manager who attests for the employee and so on. We would also need to have a good process to make sure the devices associated with the user are also attested by someone. Ultimately the security of our system completely depends on how reliable this process is. Imagine if the attacker can call the corporate help desk and pretend to be one of the employees and say he has lost his previous device and needs to be on-boarded on a new device. If the help desk person onboards the new device(which is owned by the attacker) without verifying the identity of the caller, the attacker can bypass all security controls.
This is another area where the Procyon solution excels at. It has a number of techniques to prevent the attackers from social engineering their way into impersonating trusted users. Procyon also has the ability to prevent attackers adding themselves as trusted users by compromising Procyon itself. We do this by maintaining an immutable cryptographic signature log of which user onboarded the new user and device. Even if an attacker compromises Procyon, without the private key of a user, they can not modify the immutable log.
IDWall and gateways
We introduced the concept of IDWalls in the previous blog post and we described how we want to identify the user before they can exploit the vulnerability in the software. Putting the entire software ecosystem behind an IDWall is quite a complex challenge. The software ecosystem we have built over the last 50 years is a complex beast. At a high level it is easy to say that we have applications in the cloud and users are accessing these applications from their devices, we need the IDWall between them. On the surface, this looks like an API gateway pattern that most modern microservices based applications use.
In this pattern, Users on the left hand side of this picture all come through the API gateway. API gateway knows how to authenticate and authorize the users and then handoff the API calls to individual microservices with some user metadata(in the form of a JWT) so that individual microservices can make more fine grained authorization decisions based on the user’s role or attribute. API gateway also maintains an audit log of the API calls made by the users.
But the challenge is, the existing software ecosystem doesn’t look anything like these modern microservice applications. There are a lot of legacy softwares that were developed over decades. Many of them use legacy protocols other than HTTP used by modern webapps. Many of them use legacy authentication methods. Sometimes the demarcation between the user and the application is not clear. It might be an application making the call to another application on behalf of a user. Or it might be a user logged into a remote virtual desktop service. Maybe it’s an RPA bot that is acting on behalf of a user.
What we really need is an IDMesh that understands these legacy protocols and authentication methods and can translate them and interop with existing software without requiring them to be changed. This IDMesh will need to understand the context of the request to know who is actually performing them. This is what solutions like Procyon specialize in. We have connectors for many forms of legacy applications and protocols. Since Procyon focuses on highly privileged users our connectors tend to favor developers and devops teams. We don’t claim to solve all of your identity threats. But we are confident this is the right direction to move forward.
IDMesh
In an ideal world, we would need to protect every network call using some form of IDWall. ServiceMeshes take this approach and have a sidecar process running inside every workload that acts as an identity checkpoint. This approach may not be practical in all scenarios. Some might prefer to do it per application, per subnet, per VPC, per cloud account etc. this is the same as how do you define a trust boundary during threat modeling exercise.
You can think of these trust boundaries as cells and all communication between these cells need to contain identity information. If we take the example of the Procyon solution, it looks like a mesh network of gateways. We call some of the smaller gateways as relays. These can be co-hosted with the workloads as sidecars or inside private VPCs. All these gateways discover themselves and establish a mesh-like overlay network between them. Once this mesh network is established, all communication between the workloads and services contain identity metadata about them. Some of this metadata contain workload or service identity and some contain the user identity. We will discuss different types of metadata in subsequent blog posts.
Next
In the next post in this blog series we will look at how to secure highly privileged users in the Security 2.0 stack and start discussing how the IDMesh takes shape.
Please click here to read the next post in the blog series.
Here are the links to other posts in this series:
Related Posts
