System for authenticating users and devices in on-line transaction networks4317957Abstract A method for efficiently protecting transactions and providing authentication of users and devices in on-line systems that transfer funds electronically, dispense cash, or provide a good or permit a service to be utilized is provided. The transaction may be initiated by a magnetic-striped plastic card at an attended or unattended terminal (10, 11, 12) and requires the entry of a preassigned Personal Identification Number through a keyboard (20). The Personal Identification Number is encrypted (23) more than once at the terminal and other means are used in order to prevent the utilization of certain tapped-line data. The data required to validate and authorize the transaction is transmitted securely to a centralized computer (14) which accesses from its stored data base (15) the data that is required to decrypt and validate the transaction, including the encrypted Personal Identification Number corresponding to the received transaction data. A secret Terminal Master Key must be maintained securely at each terminal and may differ at each terminal. A list of such Terminal Master Keys and other secret data must be securely maintained at the centralized computer. Means for multiple-encryptions and decryptions in a predetermined way must also be maintained at each terminal and at the centralized computer. Means (34) are provided for securely returning a response to the terminal at which the transaction was initiated to authorize or reject the requested transaction. These functions are accomplished in a way that permits efficient utilization of data communications lines and reduces or eliminate perpetration of fraud by any of various means. Claims I claim: Description BACKGROUND OF INVENTION
TABLE 1
__________________________________________________________________________
FUNCTION: REENCRYPT FROM MASTER KEY, RFMX (X, Y)
KEY PLAIN TEXT
CIPHER TEXT
OPERATION
OPERAND REGISTER-KR
REGISTER-PTR
REGISTER-CTR
__________________________________________________________________________
LOAD KM0 into KR
KM0
LOAD Y into PTR Y
DECRYPT D[KM0] (Y)
STORE CTR
GENERATE
KM1 in KR
KM1
LOAD X into PTR X
DECRYPT D[KM1] (X)
GENERATE
ODD PARITY
CTR
TRANSFER
CTR to KR
D[KM1] (X)
LOAD PTR D[KM0] (Y)
ENCRYPT E[D[KM1] (X)] (D[KM0] (Y))
CLEAR KR 0
__________________________________________________________________________
The terminal generates Working Key using function Reencrypt from Master Key and operands Secondary Key and Security Parameter 2 at 64 as specified below: RFMK(SK,SP2)=E[D[KMT1](SK)](D[KMT](SP2))=WK. (3) The terminals encrypts the Transaction Request Message using the Working Key at 65, as specified below: E[WK](Transactions Request Message). (4) The terminal generates Security Parameter 3 using function Reencrypt to Master Key and operands Secondary Key and Working Key at 66 as specified below: RTMK(SK,WK)=E[KMT](D[D[KMT2](SK)](WK))=SP3, (5) one implementation of which is shown in Table 2 below:
TABLE 2
__________________________________________________________________________
FUNCTION: REENCRYPT TO MASTER KEY, RTMX (X, Y)
KEY PLAIN TEXT
CIPHER TEXT
OPERATION
OPERAND REGISTER-KR
REGISTER-PTR
REGISTER-CTR
__________________________________________________________________________
LOAD KM0 into KR
KM0
GENERATE
KM2 to KR
KM2
LOAD X into PTR X
DECRYPT D[KM2](X)
GENERATE
ODD PARITY
CTR
TRANSFER
CTR to KR
D[KM2](X)
LOAD Y into PTR Y
DECRYPT D[D[KM2](X)](Y)
LOAD KM0 into KR
KM0
TRANSFER
CTR to PTR D[D[KM2](X)](Y)
ENCRYPT E[KM0](D[D[KM2](X)](Y))
CLEAR KR 0
__________________________________________________________________________
The terminal generates Transmitted Key using function Reencrypt to Master Key and operands Secondary Key and Security Parameter 3 at 67 as specified below: RTMK(SK,SP3)=E[KMT](D[D[KMT2](SK)](SP3))=TK (6) The terminal appends the Transmitted Key to the Transaction Request Message in addition to other routing, transit and control information required in the message header at 68. The terminal encrypts the complete message including the header using a link encryption key at 69 and transmits it to the centralized computer at 70. The centralized computer sends the message to the Security Module at 71, the Security Module decrypts the message using the link encryption key at 72, the Security Module sends the routing, transit and control information to the centralized computer at 73, the centralized computer determines whether this is an "on-us" transaction or an interchange transaction at 80. If it is an interchange transaction, additional processing is required which will be described later. If this is not an interchange transaction, the centralized computer obtains various data from the accounting data base for which it may use the Terminal Identification to obtain the Terminal Master Key (encrypted) as may be stored similar to Table 3 and sends all the data to the Security Module at 74.
TABLE 3
______________________________________
TERMINAL MASTER
TERMINAL IDENTIFICATION
KEY (ENCRYPTED)
______________________________________
TID 1 KMT 1
TID 2 KMT 2
TID 3 KMT 3
TID 4 KMT 4
0 0
0 0
0 0
TID n KMT n
0 0
0 0
0 0
______________________________________
Security Module generates Security Parameter 3 using function Inverse Reencrypt to Master Key and operands Secondary Key and Transmitted Key at 75 as specified below: RTMK.sup.-1 (SK,TK)=SP3=E[D[KMT2](SK)](D[KMT](TK)), (7) one implementation of which is shown in Table 4.
TABLE 4
__________________________________________________________________________
FUNCTION: INVERSE REENCRYPT TO MASTER KEY, RTMK.sup.-1 (X, W)
KEY PLAIN TEXT
CIPHER TEXT
OPERATION
OPERAND REGISTER-KR
REGISTOR-PTR
REGISTER-CTR
__________________________________________________________________________
LOAD KM0 into KR
KM0
LOAD W into PTR W
DECRYPT D[KM0] (W)
STORE CTR
GENERATE
KM2 in KR
KM2
LOAD X into PTR X
DECRYPT D[ KM2] (X)
GENERATE
ODD PARITY
CTR
TRANSFER
CTR to KR
D[KM2] (X)
LOAD PTR D[KM0] (W)
ENCRYPT E[D[KM2] (X)] (D[KM0] (W))
CLEAR KR 0
__________________________________________________________________________
The Security Module generates the Working Key using function Inverse Reencrypt to Master Key and operands Secondary Key and Security Parameter 3 at 76 as specified below: RTMK.sup.-1 (SK,SP3)=WK=E[D[KMT2](SK)](D[KMT](SP3)). (8) The Security Module decrypts the Transaction Request Message using the Working Key at 77, as specified below: D[WK](Transaction Request Message). (9) The Security Module generates Security Parameter 2 using function Inverse Reencrypt from Master Key and operands Secondary Key and Working Key at 78, as specified below: RFMK.sup.-1 (SK,WK)=SP2=E[KMT](D[D[KMT1](SK)](WK)), (10) one implementation of which is shown in Table 5.
TABLE 5
__________________________________________________________________________
FUNCTION: INVERSE REENCRYPT FROM MASTER KEY, RFMX.sup.-1 (X,Y)
KEY PLAIN TEXT
CIPHER TEXT
OPERATION
OPERAND REGISTER-KR
REGISTER-PTR
REGISTER-CTR
__________________________________________________________________________
LOAD KM0 into KR
KM0
GENERATE
KM1 to KR
KM1
LOAD X into PTR X
DECRYPT D[KM1](X)
GENERATE
ODD PARITY
CTR
TRANSFER
CTR to KR
D[KM1](X)
LOAD Z into PTR Z
DECRYPT D[D[KM1](X)](Z)
LOAD KM0 into KR
KM0
TRANSFER
CTR to PTR D[D[KM1](X)](Z)
ENCRYPT E[KM0](D[D[KM1](X)](Z))
CLEAR KR 0
__________________________________________________________________________
The Security Module generates Security Parameter 1 using function Inverse Reencrypt from Master Key and operands Secondary Key and Security Parameter 2 at 79 as specified below: RFMK.sup.-1 (SK,SP2)=SP1=E[KMT](D[D[KMT1](SK)](SP2)) (11) The Security Module recovers part of the Primary Account Number, part of the Personal Identification Number, part of the card anti-counterfeiting number from Security Parameter 1 if FIG. 6 was originally used at the terminal 81 or whatever was used if alternative FIGS. 3, 4 or 5 were used. The Security Module recovers the remainder of the Primary Account Number from the decrypted Transaction Request Message and sends the complete number to the centralized computer at 82, the centralized computer retrieves the encrypted Personal Identification Number and the card anti-counterfeiting feature number from the accounting data base using the Primary Account Number at 83 as may be stored similar to Table 6.
TABLE 6
______________________________________
PRIMARY PERSONAL
ACCOUNT INDENTIFICATION CARD
NUMBER NUMBER (ENCRYPTED)
SIGNATURE
______________________________________
PAN 1 PIN 1 CS 1
PAN 2 PIN 2 CS 2
PAN 3 PIN 3 CS 3
0 0 0
0 0 0
0 0 0
PAN n PIN n CS n
0 0 0
0 0 0
0 0 0
______________________________________
The centralized computer sends the data to the Security Module to validate the transaction at 84, the Security Module compares the Personal Identification Number obtained from the Accounting Data Base after appropriate decryption with that generated from the Transaction Request Message and compares the two anti-counterfeiting numbers to validate the transaction at 85, 86. If the transaction does not appear valid, the Security Module indicates that the centralized computer should specify to the terminal a request that the cardholder re-enter his Personal Identification Number at 87 shown in FIG. 7B which the centralized computer does at 88, returning to processing at 51 shown in FIG. 7A. If the transaction appears valid, the Security Module notifies the centralized computer at 89, the centralized computer executes the remainder of the approval procedure at 90, generates an approval or disapproval response and sends it to the Security Module at 91. The Security Module encrypts the response using the Working Key and returns it to the centralized computer at 92, the centralized computer transmits the response to the terminal at 93. The terminal decrypts the response using the Working Key at 94, the terminal provides the service if approved or displays a message if disapproved at 95, the terminal generates an acknowledgement at 96, the terminal encrypts the acknowledgement using the Working Key and transmits it to the centralized computer at 97. The centralized computer sends the acknowledgement to the Security Module at 98, the Security Module decrypts the acknowledgement and notifies the centralized computer at 99, the centralized computer updates the account data base and notifies the Security Module and the Terminal at 100, the Security Module destroys the Working Key at 101, the Terminal updates the magnetic stripe if required and returns the card to the cardholder at 103, the Terminal destroys the Working Key at 104, and the transaction is complete at 102. If the transaction is an interchange transaction, the centralized computer (acquirer) uses the Bank Identification Number or similar designation to obtain the encrypted Site Master Interchange Key, the encrypted Passwork, the Computer Identification (acquirer) as may be stored similar to Table 7 in addition to the data normally retrieved and sends it all to the Security Module at 105. The Security Module uses the Site Master Interchange Key in place of the Terminal Master Key, uses the Password in place of the Personal Identification Number, uses the Computer Identification in place of the Terminal Identification, uses the Bank Identification Number in place of the Primary Account Number and uses part of the Time field to generate an Interchange Working Key as was done at 62 to 64 in FIG. 7A, at 106. The Security Module encrypts the Terminal Identification and the Terminal Master Key (after it has first been decrypted), using the Interchange Working Key, generates an Interchange Transmitted Key as was done at 66, 67 in FIG. 7A, appends the Interchange Transmitted Key, the header and control information to the Transaction Request Message and encrypts it using a link encryption key at 107, the Security Module sends the transaction to the acquirer centralized computer at 108. The acquirer centralized computer transmits the transaction to the issuer centralized computer at 109, the issuer centralized computer sends the message to the issuer Security Module at 110 shown in FIG. 7C.
TABLE 7
______________________________________
BANK COM-
IDEN- SITE MASTER PUTER
TIFICA- INTERCHANGE IDEN-
TION KEY PASSWORD TIFICA-
NUMBER (ENCRYPTED) (ENCRYPTED) TION
______________________________________
BIN 1 SMIK 1 PW 1 CID 1
BIN 2 SMIK 2 PW 2 CID 2
BIN 3 SMIK 3 PW 3 CID 3
0 0 0 0
0 0 0 0
0 0 0 0
BIN n SMIK n PW n CID n
0 0 0 0
0 0 0 0
0 0 0 0
______________________________________
The Security Module decrypts the transaction using the Link Encryption Key, sends the header and control information to the issuer Centralized Computer at 111, the issuer Centralized Computer uses the information to retrieve the encrypted Site Master Interchange Key, the encrypted Password and the Computer Identification and sends it to the Security Module at 112, the Security Module uses the same procedure as was used at 75, 76 in FIG. 7A, to recover the Interchange Working Key at 113 and uses the same procedure as was used at 78, 79, 81 in FIG. 7A, to recover the Password which is validated at 113. The Security Module uses the Interchange Working Key to recover the Terminal Identification and Terminal Master Key by decryption at 114. The remainder of the procedure to recover the Personal Identification Number, to validate and approve the transaction and generate a response is the same as was used at 75 to 79, 81 to 91 in FIGS. 7A and 7B at 115. The issuer Security Module encrypts the response that will go to the terminal using the Working Key at 116, encrypts the response to acknowledgement to go to the acquirer centralized computer using the Interchange Working Key and sends it to the issuer Centralized Computer at 117. The issuer Centralized Computer transmits the response to the acquirer centralized computer at 118, the acquirer Centralized Computer sends the response to the Security Module at 119, the Security Module decrypts the response using the Interchange Working Key and sends to the acquirer Centralized Computer the part of the response that is to be transmitted to the terminal and the Centralized Computer updates its in-process file at 121. The terminal follows the same procedures as in 94 to 97 in FIG. 7B, at 122. The acquirer Centralized Computer relays the acknowledgement to the issuer Centralized Computer at 123, the issuer Centralized Computer follows the same procedure as in 98 to 101 in FIG. 7B, at 124. The acquirer Centralized Computer updates the in-process file, relays notification to terminal at 128, the acquirer Security Module destroys the Working Key at 125, the terminal updates the magnetic stripe if required, returns the card to the cardholder at 129, destroys the Working Key at 126, and the transaction is complete at 127. Considering FIG. 1, "Computer with transmission means," 14, may consist of an IBM 370/148 Central Processing Unit (CPU), 3410 Tape units, 1403 Printer, 3705 Communications Controller, Bell 201C Data Sets. The Data Base may be accommodated on one or more IBM 3330 Disks, 15. The Cash Dispenser, 10, or ATM, 11, may consist of IBM 3614's that may include an Intel 8080 microprocessor and Motorola MGD8080DSM Data Security Module. The Security Module, 13, or 17, may consist of an Intel 8080 microprocessor and a Motorola MGD8080DSM Data Security Module. The other computer shown in FIG. 1, 16, may consist of a Burroughs 7766 CPU, 9495 Tape units, 9373 Disk units (18), Documation 1500 printer, Burroughs 7350 Communications Controller, TA1201 Data Sets, and RT 4000 Cash Dispensers or ATM's deployed similar to those shown communicating with the computer system, 14. In either case, the terminals indicated in 12 may be IBM 3604, 3612, or 3610 or Burroughs TU700, TC700. The communication lines may be 300 to 1200 baud, synchronous or asynchronous. It will be recognized by those skilled in the art that the particular devices indicated are for illustrative purposes only and do not change or limit the scope of the invention. For instance, CPU's manufactured by NCR, or Univac can be used, other ATM's, peripheral or communication devices manufactured by Varian, Memorex, DEC, NCR, Docutel, FDSI, Diebold, Tandem, Mosler, Bunker Ramo or others could have been substituted for the system components indicated. Similarly, microprocessors such as the Intel 8048 or 8085, Motorola 6800, PDP11 could have been specified rather than the Intel 8080 and would suffice with appropriate changes to the program that follows. Also, LSI devices that implement the DES manufactured by Fairchild, Western Digital, Collins-Rockwell, IBM or others could have been substituted for the Motorola device without changing or limiting the scope of the invention. The set of programs which follow implements the procedure previously described using an Intel 8080 Microprocessor with an attached Motorola MGD8080DSM Data Security Module. These devices are one possible implementation of the "Security Module" 13, FIG. 1. The programs are "stand-alone" for test purposes. That is, there has been no attempt to integrate these programs into the programs required for an operating, on-line network. However, any of several operating network programs can easily be modified to use the programs shown here by placing the proper set of "CALL's" at appropriate points of the operating program since the programs included here are comprehensive in that they implement all the functions required to mechanize the security procedure described in earlier sections of this application. Although this test program uses the DES in Electronic Code Book Mode exclusively, the DES may be used in Cipher Feedback or Block Chaining mode at appropriate places without limiting or changing the scope of the invention. The programs are divided into: 1. A main routine to generate either WK and TK given SP1, TID and KMT or generate WK and SP1 given TK, TID and KMT. The same program may be used at a terminal or at a HPC, with the proper parameter supplied to the program. The difference is that at the HPC, the terminal Master Key, KMT, is encrypted using the Host Master Key, KMO, while at the terminal, KMT is not encrypted. In addition, SP1 is a starting parameter at the terminal and TK is a starting parameter at the HPC. These differences are accommodated within the programs. 2. A set of subroutines that perform smaller, "building block" functions that the main routine sequences in an order that provides for implementing the security procedure previously described. 3. A testing program that simulates the operations that would normally take place at a terminal and those that would normally take place at a HPC. The procedure at the terminal is to use the remainder of the programs to generate TK and WK after SP1, KMT and TID are supplied. Then, a Transaction Request test message is enciphered using WK, and transmission of the message and TK to the HPC is simulated. At the HPC, generation of WK and SP1 is accomplished given TK, KMT, TID, using the same set of programs, and the test message is deciphered using WK. Both versions of the test message, and both versions of SP1 and WK are compared for equality. If they are equal, the HPC program initiates the encipherment of a response message and simulates transmission to the terminal. The terminal program initiates decipherment of the response message using WK and compares it to the original message. If the fields compared are equal, the test program halts at a normal stop. If any fields compared are not equal, the program stops at an error halt. 4. All constants, parameters, space for intermediate results and working storage are included within the set of programs given so that an operating program can easily be developed by deleting those portions included only for testing purposes. Once initiated, the testing program performs all functions and tests, and runs to completion if there are no errors. A summary description of each of the routines and subroutines follows. 5. MROUT, Main Routine. Given SP1, TID, KMT, generates all the intermediate values required and produces WK and TK by sequencing the remainder of the routines as required. Alternatively, given TK, TID, KMT, then WK and SP1 are generated. The proper parameter is required. 6. MWKLD, Load Master Key into Master Key Register and Active Register or load a Working Key into the Active Register, depending on the parameter supplied. The key is not deciphered in either case. 7. NGEDR, Encipher or Decipher N Groups of 8 Bytes, no more than 254 groups or 2032 bytes. Since the devices that implement the DES require integral multiples of 8 bytes, this routine has been so organized. The routine requires a parameter to distinguish between encipherment and decipherment. 8. EDCPR, Encipher or Decipher 8 Bytes. This routine is one of the smallest building blocks and interfaces directly to the Data Security Module. A parameter distinguishes between encipherment and decipherment. 9. MOVE7, Move 7 Bytes. This subroutine is included because of the chracteristics of the specific hardware device chosen to illustrate the implementation of the security procedure described in this application. It transfers the first 7 of the 8 required bytes to the Data Security Module. 10. MKODD, Make 8 Bytes Odd Parity. Since the DES requires that each 8 bit-byte that is part of an 8 byte group used as a key, have an odd parity bit as the rightmost bit, and since the security procedure described in this application requires that in some cases, the cipher text output be used as an encipher or decipher key, this routine insures that the proper parity is generated in all those 8 byte groups used as a key. 11. GNMKV, Routine to Generate Master Key Variants V1 or V2. This routine modifies the Master Key as required to generate the 2 variants required. As a result, with current devices, the Master Key must be stored within the microprocessor in addition to being stored in the Master Key Register. However, the "chips" or LSI devices that implement the DES can be redesigned so that in the future, the additional storage is not required and the Variants could be generated within the LSI device. 12. WKLOD, Working Key Load Routine. This routine first deciphers the Working Key using the Master Key and immediately loads the deciphered key into the Active Key Register where it can be used for enciphering or deciphering data. Ahtough not used by the testing program, this routine will be required in any operational network and, so, is included. 13. DELAY, Routine for Programmed Delays of more than 255 Instruction Execution Times. In order to simplify these programs to facilitate testing, the "interrupt" system was not used in the interface between the 8080 microprocessor and the MGD8080DSM Data Security Module. Instead, delays were programmed to accommodate the 320 microseconds required for encipherment or decipherment by the Data Security Module. This routine permits variable delays to a maximum of 60,000 Instruction Execution Times depending on the parameter supplied. 14. MOVEN, Move N Bytes. Because of the limited functionality of current microprocessors, this routine was included to facilitate transfers of fields and thereby reduce the size of the other routines. Depending on the parameter supplied, up to 256 bytes can be moved. 15. COMPR, Compare 2 Fields Routine. This routine is used during the debugging of the remainder of the routines to compare the two versions of SP1, WK, and the two test messages. This routine may be removed after testing is completed. 16. START, Routine to Debug, Simulates the Terminal and HPC. This routine is used only for testing the remainder of the set of programs by simulating calls to the Main Routine as if from a Terminal and a HPC, and comparing the results. It uses a set of constants and parameters which may also be deleted after testing is complete. Once initiated at START, it runs to completion at FINIS. If there are errors, various error halts are included within each of the routines. 17. Before assembling the program, a starting location must be selected for storage of the program and storage of the working storage, which requires that at least an ORG and a DSEG be added to the beginning of the Main Routine. An additional DSEG may be required at the beginning of the constants just preceding BPARAM. 18. A Master Key, KMO, must be generated or selected and entered into 8 successive locations starting at KMO. 19. A KMT must be selected or generated and entered starting at KMT. Then, KMT must be encrypted by KMO and entered starting at EKMT (E[KMO](KMT)=EKMT). 20. A TID must be chosen and entered starting at DTID. 21. An SP1 must be chosen and entered starting at DSP1. 22. The interface between the 8080 and the DSM must be set by using the parameter specified in BPARAM to set the I/O ports on the 8080 or changing what is in BPARAM to correspond to settings already implemented. In addition, the parameters specified in the list starting at MKEYL and ending at WRTDAT must correspond to the interface settings. 23. The program is initiated at START and runs to FINIS if there are no errors.
__________________________________________________________________________
LIST OF ERROR HALTS
Label Comes
at Routine From
Halt Name (Label) Reason
__________________________________________________________________________
MHLT1 MROUT MERR1 Parameter supplied neither
4 or 5
MHLT2 MROUT MERR2 Parameter supplied neither
4 or 5
MHLT3 MROUT MERR3 Parameter supplied neither
4 or 5
MWKHT1 MWKLD MWER1 DSM Status = Busy
MWKHT2 MWKLD MWER2 DSM Parity Error
MWKHT3 MWKLD MWER3 DSM Timed Out
EDCP4 EDCPR EDER1 DSM Status = Busy
EDCP5 EDCPR EDER2 DSM Parity Error
EDCP6 EDCPR EDER3 DSM Timed Out
MVE3 MOVE7 MVER1 DSM Parity Error
MVE4 MOVE7 MVER2 DSM Timed Out
WKL2 WKLOD WKER2 DSM Parity Error
WLK3 WKLOD WKER3 DSM Timed Out
WKL4 WKLOD WKER1 DSM Status = Busy
CMPR3 COMPR CMPR2 The 2 fields being compared
are not equal
DBUG4 START DBER1 DSM Parity Error
DBUG5 START DBER2 DSM timed out or not ready
__________________________________________________________________________
NAME/LABEL
OP CODE
OPERAND COMMENTS
__________________________________________________________________________
; MAIN ROUTINE, CAN BE USED AT
; TERMINAL OR AT HOST PRO-
; CESSING CENTER (HPC). IF
; USED AT TERMINAL, WK & TK
; ARE GENERATED GIVEN SP1, TID,
; AND KMT. ALL INTERMEDIATE
; VALUES ARE GENERATED. WK
; HAS ODD PARITY AFTER COMPLE-
; TION OF THE ROUTINE. AFTER
; COMPLETION, THE OPERATING
; PROGRAM MUST REQUEST ENCI-
; PHERMENT OF THE TRANSAC-
; TION REQUEST MESSAGE USING
; WK BY MAKING 2 CALLS, ONE
; TO LOAD WK INTO ACTIVE REG.
; & ONE TO ENCIPHER N-8 BYTE
; GROUPS, APPEND TK AND TRANS
; MIT THE TRANSACTION RE-
; QUEST MESSAGE (TRM) TO THE
; HPC. WK IS SAVED IN ORDER
; TO DECIPHER RESONSE MESSAGE
; RECEIVED FROM THE HPC.
; REQUIRES MVI A, 5H (ENCIPH.)
;
; IF USED AT HOST PROCESSING
; CENTER (HPC), WK & SP1 ARE
; GENERATED GIVEN TK, TID &
; KMT, ALL REQUIRED INTER
; MEDIATE VALUES ARE GENER-
; ATED. WK HAS ODD RARITY.
; AFTER COMPLETION OF ROUTINE
; THE OPERATING PROGRAM MUST
; REQUEST DECIPHERMENT OF THE
; TRM USING WK BY MAKING 2
; CALLS, ONE TO LOAD WK INTO
; ACTIVE REGISTER & ONE TO
; DECIPHER N-8 BYTE GROUPS
; VALIDATE THE PIN, ETC. IN
; SP1 TO AUTHENTICATE THE
; TRANSACTION, PREPARE A RE-
; SPONSE, USE CALLS TO ENCI-
; PHER RESPONSE USING WK, AND
; TRANSMIT RESPONSE TO THE
; TERMINAL. REQUIRES
; MVI A, 4H (DECIPHER).
; IN ADDITION, IN H & L REG.
; MUST BE THE ADDRESS OF THE
; FIRST OF A LIST OF 5
; ADDRESSES AS FOLLOWS-
; 1.
ADDR. OF SP1 LOCATION. IF
; AT TERMINAL OR INTO
; WHICH SP1 PLACED IF AT
; HPC
; 2.
ADDR. OF TID LOCATION
; 3.
ADDR. OF KMT LOCATION
; (KMT ENCIPHERED USING
; KMO IF AT HPC)
; 4.
ADDR. OF 8-BYTE AREA
; INTO WHICH WK WILL BE
; PLACED
; 5.
ADDR. OF 8-BYTE AREA
; INTO WHICH TK WILL BE
; PLACED IF AT TERMINAL
; OR ADDR. OF TK LOC.
; IF AT HPC.
;
; MVI A,5H IF TERMINAL OR
; MVI A,4H IF HPC
; LXI H, ADDRESS
; CALL MROUT
;
NAME SENDRO
MROUT: PUSH PSW
PUSH B
PUSH D
STA MRPAR ; STORE EN/DE PAR
; AMETER
LXI B, 2H ; CONSTANT TO B
; FOR ADDR. MODIF-
; ICATION
SHLD IADSP1 ; STORE INDIR. SP1
DAD B ; INCR. ADDR.
SHLD IADTID ; STORE INDIR. TID
DAD B ; INCR. ADDR.
SHLD IADKMT ; STORE INDIR. KMT
DAD B ; INCR. ADDR.
SHLD IADWK ; STORE INDIR. WK
DAD B ; INCR. ADDR.
SHLD IADTK STORE INDIR. TK
LDA MRPAR ; LOAD EN/DE PARAM.
CPI 5H ; COMPARE- IF TERM.
JZ MRT1 ; IF TERMINAL, SKIP
; DECIPHERING KMT
CPI 4H ; COMPARE IF HPC
MERR1: JNZ MHLT1 ; JUMP TO ERROR
; HALT-NOT HPC
MVI A, 3H ; PARAMETER TO LHLD
LXI H, KMO ; LOAD MASTER KEY
; AS ACTIVE KEY
CALL MWKLD ; CALL ROUTINE
LHLD IADKMT ; INDIR. KMT ADDR
; TO H REG.
SHLD $ + 1 ; STORE IN INSTR.
LHLD OOH ; KMT ADDR TO H
MVI A, 4H ; PARAM. TO A
LXI D, KMT ; LOCATION INTO
; WHICH KMT WILL
; BE PUT AFTER IT
; IS DECIPHERED
; USING KMO
CALL EDCPR ; DECIPHER KMT
LXI H, KMT ; KMT (DECIPHERED)
; ADDRESS TO H
CALL MKODD ; MAKE ODD PARITY
MRT1: MVI A,01000001B ; VARIANT 1 PARAM
; TO A REG.
LXI D, KMT1 ; KMT1 ADDR TO D
LXI H, KMT ; KMT ADDR TO H
CALL GNMKV ; MAKE VARIANT 1
MVI A,00001001B ; VARIANT 2 PARAM
LXI D, KMT2 ; KMT2 ADDR TO D
LXI H, KMT ; KMT ADDR TO H
CALL GNMKV ; MAKE VARIANT 2
LHLD IADKMT ; INDIR KMT ADDR
; TO H REG
SHLD $ + 1 ; STORE IN INSTR.
LHLD OOH ; KMT ADDR TO H
MVI A, 3H ; PARAM. TO A
CALL MWKLD ; LOAD KMT AS
; ACTIVE KEY
LHLD IADTID ; INDIR TID ADDR
; TO H REG
SHLD $ + 1 ; STORE IN INSTR.
LHLD OOH ; TID ADDR TO H
LXI D, SK ; ADDR SK TO H
MVI A, 4H ; DECIPHER PARAM
; TO A REG.
CALL EDCPR ; GENERATE SK =
; D/KMT/(TID)
LXI H, KMT1 ; KMT1 ADDR TO A
MVI A, 3H ; PARAM TO H
CALL MWKLD ; LOAD KMT1 AS
; ACTIVE KEY
MVI A, 4H ; DECIPH. PAR. A
LXI H, SK ; SK ADDR TO H
LXI D, DT1SK ; ADDR TO D
CALL EDCPR ; GENERATE
; D/KMT1/(SK)
LXI H, DT1SK ; ADDR TO H
CALL MKODD ; MAKE ODD PARITY
MVI A, 3H ; PARAM TO A
LXI H, KMT2 ; KMT2 ADDR TO H
CALL MWKLD ; LOAD KMT2 AS
; ACTIVE KEY
MVI A, 4H ; DECIPHER PARAM
; TO A REG
LXI H, SK ; ADDR SK TO H
LXI D, DT2SK ; ADDR TO D
CALL EDCPR ; GENERATE
; D/KMT2/(SK)
LXI H, DT2SK ; ADDR TO H
CALL MKODD ; MAKE ODD PARITY
LDA MRPAR ; LOAD EN/DE PAR.
CPI 4H ; COMPARE IF HPC
JZ MRT2 ; IF HPC, JUMP TO
;OTHER ROUTINE
CPI 5H ; COMPARE IF
; TERMINAL
MERR2: JNZ MHLT2 ; JUMP TO ERROR
; HALT-NOT TERM.
MVI B, 8H ; COUNT TO B
LXI D, TEMP1 ; TO ADDR TO D
LXI H, DT1SK ; FROM ADDR TO H
CALL MOVEN ; MOVE 8 BYTES,
MVI B, 8H ; COUNT TO B
LXI D, TEMP2 ; TO ADDR TO D
LXI H, DT2SK ; FROM ADDR TO H
CALL MOVEN ; DT2SK TO TEMP2
LHLD IADSP1 ; INDIR SP1 ADDR
; TO H REG
SHLD $ + 1 ; STORE IN INSTR.
LHLD OOH ; SP1 ADD TO H
MVI B, 8H ; COUNT TO B
LXI D, TEMP3 ; TO ADDR TO D
CALL MOVEN ; SP1 TO TEMP3
JMP MRT3 ; JUMP TO CONTINUE
; ROUTINE
;
; SUBROUTINE- IF HPC, SIMILAR
; TO PREVIOUS ROUTINE
;
MTR2: MVI B, 8H ; COUNT TO B
LXI D, TEMP1 ; TO ADDR TO D
LXI H, DT2SK ; FROM ADDR TO H
CALL MOVEN ; DT2SK TO TEMP1
MVI B, 8H ; COUNT TO B
Summary In the preferred example, an authorized holder of a size "A" magnetic-striped plastic card, which may be a Debit, Credit or Identification Card, would enter the card in a cash dispensing machine or automatic teller machine, enter his secret Personal Identification Number on a keyboard, and indicate the type and amount of transaction by pushing appropriate buttons provided for that purpose. The device would read the data on the magnetic stripe, such as account number and other data, and would also have available internally by electronic means a suitable Terminal Identification Code, a time clock and a secret Terminal Master Key. The device would generate, by appropriate means, a Transaction Request Message whose content would be determined by the type of transaction, amount requested and other data. In addition, the device would use part of the secret Personal Identification Number, part of the account number, part of the "Time" field, and part of a card anti-counterfeiting field if there is one, to generate a parameter that would be one input into a suitable encryption means. Additional inputs in a specified order or sequence would be the Terminal Master Key and the Terminal Identification. Multiple encryptions in a predetermined way would result in the generation of a Working Key, which would temporarily replace the Terminal Master Key within the encryption means and be used to encipher the Transaction Request Message and other data that may be required. The Working Key is then multiply-enciphered in a predetermined way using the Terminal Master Key and Terminal Identification to generate the Transmitted Key which is appended to the enciphered Transaction Request Message together with any additional data required to process the transaction such as routing, transit and other control information, and/or an Initialization Vector that may be required to initialize or synchronize the deciphering means. A link encryption key may then be used to encipher all of the data to be transmitted to protect the network against "traffic analysis" intrusion by wire tap. The Transaction Request Message and header and control data are transmitted to the centralized computer, which may require intermediate receivers and transmitters (nodes) in a large network. At some nodes, decipherment using the link encryption key may be required, with subsequent encipherment using a different link encryption key appropriate for the next segment of the transmission. At the centralized computer, the message is first deciphered using the last-used link encryption key. Then the other data in the header or control part of the message and data available in the centralized data base, some of which may be enciphered, are used to multiply-decipher the Transmitted Key, preferably in a physically and electronically separate and secure device sometimes called a Network Security Controller (NSC) or a Security Module (SM), which process of decipherment results in generation of the Working Key that was used to encipher the Transaction Request Message at the terminal. The Working Key is used to decipher the Transaction Request Message and is then additionally multiply-decrypted to obtain the parameter that was used at the terminal to initiate the process. Since that parameter contains part of the secret Personal Identification Number, part of the account number and part of the card anti-counterfeiting features, if there is one, the validity of the transaction can be determined by comparison of the fields in the message with the corresponding fields of data obtained from the centralized data base, for which comparison additional encipherments and/or decipherments may be required. Specifically, the account number in the message may be used to obtain the corresponding secret Personal Identification Number and the card anti-counterfeiting number if there is one from the centralized data base which are compared with the corresponding partial fields that were, by implication, included in the message at the terminal. In the preferred embodiment, the secret Personal Identification Number is not otherwise directly included in the Transaction Request Message, it is independently generated at the centralized computer by decipherments in a predetermined way, so that a penetrator somehow obtaining a deciphered message still does not have access to any data that will permit compromise of that account or any other account or aspect of system operation. The card anti-counterfeiting number, if there is one, also need not be included in the Transaction Request Message provided it is used at the terminal to generate the parameter that enters into the first encipherment. Since the multiple encipherments at the terminal also include the Terminal Identification and the secret Terminal Master Key, it is not possible for a penetrator to substitute a spurious terminal in the network for the purpose of initiating fraudulent transactions to transfer funds. In the preferred embodiment, part of the "Time" field is included in the parameter that is enciphered at the terminal, to insure that each Transaction Request Message is enciphered using a different Working Key. At the centralized computer, after the Transaction Request Message is validated, as described, additional processing may be required to determine if the transaction should be approved by determining if the account balance is adequate, if the transaction requested is valid for the specific account, if the plastic card used to initiate the transaction is not out-of-date, lost or stolen and by other processing that may be required. In the present example, the transaction is approved, the centralized computer generates an appropriate response which is enciphered within the NSC or SM using the same Working Key and transmitted to the terminal that initiated the transaction, from node to node, as may be required, and with link encryption as may be required. The terminal deciphers the response and provides the requested service by dispensing the amount of cash requested. The terminal generates an acknowledgement that may include the type of service provided and amount, encrypts it using the same Working Key that was used for the Transaction Request Message, and transmits it to the centralized computer. After the centralized computer receives the acknowledgement, it changes the accounting data base to reflect the results of the transaction, then the terminal and the centralized computer destroy the Working Key securely by resetting the register or location in which the Working Key was stored, and the transaction is complete. The transaction need not be to dispense cash, it may be to transfer funds, accept a deposit, make an advance to a valid credit card or against a reserve account or may be other types of transactions that may be provided by the Financial Institution for its depositors. A secret Terminal Master Key is required to be securely stored at each terminal, computer or other device that may initiate a message. In the preferred embodiment, the Terminal Master Key is never transmitted in any form but distributed by armed guard and entered under dual control into the encipherment means at each terminal, computer or other device, or other similar means are used that provides a similar level of security. Other systems that use encipherment also require manual entry of at least one secret key for proper operation. However, all other systems require more than 1 additional key be also entered or received at each terminal, some of which may be transmitted enciphered and are then deciphered in the terminal before use. In at least one system, the enciphering key that was used at the centralized computer to encipher all the secret Personal Identification Numbers, Key A, must be entered into each terminal in the network, which may number hundreds or more, thereby increasing the possibility of compromise. The Key A is distributed as Key A.sup.1 and manipulated internally in the terminal to form Key A, to reduce the possibility of compromise; nonetheless, such wide distribution still represents an exposure. In addition, a communications key is required at each terminal. In my invention, only one encryption key is required at each terminal, the Terminal Master Key or equivalent, thereby eliminating the exposure of the enciphering key that was used to encipher all the secret Personal Identification Numbers in the account data base. Furthermore, instead of only one key, Key A, being used to encipher all the secret Personal Identification Numbers in an account data base, multiple keys may be so used, reducing the intrinsic value of each such key considering bribery, coercion or blackmail, and facilitating plastic card reissue due to a change of equipment, change of technology, compromise of one or more enciphering keys, due to elapsed time, or for other reasons. In addition, using one key, Key A, may be adequate in a proprietary network, but does not facilitate sharing, or interchange of transactions between Financial Institutions. My invention provides for sharing and interchange. In some networks, computer-to-computer messages are required for administrative purposes. My invention provides for such messages provided there is an analogue for the secret Personal Identification Number, such as a "Password," and analogues for the Terminal Master Key and for the Terminal Identification, as already described. Yet other systems require that a terminal that is to communicate with a centralized computer must first send a message to a Network Security Controller (NSC) validating itself and requesting a Working Key or Communications Key. The NSC generates 2 copies of one key and transmits one enciphered copy to the terminal and one enciphered copy to the centralized computer. The terminal deciphers the Working Key, uses it to encipher the message and transmits it to the centralized computer, where it may be deciphered. Multiple transmissions are required for each transaction in that system, decreasing effective utilization of costly data communications lines. My invention does not require the additional transmissions since authentication of the terminal and generation of the Working Key are integral to the operation of the system. Because the method of using the Terminal Master Key in my invention protects it from exposure or compromise by cryptanalysis, it may be used for an extended period if not otherwise compromised. As a result, it is possible to use this invention in networks in which it would be difficult or impossible to permit changing a set of Master Keys on a frequent basis due to inaccessibility. One such network is one in which a communications satellite is used as a switching center. For example, a small number of transmitters may each have a need to transmit data to a large number of receivers in a way that does not permit other transmitters or some of the receivers to obtain access to the data transmitted. It would be an inefficient use of communications to require each transmitter or the satellite to maintain a separate enciphering key for each receiver and to separately encipher and process multiple copies of the same message, each originally enciphered using a different key. It is more efficient to permit the transmitter to encipher only one copy of a message and supply a list of recipients to the satellite, thereby permitting the satellite to decipher the message, and then to separately generate a Working Key to encipher one copy for each receiver using a different Master Key or set of Master Keys for each Working Key. The Master Keys could be combined 2, 3, 4 . . . (n-1) at a time by "exclusive or" to minimize the storage requirements, especially if there are a large number of receivers. The same methods as already described can be used provided each transmitter and receiver has a secret password, an Identification and a secret Master Key, and a means for encryption and decryption. In the preferred embodiment described, the National Bureau of Standards Data Encryption Standard was used to clarify the description and explanation of the invention, which standard may be used in Electronic Code Book Mode, Cipher Feed Back Mode or Block Chaining Mode. Those skilled in the art will recognize that other cryptographic means or systems which require or permit a secret encryption key are as suitable, and that the use of 56 binary digit or 64 binary digit enciphering keys, and 64 binary digit blocks of plain text and cipher text are for illustrative purposes only and do not limit the scope of the invention. The method described can as well be implemented in software using a large scale computer, a minicomputer or a microcomputer, or in hardware using a large scale integrated circuit device designed and manufactured for the purpose or by other electronic devices. Instead of a "Time" field indicated previously, a currency counter, a transaction serial number or any other parameter that changes with each transaction can be used without changing or limiting the scope of the invention. Although not a preferred embodiment, another variation in operation is feasible in some networks. In some networks it may be possible to include the PAN and TID as a header in the link encrypted part of the message. The PAN can be used at the centralized computer to retrieve the encrypted PIN from the data base after the Security Module decrypts the header using the last-used link encryption key. The Security Module decrypts the PIN and uses the PAN and the PIN to form SP1 and, by the method already described, generates the WK using the TID, KMT and its variants. The Security Module then decrypts the Transaction Request Message and may verify the PIN if it was encrypted with the Transaction Request Message. Alternatively, if the message decrypts properly using the WK, the correct PIN was used to initiate the transaction at the terminal by implication. If all this is done, it is not necessary to generate or transmit TK. Although a particular embodiment of a system for authenticating users and devices in on-line transaction networks in accordance with the invention has been described for the purpose of illustrating the manner in which the invention may be used to advantage, it will be appreciated that the invention is not limited thereto. Accordingly, any modification, variation or equivalent arrangement within the scope of the accompanying claims should be considered to be within the scope of the invention.
|
Same subclass Same class
| |||||||||||||||
