IRS Identity Theft: Difference between revisions

From IDESG Wiki
Jump to navigation Jump to search
m (11 revisions imported: Initial Upload of old pages from IDESG Wiki)
(No difference)

Revision as of 04:00, 28 June 2018

Title:
IRS Identity Theft Use Case -- to prevent filing of fraudulent returns

Use Case Description:
This use case helps the IRS determine whether a taxpayer's Social Security Number is being used fraudulently in a tax return. It does this by checking the SSN against a list of verified SSNs, and authenticating the return using an NSTIC credential based on public key cryptography if the SSN used in the tax return is on the list of verified SSNs.

Use Case Category:
Authentication

Contributor:
Bob Pinheiro (nstic@bobpinheiro.com)

Use Case Details


Actors:
Internal Revenue Service, Social Security Administration, commercial tax preparation software vendors

Goals:
The IRS is experiencing many incidents of identity theft associated with stolen Social Security Numbers (SSNs). Fraudsters submit tax returns using someone else’s SSN for the purpose of obtaining a fraudulent tax refund. This use case helps the IRS determine whether a SSN is being used fraudulently. The goal is to authenticate an individual’s claim to a particular SSN when that SSN is used in a tax return. This use case could be modified to apply to a bank or other financial institution that needs to verify the SSN of someone enrolling in a new financial account.

Assumptions:
The Social Security Administration (SSA) currently offers a service that provides individuals with online access to their Social Security accounts and statements. As part of the enrollment process for this service, the SSA (in conjunction with Experian) verifies the identities of participants, which presumably includes verification of their claim to a particular SSN. Once enrolled, participants are currently given a user ID and password for online access to their accounts, with an option to receive a SMS text message on their mobile phone that contains a one-time code to be entered onto the SSA website for stronger authentication.

This use case assumes that the SSA will be able to provision, on a user’s computing device, a private cryptographic key (protected with a PIN or password), and a corresponding public crypto key maintained by the SSA. The purpose of this public/private key pair is to provide for strong authentication of returning users seeking to access their Social Security accounts or statements. An NSTIC-compliant identity ecosystem is presumed to incorporate functionality necessary to make public key cryptography usable and practical as a strong authentication method for consumer applications such as filing tax returns.

Once registered for the SSA service, this use case proposes that an individual will be able to voluntarily opt-in to an “ID Theft Protection” service that allows the IRS to determine whether someone using the individual’s SSN when filing a tax return, or for other tax-related correspondence, is authorized to do so. Opting in to this service puts the individual on a “list” that will be accessible to the IRS, and that contains the individual’s name and contact information, together with the individual’s verified SSN and the public cryptographic key associated with that SSN. The purpose of the list is to allow the IRS to authenticate tax returns that claim SSNs that are on the list; that is, SSNs whose ownership has been verified by the SSA, and whose owners have voluntarily opted into the ID Theft Protection service.

It is assumed that commercial tax preparation software will incorporate the ability of taxpayers to cryptographically sign their tax returns with SSA-provisioned private keys, and that client software on the user’s computing device(s) will exist to allow users to manage and use multiple private crypto keys to sign tax returns as well as for other authentication purposes, such as logging in to various websites that use public/private key cryptography for strong authentication.

For this use case to be truly effective in preventing large-scale identity theft and misuse of SSNs, the SSA needs to conduct a public outreach program to encourage large numbers of people to enroll for online access to their SSA accounts, and to opt-in to the ID Theft Protection service.

Although this use case focuses on authentication of SSNs for the purpose of filing tax returns with the IRS, other use cases could be defined that utilize the same functionality to protect against misuse of SSNs for other purposes. For example, another use case might protect against misuse of verified SSNs when opening new banking or credit accounts.

Requirements:

This use case assumes that the Social Security Administration, together with an outside organization (Experian), will verify the “ownership” of SSNs of people seeking to register for online access to their SSA accounts. It also assumes that the SSA will act to provision a public / private key pair on the person’s computing device. These assumptions were made because the SSA is the authoritative source of SSNs. Although some interaction between SSA and Experian may be necessary to verify ownership of a particular SSN, it’s possible that provisioning of a cryptographic key pair on the user’s computing device can be handled by a private sector identity provider instead of the SSA. This would perhaps better align the use case with the goals of NSTIC.

Process Flow:

1. Individual Taxpayer
A taxpayer who has previously registered for online access to his/her SSA account, and who opts in to the ID Theft Protection service, prepares a tax return using commercially available tax preparation software. The software allows the taxpayer to cryptographically sign the finalized tax return with a private crypto key (corresponding to the public key bound to the user’s SSA account). The taxpayer signs the return with the private key and submits the tax return electronically to the IRS in the usual manner.

A taxpayer who is a participant in the ID Theft Protection service may also submit a tax return on paper, or through other web-based portals.

If the taxpayer is a participant in the ID Theft Protection service and receives a notification from the IRS that a tax return using the taxpayer’s verified SSN has been received but that is cryptographically unsigned, or that is signed but was unable to be authenticated by the IRS against the appropriate public key from the SSA list, the taxpayer may login to the IRS website using the SSA private key as the authentication token, and notify the IRS that his/her SSN has been misused and that the tax return is fraudulent. The taxpayer can also resubmit a tax return signed with the legitimate private key. If the original tax return was unsigned with the SSA private key for any reason, and the return is legitimate, the taxpayer can login to the IRS website using the SSA private key, and notify the IRS that the original return is legitimate. If the taxpayer does nothing after receiving the IRS notice, the IRS will accept (reject?) the return after a specified amount of time.

2. IRS
When the IRS receives a tax return, the IRS compares the SSN used to file the return against the list of SSNs participating in the ID Theft Protection service. If the SSN is not on the list, the IRS processes the return in the usual manner.

If the SSN is on the list, and if the tax return is cryptographically signed by the taxpayer, the IRS attempts to authenticate the return against the SSA public key from the list that corresponds to the SSN from the tax return. If the tax return can be authenticated, the return is accepted. If the tax return cannot be authenticated, the IRS holds the return and notifies the owner of the SSN, using the contact information from the SSA list.

If the SSN is on the list of participants in the ID Theft Protection service, and if a tax return is not signed by the taxpayer with a private SSA key, such as would be the case for a paper return, the IRS notifies the owner of the SSN, using the contact information from the list.

In either of these two cases, when the IRS notifies a taxpayer who participates in the ID Theft Protection service that a tax return using their SSN cannot be authenticated against the appropriate SSA public key, the IRS then waits a specified time for either (a) receipt of a cryptographically signed tax return that can be authenticated using the public SSA key from the list, (b) an indication from the owner of the SSN that the tax return is either legitimate and should be accepted, or is fraudulent and should be rejected. If no communication is received back from the owner of the SSN within the specified time, the IRS accepts (rejects?) the return.

Success Scenario:
The SSA will undertake a public outreach program to get people to enroll for online access their SSA account and statement, and will also advertise the benefits of participation in the ID Theft Protection service. Large numbers of consumers / taxpayers will enroll for access to their SSA accounts, and will also opt-in to the ID Theft Protection service.

Taxpayer’s computing devices are outfitted with appropriate software applications to manage multiple private crypto keys. Such applications are provided to users as part of the online SSA service, or in other ways not specified here.

Vendors of tax preparation software will incorporate a capability to allow users to cryptographically sign a return using the SSA private key associated with the ID Theft Protection service.

The IRS and SSA collaborate to make the ID Theft Protection service usable and successful.

Error Conditions:
If the tax return is prepared by a tax preparer, instead of the taxpayer, there needs to be a way for the preparer to sign the return so that the IRS has high assurance that the SSN on the return is legitimate.

A rule must exist to handle joint tax returns. Does the ID Theft Protection service apply if only one party to the tax return is a participant, or must all parties by participants?

Relationships


References and Citations


Cryptographic Authentication for Access to Online Resources Use Case