This document is released under the Creative Commons (CC) BY-SA 4.0 License.
Caller ID spoofing is a global industry problem and often serves as a critical enabler of telephone fraud. CIV (Caller ID Verification) is a challenge-and-response mechanism that enables the terminating carrier to verify whether a caller is authorized to use the presented caller ID. It works with both IP and non-IP telephone networks and supports legitimate caller ID modification while detecting unauthorized spoofing. The verification result can be displayed on the receiver's phone, helping users distinguish verified caller IDs from potentially spoofed or otherwise unverified ones. Unlike STIR/SHAKEN, CIV does not require a public key infrastructure or trusted certificate authorities. It therefore offers a more cost-effective way to combat caller ID spoofing and provide recipients with assurance that the displayed caller ID is genuine. See Q&A for more information about CIV.
CIV video demo Four scenes showing CIV-enabled, illegally spoofed, legitimately spoofed, and non-CIV calls
The following Q&A addresses questions we have been asked previously. Some questions have been rephrased for clarity.
1. What is caller ID spoofing?
Caller ID spoofing, also known as number spoofing, is the practice of modifying the phone number displayed to the receiver during a call.
2. Is this legal?
That depends on the purpose and circumstances. There are many legitimate reasons to present a number different from the caller's direct line: for example, displaying a toll-free callback number or a central contact number for calls originating from within a large organization. These are established practices. However, caller ID spoofing can also be used fraudulently, for example to impersonate a bank, the police, immigration authorities, or tax officials. Scammers commonly use caller ID spoofing as part of social-engineering attacks to deceive recipients; such fraudulent use is illegal.
3. I didn't hear about caller ID spoofing before. Why has it suddenly become a problem?
Caller ID spoofing is not new. It has been possible since calling line identification (CLI) was introduced in 1987 as a telephone service for displaying the incoming caller's number. In the past, modifying the caller ID generally required specialised hardware or access to telecommunications infrastructure, so the problem remained largely invisible to the general public. With the rise of Voice over IP (VoIP), however, modifying caller ID in software has become straightforward. This ease of manipulation has enabled scammers and spammers to use number spoofing as part of social-engineering attacks on a massive, global scale.
4. It seems caller ID spoofing has existed for a long time. Is there any fundamental problem in its design?
Caller ID was designed to be trusted by the receiver, but without a built-in mechanism for verifying that trust. A basic security principle is that trust without verification is liable to be abused. The appropriate principle here is therefore: trust, but verify.
5. What's CIV, and how does it work?
CIV stands for Caller ID Verification. It is designed to authenticate the caller ID of an incoming call and verify that the displayed number is genuine. In practice, a cautious user may hang up and call back the displayed number to check whether it is authentic. CIV is based on the same intuition, but automates this call-back verification process so that it is transparent, secure, efficient, and incurs no cost to the verifier.
6. How does CIV distinguish legitimate and illegitimate spoofing?
CIV distinguishes legitimate from illegitimate spoofing according to whether the caller owns the displayed number. If the caller presents a different number that they own, the spoofing is legitimate; if they present a number they do not own, it is illegitimate.
7. Some organizations outsource the outbound calls and the inbound calls to different companies with little or no communication between them. Can CIV still work in such distributed call scenarios?
Yes. However, when an outbound call centre presents a number that terminates at a different inbound call centre, it must be able to demonstrate ownership of that number for the spoofing to be considered legitimate. If the organization owns the number, it should be able to configure call forwarding so that the CIV verification procedure can be completed. See Section 3.4 for more details on legitimate spoofing in CIV.
8. Are there other solutions available?
Several solutions have been proposed, including STIR/SHAKEN, AutLoop, AuthenticCall, CallerDec, and CEIVE. See our 2023 ACM TOPS paper for a review of these solutions. Among them, the most prominent is STIR/SHAKEN, which has been mandated for deployment in the United States and Canada.
9. What is STIR/SHAKEN?
STIR, short for "Secure Telephone Identity Revisited", is an IETF standard that uses digital signatures to provide authentication information for telephone calls. For an outgoing call, the originating carrier creates a Personal Assertion Token (PASSporT) containing information such as the calling number, called number, and time, and signs it as part of the SIP Identity header.
SHAKEN, short for "Signature-based Handling of Asserted information using toKENs", defines a framework for carriers to interpret and use the STIR authentication information. In particular, it introduces an attestation level in the PASSporT.
In practice, the combined term STIR/SHAKEN is commonly used to refer to this digital-signature-based framework.
10. Given that STIR/SHAKEN has been vetted and mandated for deployment in the USA and Canada, shouldn't every other country just follow?
Not necessarily. In 2023, Ofcom conducted a public consultation on whether the UK should adopt STIR/SHAKEN. In 2024, Ofcom decided not to proceed with its adoption. See Ofcom's final assessment report, and our contribution to this public consultation. Also, see our peer-reviewed paper (Section 1) for a review of the limitations of STIR/SHAKEN, which include: 1) reliance on a public-key infrastructure (PKI) and trusted certificate authorities (CAs); 2) lack of end-to-end operation across non-IP network segments; and 3) reliance on trusting the remote carrier to attest to the authenticity of the caller ID.
11. PKI and CAs are hardly uncommon or unfamiliar to anybody setting up a website. Why are they a problem for STIR/SHAKEN?
The PKI in STIR/SHAKEN presents a fundamentally more difficult cross-domain trust problem than the Web PKI. Under STIR, a valid digital signature establishes the authenticity of the signer and the integrity of the signed content; it does not, by itself, establish that every assertion contained in that signed content is true. A party with access to a valid private signing key can sign arbitrary assertions, and a relying party can verify that those assertions were signed by that key without independently establishing that the assertions themselves are true. This is often described as the "garbage in, garbage out" problem. This becomes especially difficult when trust must scale across national boundaries. For example, a STIR deployment in China and one in the United States would require an agreed basis for trusting each other's certification authorities. That arrangement cannot simply be assumed. The difficulty of managing certification authorities and scaling trust across borders was among the concerns considered in Ofcom's 2024 assessment.
12. How do you compare CIV with STIR/SHAKEN?
CIV and STIR/SHAKEN establish different things. CIV authenticates a caller ID by verifying the caller's possession of the displayed phone number. STIR/SHAKEN verifies a digital signature produced using a carrier's private signing key and therefore directly authenticates the signer. Any assurance about the caller ID contained in the signed PASSporT additionally depends on the carrier's attestation. The two approaches therefore address different authentication relationships.
13. You characterize STIR/SHAKEN as a technique that authenticates the carrier, not the caller ID, but in many STIR/SHAKEN documents, STIR/SHAKEN is presented as a solution to authenticate the caller ID. For example, on this FCC website, it says STIR/SHAKEN is "an industry-standard caller ID authentication technology".
In security, authentication is commonly based on one or more factors: 1) something you know (e.g., a password or secret key); 2) something you have (e.g., a token); or 3) something you are (e.g., biometrics). In STIR/SHAKEN, the receiver verifies a digital signature created with a private signing key held by the originating carrier or service provider. Cryptographically, successful signature verification establishes that the signed PASSporT was produced by the holder of the corresponding private key and has not been altered. It does not independently prove that the caller is entitled to use the calling number; that assurance comes from the attestation made by the signer.
14. The carrier includes an attestation label A, B and C with A indicating the highest assurance on the authenticity of the caller ID. If they lie, they will be punished. Isn't this sufficient to provide caller ID authentication?
Accountability and penalties can deter false attestations, but deterrence is not the same as verification of the caller's right to use a number. In STIR/SHAKEN, signature verification establishes who signed the PASSporT and that its contents have not been modified. Whether the caller was actually authorized to use the asserted calling number still depends on the correctness of the signer's attestation and the trustworthiness of the signer.
15. Does the distinction between carrier authentication and caller ID authentication really matter? As an end user, all I want is the guarantee that the caller ID displayed on my phone is genuine. As long as STIR/SHAKEN provides that guarantee, I'm all good.
STIR/SHAKEN does not provide an unconditional cryptographic guarantee that the asserted caller ID is genuine. According to data submitted by Transaction Network Services (TNS) to the FCC:
These figures illustrate an important distinction: a valid STIR/SHAKEN signature can coexist with an incorrect attestation about the calling number. This is why it is useful to distinguish cryptographic authentication of the signer from independent verification of the caller ID itself.
16. Is CIV an alternative to STIR/SHAKEN?
For the specific purpose of independently verifying that the displayed caller ID is genuine, CIV provides an alternative mechanism. However, it should not be viewed as a wholesale replacement for STIR/SHAKEN. CIV verifies possession of the caller ID, whereas STIR/SHAKEN provides signed carrier attestations. The two mechanisms can therefore serve complementary roles.
17. Since STIR/SHAKEN has already been deployed in the USA, is there still a role for CIV?
Yes. CIV can complement existing STIR/SHAKEN deployments in several scenarios:
Conversely, when the receiver obtains a validly signed call with A-level attestation and chooses to rely on the remote carrier's assertion, the receiver can accept the caller ID without invoking CIV, even if the caller indicates CIV support in the call header.
18. Does CIV require post-quantum migration?
No. CIV does not rely on digital signatures or public-key cryptography for caller ID verification and is therefore not vulnerable to the quantum attacks that threaten conventional public-key cryptosystems. Unlike STIR/SHAKEN, CIV avoids the costly transition to post-quantum public-key cryptography.
19. STIR/SHAKEN enables traceback to the originating carrier. Would CIV enable the same? That's s a requirement of the TRACED act.
Yes, CIV would enable traceback too. This is done via the range holder, who could also terminate the fraudulent phone services quickly. See Section 7.1 "CIV Impacts on tracing" in the IETF CIV draft for more details.
Feng Hao
Professor of Security Engineering
Department of Computer Science
University of Warwick
United Kingdom
Acknowledgement: the CIV project was funded by EPSRC. People who have contributed to this project include (in no particular order): Shen Wang, Basil Thomas, Mahshid Delavar, Muhammad Ajmal Azad, Steve Smith and Adrian Von Muhlenen.