text:
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.
|Transaction execution system with secure encryption key storage and communications
|Anderson et al.
|Secure communication system with remote key setting
|Identity verification method and apparatus
|Lancto et al.
User A (originator) at a first terminal sending User B (receiver) at a second terminal 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) reencrypting same 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 (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 signature portion U2 ;
the Host CPU then forming a signature utilizing 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.
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) initially received from User A and comparing same with the message V for correspondence.
User B on receipt of said message M reencrypting 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 requesting 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 portion U1 and a signature portion U2, the Verify Unit then forming a signature utilizing 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 computing a signature V' which is a predetermined 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 generating 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.
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 identities 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 keys KA and KB from memory and for 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.
means in said terminal actuable on receipt of the signature V to generate a signature V' using the logical 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.
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.
1. Technical Field
The present invention relates to a high security communication system including a plurality of users or terminals connected to each other via a common communication link which is in turn connected to a Host CPU. By means of the present system it is possible for a sender A to communicate a specific transaction to a user B with an extremely high degree of integrity or confidence in the transaction. Utilizing the present system the following threats to transaction integrity may be substantially eliminated.
The first threat is reneging, wherein the sender engages in a transaction with a receiver sending data which he may subsequently attempt to disown. Thus, the receiver must know with certainty that the sender sent the specific message which fact may be proven subsequently.
A second possible threat to such a system is forgery, wherein the receiver may allege that he received a message from a given sender, which message is a fabrication, thus, it must be possible for the sender to prove that the supposed message was in fact a forgery.
A third threat is similar to forgery namely that of alteration, 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 further 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 manipulation of the operating system, such as by eavesdropping and the capture and resending of stale messages or the fabrication of "approval" signals from the CPU, etc. The system must thereby guarantee B that such penetration is not possible. A final threat is masquerading, wherein a user on the system would attempt to masquerade as a different 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 are linked to the host telecommunication system in common and that their messages are enciphered by a common encipherment process. Accordingly, the integrity of the communication's security, or lack of it, will play no role in the verification of transactions.
There are many potential uses for such a system in the modern business community. Potential applications are in the area of stock market transactions carried out over the communications systems, automatic banking transactions, electronic mail and/or any other system in which digitalized messages are sent and received over public communications channels and wherein the integrity of both the messages and the originators must be absolutely guaranteed.
It is accordingly a primary object of the present invention to provide such a high security communication system wherein both the transaction content and the signatures of senders may be completely verified and wherein all of the above enumerated threats may be substantially eliminated.
It is a further object 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 system.
Other objects, features and advantages of the system will be apparent from the subsequent description of the system and claims.
2. Background Art
The following publications all relate to various types of electronic or digital signature systems generally using various types of approaches to achieve 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 Certification by Coding," IBM Technical Disclosure Bulletin, Vol. 20, No. 8, pp. 3337-8, (January 1978). (2) W. Diffie, M. Hellman, "New Directions in Cryptography," IEEE Trans. on Information Theory (November 1976). (3) R. L. Rivest, A. Shamir and L. Adleman, "On Digital Signatures and Public-Key Crypto-Systems," M.I.T. Laboratory for Computer Science Report, MIT/LCS/TM-82 (April 1977).
FIG. 1 comprises an overall block diagram of the high security communication system of the present invention.
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 functional block diagram of 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 comprise a detailed functional block diagram of the Verify Unit Controller block shown in FIG. 3B.
FIG. 5 comprises an organizational drawing for FIGS. 5A through 5G.
FIGS. 5A through 5G comprise a detailed operational flow chart illustrating the operation of the herein disclosed high security communications system.
For a better comprehension 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 mode configuration.
As stated generally 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 following features. The User A must provide with the message D some information, 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 system 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 by the originator A. Further, the verification process must be uneffected by 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 recipient B, or by some third party eavesdropping 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 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 Algorithm for Computer Data Protection." The standard together with a complete technical description is contained in the publication, "Data Encryption Standard," 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 invention, the above-referenced system is preferred.
Further, the particular cryptographic system used must incorporate data chaining. Chaining is introduced to make each bit of the signature S functionally dependent upon each bit of the data. For the description of such a block-chaining system, reference is made to U.S. Pat. No. 4,078,152 of L. B. Tuckerman entitled, "Block-Cipher Cryptographic System with Chaining."
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 8 bytes) by the DES encryption system using chaining with the key K. In the following description the subscript A in (KA) denotes the particular private key of the User A. The inverse operation or decipherment (π-1) is denoted by the following formula: ciphertext π(K,D)π-1 (K,π(K,D))=D cleartext
The following description is essentially a description of the protocol involved or method by which the present invention is realized. For purposes of this description FIG. 1 may be referred to. It will be noted that the overall system shows a number of terminals or users connected over a data 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 KX 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 π(KHV,KA)=KA*
In the above formula symbol KA refers to User A's personal key and KHV is the Verify Unit master key as indicated above. The result of all computations are stored in the regular Host CPU's memory in the following format:
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 signature for data D by any User A which is denoted by the symbol S(KA,D) is the final 8 bytes 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 predetermined format which will be set forth more fully subsequently.
There will now follow a description of the transaction 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.
The verification device which is denoted herein as the Verify Unit is located in the Host 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 data 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 signature represented as follows: S(KA,D)
wherein the data D is defined by the following formula:
D➝"User A to User B on Feb. 28, 1977, CTori, CTrec --Buy 100 shares of . . . " Upon completion of the generation of the signature S, A sends the pair: (D,S(KA, D))
to User B.
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 transaction, i.e., A and B; the date of the transaction, i.e., Feb. 2, 1977; 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,S(KA,D)) will be 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(KA,D).
Proceeding now with the description of the protocol, 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 data information is current.
User B is identified in the prefix as the recipient.
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 enciphers the entire message pair (X,Y) with User B's own individual key KB to form a message U, which is defined as: U= (KB,(X,Y))
After enciphering the message U, User B transmits same to the Host together with the names A and B of the originator and recipient of the transaction.
The special purpose verify hardware resident in the CPU when supplied with the parameters A, B and U which have just been received from the User B will proceed to perform the following operations.
Utilizing the identities A and B the CPU will cause 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* = (KHV,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 decipher the two values and determine the user keys KA and KB internally of the Verify Unit and appropriately store these in holding registers therefor, as will be explained subsequently.
The Verify Unit next deciphers the message U under its original encipherment key KB internally. This is represented by the formula U= -1 (KB,U). The system then treats the deciphered message U as two different parts U1 and U2 wherein U1 =U[1,n] U2 =U[n+1,n+8]
In the above formulas it will be noted that U1 is the first n bytes which correspond to the data portion of the message X as originally transmitted and the portion U2 is 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 time 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 agreement of the signatures and if C=0 it is assumed that there is no such agreement.
Assuming C=1 the verify portion of the system will cause a signature to be derived for the logical complement of the concatenation (U1,U2), this logical complement being denoted by .about.(U1,U2), using the DES encryption system under chaining with the key KB. The resulting verification message V will be returned to User B wherein: V=S(KB,.about.(U1,U2))
or if C=0, the verify portion of the system will cause a signature to be derived for the concatenation (U1,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(KB,(U1,U2))
At this point it should be noted that the operation of the Verify Unit is shown as performing a comparison 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 by the CPU and the Verify Unit.
As previously stated, regardless of the result of the comparison, i.e., C=1 or C=0, the Verify Unit will derive a signature V based on (U1,U2) utilizing DES and the key KB. 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 (presumptively equal to (D,S(KA,D)) was properly signed.
Upon receipt of the message V, User B will calculate a new signature defined by the following formula: V'=S(KB,.about.(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 transaction 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 previously upon receipt of the initial transaction from User A. The final requirement, and the most critical is the receipt of a valid verify signal from the CPU, i.e., V=V'.
It should be noted that in each case the signatures V and V' are the last 8 bytes of the total encryption of the indicated data contents 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 (X,Y) where Y is claimed to be the signature of X by User A. The arbiter will decide that the transaction is valid if and only if: Y=S(KA,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, masquerading as User A, retransmits a previously verified (and accepted) transaction to User B. The "time stamp" imposes the protocol that no two messages will be accepted if they have identical time stamps, thus, eliminating this attempt at subversion of the transaction system.
Having 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 configuration capable of performing this protocol.
FIG. 1, as stated briefly before, comprises a broad functional block diagram of the overall system wherein a plurality of terminals are shown connected via a data communication system to a centrally located Host CPU. A Verify Unit (VAULT) is directly connected to the Host CPU and may in fact be embedded therein. It is referred to as the VAULT to indicate the very high security nature of the hardware contained therein, it being clearly understood that only the system manager with special authorization should ever have access to any of the internal information stored in said VAULT and that the security of the system is limited by the security of the personnel having access thereto. This 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 majority 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 different users having different user keys KX could utilize a single terminal in accordance with the teachings of the present invention it being understood that their particular keys would either have to be entered at the keyboard or suitably accessed from the System Memory. The unique devices required of the terminal for practicing the present invention are a Programmable Timer which would be utilized to produce the counter values CTrec and CTori mentioned in the previous description 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. Pat. 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 in a straightforward manner when provided with an encryption key K and a data block to be encrypted. Given this data the DES block will automatically produce encrypted (π) or decrypted (π-1) 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 Controller is a back up storage device associated with the terminal unit 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 understood that User A and User B in the present description, refer to the originator and recipient 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 of the terminals are extremely straightforward and well known as is the case with the Programmable Timer and also the Data Security Module.
Referring now to FIGS. 3A and 3B, the primary functional units of the Verify Unit 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 previously with respect to the description of FIG. 2, is a key controlled block 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 be encrypted or decrypted, and finally, an indication of whether an encryption or decryption cycle is required. Control lines C13, C14 and C15 control the 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 B) key in either clear or encrypted form.
The block entitled, Read Write Memory (RWM), essentially stores the received complete messages transmitted by the system. The KHV Register stores the Verify Unit's master key under which all of the user keys KX are stored in the Host CPU's master memory, in encrypted form in the previously described * Table. When these encrypted keys are sent to the Verify Unit they are decrypted utilizing the master encryption key KHV to access the actual keys, i.e., KA and KB in the present illustration.
The Comparator block performs the exclusive function of comparing signatures on demand and will produce a one (1) or a zero (0) on its output line, depending 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 wherein the various signals utilized are shown on the left 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 (S1, S2) and five handshake signals (RQVRF, . . . ,URDY). The Verify Unit is under control of the command structure 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 Verify Unit Controller is shown in more detailed form in FIGS. 4A and 4B.
The functional units in the Verify Unit designated as CP1 through CP18 are referred to by digital design engineers as control points. Their operational 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 functional standpoint, however, they may be simply considered as gate circuits having the multiplexing function indicated by the bit configurations entering and emanating from each control point. Each of the control points CP1 through CP18 are indicated as being controlled by control line C1 through C18. For example, control point CP2 takes seven consecutive 8 bit bytes and places them in seven consecutive 8 bit storage registers in the functional unit denoted as the A-Register (a total of 56 bits). Similarly, the control point CP6 does just the opposite. That is, it takes 7 consecutive 8 bit bytes from the A-Register and reconverts them into a series of seven 8 bit bytes 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 CP11 merely performs a gating function. It will be noted that the Read/Write Memory (RWM) is organized in 8 bit storage locations, accordingly the control points, CP4, CP10 and CP11 need not perform any multiplexing/demultiplexing functions as described previously.
The details of the Control Point Units are not specifically shown as they would be obvious to a digital design 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 Units.
|VERIFY UNIT CONTROL POINT FUNCTIONAL DEFINITION TABLE Func- tional Con- Unit trol Con- Signal trolled Operation Controlled
Referring now to FIGS. 4A and 4B the details of the hardware configuration of the Verify Unit Controller 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 particular 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 signals 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/Verify Unit Handshake Control Definition Table is included for convenience of reference.
|HOST CPU/VERIFY UNIT INTERFACE DEFINITION TABLE Handshake Signal Function
RQVRF Inform VU of request for verification
RQV Inform VU of request for derived sig-
nature V
KA*RDY Inform VU that KA* data are ready for
KB*RDY Inform VU that KB* data are ready for
URDY Inform VU that U data are ready for
BUSY A flag indicating Verify Unit status
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 signature V is ready
for transfer
The Control Word Register clearly indicates the format of the instructions stored in Micro Program Memory and utilized by the system. The six specified fields are believed to be self-explanatory. The next address select, IMPX address, and branch address have just been described. The handshake control field comprises six bits, three of which address the five bit 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 value 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 Chart). RQU is associated with output line 3 of the 5-bit addressable latch. The 3 "address" lines are set to "011" (binary 3), the "data" line is set to 1, and the "enable" line is set to 1 (momentarily) thereby causing output line 3 to take on the binary 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 described 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 of 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 functional number of the Control Point Units requiring a plurality of inputs. Finally, the R/W Memory Address Generation field, has a five bit field which controls the R/W Memory Address Generator block 18. This block actually contains two functional units, a twelve bit bidirectional counter and a storage register for saving desired counter settings or addresses. The counter supplies an ascending sequence of memory addresses to the RWM unit to enable it to store the remaining string of message bytes making up a particular message which are received by the Verify 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 generation field of the Control Word Register perform selectively the following functions.
The "reset" line causes the counter to be reset to all zeros. The "load" line causes the current contents of the storage register mentioned previously to be loaded into the counter. The "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 whether, depending on the given operational sequence the counter is being incremented or decremented respectively. When the save line is 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/W 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.
This essentially completes the general description of the presently disclosed transaction verification system. It should be noted that the various operations required of the Host CPU would conventionally be performed by straightforward programming means. The functions required of the CPU are essentially those of setting up communication paths between the 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 Verify Unit together with the following description of 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 the 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 between the various operational sequences comprising the present transaction verification system. Each of these arrows in effect represents a handshaking operation which is required of the present system, wherein control passes from 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 handshaking operations is clearly apparent in the operational sequence charts.
Referring now to the system flow diagram which describes a complete Transaction 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 B 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 operational protocol of the system. It is believed that reference to this table of definitions will greatly facilitate an understanding of the following description of the flow chart.
1. M: message (i.e., Busy 50 shares RDQ common . . .)
2. D:data: (A, B, 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 KA.
4. (X,Y): the message received from User A,
presumptively equal to (D,S(KA,D).
5. CT: a current counter value at a particular
terminal (orig/rec)
6. KA : User A's key - KB : User B's key
7. KHV : Verify Unit's master key
8. KZ *: π(KHV, KZ), i.e., for any user Z
9. π/π-1 : encryption/decryption under an encryption
10. U = π(KB, (X, Y))
11. --U = π-1 (KB,U) = ( --U1, --U2)
12. --U1 = --U[1,n]: - --U2 = --U[n + 1,n + 8]
13. V = S(KB, --Uor S(KB, .about. --U) = last eight bytes
the chained encipherment of U by DES using the
key KB
14. If S(KB, .about. --U) = S(KB .about.(X,Y)) then
signature of A
is valid for message X.
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.
In may be assumed, beginning in FIG. 5A that User A wishes to initiate a transaction utilizing the present transaction verification system. User A's terminal begins operation as indicated in block 1 and a determination is made as to whether a transaction is being initiated. If not the system proceeds to block 2 where a test is made as to whether a transaction request has been received, 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 for User B. Thus, the "originator"/"receiver" modes are both present in every terminal although only one would be operative during any given transaction.
If the answer to the test made in block 2 is "no" the system would branch back to the beginning and continue cycling through blocks 1 and 2 in a "wait" state until either User A decides to initiate a 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 1 of User B. As will be apparent a branch to block 2 will then occur when it is determined that a transaction request has been received from User A. At this point the User B sequence proceeds to block 3 which, in fact, 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: "indentity 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 same time it is determined whether or not the counter value from User B has been received (CTrec).
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 Table). The sequence proceeds then to block 6 wherein each transaction message for transmission to User B is constructed which comprises the message pair (X,Y) the specific contents of which are clearly shown and defined in lines 2, 3, 4, 5 and 6 of the Definition Table. At this point, control transfers to the User B sequence, Block 4.
The receipt of the complete transaction message from User A causes the system to proceed to blocks 5, 6 and 8 wherein three straightforward data content tests are made, i.e., for the date, the correct addressee, i.e., User B and the proper counter value which it will be remembered was saved by User 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 further. If everything is correct however, the system proceeds to block 9 wherein the user key KB is provided to User B's DES Module which is a key-controlled block cipher cryptographic unit as described previously and similarly the message pair (X,Y) is made available to the encryption unit as the data to be encrypted, and the entire message pair (X,Y) is encrypted under User B's key to produce the message U, which is defined in line 10 of the Definition Table. The system then 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 verification. As will be remembered the data A and B provide entries to the * Table where 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 effectively cleared to zero. In block 1 the "request for verification" signal 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 wherein a request for a new transaction verification operation (RQVRF) is sent to the Verify Unit. Control then transfers the Verify 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 system 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 Vertify Unit is "busy" in case it should attempt to request a further transaction verification operation.
The system then proceeds to block 4 wherein a request is made for KA *. This request goes back to the Host CPU where it will be remembered the various user keys are encrypted under the system master key KHV in the * Table. This request will cause the RQKA* handshake control output line from the Verify Unit to be set to a one. 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 * Table 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 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 KA * to be read into the A register of the Verify Unit and at this point the RQKA* handshake control output line is reset to zero. 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 blocks 5, 6 and 7 thereof with the exception that in this case the data KB * is extracted 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 block 10 of the Verify Unit sequence wherein a request is made for the data U which has been stored in the Host CPU memory. At the same time the handshake control RQU is set to a "1" in the output from the Verify Unit and control transfers back to block 11 of the Host CPU which receives the request. The Verify Unit waits until the CPU is ready 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 is available and accordingly the handshake control indicated as URDY is set to a one which informs the Verify Unit that the message segment U is available 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 of the Verify Unit the message segment U is read from the Host CPU and stored in the RWM of the Verify Unit and the handshake control output line RQU is reset to a "zero". Block 13 of the Verify Unit causes the originator key KA to be deciphered from the value KA * currently stored in the A register by transmitting KA * plus the system master key KHV to the DES Unit whereby User A's encryption key KA is decrypted and stored 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 block 15 wherein the message U is deciphered under the user key KB and the results are stored in the RWM as U. The definition or specification of the data content of the deciphered message U is shown in block 15A and is indicated as U1 and U2 which are the first n bytes of the deciphered message and the last 8 bytes of the deciphered message respectively. As will be remembered from the prior definition of the signature, these last 8 bytes or U2, are presumptively equal to the signature of User A. To verify 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 U1 as the data source for the signature. Thus, if U1 has been truly received as the original message X, 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 U2. This comparison is made in block 17 and if 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 performed. 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 U or of .about.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 .about.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 by the Host CPU activates block 14 of the Host CPU which is informed that the signature V is now ready in the Verify Unit. In block 15 of the Host CPU, V is requested by setting the handshake control input line RQV to a "1" which actuates block 20 in the Verify Unit. In block 22 of the Verify Unit and block 16 of the Host CPU the message V is sent from the Verify Unit to the CPU and in block 17 of the CPU's sequence the derived signature V is transmitted 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 breifly 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 resetting 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 V is ready to be transmitted from the Host CPU. At this point, appropriate control is actuated and the message V is in effect read from the Host CPU in block 12 and in block 13, User B constructs the signature of the logical complement of (X,Y) denoted by .about.(X,Y) under his own key KB which as will be remembered, comprises the last 8 bytes of the encryption of message .about.(X,Y) under the key KB. This generated signature is compared with the message V, which was received from the Host CPU in block 14 of the User B sequence. The test made in this block and its consequences are implied in line 14 of the Definition Table.
It should be noted in passing that, providing the entire system is operating properly, and no messages 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 having confidence that he has been communicating with the true User 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 characteristics will be well understood by those skilled in the art.
There will now follow a detailed exposition of the operation of the Verify Unit controls in the form of an Operational Sequence List for the Verify Unit. This list comprises a sequence of the individual operations which would conventionally be performed by micro code stored in the microprogram memory of the Verify Unit which operations must be performed to practice the herein disclosed preferred embodiment of the invention. Referring to these operational sequence lists which are numbered in accordance with the blocks of the flow chart the discrete operations carried 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 Sequence List which defines the various acronyms or abbreviations utilized.
|Operational Sequence List for Verify Unit
RWM: Read/Write Memory
RWMAG: Read/Write Memory Address Generator
IMPX: Input Multiplexer
DES Unit:
Data Encryption Standard Unit
(Ci): i-th Control Point, activation of
RESET: RWMAG set to zero
LOAD: Contents of internal storage register are
loaded into RWMAG
COUNT: Enables RWMAG to count
U/--D: Up (1) /down (0) count-mode control for RWMAG
SAVE: Contents of RWMAG are saved in internal storage
CLEAR: All handshake control output lines are
cleared to zero
2 Set IMPX ADDRESS to 2
If 0, hold;
If 1, continue
3 Set BUSY to 1
4 Set RQKA* to 1
5 Set IMPX ADDRESS to 4
If 0, hold
If 1, continue
6.1 Load A-Register with KA* from Host CPU. (C1,C2)
6.2 Clear RQKA* to 0
7 Set RQKB* to 1
8 Set IMPX ADDRESS to 5
9.1 Load B-Register with KB* from Host CPU. (C1,C2)
9.2 Clear RQKB* to 0
10 Set RQU to 1
11 Set IMPX ADDRESS to 6
Test URDY:
If 0, hold
If 1, continue
12.2 Set U/--Dto 1
12.3 Set RWM for write operation (C9)
12.4 Set IMPX ADDRESS to 6
12.5 Load one data byte of U from Host CPU to RWM
via Input-Bus (C1,C4)
12.6 Test URDY:
If 1, increment RWMAG and go to step 12.5;
If 0, continue
12.7 Clear RQU to 0
13.1 Load key KHV into DES Unit (C12,C13)
13.2 Load data from A-Register (KA*) into DES Unit
13.3 Decipher data (C15)
13.4 Read 7 bytes of data (KA) from DES Unit into
A-Register (C16,C2)
14.1 Load key KHV into DES Unit (C12,C13)
14.2 Load data from B-Register (KB*) into DES Unit
14.3 Decipher data (C15)
14.4 Read 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/--Dto 1
15.6 Set RWM for read operation (C9,C10)
15.7 Load 8 bytes of U data from RWM into DES Unit
15.8 Decipher data (C15)
15.10 Set RWM for write operation (C4, C9)
15.11 Store 8 bytes of --Udata from DES Unit in
Repeat steps 15.5 through 15.11 as necessary
until N + 8 bytes of U data have been processed.
16.1 Decrement RWMAG by 8 (RWMAG N)
16.3 Load N into Microprogram Controller
16.5 Set U/--Dto 1
16.6 Load Key KA into DES Unit (C6,C13)
16.7 Set RWM for non-inverting read operation
16.8 Load 8 bytes of --U1 data from RWM into DES Unit
16.9 Encipher data (C15)
Steps 16.8 and 16.9 are repeated as necessary until
a total of N bytes of data ( --U1) have been processed
from RWM. (A short block, if one occurs, and chain-
ing linkages are handled internally by the DES Unit). -
16.10 Read final 8 bytes of data from the DES Unit
into the S-Register (C16,C5)
Set U/-- D to 1
Set RWM for non-inverting read operation
Set IMPX ADDRESS to 1
Increment RWMAG
Read data byte from RWM to comparator Q input
Read data byte from S-Register to comparator P
input (C17)
Test S2 (S2 = O), go to step 17.5 if additional
bytes of S(KA, --U1) remain to be tested; else,
go to step 19
Increment RWMAG by 8 (RWMAG N + 8)
Load N + 8 into Microprogram Controller
Load Key KB into DES Unit (C8,C13)
Set RWM for non-inverting read operation
Load 8 bytes of --Udata from RWM into DES Unit
Encipher data (C15)
Steps 18.7 and 18.8 are repeated as necessary until
N + 8 bytes of --Udata have been processed. (A short
block, if one occurs, and chaining linkages are
handled internally by the DES Unit).
18.9 Read final 8 bytes from DES Unit into the
S-Register (C16,C5)
19.2 Increment RWMAG by 8 (RWMAG N + 8)
19.3 Load N + 8 into Microprogram Controller
19.5 Set U/--Dto 1
19.6 Load key KB into DES Unit (C8,C13)
19.7 Set RWM for inverting read operation (C9,C10)
19.8 Load 8 bytes of inverted --Udata from RWM into
DES Unit (C11,C14)
19.9 Encipher data (C15)
Steps 19.8 and 19.9 are repeated as necessary
until N + 8 bytes of --Udata have been processed.
(A short block, if one occurs, and chaining
linkages are handled internally by the DES
19.10 READ FINAL 8 bytes from DES Unit into the
S-Register (C16,C5)
[S-REGISTER S(KB,.about. -- U)]
20 Set VRDY to 1
21 Set IMPX ADDRESS to 3
Test RQV:
If 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 believed that the operation of the overall 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. Similarly, how to program such hardware to perform the various operations set forth in the flow chart of FIGS. 5A through 5G is well known. For example, within the terminals, the various operations required could easily be controlled by hardware dedicated keyboard operations or could be done via a microprogram controller such as utilized in the Verify Unit.
Similarly, within the Host CPU, the actual operations performed are a relatively simple and straightforward list of fetches, data requests and the transmitting of messages between 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 verification routine would be extremely straightforward and would vary only with the particular Host CPU architecture, program language, etc., involved.
The uses of the herein disclosed transaction verification in the modern day business environment could be manifold. As has been reiterated herein, the system assures virtually a foolproof method of guaranteeing both the identity of the 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 electronic mail or by actually having people meet to consummate various transactions.
Thus for example, legally binding 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 unique signature appended thereto, plus each party to the transaction 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 verifiable at any time in the future, if a conflict arose and allegations were made that the wordings were at variance.
Similarly, long distance highly verifiable purchase orders could be made between individuals where, due to the nature of the transaction, or the amount of money involved were great, the receiver of such a message would not normally act until the identity of the sender were irrevocably established.
The system could also have applicability for such a commercial purpose as telephone ordering (i.e., local terminal) 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 identity of the sender and the actual content of the transmitted message must both be firmly 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 information via eavesdropping which could be subsequently used to bypass the present security system. The only actual data which could be obtained by an eavesdropper which might or might not prove useful would be the actual message content of 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 transmission security via the system hardware already present 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 eavesdropper. Such encryption would be superimposed on the message protocol described herein as will be well understood by those skilled 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.


text:
On Sunday morning, August 11, hundreds of hungry Angelenos descended upon the historic Vibiana downtown for the third annual LA Weekly Pancake Breakfast! Curated by Evan Kleiman, restaurateur and host of Good Food on KCRW, attendees were treated to samples from over 20 local restaurants. Amoeba was on hand with our prize wheel, making friends, passing out our own (non-edible, I'm afraid) goodies and raising money for the Downtown Women's Center.
Amoebite Michele'le was our pro behind the prize wheel, encouraging people to win "big money" and avoid the "whammy's." For only $1 a spin, folks could win gift certificates to the Natural History Museum of Los Angeles, Stella Barra (the yummy new pizzeria next to Amoeba), surprise gifts and more. For a $5 donation to DWC, people received a complimentary Amoeba tote bag or t-shirt. One amazing woman even donated $25!
It wasn't just about the food on Sunday. Country singer Lynda Kay stopped by after wooing her fans with a performance, posing for a few photos and signing autographs at our booth.
See more photos, including shots of the delicious food that was served, in LA Weekly's slideshow.
All in all, we raised $300 in a few short hours for the Downtown Women's Center. With the Amoeba match, we'll be sending $600 to a very worthy charity. With just $36, Downtown Women's Center can provide a week of basic needs services for 10 women. A $76 donation covers a mammogram for one woman. With $100 they can provide 50 nutritious lunches for women in the DWC Day Center. $260 funds one woman in the DWC 12-week education and job-readiness program. $500 funds three months of 1-on-1 case management for 46 women, providing access to essential resources needed to achieve personal stability.
Thank you to everyone who came out on Sunday and donated money! Together we helped a lot of women in need in Los Angeles.

subset: commoncrawl


text:
London cab firm boycotted by cyclists
London cab firm boycotted by cyclists
It started in early April when John Griffin, head of Addison Lee, writing to his 3,500 drivers, suggested they have a right to use London's bus lanes and offered to pay any fines they might consequentially incur. That move - which comes on top of Transport for London's (TfL) decision to formalise motorcycle access to bus lanes - triggered howls of anger from cyclists.
Why are bus lanes so important for cyclists? Most major roads in the capital have no dedicated facilities for cyclists, but most do have bus lanes which cyclists are permitted to use. Taxis already clog up the bus lanes in the centre of the city; adding yet more motor vehicles undermines their value still further.
Griffin's attempt to occupy bus lanes came in the middle of the Mayoral election campaign, testing the administration to see how firmly it would respond. With just a few months to go to the Olympics, when pressure on London's road network will grow ever more intense, Addison Lee is very keen to escape the inevitable chaos and use the (relative) emptiness of the bus lanes.
Enraging the cyclists
It wasn't just the message asking its drivers to break the law that really angered cyclists. In the company's in-house (and in-car) magazine, Griffin launched an extraordinary and ignorant attack on cyclists.
"Should a motorist fail to observe a granny wobbling to avoid a pothole or a rain drain, then he is guilty of failing to anticipate that this was somebody on her maiden voyage into the abyss. The fact is he just didn't see her and however cautious, caring or alert he is, the influx of beginner cyclists is going to lead to an overall increase in accidents involving cyclists.
"The rest of us occupying this roadspace have had to undergo extensive training. We are sitting inside a protected space with impact bars and air bags and paying extortionate amounts of taxes on our vehicle purchase, parking, servicing, insurance and road tax. It is time for us to say to cyclists you want to join our gang, get trained and pay up."
It is time for us to say to cyclists you want to join our gang, get trained and pay up"
John Griffin, Addison Lee
This rant was systematically picked apart by Simon MacMichael on road.cc while Carlton Reid, the founder of IPayRoadTax.com hounded Griffin on twitter and on the airwaves.
In his column, Griffin appeared not to have understood Rule 213 of the Highway Code which states that drivers need to give cyclists plenty of room for exactly the circumstances he states - "pay particular attention" it says "to any sudden change of direction they may have to make."
Cyclists organised a 'die in' outside the Addison Lee office on the 23 April, at which over 250 people showed up. Thousands more signed an e-petition asking for the Government to revoke their licence to operate. Firms and individuals were urged to boycott the company, which many, including the Government, did.
Meanwhile Transport for London immediately sought and obtained an injunction against Addison Lee's advice to drivers to use bus lanes, which they have subsequently withdrawn. It is expected that later in the year the company will bring a more formal challenge to TfL's exclusion of the company.
Carlton Reid has also succeeded in persuading Addison Lee to take up cyclist awareness training for their drivers.


text:
Enter your rental property address below to get your free rental analysis.
Stress Free Covington Property Management
Owning a residential rental property can be a lucrative investment, but it also carries with it its share of headaches and worries. Finding a skilled Covington residential property manager can save you a lot of time and money.
With our full service Covington property management, you get much more than just one over-worked property manager. You get a full team of skilled professionals with the expertise to provide you with the highest level of service and the maximum return on your investment.
Our Covington area property managers will safeguard your property, manage your tenants, and protect your investment, all without you having to lift a finger. You'll be amazed at how much time and money our residential property management services can save you in both the long and short term.
Our Covington apartment property management services include all necessary maintenance, tenant screening & management, and regular property inspections. Whether you own one unit or many in an apartment building, our Covington property managers can handle it all.
How do we get your home rented quickly?
- Our leasing agents drive branded, wrapped cars and their role is to find and place tenants
- All vacant homes have only Supra lock boxes, insuring only licensed real estate agents can show your home (ask us about this differentiating policy)
- Our average vacancy period is less than 30 days
Please note: We are a performance based company; until we place a tenant, our service is free... That's OUR incentive to get your home rented quickly!
Due to our volume and success, even in this economy, several of our licensed real estate professionals have earned the Board of Realtors coveted Million Dollar Club award for the past 3 years in a row based on tenant placement and finding investors new homes!
Our proven advertising and marketing campaign include the following:
- The branded/wrapped vehicles direct tenants to our website...and often get us stopped in parking lots!
- A sign & Supra box placed on the property within 24 hours.
- Listed on MLS & on 25+ additional websites
- Our leasing professionals will provide you bimonthly reports that will help provide "Solutions" to reduce your vacancy period
Good property management is not just about finding a tenant quickly, it's about finding the right tenant. After receiving an application from a prospective tenant, all applications are screened thoroughly using:
- National Tenant Network (NTN)
- Credit report & history
- National Eviction reports
- Public records/judgments
- Criminal background reports
- Rental history check
- Employment verification
We are proud of our 80% renewal/retention rate demonstrating the quality of the tenants we place!
We have an in-house maintenance company... Why?
- Our rehabilitation work is superior
- We can offer lower costs to our owners for all maintenance
- Our focus is to maintain the value of your property
- We finish the jobs faster
- Our volume provides subcontractors who are loyal, experienced in tenant related issues, and stand behind their work
What We Do As Your Covington Property Manager
We do more than just collect rent - 5 steps to successful management.
Property Marketing
Tenant Screening
Rent Collection
Property Maintenance
Financial Reporting
R.B. Wheatley
J. Jensen
T. Harper
Residential Property
Management Services We offer exceptional property management while keeping our fees lower than any of our competitors.
Get Started >>
Real Estate
Services If you are looking to buy or sell a home, let our qualified agents walk you through every step of the way.
Get Started >>
Management Services Managing associations requires special attention. PMI professionals implement proven, yet flexible, systems that resolve all HOA concerns.
Get Started >>
Management Services Whether it's a second home, a vacation home, or an estate in probate – we can make sure your estate is cared for even when you can't be there.
Get Started >>
Areas Serviced
- Atlanta
- Fayetteville
- Peachtree City
- Acworth
- Dacula
- Griffin
- Mableton
- Senoia
- Alpharetta
- Dallas
- Hampton
- Marietta
- Sharpsburg
- Decatur
- Hiram
- Mcdonough
- Smyrna
- Austell
- Douglasville
- Holly Springs
- Moreland
- Snellville
- Brookhaven
- Duluth
- Jonesboro
- Newnan
- Stockbridge
- Buckhead
- Dunwoody
- Johns Creek
- Norcross
- Stone Mountain
- Buford
- Ellenwood
- Kennesaw
- Palmetto
- Suwanee
- Canton
- Fairburn
- Lawrenceville
- Tucker
- Chamblee
- Lilburn
- Powder Springs
- Tyrone
- College Park
- Flowery Branch
- Lithonia
- Rex
- Union City
- Conyers
- Forest Park
- Loganville
- Riverdale
- Villa Rica
- Covington
- Grantville
- Locust Grove
- Roswell
- Vinings
- Cumming
- Grayson
- Lovejoy
- Sandy Springs
- Woodstock


text:
The "Stars" come out for the LCHS Prom March
Album 1
on photos below to enlarge.]
[May 05, 2014]
Send a link to a friend
Saturday evening approximately
250 young people participated in this years Lincoln High School prom
The setting this year was the
north side of the Logan County Courthouse. Broadway Street was
closed off and by the time the march began the area was filled with
spectators ready to proudly catch a glimpse of their special young
person ascending the stair and traversing a star-studded red carpet.
The outside area around the
courthouse was decorated with beautiful potted plants, ornate
stands, and star-themed decorations.
The evening began with
welcoming comments from Main Street Lincoln Executive Director Bill
Hoagland. Afterward Mayor Keith Snyder made a brief comment,
then introduced the emcee for the event, Steve Sauer.
It was also noted that this
Hollywood-themed event was the 25th prom march to be held for
Lincoln High School students.
Pictures by Nila Smith
Click here to go to Album
Back to top


text:
Your cart is empty.
for phone orders, or help choosing flowers.
You are viewing flowers available in New Zealand. You might want to change it?
Okay, got it!
Drag the slider to choose a price:
Wrapped bouquet overflowing with mini yellow gerberas, spray stock, yellow roses, berzelia berries, and greenery for a truly stunning gift.
Product Code-SG408A
Due to seasonal conditions, content and colour may be varied to offer the freshest combination and substitutions, whilst maintaining the value of your order, may be made.
Terms & Conditions
* Standard price is shown in the picture.Terms and Conditions
Follow us on Facebook to receive gift ideas and tips on flowers. Check out our Facebook status for specials!
Interflora covers 150 countries with almost 55,000 florists and handles around 75 orders every minute with an annual turnover of $2 billion.
The business of Interflora is the 24 hour delivery of flower orders throughout the world.
Interflora Pacific Unit Limited
PO Box 1048, Christchurch 8140
New Zealand
Join our mailing list to stay up to date on new products and offers.
2019 © Interflora Pacific Limited.
Website by TimeZoneOne


text:
You are hereBack to top
Anam Cara: A Book of Celtic Wisdom (Paperback)
Discover the Celtic Circle of Belonging
John O'Donohue, poet, philosopher, and scholar, guides you through the spiritual landscape of the Irish imagination. In Anam Cara, Gaelic for "soul friend," the ancient teachings, stories, and blessings of Celtic wisdom provide such profound insights on the universal themes of friendship, solitude, love, and death as:
- Light is generous
- The human heart is never completely born
- Love as ancient recognition
- The body is the angel of the soul
- Solitude is luminous
- Beauty likes neglected places
- The passionate heart never ages
- To benatural is to be holy
- Silence is the sister of the divine
- Death as an invitation to freedom
About the Author
John O'Donohue was awarded a Ph.D. in philosophical theology from the University of Tübingen in 1990. He is the author of several works, including a book on the philosophy of Hegel, Person als Vermittlung; two collections of poetry, Echoes of Memory and Conamara Blues; and two international bestsellers, Anam Cara and Eternal Echoes. He lectures and holds workshops in Europe and America, and is currently researching a book on the philosophical mysticism of Meister Eckhart. He lives in Ireland.


text:
Both of these are great for this time of year! Give the gift of reading to your child this holiday season! Scholastic books make the perfect stocking stuffer for any child on your list.
Now here's the exciting part...
I get to give one lucky winner each of these books! *USA only*
To win...
Leave a comment 1 entry
Follow my blogs 1 entry each
Tweet about this 1 entry daily
Follow me on Twitter here 2 entries
Add my buttons to your blog 1 entry each
Follow Scholastic on Twitter here 2 entries
Like Scholastic on Facebook here 3 entries
Follow me on Facebook here 3 entries
Blog about the giveaway and leave me a link 5 entries (please leave a comment for each entry)
Giveaway ends on Tues. Nov. 30th, 2010!
*I do not receive any money for my posts. I do however receive the review products at no charge to evaluate and express my opinion.*


text:
Week 1 topic: Basic commands & common problems
Our small class size of four dogs per group allows you to get the most out of every session. Topics include: the foundation of basic obedience, the core commands, social interactions, and walking on leash.
Each class is one hour long, held at our store.


text:
Really didn't want to do it, guys, but the big threads slow down the forum.
Really didn't want to do it, guys, but the big threads slow down the forum.
Disappointing the longest thread I've ever started is no more.
I am absolutely shattered.
"I am very happy and it will allow me to have lot more rice."
Eoin Morgan on being given a rice cooker for being Man of the Match in a Dhaka Premier Division game.
Threads to be merged imo.
Please use the search function in the future.
Parmi | #1 draft pick | Jake King is **** | Big Bash League tipping champion of the universeCome and Paint Turtle
Fighting for peace is like screwing for virginity.
Too many bones, not enough CASH!!
RIP Craig
Booo...at least keep the name the same?
Anyway should be a very interesting game on the weekend. Dees yet to win outside the G under Bailey but in great form, wouldn't say we are in good form but we showed decent intensity against the Hawks.
Some interesting match ups as well, might get to see Zeibell and Scully/Trengove match up with Bastinac on the other, think we match up pretty well on them, be interesting to see who takes Boomer
Dunn probably line up on Harvey, he's been doing some tagging this year hasn't he?
Haven't actually managed to get to see a Demons game this year, too many of them on Foxtel and haven't been able to get to the pub over the past couple of weeks.
Essendon losing Pears and Reimers.
Knights getting pretty sensitive over criticism!
Loking forward to seeing the Allen Jakovich v Glenn Archer encounter once again
Rest In Peace Craigos
The longevity of this thread will see a mountain of victories to the Hawthorn FC, aswell as premierships. During this period Buddy Franklin & Cyril Rioli will go down as the two greatest AFL players of alltime and Nathan Buckley will lead the Collingwood FC to numerous wooden spoons. Bank on it.
PS: North Melbourne will also become extinct in this period.
As to the question earlier about his future, I actually thought he was doing a decent job earlier on and he promissed to build our attacking game and then work defensively but our gameplan/style hasn't been tinkered with at all and it quite frankly sucks at the moment. Run,run, run is ok when your team is on top but when the opposition has all the momentum why just give it straight back? Thats exactly what we did Sunday, i was yelling so hard just to slow it ****ing down when we had any control over the ball but still we continued to make stupid decisions and play on at all costs which the better teams in the comp won't allow you to succeed at.
Patrick Ryder- What a gun http://youtube.com/watch?v=MW1VCwJJEII
Baby Bombers are back....
And I have to agree with howardj, in that my appreciation for the game has increased massively.
wfdu_ben91 and Craigos talking about football. A true meeting of the minds.
There are currently 2 users browsing this thread. (0 members and 2 guests)


text:
State officials could install a traffic light to increase safety�on M-40, just not in front of Tulip City Truck Stop.
Michigan Department of Transportation engineers listened to dozens of people concerned about traffic on M-40 south of Holland during a Tuesday afternoon open house. Quite often they hear, �we�re glad to see you doing something � just don�t do this (roundabout),� said Nick Schirripa with MDOT�s communications office.
The roundabout would be inconvenient for semi-trucks, said Dennis Reynolds, who has driven for Haworth for 22 years.
�I think it would impede traffic,� he said. �I live in Allegan, so I run it every day.�
The roundabout would be the safest option, Schirripa said, but two others would also help improve traffic movement in that area by eliminating the left-hand turn out of Tulip City Truck Stop.
After Tuesday�s open house, MDOT will likely look closer at either:
� Rerouting traffic turning left out of the truck stop out the back of the property to Interchange Drive and installing a traffic light there or
� Rerouting the traffic, installing a traffic light and realigning Interchange Drive and M-40 to be a 90-degree intersection. At $1 million and $1.7 million, respectively, both of those options are cheap when compared to the $4.5 million duo-roundabout plan.
The traffic signal would be safer at an actual intersection, rather than in the middle of a road where it meets a driveway, Schirripa said. The two new ideas came directly from those local stakeholders.
Without local partners, there isn�t much MDOT can do beyond the roundabouts. It needs permission from local governments to realign local roads and from private businesses to move driveways.
With a traffic light in front of the truck stop, �rear-end collisions would sky rocket,� Schirripa predicted.
Many have asked for a traffic signal at Tulip City Truck Stop, but what they�re really asking is for MDOT to make that stretch of highway safer, Schirripa said, and traffic signal is �not a safety solution.�
MDOT is considering the corridor in response to pleas from people in the Holland/Zeeland area after Zeeland resident and Hamilton School District teacher Joshua Hoppe was killed in a 2013 crash with a semi truck near the entrance to Tulip City Truck Stop.
In 2007, Curtis Boeve and his two children died from injuries suffered in a crash at the same location.
Comments may be sent to Transportation Service Center Manager Pete Pfeiffer at (269) 375-2570 or email@example.com. A decision is likely by the end of the year.
� Follow this reporter on Facebook and on Twitter, @SentinelAndrea.
MDOT officials mull over roundabouts, other options for M-40
State officials could install a traffic light to increase safety�on M-40, just not in front of Tulip City Truck Stop.


text:
WORCESTER � Like many things in a city, the idea of a dog park apparently enjoys near universal public support � until a proposed location is named.
Dog owners turned out Tuesday night at City Hall to enthusiastically back a pooch promenade proposed for roughly 5 acres on the western edge of Green Hill Park.
But several residents of an adjoining neighborhood argued that, while they didn't oppose a dog park in general, the proposed location would afflict them with traffic, illegal parking and noise.
Worcester's licensed canine population numbered 10,190 at last count, a figure that stands in sharp contrast to the number of public places for them to legally romp � which has long been zero.
That math just doesn't work, according to dog park supporter Colin M.J. Novick, who noted that Boynton Park in north Worcester has become a de facto dog park. He likened the city's practice of halfheartedly enforcing a law banning dogs from all city parks, while at the same time not having a legal dog park, to a kind of "don't ask, don't tell" policy that doesn't work for anyone.
"There are so many dogs in the city of Worcester, and we need to come up with a way to accommodate them," Mr. Novick said.
Dog owner Peggy Middaugh and several other supporters of the proposal called access to a dog park a quality of life issue for many city residents.
But residents of Channing Street said they feared for their own quality of life if the only legal dog park in the city were to be built on a part of the park that abuts their neighborhood.
"I don't think it should be adjacent to any residential neighborhood," said Elizabeth Noone of Channing Street.
"It's the only section of land left in the city where you can have some tranquility," fretted Mary Barrett, who lives nearby on Rodney Street.
"It would be too much of an intrusion into the peacefulness of the park."
Dog owner Chris Robarge noted that the 5-acre dog park would occupy barely more than 1 percent of the vast park's land area.
"We always say we want a thing, but we don't want it here. This is a good place for it," Mr. Robarge said.
The proposal is currently before the City Council's Youth, Parks and Recreation Committee, which held Wednesday's public hearing to gather input. Robert Antonelli Jr., assistant commissioner of Public Works and Parks, told the committee that preliminary plans call for the dog park to have a large fenced area for big dogs and a smaller, separate area for little dogs to play.
He called a dog park an amenity for some residents in the manner of playgrounds and ball fields.
It isn't clear yet what the envisioned dog park would cost to build, but the committee instructed Mr. Antonelli to begin working on a budget proposal for the purposes of discussion.
The chairman of the committee, District 5 Councilor Gary Rosen, said it's clear a dog park is needed somewhere in the city.
Councilor-at-Large Kathleen M. Toomey expressed concerns about the proposed Green Hill Park location and questioned whether the city should pay for any dog park, as opposed to a private fund-raising effort led by dog owners.
The other member of the committee, Councilor-at-Large Frederick C. Rushton, said he wasn't opposed to use of public funds or the location, which he called an under used section of the park.
Any dog park proposal would have to be approved by the full City Council. The earliest construction could begin would be this fall, Mr. Antonelli said.
Contact reporter Thomas Caywood at email@example.com or follow on Twitter @ThomasCaywood
Worcester dog park proposal has neighbors growling
WORCESTER � Like many things in a city, the idea of a dog park apparently enjoys near universal public support � until a proposed location is named.


text:
The term "scarred for life" has a far different meaning to Beck Wheeler than the colloquial expression it is typically used for.
It has a literal meaning to him that sucked away a lot of his promise the same day he was sucked under a boat. And, all he wanted to do was cool off.
Out in an ocean bay near his home in San Diego not long after graduating from St. Augustine High School, Wheeler was with a group of friends doing what most recent grads do – goofing off, having fun, enjoying life and living in the moment.
Wheeler jumped in to the bay for one final dip in the Pacific as the sun started to go down. With the music on the boat louder than his shouts, no one heard Wheeler scream when the boat's driver fired up the engines. No one had thought to look when Wheeler couldn't pull down the boat's ladder.
The boat flew into reverse and Wheeler was sucked under, his right leg first hitting the propeller and then his left.
"I remember pushing against the boat and using my arms as best as I could," Wheeler recalls some four years later. "I looked at my leg and there was blood everywhere."
A wide receiver on St. Augustine's CIF championship team as a junior, Wheeler's most important asset was gone in a matter of seconds.
"I used to be fast," he says. "I just lost it all."
Two signs of fortune, however, where on Wheeler's side during the life-altering event.
One of the people on the boat was an Emergency Medical Technician and he jumped in – clothes and all – to help Wheeler. Once Wheeler was brought back on the boat the EMT was directing orders and keeping everyone as calm as best as possible. He was, essentially, saving Wheeler's legs.
The other twist of fate was that a boating accident had occurred not long before and there were already police and other emergency technicians near the launch ramp. So once Wheeler was brought back to shore, he already had a group of people there to help.
After two hours of tests at the hospital and five hours of surgery, Wheeler woke up.
"I didn't really remember what happened," he said. "Then I felt my legs and made sure they were still there."
Eighty-four staples and three stitches held together eight deep lacerations on both of his legs.
He didn't get out of bed for the entire week he was in the hospital. It took three weeks for Wheeler to even begin walking with the aid of a walker. An 18-year-old looking more like an 80-year-old.
Summer was closing fast by this point and Wheeler had a scholarship to play baseball at Pacific.
"I went up there and could barely run around the bases," he says. "I can run faster backwards right now."
Planning on redshirting, Wheeler was needed on the field because some of the other shortstops were not giving the Tigers the necessary production.
"I started three games and played in four," he said. "After those four games it was evident I couldn't play at the full level – especially as a freshman in Division 1 baseball coming off an injury like that. It was pretty tough."
Disappointed that he burned a redshirt year and disheartened about his experience in Stockton, Wheeler looked into transferring immediately once spring classes were completed.
"I played all fall and they didn't know about my injuries, so I felt that was good not having them evaluate me any different than anyone else," Wheeler said.
A year at Orange Coast College literally got Wheeler's legs back underneath him before he transferred to UCSB. In his first season in the blue and gold he was the Gauchos' primary designated hitter, batting .297 while also providing infield depth.
As a senior he was more like a Swiss army knife – playing shortstop, third base, designated hitter and he made his collegiate debut on the mound.
A low-90s fastball and a right arm with nearly no wear and tear secured him a free agent contract with the New York Mets after his senior season. After his summer ends, Wheeler will return to UCSB to finish up his degree in business economics.
But, for someone who loves being in the water, his feelings have changed a bit about getting back on a boat.
"I've been one a boat twice since then," he said. "I'm a little hesitant."
Beach activities. Body boarding, body surfing. Ocean sports. Pick-up basketball games. Snowboarding, traveling.
2. If you were on a deserted island could only bring 3 things, what would they be?
I'd bring my iPad. I'd be set with just an ipad.
3. What's your favorite class you've taken at UCSB?
Jim Romeo's current issues in sport management class. There are a lot of relevant topics dealing with intercollegiate athletics.
4. Do you have any role models?
My dad because I see how hard-working he is and he's taught me a lot and he's shown me his love for sports growing up. He emphasized that playing baseball will not be around my entire life, so getting a good education and working hard.
The ocean breeze and the ocean smell. And the sun rises when we're going to weights at 7 am.
6. What's your favorite TV show?
Eastbound and Down and Entourage. Because they're entertaining and they have good actors.
7. What will you miss most about UCSB after you graduate?
All the friends that I've met, whether in the Athletic Department or the Greek system or normal students in my classes; always going places and recognizing people whether you're getting lunch or are in the library.
8. What actor would play you in a movie about your life?
Jeremy Piven.
9. What's your favorite sports teams?
The San Diego padres, Milwaukee Brewers and the San Diego Chargers.
I always put my left sock, then right sock, left shoe, right shoe. And then drink a cup of coffee.
11. Who is your favorite musical artist or band?
T-Pain and Akon and Lil Wayne.
12. What's your favorite spot on campus?
I like getting lunch at the UCen because you've got the lagoon right there and there's always a lot of people and activities going on.
13. What's your favorite sport to watch at UCSB other than your own?
Men's basketball and men's volleyball because you can be up front in the first couple of rows and men's volleyball is cool because you can heckle the other teams a lot.
A: Whistler, British Columbia. There are two huge mountains and I like snowboarding. I like the atmosphere in town.
15. What is one thing about you people don't know?
All I can really paint are sunsets, but I do a darn good job of painting a sunset over the ocean. My grandma, she was a really good water painter and when I spent time with her when I was little we would paint and I took a couple painting classes in high school and now I do it for fun.
16. Is there a motto that you live by?
No pain, no gain.
17. In one word how would you describe UCSB baseball?
18. What are your goals once baseball is over?
Work in the front office of a professional sports team, hopefully baseball.
A: An Extraordinary Example About How to Overcome the Obstacles of Life.
20. How did it become that you go by your middle name, Beck?
It was my grandma's maiden name and my parents always wanted my name to be Beck and it sounded better to be Jeffrey Beck Wheeler instead of Beck Jeffrey Wheeler.


text:
|Local group acknowledges individual achievements in conservation
PRATT – The Kansas Wildlife Federation (KWF) honored 13 individuals and organizations for their conservation efforts in 2012 at the Conservation Achievement Program (CAP) Awards banquet on Feb. 23. The banquet, held in Emporia, was part of KWF's annual meeting. Activities prior to the banquet included a social hour and silent auction. The evening concluded with a presentation by guest speaker Bob Gress, wildlife photographer and former Director of the Great Plains Nature Center.
Out of the 13 awards given, five of the recipients have been or are currently employed by the Kansas Department of Wildlife, Parks and Tourism (KDWPT):
Matt Smith, Wildlife Conservationist Award
Smith began his career with KDWPT as a district wildlife biologist in the southwest part of the state. He later moved to a similar position at Wilson where he took on the additional responsibility of serving as a Natural Resources and Conservation Service (NRCS) area biologist. Recently, Smith has been focusing on Farm Bill issues important to the welfare of Kansas wildlife and their habitat. He currently resides in Wilson.
Randy Rodgers and Helen Hands, Land and Soil Wildlife Conservationist Award
Rodgers provided years of valuable service to KDWPT as an upland bird research biologist. He researched and developed options to improve habitat on private land in conjunction with crop production. Now retired, Rodgers and Hands, his wife – also a former KDWPT biologist – are developing wildlife habitat on their private land. They currently reside in Hays.
Thayne Smith, Conservation Communicator Award
Smith served as the chief of Information and Education for the Kansas Fish and Game Commission from 1966-1970. In that capacity, he edited the Kansas Fish & Game magazine. Smith was a founding member of the Outdoor Writers of Kansas organization, which is still active today. He was also the first recipient of the Conservation Communication award in 1967. Smith currently resides in Claremore, OK.
Other 2012 award recipients include:
- Mike Knotts, Peck, KS: Outdoor Skills Instructor Award
- Robert Robel, Manhattan, KS: Conservationist of the Year Award
- Stephen DeHart, Olathe, KS: Youth Conservationist Award
- Stephen Pletcher, Emporia, KS: Conservation Educator Award
- Kansas Grazing Lands Coalition, Hutchinson, KS: Conservation Organization Award
- Tom Meek, Clay Center, KS: Water Conservationist Award
- Paul and Kristan Dean, Madison, KS: Forest Conservationist Award
- Mike Calwell, Shawnee Mission, KS: Stream Monitor Award
- Caleb Stotts, Fredonia, KS: Farmer/Rancher Wildlife Conservationist Award
- Ted Beringer, Lenexa, KS: President's Award
KWF, an affiliate of the National Wildlife Federation, has been dedicated to the sustainable use, conservation, appreciation, and restoration of Kansas wildlife and natural resources since 1950.
For more information on how you can support KWF, visit: www.kswildlife.org/donate.php or call (316) 214-3001.