Note: Descriptions are shown in the official language in which they were submitted.
1 1 65445
1 METHOD FOR OPERATING A TRANSACTION EXECUTION
SYSTEM HAVING IMPROVED VERIFICATION
OF PERSONAL IDENTIFICATION
Description
Cross-Reference To Related Patents
This application is an improvement of the following
U.S. Patents:
1. U.S. Patent 3,956,615 for Transaction Execution
System With Secure Data Storage And
Communications, by Thomas G. Anderson, William
Boothroyd and Richard C. Frey;
2. U.S. Patent 4,186,871, for Transaction Execution
System With Secure Encryption Key Storage, and
Communications, by Robert W. Anderson, Steven F.
Brock, and May L. Gee; and
3. U.S. Patent 4,319,336, issued March 9, 1982, for
Transaction Execution System Having Keyboard and
Message Customization, Improved Key Function
Versatility and Message Segmentation, by Robert W.
Anderson, May L. Gee, and Alice K. McMullen.
Technical Field
This invention relates to transaction execution
systems, and more particularly to a method for operating
such systems having a central data base at a host data
processing system in communication with remote
SA9-79-037
~`
B
~ `i1654~5
terminals to permit the e~YeCUtiOn of transactions,
such as the issuance of cash or the interaccount
transfer of funds in response to entry of a personal
identification number, together ~ith a machine-
readable ide~tification card issued by any of one ora plurality of cooperating institutions, and where
the personal identification number may or may not be
derived from data on the identification card.
Bac~q~ound Art
Transaction execution systems which enable the
performance of transactions, such as cash issuance at
terminals remote from and in communication with a
host data processing system having a central data
base in which account and other information is stored,
are well known. Examples of such systems are provided
i by or referred to in U.S. Patent 3j956,615 of Anderson,
et al, U.S. Patent 3,970,992 of Boothroyd, et al,
U.S. Patent 3,937,925 of Boothroyd, U.S. Patent
4,186,871, of Anderson et al and U.S. Patent 4,319,336,
entitled Transaction Execution System Having Xeyboard
and Message Customization, Improved Key Function Versa-
tility and Message Segmentation.
Such systems, which are frequently used by banks
to extend their services during times of heavy business
or business closure, permit the issuance of cash or~
the receipt of deposit~ through a terminal. Such a
terminal typically includes a mechanism for receiving
and reading information from a credit card, a keyboard,
SA9-79-037
~g:~
I 1 65~1~5
a displa~ and document entry and ~xit apertures. The
terminal may operate in conjunction with a data base
or as a ~tand-alone unit. Increased security for the
issuance of cash or the performance of other banking
transactions without intervention of a bank employee
is attained by issuing a personal ID nl~mher with each
credit card. A credit card transaction is then
enabled only when an ID number corresponding to the
account number read from the credit card is entered
through the keyboard. This required correspondence
prevents a thief or mere finder of a credit card from
receiving cash, for example, from a terminal. If a
terminal operates in conjunction ~ith a data base,
the correspondence between account n~lmhers and ID
numbers can be chosen at random, but frequently the
ID number is derivable from the account number in
accordance with a predetermined code. The former
situation will be discussed hereafter. In the latter
situation, in order for the ID number to be chosen at
random, such as by selection by the customer, an
offset value is recorded on the card along with the
account number, which offset value is selected such
that when added or otherwise combined with the ID
number derived from the account number in accordance
with the predetermined code, the result is the ID
number chosen at random. These predetermined relation-
ships ~et~een ID number and account (and offset) data
from the card permit a stand-alone terminal to check
the ID number by algorithmically relating the ID
number to the account number. If credit cards issued
by a plurality of cooperating banks are to be usable
in a given terminal, all such banks must use the same
code or algorithm, or otherwise pro~ide for distinguish-
ing the algorithmic relationship used in issuing ID
SA9-79-037
I~6S~5
numbers from account data. In one ~uch system, a
key-driven algorithm is pro~ided for determining the
relationship between ID numbers and account numbers.
In such a system, the account number and key n~mber
are combined using linear and nonlinear operations to
generate a check number for comparison with the ID
num~er. The Anderson patent 3,956,615 is such a
system. For cards issued by different banks to be
used in the same terminals, however, all banXs must
use the same key number, and the account number must
be located in the same field on all cards. In one
improvement on the Anderson system, a table of
encrypted keys is maintained in each terminal, con-
taining the keys required for use in the key-driven 15 algorithm for a plurality of cooperating banks,
together with data specifying the location on the
card data track of account, offset, and other data to
be used in generating the check number for comparison
with the ID code entered at the keyboard. In an
improvement on that system, which is described in the -
previously referred to U.S. Patent 4,186,871 of
Anderson, et al, the host data processing system
includes a virtual financial institution table (VFIT).
Upon entry by a consumer of a credit card and personal
identification number, the financial institution
table (FIT) within the terminal is searched in an
attempt to locate an entry corresponding to the
institution identified by the credit card. If a
corresponding entry is located, data from the fields
for that entry is used to encrypt the personal data
from the credit card for purposes of verification of
the personal identification number entered by the
consumer. If a corresponding entry is not located in
the financial institution table at the terminal, a
SA9-79-037
~ 1 ~5~5
search of the virtual inancial institution table at
the host is made. If a corresponding entry is located
in the host financial institution table, the included
data is communicated back to the terminal where it is
used in the verification of the personal identifica-
tion number.
Alternatively, the FIT entry at the terminal can
include a control bit instructing the terminal to
communicate the credit card data and the personal
identification number to the host for authorization
of the transaction, including ehe check of correspon-
dence between the account numbers and ID numbers
(which is sometimes referred to as a PIN check.)
A PIN check to be performed at the host, in
addition to a terminal PIN check, is described in the
Anderson patent 3,956,615. In such a host PIN check,
the personal identification number entered at the
terminal is double encrypted and sent to the host,
along with card data. At the host, the double
encrypted identification number is singly decrypted,
and a data base of encrypted identification numbers
is accessed by the card data. The encrypted identi-
fication number obtained from the data base is compared
with the singly decrypted/double encrypted personal
identification number received from the terminal to
thus perform the host PIN check. However, in this
system, it is expected that if the host PIN chec~
fails, the transaction will not be approved--the PIN
must be entered correctly on the first attempt.
SA9-79-037
~ ~ 6~ 5
When the PIN check is performed at the terminal,
based upon verification o~ an algorithmic relationship
between card data and the ID number entered at the
keyboard, failure of correspondence may result in a
S request to the individual to try again to enter the
correct ID number, and a plurality of failures of
correspondence permitted before rejecting the transaction.
While the previously mentioned table derived
key-driven credit card and ID number identificaticn
technique improves the security of cash issue terminals
and permits a plurality of banks to cooperate in
honoring cards issued by the others, there are still
~eaknesses that may be exploited to gain access to
the large amounts of cash that are stored in the
terminal or available in the accounts of cooperating
banks for interfund transfer by operation of the
terminal. One serious problem relates to the security
of the encryption algorithm for terminals which are
capable of stand-alone operation, or even on-line
operation. A large number of operators or maintenance
personnel are required for lhe day-to-day support of
cash issue terminals. For example, one or two people
at each branch bank location may have internal access
to the cash issue terminals. OftentLmes these people
may have access to the encryption key for normal
maintenance. Alternatively, with only a little
training, these people could learn to acquire the key
by fraudulently tapping the communication line or by
measuring electrical signals on the internal circuitry.
Once an encryption key is acquired, and if the algorithm
is known, a correspondence between a large number of
SA9-79-037
~ J ~5 ~45
account numbers and ID numbers could be generated.
Then, with the ~nowledge of the card format and
location of verification and offset data on the card,
correspondence between card data and random chosen ID
numbers can be ascertained.
Because of this, some institutions in an interchange
environment require that the PIN check be done at
their own host so that cooperating banks would never
have access to the encryption keys relating the card
data to the personal identification numbers. As
previously noted, however, this generally requires
rejection of a transaction when the host PIN check
fails. The customer could immediately try to initiate
- a second transaction, particularly if told that a PI~
check failure caused rejection of the first transaction.
~owever,~ this is time consuming to the customer and
the system, resulting in additional terminal/host
communications with resulting expense and degradation
of total system availability.
SummarY of the Invention
A transaction execution system, in accordance
with the invention, includes a host data processins
system having a data base of stored information,
including validation numbers, which validation numbers
may or may not be derived by encryption of account
identification or related data. Connected to the host
data processing sy~tem are one or more terminals,
each terminal including means for entering account
identification data and personal identification data.
S~9-79-037
~ ~fi5~5
- 8
In accordance with the invention, the personal
identification data entered at the terminal is
encrypted, using a first encryption key, to give a
first resultant. The first resultant is concatenated
with a terminàl-generated variable number, and then
the concatenated number encrypted, using a second
encryption key to generate a double encrypted personal
identification number. The double encrypted personal
identification number is then communicated to the
host, along with account identification data, where
the double encrypted number is decrypted using the
second encryption key to yield the first resultant,
and the first resultant compared with the validation
number associated in the host data base with the
account identification data.
If, at the host, the validation data and first
resultant do not compare, but the transaction is
otherwise approved, the host concatenates the variable
number and the validation data, encrypts the con-
catenated number with the second encryption key togenerate encrypted validation data, and communicates
the encrypted validation data to the terminal in a
conditional transaction approval message.
The terminal decrypts, using the second key,
the encrypted validation data from the conditional
transaction approval message to generate validation
data for comparison with a newly entered personal
identification data which has been encrypted with
the first key. Alternatively, the generated valida-
tion data is decrypted, using the first key, for
s~9-79-a37
~i 1 6S~d5
comparison ~ith the newly entered pQrsonal identi-
fication number ~which has not been encryptedl.
Based upon the comparison of the newly entered PIN
and the data from the conditional transaction approval
message, the transaction may be approved by the
terminal.
Brief Description of the Drawinqs
In the accompanying drawings forming a material
part of this disclosure:
Figure 1 is a functional block diagram representa-
tion of a typical transaction execution system having
~ interchange capability.
Figure 2 is a functional block diagram representa-
tion of the basic communication messages within a
second typical transaction execution system.
Figure 3 is a functional block diagram representa-
tion of the basic communication messages within the
transaction execution system of Figure 1.
Figure 4 is an operational block diagram representa-
tion of the generation in a terminal of a transactionrequest message.
Figure 5 is an operational flow diagram representa-
tion of the generation in a host of a conditional
transaction authorization message.
S~9-79-~37
~ 1 65~-~4 5
Figure 6 is an operational block diagram representa-
tion of the generation in a host of enciphered PIN
and P~D data from a transaction request message.
Figure 7 is an operational diagram representation
of the generation in a host of enciphered identification
data from the host data base for a conditional trans-
action authorization message.
Figures 8 and 11 are format diagram illustrations
of transaction reply messages, including a transaction
authorization message and a conditional transaction
authorization message.
~ Figure 9 is an operational flow diagram representa-
tion of generation in a terminal of a status message
to the host in response to a transaction reply message.
Figure 10 is an operational bloc~ diagram representa-
tion of generation in a terminal of validation data
from enciphered data received in a transaction reply
message.
Disclosure of Invention
For further comprehension of the invention, and
of the objects and advantages thereof, reference will
be had to the following description, accompanying
drawings, related applications, and to the appended
claims in ~hich the Yarious novel features of the
invention are more particularly set forth.
SA9-79-037
~ 1 fi5 ~'1rj
11
Reerring to Figure 1, the invention provides an
improved transaction authorization ~ystem comprisin~
a host bank CPU 10 having a data base 12. CPU 10 may
be, for example, an IBM System 370 having a VT~
application program, which is executed in the System
370 processor under control of DOS/VS, OS/VS1 or
OSfVS2, with access to data base 12 through VSAM,
ISAM, and/or SAM, as will be apparent to those
sk.illed in the art. The data base 12 includes the
application library and customer account files--the
latter including such account status information as
account balances and activity, and also validation
data, to be discussed more fully hereafter.
In an interchange environment, two or more
cooperating financial institutions provide inter-
connection between their respective data processing
systems, and such is illustrated by line 14 inter-
connecting CPU's 10 and 16. CPU 16 is attached to
data base 18, which would contain the account data
files for its customers.
Bank B CPU 10 is attached to a plurality of
banking terminals 20, 22, on communication loop 36.
Such attachment may be directly (such as by an SDLC
network, not shown) or through controller 24, which
may be an IBM 3601 Finance Communication Controller.
Line 26 represents a communication link which may be
controlled by ~TAM in CPU 10, and include an IBM
3704/3705 telecommunication link controller under
control of an NCP/3 CNetwork Control Program, Version
3).
SA9-79-037
1 ~ fiS~4 ~
12
Controller 24 may include a di~kette for storage
of account data, representing some subset of the data
stored in data base 12.
While bank B C~U 10 is shown in communication
with tenminals 20, 22, bank A CPU 16 may be similarly
attached to its own population of banking terminals.
In an interchange environment, cooperating banks
agree to perform at their respective terminals,
banking transactions for individuals identified as
customers of other cooperating banks.
In such an interchange environment, an individual
possessing a machine-readable identification card
~ issued by bank A may wish to withdraw cash from his
account at bank A through cash dispenser 28 at
terminal 20, or perform any other financial function,
such as deposit, transfer, account inquiry, or bill
payment (by deposit or by withdrawal from a specified
account).
In order to assure that the individual attempting
to operate terminal 20 is entitled to perform a
transaction, it is normally required that he insert
his machine-readable account card (ID card or credit
card) into card reader 30, and enter in at keyboard
32 his personal identification number (PIN). Data
read from the account card includes data, which may
be all or a portion of an account number on the card,
which is used to check the validity of the PIN. This
validity check, or PIN check, may be conducted by
encrypting either the card data or the PIN, and com-
paring the result with the other--encrypted card data
SA9-79-037
~ i 1 ~5'145
.
~ompared wit~ PIN, or encrypted PIN with c~-d data--
with the encryption being performed under control of
a key, as is more fully descri~ed in Anderson patent
.3,956,615 and in ~nderson patent 4,186,871. In '.~e
:latter, Anderson '871, the provision of a Financial
~nstitution Table (FIT) is explained, which would
permit the storage in terminal 20 of the bank A
encryption key required for the PrN check to be
performed in terminal 20 fo~ cards issued by bank A.
~owever, bank A, even though willing to enter into an
interchange agreement with bank ~, may choose not to
store its encryption keys in the bank A FIT tables
twhich may reside at CPU 10, controller 24, and/or
i terminals 20,22~. Further, bank A may choose to
issue PIN's to its customers which are not deri~ed
: from data encoded on their account cards. In either
event, terminaI 20 is unable to check for corres-
pondence between the data read by reader 30 from the
account card and the personal identification number
(PIN) entered at keyboard 32. In that situation, the
customer is instructed, such as via display 34, to
enter the information required to perform the trans-
action, as is more fully descri~ed in the Anderson
patents 3,956,615 and 4,186,8~1, and U.S. Patent
4,319,336. That informa'ion required
to perform the PIN check at the host, including
account identification information (which may be read
from the card by reader 30 and/or entered at key~oard
32 by the customer~, is sent to the host, herein
CPU 16, for a host PIN check, as will be more ~ully
described hereinafter. Also, bank B may require that
its terminals 20,22 communicate the data received
SA9-79-037
... .. . . .
~ llfi 5 ~ ~ 5
from bank B customers to controller 24 or CPU 10 for
a host PIN check, such as when bank B issues PIN's to
its customers which are not derived from data which
is recorded on their account cards.
Referring to Figure 2, by way of example, communica-
tion between terminal 20 and the host (controller 24
or CPU 10~ for a typical transaction, is performed in
accordance with a three-message protocol, including a
transaction request message 40, transaction reply
message 42, and status message 44 (as more fully
described in Anderson patent 4,186,871 in connection
with Figure 5, and U.S. Pate~t ~ lg,3~6
in connection with Figure 12, which also describe the
VFIT and interactive related messages which may be
used in processing a transaction~.
Referring to Figure 3, further by way of example,
communication from terminal 20 of ban~ B is shown
forwarded by bank 3 to host 16 of bank A through the
same message protocol, which may also include the
above-mentioned VFIT and interactive messages.
Transaction processing may ~e distributed by the
application programs between host elements ~4, 10 and
16 in order to optimize communication time, storage
costs, security requirements, and terminal usage.
Referring now to Figure 4, an explanation will
be given of the operation of terminal 20 to generate
transaction request message 40, for`secure and optimal
performance of an initial PI~ check at the host, such
as may be required when the PIN is not derived from
S~9-79-~37
~1t5~115
da~a recorded on the ID card, or when the encryption
key required to check correspondence between the PIN
and c~rd data is not available at the terminal, or
even when the PIN check is performed, but fails at
the terminal, and a further PIN check at the host is
desired. As will become apparent hereinafter, an
initial PIN check at the host under any of the above
circumstances, which fails, may be followed by a
subsequent PIN check at the terminal, based on newly
entered PIN data, without the necessity to re-establish
communication with the host for the purpose of the
PIN check, and with the communications secure against
fraudulent tapping to determine the correct PI~
associated ~ith the account card.
Terminal 20 includes a programmable microprocessor
which operatec under the control of a microprogram,
as is more fully described in the Anderson patents
3,956,615 and 4,186,871.
ID Card 38 is read by card reader 30, and iss~ing
institution identification data therefrom used to
access Financial Institution Table (FIT) 46. Data in
FIT 46 is deciphered under control of Key A to generate
PIN gEY 50, which may be institution unique. The
decipher step 48 and all other encryption and decryption
processes referred to herein may be performed in
accordance with the National Bureau of Standards
"Encryption Algorithm for Computer Data Protection",
Federal ~egister, Vol. 40, No. 52, Monday, March 17,
1975, pages 12134-12138 ~hereinafter referred to as
DES--meaning "data encryption standard~l. DES may be
SA9-79-037
1 ~ fi5~ 11 5
16
.umplemented either as a hardware module or as a
microcode rout~ne, as ~ill be apparent to those
~;killed in the art.
Also obtained from FIT 46 is PAD digit 52 ror
the institution, which is concaten~ted with PIN 54
digits entered by the customer at keyboard 32 to
generate a 64-bit number for encryption by DES at
step 56 under control of PIN KEY 50. Enciphered PIN
and PAD 58 is 64 bits, 56 bits of which are concatenated
~ith 8 bits from variable number generated 60, and
the thus concatenated numbar 62 is enciphered ~t step
64 using DES and under control of communication key,
Key C.
Variable number generator 60 may, by way of
example, generate a number algorithmically related to
some transaction or terminal state, such as trans-
action sequence number or rollover bill counter. Key
C is the communication key and is used to provide
security over the communication linX between the
2~ terminal and host systems.
The output of encipher step 64 is a 64-bit,
double encrypted number which is concatenated with
the remaining 8 bits of encyphered PIN and PAD 58 to
form a 72-bit enciphered identification number 66 for
the enciphered field 68 of transaction request
message 40. Nonenciphered information 70 includes,
for example, the necessary data for host processing
of the transaction request, such as data read from
SA9-79 037
1 1 6S~45
17
card 38 and transaction type, amount, and so forth,
entered at keyboard 32 (but not including the PIN).
Header 72 identifies the message type and the terminal
address.
Referring now to Figure 5, the process to be
performed at host bank A or B to check the PIN and
gene~ate a transaction reply message 42 is set forth.
Referring, by way of example, to bank B, transaction
reply message 40 includes in nonenciphered information
70 a data base access number, which may be related to
the customer account number read from ID card 38. In
step 74, the data base access number is extracted
from request message 40, and used to retrieve (as an
address or search argument~ validation data, which is
the customer PIN, concatenated with the PAD, enciphered
-and stored in data-base 12--the enciphered PIN + PAD.
- In this way, the customer PIN is not stored in the
host data base in clear text, where it could be read
in the clear by unauthorized individuals.
In step 76, which will be more fully described
in connection with Figure 6, enciphered data 68 from
the transaction request me~sage is deciphered. In
step 78, the transaction authorization processing
occurs, including such checks a~ account balance,
account activity, stolen or lost ID card checks, as
determined by the host bank application program. If
the transaction is not authorized, based upon the
aboYe checks, host 10 prepares in step 80 a trans-
action reply meQsage 42, rejecting the transaction
for communication in ~tep 82, to terminal 20. In the
event that the transaction is authorized, at leas`t on
SA9-79-037
~ 1 6SQ ~ S
13
the basis of the account chec~s of ~tep 78, in step
~4 the base part of transaction reply message 42 is
E~repared, as is more fully described in the previously
noted Anderson patents and application.
In step 86, the host PIN chec~ is performed,
comprising a comparison of the enciphered PI~ + P.~D
field obtained from data base 12 in step 74 with the
enciphered PIN + PAD field prepared in step 58 of
Figure 4 and derived from the transaction request
message in step 76 of Figure 5. If the host PIN
chec~ is successful, transaction reply message 42 is
generated in step 84 and transaction approval is sent
to terminal 20 in step 82. If the host PIN check is
not successful, a transaction reply message indicating
conditional authorization is generated in step 88 for
communication to terminal 20 in step 82. The format
of a transaction reply message generated in steps 80
or 84 indicating approval or rejection is shown in
Figure 8. A transaction reply message generated in
steps 84 and 88 indicating conditional authorization
and establishing in the terminal a conditional trans-
action approval state is shown in Figure 11.
In step 88, a PIN chec~ required bit. in reply
message 42 is activated, and the enciphered identi-
fication data field 90 generated, as will be described
in connection with Figure 7. A conditional authorization
reply message provides the terminal with the data
necessary to permit the customer to retry to enter
the correct PIN without the necessity to re-establis~
communication with the host.
SA9-79-037
65~5
19
Referring to Figure 6, the process to be per-
formed in the host ~o generate the enciphered PIN ~ PAD
~rom enciphered field 68 of transaction request
message 40 is set forth. In step 92, 64 bits of
enciphered field 68 are decrypted, using communication
key KEY C. The resulting 64 bits include an 8-bit
portion representing the data from variable number
generator 60 (Figure 4), and 56 bits which are concatenated
with the remaining 8 bits of field 68 to give enciphered
PIN + PAD number 94, which will be equal to data 58
of Figure 4 and used in host PIN check step 86
(Figure 51.
Referring to Figure 7, the process to be performed
by host CPU 10 in step 88 (Figure 5I to generate the
enciphered data base identification data 90 for a
transaction reply message 42, indicating conditional
approval, is set forth. By this approach, the PIN
validation data element ~which is, in this example,
the enciphered PIN + PAD stored in data base 12) does
not appear on communication lines 26, 36, where it
could be tapped and later used to control operation
of a terminal 20 to fraudulently issue cash.
Variable number generator 96 may provide one of
- the following. First, it may merely provide that
number generated by variable number generator 60, and
which is available as the 8-bit fieid at the output
of decipher step 92 (Figure 62. Second, it may
generate a random number. Third, it may generate a
number algorithmically related to some quantity in
the transaction request message (such as the trans-
action sequence number2.
SA9-79-037
) 1 65~5
The 8-bit output of variable number generator 96
is concatenated with 56 of the 64 bits of the en-
ciphered PIN + PAD obtained from data base 12 and
enciphered by DES in step 96, using communication key
KEY C. The resulting 64 bits are concatenated with
the rP~aining 8 bits of the enciphered PIN + PAD from
data base 12 to give the 72-bit double-enciphered
field 90 for the transaction reply message.
~eferring now to Figure 9, the process to be
performed at terminal 20 in response to receipt of
transaction reply message 42 will be described. In
step 100, basic validity tests are perIormed on data
in selected fields of the base part of the reply
message. If, as a result of these tests, it is
determined that the transaction is not authori~ed,
the transaction is terminated in step 102 and the
transaction status message communicated to host 10 in
step 104; If the transaction is unconditionally
authorized, terminal 20 completes the transaction in
step 106, before sending the status message.
If the transaction is conditionally authorized,
the customer will be permitted to enter a new PIN
(one or more times~, which will be checked at
terminal 20 for correspondence with the enciphered
PIN + REY stored in data base 12. Optionally, a
variable number test may be conducted as an added
precaution. In step 108, enciphered identiication
da~a 90 is deciphered, following the procedure of
Figure 10, described below. In step 110, the vari~ble
S~9-79-037
1 .1 6 ~ 5
21
number field, generated at the host by variable
n~nber generator 96, is checked for comparison with
that previously (or again~ generated by variable
nl~nber generator 60 in terminal 20. This check is
not performed if variable number generator 96 generates
a random number. If the optional variable number
test is failed, the transaction i5 terminated.
In step 112, the customer is instructed to enter
his PIN number at ~eyboard 32. This newly entered
PIN would be expected to differ from that originally
entered (to enter PIN 54 in Figure 4), such as would
occur when the customer had forgotten his PIN and is
being given an opportunity to try again. In step
114, the newly entered PIN is compared with the PIN
from host data base 12, and if equal, a transaction
approval state is generated, enabling the transaction
to be performed in step 106. If not equal, after
C~me predetermined number of permitted trys to enter
the correct PIN, the transaction is terminated. In
preparation for the comparing step 114, enciphered
identification data 90 is twice deciphered, using the
procedure of Figure 10. Alternatively, the newly
entered PIN could be enciphered, using the procedure
of Figure 4, step 56, and the identification data 90,
once deciphered, using the procedure of step 116,
Figure 10.
Referring now to Figure 10, the process to be
performed in terminal 20, to twice decrypt enciphered
identification field 90 in preparation for the test
of step 114 (Figure 9~ comparing the newly entered
sAs-7s-037
~ 1 fi5 ~ 5
22
~IN ~ith that PI~ which was ancrypted to be stored in
data base 12, will be described. In step 116, 64
bits of the 72-bit field 90 are deciphered by DES,
using communication key REY C. 56 of the resulting
64 bits are concatenated with the remaining 8 bits of
field 90 to give the single deciphered (or enciphered)
PIN + PAD 118. The remaining 8 bits of the 64-bit
result of decipher step 116 is the variable number
generated at host 10 by variable number generator 96,
and is used in the check of step 110, Figure 9.
Single encrypted PIN ~ PAD 118 is the same number
that is stored in host data base 12. In step 120, it
is again deciphered by DES, this time with PIN REY ;0,
to yield in clear text the PI~ number to be compared
- 15 with the newly entered PIN.
Best ~ode for CarrYinq Out the Invention
Referring to Figure 1 in connection with Figure
2, the operation of the transaction execution system
of the invention in accordance with the best mode
will be explained.
In terminal 20, transaction request message 40
is generated, including a personal identification
number entered at keyboard 32 and encrypted twice,
using two keys, together with data base access data
input through card reader 30. The request message 40
is transmitted to host C~U 10.
In host CPU 10, the data base access number is
extracted from the request message 40, and used to
SA9-79-037
i 365~r~
23
retrieve frQm data base 12 a validation number associated
t~herewith tand representing a singly encrypted PI~.
The twice encryptad personal identification number
from the request message 40 is deciphered using the
S communication key and compared with the singly encrypted
PIN retrieved from data base 12. If they are not
equal, the singly encrypted PIN from data base 12 is
further encrypted in the communication key, and the
resulting double encrypted PIN transmitted to ter~inal
20 in a transaction reply message 42, indicating
conditional approval of the transaction.
In terminal 20, the customer is instructed to
enter a new PIN at keyboard 32. The double encry?ted
PIN from transaction reply message 42 is twice decrypted
and checked against the newly entered PIN for correspondence.
If the PIN's correspond, the transaction is completed.
Industrial Ap~licability
The described transaction execution system, when
operated according to the invention, provides for
secure validation of a PIN which is not derived by
encryption of card data, and which permits a number
of attempts to be made by the customer to success,ully
enter the PIN without requiring host communications
for each attempt. It is of particular value in a
bank-interchange environment, ~ith communication of
PIN's through cooperating institutions done only in a
secure encrypted form.
While the preferred embodiments of the invention
have been illustrated and described, it is to be
SA9-79-037
i 1 fi54'~5
understood that such does not limit the invention to
the precise constructions herein disclosed, and the
right is reserved to all changes and modifications
- cc,ming within the scope of the invention as defined
i~ the appended claims.
