CA1121014A - Method and apparatus for transaction and identity verification - Google Patents

Abstract

A METHOD AND APPARATUS FOR
TRANSACTION AND IDENTITY VERIFICATION

ABSTRACT

A method and apparatus whereby the senders and receivers of messages sent over a transmission system including a Host CPU may guarantee the integrity of the data content of the message and also the absolute identity of the sender. Each user of the system as well as the Host CPU
contains an identical key-controlled block-cipher cryptographic device with data chaining for en-crypting and decrypting messages as required, wherein each user has knowledge of only his own cryptographic key and wherein the Host CPU has access to the unique cryptographic keys of all users of the system stored in a high security storage area available only to said CPU. Stated very generally, the originator of a message A sends a message to a receiver B which includes a trans-action or message portion X and a unique digital signature portion Y which is a function both of the message and the senders unique cryptographic key KA. The receiver then communicates with the CPU
for verification of the signature Y. The CPU
accesses the sender's key KA from a secure memory and computes the digital signature Y utilizing the message portion X received from B and the key KA. Upon a successful verification of the signatures by the CPU, the CPU notifies B via an additional message that the signature of A
is valid based on the data content of the message and the key KA. Based on the information received from the CPU, B may be certain that the signature and message originated with A and A may not later deny having sent the message as it would be vir-tually impossible for the signature to be forged since it is a complex function of the message content itself. A may also be assured that B
cannot alter the message as the signature would no longer be valid.

According to other aspects of the invention the interrupting of communications between A and B
by an eavesdropper and the subsequent sending of stale messages is prevented. As a still further feature of the invention, an eavesdropper is prevented from sending the "forged" approval from the CPU to the receiver B.

Description

~L~21L~

A METHOD AND APPARATUS FOR
T ~NSACTION AND IDENTITY VERIFICATION
., : DESCRIPTI5N

Technlcal Field The present invention relates to a high security communication system including a plurality of users or terminals connected to each other via a co~mon communication link which is in turn connected to a Host CPU. By means of the present j 10 system it is possible for a sender A to communi-cate a specific transaction to a user B with an extremely high degree of integrity or confidence in the transaction. Utilizing ~he present system the following threats to transaction integrity . :
may be substantially eliminated.

The ~irst t~reat is reneging, wherein the sender engages in a trans~ction with a receiver sending data which he may subsequently attemp~ to disown.
Thus, the receiver must know with certainty that the sender sent the specific message which fact may ~e proven subsequently.

A second possi~le threat to such a system is ~0977-068 forgery, w~erein the receiYer may allege that he received a messa~e from a g;Yen send~rl which message is a fabr~cation, thus, ~t must ~e possible for the sender to prove that the sup-s posed message was in fact a forgery.

A third threat is similar to forgery namely that oî al~eration, wherein ~the receiver might alter the message in a material way which would do some financial or other harm to the alleged sender. Thus, any alteration of such a message must be identifiable by the alleged sender.

A still furthex threat is where a sender or other person by penetrating the communication system would attempt to fool a receiver into accepting a transaction as valid from some sender by manipu-lation of the operating system, such as by eaves-dropping and the capture and resending of stale mess~ges or the fabrication of "approval" sianals from the CPU, etc. The system must therebv guar-antee ~ that such penetration is not possible. Afinal threat is masquerading, wherein a user on the system would attempt to masquerade as a dif-ferent user to a third party. This would normally -be done by means of a combination of the above threats.

It must be assumed that all users axe linked to the host telecommunication system in common and that their messa~es are enciphered by a common encipherment process. Accordingly, the integ-rity of the communIcation's security, or lackof it, ~ill play no role ;n the verification of transactions.

There aXe many potential uses for such a system in the modern business community. Potential Y0977-~68 -applications axe in the area of stock market transactions carried out ~ver the communications systems, automatic bankin~ tran~actions, elec-tronic mail and/or any other system in which digitalized messages are sent and recei~ed over public communications channels and wherein the integrity of both the messages and the origina-tors must be absolutel~ guaranteed.

It is accordingly a primary ob~ect of the present invention to provide such a high security com-munication system whexein both the transaction content and the si~natures of senders may be completely verified and wherein all of the above enumerated threats may be substantially eliminated~

It is a further ob~ect to provide such a system utilizing readily available communications and computational hardware organized and operated in the manner set forth herein to produce such a systemO

Other objects, features and advantages of the system will be apparent from the subsequent ; description o the system and claims.

Background Art .
The following pu~lications all relate to various types of electronic or digital signature systems generally using various types of approaches to achie~e data and/or message integrity. The systems disclosed in these publications differ ; considerably in both approach and results to the system disclosed herein. 1) M. o. Rabin, "Signature and Certificatlon by Coding," IBM Technical Dis-closure Bulletin, Vol. 20, No. 8, pp. 3337-8, (January lq781. 2~ W. Diffie, M. Hellman~ "New YO977-~68 Directions in Cryptography," IEEE TransO on Information Theory (Novem~er 1976). 3) R. L. Rivest, A. Shamir and L. Adleman, "On Diaital Signatures and Public-Key Crypto-Systems," M.I.T. Laboratory - 5 for Computer Science Report, MIT/LCS/TM-82 (April 1977).

Brief Description of the Drawings FIG. 1 comprises an overall block diagram of the high security communication system of ~he present in~ention.
' FIG. 2 comprises a functional block diagram of a preferred.embodiment of one of the terminal blocks illustrated in FIG. 1.

FIG. 3 comprises an organizational drawing for FIGS. 3A and 3B~

FIGS. 3A and 3B comprise a fun¢tional block diagram u the Verify Unit block attached to the Host CPU
block shown in FIG. 1.

FIG. 4 comprises an organizational drawing for FIGS.
4A and 4B.
,~
FIGS. 4A and 4B compr~se a detailed EunctionaL
block. diagram of the Yerify Unit Controller bloGk shown in FIG. 3B.

FIG. 5 comprises an organizational drawing for FIGS.
5A through SG.

FIG~. 5A through 5G comprise a detailed operational flow chart illustrating the operation of the herein disclosed high security communications system.

~2~

Disclosure of Invention For a better coTnprehension of the invention there will follow a general discussion of the underlying principles, first of a general transaction and identity verfication system; and then, a discussion of the broad application of these principles to the presently disclosed system. Finally there will ~!~ follow a detailed description of the presently disclosed hardware which constitutes the best -~ 10 mode configuration.

As stated general]v above, a transaction verification system having a high degree of integrity or security must incorporate a number of particular features.
Suppose a User A (the originator of the transaction) wishes to send a data block D to a User B (the ; recipient of the transaction), the architectural requirements of the -transaction verification ~ system and the protocols which said system must ; follow must include the follcwing featuresO The User A must provide with the message D some infor-mation, which is referred to herein as the signature (S), which signature must be dependent both on the data and the particular user. The system must be such that a valid signature S
based on data D by User A must be essentially impossible for User B to construct. Similarly, no other person having access to the system should be able to construct said signature. Further, the sys-tem must include a mechanism whereby the User B can verify that S is a proper signature for the data D by the User A. The system must also provide a mechanism whereby the data content of a message validly received by B cannot subsequently be denied bv the originator A. Further, the verification process must be uneffected by Yos77-06s a penetration of the operating system. Finally, the verification process must have some time dependence to prevent the reuse of stale messages obtained validly by, for example, the rPcipient B, or by some third party ea~esdropplng on the system.

The following describes a system architecture and ; protocol which accomplishes the above enumerated features.

It should first be understood that the present `~ 10 system utilizes a key-controlled block-cipher !~ cryptographic system referred to hereinafter as DES and in the formulas and drawings by the symbol ~. A preferred embodiment of such an encryption device is that set forth in the National Bureau of Standards Federal Information processing standard entitled, "Encryption ~/ Al~orithm for Computer Data Protection." The standard together with a complete technical description is contained in the publication, "Data Encryption Standard, 1I Federal Information Processing Standard (FIPS), Publication 46, National Bureau of Standards, U. S. Department of Commerce (January 1977~. While other key-controlled block-cipher cryptographic systems could be utilized in the in~ention r the above-referenced system is preferred.

Further, the particular cryptographic system used must incorporate data chaini~g. Chaining is introduced to make each bit of the sianature S functionally dependent upon each bit of the dataO For the description of such a block-chaining system, reference is made to U. S. Patent No. 4,078,152 of ~. B. Tuckerman entitled, "Block-Cipher Cryptographic System with Chaining."

Yos77-06s The encryption algorithm or the operation performed by the ~ block utilized in the present embodiment performs an operation represented by the formula:
cleartext D ~ ~(K,D~ ciphertext This denotes the encipherment of the (cleartext~
data D (of a fixed length of at least S bytes~
by the DES encryp~ion system using chaining with the key K. In the following description the subscript A in (K~ denotes the particular private key of the User A. The inverse operation or decipherment (~ 1) is denoted by the following formula:
cipherte~t ~,D) ~ l(K,~(K,D~ = D cleartext The following description is essentially a de-scrip~io~ of the protocol involved or method by which the present system is realized. For purposes of this description FIG. 1 may be re~erred to. It will be noted that the overall system shows a number of terminals or users connected over a data ; 20 communication network to a Host CPU. It will further be noted that the Host CPU is partitioned into the Host and a Verify Unit which is a high security device accessible only to the operating system and high security personnel who would be authorized to handle the various User Keys Xx as well as the master Verify Unit key which will be denoted subsequently as KHV.

At the system initialization time, the Host operating system enciphers each user key according to the following formula:

KA ~ ~(KEV~KA~- XA

. 8 In the abcve formula symbol KA refers to User A's personal key and KHV is the Verify Unit master key as indicated abo~e. The result of all computations are stored in the regular Host CPU's memory in the following format:
*
: A
, *

~ ~ ' ~ KB
.
z ~ ~ Kz . , .
* TABLE
~ .
In the above * Table and in the system it is assumed that an address into the * Table may be derived from the User's ID, i.e. A through Z.

In the present system it is assumed that the sign~ture for data D by any User A which is denoted bv the symbol S~KA,D~ is the final 8 ;byte~ of the encipherment of the message D by the DES encryption system using chaining with the key KA. As will be apparent later, the !data D is a composite of a number of different items including both user ID's, the date, both user time stamps and the message in a predeter-mined format which will be set forth more fully subsequently.

There will now follow a description o the trans-action protocol. It is assumed that each terminal is fitted with a DES encipherment box. Also, each terminal has a programmable timer or "clock" which continuously increments for at least a 24 hour period.

yog77-068 The verification device which is denoted herein as the Verify Unit is located in the ~ost CPU and is equipped with -the specific functional units shown in FIGS. 3A and 3B which consist essentially of a number of special registers for holding signatures and user keys, as well as a DES
; encipherment box.

A transaction from User A (the originator) to User B (the recipient) proceeds in the following manner.
It should first be noted, however, that the following description of the transaction presumes the existence of the above-referenced date stamp mechanisms, counters, etc. A much less secure system could be built without the re-use of same, however, the use of previously verified or stale messages would be impossible to detect without these features. Proceeding now with a description of a typical transaction.
(i~ User A and User B establish a link upon the request of User A and User B supplies to ; User A the current counter value CTreC at user B's terminal. At the same time User B
stores this counter value at his own terminal for later checking.
(ii) User A constructs a valid ~;ignature represent-ed as follows:
:
wherein the data D is defined by the following formula:
D ~ ~ "User A to User B on 2/28/77, CTori, rec Buy 100 shares of " Uponcompletion of the ~eneration of the signa-ture S, A sends the pair:
~D,S ~.~A,DL~
to User B.

~0977-0~8 As implied by the definition of the data value D, the actual message data is prefixed by the sequence of parameter values which are the identity of the originator and the recipient of the trans-action, i.e., A and ~; the date of the transaction,i.e., 2/28/77; the current counter value CTori at User A's terminal and the received counter value CTrec from User B's terminal.

In the following description for ease of reference, the message pair which A sends to B denoted by the above formula (D,SCKA,D)~ will ~e referred to subsequently as the message pair ~X,Y). In this pair value X corresponds to the data message D as defined above, and the value Y corresponds to the Signature S(K~,D).

Proceeding now with the description of the pro-tocol, the User B receives a pair ~X,Y) which is presumptively equal to the previous message (D,S
(KA,D)). At this point, the User B examines the prefix portion of the message (X~Y) denoted by X.
As will be remembered, this prefix portion contains the User A and B identities, dates, and the two counter values, CTori and CTreC. The verification process will continue only under the following conditions.
~ The date information is current.
o User B is identi~ied in the prefix as the recipient.
o The counter value in the prefix, i.e., CTreC
agrees with the value forwarded to User A by User B when User A requested a link and which -was subsequently stored at User B's terminal.

Assuming all of these tests are met, User B then Yo977-068 enciphers the entire message pair (X,Y~ with User B's own individual key K~ to form a message U, which is defined as:
B
After enciphering the message U, User B transmits same to the Host together with the names A and B
of the ori~inator and recipient of ~he transaction.

; The special purpose verify hardware resident in the CPU when supplied with the parameters A, B and U
which have just been reoeived from the User B will proceed to per~orm the following operations.

Utilizing the identities A and B the CPU will c~use the values KA and KB to be accessed from * Table in the CPU memory. It will be remembered from the previous description that KA = ~(KHV~KA) and KB ~ ~(K~V,KB) from the * Table. Utilizing the KA and the KB and the known Verify Unit key, KHV, the Verify Unit associated with the CPU will de-cipher the two values and determine the user keys KA and KB internally o the ~erify Unit and appro-priately store these in holding registers ~herefor,as will be explained subsequently.

The Verify Unit next deciphers the message U under its original encipherment key KB internally. This is representea ~y the formula U = ~ l(RB,U). The system then treats the deciphered message U as two different parts Ul and U2 wherein Ul = U[l,n]
U-2 = ULn+l~n~8]
In the above formulas it will be noted that Ul is the first n bytes which correspond to the data portion of the message X as originally transmitted and the portion U2 ~'s equal to the last eight bytes of the message U which it will be remembered corresponds to the signature portion Y. At this point in ~Lme the system computes the signature of U1 utilizing the key KA and compares with the actual received signature U2. Utilizing a compare variable C, if C = 1 it is assumed that there is a complete ag~eement of the signatures and if C = O it is assumed that there is no such agreement.

Assuming C = 1 the veri~y portion of the system will cause a signature to be derived for the logical complement of the concatentation ~Ul,U2), this logical complement being denoted by ~ (Ul, U2~, using the DES encryption system under chain-ing with the key KB. The resulting verification message V will be returned to User B wherein:
' V = S(KB,~(Ul,~U~2~) or if C = 0, the verify portion of the system will cause a sianature to ~e derived for the concatenation ~Ul,U2) using the DES encryption system under chaining with the key KB. The resulting message V will be returned to User B
wherein:
V = S~Kg~Ul'U2 At this point it should be noted that the operation of the Verify Unit is shown as performing a com-parison of signatures to determine whether a successful or correct signature has been received from the User A. However, a further decision is made by the User B based on the message V returned to the User B bv the CPU and the Verify Unit.

YO~77-068 As previously stated, regardless of the result of the comparison, i.e., C - 1 or C = 0, the Verify ; Unit will derive a sianature V based on (Ul,U2) utilizing DES and the key KBo The resulting verify message V will be returned to User B.
User B, using the verify message V, can now determine if the message (X,Y) from User A
(,pres~mptively equal to (D,S(KA,D)) was properly signed.

Upon receipt of the message V, User B will calcu-late a new signature defined by the following formula:
V' ~ S (KB,~ ~X,Y~ ~
It will be noted that if everything is proper the newly calculated signature V' will equal and correspond exactly to the message V, which the ~ CPU has returned to User B.

; Thus, in summary, User B will accept the trans-action if and only if the data :information in X is current, the "counter" values in X agree with the stored counter values which operations were done pre~iously upon receipt of the initial transaction from User A. The final requirement, and the most ,, critical is the receipt of a valid verify si~nal from the CPU, i.e., V = V'.

It should be noted that in each case the signatures V and V' are the last 8 ~ytes of the total encryption of the indicated data conten-t~ of said signatures under the key KB.

In the case of a dispute between the originator, User A and the recipient User B, User B will be required to produce the pair CX~y) where Y is claimed to ~e the signature of X bv User A. The ax~iter will decide that the transaction is valid if and only if:
Y = S(K~,X) which again is the signature for the putative data message X using User A's key KA.

Only one transaction with the same counter values will be declared valid on a given date. The role of the counter or time value is to protect against the re-use of a previously verified transaction;
for example, User C, màsquexadi.ng as User A, retransmits a previously v~rified (and accepted) transaction to User B. The "time stamp" imposes the protocol tha~ no two messages will be accepted i~ they have identical time stamps, thus, eliminating this attempt at sub~ersion o~ the transa~tion system.

Best Mode for Carrying out the Invention Havin~ generally described the herein disclosed method for establishing a transaction protocol in accordance with the teachings of the present invention a description will follow of a best mode hardware confi~uration capable Oe performing this proto~ol.

FIG. 1, as stated briefly before, comprises a broad ~unctional block diagram of the overall system wherein a plurality of terminals are shown connect-ed via a data communication system to a centrally :
located Host CPU. A Verify Unit (VAULT) is directlyconnected to the Host CPU and may in fact be embedded therein. It is referred to as ~.he VAULT to indicate the very hi~h security nature of the hardware contained the~ein, it being clearly understood that only the syste~ manager with special authorization should ever have access to any of the internal in~ormation stored in said VAULT and that the security o~ the system is limited by the security o~ the personnel having access thereto. ~his will be well understood since the various user keys stored in the * Tables in main memory would be decipherable to anyone having access to the Verify Unit's master key KHV which is not accessible, it being loaded into the VAULT at the time of system initialization by the system manager. The principal functioning units of the Verify Unit will be set ; forth subsequently in the description of FIGS. 3A
and 3B~ The details of the Verify Unit Controller are shown in FIGS. 4A and 4B.
.

FIG. 2 shows the structure of a typical remote terminal suitable for use with the present system.
The majorlty of the blocks of the terminal are completely conventional in nature and operate in a straightforward way. For example, the MODEM block is a modulator/demodulator well known in the art for connecting the terminal to the data bus. The CRT Display and Display Controller perform the obvious function of displaying information keyed into the terminal via the keyboard, accessed from the system memory, or received from the CPU. The keyboard is a conventional unit for entering alphanumeric data and for purposes of the present invention it should be understood that the user keys KA or KB could either be entered via the keyboard or could be stored in the System Memory uniquely accessible via a special code enterable at the keyboard by a particular user. Thus, a number of di~ferent users having different user keys Xx could utilize a single termlnal in accordance with the teachings o~ the present invention it being understood that their particular keys would either have to be entered at the keyboard or suitably accessed ~rom the System Memory. The unique devices required of the terminal for practicing the present invention are a Programmable Timer which yog77-068 would be utilized to produce the counter values CTrec and CTori mentioned in the previous de-scription of the present transaction verification system. The DES Module shown in the terminal is identical to that shown as the DES unit in FIGS. 3A
and 3B and comprises a standard key controlled block cipher encryption box with chaining. The best known example being the previously referenced U. S. Patent No. 4,078,152, of L. B. Tuckerman.

It will be noted that the encryption system denoted herein by the symbol (~) in the formulas of FIGS.
5A through 5G, operate ~n a straightforward manner when provided with an encryption key K and a data ~ block to be encrypted. Given this data the DES
; 15 block will automatically produce encrypted (~) or decrypted t~ l) data in its output. The System Memory Controls are so configured that when the particular data message D is being encrypted, the last 8 bytes thereof may be automatically accessed as they comprise the unique digital signatures of the present system as described in detail previously. The block marked File Con-troller is a back up storage device associated with the terminal un~t and would be used for example to store messages when the terminal is used as an originator, i.e., User A, or as a recipient, i.e., User B. In this case it should be clearly under-stood that User A and User B in the present description, refer to the originator and recipient 30 of a particular transaction respectively. ;~

The operation of such terminals under control of a suitable microprocessor is well known in the art and will not be gone into in greater detail since the performance of the various operations required ~Z~

of the terminals are extremely strai~htforward and well known as is the case wi-th the Programmable Timer and also the Data Security Module.

Referring now to FIGS. 3A and 3B, the primary functional units of the Verify Un~t are disclosed.
The S-Register stores derived signatures generated in the Verify Unit. The contents of the S-Register may be sent to the Comparator or to the Host CPU as the case requires. The DES Unit, as stated pre-viously with respect to the description of FIG. 2, is a key controlled ~lock cipher encryption device with chaining of the type described previously with respect to the DES Module of FIG. 2. This unit receives three data items, namely an encryption key, the data, either to ~e encrypted or decrypted, and finally, an indication of whether an encryp-tion or decryption cycle is required. Control lines C13, C14 and C15 control ~he loading of key data, message data, select the mode of operation and initiate the cryptographic conversion process.
The Register is for the purpose of specifically ; storing the originator's key, either in clear (KA) form or in encrypted (KA~ form. The B-Register stores the receiver's (User Bl key in either clear or encrypted for~.

The block entitled, Read Write ~emory (RWM~, essentially stores the received complete messages transmitted by the system. The KHV Register stores the ~erify Unit's master key under which all of the user keys RX are stored in the Host CPU's ~aster memory, in encrypted form in the previously described * Ta~le. When these encrypted keys are sent to the Verify Unit they are decrypted utiliz-ing the master encryption key KHV to access the actual keys, i.e., KA and ~B in the present illus-tration.

Yo977-068 3~

The Comparator block perorms the exclusive function of comparing signatures on demand and will produce a one (1~ or a zero (0~ on its output line, depend-ing upon whether or not the comparison is successful.

The Verify Unit Controller shown at the bottom of ; FIG. 3B, as is apparent, controls the operation of the Verify Unit wherei~ the various signals utilized are shown on the lef~ side of the block and the handshake output signals, both to the Host and to its own circuitry, are shown emanating from the right side of the block. No commands as such are received by the Verify Unit Controller from the outside. The only signals received by the Verify Unit Controller are two status signals ~Sl, S2) and ~ive handshake signals (R~VRF,...,URDY). The ~erify Unit is under control of the command struc-ture set up in the microprogram memory (FIG. 4A) and is independent of external commands thereby precluding any external attempts to modify the operating sequences of the hardware resources within the Verify Unit. The Ver:ify Unit Controller is shown in more detailed form in FIGS. 4A and 4B.

rhe functional units in the Verify Unit designated as CPl through CP18 are referred to by digital design engineers as control points. Their opera-tional sequences are quite complex in that they may perform both a gating function and a multiplexing or demultiplexing operation depending upon whether they are gating byte serial data into the various ~ -registers or out of said registers. From a func-tional standpoint, however, they may be simply considered as gate circuits having the multiplexing function indicated by the bit configurations enter-ing and emanating from each control point. Each of the control points CPl through CP18 are indicated as being controlled by control line Cl through C18.

~.~LZ~

~or example, control point CP2 takes seven con-secutive 8 ~it bytes and places them in seven consecutive 8 bit s~orage registers in the func-tional unit denoted as the A-Register (a total of 56 bits). Similarly, the control poin~ CP6 does just the opposite. That is, it takes 7 consecu-tive 8 bit bytes from the A-Register and recon-verts them into a serias of seven 8 bit bvtes which it places serially on the CD bus. It will be noted that the two control points designated as CP5 and CP17 convert from 8 bits to 64 bits since the S-Register utilizes an 8 byte signature. It will be remembered that, by definition, the signature is the last 8 bytes of the appropriately encoded message. Also, the control point CP10 is a selective inverter. That is, depending upon whether a 1 or 0 appears on control line C10, then 8 data bits passing through same will be inverted or pass through in true form. Control point CPll merely performs a gating function. It will be noted that the Read/Write Memory (RWM) is organ-ized in 8 bit storage locations, accordingly the control points, CP4, CP10 and CPll need not perform any multiplexing/demultiplexing functions as described previously~

The det~ils of the Control Point Units are not speci~ically shown as they would be obvious to a digital desi~n engineer and moreover~ could take a number of different design forms and still perform the required function.

The following table clearly indicates the specific functions performed by each of the Control Point U~its.

yo~77 068 VERIFY UNIT CONTROL POINT
FUNCTIONAL DEFINITION TABLE

Functional Control Unit Signal Controlled O ~ ntrolled ; Cl CPl ~INPUT BUS ~ HOST CPU DATA
C2 CP2 A-REG ~ INPUT BUS DATA
C3 CP3 B-REG ' INPUT BUS DATA
C4 CP4 RWl!l ~ INPUT BUS DATA
C5 CP5 S--REG ~ INPUT BUS DATA
C6 CP6 C-D BUS ' A--REG DATA
C7 CP7 CLEAR A-, B--REGS TO ZERO
C8 CP8 C-D 13US ' B-REG DATA
C9 CP9 REA.D/WRITE MODE AND ENABLE
CONTROL

Cll CPll C-D BUS ~ R~M DATA :
C12 CP12 C--D BUS ` KH~ REG DATA

i 20 BUS
Cl 4 DES LOAD DES DATA BUFFER FROM C-D
BUS
C15 DES CONVERT DATA (CRYPTOGRAPHIC
PROC:E:SSING)~SELECT MODE

2 5 INITIATE OPERATION `

C16 CP16 INPUT BUS ' DES OUTPUT DATA
C17 CP17 OUTPUT BUS ~ S-REGISTER DATA
COMPARATOR: S-REGISTER DATA
C18 CP18 HOST CPU ~ OUTPUT BUS DATA

~ .

Y0977-t~68 Referring now to FIGS. 4A and 4B the details of the hardware configuration of the Verify Unit Con-troller are shown. The controller follows the well known architecture of a small microprogrammed controller, such as is well known in the art. Part of the controller is of course the Micro Program Memory wherein the various operational sequences -- are stored, Particular addresses in the Micro Program Memory selected for par-ticular operations are determined, as will be well understood, by the Micro Program Controller 12. As a given sequence is running the next address to the Micro Program Memory 10 comes from an internal microprogram counter which is incremented unless a branch to another location in the microprogram memory is required whereupon the branch address is loaded into the microprogram controller from the branch address field of the control word register. The various conditions which control operation of the Micro Program Controller are received from the Input Multiplexer wherein the various status and/or handshaking control siqnals will allow a particular sequence to proceed or be terminated.
The particular line of the Input Multiplexor 14 utilized for controlling a given sequence is selected by the 3 bit IMPX Address field in the Control Word Register which is connected to the IMPX 14 address input port.

The following Host CPU/~erify Unit Handshake Control Definition Table is included for conven-ience of reference.

YO977 a6~

1 1.~1.~ 14 ~ 22 ; HOST CPU/VERIFY UNIT INTERFACE
DEFINITION TABLE

Handshake ~ Function 5 RQVRF Inform VU of request for verification RQV Inform W of request for derived sig-nature V

; KA*RDY Inform VU that KA* data are ready for transfer 10 K3*RDY Inform VU that KB* data are ready for transfer URDY Inform VU that U data are ready for transfer ~US~ A flag indicating Verify Unit status 15 RQKA* Inform CPU of request for KA* data RQKB* Inform CPU of request for KB* data RQU Inform CPU of request for U data VRDY Inform CPU derived si~nature V is ready ~;
for transfer YO~77-0~8 The Control Word RegIster clearly indicates the forma~ o~ t~e instructions stored in Micro Program ~emory and utilized by the system. The six speci-fied fields are believed to be self-explanatory.
The next address select, IMPX address, and branch address have just been descri~ed. The handshake control ~ield comprises six bits, three of which address the ~ive ~it addressable latch 16. The

3 bit address lines selects an output line; "data"
line is supplied with a binary value (0 or 1) that is desired at the selected output line; the "enable"
line causes the binary ~alue on the "data line"
to be "latched" and thereby appear on the selected output line. The "clear" line clears all output lines to zero. For example, if you wish to set "RQU" to 1 (as in block 10 of Verify Unit Flow Chartl. RQU is associated with output line 3 of the 5-bit addressable latch. The 3 "address"
lines are set to "011" (binary 31, the "data" line is set to 1, and the "enable" line is set to 1 (momentarily) thereby causing output line 3 to take on t~e bina~y value of 1. Thus, RQU = 1, informing the Host CPU of a request for U data.

The Data Path control field of the Control Word Register controls the various Control Point Units descri~ed previously. These signals are used to either control the data flow paths between the various registers or to control the operation of functional units such as the RWM and the DES unit o the Verify Unit as will be well understood. It will be noted on FIG. 3 that 18 Data Paths Control Lines are indicated. This is in essence a func-tional number o~ the Control Point Units requiring a plurality of inputs. Fin~lly, the R/W Memory Address Generation ~ield, has a five ~it ield which controls the R/W Memory Address Generator yog77-068 block 18. This block actually contains two func-tional units, a twelve bit bidirectional counter and a storage register for saving desired counter settings or addresses. The counter supplies an S ascending sequence of memory addresses to the RW~
unit to enable it to store the remaining string of message bytes making up a particular message which are received by the Yerify Unit. The upper input to the generator 18, from the clock generator, produces a pulse each time a data byte is received by the system. The five bits coming from R/W
Memory Address genera~ion field of the Control Word Register perform selectively the following func-tions.

The "reset" line causes the counter to be reset toall zeros. The "load" line causes the curxent contents of the storage register mentioned pre-~iously to be loaded into the counter. The ~o "count" line is essentially an enable line which allows the clock pulses to increment or decrement the counter as determined by the "up/down" line which controls whethex, dependin~ on the given operational sequence the counter is being increment-ed or decremented respectively. When the save lineis actuated it causes the contents of the counter to be stored into the register. It will be noted that the 12 bit output R/W Memory Address cable emanating from the generator 18 comes directly from the counter stages. It is these consecutive addresses which cause a given message to be stored in consecutive storage locations in the R/~ Memory shown in FIG. 3B of the Verify Unit. The two units designated 3 state buffers 20 are in effect gate circuits which will selectively gate to the Micro Program Controller either the data on the 12 bit cable emanating from the branch address field of the Control Word Register or from the R/W Memory Address Generator 18.

Yo~77-068 This essentially completes the general description of the presently disclosed transaction verification syst~m. It should be noted that the various operations required of the Host CPU would con-ventionally be performed by straigh~forward pro-gramming means. The functions required of the CPU
axe essentially those of se~ting up communication paths between ~he user A and user B, requesting service from the resident Verify Unit and for providing requested entries from the * Table to the Verify Unit~

Reference to the Operational Sequence Charts for the Veri~y Unit together with the following des-cription o~ the overall flow chart of FIGS. 5A
through 5G will clearly explain the detailed operation of the present system. It should be understood that the User A and the User B flow charts are both present in any given terminal, however, depending upon whether a given user is an originator or a recipient, the "originating" or "receiving" operational sequence will be activated.

; In th~ flow chart of FIGS. 5A through 5G" it will be noted that there are a number of dashed lines terminating in an arrow implying a direction of communication ~etween the vaxious operational sequences comprising the present transaCtiQn verification system. Each of these arrows in effect represents a handshaking operation which i~
required of the present system, wherein control passes ~rom one operational sequence to the other as the need arises. These handshaking operations take place between the CPU and the Verify Unit Controller and utilize the handshaking control signal lines for that purpose. The occurrence of the handshakin~ operations is clearly apparent in the opexational sequence charts.

~0977-068 Referring now to the system flow diagram which describes a complete ~ransaction Verification Operation, reference will first be made to FIG. 5, which is an organizational diagram for FIGS. 5A
through 5G. By arranging the figures in this fashion a single flow chart for the operation of the entire system is shown. Referring to the flow chart, each of the operational sequences is clearly labeled as occurring within the terminal of User A
or User B, the Host CPU, or the Verify Unit. It should be noted that on FIG. 5B there are six blocks which are the terminal portion of the User ~
operational sequence. This is specifically labeled ; on FIG. 5G.

Before proceeding with the specific description of the flow chart, the following is a Definition of Terms Table setting forth the formulas and their definitions as used in the flow chart and in the prior general description of the overall opera-tional protocol of the system. It is believed that i reference to this table of definitions will greatly facilitate an understanding of the following description o the flow chart.

.-~
~7 DEFIN~TION OF TE~MS TABLE

1. M: message ~iOe., Buy 50 shares RDQ common ...) 2. D:data: (A, ~, date, CTorig, CTreC, M) ; 3. S~KA,D): Signature of data D: S(KA, D~: last eight bytes of the chained encipherment of D
by DES using the key K~.

4. ~X,Y): the message received from User A, presumptively equal to CD~s(KA~D~

5. CT: a current counter value at a particular : terminal (orig~recl 10 6. KA: User A's key - KB: User B's key :

7. KHV: Ve~ify Unit's master key 8. K~ : ~(KHV, Kz~, ie-, for any user Z

9. ~/~ 1 encryption/decryption under an encryption key 10. U = ~(KB,(X,Y)) 11. U = ~ (KB,U) = ~Ul,U2) 12- Vl U[l,n]: - U2 = U[n*l~n+8]

13. V = S(KB, Ul or S(KB,~Ul = last ~ight bytes of the chained encipherment of U by DES using the key KB
14. If S~KB,~U~ = SCKB~(X,Y)~. then signature of A
is valid ~or ~essage X.

~0977-068 , :
, ; Referring now to the flow chart it will first be noted that the successive blocks in each of the separate sequences are numbered consecutively for ease of reference.

It may be assumed, beginning in FIG. 5A that User A
wishes to initiate a transaction utilizing the present transaction ver.ification .system. User A's terminal begins operation as indicated in block 1 and a determination is made as to whether a trans-action is being initiated. If not the systemproceeds to block 2 where a test is made as to whether a transaction request has been receive~, if so the operation sequence would branch downwardly ;
into the "receiver" mode. It will be noted, as ~' indicated in the figure, that the operational procedure would be the same from this point on, as is shown ~or User B. Thus, the "originator"/
"receiver" modes are both present in every terminal although only one would be operati~e during any ; 20 gi~en transaction.
, ':
` If the answer to the test made in block 2 is "no"
; the system would branch back to the baginning and continue cycling through blocks l and 2 in a "wait"
state until eithex User A decides to initiate a , 25 transaction or receives a transaction request from : another user which will cause the operational sequence to proceed in the appropriate manner. , ~`
Assuming at this point that User A is the initiator of a transaction the system proceeds to block 3 and a link is established via the Data Communication Network with User B's terminal and control switches to block l of User B. As will be apparent a branch to block 2 will then occur when it is determined that a transaction xequest has been received from User A. At this point the User B sequence proceeds YO~77-068 to block 3 which, ln Eact, establishes a link to User A over the Data Communication Network. At this point User B sends his current counter value CTreC, and at the same time causes the data: "iden-tity of A and CTreC" to be saved in his local ` memory for subsequent comparison purposes and at this point control is transferred back to User A.
; At this time it is determined whether or not the counter value from User B has been received 10 ( rec~

Next, User A's sequence proceeds to block 5 which ~ causes A's signature to be generated. The formula .. for this signature is set forth clearly in line 3 of the Definition of Terms Table (Definition Tablel. The sequence proceeds then to block 6 wherein each txansaction message for transmission to User B is constructed which comprises the message pair ~X,Y~ the speciic contents of which are clearly shown and defined in lines 2, 3, 4, 5 and 6 of the Definitton Table. At this point, ~ control trans~ers to the User B sequence, Block 4.
~
The receipt of th.e complete transaction message from User A causes the system to proceed to blocks ` 5, 6 and 8 wh.erein three straiahtforward data : 25 content tests are made, i.e., for the date, the correct addressee, i.e.., User B and the proper counter value which ~t will be remembered was saved by Usex B in block 3. If any of these tests are negative the transaction will immediately abort or terminate as shown in block 7 and the sequence will proceed no ~urther. If everything is correct howe~er, the system proceeds to block 9 wherein the user key K~ is provided to User B 15 DES ~odule wh~ch is ~ key controlled block cipher ~:
cryptographic unit as described previously ~nd similarly the message pair (X,Y~ is made available YO~77-068 to the encryption unit ~s the dat~ to be encrypted, and the entire messa~e pair CX~y~ is encrypt~d under User B's key to produce the message U, which is de~ined i~ line 10 of the Definition Table.
The system ~hen proceeds to block 10 wherein User B transmits to the Host CPU the message A, B, U.
The portion of the message defined as A, B defines the originator and recipient of the message which is being sent to the CPU for veriication. As will be remembered the data A and B provide entries to the * Table whexe the keys KA and KB
are stored.

At this point control transfers over to the Host CPU sequence. It will first be assumed that in the start operation, the system is initialized and all handshake lines to the Verify Unit are effec-tively cleared to zero. In block 1 the "request for verification" sig~al is received from User B.
The sequence proceeds to block 2 wherein the message A, B, U, is received and appropriately stored in the CPU memory.

In block 3 a test is made of the "busy" status of Verify Unit and if "busy" the system will wait until it is not busy and can proceed to block 4 whereln a request for a new transaction veri~
cation operation (RQVRF~ is sent to the Verify ~ unit. Control then transfers the ~erify Unit, ;; specifically, block 2. It will be assumed that the start bLock causes the requisite handshake control output lines to be appropriately set to zero. Upon the receipt of a "request verification~ signal the syst~m proceeds to block 3 in the Verify Unit sequence wherein the "busy" flag at the Verify Unit handshake control outputs is set to a "1" which will advise the CPU that the Verify Unit is "busy"
in case it should attempt to request a further l9L

transaction verific~tion operation.

The system then proc eds to block 4 wherein a request is made for KA. This request qoes back to the Host CPU where it will ~e remembered the various user keys are encrypted under the system master key KHV in the * Ta~le. This request will cause the RQKA* handshake control output line from the Verify Unit to be set to a oneO At this point control is shifted back to the Host CPU and specifically block 5 thereof. In block 5 the request for KA is acknowledged and the system proceeds to block 6 of the Host CPU sequence. In this block, the previously received value A, identifying the originator of the transaction, is used as an address into the * Ta~le and the data referred to as KA is accessed and KA*RDY handshake line proceeding to the Verify Unit input handshake control is set to a one, indicating to the Verify Unit, that the KA data is ready. In block 7 the 16 KA data is transmitted to the Verify Unit and the KA*RDY handshake line is reset to a zero. At this , point control transfers back to block 5 of the Verify Unit sequence.

Block 5 acknowledges the signal, which causes K~
to be read into the A register of the Verify Unit and at thiS point the RQKA* handshake control output line is reset to ~ero. Control now proceeds to block 7 wherein a request is made for the KB
data. At this point it will be noted that blocks 7, 8 and 9 of the Verify Unit are essentially identical functionally to blocks 4, 5 and 6 of the Verify Unit with the exception that at the end of this sequence the data KB is now loaded in the B
register of the Verify Unit. Similarly, blocks 8, 9 and 10 in the Host CPU sequence are essentially identical to ~locks 5, 6 and 7 thereof with the 2~

32 *
exception that in ~his case the data KB is ex-tracted from the * Table and sent to the Verify Unit~ Assuming now that the data KB is resident in the B register, the system will proceed to bloc~ 10 of the Verify Unit sequence wherein a request is made for the data U which has bean stored in the Host CPU memory. At the same time the handshake control RQU is set to à "1" in the output from the Verify Unit and control transfers back to block 11 of the Host ~PU which receives the request. The Verify Unit waits until the CPU is re~dy to send U. When the CPU is ready, it then sets URDY line to 1. In the meanwhile the Verify Unit is waiting and monitoring the URDY line. It is assumed here that U i~ available and accordingly the handshake control indicated as URDY is set to a one which info~ns the Verify Unit that the message se~nent U
is a~ailable for transmission.

In block 13 of the Host CPU sequence, the message segment U is sent to the Verify Unit and the URDY
handshake input line to the Verify Unit is reset to a "zero". Referring now to block 12 o~ tha Verify Unit the message segment U is read from the Hos~
CPU and stored in the RWM of the Verify Unit and the handshake control output line RQU is reset to a "zero". Rlock 13 of the Verify Unit causes the originator key KA to be deciphered from the value KA currently stored in ths A register by trans-mitting KA plus the system master key KHV to the DES Unit whereby User A's encryption key KA is decrypted and storsd in the A register for further verification operations. The system then proceeds to block 14 where precisely the same operation is performed for the value KB to produce the User B's key, KB, which is stored in the B register.

At this point the Verify Unit sequence proceeds to YO977-06~

block 15 wherein the message U is deciphered under the user key KB and the results are stored in the RWM as U. The defin~tion or specification of the data content of the deciphered message U is shown in block lSA and is indica~ed as U1 and U2 which are the ~irst n ~ytes of the deciphered message and the last 8 b~tes of the deciphered message respec-tively. As will be remem~ered from the prior definition of the sianature, these last 8 bytes or U2, are presumptively equal to the sianature of User A. To verif~ this in block 16 the Verify Unit now causes the signature of User A under key KA to be constructed at this time utilizing the value U
as the data source for the signature. Thus, if U
has been truly received as the oriainal message Xr set by User A to User B and then enciphered under ; key KB and sent to CPU, then the last 8 bytes of ; this encipherment as performed in block 16, should be equal to the value -2 This comparison is made in block 17 and i~ the comparison is successful the Verify Unit will have determined that the signature for User A is valid. After this comparison the Verify Unit sequence may either branch to blocks 18 or 19 where construction of an "invalid" or "valid"
message to be transmitted back to the User B is perormed. In order to insure the secrecy and integrity of the return message, rather than just sending back a simple yes or no signal, which could be easily synthesized by an interloper on the line, blocks 18 and 19 cause a complex message defined as the signature V of ~ or of ~ U under the key KB to ; be generated. Thus, depending upon whether the comparison in block 17 was or was not successful, the signature V is derived utilizing ~ U, the logical complement of U or U as the data source.
In block 20 the VRDY handshake line from the handshake control outputs of the Verify Unit is set to a "1" which when detected ~y the Host CPU

activates block 14 o~ the Host CPU which is in-foxmed that the si~nature V is now ready in the Verify Unit. In block 15 of the Host CPU, V is requested by setting th.e handshake control input line RQV to a "1" w.hich actuates block 20 in the Verify Unit. In block 22 of the Ver~fy Unit and block 16 o~ the Host CPU the message V is sent from the Verify Unit to th.e CPU and in block 17 of the CPU's sequence the derived sianature V is trans- -mitted directly to User B. This terminates the Host CPU operational sequence for this particular verification request and in effect returns same to the state of block 1.

Returning briefly to the Verify Unit operational sequence, transmission of the signature V to the Host CPU ends the active role of the Verify Unit operational sequence in the overall verification procedure, it being noted that block 23 and block 24 are merely clearing and resettin~ operations for removing stale data from the operational registers and resetting the various handshake lines to their standby or wait condition in block 2.

In block 11 of the User B sequence on FIG. 5G, the terminal of User B is appropriately notified that the verification message ~ is ready to be trans-mitted from the Host CPU. At this point, appro-pri~te control is actua~ed and the message V is in effect read from the Host CPU in block 12 and in block 13, User B constructs the sianatura of the logical cQmplement o (X,Y) denoted by ~ (X,Y~
under his own key K~ which as will be remembered, comprises the last 8 bytes of the encryption o message ~ (X,Y~ under the key KB. This generated signature is compared with the message Y, which was received from the Host CPU in block 14 of the User .
B sequence. The test made in this block and its Yos77-~6s consequences are tmplied in line 14 of t~e Defini-tion Table.

It should be noted in p~ssing that, providing the entire system is operating properly, and no messases have been erroneously transmitted or fraudulently transmitted, then U which is the decipherment of U under~the key KB should be equal to the original message ~X,Y). Thus, a successful ; comparison in block 14 indicates that the signature y which User B originally received from User A is correct and proper for the message portion X. It will be further noted that in addition to User B
now ha~ing confidence that he has been communicat-ing with the true ~ser A and further that he has received a valid message X, User A is similarly protected because of the absolute dependence of his valid signature on the content of the message X. This was explained previously with respect to the arbitration procedure possible in the present system and is repeated here for purposes of emphasis only.

Having thus described the operation of the present system from the flow charts of FIGS. 5A through 5G
it is believed that the overall operational char-acteristics will be well understood by thoseskilled in the art.

There will now follow a detailed exposition of the operation of the Verify Unit control~ in the form of an Operational $equence List f~r the Verify Unit. This list comprises a sequence of the individual oper~tions which would conventionally be performed by micro code stored in the micro-program memory of the Verify Unit which operations ~ust be performed to practice the herein disclosed preferred embodiment of the invention. ~eferring YO977-~68 `~ 36 to these operational sequence lists which are numbered in accordance with the blocks of the flow char~ the discrete opexations caxried out and the manner in which the various units of hardware shown specifically in FIGS. 3A~ 3B, 4A and 4B, operate will be readily understood. A list of definitions appears at the beginning of the Operational Se-quence List which defines the various acron~ms or : abbreviations utilized Y0~77-Q68 i Operatlonal Sequence List .

De~initions RWM: Read~Write Memory RWMAG: Read/~rite Memory Address Generator IMPX: Input Multiplexer DES Unito Data Encryption Standard Unit ~:

~Ci~ t~ Control Point, activation of ~ESET: R~MAG set to zero ' LOAD: Contents of internal storage register are loaded into RWMAG

COUNT: Enables RW~AG to count U/D: Up~l)/down(0~ count-mode control for RWMAG

SAVE: Contents of RWMAG are saved in internal storage register CLEAR: All handshake control output lines are ~ :
cleared to zero Yos77-~6s STEP

2 Set IMPX ADDRE5S to 2 TEST RQ~RF:
I~ 0, hold;
~ 1, con-tinue, 3 Set BUSY to l 4 Set RQK~* to 1 Set I~PX ADDRESS to 4 TEST KA*RDY:
If 0, hold If l, continue

6 ;:

6.1 Load A-Register with KA* from Host CPU. tCl~C2~ ;

6.2 Clear RQKA* to O

7 Set RQKB* to l j 8 Set IMPX ADDRESS to S

9.1 Load B-Register ~ith KB* from Host CPU. (Cl,C2 ~.2 CLear RQKB* to a Set ~QU to l Yos77-06s ::~12~

STEP
11 Set IMPX ~DDRESS to 6 Test URDY:
If 0, ho1d i 5 If 1, continue 12.1 RESET

12.2 Set U/D to 1 .

12.3 Set RW~ for write operation CC9l 10 12.4 Set I~PX ADDRESS to 6 :

12.5 Load one data by~e o~ U from Host CPU to RWM
via Input-Bus (C1,C4 12.6 Test UR~Y:
~f 1, increment RWMAG ancl go to step 12.5; :~
If 0, continue ' 12.7 Clear RQU to 0 12.8 SAVE

13 :

13.1 Load key K~V into DES Unit (C12,C13) 20 13.2 Load data from A-Register (KA*) into DES Unit : ~
(C6, C14 1 '"

13.3 Decipher data (C15~
: .
13.4 Read 7 bytes of data CKAl from DES Unit into A-Register ~C16,C2 STEP

14.1 Load key KHV into DES Unit ~C12rC13~

14.2 Load data from B-Register CKB*l into DES Unit tC8,C141 14.3 Decipher data (C151 14~4 Xead 7 bytes of data (KB~ from DES Unit into B-Register (C16,C3 15.1 Load N~8 into Microprogram Controller 15.2 Load Key KB into DES Unit ~C8,C13 15.3 Set U/D to 1 15.4 RESET

15.5 SAVE

15 15.6 Set RWM for read operation ~C9,C101 15.7 hoad 8 bytes of U data from RWM into DE5 Unit (Cll,C14~ :

15.8 Decipher data (C15 15~9 LOAD

20 15.10 Set RW~ ~or write opera~ion (C4, C9~

15.11 Store 8 bytes of U data from DES Unit in RWM (C16,C4) STEP

; Repeat steps 15.5 throug~ 15.11 as necessar~
: until N~8 bytes of U data have been processed.

16 ~ ;`

16.1 Decrement RWMAG by 8 (R~MAG t N) 16.2 SAVE

16.3 Load N into Microprogram Controller 16.4 RESET

16.5 Set U/D to 1 16.6 Load Key KA into DES Unit tC6,C13 16.7 Set R~M for non-inverting read operation ~C9,C10) 16.8 Load 8 bytes of Ul data from RWM into DES Unit (Cll,C14~

~, 16.~ Encipher data (C151 15 Steps 16.8 and 16.9 are repeated as necessary until a total of N bytes of data (Ul~ have been processed from RWM. (A short block, if one occurs, and chain- ~ ~-ing linkages are handled internally by the DES Unit~

: 16.lQ Read fin~l 8 ~ytes of data from the DES Unit ~ .
into the S-Resister ~C16,C5~ :
; Ls-REGIsTER ~ SCKA,U)] ~ ~

:

STEP

17.1 LOAD ~R~MAG N).

17.2 Set U/D to 1 17.3 Set R~ for non-inverting read operation (C9,C14~

17.4 Set IMPX ADDRESS to 1 17.5 Increment R~MA~ :

17.6 Read data byte from RWM to comparator Q input (Clll 17.7 Read data byte from S-Register to comparator P~ :
input (C171 ~

17.8 Test S2 (S2=01., go to step 17.5 if additional :`
bytes of S(KA,Ul~ remain to be tested; else, go to step 1 18.1 LOAD (RWM~G : N) 18.2 Increment RWMAG by 8 (R~MAG ~ N 1 8 ) ::

18.3 Load N~8 into Microprogram Controller 18.4 RESET (RWMAG ~ O~

18.5 Load Key KB into DES Unit ~C8,C13) 0 18.6 5et R~M for non-inverting read operation (C9,cl~

~ t STEP

18.7 Load 8 bytes of U data from RWM into DES Unit (Cll,C14~

18.8 Encipher data ~C15) Steps 18.7 and 18.8 ar~ repeated as necessary until N+8 bytes of U data have been processed. (A sho.rt block, if one occurs, and chainin~ linkages are ~ handled internally by the ~ES Unit).

-. 18.9 Read ~inal 8 bytes from DES Unit into the :; 10 S-Register CC16,C5) ; ~S-REGISTER ~ S(~B,U)]

,: 19 19.1 LOAD ~RWM~G ~ N~

; 19.2 Increment RWMAG.by 8 (RWMAG t N+8 19.3 Load N+8 into Microprogram Controller 19.4 RESET

19.5 Set U/D to 1 19.6 Load key KB into DES Unit (C8,C131 19.7 Set RWM for inverting read operation (C9,C10) 19.8 Load 8 ~ytes of inverted U da~ta from RWM into DES Unit (Cll,C14 19.9 Enciphe~ data (C15 - .
, STEP
Steps 19.8 and 19.9 are repeated as necessary until N~8 bytes of U data have been processed.
(A short block, if one occurs, and chaining linkages are handled internally by the DES
Unit~.

19.10 READ FINAL 8 bytes from DES Unit into the S-Register (C16,C5) ~S-REGISTER ~ SCKB,~U~]

Set VRDY to 1 21 Set IMPX ADDRESS to 3 Test RQV:
I~ 0, hold If 1, continue 22 Read 8 bytes of V data from S-Register to Host CPU ~C17,C18 23 Clear A- and B-Registers (C7 24.1 CLEAR (Handshake control output lines cleared to 0~

24.2 Go to step 2 From the above detailed Operational Sequence List for the Verify Unit, it is ~elieved that the operation of the o~erall system will be clearly apparent to those skilled in the art. Specific Operational Sequence Lists were not given for the Terminal Unit or for the Host CPU since these units are essentially well known in the art.
Slmilarly, how to program such hardware to perform the various operations set forth in the flow chart o~ FIGS. 5A through 5G is well known. For example, within the terminals, the various operations required could easily be controlled by hardware dedicated key~oard operations or could be done via a microprogram controller such as utilized in the ~erify Unit.

Similarly, within the Host CPU, the actual opera-tions performed are a relatively simple and straightforward list of fetches, data requests and the transmitting of messages ~etween the User B
and the Host upon command and it is believed that such functions are notoriously old per se and that, given the present flow charts, programming for such a veriftcation routine would be extremely straightforward and would vary only with the particular Host CPU architecture, program language, etc., involved.

Industrial Applicability Th~ uses of the herein disclosed transaction Yerification in the modern day business environ-ment could be manifold. As has been reiterated herein, the system assu~es virtually a foolproof method o~ guaranteeiny both the identity of the Yos77-06s sender or originator of a message insofar as a receiver is concerned, while at the same time guaranteeing the integrity of the message to the original sender. This allows the utilization of long distance telecommunications facilities for the real time completion of transactions which could only be performed in the past utilizing much more time consuming and conventional methods, such as electronlc mail or by actually having people meet to consummate various transa~tions.

Thus for example, legally bindin~ contracts could be effected by having both parties to the contract send an additional data or message portion to the other, each having his own uniaue signature `15 appended thereto, plus each party to the trans-action would have his own resident copy of the contract, electronically signed by the other party and wherein the actual wording of the contract would be veri~iable at any time in the future, if a conflict arose and allegations were made that the wordings were at variance.

; Similarly, long dis~ance highly verifiable pur-chase orders could be made between individuals where, due to the nature of the transaction, or th~ amount of money involved were great, t~e receiver of such a message would not normally act until the identity of the sender were ir-reyocably established.
,~
The system could also have applicability for such 0 a commercial purpose as telephone ordering (i.e., local termin~l2 by an individual from a large, centrally located store, wherein both ordering and funds transfer could be handled in a highly reliable manner utilizing various aspects of the presently disclosed system.

In short, any area where the :Ldentity of the sender and the actual content of the transmitted message must both be ~irmly established would be possible candidates for use of the present invention.

In summary, the present system, as disclosed, prevents masquerading by any party (not having access to the secret keys) even though he has access to eavesdropping equipment over the line.
It also prevents the gathering of any useful in-formation via eavesdropping which could be sub-sequently used to bypass the present security system. The only actual data which could be obtained by an eavesdropper which might or mi~ht not prove useful would be t~e actual message content o~ the unencrypted portions of the message, i.e., from User A to the Host CPU during the initialization portion of the procedure. It will be readily understood that this could be easily avoided by utilizing further cryptographic trans-mission security via the system hardware alreadypresent in the system. In such cases all messages would be transmitted using an overall system message transmission key ~KT~ known to all users and the CPU but not presumptively to an eaves-dropper. Such encryption would be superimposed onthe message protocol descri~ed herein as will be well understood by those skillad in the art.

It should also be understood that while the present invention has been specifically set forth and described with reference to a preferred embodiment, it will be readily appreciated by those skilled in the art that many changes in form and detail may be made without departing from the spirit and scope of the present invention as set forth in the appended claims.

yog77-068 r~

Claims (17)

The embodiments of the invention in which an exclusive property or privilege is claimed are defined as follows:

1. A method for effecting a high security trans-action verification operation in a computer based communications system comprising a central Host CPU which includes a high security Verify Unit (VAULT) therein said system in-cluding at least two remotely located ter-minals selectively connectable to said Host CPU and wherein said Verify Unit and each of said terminals includes substantially identical key-controlled block cipher cryptographic devices with block chaining included therein said method comprising:

User A (originator) at a first terminal sending User B (receiver) at a second ter-minal a message M having a data portion (X) and a signature portion (Y) said signature portion being a block cipher function of A's key KA and the data portion (X), such that M = (X,Y);

User B on receipt of the message (X,Y) re-encrypting same under his own key KB to form a message U, sending said message U to
1. Claim 1 Continued the Host CPU together with the identities of User A and User B (originator, receiver), and requesting a verification operation from said Host CPU, the Host CPU, after receiving said message, obtaining the keys KA and KB from a secure storage means and decrypting U under key KB
   to obtain message U which presumptively comprises a message portion U1 and a signa-ture portion U2;
   
   the Host CPU then forming a signature utiliz-ing U1 as the data input and KA as the key input to the cryptographic device and comparing this signature with the signature value U2 received from User B, and the Host CPU returning an accept/reject signal to User B depending upon whether or not the two signatures are identical.
2. 2. A method as set forth in claim 1 wherein, after determining the validity of the received signature U2 the Host CPU then generating a new signature V for the received message U
   which is a predetermined function of the key KB and the previously decrypted message u depending upon the result of said signature comparison operation, and sending the message V to User B;
   
   User B on receipt of the message V computing a signature V' which is a predetermined function of his own key KB and the message (X,Y) in-itially received from User A and comparing same with the message V for correspondence.
3. 3. A transaction verification method as set forth in claim 2, including said Verify Unit utiliz-ing the data ~ U (the logical complement of U) for generating the signature message V when a valid signature from User A is to be acknowl-edged and utilizing the data U to produce the signature V when the signature for User A is found to be incorrect, and said User B utiliz-ing the data ~ (X,Y) (the logical complement of X,Y). to produce the signature message V' and comparing V' with the signature message V
   received from host CPU.
4. 4. A transaction verification method as set forth in claim 2 whereby the security of the in-dividual user keys KZ is maintained by storing all said individual user keys in the Host CPU
   under a master system key KHV and accessing *
   a particular encrypted key KZ belonging to an identified User Z from the Host CPU memory and decrypting same under said master key KHV
   in the said Verify Unit.
5. 5. A transaction verification method as set forth in claim 4 including utilizing a master system transmission key KT for all communications between Users and between any User and the Host CPU subject to eavesdropping and wherein said transmission encryption operation is superimposed upon all messages between such system entities wherein all messages must first be encrypted under the system trans-mission key KT before transmission and de-crypted under said transmission key KT upon receipt from another unit.
6. 6. A method for transaction verification as set forth in claim 4 including forming all sig-natures in the present system by selecting as said signatures a predetermined final number of bytes of the block chained encryption of the full data input to said key controlled block-cipher cryptographic device with chaining wherein said signature is a direct function of and fully dependent upon the entire content of the data input to said cryptographic device.
7. 7. A transaction verification method as set forth in claim 2 including the User A forming the initial message M utilizing the unique counter value from his own terminal (CTorig) a unique counter value (CTrec) obtained from the receiver's (User B) terminal and, the current date and utilizing this information as a header on the message (X) and said User B, upon receiving said initial message, checking the date, and the value of the counter CTrec for correspondence with a stored value which was previously sent User A upon the initial contact between User A and User B and abort-ing said transaction if either of said values fails to agree.
   
   8. A transaction verification method for use in a computer based communication system com-prising a central Host CPU which includes a high security Verify Unit therein said system including a plurality of remotely located terminals selectively connectable to each other and to said Host CPU via said com-munications system and wherein said Verify Unit and each of said terminals includes substantially identical key-controlled block-cipher cryptographic devices with block chaining, said method comprising User A
   (originator), at a first terminal sending User B (receiver) at a second terminal a message M having a data (X) portion and a signature portion (Y) said signature portion being a block-cipher function of User A's key KA and the data portion (X) such that: M =
   (X,Y);
   
   User B on receipt of said message M reen-crypting said entire message M under his own key KB to form a message U, sending said message U to the Host CPU together with the identities of User A and User B and request-ing a verification operation from said Host CPU;
   
   the Host CPU, upon receipt of said message from User B, requesting a verify operation from its associated Verify Unit and providing the message information U to said Verify Unit;
   
   said Verify Unit obtaining the keys KA and KB from a secure storage means located in said Host CPU and decrypting U under key KB
   to obtain message U which comprises a data
8. Claim 8 continued portion U1 and a signature portion U2, the Verify Unit then forming a signature utiliz-ing the data portion U1 as the data input and the key KA as the key input to its associated cryptographic device and comparing the signature so generated with the signature value U2 received from User B, said Verify Unit after determining the validity of the received signature U2 then generating a new signature V for the message U which signature is a predetermined function of the key KB and the previously decrypted message U the particular function being dependent upon the result of said signature comparison operation and sending the message V to User B;
   
   User B upon receipt of the message V com-puting a signature V' which is a predeter-mined function of his own key KB and the message (X,Y) initially received from User A
   and comparing same with the message V for correspondence; and wherein all signature generation operations in the previous enumerated signature gen-erating steps comprise selecting as said signatures a predetermined final number of bytes of the block chained encryption of the full data input to said associated key-controlled block-cipher cryptographic devices with chaining wherein each said signature is a direct function of and fully dependent upon the entire data content supplied to said cryptographic device.
9. 9. A transaction verification method as set forth in claim 8 wherein the individual User keys KZ are stored in the Host CPU
   system memory in encrypted form under a Verify Unit master key KHV and said individual keys are obtained from said Host CPU by the Verify Unit by accessing said Host at addresses derived from the identities of the Users A and B supplied to said Verify Unit, and decrypting said keys under the master key KHV to obtain the original User's keys KA and KB.
10. 10. A transaction verification method as set forth in claim 9 including User B
    supplying to User A a counter value CTrec when User B is first contacted for a transaction by User A, and User B con-currently storing in a local memory said counter value CTrec, User A forming the initial message M utilizing the unique counter value from his own terminal CTorig, the counter value CTrec previously obtained from User B's terminal and the current date as a header on the transaction message (X) and said User B, upon receiving said initial message M, checking the date and the value of the counter CTrec for correspondence with said stored value and aborting such trans-action if either the date or the counter values fail to agree.
    
    11. A computer based communications system having a high security transaction verification feature incorporated therein, said system comprising a Host CPU which includes a high security Verify Unit therein, said system further including a plurality of remotely located terminals including means for selec-tively connecting each terminal to said Host CPU or to another terminal via the communi-cations network associated therewith, said Verify Unit and each of said terminals including substantially identical key-controlled block-cipher cryptographic devices equipped with a block chaining feature, each terminal including means actuable when said terminal is used as an originating device (Terminal A) in a transaction to send a message M to another terminal acting as a receiver (Terminal B) said message M having a data portion (X) and a signature portion (Y), means for actuating the cryptographic device located in said terminal to form said signature (Y) as a block-cipher function of Terminal A's key KA and the data portion (X) such that M = (X,Y);
    
    means in the receiving terminal (Terminal B) actuable on receipt of the message M from (Terminal A) for reencrypting said message under the terminal's own key KB to form a message U and means for sending said message U to the Host CPU together with the iden-tities of the originating and receiving terminals (Terminal A and Terminal B) and means for requesting a verification operation from said Host CPU;
    
    means in said Host CPU actuable upon the receipt of said message for obtaining the
11. Claim 11 continued.
    
    keys KA and KB from memory and fox requesting a verify operation from the Verify Unit associated therewith;
    
    means in said Verify Unit for decrypting the message U under terminal B's key KB to obtain a decrypted message U which comprises a message portion U1 and a signature portion U2, means in said Verify Unit for forming a signature utilizing U1 as a data input and the originating terminal's key KA as the key input to the cryptographic device contained therein and means for comparing the signature so generated with the signature value U2 received from terminal B;
    
    means in said Verify Unit for returning an accept/reject signal to receiving terminal B
    depending upon whether the two signatures are identical.
12. 12, A communication system as set forth in claim 11 wherein said means in said Verify Unit for returning an accept/reject signal to the receiving terminal B comprises means for generating a signature V including means for supplying the decrypted data message U, previously received from terminal B as the data input to the cryptographic device in the Verify Unit, and for supplying the key KB as the key input to said cryptographic device and means for transmitting said derived signature V to the terminal B;
    
    means in said terminal actuable on receipt of the signature V to generate a signature V' using the logicl complement of the original message M as the data input to said terminal's cryptographic device and the terminal B's key KB as the key input to said device and means for comparing the generated signature V' with the signature V received from the Verify Unit.
13. 13. A communication system as set forth in claim 12 wherein said means for generating the signature V within the Verify Unit comprises means actuable in response to the comparison between the signatures U2 and that generated from U1 and KA to supply the logical com-plement of U to the encryption device in the Verify Unit upon a successful comparison and for supplying the true value of U to said encryption device if said comparison is unsuccessful.
14. 14. A communication system as set forth in claim 13 including key storage means in the Host CPU fox storing all of the individual user keys KZ in system memory in encrypted form under a master storage key KHV which is resident in a high security storage means within the Verify Unit;
    
    means for generating key storage addresses based on the identity of the particular terminals involved in a given transaction and for transmitting accessed, encrypted keys KZ
    to the Verify Unit and means operative therein to decrypt said keys to obtain the actual keys for use in the transaction verification operations.
15. 15. A communication system as set forth in claim 14 including transmission encryption means resident in all terminals of said system and in the Host CPU for encrypting all messages transmitted between terminals and between a terminal and the Host CPU under a master transmission key KT and means for decrypting all received messages under said same en-cryption key KT.
16. 16. A communication system as set forth in claim 14 including means associated with the cryptographic device in said terminals and said Host CPU for forming all signatures utilized within the system by selecting a predetermined final number of bytes of the encrypted output of said cryptographic devices said output being derived from the entire data message input to said cryptographic device whereby said signatures are dependent upon the entire data message being encrypted.
17. 17. A communication system as set forth in claim 12 including counter means resident in each terminal for producing a time dependent count value and means for including a predetermined current count value of the counters in both the originating and re-ceiving terminals as a part of a message header which is incorporated in the data portion (X) of the message M transmitted from the originating terminal A to the receiving terminal B, means resident in each terminal for placing a quantity indicative of the date of a particular transaction as a portion of the header in any message M transmitted to another terminal, and means within each terminal for verifying the proper relation-ship of the count values and date for any received message wherein a transaction verification is to be requested.