Signalling scheme for controlling data encryption device in an electronic fund transaction processing system5175766
Abstract
An improved method for communicating with a data encryption device is described. In accordance with this invention, a data encryption device adapted for providing encryption functions such as data encryption and decryption may be controlled with an inventive signalling protocol which provides two-way, symmetrical messaging. Data encryption messages are sent to a data encryption device with a message packet which includes a start of message character, a token field, a token dependent data field, a token delimiter and an end of message character. Once the requested data encryption function is performed, a response message is generated wherein the response message mirrors the request message with the exception that the token dependent data comprises data which was processed in accordance with the requested function. The method of the present invention is also adapted for loading key information in the data encryption device as well as communicating system status information.
Claims
I claim:
1. A signalling protocol for communicating with a data encryption device, said signalling protocol comprising:
a start-of-message symbol wherein the start-of-message symbol is the "]" character;
a plurality of message fields, each message field having
a token field for indicating a desired function;
a data field following said token field wherein number of data bits in said data field is related to the value of said token; and
a delimiter wherein the delimiter is the ";" character; and
an end-of-message symbol wherein the end-of-message symbol is the "]" character.
2. A method of communicating between a data encryption device and a requesting device, the data encryption device having a plurality of data security functions, the method comprising the steps of:
a) generating a request message in the requesting device to request a data security function from the data encryption device, wherein the step of generating request message comprises the steps of:
generating a start of message character;
concatenating a plurality of token segments to the start of message character to generate message text, each token segment having a token value, token data, and a token delimiter; and
concatenating an end of message character to the message text;
b) sending the request message from the generating device to the data encryption device;
c) receiving the request message in the data encryption device;
d) performing a data security function in the data encryption device in response to receiving the request message;
e) generating a response message in the data encryption device; and
f) sending the response message from the data encryption device to the requesting device.
3. The method of claim 2 wherein a plurality of previous request messages were sent to the data encryption device, the previous request messages having a previous token segment with a token value that is equal to the token value of a selected one of the plurality of token segments, the method comprising the step of not concatenating the selected token segment to the message text when the token data of the selected token segment is equal to the token data in the previous token segment of the previous request message that was most recently sent to the data encryption device, whereby the data encryption device detects the non-concatenation of the selected token segment and uses the token data in most recently sent previous token segment in place of the token data of the selected token segment.
4. The method of claim 2 wherein the token value comprises two alphanumeric characters.
5. The method of claim 2 wherein the token data comprises a data security function identifier, a parameter required for processing by a data security function, or context information to link response and request messages.
6. The method of claim 5 wherein the data security function identifier comprises four alphanumeric characters.
7. The method of claim 5 wherein the parameter required for processing by a data security function comprises a string of characters representing Data Encryption Standard keys, device configuration parameters, requests for setting or reading device statistics, encrypted data or personal identification numbers, or a count data.
8. The method of claim 2 wherein the start of message character is the "[" character and the end of message character is the "]" character.
9. The method of claim 2 wherein token segments with token values that are not defined in the data encryption device are not processed by the data encryption device.
10. A method of communicating between a data encryption device and a requesting device, the data encryption device having a plurality of data security functions, the method comprising the steps of:
a) generating a request message in the requesting device to request a data security function from the data encryption device;
b) sending the request message from the requesting device to the data encryption device;
c) receiving the request message in the data encryption device;
d) performing a data security function in the data encryption device in response to receiving the request message;
e) generating a response message in the data encryption deice,, wherein the step of generating the response message comprises the steps of:
generating a start of message character;
concatenating a plurality of token segments to the start of message character to generate message text, each token segment having a token value, token data, and a token delimiter; and
concatenating an end of message character to the message text; and
f) sending the response message from the data encryption device to the requesting device.
11. The method of claim 10 wherein the token value comprises two alphanumeric characters.
12. The method of claim 10 wherein the token data comprises a data security function that matches the data security function received in the request message, result of performing the data security function, context information to link response and request messages, or an error message.
13. The method of claim 12 wherein the result of performing the data security function comprises a string of characters representing Data Encryption Standard keys, device configuration parameters, requests for setting or reading device statistics, encrypted data or personal identification numbers, or account data.
14. The method of claim 10 wherein the start of message character is the "[" character and end of message character is the "]" character.
15. The method of claim 10, wherein the token segments with token values that are not defined in the requesting device are not processed by the requesting device.
16. A method of communicating between a data encryption device and a requesting device, the data encryption device having a plurality of data security functions, the method comprising the steps of:
a) generating a request message in the requesting device to request a data security function from the data encryption device, wherein the data security functions comprise functions for encrypting, translating, and verifying personal identification numbers, functions for encrypting, translating, and decrypting data, functions for generating and verifying message authentication codes, functions for loading, deleting, and verifying entries in encryption device key storage tables, functions for generating and translating working keys, and functions for performing administrative tasks;
b) sending the request message from the requesting device to the data encryption device;
c) receiving the request message in the data encryption device;
d) performing a data security function in the data encryption device in response to receiving the request message;
e) generating a response message in the data encryption device; and
f) sending the response message from the data encryption device to the requesting device.
17. The method of claim 16 wherein the administrative tasks include backing up and restoring device tables, setting and reading device parameters, and generating and loading master file keys.
Description
FIELD OF THE INVENTION
This invention relates to the field of electronic transaction processing, and more specifically, to a signalling scheme for reporting the operational status of remote encryption units to a central processing location.
BACKGROUND OF THE INVENTION
Electronic fund transfer processing systems are widely used for communicating financial transaction information between banks and remote terminals, such as point of sale terminals (POS) and automated teller machines (ATM).
In today's systems, information is transmitted between respective nodes over telecommunication lines which may be intercepted by an adversary. Though the intercepted electronic data is not immediately readable, it can be made readable through the use of a typical home computer. With this data and readily available hardware, counterfeit plastic cards can be produced and used to fraudulently withdraw funds from legitimate customer accounts.
Since the information transmitted over these systems must be maintained under intense security, and the interception of messages cannot realistically be prevented, the information or data is typically encoded or encrypted prior to transmission over the system.
Data encryption is the coding of data to render it unreadable to anyone who does not possess the proper decoding information. In an ATM transaction, a customers personal identification number (PIN) is transmitted along with a transaction request to allow the customer's financial institution to verify that the person making the request is authorized to do so. If the customer's PIN is not encrypted before transmission, it is readily available to an eavesdropper for use with counterfeit or stolen cards.
However, if the PIN is encrypted before it is transmitted, this type of theft can be prevented. Even if the encrypted PIN is intercepted, the encrypted PIN would be unintelligible. Without a usable PIN, a counterfeit card would be useless. While many financial transactions travel directly from a remote terminal to a financial institution over secure telecommunication lines, the trend today is toward large, shared networks in which transaction requests entered on a remote terminal are relayed through several network nodes before they arrive at the customer's financial institution.
The first link in a typical network arrangement, after the remote terminal, is the financial institution which has contracted to acquire transactions from the terminal. This institution is called the "acquirer." The acquirer forwards the request to a regional switch which receives transactions from many acquirers. The switch then forwards the request to an institution which verifies the PIN and authorizes or rejects the transaction. This institution may be the institution which issued the card or it may be an agent of the card issuer.
The use of data encryption to protect PINs in this environment requires that each remote terminal have the ability to encrypt PINs before transmitting them in a transaction request, and that each card issuer have the information necessary to decrypt the PINs upon receiving them for verification.
This would be a relatively simple matter if all PINs were encrypted under the same encryption method. If such were the case, PINs encrypted at remote terminals would remain encrypted until they arrived at the card issuer for verification. The card issuer could decrypt all PINs, regardless of which terminal they came from, because all remote terminals would use the same PIN-encrypting method.
However, this scenario is too simplistic to be effective. While providing a slightly higher level of security than if the PINs were not encrypted at all, there would be a huge security risk in that literally hundreds of thousands of PINs would be encrypted under the same method and each transaction acquirer and card issuer in the network would need to have knowledge of the method in order to perform their function in the transaction process. Such widespread knowledge of an encryption method would expose such a large number of PINs as to present an unacceptable level of network security risk. For this reason, the encryption method used today is necessarily more complex. In cases where the information or data is transmitted through one or more institutions, the information or data is typically decrypted at each institution and re-encrypted prior to transmission to the next institution.
While a variety of encryption methods are in use today, the most common encryption method is referred to as the "Data Encryption Standard (DES) algorithm." The DES algorithm has been recommended by the American National Standards Institute (ANSI) as the encryption standard for financial institutions.
The DES algorithm encrypts electronic data, such as a PIN entered at a remote terminal keypad or an account number taken from the magnetic strip on the back of a plastic debit card, by performing a complex series of processes which transform the original data into a completely unrecognizable string of characters.
What makes it possible to use only one encryption method industry-wide and still maintain data security is the fact that the DES algorithm incorporates encryption "keys" which enable users to customize or personalize the algorithm for their own application. Decrypting data which has undergone DES encryption under a specific key requires knowledge of both the algorithm and the key. Attempting to decrypt the data with a different key or with no key at all would produce unreadable gibberish. Therefore, even though the whole network possesses the encryption algorithm, only those parties which possess the specific encryption key are able to decrypt the data.
In a process which will be further discussed below, the customer's PIN is encrypted at the remote terminal under a key which is used exclusively to encrypt PINs for transmission to the transaction acquirer. The encrypted PIN is then sent to the acquirer, where it is translated for delivery to the switch. PIN translation at the acquirer involves decrypting the PIN under the remote terminal key, then re-encrypting it under a key which is used exclusively to encrypt PINs for transmission to the switch.
From the transaction acquirer, the PIN is transmitted to the switch, where a similar process is used to translate the PIN for delivery to the card issuer. Finally, at the card issuer, the PIN is translated for verification. Therefore, for each of these translations, a reliable data encryption/decryption device must be employed to convert the PIN information into a form which can be understood by the next link in the system.
Another threat to message security comes in the form of message tampering, such as the alteration of existing messages or the substitution of counterfeit messages for authentic messages.
For example, in an EFT message, a sophisticated eavesdropping or wiretapping organization could replace various elements in the message to redirect funds or fraudulently authorize transactions
Therefore, just as data encryption protects against PIN theft, so does message authentication protect against message tampering. With message authentication, selected segments of a message are passed through the DES algorithm under a special authentication key. Rather than encrypting the data though, the algorithm calculates a code value from the data and appends this value to the end of the message. The receiver of the message runs the message through the algorithm under the same key used by the sender and arrives at a code value. The receiver then compares the just-calculated value against the value that was appended to the message by the sender. If the message has been tampered with, the two values will not be the same. If, on the other hand, the code values are equal, the message is authentic.
This would effectively foil a message-tampering scheme because the ATM, upon arriving at a message authentication value for the return message, would automatically deny the transaction, in spite of the authorization code. This would happen because the substitution of the authorization segment to the denial segment would cause the authentication value to change. The ATM would sense the disparity between the two values and would refuse to dispense the cash. The perpetrator could not effectively alter the authentication value because he would not have the proper key used by the sender and the receiver to arrive at the value.
While the DES algorithm and the message authentication scheme described above provide a large measure of security, the security of the system is totally dependent upon the security of the DES keys under which data is encrypted or authenticated. If an adversary were to come into possession of the key used between two links in the network, that adversary would have free access to all the transaction data which passed between links. For example, if he knew the key used by an ATM to encrypt PINs, he would be able to decrypt the PIN of every customer who used the ATM. If he possessed the key used to authenticate messages between any two links in the network, he could freely substitute messages or parts of messages to fraudulently redirect funds.
Therefore, in this type of system, good key management practices are essential in maintaining the security of the system. One element of maintaining the security of key information is to perform all key operations, such as key entry, key storage, encryption, and translation, within a physically and logically secure module. Since, at various points in the encryption process, keys may exist in the clear, it would be possible for an adversary to penetrate the network link's software and extract encryption keys. Maintaining the circuitry which processes this information in secrecy prevents system security breaches.
Present data encryption devices for use with secure networks are known to have many limitations. For example, in present encryption devices, key management is cumbersome. In one widely used encryption system, secure data is retained in a security module which cannot be modified or reprogrammed externally. In order to modify key data retained within the security module, the security module must be physically removed from the encryption device and reprogrammed with a dedicated programming unit. As a consequence, the encryption unit must be taken out of service while any key modification is performed. Since effective system security requires that key information is changed regularly, the above technique results in inefficient utilization of the system. Current data encryption devices do not provide an easy and efficient means of updating secure information without physically disturbing the data encryption device or removing the data encryption device from the system.
Furthermore, current systems rely on a dedicated encryption device for each data communication channel. In systems which require fault-tolerant operation, a plurality of discrete devices are required, each under the control of a remote processor. With this type of system, a host processor communicates with each encryption device individually. If fault-tolerant operation is required, duplicate encryption devices are coupled to parallel channels of the host processor. The host processor then monitors the operation of the primary encryption device, and if communications with that device are lost, the host processor initiates communication with the secondary encryption device. Systems which employ this configuration are subject to the loss of data in transit when one communication channel fails. Any data transmitted to a failed unit before the detection of a failure by a host must be retransmitted to a secondary device for reprocessing, thus degrading the performance of the system. No data encryption device is known which provides a fault-tolerant data encryption channel which requires only a single data communication channel and provides fault-tolerant operation without the need for monitoring by a host processor. Furthermore, no data encryption device is known which provides for automatic recovery from hardware failures.
In yet another aspect of present system configurations, the operating statistics of an encryption unit are unknown to the operator of a system. For example, a large number of denied transactions may be attributable to a failing encryption unit. If such statistics were of interest to a system operator, the main processing computer of the system would have to compile them, thus increasing the processing overhead and the overall cost of the system. Present data encryption devices are not provided with any means by which a user can visually monitor the operating status of the device, thereby allowing a user to detect a problem before a catastrophic failure occurs.
Finally, present systems are increasingly required to communicate with a variety of communication protocols and key verification techniques. Currently, dedicated encryption devices are required for implementing each type of encryption scheme. No device is known which supports data encryption using a variety of communications protocols.
SUMMARY OF THE INVENTION
Briefly described, the present invention contemplates an improved data encryption system wherein a plurality of data encryption devices communicate with an associated host processor and with a display and control unit using a novel, asynchronous message format. The message format of the present invention incorporates a start of message symbol to indicate a new message. A token field follows the start of message symbol and a data field follows the token field. The token field indicates the type of message being sent. The message terminates with an end of message symbol wherein a number of token and data fields may be included within one message.
Accordingly, it is an object of the present invention to provide a multichannel encryption unit that is compatible with a plurality of encryption schemes.
It is another object of the present invention to provide a fault-tolerant device for use with data processing systems.
It is another object of the present invention to provide a fault-tolerant encryption device for use in an electronic fund transfer system.
It is another object of the present invention to provide a fault-tolerant processor arrangement.
It is another object of the present invention to provide a multichannel processor arrangement which is resistant to power supply failures.
It is another object of the present invention to provide an encryption device protocol which may be used universally with all known encryption schemes.
It is another object of the present invention to provide a tokenized communication protocol for communicating with a plurality of processing units.
It is another object of the present invention to provide an efficient and user-friendly means of entering and updating key information in a data encryption unit.
It is another object of the present invention to provide an efficient, secure and user-friendly means of entering and updating key information in a data encryption unit.
It is another object of the present invention to provide a menu-driven controller for use with a multichannel data encryption device.
It is another object of the present invention to substantially reduce the cost of a data encryption device.
It is another object of the present invention to provide improved security in a data encryption device while improving the ease of entry of key information.
It is another object of the present invention to provide a display device for use with a multichannel encryption unit.
It is another object of the present invention to provide a method and means for recording and displaying operating statistics in a data encryption unit.
It is another object of the present invention to provide a method of altering the software of a data encryption device display and control unit without disturbing the operation of associated data encryption devices.
It is another object of the present invention to provide a method of updating the control software in a data encryption device without physically disturbing the data encryption unit.
It is another object of the present invention to provide an improved means for updating software in a multiprocessor computer system.
It is another object of the present invention to provide a user-friendly front end control unit which controls access to data encryption devices.
It is another object of the present invention to provide an efficient and effective means of providing password protection in data encryption devices.
It is another object of the present invention to provide a fault-tolerant microcomputer arrangement.
It is another object of the present invention to provide a menu-driven key management interface for use data encryption devices.
BRIEF DESCRIPTION OF THE DRAWINGS
These and other objects will be fully appreciated through the description below and the accompanying Figures of drawing in which:
FIG. 1 is a block diagram showing a typical shared network for an electronic fund transfer system.
FIG. 2A is a block diagram of a prior art encryption device and mainframe computer arrangement.
FIG. 2B is a block diagram of the encryption device and mainframe computer arrangement of the present invention.
FIG. 3A is a block diagram of the basic configuration of the multichannel, microcomputer-based encryption system of the present invention.
FIG. 3B is a block diagram of an embodiment of the multichannel, microcomputer-based encryption system of the present invention having a fault-tolerant encryption or processing device arrangement.
FIG. 3C is a block diagram of an embodiment of the multichannel, microcomputer-based encryption system of the present invention having a fault-tolerant power supply arrangement.
FIG. 3D is a block diagram of an embodiment of the multichannel, microcomputer-based encryption system of the present invention having a fault-tolerant encryption or processing device arrangement and a fault-tolerant power supply arrangement.
FIG. 4A is schematic diagram of an encryption device adapted for use with the system of FIG. 3A or 3C.
FIG. 4B is schematic diagram of an encryption device arrangement adapted for use with the system of FIG. 3B or 3D.
FIGS. 5A through 13 are flow diagrams detailing the operation of the monitor software portion for each of the encryption devices used in conjunction with the present invention, wherein:
FIG. 5A is a flow diagram of the encryption device power-on initialization routine.
FIG. 5B is a continuation of the flow diagram of FIG. 5A.
FIG. 6 is a flow diagram detailing the operation of the "F.sub.-- Init1" subroutine called by the routine of FIG. 5A.
FIG. 7 is a flow diagram detailing the operation of the "F.sub.-- Init2" subroutine called by the routine of FIG. 7.
FIG. 8A is a flow diagram of the encryption device serial interrupt routine.
FIG. 8B is a memory map of the serial input and output buffers.
FIG. 9 is a flow diagram of the encryption device bus interrupt routine.
FIG. 10A is a flow diagram of the "F.sub.-- LOADAPP" subroutine called by the subroutine of FIG. 9.
FIG. 10B is a continuation of the flow diagram of FIG. 10A.
FIG. 11 is a flow diagram of the encryption device "POWERFAIL.sub.13 INTERRUPT" subroutine.
FIG. 12 is a flow diagram of the encryption tamper switch interrupt routine.
FIG. 13 is a flow diagram of the encryption device F.sub.-- WATCHDOG subroutine.
FIGS. 14 through 50 are flow diagrams detailing the operation of the application software portion for each of the encryption devices used in conjunction with the present invention, wherein:
FIGS. 14A and 14B are flow diagrams of the encryption device "START.sub.-- APPLICATION" routine.
FIG. 15 is a continuation of the routine of FIG. 14.
FIGS. 16A and 16B are continuations of the routine of FIG. 15.
FIGS. 17A through 17C are flow diagrams of token input routines.
FIG. 18A is a jump table layout used by the routines of FIG. 17A.
FIG. 18B is a jump table layout used by the error routine of FIG. 50.
FIG. 19 is a flow diagram of the "STAT" routine branched to by the routine of FIG. 17A.
FIG. 20A is a flow diagram of the routine for processing the "ZA" token and is branched to by the routine of FIG. 17A.
FIG. 20B is a flow diagram of the routine for processing the "ZB" token and is branched to by the routine of FIG. 17B.
FIG. 20C is a flow diagram of the routine for processing the "ZC" token and is branched to by the routine of FIG. 17C.
FIG. 20D is a flow diagram of the routine for processing the "2D" through "ZD" tokens and is branched to by the routine of FIG. 17C.
FIG. 21 is a flow diagram of the "PROCESS" message routine jumped to from the routine of FIG. 16.
FIG. 22 is a flow diagram of the "CATC" message routine jumped to from the routine of FIG. 21.
FIG. 23 is a flow diagram of the "CKTA" message routine called by the routine of FIG. 21.
FIG. 24 is a flow diagram of the "CLWA" message routine called by the routine of FIG. 21.
FIG. 25 is a flow diagram of the "CRYP" message routine called by the routine of FIG. 21.
FIG. 26 is a flow diagram of the "CWKS" message routine called by the routine of FIG. 21.
FIG. 27 is a flow diagram of the "DDAT" message routine called by the routine of FIG. 21.
FIG. 28 is a flow diagram of the "DES" message routine called by the routine of FIG. 21.
FIG. 29 is a flow diagram of the "DKTE" message routine called by the routine of FIG. 21.
FIG. 30 is a flow diagram of the "ECHO" message routine called by the routine of FIG. 21.
FIG. 31 is a flow diagram of the "FDAT" message routine called by the routine of FIG. 21
FIG. 32 is a flow diagram of the "EFIT" message routine called by the routine of FIG. 21.
FIG. 33 is a flow diagram of the "EPIN" message routine called by the routine of FIG. 21.
FIG. 34 is a flow diagram of the "GWKS" message routine called by the routine of FIG. 21.
FIG. 35 is a flow diagram of the "IKEY" message routine called by the routine of FIG. 21.
FIG. 36 is a flow diagram of the "LATM" message routine called by the routine of FIG. 21.
FIG. 37 is a flow diagram of the "LCDT" message routine called by the routine of FIG. 21.
FIG. 38 is a flow diagram of the "LENT" message routine called by the routine of FIG. 21.
FIGS. 39A and 39B are flow diagrams of the "LMKT" message routine called by the routine of FIG. 21.
FIG. 40 is a flow diagram of the "LKEY" message routine called by the routine of FIG. 21.
FIG. 41 is a flow diagram of the "RKEY" message routine called by the routine of FIG. 21.
FIG. 42 is a flow diagram of the "SKEY" message routine called by the routine of FIG. 21.
FIG. 43 is a flow diagram of the "TDLY" message routine called by the routine of FIG. 21.
FIG. 44 is a flow diagram of the "TPIN" message routine called by the routine of FIG. 21.
FIG. 45 is a flow diagram of the "TWKD" message routine called by the routine of FIG. 21.
FIG. 46 is a flow diagram of the "F.sub.-- DELAY" message routine called by various subroutines of the present invention.
FIG. 47 is a flow diagram of the "TWKL" message routine called by the routine of FIG. 21.
FIG. 48 is a flow diagram of the "VKTE" message routine called by the routine of FIG. 21.
FIG. 49A is a flow diagram of the "VPIN" message routine called by the routine of FIG. 21.
FIG. 49B is a continuation of the routine of FIG. 49A.
FIG. 50 is a flow diagram of the "ERROR" routine called by the routine of FIG. 16.
FIGS. 51 through 97 are diagrams of screen displays of the menu-driven, user-friendly interface of the present invention, wherein:
FIG. 51 is a diagram of the opening status screen displayed to the user upon system power-up.
FIG. 52 is a representative sample of the opening help screen displayed to the user when activated from a preselected function.
FIG. 53 is a diagram of the master status screen displayed to the user when the status display mode is selected.
FIG. 54 is a diagram of the status screen displayed to the user when resetting board statistics.
FIG. 55 is a diagram of the status screen displayed to the user under an alarm condition.
FIG. 56 is a diagram of the master "OPTIONS.sub.-- MENU" displayed to the user when the options mode is selected.
FIG. 57 is a diagram of the screen displayed to the user when option "Status Interval" is selected.
FIG. 58 is a diagram of the screen displayed to the user when option "Sample Interval" is selected.
FIG. 59 is a diagram of the screen displayed to the user when option "Threshold Values" is selected.
FIG. 60 is a diagram of the screen displayed to the user when option "New Password" is selected.
FIG. 61 is a diagram of the screen displayed to the user when option "Configure" is selected.
FIG. 62 is a diagram of the screen displayed to the user when option "Configure" is selected at a first level, and a particular board is selected at a second level.
FIG. 63 is a diagram of the screen displayed to the user when option "Configure" is selected at a first level, a particular board is selected at a second level, and the "Board Description" menu is selected at a third level.
FIG. 64 is a diagram of the screen displayed to the user when option "Configure" is selected at a first level, a particular board is selected at a second level, and the Board Description menu is selected at a third level.
FIG. 65 is a diagram of the screen displayed to the user when option "Configure" is selected at a first level, a particular board is selected at a second level, and the "Group" menu is selected at a third level.
FIG. 66 is a diagram of the screen displayed to the user when option "Configure" is selected at a first level, a particular board is selected at a second level, and the "Mode" menu is selected at a third level.
FIG. 67 is a diagram of the screen displayed to the user when option "Configure" is selected at a first level, a particular board is selected at a second level, and the "Communications" menu is selected at a third level.
FIG. 68 is a diagram of the screen displayed to the user when option "Configure" is selected at a first level, a particular board is selected at a second level, the "Communications" menu is selected at a third level, and "Baud Rate" is selected at the fourth level.
FIG. 69 is a diagram of the screen displayed to the user when option "Configure" is selected at a first level, a particular board is selected at a second level, the "Communications" menu is selected at a third level, and "Parity" is selected at the fourth level.
FIG. 70 is a diagram of the screen displayed to the user when option "Configure" is selected at a first level, a particular board is selected at a second level, the "Communications" menu is selected at a third level, and "Data Bits" is selected at the fourth level.
FIG. 71 is a diagram of the screen displayed to the user when option "Configure" is selected at a first level, a particular board is selected at a second level, the "Communications" menu is selected at a third level, and "Frame Timer" is selected at the fourth level.
FIG. 72 is a diagram of the screen displayed to the user when option "Configure" is selected at a first level, a particular board is selected at a second level, and "Serial Support" is selected at a third level.
FIG. 73 is a diagram of the master screen displayed to the user when "Keys" is selected on the menu bar.
FIG. 74 is a diagram of the screen displayed to the user when Key menu item "Load MFK" is selected at a first level and "ENTER.sub.-- KEY Part 1" is displayed at a second level.
FIG. 75 is a diagram of the screen displayed to the user when Key menu item "Load MFK" is selected at a first level, "ENTER.sub.-- KEY Part 1" is selected at a second level, a key part has been entered, and the system is requesting verification of the key part.
FIG. 76 is a diagram of the screen displayed to the user when Key menu item "Load MFK" is selected at a first level, all key parts have been entered, and the system is requesting acceptance of the key parts.
FIG. 77 is a diagram of the screen displayed to the user when Key menu item "generate PVK cryptogram" is selected at a first level, the key parts are entered at the second level, and the key parts were accepted at a third level.
FIG. 78 is a diagram of the screen displayed when a user has instructed the system to load a cryptogram.
FIG. 79 is a diagram of the screen displayed when a user has instructed the system to load a cryptogram and the system is prompting a user to enter a table position.
FIG. 80 is a diagram of the screen displayed when a key table position has been entered and the system is requesting verification of the entered value.
FIG. 81 is a diagram of the screen displayed when the entered key table position value has been verified by the user and the key table position has been loaded in the system.
FIG. 82 is a diagram of the screen displayed when the menu option "Random Key generation" is selected by the user.
FIG. 83 is a diagram of the opening screen displayed to the user when the Key menu item "LOAD.sub.-- DIEBOLD.sub.-- TABLE" is selected.
FIG. 84 is a diagram of the screen displayed to the user when the Key menu item "LOAD.sub.-- DIEBOLD.sub.-- TABLE" is selected and the user editing mode is active.
FIG. 85 is a flow diagram of the screen displayed when the user has selected the menu item "LOAD.sub.-- DIEBOLD.sub.-- TABLE" is selected, a table has been entered and the "F3" key has been pressed and the system is prompting the user to accept or cancel the table or return to the table editing mode.
FIG. 86 is a diagram of the screen displayed to the user when the Key menu item "LOAD.sub.-- DIEBOLD.sub.-- TABLE" is selected and the Diebold table has been accepted.
FIG. 87 is a diagram of the screen displayed to the user when the Key menu "LOAD.sub.-- DIEBOLD.sub.-- TABLE" is selected, the Diebold table has been accepted, a table position has been entered, and a duplicate table value has been entered.
FIG. 88 is a diagram of the master screen displayed to the user when "Utils" is selected on the menu bar.
FIG. 89 is a diagram of the screen displayed to the user when "Utils" is selected on the menu bar, "Backup" has been selected under the "Utils" menu, and a board has been selected to Backup.
FIG. 90 is a diagram of the screen displayed to the user when "Utils" is selected on the menu bar, "Backup" has been selected under the "Utils" menu, and the system is prompting the user to insert a diskette in the system.
FIG. 91 is a diagram of the screen displayed to the user when "Utils" is selected on the menu bar, "Backup" has been selected under the "Utils" menu, a board has been selected to Backup, and the backup drive was not ready.
FIG. 92 is a diagram of the screen displayed to the user when "Utils" is selected on the menu bar, "Backup" has been selected under the "Utils" menu, a board has been selected to Backup, the backup has been completed, and the backup description is displayed.
FIG. 93 is a diagram of the screen displayed to the user when "Utils" is selected on the menu bar and "Restore" has been selected under the "Utils" menu.
FIG. 94 is a diagram of the screen displayed to the user when "Utils" is selected on the menu bar, "Restore" has been selected under the "Utils" menu, and a restore file is loaded in the system.
FIG. 95 is a diagram of the screen displayed to the user when "Utils" is selected on the menu bar, "Restore" has been selected under the "Utils" menu, a restore file is loaded in the system, and a restore file has been selected.
FIG. 96 is a diagram of the screen displayed to the user when "Utils" is selected on the menu bar and "Clear Board Statistics" has been selected under the "Utils" menu.
FIG. 97 is a diagram of the master screen displayed to the user when "Quit" is selected on the menu bar.
FIGS. 98 through 160 are a series of flow diagrams detailing the operation of the monitor control processor for controlling the user-friendly interface and for communicating with the above-described encryption devices, wherein:
FIG. 99 is a flow diagram of the startup routine of the display control processor.
FIG. 100A is a flow diagram of the main menu subroutine called by the routine of FIG. 100A.
FIG. 100B is a continuation of the flow diagram of FIG. 100A.
FIG. 100C is a continuation of the flow diagram of FIG. 100B.
FIG. 100D is a continuation of the flow diagram of FIG. 100C.
FIG. 101 is a flow diagram of the "INIT" subroutine called by the routine of FIG. 99.
FIG. 102A is a flow diagram of the "OPEN.sub.-- DEBS" subroutine called by numerous subroutines of the present invention.
FIG. 102B is a continuation of the flow diagram of FIG. 102A.
FIG. 103 is a flow diagram of the "CLOSE.sub.-- DEBS" subroutine called by numerous subroutines of the present invention.
FIG. 104A is a flow diagram of the "SYSTEM.sub.-- STATUS" subroutine called by the subroutine of FIG. 100B.
FIG. 104B is a continuation of the subroutine of FIG. 104A.
FIG. 104C is a continuation of the flow diagram of FIG. 100B.
FIG. 105 is a flow diagram of the "STATUS3" subroutine called by the routine of FIG. 104B.
FIG. 106 is a flow diagram of the "WRITE.sub.-- FREEZE" subroutine called by the subroutine of FIG. 104B.
FIG. 107 is a flow diagram of the "NEXT.sub.-- BOARD" subroutine called by the subroutine of FIG. 104B.
FIG. 108 is a flow diagram of the "PREV.sub.-- BOARD" subroutine called by the subroutine of FIG. 104B.
FIG. 109A is a flow diagram of the "DISPSTAT" subroutine called by the subroutine of FIG. 105.
FIG. 109B is a continuation of the flow diagram of FIG. 109A.
FIG. 109C is a continuation of the flow diagram of FIG. 109B.
FIG. 110 is a flow diagram of the "DRAWALARM" subroutine called by the subroutine of FIGS. 109A-109C.
FIG. 111 is a flow diagram of the "GETVER" subroutine called by various subroutines of the present invention.
FIG. 112A is a flow diagram of the "OPTIONS.sub.-- MENU" subroutine called by the subroutine of FIG. 100B.
FIG. 112B is a continuation of the subroutine of FIG. 112A.
FIG. 112C is a continuation of the subroutine of FIG. 112B.
FIG. 113 is a flow diagram of the "SET.sub.-- STATUS.sub.-- INTERVAL" subroutine called by the subroutine of FIG. 112.
FIG. 114 is a flow diagram of the "SET.sub.-- SAMPLE.sub.-- INTERVAL" subroutine called by the subroutine of FIG. 112.
FIG. 115 is a flow diagram of the "SET.sub.-- THRESHOLDS" subroutine called by the subroutine of FIG. 112.
FIG. 116 is a flow diagram of the "SET.sub.-- IDLE.sub.-- TIMEOUT" subroutine called by the subroutine of FIG. 112.
FIG. 117 is a flow diagram of the "SET.sub.-- CHECK.sub.-- DIGIT.sub.-- LENGTH" subroutine called by the subroutine of FIG. 112.
FIG. 118 is a flow diagram of the "SET.sub.-- KEY.sub.-- PARTS" subroutine called by the subroutine of FIG. 112.
FIG. 119 is a flow diagram of the "SET.sub.-- TABLE.sub.-- PARTS" subroutine called by the subroutine of FIG. 112.
FIG. 120 is a flow diagram of the "ENABLE/DISABLE.sub.-- PASSWORDS" subroutine called by the subroutine of FIG. 112.
FIG. 121 is a flow diagram of the "SET.sub.-- PASSWORDS" subroutine called by the subroutine of FIG. 112.
FIG. 122 is a flow diagram of the "GET.sub.-- LEVEL" subroutine called by the subroutine of FIG. 121.
FIG. 123A is a flow diagram of the "GET.sub.-- PASSWORD" subroutine called by the subroutine of FIG. 121.
FIG. 123B is a continuation of the flow diagram of FIG. 124B.
FIG. 124A is a flow diagram of the "PUT.sub.-- OPTIONS" subroutine called by the subroutine of FIG. 99.
FIG. 124B is a memory map showing the file structure of the executive portion and options portion of the control software of the monitor and control processor of the present invention.
FIG. 125A is a flow diagram of the "GET.sub.-- OPTIONS" subroutine called by the subroutine of FIG. 101.
FIG. 125B is a continuation of the flow diagram of FIG. 125A.
FIG. 126 is a flow diagram of the "CONFIG.sub.-- MENU" subroutine called by the subroutine of FIG. 112.
FIG. 127 is a flow diagram of the "CONFIG.sub.-- BOARD" subroutine called by the subroutine of FIG. 126.
FIG. 128 is a flow diagram of subroutine "A" called by the subroutine of FIG. 127.
FIG. 129 is a flow diagram of subroutine "B" called by the subroutine of FIG. 127.
FIG. 130 is a flow diagram of subroutine "C" called by the subroutine of FIG. 127.
FIG. 131 is a flow diagram of subroutine "D" called by the subroutine of FIG. 127.
FIG. 132 is a flow diagram of subroutine "E" called by the subroutine of FIG. 127.
FIG. 133A is a flow diagram of the "COMM.sub.-- PARMS" subroutine called by the subroutine of FIG. 131.
FIG. 133B is a continuation of the flow diagram of FIG. 133A.
FIG. 134 is a flow diagram of the "BAUD.sub.-- RATE" subroutine called by the subroutine of FIG. 133.
FIG. 135A is a flow diagram of the "PARITY.sub.-- PARAM" subroutine called by the subroutine of FIG. 133.
FIG. 135B is a flow diagram of the "DATA.sub.-- BITS" subroutine called by the subroutine of FIG. 133.
FIG. 136 is a flow diagram of the "STOP.sub.-- BITS" subroutine called by the subroutine of FIG. 133.
FIG. 137 is a flow diagram of the "TRANSMIT.sub.-- DELAY" subroutine called by the subroutine of FIG. 133.
FIG. 138 is a flow diagram of the "FRAME.sub.-- TIMER" subroutine called by the subroutine of FIG. 133.
FIG. 139 is a flow diagram of the "HARDWARE.sub.-- FLOW.sub.-- CONTROL" subroutine called by the subroutine of FIG. 133.
FIG. 140A is a flow diagram of the "SERIAL.sub.-- SUPPORT" subroutine called by the subroutine of FIG. 132.
FIG. 140B is a continuation of the flow diagram of FIG. 140A.
FIG. 141 is a flow diagram of the "FIRST.sub.-- CONFIG" subroutine called by various subroutines of the present invention.
FIG. 142 is a flow diagram of the "NEXT.sub.-- CONFIG" subroutine called by various subroutines of the present invention.
FIG. 143A is a flow diagram of the "KEYS.sub.-- MENU" subroutine called by the subroutine of FIG. 100.
FIG. 143B is a continuation of the flow diagram of FIG. 143A.
FIG. 143C is a continuation of the flow diagram of 143B.
FIG. 144 is a flow diagram of the "WARN.sub.-- NOBOARDS" subroutine called by various subroutines of the present invention.
FIG. 145A is a flow diagram of the "GET.sub.-- KEY" subroutine called by the subroutine of FIG. 206.
FIG. 145B is a continuation of the flow diagram of FIG. 145A.
FIG. 145C is a continuation of the flow diagram of FIG. 145B.
FIG. 146 is a continuation of the flow diagram of FIG. 145C.
FIG. 147A is a flow diagram of the "LOAD.sub.-- KEYTABLE" subroutine called by the subroutine of FIG. 203.
FIG. 147B is a continuation of the flow diagram of FIG. 147A.
FIG. 147C is a continuation of the flow diagram of FIG. 147B.
FIG. 147D is a continuation of the flow diagram of FIG. 147C.
FIG. 148 is a flow diagram of the "ACCEPT.sub.-- KEY" subroutine called by the subroutine of FIG. 206.
FIG. 149 is a flow diagram of the "ENTER.sub.-- KEY" subroutine called by the subroutine of FIG. 145C.
FIG. 150 is a flow diagram of the "ENTER.sub.-- CRYPTOGRAM" subroutine called by the subroutines of FIG. 147.
FIG. 151A is a flow diagram of the "LOAD.sub.-- DIEBOLD.sub.-- TABLE" subroutine called by the subroutine of FIG. 204.
FIG. 151B is a continuation of the flow diagram of FIG. 151A.
FIG. 151C is a continuation of the flow diagram of FIG. 151B.
FIG. 152 is a flow diagram of subroutine "C" called by the subroutine of FIG. 151.
FIG. 153 is a flow diagram of subroutine "D" called by the subroutine of FIG. 151.
FIG. 154 is a flow diagram of subroutine "E" called by the subroutine of FIG. 151.
FIG. 155 is a flow diagram of subroutine "F" called by the subroutine of FIG. 151.
FIG. 156 is a flow diagram of subroutine "G" called by the subroutine of FIG. 151.
FIG. 157 is a flow diagram of subroutine "H" called by the subroutine of FIG. 151.
FIG. 158 is a flow diagram of subroutine "I" called by the subroutine of FIG. 151.
FIG. 159 is a flow diagram of subroutine "J" called by the subroutine of FIG. 151.
FIG. 160A is a flow diagram of the "Check.sub.-- DT.sub.-- DUP" subroutine called by the subroutine of FIG. 158.
FIG. 160B is a continuation of the flow diagram of FIG. 160A.
FIG. 161 is a flow diagram of the "STORE.sub.-- DIEBOLD" flow diagram called by the subroutine of FIG. 159.
FIG. 162A is a flow diagram of subroutine "A" called by the subroutine of FIG. 161.
FIG. 162B is a continuation of the flow diagram of FIG. 162A.
FIG. 163 is a flow diagram of subroutine "B" called by the subroutine of FIG. 161.
FIG. 164 is a flow diagram of the "VALID.sub.-- DIEBOLD.sub.-- TABLE" called by the subroutine of FIG. 162A.
FIG. 165 is a flow diagram of the "INIT.sub.-- DIEBOLD.sub.-- TABLE" called by the subroutine of FIG. 156.
FIG. 166A is a flow diagram of the "GEN.sub.-- RANDOM.sub.-- DIEBOLD.sub.-- TABLE" subroutine called by the subroutine of FIG. 155.
FIG. 166B is a continuation of the flow diagram of FIG. 166A.
FIG. 167 is a flow diagram of the "NIX" subroutine called by the subroutine of FIG. 166B.
FIGS. 168A and 168B are flow diagrams of the "UTILS.sub.-- MENU" subroutine called by the subroutine of FIG. 100.
FIG. 169A is a flow diagram of the "BACKUP" subroutine called by the subroutine of FIG. 168.
FIG. 169B is a continuation of the flow diagram of FIG. 169A.
FIG. 169C is a continuation of the flow diagram of FIG. 169B.
FIG. 169D is a continuation of the flow diagram of FIG. 169C.
FIG. 170A is a flow diagram of the "RESTORE" subroutine called by the subroutine of FIG. 160A.
FIG. 170B is a continuation of the flow diagram of FIG. 170A.
FIG. 170C is a continuation of the flow diagram of FIG. 170B.
FIG. 170D is a continuation of the flow diagram of FIG. 170C.
FIG. 170E is a continuation of the flow diagram of FIG. 170D.
FIG. 171 is a flow diagram of the "PROMPT.sub.-- DISKETTE" subroutine called by the subroutines of FIGS. 169A and 170A.
FIG. 172 is a flow diagram of the "SELECT.sub.-- BOARD" subroutine called by the subroutines of FIGS. 169A and 170E.
FIG. 173 is a flow diagram of the "ERASE.sub.-- BOARD" subroutine called by the subroutine of FIG. 168.
FIG. 174 is a flow diagram of the "DO.sub.-- CWKS" subroutine called by various subroutines of the invention.
FIG. 175 is a flow diagram of the "DO.sub.-- DESE" subroutine called by various subroutines of the present invention.
FIG. 176 is a flow diagram of the "DO.sub.-- IKEY" called by various subroutines of the present invention.
FIG. 177 is a flow diagram of the "DO.sub.-- LCDT" subroutine called by various subroutines of the present invention.
FIG. 178 is a flow diagram of the "DO.sub.-- LENT" subroutine called by various subroutines of the present invention.
FIG. 179 is a flow diagram of the "DO.sub.-- LKEY" subroutine called by various subroutines of the present invention.
FIG. 180 is a flow diagram of the "DO.sub.-- LMKT" subroutine called by various subroutines of the present invention.
FIG. 181 is a flow diagram of the "DO.sub.-- RESET" subroutine called by various subroutines of the present invention.
FIG. 182 is a flow diagram of the "DO.sub.-- RKEY" subroutine called by various subroutines of the present invention.
FIG. 183 is a flow diagram of the "DO.sub.-- SKEY" subroutine called by various subroutines of the present invention.
FIG. 184A is a flow diagram of the "DO.sub.-- STAT" subroutine called by various subroutines of the present invention.
FIG. 184B is a continuation of the subroutine of FIG. 184A.
FIG. 184C is a continuation of the subroutine of the flow diagram of FIG. 184B.
FIG. 184D is a continuation of the flow diagram of FIG. 184C.
FIG. 184E is a continuation of the flow diagram FIG. 184D.
FIG. 184F is a continuation of the flow diagram of FIG. 184D.
FIG. 185 is a flow diagram of the "PRO.sub.-- DEB" subroutine called by various subroutines of the present invention.
FIG. 186 is a flow diagram of the "CHKERR" subroutine called by the subroutine of FIG. 185.
FIG. 187 is a flow diagram of the "FIND.sub.-- TOK" subroutine called by the various subroutines of the present invention.
FIG. 188 is a flow diagram of the "NEXT.sub.-- TOK" subroutine called by the subroutine of FIG. 187.
FIG. 189 is a flow diagram of the "OPEN.sub.-- WINDOW" subroutine called by various subroutines of the present invention.
FIG. 190 is a flow diagram of the "CLOSE.sub.-- WINDOW" subroutine called by various subroutines of the present invention.
FIG. 191 is a flow diagram of the "CLOSE.sub.-- WINDOWS" subroutine called by various subroutines of the present invention.
FIG. 192 is a flow diagram of the "SHOW.sub.-- MODE" subroutine called by various subroutines of the present invention.
FIG. 193 is a flow diagram of the "CHANGE.sub.-- MODES" subroutine called by the subroutine of FIG. 194E.
FIG. 194A is a flow diagram of the "GETKEY" subroutine called by various subroutines of the present invention.
FIG. 194B is a continuation of the flow diagram of FIG. 194A.
FIG. 194C is a continuation of the flow diagram of FIG. 194B.
FIG. 194D is a continuation of the flow diagram of FIG. 194C.
FIG. 194E is a continuation of the flow diagram of FIG. 194D.
FIG. 195 is a flow diagram of subroutine "D" called by the subroutine of FIG. 143.
FIG. 196 is a flow diagram of subroutine "E" called by the subroutine of FIG. 143.
FIG. 197 is a flow diagram of subroutine "F" called by the subroutine of FIG. 143.
FIG. 198 is a flow diagram of subroutine "G" called by the subroutine of FIG. 143.
FIG. 199 is a flow diagram of subroutine "H" called by the subroutine of FIG. 143.
FIG. 200 is a flow diagram of subroutine "I" called by the subroutine of FIG. 143.
FIG. 201 is a flow diagram of subroutine "J" called by the subroutine of FIG. 143.
FIG. 202 is a flow diagram of subroutine "K" called by the subroutine of FIG. 143.
FIG. 203 is a flow diagram of subroutine "L" called by the subroutine of FIG. 143.
FIG. 204 is a flow diagram of subroutine "M" called by the subroutine of FIG. 143.
FIG. 205 is a flow diagram of subroutine "M" called by the subroutine of FIG. 143.
FIG. 206 is a flow diagram of subroutine "O" called by the subroutine of FIG. 143.
DETAILED DESCRIPTION OF THE INVENTION
Modern electronic fund transfer systems are increasingly configured as shared networks wherein a number of financial institutions are networked to a number of POS or ATM terminals through a network switch. A typical shared network using the DES encryption scheme is shown in FIG. 1. The DES algorithm encrypts electronic data, such as PIN information entered on a keypad or account number information taken from a magnetic strip on the back of a plastic card, by performing a complex series of processes which transform the original data into a completely unrecognizable string of characters.
The DES algorithm allows a large number of users to use a shared network by incorporating "Keys" which enable users to customize or personalize the algorithm for their own application. Decrypting data which has undergone DES algorithm requires knowledge of both the algorithm and the key. Attempting to decrypt the data with a different key or with no key at all would generate useless data. Only those parties having the specific encryption key are able to decrypt the data.
In a shared network using the DES algorithm, a card holder inserts a plastic card having magnetically encoded account information into a remote ATM terminal 102. The ATM terminal 102 reads the PIN information and the user enters a transaction request into the ATM terminal. This information is encrypted under the ATM terminal's encryption key by an associated encryption device 104 using key information unique to the encryption device 104. The encrypted PIN and transaction request is then transmitted to an acquiring institution 106 where the encrypted PIN and transaction request is translated by the encryption device 108. The translation process involves decrypting the PIN and transaction request using the PIN encryption key of the ATM and re-encrypting the PIN and transaction request under a network switch key. The translated PIN and transaction request is then transmitted to the network switch 110. The network switch 110 receives the transmission from the acquirer and translates the PIN and transaction request by decrypting the PIN and transaction request under the acquirer key and re-encrypting the key under the card issuer key with the encryption device 112. The translated PIN and transaction request is then sent to the issuer which receives the transmission from the switch and decrypts the PIN and transaction request with the encryption device 116 for verification. Once the PIN and transaction request is verified, the card issuer generates a verification message which is encrypted and re-routed through the network in the reverse direction.
Each of the encryption devices of the present invention employ a security module which retains all sensitive key information as well as the DES algorithm (along with any other encryption algorithm supported by the system). The following information is securely stored in the encryption devices of the present invention:
1) DES Algorithm: The DES algorithm is a well-known algorithm which is widely used in the data processing industry. The DES algorithm is used in conjunction with various DES keys to encrypt and decrypt data, such as customer's PINs or working keys, and to generate message authentication codes.
2) The Master File Key (MFK): This key is used to encrypt all keys that are to be stored locally outside the security module. When an externally stored key (cryptogram) is required during PIN processing, it is retrieved from its storage area, decrypted under the security module's MFK, and injected into the DES algorithm along with the data which is being processed.
3) The Key Storage Table: All of the various keys that a network link uses to encrypt or decrypt data (except MFK), perform the message authentication process and communicate keys to other network links may be stored on the Key Storage Table. Alternatively, a network link may choose to store its keys outside the security module. In this case, the keys are encrypted under the security module's Master File Key and stored as cryptograms.
The following DES keys are stored on the Key Storage File:
Key Exchange Key (KEK): Key Exchange Keys are used to encrypt working keys that are to be transmitted to another link in the network. For example, a switch may need to change a key that a transaction acquirer uses to encrypt PINs for transmission to the network switch 110. The network switch 110 normally would create the new key and inject it to its Key storage Table or immediately encrypt it under its MFK.
However, if the switch 110 sent the key to the transaction acquirer encrypted under the network switches MFK, the acquirer would require knowledge of the switch's MFK in order to translate the new key to encryption under its own MFK. As a general rule, the MFK is never divulged outside the particular network link because of its importance to a link's overall data security.
Therefore, a separate key is required to encrypt working keys for transmission between EFT network lines. This key is referred to as the Key Exchange Key. KEKs are held jointly by the two links between which DES keys are transmitted and are used solely for transmission of working keys. A network link may have a separate KEK for each type of working key, and will have a separate set of KEKs for each network link with which it has direct communication.
Pin Encryption Key (PEK): The Pin Encryption Key (PEK) is used to encrypt a PIN for transmission between links in the network. The PIN is encrypted initially at the ATM or POS terminal for transmission to the transaction acquirer. The acquirer uses another PEK to transmit the PIN to the network switch. The switch uses yet another PEK to transmit the PIN to the card issuer. PEKs are changed regularly, either automatically or manually to prevent the system from being compromised.
Pin Verification Key(PVK): There are various methods for generating customer PINs. One method involves running the customer's Personal Account Number (PAN) through the DES algorithm under a key referred to as the Pin Verification Key, and then paring the resultant number down to four or twelve digits to arrive at the customer PIN. When this method is used to generate the PIN, the same method is used to verify the PIN when it arrives in a transaction request. The PIN verifying institution decrypts the customer-entered PIN that arrived in the transaction request (PIN 1). Then it compares this PIN against the one created by running the PAN (also received in the transaction request) through the DES algorithm under the PVK (PIN2). If the two PINs match, the transaction request is valid.
Data Encryption Key (DEK): Some types of EFT transactions require both PIN information and other types of message data to be encrypted. The Data Encryption Key is used to encrypt data other than the PIN or another working key. The Data Encryption Key, like the PIN Encryption Key, must be held jointly by the two links in the network between which the encrypted data is to be transmitted.
Message Authentication Key (MAK): The Message authentication key is used to create a message authentication Code which is appended to the end of a message to enable the message receiver to verify that the message content has not been altered in any way between the message originator and the receiver.
The MAK can also be used to guard against other tampering schemes such as intercepting and removing messages between network links, injecting messages at some point between the terminal and the transaction authorizing institution, and recording and replaying previously approved transactions.
The present invention provides a user-friendly menu-driven front end for the selection of DES keys, periodic DES key changes as well as providing for the display of the operational status of the data encryption devices of the present invention. Since the knowledge of entire keys allow an individual access to the EFT network, the present invention provides for the split entry of keys wherein only parts of keys are known by any one individual. The present invention also allows the user to define the number of keyparts used and the random generation of keyparts.
A typical prior art transaction processor and data encryption device arrangement is shown in FIG. 2A. This arrangement is typical of an EFT processing node wherein a plurality of data encryption channels are supported. In the system 200, a host transaction processor 202 communicates with a plurality of discrete encryption devices 204, 206, 208, 210 through serial interfaces 212, 214, 216 and 218, respectively. Each of the encryption devices functions independent of the others. Therefore, if fault-tolerant operation is desired, control software for fault-tolerant operation must be resident on the EFT transaction processor. In operation, the transaction processor monitors each of the serial interfaces 212, 214, 216 and 218, and if one of the encryption devices fails, the transaction processor routes messages to an alternate encryption device. Therefore, any "in flight" transaction must be reprocessed by another device. Furthermore, since the transaction processor must monitor each encryption device for proper operation, processing overhead is increased and system performance is degraded.
FIG. 2B is a block diagram of an improved electronic fund transfer system 250B constructed in accordance with the teachings of the present invention. The present invention provides a multichannel encryption device which may be operated in a fault-tolerant mode. For example, encryption devices 254B and 256B may be coupled as fault-tolerant devices while encryption devices 258B and 260B may operate independently. Each of the encryption devices of the present invention may be operated either in a fault-tolerant mode or may be configured as a solo device.
In operation, fault tolerant encryption devices 254B and 256B communicate with transaction processor 252B over a single communication channel or serial interface 264B. The encryption devices 254B, 256B are grouped in a master/slave relationship wherein each encryption device is adapted to receive processing requests from the transaction processor and each encryption device processes the request in its entirety. Under normal operation the master encryption device will respond to the processing request from the transaction processor. However, if the master device does not respond to the host within a predetermined period of time, the slave encryption device responds, thus preventing any loss of critical information. The fault-tolerant operation of encryption devices 254B and 256B operate in a fault-tolerant manner which is totally transparent to the transaction processor 252B. Therefore, fault-tolerant data encryption device operation is provided without adding any processing overhead to the transaction processor while preventing the loss of "in-flight" data. Solo encryption devices 258B and 260B communicate with the transaction processor 252B through serial interfaces 266B, 268B in a manner which is similar to the operation of the discrete encryption devices of FIG. 2A. However, in one aspect of the present invention, the respective encryption devices are disposed in a single unit coupled by a bus to a display and control processor 262B. The display and control processor 262B provides access to each of the encryption devices 254B, 256B, 258B or 260B, etc., for entering and updating key information in the respective devices.
The present invention provides means for entering data in each of the encryption devices either individually or in groups. While the system of FIG. 2B is shown with four encryption devices, the present invention is adapted to support virtually any number of encryption devices.
In another aspect of the present invention, means are provided for locally displaying statistical data on the operation of each encryption device in the system. The encryption devices of the present invention are provided with a means of recording the number of failed transactions, verifications and other statistics over predefined intervals to provide information regarding system reliability, and performance. The display and control processor 262B periodically retrieves this information from each respective encryption device in the system and displays the statistical information from each encryption device to a user. If a particular encryption device exceeds predetermined statistical thresholds, a visual alarm is displayed to the user.
In another aspect of the present invention, communications between the transaction processor 252B and the display and control processor 262B are supported by a unique communications protocol particularly adapted for communicating in an EFT network. The communications protocol of the present invention provides for the transfer of key information among a plurality of data encryption devices over parallel or serial interfaces, as well as providing for the transfer, of system operating characteristics to a display and control processor.
In yet another aspect of the present invention, a fault-tolerant, power supply arrangement is provided, as shown in FIG. 2C. This system is identical to the system 250B with the addition of a fault-tolerant, power supply arrangement. In this aspect of the present invention, each of the elements of the system 250C are powered by a main power supply 272C. Additionally, an auxiliary power supply 274C is coupled to each of the respective encryption devices. Both power supplies are always active wherein the data encrypting devices normally receive power from the auxiliary power supply. However, if the auxiliary power supply fails, the data encryption boards derive power from the main power supply. Therefore, in cases where the auxiliary power supply fails, critical encryption functions are not affected. This feature also allows the Display and Control processor to be turned-off for servicing without affecting critical encryption functions.
FIG. 3A is a block diagram of a first embodiment of the data encryption system of the present invention. In the system 300A, encryption devices 302, 304, 306 and 308, communicate with a transaction processor through serial interfaces 310, 312, 314, and 316, respectively. In this aspect of the present invention, each of the encryption devices is adapted to operate independently of the other devices when communicating with a transaction processor.
The encryption devices 302, 304, 306 and 308 are further coupled to a parallel bus 320, which is also coupled between CPU 322, RAM 324, ROM 326, display 328, disk drive 330 and a proprietary parallel port interface 334. A keyboard 332 provides a means of entering alphanumeric or keyboard function data into CPU 332. In this embodiment of the present invention, a power supply 340 provides power to all devices in the system. The display and control processor may suitably comprise an 8085 microprocessor available from Intel. The RAM 324, ROM 326, display, 328 and disk drive 330 may be any of a number of well-known devices adapted for use with the 8085 microprocessor.
The operation of the system 300 is similar to most general purpose computers with the exception of the messages communicated between the CPU 332 and the encryption devices 302, 304, 306, and 308. The control software of the CPU 322 and the respective encryption devices of the present invention are discussed in detail below. In addition, the various keyboard and display functions provided by the present invention are discussed in detail below. The CPU 322, display 328 and keyboard 332 provide an efficient and user-friendly means of interfacing user inputs to the various encryption devices in the system. In addition, the system of the present invention provides a means of recording and displaying the operating statistics of the encryption devices as will be discussed in detail below.
The disk drive 330A and/or proprietary port 334 provide a means of backing up system software as well as providing an external source of data for updating system software. Those skilled in the art will appreciate that the disk drive may be omitted in systems offering a parallel port interface or vice versa.
Referring now to FIG. 3B, an alternate embodiment of the present invention is shown. The system 300B incorporates all of the elements of the system 300A. However, in this aspect of the present invention, encryption devices 302B and 304B are coupled in a fault-tolerant arrangement wherein encryption device 302B functions as a master and encryption device 304B functions as a slave. In this aspect of the present invention, encryption devices 302B and 304B communicate through a single serial interface 310B with an associated transaction processor. In this configuration, encryption devices 302B and 304B receive processing requests from a transaction processor and each encryption device processes the request in its entirety. The slave encryption device then determines whether the master encryption device 302B responds within a predetermined period of time and if the master encryption device does not respond, the slave encryption device 304B responds to the transaction processor. The present invention provides the capability of supporting a number of master/slave pairs and further supports encryption devices operating in a solo mode along with master/slave pairs in the same system.
FIG. 3C is an alternate embodiment of the encryption system of FIG. 3A. The system 300C is similar to the system 300A. However, in this aspect of the present invention, an auxiliary power supply 342 is provided. In the system 300C, the main power supply provides power to all the components in the system. In addition, an auxiliary power supply 342 is coupled to the respective encryption devices 302, 304, 306 and 308. In normal operation, the display and control circuitry derive power from main power supply and the data encryption devices derive power from the auxiliary power supply. However, if the auxiliary power supply fails, the respective encryption devices derive power from the main power supply. Therefore, the encryption devices remain operational, thus preserving critical encryption functions. This feature is also useful when maintenance of the display or input system is required, as the main power supply may be shut off for servicing without disturbing the operation of the encryption devices.
FIG. 3D is a block diagram of an alternate embodiment of the system of FIG. 3B. The system 300D is similar to the system 300B. However, in the system 300D, fault-tolerant encryption devices 302D and 304D are provided as well as the fault-tolerant power supply arrangement provided by power supplies 340 and 342. The other function aspects of the system 300D are identical to the system configurations described above.
FIG. 4A is a schematic diagram of the encryption device of the present invention. The data encryption device 400 is adapted for implementation on a single printed circuit board and a fully configured encryption device board is herein below referred to as a data encryption board (DEB). The data encryption device 400 is implemented on the microcomputer 402, which is preferably a DS5000 microcomputer available from Dallas Semiconductor. The DS5000 microcomputer is provided with on-board ROM and RAM as well as being provided with battery backed-up RAM for nonvolatile storage of data. The DS5000 microcomputer is further provided with on-board data encryption functions. While the discussion below refers to a specific implementation of a data encryption device using the DS5000 microcomputer, those skilled in the art will appreciate that other microprocessor-based systems could be substituted therefor without departing from the teachings of the present invention.
Power is provided to the data encryption device 400 through lines 404 and 406 which are coupled to the main power supply 340 and the auxiliary power supply 342, respectively. Power supply terminal 404 is coupled to the positive voltage input terminal of voltage doubler 408 through diode 410. Power supply terminal 406 is coupled to the positive voltage input terminal of voltage doubler 408 through diode 412. The ground terminal of voltage doubler 408 is coupled to terminal 414. Under normal operation, diode 412 is reverse-biased and power for the voltage doubler 408 is derived through terminal 404. However, if power is removed from terminal 404, diode 412 becomes forward-biased and power is derived through terminal 406. The voltage doubler 408 may suitably comprise a MAX680 available from MAXIM. The microcomputer 402 is coupled to the voltage doubler 408 in accordance with the manufacturer's specification for these components.
The data encryption device 400 communicates with an associated transaction processor through the RS232 connector 416 wherein the "RX" RS-232 signal is coupled to terminal 418, the "CTS" RS-232 signal is coupled to terminal 420, the "TX" RS-232 signal is coupled to terminal 422, and the "RTS" RS-232 signal is coupled to terminal 424. Terminals 418 and 420 are coupled to pins 10 and 8 of the DS5000 through RS232 receivers 426 and 428, respectively. Pin of the DS5000 is coupled to terminal 422 through inverter 430. Pins 7 and 4 of the DS5000 are coupled to the inputs of a two-input NAND gate 432 wherein the output of NAND gate 424 is coupled to terminal 424.
The data encryption device 400 is further provided with a fault-tolerant interface connector 434 wherein terminals 436 and 438 are coupled to terminals 418 and 422, respectively; terminal 443 is coupled to pin 5 of the DS5000: terminal 442 is coupled to pin 15 of the DS5000; and terminal 444 is coupled to pin 14 of the DS5000, wherein terminal 442 is coupled to a master watchdog signal and terminal 444 is coupled to a slave watchdog signal. The master/slave device designation is controlled by switch 436 which is coupled between pins 4 and 5 of the DS5000. Master and slave devices and the master and slave watchdog signals are discussed in further detail below.
The address lines 440 of microcomputer 402 are coupled to the bus 320 through address decoder 442 which comprises a comparator 444 and latch 446 coupled in a well-known configuration. The switches 51-56 are used to control the address of the DEB. For example, if switch 2 is closed, the board designation is board 2. In operation, the DEB first reads the switch to determine board number. The DEB monitor program then writes the DEB address to latch 446 and latches the data in latch 446 by strobing pin 2 of the DS5000. The address lines are then pulled high by the DS5000.
The data encryption device 400 is provided with a tamper switch 448 which is coupled between pins 13 and 21 of the DS5000 wherein pin 21 of the DS5000 corresponds to an address input as well as a tamper switch output of the DS5000. The tamper switch 438 provides a method of detecting whether an adversary is trying to gain access to the security module of the data encryption device 400 and, if so, the tamper switch 438 is activated and the contents of the memory in the DS5000 are automatically erased. In operation, the tamper switch is normally closed, thus holding the INIT1 input of the DS5000 high and if the tamper switch opens, INIT1 goes low and the DS5000 erases the data stored therein.
The data lines 441 of microcomputer 402 are coupled to bus 320 through a bidirectional first-in/first-out (BIFIFO) buffer 442. The BIFIFO 450 is of the type 67C4701 available from Advanced Micro Devices. The BIFIFO is a bidirectional first-in/first-out 512 byte buffer, which is coupled to the DS5000 in accordance with the manufacturer's instructions.
Data flow in and out of the DEB 400 is controlled by the I/O.sub.-- R/W logic 452, which comprises OR gates 454, 458, 456, and 462 and exclusive-OR gate 462. One input of OR gate 454 is coupled to the address enable line of bus 320. The least significant bit of the bus (line A0) is coupled to one input of exclusive-OR gate 462. The other input of exclusive-OR is coupled to pin 6 of the DS5000, which controls whether the BIFIFO responds to the bit A0 or is enabled to read a slave device. One input of OR gate 458 is coupled to the bus I/O write signal. The other input of OR gate 458 is coupled to the output of OR gate 454. One input of OR gate 456 is coupled to the bus I/O read signal. The other input of OR gate 456 is coupled to the output of OR gate 454. The inputs of OR gate 460 are coupled to the output of OR gate 456 and exclusive-OR gate 462, respectively. The output of OR gate 458 is coupled to the write/enable input of BIFIFO 450. The output of OR gate of the read enable input of BIFIFO 450. This arrangement allows for asyncronous reading and writing from the BIFIFO without DS5000 interaction.
The clock signal of the DS5000 is generated internally and the frequency of the clock signal is controlled by crystal 470, which is coupled to pins 18 and 19 of the DS5000.
Referring now to FIG. 4B, the fault-tolerant data encryption device arrangement of the present invention is shown in schematic form. This aspect of the present invention incorporates two identical data encryption devices 400M and 400S wherein the master/slave switch 436M of data encryption device 400M is set in a closed position to indicate the encryption device 400M is a master and wherein the master/slave switch of data encryption device 400S is set in an open position to indicate the encryption device 400S is a slave. In addition, the fault-tolerant connectors 434M and 434S are coupled in parallel. The RS232 connector 416M is coupled to the serial interface of an associated transaction processor, and the RS232 connector 416S may be coupled to an associated device.
In operation, the master and slave watchdog timer signals are generated internally in the microcomputers 402M and 402S. The respective watchdog timer signals are periodic signals which reset an internal timer in the microcomputers 402M and 402S to indicate that the system is functioning normally. The loss of either the master watchdog timer signal or the slave watchdog timer signal indicates that the respective master or slave microcomputer 402M or 402S has failed. The signal present on terminals 440M and 440S determines whether the master data encryption device 402M or slave encryption device 402S responds to a processing request from the associated transaction processor. When the output select signal is "high", the output of microcomputer 402M is enabled through transmitter 432M. The microcomputer 402S is continually monitoring the master watchdog reset signal present on terminal 442M. If the slave microcomputer 402B determines the master has failed, the slave microcomputer 402S disables the master's output by forcing the OSE signal low, thus turning off transmitters 430 and 432.
FIGS. 5-50 are flow diagrams which describe the operation of the software that controls the operation of the data encryption devices (DEBS) of the present invention. The data encryption device control software is divided into two sections the monitor program and the application program.
The Monitor is a program that provides many application program dependent services These services include system initialization, interrupt servicing, application program loading, and watchdog timing. Moreover, the Monitor program is designed to operate in a fault-tolerant mode.
In the fault-tolerant mode, two DEBs operate in parallel. One DEB is designated as the master and the other DEB is designated as a slave by setting a switch on the respective DEBs. Both DEBs have the same bus address so that they receive the same data input through the BIFIFO. Similarly, both DEBs receive the same serial input from an associated transaction processor. Both DEBs are loaded with the same Monitor and Application programs.
While operating in a fault tolerant mode, the programs on both DEBs process all input data. The Monitor on the slave DEB, however, inhibits its BIFIFO and serial output unless the slave detects that the master is malfunctioning.
The slave DEB detects a malfunction in the master DEB as follows. The DEBs periodically send a watchdog reset signal to each other. The transmit interrupt routines of the slave Monitor program checks whether the master DEB has sent a signal since the last transmit interrupt occurred. If the master has not signaled, then the Monitor program on the slave DEB enables its outputs. Similarly, if the program monitor program of the master DEB determines that it is malfunctioning then the master DEB shuts down.
The Monitor and the Application programs are designed to detect the occurrence of certain hardware or software malfunctions. To ensure the integrity of its processing, the DEB shuts down when a program detects a problem. The Monitor and Application programs use the Watchdog Timer of the DS5000 to accomplish this detection. Upon initialization, the Monitor sets the Watchdog Timer. Both the Monitor and Application programs are designed to reset the Watchdog Timer periodically to prevent a timeout. If the Watchdog Timer does timeout because not reset within a prescribed period (e.g., the Application program in an infinite loop), then the DS5000 performs a reset. Upon reset, the DS5000 jumps to a predefined program location in the Monitor. If the master Monitor program determines that reset was due to problems in the software or hardware, then the Monitor invokes the stop mode of the DS5000 to effect a master DEB shutdown.
In application loading, the Monitor receives a signal from the BIFIFO, through the mailbox interrupt of the DS5000, indicating that a new Application program is to be downloaded. The Monitor clears the Appl.sub.-- Present flag, to indicate that no Application program is in memory. The Monitor program prepares to receive the new Application program through the BIFIFO. The Monitor loads the Application program into the application area of DEB memory. When the Monitor has received the entire application program, the Monitor program sets the Appl.sub.-- Present flag and jumps to the Appl.sub.-- Start location.
The Monitor comprises several major routines. These routines include the Initial Program Load (IPL), the serial port interrupt routine, the BIFIFO (parallel port) interrupt routine, the power fail interrupt routine, the tamper switch interrupt routine, the load application routine, and the Watchdog Timer routine.
FIGS. 5A and 5B are flow diagrams of the Monitor program that are executed when the DS5000 resets. The Monitor program determines whether the reset was due to a power on condition, or a Watchdog Timer timeout. If the reset is due to a power on condition then the Monitor program performs a cold boot, otherwise it performs a warm boot. During a cold boot, the Monitor program performs diagnostics and initializes the I/O devices, the timers, and the interrupt routines. During a warm boot, power has not been lost since the last cold boot. Therefore, the devices, timers, and routines are already initialized.
Item 504 represents the DS5000 reset entry point. As indicated by entry points 500 and 502, the reset occurs at power up or when the Watchdog Timer times out. The DS5000 resets by starting executing at location memory 0000H.
In subroutine block 508, the Monitor calls the F.sub.-- INIT1 subroutine, which is explained in detail below. Decision 512 then determines if the DS5000 reset was caused by a power on reset as indicated by the Power Control Register. If so, the Monitor program calls subroutine 532. Otherwise, the Monitor continues at item 506.
Referring now to FIG. 5B, subroutine 532 comprises the cold boot initialization routine, F.sub.-- INIT2. When completed, item 534 performs diagnostic tests, such as a memory check, to ensure that the hardware is functioning properly. During the diagnostic tests of item 534, the Monitor calls the watchdog subroutine, F.sub.-- WATCHDOG, which resets the Watchdog Timer and sends reset signals to the parallel master or slave DEB. The F.sub.-- WATCHDOG subroutine is described in more detail below. Decision 536 determines whether the diagnostics indicate that the hardware is functioning correctly. If so, Decision 538 determines whether the Appl.sub.-- Present flag is set. Otherwise, the Monitor Decision loops to subroutine 532.
If decision 538 determines that the Appl.sub.-- Present flag is set, an Application program is in memory and the Monitor program jumps to the Appl.sub.-- Start routine of FIG. 14A. Otherwise, the Monitor loops to item 534. The Monitor thus performs diagnostics until an Application program is loaded.
When invoked, the Appl.sub.-- Start routine executes the application at the Appl.sub.-- Start address. Preferably, the Monitor program resides in a memory location less than memory location 0800H, the Application program resides in memory locations 0800H through 7FFFH, and the Data resides in memory locations 8000H and above. The Appl.sub.-- Start address is suitably 0802H.
Referring again to FIG. 5A, in item 506 the Monitor sets the Reset.sub.-- Flag. The Reset.sub.-- Flag indicates that a Watchdog Timer timeout occurred. Decision 518 determines whether the Timeout Register is set. If so, the Monitor was in the process of waiting for a message when the Watchdog Timer timeout occurred, which reset the DS5000, and the Monitor continues to decision 538 in FIG. 5B. Otherwise, there is a software or hardware problem and the Monitor continues at item 522.
In item 522, the Monitor increments the AOW counter. The AOW counter keeps count of the number of software or hardware errors that are detected as a result of the Watchdog Timer timeout. Decision 528 determines whether the Master.sub.-- Flag is set, which is a diagnostic switch on the data encryption board. If so, then the Monitor program causes the DS5000 to enter the stop mode to effect a shutdown. Otherwise, the Monitor program is operating as a slave and the Monitor program loops to item 504.
The Monitor includes several subroutines and interrupt routines, which are described hereinbelow.
FIG. 6 is a flow diagram of the F.sub.-- INIT1 subroutine, which performs warm boot initialization of the DEB. This subroutine initializes the bus address for the BIFIFO and internal pointers and timers. When initialized, item 602 initializes the stack pointer of the DS5000. Item 604 then enables the DEB Watchdog Timer. In Item 606, the Monitor program reads the bus address of the parallel port as indicated by the switches coupled to the DEB address decoder circuitry 442. Item 608 then enables the address register associated with the DS5000. This latches the bus address into the address register. The BIFIFO is thereby setup to respond to the bus address stored in the user programmable switches. Subroutine F.sub.-- INIT1 then returns.
FIG. 7 is a flow diagram of the F.sub.-- INIT2 subroutine, which performs cold boot initialization of a DEB. This subroutine initializes timers, I/O ports, and interrupt routines. When invoked, item 702 sets a random key generation timer for use by the Application program, and the baud rate timer. Item 704 then sets the timer for miscellaneous functions. Program control then passes to item 706, which initializes the serial I/O buffers by setting the head and tail buffer pointers for the I/O ring buffers. The operation of the serial I/O and the use of ring buffers is explained further below.
Item 708 initializes the DEB serial port communications parameters. These parameters include the baud rate, stop bits, and parity for the DEB serial port. Item 710 initializes the BIFIFO to receive data in a FIFO mode. Item 712, then transmits a message to the BIFIFO to indicate that the DEB is ready for communication with an associated transaction processor. When complete, item 714 sets the interrupt vector for the tamper switch to point to the DEB tamper switch interrupt routine. The tamper switch interrupt routine is described in more detail below. Program control then passes to item 716, which enables the Power Fail Warning interrupt so that an interrupt will occur at the start of a power failure. This interrupt allows the Monitor enough time perform an orderly shutdown and transmit a message indicating a power fail shutdown. The Power Fail interrupt routine is described in further detail below. The F.sub.-- INIT2 subroutine then returns.
FIG. 8A is a flow diagram of the SERIAL.sub.-- INTERRUPT routine, which is invoked whenever data is received by a DEB. The DS5000 is provided with an on-chip full duplex serial I/O port, which functions like a universal asynchronous transmitter/receiver (UART). The Monitor program provides an interrupt routine for processing serial I/O interrupts. The Monitor and Application programs transmit data to, and receive data from, the SERIAL.sub.-- INTERRUPT routine through communications buffers of the respective DEBS of the present invention.
The Monitor program maintains two serial I/O buffers: one for inputs and the other for outputs (see FIG. 8B). The SERIAL.sub.-- INTERRUPT routine stores the data it receives in a serial input buffer, and retrieves the data it transmits from a serial output buffer. Analogously, the Monitor and Application programs retrieve data from serial input buffers, and store data in serial output buffers.
The SERIAL.sub.-- INTERRUPT routine is entered at decision 802 when a serial I/O port interrupt occurs. A serial interrupt occurs whenever data is received at a serial port of a DEB. In other words, Serial I/O port interrupts occur when the port completes the reception of a byte of data (receive interrupt) or when the port completes the transmission of a byte of data (transmit interrupt). When a serial interrupt occurs, decision 802 determines whether the serial interrupt is a transmit interrupt. If so, then the routine continues to decision 804. Otherwise the routine proceeds to item 816.
Flow diagram elements 804 through 814 represent the processing of a transmit interrupt. If the Monitor is in slave mode (Master.sub.-- Flag is clear), then the routine will not actually transmit the data unless the master DEB is malfunctioning. If the serial interrupt routine of the slave DEB determines that the TO counter of the DS5000 is zero, then the serial interrupt of the slave routine assumes the master DEB is malfunctioning and thus enables the slave's DEB output. If decision 804 determines the DEB is in master mode, the routine continues to decision 812. Otherwise the routine continues to decision 806.
If decision 806 determines that the T0 counter is greater than zero, then the master DEB is functioning and the routine continues to item 808. Otherwise the routine continues to item 810. Item 808 resets the T0 counter so that a subsequent signal from the master DEB will make the master counter nonzero.
In item 810, the SERIAL.sub.-- INTERRUPT routine in slave mode with a malfunctioning master DEB enables its output to effect fault-tolerant operation.
If the result of decision 802 is negative, the SERIAL.sub.-- INTERRUPT routine retrieves the next byte to be transmitted from the serial output buffer and updates the buffer pointers. The strings stored in the serial output buffer are delimited by an end of string character (e.g., a null character). If decision 812 determines that the next byte is the end of string character, then the entire string has to be transmitted and the routine proceeds to retire 822. Otherwise the routine continues with item 814. Item 814 outputs the next byte to the serial I/O port and proceeds to item 822.
Items 816 through 820 represent the processing of receive interrupt, which involve the storing of the received byte in the serial input buffer. Item 816 reads a byte from the serial I/O port. Item 818 stores the byte in the DEB serial input buffer. Program control then passes to item 820, which sets the Serial.sub.-- Flag, which indicates to the Monitor or Application programs that data has been received and has been loaded in the serial input buffer. The routine continues to return 822.
In block 822, the routine completes the interrupt processing and returns from the interrupt.
FIGS. 9, 10A and 10B are a flow diagrams of the PARALLEL.sub.-- BUS.sub.-- INTERRUPT routine of the present invention. The respective DEBs of the present invention utilize bi-directional FIFO devices (BIFIFOs). A BIFIFO provides parallel communications with a predefined bus interface. In accordance with the teachings of the present invention, a BIFIFO sends an interrupt request to the DS5000 whenever the status of the BIFIFO changes. In particular, the BIFIFO generates an interrupt when data is received from the predefined bus or is transmitted to the predefined bus. The Monitor and Application programs transmit data directly to and receive data directly from the BIFIFO and do not use communications buffers in the DS5000 memory. The FIFOs of the BIFIFO function directly as communication buffers.
The PARALLEL.sub.-- BUS.sub.-- INTERRUPT routine also supports the downloading of an Application program from the bus. This routine enters a special processing mode while a new application is being downloaded. The Display and Control Processor initiates a download through the 8-bit mailbox of the DS5000 supported through the BIFIFO. The DS5000 goes into the special processing mode when it receives a mailbox message. In this special processing mode, the routine without using interrupts retrieves the application program from the DEB BIFIFO as it is transmitted by the Display and Control Processor. The routine stores the application in the Data Memory of the DS5000. When the transmission is complete, the routine partitions memory so that the downloaded program is part of Program Memory. The routine then effects a warm boot by preferably jumping to location 0000H.
This interrupt routine is typically entered at decision 902 when a parallel I/O port interrupt occurs. Parallel I/O port interrupts occur when the port completes the reception of a byte of data (receive interrupt) and when the port completes the transmission of a byte of data (transmit interrupt). Decision 902 determines whether the interrupt is a transmit interrupt. If so, the routine continues to decision 906. Otherwise the routine continues to decision 920.
Decisions 906 and 908 and items 912 and 914 represent the processing of a bus transmit interrupt. The processing in these blocks is analogous to the processing that is represented by decisions 804 and 806 and items 808 and 810 of the SERIAL.sub.-- INTERRUPT routine of FIG. 8A. Because the communications buffers are located on the BIFIFO, this interrupt routine does not actually send transmit data to the BIFIFO because the Monitor and the Application programs place the data directly in the BIFIFO.
Decision 920 and items 924-926 represent the processing of a receive interrupt. The routine 900 first determines whether a mailbox interrupt has occurred. A mailbox interrupt indicates that a new application program is to be downloaded. If decision 920 interrupt is a mailbox interrupt, then a new application program is to be downloaded and the routine continues at block 926, otherwise the routine continues at block 924.
In item 926, the routine enters the special processing mode by clearing the Appl.sub.-- Present flag and jumping to the load application routine, F.sub.-- LOADAPP, shown in FIGS. 10A and 10B. The Appl.sub.-- Present flag indicates whether or not an application is present in Program Memory. The F.sub.-- LOADAPP routine does not perform a typical subroutine return. Rather, the subroutine effects a warm boot after it downloads the program.
The routine process a non-mailbox interrupt in item 924. In item 924, the routine sets the Parallel.sub.-- Flag, which indicates that the data is available in the BIFIFO.
In item 916, the routine completes the interrupt processing by returning from the BUS.sub.-- INTERRUPT.
FIGS. 10A and 10B represent the F.sub.-- LOADAPP routine. This routine downloads an application program from the bus through the BIFIFO. The DS5000 cannot write to Program Memory. Consequently, this routine stores the program in Data Memory. Upon completion of the download, the routine partitions memory so that the downloaded program resides in Program Memory.
This routine calculates a checksum of the downloaded program. The checksum is a byte which represents the Exclusive-OR of each byte in the program. Upon completion of the download, the routine transmits the checksum value to the bus. If the system that sent the program determines that the checksum value is incorrect, then an error occurred in transmission and the system would typically retransmit the application program.
Referring to FIG. 10A, in block 1002, the routine partitions the Data Memory space to include the area in which the Application program is to be loaded. This partitioning is necessary because the DS5000 prohibits writing to Program Memory. In item 1004, the routine sets the Load.sub.-- Pointer to point to the location, within the Data Memory space, at which the application program is to be loaded. In item 1006, the routine clears the checksum value in preparation of calculating the checksum of the downloaded program. Item 1008 then reads the BIFIFO status register.
Referring FIG. 10B, the display and control processor 322 signifies that the download is complete by sending a message to the BIFIFO mailbox. The routine loops checking whether the input FIFO is empty. If the input FIFO is empty and if a mailbox message is present, then the download is complete. Otherwise, the routine loops retrieving data from the BIFIFO and storing the data in memory.
In process 1051, the routine calls F.sub.-- WATCHDOG to signal the parallel DEB that the DEB performing the download is not malfunctioning. Decision 1052 determines whether input data is available at the BIFIFO. If so, the routine downloads the data by continuing at item 1054. Otherwise the download may be complete and the routine continues at item 1062.
In item 1054, the routine reads a byte from the BIFIFO. In item 1056, the routine sets the checksum value to the exclusive-OR of the checksum value and the byte. In item 1058, the routine stores the byte at the location pointed to by the Load.sub.-- Pointer. In item 1060, the routine increments the Load.sub.-- Pointer and loops to process 1051 to retrieve the next byte in the program.
In decision 1064, the routine determines if the download is complete. If the mailbox flag is set, then the application program download is complete and the routine continues at block 1066. Otherwise the routine continues at process 1051 to retrieve the next byte in the program.
In items 1066 through 1074, the routine completes the download processing by partitioning memory, sending the checksum to the bus, and effecting a warm boot. In item 1066, the routine reads the mailbox to clear the mailbox. In item 1068, the routine partitions memory so that the Application program is in Program Memory. In item 1070, the routine sets the Appl.sub.-- Present flag to indicate that an application is in the DS5000 memory. In item 1072, the routine transmits the checksum value to the bus through the BIFIFO mailbox. In block 1074, the routine has completed the download and effects a warm boot by jumping to 0000H.
FIG. 11 is a flow diagram of the POWERFAIL.sub.-- INTERRUPT routine. The DS5000 detects when its input voltage drops below a threshold value and generates a Power Fail Warning interrupt. The POWERFAIL.sub.-- INTERRUPT routine processes this interrupt.
This routine sends a message out the serial I/O port and sets the DS5000 to stop mode. In item 1102, the routine disables all interrupts. I/O step 1104, then outputs the power fail message to the serial I/O port. In block 1106, the routine puts the DS5000 in the stop mode.
FIG. 12 is a flow diagram of the TAMPER.sub.-- SWITCH.sub.-- INTERRUPT routine. The DS5000 generates an interrupt when the contents of its RAM are being tampered with, as when the encapsulation module has been broken. When this occurs, the tamper switch 436 opens and interrupts the DS5000. This interrupt is referred to as the tamper switch interrupt. The TAMPER.sub.-- SWITCH.sub.-- INTERRUPT routine processes such an interrupt. When the tamper switch interrupt occurs, the routine zeros out the application program and data portions of memory. In item 1202, the routine partitions Data Memory to include the portion of memory that contains the Application program. In block item 1204, the routine sets a pointer to the first location to be filled with zeros. In item 1206, the routine writes a zero to the location indicated by the pointer. Decision 1208 determines whether the pointer is equal to FFFFH. If so, the routine has filled the entire Application program and data portions with zeros and the routine continues at 1212. Otherwise the routine continues at item 1210. In item 1210, the routine increments the pointer and loops to item 1206. In block 1212, the routine puts the DS5000 in stop mode to effect a shutdown.
FIG. 13 is a flow diagram of the F.sub.-- WATCHDOG subroutine. The F.sub.-- WATCHDOG subroutine performs two functions. First, the subroutine resets the Watchdog Timer to prevent a timeout. Second, the subroutine outputs a signal to signify that the DEB is functioning properly. In the fault-tolerant mode, the signal triggers a counter in the slave DEB. If the slave DEB determines that the master DEB is not signaling, that is, malfunctioning, then the slave DEB enables its outputs to effect fault tolerance. The Monitor and Application programs call this subroutine throughout their processing.
Referring to FIG. 13, in items 1302, 1304, and 1306, the subroutine resets the Watchdog Timer. The resetting of the Watchdog Timer occurs through the Timed Access Register of the DS5000. In item 1304, the subroutine loads the Timed Access Register with AAH. In item 1306, the subroutine loads the Timed Access Register with 55H. In item 1306, the subroutine sets the Reset Watch-Timer bit of the Interrupt Priority Register to effect the reset.
Decision 1310 and item 1312 through 1320 represent the signaling to the slave DEB. If the DEB is a master, then the subroutine outputs its signal on the T0 line of microcomputer 402, which is coupled to terminal 442. If the DEB is a slave, then the subroutine outputs its signal on the T1 line of microcomputer 402 which is coupled to terminal 404. In decision 1310, if the DEB is in master mode (Master.sub.-- Flag is set), then the subroutine continues at item 1312. Otherwise the subroutine continues at item 1316.
In items 1312 and 1314, the subroutine sets the T0 line and then clears the T0 line. This effects the sending of signal to the slave. The subroutine then continues at block 1320.
In items 1316 and 1318, the subroutine sets the T1 line and then clears the T1 line. This effects the sending of a signal to the master DEB. The subroutine then continues at block 1320.
In block 1320, the resetting of the Watchdog Timer and the signaling of the parallel DEB is complete and the subroutine returns.
The Application receives messages from either the parallel or serial ports. The Application reads in an entire message and then processes the message. (The Application processes a message containing the STAT function differently.)
FIGS. 14A and 14B are flow diagrams of the main processing loop of the Application. The Application loops waiting for data input from either the parallel or the serial I/O ports. When data is received, the Application then proceeds to process the data. In decision 1404, if the Reset.sub.-- Flag is set, then a Watchdog Timer reset caused the Application to be restarted and the Application continues at item 1406, else the Application continues at subroutine 1418.
In item 1406, the Application increments ZP.sub.-- Value[3..6], which contains the number of timeout errors. In I/O block 1408, the Application outputs an error message to the serial I/O port and continues at subroutine 1416.
In subroutine 1418, the Application calls PCHKSUM, which calculates the checksum of the Application Program and stores the result in ZC.sub.-- Value, which contains the program checksum. PCHKSUM calls F.sub.-- WATCHDOG. The application continues at subroutine 1416.
In subroutine 1416, the Application calls the F.sub.-- WATCHDOG subroutine. In decision 1414, if the Parallel.sub.-- Flag is set, then data has been received from the parallel port and the Application processes the data by continuing at item 1508, otherwise the Application continues to decision 1412. In decision 1412, if the Serial.sub.-- Flag is set, then data has been received from the serial port and the Application processes the data by continuing at item 1518, otherwise no data has been received and the Application loops to subroutine 1416.
The Main.sub.-- Loop entry point at item 1420 represents the point to which the Application returns upon completing the processing of a message. Blocks 1420 through 1426, reset flags and pointers. Item 1420 clears the Status.sub.-- Flag. In decision 1422, if the Activity.sub.-- Flag is set, then item 1424 restores the pointers to the parallel, otherwise item 1426 restores the pointers to the serial buffer. The Application then continues at subroutine 1416.
FIG. 15 and FIGS. 16A and 16B are flow diagrams of the loop that receives a message and prepares the Application data structures for processing the message. The Application processes an entire message from the interrupting port, serial or parallel, before servicing any messages on the other port. The Application initializes the input data pointers based upon the interrupting port. Items 1518 through 1522 represent the setup when the serial port interrupts, and items 1508 through 1512 represent the setup when the parallel port interrupts. The Input.sub.-- Pointer and Output.sub.-- Pointer variables are initialized. Each time the application inputs or outputs data during message processing it uses these pointers, which point to the serial or parallel port buffers. In item 1513, the Application enables the Timer Interrupt based upon the value in BW.sub.-- Value.
FIGS. 16A and 16B are flow diagrams of the token processing loop. In subroutine 1602, the Application calls F.sub.-- READ, which returns one character from the input buffer. In decision 1604, if the character is equal to "[", then the start of a message is encountered and the Application continues at item 1608, else the Application continues in block 1606 to report an error at FIG. 50. In item 1608, the Application clears the Error.sub.-- Flag. In item 1610, the Application increments ZD.sub.-- Value[3..6], which contains the total number of message requests.
The tokenized message format of the present invention is shown in more detail in Appendix 1. Appendix 1 lists the various combinations of tokens which are utilized by the present invention along with the data fields associated with the tokens.
In blocks 1612 through 1620, the Application reads in a single token and stores the data in TOK[0] for processing when the end of message character ("]") is detected. The Application contains a token input routine for each token. These routines are logically grouped based upon the first character in the token (A, B, or Z).
FIG. 18A represents the grouping of the routines for tokens beginning with an "A." The Application contains a table for each of three token groupings, "A", "B", and "Z." Referring to FIG. 17A, when the Application identifies an "A" token, the Application continues at item 1702. In item 1702, the Application reads in the second character of the token and stores it in Tok[1]. The Application uses this second character as an index into the A.sub.-- Table, FIG. 18A. The A.sub.-- Table contains a series of jump instructions to token routines. For example, the A.sub.-- Table contains as its first entry a jump to the routine named SELAA, which is the AA-token routine. The second entry contains a jump to the routine named ERROR, which is an error processing routine--no AB-token is valid. The Application processes the "B" and "Z" tokens in a similar manner. Each of the token input routines jump to the Token.sub.-- Loop entry point of FIG. 16 when complete.
The Token Input Table shows the length of each token input and the allowable character type. The type "014 F" means any hexadecimal character is valid. The type "0-9" means any decimal character is valid. The type "x" means any character is valid. The type "BDIII" means the token is followed by the characters "BD" and one to three decimal digits.
The token input routines store the token input data as shown in the Token Storage Table. The description field indicates the processing that the token input routine performs before the value is stored in the Table. For example, the AA-Token input routine decrypts the AA-Input using the MFK with a modifier of 1. The term AA.sub.-- Input refers to the data that is input with the AA-Token. The routine stores the result in AA.sub.-- Value. The AD-token input routine store the input value in AD.sub.-- Value without decrypting the value.
The token input routines also support the Key.sub.-- Table processing. The Application maintains a table of keys, called Key.sub.-- Table. Many of the token inputs are keys, which are 16 hexadecimal digits. Alternatively, the token inputs can be three to five digits. The input "BD" followed by up to three decimal digits indicates that a key value is to be retrieved from the Key.sub.-- Table indexed by the decimal digits. This retrieved key is stored in the corresponding token value. For example, the AK-token can transmit either a 16-digit key or a "BD" followed by a 3-digit index into the Key.sub.-- Table. If the AK-token input routine detects a "BD", then it uses the next three digits as in index into the Key.sub.-- Table. The routine stores that Key.sub.-- Table entry at AK.sub.-- Value.
In a preferred embodiment, the data is stored in the Token Storage Table in packed format. The input data is received in ASCII format. However, the ASCII characters generally represent hexadecimal digits. In packed format, each two hexadecimal digits are stored in each byte. Analogously, the packed data is unpacked and converted to ASCII format before the data is output.
The Application processes the input for the AO-token specially, when the function "STAT" is received. The STAT function means that the Application is to transmit status information.
Referring to FIG. 19, in item 1902, the routine increments ZK.sub.-- Value[3..6], which contains a count of control functions. The brackets indicate that bytes 3 through 6 of the value is used. In subroutine 1904, the routine calls F.sub.-- START.sub.-- MSG, which outputs the "[AOxxxx;" string. The routine then continues at Token.sub.-- Loop to process the next token.
Each of the tokens following the AO-token with the STAT function are Z-tokens. The Z-tokens indicate the status information the Application is to output. Referring to FIG. 20A, in item 2002, the ZA-token input routine outputs "ZA0". Throughout the description of the Application, the I/O blocks that contain the "Output" command implicitly append a ";", a token delimiter at the end of the output string. The routine then continues at Token.sub.-- Loop.
Referring to FIG. 20B, in item 2004, the ZB-token input routine calculates the checksum of the Data Area and stores the result in ZB.sub.-- Value. The Data Area includes the MFK, KEK, MFK.sub.-- Flag, KEK.sub.-- Flag, Key.sub.-- Table, and the Diebold.sub.-- Table. In I/O block 2006, the routine outputs "ZB" and ZB.sub.-- Value. The routine continues at Token.sub.-- Loop.
Referring to FIG. 20C, in I/O block 2008, the ZC-token input routine outputs "ZP" and ZC.sub.-- Value. The routine continues at Token.sub.-- Loop.
FIG, 20D is a flow diagram of the token input routines for tokens ZD through ZN. These routines are identical except that each routine uses the corresponding Z.sub.-- Value. In decision 2010, if the input is only one character, then the routine continues at item 2012 to zero the correspond Z.sub.-- Value, else the routine continues at I/O block 2014. In I/O block 2014, the routine outputs "Z?" and Z?.sub.-- Value, where the "?" corresponds to the second character of the token. The routine continues at Token"Loop.
______________________________________
TOKEN INPUT TABLE
Length Character Type
______________________________________
AA 16 0-F
AC 16 0-F
AD 1 4-C
AF 4-12 0-9
AG 1-255 x
AH 16 0-F
AI 5 BDIII
16 0-F
AJ 16 0-F
AK 5 BDIII
16 0-F
AL 16 0-F
AO 4 x
AP 5 BDIII
16 0-F
AQ 5 BDIII
16 0-F
AS 2 0-F
AT 1 A-F
AV 1-20 0-F
AW 1 1-5
AX 5 BDIII
16 0-F
AY 16 0-F
AZ 16 0-F
BA 3 1-9
BB 256 x
BD 3 1-9
BE 4-16 0-9
BF 1 2,5
BG 5 BDIII
16 0-F
BH 5 BDIII
16 0-F
BJ 1 0-9
BK 5 BDIII
16 0-F
BL 8 0-F
BO 1-1024 x
BR 1-3 0-9
BS 5 BDIII
16 0-F
BT 5 BDIII
16 0-F
BU 2 0-9
BW 1-2 0-9
ZA 1 x
ZB 0-1 x
ZC 0-1 x
ZD 1 x
8 0-F
ZE 1 x
8 0-F
ZF 1 x
8 0-F
ZG 1 x
8 0-F
ZH 1 x
8 0-F
ZI 1 x
8 0-F
ZJ 1 x
8 0-F
ZK 1 x
8 0-F
ZL 1 x
8 0-F
ZM 1 x
8 0-F
ZN 1 x
8 0-F
ZO 1 x
8 0-F
ZP 1 x
8 0-F
______________________________________
______________________________________
TOKEN STORAGE TABLE
Variable Description
______________________________________
AA.sub.-- Value Decrypted AA.sub.-- Input
using Mod(MFK,1)
AC.sub.-- Value Decrypted AC.sub.-- Input
using Mod(MFK,4)
AD.sub.-- Value AD.sub.-- Input
AF.sub.-- Value AF.sub.-- Input
AG.sub.-- Value AG.sub.-- Input
AH.sub.-- Value AH.sub.-- Input
AI.sub.-- Value Decrypted AI.sub.-- Input
using Mod(MFK,2) or
Key Table[AI.sub.-- Input]
AJ.sub.-- Value Decrypted AJ.sub.-- Input using
Mod(MFK,AS.sub.-- Value[0])
AK.sub.-- Value AK.sub.-- Input or
Key.sub.-- Table[AK.sub.-- Input]
AL.sub.-- Value AL.sub.-- Input
AO.sub.-- Value AO.sub.-- Input
AP.sub.-- Value Decrypted AP.sub.-- Input
using MFK or
Key.sub.-- Table[AP.sub.-- Input]
AQ.sub.-- Value Decrypted AQ.sub.-- Input using
Mod(MFK,AS.sub.-- Value[1])
Key.sub.-- Table[AQ.sub.-- Value]
AS.sub.-- Value Modifier AS.sub.-- Input[ 0]
AT.sub.-- Value AT.sub.-- Input
AV.sub.-- Value AV.sub.-- Input
AW.sub.-- Value Mod(AW.sub.-- Input,30H)
AX.sub.-- Value AX.sub.-- Input or
Key.sub.-- Table[AX.sub.-- Input]
AY.sub.-- Value AY.sub.-- Input
AZ.sub.-- Value Decrypted AZ.sub.-- Input
using Mod(MFK,4)
BA.sub.-- Value BA.sub.-- Input
BB.sub.-- Value BB.sub.-- Input
BD.sub.-- Value BD.sub.-- Input
BE.sub.-- Value BE.sub.-- Input
BE.sub.-- Len Length of BE.sub.-- Input
BF.sub.-- Value Mod(BF.sub.-- Input,30H) or
Key.sub.-- Table[BF.sub.-- Input]
BG.sub.-- Value Decrypted BG.sub.-- Input using
Mod(MFK,AS.sub.-- Value[0])
Key.sub.-- Table[BG.sub.-- Input]
BH.sub.-- Value Decrypted BH.sub.-- Input using
Mod(KEK,AS.sub.-- Value[0])
Key.sub.-- Table[BH.sub.-- Input]
BJ.sub.-- Value BJ.sub.-- Input
BK.sub.-- Value Decrypted BK.sub.-- Input
using Mod(MFK,2) or
Key.sub.-- Table[BK.sub.-- Input]
BL.sub.-- Value BL.sub.-- Input
BO.sub.-- Value BO.sub.-- Input
BR.sub.-- Value BR.sub.-- Input
BS.sub.-- Value BS.sub.-- Input or
Key.sub.-- Table[BS.sub.-- Input]
BT.sub.-- Value Decrypt BT.sub.-- Input
using Mod(MFK,1) or
Key.sub.-- Table[BT.sub.-- Input]
BU.sub.-- Value BU.sub.-- Input
BW.sub.-- Value BW.sub.-- Input
______________________________________
FIG. 21 is a flow diagram of the message processing loop. The Application jumps to decision 2102 from decision 1620 of FIG. 16 when the end of message character is input, "]". In decision 2102, if the AO.sub.-- Value equals "STAT", then a STAT function was received in the message. Since the STAT function is processed specially as described above, the Application calls F.sub.-- END.sub.-- MSG to complete the response. Subroutine F.sub.-- END.sub.-- MSG is called by each token processing routine and is described below. When the subroutine returns, the Application continues at the Main.sub.-- Loop to input and process the next message.
In decision 2102, if the AO.sub.-- Value is not equal to "STAT", then the Application jumps to one of several function processing routines. The Application contains one function processing routine for each function, which are shown in FIGS. 22 through 49. In item 2106, the Application performs a series of "if-tests" to determine which processing routine to jump to. In a preferred embodiment, these "if-tests" are ordered according to the frequency at which a particular function is requested. Upon completion of each routine, the Application continues at Main.sub.-- Loop to input and process the next message.
The subroutine F.sub.-- END.sub.-- MSG (not diagrammed), which is called at the completion of each function processing routine, performs two services. First, the subroutine outputs the message "AG" and AG.sub.-- Value, if an AG-token was received in the input message. Second, the subroutine outputs a "]", the end of message character and returns.
FIG. 50 is a flow diagram of the error routine. Several of the token processing routines jump to this routine when the routine detects an error. This routine outputs an error message and continues at the Main.sub.-- Loop to process the next message. In decision 5006, if Error.sub.-- Flag is set, then an error message has already been output for this input message and the routine continues at Main1.sub.-- Loop on FIG. 14, otherwise the routine continues to item 5010. In item 5010, the routine sets Error.sub.-- Flag. In item 5012, the routine increments ZL.sub.-- Value, which contains a count of the errors. In item 5014, the routine delays before sending the error message. In I/O block 5016, the routine outputs the string "[AOERRO;". In item 5018, the routine uses the Error.sub.-- Table, shown in FIG. 18B, to jump to an error message sending routine. Before the error routine is entered, the involving routine sets Error.sub.-- Number to indicate the error message to send. The routine uses the Error-Number as an index into the Error.sub.-- Table. The routine jumps to the indexed location, which contains a jump to a routine to output the selected message. Each of these routines, upon completion, jumps to the Main.sub.-- Loop.
Several of the token processing routines call the subroutines F.sub.-- DES and F.sub.-- DESE, which are the decryption and encryption routines. A description of algorithm is contained in the "Financial Institution Message Authentication X9.9" developed by the American National Standards Committee on Financial Services, published by the X9 Secretariat, American Bankers' Association, 1120 Connecticut Avenue, N.W., Washington, D.C. 20036, which is hereby incorporated by reference.
FUNCTIONS
CATC
FIG. 22 is a flow chart of the CATC routine. This routine performs the CATC function. The routine encrypts the ATM Communications Key for downloading to a Diebold ATM or an IBM 3624 ATM.
In decision 2201, if the BJ-value is equal to a 1, then the Diebold ATM is specified and the routine continues at subroutine 2202, otherwise the IBM ATM is specified and the routine continues at subroutine 2220.
In blocks 2202 through 2216, the routine processes the Diebold ATM request. In subroutine 2202, the routine calls F.sub.-- DESE, the encryption subroutine, with AX.sub.-- Value as data and AJ.sub.-- Value as key and the subroutine return the encrypted value in Des.sub.-- Return. In subroutine 2204, the routine calls F.sub.-- START.sub.-- MSG to output the start of the output message. In I/O block 2206, the routine outputs "BJ" and the BJ.sub.-- Value. In I/O block 2208, the routine outputs "BK" and Des.sub.-- Return. In subroutine 2210, the routine calls F.sub.-- DESE, the encryption subroutine, with zero as data and AX.sub.-- Value as key and the subroutine return |
