Prevent phishing with end to end encryption

Linda Ikechukwu

Follow Smallstep

This article is the second is a series of three examining how shared secrets used in traditional authentication methods make room for social engineering attacks (like phishing) and how adopting alternative methods, like device attestation and certificate-based authentication, can migitate these risks.

In my previous article, I discussed how traditional authentication methods, such as passwords, security questions, OTPs and push notifications, are vulnerable to social engineering attacks, since secrets must be transmitted between client and server. I argued that asymmetric cryptographic based authentication methods are more secure because the private key is kept private and never transmitted, making them unphishable and ideal for granting access to internal infrastructure or protected resources such as an application, database, software module, or device.

Is your organization at risk of being phished?

Phishing, the most prominent social engineering method, tricks people into giving away sensitive information by exploiting the "human loophole." Rather than trying to forcibly access a protected resource, which would be difficult and costly, cybercriminals can use a mixture of fear, urgency, and fake legitimacy to fool even security-aware employees.

According to the Verizon Data Breach Investigations Report, 20% of data breaches in 2022 were social engineering attacks, and 66% involved phishing and stolen credentials.

Additionally, the 2022 Phishing Benchmark Global Report by Terranova Security, which analyzed over 250 organizations and 1.2 million users who participated in a phishing simulation, revealed that 7% of employees at large enterprises clicked on a phishing link. And, of those who clicked the link, 44% eventually filled out the web form on the next page and submitted their credentials.

To put this into perspective, if an organization with 1000 employees was targeted with a phishing attack, 70 of their employees would click the phishing link, and over 30 of those would have entered their credentials. While these numbers might seem low, it only takes one privileged end user to click on a malicious link or enter their credentials for attackers to gain access to an organization's network.

So the answer is YES! Your organization is vulnerable to phishing attacks as long as it has human employees regardless of the security awareness and training programs they’ve participated in. Organizations like yours have been victims of phishing attacks in the past and will continue to, unless preventative measures are taken. Even Twitter employees were tricked by cybercriminals into providing them with access to internal tools, resulting in one of the most famous social engineering attacks of all time.

A refresh on phishing approaches

To understand how device attestation and certificate-based authentication can protect your organization from phishing attacks, it may be helpful to review some common phishing formats and past incidents. Phishing attacks are often launched through emails, with attackers impersonating trusted entities or exploiting trusted relationships to gain unauthorized access to devices or networks. There are two common formats:

Generic Email phishing

In a generic email phishing scam, attackers target multiple employees. A generic email phishing attack might play out like so.

1. An attacker creates a fake domain that looks like a legitimate organization. The fake domain uses clever character substitutions to make it harder to spot discrepancies. For example, using 'r' and 'n' next to each other to create 'rn' instead of 'm’, like srnallstep.com instead of smallstep.com.
2. The attackers then send a mass email to as many employees as possible, claiming that the user's password is about to expire and giving instructions to renew it within 24 hours.
3. Clicking the link can lead to the user being redirected to a bogus page where the attacker can steal their password or to the actual password renewal page where a malicious script can hijack the user's session cookie, resulting in an XSS attack and unauthorized privileged access.

The Sacramento County incident is an example of a generic phishing attack. In June 2021, five employees fell victim to a phishing scam and revealed their login credentials to cybercriminals. The attack remained undetected for five months, until an internal audit of employees' email inboxes. The employees received phishing emails with a link to a malicious website, and entered their usernames and passwords into a fake login page, which were then harvested by cybercriminals. As a result of the attack, 2,096 health records and 816 personal identification records were exposed in a data breach.

Spear phishing

Spear phishing is similar to email phishing in that it targets or impersonates specific individuals within an organization, particularly high-ranking executives, and it requires knowledge of the organization's power structure. Email recipients may be hesitant to confront the sender, even if they suspect something is wrong, due to the power difference. A spear email phishing attack might play out as follows:

1. The attacker researches employees in the marketing department and obtains access to the latest project invoices.
2. The attacker poses as the marketing director and sends an email to a project manager with a subject line that duplicates the organization's standard email template.
3. The email contains a link that redirects to a password-protected document, which is a spoofed version of a stolen invoice.
4. The project manager is asked to log in to view the document, and the attacker steals their credentials, gaining full access to sensitive areas of the organization's network.

Perhaps the most successful spear email phishing attack of all time was conducted against a Belgian bank, Crelan. Crelan’s CEO fell victim to spear-phishing after allegedly receiving an email from someone posing as a major business partner, asking him to transfer money to a desired account to finalize an urgent business transaction. The attackers got away with $75 million and have never been brought to justice.

Phishing attacks don't only happen through emails; they can also occur through smishing - phishing through SMS text messages. Scammers purchase spoofed phone numbers and send out messages containing malicious links.

Despite the format, one thing remains constant: sensitive credentials are transmitted from one point to another, providing an opportunity for attackers to intercept them. But what if we could eliminate authentication methods that require sensitive information to be transmitted, and instead use authentication methods where sensitive credentials never leave a special tamper-proof crypto processor on the user's device?

In the previous article, I concluded that organizations need to adopt authentication methods that do not:

• Use easy-to-guess credentials
• Put the burden of coming up with credentials on the user
• Need to share or transmit sensitive credentials to prove identity

A combination of device attestation and certificate-based authentication satisfies all of the above conditions.

Device attestation as a first line of defense against phishing

Device attestation is a security mechanism that can be used to provide strong cryptographic proof to affirm that a device attempting to access a resource rightfully belongs to an organization, and is authorized to do so.

Here’s one way device attestation can work for your organization: your organization probably already uses a Mobile Device Management (MDM) platform to manage and keep track of trusted devices, their unique identifiers, and their assigned users. In this era of remote work, device attestation can provide the first line of defense against phishing and unauthorized access into your network by significantly reducing the risk of an unknown device posing as a known device and being enrolled into your MDM.

MDM solutions typically use Simple Certificate Enrollment Protocol (SCEP) for device enrollment. Employees connect to an MDM server with their credentials, and the MDM solution sends a passcode and command blob to the device. Then the device requests a certificate from the SCEP server using the passcode. While this process has been efficient, it hinges on the presumption that employee credentials or the passcode cannot be intercepted, and will only be used on the intended device. But that isn’t always the case. A phishing scammer can steal access credentials or intercept the command blob sent from the MDM server, and can then add an unauthorized device to your list of managed devices.

In contrast, ACME device attestation based on the new acme-device-attest-01 challenge allows for a more secure device enrolment process by validating the identity of a device using strong attestation obtained from a cryptographic hardware within the device and cross referenced against an attestation server. This makes it significantly harder for an unknown or unauthorized device to pose as a known device and join your network.

Modern devices are equipped with tamper-proof crypto-processors, like Trusted Platform Modules (TPMs) or Secure Enclaves (found in Apple devices). These processors are isolated from the main processor, ensuring that data stored within them remains secure even if the rest of the device is compromised. As such, they can be used to store unique device-specific credentials and generate cryptographic keys that can indisputably verify their identity.

To adopt this more secure method of device enrolment using ACME device attestation, you will need two additional components besides your MDM server: a trusted attestation server and an internal ACME CA that supports the acme-device-attest-01-challenge, such as the Smallstep CA. The attestation server, which may be run by either the device manufacturer or your organization depending on the situation, is responsible for keeping track of all devices and their unique identifiers. The internal ACME CA acts as a root of trust and gatekeeper of your device ecosystem, verifying attestation claims and issuing certificates for everything within your fleet.

With this setup, when you ship a new trusted device to an employee and they turn it on for the first time to enroll with your MDM server, they can enjoy seamless Secure Zero Touch Provisioning. Here’s how the whole flow would go:

1. The MDM server instructs the device to go get a cert from your internal ACME CA to authenticate itself. But to get a cert from the CA, the device needs to provide an attestation statement in response to the acme-device-attest-01 challenge from the CA.
2. The device sends a request to a trusted attestation server to get a device identity attestation statement.
3. The attestation server verifies the device's unique credentials stored on its crypto-processor to ensure they match the expected values and issues an attestation statement.
4. The device presents the attestation statement to the CA which the CA uses to verify the identity of the device. The CA can verify the attestation statement because crypto-processors are shipped with an unextractable private keys injected during manufacturing, of which the manufacturer certifies its public part. Upon successful validation, the device obtains a device certificate the CA.
5. Using the device certificate obtained from your CA, the device authenticates itself and is then enrolled into your MDM.

If you’ll like to dive deeper into the technical details of ACME managed device attestation, we’ve written more on that here and here.

Certificate authentication as the second line of defense against phishing

With a device enrolled into your MDM, the MDM server, knowing the employee associated with a device, can then configure the device to request additional client certificates tied to the employee's identity for accessing protected resources like websites or databases. Once there’s a client certificate and an identity, your organization is set for mutual authenticated encrypted communication between everything within your network, and finer-grained access control, authorization, and monitoring.

Imagine this: the workday is just starting and an employee needs to access their corporate email account or another cloud-based app from their work PC. They only need to Single Sign-On (SSO) into Azure AD or whatever Identity Provider (IDP) your organization uses. The flow would go something like this:

1. The client will initiate a connection to the server.
2. The server will respond with a nonce to sign, and request the client's certificate.
3. Using the private key which is generated, stored, and cannot be extracted from the secure crypto-processor, the client signs the nonce and sends that along with its certificate containing its public key.
4. The server receives both the certificate and the signed nonce. Using the client's public key, which is contained in the certificate, the server verifies that the nonce was signed by the client's private key. This ensures that the certificate actually belongs to the client and that someone else did not simply grab the public key and present it as their own. The server also checks that the certificate has not expired or been revoked, and that it was issued by your trusted internal CA. If authorization is enabled, the server can additionally verify that the certificate subject is authorized to access it.
5. If all the verifications pass, access is granted. And if any fails, access is denied.

More benefits of the Device Attestation + Certificate authentication combo

In addition to being phishing-resistant and protecting your organization from social engineering attacks, device attestation and certificate-based authentication offer two more significant benefits: they improve the user experience (UX) of authentication for employees and save your organization time and money.

With device attestation and client certificate authentication, you don't have to sacrifice convenience for security. The entire process is designed to be as quick and seamless as possible from the end user's perspective, eliminating several initial steps in a traditional authentication process. The device acts as the access point, and your employees do not have to remember passwords, deal with insecure password practices, one-time passwords (OTPs), or other convoluted authorization measures that are frustrating. Also, your organization can save cost and time on those security awareness and training programs, and make phishing click rate irrelevant.

Unphishable authentication is possible and Smallstep makes it simple

Social engineering attacks are becoming more sophisticated every year, especially with advancements in AI and deep fake technology. Adding more steps to authentication processes won't solve the problem of phishing. Attackers can only gain access if secrets and sensitive credentials are transmitted. The answer is easy: eliminate shared secrets. Keep your secrets - your private keys - to yourself. Use device attestation + client certificate-based authentication.

Smallstep is an end-to-end encryption solution for trust and identity management. We can secure everything and anything within your organization — devices, workloads, and people. You can seamlessly and cost-efficiently adopt enhanced authentication workflows like device attestation and certificate-based authentication, making it easier to protect your infrastructure and maintain a healthy trust posture.

Talk with us today about making your organization unphishable.