Secure Transactions
`
`83
`
`must be regarded as a real possibility and therefore there may be an
`
`
`
`
`to the PIN. advantage in a system which gives better protection
`
`6.2 DESIGN PRINCIPLES OF THE TOKEN
`
`One way in which the PIN can be given better protection is to provide a
`
`for its entry
`Thus the PIN is
`keyboard
`
`which is under direct user control.
`
`not entered on the keyboard of the retail terminal, but upon a keyboard
`
`
`
`specially mounted on the token itself. The first design principle of the
`
`
`NPL intelligent token is therefore that the PIN should be presented
`to the
`
`system on a keyboard integral with the token. We shall later describe how
`and then satisfy the terminal
`the token is able to check the PIN validity
`
`
`that the PIN was valid without actually disclosing the PIN to the terminal.
`Oearly it is not sufficient for the token to receive the PIN on its keyboard,
`
`check. it and then send a message saying 'the PIN was correct' to the
`sine� this message could be sent by a false token with an
`terminal,
`PIN. The message must be such that the terminal can rely upon
`incorrect
`it.
`In a transaction processing system the user is usually dependent on
`
`
`
`
`information on the terminal; the question is whether the user
`displayed
`can always trust this information.
`
`"It is. a common experience to motorists
`
`to buy petrol from a pump with digital light emitting diode display;
`
`
`elements of these displays frequently fail and an amount (petrol·or value)
`.
`.
`which is different from the correct value. It is not inconceivable
`is displayed
`
`that a retail terminal display might be deliberately altered by someone
`seeking to defraud the system owners or users. Again this brings us back
`
`
`to the customer's personal token. If it were possible to display the trans­
`
`
`on a the amount of money to be committed,
`action details, particularly
`
`display under customer control, then this problem would be much reduced,
`
`at least from the customer's point of view; comparison of token and
`
`
`terminal displays may give added confidence. For this reason the
`NPL
`
`
`intelligent token cames its own display for communication with the cus­
`
`
`of the token. tomer, which is the second iinportant design principle
`
`We have indicated earlier the importance that must attach to the
`
`
`integrity of transaction messages which control the movement of funds
`
`
`between user and retailer accounts. It is frequent practice to protect
`
`messages by encipherment techniques, often by authentication
`
`transaction
`
`
`
`based on symmetric encipherment algorithms. An alternative and attractive
`
`
`method of ensuring integrity is based on the digital signature derived
`
`
`As we shall see, the NPL from an application of public key cryptography.
`token is able to satisfy a terminal that a correct PIN has been offered
`
`without disclosure of that PIN; this property depends upon the application
`
`Page 101 of 201
`
`UNITED SERVICES AUTOMOBILE ASSOCIATION
`Exhibit 1003
`
`

`
`'I
`
`Integrated Circuit Cards
`
`84
`of a digital
`signature. The basic token design therefore includes the ability
`
`
`
`
`
`
`
`to calculate digital signatures using a stored secret key. Since the ability
`
`
`
`
`
`to calculate signatures is a fundamental requirement in the device, it is
`
`
`
`to apply this ability to calculating signatures on transaction
`convenient
`
`
`
`
`authorised by the token holder. Transaction messages signed in
`messages
`this way
`
`
`
`
`processing system in the transaction can be checked anywhere
`
`
`where a reliable copy of the corresponding public key is available.
`
`6.3 REALISATION OF THE TOKEN DESIGN PRINCIPLES
`
`of the design principles We have now identified the three fundamental
`
`
`
`
`
`
`
`
`
`to and ability display keyboard, integral NPL intelligent token -integral
`
`
`We proceed to discuss the ways in which these
`
`
`calculate digital signatures.
`
`
`
`design principles have come to be implemented in physical and logical
`
`
`terms. The central part of the design is an implementation of the RSA
`
`
`
`
`public key cryptosystem (4); this software implementation runs on a fast
`signal
`
`
`processing chip, the Texas Instruments TMS32010.
`
`
`
`
`
`Personal identity verification (more strictly PIN verification) begins
`
`
`with presentation of the token to a terminal by the user; the terminal
`
`
`
`senses the presence of the token and generates a random number which it
`
`
`to sends as a challenge to the token; at the same time the token signals
`
`
`the user (using its own display) that the PIN must be input on the token
`The token is designed to
`check the PIN and, if the PIN is
`keyboard.
`
`
`to sign the random number just received from the terminal using,
`correct,
`
`
`
`
`within the token. (Should for this purpose, the secret RSA key contained
`
`
`
`the PIN be incorrect, the signature process does not take place and the
`
`
`
`user is given a limited number of attempts to get the PIN correct, failing
`
`
`
`which the token is disabled.) Having produced a transformation of the
`
`
`random number by the signature process, the token returns the trans­
`
`
`formed number to the terminal. The terminal, after having generated the
`
`
`
`initial random number challenge and while the token is preparing its
`
`
`
`signed reply, will have sought the public key corresponding
`to the token;
`
`
`
`this can come either from a reference source of public keys or can be
`supplied
`
`
`by the token itself in the first exchange of data with the terminal,
`
`
`
`
`already signed by key is supplied in which case the version of the public
`
`
`the secret key of a superior authority (the public key of the authority
`must then be known to the terminal).
`
`Given the public key corresponding
`
`
`
`to the token, the terminal can check the validity of the returned signature
`
`
`
`
`
`PIN correct implies of the random number challenge; correct signature
`
`
`
`presentation on the token keyboard. Figure 6.1 illustrates the sequence of
`
`
`events in identity verification.
`Because the token is capable of generating RSA signatures, it is a
`
`
`
`
`
`
`simple extension of its functionality to permit the signature of transaction
`
`
`
`
`messages. In a retail point-of-sale system these messages would be pre-
`
`Page 102 of 201
`
`

`
`Secure Transactions
`
`85
`
`TOKEN
`
`TERMINAL
`
`4
`
`PIN
`
`�r
`
`Sign challenge
`using PRIVATE
`r---------�,
`key, send
`
`Send token
`identification
`, ..
`I
`Request PIN
`I
`I
`
`Check PIN
`
`Send random
`challenge
`
`Requ9st public !
`�
`key
`! Public key
`,____
`!
`i Check response !
`j using PUBLIC I
`i key
`Fig. 6.1 PIN checking,
`token challenge and response.
`
`pared on the retailer terminal and ·sent to the token for approval by the
`
`
`token holder (inspection in the token window by the user) and, if approved,
`
`signed by the token and returned to the terminal. The terminal can check
`
`
`the validity of the signature. and then send the signed message to a
`transaction
`
`
`
`processing centre. The signature validity can be checked by
`
`
`
`to corresponding any entity in the system having access to the public key
`
`
`
`
`the signature token. To avoid replays of transactions, it is necessary to
`
`
`numbering does include a time and date field in the message. Transaction
`
`
`not lend itself conveniently to prevention of replay for token originated
`
`tokens accessing multiple services would require a serial
`transactions;
`
`number for each and hosts offering services would need a number for
`
`each token in valid issue. Figure 6.2 illustrates the sequence of events in
`
`transaction signature.
`It is an interesting extension of the design that the initial random
`
`
`
`
`number challenge may be omitted and replaced by the transaction message.
`In this case the protocol is shortened by arranging that the identity
`
`
`
`verification is checked by the signature on the transaction message.
`The ability of the token to sign messages can be extended to cover
`
`
`
`messages in general; the application of the token is not restricted to value
`transactions.
`
`6.4 THE PROTOTYPE TOKEN
`
`The NPL intelligent
`token was created in prototype form in a unit
`measuring 36 em x 15 em x 2 em; this device contained 21 discrete
`
`Page 103 of 201
`
`

`
`86
`
`
`
`
`
`Integrated Circuit Cards
`
`USER
`
`TOKEN
`
`BANK
`TERMINAL
`
`Send
`transaction
`details
`
`! t
`
`..
`
`I•
`I
`Display
`I
`transa ction
`I
`·
`I
`Authorise
`
`transaction �
`I
`.. ,
`Add date
`I
`and time
`I
`Sign with
`,_ _
`I
`PRIVATE key,
`send
`I
`I
`
`PUBLIC key !
`___ ---l.,�j Check signature
`.
`j with
`j
`!
`I
`1
`Transaction
`com plete
`
`i Send transaction i
`lr--- - ---- �
`j record
`
`authorisation and signature.
`
`r� I
`I I
`Fig. 6.2 Transaction
`
`
`integrated circuits, including the TMS32010 and an Intel 8085 to act as
`
`
`
`
`
`
`Battery maintained RAM was provided for storage of para­
`controller.
`
`
`meters such as keys and a record of transactions.
`Consideration
`
`
`was given to a semi-custom designed RSA processor
`at that time that
`
`chip in the early days of the project. It was considered
`
`
`
`the technology was not readily available for such a device and so an
`
`
`
`method of implementing the algorithm was sought. Texas
`alternative
`
`
`
`
`Instruments had just released the first in a series of fast processor chips
`
`
`
`
`designed mainly for signal processing applications. This device, the
`TMS32010,
`
`is a 16-bit microprocessor
`
`
`with an instruction execution time
`
`
`
`
`
`of 200 ns. The instruction set includes a signed 16-bit multiply executed in
`
`one cycle. Although not ideal (overflow and the sign bit caused problems)
`\:.'f.lS programmed
`
`to perform the RSA calculations. The
`this processor
`
`new design continues to use this processor.
`The TMS32010 has limited
`program and data memory spaces of 4K
`
`
`
`words and 144 words respectively. Further, there is no high-level language
`
`compiler and the speed of the processor
`
`
`makes it difficult to interface to
`
`
`
`
`slow peripheral chips. For these reasons, all the remaining functions of
`
`
`
`
`the token were placed under the control of a second processor. This split
`
`
`
`
`has several advantages; the two processors can work in parallel, thus
`
`Page 104 of 201
`
`

`
`Secure Transactions
`
`87
`
`reducing or even hiding the RSA calculation time, a high-level language
`
`
`
`
`
`
`
`can be used for the application softWare, none of the TMS32010 memory
`
`
`
`
`
`resources are wasted, and peripheral interfacing is easier and uses fewer
`components.
`Creation of the prototype enabled the development team to demonstrate
`
`
`
`
`
`
`
`
`
`such as access control, of the device in applications the correct functioning
`
`
`
`
`point of sale transactions and signature of alphanumeric messages. Since
`
`
`
`a the prototype was comparatively large, the next stage was to engineer
`
`
`
`
`smaller version. In order to reduce the size, the functions of a number of
`
`
`
`
`
`the separate integrated circuits were absorbed into one application specific
`
`
`
`
`
`integrated circuit (ASIC). The chip count was thereby reduced to 11;
`
`
`
`
`
`further space was saved by using surface mounting technology. The result,
`
`
`
`
`produced in collaboration with Texas Instruments, was a device similar in
`(about 14 em X 9 em x 1 em).
`size to a medium sized pocket calculator
`
`
`In the new version, the Intel 8085 is replaced by a member of the
`
`
`
`TMS7000 series of 8-bit microprocessors. As before, this processor also
`
`
`
`
`
`controls the RSA processor and all peripherals, maintains the secret data
`
`
`and runs the applic:ation program. 32 K bytes of program memory are
`
`
`available, most applications to date have used only half of this amount.
`
`
`8K bytes of battery backed RAM are built in for the storage of keys and
`other data needed for applications.
`All of the decoding logic, address latching and bus de-multiplexing for
`
`
`
`
`
`
`
`
`
`both processors have been reduced to a single semicustom chip designed
`at the NPL and fabricated
`
`in 1.8 micron CMOS gate array technology by
`
`
`
`Texas Instruments. Figure 6.3 is a block diagram showing the important
`physical
`
`
`
`features of the token. The display is a 16 character by 2 line
`
`
`
`
`
`liquid crystal display and the keypad consists of 4 rows. of 3 buttons. The
`reasons
`
`
`for including these on the token are given elsewhere in this
`
`
`chapter. The clock maintains information about the date and time of day,
`
`
`
`this is used in some applications to date stamp messages. Communication
`
`
`
`between the token and the outside world is by way of a three-wire serial
`interface.
`Communication between the two processors takes place over an 8-bit
`
`
`
`
`
`
`bidirectional bus buffer constructed in the semicustom chip. A data block
`
`
`
`
`containing the message, exponent and modulus required for an RSA
`
`
`
`
`calculation is sent to the RSA processor via this interface, the result is
`
`
`
`returned in a similar way. Block transfers are completed in a few micro­
`
`
`
`seconds, a time not considered significant when set against the calculation
`time.
`The token contains secret information unique only to itself. No other
`
`
`
`
`
`
`token contains the same secret so the compromise of one does not put the
`
`
`
`security of the whole system at risk. Nevertheless, measures must be
`
`
`
`
`taken to detect tampering and destroy the secret information upon detec­
`
`
`to falsify tion. Possession of the secret key would enable an intruder
`
`Page 105 of 201
`
`

`
`88
`
`
`
`Integrated Circuit· Cards
`
`Clock Keypad
`
`Display
`
`Serial
`1/0
`
`
`
`Control processor
`
`RSA
`processor
`
`Program
`Data
`memory
`memory
`
`Fig. 6.3 NPL token block diagram.
`
`transactions in which the token was engaged. The tamper resistance built
`
`
`
`
`
`
`into the prototype token simply detects .when the case is opened and
`
`
`
`destroys the secret data by discharging the. RAM chips. Although adequate
`
`
`
`
`
`for our prototypes, this form of tamper detection is nothing more than a
`
`
`
`
`gesture and new circuitry has been designed to perform these functions
`
`
`
`
`properly. We have indicated elsewhere the important functions performed
`
`
`
`
`by the display and keyboard; clearly these devices must also be included
`
`
`in the tamper protected area. It is necessary to note that tamper resistance
`
`will add significantly to the cost and size of the token.
`
`
`
`The speed required of the RSA calculation implies a device that con­
`
`
`sumes a lot of power. It is unlikely that this can be supplied conveniently
`
`
`
`
`to the token without direct electrical contact so the token takes its power
`
`
`
`are only RSA calculations 'from the terminal into which it is plugged.
`
`
`
`
`required when the token is communicating with a terminal, so it could be
`
`
`
`
`supplied separately; other functions such as a calculator, clock and a
`
`would then be run by the TMS7000 under battery operation.
`database
`
`
`
`
`The implementation of the RSA algorithm en the signal processor is
`
`
`
`
`
`capable of carrying out one full operation of the algorithm in about 3
`
`
`
`seconds. This implementation has been described by Clayden [5]. An
`
`
`increase of speed has been achieved by using the method [ 6] based on
`
`
`
`knowledge of the two primes that make up the public modulus. Knowledge
`
`
`of these primes is permissible in the device that holds the ·secret key. In
`
`other words the two primes method can be used to generate signatures,
`
`to reduce but not for checking them. By this means it has been possible
`
`
`
`
`the algorithm time for signature generation to about 1.4 seconds. For
`
`
`/
`
`Page 106 of 201
`
`

`
`Secure Transactions 89
`
`
`
`checking it is possible to gain a substantial increase in speed by
`signature
`the public exponent to, say, 17 bits. This places no restriction
`on
`limiting
`
`the size of the secret exponent and does not reduce the security of the
`
`
`
`signature operation. The speed of signature checking is not exactly in­
`
`versely proportional to the size of exponent because of overheads in the
`
`
`
`in checking time is possible. reduction computation, but a very substantial
`checking using this method takes 60 ms.
`In our implementation, signature
`
`6.5 MINIATURISATION
`
`It is possible to argue that a token carrying display and keyboard should
`
`
`not be reduced in size to that of the standard plastic card as has happened
`with the smart cards. Very many people now carry small pocket calculators
`
`as a matter of course and the intelligent token could easily be reduced to
`
`a compatible size. Smart cards have not yet been in wide enough use to
`
`allow a judgement to be formed as to their durability. If the ISO draft
`
`
`
`standards for physical properties of smart cards are to be regarded as firm
`guidance, then cards are going to need the ability to withstand very
`
`
`severe handling. A small calculator-like object can be made much stronger.
`
`We understand, of course, the desire to make the smart card compatible
`·
`
`stripe card standards because of
`
`
`in dimensions with the existing magnetic
`
`
`the volume of installed equipment accepting the latter.
`Of the 11 chips in the current token, 6 are memory devices and would
`
`
`
`be the first target for chip count reduction. Integrating these devices into
`
`
`the processor would also increase the security of the token. A low power
`
`
`
`processor could be permanently powered by battery; under these circum­
`stances it could also act as the time of day clock. A two chip token could
`
`
`be built today using semicustom microcomputers now available. A single
`
`
`
`chip design using the latest digital signal processors is a distinct possibility
`in the near future.
`
`6.6 BIOMETRICS
`
`It should be plain from the introduction to this chapter that we are not
`
`
`
`satisfied with the level of security achievable in systems designed around
`
`
`personal identification numbers. We have mentioned the possibility of
`
`
`replacing PINs by biometric methods. Because the N�L token is the size
`
`
`
`
`of a small calculator, it is a realistic aim to mount a suitable interface for
`
`
`biometric identity verification on the case of the token; this could be
`
`based on written signature, fingerprint, vein scanning, etc. It is convenient
`
`
`
`
`
`that the type of processor required for realising the ))iometric measurement
`
`is just the same type that has been used for the RSA implementation in
`
`Page 107 of 201
`
`

`
`90
`
`
`
`Integrated Circuit Cards
`
`the NPL token, a signal processor, such as the TMS32010. If a biometric
`
`
`
`
`identity verification method is to be implemented in the intelligent token,
`
`further work is required and this depends on achievement of acceptable
`
`
`performance in the chosen biometric identification method. It is unrealistic
`
`to expect that any biometric method will be totally error free and the
`overall transaction system design will need to take this into account.
`
`
`
`
`When a PIN is presented to an identity verification system there is no
`or it is not; in a biometric
`margin for error - the PIN is either correct
`
`
`
`system a degree of tolerance must·be built in to allow for variability in
`
`
`measurement. Because of this degree of tolerance, a higher level of
`
`
`
`
`security may be achieved by retaining the PIN as a supplementary check
`on identity.
`One method currently of interest relies upon the unique features in the
`
`
`
`blood vessel patterns on the back of the hand. This development, called
`
`
`Veincheck, is under investigation on behalf of the British Technology
`Group. If built into the token it might consist of a row of four infrared
`
`built into the base. Identification would be performed
`emitter/detectors
`by wiping the base of the token over the back of the owner's hand before
`confirming a transaction.
`
`6.7 FUTURE DEVELOPMENTS
`
`the to miniaturise Clearly, given demand for the device, it will be feasible
`
`
`
`
`
`
`token stm further, possibly even down to the compass of an
`intelligent
`
`
`
`ISO standard plastic card, yet carrying keyboard and display. Products of
`
`this type are already being designed by various manufacturers, but not
`making ·use of the signature
`
`capability of the NPL device. A smaller
`
`
`
`possibly and, therefore, device would undoubtedly be more convenient
`
`
`be more acceptable to users. Adoption of ISO card dimensions would
`
`ensure ·compatibility with magnetic stripe card readers adapted to take
`
`
`intelligent tokens. However, a very small size is not necessarily an advan­
`
`tage. The durability of a very small design of this nature is not yet tested.
`
`
`· User habits with plastic cards are notoriously
`bad and a very s�all token
`
`
`would have to be resistant to considerable mishandling.
`
`Even more critical than the size of the device is its cost. For mass
`
`
`
`penetration of a market low cost is essential, especially if the competition
`is provided by cheap magnetic stripe plastic cards. If the cost of intelligent
`
`
`tokens remains high, then their use may be limited to applications where
`cost is not so important.
`If it becomes possible
`to achieve a sufficiently low unit cost, then mass
`
`
`
`markets may become available and the token used for transaction control
`
`
`and payment for a wide range of services in many environments, such as
`
`
`
`
`in the home, in public utilities (transport, telephone, etc.), the office and
`
`Page 108 of 201
`
`

`
`Secure Transactions
`
`91
`
`in shopping. If the amount of internal storage can be increased significantly,
`
`
`
`the token applications can extend to serving as a personal memo, com­
`
`municating with a database held on a personal computer. It is· also
`possible
`
`to envisage applications in the medical field, with personal medi­
`
`cal records held within the token, and prescriptions issued by the doctor's
`
`terminal reading them terminal directly to the token and the pharmacist's
`
`
`securely. Because many people are quite happy to carry small calculators
`on their person, the addition
`
`
`of calculator functions to the token might be
`
`
`an attra�tive option. Addition of such a capability might overcome the
`
`problem of token cost. People willing to buy a pocket calculator might be
`
`
`addition in capability. only too willing to pay a little extra for the substantial
`
`In this chapter we have attempted to point out the need for an identity
`
`token with greater security than the magnetic stripe card. We are also
`
`concerned that terminal security in smart card systems may be a weakness.
`
`The intelligent token has the advantage of greater safeguard for PINs,
`
`
`
`whilst offering the further capability of ensuring the integrity of transaction
`
`
`
`messages. The cost of providing terminal security can be reduced by intro­
`
`duction of the intelligent token, because the terminal need not contain
`
`protected secret parameters.
`
`REFERENCES
`
`[1] Chorley, B. J. and Price, W. L. (1986) 'An intelligent
`token for secure
`transactions'
`Monte Carlo, December 1986, 442-4�0.
`Proc. IFIP/Sec'86,
`'
`[2] Price, W. L. and Chorley, B. J. 'The intelligent
`card'
`token or 'super-smart'
`Proc. SmartCard 2000, Vienna, October 1987 (proceedings
`to appear).
`
`[3] Commission of the European Communities (1986) Open Shops for Information
`
`Services (OSIS}, Final Report, Cost Project 11 ter, CEC, June 1986.
`[4] Rivest, R. L., Shamir, A. and Adleman, L. (1978) 'A method of obtaining
`Comm. ACM., 21 (2)
`digital signatures and public key cryptosystems'.
`
`120-126.
`[5] Clayden, D. 0. (1985) 'Some methods of calculating the RSA exponential'
`
`Proc. Int. Conf on System Security, Online, London, October 1985, 173-183.
`
`
`[6] Quisquater, J.-J. and Couvreur, C. (1982) 'Fast decipherment algorithm for
`
`RSA public-key cryptosystem' Leuers, 18 (21} 905-907.
`Electronic
`
`Page 109 of 201
`
`

`
`Chapter 7
`Automated Personal
`Identification
`Methods for Use with Smart
`Cards
`
`JOHN R. PARKS
`( J R P Consultants)
`
`on card holders are needed to
`The PIN is insecure. Biometric measurements
`
`
`confirm their rights of possession.
`
`7.1 INTRODUCTION
`
`or claim to represent
`
`some third
`The validation of a claimed identity
`
`party has historically depended on one o"r more of four characteristics of
`
`
`These are: the person presenting themselves.
`
`(1) some recognisable thing that he has, e.g. a key, a ring, a personal
`
`
`
`a card (magnetic, smart or otherwise), etc. In short a
`sign (signature),
`I
`token.
`i.
`(2) some piece of knowledge known only to authorised persons, e.g. a
`
`l '
`
`
`password (PIN), intimate personal detail (mother-in-law's sister's car
`registration
`
`number, or something simpler!), etc.
`
`
`
`(3) some inimitable characteristic of a physical nature, e.g. fingerprints,
`
`facial features, hand geometry etc.
`
`
`(4) some characteristic behaviour, e.g. speech pattern, gait, writing
`dynamics, etc.
`
`7.1.1 Tokens and things possessed
`
`The problem with using tokens to validate a claimed identity is that such
`
`
`
`
`
`
`tokens can be obtained by impostors, by finding, stealing, coercion, deceit
`
`
`or collusion. According to the uniqueness and technology involved tokens
`
`can, more or less easily, be copied or counterfeited. A token once
`
`Page 110 of 201
`
`

`
`
`
`
`
`
`
`Automated Personal Identification Methods
`
`93
`
`'detached' from its rightful owner has clearly compromised the security
`
`
`
`system which depended on it. Unless widely duplicated the risk is however
`limited to the new holder.
`The credit card is the best known and most widely used token today;
`
`
`its vulnerability the card is often supported by 'something
`recognising
`
`
`known' i.e. the ubiquitous Personal Identification Number (PIN). The
`snags with PINs are well known though they are still the preferred
`method for cash access purposes at autotellers.
`In a complex modem life
`
`has several cards each with a different associated PIN. The
`any individual
`
`problem of remembering the number which supports each card is significant
`
`and often (frequently) solved by writing down the number or a simple
`coding of it and storing it in close proximity to the card. There are
`
`
`documented accounts in the USA of a large proportion of recovered 'lost'
`
`cards having the associated PIN written on them.
`The advent of the 'watermark'
`magnetic card made 'skimming' (transfer
`
`of data from one to one or many other cards) more difficult as the card
`stock is validatable
`
`and very difficult to counterfeit, though this would not
`immediately
`
`
`prevent collusive use of two or more watermarked cards.
`
`The so-called 'smart card' or 'IC card', the central topic of this book,
`brings a further dimension to card tokens, namely their inbuilt and
`
`
`of counter­and also the extreme difficulty tamper resistant 'intelligence',
`
`feiting them.
`However, no matter how intelligent a token is, it is still independent of
`
`
`
`or foul, and is dependent its valid user and can be 'obtained', by fair means
`
`
`
`on associated knowledge in the user to 'activate' it. Such knowledge can
`
`similarly b� 'obtained'.
`
`7 .1.2 PINs and other knowledge
`
`In a face to face interrogation the bona fides of a person presenting
`
`
`
`himself and claiming a particular identity can be tested by cross-questioning
`
`him on the basis of personal details including knowledge of specific facts
`
`person also knows. If which the inquisitor knows that the presenting
`
`taken to sufficient depth and in time then such methods can be secure and
`
`
`
`
`impostors detected. However their use in a day-to-day commercial context
`
`
`would be unrealistic where speed is generally of the essence. Some recent
`Q/ A interrogative
`approach
`work in Japan has attempted to mechanise this
`[1].
`Secure commercial techniques have been developed for validating the
`
`
`
`authenticity of (coded) messages; systems of numeric 'passwords' have
`
`
`
`been devised and encryption techniques for protecting communication
`channels are well known, these are described elsewhere in this book.
`There are also simpler methods based on the knowledge of a simple four
`
`Page 111 of 201
`
`

`
`94
`
`
`
`
`
`Integrated Circuit Cards
`
`or five digit number to support a presented token, the ubiquitous Personal
`
`
`
`
`
`
`Identification Number (PIN) or its counterpart for access control the
`Personal
`
`
`Access Number (PAN). These are only useful to protect modest
`
`
`
`security is not very high. value because their intrinsic
`As already mentioned, the practical problems of remembering several
`
`
`
`
`
`
`
`
`multidigit numbers are often overcome by writing the numbers down and
`
`
`
`storing this record close to the relevant cards. Banks are still very depen­
`
`
`dent on simple PIN systems but have eased the user's memory problem
`
`
`somewhat by allowing him to invent his own number. This eases one
`
`
`
`problem but creates others in that numbers invented are likely to relate
`
`
`
`to the individual (e.g. birthdate (self or spouse), telephone number,
`closely
`
`
`etc.) and to be used as 'universal PIN numbers' for all the cards held by
`
`
`
`
`
`that individual. Non-random numbers are likely to be more easily guessed
`
`
`
`or observed; universal numbers once 'cracked' then compromise all that
`
`individual's cards.
`There is therefore a place for automatic techniques to verify the pre­
`
`
`
`
`
`senter of a token as well as to verify the token. The rest of this paper
`concentrates
`
`
`on this possibility with no further comment on the design of
`
`
`tokens or of the use of 'knowledge' to support them.
`
`7.1.3 Automatic Personal ldentificatio� (API)
`
`I
`The topic of automatic verification of claimed identity or of direct recog­
`
`
`
`
`
`
`nition of persons has been current for at least 15 years, for example,
`
`
`
`
`
`
`palmprints (Palmguard 1969), fingerprints (IBM 1965), speech (IBM 1967),
`
`
`and signatures (Connetta 1969)).
`After several years research commercial products have emerged during
`
`
`
`
`
`
`
`
`the past decade, e.g. Identimat (1978), Qsign (1982). More recently a
`
`
`
`
`trade association and an API vendors' spate of products have appeared
`has emerged in the USA.
`Several signature-based systems using dynamic signatures, i.e. using the
`
`
`
`
`
`as well as pictorial nature
`dynamic
`
`
`of a signature as 'it is written, have
`
`
`
`There are also some been developed (Quest, AITSL, Signify, Confirma).
`
`
`
`
`
`systems for verifying 'cold' or static signatures for use in for example,
`
`
`
`
`clearing cheques for payment (ROCC, AutoSig). IBM have been working
`
`on a dynamic signature verification system continuously for some 15 ·years
`
`
`
`
`
`and are widely rumoured to be releasing a product 'soon'.
`
`
`
`
`Fingerprint·�ystems for commercial (Fingermatrix, Thumbscan, Identix)
`
`
`
`or forensic (De La Rue Printrak, NEC, Morpho) purposes are available.
`Retinal
`
`
`patterns of blood vessels (EyeDentify) are used for high security
`
`
`low throughput access control. Hand geometry (Stellar (IDENTIMAT),
`
`
`
`
`Recognition Systems Inc.) and palm prints (Palm guard) find favour for
`
`
`
`mass access control. Keystroking rhythms (BioAccess) at the keyboard
`
`Page 112 of 201
`
`

`
`
`
`
`
`
`
`Automated Personal Identification Methods 95
`
`Much offer a method for co�tinuously verifying the user of a terminal.
`
`
`has been written about voice-based
`systems and some useful demon­
`
`
`
`
`strations have been staged (though generally for security applications and
`behind closed doors); two commercial products
`
`are available (ECCO,
`
`
`continues to be researched but, so far, no
`Votran). Facial recognition
`commercial system is yet on offer.
`
`7 .1.4 Anatomy, and performance
`specification and measurement
`
`Before describing individual approaches and methods of API it is useful
`
`
`
`
`to outline the anatomy of any API system in schematic form (Figure 7.1).
`The general form begins with an input transducer to capture the property
`
`i.e. a microphone for speech, xy digitiser
`being used for verification;
`for
`
`
`
`written signatures, video-camera for fingerprints etc. The transducer output
`
`
`
`signal is then subject to signal analysis. After analysis the signal changes
`
`
`for the process of enrolling new users or for live-use with previously
`
`enrolled users. The enrolment algorithm manages the collection and
`
`
`
`storage of reference inputs from the enrollee. In live-use these references
`are used in a comparison process to assess the mismatch between an
`
`offered specimen and the stored references. A decision mechanism then
`
`either accepts the specimen against the referen�s, .requests another speci­
`
`
`men, or, after repeated unsuccessful attempts rejects the user. This decision
`
`
`mechanism is often part of the host-system, this is discussed further
`below.
`
`
`
`
`Clearly before a potential user of an API device can proceed he has to
`
`Input
`device
`
`Signal
`analysis
`
`.--'-----.0
`r-'- -- - �'c
`r-'-- --�B
`Stored A
`customer
`reference
`characteristics
`I
`_J
`Yes
`(Accept)
`
`Enrolment
`algorithm
`
`Uve use _______ _.
`- -
`--
`r- '
`
`Comparison 1---<
`I
`
`Interface to
`
`application system
`
`Doubtful
`(Retry)
`
`No
`(Reject-
`system assistance)
`Fig. 7.1 Biometric system schematic.
`
`Page 113 of 201
`
`

`
`96
`
`
`
`
`
`Integrated Circuit Cards
`
`be admitted to the system through an enrolment process, subsequent live­
`
`u