r
`
`PROTECTION
`INFORMATION SYSTEMS :
`
`Proceedings ofthe Fourth IFIP TC 11 International Conference on
`ComputerSecurity,IFIP/Sec'86
`Monte Carlo, Monaco, 2-4 December, 1986
`ll-I;l!eti!ft"III'J/t/ (6/tlc/~--eoce
`
`6h Clli,,-()n'l':t~-I
`
`(_tl-l
`
`by
`
`Andre GRISSONNANCHE
`XPConseil
`ParisI France
`
`NH
`CP~C
`
`~~
`
`1989
`
`NORTH-HOLLAND
`AMSTERDAM. NEW YORK. OXFORD. TOKYO
`
`PNC-JP MORGAN EXHIBIT 1014
`
`Page 1 of 11
`
`

`

`© IFIp'1989
`
`All rights reserved. No part of this publication may be reproduced, stared in a retrieval
`system or transmitted in any form or by any means, electronic, mechanical, photocopying,
`recording or otherwise, without the prior written permission of the publisher, Elsevier
`Science Publishers a.v.
`(Physical Sciences and Engineering Division), P.O, Box 103,
`toOO AC Amsterdam, The Netherlands.
`Special regulations for readers in the U.S.A. ...:. This pUblication has been registered with
`the Copyright Clearance Center Inc. (GeG), Salem, Massachusetts. Information can be
`obtained from the eee about conditions under which photocopies ofparts ofthis pubHca(cid:173)
`(ion may be made in the U.S.A. All other copyright Questions, including photocopying
`outside of the U.S.A. I shouldbe referred to the publisher, Elsevier Science Publisher~13.\1"
`u.nless otherwise specified.
`No responsibility is assumed by the publisher or by IFIP for any injury and/or damage to
`persons or property as a matter of products liability, negligence or otherwise, or from any
`use or operation ofany methods, productsl instructions or ideas contained in the material
`herein.
`
`ISBN: 0 444 B7345 7
`
`Published by:
`
`ELSEVIER SCIENCE PUBLISHERS B.V.
`p.o. Box 103
`1000 AC Amsterdam
`The Netherlands
`
`Sale distributors for the USA. and Canada:
`
`ELSEVIER SCIENCE PUBLISHING COMPANY, INC.
`655 Avenue ofthe Americas
`New York, N.Y. 10010
`U.S.A.
`
`Library of Congress Cataloging-in-Publication Data
`
`1986: Monte
`
`IFIP International Conference on Comput~r Security (4th
`-Carlo, Monacol
`proceedings of
`Security and protection in information systems
`the fourth IFIP International Conference on Computer Security,
`IFIP/Sec '86, Monte Carlo, Monaco, 2-4 December, 1986 I edited by
`Andre Grissonnanche.
`em.
`p.
`Bibliography: p.
`ISBN 0-444-87345-7
`2. Electronic data
`1. Computers--Access control--Congresses.
`processing departments--Security meas~res--Congresses.
`1. Grissonnanche. Andre.
`II. Title.
`III. Title:
`International
`Federation for Information Process1ng.
`QA76.9.A25145
`1986
`658.4'78--dc19
`
`89-29115
`eIP
`
`PRINTED IN THE NETHERLANDS
`
`Page 2 of 11
`
`

`

`SECURITY AND PROTECTION IN INFORMATION SYSTEMS
`A. Gris$onnanche (Editor)
`Elsevier Science Publishers B.V. (North-Holland)
`IFIP, 1989
`
`391
`
`This material may be protected by Copyright law (Title 17 U.S. Code)
`
`AN INTELLIGENT TOKEN FOR SECURE TRANSACTIONS
`
`B J CHORLEY and WL PRICE
`
`National PJ:;lysical Laboratory, Teddington, Middx, UK
`
`After reviewing the requirements for user identity verification in
`any transaction processing system.
`the paper describes the design
`of an intelligent token that offers much greater security than that
`of conventional tokens. Applications for intelligent tokens are
`explored and an attempt is made to identify further possible lines
`of progress.
`
`1 .
`
`INTRODUCTION
`
`Teleprocessing systems for handling transactions are assuming ever increasing
`importance in many areas of finance and.commerce. These systems range from
`those handling billions of pounds per day in transfers between major banking
`institutions to those where supermarket customers make their paymerits for
`purchases using plastic cards. A common need of all such systems, whatever
`their scale, is to achieve integrity so that their users can trust the outcome
`of the operations carried out on their behalf. Because of the enormous amounts
`of money involved there is an inevitable attraction for the criminal world to
`attempt to profit from unauthorised or altered transactions. There is therefore
`need for designers of these systems to take into account the attacks to which
`the systems may be subjected and to take appropriate security countermeasures.
`Attacks may involve attempts by intruders to masquerade as authorised users,
`they may involve attempts to alter transaction records.
`they may try to force
`the system to give authorisation to a transaction that should really be denied,
`and so forth. There are indeed many ways in which transaction processing
`systems may be open to attack.
`
`Our purpose in presenting this paper is to examine some aspects of the process
`of verifying the identity of authorised users and also the integrity of the
`transactions carried out on their behalf. We shall then develop a specification
`for an intelligent token that can participate effectively in achieving identity
`verification and transaction integrity. Finally we examine some of the
`potential applications of such a token.
`
`Identity verification is based classically on something known to the user,
`something possessed by the user or some physical characteristic of the user.
`'Something known' usually implies a password or, in the case of systems
`operated by banks,
`the ubiquitous 'PIN' or· personal identification number.
`'Something possessed' may be a token, for example a plastic card or a key.
`Physical characteristics used for identity verification are often called
`'biometrics'; examples include voice and signature verification. It is
`generally considered that they provide security superior to that offered by
`PINs, but
`there are other disadvantages which discourage their widespread
`introduction, not least the de~ree of imprecision that is inherent in many of
`the techniques proposed.
`.
`
`Page 3 of 11
`
`

`

`392
`
`BJ. Chorley and HI.£. Price
`
`technique for user verification is that
`There is no doubt that the commonest
`which uses the plastic card;
`there are very many millions of such cards in use
`throughout the world today, most of which carry a magnetic stripe. Strictly
`speaking the card only allows an identity to be claimed and does nothing in
`itself to help the verification of that identity. To prevent a lost card being
`used by someone other than the authorised user it is customary in many types of
`transaction to require that the user offer a memorised PIN in conjunction with
`the card: usually a derived function of the PIN is stored on the card. Human
`memory being what it is,
`the 'memorised' PIN is often written down, even on the
`card itself; the problem is compounded by many users possessing several cards,
`each with its own different PIN. There is an undoubted need to educate the
`public better in the use of PINs, but their eventual replacement by biometric
`methods of identity verification within the next few years may safely be
`predictE::d.
`
`The magnetic stripe card is itself a source of insecurity for systems in which
`it is used. The problem is that the card is too easily counterfeited. The
`magnetic stripe can easily be copied unless special measures are taken to make
`this difficult,
`the embossing can easily be altered or simulated and the
`general appearance of the cards can be imitated in a way sufficiently
`sophisticated to deceive human counter clerks. Various security measures have
`been added to the cards in recent times to make these falsification methods
`less effective:
`the hologram on the face or the card and the use of 'watermark'
`magnetic tape are examples of such measures.
`
`Because of the shortcomings of the magnetic stripe as a secure means of
`recording user parameters a great deal of attention has been paid in recent
`years to alternative card technologies. In particular we have the intelligent
`or 'smartt card, where integrated circuits (one or more) are embedded within
`the plastic; surface contacts are usually provided as part of a communication
`interface,
`though other means of communication are also being considered. It is
`well known that experiments have been carried out, particularly in France,
`to
`assess the performance of smart cards. The outcome of these experiments has not
`been widely publicised, but
`the French are showing their confidence in these
`devices by launching new applications with millions of cards in use.
`
`It seems that counterfeiting of the smart card presents the· criminal with much
`greater problems than are met with the magnetic stripe card. However,
`the
`problem of the PIN as a means of cOhfirming claimed identity remains.
`Presentation of a PIN associated with the smart card requires that it be
`entered on a keyboard associated with the terminal. Because the field of
`application of the smart card is bound to include transactions such as point of
`sale,
`the insecurity of the average point of sale terminal is significant.
`Physical protection of such terminals is bound to be much less than that
`normally found in automatic teller machines. Therefore we may expect that some
`point of sale terminals will be bugged with the object of collecting personal
`account information and PINs. Exploitation of this knowledge may not
`necessarily involve fabrication of false cards; stealing of a smart card whose
`PIN has been discovered is a much simpler means.
`
`For this reason {and others which will emerge later} there is considerable
`merit in an intelligent identity token which goes further than the smart card
`and provides its own keyboard for PIN entry and transaction confirmation.
`
`Bugging of a transaction terminal in order to collect PINs is not the only risk
`to which system customers may be exposed. The t~ansaction details are usually
`displayed to the customer on the terminal display and it is not beyond the
`bounds of criminal ingenuity to arrange that the terminal display shows a small
`amount whilst the transaction message, unseen by the customer, is constructed
`to contain a much larger amount. One precaution against this type of fraud is
`to insist on a transaction voucher being printed and retained by the customer.
`
`Page 4 of 11
`
`

`

`An Intelligent Token for Secure Transactions
`
`393
`
`they too
`However, customer habits with vouchers are also notoriously bad;
`easily get lost or are deliberately thrown away,
`leaving no record in the hands
`of the customer.
`
`There is therefore considerable merit in presenting the transaction details to
`the customer on a display that is under the customer's direct control - on the
`token itself. The customer will more readily trust such a display than that on
`the terminal. Inclusion of a display on a small token is facilitated by the
`development of very compact forms of liquid crystal display as found in many
`pocket calculators. If, later,
`the token is to be used to check on a series of
`transactions carried out by its owner,
`then it is a simple matter to arrange
`that a record of transactions be held in the token.
`
`Ensuring the integrity of transaction messages is a different problem, since
`these are vulnerable to alteration unless appropriate protective measures are
`taken. Message encipherment is commonly used in transaction systems for message
`protection, but an even more powerful
`technique is offered by message
`signature. Using public key cryptography it is possible for the sender of a
`message to produce a transformation in the message such that the recipient of
`the transformed message can use a parameter associated with the alleged sender
`(the public key of the sender) and actually prove beyond doubt that the
`transformed message came from that sender;
`this ability is commonly referred to
`as 'digital signature'. Since the intelligent token whose specification we have
`been developing in this discussion is assumed to be trusted by its owner,
`the
`ability of the token to sign messages on behalf of the owner woulq be very
`attractive. Transaction messages could be read from terminal into token,
`checked on the token display and then, if approved by the owner of the token,
`signed by the token before being sent back to the terminal for processing
`within the transaction system. The co~rectness of the signature can be checked
`by any system entity possessing a copy of the public key belonging to the
`particular user.
`
`We are therefore suggesting that desirable features of an intelligent token
`should include a keyboard and a display on the token, with internal hardware
`and software designed to provide digital signature; it goes without saying that
`a suitable interface must be provided. The remainder of this paper discusses
`the design, development and potential applications of such a token.
`
`2.
`
`THE NPL INTELLIGENT TOKEN
`
`Research and development at the National Physical Laboratory, beginning in
`1982, sponsored by the British Technology Group,
`the UK Department of Trade and
`Industry and members_of British commerce and industry, has produced a token [1]
`which possesses the desirable properties developed in the introduction to this
`paper, namely internal processing power and memory,
`integral keyboard and
`display, and appropriate interface. At present the token exists in the form of
`a fully working prototype which is the size of a small book, but it is intended
`that further development shall lead to miniaturisation of the token down to the
`size of a small pocket calculator. It is unlikely that attempts will be made to
`bring the token size down to the credit card dimensions which have governed the
`design of the smart card. The critical dimension is, of course,
`the thickness
`of the device; smart card manufacturers are seeking to create a viable device
`within the compass of 0.76 mm which is the thickness allowed for credit· cards
`in the international standard for these.
`
`A token can be designed to perform many different functions and may thereby
`replace a number of separate cards and calculators currently carried by users.
`
`Page 5 of 11
`
`

`

`394
`
`B.J. Chorley and W.L. Price
`
`to the design of the
`The ability to generate digital signatures is fundamental
`intelligent token. This is based on the RSA public key cryptosystem, which is
`implemented in the token on 8 Texas Instruments TMS32010 microprocessor. The
`latter can multiply two 16 bit numbers in 200 os. The RSA implementation has
`been described by Clayden [2]. Using a 512 bit modulus for the RSA operation,
`the processing time for the full RSA transformation is less than 3 seconds,
`which is achieved without special selection of parameters. Only one RSA
`operation is required for the generation or the checking of a digital
`signature. If the block size of the message to be signed exceeds the RSA
`modulus,
`then a hash function [3]. using the DES encipherment algorithm
`(implemented in software), is applied to the message to generate a parameter
`that can be signed directly.
`
`The bandwidth of the RSA implementation is very low in telecommunication terms,
`but an operation time of 3 seconds is perfectly tolerable in the context of a
`transaction where other events can happen in parallel.
`
`The terminal must be equipped with RSA capability in the same way as the token
`in order that it shall participate in the transactions by·checking the
`correctness of generated signatures.
`
`the TMS32010 and associated
`The token consists of two main parts (figure 1),
`ROM and RAM storage, and a control module built around an Intel 8085
`microprocessor;
`in the control module we have. ·in addition to ROM and RAM
`storage,
`time of day clock,
`input/output interface, display and keypad. The
`parts of the unit are linked via a bus buffer.
`
`memory
`
`I~rogram
`I
`
`IdiSPlayl--
`
`key and
`transaction
`memory
`
`I
`
`Iprogram
`memory
`
`I
`
`control module
`
`RSAmodule
`
`Ikeypadl-
`
`I
`
`input!
`output
`
`I
`
`time of
`day clock
`
`Fig I The NPL intelligent
`
`token
`
`the token identifies itself to
`On presentation of the token to a terminal,
`terminal which responds with a random number in the form or a 'challenge ' .
`the token receives the challenge it requests its- owner to input the PIN for
`comparison with the PIN value stored within the token. If the correct PIN is
`input on the token keyboard,
`then the token generates a digital signature on
`the challenge and returns the signed challenge to the terminal. The latter.
`which has in the meantime obtained the public key corresponding to the token
`identity (either from a register or,
`in a form signed by an authority. fro~
`
`Page 6 of 11
`
`

`

`Anllltelligent Token for Secure TransactioJlS
`
`395
`
`token itself), uses this public key to check the validity of the signature.
`Figure 2 shows this sequence of events. We see,
`therefore,
`that, if a valid
`signature is returned,
`then -this is the assurance to the terminal that the
`token is itself valid and that the correct PIN has been presented. Should the
`token receive the wrong PIN on its keyboard,
`then it asks again for the correct
`PIN. After three attempts to input the:correct PIN,
`the token is programmed to
`terminate the request-for-PIN state and to overwrite the store containing the
`secret key on which the signature is based,
`thereby preventing systematic PIN
`searching and at the same time totally disabling the token. A token that has
`passed into this state needs to be restored by using special control procedures
`before it can be used again. These·procedures would best be effected by the
`card issuer and ought perhaps to involve the card user in person.
`
`(TERMINAL)
`
`..
`
`~.oo----
`
`send random
`challenge
`
`IiII
`
`(
`
`TOKEN
`
`)
`
`send token
`identification
`
`jIii
`
`~i request PIN
`i
`- i
`i
`
`checkPIN
`
`Ii
`
`sign chaUenge
`i using PRIVATE
`i key,send
`
`PIN
`
`I Ii
`
`iI 1 1 I
`
`I I I
`
`public key
`
`request pUblic I
`r---"'"
`key
`!...-
`
`..
`
`check responsel
`using PUBLIC i
`i
`key
`
`Fig 2 Token verification
`
`The process described in the previous paragraph is solely one of identity
`confirmation. The offering of the token to the terminal constitutes a claiming
`of identity, whilst the entering of the PIN on the token enables the latter to
`satisfy the terminal that the correct PIN has been entered without the
`necessity to disclose the PIN to the terminal. The ability of the token to sign
`messages can be extended to cover a financial
`transaction. In this case the
`token is preserited as before and the PIN entered;
`the transaction message is
`created on the terminal and then passed to the token for checking. The message
`appears in the token display window and the user can be satisfied that 'the
`transaction displayed is acceptable. When satisfied,
`the user indicates this on
`the token keyboard and the token then adds the date and time, signs the
`transaction message and returns this to the terminal. The latter can check the
`correctness of the signature in exactly the same way as it did with the
`challenge used in the previous scenario. We have assumed in this description
`that the challenge is first made and replied to,
`then the transaction message
`is presented, checked, signed and returned. This procedure is not strictly
`necessary. It would be sufficient for the challenge to be dispensed with,
`leaving the signature on the signed transaction message to be checked in order
`to satisfy the terminal of the correctness of the transaction,
`including the
`presentation of the PIN.
`
`The response of the token in a transaction of this kind includes a reference to
`its time of day and date clock;
`this is checked by the terminal for
`
`Page 7 of 11
`
`

`

`396
`
`B.l. Chorley and H'L Price
`
`correctness. Thus the system insists that terminals and tokens keep step in
`time within specified limits. This is an additional precaution against
`interference from an intruder. If each transaction message is made unique by a
`message numbering system,
`then it may not be necessary to include time and
`date.
`
`We have described how the token participates. in a financial transaction. Its
`signature capability Can be used also in the more general sense of signing
`free-fOrmat messages. In this .case, after checking of PIN and challenge
`response,
`the message is prepared on the terminal, sent to the token for
`checking and approval,
`then returned in signed form to the terminal.
`
`The integrity of the processes we have discussed depends on the secrecy of the
`secret RSA key which is held within the token. Therefore it is essential that
`any production tokens shall possess sufficient tamper resistance capability to
`defy the discovery of this parameter. We have not attempted to provide this
`capability within the prototypes built thus far, but it is a vital feature of
`any tokens for serious use.
`
`We have already indicated our reservations regarding the PIN as a means of
`identity confirmation. In principle there is no reason why a suitable interface
`for biometric identity verification may not be added to the token. The success
`of such a scheme is, of course, dependent on the performance achieved by the
`biometric technique.
`
`3. APPLICATIONS FOR AN INTELLIGENT TOKEN
`
`The history of the development of the intelligent token is closely related to
`the banking industry and therefore it is natural that the more obvious
`~pplications for the new device are to be found in the domain of financial
`transfers. Dissatisfaction with the security achievable in"systems using
`magnetic stripe cards has led to the new development.
`
`the
`the credi t card,
`Within banking we already have several types of token,
`debit card,
`the cheque guarantee card and the automatic teller machine card.
`The cheque guarantee card has a radically different function and we do not see
`the intelligent token being of direct application here, but it can play an
`important part in the other systems,
`leading to higher security. The
`distinction between credit and debit cards 1s made in the accounting system
`that ensures collection of payment; credit requires payment at some accounting
`date in the future, whilst debit implies an early reference to the customer
`account and an immediate or almost immediate transfer of funds;
`in this respect
`debit is very similar to a written cheque.
`
`An intelligent token serving as credit or debit card must have a stored
`expenditure ljmit against which current activity is checked;
`this is
`indispensible if the token is used off~line and desirable even when it is used
`on-line. Clearing of the,debt, for example from another account or by a cash
`payment, should -result in the restoration of the expenditure limit. This can be
`done in the token by means of a signed message received on-line from the
`issuing bank which is checked by the token using the bank's public key.
`
`Use of the token in an EFT-POS system makes very good sense; as we have pointed
`out earlier,
`the security that can be built into an EFT-POS terminal may not be
`very great, with the danger of bugging. The token confers the required
`additional security to protect secret personal data from being disclosed.
`Indeed, it can be used also on behalf of the retailer, providing a suitable
`means for checking transactions and for storing transactions for later
`
`Page 8 of 11
`
`

`

`An Intelligent Token for Secure Transactions
`
`397
`
`to a clearing centre. Use of the retailer's token in this manner
`off-line for most of the day, with the consequent savings in
`costs and in transaction timei
`transmission to the clearing
`may take place once every 24 hours at a time when communication is
`Figure 3 shows a possible sequence of 'steps in an EFT-POS application.
`
`TERMINAL
`
`TERMINAL
`OWNER'S
`BANK
`
`CARD
`ISSUER'S
`BANK
`
`enter PIN
`-----·~c·heckPIN
`
`send 10
`
`authorise
`transaction
`
`display
`transaction
`details
`
`add date and
`time
`
`sign with
`PRIVATE key
`'check
`signature
`PUBLIC key
`transaction
`complete
`
`send day's
`transactions
`and signatures
`
`send individual
`transactions
`and signatures
`
`tra nsfer funds
`
`Fig 3 EFT - POS Transaction Isettlement
`
`'i;m!!~~:;~:;~:::n of bank accounts by customers from their home or office terminals is
`more popular. The security of such systems. particularly in respect of
`identity verification and transaction integrity. presents a challenge
`
`Page 9 of 11
`
`

`

`398
`
`B.J. Chorley and W. L. Price
`
`to the system designers. The token has much to offer here. The security
`associated with the typical home terminal is virtually non-existent and
`therefore it is vital that seme appropriate component be added to take
`responsibility for this important aspect of a home banking system. Since the
`than the sdm tien of a suitable
`token requires nO more of the terminal
`interface and provision of appropriate software enhancement, provision of
`security by this means makes good economic sense. The advantage of having
`transaction messages signed on behalf of the user and of the bank's system is
`very great.
`
`Applications of an intelligent token are not restricted to the banking domain.
`Another important application is to access control, where users' admission to a
`secure zone is controlled by a system of passwords presented on.a keyboard
`associated with a doorway. Insertion of the token into an appropriate interface
`with password offered on the token keyboard provides additional security. The
`token may, of course, _be programmed to keep an inviOlable record of the
`accesses made by its holder;
`this record can be checked by authorised persons
`at any time, either by a special interaction with the token or by collecting
`the activity record as matter of course when the token is presented by its
`holder wishing to enter at an access point. Such a system may be extended to
`cover aspects of time-keeping by staff.
`
`Payment for public utility services may be made conveniently with the token. It
`is already possible to read electricity supply meters remotely by using the
`supply mains for signalling purposes. There is no practical reason,why the same
`medium may not be used for payment messages generated by the user token
`presented to a suitable interface built in to the meter. This method of payment
`can also be applied to the telephone system and even to such utilities as
`water, gas or oil supplies, provided that agreement is obtained to use the
`electricity supply mains or the telephone connection for' this purpose.
`
`The ability of the token to sign messages could be of great significance in
`electronic message handling systems. Where a message arrives over some
`messaging system,
`the recipient is often at a loss to obtain the desired level
`of assurance -that the message has really come from the apparent sender. In the
`traditional mail system we rely upon written signatures for this purpose, but,
`unless facsimile is used,
`there is no equivalent in electronic systems. Digital
`signature provided by the token meets the need admirably.
`
`The ability to sign messages can even be extended to cover contractual
`arrangements and documents of title. To achieve a system which depends on
`digital signature for authentication will, of course, requ~re that this form of
`signature is recognised as having legal force.
`- .~
`
`Acceptability of the token by the public will depend upon the services
`supported by the token. Many are already in the habit of carrying a small
`pocket calculator as a matter of course. If the token provides basic calculator
`functions,
`then it can be carried instead of the calculator. The payment ,and
`signature functions we have d~scussed provide convenient and secure ways of
`doing business and signing documents. However, we can imagine applications
`which go beyond this. For example, medical prescriptions can be entered into
`the user's token at the doctor's surgery,
`then readout by the dispensing
`pharmacist who prepares the medicine; where drug abuse is a serious problem,
`this provides an added security dimension. A personal engagement reminder
`system can readily be added to the token, which is already designed to contain
`a source of time and date. Personal engagement calendars stored on a home
`computer can be transferred in appropriate sections from computer to token,
`which alerts its holder as each engagement comes up.
`
`Page 10 of 11
`
`

`

`An Intelligent Token for Secure Transactions
`
`399
`
`CONCLUSIONS
`
`demonstrated the need for a personal identity token whose capability
`/",cee,ds that of currently available tokens. The intelligent token confers
`)'m;~;~~;~~"~~ security both in regard to identity confirmation and transaction
`'.:1
`integrity.
`
`too early .to estimate the cost of such a token in bulk manufacture, but
`likely always to exceed that of the smart card. Therefore we may predict
`its applications will be found in areas where the value of the resource
`~ptect'ed is above average. The versatility of the token in application to a
`range of different purposes is likely to increase its acceptability.
`
`The design and development of an intelligent token. Proc.
`Chorley, B J.
`Int. Conf. on System Security, London, October 1985, PP. 9-21.
`
`Some methods of calculating the RSA exponential. Proc.
`Clayden, D O.
`Int. Conf. on System Security. London, October 1985. pp.173-183.
`
`Davies. D W, &Price, W L. Digital signatures - an update. Proc. Int.
`Conf. on Computer Communication, Sydney. October 1984, pp. 845-849.
`
`Page 11 of 11
`
`