Verifying the Verifier – Assessing Identity Verification Services

As artificial intelligence and machine learning (AI/ML) systems become more integrated into the applications that we use daily, it is inevitable that we will see them become tools that can be leveraged to help identify users. In areas of business where identities must be validated, such as the service desk or customer support, they can be used to help verify the authenticity of identity documentation that a user provides. 

These factors will present in many different forms ranging from biometric authentication mechanisms like facial recognition, to printed documents such as a driver’s license or passport. Regardless of the medium, the presented data must be checked against an authoritative database. While in many cases these integrations can return impressive results, the question must be asked: 

How can we ensure that these systems are being designed and implemented with security in mind as they are handling our most sensitive data?  

In this article, I will lay out the testing methodology that we employ to ensure that these systems are working as intended. Yet, before we get into the specifics of the methodology, it would be best if I gave you a high-level description of an identity verification assessment.  

What is an Identity Verification Assessment? 

An Identity Verification (IDV) assessment is a multifaceted, interdisciplinary process designed to evaluate whether an IDV system is accurately validating the legitimacy of the identities presented to it, as well as a high-level check to ensure that the underlying infrastructure is configured to securely handle sensitive information.  

The goal is to determine whether the system can reliably distinguish between legitimate and fraudulent identity data. This process helps identify vulnerabilities and provides recommendations for improving the system’s robustness and accuracy.  

IDV systems often focus on a single verification factor, such as ID cards, biometrics, or voice. These assessments begin by collecting original, authentic data (referred to as “control data”). This may include genuine voice recordings, government-issued identification, or biometric test cases.  

Next, the assessor creates altered or synthetic versions of this control data to simulate fraudulent attempts, commonly referred to as “spoofed” or “fake” data. These manipulated inputs are then submitted to the IDV system to observe how it responds. As the spoofed data is submitted, the assessor will also verify that technical controls are in place, and that the underlying infrastructure is handling data with best practices in mind. Additional application or network assessments may be recommended if baseline checks are not adequately met.  

Methodology 

An IDV assessment is performed across multiple phases. Broadly speaking, they are: Data Aggregation and Synthetic Data Creation; Reconnaissance; Baseline Validation; Adversarial Testing; Reporting Observations. 

Data Aggregation and Synthetic Data Creation 

At its core, this phase of testing is where it all starts. Through the scoping conversation, several factors are discussed and agreed upon before this phase begins. These factors include but are not limited to the number of original identities that need to be created for the assessment. 

It is also during this phase where the initial synthetic data will be created. If the assessment is designed to test a system that handles physical identity documents such as driver’s licenses or passports, it will be created using both out-of-the-box photo manipulation software as well as a suite of in-house custom tools. The identities would be taken from their original state and manipulated to create new documents. This would include swapping the face on the ID, changing the data such as the birth date, and updating the identification number or other relevant information that the ID contains.  

If the assessment is designed to test audio recognition, NetSPI will create deep-fake voices and attempt to bypass the voice authentication system. The original voice is run through a series of commercial and open-source tooling to clone, manipulate, and record new audio clips. Submissions to the IDV platform can be performed via real-time voice manipulation (e.g., through a live phone call), or programmatically to gauge its ability to detect replay attacks. 

Reconnaissance 

Once the data has been collected and the synthetic data has been created, the assessment moves to the next phase. The assessor will walk through the application, observing how it behaves when used by the intended, non-adversarial user. The assessor will be looking for a couple of key things at this stage: 

1. Does the application specify or restrict the types of documents that it accepts? 
2. What does the submission workflow look like? 
3. If the IDV system is an integration into an existing platform, does the integration follow security best practices? 
4. Is it using best practices for handling data and data submission? 

Baseline Validation 

Baseline validation frequently overlaps with reconnaissance and is often performed alongside it. Where reconnaissance aims to document how the system is meant to behave, baseline validation captures how it behaves when valid input is submitted. The assessor submits the original control data through each workflow and records what a legitimate submission looks like end-to-end. This will reveal which documents the platform accepts in practice, and the requests and responses exchanged with the application backend. This record becomes the reference point that the adversarial phase is measured against. 

Adversarial Testing 

In this phase of testing NetSPI will be acting as an adversary who is attempting to bypass the identity verification process. Working with the synthetic data, the assessor will submit the identities that they have created and observe how the platform handles those submissions. While they are submitting the synthetic data, the assessor will be looking for the following:  

1. How the platform handles synthetic identities and inputs crafted to defeat the verification workflows. 
2. How it responds to spoofing of environment-specific condition (e.g., device detection, sensors, audio fingerprinting, virtual camera detection, etc.) 
3. Whether the authentication process can be evaded entirely. 
4. If the network / HTTP traffic returns any sensitive data. 

Deviations from the baseline will indicate where deeper, targeted testing may be warranted against a specific component of the platform or integration. 

Reporting Observations 

Once the assessment has been completed, the assessor generates a report that will include any platform specific findings and reproducible proof-of-concept steps, as well as mitigation strategies that can be implemented. These recommendations are based on industry best practices as well as known standards including NIST 800-63-3. 

Test cases are categorized based on their medium, the type of attack that was performed, and the level of sophistication that would be required for a threat actor to replicate it. An example of what this looks like in practice would as follows: 

All the data collected will be consolidated and analyzed to identify insecure procedures. Vulnerabilities will be prioritized based on potential impact and likelihood. NetSPI will then formulate recommendations for mitigating identified security issues. 

Wrap up  

As the prevalence of generative AI usage increases, adversarial groups will continue to adapt and use it for their own means. One of the areas that it can have the greatest impact is for the use case of identity theft. The systems confirming our identities are the first line of defense when it comes to protecting our most sensitive information. They need to be audited with the same rigor as the networks and applications that house our data. 

NetSPI Security Testing Identity Verification

NetSPI tests whether your identity verification actually verifies identity, or just checks a box.