WO1997024857A1

WO1997024857A1 - Security for calling card validation

Info

Publication number: WO1997024857A1
Application number: PCT/US1996/020282
Authority: WO
Inventors: Jingsha He
Original assignee: Mci Communications Corporation
Priority date: 1995-12-29
Filing date: 1996-12-30
Publication date: 1997-07-10
Also published as: AU1686197A

Abstract

A system and method for providing a secure validation procedure. The secure validation procedure reduces the flow of a PIN both at a card acceptor location and the communication link between the card acceptor location and the card issuer location. Additionally, the secure validation procedures minimizes the association between a PIN and an account number at the card acceptor location and during transmission for validation.

Description

Security for Calling Card Validation

Background ofthe Invention

Field of the Invention

The present invention relates generally to the field of card validation, and more specifically is directed toward a method of limiting the exposure of personal identification numbers associated with calling cards.

Related Art

To facilitate universal usage of calling cards, calling card issuers (e.g., MCI) typically enter into agreements with long distance compames in foreign countries (e.g., Japan). These agreements allow the customers of the card issuer to use card issuer calling cards to place telephone calls in those foreign countries. In this transaction, the foreign long distance company or the card acceptor must validate the card issuer calling card with the data records stored in a secure database within the card issuer.

In a conventional validation system, the foreign long distance company sends a message comprising the calling card number and the personal identification number (PIN) to the card issuer. After receiving this information, the card issuer attempts to match this information with the calling card information stored within a database. If a match occurs, the card issuer sends a message to the card acceptor authorizing the provision of service.

From a security standpoint, significant problems exist within this conventional validation system. For example, hackers may break into any part of the foreign system which receives a copy of the calling card information and harvest calling card/PIN data. Moreover, a hacker may intercept the calling card information as it is transmitted from the card acceptor to the card issuer for validation. In each of these cases, system integrity is severely compromised.

Summary ofthe Invention

The present invention satisfies the above mentioned needs by providing a validation system that minimizes the exposure of the PIN at both a card acceptor location and the communication link between the card acceptor and a card issuer location. In a preferred embodiment, a calling card holder sends the calling card number to a card acceptor location. Upon receipt, the card acceptor assigns a unique identifier to the validation task and sends the calling card number and the unique identifier to the card issuer location.

Upon receipt of this validation request, the card issuer location first deteπnines whether the calling card number is valid. If the calling card number is valid, the card issuer location retrieves the stored personal identification number (PIN) that is associated with the calling card number. Next, the card issuer location encrypts a validation message with an encryption key that is derived based on the stored PIN. The resulting encrypted validation message and the unique identifier received in the validation request are sent back to the card acceptor location.

After the validation response is received, the card acceptor location prompts the card holder for the PIN. The user-supplied PIN is stored in system memory according to the unique identifier assigned to the validation task. The system memory is thus accessible only by the validation task. To decrypt the encrypted validation message included in the validation response, the validation system obtains the PIN from system memory using the same unique identifier. This user-supplied PIN is used to generate a decryption key in an analogous manner as compared to the generation of the encryption key using the stored PIN. If the user-supplied PIN is equivalent to the stored

PIN at the card issuer location, the card acceptor will successfully decrypt the validation message. Recognition of the validation message is a precondition to the authorization of service.

In a preferred embodiment, the card acceptor location represents a first telephone company that provides the requested telephone service and the card issuer location represents a separate telephone company that issued the calling card. In other embodiments, the card acceptor location and the card issuer location represent parts of a distributed system that provide services through user contact at distributed points. Access to services at the distributed points is dependent upon the validation of a generic account number and/or user ID based on information stored in a centralized administrative system. The distributed system may be owned by a single company.

Brief Description ofthe Figures

The foregoing and other features and advantages of the invention will be apparent from the following, more particular description of a preferred embodiment of the invention, as illustrated in the accompanying drawings.

Figure 1 illustrates a high level description of the parties within the calling card validation environment; and

Figures 2A and 2B are flowcharts representing the processing sequence in the validation system. Detailed Description ofthe Preferred Embodiments

Figure 1 illustrates a high level description of the parties within calling card validation system 100. In calling card validation system 100, card holder 102 desires to use a calling card issued by card issuer 106 in the phone system of card acceptor 104. Card acceptor 104 permits phone service based on the calling card if the calling card is validated by card issuer 106. The validation procedure generally involves the comparison of the user-provided calling card number and associated personal identification number (PIN) with the corresponding numbers in a database (not shown) within card issuer 106.

In conventional methods, the card number and associated PIN are provided by a user to card acceptor 104. Card acceptor 104 forwards both pieces of information to card issuer 106 for validation. This conventional method is open to attack at a variety of levels. First, a hacker may extract the card number/PIN information from any system within card acceptor 104 that is forwarded a copy. To prevent this type of attack, the locations within card acceptor 104 that store the card number and PIN prior to the return of the validation message must be secure.

In addition, communication link 108 between card acceptor 104 and card issuer 106 is vulnerable to attack. If a hacker taps into communication link 108 that may include intermediate communication devices and subsystems, the pairs of card number/PIN information that are being passed for validation are accessible.

The present invention provides improved security in calling card validation system 100 by restricting the flow of the PIN in both card acceptor location 104 and communication link 108. The PIN alone is restricted since the

PIN represents the single piece of confidential information. The calling card number, on the other hand, is generally considered non-confidential. This follows since, in many instances, the calling card number represents the user's home phone number.

In addition to restricting the flow of the PIN, the present invention also minimizes the ties between the calling card number and its associated PIN within card acceptor location 104. In conventional systems, the calling card number and its associated PIN flow together within card acceptor 104 as it is passed to card issuer 106 for validation. Thus, any hacker that breaks into card acceptor location 104 or communication link 108 could retrieve both numbers at the same time.

The present invention recognizes that since the PIN on its own is useless, limited visibility of the PIN within card acceptor location 104 does not necessarily compromise system integrity. In other words, while the PIN embodies all of the confidential information, its capture as a single independent unit of information provides little value. Accordingly, in addition to restricting the free flow of the PIN within validation system 100, the present invention also seeks to reduce the PIN's association with its companion calling card number. These ideas are embodied in the validation process described by the flowcharts of Figures 2 A and 2B.

Before describing Figures 2 A and 2B in detail, it should be noted that the validation process is applicable to multiple environments. In a preferred embodiment, card acceptor 104 represents a first telephone company that provides the requested telephone service and card issuer 106 represents a separate telephone company that issued the calling card.

More generally, however, card acceptor 104 and card issuer 106 represent parts of a distributed system that provide services through user contact at distributed points. In this alternate environment, general subscription information is stored/protected in a centralized facility represented by card issuer 106. Access to services at the distributed points (or multiple card acceptor 104 locations) is dependent upon the validation of a generic account number and/or user ID. Validation requests are sent over a communication link

108 that connects the distributed facilities to the centralized administrative system.

As Figure 2 A illustrates, the validation process begins at step 202 and continues to step 204 where card holder 102 contacts card acceptor 104 initiating a validation task. Next, in step 206, card holder 102 provides card acceptor 104 with a calling card number. In step 208, card acceptor 104 determines whether the calling card number was issued by card acceptor 104. If so, card acceptor 104 follows its normal calling card processing procedures in step 210. As would be apparent to one of ordinary skill in the relevant art, steps 208 and 210 are unnecessary in systems where card acceptor 104 does not have independent validation procedures.

If validation is required by card issuer 106, card acceptor 104 assigns a unique identifier (or port number) to the current validation task in step 212. In this dynamic process, the port number is assigned based on the validation task not the identity of the caller. The association of the port number to the validation task may rely on underlying communications systems and protocols. This port number allows a subsequently received validation response to be associated with the ongoing validation task. As will be described in greater detail below, this unique identifier minimizes the ties between the received calling card number and a later user-supplied PIN. Next, In step 214, card acceptor 104 sends a validation request to card issuer 106 via communication link 108. The validation request comprises the calling card number and the unique identifier assigned to the validation task.

In step 216, after the validation request is received by card issuer 106, card issuer 106 determines whether the calling card number is a valid number.

If the calling card number is not valid, card issuer 106 prepares a card number invalid message in step 218.

If the calling card number is a valid number, step 220 is invoked. In step 220, card issuer 106 uses the calling card number to identify the corresponding PIN number. Typically, the PINs are stored in a secure database

(not shown) at card issuer location 106.

In step 222, after the corresponding PIN is identified, card issuer 106, encrypts a validation message with an encryption key that is based on the retrieved PIN. In one embodiment, the validation message is simply a word or phrase indicating approval. In other embodiments, the validation message comprises a verification number to be used for administrative purposes. Concerning the encryption key, in one embodiment, the key may simply be the PIN itself. In other embodiments, the key is generated from a procedure using the PIN as a seed. As would be apparent to one of ordinary skill in the relevant art, any key generation method may be used.

In step 224, card issuer 106 sends a validation response to card acceptor

104. The validation response comprises either the invalidation message produced in step 218 or the encrypted validation message produced in step 222.

Additionally, the validation response further comprises the unique identifier included in the validation request. In step 226, after the validation response is received, card acceptor 104 extracts the unique identifier (or port number) included in the validation response to identify the specific validation task that originated the validation request. Significantly, it is the unique identifier and not the calling card number that provides the connection between a validation response and a particular validation task.

Next, in step 228, card acceptor 104 determines whether an invalidation message was received in the validation response. If so, card acceptor 104 may prompt the user to reenter the account number. Generally, the number of retries should be limited to avoid the possibility of fraud. If, however, the number of retries allowed has not been exhausted, steps 208 to 226 are repeated.

If an encrypted validation message was received, card acceptor 104 processes the encrypted validation message. This process begins in step 230 where card acceptor 104 prompts card holder 102 for the PIN. It should be noted that up until this point in time, the calling card number has flowed through the network without its corresponding PIN. Since the calling card number is presumptively non-confidential, risks to system integrity have been minimized. The only aspect of the processing involving the PIN has occurred at card issuer location 106. This centralized facility is assumed to be highly secure.

In step 232, card acceptor 104 utilizes the user-supplied PIN to generate a decryption key in an analogous manner to the generation of the encryption key in step 222. Using the decryption key based on the user-supplied PIN, the encrypted validation message is decrypted. Specifically, after the PIN is received from card holder 102 it is assigned to the validation task. Next, the validation system within card acceptor 104 retrieves the PIN stored in system memory based on the unique identifier contained in the received validation response. The retrieved PIN is used to decrypt the message or produce a decryption key to decrypt the message. Thereafter, the PIN is immediately deleted from the system memory of card acceptor 104. In this process, the PIN is never saved on a disk storage device. Accordingly, any hackers that break into card acceptor 104 cannot gain access to the PIN that is temporarily stored in the system memory.

In step 234, after the PIN decrypts the encrypted validation message, card acceptor 104 determines whether the result of the decryption process yields a recognizable result. If no recognizable result is produced, the user- supplied PIN is assumed to be incorrect and the service request is denied in step 236. On the other hand, if step 230 yields the validation message sent by card issuer 106, then the PIN is assumed to be correct and the service request is granted in step 234.

As noted above, the user-supplied PIN is restricted to a one-time generation of a decryption key. Additionally, the user-supplied PIN in card acceptor location 104 is restricted to temporary storage in system memory. This memory restriction protects the user-supplied PIN from hackers that infiltrate acceptor location 104.

Moreover, even if a user-supplied PIN is captured, its value is limited without the corresponding calling card number. In the present invention, the security of the validation system is further enhanced by restricting the association of PINs with calling card numbers. As described above, a unique identifier correlates validation responses to one of a plurality of concurrent validation tasks. In this manner, the validation system does not require the presence of a calling card number when card holder 102 provides the PIN.

While the invention has been particularly shown and described with reference to preferred embodiments thereof, it will be understood by those skilled in the relevant art that various changes in form and details may be made therein without departing from the spirit and scope of the invention.

Claims

What Is Claimed Is:

1. A method for secure calling card validation, comprising the steps of: (a) assigning a unique identifier to a validation task; (b) receiving a calling card number from a user at a card acceptor location; (c) sending a validation request comprising said calling card number and said unique identifier to a card issuer location; (d) identifying, at said card issuer location, whether said calling card number is valid; (e) retrieving, at said card validation location, a stored personal identification number (PIN) associated with said calling card number; (f) encrypting a validation message with an encryption key that is based on said stored PIN associated with said calling card; (g) sending a validation response comprising said encrypted validation message and said unique identifier to said card acceptor location; (h) after said validation response is received by said card acceptor location, said user supplying a PIN to said card acceptor location; (i) storing said user supplied PIN in system memory according to said unique identifier; (i) generating a decryption key based on said user-supplied PIN retrieved from said system memory; (j) after said step of generating is complete, deleting said user- supplied PIN from said system memory; (k) decrypting said encrypted validation message using said decryption key to produce a decrypted message; and (1) validating said user if said decrypted message yields a recognizable output.

2. A method for secure calling card validation, comprising the steps of: (a) receiving a calling card number from a user at a card acceptor location; (b) sending said calling card number to a card issuer location; (c) retrieving, at said card issuer location, a stored personal identification number (PIN) associated with said calling card number; (d) encrypting a validation message with an encryption key that is based on said stored PIN; (e) sending said encrypted validation message to said card acceptor location; (f) after said validation response is received by said card acceptor location, said user supplying a PIN to said card acceptor location; (g) generating a decryption key based on said user-supplied PIN ; (h) decrypting said encrypted validation message using said decryption key to produce a decrypted message; and (i) validating said user if said decrypted message yields a recognizable output.

3. A method for secure calling card validation, comprising the steps of: (a) sending a calling card number to a card issuer location; (b) retrieving, at said card issuer location, a stored personal identification number (PIN) associated with said calling card number; (c) encrypting a validation message with an encryption key that is based on said stored PIN; (d) sending said encrypted validation message to said card acceptor location; (e) generating a decryption key at said card acceptor location based on a user-supplied PIN; (f) decrypting said encrypted validation message using said decryption key to produce a decrypted message; and (g) validating said user based on said decrypted message.

4. The method of claim 3, wherein said step (e) further comprises the step of generating a decryption key based on a user-supplied PIN obtained after said encrypted validation message is received.

5. A system for secure calling card validation, comprising the steps of: means for assigning a unique identifier to a validation task; means for sending a validation request comprising a calling card number and said unique identifier to a card issuer location; means for receiving a validation response comprising an encrypted validation message and said unique identifier to said card acceptor location, wherein said encrypted validation message is encrypted using an encryption key that is based on a personal identification number (PIN) at said card issuer location; means for storing a user-supplied PIN, obtained after said encrypted validation message is received from said card issuer location, in system memory according to said unique identifier; means for generating a decryption key based on said user-supplied PIN retrieved from said system memory; and means for decrypting said encrypted validation message using said decryption key to produce a validation message that validates said user.

6. The system of claim 5, further comprising: means for retrieving, at said card validation location, a stored PIN associated with said calling card number included in said validation request; means for encrypting said validation message with an encryption key that is based on said stored PIN; and means for sending said validation response comprising said encrypted validation message and said unique identifier to said card acceptor location.

7. The system of claim 5, further comprising means for deleting said unique identifier from said system memory after said decryption key is generated.